What is IEC?

IEC is an acronym for International Electrotechnical Commission, a global organization responsible for creating the development standards of the IEC 61850 and other products.

IEC 61850-type devices are considered a third-generation communication technology that has been adopted as an official international standard in the industry. Its communication protocol consists of a client and server relationship over ethernet, very similar to a lot of today’s modern devices.

An IEC 61850-type device can also be referred to as an Intelligent Electronic Device (IED) which is, according to IEC definitions, any device incorporating one or more processors, with the capability to receive or send data to/from an external source. It is capable of executing the behavior of one or more specified logical nodes in a particular content and delimited by its interfaces (IEC 61850-2, ed. 1.0 (2003-08).

Communication Types

If SCADA software were to communicate with a device like this, it would most likely be placed in a Station Bus, a network dedicated for requests and responses between station computers or gateways and “bay-level” IEDs. The term bay-level can be summarized as the intermediary of logic devices between station bus devices and process bus devices (e.g. the plant floor process level) that need monitoring.

There are 3 different IEC communication types that can be used:

Manufacturing Message Specification (MMS) Client - An Application Layer, client / server communication. This is primarily used at the station level.
Sampled Values (SV) - A peer-to-peer communication method. Primarily used to bridge the bay level and process level.
GOOSE - A peer-to-peer communication method. Similar to SV but also makes communication between two IEDs possible.

Some systems only use MMS, some only GOOSE, some SV, and some are a mixture of two or three. MMS & GOOSE are more commonly used since SV is a bit newer. Each of these communication types can be used at the station level if the station device supports it, however some communication types are considered more reliable than others when SCADA is required. As of 8.1.25, Ignition will only support the MMS Client communication type with its embedded OPC UA server and driver. This is because this communication type provides the most control over the flow of data from source to destination and, most importantly, confirmation that the data has been sent or received. Goose and SV do not provide such control despite being able to send data with significantly lower latency. GOOSE and SV also do not incorporate the TCP/IP headers (OSI Layer 3) that a SCADA system would typically need to remotely receive provided information.

MMS Communications

MMS Client communication involves event-based messaging between a client (e.g. Ignition) and server (e.g. an IED in the field). In the IED server, specific points are monitored for changes and will trigger a message to clients when those points change in any way. When something like this occurs, a dataset representing this change will be constructed on the device and be sent via MMS to what is known as a report. Once a client has access to an IED’s report, this is where read capabilities are made possible for an HMI.

There are four types of events/triggers that will cause a report to be constructed for the client. They are also known as Trigger Operations (TrgOpt):

Data Change (dchg) - any change made to a dataset’s attributes.
Quality Change (qchg) - every dataset has a single quality attribute. A change in this alone can cause a new report to be constructed for that dataset.
Data Update (dupd) - some dataset attributes can have their values set to a frozen state (meaning a user does not want this value to change despite new values that could come from the device for this attribute). If this configuration is set during the connection, this will also generate a new report.
General Interrogation (GI) & Integrity Periods (IP) - clients have the ability to perform a GI request against a dataset that contains attributes with their own individual GI trigger options set to True. A given dataset may also contain IP that act as expiration time intervals. Once an IP expires, all contents of the dataset may be constructed into a new report regardless of GI options.

IEC Hierarchical Data Model & Reports

Bay-level IEDs act as servers capable of talking to multiple nested logic devices at once where each may contain their own complex data structures for reading and/or controlling a given process in the plant floor. In order to organize the statuses of potentially hundreds of devices, an IEC standard hierarchical data model is followed.

At the smallest level of the shown model above, we have attributes which represent individual values of a data object. A data object can be instantiated from one of many IEC Common Data Class (CDC) structures depending on the type of process. Not only do data objects have strict CDC structures, nested logical devices also need to adhere to specific CDCs based on their purpose. Logical devices are expected to follow this model in order to create the datasets needed by MMS when generating reports.

When a report is being constructed for a particular dataset in an IED, there are two types of reports that can be constructed by MMS:

Buffered - A report type that allows pending dataset changes to be buffered in the device in the event of communication loss. This report type also depends on a Buffer Time function (bufTm) to either accumulate multiple events under a single report or separate events when necessary.
- The bufTm will contain a configured time limit that is immediately started after an initial event has occurred. If other events occur before the bufTm’s expiration, they will make their way into the same report containing the initial event.
Unbuffered - Compared to buffered reports, communication loss will result in the loss of pending changes that need to be reported to the client since none of the sequence of events mentioned above will occur.

More About the Buffer Time function

If multiple events occur before the bufTm expiration and two of the changes came from the same dataset’s attribute, we can instead expect those two changes to be written to individual first and second reports. The second event detected for that same dataset’s attribute will be considered an initial event for the second report. Events of other attributes recorded after the second initial event will be placed in the second report.

The Ignition IEC 61850 driver

Ignition’s IEC 61850 driver will attempt to connect to an IED using MMS Client communication and, by default, attempt to request information about reports and logical devices. The OPC UA model will convert each data object’s individual attributes into browsable OPC items, separated into item folders that are labeled by the original report’s configured naming convention. Our user manual demonstrates how you can locate these item-converted reports either from the designer’s tag browser or the OPC quick client.

If you’re already familiar with the OPC UA model’s process of structuring qualified values for other supported device connections, then the fact that you can already browse and subscribe to items as tags may make things appear as if you have everything set up properly. However, IEC models involve a few key differences that need to be considered when integrated with OPC UA subscription.

OPC Browsing and Data Objects

Earlier, the IEC Hierarchical model was shown to explain how logical devices within IEDs create datasets, construct them as reports, and send them to MMS Clients. When these reports are sent to Ignition’s MMS Client, they are then processed by OPC UA. All data objects are translated to work similar to OPC items. During an OPC Browse you will find a folder called Reports containing individually named subfolders to represent each of these reports. When a report folder’s Points folder is opened, you will then find attributes of data objects that can be read or subscribed to just like a item for any other device with OPC browsing capabilities. The user manual section Use Quick Client to Confirm Connection Statuses provides a visual for such an OPC Browse using the OPC Quick client If you look very closely at the names of each item you will notice adjacent item matching by name except for trailing keywords such as:

instCVal.mag.f - an example of a data object’s value attribute
cVal.mag.f - an example of a data object’s value attribute
q - a data object’s quality attribute
t - a data object’s timestamp attribute

Each of these keyword examples above represent an attribute of a specific data object. In order to figure out which data object it belongs to, pay attention to the leading naming conventions that come before the attribute name. The user manual also provides an example of what a full attribute path looks like under the IEC 61850 Hierarchical Data Model sub-section. The attributes q and t are important to note because they represent the quality and timestamp of a given data object’s current value(s). This means that if a data object inside of a report contains multiple value items such as instCVal.mag.f and cVal.mag.f, then its corresponding q and t items will represent quality and timestamp for ALL value attributes sourced from a given data object. It’s recommended to rely on these attributes over any quality and timestamp properties that are generated from an OPC read or OPC subscription for individual value attributes. While the OPC UA server does compare its timestamp/quality with the source timestamp/quality in the device during a scan, the timestamp and quality received from the source should be preferred for accuracy.

The amount of value attributes paired with a quality and timestamp can vary depending on the IEC CDC structure that was built for the data object. There also exist other attribute types in a given data object that will be separated from the Points sections of an OPC Browse. It’s not important to know every CDC and attribute that is involved for every data object returned, but it is important to understand that Igniton’s OPC UA will always attempt to retrieve all value, quality, and timestamp related attributes for each data object found inside of a given report. Anything else will either be ignored or separated from the Reports section of an OPC Browse depending on whether the attribute data types can be supported.

Other Special Attributes

Supported attributes of data objects that are separated from a report’s Points section are usually parts of a data object that represent Operation Control (Oper). In IEC standards, their purpose is to provide write back capabilities of a given data object when necessary. Depending on the CDC of a data object, some will have Operation Control attributes and some will not (Status Only). In the IED’s Logical Devices, operation control attributes will be represented in a folder called Oper. When translated to OPC items, data objects’ Oper folder contents are separated into additional organized, nested folders labeled by IED/Logical Device/Node/Data Object. They can be located in the Model folder adjacent to a device connection’s Reports folder during an OPC Browse.

Operation Control attributes translated to OPC items are implemented to be Read-Only and cannot be used for writing back to the device directly. Such tasks have been given to the available IEC61850 system functions. This is because the OPC UA model in general doesn’t provide a way to adhere to IEC requirements that would make this possible. These Read-Only items can be subscribed to as normal tags and will adhere to tag group polling unlike the report attributes. Keep in mind that since the Ignition module allows polling for these items, it can add a lot of network traffic and can potentially overwhelm a device if a user isn't careful.

During an OPC Browse, you may also notice several items that exist adjacent to the Points folder of a given report. The important ones to pay attention to are:

Buffer Time (bufTm) - This was mentioned earlier as a configured time limit that is immediately started after an initial event has occurred for buffered reports.
General Interrogation (GI) - This was mentioned earlier as one of the four ways to trigger a report instantiation.
- Can be modified from the client of the report in question has GI enabled. Such configuration will be found on the IED itself.
Integrity Period (IntgPd) - This was mentioned earlier as one of the four ways to trigger a report instantiation, through expiration time intervals. Once an IP expires, all contents of the dataset may be constructed into a new report regardless of GI options.
Report Enable (RptEna) - This will be the most important attribute to pay attention to when viewing any report from an IED. In IEC standards, client communication involves a lock that will dedicate one client IP with a specific report.
- In other words, if an OPC client subscribes to any data object attributes inside of a report, that report’s RptEna will be set to true and keep track of that client in the IED server. Any attempts to subscribe to data object attributes of the same report from a different OPC client will fail and cause bad quality for secondary clients.
- If direct IED monitoring software access is not available, pay attention to the value of this item to ensure that the report is available for subscription.
- In the event a report can't be enabled by another client and no subscriptions are currently in place for that report’s points, OPC writes should be allowed by the IED in order to force disable that report.

Most of these items are also Read-Only and can be subscribed to as normal tags and will adhere to tag group polling unlike report attributes. These can also add a lot of network traffic and can potentially overwhelm a device if a user isn't careful. The GI and RptEna attributes are the only exceptions to the rule.

System Configuration Description (SCD)

An SCD Upload provides a way for adhering to another important standard when it involves configuring IEC client communication with IEDs. System Configuration Description (SCD) files are XML files that are generated by IEC software containing important communication and system parameters for making client/server connection possible. Once uploaded to the device connection in Ignition, we have the ability to select one specific IED out of many.

Without an SCD Upload applied to our device connection, we are potentially scanning for reports from an entire network of IEDs instead of one which can cause unnecessary traffic across IED servers and logical nodes. There will also be times where the associations between quality and timestamps and the logical device attributes cannot be linked without Ignition leveraging an SCD file. The user manual states that an SCD Upload is the optimal method for communicating with IEDs for these reasons.

IEC61850 System Functions

Operation Control attributes translated to OPC items are implemented to be Read-Only. If a write task is required, that ability has instead been given to the available IEC61850 system functions. This is because writing back to the device requires specific commands to be stated in a client request. The three commands are:

Select - For selecting specific Oper folder attributes of Sbo-type
Operate - For writing values to Oper folder attributes
Cancel - For unselecting Oper folder attributes of Sbo-type

Not only do we need to build our requests using these commands, but a data object you interact with can vary in type and differ in its combination of commands when compared to another data object. During an OPC UA’s scan of reports, it is able to make a distinction of these types by referring to a data object’s ctlModel attribute. This attribute defines a data object being one out of five unique types:

Status-Only
Direct-with-normal-security
Sbo-with-normal-security
Direct-with-enhanced-security
Sbo-with-enhanced-security

The first three are fairly straightforward. Depending on the ctlModel type, a data object may or may not have Oper attributes to begin with which typically results in a Status-Only type. Sbo-with-normal-security contains the acronym “sbo” (select before operate) where a select command needs to be applied on a data object before an operate command is made. Direct-with-normal-security simply means a data object does not require a select before operation.

The last two in the list above are similar to their “normal-security” counterparts except that some additional overhead occurs in the IED itself during a write. This does not require any authentication parameters to be specified on the client side, only the IED will be tasked with applying such a write with “enhanced-security”.

The ctlModel attribute is not shown for the user during an OPC Browse but it can be found using system.iec61850.getControlParams(). See the user manual’s system functions pages for more details on select(), operate(), and cancel() functions.

Troubleshooting Guidelines / Additional Notes

Important Considerations

Data object attributes defined within the {ReportName}/Points folders of an OPC Browse are the only ones that will follow event-based behavior of MMS communication when subscribed using OPC tags. All other special attributes subscribed to through an OPC browse will adhere to typical polling behavior with its tag group.
Avoid dragging the entire Report folder, the parent folder of all reports, into your tag browser to avoid unwanted polling. Doing this may subscribe Ignition to reports that aren’t meant for said client and while also placing heavy strain on the device.
According to IEC61850 standards. a subscription to a report should always be 1-to-1. Only one client IP can be subscribed to a report. If ignored, this will cause bad quality attributes for clients that cannot enable the report.
Ignition attempts to reconnect to a report’s RptEna attribute every 15 seconds if it fails to receive good quality.
There will be times where the associations between quality and timestamps and the logical device attribute cannot be linked without Ignition leveraging an SCD file.
The IEC61850 system functions are the only capable feature in the module that provides writeback to the device.

IEC61850 Loggers

com.inductiveautomation.ignition.drivers.iec61850.ReportManager
- The recommended logger for debugging purposes
- TRACE log provides all updates to any subscribed report attributes
com.inductiveautomation.ignition.drivers.iec61850.ReportAddressSpace
- Will provide additional information about values that are coming in with reports.
com.inductiveautomation.ignition.drivers.iec61850.iec61850Device
- May spam errors due to device overload
com.inductiveautomation.ignition.drivers.iec61850.iec61850ScriptingFunctions
- Provides the result of a call to one of the iec61650 scripting functions we provide
- INFO log currently only returns “”success” if function execution is successful

References

Understanding IEC61850

Table of Contents