Datasets and Report control blocks

Datasets and report control blocks are required for unsolicited communication. The dataset defines which information shall be transmitted, the report control block when this information is transmitted.

Datasets

A dataset is an ordered collection of object references. It does not contain data objects but references to FCDs (Functional Constrained Data Objects) or FCDAs (Functional Constrained Data Attributes). These references are the members of the dataset and define the data which shall be transmitted in a report. The dataset members as well as their order must be known to both the client and the server. A dataset is located in a specific logical node but may also contain references to data objects or data attributes from other logical nodes.

A dataset member with functional constraint FCD refers to a data object of a device and may be represented by a data point in WinCC OA. A dataset member with functional constraint FCDA refers to a tag address in the device and may be represented by a data point element in WinCC OA.

Dynamic datasets

A dynamic dataset is a user defined dataset which is defined at SCADA level. You have to define

  • The dataset type (persistent or none persistent)

  • Where the dataset is located (e.g. ied1|Device1|LN12, refer to Datasets for further information)

  • The dataset members

The dynamic dataset is written to the device as soon as the RCB configured with this data set is enabled. Dynamic datasets are currently only supported by Siemens devices.

Persistent datasets

A persistent dataset is visible to all clients and will remain at the device when the communication between client and device is interrupted.

The data set can only be edited by the client that created it. Other clients may add it to their configuration by browsing the device, yet for them the dataset will appear as static.

The client that created the data set will delete it from the device when no RCB configured with this data set is active.

Non-persistent datasets

A non-persistent dataset is only visible to the client that created it. It can only be assigned to unbuffered RCBs and is automatically deleted if the communication between client and device is interrupted.
Attention: It is not recommended to use non-persistent datasets in a redundant WinCC OA system.

Configuration of datasets

  • Dataset members of functional constraint FCD must be used if it is required to get time stamp and quality information from the device. In this case this information is written to the respective attributes of the _original config in WinCC OA, which is the expected behavior in WinCC OA.

  • Use dataset members of functional constraint FCDA only to retrieve values which do not provide such information, e.g. for retrieving configuration information.

  • You may also use dataset members of functional constraint FCDA if you need to get time and quality information of a data value as original values. In this case you must be aware that in WinCC OA this information is in no way linked to the actual process value it belongs to.

CAUTION:

Note that a specific datset may only contain either data set members of type FCD or FCDA.

When using XML attribute ldName, dataset members must contain only data objects (DO) of the logical device (LD) at which the dataset is defined.

Report control blocks

The IEC 61850 standard defines a reporting mechanism using unsolicited data transmission. This aims at minimizing the network load. The report generation and transmission is controlled by report control blocks. A report control block holds is defined by its attributes, e.g. assigned dataset, trigger options and optional fields.

The type of data transmission is defined by the trigger options:

  • Event based transmission of data

  • Transmission of data in regular intervals

  • General interrogation (retrieving data from all dataset members of the RCB )

The assigned dataset defines which data will be transmitted.

Optional fields allow the inclusion of additional information.

Types of report control blocks

There are two types of report control blocks:

Unbuffered report control block (URCB)

Information is transmitted as defined by the chosen trigger options. In case of connection loss, the transmission is interrupted, information is not stored. Transmission of information starts again after the connection has been re-established. Information which might have been transmitted during connection loss is lost.

Buffered report control block (BRCB)

Information is transmitted as defined by the chosen trigger options. In case of a connection loss, information is stored in a ring buffer. The buffer size is defined by the device manufacturer. As soon as the connection is re-established, buffered information is transmitted in a chronological order (sequence-of-event ( SOE ) functionality).

Ring buffer:

Behavior on connection loss:

1.) In case of a connection loss, the entry ID of the last transmitted report is stored (in WinCC OA it is written to the internal DPE _IEC61850_RCB.RCBInfo.EntryID). In WinCC OA the internal DPE _IEC61850_IED.Config.ReadCompleteBuffer defines whether the whole buffer or only the reports which were buffered during the connection lost are retrieved.

In this example the reports R3 - R18 are written to the buffer during the connection loss. After connection reestablishment the buffered reports are retrieved.

2.) If too many reports are generated during the connection loss, the last transmitted report will not be in the buffer anymore when the connection is reestablished. This results in a buffer overflow.

In this example the last transmitted report R2 is not in the buffer anymore. The reports R3 - R17 are also overwritten and lost during the connection loss. After connection reestablishment the reports R18 - R37 are retrieved from the buffer.

Note:

When using BRCBs in a redundant WinCC OA system where in the configuration "Passive host connects to device" is enabled, you have to set the config entry [iec61850] rcbReleaseTimeout to a value bigger than the highest configured resvTms.

Indexed Report Control Blocks

In a standardized configuration file (SCD, CID) an RCB can be defined as indexed. In this case several instances of this RCB will be available at the device. The number of instances (1 - 99) is defined by the XML tag attribute RptEnabled.

Example

<ReportControl name="indexedRcb">
  <RptEnabled max="3">
</ReportControl>

In the device the following instances will be available:

  • unbufferedRCB01
  • unbufferedRCB02
  • unbufferedRCB03

In WinCC OA the RCB is configured as indexed. If it is activated, the client automatically searches for a free instance, starting at the highest (03 in the example). If no free instance can be found, the RCB is labelled temporarely-unavailable.

Note:

The RCB Management Panel allows to configure a specific instance, e.g. indexedRcb02. This instance will then be treated as not-indexed RCB.

Behavior on connection loss

Applies to all addresses of the data set assigned to this RCB.

The config entry setInvalidForConnLoss sets values invalid if the connection is lost. This can be prevented if the config entry is set to 0. However, in case of unsolicited communication, the default value 2 must be used for the config entry. Following cases may occur when the bits are reset by a GI after a connection re-establishment:

1. The server (IED) supports the optional attribute "Reason for Inclusion"

  • The DPE maps an attribute for which t is available: The GI bit is set, the time stamp remains

  • The DPE maps an attribute for which t is NOT available: The GI bit is set, the time stamp is set to the time stamp of the received report.

2. The server (IED) does not support the optional attribute "Reason for Inclusion": The GI bit is NOT set. In some cases the value is mapped with an invalid time stamp.

Behavior on communication loss

Applies to all addresses of the data set assigned to this RCB.

  • In case of error, e.g. temporarily-unavailableThe ", the_invalid" bit is set.
  • In case the RCB is not active for any other reason, the "_out_of_service" bit is set.

Additionally an RCB can be configured to set defined User Bits, anytime this RCB is not active. For this the config entries [iec61850] userBitUnsolDataUnavailable or [iec61850] userByteQualityMode must be used. If any of these config entries is set, for all addresses of its dataset the RCB will mark the following User Bits, anytime it is not active:

  1. userByteQualityMode is set: Bit 7 of this Byte is set.
  2. userBitUnsolDataUnavailable is set: the respective Bit is.

If both entries are set, [iec61850] userByteQualityMode overrides [iec61850] userBitUnsolDataUnavailable

Note:

When adding an RCB to a WinCC OA project, the User Bits and the "_out_of_service" Bit are marked for all addresses of the RCB's dataset if these addresses have already been configured in WinCC OA. Addresses of the data set which are configured later, are marked as soon as a respective state change of the RCB occurs.