Documentation Home Page ◇ HYPERSIM Home Page
Pour la documentation en FRANÇAIS, utilisez l'outil de traduction de votre navigateur Chrome, Edge ou Safari. Voir un exemple.
IEC 61850 | Configuration
Accessing the I/O Interface Configuration
The IEC 61850 communication protocol can be configured in the I/O Interface Configuration tool that can be opened from the HYPERSIM ribbon.
For more information on the general use of the tool, see I/O Interface Configuration.
General Configuration
The IEC 61850 I/O interface is configured within a few pages. When creating a new configuration, it is preconfigured to contain one empty SCL file entry.
The first page contains general parameters:
Time synchronization | Choice for the time synchronization to use for all GOOSE and SV messages. The options are:
To synchronize with a Spectracom TSync card, the only possible option to use is Use sensor in model. To synchronize with an Oregano card, both the Use sensor in model and Poll synchronization hardware options are possible. |
Use an RT core for the MMS server | If enabled, the driver will reserve a real-time CPU core for its MMS communication system. Otherwise, it will default to using core 0 (running with the operating system). |
Advanced options | The 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 telegrams | If 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 telegrams | If enabled, all SV and GOOSE frames will be VLAN tagged with the identification number provided as a configuration parameter. |
Enable Sampled Values data integrity manipulation | If enabled, data integrity manipulation mechanisms will be available for the transmission of SV 9-2LE messages. |
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 the project, in a folder named scl/ found next to the model. If the next time HYPERSIM 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 path | The selected file will be parsed to retrieve all IED data models as well as all control blocks. |
File name | For 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
The following steps explain the workflow.
1. Click on the browse button of a valid entry 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 values | The 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 values | The values of the editable parameters that originated from the initial SCL file will be reset to the value 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.
IED | GOOSE | SV (IEC 61869-9 only) | Reports |
|---|---|---|---|
In the generic section:
In the MMS sever configuration section:
In the data model section, only applicable parameters are in the data attributes:
The information below applies only if the FC (Functional Constraint) was and remained MX (measurement):
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.
| In the General section:
In the Publish section:
In the Subscribe section:
In the GSE elements section:
| In the General section:
In the Publish section:
In the Subscribe section:
In the SV elements section:
| In the General section:
In the Report section:
In the Trigger options section:
In the Optional fields section:
|
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.
The image below shows an example of a list of IED, in the summary view:
The image below shows the generic parameters of an IED:
Name | Name of the current IED. |
File name | The file from which the IED information was extracted from. This is not applicable in case the IED was added manually. |
MMS server configuration
NIC name | The network interface card name used for the IED's MMS server communication. |
IP address | The 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. |
TCP port | The 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:
Name | Description | In the example above, it is.. |
|---|---|---|
AP | An access point | AP1 |
LD | A logical device | LD0 |
LN | A logical node | LLN0 |
DO | A data object | NamPlt |
DA | A data attribute | paramRev |
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 this table), 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. More concretely, the following attributes are added to the IED tree, with Read Write access rights:
|
|---|
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