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:

Open

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

Open

Data Logger

Open

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.

Record data	If enabled, all data points of the I/O interface will be recorded during the simulation. They can be monitored with ScopeView while the simulation is running. The values are also recorded in a file, configurable below. This file is retrieved from the simulator automatically after the model resets. When this box is checked, the configurable parameters of the DataLogger are made available.
Recorder log level	Select the level of verbosity for displaying user messages concerning the DataLogger feature.
Mode	Manual: Starting and stopping the recording is done manually, through the API. Automatic: Logging starts automatically at the load of the model and stops at reset.
Export format	Choice for the format of the file containing the recorded values of the monitored signals: OPREC (native format) CSV (EXCEL Comma-Separated Values) MATLAB
Output file auto naming	If selected, the name of the output file will be automatically generated. Naming collisions are therefore avoided as name uniqueness is ensured by appending the timestamp to the filename. The automatic file name is a combination of the model name, the subsystem name, and the date and hour. Note that the seconds in the generated file name correspond to the time at which the DataLogger prepares the recorded/saved file. This may occur just before the recording starts, or at some time before when a trigger is configured. To provide a custom name for the file, the field must be unchecked. As a result, the Output file name and Append Timestamp fields are made available.
Output file name	Provide the custom name of the output file. Note that multiple simulation runs will overwrite the output file if it has not been renamed/moved between each simulation start. To avoid that, check the box in the field below, Append Timestamp. This field is only visible if the Output file auto naming field above is unchecked.
Append Timestamp	Activate this to append the timestamp to the end of the filename in the following format: <Year>-<Month>-<Day>-<Hour><Minutes><Seconds>. Appending a timestamp ensures that files will not be overwritten for each simulation run. This field is only visible if the Output file auto naming field above is unchecked.
Decimation Factor	Specifies the logging frequency based on a factor of the simulation time step. For instance, with a decimation factor equal to 1 the data is saved every step. If the decimation factor is 2, the data is saved every 2 steps.
Frame length	The Frame length parameter specifies how many steps are to be recorded without any data loss. A frame corresponds to the number of consecutive steps without loss. Depending on the hardware configuration, some steps may be lost between two frames. This zone of possibly lost data is called the blind area. This area is not visible and is thus not captured by the data logging system. Because the data are stored in a file, users may see missing samples between these frames.  The size of the blind area depends on many factors such as the number of signals stored, the sampling frequency, the speed of the simulator, the disk speed, etc.
Frame length unit	Defines the unit of the Frame length parameter. Default unit is in Seconds. Open
Number of frames to record	Specifies how many frames to record. Note that there is no data loss within a frame but it may happen between frames.
Show trigger configuration	If enabled, the trigger configuration parameters will be made available.
Trigger level	Level value that activates the trigger. For example, a value of 80 means the recording starts when the trigger-signal rises past 80.
Trigger function	Specifies when a trigger event is generated, depending on the Trigger level or Trigger polarity fields. Edge: recording starts as soon as the signal moves into the polarity region specified in the Trigger polarity field (which takes place, conceptually, in an instant) Level: recording starts when the signal crosses the value set in the Trigger level field (which will be true over a period of time)
Trigger polarity	Recording starts when the trigger signal is greater (Positive) or less (Negative) than the parameter Trigger level. Together with the Trigger function and Trigger level, this parameter determines the trigger condition: When the Trigger function is set to Edge: Positive polarity: the trigger condition is met when the trigger signal becomes higher or equal to the value in the Trigger level field Negative polarity: the trigger condition is met when the trigger signal becomes lower or equal to the value in the Trigger level field When the Trigger function is set to Level: Positive polarity: the trigger condition is met whenever the trigger signal is higher than the value in the Trigger level field Negative polarity: the trigger condition is met whenever the trigger signal is lower than the value in the Trigger level field
Pre-trigger percentage	Percentage of frame length allocated to values occurring before the trigger event. In all cases the trigger event itself is recorded.
Trigger holdoff	Number of steps to ignore after a frame is completed before re-arming the trigger detection.

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:

Open

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.

Open

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.

Open

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