SCADA Failover with TwinCAT OPC UA: Make ServiceLevel Reflect Source Health

A redundant SCADA connection can keep selecting an OPC UA server that
is reachable but no longer obtaining useful PLC data. Before blaming the
failover algorithm, establish how the server’s advertised health is
produced. A high ServiceLevel is only as informative as the mechanism
updating it.

TwinCAT’s documented default is especially important: its OPC UA
Server sets ServiceLevel statically to 255. This article uses TF6100
Server manual version 1.6.0, dated 2 September 2026, and the
corresponding vendor pages. It proposes a health-signal qualification,
not an executed failover test.

Separate
redundancy capability from health calculation

The TwinCAT
redundancy guide
describes non-transparent cold, warm and hot modes.
In non-transparent redundancy, the client performs the failover and the
actions needed to continue data exchange. Configuring a server set does
not remove that client responsibility.

For the actual SCADA product, establish which advertised mode it
supports and how it chooses an active source. Keep that evidence
separate from the server configuration. Two reachable endpoints and a
redundancy object do not demonstrate that the client will use the backup
correctly.

Then identify the health signal’s owner. Does a component evaluate
source communication and report it, or is the client merely reading an
unchanged default? A displayed 255 should not be described as a passed
downstream health test without evidence of that evaluation.

Source-health evaluation feeds a watchdog-backed ServiceLevel, while SCADA still owns failover and per-point quality decisions.

Give the health
producer a failure path

The ServiceLevel
documentation
allows ADS updates with watchdog monitoring. The
writer must refresh the value within the configured interval; otherwise
the server applies a configured fallback level. ServiceLevel remains a
general indicator rather than a detailed diagnosis of each fault.

Define what the producer observes before choosing numerical levels.
For a hypothetical acquisition service, distinguish a live server
process, an established PLC communication path, and usable observations
from required sources. The ranking should express the service the SCADA
client needs, not merely whether the producer’s own loop ran.

The updater itself can fail. A retained healthy value after its last
successful write is precisely the case the watchdog needs to expose.
Choose an interval and fallback through the system’s availability
requirements and qualification evidence; there is no universally correct
timeout or health number supplied by this article.

Audit every
writer, including maintenance paths

The version
1.6.0 manual, printed page 145
, states that writing without watchdog
monitoring deactivates an active watchdog. That value then remains until
another write. A one-off maintenance update can therefore change the
liveness contract, not just the displayed number.

Keep all ServiceLevel writers in one reviewed ownership model. An
engineering tool, PLC helper and background service must not
independently apply incompatible update modes. Record whether each path
maintains monitoring, intentionally suspends it, or restores it through
the supported interface.

This is a design review, not a recommendation to issue ADS writes on
a running system. Changes need the deployment’s existing operational
controls and rollback procedure.

Test failures the
socket check cannot see

In a simulator or isolated system, first make the acquisition path
unavailable while leaving the OPC UA server reachable. Observe source
diagnostics, individual data quality, the produced ServiceLevel and the
SCADA source selection as separate evidence.

Next, stop the health updater while leaving the server running.
Confirm the configured fallback appears after the intended watchdog
boundary and that the client responds according to its documented
policy. That case differs from a producer that remains alive and
deliberately reports degraded health.

Also examine equal levels, both servers degraded, and recovery of a
previously failed server. Define whether the application stays with its
current acceptable source or changes selection. Do not infer write
ownership from whichever server currently ranks highest; command
arbitration requires its own contract.

Acceptance is a trace from source-health evidence to the advertised
level and the client’s resulting decision. No failover latency or
continuity guarantee is claimed here. A meaningful ServiceLevel improves
selection only when its producer, expiry behavior and consumer policy
are all understood.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *