|
RedundancyMaster - OPC Redundancy Software | |
Product # RM2-RDNMS-NA00 - $1295.00
Support & Maintenance within Warranty - $259.00
Support & Maintenance out of Warranty - $647.50
Buy Now
RedundancyMaster
Increases the reliability and availability of OPC data by allowing multiple OPC Servers to be configured into redundant pairs. Each redundant pair seamlessly appears as a single OPC Server to any OPC Client application. RedundancyMaster can be added to an existing server/client application without any reconfiguration of the application, keeping your processes going with out any down time.
Industrial Strength ReliabilityOPC Data Access (OPC DA) technology has proven to be reliable in virtually every possible situation requiring consistent data access to devices and systems. However, there are other factors that can jeopardize the integrity of a system, some being software, hardware, and even the human element. By using OPC redundancy technology you can make these systems more reliable and efficient.
Increase ROI & Reduce System Down-timeTo fill this need for added system reliability, Kepware has developed RedundancyMaster. RedundancyMaster resides on your OPC client machine and facilitates connections to a Primary and Secondary OPC server on the system's networks by 'hooking' into the OPC calls made between the client and the server. If for any reason the OPC client loses its communications link with the primary OPC server or a user-specified condition is met (e.g. An item is not receiving updates, a specific item value is met, or the quality of an item set to bad) RedundancyMaster will drop the primary and promote the secondary OPC server on your network - reducing system down-time and saving you money.
Ease of Use
RedundancyMaster can be a drop-in application that does not require you to make any changes to your OPC client or server applications. Its intuitive configuration takes only minutes and will allow you to have a Redundant OPC system running with no headaches. Simply browse and select your primary and secondary OPC servers, and the system is up and running. We have built in features such as email notification, object and link monitoring, and diagnostics logging. In the situation where you need multiple redundant OPC server pairs that utilize the same OPC server vendor, we have added the capability to alias* the ProgID (Program ID) of the OPC server.
*Note: Aliasing may require minor OPC client modifications
Reliability
There are a many variables that could impact the quality and reliability of your data and
even more ways an OPC system can lose a connection to an OPC server. The most common are:
- The PC running the OPC server is shut down
- User errors cause the OPC server to exit
- The Network connection to OPC server is lost or unreliable
- The Network setting is changed causing link failure
- The OPC server itself fails for any reason, known or otherwise
- The Log-in account is changed on the OPC server's PC
In most of the cases above, the OPC DA server fails to provide data due to an actual failure
underlying the OPC server or the connection to that server. These types of failures are what
we call "object-based" failures. Object-based failures occur when the actual link between your
OPC client application and the target OPC server breaks down. Considering for a moment the ways
an industrial application can lose data, we must keep a number of factors in mind. In the
previous examples, software was the culprit. However, physical hardware breakdowns within an
application can dramatically affect reliability as well. Some of these physical factors are:
- Physical Connection Failure (the cable is pulled)
- Hardware Failure (router failure)
- Electrical Interference (high current discharge)
- Delays due to signal propagation (radio links)
- Environmental factors (lightning)
- Random accidents
|
In these situations, the virtual connection between the OPC server and the client may be
perfectly intact but the physical link to the underlying device or system may be broken. These
types of failures are what we call "link-based" failures. Link-based failures occur when the
connection to the target device or system has been lost. In most cases, the OPC server is still
completely operational, but simply cannot supply the data to the rest of the system.
Single Point of Failure
The diagram below demonstrates how a typical OPC system is configured and how it is
susceptible to failure. As can be seen, the OPC DA client applications are all accessing a
single OPC server. In this case, the potential exists for both an object-based failure and a
link-based failure. If for any reason the single OPC server fails to operate, then we will
have an object-based failure. Additionally, since this single PC is responsible for data
collection from the underlying devices, a single point of failure exists for the device
connection as well. To increase the reliability of your OPC system, you need to remove these
single points of failure.
To eliminate the single point of failure, you can redesign your OPC system to use more
than one OPC server by seamlessly adding RedundancyMaster.
 Single Point of Failure
Two OPC Servers Paired with RedundancyMaster
As can be seen in the diagram below, the original OPC system has been redesigned using
two OPC servers instead of a single OPC server. To facilitate the redundant operation of the
OPC servers, each OPC client has been paired with RedundancyMaster.
Using the configurable options within RedundancyMaster, the use of either the Primary or Secondary OPC
server can be controlled directly. Based on the modes selected, RedundancyMaster will keep
both servers active or if configured to do so, start the secondary server only when the
primary server fails.
In regard to object-based failures or link-based failures, RedundancyMaster can be configured
to monitor these conditions and prevent unnecessary down-time in your system saving you time
and money!
Two OPC Servers Paired with
RedundancyMaster
|
RedundancyMaster Features:
Explore the features that will change how you think of OPC redundancy. The innovations in RedundancyMaster can work together seamlessly with your current OPC application to give you a more reliable solution.
Primary/Secondary Machine Names
Browse for the primary machine which specifies the preferred connection that should be made to
an OPC server and the secondary machine which specifies the fallback connection that should be
made to an OPC server when communications to the primary machine are unavailable. Every time a
new client connection is made to the underlying server, the application will first attempt to
make a connection to the server running on the primary machine. In the event that the connection
to the primary fails or communications to the primary is lost, a connection to the secondary
server will be attempted and, if available, established. Depending on the connection mode, you
can configure the application to automatically establish communications with the primary
machine when it becomes available.
Connection Mode
The connection mode defines how and when the redundancy application should connect to the underlying primary and secondary servers. The mode in which you operate affects the amount of time it takes to fail over from one OPC server to the other. Some modes allow you to automatically promote communications to the primary when it is available. The following summarizes connection modes:
Cold (Active machine only):
In this mode, the application
will only connect to one underlying server at a time. On startup, a connection to the primary
server will be made and all client related requests will be forwarded onto the primary. In the
event that the connection to the primary fails, or communications to the primary is lost, a
connection to the secondary will be made. If the redundancy application is unable to obtain a
connection to the secondary, it will continue to ping-pong between the two servers until it
makes a successful connection.
The 'cold' connection mode minimizes the amount of system resources that are allocated since
there will only be one connection to one server at any given time. It also reduces network
traffic since there is no need to poll the inactive machine in addition to the active machine,
as in other modes. The drawback to this setting is the amount of time it takes to fail-over to
the inactive server. When communications loss is detected with the active server, the application
needs to establish the connection to the inactive server, subscribe to all items on behalf of
the client and initiate the appropriate callback mechanisms.
Warm (Both machines, subscribe to items on active machine):
In this mode, the application will attempt to maintain a connection to both the primary and secondary servers at all times. Only items in the primary server will be active and polled. In the event that the connection to the primary fails, or communications to the primary is lost, the identical items in the primary server will be set to active in secondary server. Periodically, both servers will be pinged to determine if the connection is still valid.
The 'warm' connection increases the amount of system resources that are allocated, since
there will be two server connections made on behalf of the client. There is also a minimal
increase in network traffic due to periodically pinging two servers instead of one, as in
'Cold' mode operation. The benefits are that fail-over time is minimized over 'Cold' mode
operation, since the redundancy application will only have to initialize data callbacks
to the inactive server to begin receiving data. If you need to minimize the loss of data
in your application, and at the same time want to minimize network traffic, you should
use this connection mode.
Hot (Both machines, subscribe to items on both machines):
In this mode, the application will attempt to maintain a connection to both the primary
and secondary servers at all times. On startup, the application will initialize data
callbacks for both primary and secondary servers so that both servers will send data
change notifications. The data received from the primary server will be forwarded onto the
client. In the event that the connection to the primary fails, or communications to the
primary is lost, data received for the secondary will immediately be forwarded onto the
client. In either case, writes will only be forwarded to the active server.
Periodically, both servers will be pinged to determine if the connections are still
valid. If at anytime the redundancy application loses communications to either server, it
will periodically attempt to reconnect to the failed server.
This setting increases the amount of system resources that are allocated, since there will
be two server connections made on behalf of the client. There is also an increase in
network traffic due to receiving data change notifications from both underlying servers,
as well as periodically pinging both servers to determine if they are still available.
The benefit of this setting is that fail-over time occurs immediately after detecting the
loss of the active server. If loss of data is very crucial to your application, you should
use this connection mode.
OPC Server Aliasing:
This feature will allow you to configure multiple pairs of OPC Servers with the same ProgID
(KEPware.KEPServerEX.V5). This feature permits you to use one OPC Server vendor
if you have multiple OPC Server nodes on your network. This will allow OPC clients to connect
to a specific redundant pair by referring to the aliased ProgID of that redundant pair.
Always connect to primary machine upon availability
This setting enables RedundancyMaster to automatically promote communications back to
the primary machine when the OPC server becomes available.
Query Server Status Interval
This interval (specified in milliseconds) determines how often RedundancyMaster will ping
the underlying servers to determine if there has been a loss of communications. By querying at
a faster rate, you can minimize fail-over time since failure detection occurs more frequently.
Query Server Status Timeout
This interval (specified in milliseconds) determines how long the redundancy application will wait
for a ping response from the underlying servers before considering there to be a loss of
communications.
Monitoring Settings:
This feature allows you to configure certain conditions which will initiate a fail-over to the inactive server. These conditions allow you to monitor server items for specific states to determine the health of the underlying servers/devices, above and beyond the automatic fail-over that will occur due to the loss of communications.
|
Diagnostics Settings:
Preserve events to disk on shutdown: Events will be preserved to disk when the application is shutdown. The next time the application is started, the events will be displayed and any new events will be concatenated to the end of the view.
Maximum number of events to capture: Since diagnostics utilizes memory and storage resources, you may want to limit the number of diagnostics that are preserved at any given time. Once the maximum number of events has been reached, the oldest events will be discarded as necessary.
Notifications Settings:
This feature allows you to configure one or more recipients to receive email notifications for one or more diagnostics events. The events that are available to send as email notifications are the same events visible to the local Diagnostics Settings event view.
RedundacyMaster Diagrams:
Broadcasting Proprietary Ethernet IP Data
This diagram above shows how the proprietary Ethernet IP data is manipulated within the plug-in
device driver of KEPServerEX to become OPC Data, which is then served out to the OPC Client
in a basic redundant system.
Local Machine Redundancy
This scenario has the OPC Client, RedundancyMaster, and the Secondary OPC Server residing on the
Local Machine with the Primary OPC Server on a Remote Machine. In this scenario be sure to make
the most reliable Server your Secondary OPC Server. This scenario also reduces the need for
another machine to run the Secondary OPC Server.
Single OPC Server Pair Redundancy
This is a standard use diagram for one Server Pair where RedundancyMaster resides
on the same machine as the OPC Client, and the two OPC Servers are on remote machines.
Multiple OPC Server Pair Redundancy
RedundancyMaster can be configured to have multiple OPC Server Pairs. In this diagram there are two pairs of OPC Servers which are gathering data from two separate device networks. If the multiple OPC Server Pairs are all of the same ProgID (KEPware.KEPServerEX.V4), then you will need to use the Aliasing feature; if the two pairs have different OPC Servers with different ProgIDs then you will not need the Aliasing feature.
RedundancyMaster Client Interfaces
Application Connectivity Support:
OPC Data Access: 1.0a, 2.0, 2.05a
|
| |
|
| Additional Information and Resources:
|
Related Products:
|
|
|
| |
|
