IWS SYSTEM REDUNDANCY SAMPLE PROJECT
There are
multiple methods for implementing redundant applications and redundant database
functionality. The configuration choices may be driven by cost, equipment
availability, network reliability, etc. There are several key factors in the
System Redundancy example’s implementation, however, that are important from
both a manageability and reliability standpoint. In addition, if your operators
have an understanding of how the fundamental components interact, they will be
better able to provide pertinent information if problems arise, and may even be
able to resolve issues with their initial troubleshooting efforts. You can use this SystemRedundancy link to download the project from the Indusoft web site. You can also use this SystemRedundancyWebinar link to download and view the Webinar for this project.
Simplify Configuration and Maintenance
One of the main points in simplifying an admittedly complex implementation is
to keep to the convention used in the example, such that only one single
application is configured and then deployed to both runtime machines. It is
worth repeating. Each machine always runs an application identical to the
other. All of the components necessary for execution in the role of Hot Server
or Standby Client are present in the single application, such that copies of
that single application can be provided to a pair of machines to implement the
redundant application functionality. An additional benefit is that only
versions of that single application need be stored as backups for maintenance
and/or further development.
Naming Conventions
Before startup, the user will already have decided which of the machines will
be known as the primary machine and which will be known as the secondary
machine, but you should understand that this naming convention is simply that.
It is a way to identify the hardware itself, just as is the computer name on
the network. The primary machine will always be called the primary machine, and
the secondary machine will always be called the secondary machine, for ease of
communication with developers, operators, etc. The more important item, which
is selected and entered by the operator at startup, is the designations of
which machine will first take on the role of the Hot Server. By convention the
Primary machine is usually selected to be the first one to have the role of Hot
Server, and the Secondary machine is usually selected to act as the Standby
Client at startup. These roles can change any time that the Hot Server becomes
unable to support its role, such that the machine serving as the Standby Client
has to take over that role, and become the new Hot Server.
Runtime Conventions
In normal operations, with both the Primary and Secondary machines on line and
available, one of these machines is acting as the Hot Server and one is acting
as the Standby Client. Both of these machines can be utilized as an operator’s
work station, with the same capabilities to display independently selected
graphic screens, accept operator input, etc. From an operator’s point of view,
they are identical.
The machine currently acting as the Hot Server, however, is typically doing
more processing than the machine acting as the Standby Client, the extent of
which is determined by the number of tasks configured in the project. It can be
actively communicating with external databases for historical data logging of
alarms, events and trends, as well as other external database operations. It
can be implementing all of the alarm processing configured in the project. It
can be supporting all configured communications for data exchange with external
controllers and devices and other runtime application processes. This can
include communications drivers, OPC connectivity, DDE and TCP/IP Client/Server
connectivity.
While the Hot Server is supporting all of these tasks, the Standby Client’s
role is to provide an operator interface for graphics display and process value
I/O. The other tasks mentioned above are all disabled while acting as the
Standby Client. The tag data for the Standby Client is read from and written to
the tags database on the current Hot Server, via the TCP/IP Client Runtime task
that is always enabled on the Standby Client, and always disabled on the Hot
Server.
If the Standby Client stops receiving continuous updates of specific values
from the Hot Server, it assumes that the Hot Server is no longer available on
the network and implements a switchover. The former Standby Client then becomes
the new Hot Server and enables all of those tasks required to support the Hot
Server role. When network communications are restored between the Primary and
Secondary machines, the returning machine will always assume the role of the
Standby Client, based on the inputs received from the current Hot Server, such
that there is no interval of conflict in which two machines are vying for the
Hot Server role.
Database and PLC Redundancy
Due to the nature of the single project configuration, and the runtime
conventions discussed above, redundancy for database communications and
external device communications are simplified, since they are both configured
as if there is only one project executing. For database redundancy with a
single runtime project, the typical architecture is one in which the primary
database resides on a remote device, and the secondary database resides on the
project’s runtime machine. In this way, if the data can no longer be sent to
the remote device, it will not be lost, since it will then be recorded on the
local runtime machine’s database, and that data can be synchronized with the
remote machine’s database if, and when, it is restored to the network. When database
redundancy is to be implemented within the framework of application redundancy,
the primary database can reside on a remote device in the form of a third
machine on the network, or it can reside on both the Primary and Secondary
machines, such that it will only be enabled when that machine has the role of
Standby Client. In both scenarios, the Hot Server machine sends data to the
Primary database as long as connectivity exists to the machine on which the
Primary database resides. If that connectivity is lost, the Hot Server machine
will send the data to its own locally resident database. Both methodologies are
consistent with the convention in which only the Hot Server implements the
database communications, whether it is to the primary database or the secondary
database. The Standby Client never sends data to either. It is up to the user
to determine whether there is an advantage in either configuration.
PLC or other remote device communications redundancy is also simplified when
maintaining the convention that the Hot Server always implements such
communications, either to the primary external device, or to the secondary
external device if the primary becomes unavailable. The Standby Client never
implements such external communications.
This overall strategy is made possible because each of the tasks, which are
described above as only being implemented by the machine currently acting as
the Hot Server, can be programmatically disabled on the machine acting as the
Standby Client, and programmatically enabled when and if that machine has to
take on the role of the Hot Server. This in turn makes it possible to implement
the application redundancy in such a way that all of the configuration can be
done on a single project, with identical copies running on both machines in the
redundant pair. It is not the only way to implement application redundancy, but
it eliminates many complexities that can arise when the configuration of the
project on the Primary machine is not the same as the configuration of the project
on the Secondary machine, where a change in one project can have unexpected
consequences in the other, or may necessitate some reciprocal, but different
configuration on the other. Such disparities can multiply with time, greatly
increasing the efforts required for maintenance or enhancement.
NOTE: Application redundancy is not a built-in feature of the Indusoft Web Studio product. It can be configured using such customization as discussed in this document, but help for such customization falls under the purview of Consulting Services and is not under the purview of Technical Support.