E500 FD Rel11 Part6 RTU Functions

(1)

RTU500 series Remote Terminal Unit

Function Description Release 11

(2)

(3)

Function Description Release 11

Revision

Document identity: 1KGT 150 798 V002 1 Revision: Date: Changes:

0 03/2013 Initial version

1 05/2013 New layout

2 02/2014 Update for Release 11.1

Chapter “interfaces and network” moved to function description part 9

(4)

(5)

1 Introduction ... 1-1

1.1 About the RTU500 series Function Description ... 1-1

1.2 Preface ... 1-1

1.3 References ... 1-2

2 Host communication interface ... 2-1

2.1 Physical interfaces ... 2-1

2.2 Monitoring direction ... 2-2

2.3 Command direction ... 2-2

2.4 General interrogation ... 2-2

2.5 Filtering of information ... 2-2

2.6 Supervision of connection to host systems ... 2-2

2.7 Queue and buffer handling ... 2-3

2.7.1 Handling of overflow situations ... 2-3

Loss of changes of information ... 2-3

Loss of pulse counters ... 2-3

2.7.2 Queue storage timeout ... 2-4

2.8 Overview of the software structure ... 2-4

3 Subdevice communication interface ... 3-1

3.1 Data flow in monitoring direction ... 3-2

3.2 Command direction ... 3-2

3.2.1 Data flow ... 3-2

3.2.2 Command output procedures ... 3-3

(6)

3.3 General interrogation ... 3-4

3.4 Time synchronization ... 3-5

3.5 System events ... 3-5

4 Substation automation system with IEC 61850 ... 4-1

4.1 RTU500 series in an IEC61850 system ... 4-1

4.2 IEC61850 configurations... 4-1

4.2.1 RTU500 series configured as IEC 61850 client ... 4-2

4.2.2 RTU500 series configured as IEC 61850 server ... 4-2

5 Programmable Logic Control (PLC) ... 5-1

5.1 PLC – SCADA processing ... 5-1

5.1.1 PLC function ... 5-1

5.1.2 PLC INPUT, PLC OUTPUT and internal flag memory ... 5-2

5.1.3 PLC program memory ... 5-2

5.1.4 Retain variable section ... 5-2

5.1.5 Boot project file ... 5-2

5.1.6 PLC application and tasks ... 5-2

5.1.7 I/O interface –- general I/O handling ... 5-3

Input process image ... 5-3

Redundancy switchover activities ... 5-3

Input handler ... 5-4

PLC core ... 5-4

Output handler ... 5-4

Signal processing ... 5-5

Messages and commands ... 5-5

System event processing ... 5-6

System command processing ... 5-6

System event messages ... 5-6

Characteristic technical data ... 5-6

(7)

Function Description Release 11 Contents

6 Redundancy ... 6-1

6.1 Overview ... 6-1

6.2 RTU560 redundant CMU concept ... 6-1

6.2.1 Master and slave concept ... 6-3

6.2.2 Redundancy switchover ... 6-3

6.2.3 Impact on RTU functions ... 6-3

Process data processing ... 6-3

PLC functions ... 6-4

Logic function ... 6-4

Archive and Local Print, integrated HMI ... 6-4

Time administration ... 6-5

Simple Network Management Protocol (SNMP) ... 6-5

6.2.4 RTUtil500 configuration ... 6-10

6.2.5 RTU500 series redundant communication ... 6-11

Redundant Host Communication Interfaces ... 6-11

Redundant Subdevice Communication Interface ... 6-11

7 Start-up, Configuration and Time Management ... 7-1

7.1 Start-up procedures ... 7-1

7.1.1 RTU System Start ... 7-1

7.1.2 RTU560 CMU start ... 7-2

7.1.3 RTU560 CMU integration ... 7-2

7.1.4 RTU560 CMU removal ... 7-3

7.2 RTU500 series configuration... 7-4

7.2.1 General requirements ... 7-4

Configuration file load procedure ... 7-4

7.3 RTU500 series Time Management ... 7-5

7.3.1 Time management principle ... 7-5

7.3.2 Time administration ... 7-5

7.3.3 Time sources and time masters ... 7-7

7.3.4 RRTU System time qualifiers and signalization ... 7-7

7.3.5 Time zone and daylight saving ... 7-8

(8)

7.4 Time synchronization modes ... 7-9

7.4.1 Synchronization by NCC ... 7-9

7.4.2 Synchronization by NCC with external minute pulse ... 7-10

7.4.3 Synchronization via (S)NTP ... 7-10

Unicast client features ... 7-13

Broadcast client features ... 7-14

Synchronization accuracy ... 7-15

7.4.4 Synchronization via radio clock ... 7-16

7.4.5 Redundant Time Synchronization ... 7-16

7.5 Synchronization of sub-RTUs ... 7-17

7.5.1 Synchronization with clock synchronization command ... 7-17

7.5.2 Synchronization via SNTP server ... 7-18

8 RTU500 series I/Os and I/O bus interface ... 8-1

8.1 I/O bus master and RTU500 series I/O ... 8-1

8.2 Event flow through RTU500 series ... 8-3

8.2.1 SLC – IOM task ... 8-3

8.2.2 MPU ... 8-3

9 Status and diagnostic information ... 9-1

9.1 Status and error report to NCC ... 9-1

9.2 Web server diagnosis ... 9-1

9.2.1 System Diagnosis... 9-1

9.2.2 Status Information ... 9-2

9.3 RTU alarms and warnings ... 9-2

9.3.1 Board States and LED Signaling ... 9-14

9.3.2 LEDs on 560CMU02 and 560CMU05 ... 9-15

9.3.3 CMU states ... 9-15

Boot state ... 9-15

Start-up state ... 9-16

Alarm state ... 9-16

Warning state ... 9-17

OK state ... 9-17

(9)

Function Description Release 11 Contents

9.3.4 Communication interface states ... 9-17

Serial interface states ... 9-17

Serial interface Boot and not configured state ... 9-17

Start-up state ... 9-17

OK state ... 9-18

Error state ... 9-18

Ethernet interface ... 9-18

9.3.5 I/O boards, modems and real time clocks ... 9-19

LED indications for 23AA21, 23AE23 and 23BE23 ... 9-19

LED indications 23BA20 and 23BA22 or 23BA23 ... 9-20

LOC pushbutton ... 9-20

Object command output with (1 out of n) check ... 9-21

Object command output and failure at (1 out of n) check: ... 9-22

LED indications for 23WT25 ... 9-23

LED indications for 23WT23 or 23WT24 ... 9-23

LED indications for 560RTC01 ... 9-24

LED indications for 560RTC02 ... 9-25

LED indications for 560RTC03 ... 9-26

9.3.6 LED indications for 23OK24 ... 9-26

9.3.7 LED indications of decentralized modules ... 9-27

LED indications for 23BA40 and 23BE40 ... 9-27

10 System data interface ... 10-1

10.1 System events ... 10-1

10.2 System commands ... 10-12

11 Glossary of terms ... 11-1

(10)

(11)

1 Introduction

1.1 About the RTU500 series Function Description

The Function Description consists of several parts:

Document identity Part name Explanation

1KGT 150 793 Part 1: Overview Overview of the RTU500 series and system architecture 1KGT 150 794 Part 2: Rack Solutions Description of the RTU500

series rack solutions 1KGT 150 795 Part 3: DIN Rail

Solutions

Description of the RTU500 series DIN rail solutions 1KGT 150 796 Part 4: Hardware

Modules

Overview of the RTU500 series rack and DIN rail modules

1KGT 150 797 Part 5: SCADA

Functions

Description of the RTU500 series SCADA functions 1KGT 150 798 Part 6: RTU500

Functions

Description of the RTU500 series functions

1KGT 150 799 Part 7: Archive Functions

Description of the RTU500 series Archive functions 1KGT 150 800 Part 8: Integrated HMI Description of the RTU500

series Integrated HMI interface 1KGT 159 896 Part 9: Interfaces and

Networks

Description of the RTU500 series Interface and Network functions

Table 1: Parts of the Function Description

1.2 Preface

This document describes the following functions of the RTU500 series:

 Host Communication Interface

 Subdevice Communication Interface

 IEC 61850 Engineering

 Programmable Logic Control (PLC)

 Redundancy

 Start-up, Configuration and Time Management

 Status and Diagnostic Information

(12)

1.3 References

[1] 1KGT 150 801 RTUtil500 Users Guide

Release 11

Describes the usage of engineering tool RTUtil500 of the RTU500 series [2] Individual Ident RTU500 series

Protocol Descriptions

Description of the Sub and Host Communication Protocols [3] 1KGT 150 853 Interfaces and

Protocols Release 11

Description of the relationship of interfaces and protocols

[4] RFC1157 A Simple Network Management Protocol (SNMP) [5] RFC1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II (second version) [6] 1KGT 150 802 RTU500 series Web Server User's Guide

(13)

2 Host communication interface

This chapter describes the general part of the Host Communication Interface (HCI) of the RTU500 series. Communication with multiple host systems (e.g., NCCs) with different communication protocols is one of the basic concepts for RTU500 series.

Figure 1: RTU500 series network

The RTU enables communication with up to 16 different host systems by using the communication interfaces provided by the CMUs.

No interdependencies exist between the various instances of host communication interfaces. Each interface has its own set of configuration parameters and runs independently from other interfaces during runtime.

Because of the different requirements of protocols supported by RTU500 series, this chapter describes only the general functions and principles of host

communication interfaces. For detailed information on the functions provided by host communication interfaces for a specific protocol, refer to the corresponding Interface Description for host communication.

2.1 Physical interfaces

Physical interfaces used for communication to host systems are limited only by the available interfaces of a CMU and by their support of the selected communication protocol.

Communication interfaces can be serial interfaces or Ethernet interfaces.

Configuration of the interfaces as host communication lines with their protocols is completely performed in RTUtil500. There are no hardware switches to configure the interfaces.

(14)

For detailed information about available interface and protocol combinations of different CMU types and existing restrictions, refer to [3].

2.2 Monitoring direction

All active host systems receive any message that is generated by the RTU. Any message that comes from a substation and could be translated from one protocol to another is sent to the active host systems.

2.3 Command direction

Commands sent to the RTU are accepted from all host systems, without

preference or priority. There is no restriction to the number of different commands that can be handled at a time by the RTU.

If a command sequence is running, further operations requested by the same object will be rejected until the current command sequence is completed, or until a defined timeout has expired. The timeout period depends on the host

communication interface. A timeout period of approx. 30 s is frequently used. If interlocking with local control authority is configured, all process commands are rejected while the local control authority is active. For more details see Part 8:

Integrated HMI, section Control Authority component.

2.4 General interrogation

A host communication interface contains a database with the current state of the process data and system data objects. When prompted with a general interrogation command, the host communication interface sends the content of this database as an answer.

The handling of general interrogations is protocol-specific. For detailed information on a particular protocol, refer to the corresponding Interface Description related to host communication.

2.5 Filtering of information

To avoid transmission of certain data points on certain host communication

interfaces, data points can be defined to be out of use by means of a setting that is specific to the interface for host communication. This setting refers to data in monitoring and command direction and can be set individually for each data object.

2.6 Supervision of connection to host systems

The RTU can manage up to 16 lines to host systems. System event messages indicate the status of connections to a host system, and whether a communication between the RTU and host systems failed:

(15)

Function Description Release 11 Host communication interface

Queue and buffer handling

2.7 Queue and buffer handling

Host communication interfaces receive any information addressed to internal interfaces for host communication of the RTU. Information processing starts with the reception of events from IC and depends on the protocol, which needs to be supported by the host communication interface.

Because of the requirements of different protocols, there is no uniform method for different HCIs for buffering or queuing events received from IC.

For a detailed description of queue and buffer handling, refer to the Interface Description related to host communication for the protocol in question.

Common functionality and principles used by all host communication interfaces of different protocols are described in the following chapters.

2.7.1 Handling of overflow situations

If the amount of information received from IC is larger than the amount of information that can be transmitted to the host system, changes of information or values of pulse counters may be lost depending on the time and the

communication settings being used.

Loss of changes of information

In the event of a loss of changes of information by a particular HCI, the latest state of the information will either be sent spontaneously or is available for read access, e.g., using a general interrogation.

Host communication interfaces use the following system event for signaling the loss of changes of information:

 SEV (117 ... 132): Host interface x: At least one change of information lost with 1 ≤ x ≤ 16

The system event signals the loss of changes of information by the HCI in

question. The system event is set if a change of information is lost for the first time. It is reset by an HCI implementation-specific algorithm.

Further diagnostic information about the internal status of the relevant host communication interfaces are added to the system diagnosis of the RTU.

Loss of pulse counters

To ensure host systems are provided with the most important values as long as possible, the RTU uses a replacement process for pulse counter values. Pulse counters consist of two readings – intermediate readings (IR) and end of period readings (EPR).

If the queue is full, IR messages are no longer stored. Only EPR messages are stored, overwriting any IR messages still in the queue until no more queued IR messages are left.

To store new EPR messages, the RTU then overwrites the oldest EPR message in the queue. The queue now only contains EPR messages dating backwards from the current time.

Host communication interfaces use the following system event for signaling:

 SEV (133 … 148): Host interface x: At least one pulse counter lost with 1 ≤ x ≤ 16 The system events are set to signalize that pulse counters states are lost. If the first time a pulse counter was replaced and is reset by an HCI implementation specific algorithm, the system event is set.

(16)

Further diagnosis information about the internal status of the concerned host communication interfaces are added to the system diagnosis of the RTU.

2.7.2 Queue storage timeout

If the connection to a host system is offline for any given time, the queue content can be saved into a process image after a configured time to avoid reporting of information. The image can be processed at a configured time. In this case, all changes of information are lost and the current process values have to be read by the host system using a general interrogation.

Detailed diagnostic information about queue storage timeouts of the relevant host communication interfaces are added to the system diagnosis of the RTU (see chapter Status and diagnostic information (page 9-1)).

2.8 Overview of the software structure

The internal software of Host Communication Interfaces (HCI) follows a three-layer architecture:

 Interface to Internal Communication (IC)

 Application layer in monitoring and command direction

 Link layer

Internal Communication (IC)

Host Communication Interfaces (HCI) Interface to Internal Communication Link Layer Application Layer Command Direction Application Layer Monitoring Direction

NCC

(17)

3 Subdevice communication interface

This chapter describes the general part of the Subdevice Communication Interface (SCI) of the RTU500 series. The SCI is used for communication between the RTU and subordinate devices. Subordinate devices are RTUs or, in general, other intelligent electronic devices (IED).

Communication with multiple IEDs with different communication protocols is one of the basic concepts of the RTU500 series.

The following figure shows an example of a network configuration with subordinate devices:

Figure 3: RTU500 series network

The SCI supports various communication protocols. For detailed information on protocol-specific configuration parameters, refer to the Interface Description for the relevant protocol.

All aspects of the SCI, its communication lines, and the protocols used on these lines are configured in RTUtil500. There are no hardware switches to configure the interfaces.

The SCI can manage up to 32 devices per line. An RTU supports up to 32 sub-lines.

The assignment of UART sub-protocols to serial interfaces is completely at the user's disposal. There are no dependencies between different protocols run on a CMU. The only restriction is the number of communication protocols supported by a firmware package. Not all communication protocols can run concurrently on a CMU board. Only certain combinations of protocols are allowed.

Protocols that do not operate on a UART basis are limited to the interfaces CPA and CPB on the 560CMU05 R0002.

(18)

Ethernet- and TCP/IP-based protocols can be used only with Ethernet interfaces. The structure of the SCI is independent of the protocol and shown in the following figure.

Internal Communication

Sub-Device Communication Interface (SCI) Interface to Internal Communication

Sub-Device

Link Layer Application Layer Command Direction Application Layer Monitoring Direction

Figure 4: Internal structure of the SCI

3.1 Data flow in monitoring direction

The link layer checks any messages received from a subordinate device for validity with regard to the message format specified for the configured protocol. If the message is valid, it is handed over to the application layer for the monitoring direction.

The application layer for the monitoring direction decodes the user data. All values, flags, and other information, are mapped to the RTU's internal format. (For details on the mapping of message data to the RTU's internal format, refer to the Interface Description for the relevant protocol.)

If the user data is valid and configured as being a part of this SCI, it is forwarded to Internal Communication

Queuing between link layer and application layer is secured to eliminate the loss of messages. The relevant queue sizes are excluded from configuration in RTUtil500.

3.2 Command direction

3.2.1 Data flow

The application layer detects and checks all messages on Internal Communication for control direction, assuming that the messages are configured as being part of this SCI.

(19)

Function Description Release 11 Subdevice communication interface

Command direction The application layer for the control direction encodes the user data. All values, flags, and other information, are mapped to the protocol-specific format. (For details on the mapping of message data to the RTU's internal format, refer to the Interface Description for the relevant protocol.)

The user data is forwarded to the link layer. The link layer adds link information and forwards the data to the subordinate line.

Queuing between link layer and application layer is secured to eliminate the loss of messages. The relevant queue sizes are excluded from configuration in RTUtil500. Some protocols require the application layer for the control direction of the SCI to simulate messages, which are not sent by the subordinate line protocol, and to forward them to Internal Communication to ensure consistency with the RTU's internal sequences.

Process commands and status check instructions (during start up) can be issued simultaneously to all IED connected to a subdevice communication line.

3.2.2 Command output procedures

Commands for objects can be issued either in a one-step procedure (direct operate) or, for requests at a higher security level, in a two-step procedure (select before operate). The two-step procedure significantly lowers the risk of errors in command direction.

Upon reception, any SELECT command is first checked against the RTU's internal information. Check items include whether the object is available and whether no other object is already reserved. If the command successfully passes the check, and if a protocol is available that supports two-step command procedures, the SELECT command received is converted to the protocol-specific

format/procedures, and forwarded to the referring I/O devices (e.g., subordinate RTUs, IEDs). Confirmation of the SELECT command depends on the

acknowledgement by the I/O device. If only one-step command procedures are supported, the SCI acknowledges the reservation with a positive confirmation. The reservation is valid for 20 seconds. Within that time frame, either the corresponding EXECUTE command or a DESELECT command should be

received. If the EXECUTE and the DESELECT command are not received, the SCI cancels the reservation of the object.

If an EXECUTE command is received within the allowed time frame, the RTU checks whether the referring object equals the reserved object. If the objects are identical, the command is executed. If the objects differ, the EXECUTE command is rejected and answered with a negative confirmation. The command procedure is finished after the activation termination for the command in question has been transmitted.

While a command object is selected, no other command objects within the interlocking scope of the selected object may be selected. Other selections will be rejected. If no object is selected, multiple process command objects can be executed in parallel using a direct operate procedure.

The scope of command selection interlocking depends on the configuration of the parameter Process command interlocking mode.

Parameter name Parameter location

(20)

Parameter value Explanation Interlocking per IO device / IO bus and

group

Selection is interlocked against other commands of the same I/O device (e.g. subordinate RTUs, IEDs) and the same command group. Valid command groups are:

 Object Commands Outputs (SCO, DCO)

 Regulation Commands Outputs (RCO)

 Setpoint Commands Outputs (ASO, DSOx)

 Bit-string outputs (BSOxx)

Interlocking per object Selection is interlocked only against the same object

Interlocking per object with command priority

Selection is interlocked only against the same object, but selection can be overridden by a command originating from an originator (e.g., HCI, PLC, Integrated HMI) with higher command priority.

The HCIs with the lowest host numbers have the highest priority, followed by PLCs, Integrated HMIs and web servers of the RTU500 series.

Select and execute commands can override the selection.

Table 2: Output procedures for interlocking

In the event that a process command is rejected because of a selection mismatch or a pending command confirmation, a system event message of the type

SEV#242 .. SEV#260: Process command collision with command of X is sent to the originator of the rejected command. The system event message contains information about the originator sending the command that caused rejection.

3.3 General interrogation

The general interrogation command is automatically executed by the SCI in the following situations:

 During system start-up

 In the event of a redundancy switchover (also to update the process data from subordinate devices if the relevant CMU board is not part of the redundant system)

 When the line state of the subordinate device has changed from offline to online

If the general interrogation command is not supported by the configured protocol, the SCI simulates a general interrogation, e.g., by reading all values or using other procedures, to obtain the actual values of the subordinate devices.

(21)

Function Description Release 11 Subdevice communication interface

Time synchronization

3.4 Time synchronization

Time synchronization of a subordinate device is autonomously managed by the SCI and implemented only if supported by the configured protocol.

Time synchronization needs to be configured once for every sub-line. Only one time synchronization mode can be configured per line.

Time interval of clock synchronization commands

Line parameters

Upon synchronization of the RTU, the SCI reads the RTU's internal time and sends it within a configured time period to all subordinated devices that are in an online state.

CAUTION

If the RTU has no valid time information, no Time synchronization command is sent to any subordinate device.

3.5 System events

The SCI manages and controls system events for each device that is connected to the line.

Several SEVs are controlled by the SCI. They depend on the configuration of the SEV in RTUtil500 and on the type of device, e.g., IED, RTU.

(22)

(23)

4 Substation automation system with IEC 61850

4.1 RTU500 series in an IEC61850 system

As an IEC 61850 client, the RTU500 series provides NCC gateway functionality by connecting an IEC 61850 station bus to NCCs. As an IEC 61850 server, the RTU operates as an IEC 61850 IED, providing data to an IEC 61850 network from subordinate devices or signals that are directly connected. The figure below shows integration of the RTU in an IEC 61850 system.

Station bus IEC 61850-8

Process level Bay level Station level

IEC 60870-5-101 / IEC 60870-5-104 DNP / DNP over LAN/WAN

Network Control level

Network Control Center Diagnosis Integrated HMI Gateway RTU560

IED 1 IED 2 IED 3 _Integrated

HMI

RTU560 server RTU560 client

Figure 5: Integration of RTU500 series in an IEC 61850 system

The standard functions of the RTU500 series, such as local I/Os and connections via legacy protocols, are available in both the client and the server configuration.

4.2 IEC61850 configurations

Using RTUtil500, you can configure an RTU as an IEC 61850 client, an IED or an IEC 61850 server IED. Separate projects are required if different IED types need to be configured.

It is not possible to configure an entire IEC 61850 network with multiple RTU clients or servers in a single project.

(24)

4.2.1 RTU500 series configured as IEC 61850 client

As an IEC 61850 client, the RTU connects NCCs with an IEC 61850 network. Additional local I/Os and connections via legacy protocols are possible. In this configuration, the RTU does not support any GOOSE communication.

For more information, refer to the relevant protocol description.

The following figure shows an RTU500 series that is configured as an IEC 61850 client. IEC61850-8-1 IED IED RTU560 (NCC GW) IEC101 Slave HCI

Local I/O PLC HMI

SCI IED IED e.g. IEC103 IEC103 Master IEC61850 Client NCC connection

Figure 6: RTU500 series configured as a IEC 61850 client

4.2.2 RTU500 series configured as IEC 61850 server

As an IEC 61850 server, the RTU provides data to an IEC 61850 network. Possible data sources are IEDs that are connected via legacy protocols, local I/Os, or PLC applications.

CAUTION

In this configuration the RTU supports horizontal GOOSE communication with other IEC 61850 IEDs as well. The GOOSE data received from the IEC 61850 network could be used only in a PLC application.

(25)

Function Description Release 11 Substation automation system with IEC 61850

IEC61850 configurations

The following figure shows an RTU that is configured as an IEC 61850 server.

IEC61850-8-1 IED IED RTU560 (RTU-IED) IEC61850 Server HCI

Local I/O PLC HMI

SCI IED IED e.g. DNP3 e.g. IEC103 IEC103 Master DNP3 Master GOOSE

Figure 7: RTU500 series as an IEC 61850 server

For a detailed description of the engineering process, refer to the corresponding chapter in the RTUtil500 User's Guide.

(26)

(27)

5 Programmable Logic Control (PLC)

This chapter describes the PLC function, which is the RTU500 series' runtime system for control applications. The PLC function has been designed in accordance with IEC 61131-3. For systems engineering, version 2.11 of the MULTIPROG wt programming and debugging system is used.

5.1 PLC – SCADA processing

The PLC is an integral part of the RTU system and is used to exchange data with SCADA. PLC function RTU560 Config-files . . Boot project file . . PLC OUTPUT memory (Q) PLC INPUT memory (I) PLC internal flag memory SCADA Internal Communication

from / to Network Control Center

from / to I/O hardware from / to sub RTU

from / to MULTIPROG wt

PLC program memory

Figure 8: PLC – SCADA processing in RTU500 series

The figure above shows the basic elements of the PLC in interaction with SCADA. They are described in the following chapters.

5.1.1 PLC function

The PLC function is a licensed software package. It enables a CMU to run PLC applications, and to communicate with MULTIPROG wt for loading and debugging applications. After the function has been added to the configuration, it is started at boot time of the CMU.

Once started on a CMU, the PLC function is running in shared mode with low priority compared to the SCADA software.

It is possible to design a configuration in which PLC function and SCADA activities run on different CMUs. Since both communicate via Internal Communication, the PLC function may run on any CMU within the RTU. This approach provides maximum processing power to each activity.

(28)

5.1.2 PLC INPUT, PLC OUTPUT and internal flag memory

The PLC function has its own memory for any data areas that are allocated at start time. The basic function of a PLC application is to read data from the INPUT (I) memory and to write the calculation results to the OUTPUT (Q) memory. The data is then transferred to SCADA via Internal Communication. For a detailed

description, see chapter I/O interface –- general I/O handling (page 5-3). The internal memory is a memory area (M) that can be used by the PLC application as required.

5.1.3 PLC program memory

The program memory (in RAM) contains the PLC application. The PLC function loads and executes the application from this memory. The application also includes the entire address information required for data exchange with SCADA and

INPUT / OUTPUT memory. The program memory may be loaded by MULTIPROG wt or from the boot project.

At load time of the application, the PLC function checks whether all data points are included in the RTU configuration. If not all data points are included, a system message [13.5.4] ACTIVITY ERROR FOR PLC IN RACK X SLOT Y: START ERROR is generated (see chapter RTU alarms and warnings (page 9-2)).

5.1.4 Retain variable section

A subset of the PLC program data can be stored on the CompactFlash® / SD Card of the RTU. This data will be restored after system start-up.

The retain variables are stored on the CompactFlash® card every 20 seconds, but only if the contents of the variable section have changed. Manual saving of the variable section is also possible by using a special function block within the PLC program. Note that the storage cycle for this operation is limited to 20 seconds.

5.1.5 Boot project file

The boot project file is a file generated by MULTIPROG wt. The file is named bootfile.pro and contains the PLC application. It resides in the nonvolatile flash memory of the CMU. If no boot project is found at boot time, the PLC function starts without an application. If a boot project is found at boot time, it is loaded to PLC program memory, and started (cold start).

5.1.6 PLC application and tasks

A PLC application is generated by MULTIPROG wt as a result of the successful compilation of a project on the PC. The application can then be loaded to program memory (RAM) for testing and debugging, or to FLASH memory as a boot project that is started automatically at boot time of the RTU.

A PLC application is processed on the CMU by one or more tasks, according to the definitions specified in MULTIPROG wt. A task may be defined as a CYCLIC, EVENT, or SYSTEM type. SYSTEM tasks are can be connected to System

Programs (SPGs, see PLC help). The EVENT type is not supported. Tasks of the

CYCLIC type are activated at a specified time interval. Task cycle time is defined by the user in MULTIPROG wt. The minimum cycle time is 10 ms.

The PLC cycle time can be incremented at intervals of 1 ms but is rounded to 10 ms values during each PLC cycle. When calculating the cycle time of a task cycle, make sure to take the RTU's signal configuration and the typical event load into account. The actual PLC cycle time depends on the overall situation within the RTU software. If SCADA and PLC are configured on the same CMU, they share the MPU. SCADA has priority over PLC as it requires more CPU time in the event of a burst of signal events, compared to idle loop. This may stretch PLC cycle time.

(29)

Function Description Release 11 Programmable Logic Control (PLC)

PLC – SCADA processing If the PLC is required to perform a high amount of real-time processing, it is

recommended to run the PLC on a dedicated CMU.

A PLC task can be monitored by a watchdog with a definable timeout. If the time required to process the program is longer than the watchdog time, program execution stops. Using MULTIPROG wt, the PLC application can be programmed to restart after an elapsed watchdog error (SPG 10).

5.1.7 I/O interface –- general I/O handling

The I/O interface of a PLC provides data transfer from SCADA to the PLC and vice versa.

During start-up of a PLC application, each task reads its input signals directly from the SCADA database, which contains the latest data received. In running mode, however, the I/O interface works with an n-stage process image, as described below (also see the following figure).

Internal Communication SCO DCO Message queue Command queue SPI AMI DPI Input handler INPUT memory OUTPUT memory Output handler AND PID OR Application Task(s) DPI Value0 ... TimeTag SCO SE EX ... Value Value1 ... AMI Value OV ... DCO SE ... Value0 Value1 COT BL TimeTag ... COT PLC core Input queues

Figure 9: I/O interface of a PLC

Input process image

The data relevant to the PLC is filtered from Internal Communication, and is written to the corresponding process image for commands, messages, system events or system commands. The maximum number of entries in the process image depends on the data type.

The n-stage process image contains the oldest n-1 changes as received from Internal Communication while the PLC task is being processed, as well as the current value. If more than n-1 changes are received, any changes of information between the n-1 received value in the image and the current value are lost.

Redundancy switchover activities

If a controlled switchover occurs between two redundant CMUs, the active CMU stops the activities and performs an internal restart. The line driver on the communication interfaces will switch to high impedance of the tri-state. The standby CMU will continue the start procedure. From the viewpoint of the RTU560 system, it is a warm start. The now active CMU starts communication on the serial lines and initializes communication to their host and subordinated devices. The I/O boards will not perform a reset. The PDP module takes over communication on the RTU560 peripheral bus and reads all values from the I/O boards.

(30)

The actual state of all CMUs in a (non-)redundant configuration is indicated by SEVs #149 to #164 and #224 to #239:

 SEV (#149 … #164) CMU #x is inoperable, 1 ≤ x ≤ 16

 SEV (#224 … #239) CMU #x is active, 1 ≤ x ≤ 16

A redundant pair of communication units will report the following SEV states:

CMU Normal operation One CMU is faulty

SEV 149 – 164 (inoperable) SEV 224 – 239 (active) SEV 149 – 164 (inoperable) SEV 224 – 239 (active)

Active CMU No Yes No Yes

Standby CMU No No Yes No

Table 3: SEV states

Input handler

At the beginning of each PLC task cycle, the task executes an input handler. The input handler evaluates the data point signals in the input process image that were received in the meantime. Any signals configured for the task are transferred to the INPUT memory of the PLC. If multiple occurrences of a signal are waiting in the queue, the input handler transfers only the first occurrence to the INPUT memory and writes the remaining signals back to the queue for processing in the next PLC task cycle.

For any commands received, the input handler sets the corresponding SE (select) or EX (execute) flag of the PLC data type in the INPUT memory to TRUE. This setting applies to a single task cycle and depends on the Select state of the received command. For details, see the following table:

Received SCADA Select state of

command

PLC EX state PLC SE state

0 TRUE (for one

cycle)

FALSE

1 FALSE TRUE (for one cycle)

Table 4: Select and Execute states for commands in INPUT memory

PLC core

The PLC core processes the PLC application in one or more tasks, reading from the INPUT memory, and writing the calculation results to the OUTPUT memory.

Output handler

At the end of each task cycle, the output handler is executed. It checks if the Send condition is TRUE for each OUTPUT data point. For details, see the following table. If the Send condition is TRUE, the output handler sends the condition to Internal Communication.

Data point type Data point send condition

SPI, DPI, STI, DMIx, BSIx, ITI

The Value flag, or any quality flag, has changed compared to last task cycle.

AMI, MFI Any quality flag has changed compared to last task cycle or the TR (transmit) flag is set.

(31)

Function Description Release 11 Programmable Logic Control (PLC)

PLC – SCADA processing

Data point type Data point send condition

SCO, DCO, RCO, ASO, BSOx, DSOx, FSO

The SE (select) or EX (execute) flag has a status change compared to the last task cycle and COT (cause of transmission) is not zero.

SSC The EX (execute) flag has a status change compared to the last task cycle and COT (cause of transmission) is not zero.

Table 5: Data point Send conditions for the PLC output handler

Signal processing

This chapter describes the possible signal flow between a network control center (NCC), the PLC, and the I/O processing or subordinate RTU.

Messages and commands

Process data points that can be connected via hardware can be defined from the I/O hardware or sub RTU (both are referred to as I/O device hereafter) using a PLC function.

This function also allows the definition of virtual process data points. Virtual process data points are handled by a network control center (NCC) in the same way as process data points but are not processed by the I/O device.

Network Control Center (NCC)

I/O Processing or Sub RTU

PLC

PLC used command PLC used message Virtual message Virtual command Normal command Normal message Confirm.

Figure 10: Signal flow between NCC, PLC, and I/O device

The figure above shows, in principle, the logical signal flow of messages and commands between NCC and I/O device.

The following signal types are supported by the PLC:

 Virtual message

Adding a virtual message to a PLC task in the configuration enables the PLC to send a message to the NCC. This message cannot be sent by the I/O device. Virtual messages are represented in the OUTPUT memory of the PLC.

 Virtual command

Adding a virtual command to a PLC task in the configuration enables the PLC to receive this command from the NCC and return the confirmations. As the command is invisible to the I/O device, the I/O device is unable to

execute it. Virtual commands for activation or deactivation are represented in the INPUT memory. Virtual commands for confirmations are represented in the OUTPUT memory.

(32)

 Message used by PLC

Messages are part of the regular signal flow between I/O device and NCC. Selecting a message data point for use by the PLC in the configuration enables the PLC to receive this message. Messages used by the PLC are represented in the INPUT memory of the PLC.

 Command used by PLC

Commands are part of the regular signal flow between I/O device and NCC. Selecting a command data point for use by the PLC in the configuration enables the PLC to send and receive the command and the confirmations. Commands for activation or deactivation used by the PLC are represented in the OUTPUT memory. Commands for confirmations used by the PLC are represented in the INPUT memory.

In order for the PLC to receive data from or send data to data points, PLC-specific information needs to be configured for the data points.

System event processing

System events (SEVs) are received by the PLC. SEVs of sub-RTUs are not supported. Selecting a SEV for use by the PLC in the configuration enables the PLC to receive the system event (similar to messages from the I/O device).

System command processing

System Single Commands (SSCs) can be received and sent by the PLC. Selecting an SSC for use by the PLC enables the PLC to handle the SSC in the same manner as commands used by the PLC.

System event messages

There are two SEVs available for signaling the state of active PLC tasks:

 System Event #046: At least one PLC function not running

 System Event #047: At least one PLC cycle time exceeded

Characteristic technical data

Property Value

1000 Boolean instruction lines approx. 10 ms 1000 BOOL8 and INT instruction lines approx. 10 ms Shortest task cycle period configurable 10 ms

Memory capacity (program/data) absolute

≤ 8 MB configurable

Program memory consumption approx. 10 kB per 1 000 instructions Program memory capacity per POU 64 kB

I/O image capacity configurable max. 2 000 INPUT and 2 000 OUTPUT signals

Maximum number of user tasks 15 Table 6: Characteristic technical data

(33)

6 Redundancy

6.1 Overview

Being able to access stations in energy transmission and distribution networks at all times is a fundamental requirement of network operators. RTU560 manages this requirement by providing a sophisticated redundancy concept that includes the following features:

 Redundant power supply (only RTU560)

 Redundant communication lines, or links

 Redundant communication units (CMU) (only RTU560)

With this concept, RTU560 fulfills the highest availability requirements.

6.2 RTU560 redundant CMU concept

As a key component of the redundancy concept, one or more pairs of CMU boards exist for communication lines and functions that are critical to the operation of the station. In the event of an error condition, the RTU560 initiates a switchover to the standby CMU. The standby CMU performs a warm start and subsequently takes over the tasks from the faulty CMU.

One pair of CMUs in an RTU560 configuration can be defined as a redundant communication set. In the event of an error of an active CMU, the system initiates a switchover to the redundant standby CMU. The standby CMU performs a cold start and subsequently takes over processing from the faulty CMU. Other redundant sets of CMUs in the configuration will not be affected in their operation.

There are three redundancy types of RTU560 CMU modules:

 The active CMU, which is the active (i.e., running) device

 The standby CMU, which monitors the active CMU and is prepared to take over as an active device

 The non-redundant CMU, which operates continuously

Supervising the state of the RTU560 in such a scenario requires the standby CMU and the active CMU to monitor each other, in order to be able to take over the state of a failed CMU if necessary. For instance, a standby CMU in a failed state is not allowed to switch over; the active CMU must inform the host about the failure in the standby CMU. On the other hand, the standby CMU must detect a silent failure of the active CMU (without any alarm or warning message) and take over the active state.

(34)

Figure 11: RTU560 configuration with redundant CMU modules The above picture shows an example of a redundant RTU560. The redundant CMUs A and B may have the following configuration:

 NCC1 and NCC2 communicate via a serial line protocol (e.g. DNP 3.0).

 The I/O modules are organized in two PDP groups and connected to the CMU 1 of each group.

 Some IEDs (e.g., the protection relays for the main transformers) are of high importance, and are therefore connected to the redundant CMUs A2 and B1.

The non-redundant CMUs may have the following tasks:

 A third NCC

 PLC

 Process event / Disturbance file / Load profile archive

(35)

Function Description Release 11 Redundancy

RTU560 redundant CMU concept

6.2.1 Master and slave concept

For time administration within the RTU560, a time master needs to be defined using RTUtil500. All other configured CMU modules are defined as slave CMUs. The time master is responsible for time administration of the entire system, and for synchronizing all slave CMUs.

In addition, a system administration master is automatically defined for every RTU560 system. The system administration master supervises the entire system. During start-up, the communication boards select the active communication board with the lowest rack address and slot address as the system administration master. The time master can also be configured with redundant CMU modules. In the event of a failure, the system will then automatically switch over to the second CMU, which is defined as a secondary master.

6.2.2 Redundancy switchover

A redundancy switchover will be triggered if system errors are detected on one of the active CMUs or on a PLC program using a single system command.

A redundancy switchover will not be triggered by the following:

 Failure of a communication link to a master system or subsystem

 Firmware or configuration errors

 PLC alarm condition initiated by a PLC program

A redundancy switchover can also be forced by the connected NCCs using the System Single Commands (SSC):

 SSC (#016 … #031) Switch-over to CMU #x, 1 ≤ x ≤ 16

6.2.3 Impact on RTU functions

Process data processing

The Process Data Processing (PDP) module takes over communication on the RTU560 peripheral bus and reads all values from the I/O boards.

(36)

PLC functions

PLC functions configured on a redundant CMU board

In the event of a redundancy switchover, the PLC program on the new active CMU waits for a complete refresh of the I/O data for the Process Data Base (PDB) of the PLC module. Upon successful refresh, a cold start of the PLC application is

performed.

CAUTION

The *.pro PLC configuration file has to be loaded to both redundant boards. It will not be distributed automatically.

After a restart of a PLC program timers and storage, functions are started with their initial values.

PLC Function configured on a non-redundant CMU board

This PLC program is not stopped because of a redundancy switchover. During switchover, the PLC will continue to run using the latest actual values available. The PLC program is thus able to read the status of the system, allowing it to define its actions during the switchover period. Upon completion of the start-up of new active CMU, all data points originating from a redundant CMU are updated. The PLC then continues in normal operation. It is possible to combine redundant PLC tasks and non-redundant PLC tasks in a single RTU560 system.

Logic function

The Logic function can only be configured on one CMU of an RTU560 and supports CMU redundancy. In the event of a redundancy switchover, all derived process information is recomputed during the switchover process.

Archive and Local Print, integrated HMI

The Disturbance Data Archive, the Load Profile Archive, and the Local Print function have to run on non-redundant CMUs.

CAUTION

If process archives are used on a redundant system, data loss can occur. In the event of a switchover, the process archive is NOT synchronized. Archive recording is suspended during switchover.

(37)

Time administration

It is possible to connect the real-time-clocks 560RTC01, 560RTC02, or 560RTC03 to a redundant pair of CMUs.

When using real-time-clocks in a CMU redundancy scenario, make sure to connect the Serial Peripheral Bus (SPB) to both the active CMU and the standby CMU. The SPB takes care of reading the time information.

Simple Network Management Protocol (SNMP)

Basic concepts

The Simple Network Management Protocol is a UDP-based network protocol. It is used in network management systems to monitor network-attached devices for conditions that warrant administrative attention.

In a typical SNMP usage scenario, an administrative computer, called "manager" or "client", has the task of monitoring a group of devices on a computer network. Each managed system continuously runs a software component, called an "agent", which acts as server and reports information via SNMP to the manager.

Essentially, an SNMP server represents monitor data as variables. The variables accessible via SNMP are organized in hierarchies. These hierarchies and other metadata, e.g., type and description of the variable, are described by Management Information Bases (MIBs). For detailed information about SNMP and MIB, refer to

[4] and [5].

In the RTU560, SNMP is used to monitor network devices (or elements) connected to the RTU560. That means that RTU560 acts as manager (client), and requests information from connected SNMP servers.

CAUTION

The RTU560 does not support SNMP as server. No SNMP agent can be run on an RTU560. It is therefore not possible to monitor or manage an RTU560 via SNMP.

CAUTION

RTU560 supports only version 1 of the SNMP protocol. Network elements to be monitored by RTU560 must answer requests in SNMPv1 format.

The monitoring of connected network elements serves to determine whether the elements are operable. For this purpose, the RTU560 requests standard variables via SNMP. The requested variables pertain to the system group that is mandatory for all managed systems.

(38)

In detail, the following SNMP variables are requested:

 iso/org/dod/internet/mgmt/mib/system/sysObjectID (1,3,6,1,2,1,1,2) The vendor's authoritative identification of the network element. Static identification in form of a SNMP object identifier.

 iso/org/dod/internet/mgmt/mib/system/sysUpTime (1,3,6,1,2,1,1,3) The time (in hundredths of a second) since the network element was last re-initialized. While network element is running and operable, the time tick returned must increase.

These variables are requested every 30 seconds from each configured network element. The results of the requests, representing the state of the network element, are combined in a system event. The network element numbers are mapped to the corresponding system events SEV#192 to #223.

A network element and the corresponding system event are operable when the all of the following conditions apply:

 The network element answers to both requests.

 The returned variables are in the correct format.

 The value of the sysUpTime variable changed from one request to another. For monitoring via SNMP, the RTU560 supports non-redundant and redundant configurations.

Non-redundant CMU configuration

The following figure shows a non-redundant CMU configuration:

Figure 12: Non-redundant SNMP monitoring configuration

RTU560 provides SNMP-based monitoring of network elements for one element per Ethernet interface, i.e., each SNMP manager monitors a single network element.

(39)

Redundant CMU configuration

The following figure shows a redundant CMU configuration:

Figure 13: Redundant SNMP monitoring configuration

The redundant configuration follows the concept described in the previous chapter. A pair of CMUs is defined as a redundant communication set. In the event of an error of an active CMU, the system will switch over to the redundant standby CMU, which will continue processing after performing a cold start. In this redundancy concept, SNMP monitoring can be used to perform a switchover in the event that the network element connected to the active CMU should fail.

In redundant configurations, one network element is connected to the active CMU and another network element is connected to the standby CMU. The active CMU and the standby CMU are assigned the same IP address but only one CMU is online at a time. The connected network elements, on the other hand, have different IP addresses because both are online at any time.

Both network elements are configured in the SNMP Network Element Supervision parameter of the active CMU. The parameters for the main system refer to the network element connected to the active CMU. The parameters for the standby system refer to the network element connected to the standby CMU.

(40)

SNMP configuration (RTUtil500)

In RTU560, the parameters for SNMP monitoring are part of the Ethernet interface configuration. For each Ethernet interface in a RTU560, a single SNMP manager can be configured to monitor a device connected to that interface.

SNMP Network Element Supervision Ethernet Interface parameters

CAUTION

The maximum number of SNMP managers per RTU is 32.

For each Ethernet interface, a single SNMP manager can be configured. Consequently, two SNMP manager can be configured on a CMU with two Ethernet interfaces.

CAUTION

Each SNMP manager can supervise one connected network element.

If more elements shall be supervised in the same network, several CMUs or a CMU with two Ethernet interfaces must be used.

Each SNMP manager must have a unique number. Possible numbers are 1 .. 32. The configured number defines the system event that represents the supervision state of the network element.

SNMP Network Element Number Ethernet Interface parameters

The system event representing the monitoring state can have one of the following values:

 Operable

 Not operable

The configuration specific to the network element configuration is performed in the

SNMP Network Element Supervision parameter.

Configuration of this parameter depends on the CMU configuration type (non-redundant vs. redundant).

For non-redundant configurations, only the parameters for the network element main system are relevant. In these configurations the parameters for the standby system are not taken into account.

For each network element, a name can be defined in the configuration. This name is used for documentation purposes.

(41)

Network element name SNMP Network Element Supervision The IP address of the network element is configured in the SNMP Network

Element Supervision parameter.

Network element IP address SNMP Network Element Supervision

CAUTION

All configured network elements must be visible to the Ethernet interface that connects to the network.

Consequently, the IP address and subnet mask of the Ethernet interface must be set in accordance with the rules for TCP/IP networking.

In redundant configurations, a name and an IP address is configured for each network element. In redundant configurations, an automatic switchover in the event of a breakdown can be set as an additional parameter. In this setup, monitoring of the network element is used for switching over from the active CMU to the standby CMU in the event that the element connected to the active CMU becomes

inoperable.

Switch over in case of breakdown SNMP Network Element Supervision

CAUTION

If both network elements in a redundant configuration become inoperable, the system acts as follows:

If the first network element becomes inoperable, a single switchover is performed (from active CMU to stand-by CMU).

If the second element becomes inoperable, the system remains in its current state. No switchback takes place.

(42)

6.2.4 RTUtil500 configuration

Configuration of the master and slave board in a redundant CMU configuration is performed in the RTUtil500 engineering tool.

RTUtil500 identifies two configuration aspects:

 Time administration mode

 Initial redundancy mode

Time administration mode defines a redundant, or non-redundant, CMU as the

time master. The time master is responsible for time administration of the entire system. In order to serve as a time master, a real time clock (560RTC01, 560RTC02, or 560RTC03) needs to be connected to the relevant CMU.

Initial redundancy mode defines the default redundancy configuration of a CMU

after successful start-up of a system that operates properly. The following values are available for Initial redundancy mode:

 Active

 Standby

(43)

Figure 15: Redundant CMU configuration in RTUtil500

6.2.5 RTU500 series redundant communication

NCCs and IEDs can have redundant communication lines to the RTU. The availability of redundant lines depends on the used protocol type.

Redundant Host Communication Interfaces

Redundant communication lines to NCCs are available for the following protocols:

 IEC 60870-5-101  IEC 60870-5-104  RP570/71  Conitel 300  DNP3  DNP3 LAN/WAN

Redundant Subdevice Communication Interface

Redundant subdevice communication lines are available for the following protocols:

 IEC 60870-5-101

 IEC 60870-5-104

 Conitel 300

 Modbus

 Modbus TCP/IP

The functionality of redundant subdevice communication lines is handled by SSCs and monitored by SEVs.- For more information, refer to the corresponding sections of this document.

(44)

Modem pools for Subdevice Communication Interfaces

Dial-up modems can be connected to the serial, or Ethernet, communication interface of a CMU.

Multiple devices can be connected to one or several modems. Redundant communication lines to subordinate devices can also be configured. The pool of modems connected to the system is managed by RTU560.

The Modem Pool function is controlled by means of SSCs. Generation of the SSCs is based on commands from the NCCs. For more information, refer to the relevant sections in this document.

(45)

7 Start-up, Configuration and Time Management

7.1 Start-up procedures

The RTU500 series supports two start-up types:

 Single CMU start-up

 Multiple CMU start-up

Only the RTU560 supports multiple CMU start-ups. The single CMU start-up is a special case of the multiple CMU start-up.

An RTU560 series system may contain several CMUs, e.g., 560CMU02 R0002, 560CMU05. Activities, such as communication protocols, I/O bus interfaces or PLC functions, may be configured as required to be running on different CMUs.

RTU500 series supports the following start-up procedures:

 RTU System Start

Power ON or reset of the RTU system is common to all RTUs of the RTU500 series

 RTU560 CMU Start

Power ON or reset of a CMU of an RTU560 system

 RTU560 CMU Integration

Hot-plugging of a CMU into a running RTU560 (only in RTU560 systems with multiple CMUs)

 RTU Protocol Restart

Communication protocols often provide specific methods to restart the RTU. The RTU may support various protocols. For information on the available restart methods, refer to the relevant protocol description.

7.1.1 RTU System Start

System start of a RTU500 series (Power ON or reset of the RTU) is managed by System Control, which is running on the master CMU. The system start sequence is as follows:

 After CMU start (see chapter RTU560 CMU start (page Fehler!

Verweisquelle konnte nicht gefunden werden.)), System Control requests

the configured boards and waits 5 s for their registration (only for RTU560).

 RTU System Control starts the configured activities on the registered CMUs in the following order:

 Archive and Print functions

 Host Communication Interfaces (slave protocols, no communication)

 Subdevice Communication Interfaces (master protocols)

 I/O bus interfaces (PDP)

 PLC and local function tasks

 Subdevice interfaces and I/O bus request data from subdevices and I/O boards. System Control waits until they report their databases to be up to date.