RTU560 As IEC 61850 Gateways PDF

RTU500 series Remote Terminal Unit
Function Description Release 11

Part 6: RTU500 Functions
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
Chapter “Time management” updated
ABB AG 1KGT 150 798 V002 1

Contents
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
ABB AG 1KGT 150 798 V002 1 I

Contents Function Description Release 11
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
II 1KGT 150 798 V002 1 ABB AG

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
ABB AG 1KGT 150 798 V002 1 III

Contents Function Description Release 11
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
IV 1KGT 150 798 V002 1 ABB AG

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
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
ABB AG 1KGT 150 798 V002 1 V

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 Description of the RTU500
Solutions series DIN rail solutions
1KGT 150 796 Part 4: Hardware Overview of the RTU500
Modules series rack and DIN rail
modules
1KGT 150 797 Part 5: SCADA Description of the RTU500
Functions series SCADA functions
1KGT 150 798 Part 6: RTU500 Description of the RTU500
Functions series functions
1KGT 150 799 Part 7: Archive Description of the RTU500
Functions 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 Description of the RTU500
Networks 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
 System Data Interface
ABB AG 1KGT 150 798 V002 1 1-1

Introduction Function Description Release 11
References
1.3 References
[1] 1KGT 150 801 RTUtil500 Users Describes the usage of engineering
Guide tool RTUtil500 of the RTU500 series
Release 11
[2] Individual Ident RTU500 series Description of the Sub and Host
Protocol Communication Protocols
Descriptions
[3] 1KGT 150 853 Interfaces and Description of the relationship of
Protocols interfaces and protocols
Release 11
[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
1-2 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 2-1

Host communication interface Function Description Release 11
Monitoring direction
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:
 SEV (101 ... 116): Host number x online, 1 ≤ x ≤ 16
2-2 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 2-3

Host communication interface Function Description Release 11
Overview of the software structure
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
NCC
Host Communication
Interfaces (HCI)
Link Layer
Application Layer Application Layer

Monitoring Direction Command Direction
Interface to
Internal
Communication
Internal Communication (IC)
Figure 2: Interface to IC – Application layer – Link layer
2-4 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 3-1

Subdevice communication interface Function Description Release 11
Data flow in monitoring direction
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 to
Interface (SCI) Internal
Communication
Application Layer Application Layer

Monitoring Direction Command Direction
Link Layer
Sub-Device
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
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.
3-2 1KGT 150 798 V002 1 ABB AG

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
Process command interlocking mode RTU parameter
ABB AG 1KGT 150 798 V002 1 3-3

Subdevice communication interface Function Description Release 11
General interrogation
Parameter value Explanation

Interlocking per IO device / IO bus and Selection is interlocked against other
group 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 Selection is interlocked only against the
priority 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.
3-4 1KGT 150 798 V002 1 ABB AG

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 Line parameters

commands
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.
For more details, see chapter System events (page 10-1).
ABB AG 1KGT 150 798 V002 1 3-5

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.
Network Control
Center
Diagnosis
Network Control level
IEC 60870-5-101 / IEC 60870-5-104

DNP / DNP over LAN/WAN
Station level
Gateway
RTU560
RTU560 client
Integrated
HMI
Station bus IEC 61850-8
Bay level IED 1 IED 2 IED 3 RTU560 Integrated

server HMI
Process level
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.
The following chapters show examples of RTU client and server configurations.
ABB AG 1KGT 150 798 V002 1 4-1

Substation automation system with IEC 61850 Function Description Release 11
IEC61850 configurations
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.
NCC
connection
RTU560 IEC101
Slave
(NCC GW)
SCI HCI
IEC61850 IEC103
Local I/O PLC HMI
Client Master
IEC61850-8-1
e.g.
IEC103
IED IED IED IED
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.
4-2 1KGT 150 798 V002 1 ABB AG

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
RTU560 IEC61850
Server
(RTU-IED)
GOOSE
SCI HCI
DNP3 IEC103
Local I/O PLC HMI
Master Master
e.g. e.g.
DNP3 IEC103
IED IED IED IED
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.
ABB AG 1KGT 150 798 V002 1 4-3

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.
from / to Network Control Center from / to MULTIPROG wt
Internal
Communication
Boot
PLC project
PLC
INPUT file
program
memory .
memory
(I) .
PLC
SCADA function
PLC PLC
OUTPUT internal
memory flag
(Q) RTU560 memory
Config-
files
.
.
from / to I/O hardware

from / to sub RTU
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.
ABB AG 1KGT 150 798 V002 1 5-1

Programmable Logic Control (PLC) Function Description Release 11
PLC – SCADA processing
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.
5-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 Programmable Logic Control (PLC)
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).
Input queues
Command Message
queue queue
PLC core
INPUT OUTPUT
DPI memory memory
SCO SPI
DPI Value0 Application AMI Value
DCO AMI
Value1 Task(s) OV
... BL
TimeTag AND ...
Input SCO SE TimeTag Output
PID
handler EX OR DCO SE handler
... ...
Value Value0
COT Value1
... COT
...
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.
ABB AG 1KGT 150 798 V002 1 5-3

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 – SEV 224 – SEV 149 – SEV 224 –
164 239 (active) 164 239 (active)
(inoperable) (inoperable)
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 PLC EX state PLC SE state

Select state of
command
0 TRUE (for one FALSE
cycle)
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, The Value flag, or any quality flag, has changed
BSIx, ITI compared to last task cycle.
AMI, MFI Any quality flag has changed compared to last task
cycle or the TR (transmit) flag is set.
5-4 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 Programmable Logic Control (PLC)
Data point type Data point send condition

SCO, DCO, RCO, ASO, The SE (select) or EX (execute) flag has a status
BSOx, DSOx, FSO 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)
Virtual Virtual
Confirm. command message
Normal
command
PLC Normal
message
PLC used PLC used

command message
I/O Processing or Sub RTU

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.
ABB AG 1KGT 150 798 V002 1 5-5

 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) ≤ 8 MB configurable
absolute
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
5-6 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 6-1

Redundancy Function Description Release 11
RTU560 redundant CMU concept
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
 IEDs (e.g. additional protection relays)
6-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 Redundancy
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.
The counter values (ITI) are transferred during the following cycle.
ABB AG 1KGT 150 798 V002 1 6-3

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.
6-4 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 6-5

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.
6-6 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 6-7

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.
6-8 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 6-9

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
Figure 14: Time administration mode and Initial redundancy mode
6-10 1KGT 150 798 V002 1 ABB AG

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.
ABB AG 1KGT 150 798 V002 1 6-11

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.
 SSC ( #3 … #11 ): System Single Commands
6-12 1KGT 150 798 V002 1 ABB AG

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.
 The configured host interface(s) start(s) communication with the NCC.
ABB AG 1KGT 150 798 V002 1 7-1

Start-up, Configuration and Time Management Function Description Release 11
Start-up procedures
 System monitoring is started to enable removal and insertion of CMUs (only

for RTU560).
7.1.2 RTU560 CMU start

When a CMU is started after Power ON or a reset command by an NCC or web
server of an RTU560, the CMU performs the following start-up sequence:
 Initialize and test hardware (RAM, FLASH, watchdog, etc.), load firmware
from flash memory
 Send the following system message: “CMU x: Starting up …”
 If a CMU starting to participate at the system bus, the SEV “CMU x:
operable” is send.
 Check if other CMUs are present in the RTU for 5 s. If other CMUs are
present in the RTU for 5 s, the CMU compares its own firmware and
configuration to that of all CMUs present in RTU in the following manner:
 The major release version number of the firmware (e.g.: 11 for a Version
11.1.1.0) must be the same on every CMU. If the version number of the
firmware release is not the same on every CMU, the CMU stops further
initialization and sends the following system message: “CMU x:
(Firmware x.x.x.x) Firmware version incompatibility in system”. It then
waits for a new firmware to be loaded, and a reset to be performed.
 The .rcd configuration (RTU Configuration Data) must be present and
identical on every CMU. If the .rcd configuration is not present and
identical on every CMU, the CMU stops further initialization, sends the
following system message: “CMU x: Configuration file not consistent in
starting system. Local file created at yyyy-mm-dd hh:mm.ss". It then waits
for a new .rcd configuration to be loaded, and a reset to be performed.
 Check if the configuration is formally valid (correct CMU type, correct rack
and slot address). If the configuration is not formally valid, the CMU stops
further initialization, sends the following system message: CONFIG-ERROR
ON CMU #X: WRONG RACK OR SLOT ADDRESS.It then waits for a new
.rcd configuration to be loaded and/or replacement to be performed.
 Start activities as called by System Control. If the start of an activity fails, the
CMU sends the following system message: <ACTIVITY TYPE> CMU x:
<ACTIVITY STATE><ACTIVITY-ERROR TYPE>. For more information,
refer to the table System message text.
 If all activities have been started successfully and the CMU is in system
administration mode active or non-redundant, the SEV “CMU x: active” is
send by the CMU.
7.1.3 RTU560 CMU integration

In a system with multiple CMUs, a single CMU may be integrated into a running
RTU560. During the integration process, any activities currently running on the
RTU continue their operation.
To be able to integrate a CMU into a running RTU560, the following condition must
be fulfilled:
 The CMU must be configured in the RTU560.
During integration, a CMU runs a similar start-up sequence to the one described in
the section RTU560 CMU start (page Fehler! Verweisquelle konnte nicht
gefunden werden.), with the following exceptions:
7-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 Start-up, Configuration and Time Management
Start-up procedures
 If any of the configuration elements (.rcd or password) is missing or differs

from the files on the other CMUs, the integrating CMU tries to load the
missing configuration from a running CMU. The integrating CMU then
automatically resets in order to perform a CMU start with the new
configuration.
 During integration of a CMU into a running system, the board databases are
synchronized to ensure, that the integrated CMU has the same information
as the already running CMUs.
 Upon completion of the integration process, the host interfaces on the
integrating board (if present) start communication with the NCC.
If a formerly active CMU of a redundant pair is reintegrated into the system (e.g.,
after maintenance or repair), it becomes the stand-by CMU of the redundant pair.
The integration of a CMU is signaled by SEVs in the following way:
 Non-redundant CMU:
SEV “CMU x Inoperable” = 'FALSE', SEV “CMU x active” = 'TRUE'
 Redundant CMU:
SEV “CMU x Inoperable” = 'FALSE', SEV “CMU x active” = 'TRUE'
7.1.4 RTU560 CMU removal

A CMU may be removed from a running RTU560. Any activities running on other
CMUs continue their operation.
CAUTION
If a CMU running I/O buses or subdevice communication interfaces is removed, a

trigger is sent to the remaining boards in the RTU560 to flag the related process
data in their respective databases as being invalid.
The removal of a CMU is signaled by SEVs in the following way:

 SEV 'CMU x Inoperable' = 'TRUE'
 SEV 'CMU x Active' = 'FALSE'
If the active CMU of a redundant pair is removed, the system performs a restart of
the standby CMU. After a successful restart, the standby CMU becomes the active
CMU. The state of the new active CMU is signaled by SEVs in the following way:
 SEV 'CMU x Inoperable' = 'FALSE'
 SEV 'CMU x Active' = 'TRUE'
ABB AG 1KGT 150 798 V002 1 7-3

RTU500 series configuration
7.2 RTU500 series configuration

7.2.1 General requirements
The RTU needs valid configuration for operation. An RTU with multiple CMUs must
keep equal configurations in each CMU.
The RTU configuration data (RCD) file contains hardware, protocol and process
data point information.
The password configuration has a default setting in a new RTU and may be
changed via the web server.
The RCD configuration is provided by means of a binary files with .rcd suffix. The
files are stored non-volatile in FLASH memory and are copied into RAM at CMU
boot for read-only access.
The files are generated with the configuration tool RTUtil500 by command (See
RTUtil500 User's Guide, chapter Generate RTU-Files). The configuration files may
be loaded to the RTU via the web server of the RTU500 series or via NCC using a
file transfer service of the communication protocol.
Configuration file load procedure

Configuration files are loaded separately for each CMU type. During and after
loading of a configuration file, the RTU continues normal operation with its current
configuration, which is stored in RAM. The new configuration is stored in flash
memory and becomes active only after the next start of the CMU.
Load configuration files via the web server of the RTU500 series
The web server of the RTU500 series enables a user to load configuration files into
the flash memory file system of a particular CMU by providing its address. The
CMU in question then distributes the files to all CMUs in the RTU, regardless of
their configuration status.
The user is informed about the success of the file load procedure, and the number
of boards that received the file. The new configuration can then be activated by
sending a reset command to the RTU, if desired.
Load configuration files via NCC file transfer

Configuration file load via NCC is handled together with the host interface running
a specific communication protocol. For information on the relating file transfer
service, refer to the relevant protocol description. The distribution process after file
load is the same as described in the section Load configuration files via the web
server of the RTU500 series (page 7-4).
7-4 1KGT 150 798 V002 1 ABB AG

RTU500 series Time Management
7.3 RTU500 series Time Management

7.3.1 Time management principle
RTU500 series is managing a distributed system time driven by a common
regulated clock. This clock is provided by a CMU dynamically chosen during
runtime based on availability and priority.
The time management supports continuous time, in case of time administration
master failure or switch over.
7.3.2 Time administration
At startup of an RTU system, the CMUs synchronizes each other with the newest
time that is known by any starting or running CMU in the system. This time is used
as starting time of the RTU system time until synchronized by a configured time
master.
If no CMU was ever synchronized, the absolute time starts with the following value:
Year Month Day Hour Minute Second

1980 01 01 00 00 00
Table 7: Absolute time
Every CMU in an RTU system is able to take over the role of a time administration
master independent of their rack place, CMU type or redundancy mode.
During startup of an RTU system, one CMU is selected as administration master
controlling the system. This CMU is also working as time administration master,
whereas all other CMUs are time administration slaves.
If another CMU is getting the administration master, it is also getting the time
administration master.
Only one CMU in an RTU system is time administration master.
Time Time Time

Master Slave Slave
Logic Logic Logic
Time Time Time

Message Message Message
10 kHz
TSO
TSI
RTU560 Internal Communication
Figure 16: Time administration master and time administration slave

dependencies
ABB AG 1KGT 150 798 V002 1 7-5

The CMU acting as time administration master synchronizes the RTU time
according to the time master configuration provided. The CMU acting as time
administration master maintains the time information for the entire RTU. It
generates a controlled 10 kHz clock signal and the internal TSO minute pulse.
These signals are needed by all time administration slaves and the I/O master. It
then distributes the absolute time information as time message telegrams to time
administration slaves and I/O masters.
The time administration slave CMUs are hard-linked to the 10 kHz clock signal and
the TSO minute pulse generated by the time administration master CMU. Its own
time base is supplied by this 10 kHz signal. Synchronization is based on the TSO
minute pulse. Absolute time is provided as time message by the time administration
master via RTU System bus to synchronize the time administrations slave´s time
accordingly.
Figure 17: Time synchronization in RTU500 series

Deviations between the internal time and the received time on the time
administration master are regulated by scaling pre-divider registers. This method
allows a soft regulation of time differences and a long-time correction of crystal
clock errors.
If the computed deviation between internal time and the received time is too large,
RTU system time is hard synchronized and regulation is restarted.
The regulation works independent from the active time master. That means even in
case of a time master switch over the clock is regulated, if the deviation is not too
large.
The I/O master (IOM) on every CMU is hard-linked to the 10 kHz clock signal and the
TSO minute pulse generated by the time master. It cyclically receives a time message
by the MPU via the DPRAM interface and synchronizes its time accordingly.
The IOM again transmits a time synchronization instruction (broadcast) cyclically to all
I/O controllers (IOCs) on the I/O boards via the I/O bus (typically every 2 seconds). The
IOCs independently regulate deviations between their internal current time and the
cyclic time synchronization instructions. Time of all I/O boards is synchronized via the
I/O bus with a resolution of ±100 µs and an accuracy of ±0.3 ms.
7-6 1KGT 150 798 V002 1 ABB AG

7.3.3 Time sources and time masters

The RTU provides a system time that may be synchronized by the following time
sources:
 Time synchronization by NCC
Time synchronization through a (cyclic) time message from NCC (see
section Synchronization by NCC (page Fehler! Verweisquelle konnte nicht
gefunden werden.))
 Time synchronization by NCC with external minute pulse
Time Synchronization through a cyclic message via a host communication
interface and an external minute pulse wired to the TSI (Time
Synchronization Input) of the RTU (see section Synchronization by NCC with
external minute pulse (page 7))
 (S)NTP server
Synchronization with an (S)NTP server over the network (see section
Synchronization via SNTP)
 Radio clock
Synchronization according to the GPS, IRIG-B, or DCF 77 standard (only
Central Europe) (see section Synchronization via radio clock (page Fehler!
Verweisquelle konnte nicht gefunden werden.))
 User entered time via webserver
Time can be entered via RTU web server to set the RTU system time once.
This method is not be configurable and overwrites the priority of configured
time masters.
NOTE:
This method is very inaccurate and may only be used for commissioning and
setup purposes.
These time sources can be configured to be used by up to eight time masters
according to their configured priority. (see section Redundant Time
Synchronization (page Fehler! Verweisquelle konnte nicht gefunden werden.)).
Time masters can be assigned to any CMU in a RTU independent from time
administration master.
During start-up, the RTU determines the time masters and their priority by reading
the RCD configuration.
Time administration RTU parameters
7.3.4 R
RTU System time qualifiers and signalization
The RTU system time contains two qualifiers maintained by the time administration
master:
 NSY: Not synchronized
RTU system time was never synchronized.
 TIV: Time invalid
RTU system time was not re-synchronized within a configurable time.
TIV is set at start-up of RTU500 and will be reset, if the RTU system is
synchronized by the available configured time master with the higher priority.
It will be reset, if:
ABB AG 1KGT 150 798 V002 1 7-7

 RTU system time is not synchronized by a configured time master within a

configurable ‘time synchronization lost’ time (default 5 min).
If time is disabled by configuration, a once valid RTU system time will never
get invalid again.
 The TSO minute pulse is missing for 10 min.
An invalid RTU system time is signalized by sending a negative SEV [25] "RTU IS
NOT SYNCHRONIZED". The RTU then runs with the accuracy of its own crystal
clock. The RTU system time is still used in process messages, but marked as
invalid depending on the used NCC protocol.
A valid RTU system time is signalized by sending a positive SEV [25] "RTU
SYNCHRONIZED".
Time synchronization lost RTU parameters
NSY signalizes that the RTU system time was not yet synchronized and no time at
all is available, even if it is inaccurate.
It is set to value ‘not synchronized’ at start-up of an RTU system in the following
situation:
 Cold start of RTU560 complete system
 Cold start of RTU540 CMU
 Cold start of RTU520 CMU without battery buffered clock.
If a RTU system time is available after RTU system warm start or from battery
buffered clock, NSY is reset at start-up.
It is reset as soon as the first time, time synchronization from a time master is
received. It will now never be set any more during runtime of a RTU.
As soon as RTU system time is marked as synchronized with reset NSY,
functionalities relying on absolute time start processing, e.g. file archive, dial-up
functionality, etc. SCIs starts now also to synchronize subordinated devices, as
well as SNTP servers configured in RTU500 are responding time requests or send
broadcast time messages.
Additional information about failures is added to system diagnosis log.
7.3.5 Time zone and daylight saving
The RTU system time is derived from an internal time base in Universal Time
Coordinated (UTC). UTC is an atomic realization of Greenwich Mean Time, the
astronomical basis for civil time. To convert UTC time into local time, the RTU
needs information about the time zone and the daylight saving dates.
RTU is maintaining a calendar to handle daylight saving changes independent from
any external time source.
This chapter explains the relevant RTU parameters.
CAUTION
It is mandatory to configure the correct local zone settings the RTU system is
located in.
7-8 1KGT 150 798 V002 1 ABB AG

Time synchronization modes
The time difference between the local time zone and the UTC time zone is
configured through an offset ranging from -12 to +12 hours. The Time zone offset
parameter defines the offset between local time (standard time) and UTC time. For
example, the Western European Standard Time (WEDT) has an offset of +1 hour
to UTC. For offsets for several time zones, refer to
http://www.timeanddate.com/library/abbreviations/timezones/.
Time zone offset RTU parameters
The daylight saving dates defines the day and hour when the time is changed from
standard time to summer time and vice versa. The Daylight saving time start and
Daylight saving time end parameters specify not an exact date but a rule for
determining the dates every year. The rule includes month, day of week, position in
month, and hour. The rule reads as follows: position of day in month at hour.
An example is shown below:
Month: October, Day: Sunday, Position: Last, Hour: 3
The rule reads as follows:
”Last Sunday in October at 3 o’clock”
For the year 2005, the rule specifies the following date:
10-29-2005, 3 o’clock
Daylight saving time start RTU parameters
Daylight saving time end RTU parameters
CAUTION
The difference between summer and standard time is 1 hour. Summer time is
one hour ahead of standard time (+1 hour).
7.4 Time synchronization modes

7.4.1 Synchronization by NCC
The communication line receiving the clock synchronization command from a NCC
is configured via RTUtil500.
Due to regulation of RTU system time the long-term accuracy compared to NCC is
±5 ms.
It is recommended that clock synchronization commands are sent from NCC acting
as time master approx. every 5 minutes.
Time administration RTU parameters
ABB AG 1KGT 150 798 V002 1 7-9

7.4.2 Synchronization by NCC with external minute pulse

This method also includes reception of synchronization by NCC (see section
Synchronization by NCC (page Fehler! Verweisquelle konnte nicht gefunden
werden.)). However, the time trigger is synchronized with an external minute pulse
reference wired to the TSI input, e.g., the minute pulse of a local central clock.
To obtain high synchronization accuracy, no filters are allowed on the TSI input.
This method should only be used if the risk of receiving spikes or additional minute
pulses from source of the external minute pulse can be excluded.
Every time the RTU receives a clock synchronization command from an NCC it
computes the received time to the next full minute. The RTU waits for the external
minute pulse to trigger synchronization with the computed time. The time deviation
is regulated in an analogous manner to the other synchronization modes, using the
receipt of the minute pulse.
7.4.3 Synchronization via (S)NTP

The Network Time Protocol (NTP) is used to synchronize computer clocks on an
Ethernet-based network. The RTU supports the Simple Network Time Protocol
(SNTP) which is a simplified access strategy for servers and clients using NTP. For
instance, SNTP does not provide encryption for the transmitted time.
There are no differences in protocol between NTP and SNTP. This means that
NTP servers are able to synchronize SNTP clients, and vice versa.
The RTU supports SNTP both as a client and as a server. The SNTP client is used
to synchronize the clock in the RTU from an external source. The SNTP server can
be used to synchronize sub-RTUs or others clocks on the network. The figure
below shows the principle of the SNTP time synchronization in the RTU.
Figure 18: SNTP time synchronization in the RTU500 series

The SNTP client in the RTU retrieves the time from an external (S)NTP server and sets
the internal clock to match this time. The external (S)NTP server could be an external
clock (e.g., Meinberg GPS LANTIME), or another RTU. To requests from (S)NTP
clients in other devices, the SNTP server in the RTU replies with the time from the
internal clock. This section contains all information about the SNTP client. The SNTP
7-10 1KGT 150 798 V002 1 ABB AG

server is explained in the section Synchronization via SNTP server (page Fehler!
Verweisquelle konnte nicht gefunden werden.).
CAUTION
The SNTP client synchronizes the RTU in standard time and sets the daylight
saving time or standard time flag according to the date.
The SNTP client in the RTU offers the following features:

 Support of SNTP version 3 (RFC 1769)
 Operating modes: unicast (client /´server communication) or broadcast
(listen to broadcast server)
 Request from NTP and SNTP servers
 Request from up to 5 (S)NTP servers in unicast mode
 Listen to a single broadcast server in broadcast mode
ABB AG 1KGT 150 798 V002 1 7-11

The differences between unicast and broadcast operating mode are explained in
the following figure:
Figure 19: SNTP operating modes

In addition to the time distribution, the main difference between the operational
modes unicast and broadcast is the synchronization accuracy. For more
information on time synchronization accuracy, see the section Synchronization
accuracy (page Fehler! Verweisquelle konnte nicht gefunden werden.) at the
end of this chapter.
In the RTU, the parameters for the SNTP client are part of the Ethernet interface
configuration. An SNTP client can be configured for each Ethernet interface in an
RTU.
7-12 1KGT 150 798 V002 1 ABB AG

SNTP client Ethernet Interface parameters
CAUTION
The maximum number of SNTP clients per RTU is two. The two clients could
reside on separate CMUs, or on a single CMU with two Ethernet interfaces
(560CMU02 R0002, 560CMU05).
Each SNTP client must have a unique number. Possible numbers are 1 or 2. The
client number does not define the priority of the client as time master. The priority
of time masters is defined in the RTU parameters.
SNTP client number Ethernet Interface parameters
The current state of an SNTP client is represented by a system event in the RTU.
Possible values for the system event are synchronized, or not synchronized,
respectively.
The operational mode of the client needs to be defined in the SNTP client
parameter. If the broadcast flag is set, the client works in broadcast mode. If the
flag is not set, the client works in unicast mode. If two SNTP clients are configured,
the clients can work in the same operational mode, or in different modes.
Broadcast SNTP Client parameters
Unicast client features

In unicast mode, the SNTP client cyclically polls up to five SNTP servers on the
network. The IP address of each server must be configured in the SNTP client
parameters. If the IP address of a server is set to 0.0.0.0, the server is not
configured. All servers are equal, i.e., the SNTP client tries to poll each server
cyclically.
SNTP server X SNTP Client parameters
CAUTION
All configured SNTP servers must be visible to the Ethernet interface that
connects to the network.
Consequently, the IP address and the subnet mask of the Ethernet interface
must be set in accordance with the rules for TCP/IP networking.
ABB AG 1KGT 150 798 V002 1 7-13

The following rules define the synchronization behavior of the SNTP client in
unicast mode. According the rules, the internal clock of the RTU is synchronized
and the system event is set accordingly:
 In each cycle, the SNTP client tries to request twice from each configured
server. If both accesses fail, the server is defined as being unavailable.
 If more than 50 % of the configured servers are unavailable, no time will be
accepted.
 If the times received from the available servers differ significantly, no time
will be accepted.
 If more than one server is available, the SNTP client uses the time from the
server with the lowest transmission delay for synchronization.
The polling interval is configured in the sntp client parameter and the interval
applies for all configured servers. The range of the polling interval is between 1 and
1440 minutes (one day).
Polling interval SNTP Client parameters
Broadcast client features

In broadcast mode, the SNTP client listens to time telegrams on a special
broadcast address. This broadcast address cannot be configured but depends on
the IP address and the subnet mask of the Ethernet interface. The broadcast
address is calculated according the following rule:
Figure 20: Calculation of the broadcast address

The (S)NTP broadcast server cyclically sends the time telegram to the Ethernet
network. The RTU monitors the broadcast server using a timeout period. If the time
telegram is not received during the timeout period, the corresponding system event
is set to NOT SYNCHRONIZED. The valid range for the timeout period is from 1 to
1440 minutes (one day). The timeout is part of the SNTP client parameter.
Timeout interval SNTP Client parameters
CAUTION
It is not necessary to set the timeout to higher values than the actual broadcast
cycle. The RTU firmware ensures that the timeout does not occur in normal
operation.
7-14 1KGT 150 798 V002 1 ABB AG

The SNTP client accepts the time if two complete broadcast time telegrams are
received. In this case, the internal clock will be synchronized and the
corresponding system event is set to SYNCHRONIZED. If the time is the same in
two consecutive broadcast telegrams (server is broken), the time is discarded.
Synchronization accuracy
In unicast mode, the (S)NTP protocol takes transmission delays between client and
server into account. The client corrects the received time by the transmission
delays. This functionality increases the accuracy of time synchronization in
unicast mode. In broadcast mode (which is a one way communication), this
correction is not possible. If the minute pulse output from an external reference
clock is connected to a binary input of the RTU in a reference configuration (see
the following figure), the SNTP synchronization accuracy is defined.
Figure 21: Reference configuration for synchronization accuracy

The following values apply to the reference configuration with a polling interval of
2 minutes, or a broadcast interval of 2 minutes, respectively.
SNTP synchronization accuracy:
 Unicast mode: +/-5 ms
 Broadcast mode: +/-10 ms
The specified synchronization accuracy is valid only for a local Ethernet network.
The values do not apply to the Internet or to a corporate network and high bus
loads (e.g., collisions, GOOSE messages).
ABB AG 1KGT 150 798 V002 1 7-15

7.4.4 Synchronization via radio clock

To synchronize the time via radio clock, a real-time clock (RTC) board (560RTC01
for GPS, 560RTC02 for DCF77 – only Central Europe, or 560RTC03 for
IRIG-B/AFNOR) needs to be configured and available. The minute pulse output of
the RTC board needs to be wired to the TSI input terminal on the RTU's Bus
Connection Unit 560BCU0x and the RTC board needs to be connected to an I/O
bus.
The RTC board receives the time and synchronizes itself to the DCF77 / GPS /
IRIG-B time standard.
1. Check the alignment and position of the antenna to ensure functionality of
the RTC.
After power-on the RTC board needs approx. 3 to 4 minutes to receive the
complete information from the DCF 77 / GPS / IRIG-B transmitter.
Every minute the CMU containing the I/O bus the RTC is connected to, reads the
time of the RTC via I/O bus and compares it to the RTU system time. The RTU
signalizes a correct working RTC module by sending the positive SEV [26]
"EXTERNAL CLOCK OF RTU IS OPERABLE".
If the RTC board loses synchronization (e.g., due to an antenna fault), the RTC
board runs with its internal crystal clock with the specified accuracy for the next
2.5 hours max.
The time administration master sends the negative SEV [26] "EXTERNAL CLOCK
OF RTU IS INOPERABLE" if one of the following conditions applies:
 The RTC board is in failure state for 5 min.
 No minute pulse is received from the RTC board for 10 min.
 The RTC board is not synchronized according to DCF77 / GPS / IRIG-B for
more than 2.5 hours.
7.4.5 Redundant Time Synchronization

Up to eight time masters can be configured to synchronize the RTU. Time input is
accepted from the time master with the highest priority.
Only time synchronization input of the highest available time master is accepted. If
a time master with higher priority gets available again, the time synchronization
input of this master is accepted than. Time synchronization input of all other time
masters are rejected and ignored.
If time master is configured as synchronization by NCC, the time synchronization
input from not active time masters are rejected and negative confirmed, if not
bypassed with configuration parameter ‘Time sync acknowledge always positive’.
Time master x RTU parameters
Time sync acknowledge always positive RTU parameters
7-16 1KGT 150 798 V002 1 ABB AG

Synchronization of sub-RTUs
7.5 Synchronization of sub-RTUs

7.5.1 Synchronization with clock synchronization command
In the case of sub-RTUs, time synchronization may be performed via clock
synchronization command. In this scenario, every CMU in an RTU functions as the
time master for its sub-RTUs. It simulates the NCC functions by sending clock
synchronization commands cyclically, using the selected communication protocol.
Consequently, the cycle time must be configured. For a description of line
parameters, refer to the relevant protocol description.
If only clock synchronization via clock synchronization command is used, the
transmission time over the line reduces the time accuracy on the sub-RTU by 5 ms
per subordinate line (see the following figure). To keep the same accuracy for all
RTUs within a network, they have to be synchronized individually via an RTC, or
via clock synchronization command and external minute pulse.
NCC
CS-Command + 5 ms
RTU 560 + 10 ms
+ 5 ms
+ 15 ms
CS-Command
RTU 560
+ 5 ms
CS-Command
RTU 560
Figure 22: Time accuracy in a multi-level network (only clock synchronization

commands)
ABB AG 1KGT 150 798 V002 1 7-17

7.5.2 Synchronization via SNTP server

The RTU supports SNTP server functionality for the time synchronization of
external clocks. These clocks could be in sub-RTUs, IED or even PCs that are
connected to the same Ethernet network. The following figure shows the SNTP
server in the RTU in a possible configuration. The figure is only an example.
Figure 23: RTU500 series SNTP server configuration

The SNTP server in the RTU offers the following features:
 Support of SNTP version 3 (RFC 1769)
 Operating modes: unicast (reply to client request) and broadcast
(transmission of broadcast time telegrams)
 Reply to NTP and SNTP clients
The differences between the unicast and broadcast operating modes are explained
in the figure SNTP operating modes in the section Synchronization via (S)NTP. In
contrast to the SNTP client, the SNTP server supports the concurrent use of both
operating modes (in contrast to the client, which supports only an exclusive use of
one operating mode). The parameters for the SNTP server are part of the Ethernet
interface configuration.
A flag in the configuration must be set to configure the SNTP server. If the flag is
set, an SNTP server is started in unicast mode. In this mode, the RTU responds to
requests from SNTP clients. The time sent to the clients is taken from the internal
clock. The SNTP server is bound to the Ethernet interface. That means that the
server responds to clients that are visible on the connected network according the
interface configuration of subnet mask and IP address.
SNTP server Ethernet Interface parameters
7-18 1KGT 150 798 V002 1 ABB AG

In addition to the unicast server, a broadcast server could be configured for each
Ethernet interface. In this case, the RTU responds to client requests and sends
broadcast time telegrams at cyclic intervals. The time telegrams are sent to a
special broadcast address that depends on the IP address and the subnet mask of
the Ethernet interface. The broadcast address is calculated according to the figure
Calculation of broadcast address in the section Broadcast client features (page
Fehler! Verweisquelle konnte nicht gefunden werden.).
Broadcast Ethernet Interface parameters
The range of the cycle interval for sending broadcast telegrams is between 1 and
1440 minutes (one day).
Broadcast interval Ethernet Interface parameters
Unicast and broadcast server are independent from each other and do not interact.
ABB AG 1KGT 150 798 V002 1 7-19

8 RTU500 series I/Os and I/O bus interface
8.1 I/O bus master and RTU500 series I/O

The I/O bus master (IOM) is the master for the I/O boards connected to the RTU
I/O bus. The communication protocol between IOM and I/O board is tailored to
achieve maximum throughput. The protocol is fully independent of any
communication protocol used to communicate with the network control center.
The main processing unit (MPU) is master to the IOM. The MPU stores any output
request sent to an I/O board, or to similar modules, in a dialog RAM. The IOM will
read that part of the memory and add its own data to fulfill communication with the
addressed I/O board.
The IOM stores any event or answer it receives from I/O boards in the dialog RAM.
If it registers a message or event message from another IOM, it sends a Forced
interrupt signal to the MPU.
CMU
MPU
I/O Board
Input signal state
RAM Output signal state
Relocation register IOC

for ITI
I/O
SLC Bus- I/O
FIFO Part
module Task
Parameter
register
Requests
Dialog registers
Status etc.
Figure 24: Dialog RAM array between SLC and IOC

The main task of the IOM is to poll event information from all configured boards.
To ensure this functionality regardless of the board type (23BE23, 23AE23, etc.),
an I/O controller (IOC) is used to define a dialog RAM array with an identical
structure for all RTU I/O boards. Within the IOC software, the Bus module task
takes care of the dialog with the IOM in a standardized form. The IOC directly
reads and writes to the appropriate registers and notifies the bus module of its
activities.
ABB AG 1KGT 150 798 V002 1 8-1

RTU500 series I/Os and I/O bus interface Function Description Release 11
I/O bus master and RTU500 series I/O
The bus module handles the dialog RAM for the I/O task. The I/O task is
board-specific.
Read event flag of subrack Subrack: = 1
NO
Is there any event
message within subrack ?
YES
Read event flag of each configured board within

subrack.
Create list of board with event
Read one event into RAM to MPU.

Increment event list pointer
Address next board with event
More events YES

Subrack: = subrack + 1
in subrack ?
NO
NO
All subracks polled
for events ?
YES
Poll one board and read board status

Increment board pointer
NO
Board status o.k.
?
Store board status into
RAM to MPU
YES
Command output requests will be inserted if pending
Figure 25: Event polling by MPU
8-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 RTU500 series I/Os and I/O bus interface
Event flow through RTU500 series
8.2 Event flow through RTU500 series

The following figure describes the different levels an event has to pass through
before it is transmitted to the NCC:
Figure 26: Event flow through RTU500 series
8.2.1 SLC – IOM task

The transmission time from the I/O board to the MPU depends on the overall
configuration and state of the IOM:
 Number of sub racks and boards
 Number of pending events within a sub rack
 Number of output requests from MPU to I/O board
In order to speed up transmission, the I/O boards can be split up, on a logical level,
into a maximum of 32 I/O bus segments managed by a maximum of 16 CMUs.
8.2.2 MPU
The transmission time through the MPU depends on the CMU configuration.
PDP and HCI may run on the same CPU, or on different CPUs.
ABB AG 1KGT 150 798 V002 1 8-3

9 Status and diagnostic information
9.1 Status and error report to NCC

The RTU reports the system status and error states to the NCC by means of SEVs
(see chapter 10).
In the RTU's internal communication, system events are processed and provided
as Single Point Information. The message types and message identifications used
to send SEVs to an NCC depend on the communication protocol used on the host
interface.
9.2 Web server diagnosis

The web server of the RTU500 series is the common interface to an RTU. It is
used for carrying out maintenance and diagnostic tasks on the RTU and its
components. This chapter describes the diagnostic functions of the web server. For
more information, refer to [6].
9.2.1 System Diagnosis

The web server of the RTU500 series displays the RTU's system messages on the
System Diagnosis page.
To view the messages, proceed as follows:
1. Enter the URL of the web server of the RTU500 series in the address bar of
a standard web browser.
1. In the menu frame on the left, click on System Diagnosis. The System
Diagnosis page is displayed.
1. Use the Filter dropdown list to filter the diagnostic information by different
categories.
By default, the System Diagnosis page displays a list of system messages.
System messages are displayed one per line and in chronological order.
The general format of a system message line is as follows:
 Time System message
The system time is output in the following format:
 yy-mm-dd, hh:mm:ss
Approximately 30 seconds after the start of a CMU, the system time and date is set
to 80-01-01, 00:00:00. System messages originating to the first 30 seconds after
CMU restart are output without date and time information.
After the initial time of the CMU has been set, the internal CPU time is used. Time
synchronization of the RTU is indicated by the SEV [9.4] “RTU is synchronized”
appearing in the list of system messages.
In configurations with several CMUs, each CMU maintains and controls its own
buffer for system messages. The content of the system message buffers is not
synchronized between CMUs. This means, that the system message output may
look different on the HMIs of different CMUs, especially during the first seconds
after a restart of the RTU. Every CMU starts listening to system messages 15 to
20 seconds after a power-on or reset.
Example output (General View page):
ABB AG 1KGT 150 798 V002 1 9-1

Status and diagnostic information Function Description Release 11
RTU alarms and warnings
In an RTU with two CMUs, i.e. with an initially active CMU #3 and a standby
CMU #4, the system message output of the CMU in slot 4 may look as follows:
 14-02-26, 14:00:00->CMU #4: STARTUP
 14-02-26, 14:00:00->CMU #3: STARTUP
 14-02-26, 14:00:42->CMU #4: Operable
 14-02-26, 14:00:45->CMU #3: Operable
 14-02-26, 14:00:42->CMU #4: Not active
 14-02-06, 14:00:45->CMU #3: Active
 14-02-27, 15:42:51->RTU is synchronized
Most of the system messages are related to a change in the RTU's error status
(Warning / Alarm / OK).
9.2.2 Status Information

The Status Information pages of the web server of the RTU500 series provide
information about the RTU's hardware configuration, the state of operation and
status of any information object configured in monitoring direction, and the current
state of all system events.
To display the status information, proceed as follows:
1. Click on the hyperlink Status Information on a standard web browser surface
addressing the web server of the RTU500 series. The current configuration
is displayed in a tree structure similar to the hardware tree in RTUtil500.
2. Select a link item from the tree structure to display the current state of
operation and/or status of the related object.
The following status information is updated approx. every 5 seconds:
 The current value of any data object configured in monitoring direction.
 Any data objects in faulty state are marked up with the additional string "iv"
in red.
 If a link to an RTU is selected, a list of the current state of all system events
of this RTU is displayed. OK states are displayed in green. Faulty states are
displayed in red.
 If a link to an IED subdevice is selected, the current state of the active and
inoperable system events is displayed for this IED.
 If a 560CMU02 or 560CMU05 communication unit is selected, the related
network settings (IP address, subnet mask and default gateway) are
displayed.
9.3 RTU alarms and warnings

During configuration, Master administration mode is assigned to one CMU in each
RTU. This master CMU evaluates the system messages generated by any CMU of
an RTU and assembles the messages indicating the RTU's Warning and Alarm
states.
If a bus connection unit device is present in the RTU, the Warning and Alarm states
are indicated by means of NC contacts of the Alarm and Warning relays of the
BCU. Whenever the Alarm contact is closed, the hardware logic on the BCU closes
the Warning contact in parallel.
9-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 Status and diagnostic information
The BCU boards also provide a watchdog timer. The watchdog timer is triggered
periodically by the master CMU. If the default watchdog timer period (about
30 seconds) elapses without a new trigger signal being sent, the BCU's watchdog
logic closes the Warning and Alarm contact.
To monitor the RTU's internal Alarm and Warning states, a PLC program can be
run on any of the RTU's CMUs. The RTU's PLC firmware library RTU_FW contains
specific PLC function blocks for this purpose. For further details, refer to the
RTU500 series documentation PLC Libraries.
No. System message Cause Corrective Error status

text measure
1.1 At least one See SEV#016 for
indication faulty more details
1.2 All indications See SEV#016 for
correct more details
2.1 At least one analog See SEV#017 for
value faulty more details
2.2 All analog values See SEV#017 for
3.1 At least one digital See SEV#018 for
value faulty more details
3.2 All digital values See SEV#018 for
4.1 At least one pulse See SEV#019 for
counter value faulty more details
4.2 All pulse counters See SEV#019 for
5.1 At least one object See SEV#020 for
or regulation more details
command faulty
5.2 All object or See SEV#020 for
regulation more details
commands correct
6.1 At least one analog See SEV#021 for
output faulty more details
6.2 All analog outputs See SEV#021 for
7.1 At least one digital See SEV#022 for
output faulty more details
7.2 All digital outputs See SEV#022 for
8.1 External clock See SEV#026 for
inoperable more details
8.2 External clock See SEV#026 for
operable more details
8.3 RTU is not See SEV#025 for
synchronized more details
8.4 RTU is synchronized See SEV#025 for
more details
9.1 Power supply failure See SEV#059 for
in RTU central sub more details
rack
ABB AG 1KGT 150 798 V002 1 9-3


text measure
9.2 Power supply OK in See SEV#059 for
RTU central sub more details
rack
10.1 Configuration Error Wrong rack Check the Alarm
on CMU in rack x, address rack address.
slot y: WRONG
RACK OR SLOT
ADDRESS
Wrong slot Check the slot Alarm
address address,
Configuration Check and Alarm
does not fit to reload the
hardware configuration.
10.2 Configuration error Different RCD With CMU Alarm
on CMU in rack x, files stored in at integration:
slot y: RCD file date least two CMUs Wait for the
CMU to
reboot.
Without CMU
integration:
Reload the
configuration
file.
RCD file(s) With CMU Alarm
missing integration:
Wait for the
CMU to
reboot.
Without CMU
integration:
Reload the
configuration
file.
10.3 Configuration error Error during RCD With CMU Alarm
on CMU in rack x, file transfer integration:
slot y: RCD file size Wait for the
CMU to
reboot.
Without CMU
integration:
Reload the
configuration
file.
10.5 Configuration error Different Redefine the Alarm
on CMU in rack x, password password
slot y: Password settings in CMUs using the web
server
interface
(based on
default
setting).
9-4 1KGT 150 798 V002 1 ABB AG


text measure
10.6 Configuration error CMU is Add the -
on CMU in rack x, configured but no missing
slot y: NO function is added function, such
ACTIVITIES as a line, a
CONFIGURED peripheral
bus, or a PLC
on the CMU.
10.7 Configuration error Booting CMU has OK
on CMU in rack x, successfully
slot y: OK loaded
configuration
file(s) from
another (running)
CMU
12.1 Firmware error on Different Load the Alarm
CMU in rack x, slot y firmware correct
version Vn.xx detected on at firmware.
least two CMUs Ensure that
the same
firmware
release (first
digit of the
release
number) is
installed on all
CMUs.
12.2 No firmware error on OK
CMU in rack x, slot y
13 <Activity type> see Activity state See Activity Warning /
‘<Activity ObjectID>’ and Activity error state and Alarm
on CMU in rack x, types Activity error
slot y <Activity types
state>. <Activity
error type>
Activity type
1 Database
2 Host interface line
3 PDP interface
4 Subdevice
interface line
5 PLC
6 Logic Function
7 Local Archive
8 Local Print
Activity ObjectID
Object ID text as
configured in
RTUtil500.
If not configurable,
value is empty.
Activity state
ABB AG 1KGT 150 798 V002 1 9-5


text measure
1 starting up Activity was
started and is
initializing
2 running Activity is in
normal
processing state
3 stopped Activity was See Activity
stopped because error types.
of a configuration
error or internal
error
4 error Activity is no Shrink
longer able to configuration
react, possibly or reduce
due to a CMU activities on
overload this CMU. See
also Activity
error types.
Activity error types
1 Function not Load the
included in firmware. correct
firmware.
2 License is missing. Activity type not Request a
licensed license key
and load it
into the RTU.
3 Supervision error Activity is Shrink the
occurred. processing due configuration.
to a CMU
overload
4 Allocation of Insufficient Shrink the
memory failed. system memory configuration.
5 Spawn of task Insufficient Shrink the
failed system memory configuration.
6 No I/O devices Add I/O
configured on line. devices to
activity in
RTUtil500.
7 Maximum number Remove I/O
of possible I/O devices from
devices exceeded. activity in
RTUtil500
8 No process data At least one
configured on line. process
datum needs
to be
configured for
this activity.
9 Overlap of process <ProcDataObject Check the
addresses at ID> is the object configuration
'<ProcDataObjectID ID text configured for correct
>'. in RTUtil500 process
addresses.
9-6 1KGT 150 798 V002 1 ABB AG


text measure
10 No telephone Dial-up Configure at
number configured configuration least one valid
for dialup server. does not contain phone number
any telephone for the dial-up
number line.
11 RCD Configuration Upload the
configuration file not files were not missing file to
found properly loaded. the RTU.
14 Activity is still After a temporary Shrink the
alive. CMU overload, configuration
an activity or reduce the
marked with number of
<activity state> activities on
‘error’ is this CMU.
processing again.
14.1 CMU in rack x, slot CMU performed Wait for Alarm
y: STARTUP a reset STARTUP
READY.
14.2 CMU in rack x, slot CMU started OK
y: STARTUP successfully
READY
17.1 RTU ‘A’ is active See SEV#060 for
more details
17.2 RTU ‘A’ is not active See SEV#060 for
more details
18.1 RTU ‘B’ is active See SEV#061 for
more details
18.2 RTU ‘B’ is not active See SEV#061 for
more details
19.1 RTU ‘A’ is operable See SEV#062 for
more details
19.2 RTU ‘A’ is See SEV#062 for
20.1 RTU ‘B’ is operable See SEV#063 for
more details
20.2 RTU ‘B’ is See SEV#063 for
22.1 PLC warning PLC calls Corrective Warning
condition ON WARNING_OUT measures
(NON_EXCLUSIVE) * with depend on the
parameters: PLC
Value = TRUE application
and EXCL =
FALSE
22.2 PLC warning PLC calls Corrective Warning
condition ON WARNING_OUT measures
(EXCLUSIVE) * with depend on the
parameters: PLC
Value = TRUE application
and EXCL =
TRUE
ABB AG 1KGT 150 798 V002 1 9-7


text measure
22.3 PLC warning PLC calls Corrective OK
condition OFF WARNING_OUT measures
(NON_EXCLUSIVE) * with depend on the
parameters: PLC
Value = FALSE application
and EXCL =
FALSE
22.4 PLC warning PLC calls Corrective OK
condition OFF WARNING_OUT measures
(EXCLUSIVE) * with depend on the
parameters: PLC
Value = FALSE application
and EXCL =
TRUE
23.1 PLC alarm condition PLC calls Corrective Alarm
ON ALARM_OUT* measures
(NON_EXCLUSIVE) with parameter: depend on the
Value = TRUE PLC
application
23.2 PLC alarm condition PLC calls Corrective OK
OFF ALARM_OUT* measures
(NON_EXCLUSIVE) with parameter: depend on the
Value = FALSE PLC
application
24.1 Local printer offline See SEV#027 for
more details
24.2 Local printer online See SEV#027 for
more details
25.1 System battery low See SEV#029 for
more details
25.2 System battery O.K. See SEV#029 for
more details
26.1 AC power supply See SEV#030 for
failed more details
26.2 AC power supply See SEV#030 for
O.K. more details
27.1 PLC function A PLC function Load the Warning
<name> on CMU #x on a CMU was license file.
PROCONOS start not started
error because a
license file is
missing.
27.2 PLC function PLC task on OK
<name> on CMU #x CMU is in
PROCONOS start operation
OKAY
9-8 1KGT 150 798 V002 1 ABB AG


text measure
28.1 PLC function A PLC function  Correct the Warning
<name> on CMU #x on a CMU was PLC
program not running stopped. function.
Possible causes:  Start the
 Programming PLC
error function
 Operator via MWT.
action
28.2 PLC function The PLC function OK
<name> on CMU #x was started
program running correctly.
29.1 PLC function The PLC  Disable the Warning
<name> on CMU #x execution cycle watchdog
watchdog error time was longer via MWT.
than the  Increase
watchdog time. the
The PLC function watchdog
is restarted. timer.
29.2 PLC function The PLC task on This message OK
<name> on CMU #x CMU is back to is generated
watchdog OKAY normal operation. by the CMU
app. 10 s after
the error
disappears.
30.1 PLC function PLC execution  Simplify Warning
<name> on CMU #x was stopped the PLC
CPU overload because of a function.
CPU overload.  Load the
The PLC function PLC
is restarted. function to
another
CMU.
30.2 PLC function PLC task on This message OK
<name> on CMU #x CMU is back to is generated
no CPU overload normal operation by the CMU
app. 10 s after
the error
disappears.
31.1 PIN initialization The PIN Check the PIN
failed initialization of a in the
GSM modem has RTUtil500
failed. configuration
file.
31.2 PIN initialization The PIN
successful initialization has
failed before.
Now the PIN
initialization of a
GSM modem
was successful.
ABB AG 1KGT 150 798 V002 1 9-9


text measure
32.1 At least one modem Because of 12 Check the
blacklisted unsuccessful dial-up
dial-up attempts, numbers in
the connected the RTUtil500
dial-up modem is configuration
blacklisted for file.
the next two Check that all
hours (*). partners are
available.
Increase the
time between
two dial
attempts.
32.2 No more modems At least one
are blacklisted dial-up modem
was blacklisted
before. Now
(after two hours)
all modems are
available again.
33.1 x. Cmd supervision See SEV#064 …
circuit disconnected #095 for more
or faulty details
33.2 x. Cmd supervision See SEV#064 …
circuit is O.K. #095 for more
details
34.1 PDP interface on An error with Replace
CMU #x running. 23BA22 / 23BA22 /
Command not 23BA23 was 23BA23,
switched through detected during reconnect
due to command process
 active local check execution. voltage.
function Operate
LOCAL/REM
 process voltage
OTE switch.
missing
 23BA22 /
23BA23 internal
fault
34.2 x. Cmd supervision The command
circuit is O.K., 1 ≤ x supervision
≤ 32 circuit 23BA22 /
23BA23 is O.K.
again.
This message is
generated when
a command is
successfully
executed.
9-10 1KGT 150 798 V002 1 ABB AG


text measure
35.1 PDP interface on The command Check and
CMU #x running. supervision correct the
Lower limit circuit has process
resistance value detected during connections.
underflow. command Maybe the
x. CMD supervision execution that lower limit
circuit disconnected the resistance of resistance
or faulty, the connected value has to
1 ≤ x ≤ 32 coil is lower than be adapted.
the lower limit
resistance value.
35.2 x. Cmd supervision This message is
circuit is O.K., 1 ≤ x generated after
≤ 32 the lower limit
underflow
message when
the next
command is
successfully
executed.
36.1 PDP interface on The command Check and
CMU in rack y, slot z supervision correct the
running. Upper limit circuit has process
resistance value detected during connections.
overflow. command Maybe the
x. CMD supervision execution that upper limit
circuit disconnected the resistance of resistance
or faulty, the connected value has to
1 ≤ x ≤ 32 coil is higher than be adapted.
the upper limit
resistance value.
36.2 x. Cmd supervision This message is
circuit is O.K., 1 ≤ x generated after
≤ 32 the upper limit
overflow
message when
the next
command is
successfully
executed.
37.1 Host interface line The host
<name> on CMU #x interface <name>
running. Queue is OFFLINE and
storage timed out. the queue
Entries written to storage timeout
process image. timer has
expired. The
contents of the
host queues is
written to the
process image
and the queues
are cleared
ABB AG 1KGT 150 798 V002 1 9-11


text measure
running. Queue is ONLINE again.
storage active again. Process data is
written to the
queue.
38.1 Host interface line The priority z Enlarge the
<name> on CMU #x queue of the host size of this
running. Priority z interface <name> queue z.
queue switched to is full. The
image mode. content of the
queue is written
to the process
image and the
queue is cleared.
running. Priority z is ONLINE again.
queue switched Process data is
back to queue written to the
mode. queue.
39.1 Host interface line The ITI queue of Enlarge the
<name> on CMU #x the host interface size of this
running. Pulse <name> is full. queue.
counter queue starts New EPR pulse
to displace old IR counter values
entries. will replace old IR
entries.
storage active again. ITIs are written to
the queue again.
40.1 Host interface line The ITI queue of Enlarge the
<name> on CMU #x the host interface size of this
running. Pulse <name> is full. queue.
counter queue starts New EPR pulse
to displace old EPR counter values
entries. will replace old
EPR entries.
storage active again. ITIs are written to
the queue again.
Task error on CMU A software Alarm
#x malfunction
occurred on CMU
#x. The CMU
performs a reset
if a malfunction is
detected.
9-12 1KGT 150 798 V002 1 ABB AG


text measure
Gateway routing Configured Check the
failed for CMU #x backplane configured IP
routing failed. addresses
and settings
of backplane
routing.
41.1 RTU is faulty See SEV#023 for
more details
41.2 RTU is OK See SEV#023 for
more details
42.1 RTU not active See SEV#024 for
more details
42.2 RTU active See SEV#024 for
more details
43.1 At least one See SEV#028 for
indication is more details
oscillating
43.2 All indications stable See SEV#028 for
more details
44.1 At least one DCE See SEV#044 for
faulty more details
44.2 ALL DCE okay See SEV#044 for
more details
45.1 Device not See SEV#045 for
connected more details
45.2 Device connected See SEV#045 for
more details
46.1 RTU is out of service See SEV#049 for
more details
46.2 RTU is in service See SEV#049 for
more details
47.1 SNTP Client x not See SEV#096…
synchronized #097 for more
details
47.2 SNTP Client x See SEV#096…
synchronized #097 for more
details
48.1 Local control See SEV#100 for
authority available more details
48.2 Local control See SEV#100 for
authority active more details
49.1 Host x offline See SEV#101…
#116 for more
details
49.2 Host x online See SEV#101…
#116 for more
details
50.1 CMU #x inoperable See SEV#149…
#164 for more
details
ABB AG 1KGT 150 798 V002 1 9-13


text measure
50.2 CMU #x operable See SEV#149…
#164 for more
details
54.1 Network element no. See SEV#192…
x not operable #223 for more
details
54.1 Network element no. See SEV#192…
x operable #223 for more
details
55.1 CMU #x not active See SEV#224…
#239, for more
details
55.2 CMU #x active See SEV#224…
#239, for more
details
Table 8: System message text
9.3.1 Board States and LED Signaling

All communication and data processing units of the RTU500 series are equipped
with LEDs to indicate errors or operating modes. These LEDs allow a basic visual
check of the RTU's current situation. The following chapters describe the LEDs of
each communication or data processing unit.
9-14 1KGT 150 798 V002 1 ABB AG

9.3.2 LEDs on 560CMU02 and 560CMU05
Figure 27: LEDs on 560CMU02 and 560CMU05
9.3.3 CMU states

Boot state
After a reset (by setting the power switch to ON or as a consequence of a software
reset by web server or control system), the CMU is in Boot state. The system then
initializes the hardware and the basic hardware drivers. In this state, only the red
ERR LED is used for signaling.
The CMU signals its current Boot state as follows:
Signal element Signal

System Diagnosis -
"ERR" LED (red) ON
Alarm relay ON
Warning relay ON
Table 9: Boot state signaling of the CMU

In Boot state, the application firmware of the CMU is not yet started. Consequently,
the web server is not available for system diagnostics.
In the event of an error during initialization of the hardware, the CMU remains in
Boot state.
Upon successful completion of the Boot state, the ERR LED changes to OFF for
approximately one second. The LED then switches back to ON. The CMU changes
to Start-up state.
ABB AG 1KGT 150 798 V002 1 9-15

Start-up state
In Start-up state, the CMU initializes by evaluating the configuration files.
During this process, the administration master CMU initializes all configured
communication interfaces and internal activities on all CMUs in the RTU in the
following order:
 Subdevice communication interfaces
 Internal functions
 Host communication interfaces
The CMU signals its current Start-up state as follows:

System Diagnosis "CMU in rack x, slot y: STARTUP"
"ERR" LED (red) Flashing with approx. 2,5 Hz
Alarm relay ON
Warning relay ON
Table 10: Start-up state signaling of the CMU

Any configured communication interfaces signal their current state via serial
interface (see chapter Communication interface states (page 9-17)) after
initialization.
Depending on the success of the initialization, the CMU changes from Start-up
state to one of the following states:
 OK
 Warning
 Alarm
Alarm state
By definition, the Alarm state of an RTU means that a fatal error has occurred in
the RTU as described in the section System data interface, subsection System
events.
The CMU signals an Alarm state as follows:

System Diagnosis see section System Diagnosis
"ERR" LED (red) ON
Alarm relay ON
Warning relay ON
Table 11: Alarm state signaling of the CMU

In Alarm state, the administration master CPU sets the Alarm and Warning relays
to Active state.
9-16 1KGT 150 798 V002 1 ABB AG

Warning state
By definition, the Warning state means that a minor error has occurred in the RTU,
as described in the section System data interface, subsection System events.
The CMU signals a Warning state as follows:

"ERR" LED (red) Flashing with 1 Hz
Alarm relay OFF
Warning relay ON
Table 12: Warning state signaling of the CMU

In Warning state, the administration master CPU sets the Warning relay to Active
state.
OK state
In OK state, the RTU operates free of errors according to the active configuration.
The CMU signals an OK state as follows:

"ERR" LED (red) OFF
Alarm relay OFF
Warning relay OFF
Table 13: OK state signaling of the CMU

In OK state, the administration master CPU sets the Warning and Alarm relays to
Inactive state.
9.3.4 Communication interface states

Serial interface states
All serial interfaces on the CMU signal their current state via LED.
Serial interface Boot and not configured state

A serial interface is in Boot state if the CMU is in Boot state or if the interface is not
configured.
A serial interface signals its Boot state as follows:

Serial interface "Tx" and "Rx" LED According to data request
(green)
Table 14: Boot state signaling of a serial interface
Start-up state
A serial interface is in Start-up state if the CMU is in Start-up state and if
initialization of the serial interface via configuration files is in progress.
ABB AG 1KGT 150 798 V002 1 9-17

A serial interface signals its Start-up state as follows:

Serial interface "Tx" and "Rx" LEDs According to data transfer
(green)
Table 15: Start-up state signaling of a serial interface

If start-up fails, the System Diagnosis function of the web server generates the
following system message: Activity Error for <Activity Type> in CMU #x:
<Activity-Error Type>. For more information, see section System Diagnosis.
OK state
After successful start-up of a serial interface, the active communication protocol
sets the operating state of the device to OK.
If a communication error occurs while the device is in operating state, the Error
state is set. The communication protocol resets the device to OK state after the
next successful transmission of a telegram.
A serial interface signals its OK state as follows:

Serial interface "Tx" and "Rx" LED According to data transfer
(green)
Table 16: OK state signaling of a serial interface
Error state
A serial interface is set to Error state if a communication error (such as a parity
error, gap supervision error, or baud rate error) occurs or if start-up of the serial
interface has failed.
A serial interface signals an Error state as follows:

Serial interface "Tx" and "Rx" LED According to data transfer
(green)
Table 17: Error state signaling of a serial interface
Ethernet interface
Signaling for the Ethernet interface is independent of the RTU application.
If an active Ethernet line is connected to the CMU, signaling is as follows:

Ethernet interface "A" LED (green) According to data transfer on the
Ethernet line
Ethernet interface "L" LED (yellow) According to the state of the Ethernet
link
Table 18: Signaling of the CMU with active Ethernet line

If no active Ethernet line is connected, signaling is accidental. This applies to all
states.
9-18 1KGT 150 798 V002 1 ABB AG

9.3.5 I/O boards, modems and real time clocks

LED indications for 23AA21, 23AE23 and 23BE23
Figure 28: LEDs of the 23AA20, 23AE23, and 23BE23 communication modules
LED Status LED indication Applicable

communication
modules
ST ON The communication module runs 23AA21
the initialization procedure. 23BE23
23AE23
The communication module 23AA21
performs a cold or warm start. 23BE23
23AE23
The communication module has 23AA21
detected a memory error 23BE23
(EPROM and/or RAM). 23AE23
The micro-controller is defective. 23AA21
23BE23
23AE23
The peripheral bus processor did 23AA21
not attempt to poll data from the 23BE23
board for at least two minutes. 23AE23
An IOM cycle has timed out. 23AA21
23BE23
23AE23
ST ON The A/D converter is defective. 23AE23
Table 19: LED indications for 23AA21, 23AE23, and 23BE23
ABB AG 1KGT 150 798 V002 1 9-19

LED indications 23BA20 and 23BA22 or 23BA23
23BA22 23BA20
red Error
red Error
red Process error
red Process error
green Command output

green TM1 Test Mode circuit 2
green TM0 Test Mode circuit 1
green CO Command output
red LOC LOCAL / REMOTE

LOCAL / REMOTE
push button
Figure 29: LEDs of the 23BA20, 23BA22, and 23BA23 communication modules
LED Status LED indication

ST ON The communication module runs the initialization procedure.
The communication module performs a cold or warm start.
The communication module has detected a memory error
(EPROM and/or RAM).
The micro-controller is defective.
PST ON 24 V DC for output relays failed or an internal short circuit
has occurred.
An IOM cycle has timed out. An active output is stopped
(switched off).
TM0 / ON (1 out of n) check is active on circuit P1 (TM0) or P2 (TM1).
TM1 OFF The last command output performed successfully.
flashin The last command output sequence was stopped because of
g a resistance violation.
CO ON At least one relay is switched on. Command output is active
(pulse output or, if a GOM output is activated, persistent).
LOC ON 23BA22 or 23BA23 is switched to local mode. No active
output is possible (GO relay is disabled).
OFF The communication module is in remote operation mode.
Command output is normal.
flashin The communication module toggles between local and
g remote operation mode.
Table 20: LED indications of the 23BA20 and 23BA22, and 23BA23
communication modules
LOC pushbutton
To switch to local mode or back to remote mode, proceed as follows:
1. Press the LOC pushbutton twice within 5 s. The LOC LED will flash during
that time window.
If you press the LOC pushbutton only once, the command is ignored.
9-20 1KGT 150 798 V002 1 ABB AG

The selected state (local or remote) is transmitted to the NCCs by means of a

system event (SEV). The SEV offset is incremented by one for each check circuit,
as shown in the following example:
 SEV #64 for check circuit 1
 …..
Object command output with (1 out of n) check

The object command output with command supervision results from a combined
view of the LEDs of the 23BA20 and 23BA22, or 23BA23 communication modules,
as shown in the following tables.
23BA20 LED Explanation

1 2 3 4 5
Error ST
Process voltage error PST
Command output CO
Table 21: Normal object command output

(1) Before the pulse output
(2) 23BA20 has changed the output channel.
(3) 23BA22 or 23BA23 performs the (1 out of n) check. The result is positive.
23BA22 or 23BA23 activates GO relay for the given pulse time.
(4) 232BA20 is still active but the output relay will be switched off by the
communication unit.
(5) After the pulse output
23BA22 or 23BA23 LED Explanation

1 2 3 4 5
Error ST
Test mode circuit 1 TM0
Command output CO
Local LOC
Table 22: Normal object command output

(3) 23BA22 or 23BA23 performs the (1 out of n) check. The result is positive.
23BA22 or 23BA23 activates GO relay for the given pulse time.
(4) 232BA20 is still active but the output relay will be switched off by the
communication unit.
(5) After the pulse output
ABB AG 1KGT 150 798 V002 1 9-21

Object command output and failure at (1 out of n) check:
23BA20 LED Explanation

1 2 3 4 4a 5
Error ST
Command output CO
Table 23: Object command output and failure at (1 out of n) check

(3) 23BA22 or 23BA23 performs the (1 out of n) check. The result is negative.
(4) The PST and TMx LEDs and on 23BA22 or 23BA23 flash.
(5) Alternative to 3: If the result is positive, the command is switched on. If the
24 V DC supply fails during command output, the LEDs PST and CO flash.
23BA22 LED Expl

anat
ion
1 2 3 4 4a 5
Error ST
Command output CO
Local LOC
Table 24: Object command output and failure at (1 out of n) check

(3) 23BA22 or 23BA23 performs the (1 out of n) check. The result is negative.
(4) The PST and TMx LEDs and on 23BA22 or 23BA23 flash.
(5) Alternative to 3: If the result is positive, the command is switched on. If the
24 V DC supply fails during command output, the LEDs PST and CO flash.
The 23BA20 relay is switched off. If failure 4 occurs, the 23BA22 or 23BA23 LEDs
keep flashing until the next output command.
9-22 1KGT 150 798 V002 1 ABB AG

LED indications for 23WT25
Figure 30: LED indications for 23WT25

TxD ON Transmitted data true
RxD ON Received data true
RTS ON Request to send = ON
DCD ON Data carrier detected = ON
EQZ ON Equalizer
SQL ON Signal quality level
Table 25: LED indications for 23WT25
LED indications for 23WT23 or 23WT24
23 WT 23
TxD = Send data (green)
RxD = Receive data (green)
TxD RxD
RTS = Request to send (yellow)
RTS DCD
DCD = Data carrier detected (yellow)
Figure 31: LED indications for 23WT23 or 23WT24

TxD ON Transmitted data
RxD ON Receive data
RTS ON Request to send
DCD ON Data carrier detected
Table 26: LED indications for 23WT23 or 23WT24
ABB AG 1KGT 150 798 V002 1 9-23

LED indications for 560RTC01
560RTC01
red Error
red FR Free running

green LS Lock status (GPS receive signal)
yellow MN Minute pulse
Figure 32: LED indications for 560RTC01

ST ON  An antenna / converter unit is defective.
 An antenna cable is defective.
 A watchdog is active because of an error in the
communication module.
FR ON 560RTC01 is not synchronized by the GPS time standard or
is out of synchronization.
LS ON The LED indicates that at least 4 satellite signals were
received after start-up of the communication unit and that the
receiver has calculated his position.
MN ON Minute pulse.
 Flashes every minute for about 1 second.
Table 27: LED indications for 560RTC01
9-24 1KGT 150 798 V002 1 ABB AG

560RTC02
red Error
red FR Free running

green CD Carrier detect (DCF77 receive signal)
yellow MN Minute pulse

ST ON  The communication module runs the initialization
procedure.
 The communication module performs a cold or warm
start.
 The communication module has detected a memory error
(EPROM and/or RAM).
 The micro-controller is defective.
FR ON 560RTC02 is not synchronized by the DCF77 time standard
or is out of synchronization.
CD ON The LED indicates the receiving signal level of the DCF77
transmitter. Indication of the receiving signal level allows
adjustment of the antenna to the maximum receiving signal
level.
MN ON Minute pulse.
ABB AG 1KGT 150 798 V002 1 9-25


ST ON  The communication module runs the initialization
procedure.
 The communication module performs a cold or warm
start.
 The communication module has detected a memory error
(EPROM and/or RAM).
 The micro-controller is defective.
FR ON 560RTC03 is not synchronized according to the IRIG-B /
AFNOR time standard or is out of synchronization.
CD ON 560RTC03 has received a valid IRIG-B / AFNOR time
telegram.
TS ON 560RTC03 was synchronized by means of an IRIG-B /
AFNOR time telegram.
MN ON Minute pulse.
9.3.6 LED indications for 23OK24
Figure 35: LED indications for 23OK24
9-26 1KGT 150 798 V002 1 ABB AG

9.3.7 LED indications of decentralized modules

LED indications for 23BA40 and 23BE40
Figure 36: LED indications for 23BA40
Figure 37: LED indications for 23BE40
ABB AG 1KGT 150 798 V002 1 9-27

10 System data interface
10.1 System events

The following table describes the information displayed in the system events
(SEVs) of the RTU560 series' web server.
The columns have the following meaning:
 SEV offset:
System event offset address within the System Events block
 System event
Meaning of the system event message in case of positive transmission
value. The default value is Not set ("0").
 Cause
Possible cause(s) of the system event message
SEV System Value Detailed Cause Error status

offset message description
#016 At least one ON At least one local The I/O board is Warning
indication faulty SPI or DPI data missing.
point of RTU is
invalid.
The I/O board is not Warning
running.
An I/O bus Warning
connection failure
has occurred.
All indications OFF All local SPI or DPI - OK
correct data points of RTU
are valid.
#017 At least one ON At least one local The I/O board or Warning
analog value AMI data point of CVT module is
faulty RTU is invalid. missing.
Note:
Overflow is not
considered by this
SEV.
The I/O board or Warning

CVT module is not
running.
An I/O bus or CVI Warning
line connection
failure has occurred.
The analog settings Warning
are not correct.
ABB AG 1KGT 150 798 V002 1 10-1

System data interface Function Description Release 11
System events

All analog values OFF There is no I/O bus - OK
correct error. All I/O boards
and CVT modules
with configured
analog values are
operable. No live
zero underflow was
detected.
#018 At least one ON At least one local The I/O board or Warning
digital value faulty DMI or BSI data CVT module is
point of RTU is missing
invalid or a wrong
BCD coding was
detected.
CVT module is not
running.
line connection
A warning with Warning
regard to BCD
coding or
configuration has
occurred.
All digital values OFF There is no I/O bus - OK
correct error. All I/O boards
with configured
digital values are
operable.
#019 At least one pulse ON At least one local ITI The I/O board or Warning
counter value data point of the CVT module is
faulty RTU is invalid. missing.
CVT module is not
running.
line connection
All pulse counters OFF All local ITI data - OK
correct points of the RTU
are valid.
object or SCO, DCO, or RCO missing.
regulation data point of the
command faulty RTU is invalid and
not operable.
running.
The I/O bus Warning
connection failure
has occurred.
10-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 System data interface
System events

A command Warning
supervision board
(e.g., 23BA22 or
23BA23) is without
process voltage.
All object or OFF All local SCO, DCO - OK
regulation or RCO data points
commands of the RTU are valid
correct and operable.
analog output ASO and SOC data missing.
faulty point of the RTU is
invalid and not
operable.
running.
An I/O bus Warning
connection failure
has occurred.
All analog outputs OFF All local ASO and - OK
correct SOC data points of
the RTU are valid
and operable.
digital output BSO data point of missing.
faulty the RTU is invalid
and not operable.
running.
An I/O bus Warning
connection failure
has occurred.
All digital outputs OFF All local BSO data - OK
correct points of the RTU
are valid and
operable.
#023 RTU is faulty ON Included only for
compatibility
reasons.
Always set to OFF.
RTU is OK OFF Included only for
compatibility
reasons.
Always set to OFF.
2
#024 RTU active ON The RTU is able to OK
process as
configured.
ABB AG 1KGT 150 798 V002 1 10-3

System events

RTU not active OFF The RTU cannot The configuration Error
process as files of the RTU or a
configured. connected
subdevice contain
invalid data or
required data are
missing from the
files.
#025 RTU ON The RTU is - -
synchronized synchronized by the
time master as
configured.
RTU not OFF The time of the RTU No time -
synchronized is not synchronized synchronization
and may deviate signal is received
from the time of the from the time master
time master.
The minute pulse is -
missing.
The RTC is missing, -
has an error or has
not yet been
synchronized.
The SNTP server is -
not available or has
not been
synchronized.
#026 External clock ON The configured The RTU has not Warning
inoperable external RTC clock been synchronized
is inoperable. yet by 560RTC0x.
An RTC or minute Warning
pulse is missing.
An RTC antenna Warning
error has occurred.
External clock OFF The configured - OK
operable external RTC clock
is operable.
#027 Local printer ON The local printer is A printer connection -
offline not working or out of failure has occurred.
order.
The printer is offline. -
No paper available -
Local printer OFF The local printer is - -
online running.
#028 At least one ON At least one local The input signal Warning
indication SPI or DPI data oscillates within the
oscillating point is oscillating configured limits.
(Oscillating
suppression active).
All indications OFF All configured SPI or - OK
stable DPI data points are
stable.
10-4 1KGT 150 798 V002 1 ABB AG

System events

#029 Battery voltage ON Backup battery is The battery is Warning
low not charged. defect.
Check connection to Warning
battery.
Battery voltage OFF Backup battery is - OK
OK charged.
#030 AC power supply ON AC power supply is No AC power is Warning
failure defective. RTU is available.
running on backup
battery.
The power supply Warning
unit is defect.
AC power supply OFF AC power supply is - OK
OK available.
#044 At least one DCE ON At least one data The DCE is switched -
faulty communication off.
equipment (DCE) is
missing or not
responding.
The DCE is not -
connected.
The DCE does not -
respond to
initialization string.
The DCE is -
blacklisted.
All DCE okay OFF All pieces of data - -
communication
equipment (DCE)
are connected to the
RTU.
1
#045 Device connected ON The connection to - -
the device is
established via
dial-up.
Device not OFF The connection to No reportable data -
connected the device via were received from
dial-up is currently the device.
not established.
No cyclic dial-up call -
from the RTU to the
device is pending.
#046 At least one PLC ON At least one No boot project was Warning
function not configured PLC loaded.
running function of the RTU
is not running.
A PLC license is Warning
missing on the CMU,
An exception in a Warning
PLC user program
has occurred.
ABB AG 1KGT 150 798 V002 1 10-5

System events

All PLC functions OFF All configured PLC - OK
running functions of the RTU
are running.
#047 At least one PLC ON The cycle watchdog The PLC execution Warning
function cycle time of at least one cycle time was
time exceeded PLC task was longer than the
exceeded. watchdog time. The
PLC function is
restarted.
All PLC function OFF All PLC task cycle - OK
cycle time OK times are within the
configured
watchdog times.
1
#048 RTU inoperable ON A subordinate No physical -
device (RTU, IED, connection is
etc.) is inoperable or available.
not connected.
A protocol or -
interface setting
mismatch has
occurred.
A device address -
mismatch (such as
link address, station
address) has
occurred.
RTU is operable OFF The subordinate - -
device (RTU, IED,
etc.) is operable and
the connection to
the RTU is
established.
1
#049 RTU is out of ON The subordinate The subordinate -
service device (RTU, IED, device (RTU, IED,
etc.) was put out of etc.) was put out of
service and is not service with
being processed. SSC#001.
RTU is in service OFF The subordinate - -
device (RTU, IED,
etc.) is being
processed.
#059 Power supply ON Failure of one A hardware failure of Warning
failure in RTU configured power the power supply
central sub-rack supply unit (e.g., unit has occurred.
560PSU01) in rack
Not all configured Warning
power supply units
are plugged in.
Power supply OK OFF The configured - -
in RTU central power supply units
sub-rack are error-free.
10-6 1KGT 150 798 V002 1 ABB AG

System events

#060 RTU A active ON Included only for
compatibility
reasons
Always set to OFF
RTU A not active OFF Included only for
compatibility
reasons
Always set to OFF
#061 RTU B active ON Included only for
compatibility
reasons
Always set to OFF
RTU B not active OFF Included only for
compatibility
reasons
Always set to OFF
#062 RTU A operable ON Included only for
compatibility
reasons
Always set to OFF
RTU A inoperable OFF Included only for
compatibility
reasons
Always set to OFF
#063 RTU B operable ON Included only for
compatibility
reasons
Always set to OFF
RTU B inoperable OFF Included only for
compatibility
reasons
Always set to OFF
#064 x.Cmd. ON The command A hardware failure of -
… supervision circuit supervision circuit of command
#095 disconnected or a command supervision board
faulty supervision board has occurred.
[x= 1...32] (e.g., 23BA22 or
23BA23) is
defective.
The command
supervision board is
not plugged in or
was inserted at the
wrong rack or slot
position.
No process voltage -
is available.
The measured -
resistance of the
connected coil is
outside of the
configured limits.
ABB AG 1KGT 150 798 V002 1 10-7

System events

The -
LOCAL/REMOTE
switch of the
command
supervision board is
in LOCAL position.
x.Cmd. OFF The command - -
supervision circuit supervision circuit is
is OK okay again.
[x= 1...32] This message is
generated when a
command is
successfully
executed.
#096 SNTP Client #x ON At least one - -
… synchronized configured SNTP
#097 [x= 1...2] server is available
with a plausible
time.
SNTP Client #x OFF The time No SNTP server is -
not synchronized synchronization of responding.
[x= 1...2] the RTU is not
possible by
concerned SNTP
client.
An IP address -
mismatch has
occurred.
#100 Local control ON The command from The local control -
authority active HCIs that are authority is currently
configured to requested, e.g. by
interlock with local integrated HMI or by
control authority of client on IEC 61850
RTU will be blocked. station bus.
Local control OFF The local control - -
authority available authority can be
requested by
integrated HMI of
the client on the
IEC 61850 station
bus.
101 Host #x online ON The connection to - -
… [x= 1...16] the host is
#116 established and
running.
Host #x offline OFF No process The host is not -
[x= 1...16] communication with running
host
No physical -
connection is
available.
Line addressing is -
incorrect.
10-8 1KGT 150 798 V002 1 ABB AG

System events

#117 Hostinterface x: ON At least one See chapter ‘Host -
… At least one information change communication
#132 change of of the corresponding interface’
information lost HCI is lost due to
[x= 1...16] queue overflow.
Hostinterface x: OFF All information See chapter ‘Host -
All changes of changes are communication
information reported to the interface’.
processed connected host.
[x= 1...16]
#133 Hostinterface x: At least one pulse See chapter ‘Host -
… At least one pulse counter is lost due communication
#148 counter lost to queue overflow or interface’.
[x= 1...16] replacement.
Hostinterface x: All pulse counters See chapter ‘Host -
All pulse counters are reported to the communication
processed connected host. interface’.
[x= 1...16]
#149 CMU #x operable The CMU is started - OK
… [x= 1...16] and alive on the
#164 system bus.
CMU #x The CMU is not A hardware failure of Error

inoperable reachable on the CMU has occurred.
[x= 1...16] system bus.
The CMU is not Error
plugged in.
The redundant rack Error
with the CMU is
switched off
The CMU is starting Error
up.
1
#180 Device reachable ON The subordinate - -
… on redundant line devices (RTU, IED,
#183
1 x etc.) are marked as
[x= 1...4] reachable if a link to
the device can be
established
according to the
procedures
described in the
supporting SCIs.
Device not OFF The subordinated The physical -
reachable on device (RTU, IED, connection to the
redundant line x etc.) cannot be device is defective.
[x= 1...4] reached on line.
A device failure has -
occurred.
1
#184 Device active on ON Link is used for - -
… redundant line x process data
#187
1 [x= 1...4] communication with
subordinated device
(RTU, IED, etc.)
ABB AG 1KGT 150 798 V002 1 10-9

System events

Device not active OFF Link is checked only A link with higher -
on redundant line for reachability priority is reachable,
x (see and is therefore the
[x= 1...4] SEV#180…183) active link.
Another link was set -
as the preferred link
using an
SSC#004…#007
system command.
Another link was set
as the active link
using an
SSC#008…#011
system command.
1
#188 Device preferred ON Link to subordinate The link is the -
… on redundant line device (RTU, IED, preferred link by
#191
1 x etc.) is considered configuration.
[x= 1...4] as the preferred link
during line
switchover
The link was set as -
the preferred link
using an
SSC#004...#007
system command.
Device not OFF - - -
preferred on
redundant line x
[x= 1...4]
#192 Network element ON Supervised network - -
… no. x operable element is
#223 [x= 1...32] connected and
operable
Network element OFF Supervised network The network -
no. x not element (e.g. element is not
operable Ethernet switch running.
[x= 1...32] supervised by
SNMP) is not
connected or not
operable
A physical or logical
connection to
network element
cannot be
established.-
An IP address
mismatch has
occurred.
#224 CMU #x active ON CMU is processing The CMU is the OK
… [x= 1...16] the configured active CMU in a
#239 function. redundant pair of
CMUs.
10-10 1KGT 150 798 V002 1 ABB AG

System events

The CMU is a
non-redundant
CMU.
No command OFF - - Error-
collision with host
no x
[x= 1...16]
1
#258 Command ON The issued
collision with command is already
Integrated HMI in use. The
transmitted
command was
negatively
acknowledged.
No command OFF - - -
collision with
Integrated HMI
1
#259 Command The issued A command issued
collision with web command is already by the RTU500
server in use. The series' web server is
transmitted already being
command was executed.
negatively
acknowledged.
No command - - -
collision with web
server
1
#260 Command The issued A command issued
collision with PLC command is already by a PLC function is
in use. The already being
transmitted executed.
command was
negatively
acknowledged.
No command - - -
collision with PLC
Table 30: System event messages

1
Generated for directly connected subordinate devices by the SCI of the RTU. For
more detailed information on the supported devices, refer to the corresponding
Protocol Description manual.
2
Generated for directly connected subordinate devices by the SCI of the RTU, or
by the RTU itself.
ABB AG 1KGT 150 798 V002 1 10-11

System commands
10.2 System commands

The behavior of subordinate devices connected to a subdevice communication
interface can be controlled with the help of system commands.
This table shows the available system commands (SSC = System Single
Command).
SSC System command Value Detailed description

address
#001 Put device out of service ON Set subordinated device (RTU, IED, …)
out of service (see also SEV#049).
Put device to service OFF Set subordinated device (RTU, IED, …)
in service (see also SEV#049).
#002 Reset device process ON Send a protocol-specific reset
command to the subordinated device
(RTU, IED, etc.).
- OFF The value OFF is ignored.
#003 Connect device ON Request a dial-up connection to the
subordinated device (RTU, IED, etc.)
(see also SEV#045).
Disconnect device OFF Disconnect dial-up connection to
subordinated device (RTU, IED, etc.)
(see also SEV#045).
#004 Set redundant line x as preferred line ON Set redundant line x to subordinated
... [x= 1...4] device (RTU, IED, etc.) as the preferred
#007 line.
Setting a redundant line as preferred
line will reset all previous set preferred
lines. One redundant line is always the
preferred line (see also
SEV#188…#191).
#012 Force global process image update ON Force an update of the process image
of all subordinated devices.
#016 Switch over to redundant CMU #x ON Switch over to the partner CMU of a
... [x=1…16] redundant CMU pair.
#031 The active CMU is doing a reset if the
standby CMU #x is operable. If this is
not the case, the command is negative
acknowledged and not executed.
Table 31: System commands
10-12 1KGT 150 798 V002 1 ABB AG

11 Glossary of terms
A
AMI Analog Measured value Input
ASO Analog Setpoint command Output
BCU Bus Connection Unit
BSI Bit String Input (8, 16 bit)
BSO Bit String Output (1, 2, 8, 16 bit)
CHAP Challenge Handshake Authentication Protocol
CMU Communication and Data Processing Unit
CRC Cyclic Redundancy Check
CS Control System
CS Command Clock Synch Command
CSC Command Supervision Channel
CTO Common Time Object
DCO Double Command Output
DMI Digital Measured value Input (8, 16 bit)
DPI Double Point Input
DSO Digital Setpoint command Output (8, 16 bit)
EPI Event of Protection equipment Input (1 bit)
GCD General Configuration Data
HCI Host Communication Interface
ABB AG 1KGT 150 798 V002 1 11-1

Glossary of terms Function Description Release 11
IED Intelligent Electronic Device
IIN Internal Indication
IOC I/O Controller (Controller on I/O Board)
IOD Input Output Data
IOM I/O Bus Master (Function of SLC)
ITI Integrated Totals Input
MFI Analog Measured value Floating Input
MPU Main Processing Unit
NCC Network Control Center
PB Peripheral Bus
PBP Peripheral Bus Processor
PDP Process Data Processing
PLC Programmable Logic Control
PPP Point-to-Point Protocol
PSU Power Supply Unit
RCD RTU Configuration Data
RCO Regulation step Command Output
RNDIS Remote Network Driver Interface Specification
RTC Real Time Clock
SBO Select before Operate
SCADA Supervision, Control and Data Acquisition
SCI Sub-Device Communication Interface
SCO Single Command Output
11-2 1KGT 150 798 V002 1 ABB AG

Function Description Release 11 Glossary of terms
SEV System Event
SLC Serial Line Controller
SNMP Simple Network Management Protocol
SOC Strobe Output Channel
SOE Sequence-of-Event Queue
SPI Single Point Input
TSI Time Synch Input
TSO Time Synch Output
UDP User Datagram Protocol
USB Universal Serial Bus
ABB AG 1KGT 150 798 V002 1 11-3

Note:
We reserve the right to make technical changes or modify the contents of
this document without prior notice. With regard to purchase orders, the
agreed particulars shall prevail. ABB AG does not accept any responsibility
whatsoever for potential errors or possible lack of information in this
document.
We reserve all rights in this document and in the subject matter and
illustrations contained therein. Any reproduction, disclosure to third parties
or utilization of its contents – in whole or in parts – is forbidden without prior
written consent of ABB AG.
Copyright© 2013 ABB

All rights reserved.

RTU560 As IEC 61850 Gateways PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RTU560 As IEC 61850 Gateways PDF

Загружено:

Авторское право:

Доступные форматы

RTU500 series Remote Terminal Unit

Function Description Release 11

ABB AG 1KGT 150 798 V002 1

2 Host communication interface ................................................... 2-1

3 Subdevice communication interface ......................................... 3-1

ABB AG 1KGT 150 798 V002 1 I

3.3 General interrogation .......................................................................... 3-4

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

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

II 1KGT 150 798 V002 1 ABB AG

6 Redundancy ................................................................................ 6-1

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

ABB AG 1KGT 150 798 V002 1 III

7.4 Time synchronization modes ............................................................. 7-9

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

9 Status and diagnostic information ............................................ 9-1

IV 1KGT 150 798 V002 1 ABB AG

9.3.4 Communication interface states ................................................... 9-17

10 System data interface ............................................................... 10-1

11 Glossary of terms ..................................................................... 11-1

ABB AG 1KGT 150 798 V002 1 V

1.1 About the RTU500 series Function Description

Document identity Part name Explanation

Table 1: Parts of the Function Description

ABB AG 1KGT 150 798 V002 1 1-1

1-2 1KGT 150 798 V002 1 ABB AG

2 Host communication interface

Figure 1: RTU500 series network

2.1 Physical interfaces

ABB AG 1KGT 150 798 V002 1 2-1

For detailed information about available interface and protocol combinations of

2.2 Monitoring direction

2.3 Command direction

2.4 General interrogation

2.5 Filtering of information

2.6 Supervision of connection to host systems

2-2 1KGT 150 798 V002 1 ABB AG

2.7 Queue and buffer handling

2.7.1 Handling of overflow situations

Loss of changes of information

Loss of pulse counters

ABB AG 1KGT 150 798 V002 1 2-3

2.7.2 Queue storage timeout

2.8 Overview of the software structure

Application Layer Application Layer

Internal Communication (IC)

Figure 2: Interface to IC – Application layer – Link layer

2-4 1KGT 150 798 V002 1 ABB AG

3 Subdevice communication interface

Figure 3: RTU500 series network

ABB AG 1KGT 150 798 V002 1 3-1

Application Layer Application Layer

Figure 4: Internal structure of the SCI

3.1 Data flow in monitoring direction

3.2 Command direction

3-2 1KGT 150 798 V002 1 ABB AG

3.2.2 Command output procedures

Parameter name Parameter location

Process command interlocking mode RTU parameter

ABB AG 1KGT 150 798 V002 1 3-3

Parameter value Explanation

Table 2: Output procedures for interlocking

3.3 General interrogation