Wolfgang ColsmanandMarc Schier
97cc145811
# Description
## Problem
OPC 10000-4, clause 6.6.2 "Server redundancy", lets a Client of a
non-transparent redundant Server set (Cold, Warm, Hot, HotAndMirrored)
connect to the Server with the highest `ServiceLevel` and fail over when
the Server in use is lost or its `ServiceLevel` leaves the Healthy
subrange (6.6.2.4.2 "ServiceLevel": 200-255 Healthy, 2-199 Degraded, 1
NoData, 0 Maintenance; 6.6.2.4.5 "Client failover behaviour"). The
managed session on `master` covers part of this:
- `ManagedSession` fails over only in the `Failover` state of
`ConnectionStateMachine`, which is entered after the reconnect policy
gives up. `DefaultServerRedundancyHandler.ShouldFailover` /
`ServerRedundancyHandlerExtensions.ShouldFailover` implement the
subrange rules, but nothing in the client calls them: a connected
session stays on a Server that reports Degraded or Maintenance until its
connection breaks. There is no public member that starts a failover
(`HandleFailoverAsync` is private).
- Members known only from `ServerUriArray` get `ServiceLevel` NoData
with `ServiceLevelKnown = false` (internal). Their `ServiceLevel` is
never read, so neither the initial connect nor `SelectFailoverTarget`
can prefer the member with the highest `ServiceLevel`.
- `ReadRedundancyInfoAsync` maps a bad status of `RedundancySupport`,
`ServerUriArray`, `RedundantServerArray` or `CurrentServerId` to an
empty or default value, and peer endpoint resolution failures are only
logged. An application cannot report which redundancy Node the Server
refused or why a member has no endpoint.
An application that must fail over on `ServiceLevel` therefore polls the
`ServiceLevel` itself, opens its own sessions to read each member, and,
lacking a failover trigger, closes the managed session and opens a new
one - losing the transfer or recreate of its subscriptions that the
managed failover performs.
## API (all additions; defaults keep the current behaviour)
```csharp
public partial class ManagedSession
{
public Task FailoverAsync(ConfiguredEndpoint? target = null, CancellationToken ct = default);
public ServerRedundancyInfo? RedundancyInfo { get; } // implements IManagedSession.RedundancyInfo
}
public interface IManagedSession : ISession
{
ServerRedundancyInfo? RedundancyInfo { get; } // new interface member
}
public sealed record ServerRedundancyOptions
{
public bool ProbeMemberServiceLevel { get; init; } // default false
public TimeSpan? ServiceLevelMonitoringInterval { get; init; } // default null (off); must be positive when set
}
public sealed class RedundantServer
{
public bool ServiceLevelKnown { get; init; } = true; // was internal
public ServiceResult? ResolutionError { get; init; } // new
}
public sealed class ServerRedundancyInfo
{
public IReadOnlyDictionary<NodeId, StatusCode> ReadStatuses { get; init; } // new, empty by default
}
```
## Behaviour
1. **Read statuses and resolution errors.**
`DefaultServerRedundancyHandler` records the status of every Node it
reads from the Server in use (`RedundancySupport`, `ServiceLevel`,
`RedundantServerArray`, `ServerUriArray`, `EstimatedReturnTime`, and
`CurrentServerId` for Transparent redundancy) in
`ServerRedundancyInfo.ReadStatuses`. A peer whose endpoint resolution
fails carries the exact status in `RedundantServer.ResolutionError` (the
discovery `ServiceResult`, `BadTimeout` when the discovery bound
expires, `BadNotFound` when no endpoint matches the security and
transport in use). `IManagedSession.RedundancyInfo` exposes the last
snapshot.
2. **Member probing** (`ProbeMemberServiceLevel`). After a member's
endpoint is resolved, `ManagedSession` reads `Server.ServiceLevel` and
`Server.ServerStatus.State` of every other member over a short session
with the identity of the session in use, bounded by
`PeerDiscoveryTimeout`, and replaces the reported values. A member that
cannot be probed keeps the values reported for it and carries the
failure in `ResolutionError` (for example `BadNotReadable`). With
probing, the initial connect switches to the member with the highest
`ServiceLevel` when it is higher than that of the Server it connected to
(6.6.2.4.5).
3. **`FailoverAsync`.** Fails over a connected session to `target`, or
to the target the redundancy handler selects from a refreshed snapshot,
through the existing in-place recreate (subscriptions are transferred or
recreated; with token reuse enabled a HotAndMirrored target reactivates
the session). The connection state machine gets an internal
`RequestFailover` that enters `Failover` with the requested operation;
`ConnectionStateChanged` reports `Failover` then `Connected`. Throws
`BadNotSupported` without a redundancy handler, `BadInvalidState` when
not connected, `BadNothingToDo` when the handler selects no target, and
the failover error otherwise. A failed requested failover transitions to
`Reconnecting` (not `Disconnected` plus the recovery timer), so the
reconnect policy restores the session at once. Cancelling `ct` stops
waiting; a failover in progress completes.
4. **ServiceLevel monitoring** (`ServiceLevelMonitoringInterval`). While
connected to a non-transparent set, `ManagedSession` reads the
`ServiceLevel` of the Server in use at the interval. While it is Healthy
nothing else happens (a Healthy Server is not left, 6.6.2.4.3).
Otherwise the snapshot is refreshed (with probing when enabled),
`ShouldFailover` decides, and a warranted failover runs `FailoverAsync`
to the handler's target. The loop ends with the session.
The switch logic of the automatic failover (`HandleFailoverAsync`) is
factored into a helper shared with the initial selection and
`FailoverAsync`; its behaviour is unchanged.
## Tests
- `ManagedSessionServerRedundancyTests` (new, in-process Warm set of two
`ReferenceServer` fixtures with distinct ApplicationUris,
`Server.ServerRedundancy` promoted to `NonTransparentRedundancyType`
with each other in `ServerUriArray`, `ServiceLevel` set through
`IServerServiceLevelControl`, endpoints resolved by a test
`IRedundantServerEndpointResolver`):
- without probing the session stays on the configured Server; the peer
has `ServiceLevelKnown = false` (defaults unchanged);
- with probing the initial connect selects the member with the higher
`ServiceLevel` (250 over 210);
- a member that refuses the `ServiceLevel` read keeps an unknown
`ServiceLevel` and reports `BadNotReadable` in `ResolutionError`;
- a refused `RedundantServerArray` reports `BadNotReadable` in
`ReadStatuses`;
- lowering the `ServiceLevel` of the Server in use to 150 while the peer
reports 230 fails over within the monitoring interval,
`ConnectionStateChanged` reports only `Failover` and `Connected`, the
same subscription object keeps delivering data changes from the new
Server (sequence numbers restart there, as the subscription is recreated
on another Server);
- `FailoverAsync` to an explicit target and to the handler-selected
target;
- `FailoverAsync` without a redundancy handler throws `BadNotSupported`.
- `ServerRedundancyHandlerTests`: resolution error of a refusing and of
an unresolved peer, read status of each Node, validation of the
monitoring interval.
- `ConnectionStateMachineTests`: a requested failover runs its operation
in `Failover` and bypasses the failover delegate; a failed requested
failover reconnects without `Disconnected`; `RequestFailover` is refused
when not connected.
## Compatibility
- Source/binary additions only, except that `IManagedSession` gains
`RedundancyInfo`; `ManagedSession` is the only implementation in the
repository, external implementers of `IManagedSession` must add the
property.
- `RedundantServer.ServiceLevelKnown` changes from internal to public
(same default `true`).
- With the default options nothing changes at runtime: no probing, no
monitoring, the automatic failover path is unchanged. The only
default-visible differences are the new `ReadStatuses`/`ResolutionError`
data.
- Probing opens one short additional session per member;
reverse-connect-only members cannot be probed and report the probe
failure in `ResolutionError`.
## Related Issues
- No tracking issue; the problem and the design are described above.
## Checklist
- [x] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [x] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [ ] I have added all necessary documentation.
- [x] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed. (Run
locally: the affected test classes on net48 and net10.0 and the whole
Opc.Ua.Client.Tests project on net10.0; not the whole UA.slnx.)
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.
---------
Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>
OPC UA .NET Standard Stack
🆕 This is version 2.0 of the OPC UA .NET Standard Stack (current
master).Looking for the supported 1.x release? It lives on the
master378branch (last release:1.5.378). All new feature work happens here onmaster;master378continues to receive security and critical-bug fixes for the 1.x line.
The official OPC Foundation reference implementation of OPC UA for .NET — a cross-platform stack with client, server, PubSub, GDS, complex types, and source-generated tooling. Used in production across industrial control, manufacturing, energy, and IoT systems.
📦 What it is
- A full-stack OPC UA implementation — Core / Client / Server / PubSub / GDS / LDS / Complex Types / Device Integration / Positioning libraries built on .NET, with UA-TCP and HTTPS transports.
- Cross-platform — runs on .NET 10, .NET 9, .NET 8 (LTS), .NET Framework 4.8; ships Native-AOT-friendly assemblies.
- Conformance regression testing — the reference server is tested with the Compliance Test Tool (CTT) through the CTT regression workflow. These results identify regressions; they do not constitute product certification.
- Companion-spec coverage — Part 9 (Alarms & Conditions), Part 10 (Programs), Part 11 (Historical Access), Part 13 (Aggregates), Part 16 (State Machines), Part 17 (Alias Names), Part 18 (Role Management), Part 20 (File Transfer), Part 100 (Device Integration), Part 110 (Asset Management Basics), Parts 210/211 (Relative Spatial Location and Global Positioning), OPC-10030 (ISA-95 Common Model) with OPC-10031-4 Job Control V1/V2, OPC 30270 / OPC UA for Asset Administration Shell V2 and V3, OPC 10100-1 (WoT Connectivity), Part 200 (Industrial Automation), OPC 40001-1/-2/-3/-4/-101 (Machinery with Process Values, Job Management, Energy and Result Transfer), OPC 34100 (Energy Consumption Management), OPC 30081 (PA-DIM), OPC 40010-1 (Robotics), OPC 40100-1/-2 (Machine Vision control and asset management), OPC 40501-1 and OPC 40505 (Machine Tools and independent wireless peripherals), OPC 40210 (Geometric Measurement Systems, with its documented upstream Production-facet exception), OPC 40020-1 (Cranes and Hoists), OPC 40223 (Pumps and Vacuum Pumps), OPC 30010 (AutoID Devices), OPC 40200 (Weighing Technology) with OPC 30050 (PackML).
- Hosting and code generation —
Microsoft.Extensions.DependencyInjectionhosting (services.AddOpcUa()), fluent server + client builders, source-generated NodeManagers and DataTypes, and an MCP server so LLMs / Copilot can drive an OPC UA client.
For the full feature breakdown see OPC UA Profiles and Facets and the What's New in 2.0 tour.
🚀 Getting started
To run a first OPC UA client and server, from NuGet packages or from the samples in this repository, follow Getting started. The documentation index then leads from the core concepts to advanced and experimental features.
The recycling operator console demonstrates live browser monitoring, native companion-specification inspection, material genealogy, and authorized controls over the synthetic recycling line.
You need a stable .NET SDK
version 10.0.400 or later to build the repo. global.json selects the
highest installed stable SDK, including newer major versions. From the repository root:
dotnet restore UA.slnx
dotnet build UA.slnx
For the supported target frameworks and platform notes see
the Developer Guide. The official NuGet packages
are published to nuget.org under the OPCFoundation.NetStandard
prefix — the meta package
OPCFoundation.NetStandard.Opc.Ua
bundles a default set of stack packages; see its
package inventory.
Reference PubSub and other optional feature packages separately, or select
individual packages directly, e.g.
OPCFoundation.NetStandard.Opc.Ua.Client for clients or
OPCFoundation.NetStandard.Opc.Ua.Server for servers. Preview builds from
every successful master build are available from the
GitHub Packages NuGet feed,
which is the only feed they are published to. nuget.org receives a version
only through a manually approved promotion from a release/<major>.<minor>
branch — that is where the 2.0.0-preview.N packages already on nuget.org
came from, via the earlier release/2.0.0 line. To use those, enable
prerelease packages and float with 2.0.0-preview.* until 2.0.0 is
released. The XRegistry, WoT Connectivity, Robotics, CranesHoists,
Redundancy, Positioning, OpenUSD, and AI package families, the Vision.OpenUsd
renderer, and the Robotics MCP extension remain
preview packages when the root version is promoted to a stable version, and
keep their own -preview.N versions on nuget.org. This includes all CranesHoists
model/server/client/MCP packages and their Debug variants.
The Vision, MachineVision, MachineTool (including WMTP), and GMS
model/client/server packages and their MCP packages follow the root version
without a preview-only override;
development builds still inherit the root prerelease version. See
docs/ReleaseProcess.md for how and when stable
versions are released.
Samples
The platform-independent sample applications show how to use the stack's core services and companion models in client/server workflows. More applications, including platform-specific examples, are available in the companion OPC UA .NET Samples repository.
Developer tools
- UaLens — NativeAOT-capable desktop engineering workspace for secure connections, monitoring, alarms, structured values, history, administration, PubSub, continuity diagnostics, and guided companion-model tasks. See build and artifact qualification.
- OPC UA MCP Server — installable .NET tool and container exposing OPC UA client operations to LLMs and Copilot. Embeddable libraries provide Part 4 services, PubSub, diagnostics, Robotics and Vision, plus industrial companion profiles for AMB, Machinery, Scales, Pumps, AutoID, Device Integration, ISA-95 and Positioning. The WoT and xRegistry profiles add asset/registry management and bounded document validation, planning and NodeSet conversion. Stack workflow profiles provide GDS/credential issuance, roles/users, files, alarms, history, schemas, and host-authorized PubSub and live WoT execution.
🔧 Migrating from 1.5.378 to 2.0
The 2.0 release introduces breaking API changes, and comes with a full prescriptive migration guide that links to per-area documentation for the migration sub-topics.
Most of the mechanical migration work is automated:
OPCFoundation.NetStandard.Opc.Ua.MigrationAnalyzerNuGet — install it in your project to get 26 analyzer rules throughUA0030(excludingUA0013,UA0016,UA0017, and the shim-onlyUA0029) plus one-click code fixes for the patterns in the guide. Setup steps are in the package's NugetREADME.md.- Migration agent skill — the
opcua-v20-migrationskill walks Copilot / Claude / any coding agent through installing the NuGet, runningdotnet format analyzersto apply auto-fixes, and handling the remaining manual changes. It selects the migration sub-document for each symptom.
Copilot CLI discovers the skill automatically inside a clone. To install it for use in any repository:
copilot plugin marketplace add OPCFoundation/UA-.NETStandard
copilot plugin install opcua-v20-migration@opcua-dotnet
If you are still on 1.x and not ready to upgrade, stay on the
master378
branch — it continues to receive security and critical-bug fixes.
🤝 Contributing and license
Community contributions are welcome. Fork the repository, make your changes on a branch, and open a pull request; see CONTRIBUTING.md for the contribution workflow.
Contributors must sign the OPC Foundation Contributor License Agreement (CLA). The CLA "I AGREE" gate is presented automatically on your first PR.
The project is licensed under the OPC Foundation MIT License. Report security vulnerabilities via the process documented in SECURITY.md.
📚 Further reading
- Documentation index — every per-feature doc with a one-line description.
- What's New in 2.0 — narrative tour of the 1.5.378 → 2.0 changes grouped by theme and layer.
- OPC UA Profiles and Facets — facets / transports / security policies the stack implements.
- Migration Guide — prescriptive
per-version migration reference (links to
docs/migrate/2.0.x/). - OPC UA Online Reference — the official OPC 10000 series specification index.
- Preview Nuget package feed —
prerelease builds from every successful
masterbuild.