Signals Properties

the properties of the signals are represented in the Signals View by columns.

the number of columns can be customized with an Utility Package.

Descriptive properties

The following properties are used within Helinks STS or as part of Signal list spreadsheets, but not typically included in an SCD file. It is possible to add description or process name to SCL data object/attribute instances (DOI/DAI).

• Process name
  A custom human readable identifier of the signal

• Description
  A more verbose description of the signals purpose

• Text 1-4
  Generic text fields that can be freely used for non-61850 purposes such as HMI text, internal routing, etc.

• Sort key
  Generic text field, typically used to group, sort, or filter signals without affecting the semantic of the signal

Functional hierarchy

A signal is always attached to a logical node. Logical nodes themselves are contained in other SCL elements, all the way up to the root of the project. The set of elements between the root of the project and the signal comprises its functional hierarchy.

The typical hierarchy for a substation project contains

• Substation, Voltage, Bay, Power Equipment, Function
  These columns specify the location in the functional hierarchy where the Signal can be found. Read-Only.

This can be different for a Processelement Structure like used by hydro or DER Domains. this is handle by the ProcessEditor.

Data

The IEC 61850 data attribute of a signal is identified by a path of identifiers comprising one or more data object (DO) identifiers, followed by one or more data attribute (DA) identifiers with a separating dot between identifiers, plus a functional constraint (FC) typically appended in angular brackets.

• Data
  This column contains the logical node + IEC 61850 data that is associated with the signal.

This field can be edited to associate different IEC 61850 data with the signal.

If the parent logical node type definition (LNType) contains a corresponding hierarchy of DOType and DAType definitions, the signal is said to be ‘Resolved’ see ‘engineering status’ bellow.

A logical node has a LNType according to the specification, and usually a different logical node type for the implementation. Correspondingly, a signals data attribute definition may also differ between specification and implementation, including the associated logical node ( typically, a signal is implemented using a GGIO when the data is not available in the device ).

IED

When the virtual IED is implemented a mapping of the specification signal should be done with the signal of the implemented IED see Mapping logical nodes. This implementation influence the signal list with the filling of these columns :

• IED, LD Inst
  These columns show which IED and logical device of the logical node that contains the signal data.

Engineering Status

A signals engineering status depends on the relationship between the data attribute definition and the data type definition.

• status
  These columns is readonly and represent the engineering status.

The values are:

• Specified - the signals logical node is not mapped to a device, the specification LNType exists, and the signals (specified) data attribute is resolved in that LNType definition.

• Implemented as specified - the signals logical node is mapped to an implementation, the signals specification and implementation data attribute is identical, and is resolved in both the specification and implementation LNType

• Implemented only - the signals logical node was created during implementation, and does not have a separate specification type, but the implementation data attribute is resolved in the implementation LNType

• From implementation - as 'implemented only', but the logical node is currently not mapped

• Implemented differently - the signals logical node is mapped to an implementation, the signals specification data attribute differs from the implementation, and the both data attribute definitions are resolved in their respective LNType. (Note that the parent logical node may also differ between specification and implementation, usually when a signal is implemented using a GGIO )

• Unresolved - the signals data attribute is not resolved. This typically happens after mapping a logical node to an implementation, when the specified data attribute is not resolved in the implementation LNType.

• Undefined - the signals data attribute is not complete or contains invalid characters. Typically the result of importing signal lists from Excel spreadsheets with incomplete IEC 61850 definitions.

ApplicationRoles

Signal can be assign to several Communication application (Report, SV, GOOSE) and for each application it has a role see Applications .

• Application roles
  The read only related application roles of this signals.

IO

An implemented Signal may be augmented with physical Input/Output information such as jack number or other wiring information. To edit this field, a Signal must be implemented in a device, and the device description must be augmented with hardware configuration information.

• IO
  if an IO is linked to this signal.

IEC 60870-5-104

If the IEC 60870-5-104 plugin is active see IEC 60870-5-101/104 integration , the following columns appear in the signal list:

• 104_CAA: Station Address

• 104_IOA: Information Object Address 3 octets or

  • 104_IOA1 first octet

  • 104_IOA2 second octet

  • 104_IOA3 third octet

• 104_ASDU: generic ASDU, may be used as a customizable Address Component.

Routing information

While not technically part of the Signals properties, data transmission is usually shown in signal tables, with registered Client functions and Applications showing up as columns in the table.