IEC 61850 for Newbees - Traffic Engineering with IEC 61850-6 (SCL)

I agree: The standard series IEC 61850 is quite comprehensive ... some believe it is complex. Ok. What can I do to help you getting a better understanding? I will try to help you. 

Today I will show how IEC 61850-6 (SCL, System Configuration Language) can be used for traffic engineering - traffic means: "signals" are communicated back an forth: analogue measurements, status measurements, control, configuration, event-driven reports, event-driven logs, ... start and stop of event recorder, trip-signals, ... in IEC 61850 "signals" are named and a binding of an instance to the application process (e.g., Bay1 Circuit Breaker 2) is specified ...

I am using a brief prose language ... this description could be transformed to an SCL compliant (machine processable ) XML file.

The many "signals" are travelling from a source to a destination ... let's say the following valid (allowed) routes are:

1. A->B,
2. B->A,
3. V->A,
4. A->C, 
5. D->E, 
6. R->S, 
7. R->A

Each letter is representing a source or destination of the "signal" flow. The "->" is representing one of the specific "signals" standardized in IEC 61850. In the first route A sends an operate to B and B is reporting back to A a changed status information ...

In SCL we can configure now for each route in detail the sources, destinations, strongly typed "signals", communication services, ... The SCL compliant System Configuration Description (SCD) would list all details on all routes ... 

The source knows by the SCD document which "signal" is to be sent (when and how) to which destination. The destination knows by the SCD document which "signal" it receives (from which device, when and how).

What else can we do with the SCD file?

1. A tool could check if all source and destination (devices) are specified ... a source A is configured to send a signal to B ... Is B at all specified? Maybe it was forgotten.
2. A tool could check if for all source and destination devices the addresses are configured. 
3. Another tool could check if all traveling "signals" (messages) are specified in the SCD document. A "signal" that travels during online operation from X to B (here X tries to connect to B) is not specified and thus NOT ALOWED. The tool could rase the red flag telling the system engineer that an unknown device X is active on the network. 
4. ... many other possibilities are listed in the following figures from my seminar slides (some 10+) years old.

I hope you got an impression what IEC 61850-6 (SCL) could provide.

SCL is the backbone of IEC 61850!

Check HERE for a crucial use-case for SCL (cyber security ...).

Let me know if you have a question on this post.

Siemens PCS7 (TIA) PowerControl Station Gateway connects PLCs with IEC 61850 IEDs

In a post earlier today I wrote: "It does not make sense to decouple power systems from big(ger) applications." ... this reminded me to discuss another use case ... factory automation to substation ...

Siemens offers PLCs with the PCS7 family. They have developed gateways that bring the substation closer to the power user ... 

PCS 7 PowerControl Station Gateway connection of a SIPROTEC 5 protection device (speaking IEC 61850!)

The brochure states at the beginning: "In addition to the demanding process automation requirements in many industrial plants, it is also necessary to integrate the medium-voltage power supply switchgear into a complete automation system.

Components of such plants are electrical consumers with high energy requirements (factories, chemocal plants, ...). Individual consumers are monitored and controlled via protection devices, also known as IEDs (intelligent electronic devices)."

So, my statement on the post earlier today has been confirmed! 

The same is available for the integration of a substation into a Siemens TIA (Totally Integrated Automation) ... TIA Station Gateway: excerpt of that page:

"With the new IEC 61850 server functionality, you can extend your station gateway integration allowing you to reliably publish process data directly to IEC 61850 clients via GOOSE Publisher or MMS polling and reporting with a high degree of performance. Whether protection systems, instrumentation and control or automation environments: The publisher ensures that events are quickly transferred and facilitates fixed data models and the highest degree of interoperability."

WOW.

IEC 61850 covers applications inside substations AND beyond substations

IEC 61850 is applicable for general automation applications as well as for electric power delivery systems. The following lists give an impression of what kind of domains are taken into account so far ... more to come:

Information models and exchange for

• real-time and near real-time applications  (pub/sub: GOOSE, Sampled Values)
• protection
• monitoring, supervision, and control (client/server TCP/IP and WebSocket)
• substation and feeder equipment
• substation-to-substation
• substation-to-control centre
• power plant-to-control centre
• distributed generation
• distributed energy resources
• micro grids
• metering
• power quality
• condition monitoring
• hydro, steam, gas power plants
• wind generation plants
• data centers
• …

System Configuration and engineering

• System Configuration Language (SCL)
• Basic Application Profiles
• top-down-engineering (model-based engineering)
• - …

These lists demonstrate that the standard series IEC 61850 covers applications inside substations AND beyond substations. One crucial question remains: What are the logical nodes and data objects ... from which parts of the standard series IEC 61850 are required for a specific application domain?
The answer is here: ask me.

HERE you can find a sample model for an IEC 61850 Profile for Distributed Energy Resources Supporting IEEE 1547 [pdf] ... quite interesting ...

You may search the web for MICS (IEC 61850 model implementation conformance Statement) ... 

Note that substations are very crucial components of the interconnected electric energy systems.

Let me know if you need some help.

How are IEC 61850 Information Models related to Functions?

The common understanding of information is crucial for the understanding of the related functions that produce, consume, and exchange the information. Information is always "bound" to functions ... no function - no information.

Let's have a look at this function: 

Supervision of a temperature value ... report an alarm to a well known entity when the temperature change rate reaches a value of xyz ... this is the FUNCTION. Now we model it with IEC 61850:

The temperature supervision is modeled in the logical node MySTMP1. We use the data objects Tmp (reported every x minutes), RteAlm (reported when the value of the RteAlmSet is reached, e.g., 0.5 K/s).

This "function" is described in an SCL document ... here the MySTMP1 is bound to a topology (SSD), e.g., room temperature in building so-and-so, the reports are sent to the SCADA system mySCADA-client, ... the factory acceptance test can more or less be automated based on the SCL document.

The IEC 61850 STMP logical node model follows the temperature supervision function!! 

The function was there well before IEC 61850 was born!

IEC 61850 standardizes the information shared with a real function.

The following diagram shows the basic modelling approach in IEC 61850:

• IEC 61850-7-2 defines the foundation
• IEC 61850-7-3 defines the common data classes: MV for measurements, SPS for single point status, and ASG for analogue sessings.
• IEC 61850-7-4 defines the logical node and data object classes.

More details will follow ... stay tuned.

The real challenge with IEC 61850 is: You likely get the feeling when you start reading hundreds of pages: unable to see the wood for the trees.

Let me know if you need help ... after 30 years I can support you.

Is IEC 61850 an old Standard?

What do you think? It depends ... IEC 61850 is a standard series of many parts ... published in different years ...

The other day I was reading that somebody on LinkedIn beliefs that IEC 61850 is old ... Oops. Here is what I answered:

I was involved in the development of MMS (ISO 9506, starting mid 1980s), later in ICCP (TASE.2, IEC 60870-6, using MMS), then IEC 61850 (starting 1995, using as well the "old" MMS). 

The AC interconnected power systems have been developed more than 130 years ago ... and improved since then ... AND: Yet we do not complain that they are OLD. They have done a great job. Old wine may be better than young wine ... or?

The standard series IEC 61850 has many aspects to consider: 

• System Configuration Language (SCL, IEC 61850-6) is brand new! 
• GOOSE and sampled values are brand new! 
• The many standard "signals" like MMXU.Hz for frequency measurement are old in the sense that frequency is a physical given.
• There is something we may call "old": the use of the "old" MMS as the protocol for client/server communication according to IEC 61850-8-1 (-8-2). ok.
• There is an alternative new web-based solution under way: IEC 61850-8-3 (a new protocol for client/server in IEC 61850 ... WebSocket transport, ASN.1 message schema, ASN.1 JSON encoding rules, and ASN.1 DER encoding rules).

If you want to learn why the Netherlands DSOs initiated the IEC 61850-8-3, check HERE.

A great reply says: "The transport choice is what stands out: MMS was never reachable from a browser, WebSocket with JSON encoding is, which changes what client tooling can be without an install."

There are other brand new parts of IEC 61850 just published, e.g., IEC 61850-7-410 for hydro, gas, and steam power plants.

IEC 61850 for Battery Energy Storage Systems (BESS)

With the growth of planning and installation of BESS the question is discussed, how IEC 61850 could contribute. A lot!

Have a look at three posters that depict the architecture of an electric system that includes batteries ... with some comments from me:

Poster 1
Poster 2
Poster 3

See also a paper on the use of IEC 61850-7-420 (DER) from the year 2014.

Communication networks and systems for power utility automation –
Part 7-420: Basic communication structure –
Distributed energy resources and distribution automation logical nodes

Preview of IEC 61850-7-420 (2021).

A few excerpts:

The DER storage Logical Nodes in IEC 61850-7-420 have hundreds of Data Objects ... see just a few:

IEC TC 57 offers a name space document listing the syntax of all logical nodes and data objects:

That (light) name space is an xml document with 5520 lines !!! The light name space contains the syntax of the models ... the textual semantic is missing ... comes with the purchase of the standard IEC 61850-7-420.

I am confident that IEC 61850 offers the most crucial information models for BESS.

Are WebSockets the future for real-time communication?

WebSockets provide a way for web browsers and cloud apps to talk directly to devices for automation and monitoring. A WebSockets create a two-way open communication channel. It wraps messages (according to various message schema, e.g. in ASN.1 notation) in web-friendly formats like JSON. This bypasses strict firewall rules without needing complex, heavy software.

WebSockets are used in many solutions like OPC UA, OpenADR, ... and soon in IEC 61850-8-3 (alternative for MMS). 

How do WebSockets perform in a PLC environment where usually special industrial communication protocols are used? An interesting paper discusses this question:

"Latency Analysis of WebSocket and Industrial Protocols ..."

WebSockets are likely to becoming the future standardized web-based "carrier". 

The Netherlands Distribution Service Operator have shown with a PoC (proof of concept, now used for the definition of IEC 61850-8-3) that standardized (!) WebSockets can exchange IEC 61850 standard(!) messages containing data values produced and consumed by the huge amount of standardized (!) IEC 61850 models, configured by a standardized configuration (!) language (SCL, IEC 61850-6), and encoded in a standard (!) JSON format.

Background information can be found in my video

Feedback on LinkedIn: "This presentation made everything much clearer! But seriously, using WebSockets as a transport for industrial protocols is a really good idea."

IEC 61850 in Cyber Secure Environments - New Comprehensive Seminar

Due to my family situation (nursing my beloved wife from 2017 to 2022) I had to slow down my training activities. This year I was asked by several senior experts if it would be possible to resume the training.

As a result of discussions with friends of mine, we updated our previous course program and offer a brand new 5-day comprehensive public seminar for Automation, Protection, Monitoring, Engineering, Configuration (SCL), SCADA, Smart Grids, RTU, Gateways, … cyber physical security in electrical systems of any industrial plant … it is available for you and your people.

The reason for the update: We want to do more than teaching the theory of IEC 6850 and demonstrate single IEDs … we want to let our practice talk for your practice. The new training will start in March 2026. Taking the experience with many crucial applications of IEC 61850 into account we offer a new program for a 5-day course conducted by four (4) real experts.

09.-13. March 2026, Karlsruhe (Germany)
21.-25. September 2026, Karlsruhe (Germany)

Click HERE for more details on dates, location, and registration information.

Why Do We Need IEC 61850 (SCL) Based System Configuration Descriptions?

IEC 61850 has been developed in the late 1990's mainly by protocol experts and protection engineers - results are well done and applied all-over. Later IEC 61850-6 (SCL - Substation System Configuration Language) was in the focus. Now, 30 years later the industry has learned that the System Configuration Description goes far beyond information models and communication networks and services - AND PROTOCOLS. The crucial aspect is about a COMPLETE description of the WHOLE system ... from device independent descriptions of Functions and Function Models applying a Top-Down-Modeling-Approach. Work towards this approach is going on in several projects, e.g., IEC 61850-90-30 (IEC 61850 90-30 – IEC 61850 Function Modeling in SCL). A nice description from Jörg Reuter (Helinks) can be found HERE from the pacworld magazine. IEC 61850 based aspects is - of course - just one (crucial) aspect of a system. There are more aspects ... like Hardware, Software, Cybersecurity, Operation, ...

In addition to getting a complete system specification based on SCL to get a running IEC 61850 based system that does the job you want to have ... there is another crucial aspect: Engineers may be happy to use a complete SCD file to configure everything and then forget the SCD file ... don't forget it BUT keep it up-to-date and NEVER EVER make any change in the system without updating the SCL based System Description! 

You may need the complete and updated SCD file to help you "protecting" yourself in case there is a damage or an accident ... when "a fleet of well dressed lawyers who will use the lack of that document to make you all look guilty after ..." may arrive immediately after ... as Jake Brodsky (a well known engineer) just published in an article about "Industrial Cybersecurity “Gatekeeping”" ... worth to read.

Here is one excerpt from his article: "Take the time to find out where the important documents are such as the Standard Operating Procedures, the chemical Safety Data Sheets, and especially the Control System Narrative documents are located. If you can’t find the control system narrative documents, stop. Get someone to agree to write them with you. This is effectively your contract with the engineers, technicians, and operators that indicates in plain language what is supposed to happen normally and in most upset conditions. If you’re operating without that living document you will all be fodder for a fleet of well dressed lawyers who will use the lack of that document to make you all look guilty after an accident."

What could be done to get and maintain such complete descriptions of various aspects of a system? Do we need more lawyers, politicians, engineers, ... ? 

I am kidding (just a bit): "Hire a lawyer to escort you when you have an interview for a new position as a responsible engineer in a utility or ... in order to figure out (by the right questions of the lawyer) that the company applies with what Jake Brodsky recommends!"

What we really need is more engineers ... gray-hair experts that know a lot about the systems ... that could write down what the systems do and how they work ... and that could train the young people ... BUT: it isn't easy to convince the management to let the engineers learn from the experienced, gray-hair experts ... gray-hair engineers could lead the horses to the water - but they cannot make to drink it. 

What do you think? Let me know!

Some Hints On Static And Dynamic Reporting According To IEC 61850

Let me briefly help to understand the term dynamic and static regarding reporting:

Every report control block must be “created” in an SCL file – no way to create a report control block with a service.

Several report control block attributes can be configured in an SCL file or set (overwritten) by a (MMS) service.

A data set can be “created” in an SCL file or by the optional service CreateDataSet.

The term “dynamic” could apply to the setting/overwriting of report control block attributes, and the creation of data sets.

In one case with a Gateway from a well known vendor (as a client) I have seen that the client always defines the data sets dynamically!! And links a given report control block to that created data set. If a server does not support the service CreateDataSet, then you get into trouble …

A nice summary can be found here:

https://wiki.lfenergy.org/pages/viewpage.action?pageId=56380504

For operational functions (protection, control, …) the only dynamical services that should be allowed are to enable or disable the report control blocks. This should be configured in the corresponding SCL file for an IED by setting the attributes to “Conf”:

<ReportSettings cbName="Conf" datSet="Conf" rptID="Conf" optFields="Conf" bufTime="Conf" trgOps="Conf" intgPd="Conf" resvTms="true" owner="true" />

Example of a device from a well known vendor I received the other day:

<ReportSettings cbName="Conf" datSet="Dyn" rptID="Dyn" optFields="Dyn" bufTime="Dyn" trgOps="Dyn" intgPd="Dyn" resvTms="true" owner="true" />

Dynamic setting or overwriting of control block attributes or creation of a data set by a service could cause a lot of troubles!! Client and server should not allow it!  A well known RTU (client) overwrites dynamically a report control block attribute (in the server) immediately after it has connected to the server … that should not be accepted.

It could have a big impact on testing, e.g., you expect that a report (or GOOSE, SMV) message has a structure defined by a data set “X with 5 members” (according to the SCL file) … but you receive a message with 3 members (from data set Y) only … because somebody has overwritten the attribute “DatSet” of the report (GOOSE, SMV) control block. 

IEC 61850 is very flexible … to cause trouble … if you want to trust, that the device is 100% as shown in the SCL file, then NO dynamic modifications should be allowed!

Do you want have a problem - no problem!

By the way, Andrea Bonetti wrote the other day: "It is a good practice followed by the majority of the TSOs that do write their own IEC 61850 specification (sort of “dynamic reports are not allowed unless for testing/debugging”). It is also mentioned in IEC TS 63266:2023 (Representation of communication in power utility automation)."

What is an IED (Intelligent Electronic Device)?

IEC 61850 deals a lot with IEDs. But: What is an IED?

First you can check with two documents of the series IEC 61850:

IEC 61850-1 - Intelligent Electronic Device (IED)
any device incorporating one or more processors with the capability of receiving or sending data/control from or to an external source (for example, electronic multifunktional meters, digital relays, controllers)

IEC 61850-1 - Physical Device (PD)
equivalent to an IED as used in the context of this standard

IEC 61850-5 - Intelligent electronic device (IED)
device incorporating one or more processors with the capability to execute application 
functions, store data locally in a memory and exchange data with other IEDs (sources or sinks) over a digital link

Many years after these definitions have been published, we have different views on the term IED:

Physical IED (in the context of IEC 61850 and IEC 61400-25) - any physical device incorporating one or more processors with the capability of exchanging information (derived from IEC 61850 information models and exchanged with IEC 61850 services for client/server and publisher/subscriber) with other physical device(s). The semantic, the coding and decoding of the exchanged information (messages) follows the standard series.

IED Configuration (in the context of IEC 61850 and IEC 61400-25) - formal description (section in the SCL according to part 6) of the IEC 61850 information models linked to the IEC 61850 information exchange roles client, server, publisher, or subscriber, and the signal flow between physical IEDs.

IED Role (in the context of IEC 61850 and IEC 61400-25) - implementation of the IED Configuration: implementation of the IEC 61850 information model plus implementation of any combination of the following information exchange roles: client, server, publisher, or subscriber.

A Physical IED can host any combination of IED Roles.

Note: A gateway may host a server role to an up-link (first SCL file plus a client role and a subscriber role (both configured in a second SCL file) to the underlying Physical IEDs.

Please note that in SCL a Server configuration comprises the models including the DataSets, Report Control Blocks, GOOSE Control Blocks, SV Control Blocks, and Log Control Blocks:

From a communication point of view GOOSE and SV publisher and subscriber are NOT part of the client/server communication ... 

I hope this definition will help to reduce the disconnects in the communication of the experts.

Let me know what you think.

IEC CDV files available for Public Commenting - circulation date 2023-08-11

 Dear Friends of IEC standards, I just remember you that IEC lets you comment on published CDVs (Committe Draft for Vote) ... 

Click HERE for general rules, :

IEC Public Commenting

Help shape international standards if you have the requisite technical expertise. Public commenting on draft IEC Standards is open for a two month period

Currently the following IEC 61850 document is open for comments ... you have to login with your IEC account or register for an account:

57/2602/CDV 

IEC 61850-6/AMD2 ED2: Amendment 2 -
Communication networks and systems for power utility automation -
Part 6: Configuration description language for communication in electrical substations related to IEDs 

CLOSING DATE FOR VOTING: 2023-11-03

Please take your time to review the document ... You may agree with me that part 6 (SCL) is a crucial part of the series IEC 61850!

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."

IEDScout 5.00 Available - One of the Most Crucial Test Tools for IEC 61850

IEDScout is a well known test tool for most of the needed support in the communication with IEC 61850 compliant devices.
Omicron has released the version 5.00 ... providing crucial extensions compared to version 4.2:



IEDScout is a versatile software tool for working with IEC 61850 devices. With Version 5.0, IEDScout offers a new level of cyber security and powerful simulation utilizing the new MBX1/RBX1 hardware.
Additional improvements are:

• IEDScout now supports function-related naming for logical devices
• The icon set has been updated to provide a smooth user experience when used together with StationScout/StationGuard.
• When writing data to an IED, IEDScout will now automatically update the “t” attribute of the data object.
• Improved screen scaling for better readability on high resolution screens.
• License information is now available in the configuration dialog.
• OMICRON’s IEC 61850 library has been updated to include the latest developments in standardization and improve interoperability.
• The usability of IEDScout is continuously improved based on expert reviews and customer feedback.
• Several smaller tweaks and bug fixes improve overall performance and stability.

Click HERE for more information on IEDScout 5.0

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

3-Day Training for Electrical Engineers New to IEC 61850

3-Day Training for Electrical Engineers New to IEC 61850

17-19 March 2020 | London, UK

Day One: Tuesday 17 March
Core Concepts
Overview of IEC 61850 and introduction to the core concepts, including the hierarchical data model, communication services and the range of applications possible.

Day Two: Wednesday 18 March
Engineering and Configuration
Deep-dive into the IEC 61850 engineering process, learning how to use Substation Configuration Language and engineering tools for IEC 61850 specification, system design and IED configuration.

Day Three: Thursday 19 March
Testing
Learn how to thoroughly test IEC 61850 systems, including functional and system testing as well as gaining an overview of cybersecurity considerations for IEC 61850 systems.

Click HERE to learn more.

Why Is It So Easy To Map IEC 61850 Signals to JSON Objects?

IEC 61850 defines Device Models for the exchange of information between any two or more entities. The Models are structured as unique branches of a tree.That means:

Each path from the Device (Root) to 

any node or leave of the trees is unique

The signals are composed of an access reference (LDName/LNName.DOI. ...) and the value that corresponds with the path.

Example of two leaves:
LDName/Tran1STMP1.Tmp.mag.f = 23.5 (Temperature value)
LDName/Tran1STMP1.Tmp.units.SIUnit = °C (Temperature engineering units)

These are key-value pairs that could easily map to JSON Objects:

"LDName/Tran1STMP1.Tmp.mag.f " : "23.5"
"LDName/Tran1STMP1.Tmp.units.SIUnit" : °C

These JSON objects are

• Light-weight
• Language independent
• Easy to process with Python, ...
• Text based and human readable 
• JSON Schemas could support automatic (syntax and semantic) checks
• JSON is supported by many controllers

The controller of our PV inverter from Fronius has an http/JSON interface. The following request (lines 1-3) returns many common inverter data (line 21ff):



Lesson learned: Controller in inverter could easily provide an http/JSON interface.

The Device Model is a virtual model that could be configured using the SCL (System Configuration Language, IEC 61850-6). The Device Model is implemented in an IED and could be accessed to get the self-description, read, write, send/receive reports, publish/subscribe, ...

An IEC 61850 Server hosted by an IED could easily map the model to JSON objects that may be communicated with MQTT, HTTP, ...

The mapping to JSON is quite easy. It could be implemented by a simple automatic process that parses the model (SCL/XML), searches for the paths and concatenates the names from the root to the leaves to get the reference! AND: the mapping preserves the semantic - the meaning represented by the path name.

The mappings of IEC 61850 Models to IEC 60870-5-104, DNP3 or Modbus would result in messages that have lost the semantic of the signals. These solutions have mainly numbers as reference - these numbers have no meaning in the communication.

Many IEC 61850 Projects Under Progress

37 new parts and parts under revision are under progress as listed in the following table:

As you can see here: IEC 61850 is a bit more than another protocol.

Other parts are published already (some of them are under revision - see above):
https://webstore.iec.ch/publication/6028



Unfortunately many "grey-hair experts" with a lot of experience regarding IEC 61850 have been retired and a lot of experience has been wasted ... politics cares more about wasting food than wasting "experience" good for human survival! It's really a pity when we take into account that the comprehensiveness and complexity of IEC 61850 is growing so fast ...

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.