| Table of Contents |
|---|
...
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. |
...
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 |
...
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 |
...
| 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. |
...
| Background Color | ||
|---|---|---|
| ||
Note: This I/O interface is currently not compatible with the IEC 61850 Data Integrity Manipulation component. Support will be added in subsequent versions. The component can be used with the legacy interface. For details, see IEC 61850 (legacy) | Connections and the component's documentation linked above. |
...