IEC 61850 Edition 2.1 of Core Documents Published

The other day IEC TC 57 has published five more parts as Edition 2.1 - it took several years to get there! But finally it was successful.

I would call these Edition 2.1 documents simply the real Edition 2 documents.

First of all, what does Edition 2.1 mean?

The original edition 2 documents needed some corrections and updates. All crucial corrections et cetera have been documented in the Tissue Database (https://iec61850.tissue-db.com/default.mspx). The solutions provided on the Tissue Database have been used as input to the standardization process and led to amendments number 1 of the corresponding parts. These amendments have been commented and balloted officially by the members of TC 57. These amendments 1 are now the official documents that are amending the edition 2 documents (both are valid for the next years).

In order to make the "edition 2.1" more readable and understandable, there are other documents available: The consolidated parts 2.1 ... comprising the "old" stuff, the fixes and the extensions.




Consolidated Version of part 7-2: https://webstore.iec.ch/publication/66525 :



So: This consolidated version consists of the second edition (2010) and its amendment 1 (2020). Therefore, no need to order the amendment in addition to this publication.

Note: The first Tissues for edition 2.1 have already be posted, e.g., for part 7-2 Edition 2.1:



The following Previews for edition 2.1 consolidated versions are available:

Preview IEC 61850-6 Edition 2.1
Preview IEC 61850-7-2 Edition 2.1
Preview IEC 61850-7-3 Edition 2.1
Preview IEC 61850-7-4 Edition 2.1
Preview IEC 61850-8-1 Edition 2.1
Preview IEC 61850-9-2 Edition 2.1

Note: The name spaces (code components) for the edition 2.1 parts will be available soon - I hope:
Click HERE for the list of available name spaces (code components).

FDIS Ballot for Amendment 1 for IEC 61850-7-2, 7-3 and 7-4 Edition 2 Approved

The ballot of the three amendments (Amendment 1 for IEC 61850-7-2, 7-3 and 7-4 Edition 2) passed the FDIS process. All three amendments have been approved by 100 %.

The next step will be the IS publication of the three amendments.

It is likely that there will be a consolidated version of each of the three parts - means: the amendment is merged into the edition 2 versions and become edition 2.1.

IEC TC 57 Published Several New IEC 61850 Documents

IEC TC 57 has published several new documents of the standard series IEC 61850 (Communication networks and systems for power utility automation):

57/1832/CD
IEC 61850-2: Glossary [57 pages]
Comments are required by 2017-04-07

57/1829/CD
IEC 61850-80-5: Guideline for mapping information between IEC 61850 and IEC 61158-6 (Modbus) [45 pages]
Comments are required by 2017-04-07

57/1828/RVC
IEC 61850-7-2 A1 Ed.2: Abstract communication service interface (ACSI)
The CDV has been accepted.

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

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

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

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

The commenting period closes 2016-04-15.

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

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

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

Click HERE to register for public access and comments.

This allows everybody to ready the content and comment online.

Click HERE to visit the Tissue Database.

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

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

Congratulation to the editors for this great work!!

What is “Control with Enhanced Security”?

The IEC 61850-7-2 Control Model defines several operation modes:

• Status Only
• Direct control
  - normal security: Operate, TimeActivatedOperate, Cancel
  - enhanced security: Operate, TimeActivatedOperate, Cancel, CommandTermination
• SBO control (Select Before Operate)
  - normal security: Select, Operate, TimeActivatedOperate, Cancel
  - enhanced security: SelectWithValue, Operate, TimeActivatedOperate, Cancel, 
     CommandTermination

Have you ever tried to understand, implement, or use the option “Control with enhanced security”? The term can be quite misleading for people to believe that it has something to do with Cyber Security! No, it is not linked to that kind of security – even every operate command shall be secured by communication security measures.

So, what is it then? Usually I have explained it with the following slide.

Here is a one of many understandable use-cases for a specific switchgear (based on an email exchange with a very good friend of mine – a real switchgear expert … that believes in IEC 61850):

The proper name should be “Control with Confirmed Feedback”, so that any interlocks in the switchgear (can be abstract as well), need to be in the De-active state for the switchgear to report “Command Termination”, which would mean: the Control Element is now ready for another Operate service request.

A circuit breaker (CB) spring (drive) mechanism may work that it is only charged when the CB is Opened or Tripped. Then the energy in the spring mechanism would be enough to perform a Close Operation as well as a Trip Operation.

As the Trip mechanism does not need spring re-charging, it is instantaneous. However, there is a big delay after the Trip operation which is needed for the spring to charge or reset the mechanism again.

Although the indication of Trip will be instantaneous and reported spontaneously, however the switchgear cannot accept a new command since the spring mechanism is being recharged. During this time, the unit will not transmit the ‘Command Termination’ message so that a new command cannot be initiated. Once the spring is successfully charged, a ‘Command Termination’ message is transferred.

The CB mechanism example given above is one of many… there are some linear actuators which can Over-shoot during the process of operating the switch, this is then re-adjusted (i.e., brought to the normal position) after the instantaneous status change. The extra time needed to re-align actuator position (or to bring the actuator in the dead zone), will be the time after which the ‘command termination’ message is sent out.

Lesson learned: Ask always the domain experts!

Any question on IEC 61850?

Semantic Models of IEC 61850 raise Interest in OPC UA Domain

One of the first true international standards in the domain of automation that defines rich semantic models is IEC 61850: LogicalNodes containing DataObjects containing DataAttribues … etc.

Example:

IEC 61850 models of all almost all application domains have been converted to UML (Enterprise Architect). The interest in the many crucial semantic models of IEC 61850 is growing all over!

From the UML representation of the IEC 61850 based class-models it is now possible to generate OPC UA Address Spaces!

UMLbaT—UML based Transformation

UMLbaT is an extension, a so-called Add-In, for Sparx Enterprise Architect. The Add-In is an advancement of existing CIMbaT (CIM based Transformation). With CIMbaT it is possible to generate OPC UA Address Spaces from CIM based class-models. Now, with UMLbaT, it's also possible to create OPC UA Address Spaces from IEC 61850 based class-models.

Visit the UMLbaT website (OFFIS Oldenburg) to get more details on the transformation.

Usually the various fieldbus consortia define fieldbus-specific “models” … not allowing interoperability at semantic level between different fieldbusses. IEC 61850 semantic models could now be accessed by MMS (as defined in IEC 61850-8-1) and OPC UA. The mapping of IEC 61850-7-2 ACSI to OPC is under discussion and may be published as IEC 61850-8-2.

In the mid 90s we had already a document IEC 61850-8-2 (SCSM: Mapping to Profibus FMS). See also discussion on further mappings in IEC 61400-25-4.

Let me know what you think about the transformation. Thanks.

When to use Operate Service and when SetDataValues?

The IEC 61850-7-2 abstract services Operate and SetDataValues are both mapped to MMS Write in IEC 61850-8-1. So, what makes a MMS Write service an Operate or a SetDataValues?

The two services and the mapping are sketched here:

The first mapping is showing the Operate service (as part of the control model):

The Operate service is used in conjunction with the control model (defining state machines, select-before-operate, time-activated control,…). Control service models require a special information model: controllable Common Data Classes, e.g., SPC – Controllable Single Point. The model comprises attributes defined by the CDC and the service parameter ctlVal: these are shown in the MMS Variable as a structure “Oper” with the components: ctlVal, origin, ctlNum, T, Test, Check. These have to written at MMS level. These are always required for Operate even if you need just ctlVal !!

The settable DataObjects require the MMS Write as shown in the following figure:

In IEC 61850-7-3 it is defined exactly which services are to be used for the various attributes in the Common Data Classes. Example for controllable DataObjects:

 
Note that the FC=CO is defined in 8-1 !

Note also that client user interfaces (like the IEDScout) may use different service names than 7-2 or MMS.

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.

Can IEC 61850-7-2 Edition 2 be used to build Agents?

There are more and more discussions on the question if IEC 61850 could be applied to build an Agent. Some understand this as IEC 61850 versus Agent.

What is an Agent? There are as many answers when you ask experts.

I found a very interesting definition of an (special) Agent on Wikipedia:

“Monitoring and surveillance agents (also known as predictive agents) are a type of intelligent agent software that observes and reports on computer equipment. Monitoring and surveillance agents are often used to monitor complex computer networks to predict when a crash or some other defect may occur. Another type of monitoring and surveillance agent works on computer networks keeping track of the configuration of each computer connected to the network. It tracks and updates the central configuration database when anything on any computer changes, such as the number or type of disk drives. An important task in managing networks lies in prioritizing traffic and shaping bandwidth.”

More generally Wikipedia provides a definition of an Agent:

“In computer science, a software agent is a piece of software that acts for a user or other program”.

IEC 61850 can be used for many applications: Protection and Control in Substations, SCADA, monitoring any simple and complex computer based applications in the (power system) Automation or assets like transformer, etc. This covers also network components like Ethernet Switches – there is work underway to model the network management MIB onto Logical Nodes and DataObjects and use the IEC 61850 services!. An IEC 61850 Server can act for a Client (and its User – a person or program). Crucial characteristics of Agents can be found in IEC 61850, too. You are not (yet) convinced!?

Let me point to the Edition 2 of IEC 61850-7-2 (ACSI) published in August 2010. What is new there? A lot great stuff for more secure systems!

Edition 1 had already the service model of Reporting and Logging observing (monitoring) application information like status or limit violations – allowing to send and log spontaneous events. There was also a possibility to monitor attributes of the various control blocks (Reporting, Logging, GOOSE, SMV); allowing to report or log the enable request of a control block. This last application has been extended in Edition 2 to keeping track of all ACSI services.

Edition 2 of IEC 61850-7-2 introduces the concept of the Service tracking in clause 14:

The reporting and logging functions of process and function related data objects as defined in Edition 1 of IEC 61850-7-x and IEC 61400-25-2 are extended in Edition 2 of IEC 61850-7-2 to keep track of changes, event, or actions in the process related information modeled as Logical Nodes and DataObjects. IEC 61850-7-2 Edition 2 provides the possibility to keep track of all services, even those with negative responses. The services are classified as follows:

• Control block related services
• Command related services
• Other services

IEC 61850-7-2 Edition 2 defines additional specific common data classes for each type of service to be reported or logged. For a given Server, a single data object instance (tracking data object) needs to be instantiated in the object model for each kind of service, that will mirror the value of the service parameters exchanged and its acceptance by the server. This allows that a service can be logged or reported to any client. This requires that the tracking data object is a member of the data-set referenced by a LCB, BRCB, or URCB.

The following additional Common Data Classes (CDC) are defined in IEC 61850-7-2 Edition 2:

• Common service tracking (CST)
• Buffered report Tracking Service (BTS)
• Unbuffered report Tracking Service (UTS)
• Log control block Tracking Service (LTS)
• GOOSE control block Tracking Service (GTS)
• MSVCB Tracking Service (MTS)
• USVCB Tracking Service (NTS)
• SGCB Tracking Service (STS)

The tracking of services could be used to record the “manipulation” of the process and the information exchange control block attributes, e.g., the settings of relays or other functions. The FERC CIP (Critical Infrastructure Protection) requires to keep logs (records) of many information changes. The reporting and logging of IEC 61850-7-2 and the extended common data classes could be used to implement such a “Recorder” or “Data Logger”.

IEC 61850 (IEC 61400-25) provides a reach suite of service-oriented, event-driven or agent-oriented application and information exchange models.

The answer of the question in the headline is simply: YES, IEC 61850 can.