Once configured, the IEC 61850 I/O interface offers data points to be connected with the model using the HYPERSIM sensors.
Time synchronization
The connection points below are only available if the I/O interface's Time synchronization parameter is set to Use sensor 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.
Connection point | Direction | Description |
---|---|---|
Sync | From model to driver | 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. |
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. | |
Microseconds | For GOOSE: Represents the microsecond count within the current second. For SV: This input is not necessary. |
GOOSE
Publishers
Connection point | Direction | Description |
---|---|---|
Settings / Pause | From model to driver | Controls the transmission of the GOOSE message. An input of 1 suspends transmission and a value of 0 enables it. |
Settings / stNum | From driver to model | Starting from 0, this value is incremented every time a change occurred to a data set member of the GOOSE message. |
Settings / sqNum | From driver to model | Starting from 0, this value is incremented for each GOOSE message sent without any modifications to its data set members. |
Settings / simulation | From model to driver | 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. |
Settings / ndsCom | From model to driver | This input controls the GOOSE header field "needs commissioning". |
Data | From model to driver | 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
Connection point | Direction | Description |
---|---|---|
Settings / Pause | From model to driver | Controls the reception of the GOOSE message. An input of 1 suspends reception and a value of 0 enables it. |
Settings / stNum | From driver to model | Starting from 0, this value is incremented every time a change occurred to a data set member of the GOOSE message. |
Settings / sqNum | From driver to model | 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 | From driver to model |
|
Settings / simulation | From driver to model | 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 | From driver to model | 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 | From driver to model | 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
Connection point | Direction | Description |
---|---|---|
Settings / Pause | From model to driver | Controls the transmission of the Sampled Values message. An input of 1 suspends transmission and a value of 0 enables it. |
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
Connection point | Direction | Description |
---|---|---|
Settings / Pause | From model to driver | Controls the transmission of the Sampled Values message. An input of 1 suspends transmission and a value of 0 enables it. |
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. |
Subscribers 9-2LE
Connection point | Direction | Description |
---|---|---|
Settings / Pause | From model to driver | Controls the reception of the Sampled Values message. An input of 1 suspends reception and a value of 0 activates it. |
Settings / Timestamp | From driver to model | Provides the time when each SV message was captured. This is an increasing count in microseconds provided by the Ethernet card. |
Settings / smpCnt | From driver to model | 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 | From driver to model | 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 | From driver to model | Vector of 4 currents [Ia, Ib, Ic, In], which are the 3 phase currents and the neutral current. |
Current Quality | From driver to model | 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 | From driver to model | Vector of 4 voltages [Va, Vb, Vc, Vn], which are the 3 phase voltages and the neutral voltage. |
Voltage Quality | From driver to model | 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
Connection point | Direction | Description |
---|---|---|
Settings / Pause | From model to driver | Controls the reception of the Sampled Values message. An input of 1 suspends reception and a value of 0 activates it. |
Settings / Timestamp | From driver to model | Provides the time when each SV message was captured. This is an increasing count in microseconds provided by the Ethernet card. |
Settings / smpCnt | From driver to model | 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 | From driver to model | 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 | From driver to model | 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. |
Quality word in Sampled Values messages
This information applies to both Sampled Values 9-2LE and IEC 61869-9 publishers and subscribers.
Bit | Attribute Name | Meaning of value | Value | Default value |
---|---|---|---|---|
0-1 | Validity | Good | 0 0 | 0 0 |
Invalid | 0 1 | |||
Reserved | 1 0 | |||
Questionable | 1 1 | |||
2 | Overflow | TRUE | FALSE | |
3 | Out of range | TRUE | FALSE | |
4 | Bad reference | TRUE | FALSE | |
5 | Oscillatory | TRUE | FALSE | |
6 | Failure | TRUE | FALSE | |
7 | Old data | TRUE | FALSE | |
8 | Inconsistent | TRUE | FALSE | |
9 | Inaccurate | TRUE | FALSE | |
10 | Source | Process | 0 | 0 |
Substituted | 1 | |||
11 | Test | TRUE | FALSE | |
12 | Operator blocked | TRUE | FALSE | |
13 | Derived | TRUE | FALSE |
Reports
Connection point | Direction | Description |
---|---|---|
Data | From model to driver | Each attribute found in the data set used by the report provides a connection point. Its format represents its full path within the IED: |
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, HYPERSIM 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, HYPERSIM 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.
Connection point | Direction | Description |
---|---|---|
Data | From model to driver | 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: |
Data (write) | From driver to model | If an attribute:
→ then it will provide a connection point from the driver to the model. |
Data Integrity Manipulation
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.
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.
Note:
This I/O interface is currently not compatible with the IEC 61850 Data Integrity Manipulation component. Support will be added in subsequent versions.
Nevertheless, the feature can be used by creating connections with other blocks.
The component can be used with the legacy interface. For details, see IEC 61850 (legacy) | Connections and the component's documentation linked above.
Loss
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 point | Direction | Description |
---|---|---|
Trigger | From model to driver | The 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. |
Mode | 0 → 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 frames | This value is the number of frames that will be dropped (prevented from being sent on the network). | |
Wait for smpCnt | If Mode is set to 1, the fault is delayed to wait for the specified smpCnt value. |
Duplication
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 point | Direction | Description |
---|---|---|
Trigger | From model to driver | The 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. |
Mode | 0 → 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 frames | This value is the number of frames on which the duplication fault will be applied. | |
Number of duplications | This 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 smpCnt | If 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 point | Direction | Description |
---|---|---|
Trigger | From model to driver | The 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. |
Mode | 0 → 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 smpCnt | When 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 smpCnt | If Mode is set to 1, the fault is delayed to wait for the specified smpCnt value. |
Delay
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 point | Direction | Description |
---|---|---|
Trigger | From model to driver | The 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. |
Mode | 0 → Fault is applied immediately after the trigger is raised. | |
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 smpCnt | If Mode is set to 1, the fault is delayed to wait for the specified smpCnt value. | |
Discard buffer | This connection allows to reset the delay to 0 while discarding all values in the internal buffer. | |
Flush on Network | This connection allows to reset the delay to 0 while flushing all values from the internal buffer on the network immediately. |
smpSynch manipulation
Simulate a man-in-the-middle attack by manipulating the smpSynch of a stream.
Connection point | Direction | Description |
---|---|---|
Trigger | From model to driver | The 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. |
Mode | 0 → 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 frames | This value is the number of frames on which the smpSynch fault will be applied. | |
smpSynch | When the fault is triggered, the smpSynch value will be overridden by the value provided in this connection. | |
Wait for smpCnt | If Mode is set to 1, the fault is delayed to wait for the specified smpCnt value. |
Quality Bits
Simulate a man-in-the-middle attack by manipulating the quality of the stream's voltage and current values.
Connection point | Direction | Description |
---|---|---|
Trigger | From model to driver | The 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. |
Mode | 0 → 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 frames | This value is the number of frames on which the quality manipulation fault will be applied. | |
Voltage Quality | When the fault is triggered, the voltage quality values will be overridden by the values provided in this connection. | |
Current Quality | When the fault is triggered, the current quality values will be overridden by the values provided in this connection. | |
Wait for smpCnt | If Mode is set to 1, the fault is delayed to wait for the specified smpCnt value. |
Connection Examples
Currently there are two options for connecting each configured data point:
- Use the sensor editor
- As of HYPERSIM 2022.1, use the I/O Interface block. More information about this block can be found here.
Here is an example of using the I/O Interface block:
The sensors can be viewed in the Selected Sensor Summary. Please note that unused columns have been hidden.