IndustrialIT

800xA - System
System Version 5.0

Automation System Network

Design and Configuration
 IndustrialIT
800xA - System
System Version 5.0

Automation System Network

Design and Configuration
NOTICE
This document contains information about one or more ABB products and may include a
description of or a reference to one or more standards that may be generally relevant to
the ABB products. The presence of any such description of a standard or reference to a
standard is not a representation that all of the ABB products referenced in this document
support all of the features of the described or referenced standard. In order to determine
the specific features supported by a particular ABB product, the reader should consult the
product specifications for the particular ABB product.

The information in this document is subject to change without notice and should not be
construed as a commitment by ABB. ABB assumes no responsibility for any errors that
may appear in this document.

In no event shall ABB be liable for direct, indirect, special, incidental or consequential
damages of any nature or kind arising from the use of this document, nor shall ABB be
liable for incidental or consequential damages arising from use of any software or hard-
ware described in this document.

This document and parts thereof must not be reproduced or copied without written per-
mission from ABB, and the contents thereof must not be imparted to a third party nor used
for any unauthorized purpose.

The software or hardware described in this document is furnished under a license and
may be used, copied, or disclosed only in accordance with the terms of such license.

This product meets the requirements specified in EMC Directive 89/336/EEC and in Low
Voltage Directive 72/23/EEC.

TRADEMARKS
All rights to copyrights, registered trademarks, and trademarks reside with their respec-
tive owners.

Copyright © 2003-2006 by ABB.

All rights reserved.

Release: September 2006

Document number: 3BSE034463R5001
 TABLE OF CONTENTS

About This Book

General ............................................................................................................................13
Document Conventions ...................................................................................................14
Warning, Caution, Information, and Tip Icons................................................................14
Terminology.....................................................................................................................15
Related Documentation ...................................................................................................17

Section 1 - Introduction
Network Topologies ........................................................................................................20
Plant Network.......................................................................................................21
Client/Server Network .........................................................................................21
Control Network...................................................................................................21
Network Areas .....................................................................................................22
Combined Client/Server and Control Network....................................................22
Client/Server Network and Control Network on Separate Network Areas .........23
Large Configuration with Control Network on Two Network Areas ..................24
Controller Communication via PPP .....................................................................25
Introduction of Network Redundancy .............................................................................26
Selection of IP Addresses ................................................................................................27
Recommended IP Address Plan ...........................................................................28
Recommended IP Address Plan for Non-RNRP Networks .................................32
Introduction of Domain Controllers ................................................................................33
Introduction of DNS ........................................................................................................34

3BSE034463R5001 5
Table of Contents

Section 2 - Distributed System Topologies

Extend the 800xA Automation System Network............................................................ 36
Equal System Sections on Different Locations............................................................... 39
Security Considerations .................................................................................................. 40

Section 3 - RNRP and Network Configurations

Redundant Network Routing Protocol (RNRP) .............................................................. 41
Network Areas ................................................................................................................ 43
Fault Handling within a Network Area................................................................ 44
Multiple Network Areas and RNRP Routers....................................................... 46
Local Network Areas ........................................................................................... 51
RNRP Address Configuration: Implicit or Explicit ........................................................ 52
Using Explicit RNRP Configuration ................................................................... 53
Address Rules for Implicit RNRP Configuration ................................................ 54
RNRP Configuration Parameters......................................................................... 56
Mixing Explicit and Implicit RNRP Configuration............................................. 62
Interconnection of Network Areas over WAN................................................................ 62
Use of Standard IP Routers between RNRP Network Areas............................... 63
Use of Layer 2 VPN Solutions ............................................................................ 66
Use of Layer 3 VPN Solutions ............................................................................ 67
RNRP in a PC.................................................................................................................. 67
Configuring a Network Adapter .......................................................................... 67
Installing RNRP ................................................................................................... 68
Configuring RNRP in a PC.................................................................................. 68
Verify RNRP Connectivity .................................................................................. 70
Configuring what Networks to Use ..................................................................... 70

Section 4 - Domain and DNS Configuration

DNS Strategies ................................................................................................................ 71
Choosing Names for Domains and PCs............................................................... 71
Allocating 800xA Systems to Domains............................................................... 72
Configuring DNS Functionality ...................................................................................... 73
NetBIOS Considerations ................................................................................................. 73

6 3BSE034463R5001
 Table of Contents

Which Nodes use DNS ....................................................................................................74

Location of Domain Controllers......................................................................................74
Operating System for Domain Controllers......................................................................75
Maintaining Redundant Domain Controllers ..................................................................75
DcDiag: Domain Controller Diagnostics .............................................................75
Backups of Domain Controllers...........................................................................75
Recovering after a Crash of the First Installed Domain Controller .....................76
Time Synchronization in a Domain.................................................................................78
DNS Server Configuration ..............................................................................................78
Assuring that Forward Lookup Queries give a Unique IP Address.....................81
DNS Configuration in Each Node ...................................................................................83
Configuring the Order of the Network Interfaces ................................................86
Windows Workgroups Instead of Windows Domain ......................................................87
Managing PC Names with Host Files ..................................................................88
Example of IP Addresses and DNS Configuration .........................................................89
Verifying DNS and NetBIOS Configuration ...................................................................91
nslookup .............................................................................................................91
Special Considerations when Changing DNS Configuration ..............................93
Verifying NetBIOS Configuration .......................................................................93

Section 5 - Time Synchronization

Recommended Time Synchronization Schemes .............................................................96
Local Time Source ...............................................................................................96
External Time Source.........................................................................................100
Windows Time Instead of AfwTime ..................................................................103
Systems with More Than One Control Network................................................106
Systems with MB 300 and 800xA for AC 800M...............................................107
MB 300 as Time Source for AC 800M .............................................................. 111
Synchronization from the Client Server Network..............................................114
Configure Time Synchronization in Controllers ...........................................................117
Time Synchronization Parameters for AC 800M...............................................117
Time Synchronization for MB 300 via CI855....................................................119
Time Synchronization in Advant Master Controllers ........................................120

3BSE034463R5001 7
Table of Contents

CNCP - Control Network Clock Protocol..................................................................... 120

Forwarding of CNCP Between Network Areas................................................. 122
SNTP - Simple Network Time Protocol........................................................................ 122
SNTP Implementations...................................................................................... 122
Stratum .......................................................................................................... 123
SNTP Servers on a Redundant Network............................................................ 123
Routing SNTP Traffic........................................................................................ 124
Configuring SNTP ............................................................................................. 124
MB 300 Time Synchronization ..................................................................................... 124
MMS Time Synchronization ......................................................................................... 126
AfwTime Service .......................................................................................................... 126
Configuration of the AfwTime Service ............................................................. 128
Configuring the AfwTime Server and the Server Group................................... 130
Configuring an AfwTime Client ........................................................................ 132
Time Synchronization for Connectivity Servers, Time Adaptors ................................. 134
AC 800M Time Adaptor .................................................................................... 135
Advant Master Time Adaptor ............................................................................ 135
Time Synchronization on the RTA Board .......................................................... 136
Time Sync with 800xA for Harmony ................................................................ 138
Time Sync with 800xA for Melody ................................................................... 139
Windows Time Service (W32Time).............................................................................. 139
Disable/Enable the Windows Time Service....................................................... 140
Configuring Time Zone and Daylight Saving Time Support............................. 141
Enable the SNTP Server, Disable SNTP Client in a PC .................................... 142
Configure Time Synchronization in a Dedicated Domain Controller ............... 143
Comparison Between W32Time and the AfwTime Service.............................. 144
Tuning the Synchronization Rate for W32Time................................................ 145
Setting the System Time................................................................................................ 145
Setting the Time with the Control Builder M .................................................... 147
Setting the Time for the AfwTime Service ........................................................ 148
Adjust the Time in AC 800M via the Function Block SetDT ........................... 149
Handling Time Changes when Using W32Time ............................................... 150

8 3BSE034463R5001
 Table of Contents

Adjusting Time with 800xA for Melody or 800xA for Harmony......................151

Fault Tracing Time Synchronization Problems .............................................................151
Fault Tracing Time Sync in Controllers.............................................................151
Fault Tracing SNTP............................................................................................153
Fault Tracing AfwTime......................................................................................153

Section 6 - Network Monitoring and Maintenance

System Status Viewer ....................................................................................................155
Afw Service Connection Status Viewer ........................................................................158
Topology Designer / Topology Status Viewer...............................................................159
Node Status Alarms .......................................................................................................160
Ping ............................................................................................................................161
RNRP Network Monitor................................................................................................161
RNRP Events in Controllers ..............................................................................163
RNRP Fault Tracer/RNRP Utility .................................................................................164
Network Interface Supervision in a PC .........................................................................165
Network Interface Supervision in a Controller .............................................................166
Monitoring MMS Communication................................................................................168
Using Network Management information.....................................................................169
PC, Network and Software Monitoring .............................................................169
Network Management Tools from Switch Vendors ...........................................171

Section 7 - Ethernet and Network Equipment

Building a Physical Network.........................................................................................173
Hubs and Switches ........................................................................................................174
Features in Switches ......................................................................................................175
Managed Switches .............................................................................................175
Basic Requirements on Switches .......................................................................176
Features not Required in Switches .....................................................................176
Recommended Features in Switches..................................................................177
Ethernet Speed...............................................................................................................177
Physical Network Installation........................................................................................177
Coexistence of Network Types ..........................................................................179

3BSE034463R5001 9
Table of Contents

Reducing HW using Virtual LANs .................................................................... 179

Ring Redundancy............................................................................................... 180
Using Rapid Spanning Tree ............................................................................... 181
Environmental Consideration ............................................................................ 183
Connecting to a Redundant Network ............................................................................ 185
Connecting a PC ................................................................................................ 186
Connecting a Controller without CPU Redundancy.......................................... 186
Connecting a Controller with CPU Redundancy ............................................... 187
Routers .......................................................................................................................... 188

Section 8 - Network Security

Establish a Network Security Policy............................................................................. 189
The Onion Approach..................................................................................................... 190
Firewalls ........................................................................................................................ 192
Connections to 800xA Systems through Firewalls ....................................................... 194
Connect Inside-out Instead of Outside-in .......................................................... 194
Network Address Translation in Firewalls ........................................................ 194
Single Firewall or a Demilitarized Zone............................................................ 197
Connecting a Firewall to a Redundant Network................................................ 201
Using an Extra Network for Remote Access ..................................................... 202
Virtual Private Networks (VPN) for Secure Connections ................................. 203
Use cases for Connections through Firewalls ............................................................... 204
Remote/External Client ................................................................................................. 205
Remote Windows Workplace............................................................................. 206
Remote Usage of a Node on the System Network............................................. 207
Information Manager Desktop Tools ................................................................. 207
Secure Connections for Remote Clients ............................................................ 208
Remote Clients Connecting through a Demilitarized Zone............................... 208
Site to Site Connections via a Firewall ......................................................................... 209
Integration with 3rd Party Systems ............................................................................... 210
Accessing OPC Data from External Network ................................................... 210
Asset Optimization Integrations ........................................................................ 212
Batch Integrations .............................................................................................. 213

10 3BSE034463R5001
 Table of Contents

Management of System Updates ...................................................................................213

Other Services to be Used Through a Firewall .............................................................214
Summary of Ports to Open in Firewalls ........................................................................215

Appendix A - Reference Details

IP Addresses ..................................................................................................................217
How to Choose IP Addresses ........................................................................................218
Choosing Address Space....................................................................................218
Using Implicit or Explicit RNRP Configuration................................................219
Suggested Configuration of RNRP and IP Addresses .......................................221
IP Addresses for Redundant Controller Nodes ..................................................221
Configuring IP Addresses with DHCP ..............................................................222

INDEX ........................................................................................................................223

3BSE034463R5001 11
Table of Contents

12 3BSE034463R5001
 About This Book

General
This instruction describes how to configure the IndustrialIT 800xA Automation
System Network, including the Client Server Network, the Control Network, and
how to connect to a Plant Network. It generally does not cover fieldbuses.
The section about Network equipment however applies to Ethernet communication
in general, which means that it also applies to Fieldbuses using Ethernet.
For the 800xA Automation System network the following main topics are covered:
• System Network topologies
• Network Redundancy
• Domain and DNS configuration
• Clock Synchronization
• Network installation and maintenance
• Network Security
Section 1, Introduction introduces the topics and the following sections describe
them in more details.
For configuration of users, user groups, security settings, and group policies,
please refer to IndustrialIT 800xA, System, Administration and Security
(3BSE037410Rxxxx).
This instruction does not describe configuration of general purpose networks, such
as an office or plant network, neither does it cover the situation where IndustrialIT
800xA products are connected to a general purpose network.

3BSE034463R5001 13
Document Conventions About This Book

Document Conventions
Microsoft Windows conventions are normally used for the standard presentation of
material when entering text, key sequences, prompts, messages, menu items, screen
elements, etc.

Warning, Caution, Information, and Tip Icons

This publication includes Warning, Caution, and Information where appropriate
to point out safety related or other important information. It also includes Tip to
point out useful hints to the reader. The corresponding symbols should be
interpreted as follows:

Electrical warning icon indicates the presence of a hazard which could result in
electrical shock.

Warning icon indicates the presence of a hazard which could result in personal
injury.

Caution icon indicates important information or warning related to the concept

discussed in the text. It might indicate the presence of a hazard which could
result in corruption of software or damage to equipment/property.

Information icon alerts the reader to pertinent facts and conditions.

Tip icon indicates advice on, for example, how to design your project or how to
use a certain function
Although Warning hazards are related to personal injury, and Caution hazards are
associated with equipment or property damage, it should be understood that
operation of damaged equipment could, under certain operational conditions, result
in degraded process performance leading to personal injury or death. Therefore,
fully comply with all Warning and Caution notices.

14 3BSE034463R5001
About This Book Terminology

Terminology
A complete and comprehensive list of Terms is included in the IndustrialIT
Extended Automation System 800xA, Engineering Concepts instruction
(3BDS100972Rxxxx). The listing included in Engineering Concepts includes terms
and definitions as they that apply to the 800xA system where the usage is different
from commonly accepted industry standard definitions and definitions given in
standard dictionaries such as Webster’s Dictionary of Computer Terms.

Term/Acronym Description
Client Client is a part of a software that subscribes data from a
server.
Client/Server Network A client/server network is used for communication
between servers, and between workplaces and servers.
CNCP Control Network Clock Protocol. A protocol for
synchronization of clocks in Controllers on the Control
Network.
Connectivity Server A server that provides access to controllers and other
sources for real-time data, historical data, and alarm and
event data. A Connectivity Server runs services related
to OPC/DA, OPC/AE, OPC/HDA.
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
Hop count A measure of distance in a network. The hop count is
equal to the number of routers that must passed to reach
a destination.
IP Internet Protocol. A layer 3 protocol in the OSI model.
IP address A 32-bit address assigned to each host/node connected
on the network.
IP address mask A 32-bit address mask used on an IP address to
separate network from host identifier.
IPsec Internet Protocol Security

3BSE034463R5001 15
Terminology About This Book

Term/Acronym Description
LAN Local Area Network
MMS Manufacturing Message Specification. ISO standard for
communication between controllers.
MPLS Multi Protocol Label Switching
Node A computer communicating on a network e.g. the
Internet, Plant, Control or I/O network. Each node
typically has a unique node address with a format
depending on the network it is connected to.
PC Computer running the Windows operating system
Private IP addresses Blocks of IP address space that are reserved by the
Internet Assigned Numbers Authority (IANA) for free use
in private networks.
RMON Remote Monitoring. A standard for performing traffic
analysis
RNRP Redundant Network Routing Protocol
Router A computer/device that forwards IP data grams among
the networks to which it is connected
Server A node that runs one or several Afw Services.
It is the part of the software that supply data to a
subscriber.
SNMP Simple Network Management Protocol
SNTP Simple Network Time Protocol
STP Shielded Twisted Pair cable
TCP Transmission Control Protocol. A layer 4 protocol in the
OSI model.
UTC Coordinated Universal Time
UTP Un-shielded Twisted Pair cable

16 3BSE034463R5001
About This Book Related Documentation

Term/Acronym Description
WAN Wide Area Network
VPN Virtual Private Network

Related Documentation
A complete list of all documents applicable to the 800xA IndustrialIT Extended
Automation System is provided in Released User Documents, 3BUA000263Rxxxx.
This document lists applicable Release Notes and User Instructions. It is provided in
PDF format and is included on the Release Notes/Documentation media provided
with your system. Released User Documents are updated with each release and a
new file is provided that contains all user documents applicable for that release with
their applicable document number. Whenever a reference to a specific instruction is
made, the instruction number is included in the reference.

3BSE034463R5001 17
Related Documentation About This Book

18 3BSE034463R5001
 Section 1 Introduction

This section introduces the main areas covered by this document:

• Network Topologies, on page 20
• Network Redundancy, on page 26
• Selection of IP addresses, on page 27
• Domain Controllers, on page 33
• DNS configuration, on page 34
The later sections will describe the different topics in detail.

3BSE034463R5001 19
Network Topologies Section 1 Introduction

Network Topologies
System communication in the IndustrialIT System is based on Ethernet and TCP/IP
networks, which are functionally and, in most cases, also physically built in levels.
The following figure shows the different levels in the network. Later sections will
describe more about why the system should be separated into different network
areas on different levels.

Internet

Thin Clients
Firewall

Plant Network
Workplaces
Isolation Device (clients)

Client/Server
Network

Servers

Control network

Controllers

Fieldbus
Field devices

Figure 1. Network Topology: Plant-, Client/Server- and Control Network

20 3BSE034463R5001
Section 1 Introduction Plant Network

Plant Network
The Plant Network can be dedicated for process automation purposes or be a part of
the plant intranet already available on a site.

Client/Server Network
The Client/Server network is used for communication between servers, and between
client Workplaces and servers.
The Client/Server Network is a trusted network zone that should be protected by
firewalls. It is a private IP network that uses static addresses, see the
recommendations on page 27.
The Client/Server Network can optionally be made redundant.

Due to security and performance reasons only IndustrialIT Certified products

should be connected on the Client/Server Network.

Control Network
The Control Network is a local area network (LAN) optimized for high performance
and reliable communication, with predictable response times in real time.
Controllers and Connectivity Servers are connected to the control network.
The Control Network is based on Ethernet using the MMS protocol on top of a
TCP/IP protocol stack, plus additional services for time distribution, redundancy
features, etc. The control network can optionally be made redundant using the
RNRP redundancy protocol. Controllers connect to the control network via dual
built-in network ports. Server and client PCs need additional network cards to adapt
to redundant networks.
The Control Network should be kept as isolated as possible from all traffic that
does not belong to controller products. Other traffic may jeopardize
performance.
Only Industrial IT Certified products should be connected on the Control
Network.
It is recommended that separate networks be built for Ethernet based fieldbuses for
example FOUNDATION Fieldbuses HSE or TCP/IP based communication with the
INSUM System.

3BSE034463R5001 21
Network Areas Section 1 Introduction

Network Areas
The terms Client/Server Network and Control Network are used to describe the
system functions performed by these networks. From an IP routing point of view the
concept of Network Areas is used. A Network Area is a logically flat network that
does not contain IP routers. In Figure 1, the Client/Server Network and the Control
Network are different Network Areas with the Connectivity Servers potentially
being used as IP routers. A Network Area may be redundant or non-redundant. A
non-redundant Network Area maps to one IP subnet. A redundant Network Area
maps to two IP subnets.

Combined Client/Server and Control Network

In systems with less than 50 nodes the Control Network and the Client/Server
Network may run on the same physical network.

Network Area 1

Figure 2. Combined Control Network and Client/Server Network

22 3BSE034463R5001
Section 1 Introduction Client/Server Network and Control Network on Separate Network Areas

Client/Server Network and Control Network on Separate Network Areas

For large systems it is recommended that the Control Network and Client/Server
Network be separated into different Network Areas. The connection between the
Network Areas is provided by Connectivity Servers using the RNRP routing
protocol (Section 3, RNRP and Network Configurations). The two networks may be
separated also for smaller systems. There are several reasons to separate the Control
Network from the Client/Server Network:
• Fault isolation. An erroneous network segment on Client/Server Network will
not affect nodes on the Control Network.
• Limitation of broadcast traffic. Broadcasts on Client/Server Network will not
disturb the real-time traffic on the Control Network
• Traffic filtering. Undesired traffic can be blocked by a Connectivity Server
node.
• Multicast traffic used by RNRP for network supervision is reduced on the
Control Network.

Network Area 1
Client/Server
Network

Connectivity
Servers

Network Area 20
Control Network

Figure 3. Separated Client Server Network and Control Network

3BSE034463R5001 23
Large Configuration with Control Network on Two Network Areas Section 1 Introduction

Large Configuration with Control Network on Two Network Areas

If the total number of nodes on the Control Network exceeds 50 it is recommended
to split the Control Network on two or more Network Areas.

Network Area 1
Client/Server
Network

Network Area 20 Network Area 21

Control Networks

Fieldbus

Figure 4. Separated Client Server Network and Multiple Control Networks

For best performance the controller to controller communication should be kept

within one Network Area.
If required by the physical topology, controllers on different Network Areas can
communicate through the Client/Server Network, area 1 in the example above.
The Connectivity Servers will act as routers, see Connectivity Servers as Routers on
page 47.
Other possible alternatives are to use MB 300 via CI855 or Foundation Fieldbus
HSE via CI860. These are described in the manual IndustrialIT 800xA,
Control and I/O, Communication, Protocols and Design (3BSE035982Rxxxx).

24 3BSE034463R5001
Section 1 Introduction Controller Communication via PPP

Controller Communication via PPP

The Control Network can be extended via PPP (Point to Point Protocol) links.

Control Network,
Network Area X

PPP link

Network Area Y PPP links Network Area Z

Figure 5. PPP Links for extending the Control Network or Direct

Communication between PC and Controller

Each PPP link is a non-redundant Network Area. It is also possible to use a PPP link
between a PC and a Controller.
PPP is more described in the manual IndustrialIT 800xA, Control and I/O,
Communication, Protocols and Design (3BSE035982Rxxxx) and in the On-line
Help for the Control Builder.

3BSE034463R5001 25
Introduction of Network Redundancy Section 1 Introduction

Introduction of Network Redundancy

Industrial applications require high availability. The effects of a network error must
be reduced to a minimum. Single points of failure should, if possible, be avoided.
For high availability, all network devices (cables, switches, routers and network
adapters) should be duplicated in physically separated network paths. The two
network paths are named Primary Network and Secondary Network or Back-up
Network.

Primary Network

Secondary Network

Figure 6. Physical View of a full Redundant Network with Duplication of

Switches, Cabling and Network Adapters

As long as the primary network paths are working, all process data is sent on that
network. The secondary network normally carries no user traffic. This guarantees
that network performance is not affected after a network fail over.
Both supervision of network paths and fail-over between Primary and Secondary
networks are performed by RNRP.

26 3BSE034463R5001
Section 1 Introduction Selection of IP Addresses

In order to have a robust redundant system, it is very important to have continuous

supervision of all network paths on a node-to-node basis, not only on individual
network devices. A detected network error results in fault annunciation.
For more information about redundancy, RNRP and network configurations,
please read Section 3, RNRP and Network Configurations.

Selection of IP Addresses
When planning a system the user must decide what IP addresses to use for all nodes
in the system.
It is recommended that addresses be selected from a private address space.
This has the following advantages:
• There is no requirement to apply to the licensing authorities for an IP address,
i.e. it is easy to allocate a large IP address space especially in redundant
network configurations.
• Some protection is gained against illegal access because private addresses are
not permitted on the public Internet.
It is strongly recommended that addresses shown in the next chapter are used.
This greatly simplifies the network configuration and reduces the probability for
configuration errors.
If it is not possible to use the recommended IP addresses, then read about RNRP
addresses in RNRP Address Configuration: Implicit or Explicit on page 52 and in
Appendix A How to Choose IP Addresses on page 218.

3BSE034463R5001 27
Recommended IP Address Plan Section 1 Introduction

Recommended IP Address Plan

The tables below gives a recommendation on IP addresses that will work for most
installations. If this suggestion is followed, the reader can disregard much of the
details about RNRP configuration.
Table 1 suggests which NetIDs1 to use.

Table 1. Suggested NetIDs and Network Area Numbers

Network type NetIDs Network Areas

Plant Network 172.16.0 0
172.17.0
Client/Server Networks 172.16.4 - 172.16.40 1-10
172.17.4 - 172.17.40
Control Networks 172.16.80 - 172.16.124 20-31
172.17.80 - 172.17.124

Use the IP address mask 255.255.252.0 on all addresses.

Do not connect more than 50 nodes on a Control Network Area.

See also Recommended IP Address Plan for Non-RNRP Networks on page 32.

1. NetID is the left most part of the IP address. See Appendix A, Reference Details

28 3BSE034463R5001
Section 1 Introduction Recommended IP Address Plan

Addresses recommended on the Client/Server/Control Network Area 1

Table 2. Suggested Addresses for Nodes on Network Area (1)

Node Addr on Primary Addr on Secondary

Nodes
number Network Network
Domain and DNS 1-10 172.16.4. 1 - 172.17.4. 1-
servers 172.16.4.10 172.17.4.10
Aspect servers 11-20 172.16.4.11 - 172.17.4.11-
172.16.4.20 172.17.4.20
Connectivity servers 21-50 172.16.4.21 - 172.17.4.21 -
172.16.4.50 172.17.4.50
Application Servers 51-70 172.16.4.51- 172.17.4.51 -
Information Manager, 172.16.4.70 172.17.4.70
Batch,3rd Party Nodes
Workplace Clients 71- 150 172.16.4.71 - 172.17.4.71 -
172.16.4.150 172.17.4.150
Controllers 151-220/255 172.16.4.151 - 172.17.4.151 -
172.16.4.220/255 172.17.4.220/255
Panel 800 (if used) 221-255 172.16.4.221 - (not used)
(non redundant) 172.16.4.255
Backup CPUs for 663-767 172.16.6.151 - 172.17.6.151 -
Redundant Controllers 172.16.6.255 172.17.6.255
Switches, Gateways, (501-511) 172.16.5.245- 172.17.5.245 -
Firewalls 172.16.5.255 172.17.5.255
(not RNRP addresses) (1013-1022) 172.16.7.245- 172.17.7.245 -
172.16.7.254 172.17.7.254
Spare, Unused RNRP 256-500 172.16.5.0- 172.17.5.0-
addresses 172.16.5.244 172.17.5.244
Spare (512-662) 172.16.6.0- 172.17.6.0-
(not RNRP addresses) 172.16.6.150 172.17.6.150
(768-1012) 172.16.7.0- 172.17.7.0-
172.16.7.244 172.17.7.244

3BSE034463R5001 29
Recommended IP Address Plan Section 1 Introduction

The following addresses are recommended on the Control Network Area 20.

Table 3. Suggested Addresses for nodes on Network Area (20)

Node Addr on Primary Addr on Secondary

Nodes
number Network Network
Connectivity servers 21-50 172.16.80.21 - 172.17.80.21 -
172.16.80.50 172.17.80.50
Controllers 151-220/255 172.16.80.151 - 172.17.80.151 -
172.16.80.220/255 172.17.80.220/255
Panel 800 (if used) 221-255 172.16.80.221 - (not used)
(non redundant) 172.16.80.255
Backup CPUs for 663-767 172.16.82.151 - 172.17.82.151 -
Redundant Controllers 172.16.82.255 172.17.82.255
Switches, Gateways, (501-511) 172.16.81.245- 172.17.81.245 -
Firewalls 172.16.81.255 172.17.81.255
(not RNRP addresses) (1013-1022) 172.16.83.245- 172.17.83.245 -
172.16.83.254 172.17.83.254
Spare, Unused RNRP 256-500 172.16.81.0- 172.17.81.0-
addresses 172.16.81.244 172.17.81.244
Spare (512-662) 172.16.82.0- 172.17.82.0-
(not RNRP addresses) 172.16.82.150 172.17.82.150
(768-1012) 172.16.83.0- 172.17.83.0-
172.16.83.244 172.17.83.244

For controllers running SattBus on TCP/IP the HostID must be 2-127.

This means that the user needs to decide on a different node number allocation
than Table 3. SattBus is described in the OnLine help for the Control Builder.
For the node status alarms to work properly Connectivity Servers, and possibly
other nodes, that connect to both the Client/Server Network and the Control
Network must use the same node number on both (all) Network Areas they are
connected to.

30 3BSE034463R5001
Section 1 Introduction Recommended IP Address Plan

The above tables but generic for any Network Area with the area number as
parameter ‘a’ is shown below (a = [0..31]).

Table 4. Suggested Addresses for nodes on a Network Area (a)

Node Addr on Primary Addr on Secondary

Nodes
number Network Network
Domain and DNS 1-10 172.16.4*a. 1 - 172.17.4*a. 1-
servers 172.16.4*a.10 172.17.4*a.10
Aspect servers 11-20 172.16.4*a.11 - 172.17.4*a.11-
172.16.4*a.20 172.17.4*a.20
Connectivity servers 21-50 172.16.4*a.21 - 172.17.4*a.21 -
172.16.4*a.50 172.17.4*a.50
Application Servers 51-70 172.16.4*a.51- 172.17.4*a.51 -
Information Manager, 172.16.4*a.70 172.17.4*a.70
Batch,3rd Party Nodes
Workplace Clients 71- 150 172.16.4*a.71 - 172.17.4*a.71 -
172.16.4*a.150 172.17.4*a.150
Controllers 151-220/255 172.16.4*a.151 - 172.17.4*a.151 -
172.16.4*a.220/255 172.17.4*a.220/255
Panel 800 (if used) 221-255 172.16.4*a.221 - (not used)
(non redundant) 172.16.4*a.255
Backup CPUs for 663-767 172.16.4*a+2.151 - 172.17.4*a+2.151 -
Redundant Controllers 172.16.4*a+2.255 172.17.4*a+2.255
Switches, Gateways, (501-511) 172.16.4*a+1.245- 172.17.4*a+1.245 -
Firewalls 172.16.4*a+1.255 172.17.4*a+1.255
(not RNRP addresses) 172.16.4*a+3.245- 172.17.4*a+3.245 -
(1013-1022)
172.16.4*a+3.254 172.17.4*a+3.254

Spare, Unused RNRP 256-500 172.16.4*a+1.0- 172.17.4*a+1.0-

addresses 172.16.4*a+1.244 172.17.4*a+1.244

Spare (512-662) 172.16.4*a+2.0- 172.17.4*a+2.0-

(not RNRP addresses) 172.16.4*a+2.150 172.17.4*a+2.150
172.16.4*a 3.0- 172.17.4*a+3.0-
(768-1012)
172.16.4*a+3.244 172.17.4*a+3.244

3BSE034463R5001 31
Recommended IP Address Plan for Non-RNRP Networks Section 1 Introduction

Recommended IP Address Plan for Non-RNRP Networks

Table 5 gives a recommendation on IP addresses for networks that do not run
RNRP.

Table 5. Suggested NetIDs and Subnet Masks for Networks that do not run RNRP

Network Type NetIDs Subnet Mask

HSE Subnets 192.168.1 - 192.168.40 255.255.255.0
(FOUNDATION Fieldbus)
Insum 192.168.41 - 192.168.60 255.255.255.0
Other IP based networks 192.168.61 - ... 255.255.255.0

Do not use NetIDs that correspond to the RNRP Base Address for Non-RNRP
networks, i.e. with the default base address = 172.16; do not use the NetID
172.16.x for Non-RNRP networks. Otherwise an RNRP network area will be
implicitly defined and all nodes will get information about it for no use.
Table 6 gives a recommendation for usage of node numbers on the HSE Subnet.

Table 6. Suggested Node Numbers on an HSE Subnet

Nodes Node Number

Spare 1 - 10
Only to be used temporarily during commissioning 11 - 20
(factory defaults of un-commissioned devices will
preferably use these node numbers)
Connectivity servers (running OPC Server FF) 21 - 50
Linking devices 51 - 150
Communication interfaces 151 - 254

Let the Connectivity Servers that connect to both the Client/Server Network and the
HSE Subnet use the same node number on both Network Areas

32 3BSE034463R5001
Section 1 Introduction Introduction of Domain Controllers

Introduction of Domain Controllers

A domain is a group of nodes that are part of a network and share a common
directory database.
A domain defines a scope or unit of policy. A Group Policy object establishes how
domain resources can be accessed, configured, and used. These policies are applied
only within the domain and not across domains. Applying a Group Policy object to
the domain consolidates resource and security management.
A domain controller contains matching copies of the user accounts in a given
domain. It is used to store and manage information about user credentials and access
rights, both for humans and for the system. The domain controller provides the
Active Directory service that manages user access to a network, which includes user
logon, authentication, and access to the directory and shared resources.
Every domain must have at least one domain controller. In a Windows 2000/2003
domain, this must be on a node running the Windows 2000 Server or Windows 2003
Server operating system. To improve the availability of the system a domain may
have multiple domain controllers to support the handling of logon requests and
directory updates.
In Windows 2000 and Windows 2003 the Domains are stored in Active Directory.
Administration of Domain Controllers to great extent means administration of
Active Directory. It is possible to use Windows 2000 Server and Windows 2003
Server on domain controllers in the same domain. Operating System for Domain
Controllers on page 75 describes more about this topic.
Single node systems, i.e. systems with only one PC, and small systems that use
Windows Workgroups do not need Domain Controllers.

3BSE034463R5001 33
Introduction of DNS Section 1 Introduction

Introduction of DNS
DNS is a hierarchical name service for domains and IP addresses. The DNS service
enables client nodes on your network to register and resolve DNS domain names.
All Industrial IT applications that identify other nodes by name, i.e. not only by IP
Address, use DNS to find the corresponding IP address.
The names and IP Addresses are stored in a DNS database. A DNS Server is a
server containing information about a portion of the DNS database. The DNS server
handles queries from DNS resolvers in the clients.
There are two types of DNS queries:
• I know the name of a node. What is its IP address?
This is called Forward Lookup.
• I know the IP Address of a node. What is its name?
This is called Reverse Lookup.
To serve these queries the information in a DNS database is organized in Forward
Lookup Zones and Reverse Lookup Zones.
The client resolvers typically cache DNS information so that they do not need to
send all the queries to the DNS server.
Normally the primary Domain Name System (DNS) server is also run on the same
node as the Domain controller. With multiple domain controllers in a system the
DNS server functions are also distributed. This also improves the availability of the
DNS system.
Configuring the DNS functions in a system requires:
• Configuring the DNS server on the Domain Controller (s).
• Configuring names and IP addresses, for nodes that will be possible to identify
by name (see below), in the DNS database.
• Configuring knowledge of the domain and the DNS server(s) in each node that
uses DNS.
Further information about DNS can be found in the On-line help for DNS in
Windows Server, the help file dnsconcepts.chm and in the resource kits in
MSDN.
Section 4, Domain and DNS Configuration describes how to configure DNS.

34 3BSE034463R5001
 Section 2 Distributed System Topologies

This section describes examples of how to build 800xA systems where different
parts of the system are located more or less far away from each other.
The standard system, where all nodes are located at more or less the same place,
is described in Figure 7 below..

Figure 7. Standard System Topologies

For the discussion in this section there is no principle difference between the left
system with combined client server and control network and the right system with
separated networks.
The following sections describe different system configurations using remote
connections.
The focus here is where to place different node types. Section 8, Network Security
describes how to make sure that the remote connections are secure.

3BSE034463R5001 35
Extend the 800xA Automation System Network Section 2 Distributed System Topologies

Extend the 800xA Automation System Network

A straight forward approach to building a system where some of the nodes are
located far away is to simply extend the Automation System Network.
As long as the network equipment supports building an ethernet network with the
same performance as on a local network there is nothing special to consider for an
extended system network. The paragraph Ethernet Speed on page 177 describes
performance considerations for the Automation system network.
If a controller is located far away, extend the Control Network to reach this place,
see Figure 8 below.

Figure 8. Remote Controllers on an extended Control Network

If a client or a server is located far away, extend the Client Server Network to reach
to that place, see Figure 9.

Figure 9. Remote Client on an extended Client Server Network

36 3BSE034463R5001
Section 2 Distributed System Topologies Extend the 800xA Automation System Network

The traffic on the client server network normally is heavier than the traffic on the
Control Network. This means that if all controllers are located far away, it is still
recommended to locate the connectivity servers centrally and to extend the Control
Network over the remote connection. See Figure 10and Figure 11.

Figure 10. Locate Connectivity Servers centrally, extend the Control Network

Figure 11. Avoid locating the Connectivity Servers together with the Controllers

If it is desired to have both client workplace functionality and controllers at a remote

location the recommended solution is to place both connectivity servers and clients
at the remote location1, see Figure 12.
It is not recommended to place only the controllers and the clients there as in
Figure 13. The reason is that this would mean that the remote connection needs to
be used for both the Control Network and Client Server Network since the
Workplace Clients do not communicate directly with the controllers. All OPC
communication goes via the Connectivity Servers.
1. If the performance allows it the workplace may be run on the Connectivity Servers. Otherwise the workplaces
should be run in separate client nodes.

3BSE034463R5001 37
Extend the 800xA Automation System Network Section 2 Distributed System Topologies

Figure 12. Remote combined Clients and Connectivity Servers

Figure 13. Do not connect Clients to the Control Network

If both the Client Server Network and the Control Network need to be extended the
straight forward solution would be to build two remote connections (4 in case of
redundancy). If the remote connection has sufficient bandwidth it is possible to run
both networks on the same link. To separate the networks VLANs can be used as
shown in figure Figure 14. Section Reducing HW using Virtual LANs on page 179
describes more about how to do this.

38 3BSE034463R5001
Section 2 Distributed System Topologies Equal System Sections on Different Locations

Figure 14. Clients close to the Controllers, extended Client/Server Network

Equal System Sections on Different Locations

For some distributed systems the topology may not be described as one central
location with most of the system and one or more remote locations, but rather as two
or more locations that all are similar to each other with perhaps all node types on all
places.
Also in such case it may be considered to build one distributed 800xA system with
an extended Automation system Network. Which parts of the automation system
network to extend depends on which type of data needs to be exchanged between
the nodes on different locations.
If the controllers do not communicate time critical data directly between the two
locations it is recommended to use separate Control Networks, one on each location,
and to extend the Client Server network between the locations, see Figure 15.
If controllers communicate much with each other between the two locations the
control network may need to be extended, see Figure 16.

3BSE034463R5001 39
Security Considerations Section 2 Distributed System Topologies

Figure 15. One 800xA System with two connected equal parts

Figure 16. One 800xA System, Both Networks extended

For a distributed 800xA system to work with full functionality the remote
connection needs to be reliable. If it is broken some functions may be lost.
For example: In a system with 2oo3 redundancy for the Aspect Servers with two
Aspect Servers on one side of the connection and one on the other, the side with
only one Aspect Server can not be engineered if the remote connection is broken.

Security Considerations
If a part of the system network is extended via a remote connection the whole
connection and both sides of it need to be treated the same way regarding network
security, e.g. having the same security level. The protocols used between the nodes
on the control network and on the client server network are not designed to be used
through a firewall. Section 8, Network Security describes different alternatives for
how to extend the Automation System Network through firewalls.

40 3BSE034463R5001
 Section 3 RNRP and Network Configurations

This section describes the Network Redundancy based on the Redundant Network
Routing Protocol (RNRP). The main areas covered are:
• the concepts of the RNRP protocol
• how to build different network structures
• how to choose addresses
• how to configure nodes; PCs and Controllers

Redundant Network Routing Protocol (RNRP)

RNRP is a IPv4 routing protocol developed by ABB. It is specially designed for use
in automation networks with limited topology but with high demands on network
availability. RNRP provides the following features:
• Network redundancy
The protocol supports redundant physical networks, full redundancy including
network interface boards, between end nodes. Routing messages are
periodically multicasted on all networks. If a network error occurs, RNRP
updates the system IP Routing Table with a good network path within the time
of the RNRP send period. The send period is as default 1 second.
• Routing between network areas
IP routes to all neighbor nodes and subnetworks are automatically maintained
in the IP Routing Table in every node. A node with RNRP can act as a IP router
and forward messages on best path to destination nodes.
• Node and network supervision
RNRP quickly detects if a node or remote network is down and sends this
information to applications that subscribe to RNRP status. This information is
used to detect if a redundant server is down and whether a new server can be
connected.

3BSE034463R5001 41
Redundant Network Routing Protocol (RNRP) Section 3 RNRP and Network Configurations

The RNRP redundancy concept works with standard network devices (hubs,
switches or bridges) and no special functionality is required from the network
interface cards (NICs).
The protocol gives high flexibility to integrate networks with different types of data
links like PPP and Ethernet. The routing update period can be configured to fit on
very slow serial links as well as on high speed networks mixed in the same Control
Network.
IP routing works for Unicast communication (node to node), not for Multicast or
Broadcast. This means that RNRP does NOT provide redundancy or routing for
Multicast or Broadcast communication.
Applications that use Multicast or Broadcast must take care of the network
redundancy themselves, if desired communication between different network
areas.
All RNRP versions used in previous system versions of the 800xA System are
compatible with each other.

42 3BSE034463R5001
Section 3 RNRP and Network Configurations Network Areas

Network Areas
A network that uses RNRP is built up by one or more Network Areas.
A Network Area is a logically flat network structure without routers.
Routers are not allowed within a Network Area.
A Network Area with redundancy contains two independent IP networks with equal
capacity. The individual networks within a Network Area are assigned
Path Numbers.
The primary network has Path Number = 0 and the secondary network has
Path Number = 1.

Primary Network
Path Number = 0 Node Numbers
11 21

Secondary Network
151 152 153
Path Number = 1

Figure 17. A Network Consisting of one Network Area

A node is identified in RNRP by:

• Network area number (0 - 31)
• Node number (1 - 500)

3BSE034463R5001 43
Fault Handling within a Network Area Section 3 RNRP and Network Configurations

The path number is a parameter on each network interface (see RNRP Address
Configuration: Implicit or Explicit on page 52).
Each path on a Network Area corresponds to one IP subnet. The NetID is the
same for all interfaces on the same Path. (see IP Addresses on page 217)
Applications communicating with nodes that run RNRP shall always address the
nodes on the primary network (path 0).
In case of error on the primary network, the Redundant Network Routing Protocol
(RNRP) redirects traffic over to the secondary network (the backup network)
without involving any application program.
Nodes with redundant interfaces and nodes with a single interface can be mixed on
the same Network Area. A node with only one interface must only be connected to
the primary network.

Fault Handling within a Network Area

Within a Network Area RNRP can handle single network errors in all node-to-node
connections. In the example below, node A has an error on the connection to the
primary network and node B an error on the connection to the secondary network.

A B

Network
X X Errors

C D E

Figure 18. A Fault handling in one Network Area

44 3BSE034463R5001
Section 3 RNRP and Network Configurations Fault Handling within a Network Area

In this example communication between node A and node B is not possible but all
other peer communication will work.
Node A can communicate over secondary network with nodes C, D and E.
Node B can communicate over primary network with nodes C, D and E.
Nodes C, D and E are fully redundant to each other.

Network Fail Over Time

The time required for RNRP to redirect traffic from a faulty path to a good path is
the same as the configured RNRP parameter Send Period, see Table 7 on page 57.

Data Recover Time

The application data recover time is not the same as the network fail over time.
A TCP application is not recovered until TCP has retransmitted lost data.
TCP continuously adjusts its retransmit time after transmission delays and repeated
network errors. Standard TCP has a minimum value for retransmission of one
second. This means that even if network fail over occur instantly, application data is
not recovered until one second has elapsed. The default value of the RNRP
parameter Send Period has been set up to reflect this limitation.

Node Down Notification

A single lost message does not cause a Node down event. The time until a Node
down event is generated is configured by the parameter MaxLostMessages
(see Table 7 on page 57).
Time until node down event = (MaxLostMessages + 1) * SourceSendPeriod.

3BSE034463R5001 45
Multiple Network Areas and RNRP Routers Section 3 RNRP and Network Configurations

Multiple Network Areas and RNRP Routers

There are a number of reasons why a network should be divided into Network Areas
(subnetworks):
• Fault isolation. An erroneous network segment (bad cable, Ethernet switch or
interface card) can not affect nodes on an other Network Areas.
• Traffic filtering. Undesired traffic can be blocked by a router if filter software
is installed. This is true for a Windows Server node.
• Limitation of broadcast traffic. A router does normally not forward broadcast
and multicast messages.
• The network is distributed over large distances using link protocols with
different network characteristics. PPP is one example.
• The IP routing resources (Routing table, ARP table or CPU power et.c.) in a
single node are not large enough to handle a large number of nodes on the same
Network Area.
For best performance the network designer should try to keep the time-critical
traffic within the same Network Area. The time to change router node is always
greater than the time to change path within the Network Area.
The Network Areas are interconnected by RNRP routers. A node with RNRP and
connections to more than one network area can act as an RNRP router. In a PC
additionally the flag “Enable TCP/IP forwarding” has to be set to 1 (see Table 7 on
page page 57).
A message between two nodes can be forwarded via several network areas. The
number of routers it goes through is described by the term “hop count”. The
recommended network topology should not contain hop counts higher than five (5).
The reason for this is that a large hop count increases the probability for undesired
behavior such as loops and slow response time due to delayed updates from distant
routers.

46 3BSE034463R5001
Section 3 RNRP and Network Configurations Multiple Network Areas and RNRP Routers

Connectivity Servers as Routers

In systems where the Control Network and the Client Server network are separated,
the network is build up by different network areas. The connectivity servers that are
connected to both networks, as in Figure 19, will work as RNRP routers provided
that IP forwarding is enabled (see above). This makes it possible for all nodes on the
Client Server network to communicate with all the Controllers on the Control
Network. This is used by the Control Builder in an Engineering Client when it
communicates with the Controllers. The routing through the Connectivity Servers is
also needed for the network alarm handling to work properly, see Node Status
Alarms on page 160.
The function “Show Remote Systems” in the Control Builder and the OPC server
uses broadcasting and does therefore not work through routers. The IP addresses
of the controllers have to be known and entered manually when the networks are
separated.

Network Area 1

Connectivity
Servers as
RNRP
Network Area 20 Network Area 21
Routers

Figure 19. Network with Three Network Areas and Connectivity Servers as Routers

3BSE034463R5001 47
Multiple Network Areas and RNRP Routers Section 3 RNRP and Network Configurations

Controllers as Routers
The AC 800M controller can be used as router between non-redundant networks.
There is no parameter to enable the routing capability. It is always enabled when
RNRP is used and the controller is connected to two different network areas.
It is not possible to use two AC 800M Controllers to achieve a redundant
connection between two redundant networks. For this 4 network interfaces per
router is needed. This is described below.

Redundant Connectivity Servers/Routers

A Connectivity Server (router node) can be a single point of failure. The RNRP
protocol allows redundant router nodes between Network Areas. In the
configuration below RNRP selects the router with lowest node number as the active
router node. If this node fails the RNRP protocol selects the other router as active.

Network Area 1

Connectivity
Node 21 Servers as
Primary router Node 22
redundant
RNRP Routers
Network Area 20

Figure 20. Two Network Areas with Redundant Connectivity Servers as Routers

48 3BSE034463R5001
Section 3 RNRP and Network Configurations Multiple Network Areas and RNRP Routers

In cases where multiple routes exist to a remote Network Area, the router that has
the highest number of reachable nodes is selected as primary. If all routers have
an equal number of reachable nodes then the router with the shortest distance
(hop count) is selected as primary. If routers have equal distance then the
intermediate network with lowest Network Area number is selected as the
primary.
The network engineer should recognize that if serial links area used within the
Control Network, throughput will be very low as compared to Ethernet alone.
In mixed configurations, it is recommended to put low Network Area numbers on
the high capacity networks and high numbers on slow networks.
A good rule to follow during network configuration is to make sure that all
alternative routes to destination nodes have equal distance (hop count).
A network error should not cause redirection to a route with a greater distance.
By following this rule, a network error will not change the node-to-node response
time and no node will receive unpredictable loads from transit traffic.
An RNRP router has several advantages compared to a standard IP router:
• No manual routing configuration is needed.
The routing information about all nodes and networks is spread
automatically.
• The routers can be redundant.
It is not possible to avoid a single point of failure when connecting two
redundant RNRP network areas with a pair of standard IP routers.
To do this two RNRP routers with 4 network ports each are needed, see
Figure 20 on page 48 and Figure 21 on page 50.
Such a router can only be built using a PC with 4 network interfaces.
It is not possible to achieve the same functionality with two routers with two
ports each.

Default Gateway Routing for Nodes without RNRP

If nodes that do not support RNRP are connected to the control network, e.g.
managed switches or time servers, and these nodes need to be accessed via the
RNRP routers the necessary routing information can not build up by RNRP. One
way to solve this is to enter the primary Control Network address of the primary
connectivity server as “Default Gateway” to inform these nodes about how to reach
the Client Server network.

3BSE034463R5001 49
Multiple Network Areas and RNRP Routers Section 3 RNRP and Network Configurations

Routing between Control Networks

Controllers on Control Network areas can communicate with each other if the
Connectivity servers work as routers as in Figure 19 on page 47. If it is desired that
controller-to-controller communication is independent from the operation of the
Connectivity servers and/or from the Client Server network it is possible to build a
network where control networks are directly connected via dedicated routers.
Figure 21 shows two control network areas that are connected via a redundant pair
of dedicated routers.

Connections to the Client Server Network.

Not used for Controller-to-Controller
Communication

Redundant RNRP routers.

Dedicated for
Controller-to-Controller
Network Area 20 communication Network Area 21

Figure 21. Redundant RNRP routers for Controller-to-Controller communication

Special Routing Consideration

A message can only be received on the Network Area on which the message’s
destination address belongs. Even if the message destination node is connected to
multiple Network Areas and an alternative route exists through one of these other
Network Areas, the protocol will not reroute to reach the destination node if the first
Network Area breaks down.
Figure 22 on page 51 shows an example with an application in node 71 that has a
session to target node 22 in Network Area 1. If node 22 loses both paths (double

50 3BSE034463R5001
Section 3 RNRP and Network Configurations Local Network Areas

fault) on Network Area 1, then the application will lose the current connection even
if it in theory it is possible to route via Node 21 to Node 22 on Area 20.

Application
connected to node 22
in Network Area 1

Node 71
Network Area 1

Both paths to

X
Network Area 1
are broken

Node 21 Node 22

Network Area 20

Figure 22. A Network Connection is lost if all Paths to a Node in the Destination
Network Area are Down

Local Network Areas

The RNRP protocol permits Network Areas to be declared as “Local”. A Local
Network Area does not distribute information about own networks and nodes to
adjacent Network Areas. Traffic from other Network Areas can not be routed over
this local Network Area. Only nodes directly connected to a Local Network Area
can use it. In this way, nodes within the Control Network can use dedicated
networks without risking being over loaded by transit traffic.

3BSE034463R5001 51
RNRP Address Configuration: Implicit or Explicit Section 3 RNRP and Network Configurations

RNRP Address Configuration: Implicit or Explicit

It is strongly recommended that the addresses presented in, Recommended IP
Address Plan on page 28, are used. If they are used, no extra RNRP configuration
is required and the following chapters about addressing may be ignored.
A node on a TCP/IP network is identified by its 32 bit IP address. The IP address1
consists of a NetID part and a HostID part. The subnet mask specifies the boundary
between the NetID and the HostID.
A node with more than one network interface must have a unique IP address for
each interface.
Since RNRP is based on IP routing this is also true for all nodes running RNRP.
The interfaces in a node running RNRP are, in addition to the IP address and the
subnet mask, also configured with the following logical address parameters:
• Network Area 0 - 31
• Local Flag 0 = Normal Network Area
1 = Local Network Area, no routing to this area.
This area is not announced to other areas.
• Node Number 1 - 500
• Path Number 0-1
The only mandatory rules for these parameters are:
• The Node number must be the same as the HostID (the least significant, right
most bits in the IP address).
• For all nodes in one system the NetID (the most significant, left most bits in the
IP address) must uniquely correspond to one Path in one Network Area. This
means that:
– All interfaces (in all nodes) on the same path in one Network Area must
use the same NetID, i.e. be on the same subnet. This is as for all IP based
communication, else they cannot reach each other.
– For interfaces with different NetID either the Path or the Network Area
must differ.

1. IP addresses are described in more detail in the Appendix, section IP Addresses on page 217.

52 3BSE034463R5001
Section 3 RNRP and Network Configurations Using Explicit RNRP Configuration

To simplify the configuration of the network interfaces there is a set of additional

rules.
If these rules are also followed, the RNRP address parameters are automatically
configured. This is called the Implicit RNRP Configuration Method. See Address
Rules for Implicit RNRP Configuration on page 54.
If only the mandatory rules are followed, the RNRP address parameters have to be
configured manually for each network interface. This is called the Explicit RNRP
Configuration Method.
Some more details about how to select IP addresses can be found in
Appendix A How to Choose IP Addresses on page 218.

Using Explicit RNRP Configuration

Examples of how to apply the mandatory rules for explicit RNRP configuration:
If somebody decides that his/her system needs to use the subnet mask 255.255.0.0
the 3rd digit can not be arbitrarily chosen. For example the node address
10.11.12.13 can not be used because the HostID is 12*256+13=3085, HostID must
be the same as the node number and the node numbers can only be 1-500.
The allowed addresses with this subnet mask are x.y.0.1 - x.y.1.244. The address
x.y.1.200 is used on the node with node number 256+200=456.
If somebody decides that his/her system only is allowed to use two different subnets
this means that this only can be a system with two non-redundant network areas or a
system with one network area with network redundancy.
A system with two network areas with network redundancy uses 4 subnets, i.e. 4
NetIDs.
In a system with subnet mask 255.255.255.0 the two interfaces (in two different
nodes) with addresses 10.11.12.13 and 10.11.12.243 shall be connected to the same
network. They are on the same path on the same network area. 10.11.13.12 shall be
connected to a different network. It is either on a different path or on a different
network area. If the path or the network area or both differ depends on the settings
of the parameters for path and network area in the different nodes.

3BSE034463R5001 53
Address Rules for Implicit RNRP Configuration Section 3 RNRP and Network Configurations

Address Rules for Implicit RNRP Configuration

With the implicit RNRP configuration method all IP addresses have a strict
relationship to the RNRP address parameters. This relationship means that it is
sufficient to configure only the IP address. RNRP can calculate the other address
parameters from the IP address. This is done in each node. The easiest method is to
just use the addresses according to Table 2, Table 3 or Table 4 on page 29-page 31.
To manually decide the RNRP address parameters and use implicit RNRP
configuration the user needs to understand how RNRP extracts the parameters from
an IP address. The following steps can be followed:
1. Choose the RNRP address parameters
2. Choose the Base Address.
The base part of the IP addresses: N1.N2.0.0
(the 14 most significant bits with 2 additional zero bits)
This may be chosen freely from RNRP’s point of view, but they must be the
same in the whole system. Using the default 172.16 reduces the configuration
work.
3. Calculate the IP address based on the RNRP address parameters
4. Set subnet mask to 255.255.252.0
When using implicit configuration the address mask must be set to 255.255.252.0.
This gives 10 bits for the HostId, i.e. 1024 addresses. This allows the HostID to be
identical to the RNRP Node number that can be 1-500 for normal nodes and 513-
1013 for backup CPUs in Redundant Controllers (see Mixing Explicit and Implicit
RNRP Configuration on page 62).
Below there are two ways of describing how to calculate the IP address based on the
RNRP address parameters. They give the same result but one or the other may be
simpler to use in different situations.

54 3BSE034463R5001
Section 3 RNRP and Network Configurations Address Rules for Implicit RNRP Configuration

Calculating the IP Address Bit by Bit

With a binary representation the IP address must be created as:
XXXXXXXX.XXXXXXPP.LAAAAANN.NNNNNNNN
where the bits are:

XXXXXXXX.XXXXXX XXXXXXXX.XXXXXX00.00000000.00000000 is
equal to the Base Address
The 14 first bits is the Network Identity
PP Path Number
L Local Flag
AAAAA Network Area Number
NN.NNNNNNNN Node Number

Calculating the IP Address Byte by Byte

With a byte wise representation the IP address must be created as: A.B.C.D
where the bytes are:
A = N1
B = N2 + Path
C = Local*128 + Area*4 + Node DIV 256
D = Node MOD 256
N1.N2 is the Network Identity. Path, Local, Area and Node are the other RNRP
address parameters.
DIV means an integer division and MOD means the Modulo operation, i.e. the rest
after the integer division.

3BSE034463R5001 55
RNRP Configuration Parameters Section 3 RNRP and Network Configurations

If the Local flag is 0 and the node number is less than 256 the formula is a bit
simpler:
A = N1
B = N2 + Path
C = Area*4
D = Node
Example:
Base Address = 172.16.0.0, Network Area = 2, Node number = 201
(Local = 0, Node number < 256) =>
Primary Network Interface (Path = 0): 172.(16+0).(2*4).201 = 172.16.8.201
Secondary Network Interface (Path = 1)172.(16+1).(2*4).201 = 172.17.8.201

RNRP Configuration Parameters

RNRP has two groups of configuration parameters. One group contains base
parameters that are common to all network interfaces in a node and another group
contains parameters that may be specified for each individual network interface.
Table 7 and Table 8 below describe the parameters. The same parameters exist in a
PC and in the Control Builder configuration but in some cases the names differ
slightly. In these cases the table indicates where the names apply by (PC) and (Ctrl).
For most installations the default values for the RNRP configuration parameters
are sufficient. This means that none of the parameters in Table 7 and Table 8 need
to be modified.
If explicit RNRP configuration is used at least some of the parameters need to be
set to other than the default values.
For a controller the RNRP parameters are set in the hardware tree in the controller
project built in the Control Builder. The Base parameters are set on the hardware
unit for the Controller CPU, e.g. PM860/TP860 and the explicit RNRP parameters
are set on the hardware unit for the Ethernet interfaces and the PPP protocol
definition on a COM-port.

56 3BSE034463R5001
Section 3 RNRP and Network Configurations RNRP Configuration Parameters

In a PC the RNRP parameters are set with the RNRP configuration wizard,
see Configuring RNRP in a PC on page 68. The base parameters and the explicit
parameters are located under different tabs.

Table 7. RNRP Base Parameters

RNRP Base Parameters

Parameter Range Description
Max number of own 1 - 8(PC) Maximum number of Network Areas that can
network areas (PC) 1-4(Ctrl) be installed in this node. An end node always
RNRP Number of own uses one Network Area.
areas (Ctrl) Default: 3(PC), 2(Ctrl), rarely changed
Max number of remote 0 - 35(PC) Maximum number of remote Network Areas
network areas (PC) 0 - 8(Ctrl) to which this node can be connected.
RNRP Number of Default: 5(PC), 4(Ctrl), rarely changed
remote areas (Ctrl)
Network Identity (PC) A.B.0.0 The network base address used at
RNRP Default implicit RNRP configuration.
Network ID (Ctrl) Default: 172.16.0.0
Send Period (PC) 1..60 The time period for multicasting of routing
RNRP Send Period messages. This is also the minimum time for
(Ctrl) fail over in a redundant network.Range value
in second units. Default: 1
Also read Network Fail Over Time on page
45.
Max number of lost 1..10 Number of routing messages that may be lost
messages (PC) until a path to a node is down.
RNRP Max Lost Time(s) to detect node down =
Messages (Ctrl) Send Period * (Max Lost Messages + 1)
Default: 3, rarely changed
Max number of hops 1..5 The maximum accepted hop count (number
(PC) of passed routers) in the network.
RNRP Max no of hops Default: 3, rarely changed
Ctrl)

3BSE034463R5001 57
RNRP Configuration Parameters Section 3 RNRP and Network Configurations

Table 7. RNRP Base Parameters (Continued)

RNRP Base Parameters

Parameter Range Description
Multicast enabled (PC) 0..1 A flag that if set makes the protocol use IP
(fixed set in a multicasting instead of broadcasting.
controller) Default: 1, do never change!

System type (PC) 1..127 System type that will be displayed by e.g. the
(fixed set in a RNRP Network Monitor.
controller) Note that bit zero is reserved and is not a part
of the System Type.
1-70: Controllers
71-127: Workplaces
Number of explicit 0..8 Number of explicit specified network interface
addresses (PC) addresses with RNRP parameters.
(not configured in a Default: 0.
controller) For a controller this is decided by the values
of the RNRP address parameters for the
Ethernet ports
Enable ICMP 0..1 Internet Control Message Protocol. This
Redirects(PC) parameter can cause the stack to plumb route
(not configured in a host.
controller) Default: 0, do never change
To make a change of this parameter effective
the node needs to be restarted.

58 3BSE034463R5001
Section 3 RNRP and Network Configurations RNRP Configuration Parameters

Table 7. RNRP Base Parameters (Continued)

RNRP Base Parameters

Parameter Range Description
Disable Media 0..1 This parameter controls DHCP media sense
Sensing behavior such as if the network cable is out.
(not configured in a Set to 1 means the clients ignores the media.
controller) Default: 1, do never change
To make a change of this parameter effective
the node needs to be restarted.
Enable TCP/IP 0..1 A flag that if set enables this node to be a
Forwarding (PC) router.
(always enabled in a It shall typically be set to 1 in a Connectivity
controller) Server.
Default: 0
To make a change of this parameter effective
the node needs to be restarted.

3BSE034463R5001 59
RNRP Configuration Parameters Section 3 RNRP and Network Configurations

If the parameters, Network Identity, Send Period, and Max number of lost
messages, are valid for all the network interfaces used in this node, no explicit
interface parameters have to be defined and the value of parameter numExplicit
must be zero.
If the base parameters are not acceptable to all Network Areas or if the implicit
addressing scheme does not fit the installed network (true for all point-to-point
links), then the RNRP parameters have to be specified explicitly for every
individual network interface. Please see Table 8.
For many parameters in the explicit tabs in the RNRP Wizard (see Configuring
RNRP in a PC on page 68) and on the individual Ethernet interface for a
controller setting the value 0 means that the corresponding base parameter will be
used.
Table 8. RNRP Explicit Parameters

Parameters that may be specified for each Network Interface

Parameter Range Description
IP address A.B.C.D The interface IP address.
If point-to-point link, please read next chapter.
IP subnet mask X.Y.Z.W The IP address mask used on this interface.
Normal value 255.255.252.0
Network Area 0..31 Network Area number on this interface.
32..35 Tunnel Network Area numbers.
Set to 0 if implicit configuration is used.
Network Area Local 0..1 A flag that, if non zero, specifies a Local Network Area.
Normal value is 0.
Set to 0 if implicit configuration is used.
Path Number 0..1 Network Path number on this interface.
Set to 0 if implicit configuration is used.
Node Number 1..500 The own Node number in this Network Area
Set to 0 if implicit configuration is used.

60 3BSE034463R5001
Section 3 RNRP and Network Configurations RNRP Configuration Parameters

Table 8. RNRP Explicit Parameters (Continued)

Parameters that may be specified for each Network Interface

Parameter Range Description
Send Period 1..60 Routing update period. Range value in second units.
Normal value is 1.
0 means use the corresponding base parameter.
Max Lost Messages 1..10 Number of routing messages that may be lost until a
(Ctrl) path to a node is down. Normal value is 3.
Max number of lost Time(s) to detect node down =
messages (PC) receivedSendPeriod* (maxLostMessages+1)
0 means use the corresponding base parameter.
Remote IP address 0..500 The peer node number. If specified, the protocol uses
(Ctrl, Set on the HW unicast instead of multicast/broadcasting.
unit for PPP) Only used for point-to-point links. Set to zero
Point-to-point otherwise.
destination node
(PC)
Proxy router A.B.C.D The IP address to a router not running RNRP that is
used in a Tunnel Network Area. Only Network Areas 32
to 35 are defined as Tunnel Areas.
Only used for Tunnel Areas. Set to zero otherwise.
Target addr A.B.C.D The IP address to the node on the other end of the
Tunnel Area that belongs to a real Network Area.
Only used for Tunnel Areas. Set to zero otherwise.

In a PC RNRP needs to be restarted to make a change effective of any of the

parameters in Table 8. This is done with the button “Restart RNRP”, see
Figure 27 on page 70. In a controller a change of most of the parameters in Table
7 will be effective without restarting RNRP.
If however the IP address or the IP subnet mask is changed the controller needs to
be restarted to make the change effective.
Any controller restart works (short or long init or power fail restart), but the
application restart at download is not enough.

3BSE034463R5001 61
Mixing Explicit and Implicit RNRP Configuration Section 3 RNRP and Network Configurations

A user that configures with explicit parameters must follow these rules:
• The Node number must be the same as the HostID (the least significant bits in
the IP address). An exception to this rule is when the IP address mask is equal
to 255.255.255.255 in which case RNRP will use the IP class C address
internally, i.e. the Node Number must be equal to the least significant byte in
the IP address, i.e. D if the IP address is A.B.C.D.
• Parameters nodeNo, sendPeriod, and maxLostMessages, must have the same
values on both redundant paths within one Network Area.

Mixing Explicit and Implicit RNRP Configuration

All nodes on the same network area must use the same configuration method for
the interfaces towards that area.
In different Network areas of a system it is possible to use different methods.
A node with connections to more than one network area can use different methods
towards different areas. For a PC this means that the parameter Number of explicit
addresses (see RNRP Address Configuration: Implicit or Explicit on page 52) will
be > 1 but less than the number of network interfaces. For a controller this
corresponds to setting Node Number, Network or Path number > 0.

Interconnection of Network Areas over WAN

System communications sometimes needs to use external network providers to
cover sites distributed over large areas. This chapter only briefly describes different
methods to interconnect Network Areas over WAN by different network services.
Details about configurations, security and performance must be made up together
with a selected network provider.
Shown possibilities are:
• Use of standard IP Routers
• Use of Layer 2 VPN or VLAN Tunneling
• Use of Layer 3 VPN
The first section covers routing and redundancy issues. The two following also
cover security aspects of extending the system network.

62 3BSE034463R5001
Section 3 RNRP and Network Configurations Use of Standard IP Routers between RNRP Network

Use of Standard IP Routers between RNRP Network Areas

Standard IP routers that do not run the RNRP protocol can be used between
Network Areas. This is done by configuration of RNRP Tunnel Areas. A Tunnel
Area is a specification of IP routes and addresses in a path between two Network
Areas. Both static network routes in the routers and explicit addresses to the routers
in the Area border nodes have to be configured. See example below.

172.16.4.0 Network Area 1

172.17.4.0
area = 32
router = 138.201.0.2
target = 138.203.0.1
Tunnel Area
border node
Network nextHop
.1 172.16.4.0 138.201.0.1
172.17.4.0 138.201.0.1
138.201.0.0 172.16.8.0 138.202.0.2
.2
172.17.8.0 138.202.0.2
138.203.0.1 138.202.0.2
.1
Tunnel Area 32 138.202.0.0 WAN Network nextHop
172.16.4.0 138.202.0.1
.2 172.17.4.0 138.202.0.1
172.16.8.0 138.203.0.1
172.17.8.0 138.203.0.1
.2 138.201.0.1 138.202.0.1
138.203.0.0
.1
area = 32
router = 138.203.0.2
target = 138.201.0.1

172.16.8.0
172.17.8.0 Network Area 2

Figure 23. An RNRP Tunnel Area between Network Area 1 and 2

3BSE034463R5001 63
Use of Standard IP Routers between RNRP Network Areas Section 3 RNRP and Network

The network IP addresses inside a Network Tunnel Area can be freely selected, the
RNRP protocol does not restrict IP address selection.
A Tunnel Area border node collects network information about all known Network
Areas on its side of the tunnel and send the collected information to the Tunnel Area
border node on opposite side of the tunnel.
An RNRP Tunnel Area only has one network path. There is no support of redundant
paths within a Tunnel Area. If redundant connections are required then two parallel
Network Tunnel Areas can be configured. This is shown in Figure 24 on page 65.

64 3BSE034463R5001
Section 3 RNRP and Network Configurations Use of Standard IP Routers between RNRP Network

172.16.4.0 Network Area 1

172.17.4.0
area = 33
Tunnel Area router = 138.204.0.2
border nodes target = 138.206.0.1

Network nextHop
.1 .1 172.16.4.0 138.204.0.1
172.17.4.0 138.204.0.1
138.201.0.0 138.204.0.0
172.16.8.0 138.205.0.2
.2 .2
172.17.8.0 138.205.0.2
138.206.0.1 138.205.0.2
.1 .1
Tunnel Area 32 Tunnel Area 33
138.202.0.0 WAN1 138.205.0.0 WAN2 Network nextHop
172.16.4.0 138.205.0.1
.2 .2 172.17.4.0 138.205.0.1
172.16.8.0 138.206.0.1
172.17.8.0 138.206.0.1
.2 .2 138.204.0.1 138.205.0.1
The routing 138.203.0.0 138.206.0.0
configurations for .1 .1
area = 33
Tunnel area 32 are router = 138.206.0.2
the same as in target = 138.204.0.1
Figure 23
172.16.8.0
172.17.8.0 Network Area 2

Figure 24. Redundant RNRP Tunnel Areas between Network Area 1 and 2

Applications inside the Tunnel Area border node itself do not get redundancy
between the two Tunnel Areas.This means that the Tunnel Area border nodes should
not be nodes that run applications that need to use the tunnel.

3BSE034463R5001 65
Use of Layer 2 VPN Solutions Section 3 RNRP and Network Configurations

The Tunnel is not recommended to make direct use of public networks since the
private Network Areas are exposed by the routers. If a link over Internet is
requested than a secure tunnel using Layer 3 VPN technique is recommended. See
Use of Layer 3 VPN Solutions on page 67 and Virtual Private Networks (VPN) for
Secure Connections on page 203.

Use of Layer 2 VPN Solutions

A layer 2 solution enables the one and same RNRP Network Area to be distributed
by use of VLAN and different network backbone technologies. For the clients point
of view the network is transparent looking as single LANs. Clients and Controllers
connect to VLAN ports on Ethernet devices. The traffic between the Ethernet
devices are transferred by some type of routing or tunneling protocol. One possible
protocol to use is Multi Protocol Label Switching (MPLS).

Network Area N
(untagged traffic)

VLAN x LER LER VLAN y

VLAN tunneled over

LSR LSR
backbone network with
MPLS

LER = Label Edge Router

LSR LSR
LSR = Label Switch Router

VLAN x LER LER VLAN y

Network Area N
(untagged traffic)

Figure 25. Layer 2 VPN, Example with MPLS Backbone

66 3BSE034463R5001
Section 3 RNRP and Network Configurations Use of Layer 3 VPN Solutions

Use of VLAN makes RNRP configuration easy, the network transportation is

invisible for RNRP. Both sides of the network belong to the same subnet and
network area. See also Reducing HW using Virtual LANs on page 179.
Layer 2 VPN does generally not give the same security a Layer 3 VPN.

Use of Layer 3 VPN Solutions

Layer 3 solutions gives high security by using encrypted tunnels like for example
the IPSec standard. Service providers has no visibility into IP tunnels. The traffic
within a service provider can be routed as any other IP traffic.
The RNRP configurations is made in the same way as with RNRP Tunnels over
standard routers, see Use of Standard IP Routers between RNRP Network Areas on
page 63.
The VPN tunnel must be able to tunnel data from nodes on different subnets on each
remote site.
Layer 3 solutions are generally slower than Layer 2 solutions.
Microsoft Windows Server 2003 support the two Layer 3 solutions PPTP and L2TP.
See also Virtual Private Networks (VPN) for Secure Connections on page 203 and
Site to Site Connections via a Firewall on page 209.

RNRP in a PC
This section describes how to install and configure RNRP in a PC.

Configuring a Network Adapter

The manual IndustrialIT 800xA, System, System Installation (3BSE034678Rxxxx)
includes a description of how to configure the network adapter. The following
parameters shall be configured:
• The IP address
See Selection of IP Addresses on page 27.
• The Subnet Mask
See Address Rules for Implicit RNRP Configuration on page 54.

3BSE034463R5001 67
Installing RNRP Section 3 RNRP and Network Configurations

• The DNS server addresses

See DNS Configuration in Each Node on page 83.
• If the interface shall be automatically registered in DNS
See DNS Configuration in Each Node on page 83.
• If NetBIOS shall be used on this interface
See DNS Configuration in Each Node on page 83.
A Network Adapter in a PC must never be Disabled. If it is disabled the network
redundancy function is lost and RNRP must to be restarted.

Installing RNRP
RNRP is installed together with other products.
It is always included in the AC 800M controller firmware.
For PCs it is automatically installed when the Process Portal is installed.
RNRP can also be used in PCs that do not use any other 800xA software.
On the 800xA System DVD RNRP is available as a component that can be installed
without the rest of the 800xA System.

Configuring RNRP in a PC
Normally the only item to configure is the IP address for each Network Adapter and
this will be handled during the installation of Windows.

If the implicit RNRP configuration is used normally RNRP does not need to be
configured after being installed.

It is possible to configure more than one IP address for a network interface in a

PC, but only the first IP address in the list for the interface can be used for a
normal RNRP area. A point to point connection area (e.g. a tunnel area) can
however use a second IP address.

68 3BSE034463R5001
Section 3 RNRP and Network Configurations Configuring RNRP in a PC

To use a PC as a RNRP router (e.g. a connectivity server) the parameter Enable

TCP/IP Forwarding must be set to 1. After this parameter is changed the node
needs to be restarted.
Explicit RNRP configuration (and configuration of RNRP Base parameters e.g.
TCP/IP Forwarding, see RNRP Configuration Parameters on page 56) in a PC is
done with the RNRP Setup Wizard that can be found with a right-click on the RNRP
icon in the System Tray or at Start > Programs > ABB Industrial IT 800xA >
System > Network > RNRP Wizard, see Figure 26.
The RNRP icon is normally listed at Start > Programs > Startup to be activated
automatically when a user logs in. It can also be started by Start > Programs >
ABB Industrial IT 800xA > System > Network > RNRP Create Icon.

Figure 26. RNRP Setup Wizard Mainly for Explicit Configuration of RNRP,
the Tabs “Parameters” and “Explicit address 0”

3BSE034463R5001 69
Verify RNRP Connectivity Section 3 RNRP and Network Configurations

Verify RNRP Connectivity

Use the RNRP Network Event Monitor (see RNRP Network Monitor on page 161)
to verify that the PC has contact with all other nodes that run RNRP.

Configuring what Networks to Use

In order for system communication applications in an 800xA system to follow the
rule that all connections must be established using primary address (see page 44) the
system needs to know what network areas and paths it should use.
The configuration is done at “Create System” (or later) with two dialogs.
One dialog where you first tell the number of network areas where 800xA PCs will
communicate. This should be network areas where clients and servers communicate
with each other. Network areas where only controllers and connectivity servers are
connected do not need to be counted here. The number is 1 in almost all systems.
After the first question you get the dialog shown in Figure 27.
Enter the network address information for the Client Server network.

Figure 27. Dialog to Configure Network Areas where PPA Nodes Communicate

The configuration is intended for the 800xA System applications if a redundant

Client Server network is used or if clients and/or servers are connected to a
network in addition to the Client Server network. The purpose is to prevent the
clients and servers from establishing connections on the wrong network.

70 3BSE034463R5001
 Section 4 Domain and DNS Configuration

DNS Strategies
Configuring DNS for an 800xA system is much the same as for any system using
Windows, but there are also some specific things to consider:
• The administration of the DNS configuration shall be as simple as possible;
let the nodes register their addresses and names in the DNS Server
automatically.
• Reverse lookup queries on any address for a node shall give the correct name.
This means that there must be a reverse lookup zone for both the primary and
the secondary network.
• All forward lookup queries shall give a unique IP Address in all situations.
This must work also during cable breaks or if only one of the DNS Servers is
working. This is discussed more in Assuring that Forward Lookup Queries
give a Unique IP Address on page 81.
• DNS queries shall be as quick as possible in all situations, including when only
one of the DNS Servers is working. This is described more in DNS
Configuration in Each Node on page 83.

Choosing Names for Domains and PCs

Before you configure the Domain Controller you should decide the conventions for
node names in the system. The first thing to decide is the domain name. The domain
will be given two types of names:
• The fully qualified domain name (FQDN)
This is the name that is used by DNS. It can consist of several labels separated
by dots, e.g. MyPlant.MyCompany.com.

3BSE034463R5001 71
Allocating 800xA Systems to Domains Section 4 Domain and DNS Configuration

• The NetBIOS name

This name is used by most Windows components, e.g. the Windows Login
Screen. It is typically equal to the left most part of the fully qualified domain
name, e.g. MYPLANT.
Once an 800xA system has been installed in a domain, the domain name must not
be changed. One reason is that user names in the system contain the domain name.
The name of a domain for a private network that is not going to be connected to
Internet should end with “.local”, e.g. MyPlant.local. The part before “.local” can be
chosen arbitrarily.
The nodes within a domain must be given computer names that are unique within
the domain. The full computer name of a PC is “computer name”.”domain name”,
e.g. ServerA.mydomain.local (see also Figure 28). The corresponding NetBIOS
name is written \\MYDOMAIN\SERVERA.
The On-line Help for Windows Server 2003 describe more about names in the
sections DNS Domain Names and Name space planning for DNS.

Allocating 800xA Systems to Domains

All nodes in an 800xA system must be members of the same domain. A running
800xA system must always stay in the same domain. It is however possible to take a
backup of a system and do the restore to another domain.
Several 800xA Systems may belong to the same domain. An 800xA system may
belong to a domain which is also used for other types of systems. The 800xA system
depends on the Domain Controller being available at all times. This means that it is
important to consider if the availability of the Domain Controller will be sufficient
if one domain is used for many types of systems.
When importing data with the import/export tool there are no restrictions regarding
domain membership for the system that exported the data. It could belong to the
same or a different domain or a workgroup.

72 3BSE034463R5001
Section 4 Domain and DNS Configuration Configuring DNS Functionality

Configuring DNS Functionality

DNS configuration is done with the normal Windows configuration editors:
• For each node, including the DNS Servers:
See DNS Configuration in Each Node on page 83
– Domain membership in the System Properties
– Properties for each Network Interfaces for Network Areas where DNS is
used
• In the DNS Server
DNS Server Configuration on page 78
– Properties for the DNS server itself
– Properties for the DNS Lookup Zones
– The records in the DNS Lookup Zones
It is recommended to configure the DNS Server and to set up the DNS Lookup
Zones before anything else is done with the other nodes.

NetBIOS Considerations
NetBIOS is an old Microsoft protocol for network communication between nodes
with Microsoft Windows operating systems. With Windows 2000 and beyond, the
importance of NetBIOS has been reduced. For example, for name resolution DNS is
used instead of NetBIOS. There are however still some functions that need
NetBIOS. One example is the ability to use the Windows Explorer to browse
neighbor nodes under “My Network Places\Entire Network\Microsoft Windows
Network”. The same Windows functionality is used to locate possible nodes for
connection of Clients and Servers when running the Configuration Wizard.
This means that NetBIOS is needed on the Client Server network, but it is not
needed on the Control Network. NetBIOS and the browsing functions do however
not work well if the Domain Controller is “Multi Homed”, i.e. is connected to more
than one network. Therefore using redundant networks, NetBIOS should be
disabled on the secondary network.

3BSE034463R5001 73
Which Nodes use DNS Section 4 Domain and DNS Configuration

The recommendation for NetBIOS configuration is therefore:

• Enable NetBIOS on all interfaces for the Primary Client Server Network
• Disable NetBIOS on all interfaces for the Secondary Client Server Network
• Disable NetBIOS on all interfaces for the Control Network
Figure 34 in DNS Configuration in Each Node on page 83 shows how to configure
NetBIOS. This approach means that the Primary Client Server Network has to be
working for browsing to work properly. Browsing however is not needed when the
system has been configured and is up and running. See Verifying NetBIOS
Configuration on page 93 for advice on how to fault trace problems by browsing.

Which Nodes use DNS

PC application programs in the Industrial IT System use DNS when they
communicate with another node that are identified by name.
This means that all PCs use DNS and all PCs must all be known by the DNS
servers.
However, the applications in the AC 800M Controllers identify other nodes only by
IP address and all PC applications that communicate with the controllers also only
identify the controllers by IP address.
This means that the AC 800M Controllers do not use DNS and they will not be
known by the DNS servers.

Location of Domain Controllers

A Domain Controller and a DNS server are required to be on-line and operating to
use the 800xA system.
The Domain Controller and the DNS server are normally installed on the same
machine. This should be a dedicated node (or two for redundancy) that does not run
any other 800xA System Software except RNRP (see Configuring RNRP in a PC on
page 68). The main reason is that it simplifies the handling of backups and upgrades
substantially, see Backups of Domain Controllers on page 75.

74 3BSE034463R5001
Section 4 Domain and DNS Configuration Operating System for Domain Controllers

Operating System for Domain Controllers

Use Windows 2000 Server or Windows Server 2003 on the Domain Controllers for
800xA systems.
If all Domain Controllers are running Windows 2003 Server the Domain Functional
Level may be set to “Windows Server 2003”. This gives improved performance of
the domain controllers in a number of areas that are described in e.g. the Online
Help for Windows 2003 Server.
If at least one of the domain controllers is running Windows 2000 Server the
Domain Functional Level must be set to “Windows 2000 Native”.

Maintaining Redundant Domain Controllers

DcDiag: Domain Controller Diagnostics
Microsoft provides a tool called DcDiag that can perform a number of tests of the
health of a domain controller. DcDiag is included on the delivery of Windows 2000
Advanced Server and Windows Server 2003. It can also be downloaded from
Microsoft’s web site. dcdiag /a performs a test of all domain controllers in a site.
DcDiag will report an error if W32Time is disabled. Disregard this error message
if you are using e.g. AfwTime instead of W32Time, see Windows Time Service
(W32Time) on page 139.

Backups of Domain Controllers

It is possible to use Ghost backup for redundant and non-redundant domain
controllers. However, it is important not to exceed the Active Directory Tombstone
Lifetime (by default 60 days) when restoring a backup.
A backup which is older than the tombstone lifetime is normally not useful, unless
all domain controllers are restored at the same time (with images taken not more
than 60 days apart).
Microsoft Knowledge Base Article KB216993 describes more about this topic.

3BSE034463R5001 75
Recovering after a Crash of the First Installed Domain Controller Section 4 Domain and DNS

In addition to periodic complete backups of the Domain Controllers it is

recommended to do a complete backup of the nodes just before they are promoted to
become domains controller (dcpromo). This is a time when the active directory has
not yet been created and this backup is therefore independent of the tombstone life
time.
If a redundant domain controller fails it is possible to restore it from a Ghost backup
which was taken before promoting the server to become a domain controller. After
restoring such a backup the content of the Active Directory must be replicated over
from a domain controller which still is working properly.
Depending on what domain controller functions the lost server was responsible for
some additional steps may need to be taken. So called FSMO roles may need to be
seized by another domain controller and old stale FSMO records may need to be
cleaned out. This process is described in the next section.

Recovering after a Crash of the First Installed Domain Controller

It is possible to use multiple Domain Controllers for a Domain. In most of their
operation all domain controllers are equal but there are a number of roles that are
only taken by the first PC that is promoted to be Domain Controller. The first
installed Domain controller is by default the only one which is:
• FSMO role Schema Master
• FSMO role Domain Naming Master
• FSMO role PDC
• FSMO role RID master
• FSMO role Infrastructure master
• Global Catalog server
If the first Domain Controller is permanently removed from the network there are
some manual actions to do to make sure that the system keeps working in the long
run. This involves the following steps:
1. Check if the removed server had the 5 FSMO roles
This is done with the tool ntdsutil. See below.

76 3BSE034463R5001
Section 4 Domain and DNS Configuration Recovering after a Crash of the First Installed Domain

2. If necessary, seize the FSMO roles to one of the other servers

This is described in TechNet article KB255504
3. Create a new Global Catalog
This is described in TechNet article KB313994
4. Remove the old server from the Active Directory
This is described in TechNet article KB216498
To find out if the removed server had the 5 FSMO roles do the following at a
command prompt:
ntdsutil: roles
fsmo maintenance: conn
server connections: conn to serv <a working server>
server connections: quit
fsmo maintenance: Select operation target
select operation target: list roles for conn ser
This gives the result:
Server <the working server> knows about 5 roles
Schema - CN=NTDS Settings,CN=<the removed server>,
CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=demo,DC=net
Domain - CN=NTDS Settings,CN=<the removed server>,
CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=demo,DC=net
PDC - CN=NTDS Settings,CN=<the removed server>,
CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=demo,DC=net
RID - CN=NTDS Settings,CN=<the removed server>,
CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=demo,DC=net
Infrastructure - CN=NTDS Settings,CN=<the removed server>,
CN=Servers,CN=Default-First-Site-
Name,CN=Sites,CN=Configuration,DC=demo,DC=net

3BSE034463R5001 77
Time Synchronization in a Domain Section 4 Domain and DNS Configuration

Time Synchronization in a Domain

The time must be synchronized between all nodes in a domain. The default setting is
that if the time in a node differs more than 5 minutes compared to the Domain
Controller the node is denied access to the domain. The limit is a parameter which is
called the Kerberos Time Skew variable. See also Windows Time Service
(W32Time) on page 139.

DNS Server Configuration

If more than one Domain Controller is used, you have to decide how they will be
used as DNS Servers. Each node must be configured with one DNS Server as the
Preferred DNS Server. Normally it is suggested to appoint one of the Domain
Controllers to be the Primary DNS Server and configure all nodes to use it as the
Preferred DNS Server. One reason is that this simplifies the replication between
the DNS Servers. It is also easier to predict the behavior of the system if one of the
Domain Controllers stops working. If the system is distributed so that different
nodes are substantially closer to different Domain Controllers other configurations
may be used.
The IndustrialIT 800xA, System, System Installation (3BSE034679Rxxxx)
instruction describes how to set up a Domain Controller and DNS Server with DNS
integrated in Active Directory. See also Location of Domain Controllers on page 74.
After that creation of the Domain Controller, make sure that the following is
configured for DNS:
• The Network Identification (in Start > Settings > Control Panel > System)
for the Domain Controller must indicate that it belongs to the newly created
domain, see Figure 28.
• The DNS server is running and there are DNS Lookup Zones for each path on
each network area that is included in the domain and where there are nodes that
use DNS. See Figure 29 and Figure 30. This typically means the Client Server
Network but not the Control Networks. DNS Lookup zones are needed for a
Control Network only if there will be PCs that communicate with each other
via the Control Network. The DNS Zones will be populated with records for
the PCs when they join the domain.

78 3BSE034463R5001
Section 4 Domain and DNS Configuration DNS Server Configuration

• The DNS Lookup Zones are Active Directory integrated and allow dynamic
update of records from nodes that enter the network, see Figure 31.
Make sure that the parameter Dynamic updates is set to Secure Only or Non
secure and secure.

Figure 28. System Properties for a Domain Controller with Computer Name

3BSE034463R5001 79
DNS Server Configuration Section 4 Domain and DNS Configuration

Figure 29. DNS Database with one Forward Lookup Zone and two Reverse Lookup
Zones. The Data base is shared between DNS Servers.

Figure 30. The Reverse Lookup Zone for Primary Network

80 3BSE034463R5001
Section 4 Domain and DNS Configuration Assuring that Forward Lookup Queries give a Unique IP

Figure 31. Properties for DNS Lookup Zones

Assuring that Forward Lookup Queries give a Unique IP Address

When a node makes a forward lookup query to get the IP Address for a node the
response will always be the Primary Network address. This is to make sure that all
applications communicating with nodes that run RNRP always address the nodes on
the primary network (see page 44). The default DNS settings do not provide this
functionality. The important parameters are:
• The parameter Allow dynamic update for the Forward Lookup Zones.
• The parameter Register this connection’s addresses in DNS for the Network
Interfaces.
Letting the DNS Zones dynamically update and the nodes to automatically register
their addresses and names simplifies the administration of the DNS configuration
since all nodes will be registered when they enter the network for the first time.

3BSE034463R5001 81
Assuring that Forward Lookup Queries give a Unique IP Address Section 4 Domain and DNS

This scheme is preferred, but realized that the Forward lookup zones will contain
two addresses for nodes when using a redundant network. Forward lookup queries
of the DNS server will return both these addresses.
The order of the addresses typically depends from which network the query is
received. This is not acceptable. To prevent this make sure that only the primary
network addresses are available in the Forward Lookup Zones. This can be achieved
in the following way:
• Set the parameter Register this connection’s addresses in DNS to false for
the Secondary Network Interfaces. (See Figure 33 on page 85)
• Add the Secondary address in the reverse lookup zone for the secondary
network manually.
An alternative method is to:
1. Set the parameter Register this connection’s addresses in DNS to true for
both the Primary and the secondary Network Interface.
2. Let the PC register both addresses in DNS.
3. Set the parameter Register this connection’s addresses in DNS to false for the
Secondary Network Interface.
4. Delete the Secondary address from the Forward Lookup Zone.
It is not recommended to disable the Dynamic update for a Forward Lookup Zone.
The Forward Lookup Zones contain more information about the domain controllers
than just node names. This information must be allowed to update dynamically.

82 3BSE034463R5001
Section 4 Domain and DNS Configuration DNS Configuration in Each Node

DNS Configuration in Each Node

This section describes how to configure each node to fulfill the goals described in
DNS Strategies on page 71 and NetBIOS Considerations on page 73, see Figure 33
and Figure 34.
• The Primary DNS Suffix must be the same as the domain name. When joining
the domain it will automatically be configured like this and normally does not
need to be changed. To check that it is correct open Start > Settings >
Control Panel > System, select the tab Network Identification, open
Properties and More, see Figure 32.
• The Primary DNS Server must be configured as the Preferred DNS Server for
the Network interface which is first in the list of interfaces, i.e. the Primary
Network Interface (see Configuring the Order of the Network Interfaces on
page 86).
• The Secondary DNS server must be configured as Preferred DNS Server for
the Network interface which is second in the list of interfaces, i.e. the
Secondary Network interface.
• For both the Primary and the Secondary Network interface Alternate DNS
Server shall be the DNS server which is not the Preferred DNS Server.
This is to ensure that both Network Interfaces are registered on both DNS
Servers.
• The parameter Register this connection’s addresses in DNS must be set for
the Primary Network Interfaces where DNS will be used (typically only the
Primary Client Server network) and reset for the secondary network interfaces.
• NetBIOS shall only be used on the Primary Client Server Network. It is by
default enabled so it must be disabled on all other Network Interfaces.
On a combined network it shall be used on the Primary network.
See also Verifying DNS and NetBIOS Configuration on page 91.
PCs shall be entered in the DNS Lookup Zones.
Controllers shall not be entered in the DNS Lookup Zones.
(See Which Nodes use DNS on page 74)

3BSE034463R5001 83
DNS Configuration in Each Node Section 4 Domain and DNS Configuration

Figure 32. Network Identification with full Computer Name and Primary DNS
Suffix for Domain Member Computers

84 3BSE034463R5001
Section 4 Domain and DNS Configuration DNS Configuration in Each Node

Figure 33. DNS Configuration for Primary and Secondary Network Interface

3BSE034463R5001 85
Configuring the Order of the Network Interfaces Section 4 Domain and DNS Configuration

Figure 34. NetBIOS shall only be enabled on the Primary Client Server Network

Configuring the Order of the Network Interfaces

To ensure that DNS queries are primarily sent to the DNS server configured as
Preferred DNS Server on the Primary Network Interface, it is important to set the
order of the network interfaces correctly; the primary network as the top selection,
and the secondary network next. Network interfaces for network areas where DNS
is not used must be set below the interfaces of those that are used.
1. Set the order in Network and Dial-up Connections in the Control Panel on
each node.
2. Select Advanced Settings in the Advanced menu.

86 3BSE034463R5001
Section 4 Domain and DNS Configuration Windows Workgroups Instead of Windows Domain

3. Set the order of the Network Interfaces in the Adapters and Bindings tab,
according to Figure 35.

Figure 35. Network Interface Order

Windows Workgroups Instead of Windows Domain

Small systems can run without a Domain Controller (and DNS server). In that case
the PCs and users are not handled by a Windows Domain and instead a Windows
Workgroup needs to be created.
A Windows Workgroup is not managed on a dedicated PC. The workgroup
configuration needs to be done on all PCs that belong to the workgroup. This
includes handling the names and addresses of the PCs and definition of users and
groups. The handling of Users and groups in a Windows Workgroup is described in
IndustrialIT 800xA, System, Administration and Security (3BSE037410Rxxxx).
There is no fixed limit for the number of nodes or number of users that can be
handled within a workgroup. Systems with more than 10 PCs or 5 users are
normally easier to manage in a domain.

3BSE034463R5001 87
Managing PC Names with Host Files Section 4 Domain and DNS Configuration

Managing PC Names with Host Files

In a Windows Workgroup the correlation between node names and IP addresses is
best handled with host files. Create one “host file” with the addresses and names of
all nodes and copy it to all nodes in the network.
In a simple network address and name resolution could be handled with NetBIOS
instead of with host files, but when nodes are connected to more than one network,
e.g. when using a redundant network, it is not possible to control which address a
node name will be associated with. This means that it is not possible to guarantee
that the rule is followed that all applications communicating with nodes that run
RNRP always address the nodes on the primary network (see page 44).
The host file has the name hosts with no extension. It is located at the directory
C:\WINNT\system32\drivers\etc. It contains rows like this:
127.0.0.1 localhost
172.16.4.11 AS1 # The Aspect Server, CS1
172.17.4.11 AS1 # The Aspect Server, CS2
172.16.4.21 CS1 # The Connectivity Server, CS1
172.17.4.21 CS1 # The Connectivity Server, CS2
172.16.4.71 C1 # Workplace Client 1, CS1
172.17.4.71 C1 # Workplace Client 1, CS2
172.16.4.72 C2 # Workplace Client 2, CS1
172.17.4.72 C2 # Workplace Client 2, CS2
Enter the nodes’ both IP addresses for the Client/Server Network if the network is
redundant.
Windows always first looks for address information in the file hosts before
using DNS or other lookup methods. The check box “Enable LMHOSTS lookup”
in the Advanced TCP/IP settings, see Figure 34 on page 86 has no influence on
this.

88 3BSE034463R5001
Section 4 Domain and DNS Configuration Example of IP Addresses and DNS Configuration

Example of IP Addresses and DNS Configuration

This section describes an example of how to configure DNS for a system with the
following features:
• Two Domain Controllers
• One Network Area for the Client Server Network
• Two Network Areas for Control Networks.
• One Control Network Area is handled by 2 Connectivity Servers
• One Controller with single CPU
• One Controller with redundant CPU

Domain Aspect
Domain Client 71
Controller 1 Server 11
Controller 2

Client/Server
Network Area 1 Network
Connectivity
Connectivity Connectivity
Server 21
Server 22 Server 23

Network Area 20 Control Networks Network Area 21

Controller 20-151 Controller 21-151

Figure 36. Example System to show DNS Configuration

This is not a recommended way to connect a system with only so few nodes. It is an
example to show concepts. A system with more servers, clients and controllers
would be configured in a similar way.

3BSE034463R5001 89
Example of IP Addresses and DNS Configuration Section 4 Domain and DNS Configuration

Table 9. DNS Configuration Example

Forward Reverse
Preferred Alternate Auto register
Node name Node Area Path IP Address NetBIOS lookup lookup
DNS server DNS server in DNS
zone zone

Domain 1 1 0 172.16.4.1 172.16.4.1 172.16.4.2 Yes Yes Yes auto Yes auto
Controller 1
1 172.17.4.1 172.16.4.2 172.16.4.1 No No No Yes manual

Domain 2 1 0 172.16.4.2 172.16.4.2 172.16.4.1 Yes Yes Yes auto Yes auto
Controller 2
1 172.17.4.2 172.16.4.1 172.16.4.2 No No No Yes manual

Aspect 11 1 0 172.16.4.11 172.16.4.1 172.16.4.2 Yes Yes Yes auto Yes auto
Server 11
1 172.17.4.11 172.16.4.2 172.16.4.1 No No No Yes manual

Connectivity 21 1 0 172.16.4.21 172.16.4.1 172.16.4.2 Yes Yes Yes auto Yes auto
Server
AC 800M 21 1 172.17.4.21 172.16.4.2 172.16.4.1 No No No Yes manual

20 0 172.16.80.21 [empty] [empty] No No No No

1 172.17.80.21 [empty] [empty] No No No No

Connectivity 22 1 0 172.16.4.22 172.16.4.1 172.16.4.2 Yes Yes Yes auto Yes auto
Server
AC 800M 22 1 172.17.4.22 172.16.4.2 172.16.4.1 No No No Yes manual

21 0 172.16.84.22 [empty] [empty] No No No No

1 172.17.84.22 [empty] [empty] No No No No

Connectivity 23 1 0 172.16.4.23 172.16.4.1 172.16.4.2 Yes Yes Yes auto Yes auto
Server
AC 800M 23 1 172.17.4.23 172.16.4.2 172.16.4.1 No No No Yes manual

21 0 172.16.84.23 [empty] [empty] No No No No

1 172.17.84.23 [empty] [empty] No No No No

Client 71 71 1 0 172.16.4.71 172.16.4.1 172.16.4.2 Yes Yes Yes auto Yes auto

1 172.17.4.71 172.16.4.2 172.16.4.1 No No No Yes manual

Controller 20-151 151 20 0 172.16.80.151 [n.a.] [n.a.] [n.a.] [n.a.] No No

Single CPU
1 172.17.80.151 [n.a.] [n.a.] [n.a.] [n.a.] No No

90 3BSE034463R5001
Section 4 Domain and DNS Configuration Verifying DNS and NetBIOS Configuration

Table 9. DNS Configuration Example

Forward Reverse
Preferred Alternate Auto register
Node name Node Area Path IP Address NetBIOS lookup lookup
DNS server DNS server in DNS
zone zone

Controller 21-151 151 21 0 172.16.84.151 [n.a.] [n.a.] [n.a.] [n.a.] No No

Redundant CPU
1 172.17.84.151 [n.a.] [n.a.] [n.a.] [n.a.] No No

Backup CPU 0 172.16.86.151 [n.a.] [n.a.] [n.a.] [n.a.] No No

1 172.17.86.151 [n.a.] [n.a.] [n.a.] [n.a.] No No

Table 9 shows how to set the DNS parameters for the Network Adapters in the PCs
and what IP addresses to enter in the DNS Lookup Zones.
Each row in Table 9 represents a network interface in a PC or a Controller.
Node, Area and Path are the RNRP address parameters for the Network Interface.
[n.a.] means “not applicable”, e.g. the parameter Preferred DNS server does not
exist for the network interfaces in the controllers.
[empty] means that nothing is to be entered on this parameter.
“Auto register in DNS” Yes/No tells if the check box “Register this connections
addresses in DNS” is to be marked or not.
The two last columns tell if the corresponding IP address should be entered in the
respective Lookup Zones in the DNS server. “Yes auto” means that it will be entered
automatically. “Yes manual” means that it must be entered manually. “No” means
that it should not be entered.

Verifying DNS and NetBIOS Configuration

nslookup
Use the command line utility nslookup to verify that the DNS server and the
different nodes in the system are configured correctly. Nslookup can do both
forward and reverse lookup queries:
Example of a Forward Lookup query for the name sevst-w-0001815:

3BSE034463R5001 91
nslookup Section 4 Domain and DNS Configuration

C:\>nslookup sevst-w-0001815
Server: ahc-domainctrl1.lab.ahc
Address: 172.16.4.1
Name: sevst-w-0001815.lab.ahc
Address: 172.16.4.91
The query is sent to the DNS server ahc-domainctrl1.lab.ahc at address 172.16.4.1.
The response is that the address for sevst-w-0001815 is 172.16.4.91.
Note that a single address is given as a response. This is because there was only one
record for sevst-w-0001815 in the forward lookup zone.
Reverse Lookup Queries will work for both Primary and Secondary addresses:
C:\>nslookup 172.16.4.91
Server: ahc-domainctrl1.lab.ahc
Address: 172.16.4.1
Name: sevst-w-0001815.lab.ahc
Address: 172.16.4.91
C:\>nslookup 172.17.4.91
Server: ahc-domainctrl1.lab.ahc
Address: 172.16.4.1
Name: sevst-w-0001815.lab.ahc
Address: 172.17.4.91
Check that you always get the same response by repeating the queries.
Check that you get the same response if the Primary Network is disconnected.
Check that you get the same response if the Primary DNS Server is disconnected.
This response will however come some seconds later since the first query is sent
only to the Primary DNS Server.
Do not use ping to verify that the DNS configuration works properly.
If NetBIOS is enabled, which it is by default, ping may find the node even if
DNS is not correctly configured.
The On-line help for DNS in Windows Server 2003 include advice for trouble
shooting DNS problems.
If there are problems with the DNS configuration the Windows Event Viewer
may contain useful information.

92 3BSE034463R5001
Section 4 Domain and DNS Configuration Special Considerations when Changing DNS

Special Considerations when Changing DNS Configuration

When changing the DNS configuration pay special attention to when the changes
are actually applied.
If the IP address of a node is changed the DNS Server is not immediately notified.
Notification normally occurs at startup of the node. To force notification, use the
command line utility ipconfig /registerdns in a command window on the
node that will be registered.
When a node makes a DNS query the response is stored in a local cache to speed up
subsequent queries. This implies that changes in the DNS server are not
immediately noticed in client nodes. To empty the local DNS cache use the
command line utility ipconfig /flushdns in a command window on the node
that is to be refreshed.
If the two DNS Servers give different responses the replication between the DNS
Servers may not have been completed since the last change. Read more in the
On-line help on the Windows Server 2003 about replication of Active Directory.

Verifying NetBIOS Configuration

The consequences of an in correctly configured NetBIOS are not always obvious.
First check that all nodes on the Client Server network are visible under “My
Network Places\Entire Network\Microsoft Windows Network”. If they are not,
also verify the following items:
• Check that the nodes are visible on the Primary Client Server Network via
RNRP (path 0) with the RNRP network Monitor, see RNRP Network Monitor
on page 161.
• Check that the configuration has been setup according to DNS Configuration in
Each Node on page 83.
• Actions that change the visible of a node during browsing may take up to 15
minutes to take effect.

3BSE034463R5001 93
Verifying NetBIOS Configuration Section 4 Domain and DNS Configuration

• There is a Windows setting that may hide a node for browsing. After a normal
Windows installation this setting allows browsing, but if a node is not shown,
it should be checked.
Use the command line utility net config server on a node that is not
shown in the browse list. The printout contains a line that may read:
Server hidden Yes
To change the setting write net config server /hidden:No
• Check that the Windows Event Viewer (Start > Settings > Administrative
Tools > Event Viewer) does not contain any errors with the source “browser”.

94 3BSE034463R5001
 Section 5 Time Synchronization

This section describes how to synchronize real time clocks in an IndustrialIT 800xA
System.
The first part of the section describes recommended time synchronization schemes
for the most common configurations:
1. Local Time Source on page 96.
2. External Time Source on page 100.
3. Windows Time Instead of AfwTime on page 103.
4. Systems with More Than One Control Network on page 106.
5. Systems with MB 300 and 800xA for AC 800M on page 107
6. MB 300 as Time Source for AC 800M on page 111.
7. Synchronization from the Client Server Network on page 114.
This is followed by a section describing how to set different configuration
parameters in controllers:
• Configure Time Synchronization in Controllers on page 117.
The rest of this section describes the different protocols and time synchronization
components:
• CNCP - Control Network Clock Protocol on page 120.
• SNTP - Simple Network Time Protocol on page 122.
• MB 300 Time Synchronization on page 124.
• MMS Time Synchronization on page 126.
• AfwTime Service on page 126.
• Time Synchronization for Connectivity Servers, Time Adaptors on page 134.
• Windows Time Service (W32Time) on page 139.

3BSE034463R5001 95
Recommended Time Synchronization Schemes Section 5 Time Synchronization

Recommended Time Synchronization Schemes

To achieve the best time accuracy in the total system, it is recommended to
distribute the time “upwards” in the system, from the Control Network to the Client
Server Network. Typically a controller will act as time master for the Control
Network and the rest of the system will be synchronized from this source.
This way of synchronizing is better than the other direction, because the protocols
on the Control Network support a higher accuracy and the implementations of the
real-time clocks in the Controllers are better than the protocols used between PCs
and the Windows time.
The time source can be a Controller (see Local Time Source on page 96) or an
external time source (see External Time Source on page 100).
Use an external time source if it is important that time stamps in the system are
possible to compare with time stamps from other systems.
The following sections describe some different alternatives. There are tables with
recommended settings. Where and how the settings are done is described in the
protocol sections later in this chapter.

Local Time Source

If it is not important that the clocks in the system are well synchronized with clocks
in the rest of the world, it is sufficient to let one (or more to get redundancy) of the
controllers act as the time source for the whole system. When using AC 800M
controllers CNCP is the recommended protocol for time synchronization to all
nodes on the Control Network that support CNCP. This includes all 800xA PCs that
are connected to the Control Network and use 800xA for AC 800M. If the Control
Network is separated from the Client Server Network, normally only the AC 800M
connectivity servers are connected directly to the Control Network. These PCs shall
use the option, AC 800M Time Adaptor, to act as CNCP time slaves and should also
run the AfwTime Server. The other PCs shall run the AfwTime Client.
Let the Domain Controllers fetch the time from time source controller using SNTP.
If they are not connected to the same network area as the controller, TCP/IP
forwarding must be enabled in the connectivity server (see Table 7 in section RNRP
Configuration Parameters on page 56).

96 3BSE034463R5001
Section 5 Time Synchronization Local Time Source

When using 800xA for Harmony, 800xA for Melody, or 800xA for Advant Master
the connectivity servers shall act as SNTP server for the Domain Controller, see for
example MB 300 as Time Source for AC 800M on page 111.
When using a local time source it is recommended to periodically check and
possibly adjust the system time manually, e.g. once or a few times per year. To be
able to do this the controllers must be set to accept manual time setting. This is done
by setting the parameter “CS Time Set Enable” = true. See also section Setting the
System Time on page 145.

Domain
Controller Client Client Client

Client/Server Network
AfwTime Service sync
Time Server
SNTP Connectivity Server
CNCP
Clock Slave

Control Network

CNCP Clock Slaves

CNCP
Clock Master AC 800M

Figure 37. Time Synchronization with Local Time Source

3BSE034463R5001 97
Local Time Source Section 5 Time Synchronization

Configuration of the Different Nodes

Table 10. Time Sync Configuration in Controllers: Local Time Source

Controller Type

Up to 10 AC 800Ms Other Controllers

CNCP, Master
Time Sync Protocol, Role CNCP, Slave
SNTP Server

Parameters

CS CNCP Clock Master Order Number 1,2,3...10 0

CS Protocol Type CNCP (don’t care) CNCP

CS Time Set Enabled True True

CS Synchronization Interval 20 <don’t care>

CS SNTP Server Addr 1 <empty> <empty>

CS SNTP Server Addr 2 <empty> <empty>

Table 11. Configuration of the AfwTime Service: Local Time Source

Parameters Value

Server Running True

Clients Allowed to set time False

Synchronization Interval (sec.) 20

98 3BSE034463R5001
Section 5 Time Synchronization Local Time Source

Table 12. Time Sync Configuration in Clients and Servers: Local Time Source

Node Type

Connectivity Servers Other 800xA System Nodes

CNCP Role Slave <not used>

AC 800M Time Adaptor Installed Not installed

Other Time Adaptors Not installed Not installed

AfwTime Service Role Server Client

Time Service
Enabled True False
Provider Definition

Time
Synchronization True True
TimeServerHandler Running

Allowed to set time False False

W32Time Startup type Disabled Disabled

Table 13. Time Sync Configuration in Dedicated Domain Controller:

Local Time Source

net time /setsntp:”A.B.C.D A.B.E.F”

SNTP Server addresses
(the addresses of the Controllers that act as SNTP Servers)

Startup type Automatic

W32Time service
Server status Started

NtpServer Enabled = 0
Windows Registry
parameters for
NtpClient Enabled = 1
W32Time
Type NTP (this is set by net time /setsntp)

3BSE034463R5001 99
External Time Source Section 5 Time Synchronization

External Time Source

If the system needs to be synchronized with a global time master, the recommended
method is to use an SNTP server with a GPS receiver.
Connect the SNTP server to the Control Network and configure all AC 800M
controllers to fetch the time via SNTP.
Configure two AC 800M as CNCP Clock Masters to synchronize the connectivity
servers as in the case with Local Time Source. It is possible to use only a few
controllers as SNTP clients and let the others be CNCP slaves.
The best over all accuracy is achieved with one or more High Precision SNTP
Servers connected to each network area. Use at least two servers to improve the
availability. Since these products do not support RNRP one of them shall be
connected to the primary network and the other to the secondary network.
Dedicated Domain Controllers may also synchronize directly from the SNTP
servers. For this traffic to find its way TCP/IP forwarding must be enabled in the
connectivity servers and the SNTP servers need to have the “Default Gateway”
parameter set to the address of a Connectivity Server.

Domain
Client Client Client
Controller

Client/Server Network
AfwTime Service sync
AfwTime Server
AC 800 Connectivity Server
CNCP
Clock Slave SNTP Server

SNTP
Control Network GPS Receiver

CNCP CNCP
Clock Master Clock Slave

SNTP Clients

Figure 38. Using an External Time Source

100 3BSE034463R5001
Section 5 Time Synchronization External Time Source

Configuration of the Different Nodes

Table 14. Time Sync Configuration in Controllers: External Time Source

Controller Type

2 AC 800Ms Other AC 800Ms Other Controllers

SNTP, Client
Time Sync Protocol, Role SNTP, Client CNCP, Slave
CNCP, Master

Parameters

CS CNCP Clock Master Order Number 1,2 0 0

CS Protocol Type SNTP SNTP CNCP

CS Time Set Enabled False False False

CS Synchronization Interval 20 20 <don’t care>

CS SNTP Server Addr 1 A.B.C.D A.B.C.D <empty>

CS SNTP Server Addr 2 A.E.F.G A.E.F.G <empty>

A.B.C.D and A.E.F.G are the addresses of the SNTP servers. One on each network
path.

Table 15. Configuration of the AfwTime Service: External Time Source

Parameters Value

Server Running True

Clients Allowed to set time False

Synchronization Interval (sec.) 20

3BSE034463R5001 101
External Time Source Section 5 Time Synchronization

Table 16. Time Sync Configuration in Clients and Servers: External Time Source

Node Type

Connectivity Servers Other 800xA System Nodes

CNCP Role Slave <not used>

AC 800M Time Adaptor Installed Not installed

Other Time Adaptors Not installed Not installed

AfwTime Service Role Server Client

Time Service
Enabled True False
Provider Definition

Time
Synchronization True True
TimeServerHandler Running

Allowed to set time False False

W32Time Startup type Disabled Disabled

Table 17. Time Sync Configuration in Dedicated Domain Controller:

External Time Source

net time /setsntp:”A.B.C.D A.B.E.F”

SNTP Server addresses
(the addresses of the external SNTP Servers)

Startup type Automatic

W32Time service
Server status Started

NtpServer Enabled = 0
Windows Registry
parameters for
NtpClient Enabled = 1
W32Time
Type NTP (this is set by net time /setsntp)

102 3BSE034463R5001
Section 5 Time Synchronization Windows Time Instead of AfwTime

Windows Time Instead of AfwTime

If it is not important to have a high time synchronization accuracy in the system it is
possible to use the standard settings of Windows Time to synchronize the PCs. This
means that all PCs will fetch the time from the domain controller.
It is still a good idea to use a controller or even an external SNTP server as time
source for the system but the AfwTime service is not needed and must be disabled.
By tuning NTP parameters in the Windows Registry it is possible to achieve a quite
good time synchronization accuracy also with this method.This however gives a
configuration which is a bit tricky to maintain.

Domain
Client Client Client
Controller
SNTP

SNTP Client/Server Network

Connectivity Server
SNTP
SNTP Server

Control Network

CNCP CNCP
Clock Master Clock Slave

SNTP Clients

Figure 39. Using Windows Time to synchronize the PCs

3BSE034463R5001 103
Windows Time Instead of AfwTime Section 5 Time Synchronization

Configuration of the Different Nodes

Table 18. Time Sync Configuration in Controllers: Windows Time Sync

Controller Type

2 AC 800Ms Other AC 800Ms Other Controllers

SNTP, Client
Time Sync Protocol, Role SNTP, Client CNCP, Slave
CNCP, Master

Parameters

CS CNCP Clock Master Order Number 1,2 0 0

CS Protocol Type SNTP SNTP CNCP

CS Time Set Enabled False False False

CS Synchronization Interval 20 20 <don’t care>

CS SNTP Server Addr 1 A.B.C.D A.B.C.D <empty>

CS SNTP Server Addr 2 A.E.F.G A.E.F.G <empty>

A.B.C.D and A.E.F.G are the addresses of the SNTP servers. One on each network
path.

Table 19. Configuration of the AfwTime Service: Windows Time sync

Parameters Value

Server Running False

Clients Allowed to set time False

Synchronization Interval (sec.) <don’t care>

104 3BSE034463R5001
Section 5 Time Synchronization Windows Time Instead of AfwTime

Table 20. Time Sync Configuration in Clients and Servers: Windows Time Sync

Node Type

Connectivity Servers Other 800xA System Nodes

CNCP Role <not used> <not used>

Time Adaptors Not installed Not installed

AfwTime Service Role <not used> <not used>

Time Service
Enabled False False
Provider Definition

Time
Synchronization False False
TimeServerHandler Running

Allowed to set time False False

SNTP Role Client Client

Startup type Enabled Enabled

W32Time
Server status Started Started

Table 21. Time Sync Configuration in Dedicated Domain Controller:

Windows Time sync

net time /setsntp:”A.B.C.D A.B.E.F”

SNTP Server addresses
(the addresses of the external SNTP Servers)

Startup type Automatic

W32Time service
Server status Started

NtpServer Enabled = 1
Windows Registry
parameters for
NtpClient Enabled = 1
W32Time
Type NTP (this is set by net time /setsntp)

3BSE034463R5001 105
Systems with More Than One Control Network Section 5 Time Synchronization

Systems with More Than One Control Network

If a system contains connectivity servers for more than one Control Network, the
best system wide time synchronization accuracy is achieved by using externally
synchronized time sources, for example (S)NTP time servers with GPS receivers.
One of the Control Networks must to be responsible for synchronizing the
Client/Server Network via the connectivity servers.

Domain
Controller Client Client Client
Client Server
Network

Connectivity Server Connectivity Server

External Time source
External Time source Control Network Y
Time Master Network
Control Network X
Controller Controller

Controller Controller

Figure 40. Time Synchronization with more than one Control Network

To reduce the number of time servers it is possible to let controllers in one Control
Network use time servers in another Control Network via routing through the
Connectivity Servers. This gives a lower synchronization accuracy than if only local
servers are used, but with AC 800M controllers synchronizing from good SNTP
servers it can still be better than 1 ms between all controllers in the system.
Time Synchronization configuration in the Connectivity Servers differ between the
different Connect Products:
For 800xA for AC 800M see AC 800M Time Adaptor on page 135.
For 800xA for Advant Master see Advant Master Time Adaptor on page 135.
For 800xA for Harmony see Time Sync with 800xA for Harmony on page 138.
For 800xA for Melody see Time Sync with 800xA for Melody on page 139.

106 3BSE034463R5001
Section 5 Time Synchronization Systems with MB 300 and 800xA for AC 800M

Time Synchronization in the Control Networks that are not acting as time sources
for the Client/Server network also differs between Controller families:
• 800xA for AC 800M, 800xA for Harmony and 800xA for Melody: Use a GPS
clock or similar.
• 800xA for Advant Master: Connect the MB 300 network with an AC 800M
controller with CI855, see Systems with MB 300 and 800xA for AC 800M on
page 107.
It is possible but not recommended to let the Advant Master Connectivity
server synchronize the MB 300 network, see Reverse Synchronization Mode
on page 136.
The Connectivity Servers for these Control Networks may be synchronized from
their own Control Networks or the same way as the rest of the nodes on the Client
Server Network.

Systems with MB 300 and 800xA for AC 800M

If a system contains both a MB 300 network and a Control network with AC 800M
Controllers, it is recommended to use a CI855 in at least one AC 800M so that the
time can be distributed from the Control Network to MB 300 via CI855. The
following description is based on an AC 800M being the time source for the entire
system.
If an external SNTP server is used, the AC 800M controllers must be configured as
in Windows Time Instead of AfwTime on page 103. The other nodes will be
configured in the same way as described below.
In this example the AfwTime Service is used on the Client Server Network,
but the W32Time service may be used as in Local Time Source on page 96.

3BSE034463R5001 107
Systems with MB 300 and 800xA for AC 800M Section 5 Time Synchronization

Domain
Controller Client Client Client
Client Server
Network

Time Server
AfwTime Service sync
Advant Master SNTP
Connectivity
Server Clock Slave
RTA CNCP
Control Network

CI855 AC 800M
MB 300 Clock Sync

MB 300

Advant
Master

Figure 41. Time Synchronization with Both MB 300 and the Control Network

Configuration of the Different Nodes

Table 22. Time Sync Configuration in Controllers: AC 800M to MB 300

Controller Type

One or two AC 800Ms Other Controllers

CNCP, Master
Time Sync Protocol, Role CNCP, Slave
MB 300, Master

Parameters

CS CNCP Clock Master Order Number 1,2 0

CS Protocol Type CNCP (don’t care) CNCP

108 3BSE034463R5001
Section 5 Time Synchronization Systems with MB 300 and 800xA for AC 800M

Table 22. Time Sync Configuration in Controllers: AC 800M to MB 300

Controller Type

One or two AC 800Ms Other Controllers

CS Time Set Enabled True True

CS Synchronization Interval 20 <don’t care>

CS SNTP Server Addr 1 <empty> <empty>

CS SNTP Server Addr 2 <empty> <empty>

Configuration for CI855:

MB 300 Master <not used>
Time Synchronization

Table 23. Configuration of the AfwTime Service: AC 800M to MB 300

Parameters Value

Server Running True

Clients Allowed to set time False

Synchronization Interval (sec.) 20

Table 24. Time Sync Configuration in Advant Master Controllers on MB 300:

AC 800M to MB 300

Parameters on the Clock Synch DB element Value

CLK_MAST 0

LOC_TIME 2

CLK_SEND 0

3BSE034463R5001 109
Systems with MB 300 and 800xA for AC 800M Section 5 Time Synchronization

Table 25. Time Sync Configuration in Clients and Servers: AC 800M to MB 300

Node Type

Advant Master
Other 800xA System
AC800M Connectivity Servers Connectivity
Nodes
Servers

CNCP Role Slave <not used> <not used>

AC 800M Time Adaptor Installed Not installed Not installed

Other Time Adaptors Not installed Not installed Not installed

AfwTime Service Role Server Client Client

Time Service
Enabled True False False
Provider Definition

Time
Synchronization True True True
TimeServerHandler Running

Allowed to set time False False False

MB 300 Clock Synch Role <not used> Slave <not used>

CLK_MAST <not used> 0 <not used>

MB 300 Clock Sync
Config for the Clock
LOC_TIME <not used> 2 <not used>
Synch DB element
on the RTA board
CLK_SEND <not used> 0 <not used>

W32Time Startup type Disabled Disabled Disabled

Table 26. Time Sync Configuration in Dedicated Domain Controller:

AC 800M to MB 300

net time /setsntp:”A.B.C.D A.B.E.F”

SNTP Server addresses
(the addresses of the Controllers that act as SNTP Servers)

Startup type Automatic

W32Time service
Server status Started

NtpServer Enabled = 0
Windows Registry
parameters for
NtpClient Enabled = 1
W32Time
Type NTP (this is set by net time /setsntp)

110 3BSE034463R5001
Section 5 Time Synchronization MB 300 as Time Source for AC 800M

MB 300 as Time Source for AC 800M

For existing systems with Advant Master that are extended with 800xA for
AC 800M it is often a requirement to synchronize the new AC 800M controllers
from the Advant Master Controllers via the CI855. This is also possible.
A draw back (compared to the previous alternative) is that the MB 300 time sync
protocol uses local time and the Advant Master Controllers do not handle Daylight
Savings Time changes. The Advant Master Controller which is time sync master
appoints a RTA board or a CI855 to handle the shifting of Daylight Savings Time.
The following description is based on an AC 400 controller being the time source
for the entire system. That controller may additionally be synchronized with a
minute pulse.
In this type of configuration it is recommended to use AfwTime Service on all
800xA nodes in the Client Server Network. It is necessary at least for the Advant
Master Time Adaptor..

Domain
Controller Client Client Client
Client Server
SNTP
Network
AfwTime Service sync
SNTP Server AfwTime Server AC 800M
Connectivity Server
Advant Master Connectivity Server

RTA
Control Network
CNCP

CI855 AC 800M
MB 300 Clock Sync
MB 300

Daylight Savings Shift

Advant
Master

Figure 42. Time Synchronization with Both MB 300 and the Control Network

3BSE034463R5001 111
MB 300 as Time Source for AC 800M Section 5 Time Synchronization

Configuration of the Different Nodes

Table 27. Configuration in Clock Sync Master on MB 300: only MB 300

Parameters on the Clock Synch DB element Value

CLK_MAST 1

LOC_TIME 2

CLK_SEND 1

Table 28. Time Sync Configuration in AC 800M Controllers: MB 300 to AC 800M

Controller Type

AC 800Ms connected
Other Controllers
to MB 300

CNCP, Master
Time Sync Protocol, Role CNCP, Slave
MB 300, slave

Parameters

CS CNCP Clock Master Order Number 1,2 0

CS Protocol Type MB 300 CNCP

CS Time Set Enabled False False

CS Synchronization Interval 20 <don’t care>

CS SNTP Server Addr 1 <empty> <empty>

CS SNTP Server Addr 2 <empty> <empty>

Configuration for CI855:

MB 300 Slave <not used>
Time Synchronization

Table 29. Configuration of the AfwTime Service: MB 300 to AC 800M

Parameters Value

Server Running True

Clients Allowed to set time False

Synchronization Interval (sec.) 20

112 3BSE034463R5001
Section 5 Time Synchronization MB 300 as Time Source for AC 800M

Table 30. Time Sync Configuration in Clients and Servers: MB 300 to AC 800M

Node Type

Advant Master Connectivity

Other 800xA System Nodes
Servers

Advant Master Time Adaptor Installed Not installed

Other Time Adaptors Not installed Not installed

AfwTime Service Role Server Client

Time Service
Enabled True False
Provider Definition

Time
Synchronization True True
TimeServerHandler Running

Allowed to set time False False

MB 300 Clock Synch Role Slave, DST Master <not used>

CLK_MAST 0 <not used>

MB 300 Clock Sync
Config for the Clock
LOC_TIME 2 <not used>
Synch DB element
on the RTA board
CLK_SEND 1 <not used>

SNTP role Server <not used>

Startup type Automatic Disabled

W32Time
Server status Started Stopped

NtpServer Enabled = 1 <don’t care>

SNTP parameters in
Windows Registry NtpClient Enabled = 0 <don’t care>

Type NoSync <don’t care>

3BSE034463R5001 113
Synchronization from the Client Server Network Section 5 Time Synchronization

Table 31. Time Sync Configuration in Domain Controller: MB 300 to AC 800M

net time /setsntp:”A.B.C.D A.B.E.F”

SNTP Server addresses (the addresses of the Advant Master Connectivity Servers
that act as SNTP Servers)

Startup type Automatic

W32Time service
Server status Started

NtpServer Enabled = 0
Windows Registry
parameters for
NtpClient Enabled = 1
W32Time
Type NTP (this is set by net time /setsntp)

Synchronization from the Client Server Network

With 800xA for AC 800M and 800xA for Advant Master it is possible to
synchronize the clocks in the controllers from the Client Server network through the
connectivity servers. This is normally not the recommended solution. It typically
gives lower accuracy of the clocks in the controllers. In this example the domain
controller is synchronized by an external SNTP server.

Domain SNTP SNTP

Controller Client Client
SNTP Servers
SNTP
Client/Server Network

SNTP Client SNTP Client

Advant Master Connectivity Server AC 800M Connectivity Server

RTA

MB300 Control Network

MB300
Clock Sync CNCP
Advant SNTP
Master Client
CNCP Master CNCP Slaves

Figure 43. Synchronizing from the Client Server Network

114 3BSE034463R5001
Section 5 Time Synchronization Synchronization from the Client Server Network

Configuration of the Different Nodes

Table 32. Time Sync Configuration in Controllers: Reversed Sync

Controller Type

2 AC 800Ms Other Controllers

SNTP, Client
Time Sync Protocol, Role CNCP, Slave
CNCP, Master

Parameters

CS CNCP Clock Master Order Number 1,2 0

CS Protocol Type SNTP CNCP

CS Time Set Enabled False False

CS Synchronization Interval 20 <don’t care>

CS SNTP Server Addr 1 A.B.C.D <empty>

CS SNTP Server Addr 2 A.E.F.G <empty>

Table 33. Time Sync Configuration in Advant Master Controllers on MB 300:

Reversed Sync

Parameters on the Clock Synch DB element Value

CLK_MAST 0

LOC_TIME 2

CLK_SEND 0

A.B.C.D and A.E.F.G are the addresses of the external SNTP servers. One on each
network path.

Table 34. Configuration of the AfwTime Service: Reversed Sync

Parameters Value

Server Running True

Clients Allowed to set time False

Synchronization Interval (sec.) 20

3BSE034463R5001 115
Synchronization from the Client Server Network Section 5 Time Synchronization

Table 35. Time Sync Configuration in Clients and Servers: Reversed Sync

Node Type

AC 800M Advant Master Other 800xA System

Connectivity Servers Connectivity Servers Nodes

CNCP Role <not used> <not used> <not used>

AC400 Time Adaptor Not installed Installed Not installed

Other Time Adaptors Not installed Not installed Not installed

Just executing the

AfwTime Service Role <not used> <not used>
AC400 Time Adaptor

Time Service Provider

Enabled False True False
Definition

Time Synchronization
False False False
Running
TimeServerHandler
Allowed to set time False False False

MB 300 Clock Synch Role <not used> Master <not used>

CLK_MAST <not used> 1 <not used>

MB 300 Clock Sync
Config for the Clock
LOC_TIME <not used> 0 <not used>
Synch DB element on
the RTA board
CLK_SEND <not used> 1 <not used>

REVERSED_SYNC_MODE in Windows Registry <not used> 1 <not used>

SNTP Role Client Client Client

W32Time Startup type Enabled Enabled Enabled

Table 36. Time Sync Configuration in Dedicated Domain Controller:

Reversed Sync

net time /setsntp:”A.B.C.D A.E.F.G”

SNTP Server addresses
(the addresses of the external SNTP Servers)

Startup type Automatic

W32Time service
Server status Started

NtpServer Enabled = 1
Windows Registry
parameters for
NtpClient Enabled = 1
W32Time
Type NTP (this is set by net time /setsntp)

116 3BSE034463R5001
Section 5 Time Synchronization Configure Time Synchronization in Controllers

Configure Time Synchronization in Controllers

Time Synchronization Parameters for AC 800M
Synchronization of the real time clock in an AC 800M controller is configured in
the controller project in the Control Builder. The parameters are located at the
bottom of the Hardware editor window for the CPU unit, e.g. PM860/TP860, see
Figure 44.

Figure 44. Configuration of Time Synchronization for AC 800M

Table 37 describes the parameters.

3BSE034463R5001 117
Time Synchronization Parameters for AC 800M Section 5 Time Synchronization

Table 37. Parameters Defining Clock Synchronization in AC 800M

Parameter Type Value and description

CS CNCP dint CNCP Clock Master order number:

ClockMasterOrderNo 0: This node can not become Clock Master
1: This is primary Clock Master
2: This is secondary Clock Master
3: This is third order Clock Master
n: This is the n' order CNCP Master
Max value is 10.
CS Protocol Type enum The protocol used for receiving clock synchronization:
No Synch: The Controller clock is not synchronized.
CNCP: The Controller clock is synchronized via CNCP.
SNTP: The Controller clock is synchronized via SNTP.
MMS: Sync from MMS Date & Time is allowed.
MB 300: The Controller clock is synchronized from MB 300
via CI855. See Time Synchronization for MB 300
via CI855 on page 119.

CS Time Set Enabled enum False:CNCP Time set from network disabled.
(recommended if an external time source is used)
True: CNCP Time set from network will be accepted.
(see Setting the System Time on page 145)
“Time Setting” is when the time is changed in a large step, typ-
ically manually. Small automatic changes are called “Time
Synchronization”.

CS Synch Interval dint The clock synchronization interval in seconds:

CNCP: The Clock Master transmit interval.
SNTP: The interval for poll of Time Server.
Default value is 20 seconds.
Max value is 240 seconds (4 minutes).

CS SNTP ServerAddr1 string IP-addresses to alternative SNTP Servers

CS SNTP ServerAddr2 If the first entry is zero, no SNTP time requests will be sent.

118 3BSE034463R5001
Section 5 Time Synchronization Time Synchronization for MB 300 via CI855

AC 800M can distribute time via all its supported protocols simultaneously, but it
only receives time synchronization via the protocol defined by “CS Protocol Type”.
The sending is enabled per protocol:
• The parameter CS CNCP ClockMasterOrderNo controls sending with CNCP.
If the parameter is zero the node will not send time with CNCP.
• AC 800M can act as SNTP server. This function is always enabled. The
communication initiative lies on the clients so there is no parameter for this.
• The parameter “Time sync” on CI855 controls if CI855 will send time sync on
MB 300.

Time Synchronization for MB 300 via CI855

AC 800M can use the communication module CI855 for time synchronization to or
from the MB 300. This is configured with the “Time sync” parameter on the CI855
in the controller project in Control Builder, see Figure 45.

Figure 45. Configuration of MB 300 Time Synchronization via CI855

3BSE034463R5001 119
Time Synchronization in Advant Master Controllers Section 5 Time Synchronization

The Time synchronization parameter on CI855 can be set up according to Table 38

below.

Table 38. Parameters for Defining Time Synchronization of CI855 in AC 800M

Parameter Type Value and description

Time sync Enum No Time-sync: CI855 is not synchronized.

AC 800M Local: CI855 is synchronized from the AC 800M.
MB 300 Master: CI855 is synchronized from the AC 800M
and acts as a clock sync master on the
MB 300 network.
MB 300 Slave: CI855 is synchronized from the MB 300
network and synchronizes the AC 800M.
(Set also CS Protocol Type = MB 300)

CI855 is the only node type on MB 300 that has both a high accuracy of its local
clock, good support for daylight saving time and a possibility to use an external
time source. Therefore, it is recommended that the CI855 is set up as “MB 300
Master” on the MB 300 network rather than being used as “MB 300 Slave”.

Time Synchronization in Advant Master Controllers

The time synchronization of an Advant Master controller is configured by the
Database Element CLOCK_SYNCH, just like it is done on the RTA board (see
Time Synchronization on the RTA Board on page 136).

CNCP - Control Network Clock Protocol

CNCP is an ABB proprietary master-slave clock synchronization protocol for the
Control Network.
CNCP uses RNRP functionality so RNRP must be configured (implicit or
explicit) in a node that uses CNCP.
The CNCP Clock Master periodically sends time updates to the clock slaves with
multicast messages.

120 3BSE034463R5001
Section 5 Time Synchronization CNCP - Control Network Clock Protocol

One or several nodes can act as a backup Clock Master. This means that if the
current Clock Master is lost, one or several other nodes are prepared to take over as
Clock Synchronization Master. To become a backup Clock Master the nodes must
be configured for that role. While a node is Clock Master backup it acts as Clock
slave and receives time from the active Clock Master.
AC 800M can act as CNCP Clock Master (and as Clock Master backup).
AC 800M and Connectivity Servers with 800xA for AC 800M with the option
AC 800M Time Adaptor installed can act as CNCP Clock Slaves.
Figure 46 shows the node types that can be synchronized with CNCP and their
relative time accuracy.

800xA System
with ~200ms
AC 800M Time AC 800M
Control Network

<= 1ms
AC 800M

Figure 46. Time Synchronization with CNCP

Time Synchronization Parameters for AC 800M on page 117 describes how to

configure CNCP in a controller. AC 800M Time Adaptor on page 135 describes
how CNCP is used in a PC.
The CNCP messages are received by all CNCP Slaves on the same Network Area
as the master independent of which Aspect Directory the nodes belong to.
If two 800xA systems are running on the same network the planning of clock
Synchronization with CNCP must be done considering both 800xA systems.
When CNCP is used on a redundant network the messages are sent on both paths.
If the backup path is working the messages are taken from this path. The reason is
that the amount of traffic is lower on the backup path and this typically gives a
better accuracy.

3BSE034463R5001 121
Forwarding of CNCP Between Network Areas Section 5 Time Synchronization

Forwarding of CNCP Between Network Areas

Since CNCP messages uses multicast, the messages are normally not routed
between network areas. Standard network routers can be configured to forward
multicast but this is not recommended in a system using RNRP and/or CNCP.
An AC 800M controller connected to two different non-redundant network areas
can forward CNCP time synchronization between the areas.

SNTP - Simple Network Time Protocol

SNTP is a standard client server oriented time synchronization protocol. It is
described in the Internet RFC-2030. The SNTP time clients periodically request
time updates from the time server.
SNTP can be used to fetch time from an external time source.
SNTP is a subset of the more advanced NTP (Network Time Protocol) which is
described in RFC-1305. The message formats are the same in NTP and SNTP. This
means that an SNTP client can use an NTP server.

SNTP Implementations
There are special SNTP implementations that compensate for most known delays
(internal and on the network) in the transmission of the time messages from the
source to the destination. This can give an accuracy down to +/- 1 microseconds.
The SNTP client implementation in the AC 800M handles some of the known
delays. With good SNTP servers, AC 800M can be synchronized with an accuracy
better than +/-500 microseconds for nodes connected to the same switch.
The best accuracy is normally achieved with SNTP server usually receives globally
synchronized time via a GPS receiver.
The AC 800M controller includes an SNTP server which is always enabled. This
server does however not give a very high accuracy.

122 3BSE034463R5001
Section 5 Time Synchronization Stratum

The Windows Time Service (see Windows Time Service (W32Time) on page 139)
in Windows Server 2003 and Windows XP implements the complete NTP with
client and server functionality.

PC
~1000 ms ~1000 ms (routed)
Client Server Network

~1000 ms (routed) GPS

SNTP
PC receiver
Server
~200ms
Control Network
<= 1ms
~200ms
<= 1ms
AC 800M AC 800M

Figure 47. Time Synchronization with SNTP

Stratum
Nodes using SNTP are classified with the term Stratum. Stratum is a value that tells
the number of intermediate time servers from an independent global reference time
source. An atomic clock is at stratum 0. A time server receiving its time from a
stratum 0 source gets stratum 1. An SNTP server with a GPS receiver normally has
stratum 1. When AC 800M fetches time with SNTP it informs in the controller log
about the stratum of its SNTP server. The stratum of the server does not necessarily
say how accurate the clock in the client will be. For example if the transportation
delay between the client and the server varies much the accuracy may be bad even if
the server has a low stratum and is very accurate. Fault Tracing Time
Synchronization Problems on page 151 describes more about how to check the
clock accuracy in different nodes.

SNTP Servers on a Redundant Network

If a redundant network is used the SNTP servers must be duplicated so that there is
at least one on each network path i.e. if the SNTP server does not support RNRP.

3BSE034463R5001 123
Routing SNTP Traffic Section 5 Time Synchronization

Routing SNTP Traffic

It is possible to route SNTP communication via an IP router, e.g. a Connectivity
Server. This will lead to a lower accuracy than if the Client and the Server are
located on the same subnet. This method is recommended for Domain Controllers
that do not run the AfwTime Service.
Nodes running RNRP are able to communicate through RNRP routers, as for
example the Connectivity Servers, without any special configuration. To enable an
SNTP server that does not run RNRP to communicate through an RNRP router the
routing capability needs to be configured in the SNTP server. The simplest method
is normally to set the parameter for default gateway in the SNTP server to the
Control Network address of the Connectivity Server. Note that this must be the
address on the network path where the SNTP server is connected, i.e. in the case of
an SNTP server connected to the secondary Control Network, it must be the
Secondary Control Network address for the Connectivity Server.
Read also about the parameter Enable TCP/IP Forwarding in Table 7, RNRP
Configuration Parameters on page 56.

Configuring SNTP
Time Synchronization Parameters for AC 800M on page 117 describes how to
configure SNTP in a controller.
Windows Time Service (W32Time) on page 139, Enable the SNTP Server, Disable
SNTP Client in a PC on page 142 and Configure Time Synchronization in a
Dedicated Domain Controller on page 143 describe how to configure SNTP in a PC.
See also Fault Tracing SNTP on page 153.

MB 300 Time Synchronization

The time synchronization protocol used on MB 300 is a master slave protocol
providing an accuracy better than 3 milliseconds. The protocol is used when time is
distributed between 800xA and legacy products in the ABB Master family.
Nodes supporting the MB 300 time protocol are:
• AC 400 Connectivity server via the RTA board PU510

124 3BSE034463R5001
Section 5 Time Synchronization MB 300 Time Synchronization

• AC 800M via CI855

• AC 400 Master, MasterPiece 200, Advant Station 500 OS, MasterGate, etc.
It is recommended to use the CI855 as Clock Master wherever possible. There are
two advantages with using the CI855:
• CI855 can distribute time which has been externally synchronized with a high
accuracy. This is because CI855 is used in the AC 800M and AC 800M can be
synchronized from a high precision SNTP server.
• the CI855 can handle daylight saving shifts.
If CI855 can not be used, it is recommended to use an AC 400 Master controller as
Clock Master and to run with a local time source.
In this case the RTA board in the AC 400 connectivity server will act as daylight
saving master. This is automatically configured.
An AC 800M using 2 CI855s may forward time synchronization from one MB 300
network to the other. One CI855 is time sync slave on its network, the controller
receives the time from that CI855 and the other CI855 is time sync master on its
network. This is how you configure the AC 800M if it is used as a replacement of
the Master Gate 230/1.

Advant Master
Connectivity
Server
RTA CI855 CI855 AC 800M

3 ms 10 ms
MB 300

AC400 AC400 AC400

Figure 48. Time Synchronization on MB 300

Time Synchronization for MB 300 via CI855 on page 119,

Time Synchronization in Advant Master Controllers on page 120,
Advant Master Time Adaptor on page 135 and Time Synchronization on the RTA
Board on page 136 describe how to configure MB 300 time synchronization.

3BSE034463R5001 125
MMS Time Synchronization Section 5 Time Synchronization

MMS Time Synchronization

It is possible to set the clock in the AC 800M Controllers and in Panel 800 via
MMS. This gives an accuracy between nodes of about 200 ms. The time can be sent
from:
• The OPC Server for AC 800M
• Another AC 800M Controller
For Panel 800 MMS is the only supported time sync protocol but the MMS time
synchronization should normally not be used for controllers. CNCP and SNTP
provide better accuracy.

AfwTime Service
The AfwTime Service can be used to synchronize the time on the server and client
nodes defined in a system. This service can also be used to change the current time
in the system.
The Time Service has two components, a Time Server and a Time Client.
• Time Server (Service Provider)
The Time Server component is the administrator of the time synchronization. It
receives and distributes the time synchronization telegrams to/from other
nodes, and it makes the final decision on which telegram to accept and
broadcast to the network.
The Time Server should be active in the Connectivity Servers. By default the
Time Server is installed on all System Product server nodes. There must be at
least one Time Server enabled in the network for the Time Service to be
operational. If more than one node is configured as a Time Server, only one of
the nodes will be active (in Service State), the other nodes will be passive
(in Standby State).
• Time Client (Service Handler)
A Time Client is responsible for keeping the date and time in its node updated
and synchronized with the global time broadcast from the Time Server.
It is also responsible for allowing or disallowing manual setting of date and

126 3BSE034463R5001
Section 5 Time Synchronization AfwTime Service

time, according to how it is configured. A Time Client resides in all 800xA

System nodes.

Time Client Time Client Time Client

Client/Server
Time Set Network
Time Server Time Server
Time Sync (Service state) (Standby state)

Figure 49. The AfwTime Service

The accuracy achieved is better than 1 second. The operation of the AfwTime
Service in a complete system is configured on four types of Aspect Objects:
• The Time Service
• The Time Service Providers
• The Time Server Group
• The Time Service Handlers
The configuration parameters on these different objects are described in the
following sections. See also Fault Tracing AfwTime on page 153.

3BSE034463R5001 127
Configuration of the AfwTime Service Section 5 Time Synchronization

Configuration of the AfwTime Service

The Service Definition Aspect for the Time Service Object contains Special
Configuration parameters that control the operation of all Time Servers (Service
Providers) in the system, see Figure 50.

Figure 50. Time Service Definition Configuration Dialog

Table 39 describes the parameters for the Time Service.

128 3BSE034463R5001
Section 5 Time Synchronization Configuration of the AfwTime Service

Table 39. Parameters for Special Server Configuration

Parameter Description
Server running Determines whether the Time Server service must run.
If FALSE, no AfwTime server will distribute time and no AfwTime
Adaptor will operate.
Default value: TRUE
Clients allowed Determines whether users at client nodes are allowed to set the
to set time system time, i.e. the clock on the Time Server node.
Default value: FALSE
If this parameter is TRUE and the corresponding parameter on the
Time Server Handler aspect on the Node object the Time Server will
change its time if the windows time is changed on a client node.
If FALSE, the engineer can only change the system time when working
on the Time Server node.
This parameter actually decides if the Time Server will accept a time
set message sent from a client. The corresponding parameter on the
Time Server Handler aspect on the node object prevents the client
node from sending the time set message.
Set this parameter to FALSE if the system uses an external time
source, e.g. a GPS receiver with an SNTP server on the Control
Network.
Section Setting the System Time on page 145 describes different
methods to set the system time. One way is to set this parameter to
TRUE and to use windows time to adjust the system time.
Sync Interval This value determines how often synchronization messages are sent to
(sec.) the Time Clients.
Default value: 10 sec.

There are additional parameters in the tab Special Configuration for the Time
Service Definition that can be used if the Time Server must fetch the time from an
external time master. This configures external time synchronization using
NetRemoteTOD, which is supported at least by Windows based nodes. Receiving
the time from a Time Adaptor however typically gives better accuracy.

3BSE034463R5001 129
Configuring the AfwTime Server and the Server Group Section 5 Time Synchronization

Configuring the AfwTime Server and the Server Group

The main configuration of the Time Servers is done in the Service Definition.
The only item to configure on each Time Server Node is whether the service should
run or not, see Figure 51.. By default the Time Server is enabled in all Server nodes.

Figure 51. Enabling the AfwTime Server

The Time Server can get the time from a Time Adaptor, see Time Synchronization
for Connectivity Servers, Time Adaptors on page 134. If you want to use a Time
Adaptor for receiving or sending time, the Time Server must be enabled.
If there is no time adaptor installed, the Time Server will take the time from the
local Windows Time.
The operation of the Time Server depends on its state. In Service state the Time
Server distributes time to all AfwTime Clients.
When adding a Time Server to the system, the Time Service provider is
automatically added to a service group (the Time Server Group) in the service
structure.

130 3BSE034463R5001
Section 5 Time Synchronization Configuring the AfwTime Server and the Server Group

The order of the servers in the Server Group list decides the priority between the
servers. The server at the top of the list will become active and the others will be in
a standby state. If the first in the list does not work the next one will take over. The
system creates a default order in the list, but the order can be changed manually, see
Figure 52.
By default the Time Server is enabled in all Server nodes. Make sure it only runs in
the appropriate nodes. If for example a redundant connectivity server pair are the
only servers that can receive time from a control network the Time Server should be
disabled in all other nodes.

Figure 52. Configuring the priorities for the Time Servers

3BSE034463R5001 131
Configuring an AfwTime Client Section 5 Time Synchronization

Configuring an AfwTime Client

The configuration of reception of time synchronization in an 800xA node is done on
the TimeServerHandler aspect for the Node object in the Node Administration
structure, see Figure 53.

Figure 53. Configuration of the AfwTime Client (Time Server Handler)

Table 40 describes the parameters for the TimeServerHandler.

132 3BSE034463R5001
Section 5 Time Synchronization Configuring an AfwTime Client

Table 40. Configuration parameters for the TimeServerHandler

Parameter Description
Allowed to Set Time Determines whether a user on this node can set the
system time by adjusting the windows time. Section
Setting the Time for the AfwTime Service on page 148
describes this.
Default value: TRUE
If the parameter is FALSE, or if the corresponding
parameter for the Service Definition is FALSE, a time
adjustment in such a node is only executed in the PC
where it was done. If that PC is synchronized with some
other protocol the change will be over-written the next
time the PC is synchronized.
Time Synch Running Determines whether the node will react when the Server
sends time synchronization messages.
If FALSE, the Workplace’s clock will not be synchronized
with the Time Server’s clock.
Default value: TRUE
Deviation Limit This value sets the limit for how much the node’s time is
allowed to differ from the Time Server’s time before a
correction is made.
Default value: 1000 msec.
The default value may be used.
(Value 0 = No synchronization, the Time Synch is
disabled.)

3BSE034463R5001 133
Time Synchronization for Connectivity Servers, Time Adaptors Section 5 Time Synchronization

Time Synchronization for Connectivity Servers, Time

Adaptors
The AfwTime Server receives time synchronization with so called Time Adaptors.
There are Time Adaptors for different protocols, for example for CNCP and
MB 300. See AC 800M Time Adaptor on page 135 and Advant Master Time
Adaptor on page 135.
Only one Time Adaptor may be active and synchronizing the AfwTime Server.
Since it is not possible to configure which adaptor the Time Server will use,
it is recommended to only have one Adaptor installed (or at least only one active)
in a PC that will act as AfwTime Server.

Client Client Client

Client/Server
Time Server Network

Time Adaptor
Clock Slave

Control Network

Clock Master

Figure 54. Time Adaptor for the AfwTime Service

A Time Adaptor only works if the Time Service is enabled in the node.
This is a requirement for both receiving and sending of time via a Time Adaptor.

134 3BSE034463R5001
Section 5 Time Synchronization AC 800M Time Adaptor

AC 800M Time Adaptor

800xA for AC 800M includes the optional AC 800M Time Adaptor that can receive
time with CNCP from the Control Network and synchronize the AfwTime Service.
If the time is changed manually in Process Portal, the Adaptor sends a CNCP
message to set the new time. This simultaneously sets the new time in all nodes on
the control network. See also Setting the System Time on page 145.
The AC 800M Time Adaptor is installed together with 800xA for AC 800M as
follows:
• A typical installation always installs the Time Adaptor
• A custom installation installs the adaptor as optional, default setting is Yes
The AC 800M Time Adaptor is not configurable, so if it is desired not to
synchronize the AfwTime Server from CNCP, the Time Adaptor must not be
installed in the PC or the Time Server must be disabled.
800xA for AC 800M also includes the OPC server for AC 800M that supports time
synchronization via MMS. Disable this feature when CNCP is used.
An AC 800 M Connectivity Server can not synchronize the Control Network from
the Client Server network with CNCP. If it is desired to synchronize the nodes on
the Control Network from the Client Server network, a node on the Control
Network must use SNTP to fetch the time from a Connectivity Server.
This is however, not a recommended synchronization scheme since it typically
gives bad accuracy.

Advant Master Time Adaptor

800xA for Advant Master includes a Time Adaptor that can forward time between
the RTA board and the AfwTime Service. The default configuration is that the RTA
board receives the time from MB 300, the Adaptor reads the time from the RTA
board and updates the AfwTime Service.
If the time is changed manually in the Advant Master Connectivity Server and at
local time shifts, e.g. daylight saving shift, the Adaptor sends the time to the RTA
board which will propagate this to MB 300 to set the new reference time in the
system.

3BSE034463R5001 135
Time Synchronization on the RTA Board Section 5 Time Synchronization

Reverse Synchronization Mode

The Advant Master Time Adaptor can be reconfigured to transfer time from the
AfwTime Service to the RTA board. This is done with the parameter
REVERSED_SYNC_MODE in the Windows Registry. The instruction IndustrialIT
800xA, System, 800xA for Advant Master, Configuration (3BSE030340Rxxxx)
describes how to find and modify this parameter. This synchronization direction,
however, is not recommended since it gives worse time accuracy to let a PC clock
synchronize a controller clock than the other direction. When using reversed
synchronization the RTA board should be configured with and CLK_MAST=1,
LOC_TIME=0, CLK_SEND=1.

Deactivating Time Synchronization via the Advant Master Time Adaptor

If the Advant Master Time Adaptor should not be used, it can be deactivated by
modifying a parameter in the windows registry. This is described in IndustrialIT
800xA, System, 800xA for Advant Master, Configuration (3BSE030340Rxxxx).
The preferred method is to deactivate the time functionality on the RTA board by
setting CLK_SEND=0 and CLK_MAST=0,
see Time Synchronization on the RTA Board on page 136.

Time Synchronization on the RTA Board

The AC 400 Connect uses the RTA board to communicate on MB 300.
The RTA board has the following time synchronization functions:
• Clock Synchronization master on MB 300
• Clock Synchronization slave on MB 300
• Daylight saving time master on MB 300
(This is not configured explicitly)
The time synchronization functionality of the RTA board is controlled by the
database element CLOCK_SYNCH. It has the following parameters:
• CLK_MAST
• LOC_TIME
• CLK_SEND

136 3BSE034463R5001
Section 5 Time Synchronization Time Synchronization on the RTA Board

The exact definition of the CLOCK_SYNCH database element can be found in the
Master Net Manual. The most common combinations are the following:

Table 41. Time Synchronization Configuration for AC 400 Connectivity Server

TIME SOURCE CLK MAST LOC TIME CLK SEND AfwTime REVERSED
Service SYNC_MODE

AC 800M with CI855 as time source 0 2 0 Client on 0

for MB 300, (see Systems with MB Server off
300 and 800xA for AC 800M on page
107)
(RTA only receives the time for its
own use)
RTA board as time source in the 1 2 1/3 Client on 0
whole system Server on
AC 400 as time source in the whole 0 2 1 Client on 0
system, Server on
RTA as Daylight Saving Time Master
(to be used if AC 400 receives
external time via minute pulse)
SNTP(W32Time) on the Client 1 0 1 Server on 1
Server network (see Synchronization
from the Client Server Network on
page 114)

The Time Service column indicates how the AfwTime Service in

the AC 400 Connectivity Server must be used in the different alternatives.
When using an AC 400 Connectivity server as time source for the Client Server
Network, the AC 800M Time Adaptor must NOT be installed on that node.

The instruction IndustrialIT 800xA, System, 800xA for Advant Master,

Configuration (3BSE030340Rxxxx) describes how the Clock Synchronization
parameters on the RTA board are modified.

3BSE034463R5001 137
Time Sync with 800xA for Harmony Section 5 Time Synchronization

Time Sync with 800xA for Harmony

A Connectivity Server with 800xA for Harmony can receive time from the
Harmony Control network and update the local Windows time in the Connectivity
Server. A redundant pair of Harmony Connectivity Servers synchronize each other
via TSP (=Time Sync Protocol) over the Client Server Network.
The TSP protocol only runs on one network. It does not utilize the RNRP
network redundancy on the Client Server network. If the used network path
breaks the synchronization stops. Consider this when planning the network
connection between the Harmony Connectivity Servers.
To secure the TSP traffic between the Connectivity Servers other ethernet
redundancy solutions could be used. The availability of the network path that
TSP uses could for example be improved by using ring redundancy or Rapid
Spanning Tree, see Physical Network Installation on page 177.
If a Harmony Connectivity Server is responsible for synchronizing the Client Server
network, the AfwTime Server and/or the W32Time SNTP server must be used (see
Configuring the AfwTime Server and the Server Group on page 130 and Enable the
SNTP Server, Disable SNTP Client in a PC on page 142). No Time Adaptors should
be installed in the Harmony Connectivity Servers. Configure the AfwTime service
as follows:
• Enable the Time Service Providers in the Harmony Connectivity Servers.
(See Configuring the AfwTime Server and the Server Group on page 130)
• Disable the Time Service Providers in all other 800xA nodes.
• Uncheck “Time Sync Running” for the Harmony Connectivity Servers.
(See Configuring an AfwTime Client on page 132)
• Uncheck “Allowed to set time” for all 800xA nodes.
A Harmony Connectivity Server can act as time source for both the Harmony
system and the Client Server network.
If a Harmony Connectivity Server is not responsible for synchronizing the Client
Server network, it is possible to synchronize it with either the Harmony Control
network or with the Client Server network. In the first case the AfwTime Server
must be turned off in the node and in the latter case the Connectivity Server must be
configured not to synchronize with the Harmony Control network.

138 3BSE034463R5001
Section 5 Time Synchronization Time Sync with 800xA for Melody

For more information about how to configure Time Sync with 800xA for Harmony
see IndustrialIT 800xA, System, 800xA for Harmony, Configuration
(3BUA000157Rxxxx).

Time Sync with 800xA for Melody

A Connectivity Server running 800xA for Melody can receive time from the
Melody O-Net and update the local Windows time in the Connectivity Server. A
redundant pair of Melody Connectivity Servers synchronize each other via the TSP
(=Time Sync Protocol) protocol via the Client Server Network.
The TSP protocol does not use any network redundancy. The caution note in
Time Sync with 800xA for Harmony on page 138 is valid also for 800xA with
Melody.
If a Melody Connectivity Server is responsible for synchronizing the Client Server
network, the AfwTime Server and/or the W32Time SNTP server must be used (see
Configuring the AfwTime Server and the Server Group on page 130 and Enable the
SNTP Server, Disable SNTP Client in a PC on page 142). No Time Adaptors should
be installed in the Connectivity Servers.
If a Melody Connectivity Server is not responsible for synchronizing the Client
Server network, the AfwTime Server must be disabled in the node. The
Connectivity Servers itself still needs to be synchronized from the Melody O-Net.
A Melody Connectivity Server only synchronizes from the Melody O-Net to the
Client Server network. Not in the other direction. For more information about how
to configure Time Sync with 800xA for Melody see IndustrialIT 800xA, System,
800xA for Melody, Configuration (3BDD011741Rxxxx).

Windows Time Service (W32Time)

Windows Server 2003 and Windows XP supports its own native time
synchronization service W32Time. W32Time uses the Network Time Protocol
(NTP). The standard configuration for W32Time is that the time is distributed from
the domain controller to the member nodes in the domain; one of the Domain
Controllers act as NTP server and the other nodes act as NTP clients.
Normally W32Time must be disabled in all nodes that use the AfwTime Service.
The exception is when a Connectivity Server is used as SNTP server for the Domain

3BSE034463R5001 139
Disable/Enable the Windows Time Service Section 5 Time Synchronization

Controller. This is described in Enable the SNTP Server, Disable SNTP Client in a
PC on page 142.
In Windows XP and Windows Server 2003 W32Time is a complete NTP
implementation. It is described in for example in the Microsoft Technet article
“Windows Time Service Technical Reference“. It can be found by searching for
the article name at http://technet.microsoft.com.

Disable/Enable the Windows Time Service

Normally the Windows Time Service must be disabled in all nodes that use the
AfwTime Service. The exception a node that acts as SNTP server, see Enable the
SNTP Server, Disable SNTP Client in a PC on page 142.
Starting, stopping, enabling and disabling Windows Time Service is done in
Windows Services. Set startup type to Disabled if the Windows Time is not to be
used.

Figure 55. The Windows Time Service in the Services Window

140 3BSE034463R5001
Section 5 Time Synchronization Configuring Time Zone and Daylight Saving Time Support

If the goal is to make it possible to synchronize a PC with some other method than
Windows Time, an alternative to disabling the Windows Time service is to let it run
but to disable the NtpClient function. This is done by setting the value of Enabled =
0 in the Windows Registry system key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
W32Time\TimeProviders\NtpClient].
This has the advantage that the NtpServer function can still be used. The NtpServer
for example needs to run to make it possible to check time differences between
nodes with w32tm /monitor or other tools. See more in Fault Tracing SNTP on page
153.

Configuring Time Zone and Daylight Saving Time Support

Each PC must be configured for the correct time zone and support for Daylight
Saving time for time presentations. This is done with the Windows Date and Time
Properties window which can be started from the task bar, see Figure 56.,

Figure 56. Windows Date and Time Dialog Box

This allows the correct presentation of all times stamps in local time.

3BSE034463R5001 141
Enable the SNTP Server, Disable SNTP Client in a PC Section 5 Time Synchronization

All historic data such as Alarms, Events and History data are stored according to
UTC time stamps, so their sorting will not be affected, just the presentation will be
shown in local time.

Enable the SNTP Server, Disable SNTP Client in a PC

If a PC, which is not a Domain Controller, will be used as an SNTP server and this
PC is synchronized with other means than w32time (i.e. not with SNTP), the
following settings must be made on that PC:
1. Open the Windows Registry via the Start menu > Run, type regedit.
2. Go to the System Key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
W32Time\TimeProviders\NtpServer]
3. Check that the value of Enabled is 1. Set it if it is 0.
4. Go to the neighbouring System Key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
W32Time\TimeProviders\NtpClient]
5. Set the value of Enabled to 0 to disable the NTP client function.
6. Go to the neighbouring System Key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
W32Time\Config]
7. Set the value of AnnounceFlags to 5 to set the NTP server as
"authoritative".
Independent of which of the above sequences that was used, restart W32Time by the
following commands at the command prompt:
C:\>net stop w32time
C:\>net start w32time
or restart it from Windows Service Manager,
(see Disable/Enable the Windows Time Service on page 140).

142 3BSE034463R5001
Section 5 Time Synchronization Configure Time Synchronization in a Dedicated Domain Controller

Configure Time Synchronization in a Dedicated Domain Controller

If the Domain Controller is running in a node that does not run any 800xA software,
verify that the clock in the domain controller is nearly the same as in the rest of the
system. If the time in a node differs more than 5 minutes from the time in the
domain controller that node will not be accepted by the domain controller.
One way of synchronizing a Domain Controller that does not run the AfwTime
Service is as follows:
• Install an SNTP server on the same subnet as the Domain Controller or
reconfigure the Windows Time Service on one of the nodes that is
synchronized from the Control Network system so that it acts as an SNTP
server but not as SNTP client (see Enable the SNTP Server, Disable SNTP
Client in a PC on page 142).
• Reconfigure the Windows Time Service in the Domain controller so that it
fetches the time from the SNTP server.
To configure a Domain Controller to fetch the time from a specific SNTP server do
the following:
1. Start a Windows Command Prompt on the Domain Controller.
2. Stop W32Time and reconfigure it by the following commands:
C:\>net stop w32time
C:\>net time /setsntp:“A.B.C.D“
A.B.C.D is the IP address of the appointed SNTP server. If more than one
SNTP server is to be used in order to get server redundancy, type the addresses
separated with blank space(s): “A.B.C.D E.F.G.H“.
(There are notes saying that it does not work with more than one server
address, but it does with the Windows versions used for the 800xA system.)
3. Restart W32Time:
C:\>net start w32time
4. Request Windows time to resynchronize once to verify that it works:
C:\>w32tm /resync
This should give the printout This command completed successfully
Check that there are no error messages from w32Time in the System Log in the
Event Viewer in Administrative Tools.

3BSE034463R5001 143
Comparison Between W32Time and the AfwTime Service Section 5 Time Synchronization

Comparison Between W32Time and the AfwTime Service

This section describes some pros and cons with the Windows Time Service
compared to the AfwTime Service for synchronization of 800xA nodes.
The initial configuration effort is typically smaller if W32Time is used
In a standard installation of Windows the default configuration of Windows is that
W32Time is used. The default configuration of AfwTime is that the AfwTime
Servers are enabled in all servers.
• To use W32Time, disable the AfwTime servers. This is easily done from one
node.
• To use AfwTime, disable W32Time in all 800xA nodes. This has to be done on
each node. To use the AfwTime service determine which node(s) to use as
Time Server(s). For some cases Time Adaptors needs to be installed. The
AfwTime Service objects need to be configured accordingly.
With both methods the Domain Controller anyway needs to be configured to fetch
the time from some time source with NTP/SNTP.
It is easier to supervise the operation of AfwTime
• There is no centralized tool to check that W32Time works properly.
• All configuration and operation of AfwTime in all nodes can be done from one
(any) 800xA node.
There are tools that can be used for supervision of W32Time, but these are not
included in the 800xA system offering.
In a system where time changes need to be easily handled it is recommended to use
AfwTime.
Time sync via an Advant Master Connectivity Server needs AfwTime
It is only possible to distribute time via an Advant Master Connectivity Server if the
AfwTime Server is running in the node. It is possible to synchronize through the
other connectivity server types without using AfwTime.

144 3BSE034463R5001
Section 5 Time Synchronization Tuning the Synchronization Rate for W32Time

Tuning the Synchronization Rate for W32Time

It is possible to change the time between time update requests from the a Windows
NTP client in Windows XP and Windows Server 2003. This is done by modifying
the windows registry parameter SpecialPollInterval which is located in
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\
TimeProviders\NtpClient].
To enable usage of SpecialPollInterval the parameter NtpServer in
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\
Parameters] needs to be set to an host address followed by the option value 1:
172.16.5.245,0x1. The default value is time.microsoft.com,0x1.

Setting the System Time

If a controller is used as time source for the entire system (see Local Time Source on
page 96, Local Time Source on page 96 and Synchronization from the Client Server
Network on page 114), it is recommended that all manual time settings are done by
one of these methods:
1. If there is a Control Builder M with direct connection to the Control Network,
the best method to set the time is via the Time Set function in Control Builder.
This sets the time in all controllers on the Control Network simultaneously.
2. Set the time for AfwTime Service on the Connectivity server that is connected
to the same Control Network (or MB 300) as the controller that is time source
for the system.
This is the generally the recommended method for systems with both 800xA
for AC 800M and 800xA for Advant Master.
3. Use the function block SetDT in the controller which is clock master.
4. For systems that are synchronized from the Harmony Control Network or the
Melody Control Network, the corresponding manuals for the Connect products
describe how to set the time.
If an external time source is used, the time should not be set manually. The only
exception is during configuration of the system, before the connection to the
external time source is working.The time must be reasonably well synchronized
in all PCs so that they are not thrown out of the Domain (see Time
Synchronization in a Domain on page 78).

3BSE034463R5001 145
Setting the System Time Section 5 Time Synchronization

Be careful when changing the system time. Try not to do it when the process is
running.
Different functions in the system may behave strangely. Listed below are some
examples. There may be others, which are difficult to predict, at least if the time
change is large:
• If the time is set backwards the Sequence of Events in Alarm and Event lists
may become corrupt. A new event may get an “older” time stamp than an
prior events.
You may get similar problems with trend logs. The logs will look strange
since there will be two sets of log points for the time that corresponds to the
time change.
• If the time is set forward, with a large difference, while the History server is
creating logs, the load on the server may increase drastically because it may
interpolate log points corresponding to the time jump.
What to regard as a large difference depends on the number of logs and their
max time, i.e. the time between interpolated points.
If you for example have 10000 logs with a max time of 10 minutes and
make a time change of 100 minutes the History Server needs to create
10000*100/10=100000 log points. In a normally loaded systems such a
burst with more than a couple thousand points may cause problems.
The recommended way to handle a big time change is to disable all active
logs first and erase the History files in the directory “Operate IT
Data/History”.
• Any substantial time change may cause strange behaviors in active batch
processes. What to regard as a big change depends on the timing in the
batch process. Stop all active batch processes first if you need to make a big
time change.
• If the time is changed in a PC and its domain controller at different times
there may be problems logging in. Changes of less than 5 minutes are
normally OK, see Time Synchronization in a Domain on page 78.
The following sections describe how to set the time for the AfwTime Service and
how to set the time with Control Builder M.

146 3BSE034463R5001
Section 5 Time Synchronization Setting the Time with the Control Builder M

Setting the Time with the Control Builder M

With the Time Set function in the Control Builder M a Set-Time message can be
sent with CNCP. The message will be received by all nodes that run CNCP.
The Set-Time message will take effect if the parameter CS Time Set Enabled is
set to TRUE.
Since the Time Set function sends the Set-Time message to all Controllers at the
same time this is the recommended method to use in all systems where it is
possible.
The Time Set function can only be used to set the time in the AC 800M
controllers if the Control Builder is connected to the Control Network with no
routers between itself and the controllers to be synchronized. If this is not the
case the best method is to use do as in Setting the Time for the AfwTime Service
on page 148.
1. Open Tools > Maintenance > Clock Synch > Time Set.

Figure 57. Time Set Dialog in the Control Builder M

2. Enter the new local time to set.

3. Click OK.

3BSE034463R5001 147
Setting the Time for the AfwTime Service Section 5 Time Synchronization

Setting the Time for the AfwTime Service

The time for the AfwTime Service is changed via the normal Windows time
function.
The AC 800M Time Adaptors and the AC 400 Time Adaptors in the Connectivity
Servers forward the time setting to the Control Network and to MB 300. The AC
800M Time Adaptor does this with the CNCP time set multicast which is also used
in Setting the Time with the Control Builder M on page 147.
It is recommended to configure the Windows user rights so that only some users
can change the Windows time.
Time changes are done most accurate if they are done as close as possible to the
time source network wise. Time changes done via the Windows time function are
therefore best done on the connectivity server with the active AfwTime Server.
Do not use this method for changing the time when using 800xA for Melody or
800xA for Harmony. See Adjusting Time with 800xA for Melody or 800xA for
Harmony on page 151.
1. Right-click on the Windows Taskbar and select Adjust Date/Time.

Figure 58. Manually Adjusting the Time from a PC

2. Adjust the time and click Apply.

148 3BSE034463R5001
Section 5 Time Synchronization Adjust the Time in AC 800M via the Function Block SetDT

Adjust the Time in AC 800M via the Function Block SetDT

The function block SetDT has an interaction window that allows the user to adjust
the time in the controller with absolute or relative adjustments.
The default template for Controller projects include a Program3 which contains the
function block SetTime which is of the type SetDT. The time can be modified with
the SetDT function block when an controller application that includes this function
block is running in the controller.
To adjust the time with a relative adjustment do the following:
1. Go On-Line to the controller with the Control Builder.
2. Right-Click on the SetDT function block in the HW tree or in an on-line editor
and select Interaction Window.

Figure 59. Interaction window for SetDT

3. Mark the check box Relative time.

3BSE034463R5001 149
Handling Time Changes when Using W32Time Section 5 Time Synchronization

4. Enter the desired clock adjustment in Time difference. The time is entered in
the format XdXhXmXsXms where X represents digits and d, h, m, s, ms
represent days, hours, minutes, seconds and milliseconds (see data type time in
the documentation for Control IT).
Example: Write 1m1s to adjust the clock 1 minute and 1 second forward.
5. Click Apply.

Handling Time Changes when Using W32Time

The standard configuration for the Windows Time Service does not handle time
changes well. When a node has joined the domain and has established a working
connection with its domain controller it only requests time updates every 8 hours.
This means that if the time is changed on the domain controller it may take up to 8
hours for this change to take effect on all member nodes. Therefore it is
recommended to avoid time changes as much as possible when using the standard
settings for the Windows Time Service.
If a time change has to be done, it is recommended to trigger a time update on all
nodes manually if the time is changed more than 1-2 minutes (see Time
Synchronization in a Domain on page 78). This can be done from a command line
with the command line tool w32tm.
First make sure that the domain controller has received the new time from its
source. If it has not, or just to make sure that it does, write:
C:\>w32tm /resync
This causes the PC to request the time from the SNTP server. The same command
may be used on all nodes, but for all nodes except the domain controllers it is
possible to handle everything from one PC. With the option “-s” the name of
another PC can be given. To request “client1” to request new time from the domain
controller write:
C:\>w32tm /resync /computer:client1
A successful response that tells that the PC made an attempt to resync is:
RPC to server client1 returned 0x0
This however does not mean that the resync attempt was successful. This should
preferably be checked manually.

150 3BSE034463R5001
Section 5 Time Synchronization Adjusting Time with 800xA for Melody or 800xA for Harmony

Adjusting Time with 800xA for Melody or 800xA for Harmony

800xA for Melody and 800xA for Harmony include special features for time
adjustments and time setting. These features are described in the respective
manuals: IndustrialIT 800xA, System, 800xA for Harmony, Configuration
(3BUA000157Rxxxx) and IndustrialIT 800xA, System, 800xA for Melody,
Configuration (3BDD011741Rxxxx).

Fault Tracing Time Synchronization Problems

Fault Tracing Time Sync in Controllers
The Control Builder includes a tool to supervise the clock sync status in controllers.
The Clock Sync Status tool can be found under
Tools > Maintenance > Clock Synch > Status.

Figure 60. The Clock Sync Status tool in the Control Builder

The Clock Sync Status tool can tell the following about the real time clock in a
controller:
• Protocol by which the controller receives its synchronization.
• If the controller currently is CNCP Master or not.
• Configured CNCP Master Order number.
• Time Quality, see Table 42.
• Last time source address.

3BSE034463R5001 151
Fault Tracing Time Sync in Controllers Section 5 Time Synchronization

• Mean time difference the last 601 synchronizations.

• Configured SNTP server addresses.

Table 42. Time Quality of the Clock Object in a Controller

TQ Relative error to the time source

TQ0 Time Quality undefined
TQ1 Time Undefined
TQ2 Not externally synchronized
TQ3 error > 100 milliseconds
TQ4 error < 100 milliseconds
TQ5 error < 10 milliseconds
TQ6 error < 1 milliseconds
TQ7 error < 100 microseconds
TQ8 error < 25 microseconds

The Clock Sync Status tool can only show the status for Controllers.
AC 800M may write clock sync status information in the Controller Log.
These are some examples of what this can say:
CNCP:
• Time Set message is received
SNTP:
• Synchronization interval
• The address of the used server
• The Stratum of the server (see Stratum on page 123)
• If there is no connection to any server

1. The evaluation of Time Quality uses a shorter filter that the mean time difference. This means that the mean
time difference may indicate a better time quality than the TQ value.

152 3BSE034463R5001
Section 5 Time Synchronization Fault Tracing SNTP

• If the found server (or servers) is not accepted for some reason, e.g. because it
is not synchronized.
MB 300/CI855:
• System messages with Message Type 17 and Code 11.
Data 1 may say:
– 3 = There might be more than one backup time master. Data 2 = Bup Node
– 4 = More than one Clock Master on the network

Fault Tracing SNTP

SNTP time sync problems can be analyzed with the windows command line utility
w32tm.
The Microsoft Knowledge Base Article 816043 describes how to turn on debug
logging in the Windows Time Service for Windows Server 2003 and Windows XP.

Fault Tracing AfwTime

The status of the AfwTime service providers can be supervised on the Service
Group Definition in the service structure, see Figure 61.

Figure 61. AfwTime Service Provider status

State must be “Service” for one service provider and “Standby” for all others.
The column “M” (=Master) contains an X for the same node. This is the current
time source.

3BSE034463R5001 153
Fault Tracing AfwTime Section 5 Time Synchronization

On the Time Service Definition there is a window that shows the time difference
between different 800xA nodes, see Figure 62.

Figure 62. Time Difference Supervision

154 3BSE034463R5001
 Section 6 Network Monitoring and
Maintenance

Supervision and fault tracing in the networks can be done in many different ways
depending on what is required. The following sections describe some tools and
methods for:
• Supervising general network health.
• Checking that one node has contact with another node.
• Checking the network connections in a node.

System Status Viewer

The System Status Viewer is the main Aspect system for on line supervision of the
800xA system. Servers and Controllers have system status providers that show their
status. Clients do not have any System Status providers.
The System Status viewer can be added as an aspect on any object. It is by default
added to the node group All nodes in the Node Administration structure, see
Figure 63. Here all servers and controllers are available.

3BSE034463R5001 155
System Status Viewer Section 6 Network Monitoring and Maintenance

Figure 63. The System Status Viewer with status for Servers and Controllers

The controllers are represented by one object in the node administration structure.
In the control structure also the subordinate objects are visible, see Figure 64. By
adding a System Status Viewer aspect for the Object representing a Control
Network it is possible to show the System Status for all the objects in the
Controllers on that Control Network.

156 3BSE034463R5001
Section 6 Network Monitoring and Maintenance System Status Viewer

Figure 64. The System Status Viewer with status for Controller Objects

The System Status viewer can show if a controller looses all communication on an
ethernet port. This is indicated as No Communication as in Figure 64.
Independent of which client is running the System Status viewer it shows the status
of all nodes as seen from the aspect servers. In a normal network this is sufficient
since all nodes normally see the same other nodes, but for fault tracing special
problems where it is interesting to check the connection between two particular
nodes the RNRP monitor can be used, see RNRP Network Monitor on page 161.
A particular nodes connections to different servers can be checked with the Afw
Service Connection Viewer, see Afw Service Connection Status Viewer on page
158.

3BSE034463R5001 157
Afw Service Connection Status Viewer Section 6 Network Monitoring and Maintenance

Afw Service Connection Status Viewer

The Afw Service Connection Status Viewer shows the status of services that are
used in the node where it is running, see Figure 65.

Figure 65. The Afw Service Connection Status Viewer

If node A is using a service in node B the Afw Service Connection Status viewer in
node A shows the status for the service in node B. If the network is redundant the
status of the network paths between node A and node B is also shown. A green flash
indicates that the path is working and a red flash indicates that the path is broken.
Figure 65 shows how it looks when the node running the Afw Service Connection
Status viewer has lost the secondary network path to node BCTID199. It also shows
that there is no working connection to the services in BCTID200. Either both
network paths are broken or the services are not running in BCTID200.
The Afw Service Connection Status viewer is started with a right click on the green
800xA System icon in the System Tray.

158 3BSE034463R5001
Section 6 Network Monitoring and Maintenance Topology Designer / Topology Status Viewer

Topology Designer / Topology Status Viewer

With the Topology Designer you can configure graphical network diagrams.
When the network diagram is configured the Topology Designer can also be used as
a Topology Status Viewer to show live status information about the nodes in the
diagram.

Figure 66. Topology Diagram over the Automation System Network

The Topology Designer and how to use it as Topology Status Viewer is described in
IndustrialIT 800xA, System, Configuration (3BDS011222Rxxxx) and in IndustrialIT
800xA, System, Topology Designer (3BDS011225Rxxxx).

3BSE034463R5001 159
Node Status Alarms Section 6 Network Monitoring and Maintenance

Node Status Alarms

The network events that RNRP detects creates Node status alarms.
All node alarms have the following properties:
• The node object is used as the alarm source. The name of the node will be
shown in the Object Name column in the alarm and event lists.
• The category used is “System Alarm for SoftAlarm”. This category is included
in the System Alarms category group and the alarms will therefore show up in
the default system alarm and event lists.
Node alarms are generated on some different alarm conditions:
• Network Connection Error. The message text includes the node name and the
network area number where it has a problem. Note that a node may be
connected to more than one area.
The following different sub conditions exist:
– Connection down. The node is not reachable at all.
– Primary network down. (The secondary is still OK.)
– Secondary Network down, (The Primary still OK.)
• Network Error Area <area nr>. This condition describes the state of an entire
network area. This condition occurs if the connection to all nodes on the
network is lost, including the router nodes.
The following different sub conditions exist:
– Network down. The network is down.
– Primary network down. (The secondary is still OK.)
– Secondary Network down, (The Primary still OK.)
From the node alarm it is easy to navigate to the corresponding node object in the
node administration structure via the objects context menu, see Figure 63 on page
156.
Alarms are only generated for nodes that are defined in the Node Administration
Structure. For this reason Controllers are defined in both the Control Structure
and in the Node Administration structure.
For the node status alarms to work properly Connectivity Servers, and possibly
other nodes, that connect to both the Client/Server Network and the Control
Network must use the same node number on both (all) Network Areas they are
connected to.

160 3BSE034463R5001
Section 6 Network Monitoring and Maintenance Ping

Ping
Ping is a simple program for checking whether one node has contact with another
node. Ping is available on all PCs. It is used from the Command prompt and its
syntax is as follows: drive:>ping address

Example:
C:\>ping 172.16.0.201

Pinging 172.16.0.201 with 32 bytes of data:

Reply from 172.16.0.201: bytes=32 time<10ms TTL=64

Reply from 172.16.0.201: bytes=32 time<10ms TTL=64
Reply from 172.16.0.201: bytes=32 time<10ms TTL=64
Reply from 172.16.0.201: bytes=32 time<10ms TTL=64

Ping statistics for 172.16.0.201:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
The node can be specified by name or by IP address, but note that ping is not the
recommended tool for fault tracing of DNS problems, see Verifying DNS and
NetBIOS Configuration on page 91.

RNRP Network Monitor

In PCs where RNRP is installed there is a tool called the RNRP Network Monitor.
When it starts up, it gives an overview of the entire network as seen from the node
where it is running. For all nodes that are connected, it reports if there is a working
connection between that node and the node where the Monitor is running. It shows
if the connection is working on the primary or the secondary or both paths. After the
initial overview all changes to the current status will be reported as for example
node up and node down events.

3BSE034463R5001 161
RNRP Network Monitor Section 6 Network Monitoring and Maintenance

The RNRP Network Monitor is started with a left-click on the RNRP icon in the
Windows system tray.

Figure 67. RNRP Icon in the System Tray

The RNRP icon is normally listed at Start > Programs > Startup to be activated
automatically when a user logs in. It can also be started by Start > Programs >
ABB Industrial IT 800xA > System > Network > RNRP Create Icon.
The RNRP Network Monitor can also be started at Start > Programs > ABB
Industrial IT 800xA > System > Network > RNRP Monitor.

Figure 68. RNRP Network Event Monitor

162 3BSE034463R5001
Section 6 Network Monitoring and Maintenance RNRP Events in Controllers

RNRP Events in Controllers

The same type of RNRP events that the RNRP Event Monitor can show can also be
registered in the controller log in the AC 800M. These event messages are by
default disabled, but they can be enabled1 by setting the system variable syscmd =
9, see Figure 69. The event logging is disabled by setting syscmd=10.

Figure 69. Enabling RNRP events in a Controller by setting syscmd=9

The RNRP events may look like this in the controller:

I 2004-10-01 16:04:31.128 RNRP: Node down, area=1 path=0 node=92
I 2004-10-01 16:05:03.631 RNRP: Node up, area=1 path=0 node=92

1. Changing the values of system variables is blocked in the AC 800M HI Controller.

3BSE034463R5001 163
RNRP Fault Tracer/RNRP Utility Section 6 Network Monitoring and Maintenance

RNRP Fault Tracer/RNRP Utility

For a more detailed analysis of nodes using RNRP there is a tool called RNRP Fault
Tracer. It is started with a right double-click on the RNRP icon in the system tray or
at Start > Programs > ABB Industrial IT 800xA > System > Network > RNRP
Utility.

Figure 70. RNRP Fault Tracer/RNRP Utility

164 3BSE034463R5001
Section 6 Network Monitoring and Maintenance Network Interface Supervision in a PC

The RNRP Fault Tracer/RNRP Utility can:

• Check the RNRP configuration in a remote node.
• Ask a remote node about its view of the network (network map).
• Test response times between two nodes with RNRP ping.
• Find nodes using RNRP on one network independent of their configured area
or IP addresses.
• Check for configuration errors in all reachable RNRP nodes on own network
areas.

Network Interface Supervision in a PC

Windows representation of the network interfaces also provides some information
about the status of the connections to the network. You start them via the Start
Menu > Settings > Network and Dial-Up Connections.
The status display for an interface is opened by a double click on its icon.

Figure 71. Windows Network Interface Status

3BSE034463R5001 165
Network Interface Supervision in a Controller Section 6 Network Monitoring and Maintenance

Network Interface Supervision in a Controller

The status of the network interfaces in a controller is indicated in the hardware tree
in the Control Builder when the Control Builder is in on-line mode, see Figure 72.
The indication No communication means that RNRP does not detect any nodes via
that particular Network interface.

Figure 72. Network Interface Status in the Control Builder

166 3BSE034463R5001
Section 6 Network Monitoring and Maintenance Network Interface Supervision in a Controller

The function block SystemDiagnostics, which by default is used in the Program3

when a controller application is created, contains a display about Ethernet statistics,
see Figure 73.

Figure 73. The Function Block SystemDiagnostics with Ethernet Statistics

3BSE034463R5001 167
Monitoring MMS Communication Section 6 Network Monitoring and Maintenance

Monitoring MMS Communication

The Control Builder includes a tool to supervise MMS connections to/from a node
running MMS, see Figure 74. The tool is started from the dialog “Remote System”..

Figure 74. Show MMS Connections

The node may be a controller, an OPC server or a PC running the Control Builder.
The OnLine help for the Control Builder describes more about what this viewer can
show.

168 3BSE034463R5001
Section 6 Network Monitoring and Maintenance Using Network Management information

Using Network Management information

Switches that include network management can give information about the status of
the network in general and specifically the status per network port, see Features in
Switches on page 175.
Many switches provide built-in support for SNMP (Simple Network Management
Protocol), which gives network management software the ability to monitor the
health of the switch.

PC, Network and Software Monitoring

The 800xA System comes with a package called ‘PC, Network and Software
Monitoring’ that can communicate via SNMP to device types (Assets) which
support SNMP communications.
This allows switch health and status information to be shown in operator trends,
graphics and logs, as well as incorporated into the standard System Status Viewer
Aspect. The System Status Viewer will show the first error encountered for an
Asset, as seen in Figure 75.

Figure 75. System Status Viewer showing Error on Port 1

3BSE034463R5001 169
PC, Network and Software Monitoring Section 6 Network Monitoring and Maintenance

The package contains faceplates that visualize status information from different
device types.
Figure 76 shows the faceplate for a Hirschmann RS2 switch. In this example the
faceplate shows under the Operating Status column that there is no cable attached
for Interface Indexes 1,2,3,6,7.

Figure 76. Faceplate for a Switch with SNMP Support

170 3BSE034463R5001
Section 6 Network Monitoring and Maintenance Network Management Tools from Switch Vendors

When combined with the 800xA Asset Optimization functionality, the system can
automatically detect problems and generate alarms based on this information as
seen in Figure 77.

Figure 77. Asset Optimization Asset Reporter showing no Cable attached on some
Ports.

Please refer to IndustrialIT 800xA, System, Configuration (3BDS011222Rxxxx) for

more details on how to configure this package.

Network Management Tools from Switch Vendors

Vendors of switches with network management information also supply tools that
can show and manipulate this information. There are many tools for accessing
SNMP data. Many network switches include web servers. In this case only a web
browser is needed to access the information in the switch. Some vendors also supply
OPC servers for their switches so that the network management information is
available to use for OPC clients. This means that the network management
information is possible to access from the 800xA system as from any third party
OPC servers.

3BSE034463R5001 171
Network Management Tools from Switch Vendors Section 6 Network Monitoring and Maintenance

172 3BSE034463R5001
 Section 7 Ethernet and Network Equipment

Ethernet is used for the Control Network, the Client Server Network and MB 300.
Some fieldbuses, e.g. FOUNDATION Fieldbus HSE, also use Ethernet. This section
describes how to plan and build these Ethernet networks and the equipment needed.

Building a Physical Network

Most network diagrams show logical networks only and not physical networks.
When you implement them into the real physical networks, you connect
systems/nodes to Ethernet hubs or switches. You design each Network Area,
in principle, using a star topology. If you want a Network Area to have redundant
paths, you must then duplicate all network components (full redundancy).
Below is an example of a Control Network shown first with a logical view,
and then with a physical view.

Figure 78. Logical View of a Redundant Control Network

3BSE034463R5001 173
Hubs and Switches Section 7 Ethernet and Network Equipment

Figure 79. Physical View of the Redundant Control Network

Hubs and Switches

A hub is a connection device within a network segment. It is an Ethernet multiport
repeater. A hub only allows one message to be transferred at a time between all of
its ports. This means that there will be message collisions when more than one node
transmits at the same time, just as it used to be with the old coax cables. Collisions
are handled by the media access mechanisms of Ethernet, but in a network with
heavy traffic the collisions decrease the data throughput and give non-deterministic
response times in the network.
A more sophisticated type of hub is sometimes called a switched hub, but normally
just a network switch. A switch is a connection device within a network segment.
It filters and forwards frames based on the destination address of each frame.
A switch eliminates most of the message collisions caused by several nodes
transmitting at the same time. This is basically accomplished by queueing messages
per port and by allowing several point-to-point messages to be transferred
simultaneously, if they go between different pairs of ports. This means that a
network using switches will allow a much higher throughput than a network using
hubs and it does not have the same problem with non-deterministic response times.
Even if the basic idea behind switches is conceptually better than that behind
hubs, there are differences between different switch products that can have a
large influence on the actual network bandwidth. See Features in Switches on
page 175. A poor switch may behave just like a hub under high network load.
In addition, hubs can not be supervised by network management tools.

174 3BSE034463R5001
Section 7 Ethernet and Network Equipment Features in Switches

Features in Switches
A switch is not altogether an ideal device. The store-and-forward delay introduced
by a typical switch is about 25 us. If the switch output port is busy with an other
1518 byte packet, then an extra delay of 122 us may occur when the port speed is
100 Mbps, 1.22 ms when the port speed is 10 Mbps. These delays are no problem
for normal system applications, but they do affect the accuracy of the network clock
synchronization. In this sense, a few large switches in a star topology are better than
many switches in a tree structure. The minimum delay is the sum of the store-and-
forward delay in every switch passed.

Managed Switches
Switches that only store and forward ethernet packets without being accessible as
nodes on the network are called un-managed switches.
Switches that act as a node with an IP address on the network giving access to
network management information are called managed switches. The network
management information is for example configuration data for the different ports
regarding port speed and status information about number of bytes transferred,
check sum errors etc. The amount of management information may differ very
much between different switch types.
The actual ethernet packet switching function is often the same for managed and un-
managed switches. These are some pros and cons for managed and un-managed
switches:
• Un-managed switches are typically cheaper.
• Managed switches give the possibility to supervise the network better.
• Managed switches may give possibilities to control the traffic better by e.g.
address based traffic filtering.
• In a small network the additional features of a managed switch may be
unnecessary.
• In a large network the additional features of a managed switch may be very
useful.

3BSE034463R5001 175
Basic Requirements on Switches Section 7 Ethernet and Network Equipment

The user must decide what features he/she wants to use in the switches.
The following sections list some notable features in switches, some are only
available in managed switches.

Basic Requirements on Switches

• Ports in compliance with 10Base-T/ 100Base-TX supporting both full and half
duplex with RJ45 sockets.
• Fiber ports 100Base-FX for backbone connections in noisy environments and
for long distance connections.
• Link speed should be possible to set by auto-sensing, but manual configuration
is recommended, see Ethernet Speed on page 177.
• Transmission mode, half or full duplex, should be possible to set by auto-
negotiation, but manually configuration is recommended, see Ethernet Speed
on page 177.
• Multicast traffic must be allowed.
• Port status should be visible on LEDs.
These features are normally available in both managed and un-managed switches.

Features not Required in Switches

• Quality of Service (QoS) functions like priority tagging (IEEE 802.1p/q) are
not required since at present, none of the system applications define any type of
service to the network.
• IGMP Snooping can not be used and must be disabled. RNRP multicasting
may otherwise be disturbed.
• Spanning Tree Algorithm support is of no use in the network redundancy
concept (see however Using Rapid Spanning Tree on page 181).
• Multicast filtering must be disabled.
• Intelligent Multicast must be disabled.
These features are normally only available in managed switches.

176 3BSE034463R5001
Section 7 Ethernet and Network Equipment Recommended Features in Switches

Recommended Features in Switches

• Simple Network Management Protocol (SNMP) and RMON are good tools for
network diagnostics and traffic monitoring.
• Switches with built-in Web Server are easiest to manage.
• Switches, for which OPC servers allow the user to build applications accessing
network management information via OPC; will allow management of the
network from the same tools as the management of the remaining system.

Ethernet Speed
Different network equipment supports different communication speed.
It is recommended that all PCs used in an IndustrialIT 800xA System support at
least 100 Mbit full duplex.
AC 800M controllers support 10Mbit half duplex.
Nodes with different communication speeds can normally be connected to the same
switch. It is recommended to avoid this as much as possible since multicast traffic to
the slow devices may also slow down the performance of the nodes using higher
speed.
It is recommended to manually set the speed and duplex parameters for the ports on
both ends of the connection to maximize switch performance and ensure a stable
link. In most cases it works just fine to use auto negotiation, but it is a safer choice
to configure it manually. In systems where it normally works fine with auto
negotiation the performance may still be improved by manually configuring the
ports. Auto negotiation on one side and manual configuration on the other should be
avoided. This often leads to problems.

Physical Network Installation

The following sections contain recommendations and considerations on how to plan
the physical installation.

3BSE034463R5001 177
Physical Network Installation Section 7 Ethernet and Network Equipment

Ethernet Cables
• Normal copper cable installations use RJ-45 connectors and a category 5 or
higher Shielded Twisted Pair (STP) cable.
Use CAT5 or higher cables on 10MBit connections.
Use CAT 5E cables on 100MBit connections.
Use CAT 5E or 6 on 1000MBit connections.
• With the STP cable, you can obtain a 100 m maximum distance between the
end-nodes in the network segment.
• Separate the cables for the two redundant networks as much as possible to limit
the risk of simultaneous problems on both networks.

Allocating nodes to switches

• Nodes that communicate frequently with each other should be connected to the
same switch. If this is not possible, keep the number of switches between the
communication partners as low as possible.
• In a network with many switches and where all nodes communicate roughly
equally with each other, a tree structure of switches is preferable to a chain
structure. This is because a tree structure decreases the maximum number of
switches between two communication partners.

Figure 80. Serial (left) or Tree (right) Network Structure

• Connect nodes with the same communication speed to the same switch.

178 3BSE034463R5001
Section 7 Ethernet and Network Equipment Coexistence of Network Types

Coexistence of Network Types

Do not run MB300 on the same physical network as the Control Network. It is
possible but not recommended due to bandwidth considerations.
Do not run Foundation Fieldbus on the same physical network as the Control
Network. FF HSE uses broadcast that give undesired load to the controllers.

Reducing HW using Virtual LANs

Installing a network using several separate networks can in some cases be simplified
by use of Virtual LANs; VLANs. Most managed switches support VLANs. When
using VLANs the ethernet ports in the switches are configured to belong to one (or
more1) VLANs or to run VLAN tagged traffic (aka trunk ports). The ports with
tagged traffic transport packets belonging to all VLANs. Each packet is tagged with
information about which VLAN it belongs to. The untagged ports transport only
packets belonging to a certain VLAN. This makes it possible to build a network
where several networks share the physical media between switches but the nodes
connected to untagged ports for different VLANs do not receive traffic from each
other. The right hand part of the system configuration described in Figure 14 on
page 39 can be implemented as shown in Figure 81.

Figure 81. Client/Server and Control network sharing a physical link using VLANs
1. All switches may not be able to configure untagged ports belonging to more than one VLAN.

3BSE034463R5001 179
Ring Redundancy Section 7 Ethernet and Network Equipment

Usage of VLANs can simplify physical installation because it may reduce the
amount of cables and switches but it may make the maintenance more complicated.
If a switch needs to be replaced the amount of configuration to do before the new
switch can be used increases if VLANs are used compared to if all logical networks
are built with physically separate switches.

Ring Redundancy
Some switch vendors support a ring redundancy concept.
This normally gives an improved system availability as it provides cable
redundancy. The switches themselves are still, however, single points of failure.
You have to consider what type of problems threaten the availability of the network;
is it more likely that a fiber optic cable will be destroyed or that a switch will fail.

Figure 82. Switches with Ring Redundancy

We do not recommended running the two RNRP network paths on the same
physical ring even if it would be possible to connect the two network interfaces
of a node to two different switches.
If redundant switches are required, the two network paths should be physically
separated as described in Figure 79 on page 174 because running both paths on
one ring:
• gives less protection for “active” Ethernet problems, like for example a
continuous sender.
• does typically not save any hardware since the same amount of switches are
needed as if the paths are physically separated.

180 3BSE034463R5001
Section 7 Ethernet and Network Equipment Using Rapid Spanning Tree

With separated network paths the availability of each path can of course be
additionally improved by using one redundancy ring for each path as in Figure 83.

Figure 83. Using Fiber Optic Ring Redundancy and RNRP

Using Rapid Spanning Tree

The protocol Rapid Spanning Tree (IEEE 802.1w) provides a mechanism to achieve
a network where several switches can cooperate to create redundant communication
paths for the nodes connected to the network.
It selects one path and switches to another if the currently used path breaks.In a
network with many switches Rapid Spanning Tree is able to create several
redundant paths.

3BSE034463R5001 181
Using Rapid Spanning Tree Section 7 Ethernet and Network Equipment

Figure 84. Rapid Spanning Tree creates Redundant Paths in the Network

Like in the case of the ring redundancy Rapid Spanning Tree is a good method to
improve the availability in a network with nodes that are connected with single
interfaces.
It is possible to combine Rapid Spanning Tree and RNRP redundancy, but as in the
standard case in Figure 79 on page 174 and in case of ring redundancy in Figure 83
on page 181 the two paths should be kept physically separate.
As for ring redundancy we do not recommended connecting the two interfaces of
each RNRP node to two switches that are on the same Rapid Spanning Tree
network. Doing this may lead to a network where both RNRP paths are using the
same Rapid Spanning Tree path. A break on that path will stop both RNRP paths.
The time it will take to heal such a network break depends on the speed of the
Rapid Spanning Tree network and this depends on the size of the network. The
RNRP switch over time is constant.
When building a redundant RNRP network the availability of each path may, as in
the case of ring redundancy, be improved with one separate Rapid Spanning Tree
network for each path as in Figure 85.

182 3BSE034463R5001
Section 7 Ethernet and Network Equipment Environmental Consideration

Figure 85. Using Rapid Spanning Tree together with RNRP

Environmental Consideration
The type of network components that you may use depend on the climatic and
electrical environment.

In a Non-industrial Application
In an office environment, you can use most world-wide known brand products.
It is recommended to use the STP cable.

In an Industrial Application
You have to select products that fulfill industrial requirements on:
• Temperature
• Humidity
• MTBF
• EMC
• Supervision
In the industrial application it is recommended to use the multi-mode fiber 62.5/125
or better 50/125 fiber, 100Base-FX between hubs or switches. The max distance is
at least 1500 m. Special network components can be used to obtain longer distance.
It is safe to use twisted pair cable only where you have full control of the cabling
inside an area with the same common ground, for example inside cabinets or
between cabinets in a control room with cabinets connected to the same common
ground.

3BSE034463R5001 183
Environmental Consideration Section 7 Ethernet and Network Equipment

Figure 86. EMC Considerations for a Network Installation

184 3BSE034463R5001
Section 7 Ethernet and Network Equipment Connecting to a Redundant Network

Connecting to a Redundant Network

When nodes are connected to a redundant network it is important that the network
interface for the primary network is actually connected to the primary network and
vice versa. This is true for both PCs and Controllers. It is recommended to use
different cable colors for the two network paths. Table 43 shows one example.

Table 43. Example of Cable Colors

Network type Color

Client/server Network Primary Path Yellow
(also for combined Client Server and Control Network)
Client/server Network Secondary Path Orange
(also for combined Client Server and Control Network)
Control Network Primary Path Red
Control Network Secondary Path Blue
Ethernet based Fieldbus Primary Path Black
Ethernet based Fieldbus Secondary Path White

3BSE034463R5001 185
Connecting a PC Section 7 Ethernet and Network Equipment

Connecting a PC
When connecting the network to the PC it may be difficult to know which of the two
network interface boards is the primary. One way to find out is to do the following:
1. Connect one of the network interfaces cables to the switch.
2. Open the Start Menu > Settings > Network and Dial-Up Connections.

Figure 87. Network Status View with only Primary Network Interface Connected

3. The icons show which of the network interfaces you have connected.
4. Disconnect the network cable.
5. Verify that both network interfaces now are marked disconnected.

Connecting a Controller without CPU Redundancy

When connecting a controller without CPU redundancy simply connect the primary
network to the connector CN1 and the secondary network to CN2.

186 3BSE034463R5001
Section 7 Ethernet and Network Equipment Connecting a Controller with CPU Redundancy

Connecting a Controller with CPU Redundancy

When using the AC 800M with redundant CPUs, e.g. PM861, PM864 or PM865, it
is recommended to always also use network redundancy, i.e. using both network
interfaces on both Controller CPUs. This means that each AC 800M controller in
total has 4 connections to the network. It is important that the primary network
interfaces on both CPUs are connected to the primary network.
The best tolerance to network faults is achieved if all the 4 network ports are
connected to different switches. Use 4 switches for each group of controllers in the
plant as in Figure 88:
• One for the Primary network for all “Upper” CPUs
• One for the Secondary network for all “Upper” CPUs
• One for the Primary network for all “Lower” CPUs
• One for the Secondary network for all “Lower” CPUs

Redundant AC 800M with

2 PM861A and 2 BC810 Secondary
Upper CPU Primary Network
Network

CEX bus
RCU link
Lower CPU 4 Redundant
Switches

Figure 88. How to Connect a Redundant AC 800M to a Redundant Control Network

If the two network paths are implemented as rings or with some similar kind of
ethernet redundancy the complete solution will be very fault tolerant.

3BSE034463R5001 187
Routers Section 7 Ethernet and Network Equipment

Routers
Separate standard non-RNRP routers are normally not used within the Control
Network. The routing required between Client/Server Network and Control
Network Areas is taken care of by the Connectivity Servers running RNRP.
Standard routers may be used for connections between a network running RNRP
and an external network. This must in many cases be done with a device which acts
as a firewall, see Connecting to a Redundant Network on page 185.

188 3BSE034463R5001
 Section 8 Network Security

Network security measures aim at protecting the confidentiality, integrity, and

availability of a computer system. This is a complex challenge involving both
technical and procedural measures. Providing and managing enterprise-wide
network security is a moving and dynamic target, complicated by continuous
technical, organizational, political changes, global interconnections, and new
business models such as Internet-based e-commerce.
There is no single solution or technology for network security that fits the needs of
all organizations and all applications. While basically all computer systems are
vulnerable to intrusion attempts, the potential consequences of such attempts are
vastly different for different types of applications. The security measures that are
applied to a specific installation should be proportional to the assessed risk in terms
of probability of an attack and the potential consequences. For a small system with a
few users controlling a non-critical process this risk is obviously smaller than for a
large system spanning multiple sites with safety critical processes in several
countries and continents and thousands or even tens of thousands of users.
For manufacturing and control systems in particular, the potential impact of an
attack includes, for example, violation of regulatory requirements, loss of public
confidence, loss of proprietary or confidential information, loss of production,
damage to equipment, and endangerment of public or employee safety.

Establish a Network Security Policy

A key element in implementing and maintaining the security of a computer network
is the establishment of an adequate network security policy. This should be based on
an analysis and assessment of the needs of the organization, current and planned
network structures and information and control flows, risks in terms of probability
of different types of attack and potential consequences, and available technical
security solutions.

3BSE034463R5001 189
The Onion Approach Section 8 Network Security

The security policy should be based on the principle of least privilege and
compartmentalization, i.e., every application, user, or subsystem should be
restricted to the minimum number of rights for the minimum number of resources
that is necessary to fulfill its purpose. Network access to functions that are not
explicitly required should be disabled. This reduces the possibilities that an attacker
can exploit and limits the damage in case an intrusion attempt is successful.

The Onion Approach

A generally recommended approach to network security is the onion approach, also
known as “defense in depth”. The inner layers, or zones, of a network, where
communication interaction needs to flow freely between nodes, are referred to as
trusted. Trusted network zones should be kept small and independent. They need to
be physically protected, i.e. physical access to nodes, network equipment, and
network cables, must through physical means be limited to authorized persons.
When connecting a trusted network zone to outer network zones, additional layers
of security measures should be applied, isolating the network zones from each other
and providing additional security for the network as a whole.
Firewalls are used to control network traffic between zones of different security
levels and to filter out undesirable or dangerous material. Traffic that is allowed to
pass between zones should be limited to what is absolutely necessary, because each
type of service call or information exchange translates into a possible route that an
intruder, virus, or worm may be able to exploit. Different types of services represent
different risks - incoming e-mail, as an example, represents a very high risk.
Security mechanisms should not only include defensive and preventive means,
but also means for detection and reaction. By continuously monitoring a system for
intrusion attempts, users can be alerted to potential threats and take suitable actions,
such as isolating an inner network zone from outer zones.
Figure 89 below illustrates how the onion approach could be applied when
connecting an 800xA system to an office network, which in turn is connected to
Internet.

190 3BSE034463R5001
Section 8 Network Security The Onion Approach

An overview of different elements of network security, and measures and practices

that a user of an Industrial IT 800xA system may want to consider, can be found in
the document IIT Integrated Automation System - Network Security Considerations
(3BSE032547). The document Microsoft Security Updates Validation Status
describes which Windows updates that are verified together with the 800xA System.
Both these documents are available in the ABB Solutions Bank.

Internet

Firewall system

Office network
Domain
controller … …

Separate
domains Automation System Network

Firewall

Domain Application Aspect server Operator

controller server Workplaces

Connectivity servers
Controllers

Figure 89. Example of how the Onion Approach could be applied when connecting
an 800xA System to an Office Network, which in turn is connected to Internet

3BSE034463R5001 191
Firewalls Section 8 Network Security

All external connections to an Industrial IT 800xA system network should be made

through a firewall. Direct connections to nodes in the 800xA system, e.g. through
dial-up modems and similar equipment, should not be used.
A connection between the Internet and an Industrial IT 800xA system must
always pass through a correctly configured and maintained firewall system.

The security measures described in this document represent possible steps that a
user of an 800xA system could consider, based on a risk assessment for a
particular application and installation. This risk assessment, as well as the proper
implementation, configuration, installation, operation, administration, and
maintenance of all relevant security related equipment, software, and procedures,
are the responsibility of the user of the 800xA system.

Firewalls
The selection and design of a firewall system should be based on the corporate
security policy. It should be revised on a regular basis, as requirements and
environment change. Note also that while firewalls block traffic from the outside of
a protected area to the inside, they normally allow users on the inside to
communicate freely with outside services. For manufacturing and control systems,
more restrictive policies are likely to be appropriate.
A firewall system can be a dedicated hardware box, a workstation, one or more
servers, or a mix of all of these. There are four general classes of firewall functions:
• Packet filtering firewalls check the address information in each packet before
forwarding it to its destination. If this information does not match certain
criteria, the packet is dropped. Advantages of packet filtering firewalls include
low cost and low impact on network performance. Packet filtering firewalls are
also referred to as Static Filtering firewalls.
• Stateful Filtering firewalls are similar to Static Filtering firewalls but they
remember outgoing requests („keep state information“) and dynamically
reconfigure rules to let responses back in. This often simplifies the firewall
configuration, particularly if the connections through the firewall are
established only from one side and the traffic from the other side can be
considered as responses to accepted requests.

192 3BSE034463R5001
Section 8 Network Security Firewalls

• Stateful Inspection firewalls check packets at the network layer, determine

which packets are legitimate, and then evaluate the contents of packets at the
application layer. Stateful inspection firewalls offer a high level of security,
good performance, and do not require configuration of each node, but are
expensive and must be properly configured and maintained, otherwise they can
actually be less secure than simpler types of firewalls.
They are sometimes combined with content scanning functions that for
example can block viruses, filter out active contents from e-mail, etc. Stateful
Inspection firewalls are also referred to as Dynamic Packet Filtering firewalls.
• Application Proxies examine packets at the application layer, and filter traffic
based on specific application level rules. They offer a high level of security, but
have a significant impact on network performance. They are not transparent to
end-users, but require configuration of each client workstation. Application
proxies are often combined with a circuit-level gateway, which monitors the
TCP handshaking to determine whether a requested session is legitimate.
Application proxies are well suited to use in association with a demilitarized
zone, see Single Firewall or a Demilitarized Zone on page 197. There are a
number of examples of Application Proxy solutions that are suitable for an
800xA system:
– WebProxy
A webproxy is an application that forwards http traffic. Clients on the
800xA system network only accesses the webproxy. From the outside it
looks like all traffic comes from the webproxy. This can be used for all
http traffic. Traditional web access to the Internet might not be desired
from the 800xA system but some integrations with 3rd party systems use
http, see Integration with 3rd Party Systems on page 210.
– Remote Client access in two steps
This is perhaps not a real proxy application but it serves the same purpose.
See Remote Clients Connecting through a Demilitarized Zone on page
208.
A particular firewall may contain a combination of these mentioned functions.
Besides filtering network traffic, firewalls normally also log communication events
and intrusion attempts. It is recommended that the security policy contains a plan
for if and how to use this information.

3BSE034463R5001 193
Connections to 800xA Systems through Firewalls Section 8 Network Security

Firewall systems are available for example from:

• Checkpoint (www.checkpoint.com)
• Cisco (www.cisco.com)
• Netscreen (www.netscreen.com)
• Nokia (www.nokia.com/securitysolutions).

Connections to 800xA Systems through Firewalls

This section describes some general background information which is true for many
different applications that require access through a firewall.

Connect Inside-out Instead of Outside-in

Connections between the 800xA System and other systems through a firewall may
be done in different ways depending on the direction. It is easier to maintain a high
level of security if connections are only allowed from the automation system
network out to the external network and not vice versa.
If you need to get data from the 800xA system to an external system it is better if
you can push the data from the inside of the system instead of allowing for an
external system to fetch the data from the outside. An example is described in Using
a 3rd Party Access Agent on page 211.

Network Address Translation in Firewalls

In addition to configuring access restrictions by port numbers, it is recommended to
configure the firewall to perform Network Address Translation (NAT).
This prevents externally exposing the IP addresses used in the 800xA system.
If the only connections that are needed through the firewall are initiated from the
automation system network the firewall only needs to expose its own external
address to the external network. All connections will look like they were initiated
from within the firewall.
If there is a need for applications on the external network to connect to servers on
the automation system network the firewall needs to expose more addresses to the
external network. This can be done using “static NAT”. Static NAT means that the

194 3BSE034463R5001
Section 8 Network Security Network Address Translation in Firewalls

firewall translates between static pairs of external and internal addresses. For each
individual server that is to be accessed from the external network the firewall needs
to expose an address in addition to the firewalls own address on the external
network. See Figure 90.

Figure 90. Static Network Address Translation or Port Address Translation

An alternative to NAT is PAT (Port Address Translation): The Firewall only exposes
one IP address but is configured to forward traffic directed to specific ports on its
external network interface to another port on a node on the automation system
network. A separate external port number is reserved for each local server. To be
able to use PAT it must be possible to configure which port the external clients
should connect to.
By usage of Network Address Translation the addresses used by the 800xA
system do not need to be known anywhere except internally on the automation
system network. This makes it possible to use the same address range (see
Recommended IP Address Plan on page 28 and Choosing Address Space on page
218) for each 800xA system even if there are more than one 800xA system
connected to the same external network and even if they need to be accessed
from outside or even need to access each other.

3BSE034463R5001 195
Network Address Translation in Firewalls Section 8 Network Security

Example:
Two Terminal servers on the Client Server Network to be used by remote clients on
the plant network.
Static PAT: If the port numbers, used by the Terminal Clients when they connect to
the Terminal Servers, can be changed it is not necessary to expose any other
addresses for the Plant Network than the address of the Firewall (10.1.1.101). The
Terminal Clients select which Terminal Server to use by selecting different port
numbers (33389 or 33390). The Firewall translates access towards
10.1.1.101:33389 to 172.16.4.41:3389 and 10.1.1.101:33390 to 172.16.4.42:3389.

Table 44. Address translation rules, Static PAT

Internal External
Node IP Address Port # IP Address Port #
Firewall 172.16.5.245 10.1.1.101
Terminal Server 1 172.16.4.41 3389 10.1.1.101 33389
Terminal Server 2 172.16.4.42 3389 10.1.1.101 33390

Static NAT: If it is desired not to set any special port numbers for the Terminal
Clients it is necessary to expose specific IP addresses for the Terminal Servers on
the Plant Network. The Terminal Clients select which Terminal Server to use by
selecting different IP addresses (10.1.1.141 or 10.1.1.142). The Firewall translates
access towards 10.1.1.141:3389 to 172.16.4.41:3389 and 10.1.1.142:3389 to
172.16.4.42:3389.

Table 45. Address translation rules, Static NAT

Internal External
Node IP Address Port # IP Address Port #
Firewall 172.16.5.245 10.1.1.101
Terminal Server 1 172.16.4.41 3389 10.1.1.141 3389
Terminal Server 2 172.16.4.42 3389 10.1.1.142 3389

196 3BSE034463R5001
Section 8 Network Security Single Firewall or a Demilitarized Zone

Single Firewall or a Demilitarized Zone

A connection between an Automation System Network and an external network
should be done through at least one firewall. The solution may be done more or less
complex depending on the requirements on the security.
A simple straight forward solution is to use one firewall with two network
interfaces, one connected to the 800xA System Network, one interface is connected
to the external network, see Figure 91. Configure the firewall to only allow the
necessary services to pass. The instruction IndustrialIT 800xA, System, Engineering
Planning (3BSE041389Rxxxx) contains a number of points to consider when
planning how to configure the firewall.

Figure 91. Single firewall between 800xA and external network

3BSE034463R5001 197
Single Firewall or a Demilitarized Zone Section 8 Network Security

By using a firewall with more than 2 network interfaces it is possible to build a

solution where one interface is connected to the 800xA System Network, one
interface is connected to the external network and at least one port is connected to a
separate network that may be called “Demilitarized Zone” (DMZ), Figure 92.

Figure 92. Firewall with demilitarized zone between 800xA and external network

198 3BSE034463R5001
Section 8 Network Security Single Firewall or a Demilitarized Zone

The idea with a Demilitarized zone is that the traffic between the external network
and the 800xA system needs to go via nodes on the demilitarized zone. Connections
should not be made directly between an external node and a node on the 800xA
System network. Exactly how this can be done depends on the actual service which
is to be accessed. One example is that anti virus updates and security patches can be
loaded to a server in the demilitarized zone and fetched from that node from the
system network. For some services there are Application proxies (see Firewalls on
page 192) that can be connected in the demilitarized zone.
Another common usage of a demilitarized zone is as the location of VPN gateways
for VPN connections terminated outside the Automation System Network, see
Figure 96 on page 204.
By using two firewalls of different types the security of the demilitarized zone can
be built even stronger, see Figure 93. If there is a problem with the firewall on the
outside of the demilitarized zone there is still a chance that this can be detected
allowing actions to be taken before there is a problem also with the firewall on the
inside. The nodes and services to connect to the demilitarized zone can be the same
in this solution as in the previous one. A further extension could be to use different
demilitarized zones for different services.

3BSE034463R5001 199
Single Firewall or a Demilitarized Zone Section 8 Network Security

Figure 93. Dual firewalls with demilitarized zone between 800xA and external
network

200 3BSE034463R5001
Section 8 Network Security Connecting a Firewall to a Redundant Network

Connecting a Firewall to a Redundant Network

Two basic approaches can be used to connect a firewall to a redundant network
using RNRP. The two methods plus a variant of the second are shown in Figure 94.

Figure 94. Connecting directly on the primary network or via an RNRP router

Left: Connect the firewall to the primary path of the redundant network and let it
communicate directly to all nodes it needs to reach. In this case the firewall
can only communicate with nodes for which the primary network path is
working OK. If a node looses the primary path the firewall can not reach it.
Middle: Use a server running RNRP as router between the redundant network and
the firewall. In this case the firewall can communicate with nodes even if
they loose the primary network path. It is however dependant on the RNRP
router node to work OK.
Right: The middle solution can be slightly modified to save some hardware: The
router node does not need to use 3 network interfaces. It is possible to do
the connection between the router node and the firewall using the primary
network. This (or the middle) method is recommended at least when a
tunnel area is used (see Use of Standard IP Routers between RNRP
Network Areas on page 63) since this anyway requires an extra router node:
the tunnel area border node.

3BSE034463R5001 201
Using an Extra Network for Remote Access Section 8 Network Security

Using an Extra Network for Remote Access

To separate the network traffic for remote access from the normal traffic on the
Client Server network a extra network can be built for this traffic between the
firewall and some of the 800xA nodes. An example is shown in Figure 95.

Figure 95. Extra network for remote access limiting the Client Server network
traffic

This is particularly useful if there is much traffic for remote access and if only a few
internal nodes are to be accessed from the outside, for example some terminal
servers for Remote Clients. Connect only the nodes that will have much remote
access traffic to the extra network. If needed the other nodes can be reached via one
of these nodes that will act as a router as in the middle alternative in Figure 94 on
page 201. Disable IP forwarding in the other nodes.
This method provides some degree of improved security since it limits the amount
of remote access traffic on the Clients Server network.

202 3BSE034463R5001
Section 8 Network Security Virtual Private Networks (VPN) for Secure Connections

Virtual Private Networks (VPN) for Secure Connections

Virtual private network (VPN) is a general notion for a connection that is created
over an existing public or shared network using encryption and/or authentication
technologies to protect the user data. The two main applications for VPNs are:
• VPN for LAN to LAN connections. Two secure networks are connected via an
encrypted connection over an unsecure network. The most common protocol to
use is IPsec. This type of VPN can be used for all kind of IP based
communication. An application is described in Site to Site Connections via a
Firewall on page 209.
• VPN for remote access. A remote client node is connected to a server on a local
network. IPsec and SSL are commonly used protocols for remote access. IPSec
operates on the network layer and is thus able to protect all UDP- or TCP-based
communication, but requires appropriate configuration of the firewalls by the
network administrators. SSL operates on a higher protocol layer and only
protects TCP-based connections. It requires that users or application software
handle digital certificates, but has typically less interaction with networking
and firewalls than IPSec.
Secure Connections for Remote Clients on page 208 describes considerations
on VPN usage for remote access.
A VPN connection to a network is terminated in a VPN gateway. Many firewalls
can act as VPN gateways.
A VPN connection typically does not filter traffic. This means that both sides of the
connection need to be treated the same way regarding network security, e.g. having
the same security level. A VPN connection to an 800xA System should only be
terminated in a VPN gateway connected directly to the system network if the other
side of the connection has the same security level. An alternative is to terminate the
VPN connection in VPN gateway connected to a network outside a firewall and to
let the communication between the VPN connection and the system network go
unencrypted through the firewall to the system network. This way the traffic from
the VPN connection can be filtered before entering the system network. If a
demilitarized zone (DMZ) is used outside the Automation System Network the
VPN gateway can be placed in there (see Single Firewall or a Demilitarized Zone on
page 197).

3BSE034463R5001 203
Use cases for Connections through Firewalls Section 8 Network Security

Figure 96. Terminating the VPN inside or outside the 800xA System Network

Use cases for Connections through Firewalls

From network security point of view the easiest configuration to maintain is an
isolated Automation System Network which is not connected to any other network.
There are however a number of cases where it is necessary to connect the
Automation System Network with some other network.
Some of the more common use cases are described below:
• Remote/external client
The 800xA system needs to be accessed from a user on a computer which is not
connected to the automation system network. This means that the Automation
System Network needs to be connected to an external network and the client
functionality needs to be made available through some kind of firewall system.
This is described in Remote/External Client on page 205
• Site to site connection
The automation system is located on two or more geographical sites and the
remote connection needs to go via an external network.
This is described in Site to Site Connections via a Firewall on page 209.

204 3BSE034463R5001
Section 8 Network Security Remote/External Client

• Integration with external 3rd party system

Data in the 800xA system needs to be accessed from a 3rd party system on an
intranet. This can be done in some different ways where the intranet and the
Automation System Network are connected in some way.
This is described in Integration with 3rd Party Systems on page 210.
• Management of system updates
Updates for Windows and updates for the 800xA system need to be introduced
in the system a safe way.
This is described in Management of System Updates on page 213.
• Other services to through the firewall
In some cases it may be desired to route some other specific services through a
firewall. Some examples are:
– DNS for name resolution
– E-mail alerts from an Alarm Server
– Time synchronization via SNTP or NTP
This is described in Other Services to be Used Through a Firewall on page 214.

Remote/External Client
It is possible to use client functionality on nodes outside the 800xA system network.
The way this should be done depends on what type of client functionality to access:
• External node working with the same functions as the client inside the system,
e.g. with the Operator Workplace. This is a case where the external node is
used for interactive operation with data which stays inside the system. It is not
a matter of extracting data from the system to use in any external system or to
import data to the system. The recommended method is to use some kind of
remote windows workplace functionality, e.g. Windows Terminal Server and
Remote Desktop.
• A user on an external node remotely controls a node on the system network.
• External user accessing OPC data from the 800xA system using Excel and the
Information Manager Desktop Tools.

3BSE034463R5001 205
Remote Windows Workplace Section 8 Network Security

Figure 97. Examples of Remote Client access

The following sections will describe these use cases in more detail. For each use
case it will be described which network ports that are needed to be opened in the
Firewall.

Remote Windows Workplace

There are two main alternatives for system configurations with a terminal server on
the 800xA network to be used by a number of remote clients:
• Microsoft Remote Desktop
The Remote Desktop functionality is included in the standard Windows XP and
WindowsServer 2003. The traffic is encrypted.
The default port is 3389 but it can be changed.
• Citrix
Citrix remote clients can be configured to use a number of different protocols:
– Citrix Client, no encryption. Uses port 1494 for a proprietary protocol.
– Citrix Client, secure connection. Uses port 443 for HTTPS.
– Web Browser. Uses port 80 for HTTP and 1494 for a proprietary protocol.
– Web Browser, secure connection. Uses port 80 for HTTP and 443 for
HTTPS.

206 3BSE034463R5001
Section 8 Network Security Remote Usage of a Node on the System Network

Remote Usage of a Node on the System Network

There are a number of products that allow a remote user to use a node on the 800xA
System Network. With these products the server node is taken over by the client.
This can for example be used for remote administration of a system or for assistance
to local engineers.
• VNC
VNC is an open source protocol. There are several implementations, e.g.
RealVNC, TightVNC and UltraVNC.
All implementations do not support encryption.
The default port number is 5900 but it can be changed.
• Symantec PC Anywhere
The default port number is 5631 and 5632 but it can be changed.
To enable remote usage of all nodes in a system it might be good to do these
connections in more than one step. Establish one connection from the remote node
to one particular node on the system network and connect from that node to the
other node. This makes it easier to configure the firewall if it only needs to allow
connections to one local node.

Information Manager Desktop Tools

The Display Services Client, Desktop Trends and the Excel addins are functions that
make it possible to work with data from the 800xA system. They are normally
installed on a on a PC which is not part of the 800xA system. To use these tools on a
node on a plant intranet outside a firewall the ports 19014-19017 need to be opened
for access from the external node to the Information Manager server. The port
numbers can be changed.

3BSE034463R5001 207
Secure Connections for Remote Clients Section 8 Network Security

Secure Connections for Remote Clients

To run Client functionality on an external node a connection from the external node
needs to be established to a node on the 800xA system network. This connection
may be done more or less complex giving different level of security.
Many of the products providing Remote Client functionality support encryption
between the client and the server. In some cases this might be considered sufficient,
e.g. if the clients are located on a protected plant intranet. If a higher level of
security is desired the connection may be done using some kind of additional VPN
connection see Virtual Private Networks (VPN) for Secure Connections on page
203.
If a remote node is connected as a client to an 800xA system via a VPN connection
it is very important to notice that the same care must be taken regarding the security
handling of the remote node as for the 800xA nodes since the VPN connection may
make the remote node a member of the 800xA system and if the remote node is
unsecure the whole system may be unsecure. For example the remote node should
preferably not have any normal connection to Internet when it is connected to the
800xA System.
A way to limit the risk from a remote client is to make sure that the remote client
only has access to a limited set of services. This can be done by using a remote
client application that only has a limited set of services instead of using a VPN
connection that gives the remote client the same rights and possibilities as a local
node in the system.

Remote Clients Connecting through a Demilitarized Zone

A remote client connection through a demilitarized zone can be done as a two step
connection: One remote client connection from the external network to a terminal
server on the Demilitarized zone and another remote client connection from that
node to a terminal server on the 800xA System network. If the two connections are
done using different products the risk for intrusion due to problems with one
product is reduced, but some combinations of some products may however not work
perfectly. There may for example be problems with keyboard handling.

208 3BSE034463R5001
Section 8 Network Security Site to Site Connections via a Firewall

Site to Site Connections via a Firewall

Two parts of an automation system that need to communicate via a network with
lower security level than the automation system network can use a VPN for LAN to
LAN connection (see Figure 98 and Virtual Private Networks (VPN) for Secure
Connections on page 203).

Figure 98. Site to Site VPN

The VPN connection tunnels all communication so that it can not be intercepted by
any node between the two sides. Filtering of the traffic between the two sides does
not need to be done since both sides are regarded as being on the same trusted
network. If filtering is desired the VPN connections may be terminated outside of a
firewall on either of the sides as described in Figure 96 on page 204.
The two sides communicating via the VPN connection may be one 800xA system
with an extended automation system network with some distributed nodes as some
of the examples in Section 2, Distributed System Topologies.

3BSE034463R5001 209
Integration with 3rd Party Systems Section 8 Network Security

If the connection between the sites needs to be redundant this can be achieved with
two RNRP tunnel areas, see Figure 99. See also Figure 24 in Use of Standard IP
Routers between RNRP Network Areas on page 63

Figure 99. Redundant RNRP Tunnel Areas

Integration with 3rd Party Systems

This section describes some of the more common use cases where the 800xA
system needs to exchange data with a 3rd party system. Data that needs to be
exchanged may be:
• OPC Output data, e.g. from an Information Manager Server, from the 800xA
system for further processing.
• OPC Input data controlling the operation of the 800xA system.
• Asset Optimization information to and from an external maintenance
management system.

Accessing OPC Data from External Network

Accessing OPC data in the 800xA system is done via the OPC Server interface
which is available in all 800xA nodes. The access is done via an OPC Client. It is
recommended that the OPC Client is run in the same node as the OPC server or at
least in another node on the Client Server Network. If the OPC Client and the OPC
Server are run in different nodes they will communicate with DCOM and DCOM is
not recommended to be run through a firewall.

210 3BSE034463R5001
Section 8 Network Security Accessing OPC Data from External Network

ODBC/OLE/DB Access of Data in the 800xA System

The Oracle database in the Information Manager server can be accessed from a node
outside the Automation System Network. To do this the external node needs to be
able to connect to the Information Manager Server via TCP port 1521.
The Information Manager Server also provides the Open Data Access interface
which can be used for accessing historical and process data. An external node using
this interface needs to be able to connect to the Information Manager Server via
TCP port 1706.

Using a 3rd Party Access Agent

For some 3rd party systems there are access agents that can be installed in a node on
the Client Server Network accessing data from the 800xA system and transporting it
to its main server via a protocol better designed for communication through a
firewall than what DCOM is, see Figure 100. This is in line with the
recommendation to establish connections from the inside instead of from the
outside, see Connect Inside-out Instead of Outside-in on page 194. The OPC
Tunneler from Matricon is an example of a sort of Access Agent. Another example
is that Aspentech has an access agent for their IP21 server.

Figure 100. Using an Access Agent through a Firewall

3BSE034463R5001 211
Asset Optimization Integrations Section 8 Network Security

Asset Optimization Integrations

There are a number of 3rd party systems for which there are integration
functionality available in the Asset Optimization package. These are:
• MAXIMO
A MAXIMO server can be connected to an external network.
It must be possible for the AO Server to reach the MAXIMO server via TCP
port 1099. Other 800xA nodes where the user will work with MAXIMO data
only communicate with the AO Server.
• DMS
A DMS server can be connected to an external network.
It must be possible to reach the external DMS Server via TCP port 80 from any
800xA node where the user will work with DMS Device Management Data
and it must be possible for the external DMS server to reach the AO Server via
TCP port 80.
• SAP/PM
An SAP server can be connected to an external network.
It must be possible for the AO Server to reach the SAP server via TCP port
3300. Other 800xA nodes where the user will work with SAP data only
communicate with the AO Server.
All Asset Optimization web services use TCP/IP port 80 by default.
Maximo and SAP Portal Views
Maximo and SAP portal views are function-related web pages viewed in a browser
and as such are subject to the security settings configured on the 800xA network.
The ability to access and view the web of the Maximo or SAP server is dependent
on the 800xA network configuration and the access privilege of the client machines
on each server in the network. A client browser must be able to "ping" a server in
order to have the first level of access to the server's web and data. In some networks,
a router must be used to allow clients in an 800xA system (nodes) to access servers
that are outside the network segment. In particular, servers that are located behind a
firewall, may require special access on TCP/IP port 80, or whatever port the HTTP
web service is configured to run on.

212 3BSE034463R5001
Section 8 Network Security Batch Integrations

Batch Integrations
With the function Batch Scheduling Interface it is possible for an external node to
access data from the Batch system. The Batch Scheduling Interface is installed on
one of the Batch client nodes in the 800xA system. The external node needs to be
able to communicate with that node via port 80.

Management of System Updates

Updates of software for the 800xA system, including operating systems, 800xA
software, libraries, and applications, are normally done via CD or DVD. Care
should be taken to verify that the CD/DVDs are of proper origin and do not contain
viruses.
Alternatively, updates could be downloaded from trusted servers on the Internet.
The following is an example of a process that could be used. The system
administrator for the 800xA system downloads updates from a trusted server on the
Internet to a node on the office network.
After verifying the authenticity of all downloads, e.g. by means of digital signatures,
and scanning them for viruses, the administrator makes them available on a
distribution server on the office network or in a demilitarized zone if such a
configuration is used.
From there they are accessed from e.g. an engineering workplace on the 800xA
client/server network. In this case the firewall must be set up to also allow this
traffic. Configure with a restricted host list, allowing access to the distribution
server only.
There are a number of different methods for file transfer from a server. FTP in active
mode can not be used through a firewall using NAT. FTP in passive mode may be
used, but it requires opening access from the 800xA node to the external server via
TCP port 21 and additionally all high TCP ports (above 1023). This is normally not
any major problem. It still follows the rule to access from the inside, but FTP uses
unencrypted passwords so it is better to use other protocols, e.g. HTTP, HTTPS or
SSH for file transfer.

3BSE034463R5001 213
Other Services to be Used Through a Firewall Section 8 Network Security

Other Services to be Used Through a Firewall

In addition to the services mentioned there are a number of other services that may
be needed to use through a firewall:
• DNS
If nodes on the 800xA system need to address external nodes by host name
DNS might be used, but this requires a configuration of the local DNS server
on the 800xA system network which is not the standard. It is normally
recommended to address any external node by its IP address.
If the external nodes need to be addresses by host name the local Domain
Controller needs to be able to communicate with an external DNS Server via
UDP port 53.
• E-mail for alarm alerting
If the Alarm server will be set up to send e-mails it needs to be able to
communicate with the external mail server via TCP port 25.
• Clock Synchronization via NTP or SNTP
If real time clocks in the 800xA system will be synchronized from an external
NTP or SNTP server the client node on the 800xA System network needs to be
able to communicate with the NTP server via UDP port 123.
• File transfers. See Management of System Updates on page 213.
• MMS
The client needs to be able to reach the server via TCP port 102.
• SattBus on TCP/IP uses UDP port 2999.

214 3BSE034463R5001
Section 8 Network Security Summary of Ports to Open in Firewalls

Summary of Ports to Open in Firewalls

Table 46 is a summary of ports that may need to be opened in a firewall between the
800xA system network and an external network:

Table 46. Summary of Port Numbers that may need to be opened

Function Server Ports Direction of Connection establishment

Microsoft Remote Desktop 3389/tcp (RDP) External Client -> 800xA Terminal Server
Citrix remote client 1494/tcp External Client -> 800xA Terminal Server
Citrix remote client 443/tcp (SSL) External Client -> 800xA Terminal Server
(secure connection)
Citrix web browser 80/tcp (HTTP) External Client -> 800xA Terminal Server
1494/tcp
Citrix Web Browser 80/tcp (HTTP) External Client -> 800xA Terminal Server
(secure connection) 443/tcp
VNC 5800/tcp (VNC)/ External Client -> 800xA node to control
5900/tcp (VNC)
PC Anywhere 5631/tcp and External Client -> 800xA node to control
5632/tcp
SMS & e-mail Messaging 25/tcp (SMTP) Aspect Server -> External Mail Server
IM, Multi-screen Display 19014- External Client -> IM Server
Interface and Desktop Trends 19017/tcp
Batch Schedule Interface 80/tcp (HTTP) External node -> Batch Client
AO, MAXIMO integration 1099/tcp AO Server -> MAXIMO Server
AO, DMS Calibration 80/tcp (HTTP) Device Management Client -> DMS Server
integration
80/tcp (HTTP) DMS Server -> AO Server

3BSE034463R5001 215
Summary of Ports to Open in Firewalls Section 8 Network Security

Table 46. (Continued)Summary of Port Numbers that may need to be opened

AO, SAP/PM integration 3300/tcp AO Server -> SAP Server

Clock Synchronization 123/udp (SNTP) Local Time Server -> External Time Server
Download of software 21/udp (FTP) Local File Server -> External File Server
updates via passive FTP >1023/udp
MMS 102/tcp Client -> Server
SattBus on TCP/IP 2999/udp Sender -> Receiver

216 3BSE034463R5001
 Appendix A Reference Details

IP Addresses
All nodes in the IndustrialIT System networks are identified by their IP Address.
IP stands for Internet Protocol. The IP address is a 32-bit word (4×8 bits) that often
is written in the form X.Y.Z.Q with four decimal numbers 0-255, separated by
periods.
The IP standard uses the terms NetID and HostID. The subnet mask specifies the
boundary between the NetID part and the HostID part of the IP address (the zero
bits indicate the HostID part). A (part of a) network where all nodes use the same
NetID is called a subnet.
Depending on the value of X, IP addresses are divided mainly into three classes,
A–C:

Table 47. IP Address Classes.

IP address in bit format XXXXXXXX.YYYYYYYY.ZZZZZZZZ.QQQQQQQQ

Class A NetID HostID
Class B NetID HostID
Class C NetID HostID

Value Possible host Default subnet

Class NetID HostID
of X IP addresses mask
A 1-126 X Y.Z.Q X.0.0.1-X.255.255.254 255.0.0.0
B 128-191 X.Y Z.Q X.Y.0.1-X.Y.255.254 255.255.0.0
C 192-223 X.Y.Z Q X.Y.Z.1-X.Y.Z.254 255.255.255.0

3BSE034463R5001 217
How to Choose IP Addresses Appendix A Reference Details

Example with 24 bit NetID and 8 bit HostID:

IP Address: 192. 16. 10. 56
Address mask: 255. 255. 255. 0
NetID: 192. 16. 10.
HostID : 56
The boundary between NetID and HostID does however not need to be at even byte-
boundaries.
Example with 22 bit NetID and 10 bit HostID:
IP Address: 172. 16. 5. 101
Address mask: 255. 255. 252. 0
NetID: 172. 16. 4.
HostID : 1. 101 (=256+101=357)
The 3:rd byte (=5) contains bits from both NetID and HostID.
What happens with the 2 last bytes is perhaps more clear in the binary notation:
IP Address 5. 101 = 0000 0101 0110 0101
Address mask252. 0 = 1111 1100 0000 0000
NetID: 4. 0 = 0000 0100 0000 0000
HostID : 1. 101 = 0000 0001 0110 0101
The address mask 255.255.252.0 is chosen for implicit RNRP configuration.
This is described in section Address Rules for Implicit RNRP Configuration on
page 54.
A common way to write an IP address including the information about the address
mask is X.Y.Z.Q/H. Where H is the number of bits in the NetID. The 2:nd example
above would be written 172.16.5.101/22.

How to Choose IP Addresses

The user must plan what IP addresses to use for all nodes in the system.

Choosing Address Space

The first thing to choose is the address space for the network. It is recommended to
use private addresses. This has the following advantages:

218 3BSE034463R5001
Appendix A Reference Details Using Implicit or Explicit RNRP Configuration

• There is no requirement to apply to the licensing authorities for an IP address,

i.e. it is easy to allocate a large IP address space.
• Some protection is gained against illegal access, because private addresses are
not permitted on the public Internet.
The following private addresses may be selected as “Default Network ID”1 when
using implicit RNRP configuration:
IP Class A addresses:
10. n*4. 0. 0 n= 0, 1, 2, , , , ,63
IP Class B addresses:
172. 16. 0. 0
172. 20. 0. 0
172. 24. 0. 0
172. 28. 0. 0
If Explicit RNRP configuration is used also the NetIDs between these can be used.

Using Implicit or Explicit RNRP Configuration

To simplify the configuration of RNRP it is recommended to use implicit RNRP
configuration. Explicit RNRP configuration must on the whole only be used if the
user has their own requirements on the network that do not allow implicit RNRP
configuration. The following criteria decide whether Implicit RNRP Configuration
can be used:
• The chosen address range must contain 2 complete Class B networks (one for
nonredundant) which means that all addresses available between N1.N2.0.0 to
N1.(N2+1).255.255 must be free to use.
• The Address Mask must be 255.255.252.0
• The following configuration parameters (see Table 47) must be the same for all
network interfaces in the node:
– Network Base Address
– Send Period

1. See RNRP Configuration Parameters on page 56

3BSE034463R5001 219
Using Implicit or Explicit RNRP Configuration Appendix A Reference Details

– Max number of lost messages

Using the implicit method has the following advantages compared to the explicit:
• Less manual configuration work has to be done.
• It decreases the risk of inconsistent configuration.
• If the default values for the configuration parameters can be used, NO manual
configuration of RNRP is necessary in the node. It is sufficient to configure the
IP address and the Address Mask.
With the Explicit Configuration method, specific RNRP configuration has to
be done in each node, in addition to the configuration of IP address and subnet
mask, even if many parameters can use default values.
An example of using the explicit method is in a node with both connections to the
normal Ethernet based Control Network and to a PPP link, since it is recommended
to use a Send Period greater than the default value for PPP links.
To use implicit RNRP configuration do as follows for each node:
1. Decide the RNRP address parameters.
2. Calculate the IP address based on the RNRP address parameters using one of
the formulas in Address Rules for Implicit RNRP Configuration on page 54.
Set the IP address and the Address Mask per interface.
(RNRP extracts the RNRP address parameters from the IP address)
To use the explicit address selection method do as follows for each node:
1. Decide the IP addresses.
2. Decide the RNRP address parameters.
3. Set the parameter “number of explicit addresses” to cover the appropriate
number of network interfaces.
4. Set the IP address and the Address Mask for each network interface.
5. Set the RNRP address parameters for each network interface.

220 3BSE034463R5001
Appendix A Reference Details Suggested Configuration of RNRP and IP Addresses

Suggested Configuration of RNRP and IP Addresses

Below are some principles to follow when choosing the addresses.
There are no requirements on what addresses to set on what nodes in the system, but
these are some suggestions of how to organize the network:
• Use addresses that allow implicit RNRP configuration if possible1(see RNRP
Address Configuration: Implicit or Explicit on page 52).
Use the private base address 172.16.0.0 if possible
(see Choosing IP Addresses (A.5.3) on page 15).
• Define address groups for similar types of nodes used in the system.
Define these groups with spare addresses for future extensions of the system.
Use the same group definitions on all network areas, e.g. let node number 101
always be reserved for a Workplace Client and 201 for a Controller.
• Nodes that connect to several Network Areas (typically Connectivity Servers)
must use the same Node number on the different networks.
• Use the default rule for the address of Backup Controllers
(see IP Addresses for Redundant Nodes on page 15).
• For systems where it is unlikely that there will be more than 256 nodes, use
node numbers less than 256. This way the last byte in the IP address will
correspond to the node number.
(Address Rules for Implicit RNRP Configuration on page 54 describes how to
calculate IP addresses based on RNRP parameters.)

IP Addresses for Redundant Controller Nodes

All nodes on the network need a unique IP address. This is true also for all nodes
with unit redundancy like for example redundant servers or controllers with CPU
redundancy.
In case of redundant servers each node always has its own IP address. There is no
special rule about how to choose the addresses for the redundant servers.
In case of redundant AC 800M controllers the Primary CPU always works with the
primary IP addresses. In case of a switch-over, the addresses are also switched. The
addresses of the Backup CPU can be configured arbitrarily, but to simplify the
configuration there is a default rule for it:
1. “If possible” means “if the user does not have any contradicting requirements on the network” e.g. using PPP.

3BSE034463R5001 221
Configuring IP Addresses with DHCP Appendix A Reference Details

The default addresses of a Backup CPU is the same addresses as the backup except
that: BackupNodeNumber = PrimaryNodeNumber + 512.
Note that this is an exception to the rule that node numbers can not be higher than
500.
Byte wise this means that if the address of the Primary is A.B.C.D the address of the
Backup is: A.B.C+2.D

Configuring IP Addresses with DHCP

This is not the recommended method but can be chosen by advanced users.

If implicit RNRP configuration is used and all RNRP configuration parameters can
use the default values, it could even be considered to use a DHCP server to
distribute the IP addresses for Windows nodes (not for the Domain Server and DNS
server). If explicit RNRP configuration is used manual configuration is anyway
needed on each node, i.e. you do not gain anything with using DHCP.
To use a DHCP server for an RNRP network the server has to be explicitly
configured with the relations between MAC-address and IP address. It is not
possible to run DHCP with actual dynamic allocation of IP addresses for the 800xA
System nodes. One reason is that a DHCP server has no possibility to apply the
address rules of RNRP.

Pros and Cons with DHCP:

+ In most nodes no network interface configuration at all is needed. The IP address
is given by the DHCP server and RNRP calculates its address parameters from the
IP addresses and uses the default values for the other parameters.
- The MAC address has to be known and the configuration in the DHCP server has
to be changed, if a network adapter card is exchanged.
- If any of the RNRP configuration parameters have to be different from the default
values, the interface has to be configured manually in the node. Then it is probably
easier to also configure the IP address locally on the node instead of using DHCP.

222 3BSE034463R5001
 INDEX
Numerics Client/Server Network 21
800xA for AC 800M 106 Clients allowed to set Time 129
800xA for AC 800M Time Adaptor 96 CLK_MAST 136
800xA for Advant Master 106 CLK_SEND 136
800xA for Harmony 106 CLOCK_SYNCH 120, 136
Adjusting Time 151 CNCP 120
Clock Sync 138 Communication
SettingTime 151 Broadcast 42
800xA for Melody 106 Multicast 42
Adjusting Time 151 Connectivity Server 90
Clock Sync 139 as Routers 47
Setting Time 151 using RNRP 23
Control Network 21
A CPU Redundancy 187, 221
Adapters and Bindings 87 CS CNCP ClockMasterOrderNo 118
Address Space 218 CS Protocol Type 118
AfwTime 144 CS SNTP ServerAddr1 118
AfwTime Client 132 CS SNTP ServerAddr2 118
AfwTime Server 130 CS Synch Interval 118
AfwTime Service 126 CS Time Set Enabled 118, 147
Local Time Service 96
Allowed to Set Time 133 D
Aspect Server 90 Data Recover Time 45
Daylight Saving Time 141
B Support 141
Backup CPU 91, 221 Defense in depth 190
Base Address 54 DHCP 222
DNS 74, 89
Configuration 83, 93
C
Introduction 34
Cable Color 185
Parameters 73
CAT5 178
Queries 34
CI855 107, 111
Server 34, 78
Class A 217
Strategies 71
Class B 217
Domain Controllers 71, 143
Class C 217

3BSE034463R5001 223
Index

Introduction 33 LOC_TIME 136

Domain Name 71 Local Network Area 51
Duplex 177 Local Time Source 96

E M
Ethernet 173 MAC-address 222
MaxLostMessages 45
F MB 300 107
Fault Handling 44 as Clock Master 111
Firewalls 192 Clock Synchronization 124
Application Proxies 193 via CI855 119
Packet Filtering 192 MMS Time Synchronization 126
Stateful Inspection 193 MPLS 66
flushdns 93 Multi-mode fiber 183
Forward Lookup 91
N
G NetBIOS 72
GPS 122 Configuration 93
GPS Receiver 100 Considerations 73
NetID 217
H NetID part 52
Hop Count 46, 49 NetRemoteTOD 129
HostID 217 Network Address Translation (NAT). 194
HostID Part 52 Network Area 43
Hubs 174 Network Area Number 43
Network Areas 22
Network Fail over Time 45
I
Network Interfaces 86
IGMP Snooping 176
Network Redundancy 41
Interface Status 165
Introduction 26
Internet Protocol 217
Primary Network 26
IP Address 52, 217
Secondary Network 26
IP Address Plan 28
Network Security 189
IP Routers 63
Network Segment 174
ipconfig 93
Node Administration structure 155
IPSec 67
Node down 161
Node Number 43
L Node up 161
Layer 2 VPN 66 nslookup 91
Layer 3 VPN 67

224 3BSE034463R5001
 Index

O Server Group 130

OPC Server 126, 177 Server running 129
Service Handler 126
P Service Provider 126
Path Number 43 SetDT 149
Ping 161 Shielded Twisted Pair (STP) 178
Plant Network 21 SNMP 177
PPP 25 Network Management 169
Primary CPU 221 SNTP 122
Private Address Space 27 SNTP Server 100, 142
Private Addresses 218 Spanning Tree 176
Store-and-forward delay 175
STP Cable 183
Q
Subnet Mask 217
Quality of Service 176
Switches 174
System Status Providers 155
R System Status Viewer 155, 169
Redundant Controller 221
registerdns 93
T
Reverse Lookup 92
TCP/IP Forwarding 69
REVERSED_SYNC_MODE 136
Time Adaptor
Ring Redundancy 180
AC 800M 135
RJ-45 178
Advant Master 135
RMON 177
Time Adaptors 134
RNRP 41
Time Client 126
Base Parameters 57
Time Server 126
Explicit Paramters 60
Time Set 147
Network Monitor 70, 161
Time Synch Running 133
Tunnel Areas 63
TimeServerHandler
RNRP Configuration
Aspect 132
Implicit 53
Trusted Network Zones 190
RNRP icon 162
TSP 138
Router
Redundant 48
Routers 188 W
RTA Board 120 W32Time 144, 150
Clock Synchronization 136 w32tm 150
WAN 62
Windows system tray 162
S
Windows Time Service 123, 139 to 140, 143
Send Period 45

3BSE034463R5001 225
 Index

3BSE034463R5001 226
3BSE034463R5001. Printed in Sweden September 2006
Copyright © 2003-2006 by ABB. All Rights Reserved
® Registered Trademark of ABB.
™ Trademark of ABB.

http://www.abb.com

Automation Technology Products Automation Technology Products Automation Technology Products

Wickliffe, Ohio, USA Västerås, Sweden Mannheim, Germany
www.abb.com/controlsystems www.abb.com/controlsystems www.abb.de/controlsystems