RTU500 series

RTU500 series Remote Terminal Unit

Function Description
Part 9: Interfaces and Networks
RTU500 series Remote Terminal Unit Revision

Revision

Document identity: 1KGT 150 896 V002 1

Revision: Date: Changes:
0 01/2014 Initial version (Release 11.1)
Update: VPN Step 2
RNDIS and PPP: minor updates
IPv4 Routing for up to 10 destination networks
1 03/2014 Denial of service function added
2 08/2014 PRP redundancy added
VPN functions updates
protocol logging corrections

ABB AG - 1KGT 150 896 V002 1

Revision RTU500 series Remote Terminal Unit

1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Contents

Contents
1 Introduction.................................................................................................................... 1-1
1.1 About the RTU500 series Function Description...................................................1-1
1.2 Preface................................................................................................................1-1
1.3 References.......................................................................................................... 1-1

2 Interfaces........................................................................................................................2-1
2.1 Interface configuration.........................................................................................2-1
2.1.1 Interfaces........................................................................................... 2-1
2.1.2 Interface Configuration Rules and Restrictions................................... 2-3
2.2 Serial interfaces: Duplex communication.............................................................2-3
2.2.1 WT duplex link (no handshake).......................................................... 2-4
2.2.2 Direct link communication (only TxD / RxD)........................................2-4
2.2.3 Dial-up communication (external modem, DCD handshake)............... 2-5
2.3 Serial interfaces: Half-duplex communication...................................................... 2-7
2.3.1 WT half-duplex communication (RTS/CTS handshake)...................... 2-7
2.3.2 WT Link Half Duplex (RTS/DCD handshake)...................................... 2-8
2.4 Serial interfaces: Point-to-Point Protocol (PPP)................................................... 2-8
2.4.1 Setting up a PPP client connection....................................................2-9
2.4.2 Setting up a PPP server connection................................................ 2-15
2.5 Serial interfaces: Additional communication modes...........................................2-20
2.5.1 Loop switch unit DSTC 3002...........................................................2-20
2.5.2 Link with collision avoidance (DCD handshake)................................ 2-20
2.6 Ethernet interfaces: Configuration and Routing................................................. 2-21
2.7 USB RNDIS interface........................................................................................ 2-23
2.7.1 Introduction...................................................................................... 2-23
2.7.2 Configuration....................................................................................2-24
2.8 Protocol logging for communication interfaces..................................................2-24
2.8.1 Host communication protocols........................................................ 2-25
2.8.2 Sub-device communication protocols.............................................. 2-25
2.8.3 Configuration in CPTT......................................................................2-25
2.8.4 Configuration string in CPTT............................................................ 2-26
2.8.5 Examples......................................................................................... 2-28

3 Networks........................................................................................................................ 3-1
3.1 Network configuration......................................................................................... 3-1
3.2 Network configuration rules and restrictions....................................................... 3-1
3.2.1 Denial of Service................................................................................ 3-2
3.3 Virtual Private Network (VPN)..............................................................................3-2
3.3.1 Overview............................................................................................ 3-2
3.3.2 Supported Features........................................................................... 3-3
3.3.3 Pre-Shared Key (PSK)........................................................................3-4
3.3.4 Certificates......................................................................................... 3-5
3.3.5 Perfect Forward Secrecy (PFS).......................................................... 3-5

ABB AG - 1KGT 150 896 V002 1 | I

Contents RTU500 series Remote Terminal Unit

3.3.6 Dead Peer Detection..........................................................................3-5

3.3.7 UDP Encapsulation and NAT-Traversal...............................................3-5
3.3.8 VPN connection set up......................................................................3-6
3.3.9 VPN configuration.............................................................................. 3-6
3.4 VPN Configuration with Sophos UTM................................................................. 3-9
3.4.1 Preliminaries..................................................................................... 3-10
3.4.2 Create certificates............................................................................ 3-12
3.4.3 Configure VPN Router..................................................................... 3-14
3.4.4 Configure RTU................................................................................. 3-17
3.4.5 Download X509 certificate @RTU.................................................... 3-20
3.4.6 Establish communication................................................................. 3-21
3.5 Templates......................................................................................................... 3-21
3.5.1 VPN IPSec encryption template....................................................... 3-21
3.5.2 CIDR List......................................................................................... 3-23
3.5.3 APN List for Germany......................................................................3-24
3.6 Parallel Redundancy Protocol (PRP)................................................................. 3-25
3.6.1 Overview.......................................................................................... 3-25
3.6.2 PRP in RTU500 series..................................................................... 3-26
3.6.3 PRP configuration............................................................................ 3-27
3.6.4 PRP supervision...............................................................................3-29

4 Glossary......................................................................................................................... 4-1

II | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Introduction
About the RTU500 series Function Description

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 mounted solutions Description of the RTU500 series rack solu-
tions

1KGT 150 795 Part 3: DIN rail solutions Description of the RTU500 series DIN rail so-
lutions

1KGT 150 796 Part 4: Hardware modules Overview of the RTU500 series rack and DIN
rail modules

1KGT 150 797 Part 5: SCADA functions Description of the RTU500 series SCADA
functions

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

1KGT 150 799 Part 7: Archive functions Description of the RTU500 series Archive
functions

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

1KGT 159 896 Part 9: Interfaces and Networks Description of the RTU500 series Interface
and Network functions

Table 1: Parts of the Function Description

1.2 Preface
This document describes the following functions of the RTU500 series:

• Interfaces
• Networks

1.3 References

[1] 1KGT 150 801 RTUtil500 Users Describes the usage of engineering tool
Guide Release 11 RTUtil500 of the RTU500 series
[2] Individual Ident RTU500 series Description of the Sub and Host Communi-
Protocol Descriptions cation Protocols
[3] 1KGT 150 853 Interfaces and Proto- Description of the relationship of interfaces
cols Release 11 and protocols

ABB AG - 1KGT 150 896 V002 1 | 1-1

Introduction RTU500 series Remote Terminal Unit
References

[4] RFC1157 A Simple Network

Management Protocol
(SNMP)
[5] RFC1213 Management Infor-
mation Base for Net-
work Management of
TCP/IP-based inter-
nets: MIB-II (second
version)
[6] 1KGT 150 802 RTU500 series Web
Server User's Guide
[7] IEC 62439-3 Industrial Commu- Part 3: Parallel Redundancy Protocol (PRP)
nication Networks - and High-availability Seamless Redundancy
High Availability Au- (HSR)
tomation Networks

1-2 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Interface configuration

2 Interfaces

2.1 Interface configuration

2.1.1 Interfaces

Serial interfaces CP1, CP2, (CP3)

The following communication units are available for the interfaces CP1, CP2 and CP3:

• 560CMU02
• 560CMU05
• 560CMG10
• 560CIG10
• 560CMD11
• 560CID11
• 560CMU01
• 520CMD01
• 511CIM01

The following parameters are available for the interfaces CP1, CP2 and CP3:

Parameter name Default Parameter location

Interface type RS232 RS485

Com speed 50 to 38 400 baud

Serial interfaces CPA, (CPB), (CPM)

The following communication units are available for the interfaces CPA, CPB, and CPM:

• 560CMU02
• 560CMU05
• 560CMG10
• 560CIG10
• 560CMD11
• 560CID11
• 560CMU01
• 511CIM01

The following parameters are available for the interfaces CPA, CPB, and CPM:

Parameter name Default Parameter location

Interface type RS232 RS485

ABB AG - 1KGT 150 896 V002 1 | 2-1

Interfaces RTU500 series Remote Terminal Unit
Interface configuration

Parameter name Default Parameter location

Com speed 50 to 38 400 baud

Ethernet interfaces

The following communication units are available for Ethernet interfaces:

• 560CMU02
• 560CMU05
• 560CMG10
• 560CIG10
• 560CMD11
• 560CID11
• 560CMU01
• 520CMD01
• 511CIM01

The following parameters are available for Ethernet interfaces:

Parameter name Default Parameter location

IP address Interface parameters

Subnet mask Interface parameters

Default Gateway IP Interface parameters

The communication units use the Ethernet interface for downloading configuration data and for di-
agnostic purposes. The default IP address of the Ethernet interface is 192.168.0.1. It is enabled and
can be temporarily set to a different value using an onboard jumper (not available on 520CMD01).

USB interfaces

The following communication units are available with USB interfaces:

• 520CMD01
• 511CIM01

These communication units work as USB RNDIS target device. RNDIS host is a Windows XP or
Windows 7 computer. RNDIS interface’s IP address on the RTU is 169.254.0.10. The USB RNDIS
Device running on Windows host can get IP settings assigned automatically from the "link local"
block 169.254.0.0/16.

2-2 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Interface configuration

2.1.2 Interface Configuration Rules and Restrictions

The assignment of UART host protocols to serial interfaces is completely at the user's disposal.
There are no dependencies between different protocols run on a CMU.

Special protocols run only on the following devices:

• 560CMU05 R0002
• CP1 or CP2 of the 560CMU02 or 560CMU05

The SLC can run only in one of the following modes:

• I/O bus
• Bit protocols
• UART protocols

Mode types cannot be mixed. For instance, CPA cannot run in I/O bus mode while CPB runs in
Bit protocol mode.

Ethernet and TCP/IP-based protocols can be used with the Ethernet interface on all CMUs.

The USB interfaces can only be used to access the RTU500 series Web-Server

For more information, refer to [3].

2.2 Serial interfaces: Duplex communication

WT Duplex
4 Wire

NCC

WT

Tx Tx
RTU500
WT

Rx Rx

Figure 1: Duplex communication

ABB AG - 1KGT 150 896 V002 1 | 2-3

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Duplex communication

2.2.1 WT duplex link (no handshake)

To communicate with WT modems of the type 23WT25 via 4-wire links or 2 channels, RTU500
series uses full-duplex communication.

To communicate with WT modems of the type 23WT23 via 4-wire links, RTU500 series uses full-
duplex communication.

As with No hardware handshake, RTU500 uses full-duplex communication with TxD and RxD.

DTR and RTS are set to continuous ON. This switches the modem's carrier signal to ON state.

DSR, DCD and CTS are ignored, or at least not analyzed.

Transmission delay time can be used to slow down the display of messages. This has no effect on
the DTR or RTS control signals.

The following parameters are used for transmission control:

Parameter name Default Parameter location

Modem control Interface parameters

Transmit delay time Interface parameters

The following diagram shows transmission control in WT full-duplex communication:

Figure 2: Transmission control in WT full-duplex communication

2.2.2 Direct link communication (only TxD / RxD)

For direct link communication, RTU500 series uses TxD and RxD via separate lines (duplex trans-
mission).

No control signals are used. CTS and DCD are not analyzed.

Transmission delay time can be used to slow down the display of messages. This works in RS232
and RS422.

The RTU and its communication partner device are linked via a direct connection. A communication
partner device may be a PC, another RTU, a PC modem, or a CS.

2-4 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Duplex communication

The following parameters are used for transmission control:

Parameter name Default Parameter location

Modem control Interface parameters

Transmit delay time Interface parameters

Figure 3: Transmission control in direct link communication

2.2.3 Dial-up communication (external modem, DCD handshake)

For dial-up communication through an external modem, RTU500 series uses TxD and RxD via sep-
arate lines (duplex transmission).

The DTR / DSR, RTS / CTS, and DCD control signals are used for flow control. This works only
in RS232 mode.

The RTU and its communication partner device are linked via a direct connection. A communication
partner device may be a PC, another RTU, a PC modem, or a CS.

The following parameters are used for transmission control:

Parameter name Default Parameter location

Modem control Interface parameters

Transmit delay time Interface parameters

Carrier trailing time Interface parameters

ABB AG - 1KGT 150 896 V002 1 | 2-5

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Duplex communication

Figure 4: Transmission control in direct link or modem link communication

Figure 5: Dial-up configuration (example)

2-6 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Half-duplex communication

2.3 Serial interfaces: Half-duplex communication

WT Half Duplex WT Half Duplex
4 Wire 2 Wire

NCC NCC

WT WT

RTU500

RTU500
Tx Tx Tx

Rx WT Rx WT Rx

RTU500

RTU500
Tx Tx Tx

Rx WT Rx WT Rx

Figure 6: Half-duplex communication

2.3.1 WT half-duplex communication (RTS/CTS handshake)

To communicate with WT modems of the type 23WT23 and 23WT25 via 2-wire links, RTU500
series uses half-duplex communication. The control signals are used to control the carrier on the
transmission line.

The following parameters are used for transmission control:

Parameter name Default Parameter location

Modem control Interface parameters

Transmit delay time Interface parameters

Figure 7: WT mode, half-duplex communication, with RTS or CTS handshake

ABB AG - 1KGT 150 896 V002 1 | 2-7

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Half-duplex communication

From an RTU point of view, the following limitations have to be observed:

• Receive: RTS is reset, DCD set. DSR and CTS are not analyzed.
• Send: RTS is set and transmission delay time is awaited. When CTS is set, data is sent, the
carrier trailing time is awaited before RTS is reset. Reception is released again upon reset of
RTS.

2.3.2 WT Link Half Duplex (RTS/DCD handshake)

To communicate with WT modems of the type 23WT23 and 23WT25 via 2-wire links, RTU500
series uses half-duplex communication. The control signals are used to control the carrier on the
transmission line.

The following parameters are used for transmission control:

Parameter name Default Parameter location

Modem control Interface parameters

Transmit delay time Interface parameters

Figure 8: WT mode, half-duplex communication, no RTS or CTS handshake

From an RTU point of view, the following limitations have to be observed:

• Receive: RTS is reset, DCD set. DSR and CTS are not analyzed.
• Send: When RTS is set, CSTD (Carrier Setup Time Delay) is awaited (only with SCI IEC 101).
Then data is sent and CTTD (Carrier Trailing Time Delay) is awaited before RTS is reset. Recep-
tion is released again upon reset of RTS.

2.4 Serial interfaces: Point-to-Point Protocol (PPP)

The RTU500 series Point-to-Point Protocol (PPP) implementation provides a standard method for
transporting IP datagrams over point-to-point links.

2-8 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Point-to-Point Protocol (PPP)

PPP is comprised of three main components:

• A standard method for encapsulating IP datagrams (Network Layer protocol information)

• A Link Control Protocol (LCP) for establishing, configuring and testing the data-link connection
• The IP Control Protocol (IPCP) for establishing and configuring the network-layer protocol (IP
over the PPP link)

The RTU500 series supports a version of the PPP that complies with the standard for that protocol,
RFC 1661. The RTU is designed for links which transport packets between two peers. These links
provide full-duplex, simultaneous, bi-directional operation.

For each serial interface of the RTU, the type of peer used on either end of the PPP link can be
configured in one of the following ways:

• as an RTU PPP client to a remote network host over a dial-up line connection using a GSM/
GPRS modem
• as an RTU PPP server to a Microsoft® Windows® client connection over a null modem cable

Every serial interface of an RTU can be configured either as a PPP client or as a PPP server.

PPP is basically responsible for encapsulating and carrying IP datagrams across two endpoints of a
serial connection. PPP communication starts after a physical serial connection has been established.
However, before PPP can start carrying data, numerous negotiations take place between the peers
to configure, establish and monitor the connection.

2.4.1 Setting up a PPP client connection

Overview

The PPP Link Control Protocol is used to connect an RTU to a control system via the Internet over
any distance.

In order to use this feature, you need to equip the RTU either with an external GSM/GPRS modem
connected to a serial port (e.g. 560MDD10), or with an internal GSM/GPRS modem running on CPB
of the 560CMD11 R0011.

An Internet Service Provider (ISP) supporting network connections between a GPRS modem and
the Internet is required

Once a PPP connection has been established, the RTU can be accessed by a control system using
the IP address assigned by the ISP. All IP-based protocols (IEC 60870-5-104, DNP3, Modbus, etc.)
can be used with this connection.

With a PPP connection, the RTU can be configured and monitored remotely using a Web browser.

Configuration

The following section describes the steps required to set up a PPP client connection.

ABB AG - 1KGT 150 896 V002 1 | 2-9

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Point-to-Point Protocol (PPP)

Assigning a PPP Client link to a serial interface in the hardware tree

On a CMU module select Add item... and in the upcoming dialog select a serial interface and PPP
Client from dropdown list.

Figure 9: Assigning a link in RTUtil500

The RTU supports the PPP Client link configuration on all serial interfaces (CP1, CP2, CPA, CPB and
CPM) with the following exceptions: On 560CMU05 the PPP Client link configuration is supported
on CP1 and CP2, but not on CPA or CPB. On 511CMM01 the PPP Client link configuration is
supported on CP2 and CPM, but not on CP1.

Configuring external DIN rail modem 560MDD10

Add DIN rail for DIN rail modules. From the Add node to DIN rail dropdown list select 560MDD10
– DIN rail modem.

On 560MDD10 select the serial communication port the modem will be connected to from the
Connected to interface dropdown list.

Figure 10: Assigning an interface to modem

Configuring COM speed

The COM speed 115200 bits/sec for external GSM/GPRS modem 560MDD10 is not displayed and
cannot be changed.

2-10 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Point-to-Point Protocol (PPP)

The COM speed 115200 bits/sec for internal GSM/GPRS modem running on CPB of a 560CMD11
R0011 is insensitive and cannot be changed.

For other external GSM/GPRS modems (e.g. INSYS) select the required baud rate from COM speed
dropdown list. The default value is 19200 bits/sec.

Configuring Modem control

Modem control for external GSM/GPRS modem 560MDD10 is not displayed and cannot be
changed.

Modem control for internal GSM/GPRS modem running on CPB of a 560CMD11 R0011 is insensitive
and cannot be changed.

For other external GSM/GPRS modems (e.g. INSYS) select Dial-up (external modem DCD hand-
shake) from the Modem control dropdown list.

Configuring Dial up parameters (560MDD10 or internal modem of 560CMD11

R0011)

Activate the Dial up enabled option and click the Dial up parameters button to open the Modem
parameters configuration dialog.

Figure 11: Configuring initialization commands (560MDD10)

ABB AG - 1KGT 150 896 V002 1 | 2-11

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Point-to-Point Protocol (PPP)

Some ISPs use PIN protection to protect their SIM cards from unauthorized access. This protection
requires the user to provide a secret numeric password as an authentication before being able to
access the system. If your ISP uses this function enable the PIN configuration option and enter the
PIN. If no PIN protection is used leave this option disabled.

Enable the option APN and enter the Access Point Name of your service provider e.g. internet.t-
d1.de or mdex.ic.t-mobile. The APN is the name of the gateway between the GPRS mobile network
and the public internet.

Normally, the option Connect to fixed mobile network is not enabled. It is only necessary in very
rare cases to force the modem to connect exclusively to the specified PLMN (Public Land Mobile
Network) composed of MCC (Mobile Country Code) and MNC (Mobile Network Code).

Configuring Dial up parameters (other modems)

Activate the Dial up enabled option and click the Dial up parameters button to open the Modem
parameters configuration dialog.

Configure the AT commands and command responses as required, using suitable values for the
modem used. The configuration settings are usually similar to the specification according to V.25ter.

The configured AT commands are sent to the modem during initialization time.

Figure 12: Configuring initialization commands (other modems)

2-12 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Point-to-Point Protocol (PPP)

Some ISPs use PIN protection to protect their SIM cards from unauthorized access. This protection
requires the user to provide a secret numeric password as an authentication before being able to
access the system. If your ISP uses this function enable the option PIN Configuration string for
GSM modem. In the text field to the right, enter the full AT command for sending the PIN. Quotation
marks around the PIN are mandatory, e.g. AT+CPIN=”9178”. If no PIN protection is used, this option
can be disabled.

The Service Configuration string for GSM modem is sent to the modem immediately before the
configured telephone number is called. The string usually contains the name of the provider and
the service offered.

Example:

In the above figure, the internal modem AirPrime WISMO228 is used. More information can be found
on: http://www.sierrawireless.com.

The configuration of external modems, e.g., INSYS GSM/GPRS, is similar. More information can be
found on: http://www.insys-tec.de/en/en/insys-gsm.

Under Service configuration string for GSM modem, the AT command AT+CGDCONT=<PDP (Pack-
et Data Protocol) context> is used to specify the service. The configuration string in the following
example uses the provider mdex.

Example: AT+CGDCONT= 1,”IP”,”mdex.ic.t-mobile”

The following table outlines the parameters used in the configuration string.

Parameter Explanation

1 PDP context id (definition stored in non-volatile memory)

”IP” PDP type – Internet Protocol1

”mdex.ic.t-mobile” APN (Access Point Name)1

Table 2: Explanation of AT command example – String parameters

1Quotation marks are mandatory.

Configuring contract specific parameters

The ISP usually provides contract-specific data, which need to be provided as part of the PPP client
link.

The following contract-specific parameters can be configured:

• Send local IP address to provider: This option is usually disabled, because the local IP address
is assigned automatically from the provider during connection setup. Attention: If this option
will be enabled in very rare cases the local IP address will be sent to the peer and has to be ac-
knowledged positive from the provider during connection setup.
• User name
• Password
• Telephone number (not necessary for 560MDD10)

ABB AG - 1KGT 150 896 V002 1 | 2-13

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Point-to-Point Protocol (PPP)

Figure 13: PPP dialog for contract-specific data

Enable routing setting for the PPP client interface. Use the remote network address (provided by
your provider). Define network and netmask. Gateway is handled automatically according to the
dial-in server of your provider.

Figure 14: IPv4 Routing dialog

Establishing a connection

When powering on the RTU, the AT commands configured for initialization are sent to the modem.
If these commands are answered correctly, the RTU starts a call to the telephone number specified
in the configuration data.

Once a connection is established, the connection string received, and the DCD signal activated,
control is handed over to the PPP Link Control Protocol (LCP). Note that the RTU does not provide
an IP address. The remote peer has to determine both addresses. The network address specified
in the above figure is used only for expansion of the internal routing table and should match the
address provided by the remote peer.

2-14 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Point-to-Point Protocol (PPP)

2.4.2 Setting up a PPP server connection

Overview

PPP is a symmetric peer-to-peer protocol. Each endpoint interacts with its peer in an identical man-
ner. The designations client and server are used only in the context of establishing a connection to
distinguish the endpoint initiating the connection (client) from the endpoint answering that request
(server). Once a physical serial connection has been established, this distinction is no longer relevant.

The RTU500 series provides a common solution for connections between an RTU PPP server and
Windows clients. The RTU's PPP server functionality provides a remote access server that is able
to answer connection requests from PPP clients. Microsoft® Windows® remote access software is
compliant with the PPP standard and can therefore be used to access the RTU over the network.
The RTU's PPP server also provides advanced features, such as authentication (optional), network
address compression, and control field compression.

Configuration

The following section describes the basic configuration steps required to set up an RTU's PPP server
and a Microsoft® Windows® PPP client.

Assigning a PPP Server link to a serial interface in the hardware tree

On a CMU module select Add item... and in the upcoming dialog select a serial interface and PPP
Server from dropdown list.

Figure 15: Assigning a link in RTUtil500

The RTU supports the PPP Server link configuration on all serial interfaces (CP1, CP2, CPA, CPB and
CPM) with the following exceptions: On 560CMU05 the PPP Server link configuration is supported
on CP1 and CP2, but not on CPA or CPB. On 511CMM01 the PPP Server link configuration is
supported on CP2 and CPM, but not on CP1.

Configuring IP addresses

In RTUtil500, the IP addresses of the local system (server) and the remote system (client) are manda-
tory.

To configure the IP addresses, proceed as follows:

ABB AG - 1KGT 150 896 V002 1 | 2-15

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Point-to-Point Protocol (PPP)

1. In the Server IP address field, enter the IP address of the PPP server in dotted decimal for-
mat.
2. In the Client IP address field, enter the IP address of the PPP client in dotted decimal format.

Figure 16: Configuring IP addresses in RTUtil500

Configuring authentication

You can configure the PPP server with or without authentication. By default, authentication is dis-
abled, as displayed in the figure above.

To configure authentication for the PPP link, proceed as follows:

1. Enable the Authentication option.

2. Enter the User name and Password of the client user, as displayed in the figure below.

Figure 17: Configuring authentication in RTUtil500

The RTU supports a version of the CHAP (Challenge Handshake Authentication Protocol) that com-
plies with the standard for that protocol, RFC 1994. This protocol issues a random challenge. The
challenge is matched against a cryptographically hashed response generated from the challenge
and a secret key. Only a recipient of the challenge who also is in possession of the key can reliably
generate a valid response.

If the Authentication checkbox is enabled, the server expects the client to authenticate before being
granted access. As the server requires CHAP as its authentication method, the client must encrypt
the user name and password. The server verifies the user name and the password provided by
the client against its configured acceptable user name and password. If the provided name and

2-16 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Point-to-Point Protocol (PPP)

password cannot be verified, access is denied. If an authentication failure occurs while trying to
open a link, the link is closed and the client application that attempted to open the link is notified
of this event.

Configuring COM speed

To configure the COM speed, proceed as follows:

1. Configure both ends of the PPP link with the same connection speed used by the serial I/O
adapter. The default value of 38400 bits/s is usually an ideal match to the COM speed of the
peer and no additional configuration is necessary.

Figure 18: COM speed configuration in RTUtil500

2. Verify the PPP connection. A Microsoft® Windows® client is required for the second end
point of the connection. For a detailed description of the configuration of a standard PPP
client – as installed on Microsoft® Windows® platforms by default – refer to [6]. Note that the
current section contains additional instructions that are not included in the Web Server User's
Guide.
3. If the RTU's PPP server is configured with authentication, enable the following settings in the
configuration dialogs on the Microsoft® Windows® machine.
4. From the Microsoft® Windows® Control Panel, select Network Connections.
5. Right-click on PPP-RTU560 to open the Properties dialog.
6. On the Security tab, under Security options, select the Advanced (custom settings) option.

ABB AG - 1KGT 150 896 V002 1 | 2-17

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Point-to-Point Protocol (PPP)

Figure 19: Security options

7. Enable the Challenge Handshake Authentication Protocol (CHAP) checkbox.

2-18 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Serial interfaces: Point-to-Point Protocol (PPP)

Figure 20: Advanced Security Settings dialog

8. Use the same values for Maximum speed (bps) (e.g., 38400) on the Microsoft® Windows®
PPP client and for the COM speed of the PPP server in RTUtil500, as shown in the figures
COM speed configuration in RTUtil500 above and Modem Configuration dialog below.

ABB AG - 1KGT 150 896 V002 1 | 2-19

Interfaces RTU500 series Remote Terminal Unit
Serial interfaces: Additional communication modes

Figure 21: Modem Configuration dialog

2.5 Serial interfaces: Additional communication modes

2.5.1 Loop switch unit DSTC 3002

The communication loop switch unit DSTC 3002 for redundant communication lines is supported
only by the RP570/71 host communication interface.

Parameter name Default Parameter location

Loop switch unit Interface parameter

2.5.2 Link with collision avoidance (DCD handshake)

Collision avoidance is supported only by host and subdevice communication interfaces supporting
the DNP3 protocol. If a collision is detected on the communication link, the interface will wait a
random time before continuing transmission.

Parameter name Default Parameter location

Fixed delay time Interface parameters

Maximum random delay Interface parameters

2-20 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Ethernet interfaces: Configuration and Routing

2.6 Ethernet interfaces: Configuration and Routing

In RTUtil500 the page 'Network Interfaces' contains an 'E1' and if present on selected CMU module
an 'E2' tab. The interface parameters are configured on this tab. There are the following parameters:

• Interface mode (transmission rate and duplex mode)

• Node name
• IP address
• Subnet mask
• Default Gateway IP (E1 only) The value indicates the next-hop intermediary through which
packets should be routed.

If there are both ethernet interfaces 'E1' and 'E2' present on selected CMU module the following
additional options are available:

• Switch default routing between interfaces (Check whether the routing must be switched be-
tween the two ethernet interfaces depending on the link status.)
• Allow IP address of interfaces in the same subnet (Both ethernet interfaces have to be in the
same physical network.)

There are restrictions when enabling the option 'Allow IP address of interfaces in the same subnet ':

If the ethernet interfaces E1 and E2 are configured in the same subnet and link on E1 is down, then
the RTU do switch over the gateway from E1 to E2. This works in case of communication of host
interfaces. But if a sub interface is defined and the IED is configured with two IP ports and same IP
address for both ports, then the RTU can communicate from E1 and from E2 to the IED, but only
one communication line (one socket) can be active. One link is online (communication is up) and
the redundant link cannot be connected. A “connect” must not be done and test link cannot be
send on redundant line. That means only one socket with port 2404 can be active. If this will work
is depending from IED. IED needs to ignore a connection from redundant link as long the active
link is online.

Figure 22: Ethernet interface configuration

The RTU offers routing support for up to 10 destination networks. It is possible to configure network
routes on ethernet interfaces (E1 and if present E2) including netmask of routing destination and
interface.

The page 'Network Interfaces' contains an 'IPv4 Routing' tab. The content of the internal routing
table is configured on this tab. There are the following parameters:

ABB AG - 1KGT 150 896 V002 1 | 2-21

Interfaces RTU500 series Remote Terminal Unit
Ethernet interfaces: Configuration and Routing

• Network (The destination to be routed in.)

• Netmask (The value is used for specifying subnet masks.)
• Gateway (The value indicates the next-hop intermediary through which packets should be rout-
ed.)
• Interface (The route setting is applied to this interface.)

Figure 23: IPv4 Routing configuration

Routing to destination networks is allowed also with breaking the IANA rules by explicit entering the
netmask for each routing configuration.

For IPv4, a destination network is identified by an IPv4 address and a netmask value. The net-
mask is normally contiguous makes it possible to specify as a prefix as well. For example, the mask
255.255.255.0 is equivalent to the prefix /24 since the 24 first bits (counting from left) are set. The
netmask is selected using a dropdown list:

2-22 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
USB RNDIS interface

Figure 24: Netmask selection dropdown list

2.7 USB RNDIS interface

2.7.1 Introduction
The Remote Network Driver Interface Specification (RNDIS) is a Microsoft® Windows® proprietary
protocol. It provides a virtual Ethernet link to most versions of the Microsoft® Windows® operating
systems. A partial RNDIS specification is available from Microsoft®. The protocol is tightly bound
to programming interfaces and models from Microsoft®, most notably the Network Driver Interface
Specification (NDIS).

RNDIS is a specification for network devices on dynamic Plug-and-Play I/O buses, such as USB. It
includes two components: a bus-independent message set, and a description of how this message
set is conveyed across a specific I/O bus on which it is supported.

Some communication unit of the RTU500 series embeds a USB device port that is compliant with
the Universal Serial Bus (USB) V2.0 full-speed device specification (12 Mbit/s). The RNDIS protocol
is used on top of USB, providing a virtual Ethernet link to a Microsoft® Windows® XP or Microsoft®
Windows® 7 operating system. The result is the same as creating two network devices and assign-
ing one to the 511CIM01 and the other one to the Microsoft® Windows® machine. After installing
and configuring the required RNDIS driver on the Microsoft® Windows® system, the connection
could be used for web server diagnostics, and for the download of configuration data and firmware.

The USB V2.0 full-speed protocol provides communication services between Microsoft® Win-
dows® host and an attached USB device. The protocol provides a collection of communication
flows (pipes), each one associated to an endpoint, to the USB device. Software on the Microsoft®
Windows® host communicates with the USB device through a set of communication flows.

ABB AG - 1KGT 150 896 V002 1 | 2-23

Interfaces RTU500 series Remote Terminal Unit
USB RNDIS interface

Endpoint Transfer Direction Value

0 Control transfer Bidirectional 64 bytes

1 Bulk transfer Unidirectional 64 bytes

2 Bulk transfer Unidirectional 64 bytes

3 Interrupt transfer Unidirectional 8 bytes

Table 3: Endpoints

The RTU communication unit provides the USB device used to transfer data with a Microsoft®
Windows® XP/7 USB host. The USB device is able to emulate a single Ethernet device as if it were
attached to a single USB host. The Ethernet device will be found both on the host side and the
target side, enabling the host, and the target, to communicate with each other using the TCP/IP
network protocol.

2.7.2 Configuration
The RTU500 series communication unit works as a USB RNDIS target device. A Microsoft® Win-
dows® XP/7 computer is used as the RNDIS host.

To configure RNDIS communication, proceed as follows:

1. RNDIS interface on the RTU is automatically set to 169.254.0.10.

2. The USB RNDIS device running on Windows Microsoft® Windows® XP/7 host can get IP
settings assigned automatically from the "link local" block 169.254.0.0/16 (APIPA - Automatic
Private IP Addressing). As described in RFC3927, it is allocated for communication between
hosts on a single link. The Windows host can obtain this address by auto-configuration.
3. Microsoft® Windows® XP/7 computer, customize the firewall settings to allow communica-
tion via the RNDIS interface.
4. Subnet mask is 255.255.0.0.

After connecting the 511CIM01, 520CMD01 communication unit and the Microsoft® Windows®
XP/7 machine via USB cable for the first time, the Microsoft® Windows® machine detects the new
USB RNDIS device, and prompts to install it.

This USB interface is used for web server access via the following URL: http://169.254.0.10. For
detailed information on installing and configuring the USB RNDIS driver on Microsoft® Windows®
XP/7, see the RTU500 series Web Server User's Guide.

2.8 Protocol logging for communication interfaces

For the diagnosis of communication protocols, the RTU500 series provides functions to capture
serial and Ethernet-based communication protocols without modifications to the hardware connec-
tions. All telegram traffic that is received and sent can be logged on request in parallel to the RTUs’
normal processing. Simulation of subordinate devices or control centers is not possible.

2-24 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Protocol logging for communication interfaces

This functionality is available on every CMU and called RIO server. The logged traffic is dis-
played in CPTT, the communication protocol testing tool, which is provided by Real Thoughts
(www.realthoughts.com).

Protocol logging is possible for direct serial links, Ethernet links and TCP/IP communication via PPP
protocol. Protocol logging is not possible for VPN communication.

For monitoring purposes, a network connection to the card used for serial or network communication
is required. Monitoring via backplane routing is not possible.

The following chapters describe the communication protocols supported by the RTU500 series, and
the configuration options available in CPTT.

2.8.1 Host communication protocols

The following host communication protocols are available:

• IEC 60870-5-101
• IEC 60870-5-104
• DNP3
• DNP3 LAN/WAN
• Modbus TCP
• Modbus ASCII/RTU

2.8.2 Sub-device communication protocols

The following sub-device communication protocols are available:

• IEC 60870-5-101
• IEC 60870-5-103
• IEC 60870-5-104
• DNP3
• DNP3 LAN/WAN
• SPAbus
• Modbus TCP
• Modbus ASCII/RTU

2.8.3 Configuration in CPTT

1. In the Protocol profile menu, configure all settings for the selected protocol in the usual man-
ner.
2. Ensure that the settings comply with the configuration of your system, and that the settings
correspond to a master or slave simulation.
3. In the General Preferences dialog, in the Address field of the Remote I/O Server section, enter
the IP address of the CMU to be monitored.

The default value for the network port (1793) must not be changed. An example is shown in the
following figure:

ABB AG - 1KGT 150 896 V002 1 | 2-25

Interfaces RTU500 series Remote Terminal Unit
Protocol logging for communication interfaces

Figure 25: General Preferences dialog

To prevent unintended filtering use default masks in the protocol profile dialog for Ethernet protocols.
An example is shown in the following figure:

Figure 26: Protocol Profile dialog

2.8.4 Configuration string in CPTT

In the General Preferences dialog, in the Configuration string field in the Remote I/O Server section,
enter a string that specifies the interface, or line, to be monitored.

The format of the configuration string is described below. The format excludes certain characters
from being used in the configuration string. The configuration string is case sensitive.

Some special characters are reserved for syntax representation, and must not be used in the con-
figuration string:

2-26 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Interfaces
Protocol logging for communication interfaces

Syntax characters Explanation

{} Selection of input options

| "or" linkage of input options

[] optional part of the string

<> configuration value (described below)

Table 4: Syntax characters

The names of interfaces to be used in the configuration string depend on the communication unit
for which the configuration string is defined:

Communication unit Serial interface names Ethernet interface names PPP links

560CMU02, 560CMU05, cp1, cp2, cpA, cpB E1, E2 PPP1, PPP2

560CMU01

560CMG10, 560CIG10, cp1, cp2, cpA, cpB E1, E2 PPP1, PPP2, (PPP3, PPP4)
560CMD11, 560CID11

520CMD01 cp1, cp2, cp3 E1 PPP1

511CIM01 cp1, cp2, cpM E1 PPP1, PPP2

Table 5: CPTT – Interface naming

Serial communication

ABBRTU560-srl:{cpA | cpB | cp1 | cp2 | cp3 | cpM }[@cmu:rack=<x>/slot=>y>]

Network communication

ABBRTU560-net:{E1 | E2 | PPP1 | PPP2 | PPP3 | PPP4}[:{iec104 | dnp | modbus | <port

number>}];remote:<IP address>[/<metric>][:{iec104 | dnp | modbus | <port number>}][;proto-
col:{tcp | udp}]

Parameter Explanation

<Port number> Network port of the protocol to monitor

<IP address> IP address of the communication partner device

<Metric> Number of relevant bits of the IP address (left to right).

Range: 8 to 32
Default value: 32

<x> Rack address of the target CMU

<y> Slot address of the target CMU

Table 6: Network communication variables

Details concerning the network string

Note the following detail information regarding the network string:

ABB AG - 1KGT 150 896 V002 1 | 2-27

Interfaces RTU500 series Remote Terminal Unit
Protocol logging for communication interfaces

• The first list of protocols (iec104 | dnp | modbus) defines host communication protocols
• The second list of protocols (iec104 | dnp | modbus ) describe the sub-device communication
protocol
• A port number or protocol type needs to be specified, using either the local interface or the re-
mote IP address.
• A port number or protocol type using the local interface refers to a host interface.
• A port number or protocol type using the remote IP address refers to a subdevice interface.
• The default network protocol type is tcp.
• Using the prefix ABBRTU560- eliminates the need of a CPTT Remote I/O Client license. If the
prefix is not included in the configuration string, CPTT will output an error message.

2.8.5 Examples
1 ABBRTU560-srl:cp2
Serial interface CP2
2 ABBRTU560-srl:cpA
Serial interface CPA on CMU01, CMU02 or CMU10
3 ABBRTU560-net:E1:iec104;remote:192.168.1.100
Network interface E1, IEC 60870-5-104 host communication line, host IP address
192.168.1.100
4 ABBRTU560-net:E1:iec104;remote:192.168.1.100/24
Network interface E1, IEC 60870-5-104 host communication line, all host IP addresses are part
of the network 192.168.1.0
5 ABBRTU560-net:E2;remote:192.168.1.100:dnp
Network interface E2, DNP3 LAN/WAN subdevice communication line, IED IP address
192.168.1.100, network protocol TCP
6 ABBRTU560-net:E2;remote:192.168.1.100:dnp;protocol:udp
Network interface E2, DNP3 LAN/WAN subdevice communication line, IED IP address
192.168.1.100, network protocol UDP
7 ABBRTU560-net:E1:1234;remote:192.168.1.100;protocol:tcp
Network interface E1, host communication line with network port 1234, Host IP address
192.168.1.100, network protocol TCP address
8 ABBRTU560-net:E1;remote:192.168.1.100:1234;protocol:udp
Network interface E1, subdevice communication line with network port 1234, IED IP address
192.168.1.100, network protocol UDP
9 ABBRTU560-net:PPP1:iec104;remote:192.21.89.38
IEC 60870-5-104 host communication line via PPP on interface PPP1, host IP address
192.21.89.38

2-28 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Network configuration

3 Networks

3.1 Network configuration

Figure 27: RTU network with interfaces

The entire station network, including router RTUs, sub-RTUs, and IEDs, is configured in the RTU-
til500 software. Configuration of the station network topology is configured in the Network Tree of
RTUtil500. The starting point in this tree is the router RTU of the station network. For detailed infor-
mation on how to build the Network Tree, refer to [1].

3.2 Network configuration rules and restrictions

The configuration of a sub-RTU network is subject to various restrictions with regard to definitions,
physical limitations, address ranges, etc. The following restrictions apply:

• Max. 64 physical serial interfaces available (including SPB)

• Max. 16 host lines
• Max. 32 sublines
• Max. 32 substations (RTUs and IEDs) per line
• Max 150 substations in total
• Each router RTU can be a process RTU

The actual restrictions may differ depending on the communication speed of the station network,
the communication protocols used and the amount of process data points connected to an RTU.

ABB AG - 1KGT 150 896 V002 1 | 3-1

Networks RTU500 series Remote Terminal Unit
Network configuration rules and restrictions

3.2.1 Denial of Service

The denial of service function is designed to limit the CPU load that can be produced by the Ethernet
network traffic to the RTU. The communication facilities must not be allowed to compromise the
primary functionality of the RTU. All inbound network traffic is quota controlled, so that a too heavy
network load can be controlled. Heavy network load might for instance be the result of malfunctioning
equipment connected to the network. In case the limit is exceeding external rate limiters shall be
used.

The denial of service function measures the traffic from an Ethernet port and, if necessary, limits it
from jeopardizing the RTU's functionality due to a high CPU load.

Following limits are applicable:

• RTU560: 425 frames/s

• RTU540: 425 frames/s
• RTU520: 575 frames/s
• RTU511: 575 frames/s
• 560CMU01: 425 frames/s

The function has the following outputs:

• Following internal message is displayed in the RTU system diagnosis if the limit is exceed: CMU
x: Rate monitor interface Exchange to polling mode (Count=n)
• Following internal message is displayed in the RTU system diagnosis the traffic is again below
the limit: CMU x: Rate monitor interface Exchange to interrupt mode (Count=n)

3.3 Virtual Private Network (VPN)

The RTU500 Virtual Private Network Protocol implementation provides a standard method for trans-
porting IP datagrams over a secured communication channel, called VPN tunnel.

The VPN tunnel provides confidentiality, integrity and authenticity.

Confidentiality is keeping the data secret from the unintended listeners on the network.

Integrity is ensuring that the received data is the data was actually sent.

Authenticity is providing the identity of the endpoint to ensure that the end point is the intended
entity to communicate with.

3.3.1 Overview
With the help of VPN a RTU can be connected to control system via the public internet. The data
exchange is secured via the VPN connection. From the user point of view it looks like the RTU500
resides within the NCC network.

3-2 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Virtual Private Network (VPN)

Network control center

NCC
RTU560 Internet
Network
IP sec router

RTU540

Figure 28: Typical configuration for VPN connections

The RTU establishes a VPN connection to the IPsec Router. The VPN tunnel (red line) connects the
virtual RTU network with the NCC network. Therefore a network-to-network connection is estab-
lished. This connection is transparent and secured.

If a connection is established, the RTU can be accessed by a control system using the internal virtual
IP address. All IP based protocols can run on this connection.

The RTU can be remote configured and supervised using a web browser.

3.3.2 Supported Features

The Internet Key Exchange (IKE) is implemented according to the requirements of:

• RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP

• RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409: The Internet Key Exchange Protocol (IKE)
• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3947: Negotiation of NAT-Traversal in the IKE

The Internet Security Protocol (IPsec) is implemented according to the requirements of:

• RFC 2401: Security Architecture for the Internet Protocol

• RFC 2406: IP Encapsulation Security Payload (ESP)

For Phase 1, the IKE supports the following cryptographic algorithms:

• 3DES 168 CBC

• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• BLOWFISH
• DES 56 CBC

For Phase 1, the IKE supports the following hash algorithms (integrity protection and authenticity):

• AES 128
• MD5
• SHA1

For Phase 1, the IKE supports the following Diffie-Hellmann groups:

• MODP group 1 (768 bit)

• MODP group 2 (1024 bit)

ABB AG - 1KGT 150 896 V002 1 | 3-3

Networks RTU500 series Remote Terminal Unit
Virtual Private Network (VPN)

• MODP group 5 (1536 bit)

• MODP group 14 (2048 bit)
• MODP group 15 (3072 bit)
• MODP group 16 (4096 bit)
• MODP group 17 (6144 bit)
• MODP group 18 (8192 bit)

For Phase 2 (IPsec), the IKE supports the following cryptographic algorithms:

• 3DES 168 CBC

• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• BLOWFISH
• DES 56 CBC
• NULL

For Phase 2 (IPsec), the IKE supports the following cryptographic algorithms (integrity protection
and authenticity):

• AES 128
• MD5
• SHA1

For Phase 2 (IPsec), the IKE supports the following Diffie-Hellmann group:

• MODP group 2 (1024 bit)

For peer authentication Pre-Shared Key (PSK) and certificates are supported.

Protocol versions IKEv1 and IKEv2 are supported. IKEv2, the second version of the IKE protocol,
uses the same techniques as IKEv1, but improves upon IKEv1 in the following ways:

• simpler message exchange

• fewer cryptographic mechanisms
• greater reliability through state management
• better resistance to denial-of-service attacks

Only one tunnel on one interface is supported.

Only ESP tunnel mode is supported.

3.3.3 Pre-Shared Key (PSK)

The RTU supports authentication method Pre-shared key. Network peers can establish trust in each
other through the use of a pre-shared key (also called a pre-shared secret). At the start of negotiation,
the peers compare their stored key values. If the keys do not match, authentication and negotiation
fail.

Maximum PSK length is 64 characters.

3-4 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Virtual Private Network (VPN)

3.3.4 Certificates
The RTU supports authentication method Certificates. Network peers can establish trust in each
other through the exchange of X.509 certificates. A certificate binds a peer’s public key to the peer’s
identity. In order to be trusted, the certificate must itself be signed by a trusted Certificate Authority
(CA) or by a member of a chain of trust that ends at such an authority.

3.3.5 Perfect Forward Secrecy (PFS)

The RTU supports Perfect Forward Secrecy. RFC 2409: The Internet Key Exchange (IKE), states
the principle of PFS: the key used to protect a transmission of data must not be used to derive any
additional keys, and if the key used to protect a transmission of data was derived from some other
keying material, that material must not be used to derive any more keys.

If PFS is enabled, Phase 2 performs a new Diffie-Hellman computation of key material. This operation
significantly slows down the exchange but ensures that the Phase 2 traffic will still be protected even
if an attacker breaks the Phase 1 exchange. If PFS is not enabled, Phase 2 uses the key material
generated in Phase 1 to establish keys for the transforms to be used by IPsec.

3.3.6 Dead Peer Detection

To detect dead peers a two different mechanisms are supported:

– DPD (Dead Peer Detection)

– PING (ICMP)

RTU IKE implementation supports dead peer detection, based upon RFC 3706: A Traffic-Based
Method of Detecting Dead Internet Key Exchange (IKE) Peers.

When two peers communicate using IPsec and IKE, a situation may arise in which connectivity
between the two goes down unexpectedly; for example, because of routing problems or if one of
the hosts reboots. In such cases, there is often no way for IPsec and IKE to detect the loss of
connectivity. SAs may remain in existence (until their lifetimes naturally expire), resulting in a “black
hole” situation where packets are tunneled to oblivion. It is desirable to recognize black holes as
soon as possible so that a host can quickly fail over to a different peer. Likewise, detecting black
holes enables the recovery of lost resources.

There is an alternative feature to detect dead peers with ping utility. That alternative requires a host
IP address and an interval time to be configured. The RTU sends a ping to the configured Host
IP address when the Interval time expires. The RTU waits 5 seconds for a ping answer. The RTU
repeats this up to five times. The connection is broken if no answer received. The VPN connection is
torn down and a new connection is established. The configured Host IP address must reside within
the remote network IP address range.

3.3.7 UDP Encapsulation and NAT-Traversal

The RTU supports NAT-Traversal. IPsec NAT-T introduces support for crypto peers to travel through
NAT or PAT devices in the network by encapsulating crypto packets in a UDP wrapper, which allows
packets to traverse NAT device. NAT-T is auto-negotiated between the two crypto peers during
ISAKMP negotiation with a destination UDP port 4500 instead of 500. NAT-T is defined in RFC 3947:
Negotiation of NAT-Traversal in the IKE.

ABB AG - 1KGT 150 896 V002 1 | 3-5

Networks RTU500 series Remote Terminal Unit
Virtual Private Network (VPN)

3.3.8 VPN connection set up

The IPsec connection setup is divided in two phases. IPsec connections are based on Security
Associations (SA). The SAs are created from the IKE protocol during connection setup.

Setting up an IPsec connection starts with IKE Phase 1 and is the initial negotiation of a bi-direc-
tional connection between two crypto peers, referred to as main mode. IKE Phase 1 begins with an
authentication in which each crypto peer verifies their identity with each other (Certificates or PSK).
When authenticated, the crypto peers agree upon the encryption algorithm, hash method and other
parameters (e.g. IKE SA lifetime). The negotiated SA information is stored locally in the SA database
of each crypto peer.

In IKE Phase 2, the IPsec SAs are negotiated by the IKE process using the bi-directional SA, referred
as quick mode.

The IPsec SAs are uni-directional in nature, causing separate key exchange for data flowing in each
direction. One of the advantages is to double the amount of work required by an eavesdropper to
successfully recover both sides of a conversation.

During IKE Phase 2 the crypto peers agree upon the encryption algorithm, authentication (hash)
methods and other parameters (e.g. IPsec SA lifetime).

3.3.9 VPN configuration

Step 1: Configure the used IP interface (Ethernet or PPP). Enable VPN on this IP interface.

3-6 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Virtual Private Network (VPN)

Figure 29: Configuration of an IP interface

Step 2: Configure the IPsec Peers

The local IP address is taken from the interface configuration and can’t be modified. Set the Remote
IP address (public IP address of the IPsec server).

ABB AG - 1KGT 150 896 V002 1 | 3-7

Networks RTU500 series Remote Terminal Unit
Virtual Private Network (VPN)

Figure 30: VPN settings

Step 3: Configure the IPsec Networks

First configure the local virtual network. Set the desired Local virtual IP address. This address can
be used to access the RTU from the NCC. Also set the Local virtual network and the Local virtual
netmask. A typical value is 255.255.255.0 because only one IP address of the address space is
used.

Second configure the remote network. Set the Remote network. It is the network reachable through
the VPN tunnel. Also set the network mask of this network.

Step 4: Configure the IKE version

Select the used IKE protocol version allowed for tunnel negotiation and establishment. IKEv1 and
IKEv2 means the RTU tries to connect with v1 and accepts both v1 and v2.

Step 5: Configure the Authentication method

3-8 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

Select Certificates or Pre-shared key (PSK). The PSK is an ASCII character string up to 64 characters.
This key must be the same on the RTU and the IPsec server.

Example: “dh34E2k_iew9j823H&,spwDkd43Hez23”

Authentication using Certificates is explained by means of an example in a separate chapter below.

Step 6: Configure IKE (Phase 1)

Configure the security policies for the IKE authentication. Specify the encryption algorithm, authen-
tication algorithm and Diffie-Hellmann group.

It is also possible to modify the IKE SA Lifetime. After 75% of this time the SA is renewed. It isn’t
possible until the SA Lifetime expires the SA is deleted and the connection is turned down.

The SA Lifetime may be changed when the server uses the strict policy option. In this case a con-
nection setup is only successful if the SA lifetimes are the same.

The used values have to be matched the settings of the IPsec server otherwise no connection can
be established.

Step 7: Configure IPsec (Phase 2)

Configure the security policies for the IPsec connection (Phase 2). These parameters are typically
the same as in IKE Phase 1. But it is also possible to use different values.

For advanced user it is also possible to modify the IPsec SA Lifetime. After 75% of this time the
SA is renewed. It isn’t possible until the SA Lifetime expires the SA is deleted and the connection
is torn down.

The SA Lifetime may be changed when the server uses the strict policy option. In this case a con-
nection setup is only successful if the SA Lifetimes are the same.

Perfect forward secrecy is enabled per default.

Step 8: Configure Dead peer detection

To detect a dead VPN connection, select between two methods DPD and PING.

3.4 VPN Configuration with Sophos UTM

This chapter describes an example configuration between RTU520 with GPRS Modem and Sophos
UTM using certificate based authentication.

ABB AG - 1KGT 150 896 V002 1 | 3-9

Networks RTU500 series Remote Terminal Unit
VPN Configuration with Sophos UTM

3.4.1 Preliminaries

Define local and remote networks.

Definition:

• Local virtual network is on RTU site. This must be different to IP address range for E1 inter-
face. Under this IP address RTU is reachable from control system.
• VPN Remote network is on Control System site.
• Fixed public IP address is on Control System site.

For RTU local virtual network only one IP address for RTU is required. This results in a small subnet
for each VPN connection (/30), with 64 subnets in a range of one class C network.

Here is an example for Local virtual network with starting subnet 192.168.0.0:

RTU Name RTU IP address Network Netmask CIDR-Suffix

1 192.168.0.1 192.168.0.0 255.255.255.252 /30

2 192.168.0.5 192.168.0.4 255.255.255.252 /30

3 192.168.0.9 192.168.0.8 255.255.255.252 /30

4 192.168.0.13 192.168.0.12 255.255.255.252 /30

………

64

65 192.168.1.1 192.168.1.0 255.255.255.252 /30

The VPN remote network needs to be in a different subnet (different to Local virtual network and
E1 network).

3-10 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

Receive GPRS Information from Provider.

Depending on your provider the following information is required:

• APN (if possible APN without NAT, see examples in appendix)

• APN Login (in most cases for username and password any is accepted, in some cases empty
username or password is not allowed)
• SIM PIN (if not disabled on SIM card)
• Fixed Public IP address (External (WAN) interface of VPN server)

Define encryption policy for VPN connection between RTUs and VPN server.

With Sophos UTM following configuration has been tested:

IKE Version
X IKEv1

IKEv2

IKEv1 and IKEv2

ISAKMP Parameter

IKE encryption algorithm

3DES

AES 128 CBC

AES 256 CBC

IKE authentication algorithm

AES128

MD5

SHA1

IKE DH group
group 5: MODP 1536-bit

X group 2: MODP 1024-bit

group 1

Authentication
Preshared Key

RSA Key

RSA Key RSA key with FQDN:

IKE SA lifetime (Phase 1)

28800 sec

9600 sec

3600 sec

IPsec SA Parameter

ABB AG - 1KGT 150 896 V002 1 | 3-11

Networks RTU500 series Remote Terminal Unit
VPN Configuration with Sophos UTM

X ESP

IPSec encryption algorithm

3DES

AES 128

AES 256

IPSec authentication algorithm

AES128

SHA1

MD5

IPSec SA lifetime (Phase 2)

28800 sec

9600 sec

3600 sec

IPSec PFS

IPSec PFS group

X group 2: MODP 1024-bit

Compression not supported

Dead peer detection

Keep alive method

X DPD

A valid policy @Sophos UTM need to be defined or selected. Naming could be RTU_GPRS

3.4.2 Create certificates

Sophos UTM bring all infrastructure with the device that is required for certificate based authentica-
tion via IPSec VPN.

Here is a step by step description how to do with Sophos UTM Version 8.

Generate X509 certificate for each RTU via web interface @Sophos UTM

Click on Site-to-site VPN and then

3-12 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

“Certificate Management”

Then click to “New certificate...”

The field Name, VPN ID and Common Name should be the same. In this example
RTU520.RTUName is used. Replace RTU520 with your device and RTUName with the Station Name
of your RTU. The dot in the name is required.

Select as VPN ID Type: Hostname. Fill the other values with your information.

For each VPN connection to a RTU an own certificate is required.

Download X509 certificate and define transport password @Sophos UTM

Search created certificate in list and clock on download:

ABB AG - 1KGT 150 896 V002 1 | 3-13

Networks RTU500 series Remote Terminal Unit
VPN Configuration with Sophos UTM

Export as “PKCS#12” certificate and enter transport password in Export password field, repeat and
click “Download” again.

Save this to your local disc. This certificate is required later on RTU web server. The password as well.

On this table you can write down your transport passwords:

Certificate Password

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

RTU-……………….

3.4.3 Configure VPN Router

Create “New Remote Gateway” @Sophos UTM

Click on Site-to-site VPN and then “IPSec”

3-14 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

Then Click on ”New Remote Gateway...”

Add New Remote Network definition (if not available) via ”+” button:

Fill in name is a good way. E.g. Using geographical identifier like

CS for Control System

N for Network

NG for NetworkGroup

H for Host

HG for Hostgroup

192.168.0.0 for NetworkAddress

192.168.0.1 for IPAddress

Location_N_NetworkAddress
Host_H_IPAddress

Fill in ”Add Remote Gateway” form:

ABB AG - 1KGT 150 896 V002 1 | 3-15

Networks RTU500 series Remote Terminal Unit
VPN Configuration with Sophos UTM

Define a Name with e.g. RTU and Network Information is in.

Gateway type is Respond only, because IP address of RTU via GPRS is always the same.

Authentication type is Local X509 Certificate

Certificate: select created RTU certificate

Create “New IPSec connection” @Sophos UTM

Click “Connections” Tab

Then Click on ”New IPSec connection...”

Use a useful name, like reuse defined VPN Network information and Station name:

e.g. RTU-Station_192.168.0.0/30===CS_172.16.100.0/24

3-16 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

Fill in ”Edit IPSec connection” form:

3.4.4 Configure RTU

Start RTU500 engineering tool (RTUtil500) and open your project.

In the hardware tree select the CMU and switch to tab “Network Interfaces”.

Switch to “PPPx” tab and fill in User name and Password for GPRS communication.

Select the “CPx” tab, where your modem will be connected:

ABB AG - 1KGT 150 896 V002 1 | 3-17

Networks RTU500 series Remote Terminal Unit
VPN Configuration with Sophos UTM

Click Dial up parameters and fill in APN and PIN, if required:

Switch to tab “Network Interfaces” and “PPPx”:

Enable the VPN checkbox and click Configuration:

VPN settings need to be filled in regarding your definitions in chapter Preliminaries:

3-18 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

Enable routing setting for PPP interface. Define network and netmask. Gateway is handled auto-
matically according to the dial-in server of your provider.

ABB AG - 1KGT 150 896 V002 1 | 3-19

Networks RTU500 series Remote Terminal Unit
VPN Configuration with Sophos UTM

3.4.5 Download X509 certificate @RTU

Download X509 certificate to RTU via webserver.

Open Hardware Tree:

And select “Network Interfaces”

Then click “VPN administration” tab:

To upload certificate, click “Browse…” button and select certificate file from your local drive:

3-20 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
VPN Configuration with Sophos UTM

Enter transport password for certificate in the field: “Certificate file password”. Then click “Upload
certificate” and wait until the following message comes up:

After successful loaded certificate more details about the certificate will be displayed.

3.4.6 Establish communication

To establish communication restart RTU and check that the following System Diagnosis events are
displayed:

CMU x: VPN initialization successfully completed.

VPN: Tunnel 1 to remote network ‘xxx.xxx.xxx.xxx’ setup.

VPN: Tunnel 1 to remote network ‘xxx.xxx.xxx.xxx’ established.

3.5 Templates

3.5.1 VPN IPSec encryption template

to communicate with VPN administrator:

RTU500 VPN IPSEC

RTU Public IP Address dynamic

RTU local virtual IP address ___.___.___.___

RTU local virtual network ___.___.___.___

RTU local virtual netmask ___.___.___.___ CIDR-Suffix /___

Customer Public IP Address ___.___.___.___

Customer private (remote) network ___.___.___.___

Customer private (remote) netmask ___.___.___.___ CIDR-Suffix /___

ABB AG - 1KGT 150 896 V002 1 | 3-21

Networks RTU500 series Remote Terminal Unit
Templates

Policies

IKE Version
IKEv1

IKEv2

IKEv1 and IKEv2

Authentication
Preshared Key

RSA Key (certificates)

RSA Key (certificates) RSA key with FQDN (Fully Qualified Domain Name)

IKE (Phase 1) Parameter

IKE encryption algorithm

3DES 168 CBC

AES 128 CBC

AES 192 CBC

AES 256 CBC

BLOWFISH

DES 56 CBC

IKE authentication algorithm

AES128

SHA1

MD5

IKE DH group
group 1: MODP 768 bit

group 2: MODP 1024 bit

group 5: MODP 1536 bit

group 14: MODP 2048 bit

group 15: MODP 3072 bit

group 16: MODP 4096 bit

group 17: MODP 6144 bit

group 18: MODP 8192 bit

IKE SA lifetime (Phase 1)

28800 sec

9600 sec

3600 sec

3-22 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Templates

IPsec (Phase 2) Parameter

X ESP

IPSec encryption algorithm

3DES 168 CBC

AES 128 CBC

AES 192 CBC

AES 256 CBC

BLOWFISH

DES 56 CBC

NULL

IPSec authentication algorithm

AES128

SHA1

MD5

IPSec DH group
X group 2: MODP 1024 bit

IPSec SA lifetime (Phase 2)

28800 sec

9600 sec

3600 sec

IPSec PFS (perfect forward secrecy)

Compression not supported

3.5.2 CIDR List

CIDR Netmask IPs in subnet Hosts per subnet Comments

/32 255.255.255.255 1 1

/31 255.255.255.254 2 - Not usable

/30 255.255.255.252 4 2

/29 255.255.255.248 8 6

/28 255.255.255.240 16 14

/27 255.255.255.224 32 30

/26 255.255.255.192 64 62

/25 255.255.255.128 128 126

/24 255.255.255.0 256 254 Class C network

/23 255.255.254.0 512 510

ABB AG - 1KGT 150 896 V002 1 | 3-23

Networks RTU500 series Remote Terminal Unit
Templates

CIDR Netmask IPs in subnet Hosts per subnet Comments

/22 255.255.252.0 1.024 1.022

/21 255.255.248.0 2.048 2.046

/20 255.255.240.0 4.096 4.094

/19 255.255.224.0 8.192 8.190

/18 255.255.192.0 16.384 16.382

/17 255.255.128.0 32.768 32.766

/16 255.255.0.0 65.536 65.534 Class B network

/15 255.254.0.0 131.072 131070

/14 255.252.0.0 262.144 262.142

/13 255.248.0.0 524.288 524.286

/12 255.240.0.0 1.048.576 1.048.574

/11 255.224.0.0 2.097.152 2.097.150

/10 255.192.0.0 4.194.304 4.194.302

/9 255.128.0.0 8.388.608 8.388.606

/8 255.0.0.0 16.777.216 16.777.214 Class A network

/7 254.0.0.0 33.554.432 33.554.430

/6 252.0.0.0 67.108.864 67.108.862

/5 248.0.0.0 134.217.728 134.217.726

/4 240.0.0.0 268.435.456 268.435.454

/3 224.0.0.0 536.870.912 536.870.910

/2 192.0.0.0 1.073.741.824 1.073.741.822

/1 128.0.0.0 2.147.483.648 2.147.483.646

/0 0.0.0.0 all all all

3.5.3 APN List for Germany

Provider APN Username Password

T-Mobile Internet.t-d1.de internet t-d1

Vodafone volume.d2gprs.de Internet d2

3-24 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Parallel Redundancy Protocol (PRP)

3.6 Parallel Redundancy Protocol (PRP)

3.6.1 Overview
The Parallel Redundancy Protocol (PRP) provides a standard method to obtain redundancy in net-
works, using doubly attached nodes obeying to PRP (DANPs). PRP implements redundancy func-
tions in the end nodes rather than in network elements.

A doubly attached node DANP is attached to two independent Local Area Networks (LANs) of similar
topology, named LAN_A and LAN_B, which operate in parallel. A source DANP sends the same
frame over both LANs and a destination DANP receives it from both LANs within a certain time,
consumes the first frame and discards the duplicate.

The following figure shows a redundant network consisting of two LANs, each of which can have
any topology, e.g. tree, ring or meshed.

Source
SAN DANP DANP
A1
B- frame
A- frame

B ridge B ridge
Bridged Local Area
Bridged Local Area Network (tree)
Network (ring) LAN_B
LAN_A

B ridge B ridge B ridge B ridge

SAN
A2 RedBox SAN SAN
B1 B2

A- frame B- frame

DANP DANP DANP

SAN SAN
Destination R1 R2

Figure 31: PRP network consisting of two LANs with different topology

The two LANs have no connection between them and are assumed to be fail-independent. Redun-
dancy can be defeated by single points of failure, such as a common power supply or a direct con-
nection whose failure brings both networks down.

Additional to DANPs the networks can contain singly attached nodes (SANs). These nodes can be
attached in two ways:

– SANs can be attached directly to one LAN only. Such SANs can only communicate with other
SANs on the same LAN. For instance, in the figure above, SAN A1 can communicate with SAN
A2, but not with SAN B1 or SAN B2. SANs can communicate (not redundantly) with all DANPs.
– SANs can be attached over a RedBox (redundancy box) to both LANs, as the figure shows
for SAN R1 and SAN R2. Such SANs can communicate with all DANP and SANs, for instance
SAN A1 and SAN R1 can communicate. These kind of SANs are named virtual doubly at-
tached node VANP too.

For further, detailed information see PRP standard documentation IEC 62439-3 [7].

ABB AG - 1KGT 150 896 V002 1 | 3-25

Networks RTU500 series Remote Terminal Unit
Parallel Redundancy Protocol (PRP)

3.6.2 PRP in RTU500 series

The RTU500 series supports PRP in different ways. As singly attached node SAN each RTU500
series CMU that provides at least one Ethernet interface can be used. As doubly attached nodes
only RTU500 series CMUs with two Ethernet interfaces can be used. The figure below shows a
simple RTU500 series PRP setup with SCI IEC 61850.

NCC via host protocol Web client to RTU

SCI IEC 61850

RTU560

SNTP Server 1 SNTP Server 2

RedBox RedBox

Ethernet Switch Ethernet Switch LAN B

LAN A

RedBox
RedBox

SAN IED SAN IED

The PRP implementation for the RTU500 series is defined by the following basic points:
– The RTU500 series supports the newer PRP-1 protocol (PRP 2012, IEC 62439-3 (2012)) only.
The older PRP-0 protocol is not supported by the RTU500 series.
– PRP is supported on CMUs with two Ethernet interfaces (e.g. 560CMU05, 560CID11,
560CMD11) only.
– Up to 8 CMUs with PRP configuration are supported within a RTU560 rack system.
– The RTU500 series supports communication with other DANPs and SANs according to the
network restrictions.
– All network host and subdevice communication protocols can be used with PRP. There is no
restriction to certain protocols like IEC 61850.
– Other network functionality like web server, HMI or SNTP time synchronization works via PRP
as well. There is no restriction to certain network functionalities.
– The IPv4 routing of the network interfaces is not restricted when using PRP.
– The PRP connection status can be supervised by system events. See chapter “PRP supervi-
sion” for more information.

3-26 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Parallel Redundancy Protocol (PRP)

– Protocol logging via CPTT is possible with PRP. See chapter “Protocol logging for communica-
tion interfaces” for detailed information.
– The RTU500 series CMU redundancy can be used together with PRP. In this case a CMU
switch over is possible when both networks links of a CMU fail.

The following restrictions apply if using PRP on an RTU500 series CMU:

– In PRP configurations the RTU500 series CMU uses the same IP and MAC address on both
Ethernet interfaces. Therefore the connected LAN must have no connection between them.
– PRP cannot be used together with VPN.
– PRP cannot be used via PPP or USB RNDIS.

3.6.3 PRP configuration

The PRP configuration can be found in RTUtil500 at the ‘Network Interfaces’ tab of a CMU. The
following figure shows an example for a RTU560 with 560CMU05 and enabled PRP.

Figure 32: CMU parameters - Tab: network interfaces

The main PRP CMU configuration parameters are:

Parameter name Default Parameter location

Enable PRP for Ethernet interfaces Disabled CMU parameter - Network interfaces

Enable PRP on CMUs with two Ethernet interfaces

PRP interface number 1 CMU parameter - Network interfaces

Unique PRP interface number within an RTU. Value range from 1 to 8. Select from list.

ABB AG - 1KGT 150 896 V002 1 | 3-27

Networks RTU500 series Remote Terminal Unit
Parallel Redundancy Protocol (PRP)

The notes below have to be considered for the PRP CMU configuration parameters:

– When enabling PRP a confirmation dialog is shown to acknowledge the usage.

– When enabling PRP the network interface tabs ‘E1’ and ‘E2’ are replaced by a new tab called
‘PRP’. On this tab network parameters like IP address and subnet mask are configured for the
PRP interface.

Additional to the main, specific PRP parameters are available. These parameters are set in a separate
dialog, shown when selecting the button ‘Configuration’ besides the PRP interface number. An
example is shown in the figure below.

The specific PRP configuration parameters are:

Parameter name Default Parameter location

PRP type PRP-1 CMU parameter - Network interfaces

PRP protocol type. Not changeable and set to the fix value PRP-1.

Node forget time 60 secs CMU parameter - Network interfaces

A connected PRP node is considered not reachable when the time elapsed since reception of a frame from that node over
both LANs exceeds the node forget time. The PRP node forget time is set in seconds. Value range from 10 to 320 seconds.

Life check interval 10 secs CMU parameter - Network interfaces

Every life check interval a PRP node sends a supervision frame (see below). The PRP life check interval is set in seconds.
Value range from 2 to 60 seconds.

Supervision MAC address 0x00 CMU parameter - Network interfaces

Every PRP node sends a supervision frame every life check interval to this multicast address. According to the standard, the
first 5 octets of this MAC address must match 01:15:4E:00:01. The last token of the supervision MAC address can be set
here. Value range from 0x00 to 0xfd.

CMU redundancy switch over in case of link Disabled CMU parameter - Network interfaces
failure

Enables CMU switch over in case both PRP links of a CMU fails. Only visible if CMU has redundancy mode active or standby.

3-28 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Networks
Parallel Redundancy Protocol (PRP)

The notes below have to be considered for the specific PRP configuration parameters:
– The node forget time must be greater than the life check interval. It shall be set at least two
times the life check interval.
– The parameters supervision MAC address and life check interval must be set to the same value
for every PRP node in the network.
– The life check interval requires receiving and processing of a supervision frame from each node
in the network within the time interval. For performance considerations the interval time shall
not be set below 10 seconds (especially in large PRP configurations).

3.6.4 PRP supervision

The PRP connection status of a CMU and the PRP communication status of all connected DANP
nodes (devices) are supervised. The actual status can be derived from system events provided by
the RTU500.

The RTU500 PRP implementation supports the system events summarized in the following table:

System event Description Shortcut

PRP interface n: Network interface E1 link up Signalize link status of interface 'E1' using #277 - #284
PRP interface n to the next network de-
vice (e.g. switch)

PRP interface n: Network interface E2 link up Signalize link status of interface 'E2' using #285 - #292
PRP interface n to the next network de-
vice (e.g. switch)

Device reachable on redundant line 1 Signalize communication status to the re- #180
ferring subordinated PRP device (node)
via network interface 'E1'

Device reachable on redundant line 2 Signalize communication status to the re- #181
ferring subordinated PRP device (node)
via network interface 'E2'

The system events ‘SEV#277 - #292 PRP interface n: Network interface Ex link up’ are located at
the system data interface of the CMU. The system event ‘SEV#180 - #181 Device reachable on
redundant line x’ are located at the system data interface of the subordinated PRP devices.

The meaning of the system event values are as defined in the table below:

System event Value Meaning

PRP interface n: Network interface Ex link up On Link of interface 'Ex' using PRP interface n to the
next network device is up

Off Link of interface 'Ex' using PRP interface n to the

next network device is down

Device reachable on redundant line x On Subordinated PRP device reachable via network
interface ‘Ex’

Off Subordinated PRP device not reachable via net-

work interface ‘Ex’

The following restrictions apply to the PRP system events:

ABB AG - 1KGT 150 896 V002 1 | 3-29

Networks RTU500 series Remote Terminal Unit
Parallel Redundancy Protocol (PRP)

– In case the system events ‘SEV#277 - #292 PRP interface n: Network interface Ex link up’ are
missing in PRP configurations, the affected system events are written to the configuration file
nevertheless. As result the system events are available in the system diagnosis in any case.
– The system events ‘Device reachable on redundant line x’ are available only, if a PRP interfaces
is used with a SCI activity.
– The system events ‘Device reachable on redundant line x’ are set by the PRP implementation
independent from the used communication protocol. It doesn’t represent the connection sta-
tus of the protocol. The protocol status is signalized by the system event ‘Device inoperable’.
Both system events shall show in normal situations the same status. But due to different time-
outs the status can differ when a device just connects or disconnects.
– PRP doesn’t provide a supervision of SAN devices (nodes). These devices must be supervised
by other system events like ‘Device inoperable’.

3-30 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit Glossary

4 Glossary
CMU Communication and Data Processing Unit

CS Control System

DANP Doubly attached nodes obeying to PRP

IED Intelligent Electronic Device

NCC Network Control Center

PDP Process Data Processing

PPP Point to Point Protocol

PRP Parallel Redundancy Protocol

RTU Remote Terminal Unit

SAN singly attached PRP nodes

SCADA Supervision, Control and Data Acquisition

SCI Sub-Device Communication Interface

SEV System Event

SLC Serial Line Controller

SPB Serial Peripherial Bus is the RTU I/O bus used with RS485 or fibre optical media

VPN Virtual Private Network

ABB AG - 1KGT 150 896 V002 1 | 4-1

  RTU500 series Remote Terminal Unit

2 | 1KGT 150 896 V002 1 - ABB AG

RTU500 series Remote Terminal Unit  

Note:

The specifications, data, design or other information contained in this document (the “Brochure”)
- together: the “Information” - shall only be for information purposes and shall in no respect be
binding. The Brochure does not claim to be exhaustive. Technical data in the Information are only
approximate figures. We reserve the right at any time to make technical changes or modify the
contents of this document without prior notice. The user shall be solely responsible for the use of
any application example or information described within this document. The described examples
and solutions are examples only and do not represent any comprehensive or complete solution. The
user shall determine at its sole discretion, or as the case may be, customize, program or add value
to the ABB products including software by creating solutions for the end customer and to assess
whether and to what extent the products are suitable and need to be adjusted or customized.

This product is designed to be connected to and to communicate information and data via a network
interface. It is the users sole responsibility to provide and continuously ensure a secure connection
between the product and users or end customers network or any other network (as the case may
be). The user shall establish and maintain any appropriate measures (such as but not limited to
the installation of firewalls, application of authentication measures, encryption of data, installation of
anti-virus programs, etc) to protect the product, the network, its system and the interface against any
kind of security breaches, unauthorized access, interference, intrusion, leakage and/or theft of data
or information. ABB AG is not liable for any damages and/or losses related to such security breaches,
any unauthorized access, interference, intrusion, leakage and/or theft of data or information.

ABB AG shall be under no warranty whatsoever whether express or implied and assumes no re-
sponsibility for the information contained in this document or for any errors that may appear in this
document. ABB AG's liability under or in connection with this Brochure or the files included within
the Brochure, irrespective of the legal ground towards any person or entity, to which the Brochure
has been made available, in view of any damages including costs or losses shall be excluded. In
particular ABB AG shall in no event be liable for any indirect, consequential or special damages,
such as – but not limited to – loss of profit, loss of production, loss of revenue, loss of data, loss
of use, loss of earnings, cost of capital or cost connected with an interruption of business or oper-
ation, third party claims. The exclusion of liability shall not apply in the case of intention or gross
negligence. The present declaration shall be governed by and construed in accordance with the
laws of Switzerland under exclusion of its conflict of laws rules and of the Vienna Convention on the
International Sale of Goods (CISG).

ABB AG reserves all rights in particular copyrights and other intellectual property rights. Any repro-
duction, disclosure to third parties or utilization of its contents - in whole or in part - is not permitted
without the prior written consent of ABB AG.

© Copyright ABB 2014

All rights reserved

ABB AG - 1KGT 150 896 V002 1 | 3