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!

Machine Processable SCL/XML Schema Available for Download

Please note that the SCL Schema Edition 1 and 2 are available for download from the IEC Website.

Click HERE for more details.

There will be more machine processable documents of the series IEC 61850 available in the near future.

I highly recommend to stay tuned to this IEC 61850 Blog ... just Subscribe to it (details can be found on the top right of the site).

First Document of Series IEC 61850 Published as Edition 2.1 FDIS

IEC TC 57 has just published the FDIS of IEC 61850-6/AMD1 ED2:

Amendment 1 – Communication networks and systems for power utility automation –
Part 6: Configuration description language for communication in power utility automation systems related to IEDs

The voting ends: 2017-10-27

Amendment 1 means finally Part 6 Edition 2.1:

The present FDIS reflects amendment 1 to IEC 61850-6 Ed. 2. TC 57 WG 10 has also developed a so-called consolidated edition 2.1 based on the present amendment and the existing Edition 2. The consolidated edition is circulated in parallel under reference 57/1919/INF, so that national committees can see the implementation of the amendment in the existing edition.
Once the present FDIS is approved, the consolidated edition will be published together with the amendment under reference IEC 61850-6 Ed. 2.1.

Machine processable Schema available!!

Note that the Schemata for Edition 1 and 2 of part 6 could be downloaded from the IEC Website:



The availability of the machine readable schemata is a very great progress in getting IEC 61850 applied in more and new application domains. More to come.

Congratulation!

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.

XML Documents and Pretty Print with Notepad++

Dear All,

I guess you have seen this kind of XML documents quite often in conjunction with SCL Documents:

One way is to use the online tool "Pretty Print".

There is a more convenient way: Use the "Pretty Print" Plugin tool that comes with Notepad++ (you have to install it with the Plugin Manager):

This will result in a Pretty Clean XML Document:

Wow!

Enjoy the plugin!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SCL Schema Accessibility in the near future

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

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

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

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

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

IEC 62351-11: Draft on Securing XML files

XML (a notation for structured documents) is used in many standards published by IEC TC 57 (Power systems management and associated information exchange). IEC 61850-6 (SCL) is one of these parts that rely on XML and XML schema.

A small change in an SCL file may have a crucial impact of the content of the whole file.  There is a need to secure such files.

IEC TC 57 just published the first CDV:

IEC 62351-11 Ed.1 (57/1562/CDV)

Power systems management and associated information exchange - Data and communications security -
Part 11: Security for XML files

The 62351-11 extensions provide the capability to provide:

• Header information: the header contains information relevant to the creation of the secured document such as the Date and Time of the when the IEC 62351-11 document was created.
• A choice of encapsulating the original XML document in an encrypted (Encrypted) or non-encrypted (nonEncrypted) format. If encryption is chosen, there is a mechanism provided to express the information required to actually perform encryption in an interoperable manner (EncryptionInfo).
• AccessControl: a mechanism to express access control information regarding information contained in the original XML document.
• Body: is used to contain the original XML document that is being encapsulated.
• Signature: a signature that can be used for the purposes of authentication and tamper detection.

What do you think about security? It is important! How many time and money have you and your colleagues or your management spent for making systems more secure? One Euro or 1000 Euro?

When it comes to costs – then people are behaving different.

Be more serious about security.

1400 Tissues (Technical Issues) listed since 2004

The Tissue process is one of the crucial means to improve the quality of the various parts of the IEC 61850 standard series and helps to improve the interoperability of IEDs. Since 2004 the IEC 61850 experts have posted more than 1400 Tissues – number 1400 was posted today (2015-06-04).

The Tissue 1400 is very interesting: It is based on input from utilities (User Feedback Task Force).

This tissue proposes to remove several options in the area of how the subscription is specified in an SCL file – and to allow only ONE possibility. 

This is a good news!

I personally expect that this approach (to get rid of options) will be applied more often in the future.

Note: Many tissues are just questions that are tagged as “blue” tissues.

How to Generate IEC 61850 IED Models?

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

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

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

IEDmodeler from RedWind:

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

Click HERE for more information.

ICD Designer from SystemCorp:

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

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

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

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

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

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

Using ConfRev to report a change of value

The configuration revision is a very useful information for clients (Reporting) and subscribers (GOOSE and SV). It is highly recommended that a receiving IED marks the received values as invalid in case the receiver expects ConfRev=X but receives a message with a value unequal X.

The service Reporting (or GOOSE) could be used to inform receivers that there is a change in the ConfRev – long before it may receive a message with a different (incremented) value.

By the way, the functionality to “monitor” changes of control block attribute values is called “Service Tracking” and is defined in IEC 61850-7-2 Edition 2.

The Control Block Attribute ConfRev needs to become a member in a data set. This data set may have all ConfRev attributes of all control blocks as members. So, if any change is detected, a message is issued (Report or GOOSE message, or log entry posted).

It is not yet specified in IEC 61850 if the change of a value (of the ConfRev) implemented by a re-configuration of the IED (e.g., change of the data set) can be used as a trigger (dchg) to issue a report or GOOSE message or post a log entry. Because this new value may become online visible after the IED restart (to interpret the new SCL file).

It would require that the Control Block stores the last ConfRev value non-volatile; in order to figure out that the new value (from configuration tool) is larger than the old one. This is true for SV Control Blocks only, see §19.2.1.6: “A restart of the IED shall not reset the value.”

See IEC 61850 Tissue # 861.

Mismatch of ConfRev values in IED and SCL file

The issue of how can the values of ConfRev (configuration revision) in an IED be consistent with the configuration file during the lifetime of IED has been discussed may times. The final standardized solution is now discussed in the IEC TC 57 WG 10 task force “System Management”.

Here are some hints on the issue that help to understand what to do until we get a standardized solution.

Part IEC 61850-7-2 Edition 2 defines for GOOSE Control Blocks:

18.2.1.6 ConfRev – configuration revision
The attribute ConfRev shall represent a count of the number of times that the configuration of the DATA-SET referenced by DatSet has been changed. Changes that shall be counted are:
– any deletion of a member of the data-set;
– Any adding of a member to the data-set;
– the reordering of members of the data-set; and
– changing the value of the attribute DatSet.
The counter shall be incremented when the configuration changes. At configuration time, the configuration tool will be responsible for incrementing/maintaining the ConfRev value. When configuration changes occur due to SetGoCBValues, the IED shall be responsible for incrementing the value of ConfRev.
If the value of DatSet is set through a SetGoCBValues service to the same value, the ConfRev value shall still be incremented.

Part IEC 61850-6 Edition 2 defines for GOOSE and SV Control Blocks:

confRev
“The configuration revision number of this control block; mandatory. It is recommended to increment it by 10000 on any configuration change, to distinguish this from online configuration changes [by services] leading to an increment of 1 only”

Work-around

In the meantime you have to implement a work-around on your own, e.g., when you implement online changes (caused by services), then the build-in IED Tool (“online tool” in the IED) has to increment the ConfRev value by 1. If you implement a change in the SCL file that is used to configure the IED then you are recommended to READ first the current ConfRev value of the IED and increment by 10,000 and “overwrite” the current value in the SCL file before you re-configure the IED.

It should be specified in the PIXIT file how your IED works (as publisher and/or subscriber).

Please note the tissue 840 (quite new) in which you can read:

“The question, how dynamic changes done online (through the IED front-panel or through communication services) relate to changes made through configuration files and if these changes shall be allowed for real use is a different topic. There is currently a task force active dealing with system management - they will need to address details on how precisely dynamic changes shall be handled compared to static (through configuration) changes.”

http://tissue.iec61850.com/tissue.mspx?issueid=840

In the following document you find also that the issue is well known:

http://www.fgh.rwth-aachen.de/verein/projekte/InterOP_TestReport.pdf

See §2.2.9

There is still some work to be done – you are invited to get involved in the ongoing work of the WG 10 (Project “System Management”) to provide your input on the issue “Configuration Version Control”.

A special group of the German Mirror committee of IEC TC 57 has published a requirement document for IEC 61850 Engineering Systems:

“Anforderungen an IEC 61850 Engineeringwerkzeuge” [Deutsch]

Video on the Use of IEC 61850-6 SCL to configure a server and a client

This presentation explains the use of two IED specific SCL files to configure IEDs. One is used to configure a server and the second (with the same model - but different bindings between the model and the real data) is used to configure a client. The API "Write call " at the client and the "Write callback" at the server are briefly explained. The API is provided by SystemCorp (Bentley, Western Australia). The API is available at the Beck IPC Chip and other embedded controllers, or for Windows (DLL) and Linux.

Click HERE for an evaluation kit running on a PC (with DLL and applications). The evaluation package runs for six months. It uses two SCL files for configuring the server and the client (as shown in the video).

I hope you will enjoy this video!
Your feedback to Karlheinz Schwarz would be appreciated.

Improvements of IEC 61850-6 (System Configuration Language) and other parts

The IEC 61850 System Configuration Language (SCL) as defined in IEC 61850-6 Edition 2 is a very crucial, successful and comprehensive part of the standard series IEC 61850. This part has a major impact of System Design, System Engineering and Device Configuration Tools.

The standard defines many concepts and a lot of details! People in the SCL Team and other groups have worked hard to provide a consistent and complete specification. As usual, there are typos, incompletely defined details, … The IEC 61850 community takes these inconsistencies and errors very serious.

Since the publication in 2009 there have 21 tissues (technical issues) been reported on part 6:

Click HERE for the list of the IEC 61850-6 Edition 2 tissues.

One typical tissue (Tissue 719) is about the “maxAttributes” definition in clause 9.3.1:

The definition of ConfDataSet - maxAttributes is confusing especially the part in brackets (an FCDA can contain several attributes).
2 interpretations seem possible :
- maxAttributes = max nb of members in the dataset
- maxAttributes = max sum of attributes of all dataset member

The tissue has helped to clarify what is meant: “ConfDataSet.maxAttributes shall define the maximum number of members in a data set …”

Click HERE for the complete tissue 719.

Please check the tissue database if you find anything in the published standards (of any Edition) that may be wrong or not complete or unclear. Before you post a tissue check if it has already been reported and solved.

Click HERE for the Tissue Database entry on IEC 61850 and HERE for IEC 61400-25.

You can help the IEC 61850 community to improve the standard by checking the content of the tissue data bases and posting your findings on possible deficiencies.

Thanks!

What are Client/Server and Publisher/Subscriber in IEC 61850?

The terms Client/Server (C/S) and Publisher/Subscriber (P/S) in IEC 61850 are describing (communication) roles a real device may have. A device can play any of the four roles - even at the same time.

From an information flow point of view (independent of C/S and P/S) there are different levels of relations: (#1) the Application Layer Protocol or communication view (see first slide); (#2) the system view as seen from an IEC 61850-6 (SCL - System Configuration Language) point of view (see second slide).

(#1) First slide: A server exposes the Data (in a LD/LN) that can be accessed by the client over a TCP/IP connection - may be over Ethernet. Or the client will receive event-driven reports from the server over TCP/IP (Ethernet). This is a 1:1 connection at protocol level. A server may communicate with many clients (one TCP/IP connection between each client and server). The connection is opened by the client. Note: a real device could play both roles - in MMS an association (connection) allows both devices to play both roles (this is not yet used in IEC 61850)!

The slide also shows the publisher and subscriber. The publisher sends multicast messages that are picked-up by subscribers. The subscriber is (at communication level) NOT subscribing to the subscriber. The message is just sent and any device that has a subscriber role picks-up the messages it wants to receive. Each multicast message has an identification (let's say number 277). The publisher does NOT know who is receiving the messages. This is like picking-up a newspaper at the red traffic light in the morning. You may also subscribe to the publishing house to get the newspaper delivered to your home every morning - this is the real publishing/subscribing).

A device that has a Server can model Data (in LD/LN), e.g. status of a cirsuit breaker. This Data can be used for publishing values (by a DataSet and a Control block). Strictly speaking: a Publisher does not expose a data model. This is done by a server. The publishing service makes use of a server (explicitly or implicitly). Explicitly means: data - dataset - control block - message. Implicitly means: message - you don't see the model; it may be defined in SCL only.

(#2) From a SCL (system) point of view we can model the flow of information from a source (right), through a server/publisher, message, client/server, ... to a sink (see next slide). In SCL we are describing the information exchange between a Data in logical nodes - clients/servers are not in the main focus. SCL provides - in my words - the wiring plan of a whole system (from a source to a sink).

The services defined in IEC 61850 ACSI are listed in the third slide:

The last slide shows that clients and servers can be cascaded ... this is outside the protocols - but can be specified with SCL! SCL is a VERY powerful specification language!!

Examples of these cascaded relations are presented and discussed during the hands-on training courses of NettedAutomation ... and much more.

Summary: each device implementing all four roles defined in IEC 61850 can communicate with each other device as a client, server, publisher, and subscriber.

Some applications of SCL (IEC 61850-6)

The System Configuration Language serves many applications in substations and in distributed automation in general. Often people are a little bit confused ... they read here and there - but do not get the full story.

The following list is intended to help people to find a way to get a better understanding:

1. To understand SCL (System Configuration Language) I recommend to read/study IEC 61850-6 Edition 2.

2. There are many applications of SCL files (some may not be found in any standard):

• System design → single line diagram (re-useable designs in library)
• IED development → IED capabilities
• System engineering → System configuration (re-useable config.)
• IED configuration/parameterization → running IEDs
• Documentation → provides view of system
• Plausibility/verification → check if system is able to run
• Self description of IEDs → Retrieve IED section from IED
• Validation of Device content → Check model against standard
• Simulate I/Os of IEDs for testing → Fieldbus driven remote I/O
• Simulate IEDs → Generate virtual IEDs on computer from SCL file
• Message interpretation → Use SCL file to get semantic of the model
• …

One or the other tool is needed for all of these applications. Some tools are available, other tools are under development ... the good thing is: the files are all written in ASCII-Code !! so that your 16 year old son or daughter can write simple but powerful tools by just searching and comparing TEXT !!

Example: It is easy to check if for every control block in an Input section (Sink) there is an IED with exactly that control block (Source) ... and so on.

3. SCL is not complex - it is very comprehensive. I have conducted many seminars and training sessions on IEC 61850 ... SCL is very crucial to understand ... SCL is 51 per cent of the standard in the long run ... in my opinion.

4. The blue sky is the limit of the use of SCL.

5. Today's implementations of IEDs and Tools is quite limited ... but wait ...

6. A two-page overview of IEC 61850 can be found here:
http://nettedautomation.com/standardization/IEC_TC57/WG10-12/iec61850/What-is-IEC61850.pdf

I wish you and your family a healthy and happy new year.