GE Fanuc Automation

CIMPLICITY® Monitoring and Control Products

CIMPLICITY HMI
for Windows NT and Windows 95

Server Redundancy
Operation Manual

GFK-1353B October 1997

 GFL-002

Warning notices are used in this publication to emphasize that hazardous voltages, currents, temperatures, or other
conditions that could cause personal injury exist in the equipment or may be associated with its use.
In situations where inattention could cause either personal injury or damage to equipment, a Warning notice is used.

Caution notices are used where equipment might be damaged if care is not taken.
Note
Notes merely call attention to information that is especially significant to understanding and operating the equipment.

This document is based on information available at the time of publication. While efforts have been made to be accurate,
the information contained herein does not purport to cover all details or variations in hardware or software, not to provide
for every possible contingency in connection with installation, operation, or maintenance. Features may be described
herein which are not present in all hardware and software systems. GE Fanuc Automation assumes no obligation of
notice to holders of this document with respect to changes subsequently made.
GE Fanuc Automation makes no representation of warranty, expressed, implied, or statutory with respect to, and assumes
no responsibility for the accuracy, completeness, sufficiency, or usefulness of the information contained herein. No
warranties of merchantability or fitness for purpose shall apply.

CIMPLICITY is a registered trademark of GE Fanuc Automation North America, Inc.

Windows is a registered trademark and NT is a trademark of Microsoft Corporation

This manual was produced using Doc-To-Help®, by WexTech Systems, Inc.

Copyright 1996-1997 GE Fanuc Automation North America, Inc.

All rights reserved
Preface

Content of this Manual

Chapter 1. Introduction. Describes CIMPLICITY functionality and discusses the
various type of redundancy.
Chapter 2. CIMPLICITY Server Redundancy. Discusses the types of nodes used
for CIMPLICITY Server Redundancy and summarizes redundant system behavior.
Chapter 3. Hardware Requirements. Documents the hardware requirements for
CIMPLICITY Server Redundancy.
Chapter 4. Redundancy Configuration Procedures. Shows the configuration
procedures that support CIMPLICITY Server Redundancy.
Chapter 5. Recovery Procedures. Documents the recovery procedures for
CIMPLICITY Server Redundancy.
Appendix A. Supported Communication Interfaces. Discusses the
communication interfaces supported by CIMPLICITY Server Redundancy.
Appendix B. Configuration Parameters. Documents the configuration parameters
needed for CIMPLICITY Server Redundancy.

Related Publications
For more information, refer to these publications:
CIMPLICITY HMI for Windows NT and Windows 95 Base System User’s Manual
(GFK-1180). This book describes all the basic features of the CIMPLICITY HMI
for Windows NT and Windows 95 product.
CIMPLICITY HMI for Windows NT and Windows 95 Device Communications
Manual (GFK-1181). This book documents all the device communication enablers
for the CIMPLICITY HMI for Windows NT and Windows 95 product.

We Welcome Your Comments and Suggestions

At GE Fanuc Automation, we strive to produce quality technical documentation.
After you have used this manual, please take a few moments to complete and return
the Reader’s Comment Card located on the next page.

GFK-1353 iii
Contents
Introduction 1-1
Introduction............................................................................................................................ 1-1
Levels of Redundancy ............................................................................................................ 1-1
PLC Redundancy ..................................................................................................... 1-2
Cabling Redundancy ................................................................................................ 1-2
Server Redundancy .................................................................................................. 1-3
Computer Network Redundancy .............................................................................. 1-3
Redundancy in CIMPLICITY HMI ....................................................................................... 1-3

CIMPLICITY Server Redundancy 2-1

Types of CIMPLICITY HMI Nodes ...................................................................................... 2-1
Limitations on Functionality .................................................................................................. 2-2
CIMPLICITY Server Redundancy Overview ........................................................................ 2-3
Operation ................................................................................................................. 2-3
Limitations on Failure Recovery.............................................................................. 2-4
Startup/Shutdown Order .......................................................................................... 2-4
Redundant System Behavior .................................................................................................. 2-5
Configuration ........................................................................................................... 2-5
Data Collection ........................................................................................................ 2-5
Unsolicited Data ...................................................................................................... 2-6
Identification of Active Primary Node..................................................................... 2-6
Setpoints .................................................................................................................. 2-6
Database Logging .................................................................................................... 2-7
Alarm Management.................................................................................................. 2-7
User Registration ..................................................................................................... 2-7
CimView.................................................................................................................. 2-7
User Interfaces ....................................................................................................................... 2-8
Failover .................................................................................................................................. 2-8

Hardware Requirements 3-1

About Hardware Requirements .............................................................................................. 3-1

Redundancy Configuration Procedures 4-1

About Redundancy Configuration Procedures ....................................................................... 4-1
Configuration Functions........................................................................................... 4-1
Network Configuration ............................................................................................ 4-2
Devcom Configuration............................................................................................. 4-2
Global Point Configuration...................................................................................... 4-2

GFK-1353 v
 Recovery Procedures 5-1
Normal Operating Procedures ................................................................................................ 5-1
Startup and Shutdown .............................................................................................. 5-1
Server Failure ................................................................................................................. ........ 5-2
System Operation During Failover ......................................................................................... 5-3
Device Communications and Point Management..................................................... 5-3
Alarm Management.................................................................................................. 5-3
User Logons ............................................................................................................. 5-3
Runtime Interfaces ................................................................................................... 5-4
Resetting the Primary Server after Recovery.......................................................................... 5-4
Resynchronizing Database Logging Files............................................................................... 5-5
Failure Exceptions.................................................................................................................. 5-6
Process Failures ....................................................................................................... 5-6
Network Failures...................................................................................................... 5-6

Appendix A - Supported Communication Interfaces A-1

About Supported Communication Interfaces......................................................................... A-1
Series 90 TCP/IP Communications ....................................................................................... A-2
Series 90 TCP/IP Redundancy Communications .................................................................. A-2
CCM2 Communications ........................................................................................................ A-3
Genius Communications........................................................................................................ A-3
SNPX Communications......................................................................................................... A-4
Allen-Bradley Communications ............................................................................................ A-4
Allen-Bradley Data Highway Plus Communications............................................................. A-5
APPLICOM Communications............................................................................................... A-5
DDE Client Communications ................................................................................................ A-5
Modbus Plus Communications .............................................................................................. A-6
Modbus RTU Communications............................................................................................. A-6
Modbus TCP/IP Communications......................................................................................... A-7

Appendix B - Configuration Parameters B-1

Failover Rate Configuration .................................................................................................. B-1
User Registration Synchronization ........................................................................................ B-2
Slave Startup Timeout ........................................................................................................... B-2
TCP/IP Keep Alives .............................................................................................................. B-3
Windows NT ........................................................................................................... B-3
Windows 95 ............................................................................................................ B-4

Index i

vi CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Introduction

Introduction
This chapter provides a brief introduction to redundancy in monitoring and control
applications.

Levels of Redundancy
The principle of redundancy in automated systems provides for switchover of
functionality to a backup component in case of failure of a primary component. The
switchover is considered automatic if no operator intervention is required.
Redundancy applies to both hardware and software, and implies minimal loss of
continuity during the transfer of control between primary (active) and redundant
(backup) components. Redundant systems reduce single points of failure, preventing
loss of functionality.
For cell control systems, the major levels of redundancy include:
• PLC
• PLC LAN or serial connections to server
• Computer networks
• Computer
Each level of redundancy provides a failover system that allows continuous system
activity with minimal loss of data. The following sections briefly describe each level.

GFK-1353 1-1
 PLC Redundancy
PLC redundancy lets control transfer from a primary programmable controller to a
redundant one in case of failure.

When the primary PLC comes back on line, control can be transferred from the
redundant PLC back to the primary with minimal loss of data.
The redundancy can be synchronous or independent. Synchronous systems
coordinate control and handling of data between CPUs of the active and backup
units, while in independent systems each PLC acts like an active unit and is not
constrained by the others.
Some CIMPLICITY HMI communication options support PLC redundancy. See the
CIMPLICITY HMI for Windows NT and Windows 95 Device Communications
Manual (GFK-1181) for more information.

Cabling Redundancy
Cabling redundancy involves separate physical connections to the same device.

The devices can be on a LAN (GENIUS, MAP, etc.) or may require serial
connections (SNP, CCM, etc.). Redundant cabling provides an alternate
communication path to the device if the association with the host computer is lost due
to failure of the primary path. The implementation of cable redundancy with respect
to host monitoring/control systems differs with the device protocol involved.
Some CIMPLICITY HMI communication options support cabling redundancy. See
the CIMPLICITY HMI for Windows NT and Windows 95 Device Communications
Manual (GFK-1181) for more information.

1-2 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
 Server Redundancy
Server redundancy involves a primary factory monitoring server and a redundant
"Hot Standby" server.

The redundant server is essentially a mirror image of the primary server, running
alternate monitoring/control processes and applications. Data collection is performed
via independent or shared network paths to the same devices, depending on the
protocol. The characteristics of the selected communications protocol(s) determine
the details of the configuration.
Upon detection of failure of the primary server, the secondary server can assume
control of data collection, alarm functions, applications, and allow user access with
minimal loss of continuity. When the primary server comes back on line, control can
be transferred back, and the secondary server will resume its backup role.

Computer Network Redundancy

Computer network redundancy is similar to cabling redundancy, except it covers
computer to computer communications rather than computer to programmable
controller. Computer network redundancy provides an alternate network path in case
of failure of the primary network.

Redundancy in CIMPLICITY HMI

Server Redundancy is fully integrated with CIMPLICITY HMI software’s Base
System Functionality, enhancing its already powerful monitoring capability in a full
range of computer-integrated manufacturing environments.
In the CIMPLICITY HMI system, redundant features are integrated into Point
Management (PTM) and Device Communications (Devcoms), User Registration
(UR) and Alarm Management (AM). The focus of redundancy in CIMPLICITY
HMI software centers on data collection, applications driven by these data, alarms,
and users accessing these applications. These functions are given primary
consideration when integrating levels of redundancy within CIMPLICITY HMI
software.

GFK-1353 Introduction 1-3

CIMPLICITY Server Redundancy

Types of CIMPLICITY HMI Nodes

For CIMPLICITY Server Redundancy, there are two types of computers; the primary
server and the secondary server.

A Primary Server is the Server that normally takes the primary role in a redundant
configuration. The master configuration node is the Primary Server. Each Primary
Server has one Secondary Server.
A Secondary Server is essentially a mirror image of the Primary Server. It runs the
same version of the software as the Primary Server and communicates to the same
devices. When the Primary Server fails, the Secondary Server assumes control of
any functions that normally run on the Primary Server. A Secondary Server cannot
be a master configuration node, and does not support any configuration functions.

GFK-1353 2-1
Limitations on Functionality
The following limitations apply for Server Redundancy:
• You may not use the Multiple Projects feature on the redundant servers.
• You may not use the Enterprise Server capability.
• You may not use Point Bridge device communications.
• Viewer Development is not supported.
• Dynamic updates are not supported for the Event Manager.
• Failover is not supported for Viewers in the following cases:
• BCEUI displays
• CimView screens with embedded Recipe objects
• CimView screens with embedded SPC objects
• CimView screens with embedded Historical Data Analyzer objects
• Computers that use a Remote Access Server (RAS) or a Wide Area
Network (WAN) connection
• Show Users displays
• Viewers must have local copies of CimView screens to operate
following a failover.
• If you are looking at logged data for Trending, SPC or the Historical
Data Analyzer on the primary server and the primary server fails, you
will have to switch to the secondary data source to continue viewing the
logged data.
• For Trending, point buffering information is lost on failover.
• Recipes are not supported in redundant configurations.
• SPC is not supported in redundant configurations.
• Configuration changes that cannot be made dynamically require the
project to be shut down, updated and restarted.
• Tracker is not supported in redundant configurations.
• During failover, device values are not read and setpoints to devices are
not written. Benchmark failover period is 5 seconds for 2000 points on
a P5-133 MHz computer.

2-2 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
CIMPLICITY Server Redundancy Overview
CIMPLICITY Server Redundancy provides server redundancy. A secondary server
may be configured to take over the data acquisition, alarming, and viewer support of
the primary server.

Operation
The following rules describe the overall operation of a redundant system:
• While both the primary and secondary servers are running, the
secondary server may be accessed for two purposes:
• To validate that the secondary server is functioning properly and
will be capable of taking over the functions of the primary
• To provide additional computing capacity where functions on the
primary node are inadequate for performing a task such as
displaying CimView or Alarm Viewer screens.
• Alarm Management and User Registration are configured to run on the
redundant pair. Thus, both the primary and secondary servers will have
identical run-time data.
• When both servers are operating, point and alarm data are maintained
on the active primary and continuously updated on the secondary
server.
• Point data collection is performed by device communications
modules on the primary server. Device communication modules on
the secondary server establish communications to devices, but do
not poll for data until the primary server is lost.
• Alarm Management, Point Management, and User Registration on
the primary server forward updates to their corresponding
processes on the secondary server.
• Manual alarm acknowledgments, deletions, and resets invoked
from processes on a secondary server are routed to the Alarm
Manager on the primary server.
• Manually invoked setpoints and manually invoked Modify/Restore
and Disable/Enable alarm requests from processes on the
secondary server will be routed to the Point Manager on the
primary server (the primary Point Manager).

GFK-1353 CIMPLICITY Server Redundancy 2-3

 • The data collection, Alarm Management, Point Management, and
User Registration functions run in parallel (kept in sync) with their
Server Redundant partners.
• An alarm is generated when any node in the system fails.
• Alarm Management and User Registration on the secondary server
become the masters when the primary server fails or becomes
unreachable.
• Time synchronization between the primary server CPU and secondary
server CPU is the responsibility of the CIMPLICITY system manager.
• No configuration functions are supported on the secondary server. All
configuration changes must be made on the primary server and are
transferred to the secondary server by the Configuration Update
function.

Limitations on Failure Recovery

CIMPLICITY Server Redundancy will not cover the following failures:
• Loss of data due to failure of a single component involved in data
collection.
If a cable or LAN interface fails, CIMPLICITY software detects the
problem, but it will not automatically start collecting data on the
secondary server. Under these circumstances, a user may choose to
shut down the primary server to allow the secondary server to take over.
• Loss of the communications link between CIMPLICITY primary and
secondary servers.
If the link is lost, both servers will act as the primary server. The secondary
server will need to be shut down, and the network repaired.
CIMPLICITY software can then be restarted on the secondary server.

Startup/Shutdown Order
To prevent operational anomalies, the startup and shutdown procedures that can be
accessed from the Configuration cabinet will always prompt to start a primary server
prior to starting the corresponding secondary server.
The shutdown procedures that can be accessed from the Configuration cabinet will
stop the secondary server before stopping the corresponding primary server.
When the servers are started in this way, resynchronization of processes and data
files will automatically take place.
The project on the primary server can be started or stopped through its Configuration
cabinet.
To stop or start the project on the secondary server, use the CIMPLICITY Startup
Options.

2-4 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Redundant System Behavior
CIMPLICITY servers can be configured as redundant pairs. This section discusses
how the various CIMPLICITY processes behave when they run in a redundant
configuration.

Configuration
Configuration is supported on the primary server. Configuration cannot be run on the
secondary server.

Data Collection
A runtime Point Management database that holds current data values is maintained
on the primary server and duplicated on the secondary server. The primary Point
Manager processes point updates from Device Communication and the Virtual Point
Process on the primary server, and from all manual and automatic control functions,
then sends updates to the secondary Point Manager.
If device communications modules are running on the primary server, the
corresponding modules also run on the secondary server. While the primary server is
running, the device communication modules on the secondary server will operate in
standby mode to minimize the impact of redundant data collection on the
communications LAN or the programmable controller.
When the primary server terminates, the secondary Point Manager automatically
begins receiving its updates from the Device Communications and Virtual Point
Process on the secondary server and from all manual and automatic control functions.
The Device Communications on the secondary server reads all point values as if the
system is restarting, and reports all point data to the Point Manager.
Note

Applications affected by duplicated point values are not supported.

When the primary server is restarted, resynchronization takes place:

• Point data managed by the secondary Point Manager is sent to the Point
Manager on the primary server.
• The Point Manager and Device Communications on the primary server
do not take over the primary functionality until the CIMPLICITY
System Manager issues a manual command.
• When the manual command is issued from the primary server, the Point
Manager and device communication modules on the primary server
assume primary roles, and the Point Manager and device
communication modules on the secondary server to resume standby
roles.

GFK-1353 CIMPLICITY Server Redundancy 2-5

 Unsolicited Data
Unsolicited data reported from factory devices is processed by the Device
Communications module to which it is sent. In order for unsolicited data to be
processed by the secondary Device Communications/Point Manager when the
primary server fails, unsolicited information must be directed to the secondary server
in addition to the primary node.

Identification of Active Primary Node

For Point Managers operating on redundant pairs, global points can be configured to
track the current operating status of the primary and secondary servers. The primary
server is represented by a digital point with the name:
MASTER_PTM_RP

The secondary server is represented by a digital point with the name:

SLAVE_PTM_RP

A value of "1" means that the node is the current primary server, and "0" means that
the node is the current secondary server. The points are updated only by the primary
Point Manager when a server loss or secondary-to-primary mode switch occurs.
Note

The CIMPLICITY System Manager must configure the above global points.

Setpoints
Users can make setpoint requests via Point Control Panel, CimView, and user-written
interfaces on either the primary server or the secondary server. While the primary
server is running, all setpoints from the secondary server will be routed to the
primary server for processing.
The Event Manager can run on both the primary and secondary servers. However,
while the primary server is running, setpoints originating from automatic control
functions running on the secondary server are ignored.
If you are using any Point Management API functions that involve setpoints or
automatic control functions, you must configure redundant processes on the primary
and secondary servers so that the primary Point Manager can properly filter out
setpoints originating from the secondary server.

2-6 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
 Database Logging
If a server that does Database Logging is made redundant, then point and group
logging will occur independently on the primary and secondary servers. This means
that independent databases exist on both the primary and secondary servers and the
primary server performs database logging to the primary database while the
secondary server performs identical logging to an independent database on the
secondary server.
For point and group logging, there may be slight differences in time-initiated logging
due to variances in CPU synchronization. In addition, when either of the servers fail,
or is shut down, the data may need to be synchronized. You may also need to
synchronize data when a server is restarted.
To configure redundant Database Logging:
• You must configure all of the data sources with the ODBC
Administrator on the primary server.
• You must configure only the data sources used as slave data sources
with the ODBC Administrator on the secondary server.
• In the Database Logger, the Logging Properties will have four (4)
pages to allow you to configure Alarm Logging and Point Logging on
both the primary and secondary servers.
• The dbmsdef.idt file will have four (4) entries in it.
• You only have to configure logging on the Primary server. All logging
configuration data is automatically copied to the secondary server.
Viewer applications, such as Trending, that use logged data from a server will not fail
over to the database on the redundant server.

Alarm Management
The Alarm Manager on the primary server receives its updates from CIMPLICITY
services on both the primary and secondary servers. CIMPLICITY applications that
generate alarms (Point Management, SPC, etc.) will not generate alarms when the
corresponding application is running on the primary server. Exceptions to this rule
are device communications, process down, and node lost alarms.

User Registration
A runtime database for users is maintained by User Registration on the primary
server. This information is passed to User Registration on the secondary server.

CimView
CimView applications running on primary servers or Viewers will receive point
updates from the primary Point Manager. CimView applications running on
secondary servers receive updates from the Point Manager running on the secondary
server. All setpoints are routed to the primary Point Manager. When the primary
server is lost, CimView applications on Viewers automatically begin receiving
updates from the secondary Point Manager.
Controls on CimView screens that use logged data will not fail over to the database
on the redundant server.

GFK-1353 CIMPLICITY Server Redundancy 2-7

User Interfaces
The following configurations are supported:
• You can run CimView, Alarm Viewer and Point Control Panel on the
primary or secondary servers to access the functions on that node. If
you are running on the primary server and it fails, you will have to shift
over to the secondary server, log in, and start the user interface.
• You can run the CIMPLICITY HMI user interface on a Viewer. You
will be connected to the current primary server. If the connection to the
CIMPLICITY HMI computer is lost, the Viewer will switch to the new
primary server.
Users running the CIMPLICITY HMI user interface on a primary server or Viewer
always access functions on the primary server.

Failover
CIMPLICITY Interprocess Communications (the TCP router) has a built-in probing
mechanism, independent of TCP/IP’s network probing mechanism. This was
introduced so that you can configure a smaller failover period than the TCP/IP
default timeout period of 2 hours. This expedites detection of a failed node for
Server Redundancy. Implementation of the probing mechanism is done by specifying
the following global parameters:
REDUND_PROBE_DELAY
REDUND_PROBE_COUNT
REDUND_PROBE_PORT
in your project's glb_parms file. These parameters define the length of time that it
will take to detect a communication loss between redundant servers. The length of
time, in seconds, is calculated using the following formula:
REDUND_PROBE_DELAY * (REDUND_PROBE_COUNT+1)

The potential data loss in the system is defined by the timeout period.
You must also configure TCP/IP Keep Alives on both the primary and secondary
servers as well as any Viewers that will connect to the redundant system.

2-8 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Hardware Requirements

About Hardware Requirements

Because the secondary server in a redundant pair will be set up to run exactly the
same functions (except for configuration functions) as the primary server, the
secondary server in a redundant pair must be identical to the primary server; that is,
the disk, memory, and input/output peripherals should be identical.
Cabling to devices may place the primary and redundant servers on the same or
different cables. The type of cabling used will depend on the requirements of the
device. Communications interface software supported by CIMPLICITY Server
Redundancy attempts to minimize network traffic to and from the secondary server.
You can connect a device to redundant servers via different cables:

Or you can connect a device to redundant servers on the same cable:

GFK-1353 3-1
Redundancy Configuration
Procedures

About Redundancy Configuration Procedures

This chapter documents the configuration procedures needed to support Server
Redundancy for CIMPLICITY HMI for Windows NT.
It is assumed that the same version of CIMPLICITY HMI software has been installed
on both servers of each redundant pair as described in the CIMPLICITY HMI for
Windows NT and Windows 95 Base System User Manual (GFK-1180).

Configuration Functions
From the Project/Settings... dialog select the Server Redundancy option. This will
enable the Redundancy property page.

GFK-1353 4-1
 Enter the following information on the Redundancy property page:
Computer name Enter the name of the secondary Server.
Project path Enter the directory on the secondary Server where the
CIMPLICITY project will be stored.
UNC filenames are not supported.
Configuration files and screens are copied from the primary server to the Project path
whenever a Configuration Update is performed.

Network Configuration
The IP addresses for the primary and secondary servers must be configured in the
Host files of the primary server, the secondary server, and all Viewers.

Devcom Configuration
Ports that have been configured for serial device communications on the primary
server are automatically configured for the secondary server. However, specific
Device Communications hardware configuration, done through device or port
configuration, must be performed on each server for proper system device
management.

Global Point Configuration

You may configure global points to track redundant server status during system
operation. The points have the following requirements:
• The naming convention is MASTER_PTM_RP for the primary server
and SLAVE_PTM_RP for the secondary server.
• The Calc Type for the point is GLOBAL.
A point will take on a value of "1" if the server it represents is currently operating as
the primary server, and will take on a value of "0" if the server is the secondary
server. The values will only be changed by the current primary Point Manager. This
implies that point updates will occur:
• Whenever there is a redundant server failure
• When redundant servers are synchronized at startup
• When an orderly transition from secondary to primary server occurs.

4-2 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Recovery Procedures

Normal Operating Procedures

Startup and Shutdown

When all hardware is working correctly, CIMPLICITY software can be started and
shut down using the Run and Stop items in the Project menu of Configuration
cabinet on the primary server.

Project Start
When you select Start, the Redundant project start dialog box opens.

Select one of the following:

• Master & Slave to start the project on both the primary and secondary
servers.
• Master only to start the project only on the primary server.
• Slave only to start the project only on the secondary server.
then select Start to start the project.

GFK-1353 5-1
 Project Stop
When you select Stop, the Redundant project stop dialog box opens.

Select one of the following:

• Master & Slave to stop the project on both the primary and secondary
servers.
• Master only to stop the project only on the primary server.
• Slave only to stop the project only on the secondary server.
then select Stop to stop the project.

Server Failure
Server failure may be due to:
• CIMPLICITY software shutdown on either server
• Network failure between the primary and secondary servers
• Loss of server due to loss of power or equipment failure
Server failure is detected by the IPC Router, the communications process that runs on
each server.
• The Router sets up links to each server in the system and sends
messages to each node at a set interval. The probe interval is defined in
REDUND_PROBE_DELAY which is set to 1000 milliseconds by
default.
• If no reply is received from the server for a set number of tries (defined
in REDUND_PROBE_COUNT) the server is then declared to have
failed and the Router sends a "Partner Dead" message to any processes
that have outstanding messages to processes on that server.
Server failure may be detected on a primary server, secondary server or Viewer.
• When a secondary server fails, functionality is not lost, because all
functions are also running on the primary server.
• When a primary server fails, the secondary server initiates procedures
to take over redundant CIMPLICITY functions.

5-2 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
System Operation During Failover
When the primary server of a redundant pair fails, the following will automatically
occur:

Device Communications and Point Management

Device Communications on the secondary server begins actively polling for data and
passes point data to the Point Manager on the secondary server, which now becomes
the primary Point Manager. Any viewer process that was connected to the original
primary Point Manager will automatically switch over to the new primary Point
Manager, which will now assume all supervisory and control functions.
Note

Between the time that the primary server is lost and before the secondary server takes
over, users may notice an interruption in system performance. During this time, point
values will not be updated, setpoints and alarm acknowledgments will not complete,
and users will not be able to log on or off.

Alarm Management
The Alarm Manager on the secondary server becomes the primary Alarm Manager.
No alarm data is lost because the Alarm Manager on the primary server continually
updated the alarm list for the Alarm Manager on the secondary server. The new
primary Alarm Manager will now process all alarm updates and provide alarm
information to all interested processes.

User Logons
The User Registration process on the secondary server becomes the primary User
Registration process. No user registration data is lost because User Registration on
the primary server continually updated the user list for User Registration on the
secondary server. The new primary User Registration will now process all user
logins and logouts and provide information on user views.

GFK-1353 Recovery Procedures 5-3

 Runtime Interfaces
When the primary server fails, all CimView, Alarm Viewer and Point Control Panel
sessions running on that server are lost.
• CIMPLICITY user interface accessed from console on the primary
server.
When the primary server fails, this console is no longer usable. The user
will have to move to the console on the secondary server, log in, and
access the CIMPLICITY user interface from there.
• CIMPLICITY user interface accessed from a Viewer.
The user interfaces will failover to the new master.

Resetting the Primary Server after Recovery

After a primary server has failed and recovered, processes on the secondary server
need to be told that the primary sever is now available.
To reset the primary server on CIMPLICITY :
• Make sure that CIMPLICITY software is running on the primary and
secondary servers.
Note

The Alarm Manager and User Registration on the primary and secondary servers will
automatically resynchronize themselves to their primary and secondary roles when
the primary server initially comes on line.

• Start a project’s Configuration cabinet on the primary server.

• Select the Tools menu
• Select Command Prompt....
• Execute the following command:
ptmrp_msx <primary_name> MAC_PTM
where <primary_name> is the name of the primary server.
The following will occur as part of the reset:
• Device communications modules on the secondary server will stop
collecting data and return to standby mode.
• The Point Manager on the secondary server resumes its secondary role.
• All viewer applications will automatically resynchronize to the primary
Point Manager.
• The Point Manager on the primary server will resume its primary role,
and will initiate device communications modules on the primary server
to start collecting data.

5-4 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Resynchronizing Database Logging Files
The Database Logger uses ODBC database tables to store historical data. For Server
redundancy, the same database tables are created on the primary and secondary
servers.
Note

If you intend to use the Database Logger in a Server Redundant system, you should
set the system times of the primary and secondary servers to be as close as possible.

When one of the servers in the redundant pair goes down, a

ptnr_<timestamp>.log file is generated in the project’s \log directory, where
<timestamp> is the date and time the file was created. This file contains the time
the partner server went down and the time the partner server came back up. These
files are used to synchronize the databases.
To synchronize the databases on the primary and secondary nodes, do the following
on the primary server:
Note

You can only run datamerge.exe on the primary server - that is, the server that
has all of the ODBC datasources defined.

1. Open the project’s Configuration cabinet.

2. From the Tools menu, select Command prompt...
3. In the Command Prompt window, type:
datamerge.exe
The datamerge.exe utility reads the ptnr_<timestamp>.log
files on the primary and secondary servers and merges the data for the
two databases as follows:
• First, it determines from the ptnr_<timestamp>.log files in
the primary server’s \log directory what data needs to be merged
from the primary server’s database to the secondary server’s
database and executes the merge.
• Next it determines from the ptnr_<timestamp>.log files in
the secondary server’s \log directory what data needs to be
merged from the secondary sever’s database to the primary server’s
database and executes the merge.
A db_merge.log file is generated to report the success or failure of
the merge.

GFK-1353 Recovery Procedures 5-5

 You can also run the datamerge.exe utility with optional parameters to merge
specific times. The command format is:
datamerge.exe [[source] [dest] time1 time2]

where:
source is the name of the source server
dest is the name of the destination server
time1 is the start time for merging data
time2 is the end time for merging data
Note

When you run the datamerge.exe utility with specific start and end times, the
ptnr_timestamp.log files on the secondary and primary servers are not used.

Failure Exceptions
There are two categories of failure exceptions that CIMPLICITY Server Redundancy
will not handle; process failures, and network failures

Process Failures
A process failure occurs when a single process on a server fails. If this occurs on a
primary server, the recovery method depends on which process failed.
• If the Alarm Manager or User Registration on the primary server fails,
control automatically passes the corresponding process on the
secondary server. If the process on the primary server is restarted (via
cpc), control will automatically pass back to the process on the primary
server.
• If a device communications process on the primary server fails, control
will not pass to the corresponding process on the secondary server, and
point data will be lost.
• If the Point Manager on the primary server fails, control automatically
passes to the Point Manager on the secondary server.
To safely recover, user Stop to shut down the project on the primary
server, then use Run to restart it. After the project is up and running,
reset the primary server to be the master.

Network Failures
Network partition occurs when the computer network fails. Each CIMPLICITY
server continues to perform its own functions, but there is no communications
between the servers. Secondary servers will perform their automatic takeover
procedures. In other words, both the primary and secondary servers act as master.

5-6 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
 The following procedure should be following when network partition occurs:
• On each secondary server, use Stop to shut down the CIMPLICITY
HMI project.
• Repair the network
• After the network is restored, use Start to bring the project on the
secondary server back on-line.
Note

This assumes that the CIMPLICITY HMI project is still running on the primary
server. If the project has been shut down, then use the normal startup procedures to
restart the project on both the primary and secondary server.

GFK-1353 Recovery Procedures 5-7

Appendix A - Supported
Communication Interfaces

About Supported Communication Interfaces

This appendix documents the redundant communication interfaces supported by
Server Redundancy.
The supported redundant communication interfaces are:
• Series 90 TCP/IP
• Series 90 TCP/IP Redundancy
• CCM2
• Genius
• SNPX
• Allen-Bradley Communications
• Allen-Bradley Data Highway Plus
• APPLICOM
• DDE Client
• Modbus Plus
• Modbus RTU
• Modbus TCP/IP
In addition, CIMPLICITY HMI for Windows NT and Windows 95 supports the
development of Server Redundant Device Communication Toolkit drivers. Use the
heartbeat function in the enabler to determine if the secondary server can
communicate with its configured devices. Further details can be found in the
CIMPLICITY HMI for Windows NT and Windows 95 Device Communications
Toolkit Application Developer Guide (GFK-1202).

GFK-1353 A-1
Series 90 TCP/IP Communications
Server redundant computer configurations that use the Series 90 TCP/IP
Communications option must be configured as in the following diagram:

The primary and secondary servers are on the same Ethernet LAN connected to a
single Ethernet card in the programmable controller.

Series 90 TCP/IP Redundancy Communications

Server redundant computer configurations that use the Series 90 TCP/IP Redundancy
Communications option can support:
• PLC redundancy
• Cabling redundancy
• Combined PLC and cabling redundancy
The following diagram illustrates PLC redundancy:

The primary and secondary servers are on the same Ethernet LAN connected to
Ethernet cards in the primary and backup programmable controllers.
For detailed information on the configurations supported by the Series 90 TCP/IP
Redundancy Communication options, see the CIMPLICITY HMI for Windows NT
and Windows 95 Device Communications Manual (GFK-1181)

A-2 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
CCM2 Communications
Server redundant computer configurations that use the CCM2 Communications
option must be configured as in the following diagram:

The primary and secondary servers must have independent cable paths to the PLC.
The PLC must have two serial ports available for CCM2 communications. Both of
the PLC’s serial ports must be configured with the same CPU ID.
The recommended configuration is to use the CMM module in CCM2 mode. Both
ports on the CMM module can be configured for CCM2 communications.

Genius Communications
Server redundant computer configurations that use the Genius Communications
option must be configured as in the following diagram:

The primary and secondary servers must have different PCIM addresses. Unsolicited
datagrams sent from the PLC must be sent to both the primary and secondary servers.

GFK-1353 Appendix A - Supported Communication Interfaces A-3

SNPX Communications
Server redundant computer configurations that use the SNPX Communications
option must be configured as in the following diagram:

The primary and secondary servers must have independent cable paths to the PLC.
The PLC must have two serial ports available for SNPX communications. Both of
the PLC’s serial ports must be configured with the same CPU ID.

Allen-Bradley Communications
Server redundant computer configurations that use the Allen-Bradley
Communications option must be configured as in the following diagram:

Communications can be done over an Ethernet network or over a Data Highway Plus
network using Allen-Bradley 1784 KTX cards. Unsolicited data sent from the PLC
must be sent to both the primary and secondary servers.

A-4 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Allen-Bradley Data Highway Plus Communications
Server redundant computer configurations that use the Allen-Bradley Data Highway
Plus Communications option must be configured as in the following diagram:
1 1
Primary 7 Secondary 7
8 8
Server 4 Server 4

KT KT

PLC DH+

Both 1784-KT/B cards are on the same network and must be at different Station
Addresses. Unsolicited data sent from the PLC must be sent to both the primary and
secondary servers.

APPLICOM Communications
If the protocol you are implementing via the APPLICOM Communications option
allows multiple servers on the bus, then Server redundancy is supported for that
protocol.

DDE Client Communications

Server redundant computer configurations that use the DDE Client Communications
option must be configured in one of the following ways:
• The NetDDE Server must be installed and configured identically on
both the primary and secondary servers.
• The NetDDE Server must be installed and configured on a computer
other than the primary and secondary servers.

GFK-1353 Appendix A - Supported Communication Interfaces A-5

Modbus Plus Communications
Server redundant computer configurations that use the Modbus Plus Communication
soption must be configured as in the following diagram:
S S
Primary A Secondary A
8 8
Server 5 Server 5

Programmable
MB+
Controller

Both SA85 cards are on the same network and must be at different Node Addresses.
Unsolicited data sent from the PLC must be sent to both the primary and secondary
servers.

Modbus RTU Communications

Server redundant computer configurations that use the Modbus RTU
Communications option must be configured as in the following diagram:

Unsolicited data sent from the PLC must be sent to both the primary and secondary
servers.

A-6 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
Modbus TCP/IP Communications
Server redundant computer configurations that use the Modbus TCP/IP
Communications option must be configured as in the following diagram:

The primary and secondary servers are on the same Ethernet LAN connected to a
single Ethernet card in the programmable controller.

GFK-1353 Appendix A - Supported Communication Interfaces A-7

Appendix B - Configuration
Parameters

Failover Rate Configuration

The default value for the failover period is 3 seconds. It can be increased, depending
on the needs of the application. The failover rate should never be modified to less
than 3 seconds.
The failover period is defined as:
REDUND_PROBE_DELAY * (REDUND_PROBE_COUNT + 1)

The two parameters, REDUND_PROBE_DELAY and REDUND_PROBE_COUNT

are defined in the global parameters file.
The formats for these parameters are:
REDUND_PROBE_DELAY|3|<millisec>
REDUND_PROBE_INTERVAL|3|<count>

where <millisec> is the number of milliseconds for the probe delay and <count> is
the number of probes to make.
Sample entries for these parameters would be:
REDUND_PROBE_DELAY|3|1000
REDUND_PROBE_INTERVAL|3|3

A related parameter is REDUND_PROBE_PORT. This is the TCP/IP port number

used to implement the probing mechanism. The default value is 4000. Only change
this parameter if it conflicts with other software.

GFK-1353 B-1
User Registration Synchronization
The User Registration(UR) processes on the primary and secondary nodes need to
synchronize with each other at startup. This can normally occur within a 30 second
period. On slower computers this might not be enough time. The global parameter
REDUND_LINK_SLEEP can be changed to provide more time for the UR process
to synchronize.
The format for this parameter is:
REDUND_LINK_SLEEP|3|<time>

where <time> is the sleep time in seconds.

For example, to set the sleep time to 30 seconds, enter the following in the global
parameters file:
REDUND_LINK_SLEEP|3|30

Slave Startup Timeout

If the project on both the primary (master) and secondary (slave) servers is
configured to start at boot, you can use the SLAVE_STARTUP_TIMEOUT global
parameter to delay starting the project on the secondary server until after the project
on the primary server starts. This helps avoid race conditions between the two
servers when they are trying to determine which server is the master.
If you do not define this global parameter, the default time is 0 (zero) minutes.
The format for this parameter is:
SLAVE_STARTUP_TIMEOUT|1|<time>

where <time> is the time in minutes to wait before starting the project on the
secondary server.
For example, to delay the project startup on the secondary server by 2 minutes, enter
the following in the global parameters file:
SLAVE_STARTUP_TIMEOUT|1|2

B-2 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
TCP/IP Keep Alives
In order for Server Redundancy to work correctly, the TCP/IP Keep Alive
mechanism needs to be activated. To do this two parameters will need to be entered
in the Windows registry.

Windows NT
To activate the Keep Alive mechanism on Windows NT:
1. Use regedit to open the registry.
2. Follow the path
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser
vices\Tcpip\Parameters
3. Add the KeepAliveInteval and KeepAliveTime DWORD
Values.
4. Reboot your computer.

KeepAliveInterval
Add the following DWORD value:
KeepAliveInterval : REG_DWORD : 1 to 0xffffffff milliseconds
This parameter determines the interval separating keep alive re-transmissions until a
response is received. Once a response is received, the delay until the next keep alive
transmission is again controlled by the value of KeepAliveTime. The connection
will be end after the number of retransmissions specified by
TcpMaxDataRetransmissions have gone unanswered.
Set KeepAliveInterval to: 1000 (1 second)

KeepAliveTime
Add the following DWORD value:
KeepAliveTime : REG_DWORD : 1 to 0xffffffff milliseconds
The parameter controls how often TCP attempts to verify that an idle connection is
still intact by sending a keep alive packet. If the remote system is still reachable and
functioning, it will acknowledge the keep alive transmission. Keep alive packets are
not sent by default. This feature may be enabled on a connection by an application.
Set KeepAliveTime to: 3000 (3 seconds)

GFK-1353 Appendix B - Configuration Parameters B-3

 Windows 95
To activate the Keep Alive mechanism on Windows 95:
1. Use regedit to open the registry.
2. Follow the path
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser
vices\VxD\MSTCP\ Parameters
3. Add the following DWORD Values:
• KeepAlive - Indicates whether keepalives are sent

• TcpKeepCnt - Number of minutes before generating keepalive

traffic
• TcpKeepTries - Number of keepalive probes to use before
marking connection as down.
4. After changing the Registry, reboot your computer.

B-4 CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
 Devcom configuration
Server redundancy 4-2
Device communications
Operation during failover 5-3

Index F
Failover
Alarm management operation during 5-3
Device communications operation during 5-3
Point management operation during 5-3
Runtime interfaces during 5-4
Server redundancy 2-8
System operation during 5-3
User logons operation during 5-3
Failover rate configuration
A Server redundancy B-1
About Failure exceptions
Supported communication interfaces, Server Network failures 5-6
redundancy A-1 Process failures 5-6
Alarm management Server redundancy 5-6
Operation during failover 5-3 Failure recovery limitations
Redundant system behavior 2-7 Server redundancy 2-4
Allen-Bradley communications Functionality limitations
Redundant configuration A-4 Server redundancy 2-2
Allen-Bradley Data Highway Plus
Redundant configuration A-5 G
APPLICOM
Redundant configuration A-5 Genius
Redundant configuration A-3
Global point configuration
C Server redundancy 4-2
Cabling redundancy 1-2
CCM2 H
Redundant configuration A-3
CimView Hardware requirements
Redundant system behavior 2-7 Server redundancy 3-1
Computer network redundancy 1-3
Configuration I
Redundancy system behavior 2-5
Configuration procedures Identification of active primary
Server redundancy 4-1 Redundant system behavior 2-6
Configuration settings
Server redundancy 4-1 K
KeepAliveInterval B-3
D KeepAliveTime B-3
Data collection
Redundant system behavior 2-5 M
Database logging
Modbus RTU
Redundant system behavior 2-7
Redundant configuration A-6
Database logging files
Modbus TCP/IP
Resynchronizing, Server redundancy 5-5
Redundant configuration A-7
DDE client
Modubs Plus
Redundant configuration A-5

GFK-1353 i
 Redundant configuration A-6 Modubs TCP/IP A-7
Series 90 TCP/IP A-2
N Series 90 TCP/IP redundancy A-2
SNPX A-4
Network configuration Redundant system behavior
Server redundancy 4-2 Alarm management 2-7
Network failures CimView 2-7
Server redundancy 5-6 Configuration 2-5
Normal operating procedures Data collection 2-5
Server redundancy 5-1 Database logging 2-7
Normal operating procedures, Startup and shutdown Identification of active primary 2-6
Server redundancy 5-1 Setpoints 2-6
Unsolicited data 2-6
O User registration 2-7
Rimto,e omterfaces
Operation, Description of Operation during failover 5-4
Server redundancy 2-3
Overview
Server redundancy 2-3
S
Series 90 TCP/IP
P Redundant configuration A-2
Series 90 TCP/IP redundancy
PLC redundancy 1-2 Redundant configuration A-2
Point management Server failure
Operation during failover 5-3 Server redundancy 5-2
Primary server Server redundancy 1-3
Reset after recovery, Server redundancy 5-4 Allen-Bradley communications A-4
Process failures Allen-Bradley Data Highway Plus A-5
Server redundancy 5-6 APPLICOM A-5
Project start, Normal CCM2 A-3
Server redundancy 5-1 Configuration procedures 4-1
Project stop, Normal Configuration settings 4-1
Server redundancy 5-2 Database logging files, Resynchronizing 5-5
DDE client A-5
R Definition for CIMPLICITY HMI 1-3
Description of operation 2-3
REDUND_LINK_SLEEP B-2 Devcom configuration 4-2
REDUND_PROBE_DELAY B-1 Failover 2-8
REDUND_PROBE_INTERVAL B-1 Failover rate configuration B-1
Redundancy Failure exceptions 5-6
Cabling 1-2 Failure recover limitiations 2-4
CIMPLICITY HMI, definition of 1-3 Functionality limitations 2-2
General definition 1-1 Genius A-3
Host Computer network 1-3 Global point configuration 4-2
PLC 1-2 Hardware requirements 3-1
Server 1-3 Introduction 1-1
Redundant configuration KeepAliveInterval, Windows NT B-3
Allen-Bradley communications A-4 KeepAliveTime, Windows NT B-3
Allen-Bradley Data Highway Plus A-5 Modbus Plus A-6
APPLICOM A-5 Modbus RTU A-6
CCM2 A-3 Modbus TCP/IP A-7
DDE client A-5 Network configuration 4-2
Genius A-3 Network failures 5-6
Modbus Plus A-6 Normal operating procedures 5-1
Modbus RTU A-6 Normal startup and shutdown 5-1

ii CIMPLICITY HMI for Windows NT and Windows 95 Server Redundancy Operation Manual GFK-1353
 Overview 2-3
Process failures 5-6
Project start, Normal 5-1
Project stop, Normal 5-2
Resetting primary server after recovery 5-4
Series 90 TCP/IP A-2
Series 90 TCP/IP redundancy A-2
Server failure 5-2
Slave startup timeout B-2
SNPX A-4
Startup/shutdown order 2-4
Supported communication interfaces, About A-1
System behavior 2-5
System operation during failover 5-3
TCP/IP keep alives B-3
TCP/IP keep alives, Windows 95 B-4
TCP/IP keep alives, Windows NT B-3
Types of HMI nodes 2-1
User interfaces 2-8
User registration synchronization B-2
Setpoints
Redundant system behavior 2-6
Slave startup timeout
Server redundancy B-2
SLAVE_STARTUP_TIMEOUT B-2
SNPX
Redundant configuration A-4
Startup/shutdown order
Server redundancy 2-4
System behavior
Server redundancy 2-5
System operation during failover
Server redundancy 5-3

T
TCP/IP keep alives
Server redundancy B-3
Windows 95 B-4
Windows NT B-3
Types of HMI nodes
Server redundancy 2-1

U
Unsolicited data
Redundant system behavior 2-6
User interfaces
Server redundancy 2-8
User logons
Operation during failover 5-3
User registration
Redundant system behavior 2-7
User registration synchronization
Server redundancy B-2

GFK-1353 Index iii