E500 FD Rel11 Part6 RTU Functions

RTU500 series Remote Terminal Unit
Function Description Release 11

Part 6: RTU500 Functions


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

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

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

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

ABB AG 1KGT 150 798 V002 1 V
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 1-1
1 Introduction
1.1 About the RTU500 series Function Description
The Function Description consists of several parts:

Document identity Part name Explanation
1KGT 150 793 Part 1: Overview Overview of the RTU500
series and system architecture
1KGT 150 794 Part 2: Rack Solutions Description of the RTU500
series rack solutions
1KGT 150 795 Part 3: DIN Rail
Solutions
Description of the RTU500
series DIN rail solutions
1KGT 150 796 Part 4: Hardware
Modules
Overview of the RTU500
series rack and DIN rail
modules
1KGT 150 797 Part 5: SCADA
Functions
series SCADA functions
1KGT 150 798 Part 6: RTU500
Functions
series functions
1KGT 150 799 Part 7: Archive
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
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

Introduction Function Description Release 11
References
1-2 1KGT 150 798 V002 1 ABB AG
1.3 References

[1] 1KGT 150 801 RTUtil500 Users
Guide
Release 11
Describes the usage of engineering
tool RTUtil500 of the RTU500 series
[2] Individual Ident RTU500 series
Protocol
Descriptions
Description of the Sub and Host
Communication Protocols
[3] 1KGT 150 853 Interfaces and
Protocols
Release 11
Description of the relationship of
interfaces and protocols
[4] RFC1157 A Simple
Network
Management
Protocol (SNMP)

[5] RFC1213 Management
Information Base
for Network
Management of
TCP/IP-based
internets: MIB-II
(second version)

[6] 1KGT 150 802 RTU500 series
Web Server
User's Guide


ABB AG 1KGT 150 798 V002 1 2-1
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.
Host communication interface Function Description Release 11
Monitoring direction
2-2 1KGT 150 798 V002 1 ABB AG
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
Function Description Release 11 Host communication interface
Queue and buffer handling
ABB AG 1KGT 150 798 V002 1 2-3
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.
Host communication interface Function Description Release 11
Overview of the software structure
2-4 1KGT 150 798 V002 1 ABB AG
Further diagnosis information about the internal status of the concerned host
communication interfaces are added to the system diagnosis of the RTU.

2.7.2 Queue storage timeout
If the connection to a host system is offline for any given time, the queue content
can be saved into a process image after a configured time to avoid reporting of
information. The image can be processed at a configured time. In this case, all
changes of information are lost and the current process values have to be read by
the host system using a general interrogation.
Detailed diagnostic information about queue storage timeouts of the relevant host
communication interfaces are added to the system diagnosis of the RTU (see
chapter Status and diagnostic information (page 9-1)).
2.8 Overview of the software structure
The internal software of Host Communication Interfaces (HCI) follows a three-layer
architecture:
Interface to Internal Communication (IC)
Application layer in monitoring and command direction
Link layer
Internal Communication (IC)
Host Communication
Interfaces (HCI)
Interface to
Internal
Communication
Link Layer
Application Layer
Command Direction
Application Layer
Monitoring Direction
NCC

Figure 2: Interface to IC Application layer Link layer


ABB AG 1KGT 150 798 V002 1 3-1
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.
Subdevice communication interface Function Description Release 11
Data flow in monitoring direction
3-2 1KGT 150 798 V002 1 ABB AG
Ethernet- and TCP/IP-based protocols can be used only with Ethernet interfaces.
The structure of the SCI is independent of the protocol and shown in the following
figure.
Internal Communication
Sub-Device
Communication
Interface (SCI)
Interface to
Internal
Communication
Sub-Device
Link Layer
Application Layer
Command Direction
Application Layer
Monitoring Direction

Figure 4: Internal structure of the SCI

3.1 Data flow in monitoring direction
The link layer checks any messages received from a subordinate device for validity
with regard to the message format specified for the configured protocol. If the
message is valid, it is handed over to the application layer for the monitoring
direction.
The application layer for the monitoring direction decodes the user data. All values,
flags, and other information, are mapped to the RTU's internal format. (For details
on the mapping of message data to the RTU's internal format, refer to the Interface
Description for the relevant protocol.)
If the user data is valid and configured as being a part of this SCI, it is forwarded to
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.
Function Description Release 11 Subdevice communication interface
Command direction
ABB AG 1KGT 150 798 V002 1 3-3
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

Subdevice communication interface Function Description Release 11
General interrogation
3-4 1KGT 150 798 V002 1 ABB AG
Parameter value Explanation
Interlocking per IO device / IO bus and
group
Selection is interlocked against other
commands of the same I/O device (e.g.
subordinate RTUs, IEDs) and the same
command group. Valid command
groups are:
Object Commands Outputs (SCO,
DCO)
Regulation Commands Outputs
(RCO)
Setpoint Commands Outputs (ASO,
DSOx)
Bit-string outputs (BSOxx)
Interlocking per object Selection is interlocked only against the
same object
Interlocking per object with command
priority
Selection is interlocked only against the
same object, but selection can be
overridden by a command originating
from an originator (e.g., HCI, PLC,
Integrated HMI) with higher command
priority.
The HCIs with the lowest host numbers
have the highest priority, followed by
PLCs, Integrated HMIs and web servers
of the RTU500 series.
Select and execute commands can
override the selection.
Table 2: Output procedures for interlocking
In the event that a process command is rejected because of a selection mismatch
or a pending command confirmation, a system event message of the type
SEV#242 .. SEV#260: Process command collision with command of X is sent to
the originator of the rejected command. The system event message contains
information about the originator sending the command that caused rejection.

3.3 General interrogation
The general interrogation command is automatically executed by the SCI in the
following situations:
During system start-up
In the event of a redundancy switchover (also to update the process data
from subordinate devices if the relevant CMU board is not part of the
redundant system)
When the line state of the subordinate device has changed from offline to
online
If the general interrogation command is not supported by the configured protocol,
the SCI simulates a general interrogation, e.g., by reading all values or using other
procedures, to obtain the actual values of the subordinate devices.

Function Description Release 11 Subdevice communication interface
Time synchronization
ABB AG 1KGT 150 798 V002 1 3-5
3.4 Time synchronization
Time synchronization of a subordinate device is autonomously managed by the
SCI and implemented only if supported by the configured protocol.
Time synchronization needs to be configured once for every sub-line. Only one
time synchronization mode can be configured per line.


Time interval of clock synchronization
commands
Line parameters

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

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

3.5 System events
The SCI manages and controls system events for each device that is connected to
the line.
Several SEVs are controlled by the SCI. They depend on the configuration of the
SEV in RTUtil500 and on the type of device, e.g., IED, RTU.
For more details, see chapter System events (page 10-1).


ABB AG 1KGT 150 798 V002 1 4-1
4 Substation automation system with IEC 61850
4.1 RTU500 series in an IEC61850 system
As an IEC 61850 client, the RTU500 series provides NCC gateway functionality by
connecting an IEC 61850 station bus to NCCs. As an IEC 61850 server, the RTU
operates as an IEC 61850 IED, providing data to an IEC 61850 network from
subordinate devices or signals that are directly connected. The figure below shows
integration of the RTU in an IEC 61850 system.
Station bus IEC 61850-8
Process level
Bay level
Station level
IEC 60870-5-101 / IEC 60870-5-104
DNP / DNP over LAN/WAN
Network Control level
Network Control
Center
Diagnosis
Integrated
HMI
Gateway
RTU560
IED 1 IED 2 IED 3
Integrated
HMI
RTU560
server
RTU560 client

Figure 5: Integration of RTU500 series in an IEC 61850 system
The standard functions of the RTU500 series, such as local I/Os and connections
via legacy protocols, are available in both the client and the server configuration.

4.2 IEC61850 configurations
Using RTUtil500, you can configure an RTU as an IEC 61850 client, an IED or an
IEC 61850 server IED. Separate projects are required if different IED types need to
be configured.
It is not possible to configure an entire IEC 61850 network with multiple RTU clients
or servers in a single project.
The following chapters show examples of RTU client and server configurations.

Substation automation system with IEC 61850 Function Description Release 11
IEC61850 configurations
4-2 1KGT 150 798 V002 1 ABB AG
4.2.1 RTU500 series configured as IEC 61850 client
As an IEC 61850 client, the RTU connects NCCs with an IEC 61850 network.
Additional local I/Os and connections via legacy protocols are possible. In this
configuration, the RTU does not support any GOOSE communication.
For more information, refer to the relevant protocol description.
The following figure shows an RTU500 series that is configured as an IEC 61850
client.
IEC61850-8-1
IED IED
RTU560
(NCC GW)
IEC101
Slave
HCI
Local I/O PLC HMI
SCI
IED IED
e.g.
IEC103
IEC103
Master
IEC61850
Client
NCC
connection

Figure 6: RTU500 series configured as a IEC 61850 client

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

CAUTION
In this configuration the RTU supports horizontal GOOSE communication with
other IEC 61850 IEDs as well. The GOOSE data received from the IEC 61850
network could be used only in a PLC application.
Function Description Release 11 Substation automation system with IEC 61850
IEC61850 configurations
ABB AG 1KGT 150 798 V002 1 4-3

The following figure shows an RTU that is configured as an IEC 61850 server.
IEC61850-8-1
IED IED
RTU560
(RTU-IED)
IEC61850
Server
HCI
Local I/O PLC HMI
SCI
IED IED
e.g.
DNP3
e.g.
IEC103
IEC103
Master
DNP3
Master
GOOSE

Figure 7: RTU500 series as an IEC 61850 server
For a detailed description of the engineering process, refer to the corresponding
chapter in the RTUtil500 User's Guide.


ABB AG 1KGT 150 798 V002 1 5-1
5 Programmable Logic Control (PLC)
This chapter describes the PLC function, which is the RTU500 series' runtime
system for control applications. The PLC function has been designed in
accordance with IEC 61131-3. For systems engineering, version 2.11 of the
MULTIPROG wt programming and debugging system is used.

5.1 PLC SCADA processing
The PLC is an integral part of the RTU system and is used to exchange data with
SCADA.
PLC
function
RTU560
Config-
files
.
.
Boot
project
file
.
.
PLC
OUTPUT
memory
(Q)
PLC
INPUT
memory
(I)
PLC
internal
flag
memory
SCADA
Internal
Communication
from / to Network Control Center
from / to I/O hardware
from / to sub RTU
from / to MULTIPROG wt
PLC
program
memory

Figure 8: PLC SCADA processing in RTU500 series
The figure above shows the basic elements of the PLC in interaction with SCADA.
They are described in the following chapters.

5.1.1 PLC function
The PLC function is a licensed software package. It enables a CMU to run PLC
applications, and to communicate with MULTIPROG wt for loading and debugging
applications. After the function has been added to the configuration, it is started at
boot time of the CMU.
Once started on a CMU, the PLC function is running in shared mode with low
priority compared to the SCADA software.
It is possible to design a configuration in which PLC function and SCADA activities
run on different CMUs. Since both communicate via Internal Communication, the
PLC function may run on any CMU within the RTU. This approach provides
maximum processing power to each activity.

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

Figure 9: I/O interface of a PLC

Input process image
The data relevant to the PLC is filtered from Internal Communication, and is written
to the corresponding process image for commands, messages, system events or
system commands. The maximum number of entries in the process image
depends on the data type.
The n-stage process image contains the oldest n-1 changes as received from
Internal Communication while the PLC task is being processed, as well as the
current value. If more than n-1 changes are received, any changes of information
between the n-1 received value in the image and the current value are lost.

Redundancy switchover activities
If a controlled switchover occurs between two redundant CMUs, the active CMU
stops the activities and performs an internal restart. The line driver on the
communication interfaces will switch to high impedance of the tri-state.
The standby CMU will continue the start procedure. From the viewpoint of the
RTU560 system, it is a warm start. The now active CMU starts communication on
the serial lines and initializes communication to their host and subordinated
devices. The I/O boards will not perform a reset. The PDP module takes over
communication on the RTU560 peripheral bus and reads all values from the I/O
boards.
5-4 1KGT 150 798 V002 1 ABB AG
The actual state of all CMUs in a (non-)redundant configuration is indicated by
SEVs #149 to #164 and #224 to #239:
SEV (#149 #164) CMU #x is inoperable, 1 x 16
SEV (#224 #239) CMU #x is active, 1 x 16
A redundant pair of communication units will report the following SEV states:

CMU Normal operation One CMU is faulty

SEV 149
164
(inoperable)
SEV 224
239 (active)
SEV 149
164
(inoperable)
SEV 224
239 (active)
Active CMU No Yes No Yes
Standby CMU No No Yes No
Table 3: SEV states

Input handler
At the beginning of each PLC task cycle, the task executes an input handler. The
input handler evaluates the data point signals in the input process image that were
received in the meantime. Any signals configured for the task are transferred to the
INPUT memory of the PLC. If multiple occurrences of a signal are waiting in the
queue, the input handler transfers only the first occurrence to the INPUT memory
and writes the remaining signals back to the queue for processing in the next PLC
task cycle.
For any commands received, the input handler sets the corresponding SE (select)
or EX (execute) flag of the PLC data type in the INPUT memory to TRUE. This
setting applies to a single task cycle and depends on the Select state of the
received command. For details, see the following table:

Received SCADA
Select state of
command
PLC EX state PLC SE state
0 TRUE (for one
cycle)
FALSE
1 FALSE TRUE (for one cycle)
Table 4: Select and Execute states for commands in INPUT memory

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

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

Data point type Data point send condition
SPI, DPI, STI, DMIx,
BSIx, ITI
The Value flag, or any quality flag, has changed
compared to last task cycle.
AMI, MFI Any quality flag has changed compared to last task
cycle or the TR (transmit) flag is set.
Function Description Release 11 Programmable Logic Control (PLC)
ABB AG 1KGT 150 798 V002 1 5-5
Data point type Data point send condition
SCO, DCO, RCO, ASO,
BSOx, DSOx, FSO
The SE (select) or EX (execute) flag has a status
change compared to the last task cycle and COT
(cause of transmission) is not zero.
SSC The EX (execute) flag has a status change compared to
the last task cycle and COT (cause of transmission) is
not zero.
Table 5: Data point Send conditions for the PLC output handler

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

Messages and commands
Process data points that can be connected via hardware can be defined from the
I/O hardware or sub RTU (both are referred to as I/O device hereafter) using a PLC
function.
This function also allows the definition of virtual process data points. Virtual
process data points are handled by a network control center (NCC) in the same
way as process data points but are not processed by the I/O device.
Network Control Center (NCC)
I/O Processing or Sub RTU
PLC
PLC used
command
PLC used
message
Virtual
message
Virtual
command
Normal
command
Normal
message
Confirm.

Figure 10: Signal flow between NCC, PLC, and I/O device
The figure above shows, in principle, the logical signal flow of messages and
commands between NCC and I/O device.
The following signal types are supported by the PLC:
Virtual message
Adding a virtual message to a PLC task in the configuration enables the PLC
to send a message to the NCC. This message cannot be sent by the I/O
device. Virtual messages are represented in the OUTPUT memory of the
PLC.
Virtual command
Adding a virtual command to a PLC task in the configuration enables the
PLC to receive this command from the NCC and return the confirmations. As
the command is invisible to the I/O device, the I/O device is unable to
execute it. Virtual commands for activation or deactivation are represented in
the INPUT memory. Virtual commands for confirmations are represented in
the OUTPUT memory.
5-6 1KGT 150 798 V002 1 ABB AG
Message used by PLC
Messages are part of the regular signal flow between I/O device and NCC.
Selecting a message data point for use by the PLC in the configuration
enables the PLC to receive this message. Messages used by the PLC are
represented in the INPUT memory of the PLC.
Command used by PLC
Commands are part of the regular signal flow between I/O device and NCC.
Selecting a command data point for use by the PLC in the configuration
enables the PLC to send and receive the command and the confirmations.
Commands for activation or deactivation used by the PLC are represented in
the OUTPUT memory. Commands for confirmations used by the PLC are
represented in the INPUT memory.

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

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

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

System event messages
There are two SEVs available for signaling the state of active PLC tasks:
System Event #046: At least one PLC function not running
System Event #047: At least one PLC cycle time exceeded

Characteristic technical data

Property Value
1000 Boolean instruction lines approx. 10 ms
1000 BOOL8 and INT instruction lines approx. 10 ms
Shortest task cycle period configurable 10 ms
Memory capacity (program/data)
absolute
8 MB configurable
Program memory consumption approx. 10 kB per 1 000 instructions
Program memory capacity per POU 64 kB
I/O image capacity configurable max. 2 000 INPUT and 2 000 OUTPUT
signals
Maximum number of user tasks 15
Table 6: Characteristic technical data


ABB AG 1KGT 150 798 V002 1 6-1
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.
Redundancy Function Description Release 11
RTU560 redundant CMU concept
6-2 1KGT 150 798 V002 1 ABB AG

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)

Function Description Release 11 Redundancy
ABB AG 1KGT 150 798 V002 1 6-3
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.

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

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

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

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


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.

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

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.

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


ABB AG 1KGT 150 798 V002 1 7-1
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.
Start-up, Configuration and Time Management Function Description Release 11
Start-up procedures
7-2 1KGT 150 798 V002 1 ABB AG
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:
Function Description Release 11 Start-up, Configuration and Time Management
Start-up procedures
ABB AG 1KGT 150 798 V002 1 7-3
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'

RTU500 series configuration
7-4 1KGT 150 798 V002 1 ABB AG
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).

RTU500 series Time Management
ABB AG 1KGT 150 798 V002 1 7-5
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:

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.

Figure 16: Time administration master and time administration slave
dependencies

Year Month Day Hour Minute Second
1980 01 01 00 00 00
10 kHz
TSO
Time
Slave
RTU560 Internal Communication
TSI
Time
Master
Time
Message
Time
Message
Time
Slave
Time
Message
Logic Logic Logic
7-6 1KGT 150 798 V002 1 ABB AG
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 slaves 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.

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

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:


Time administration RTU parameters
7-8 1KGT 150 798 V002 1 ABB AG
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".

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.


Time synchronization lost RTU parameters
Time synchronization modes
ABB AG 1KGT 150 798 V002 1 7-9
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 oclock
For the year 2005, the rule specifies the following date:
10-29-2005, 3 oclock


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

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

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

ABB AG 1KGT 150 798 V002 1 7-13

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

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

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).

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

Synchronization of sub-RTUs
ABB AG 1KGT 150 798 V002 1 7-17
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.
+ 5 ms
NCC
RTU 560
CS-Command
RTU 560
CS-Command
RTU 560
CS-Command
+ 5 ms
+ 5 ms
+ 10 ms
+ 15 ms

Figure 22: Time accuracy in a multi-level network (only clock synchronization
commands)

7-18 1KGT 150 798 V002 1 ABB AG
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
ABB AG 1KGT 150 798 V002 1 7-19
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 8-1
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.
Input signal state
Output signal state
Relocation register
for ITI
FIFO
Parameter
register
Requests
Dialog registers
Status etc.
IOC
Bus-
module
I/O
Task
I/O
Part
RAM
MPU
SLC
CMU
I/O Board

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.
RTU500 series I/Os and I/O bus interface Function Description Release 11
I/O bus master and RTU500 series I/O
8-2 1KGT 150 798 V002 1 ABB AG
The bus module handles the dialog RAM for the I/O task. The I/O task is
board-specific.
Is there any event
message within subrack ?
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
More events
in subrack ?
Poll one board and read board status
Increment board pointer
Subrack: = subrack + 1
Address next board with event
Read event flag of subrack
All subracks polled
for events ?
Subrack: = 1
NO
YES
YES
NO
NO
YES
Store board status into
RAM to MPU
Board status o.k.
?
NO
YES
Command output requests will be inserted if pending

Figure 25: Event polling by MPU

Function Description Release 11 RTU500 series I/Os and I/O bus interface
Event flow through RTU500 series
ABB AG 1KGT 150 798 V002 1 8-3
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 9-1
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):
Status and diagnostic information Function Description Release 11
RTU alarms and warnings
9-2 1KGT 150 798 V002 1 ABB AG
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.
Function Description Release 11 Status and diagnostic information
ABB AG 1KGT 150 798 V002 1 9-3
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
text
Cause Corrective
measure
Error status
1.1 At least one
indication faulty
See SEV#016 for
more details

1.2 All indications
correct
See SEV#016 for
more details

2.1 At least one analog
value faulty
See SEV#017 for
more details

2.2 All analog values
correct
See SEV#017 for
more details

3.1 At least one digital
value faulty
See SEV#018 for
more details

3.2 All digital values
correct
See SEV#018 for
more details

4.1 At least one pulse
counter value faulty
See SEV#019 for
more details

4.2 All pulse counters
correct
See SEV#019 for
more details

5.1 At least one object
or regulation
command faulty
See SEV#020 for
more details

5.2 All object or
regulation
commands correct
See SEV#020 for
more details

6.1 At least one analog
output faulty
See SEV#021 for
more details

6.2 All analog outputs
correct
See SEV#021 for
more details

7.1 At least one digital
output faulty
See SEV#022 for
more details

7.2 All digital outputs
correct
See SEV#022 for
more details

8.1 External clock
inoperable
See SEV#026 for
more details

8.2 External clock
operable
See SEV#026 for
more details

8.3 RTU is not
synchronized
See SEV#025 for
more details

8.4 RTU is synchronized See SEV#025 for
more details

9.1 Power supply failure
in RTU central sub
rack
See SEV#059 for
more details

9-4 1KGT 150 798 V002 1 ABB AG
No. System message
text
Cause Corrective
measure
Error status
9.2 Power supply OK in
RTU central sub
rack
See SEV#059 for
more details

10.1 Configuration Error
on CMU in rack x,
slot y: WRONG
RACK OR SLOT
ADDRESS
Wrong rack
address
Check the
rack address.
Alarm
Wrong slot
address
Check the slot
address,
Alarm
Configuration
does not fit to
hardware
Check and
reload the
configuration.
Alarm
10.2 Configuration error
on CMU in rack x,
slot y: RCD file date
Different RCD
files stored in at
least two CMUs
With CMU
integration:
Wait for the
CMU to
reboot.
Without CMU
integration:
Reload the
configuration
file.
Alarm
RCD file(s)
missing
With CMU
integration:
Wait for the
CMU to
reboot.
Without CMU
integration:
Reload the
configuration
file.
Alarm
on CMU in rack x,
slot y: RCD file size
Error during RCD
file transfer
With CMU
integration:
Wait for the
CMU to
reboot.
Without CMU
integration:
Reload the
configuration
file.
Alarm
on CMU in rack x,
slot y: Password
Different
password
settings in CMUs
Redefine the
password
using the web
server
interface
(based on
default
setting).
Alarm
ABB AG 1KGT 150 798 V002 1 9-5
No. System message
text
Cause Corrective
measure
Error status
on CMU in rack x,
slot y: NO
ACTIVITIES
CONFIGURED
CMU is
configured but no
function is added
Add the
missing
function, such
as a line, a
peripheral
bus, or a PLC
on the CMU.
-
on CMU in rack x,
slot y: OK
Booting CMU has
successfully
loaded
configuration
file(s) from
another (running)
CMU
OK
12.1 Firmware error on
CMU in rack x, slot y
version Vn.xx
Different
firmware
detected on at
least two CMUs
Load the
correct
firmware.
Ensure that
the same
firmware
release (first
digit of the
release
number) is
installed on all
CMUs.
Alarm
12.2 No firmware error on
CMU in rack x, slot y
OK
13 <Activity type>
<Activity ObjectID>
on CMU in rack x,
slot y <Activity
state>. <Activity
error type>
see Activity state
and Activity error
types
See Activity
state and
Activity error
types
Warning /
Alarm
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
9-6 1KGT 150 798 V002 1 ABB AG
No. System message
text
Cause Corrective
measure
Error status
1 starting up Activity was
started and is
initializing

2 running Activity is in
normal
processing state

3 stopped Activity was
stopped because
of a configuration
error or internal
error
See Activity
error types.

4 error Activity is no
longer able to
react, possibly
due to a CMU
overload
Shrink
configuration
or reduce
activities on
this CMU. See
also Activity
error types.

Activity error types
1 Function not
included in firmware.
Load the
correct
firmware.

2 License is missing. Activity type not
licensed
Request a
license key
and load it
into the RTU.

3 Supervision error
occurred.
Activity is
processing due
to a CMU
overload
Shrink the
configuration.

4 Allocation of
memory failed.
Insufficient
system memory
Shrink the
configuration.

5 Spawn of task
failed
Insufficient
system memory
Shrink the
configuration.

6 No I/O devices
configured on line.
Add I/O
devices to
activity in
RTUtil500.

7 Maximum number
of possible I/O
devices exceeded.
Remove I/O
devices from
activity in
RTUtil500

8 No process data
configured on line.
At least one
process
datum needs
to be
configured for
this activity.

9 Overlap of process
addresses at
'<ProcDataObjectID
>'.
<ProcDataObject
ID> is the object
ID text configured
in RTUtil500
Check the
configuration
for correct
process
addresses.

ABB AG 1KGT 150 798 V002 1 9-7
No. System message
text
Cause Corrective
measure
Error status
10 No telephone
number configured
for dialup server.
Dial-up
configuration
does not contain
any telephone
number
Configure at
least one valid
phone number
for the dial-up
line.

11 RCD
configuration file not
found
Configuration
files were not
properly loaded.
Upload the
missing file to
the RTU.

14 Activity is still
alive.
After a temporary
CMU overload,
an activity
marked with
<activity state>
error is
processing again.
Shrink the
configuration
or reduce the
number of
activities on
this CMU.

14.1 CMU in rack x, slot
y: STARTUP
CMU performed
a reset
Wait for
STARTUP
READY.
Alarm
14.2 CMU in rack x, slot
y: STARTUP
READY
CMU started
successfully
OK
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
inoperable
See SEV#062 for
more details

20.1 RTU B is operable See SEV#063 for
more details

20.2 RTU B is
inoperable
See SEV#063 for
more details

22.1 PLC warning
condition ON
(NON_EXCLUSIVE)
PLC calls
WARNING_OUT
* with
parameters:
Value = TRUE
and EXCL =
FALSE
Corrective
measures
depend on the
PLC
application
Warning
22.2 PLC warning
condition ON
(EXCLUSIVE)
PLC calls
WARNING_OUT
* with
parameters:
Value = TRUE
and EXCL =
TRUE
Corrective
measures
depend on the
PLC
application
Warning
9-8 1KGT 150 798 V002 1 ABB AG
No. System message
text
Cause Corrective
measure
Error status
22.3 PLC warning
condition OFF
(NON_EXCLUSIVE)
PLC calls
WARNING_OUT
* with
parameters:
Value = FALSE
and EXCL =
FALSE
Corrective
measures
depend on the
PLC
application
OK
22.4 PLC warning
condition OFF
(EXCLUSIVE)
PLC calls
WARNING_OUT
* with
parameters:
Value = FALSE
and EXCL =
TRUE
Corrective
measures
depend on the
PLC
application
OK
23.1 PLC alarm condition
ON
(NON_EXCLUSIVE)
PLC calls
ALARM_OUT*
with parameter:
Value = TRUE
Corrective
measures
depend on the
PLC
application
Alarm
23.2 PLC alarm condition
OFF
(NON_EXCLUSIVE)
PLC calls
ALARM_OUT*
with parameter:
Value = FALSE
Corrective
measures
depend on the
PLC
application
OK
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
failed
See SEV#030 for
more details

26.2 AC power supply
O.K.
See SEV#030 for
more details

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

31.2 PIN initialization
successful
The PIN
initialization has
failed before.
Now the PIN
initialization of a
GSM modem
was successful.

9-10 1KGT 150 798 V002 1 ABB AG
No. System message
text
Cause Corrective
measure
Error status
32.1 At least one modem
blacklisted
Because of 12
unsuccessful
dial-up attempts,
the connected
dial-up modem is
blacklisted for
the next two
hours (*).
Check the
dial-up
numbers in
the RTUtil500
configuration
file.
Check that all
partners are
available.
Increase the
time between
two dial
attempts.

32.2 No more modems
are blacklisted
At least one
dial-up modem
was blacklisted
before. Now
(after two hours)
all modems are
available again.

33.1 x. Cmd supervision
circuit disconnected
or faulty
See SEV#064
#095 for more
details

circuit is O.K.
See SEV#064
#095 for more
details

34.1 PDP interface on
CMU #x running.
Command not
switched through
due to
active local check
function
process voltage
missing
23BA22 /
23BA23 internal
fault
An error with
23BA22 /
23BA23 was
detected during
command
execution.
Replace
23BA22 /
23BA23,
reconnect
process
voltage.
Operate
LOCAL/REM
OTE switch.

circuit is O.K., 1 x
32
The command
supervision
circuit 23BA22 /
23BA23 is O.K.
again.
This message is
generated when
a command is
successfully
executed.

ABB AG 1KGT 150 798 V002 1 9-11
No. System message
text
Cause Corrective
measure
Error status
CMU #x running.
Lower limit
resistance value
underflow.
x. CMD supervision
or faulty,
1 x 32
The command
supervision
circuit has
detected during
command
execution that
the resistance of
the connected
coil is lower than
the lower limit
resistance value.
Check and
correct the
process
connections.
Maybe the
lower limit
resistance
value has to
be adapted.

32
This message is
generated after
the lower limit
underflow
message when
the next
command is
successfully
executed.

CMU in rack y, slot z
running. Upper limit
resistance value
overflow.
x. CMD supervision
or faulty,
1 x 32
The command
supervision
circuit has
detected during
command
execution that
the resistance of
the connected
coil is higher than
the upper limit
resistance value.
Check and
correct the
process
connections.
Maybe the
upper limit
resistance
value has to
be adapted.

32
This message is
generated after
the upper limit
overflow
message when
the next
command is
successfully
executed.

37.1 Host interface line
<name> on CMU #x
running. Queue
storage timed out.
Entries written to
process image.
The host
interface <name>
is OFFLINE and
the queue
storage timeout
timer has
expired. The
contents of the
host queues is
written to the
process image
and the queues
are cleared

9-12 1KGT 150 798 V002 1 ABB AG
No. System message
text
Cause Corrective
measure
Error status
<name> on CMU #x
running. Queue
storage active again.
The host
interface <name>
is ONLINE again.
Process data is
written to the
queue.

<name> on CMU #x
running. Priority z
queue switched to
image mode.
The priority z
queue of the host
interface <name>
is full. The
content of the
queue is written
to the process
image and the
queue is cleared.
Enlarge the
size of this
queue z.

<name> on CMU #x
running. Priority z
queue switched
back to queue
mode.
The host
interface <name>
is ONLINE again.
Process data is
written to the
queue.

<name> on CMU #x
running. Pulse
counter queue starts
to displace old IR
entries.
The ITI queue of
the host interface
<name> is full.
New EPR pulse
counter values
will replace old IR
entries.
Enlarge the
size of this
queue.

<name> on CMU #x
running. Queue
The host
interface <name>
is ONLINE again.
ITIs are written to
the queue again.

<name> on CMU #x
running. Pulse
counter queue starts
to displace old EPR
entries.
The ITI queue of
the host interface
<name> is full.
New EPR pulse
counter values
will replace old
EPR entries.
Enlarge the
size of this
queue.

<name> on CMU #x
running. Queue
The host
interface <name>
is ONLINE again.
ITIs are written to
the queue again.

Task error on CMU
#x
A software
malfunction
occurred on CMU
#x. The CMU
performs a reset
if a malfunction is
detected.
Alarm
ABB AG 1KGT 150 798 V002 1 9-13
No. System message
text
Cause Corrective
measure
Error status
Gateway routing
failed for CMU #x
Configured
backplane
routing failed.
Check the
configured IP
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
indication is
oscillating
See SEV#028 for
more details

43.2 All indications stable See SEV#028 for
more details

44.1 At least one DCE
faulty
See SEV#044 for
more details

44.2 ALL DCE okay See SEV#044 for
more details

45.1 Device not
connected
See SEV#045 for
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
synchronized
See SEV#096
#097 for more
details

47.2 SNTP Client x
synchronized
See SEV#096
#097 for more
details

48.1 Local control
authority available
See SEV#100 for
more details

48.2 Local control
authority active
See SEV#100 for
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

9-14 1KGT 150 798 V002 1 ABB AG
No. System message
text
Cause Corrective
measure
Error status
50.2 CMU #x operable See SEV#149
#164 for more
details

54.1 Network element no.
x not operable
See SEV#192
#223 for more
details

54.1 Network element no.
x operable
See SEV#192
#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.

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

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.

ABB AG 1KGT 150 798 V002 1 9-17
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
(green)
According to data request
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.
9-18 1KGT 150 798 V002 1 ABB AG
A serial interface signals its Start-up state as follows:

Serial interface "Tx" and "Rx" LEDs
(green)
According to data transfer
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:

(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:

(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.

ABB AG 1KGT 150 798 V002 1 9-19
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
the initialization procedure.
23AA21
23BE23
23AE23
The communication module
performs a cold or warm start.
23AA21
23BE23
23AE23
The communication module has
detected a memory error
(EPROM and/or RAM).
23AA21
23BE23
23AE23
The micro-controller is defective. 23AA21
23BE23
23AE23
The peripheral bus processor did
not attempt to poll data from the
board for at least two minutes.
23AA21
23BE23
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

9-20 1KGT 150 798 V002 1 ABB AG
LED indications 23BA20 and 23BA22 or 23BA23
red
red
green
green
green
red
Error
red
red
green
Error
Process error
Test Mode circuit 2
Test Mode circuit 1
Command output
LOCAL / REMOTE
Process error
Command output
LOCAL / REMOTE
push button
23BA22
23BA20
TM1
TM0
CO
LOC

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 /
TM1
ON
OFF
(1 out of n) check is active on circuit P1 (TM0) or P2 (TM1).
The last command output performed successfully.
flashin
g
The last command output sequence was stopped because of
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
g
The communication module toggles between local and
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.
ABB AG 1KGT 150 798 V002 1 9-21
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

9-22 1KGT 150 798 V002 1 ABB AG

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.

ABB AG 1KGT 150 798 V002 1 9-23
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 RxD
RTS DCD
TxD = Send data (green)
RxD = Receive data (green)
RTS = Request to send (yellow)
DCD = Data carrier detected (yellow)
23 WT 23
TxD RxD
RTS DCD
TxD = Send data (green)
RxD = Receive data (green)
RTS = Request to send (yellow)
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

9-24 1KGT 150 798 V002 1 ABB AG
LED indications for 560RTC01
red
red
green
yellow
Error
Free running
Lock status (GPS receive signal)
Minute pulse
560RTC01
FR
LS
MN

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

ABB AG 1KGT 150 798 V002 1 9-25
red
red
green
yellow
Error
Free running
Carrier detect (DCF77 receive signal)
Minute pulse
560RTC02
FR
CD
MN


ST ON The communication module runs the initialization
procedure.
The communication module performs a cold or warm
start.
(EPROM and/or RAM).
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.

9-26 1KGT 150 798 V002 1 ABB AG


ST ON The communication module runs the initialization
procedure.
The communication module performs a cold or warm
start.
(EPROM and/or RAM).
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

ABB AG 1KGT 150 798 V002 1 9-27
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 10-1
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
offset
System
message
Value Detailed
description
Cause Error status
#016 At least one
indication faulty
ON At least one local
SPI or DPI data
point of RTU is
invalid.
The I/O board is
missing.
Warning
The I/O board is not
running.
Warning
An I/O bus
connection failure
has occurred.
Warning
All indications
correct
OFF All local SPI or DPI
data points of RTU
are valid.
- OK
#017 At least one
analog value
faulty
AMI data point of
RTU is invalid.
Note:
Overflow is not
considered by this
SEV.
The I/O board or
CVT module is
missing.
Warning
The I/O board or
CVT module is not
running.
Warning
An I/O bus or CVI
line connection
failure has occurred.
Warning
The analog settings
are not correct.
Warning
System data interface Function Description Release 11
System events
10-2 1KGT 150 798 V002 1 ABB AG
SEV
offset
System
message
Value Detailed
description
Cause Error status
All analog values
correct
OFF There is no I/O bus
error. All I/O boards
and CVT modules
with configured
analog values are
operable. No live
zero underflow was
detected.
- OK
#018 At least one
digital value faulty
DMI or BSI data
point of RTU is
invalid or a wrong
BCD coding was
detected.
The I/O board or
CVT module is
missing
Warning
The I/O board or
CVT module is not
running.
Warning
An I/O bus or CVI
line connection
Warning
A warning with
regard to BCD
coding or
configuration has
occurred.
Warning
All digital values
correct
OFF There is no I/O bus
error. All I/O boards
with configured
digital values are
operable.
- OK
#019 At least one pulse
counter value
faulty
ON At least one local ITI
data point of the
RTU is invalid.
The I/O board or
CVT module is
missing.
Warning
The I/O board or
CVT module is not
running.
Warning
An I/O bus or CVI
line connection
Warning
All pulse counters
correct
OFF All local ITI data
points of the RTU
are valid.
- OK
#020 At least one
object or
regulation
command faulty
SCO, DCO, or RCO
data point of the
RTU is invalid and
not operable.
The I/O board is
missing.
Warning
running.
Warning
The I/O bus
connection failure
has occurred.
Warning
Function Description Release 11 System data interface
System events
ABB AG 1KGT 150 798 V002 1 10-3
SEV
offset
System
message
Value Detailed
description
Cause Error status
A command
supervision board
(e.g., 23BA22 or
23BA23) is without
process voltage.
Warning
All object or
regulation
commands
correct
OFF All local SCO, DCO
or RCO data points
of the RTU are valid
and operable.
- OK
#021 At least one
analog output
faulty
ASO and SOC data
point of the RTU is
invalid and not
operable.
The I/O board is
missing.
Warning
running.
Warning
An I/O bus
connection failure
has occurred.
Warning
All analog outputs
correct
OFF All local ASO and
SOC data points of
the RTU are valid
and operable.
- OK
#022 At least one
digital output
faulty
BSO data point of
the RTU is invalid
and not operable.
The I/O board is
missing.
Warning
running.
Warning
An I/O bus
connection failure
has occurred.
Warning
All digital outputs
correct
OFF All local BSO data
points of the RTU
are valid and
operable.
- OK
#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.

#024
2
RTU active ON The RTU is able to
process as
configured.
OK
System events
10-4 1KGT 150 798 V002 1 ABB AG
SEV
offset
System
message
Value Detailed
description
Cause Error status
RTU not active OFF The RTU cannot
process as
configured.
The configuration
files of the RTU or a
connected
subdevice contain
invalid data or
required data are
missing from the
files.
Error
#025 RTU
synchronized
ON The RTU is
synchronized by the
time master as
configured.
- -
RTU not
synchronized
OFF The time of the RTU
is not synchronized
and may deviate
from the time of the
time master.
No time
synchronization
signal is received
from the 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
inoperable
ON The configured
external RTC clock
is inoperable.
The RTU has not
been synchronized
yet by 560RTC0x.
Warning
An RTC or minute
pulse is missing.
Warning
An RTC antenna
error has occurred.
Warning
External clock
operable
OFF The configured
external RTC clock
is operable.
- OK
#027 Local printer
offline
ON The local printer is
not working or out of
order.
A printer connection
-
The printer is offline. -
No paper available -
Local printer
online
OFF The local printer is
running.
- -
#028 At least one
indication
oscillating
SPI or DPI data
point is oscillating
(Oscillating
suppression active).
The input signal
oscillates within the
configured limits.
Warning
All indications
stable
OFF All configured SPI or
DPI data points are
stable.
- OK
System events
ABB AG 1KGT 150 798 V002 1 10-5
SEV
offset
System
message
Value Detailed
description
Cause Error status
#029 Battery voltage
low
ON Backup battery is
not charged.
The battery is
defect.
Warning
Check connection to
battery.
Warning
Battery voltage
OK
OFF Backup battery is
charged.
- OK
#030 AC power supply
failure
ON AC power supply is
defective. RTU is
running on backup
battery.
No AC power is
available.
Warning
The power supply
unit is defect.
Warning
AC power supply
OK
OFF AC power supply is
available.
- OK
#044 At least one DCE
faulty
ON At least one data
communication
equipment (DCE) is
missing or not
responding.
The DCE is switched
off.
-
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.
- -
#045
1
Device connected ON The connection to
the device is
established via
dial-up.
- -
Device not
connected
OFF The connection to
the device via
dial-up is currently
not established.
No reportable data
were received from
the device.
-
No cyclic dial-up call
from the RTU to the
device is pending.
-
#046 At least one PLC
function not
running
ON At least one
configured PLC
function of the RTU
is not running.
No boot project was
loaded.
Warning
A PLC license is
missing on the CMU,
Warning
An exception in a
PLC user program
has occurred.
Warning
System events
10-6 1KGT 150 798 V002 1 ABB AG
SEV
offset
System
message
Value Detailed
description
Cause Error status
All PLC functions
running
OFF All configured PLC
functions of the RTU
are running.
- OK
#047 At least one PLC
function cycle
time exceeded
ON The cycle watchdog
time of at least one
PLC task was
exceeded.
The PLC execution
cycle time was
longer than the
watchdog time. The
PLC function is
restarted.
Warning
All PLC function
cycle time OK
OFF All PLC task cycle
times are within the
configured
watchdog times.
- OK
#048
1
RTU inoperable ON A subordinate
device (RTU, IED,
etc.) is inoperable or
not connected.
No physical
connection is
available.
-
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.
- -
#049
1
RTU is out of
service
ON The subordinate
device (RTU, IED,
etc.) was put out of
service and is not
being processed.
The subordinate
device (RTU, IED,
etc.) was put out of
service with
SSC#001.
-
RTU is in service OFF The subordinate
device (RTU, IED,
etc.) is being
processed.
- -
#059 Power supply
failure in RTU
central sub-rack
ON Failure of one
configured power
supply unit (e.g.,
560PSU01) in rack
A hardware failure of
the power supply
unit has occurred.
Warning
Not all configured
power supply units
are plugged in.
Warning
Power supply OK
in RTU central
sub-rack
OFF The configured
power supply units
are error-free.
- -
System events
ABB AG 1KGT 150 798 V002 1 10-7
SEV
offset
System
message
Value Detailed
description
Cause Error status
#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

#095
x.Cmd.
supervision circuit
disconnected or
faulty
[x= 1...32]
ON The command
supervision circuit of
a command
supervision board
(e.g., 23BA22 or
23BA23) is
defective.
command
supervision board
has occurred.
-
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.
-
System events
10-8 1KGT 150 798 V002 1 ABB AG
SEV
offset
System
message
Value Detailed
description
Cause Error status
The
LOCAL/REMOTE
switch of the
command
supervision board is
in LOCAL position.
-
x.Cmd.
supervision circuit
is OK
[x= 1...32]
OFF The command
supervision circuit is
okay again.
This message is
generated when a
command is
successfully
executed.
- -
#096

#097
SNTP Client #x
synchronized
[x= 1...2]
ON At least one
configured SNTP
server is available
with a plausible
time.
- -
SNTP Client #x
not synchronized
[x= 1...2]
OFF The time
synchronization of
the RTU is not
possible by
concerned SNTP
client.
No SNTP server is
responding.
-
An IP address
mismatch has
occurred.
-
#100 Local control
authority active
ON The command from
HCIs that are
configured to
interlock with local
control authority of
RTU will be blocked.
The local control
authority is currently
requested, e.g. by
integrated HMI or by
client on IEC 61850
station bus.
-
Local control
authority available
OFF The local control
authority can be
requested by
integrated HMI of
the client on the
IEC 61850 station
bus.
- -
101

#116
Host #x online
[x= 1...16]
ON The connection to
the host is
established and
running.
- -
Host #x offline
[x= 1...16]
OFF No process
communication with
host
The host is not
running
-
No physical
connection is
available.
-
Line addressing is
incorrect.
-
System events
ABB AG 1KGT 150 798 V002 1 10-9
SEV
offset
System
message
Value Detailed
description
Cause Error status
#117

#132
Hostinterface x:
At least one
change of
information lost
[x= 1...16]
ON At least one
information change
of the corresponding
HCI is lost due to
queue overflow.
See chapter Host
communication
interface
-
Hostinterface x:
All changes of
information
processed
[x= 1...16]
OFF All information
changes are
reported to the
connected host.
See chapter Host
communication
interface.
-
#133

#148
Hostinterface x:
At least one pulse
counter lost
[x= 1...16]
At least one pulse
counter is lost due
to queue overflow or
replacement.
See chapter Host
communication
interface.
-
Hostinterface x:
All pulse counters
processed
[x= 1...16]
All pulse counters
are reported to the
connected host.
See chapter Host
communication
interface.
-
#149

#164
CMU #x operable
[x= 1...16]
The CMU is started
and alive on the
system bus.
- OK
CMU #x
inoperable
[x= 1...16]
The CMU is not
reachable on the
system bus.
CMU has occurred.
Error
The CMU is not
plugged in.
Error
The redundant rack
with the CMU is
switched off
Error
The CMU is starting
up.
Error
#180
1

#183
1

Device reachable
on redundant line
x
[x= 1...4]
ON The subordinate
devices (RTU, IED,
etc.) are marked as
reachable if a link to
the device can be
established
according to the
procedures
described in the
supporting SCIs.
- -
Device not
reachable on
redundant line x
[x= 1...4]
OFF The subordinated
device (RTU, IED,
etc.) cannot be
reached on line.
The physical
connection to the
device is defective.
-
A device failure has
occurred.
-
#184
1

#187
1

Device active on
redundant line x
[x= 1...4]
ON Link is used for
process data
communication with
subordinated device
(RTU, IED, etc.)
- -
System events
10-10 1KGT 150 798 V002 1 ABB AG
SEV
offset
System
message
Value Detailed
description
Cause Error status
Device not active
on redundant line
x
[x= 1...4]
OFF Link is checked only
for reachability
(see
SEV#180183)
A link with higher
priority is reachable,
and is therefore the
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.

#188
1

#191
1

Device preferred
on redundant line
x
[x= 1...4]
ON Link to subordinate
device (RTU, IED,
etc.) is considered
as the preferred link
during line
switchover
The link is the
preferred link by
configuration.
-
The link was set as
the preferred link
using an
SSC#004...#007
system command.
-
Device not
preferred on
redundant line x
[x= 1...4]
OFF - - -
#192

#223
Network element
no. x operable
[x= 1...32]
ON Supervised network
element is
connected and
operable
- -
Network element
no. x not
operable
[x= 1...32]
OFF Supervised network
element (e.g.
Ethernet switch
supervised by
SNMP) is not
connected or not
operable
The network
element is not
running.
-
A physical or logical
connection to
network element
cannot be
established.-

An IP address
mismatch has
occurred.

#224

#239
CMU #x active
[x= 1...16]
ON CMU is processing
the configured
function.
The CMU is the
active CMU in a
redundant pair of
CMUs.
OK
System events
ABB AG 1KGT 150 798 V002 1 10-11
SEV
offset
System
message
Value Detailed
description
Cause Error status
The CMU is a
non-redundant
CMU.

No command
collision with host
no x
[x= 1...16]
OFF - - Error-
#258
1
Command
collision with
Integrated HMI
ON The issued
command is already
in use. The
transmitted
command was
negatively
acknowledged.

No command
collision with
Integrated HMI
OFF - - -
#259
1
Command
collision with web
server
The issued
command is already
in use. The
transmitted
command was
negatively
acknowledged.

A command issued
by the RTU500
series' web server is
already being
executed.

No command
collision with web
server
- - -
#260
1
Command
collision with PLC
The issued
command is already
in use. The
transmitted
command was
negatively
acknowledged.

A command issued
by a PLC function is
already being
executed.

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.

System commands
10-12 1KGT 150 798 V002 1 ABB AG
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
address
System command Value Detailed description
#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
...
#007
Set redundant line x as preferred line
[x= 1...4]
ON Set redundant line x to subordinated
device (RTU, IED, etc.) as the preferred
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
...
#031
Switch over to redundant CMU #x
[x=116]
ON Switch over to the partner CMU of a
redundant CMU pair.
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


ABB AG 1KGT 150 798 V002 1 11-1
11 Glossary of terms
A
AMI Analog Measured value Input
ASO Analog Setpoint command Output
B
BCU Bus Connection Unit
BSI Bit String Input (8, 16 bit)
BSO Bit String Output (1, 2, 8, 16 bit)
C
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
D
DCO Double Command Output
DMI Digital Measured value Input (8, 16 bit)
DPI Double Point Input
DSO Digital Setpoint command Output (8, 16 bit)
E
EPI Event of Protection equipment Input (1 bit)
G
GCD General Configuration Data
H
HCI Host Communication Interface
Glossary of terms Function Description Release 11

11-2 1KGT 150 798 V002 1 ABB AG
I
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
M
MFI Analog Measured value Floating Input
MPU Main Processing Unit
N
NCC Network Control Center
P
PB Peripheral Bus
PBP Peripheral Bus Processor
PDP Process Data Processing
PLC Programmable Logic Control
PPP Point-to-Point Protocol
PSU Power Supply Unit
R
RCD RTU Configuration Data
RCO Regulation step Command Output
RNDIS Remote Network Driver Interface Specification
RTC Real Time Clock
S
SBO Select before Operate
SCADA Supervision, Control and Data Acquisition
SCI Sub-Device Communication Interface
SCO Single Command Output
Function Description Release 11 Glossary of terms

ABB AG 1KGT 150 798 V002 1 11-3
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
T
TSI Time Synch Input
TSO Time Synch Output
U
UDP User Datagram Protocol
USB Universal Serial Bus

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.

E500 FD Rel11 Part6 RTU Functions

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

E500 FD Rel11 Part6 RTU Functions

Hochgeladen von

Copyright:

Verfügbare Formate

RTU500 series Remote Terminal Unit

Function Description Release 11

card every 20 seconds, but

Das könnte Ihnen auch gefallen