Documentation Home Page RT-LAB Home Page
Pour la documentation en FRANÇAIS, utilisez l'outil de traduction de votre navigateur Chrome, Edge ou Safari. Voir un exemple.

IEC61850 Introduction

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.



NOTE: Support for the legacy interface will be dropped in version 2024.1. Please ensure to have done the migration to the new interface by that point, either by using the converter tool described above or by recreating the configuration manually.




NOTE: As of RT-LAB 2022.1, the legacy interface can no longer be used to create new configurations. However, all previously made configurations will continue to be supported until version 2024.1.


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:

Mode (enum value)DetailsCommands possibleNotes

Status only (0)

In this mode, the server will not accept any commands from the client

None


Direct control with normal security (1)An IED receiving a command will implement it as is

Operate: acts on the Oper attribute

Cancel: acts on the Cancel attribute


Select-before-operate (SBO) with normal security (2)Helps prevent against concurrent accesses on the same IED

Select: acts on the SBO attribute

Operate: acts on the Oper attribute

Cancel: acts on the Cancel attribute

Make sure that the sboTimeout attribute has a value higher than 0. This attribute denotes the amount of time to wait between a select command and an operate command. If that time passes, the object is unselected and the process has to be started over.

Direct control with enhanced security (3)Same as the second mode mentioned above but with added feedback upon command completion

Operate: acts on the Oper attribute

Cancel: acts on the Cancel attribute


Select-before-operate (SBO) with enhanced security (4)

Same as the third mode mentioned above but with added feedback upon command completion

Select: acts on the SBOw (select-with-value) attribute

Operate: acts on the Oper attribute

Cancel: acts on the Cancel attribute

Make sure that the sboTimeout attribute has a value higher than 0. This attribute denotes the amount of time to wait between a select command and an operate command. If that time passes, the object is unselected and the process has to be started over.


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

Type of objectControlled attributeType of controlled attributePossible outcomes
Controllable single point (SPC)stValbooleanstVal can be forced to change its value to 0 or 1
Controllable double point (DPC)stValenumerated (interpreted as integer)stVal can be forced to change its value to 1 (off) or 2 (on)
Controllable integer status (INC)stValintegerstVal can be forced to change its value to any valid integer
Controllable enumerated status (ENC)stValenumerated (interpreted as integer)stVal can be forced to change its value to any valid enumeration index
Binary controlled step position information (BSC)valWTr.posValinteger

valWTr.posVal can be forced to step a value up or down, depending on the received command.

The attribute can change values within the range from -64 to 63 (included).

Integer controlled step position information (ISC)valWTr.posValintegervalWTr.posVal can be forced to any valid integer in the range from -64 to 63 (included)

Controllable analogue process value (APC)

mxVal.i

mxVal.f

(either both or just one)

mxVal.i - integer

mxVal.f - floating point

mxVal.i and/or mxVal.f can be forced to any valid integer/floating point value. 

The presence of one or the other depends on what has been included in their SCL file of origin. Most of the times, they are both present.

Binary controlled analogue process value (BAC)

mxVal.i

mxVal.f

(either both or just one)

mxVal.i - integer

mxVal.f - floating point

mxVal.i and/or mxVal.f can be forced to step a value up or down, depending on the received command.

The presence of one or the other depends on what has been included in their SCL file of origin. Most of the times, they are both present.


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


Time synchronization

Choice for the time synchronization to use for all GOOSE and SV messages.

The options are:

  • Poll CPU clock: the driver will use the system time of the simulator to compute protocol timings.
  • Use connection in model: the timings will be synchronized with an external clock provided through connection points. This mode allows the use of the Spectracom TSync or Oregano boards to synchronize the protocol timings with a synchronization standard.
  • Poll synchronization hardware: the driver will attempt to detect and automatically use a synchronization source. The only compatible source available at the moment is the Oregano Syn1588 PCIe card. The card needs to be present in the system and the Synchronization driver must be properly configured in order to achieve the automatic synchronization.

To synchronize with a Spectracom TSync card, the only possible option to use is Use connection in model.

To synchronize with an Oregano card, both the Use connection in model and Poll synchronization hardware options are possible.

Use an RT core for the MMS serverIf enabled, the driver will reserve a real-time CPU core for its MMS server communication system. Otherwise, it will default to using core 0 (running with the operating system).
Advanced optionsThe options below require advanced knowledge of the IEC 61850 standard.
    Enable fixed-length encoding for GOOSE messages (61850-8-1 Ed.2 A.3)If enabled, the encoding of GOOSE messages will be done according to 61850-8-1 Ed.2 A.3. Some specific fields of the header and some data types will be encoded with a fixed-length, avoiding the compression done by ASN.1.
    Enable simulation flag (Reserved 1) in every SV and GOOSE telegramsIf enabled, the simulation bit in the Reserved 1 field of the header of each transmitted SV and GOOSE message will be set to 1. This will identify the data as being transmitted by a simulated device.
    Enable use of VLAN for SV and GOOSE telegramsIf enabled, all SV and GOOSE frames will be VLAN tagged with the identification number provided as a configuration parameter.


For GOOSE and SV IEC 61869-9 the initial value for that parameter comes from the SCL file.
    Enable Sampled Values data integrity manipulationIf enabled, data integrity manipulation mechanisms will be available for the transmission of SV 9-2LE messages. Additional information on all the possible error injection features are described in this document.

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.

Record dataIf 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 levelSelect 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 nameProvide 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.

    Number of frames to recordSpecifies how many frames to record. Note that there is no data loss within a frame but it may happen between frames.
    Show trigger configurationIf enabled, the trigger configuration parameters will be made available.
        Trigger levelLevel 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 percentagePercentage of frame length allocated to values occurring before the trigger event. In all cases the trigger event itself is recorded.
        Trigger holdoffNumber 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:

File pathThe selected file will be parsed to retrieve all IED data models as well as all control blocks.
File nameFor ease of use, this field shows only the name of the file provided in the File path field.

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.

Keep all modified valuesThe values of the editable parameters that originated from the initial SCL file will be unaltered. This will ensure that any user modifications are maintained.
Reset all modified valuesThe values of the editable parameters that originated from the initial SCL file will be reset to the values found in the new file. All user modifications will be lost.


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.

IEDGOOSESV (IEC 61869-9 only)Reports

In the generic section:

  • Name reset
  • File namereset

In the MMS sever configuration section:

  • NIC namekeep
  • IP address keep
  • TCP portkeep

In the data model section, only applicable parameters are in the data attributes:

  • Name reset
  • Functional constraintreset
  • Data set reference(s)reset
  • Control block reference(s)reset
  • Add MMS data point keep

The information below applies only if the FC (Functional Constraint) was and remained MX (measurement):

  • Output RMSkeep
  • RMS number of sampleskeep
  • RMS gainkeep

In the Data sets section, FCDAs can only be flagged as added or removed. This happens when the combination of node path, data object, data attribute and functional constraint cannot be found in both files.
Therefore, it can be said that the entire contents of a data set is reset. For each FCDA of the data set:

  • Node pathreset
  • Data objectreset
  • Data attributereset
  • Functional constraintreset
In the General section:
  • GOOSE IDreset
  • GOOSE control block namereset
  • GOOSE pathreset
  • Dataset → reset
  • Dataset path → reset
  • Description → reset
  • Configuration revision → reset

In the Publish section:

  • Enable publishing keep
  • Publishing ethernet adapterkeep
  • Publishing IEDreset

In the Subscribe section:

  • Enable subscribingkeep
  • Subscribing ethernet adapterkeep
  • Subscribing IEDkeep
    (IED that were removed during the file change will also be removed from this field)

In the GSE elements section:

  • MAC addresskeep or reset
  • App IDreset
  • VLAN ID keep or reset
  • VLAN priority  → keep or reset
  • Min duration [ms]keep or reset
  • Max duration [ms] keep or reset
In the General section:
  • SV IDreset
  • SV control block namereset
  • SV pathreset
  • SV type reset
  • Sampling ratereset
  • Nominal frequencykeep
  • Datasetreset
  • Dataset pathreset
  • Descriptionreset
  • Configuration revisionreset
  • Number of ASDU reset

In the Publish section:

  • Enable publishingkeep
  • Publishing ethernet adapterkeep
  • Publishing IEDreset

In the Subscribe section:

  • Enable subscribingkeep
  • Subscribing ethernet adapterkeep
  • Subscribing IEDkeep
    (IED that were removed during the file change will also be removed from this field)

In the SV elements section:

  • MAC addresskeep or reset
  • App IDreset
  • VLAN IDkeep or reset
  • VLAN prioritykeep or reset
In the General section:
  • Rpt ID reset
  • Report control block name → reset
  • RCB path reset
  • RCB typereset
  • Dataset reset
  • Dataset pathreset
  • Description reset
  • Configuration revision → reset

In the Report section:

  • Enable reporting → keep
  • Server IED reset
  • Client LN reset
  • Maximum number of clients reset
  • Indexed reports → reset
  • Integrity period [ms] reset
  • Buffer time [ms] → reset

In the Trigger options section:

  • Data change (dchg) keep or reset
  • Quality change (qchg)  → keep or reset
  • Data update (dupd)  → keep or reset
  • Periodic integrity → keep or reset
  • General interrogation (gi) → keep or reset

In the Optional fields section:

  • Sequence number (seqNum)keep or reset
  • Timestamp (timeStamp) → keep or reset
  • Dataset (dataSet)keep or reset
  • Reason code (reasonCode) → keep or reset
  • Data reference (dataRef)keep or reset
  • Entry identification (entryID) → keep or reset
  • Configuration reference (confRef) → keep or reset
  • Buffer overflow (bufOvfl) keep or reset

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:

File nameThe file from which the IED information was extracted from. This is not applicable in case the IED was added manually.

MMS server configuration

NIC nameThe network interface card name used for the IED's MMS server communication.
The proper adapter should be selected based on the information given by the Linux command "ifconfig" or Windows command "ipconfig".
On Linux platforms, the server communication will bind itself to the network interface specified in this field. This means that the server will only accept connection requests received through that particular interface.
IP addressThe IP address to use for the IED's MMS server communication. The keywords ANY or AUTO can be used when the IP is not known. In that case, the IP will be determined automatically from the NIC name provided.


On Linux platforms, the IP aliasing functionality can be used to give each IED a different IP address even though the same network interface will be used. Each IED will have its own IP alias (i.e. eth0:0, eth0:1 ...) which should appear in the list displayed by the Linux command "ifconfig".
TCP portThe TCP port used for the IED's MMS server communication.

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:

NameDescriptionIn the example above, it is..
AP

An access point

AP1
LDA logical deviceLD0
LNA logical nodeLLN0
DOA data objectNamPlt
DAA data attributeparamRev

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:

Enable as controllable object

When this checkbox is enabled, the current object's attributes with FC = CO, along with any other attributes that might change following a control request (such as stVal) will be added to the MMS server.
Attributes with FC = CO can only be added to the MMS server through this checkbox.

More concretely, the following attributes are added to the IED tree, with Read Write access rights:

  • stVal or valWTr.posVal or mxVal.i/f (which one is present depends on the CDC of the controlled object)
  • ctlModel
  • sboTimeout

Some other attributes also become Read Write in order to be able to display any extra information about the control commands executed. To keep things simple, these attributes are not added automatically to the IED tree but they can be added manually by the user on a per-need basis. These attributes are:

  • ctlNum
  • origin.orCat
  • origin.orIdent
  • opRcvd
  • opOk
  • tOpOk


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:

NameThe name of the data attribute. It contains any potential sub-object or structure levels, separated by dots.
Functional constraintThe functional constraint (FC) of the current attribute. The following FC are not supported: BR, RP, GO, MS, US, LG, SG, SE.
Data set reference(s)Names of the datasets within the IED that contain the data attribute.
Control block reference(s)Names of the control blocks within the IED that make use of the data attribute.
Add MMS data point

Add the data attribute to the MMS server instantiated on the simulator. This means that any client connecting to the server will be able to read the attribute and/or write into it (if the functional constraint permits it).


Enabling a report using a dataset that contains this attribute will cause this field to be automatically enabled as well.

If this field is grayed out, there are several explanations:

  • if the FC is CO, it means the current attribute can only be enabled through its parent object's Enable as controllable object field
  • if the FC is not CO and:
    • the field is enabled, it means the current attribute is in use by a report control block; the field is grayed out to prevent disabling it while a report needs it
    • the field is disabled, it means the FC of the current attribute is not supported

Note: since attributes with FC = CO are parameters for control commands sent by the client, they are considered pseudo-attributes. Therefore, they cannot be read or written the same way as other attributes. They can be added to the IED tree but they will not have any connection points to allow their control by the user in the model.

Output RMSThe value placed in the server for the attribute will be its RMS calculation.


This field is only available for attributes with the MX (measurement) functional constraint and it can be changed only if the field Add MMS data point above is enabled.
RMS number of samples

Number of samples to accumulate for each RMS calculation.
This field is only available for attributes with the MX (measurement) functional constraint. It can be changed only if the fields Add MMS data point and Output RMS above are enabled.

RMS gainGain to apply to each RMS calculation. The value placed in the server contains this gain.


This field is only available for attributes with the MX (measurement) functional constraint. It can be changed only if the fields Add MMS data point and Output RMS above are enabled.

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:

Node pathFull path of the node within the IED. The format is IED / Access point / Logical device / Logical node.


The items referenced in the Data object and Data attribute columns are part of this node.
Data objectData object referenced by the FCDA.


If set to < all >, all attributes matching the criteria in the Data attribute and Functional constraint columns are selected.


If Data attribute is also set to < all >, then all attributes that are part of the node referenced in the Node path column and have FC equal to the value in the Functional Constraint column are selected.
Data attributeData attribute referenced by the FCDA.
If set to < all >, all attributes that are in the data object referenced in the Data object column and have FC equal to the value in the Functional constraint column are selected.
If Data object is also set to < all >, then all attributes that are part of the node referenced in the Node path column and have FC equal to the value in the Functional Constraint column are selected.
Functional constraintMain criteria used for selecting attributes from the location specified in the other columns.

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:

GeneralGeneral section, it contains non-editable information coming from the SCL file.
    GOOSE IDThe unique identification of the GOOSE message.
    GOOSE control block nameThe name of the control block describing the GOOSE message.
    GOOSE pathThe path of the GOOSE control block within the IED.
    Dataset

The name of the dataset used by the GOOSE message.

    Dataset pathThe full path within the IED of the dataset used by the GOOSE message.
    DescriptionThe description of the GOOSE message, retrieved from the SCL file.
    Configuration revisionThe configuration revision number of the GOOSE message.
PublishThis section contains fields to configure the publishing of the GOOSE message.
    Enable publishingEnable publishing of the GOOSE message.


Having this box checked will create the connection points associated with the publishing of the message. It will also ensure that publishing will start as soon as the simulation will start.
    Publishing ethernet adapterThe network interface card name used to publish the GOOSE message.
The proper adapter should be selected based on the information given by the Linux command "ifconfig" or Windows command "ipconfig".
    Publishing IEDThe name of the IED publishing the GOOSE message.


This field is non-editable.
SubscribeThis section contains fields to configure the subscription to the GOOSE message.
    Enable subscribingEnable subscribing to the GOOSE message.


Having this box checked will create the connection points associated with the subscription to the message. It will also ensure that subscription will start as soon as the simulation will start.
    Subscribing ethernet adapterThe network interface card name used to subscribe to the GOOSE message.


The proper adapter should be selected based on the information given by the Linux command "ifconfig" or Windows command "ipconfig".
    Subscribing IEDList of subscribing IED. This list is built manually according to the user's setup, with more than one choice possible. The options offered are the elements of the interface's IED list.


This field is not used in the real time simulation.
GSE elementsThis section contains fields specific to GOOSE messages.
    MAC address

The MAC multicast destination address associated with the GOOSE message (e.g. '01-0C-CD-04-00-00'). This field is initially filled based on information from the SCL file but it can be changed by the user as needed.
It must respect the following format: 'xx-xx-xx-xx-xx-xx', where x represents a hexadecimal digit. 

    App ID

The App ID associated with the GOOSE message. It is automatically filled based on information from the SCL file and it should be unique within the entire IEC 61850 network.
This field is non-editable.

    VLAN ID

The VLAN identifier associated with the GOOSE message. Along with the VLAN priority parameter below, it allows advanced configuration of smart switches to handle packet priorities on the network. 


This parameter is only taken into account if the Enable use of VLAN for SV and GOOSE telegrams checkbox in the General configuration is enabled.


The field is initially filled based on information from the SCL file but it can be changed by the user as needed.


Values accepted are between 1 and 4095.

    VLAN priority

The VLAN priority associated with the GOOSE message. Along with the VLAN ID parameter above, it allows advanced configuration of smart switches to handle packet priorities on the network. 


This parameter is only taken into account if the Enable use of VLAN for SV and GOOSE telegrams checkbox in the General configuration is enabled.


The field is initially filled based on information from the SCL file but it can be changed by the user as needed.


Values accepted are between 1 and 7.

    Min duration [ms]

The message retransmission delay used immediately following a change in any of the dataset members of the GOOSE message. The field is initially filled based on information from the SCL file. If the information is missing in the file, a default value of 62.5 ms is used. This value can be changed by the user as needed.

    Max duration [ms]

The maximum message retransmission delay reached when no changes occurred in any of the dataset members of the GOOSE message. The field is initially filled based on information from the SCL file. If the information is missing in the file, a default value of 1000 ms is used. This value can be changed by the user as needed.

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.

GeneralGeneral section, it contains a mix of editable and non-editable general information fields about the SV message.
    SV ID

The unique identification of the SV message.

For SV type 9-2LE: This field is editable. The user convention IEC61850-9-2LE recommends using the following format: "xxxxMUnn", where "xxxx" is the concatenation of the substation name, voltage and bay levels and "nn" identifies the measuring point. 
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    SV control block name

The name of the control block describing the SV message.

For SV type 9-2LE: Not applicable, field not used for this type.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    SV path

The path of the SV control block within the IED.

For SV type 9-2LE: Not applicable, field not used for this type.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    SV typeThe type of the SV message: IEC 61869-9 or 9-2LE.


This field is non-editable.
    Sampling rate

The number of transmitted or received samples per cycle, associated with the SV message. 

For SV type 9-2LE: This field is editable.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    Nominal frequencyThe power system frequency associated with the SV message.
This field is editable.
    Dataset

The name of the dataset used by the SV message.

For SV type 9-2LE: Not applicable, field not used for this type.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    Dataset path

The full path within the IED of the dataset used by the SV message.

For SV type 9-2LE: Not applicable, field not used for this type.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    Description

The description of the SV message, retrieved from the SCL file.

For SV type 9-2LE: Not applicable, field not used for this type.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    Configuration revision

The configuration revision number of the SV message.

For SV type 9-2LE: Not applicable, field not used for this type.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

    Number of ASDU

The number of samples embedded in each packet of the SV message.

For SV type 9-2LE: The value updates based on the sampling rate: for 80 samples per cycle, the number of ASDU is set to 1; for 256 samples per cycle, it is set to 8. This field is non-editable.
For SV type IEC 61869-9: The value is defined in the SCL file. This field is non-editable.

PublishThis section contains fields to configure the publishing of the SV message.
    Enable publishingEnable publishing of the SV message.


Having this box checked will create the connection points associated with the publishing of the SV message. It will also ensure that publishing will start as soon as the simulation will start.
    Publishing ethernet adapterThe network interface card name used to publish the SV message.
The proper adapter should be selected based on the information given by the Linux command "ifconfig" or Windows command "ipconfig".
    Publishing IEDThe name of the IED publishing the SV message.

For SV type 9-2LE: The publishing IED is selected manually according to the user's setup. The options offered are the elements of the interface's IED list. This field is not used in the real time simulation.
For SV type IEC 61869-9: This field is non-editable and it is necessary for the real time simulation. The information is extracted during the parsing of the SCL file.

SubscribeThis section contains fields to configure the subscription to the SV message.
    Enable subscribingEnable subscribing to the SV message.


Having this box checked will create the connection points associated with the subscription to the SV message. It will also ensure that subscription will start as soon as the simulation will start.
    Subscribing ethernet adapterThe network interface card name used to subscribe to the SV message.


The proper adapter should be selected based on the information given by the Linux command "ifconfig" or Windows command "ipconfig".
    Subscribing IEDList of subscribing IED. This list is built manually according to the user's setup, with more than one choice possible. The options offered are the elements of the interface's IED list.


This field is not used in the real time simulation.
SV elementsThis section contains fields specific to SV messages.
    MAC address

The MAC multicast destination address associated with the SV message (e.g. '01-0C-CD-04-00-00'). It must respect the following format: 'xx-xx-xx-xx-xx-xx', where x represents a hexadecimal digit. 

For SV type 9-2LE: This field needs to be configured by the user. To simplify the process, the first 8 digits are provided. Nevertheless, the field can be changed entirely to suit the simulation needs.
For SV type IEC 61869-9: This field is initially filled based on information from the SCL file but it can be changed by the user as needed.

    App ID

The App ID associated with the SV message.

For SV type 9-2LE: The App ID is set by default to the value 0x4000. This field is non-editable.
For SV type IEC 61869-9: The App ID is automatically filled based on information from the SCL file and it should be unique within the entire IEC 61850 network. This field is non-editable.

    VLAN ID

The VLAN identifier associated with the SV message. Along with the VLAN priority parameter below, it allows advanced configuration of smart switches to handle packet priorities on the network. 
This parameter is only taken into account if the Enable use of VLAN for SV and GOOSE telegrams checkbox in the General configuration is enabled.
For SV type IEC 61869-9, the field is initially filled based on information from the SCL file but it can be changed by the user as needed.
Values accepted are between 1 and 4095.

    VLAN priority

The VLAN priority associated with the SV message. Along with the VLAN ID parameter above, it allows advanced configuration of smart switches to handle packet priorities on the network. 


This parameter is only taken into account if the Enable use of VLAN for SV and GOOSE telegrams checkbox in the General configuration is enabled.


For SV type IEC 61869-9, the field is initially filled based on information from the SCL file but it can be changed by the user as needed.


Values accepted are between 1 and 7.

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:

GeneralGeneral section, it contains non-editable information coming from the SCL file.
    Rpt IDThe unique identification of the report control block.
    Report control block nameThe name of the report control block as taken from the SCL file.
    RCB pathThe path of the report control control block within the IED.
    RCB typeThe type of report control block: buffered or unbuffered.
    DatasetThe name of the dataset used by the report control block.
    Dataset pathThe full path within the IED of the dataset used by the report control block.
    DescriptionThe description of the report control block, retrieved from the SCL file.
    Configuration revisionThe configuration revision number of the report control block.
ReportThis section contains fields to configure the reporting. 
    Enable reportingEnable sending reports if the trigger options are met for any of the dataset members.
Having this box checked will create the connection points associated with sending the report.
    Server IEDThe name of the IED sending the report.
This field is non-editable.
    Client LNThe names of the LNs in the system that are clients to the report.
This field is non-editable and it is not used in the real time simulation.
    Maximum number of clients

Defines the maximum number of clients that can connect to this report type.
This field is non-editable.

    Indexed reports

When reports are indexed, their names are built by appending a suffix from 1 to 99 (representing the instance index) to their name.
This field is non-editable.

    Integrity period [ms]

This value is only relevant if the trigger option Periodic integrity is enabled. Reports containing all dataset members will be sent periodically at the interval (in milliseconds) dictated by the value in this field.
This field is non-editable.

    Buffer time [ms]

Amount of time in milliseconds between the detection of a trigger and the transmission of a report. If multiple attributes generate a trigger during this interval, they will all be added in the same report.
This field is non-editable.

Trigger options

Trigger options section, it contains fields to configure when reports are sent. All items below are editable.
They are initially filled based on information from the SCL file.

    Data change (dchg)

Triggers sending a report upon detecting a change in the dataset members' attributes.

    Quality change (qchg)

Triggers sending a report upon detecting a change in the dataset members' quality attributes.

    Data update (dupd)

Triggers sending a report upon detecting an update in the dataset members' attributes. The report will be sent if the value written into the triggering attribute is the same as the previously stored one.

    Periodic integrity

Enables sending a report periodically. The interval is dictated by the value in the Integrity period [ms] field.

    General interrogation (gi)

Enables sending of reports at the client's request.

Optional fields

Optional fields section, enabling an element below will ensure that it will be included in the reports sent. All items below are editable.
They are initially filled based on information from the SCL file.

    Sequence number (seqNum)

When enabled, will include the sequence number in the reports sent.

    Timestamp (timeStamp)

When enabled, will include the entry time in the reports sent.

    Dataset (dataSet)

When enabled, will include the name of the dataset used by the report control block.

    Reason code (reasonCode)

When enabled, will include the reason for sending the report. The reason is set according to the trigger that caused the report to be sent.

    Data reference (dataRef)

When enabled, will include the name of the data attribute that triggered the report transmission.

    Entry identification (entryID)

When enabled, will include the entry ID for the report.

    Configuration reference (confRev)

When enabled, will include the configuration revision number of the report control block.

    Buffer overflow (bufOvfl)

When enabled, will include information about any potential buffer overflow.

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.

Connectable nameDescriptionDirection

Sync

It is a binary value (0 or 1) that represents the synchronization state of the timestamp. If the timestamp is synchronized with an accurate external source such as a GPS, the value applied to this signal should be 1 and otherwise it should be 0.

For GOOSE: This value will appear in each time qualify byte of the data frames to indicate the validity of the timestamp.
For SV: Thi
s value will appear in the smpSynch attribute of the SV messages.

From model

Epoch

For GOOSE: Represents the number of seconds elapsed since January 1st 1970, commonly known as Unix epoch time. It means that it has to increment at each second. This signal is used to timestamp the outgoing packets.
For SV: Represents the second increment, which may be the epoch time (see above), as well as a counter of a period of one second. It means that it has to increment at each second. This value is used to set the smpCnt attribute in the SV messages.

Microseconds

For GOOSE: Represents the microsecond count within the current second.


For SV: This input is not necessary.

GOOSE

Publishers

Connectable nameDescriptionDirection

Settings / Pause

Controls the transmission of the GOOSE message. An input of 1 suspends transmission and a value of 0 enables it.

From model

Settings / stNum

Starting from 0, this value is incremented every time a change occurred to a data set member of the GOOSE message.

To model

Settings / sqNum

Starting from 0, this value is incremented for each GOOSE message sent without any modifications to its data set members.


The count is reset to zero if a change is detected for any of the data set objects.

Settings / simulation

This input controls the GOOSE header field "test". If the input value is 1 (TRUE), the GOOSE message will be transmitted with the test flag equal to TRUE, informing all subscribers that the Object Input Data is the result of a test.

From model

Settings / ndsCom

This input controls the GOOSE header field "needs commissioning".

Data

Each attribute found in the data set used by the GOOSE message provides a connection point. Its format represents its full path within the IED:


IED / Access point / Logical device / Logical node / Data object / Data attribute

Subscribers

Connectable nameDescriptionDirection

Settings / Pause

Controls the reception of the GOOSE message. An input of 1 suspends reception and a value of 0 enables it.

From model

Settings / stNum

Starting from 0, this value is incremented every time a change occurred to a data set member of the GOOSE message.

To model

Settings / sqNum

Starting from 0, this value is incremented for each GOOSE message received without any modifications to its data set members.


The count is reset to zero if a change is detected for any of the data set objects.

Settings / State

  • 0 → Message reception has been stopped or first message has not been received yet.
  • 1 → Reception is operational.
  • -4 → Message lost: the time-frame period between two consecutive GOOSE messages has surpassed the TimeAllowedToLive parameter.
  • -5 → Message Out of Order: newly received message has a sqNum or stNum smaller than the previously received message. In other words, the current message is older than the previous one.
  • -14 → pcap library initialization error: verify if the NIC name provided in the configuration is valid in the system.

Settings / simulation

This value represents the contents of the GOOSE header field "test". If the value is 1 (TRUE), it means the GOOSE message received has the test flag equal to TRUE. In other words, the Object Input Data is the result of a test.

Settings / Header simulated bit

This value represents the simulation bit in the Reserved 1 field of the header of each received GOOSE message. If the value is 1, the data is considered to be sent by a simulated device.

Data

Each attribute found in the data set used by the GOOSE message provides a connection point. Its format represents its full path within the IED:


IED / Access point / Logical device / Logical node / Data object / Data attribute

Sampled Values

Publishers 9-2LE

Connectable nameDescriptionDirection

Settings / Pause

Controls the transmission of the Sampled Values message. An input of 1 suspends transmission and a value of 0 enables it.

From model



Current Value

Vector of 4 currents [Ia, Ib, Ic, In], which are the 3 phase currents and the neutral current.

Current Quality

Vector of 4 quality values [QIa, QIb, QIc, QIn]. Each element represents a 16-bit value. The significance of each bit is described in the table below, in the Quality word in Sampled Values messages section.

Voltage Value

Vector of 4 voltages [Va, Vb, Vc, Vn], which are the 3 phase voltages and the neutral voltage.

Voltage Quality

Vector of 4 quality values [QVa, QVb, QVc, QVn]. Each element represents a 16-bit value. The significance of each bit is described in the table below, in the Quality word in Sampled Values messages section.

Publishers IEC 61869-9

Connectable nameDescriptionDirection

Settings / Pause

Controls the transmission of the Sampled Values message. An input of 1 suspends transmission and a value of 0 enables it.

From model



Data

Each attribute found in the data set used by the SV message provides a connection point. These points are for voltage and current values, as well as their quality values.


An attribute's format represents its full path within the IED:


IED / Access point / Logical device / Logical node / Data object / Data attribute

Subscribers 9-2LE

Connectable nameDescriptionDirection

Settings / Pause

Controls the reception of the Sampled Values message. An input of 1 suspends reception and a value of 0 activates it.

From model

Settings / Timestamp

Provides the time when each SV message was captured. This is an increasing count in microseconds provided by the Ethernet card.

To model

Settings / smpCnt

Number of SV messages received since the last change of second. For an SV stream of 80 samples per cycle at 60 Hz, smpCnt should increase from 0 to 4799, and wrap around at every second.

Settings / Header simulated bit

This value represents the simulation bit in the Reserved 1 field of the header of each received SV message. If the value is 1, the data is considered to be sent by a simulated device.

Current Value

Vector of 4 currents [Ia, Ib, Ic, In], which are the 3 phase currents and the neutral current.

Current Quality

Vector of 4 quality values [QIa, QIb, QIc, QIn]. Each element represents a 16-bit value. The significance of each bit is described in the table below, in the Quality word in Sampled Values messages section.

Voltage Value

Vector of 4 voltages [Va, Vb, Vc, Vn], which are the 3 phase voltages and the neutral voltage.

Voltage Quality

Vector of 4 quality values [QVa, QVb, QVc, QVn]. Each element represents a 16-bit value. The significance of each bit is described in the table below, in the Quality word in Sampled Values messages section.

Subscribers IEC 61869-9

Connectable nameDescriptionDirection

Settings / Pause

Controls the reception of the Sampled Values message. An input of 1 suspends reception and a value of 0 activates it.

From model

Settings / Timestamp

Provides the time when each SV message was captured. This is an increasing count in microseconds provided by the Ethernet card.

To model

Settings / smpCnt

Number of SV messages received since the last change of second. For an SV stream of 80 samples per cycle at 60 Hz, smpCnt should increase from 0 to 4799, and wrap around at every second.

Settings / Header simulated bit

This value represents the simulation bit in the Reserved 1 field of the header of each received SV message. If the value is 1, the data is considered to be sent by a simulated device.

Data

Each attribute found in the data set used by the SV message provides a connection point. These points are for voltage and current values, as well as their quality values.


An attribute's format represents its full path within the IED:


IED / Access point / Logical device / Logical node / Data object / Data attribute

Quality word in Sampled Values messages

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

Bit

Attribute nameMeaning of valueValueDefault value

0-1


Validity


Good0 00 0
Invalid0 1
Reserved1 0
Questionable1 1
2Overflow

TRUE

FALSE
3Out of range

TRUE

FALSE
4Bad reference

TRUE

FALSE
5Oscillatory

TRUE

FALSE
6Failure

TRUE

FALSE
7Old data

TRUE

FALSE
8Inconsistent

TRUE

FALSE
9Inaccurate

TRUE

FALSE

10

SourceProcess00
Substituted1
11Test

TRUE

FALSE
12Operator blocked

TRUE

FALSE
13Derived

TRUE

FALSE

Reports

Connectable nameDescriptionDirection

Data

Each attribute found in the data set used by the report provides a connection point. Its format represents its full path within the IED:


IED / Access point / Logical device / Logical node / Data object / Data attribute

From model

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.

Connectable nameDescriptionDirection

Data

Each attribute enabled in the IED tree that is used outside of reports provides a connection point from the model to the driver. Its format represents its full path within the IED:


IED / Access point / Logical device / Logical node / Data object / Data attribute

From model

Data (write)

If an attribute:

  • is enabled in the IED tree
  • is not part of any data sets used by reports
  • has functional constraint (FC) equal to SP, SV, CF, DC or BL or it is one of the attributes mentioned above part of a controllable object

→ then it will also provide a connection point from the driver to the model.
Its format represents its full path within the IED with the suffix that denotes it being written externally:
IED / Access point / Logical device / Logical node / Data object / Data attribute (write)

To model

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.

Connection nameDescriptionDirection
TriggerThe fault will be applied on a rising-edge from 0 to 1.
The trigger needs to be reset to 0 to be able to create a new fault.
From model
Mode0 → Fault is applied immediately after the trigger is raised.


1 → Fault is applied as soon as the smpCnt reaches the value provided in the Wait for smpCnt connection. 
Number of framesThis value is the number of frames that will be dropped (prevented from being sent on the network).
Wait for smpCntIf Mode is set to 1, the fault is delayed to wait for the specified smpCnt value.

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.

Connection nameDescriptionDirection
TriggerThe fault will be applied on a rising-edge from 0 to 1.
The trigger needs to be reset to 0 to be able to create a new fault.
From model
Mode0 → Fault is applied immediately after the trigger is raised.


1 → Fault is applied as soon as the smpCnt reaches the value provided in the Wait for smpCnt connection. 
Delay (us)When the trigger is raised, the transmission of the frames is delayed by this value in microseconds. An internal buffer will keep all the information to delay the packet. The delay can be a value from 0 to 1,000,000, i.e. the maximum accepted delay is one second.
Wait for smpCntIf Mode is set to 1, the fault is delayed to wait for the specified smpCnt value.
Discard bufferThis connection allows to reset the delay to 0 while discarding all values in the internal buffer.
Flush on NetworkThis connection allows to reset the delay to 0 while flushing all values from the internal buffer on the network immediately.

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.

Connection nameDescriptionDirection
TriggerThe fault will be applied on a rising-edge from 0 to 1.
The trigger needs to be reset to 0 to be able to create a new fault.
From model
Mode0 → Fault is applied immediately after the trigger is raised.


1 → Fault is applied as soon as the smpCnt reaches the value provided in the Wait for smpCnt connection. 
Number of framesThis value is the number of frames on which the duplication fault will be applied.
Number of duplicationsThis value is the number of times a specific frame will be duplicated.
As an example, if this number is 5 then every frame will be sent 5 times on the network together.
Wait for smpCntIf Mode is set to 1, the fault is delayed to wait for the specified smpCnt value.

smpCnt Manipulation

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

Connection nameDescriptionDirection
TriggerThe fault will be applied on a rising-edge from 0 to 1.
The trigger needs to be reset to 0 to be able to create a new fault.
From model
Mode0 → Fault is applied immediately after the trigger is raised.


1 → Fault is applied as soon as the smpCnt reaches the value provided in the Wait for smpCnt connection.
New smpCntWhen the fault is triggered, the smpCnt of the SV message will be overridden by the value provided in this connection.
It is up to the user to control the validity of the new smpCnt.
Wait for smpCntIf Mode is set to 1, the fault is delayed to wait for the specified smpCnt value.

smpSynch Manipulation

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

Connection nameDescriptionDirection
TriggerThe fault will be applied on a rising-edge from 0 to 1.
The trigger needs to be reset to 0 to be able to create a new fault.
From model
Mode0 → Fault is applied immediately after the trigger is raised.


1 → Fault is applied as soon as the smpCnt reaches the value provided in the Wait for smpCnt connection.
Number of framesThis value is the number of frames on which the smpSynch fault will be applied.
smpSynchWhen the fault is triggered, the smpSynch value will be overridden by the value provided in this connection.
Wait for smpCntIf Mode is set to 1, the fault is delayed to wait for the specified smpCnt value.

Quality Manipulation

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

Connection nameDescriptionDirection
TriggerThe fault will be applied on a rising-edge from 0 to 1.
The trigger needs to be reset to 0 to be able to create a new fault.
From model
Mode0 → Fault is applied immediately after the trigger is raised.


1 → Fault is applied as soon as the smpCnt reaches the value provided in the Wait for smpCnt connection.
Number of framesThis value is the number of frames on which the quality manipulation fault will be applied.
Voltage QualityWhen the fault is triggered, the voltage quality values will be overridden by the values provided in this connection.
Current QualityWhen the fault is triggered, the current quality values will be overridden by the values provided in this connection.
Wait for smpCntIf Mode is set to 1, the fault is delayed to wait for the specified smpCnt value.

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.



OPAL-RT TECHNOLOGIES, Inc. | 1751, rue Richardson, bureau 1060 | Montréal, Québec Canada H3K 1G6 | opal-rt.com | +1 514-935-2323
Follow OPAL-RT: LinkedIn | Facebook | YouTube | X/Twitter