Description
HYPERSIM 2022.1 introduced a redesigned IEC 61850 solution, with added support for the Manufacturing Message Specification (MMS) feature. Due to the nature of this change, it was not possible to build upon the previously existing IEC 61850 solution and therefore a completely new interface was created.
In order to facilitate the migration from the legacy solution to the new one, a converter tool was also made. It permits porting the configuration of the interface along with its created connections. The goal of this document is to describe in detail the functioning of this tool.
The converter can be reached by right-clicking on the legacy interface instance and selecting Convert to V2.., as seen in the image below:
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.
Parameters
| I/O interface name | The name to give to the converted interface. The name cannot be empty and it must be unique in the project. |
|---|---|
| Relink sensors I/O configuration from the legacy to the new interface | This option is enabled by default. When this option is enabled, the sensors in the model that were previously linked with the legacy data points will be linked to their equivalent data points of the new interface. The exceptions are:
For more details on the differences and how the converter handles them, please refer to the Special conversion situations section below. |
| After conversion, keep the legacy interface configuration | This option is disabled by default. When this option is enabled, the legacy interface will be kept in the project at the end of a conversion. Once the legacy interface is deleted, no other conversion can take place. It is advised to backup the work project before proceeding with a conversion involving this option. |
| Test the conversion without altering the project (dry run) | This option is disabled by default. When this option is enabled, the configuration and connections will be converted "silently", i.e. without making any modifications to the project. This mode permits checking for any possible errors in order to fix them before running the actual conversion. |
Special conversion situations
The sections below detail information about situations where a direct conversion is not possible.
Enabling of services
Legacy implementation: option Enable all SV and GOOSE services by default as soon as the simulation starts found in the main section. This parameter is combined with each GOOSE and Sampled Values (publisher and subscriber) item's Enable connection point.
Current implementation: transmission and/or reception of all GOOSE and Sampled Values (and Reports as well) items that are enabled in the configuration will start automatically when the simulation starts. A new data point is used to stop transmission and/or reception, named Pause.
The table below shows how the converter handles this scenario:
| Legacy implementation | Result of conversion | Notes |
|---|---|---|
Enable all SV and GOOSE services by default as soon as the simulation starts does not matter or
| No impact on the converted configuration. | All items that are enabled in the new interface's configuration are started by default. Therefore, this parameter does not have any impact on the resulting converted configuration or connections. |
| Enable connections used for GOOSE or Sampled Values (publisher or subscriber) items | No impact on the converted connections. | This row is applicable only if the connection conversion is requested. As mentioned above, all items that are enabled in the new interface's configuration are started by default. A Pause data point can be used if it is required to suspend transmission or reception at any time during the simulation. Due to Enable and Pause essentially having opposite meanings, it was not possible to convert the Enable data points without a meaningful impact on the simulation. |
Synchronization
Legacy implementation: option Auto-connect to external synchronization if present found in the main section. This parameter is combined with each GOOSE and Sampled Values publisher item's Clock (possible values: INTERNAL or EXTERNAL). In the situation when auto-connection is not requested, every GOOSE or Sampled Values item configured with an EXTERNAL clock will have a set of clock connection points.
Current implementation: the drop-down menu Time synchronization found in the main section is now the only place to configure the synchronization. This parameter will be applied to all GOOSE and Sampled Values published. In case this parameter is set to Use sensor in model, a single set of clock connection points are made available.
The table below shows how the converter handles all the possible combinations.
| Legacy implementation | Result of conversion | Notes |
|---|---|---|
Auto-connect to external synchronization if present enabled Clock parameters of publisher items do not matter
| Time synchronization = Poll synchronization hardware
| Configuration: All publisher items that were previously using the INTERNAL clock setting are therefore upgraded to use the clock provided by an external synchronization hardware. Connections: If connection conversion is requested, any clock connections between the legacy interface and the model sensors will be ignored, ensuring that the only clock source is the external synchronization hardware. |
Auto-connect to external synchronization if present disabled
Clock settings of publisher items are a mix of INTERNAL and EXTERNAL (GOOSE used as example)
| Time synchronization = Use sensor in model
| Configuration: All publisher items that were previously using the INTERNAL clock setting will therefore use the clock provided through connections. Connections: If connection conversion is requested the following will happen: → To resolve the complexity of choosing which set of clock connections from the legacy interface gets ported to the new interface, the converter uses a 'best-of' algorithm. → A set of legacy connections is considered best if it has all 3 data points necessary: Seconds, Microseconds and Sync. → If no such set is found, then the algorithm will connect each new clock data point to the sensor used by the first equivalent legacy point. → In case no suitable legacy point is found, the new data point is left unconnected. |
Auto-connect to external synchronization if present disabled
Clock settings of all publisher items are EXTERNAL (GOOSE used as example)
| Time synchronization = Use sensor in model
| Configuration: The conversion of the configuration is straight forward in this case, as all publishing items in the legacy interface use an EXTERNAL clock. This translates directly to the new interface using the Use sensor in model option. Connections: If connection conversion is requested the following will happen (same as above): → To resolve the complexity of choosing which set of clock connections from the legacy interface gets ported to the new interface, the converter uses a 'best-of' algorithm. → A set of legacy connections is considered best if it has all 3 data points necessary: Seconds, Microseconds and Sync. → If no such set is found, then the algorithm will connect each new clock data point to the sensor used by the first equivalent legacy point. → In case no suitable legacy point is found, the new data point is left unconnected. |
Auto-connect to external synchronization if present disabled
Clock settings of all publisher items are INTERNAL (GOOSE used as example)
| Time synchronization = Poll CPU clock
| Configuration: The conversion of the configuration is straight forward in this case, as all publishing items in the legacy interface use an INTERNAL clock. This translates directly to the new interface using the Poll CPU clock option. Connections: This mode does not have any implications in case the connection conversion is requested. |
SCL file input
Legacy implementation: an SCL file needs to be provided for each GOOSE and Sampled Values (IEC 61869-9) item (publisher and subscriber).
Current implementation: For each SCL file provided, the new interface will reveal all the control blocks present in it (GOOSE, Sampled Values or Reports) along with the complete data model of each IED found.
The following scenarios are of interest.
| Legacy implementation | Result of conversion | Notes |
|---|---|---|
The files inputted for GOOSE or Sampled Values (IEC 61869-9) items are no longer found on the disk (GOOSE used as example) | MMS will not be available for IED deduced during conversion, due to their missing data model:
All elements that had missing information will be marked with (Unknown), such as the Access Points in paths:
| In spite of lacking information, the simulation using the converted interface and connections would be able to run. Ideally, a verification should be done before the conversion to ensure that the files are still present at the path indicated in the legacy interface. When the files are found, the converter is capable of retrieving all information related to control blocks and IED data models. |
The file inputted for GOOSE or Sampled Values had issues that went unnoticed due to the problem being in an unused feature. Here's a concrete example: A project was created to publish GOOSE messages. | One feature of the new interface is that it shows everything that is in the SCL file including control blocks which were not used before. After a conversion, this could potentially lead to discovering issues with the file in use. Converting the example shown on the left leads to having this kind of configuration:
| In the example on the left, the converted project would work in the same manner as it did before, thanks to SV not being required. The workflow to correct SCL file information (or just to update it) is: → Fix the issue/make the change in the file → Refresh the file by clicking on its entry in the SCL/SCD/ICD files list and re-selecting it → Choose the refresh options desired (keep or reset user changes) → After this process, the configuration will be updated according to the information in the file and the refresh option chosen above. |
Exploring the possible combinations
If you want to have the converted configuration but want to start fresh with the connections
Running a conversion with the options as shown above:
- will create the new IEC 61850 interface based on the configuration of its predecessor
- will not replace its connections; the new interface's data points will have to be connected to the model sensors manually
- will not keep the legacy interface; it will be deleted at the end of the conversion process
This scenario is useful when converting the connections is of no interest, such as when a substantial part of the model has changed (placement, names and logic surrounding the sensors connected to the legacy data points).
If you want to perform a quick conversion test without changing connections
Running a conversion with the options as shown above:
- will create the new IEC 61850 interface based on the configuration of its predecessor
- will not replace its connections; the legacy interface's data points will remain connected to the model sensors
- will keep the legacy interface; it will not be deleted at the end of the conversion process
This scenario is benign: only the configuration of the legacy interface is converted. Its utility lies in permitting the user to perform a test-conversion, to see what the current configuration found in the legacy interface looks like in the new interface.
If you want to perform the complete conversion
Running a conversion with the options as shown above:
- will create the new IEC 61850 interface based on the configuration of its predecessor
- will replace its connections
- will not keep the legacy interface; it will be deleted at the end of the conversion process
This scenario is considered to be the default one. It represents a complete conversion.
If you want to perform the conversion but are not ready to delete the legacy interface
Running a conversion with the options as shown above:
- will create the new IEC 61850 interface based on the configuration of its predecessor
- will replace its connections
- will keep the legacy interface; it will not be deleted at the end of the conversion process
This scenario is considered to be an incomplete conversion: while configuration and connections are converted, the legacy interface remains in the project. It could serve as reference or as an example during the transition period before fully passing to the new interface.