Description

IEC 61850 is a standard for the design of electrical substation automation. It is part of the International Electrotechnical Commission's (IEC) Technical Committee 57 reference architecture for electric power systems. The abstract data models defined in IEC 61850 can be mapped to a number of protocols. Current supported mappings in the standard are to GOOSE (Generic Object Oriented Substation Event), SV (Sampled Values) and MMS (Manufacturing Message Specification). GOOSE and SV can run over substation LANs using high-speed Ethernet switches to obtain the necessary response times of less than 4 ms for protective relaying.

RT-LAB implements the exchange of GOOSE messages (based on chapter IEC 61850-8-1), exchange of SV messages (based on documents IEC 61850-9-2LE and IEC 61869-9) and MMS mapping services (including reporting, also based on chapter IEC 61850-8-1).

Migration details

This interface was introduced in RT-LAB 2022.1 as a redesigned IEC 61850 solution, with added support for the Manufacturing Message Specification (MMS) feature. It is meant to replace the previous implementation, which hereafter will be considered legacy. The legacy interface's documentation can be found here.
In order to facilitate the migration from the legacy solution to the new one, a converter tool was made. It permits porting the configuration of the interface along with its created connections. The converter can be reached by clicking on the legacy interface's Convert to new I/O interface button, as seen in the image below:

The documentation for the converter tool can be found here.

IEC 61850-8-1 GOOSE

GOOSE is a control model mechanism in which data (status, values) are grouped into data sets and transmitted within a time period of 4 milliseconds. GOOSE data is directly embedded into Ethernet data packets and is exchanged on a publisher-subscriber mechanism on multicast or broadcast MAC addresses.
The same GOOSE message is retransmitted with increasing retransmission time intervals until an event occurs among the data set's elements. At that point, a new message will begin to be broadcast at high speeds containing the most up to date data. Therefore, a message is considered retransmitted if its state number (stNum) is the same as the one of the previous message. Conversely, when the stNum changes, it means that a change has occurred among the GOOSE data set's elements. 
Please refer to the IEC 61850-8-1 chapter for further information about the support of GOOSE messages in the IEC 61850 standard.
The contents of GOOSE messages are described in SCL (Substation Configuration Language) files. For more information about the SCL file format, please refer to the IEC 61850-6 chapter of the IEC 61850 standard. 

IEC 61850-9-2LE Sampled Values

To facilitate easy synchronization and efficient combination in substations for some signals, the so-called logical merging unit (MU) was introduced. It combines the currents and voltages from three phases along with the neutral currents and voltages into one data set, to transmit them as Sampled Values messages to all subscribing IED (Intelligent Electronic Devices).
The UCA international users group has published the “Implementation guideline for digital interface to instrument transformers using IEC 61850-9-2“. This guideline is an agreement of the vendors participating in the UCA users group on the implementation specifics of digital interfaces to instrument transformers. IEC 61850-9-2 leaves both the grouping of signals into data sets and the sampling rate as free engineering parameters. To reduce acceptance problems, the user convention IEC 61850-9-2LE has recommended values for the most common applications i.e. using 80 samples per cycle for protection and 256 samples per cycle for power quality.

IEC 61869-9 Sampled Values

This standard extends the use of Sampled Values to customizable data sets and sampling rates. The content of an IEC 61869-9 SV message must be described in an SCL file, similarly to GOOSE messages.

IEC 61850-8-1 MMS

MMS is an international standard dealing with messaging systems for transferring real time process data and supervisory control information between networked devices or computer applications. In the IEC 61850 standard, it is the communication protocol chosen to implement a client-sever TCP/IP communication link.
There are two ways to exchange data between clients and servers: through reporting (initiated by servers) or polling (initiated by clients).
A report is an event based transmission of a data set's contents, according to specific trigger options. Its definition is found in an SCL file, similarly to GOOSE and SV IEC 61869-9. The file contains information about the data set the report uses, what its triggers are and which optional fields to include in the packet. When one of the trigger conditions is met, the server IED will send a report containing all data attributes of the concerned data set to all connected clients.
On the other hand, polling is done by the client by performing a direct read of a data attribute that is part of the server.

Supported Features

General aspects

• Simulation is supported on Windows and Linux.
• The user interface can display the entire data model as well as all data sets of all IED found in any given SCL file
• The user interface can display all GOOSE, SV or Report control blocks found in any given SCL file
• The values of all data points can be logged to a file or monitored with ScopeView, through an automatically started DataLogger instance.

SCL/SCD/ICD file manipulations

A copy of all SCL files inputted is saved in the project folder. As such, the full portability of projects is ensured.
A file entry can be changed, whether to re-upload the same file whose contents might have been modified, or to change the file entirely. In both these scenarios a change detection mechanism will help the user make an informed decision about whether or not the SCL file entry should be updated.

GOOSE publishing & subscribing

The simulator can transmit and receive GOOSE messages (command, control or status). Publishing and subscribing is configured by providing an SCL/SCD/ICD file and creating connection points for all attributes comprised within the selected GOOSE message's data set.

Sampled Values publishing & subscribing

9-2LE

The simulator can become a merging unit and/or a subscriber in an IEC 61850 architecture. The logical device referred to as Merging Unit (MU) performs a time coherent combination of the current and/or voltage data. The MU contains the Logical Nodes TVTR (voltage transformer) and TCTR (current transformer). It combines the currents and voltages from three phases along with the neutral currents and voltages into one data set, to transmit them as Sampled Values messages to all subscribing IED.
This version of Merging Unit follows the recommendations of the UCA International Users Group, published in the user convention IEC 61850-9-2LE. Mainly, the SV data set is composed of 4 CT/VT transmitted using 80 or 256 samples per cycle. The input data is computed and sent/received by a driver application that runs at a frequency determined by the configured sample rate and nominal frequency.

This I/O interface also supports data integrity manipulation of publisher values.

Simulator throughput

About the size of 9-2LE messages (by SEL)

One 9-2LE Sampled Values stream represents 4.8 Mbps of data throughput. Our simulators support 1 Gbps throughput per Ethernet adapter and provide a minimum of 2 adapters (additional Ethernet cards are optionally available). In a typical configuration, the first adapter is reserved for communication with the host and the second adapter can be used by the simulation. Thus the most basic simulator hardware configuration supports up to 213 9-2LE Sampled Values streams. Considering that the driver runs the asynchronous process at a time step of 208 us and that each message takes approximately 5 us to process, a maximum of 41 streams can be managed per physical core. The driver adapts automatically to the user's needs and reserves additional cores when more than 41 streams are configured. To achieve 213 streams, 6 physical cores are required. By using additional Ethernet cards, expansion chassis and larger CPU, there is no theoretical limit to the number of streams our simulators can manage. Please consider the potential limits imposed by the number of ports of the Ethernet switch(es) or other devices in the network.

Note that these guidelines do not consider mixing GOOSE messages, MMS server communication or other communication protocols on the same Ethernet interface.

IEC 61869-9

Contrary to Sampled Values 9-2LE, the SV data set is composed of a custom number of current and voltage values, usually associated to a quality value. In this standard, the transmission rate is not limited to 80 or 256 samples per cycle. Publishing and subscribing is configured by providing an SCL/SCD/ICD file and creating connection points for all attributes comprised within the selected SV message's data set.

Reports

The simulator can become an MMS server that sends reports to connected clients according to the triggers established for data attributes of interest. Reporting is configured by providing an SCL/SCD/ICD file and creating connection points for all attributes comprised within the selected report's data set.
The trigger options and the optional fields are initially populated with information from the SCL file but are fully configurable to adapt to the simulation's needs.

MMS server

Any IED added as a result of parsing an SCL/SCD/ICD file can be used as an MMS server. Here is a summary of the supported features:

• Apart from the reporting feature, clients can also access server data by direct request. As such, they can directly read (though polling) or write (FC permitting) data attributes present in the server.
• Clients can send control commands (provided the IED contains controllable objects); the scope of the feature is detailed below.
• On Linux systems, the server will bind to the network interface specified in the IED's configuration parameters.
• On Linux systems, the IP aliasing functionality can be used to permit multiple IED that use different IP addresses to use the same network interface.
• The MMS server's asynchronous computation can be migrated to a dedicated core.
• Data sent by the model can be accumulated to compute their RMS value before placing them in the server; this computation is done outside the real time loop.

Control services

The implementation of this feature was done following chapters IEC61850-7-2 (section 20), IEC61850-7-3 (section 7.5) and IEC61850-8-1 (section 20).

IEC61850-7-2 defines 5 models of control, specified as elements of an enumeration:

The table below offers an overview of the controls possible, depending on the common data class (CDC) of the object: 

Connected clients can send control commands to the objects in the server, provided that:

• the objects' common data class is appropriate (as mentioned in the table above)
• the control model is different from status only (0)
• the control command is appropriate for the control model chosen (e.g. Select cannot be sent when the control model is direct operate)

Configuration

The IEC 61850 communication protocol can be configured through the I/O configuration panel. Adding an instance is done in the Project Explorer (Project Explorer > YOUR_PROJECT > I/Os > Right-click + New I/O > IEC 61850).

General

Data Logger

This feature permits recording the values of all data points of this I/O interface during the simulation.
Enabling its use will add all available connectable points of the interface to the recorded signal group. As such, setting up the feature is done entirely in the view shown above.

The information below is taken from the DataLogger Documentation | RT-LAB v.11.3.5 and up.

SCL/SCD/ICD files

Adding a file in this list is in most cases the first step to take when building an IEC 61850 configuration in the context of an OPAL-RT simulation. The exception is when only using 9-2LE SV messages, as this type of communication is not defined in an SCL file.
Files are parsed to extract all IED information, including their data model, data sets, and all GOOSE, Sampled Values and Report control blocks.

Each file added is copied into a folder named scl/ found in the project. If the next time RT-LAB is opened the original SCL file is no longer found, the interface will fall back upon using the back-up saved in the scl folder.

When a file is removed, all IED added as a result of its parsing will be removed. This means that all data sets, data model and control blocks associated with those IED will also be removed.

The image below shows an example of a list of SCL/SCD/ICD files:

Updating an SCL file entry

A file entry can be changed, whether to re-upload the same file whose contents might have been modified, or to change the file entirely. In both these scenarios a change detection mechanism will help the user make an informed decision about whether or not to continue with the update of the SCL file.

SCL file change workflow

1. Click on a valid entry to browse and select an SCL file (the same or different). This will bring up the refresh menu, asking how to proceed with the configuration's editable parameters that originated from the initial SCL file. The parameters affected by this choice are the ones marked as keep or reset in the table below, in the Updating common elements section.

2. Select the type of refresh and click OK. A pop-up window will appear, listing all the changes and requesting user input on whether or not to apply them.

3. Click Yes to apply the changes. 

Detecting changes within IED

The unique identifier of an IED is its name. Therefore, if its name is no longer found in the new file, the IED in question will be removed; conversely, new IED can be added as a result of parsing the new file. The same principle applies to all layers of the data model: access points, logical devices, logical nodes, data objects and data attributes.
For data sets, their unique identifier is their full path within the IED. For FCDA, the identifier is considered to be the combination of their parameters: node path, data object, data attribute and functional constraint.

This is best illustrated in the two examples below:

Example 1: SCL file A contains information about IED1 and IED2; SCL file B contains information about IED2 and IED3. When file A is changed for file B, the following happens:

• IED1 along with its data model, data sets and control blocks will be removed: it was part of file A, but not part of file B
• IED2 will be kept: it was part of both files
• IED3 along with its data model, data sets and control blocks will be added: it was not part of file A, but it is part of file B

Example 2: Starting with the same two files as above, assume IED2's definition in file A contains a logical device LD10. In file B, IED2's definition sees this logical device change name from LD10 to LD20. When file A is changed for file B, the following happens in the structure of IED2:

• LD10 will be removed along with its logical nodes, and consequently its data objects and attributes
• LD20 will be added with its own structure of nodes, data objects and attributes

Note that the same principle applies if a file is refreshed i.e. its own content is re-applied after a modification.

Detecting changes within control blocks

A GOOSE, SV or Report control block is considered the same either if its ID is the same or if its path within the IED is the same. Let's look at a few examples:

Example 3: Keeping with the same setup as in the examples above, assume IED2 (which was found in both files A and B) has a GOOSE control block that changed its ID from GoID10 to GoID20. Its name and path within the IED have not changed. 
In this scenario, the GOOSE control block will be considered the same and its ID will be successfully changed to GoID20.

Example 4: Now assume that IED2 has another GOOSE control block, whose ID is the same in both files but whose name has changed from gcb_name30 to gcb_name40. As a result, its path within the IED is considered changed.
In this scenario, as in the one above, the GOOSE control block will be considered the same and its name will be successfully changed to gcb_name40.

Example 5: In file A, GOOSE message with ID GoID50 was defined within IED2; However, in file B, GoID50 is now part of IED3. As in the example above, the GOOSE ID is unchanged, but the path is different.
Again, the GOOSE control block will be considered the same and its path will be successfully updated to show that it is published by IED3.

Example 6: Finally, according to file A, IED2 is publishing a GOOSE message with ID GoID60; according to file B, there no longer is any IED publishing a GOOSE message with that ID. 
Moreover, according to file B, IED2 is now publishing a GOOSE message with ID GoID70, which was not previously defined in file A.
When file A is changed for file B, the following happens:

• GOOSE message with ID GoID60 (published by IED2) will be removed from the configuration: it was part of file A, but not part of file B
• GOOSE message with ID GoID70 (published by IED2) will be added to the configuration: it was not part of file A, but it is part of file B

Updating common elements

The parameters of the elements that were deemed common to both files according to the constraints explained above (such as IED2 in the examples) can be divided into 3 categories:

• keep: applies to parameters that did not originate from an SCL file, such as the MMS server configuration parameters. The values of these parameters will remain unaltered during SCL file changes
• reset: applies to read-only parameters that did originate from an SCL file, such as the dataset path of GOOSE items. Their value will be reset to the value found in the new SCL file
• keep or reset: applies to editable parameters that did originate from an SCL file, such as the MAC address of GOOSE items. Their value can be either kept or reset, depending on the user preference

The table below shows how each parameter is handled during an SCL file change. Each column represents a section of the I/O interface.

IED

In most cases, the IED in the list seen below will come from the SCL file(s) inputted in the SCL/SCD/ICD files section.

It is also possible to add IED manually. These IED can be used to build a configuration more closely representing a real system, however they do not have any impact on the real time simulation. 
More concretely, they can serve as subscribing IED for GOOSE or SV messages, or as publishing IED for SV 9-2LE messages.
MMS configuration elements are not applicable to such IED, due to their missing data model template along with any type of control blocks.

Removing an IED from the list will remove all its information (data model and data sets) along with its associated control blocks.

Changing the name of an IED is only possible for IED added manually.

The image below shows an example of a list of IED:

The generic parameters of an IED can be seen below:

MMS server configuration

Access points

Browse through this section to explore the IED's data model. The image below shows an example of a tree expanded until the data attributes (DA) level:

The levels of the tree offer a graphical representation of the IED's data model:

Items cannot be manually added or removed in any of the tree's levels. The intermediate levels of the tree descending to the data objects do not contain any configurable parameters.

For non-controllable data objects (see which objects can be controlled in the table above), there is nothing to configure.
However, for controllable data objects the parameters are as follows:

The image below shows the details of the phsA.cVal.mag.f data attribute. This attribute was chosen due to having all possible configurable options:

Data sets

The image below shows an example of the contents of a data set:

This view does not have any configurable parameters. It serves to determine how the IED's attributes are used by its control blocks (GOOSE, SV or Reports).
Each data set entry contains a list of functional constrained data attributes (FCDA). FCDA items cannot be added or removed manually.
An FCDA element has the following parameters:

GOOSE

GOOSE items are added as a result of parsing SCL files that contain their definition. 
To remove an item, either its publishing IED must be removed from the IED list, or the SCL file where the message is defined must be removed from the SCL/SCD/ICD files list.

The configuration of a GOOSE item can be seen below:

Sampled Values

The Sampled Values list can contain elements of both supported types: 9-2LE and IEC 61869-9. However, the elements are not added and removed in the same manner.

For SV 9-2LE:
Items of this type are added using the + button, which can be seen in the screenshot below.
Conversely, removing an item is done by selecting it and clicking on the - button.

For SV IEC 61869-9:
Items of this type are added as a result of parsing SCL files that contain their definition. 
To remove such an item, either its publishing IED must be removed from the IED list, or the SCL file where the message is defined must be removed from the SCL/SCD/ICD files list.
As such, it is not possible to manually add or remove SV IEC 61869-9 elements.

The image below shows an example of a list of SV messages (9-2LE and IEC 61869-9):

The configuration of SV items can be seen below, with 9-2LE on the left and IEC 61869-9 on the right:

Differences between the two types of SV messages are highlighted in the table below. If there are none, it can be assumed that the parameter is used in the same way for both types.

Reports

Reports are added as a result of parsing SCL files that contain their definition.
To remove a report, either its reporting IED must be removed from the IED list, or the SCL file where the report is defined must be removed from the SCL/SCD/ICD files list.

The configuration of a Report item can be seen below:

Connections

Once configured, the IEC 61850 I/O interface offers data points to be connected with the RT-LAB model. These appear in the I/O Explorer, accessible through the Project Explorer under the I/O item, or in the Configuration panel (Project Explorer > YOUR_PROJECT > Configuration).

Time synchronization

The connection points below are only available if the I/O interface's Time synchronization parameter is set to Use connection in model.

Ideally, the timestamp input should come from an accurate synchronization source. Otherwise, there is no guarantee on the data sampling, reported data rate and fraction of second information.

GOOSE

Publishers

Subscribers

Sampled Values

Publishers 9-2LE

Publishers IEC 61869-9

Subscribers 9-2LE

Subscribers IEC 61869-9

Quality word in Sampled Values messages

This information applies to both Sampled Values 9-2LE and IEC 61869-9 publishers and subscribers.

Reports

MMS data points

The direction of a data point in this section depends mainly on its functional constraint. For certain attributes a deciding factor is also whether or not they are part of a controllable object.

For most cases, the FC decides the access right that clients might have for a particular data attribute:

• Read Only: this is the access right that most data attributes have; this means that the client can only read the value in the server but cannot write into it.
  In this scenario, the data attribute will have a model → driver connection point. In other words, RT-LAB will be able to read and write the value, but the MMS client will only be able to read it.
• Write Only: this type of client access type is not applicable
• Read Write: this means the client can both read and write the value in the server.
  In this scenario, the data attribute will have 2 connection points: a model → driver connection and a driver → model connection. This is necessary to show the user any value that might have been written by the client.
  In other words, RT-LAB will be able to read and write the value, but so will the MMS client.

A very small subset of an IED's attributes might deviate from the rules above: initially categorized as Read Only, they will become Read Write. It is the case for the following data attributes, when they are part of a data object that has Enable as controllable object set to true:

• stVal
• valWTr.posVal
• mxVal.i
• mxVal.f
• ctlNum
• origin.orCat
• origin.orIdent
• opRcvd
• opOk
• tOpOk

While the client cannot directly write into these attributes, their value can change following a control command sent by the client. By changing them to be Read Write, the new value can be made available in the model.

In short, every attribute enabled in the IED tree that is not used in reports (this scenario is covered in the section above) will have a model → driver connection point. If its FC permits it or if it's one of the attributes mentioned above as part of a controllable object, it will also have a driver → model connection point.

Sampled Values Fault Injection

When the I/O interface's Enable Sampled Values data integrity manipulation box is checked, additional connection points are available to inject errors into published Sampled Values 9-2LE messages. This feature is license-protected.

Every Sampled Values 9-2LE published message will have a new connection group called Faults which will contain the new connections points. Here is a short description of the different faults and how to configure them.

Stop Transmission

Simulate the loss of packets on the network by stopping the SV publishing during a certain amount of frames. If monitored, the stream will appear as it loses n packets of data.

Delay Transmission

Simulate an unwanted delay on the network by delaying the frames for a configured amount of time in microseconds, for a certain amount of frames.

Duplicate Transmission

Simulate a wrong network topology where packets could be sent multiple times by duplicating frames a certain amount of times and for a certain amount of frames.

smpCnt Manipulation

Simulate a man-in-the-middle attack by manipulating the smpCnt of a stream.

smpSynch Manipulation

Simulate a man-in-the-middle attack by manipulating the smpSynch of a stream.

Quality Manipulation

Simulate a man-in-the-middle attack by manipulating the quality of the stream's voltage and current values.

Limitations

IEC 61850-8-1 GOOSE

• Supported GOOSE basic attributes are: BOOLEAN, INT8, INT16, INT32, INT64, INT8U, INT16U, INT32U, FLOAT32, FLOAT64, Enum, Dbpos, Tcmd, Check, Quality, Timestamp, and Struct.
• Timestamp data type is only processed at the GOOSE header level as UTC field; otherwise, it is treated as a simple integer.

IEC 61850-9-2LE Sampled Values

• Sampled Values subscribers can only filter messages by multicast address; therefore is it not possible to have two SV messages being published on the same address since SV subscribers will subscribe to both leading to erroneous information.

IEC 61850-8-1 MMS

• Supported basic attributes are: BOOLEAN, INT8, INT16, INT32, INT64, INT8U, INT16U, INT32U, FLOAT32, FLOAT64, Enum, Dbpos, Tcmd, Check, Quality, Timestamp and Struct.
• Timestamp data type is treated as a simple integer.
• The following data attribute FC are not supported: BR, RP, GO, MS, US, LG, SG, SE.