Prevent Data Loss with Intelligent Failover in OPC Redundancy

In most redundancy strategies, failover happens when the primary OPC server disconnects. That’s necessary—but it’s not enough. In real industrial environments, failures are often more subtle: values stop updating, data drifts outside acceptable limits, or a process variable becomes stale while the connection still appears healthy. Intelligent OPC redundancy lets you define failover triggers based on real-world conditions, not just connection loss.

OPC Redundancy in OPC Expert is designed for engineers who need continuous, reliable data, not just a backup server waiting for a crash. It supports Hot and Warm redundancy, built-in automatic triggers, and fully customizable failover logic.

Setting up redundancy should not require scripting or complex configuration.

Above, you can see how redundancy objects are created visually. The PRIMARY-PC and STANDBY-PC each host a Siemens OPC server (Siemens.OPC). Creating redundancy is as simple as dragging the primary server and dropping it onto the standby server.

This drag-and-drop model reduces configuration errors and makes the setup process intuitive—especially useful when deploying in production environments where mistakes are costly.

Once configured, OPC Expert monitors both servers simultaneously, ensuring it always knows the state of each connection.

Redundancy is not one-size-fits-all.

In the image below, the Redundancy configuration window shows selectable failover modes:

• Hot
• Warm

Warm redundancy connects to both servers but only serves data from the Primary. If the Primary fails, the Standby takes over.

Hot redundancy keeps both servers actively synchronized, minimizing any delay during switching. The choice depends on your application—some environments tolerate a brief transition; others do not.

OPC Redundancy includes built-in automated triggers that require no setup.

If the primary server:

• Loses network connectivity
• Crashes
• Becomes non-responsive

Failover occurs automatically.

Above, you can see a real-world example:

• PRIMARY-PC shows “No Network Connection.”
• Warnings and error codes indicate loss of connectivity
• OPC Expert automatically falls back to the STANDBY-PC

This happens without user intervention. For many systems, that level of automatic protection is sufficient.

But intelligent redundancy goes further.

A connected server doesn’t guarantee good data.

A PLC could freeze.

A device could stop updating.

A sensor might drift outside acceptable limits.

From a network standpoint, everything looks “connected.” From a process standpoint, you’re flying blind.

That’s where custom triggers come in.

In the image below, the “Trigger on ‘Flow’ item” window shows configurable trigger conditions:

Built-in Conditions:

• Quality is Bad
• Quality is Uncertain
• Disconnected from OPC server

Value-Based Conditions:

• Value is equal to…
• Value changes
• Value does not change in X seconds

That last option is critical.

If a value does not change in a defined time window, you can force a failover—even though the server connection is technically still active.

This is how you protect against stale data.

Imagine a flow meter that should fluctuate continuously during operation.

If:

• The connection remains “Good”
• But the flow value hasn’t changed in 5 seconds

That may indicate:

• A frozen PLC task
• A stalled driver
• A failed device

By configuring:

“Value does not change in 5 seconds”

and enabling

“Fail over to backup server”

You move from reactive failover to proactive protection.

Custom triggers can also be tied to thresholds:

• Pressure > 250 PSI
• Temperature < expected minimum
• Level signal outside the operational band

And because OPC Expert supports calculated logic, you can combine conditions:

• Failover only if the value is stale and the quality is uncertain
• Failover if multiple tags exceed limits
• Force manual failover on operator input

This is especially valuable in regulated industries, energy systems, water treatment, or manufacturing lines, where incorrect data can be more dangerous than missing data.

Redundancy isn’t just about switching—it’s about knowing what happened.

In the image above, the Modify Redundant Server window shows:

• Server status indicators
• Connection state (WasConnected, Asynchronous)
• Failover Mode selection

The diagnostic logs at the bottom provide detailed error codes and reconnection attempts. This level of visibility helps maintenance teams troubleshoot root causes—not just mask failures.

As documented, OPC Expert continuously monitors both servers and automatically manages failover.

Traditional redundancy solutions often focus only on the connection state.

But industrial failures are rarely binary.

A system might:

• Stay connected, but stop updating values
• Return corrupted or drifting data
• Experience partial communication issues

By defining your own failover logic, you ensure switching happens based on data reliability, not just connectivity.

That approach:

• Prevents data loss
• Reduces downtime
• Protects process integrity
• Minimizes manual intervention

And because OPC Redundancy runs as a Windows service, it works even in unattended environments.

If you’re deploying intelligent redundancy, here’s a practical approach:

1. Set up visual redundancy pairing
2. Select Warm or Hot redundancy based on process requirements
3. Enable automatic triggers (default behavior)
4. Identify critical tags:
   • Flow
   • Pressure
   • Temperature
   • Production counts
5. Configure custom triggers:
   • Stale data timeout
   • Threshold breaches
   • Combined logic
6. Validate behavior using diagnostic logs

This ensures your redundancy strategy reflects real operational risks—not just network failures.

OPC Redundancy isn’t just about keeping a second server online. It’s about maintaining trustworthy data under all conditions.

With:

• Automatic connection-based failover
• Custom trigger configuration
• Hot and Warm redundancy modes
• Visual drag-and-drop setup

You’re not just reacting to outages—you’re designing intelligent switching logic that reflects how real industrial systems fail.

For automation engineers and system integrators, that’s the difference between “redundant” and truly reliable.