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. 

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. 

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.

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.

Difference between IEC 60870-5-104 and IEC 61850

There seems to be a growing interest to understand what the difference is between IEC 60870-5-104 and IEC 61850. There have been many discussions, complaints, and frustrations ... no wonder.Here is what I have answered to somebody this week:

Dear xxx,

I guess I got it ... you are analyzing the communication inside a station ... to the IEDs (protection, control, ...).

The IEC 60870-5-104 plus a lot of utility or project specific (signal) engineering will do the job – has done it for decades.

The engineering is the key issue when comparing the two standards … if you can compare them at all!!

IEC 61850 offers a lot more than 104 or DNP3 …

From a message overhead point of view, you can say, that both are more or less the same ... because they use both Ethernet and TCP/IP. There is no benefit to use one or the other.

It is likely that IED vendors will mainly focus on IEC 61850 ... and may get rid of 104 in the long run.

I have always said that utilities using 104 in all substations should continue to use it – until they build new substations or do major refurbishments. There is no need to replace a running 104 solution with IEC 61850 ...

Another issue is: To use GOOSE for interlocking … to get rid of copper … or use it for tripping … and use sampled values some time down the road.

Finally there is an issue with manpower: If the utility has senior experts in 104 close to retirement … they should wait until they have retired. Yes! I have seen many old engineers not willing to learn something completely new!!
Click HERE for a detailed comparison written by domain experts.
Hope that helps a bit more.
Best Regards,

Karlheinz

IEC TC 57 Has Published New Work Proposal For IEC 61850-6-3

IEC TC 57 has just published a new work proposal for IEC 61850-6-3 proposed by the Chinese National Committee:

57/2075/NP
Communication networks and systems for power utility automation –
Part 6-3: Configuration description language for physical resource related to IEDs in substation network systems

CLOSING DATE FOR VOTING:
2019-05-03

Scope:
"The international standard defines the emerging requirements from physical resource description side to facilitate the design, system integration, test, fault analysis and commission, etc. during different stages when IEC 61850 is applied. It described how the physical resource information, such as IED’s dimension, communication port and optical connection, is to be modelled using the System Configuration Language (SCL) which is incorporated under IEC 61850. The application scenarios include but are not limited these mentioned stages.

Furthermore, IEC 61850-6-X helps to fill a gap and establish a relationship between logic function and physical resource information according to the existing IEC 61850 communication structure and configuration description language. The initial focus on application within substations, includes following cases:

• Physical information related to infrastructure in electrical substations, including cubicle, trench, optical, wire, etc.
• Physical information related to devices in electrical substations, including device dimension, amount model, physical port, etc.

The proposed international standard specifies a file format for describing dimension, communication connection port, optical wire, cubicle, trench related to IEDs within substations, and the relations between them and logical functions."

The NP notes that "In China, by the end of 2016, nearly 3,000 substations of 110 kV or above based on IEC 61850 had been under operation."

The standard series IEC 61850 is really growing in 2019, see extra post.

IEC 61850 Applications in Germany - DKE Documents Online for Free Download

The German National Committee of IEC TC 57 (DKE K 952) has many members of various Working Groups (in the national as well as in the international groups) that discussed the IEC 61850 standard series in general and particularly how the standards could be applied to substation automation and protection. One of the key issues is the modelling and configuration using SCL.

Several documents in German and in English are available:



Click HERE for the link to the above page.

Enjoy the documents.

Draft TR IEC 61850-7-6 published: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850

IEC TC 57 just published the 68 page draft Technical Report IEC 61850-7-6:

57/1986/DTR

Communication networks and systems for power utility automation –
Part 7-6: Guideline for definition of Basic Application Profiles (BAPs) using IEC 61850

Voting closes 2018-06-08.

"The IEC 61850 standard series offers a broad basis for communication networks and systems in power utility automation. Due to its broad coverage of power utility automation applications, it is up to the standard’s user (utility, vendor, system integrator…) to pick and choose specific options from the standard in order to meet the requirements of the intended objective. As a consequence, implementations of IEC 61850 represent specific subsets of the standard.
In the context of standards the term “profile” is commonly used to describe a subset of an entity (e.g. standard, model, rules).
Accordingly an IEC 61850 standard profile contain a selection of data models (mandatory elements), communication services applicable and relevant engineering conventions (based on the Substation Configuration Language SCL defined in IEC 61850-6) for an application function of a specific use case in the domain of power utility automation.
Depending on the scope and objective different profile types can be distinguished:

• User profile – defined subset that is valid for a specific user / organization (e.g. utility)
• Product / Device profile – implemented subset in a specific vendor product /device
• Domain profile – defined subset for a specific domain and relevant use cases (e.g. monitoring of substation)
• Application / function profile - subset covering a specific application or function (e.g. substation interlocking)

These profile types target on reducing complexity and facilitate interoperability for their specific scope and during engineering and device / substation lifetime. In order to achieve both these goals - a properly defined profile and appropriate implementations (processes, tools, products) that support the profile are required."

Note that IEC 61850 is not that complex - but it is very comprehensive!!
Comprehensiveness with regard to:

1. Number of parts: some 50 inclusing drafts
2. Number of Logical Nodes
3. Number of Data Objects
4. Configuration language
5. Number of task forces working on new stuff
6. Number of applications that can be covered
7. ...

The most crucial challenge is this: How can I find what may be of interest for my application? I hope somebody will do a good job in preparing an overview of models published and under preparation.
Let me know if you are aware of some good document or website ...

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.

Read One of the Best Papers on IEC 61850 ever Published

Eric A. Udren (a friend of mine) from Quanta Technology, LLC of Raleigh, North Carolina has written one of the best papers on the application of IEC 61850 in general and in the USA I ever read:

What Drives the Business Case for IEC 61850?

published in the December 2016 issue of the PAC World magazine.

This paper summarizes the experience of more than 10 years with the application of the standard series IEC 61850. It is a very easy to read and understand summary of the content of my training courses. After more than 230 training courses I conducted globally since 2003 and more than 4,200 experts educated in these courses I fully agree with the crucial recommendations of the paper:

Eric states at the very beginning (3rd sentence!): " ... one must first understand that IEC 61850 is not just a communications protocol." Well said. He lists many crucial facets.

The main part of Eric's conclusion is [highlights are added by myself]:

"The following action items can help the utility to achieve technical success and lowest life cycle costs:

• Develop requirements for and relationships with product vendors, who must commit to support interoperable and sustainable products and designs over the service life of the PAC design.
• Apply the sustainable design principles of the previous sections. If some of these seem unfamiliar, get expert help from vendors and from vendor-independent industry experts with experience in PAC system design and integration.
• Create strong, rigid design standards; develop broadly useable documentation for new PAC design features like network configuration, data flows, and GOOSE messaging connections of functional points.
• Set up rigid documentation and configuration management systems. With IEC 61850, much of the PAC design is no longer evident in the physical installation – this managed design information is the only tool to maintain the system.
• Create a development laboratory to validate the performance of the design. Keep the laboratory throughout the installation life to train personnel, to troubleshoot bugs that arise in the field, and to test new product or firmware insertions in the existing design before authorizing those for field use.
• Develop and run training programs for field maintenance personnel, including hands-on participation and feedback during the design and laboratory test phases.
• Develop and run training programs for other enterprise stakeholders, including system planning, capital planning, purchasing, and operations teams.
• After the pilot or trial phase, plan a crisp organizational transition to the new design at the fastest sustainable rate."

Click HERE to access the paper for free.

There have been a lot of misleading and strange statements on the benefits of IEC 61850 communicated ... trust the real experts like Eric Udren ...

One of the real show-stoppers of a beneficial application is the lack of education of many engineers. We offer the right experience and knowledge for your people to harvest the benefits of the application of IEC 61850 and other standards:

Click HERE for the latest announcements of courses in German.
Click HERE for the latest announcements of courses in English.

I look forward meeting you in one of the public courses or in an inhouse seminar. Peopleware is one of the most crucial issues in future energy systems.

Seminar on Protection and Control in Stockholm (18-22 Sep / 10-13 Oct 2017)

FMTP, KTH, OPAL RT, and NettedAutomation offer a very comprehensive training courses on IEC 61850 and related standards

Stockholm-Arlanda (Airport)
18-22 September 2017
Click HERE for details
Karlsruhe (Germany)
10-13 October 2017
Click HERE for details

Wind Energy Generation Systems - About to Use and Extend SCL

IEC TC 88 (Wind energy generation systems) has just published a new work item proposal for the series IEC 61400-25 (Communications for monitoring and control of wind power plants):

(88/621/NP):
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 voting closes 2017-04-21.

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

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

IEC TC 57 Published FDIS IEC 62351-11 Security for XML Documents

Have you ever seen a multi MegaByte XML file used for system or device configurations, COMTRADE, COMFEDE, or other purposes? I have big SCL files that represent real substation specifications. What happens if one (1) single character is removed or changed by somebody ...? A change of a single character can have very severe consequences!
In order to secure XML Files in the context of IEC and other standards organizations, IEC TC 57 just published the document:
57/1753/FDIS: Power systems management and associated information exchange – Data and communications security – IEC 62351-11: Security for XML Documents

Voting closes 2016-09-02

IEC 62351-11 specifies schema, procedures, and algorithms for securing XML documents that are used within the scope of the IEC as well as documents in other domains (e.g. IEEE, proprietary, etc.). This part is intended to be referenced by standards if secure exchanges are required, unless there is an agreement between parties in order to use other recognized secure exchange mechanisms. It utilizes well-known W3C standards for XML document security and provides profiling of these standards and additional extensions.

Experience with the OMICRON IEDScout Version 4.10 - The Name Space Concept

As you may know we have defined a very powerful namespace concept into IEC 61850. It allows to use logical nodes and data objects from multiple application domains in one single SCL File.
This concept has been incorporated into the standard (IEC 61850-6, -7-1, -7-2, -7-3, 7-4, and 8-1) some 15 years ago. At that time I was the editor of parts -7-1 and -7-2.
By the way: These five (5) parts are often called "The Core Parts of IEC 61850".

The name space “IEC 61850-7-4:2003” indicates that ALL instances within this logical device
are derived from the 2003 editions of IEC 61850-7-4, IEC 61850-7-3, and IEC 61850-7-2. The logical device name space could be understood as the prime name space. The attribute ldNs is an attribute contained in the name plate of the logical node zero (LLN0).
A device that implements more than one Logical Device can support multiple prime name spaces - one per Logical Device.

The name space for Edition 2 of the core documents is as follows:

        IEC 61850-7-4:2007A

The Omicron IEDScout V4.1 analyzes this Logical Device name space and acts according to the name space configured. Let's see how that works.

If the LD name space is missing then the default value will be used: this means Edition 1 of the core documents).
The following figure shows an SCL file that does not contain a value for the "ldNs". Now we open the SCL file with the IEDScout 4.1.The IEDScout figures out that the prime name space is Edition 1 of the core parts. In Edition 1 of IEC 61850-7-3 (Common Data Classes) there are no CDCs like ENS and ENC defined. This is indicated in the warning area. Edition 1 of IEC 61850-7-3 defines INS and INC instead.



The new enumerated Common Data Classes (ENS, ENC and ENG) have been added in Edition 2 of IEC 61850-7-3. The SCL File with the Edition 2 prime name space is shown next:


The IEDScout does not show any warning!

Smart!

What does that mean for all of us? We have to make sure that our IEC 61850 models configured in an SCL File are according to the prime name space we want to use!

And: The IEDScout has many other powerful (browsing, testing, ...) features build-in that help you to get your IEC 61850 based system running according to the standard series IEC 61850, IEC 61400-25, ...

I am using the IEDScout 4.1 in my training courses. Attendees learn how to model IEDs and how to test them.

Click HERE for downloading a 30 days fully functional evaluation license.

CDV of IEC 61850-6 Amendment 1 and IEC 62351-9 available for comments

IEC TC 57 has published the following documents for review:

57/1697/CDV
IEC 61850-6 A1: Amendment 1 to IEC 61850-6 Ed.2:Communication networks and systems for power utility automation -
Part 6: Configuration description language for communication in electrical substations related to IEDs

The Amendment incorporates 60 Tissues - listed in the CDV document. You can find easily what has been revised.

57/1699/CDV
IEC 62351-9: Power systems management and associated information exchange - Data and communications security -
Part 9: Cyber security key management for power system equipment

Please take some time to review both documents.
The documents should be available online for reading and for comments.
Check HERE for the access and for providing comments.