romanettandClaude Opus 5.5 37a2a831f3 Server: keep the publish timer on a fixed cadence and parallelize the sweep by work (#4829)
The publish timer loop ran a pass over all session publish queues and
then
waited a full PublishingResolution, so the cycle period was pass time +
resolution and a slow pass delayed every following cycle. Whether the
pass
ran in parallel depended only on the session count (256 or more).

Fixed cadence: the loop now waits only for what is left of the period
(RunAtFixedPeriodAsync on the server TimeProvider). A pass that overruns
the period is followed by the next pass at once and the cadence restarts
from there; missed periods are not caught up with extra passes.
Shutdown, cancellation and abandoned subscription handling are
unchanged.

Parallelism by work: a pass checks the queues on the sweep thread until
it
has used a quarter of the publishing resolution (25 ms at 100 ms), then
checks the remaining queues with Parallel.For (CheckPublishTimers). The
session count no longer decides.

Why the budget:
- The pass cost is real per-item work. In the LoadTest subscribe shape
  (50 sessions x 15 subscriptions x 600 items, all 600 written every
  150 ms, publish 100 ms) every pass promotes up to 450k items; the
sequential pass takes 85-125 ms (~0.28 us per promoted item: ready list,
IsReadyToReport, LinkedList move, trigger check, ready signal release).
  Ready-list promotion already skips items without pending values and
  subscriptions whose timer is not due, so there is no idle work left to
  skip; only parallelism makes the pass fit the period.
- Fixed cadence alone lifts delivery from 64 % to 91 % (pass ~85 ms in a
  100 ms period, no headroom); with the parallel remainder 97-98 %.
- Parallel sweeps cost CPU when the pass fits anyway: at 10 sessions the
sequential pass takes ~15 ms; a 2 ms budget made it parallel and raised
  server CPU per notification from 5.0 to 8.9 us. With the 25 ms budget
  it stays sequential.
- Idle servers stay sequential: 1000 sessions x 1 slow subscription pass
  in ~2 ms sequential (was always parallel above 256 sessions); 2
  sessions in 0.05 ms.

Diagnostic probes (one build with temporary switches, one run each,
50x15x600 shape):

| loop / sweep            | delivered | us/notif | pass avg | cycle  |
|-------------------------|-----------|----------|----------|--------|
| old loop, sequential    | 63.9 %    | 5.1      | ~125 ms  | ~225 ms|
| fixed, sequential       | 91.2 %    | 5.1      | ~85 ms   | ~110 ms|
| old loop, all parallel  | 96.9 %    | 3.9      | ~24 ms   | ~132 ms|
| fixed, all parallel     | 97.0 %    | 4.1      | ~21 ms   | 100 ms |
| fixed, 25 ms budget     | 97.8 %    | 4.4      | ~44 ms   | 100 ms |

Paired A/B against master (perf/ServerLoadHarness, Server GC, encrypted,
alternating rounds, medians; runs repeated when processes outside the
harness used more than 1.5 cores):

| shape (sessions x subs x items) | n | delivered | us/notif | server
cores |

|-----------------------------------|---|--------------|-------------|--------------|
| 50 x 15 x 600, pub 100, write 150 | 3 | 67.7 -> 97.8 | 5.5 -> 4.4 |
11.3 -> 13.3 |
| 10 x 15 x 600, pub 100, write 150 | 3 | 100.4 -> 99.9| 5.5 -> 5.1 |
3.32 -> 3.11 |
| 1000 x 1 x 1, pub 1000, write 500 | 7 | 50 -> 50 (*) | 216 -> 201 |
0.21 -> 0.20 |
| 2 x 1 x 100, pub 100, write 150 | 3 | 100 -> 100 | 48.5 -> 46.1| 0.06
-> 0.06 |

(*) two writes per publishing interval with queue size 1, by design.

Side effect at 50 sessions: server allocation per notification rises
from ~54 to ~96 B. An allocation trace attributes it to
MonitoredItemNotification: the parallel remainder makes all
subscriptions publish within a few ms, the in-flight burst exceeds the
notification pool bound (kMaxPooledNotifications = 65536) and the pool
misses; the slow sequential sweep spread gets and returns. Gen0 GCs in
the 15 s window 3-5 -> 8, pause 20-50 -> ~60 ms; CPU per notification
still drops. Addressed by the stacked #4830, which allocates these
notifications instead of pooling them (tracking issue #4819).



### Follow-up commits

- **Late wake / exact deadline** (review): a wait that ends a whole
period late restarts the cadence from the late pass (no catch-up pass),
and a sweep exactly at a subscription's deadline counts as due.
- **Phase aliasing with equal periods** (f33893b7c): with the sweep at
the publishing interval, a subscription's deadline keeps one phase
relative to the sweep for the whole session. If it falls inside the ~16
ms timer jitter, a late sweep followed by an on-time one dropped a
publishing cycle. The 2-session shape (write = publish = 100 ms, queue
size 1) was bimodal: 6 of 24 runs at 56-85 %. The deadline now advances
by one interval per expiry and skips missed expiries only when a whole
interval behind after that. Result: 24 of 24 runs at 97-101 % (master:
steady 88-98 %); write 150 ms gave 98.5-100 %, and the 50 x 15 x 600
shape stayed at 99.3-100.7 %.
🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-19 06:48:41 +02:00
2020-05-15 19:41:55 +02:00
2021-07-26 10:06:51 +03:00

OPC UA .NET Standard Stack

Release NuGet Downloads CI CodeQL Coverage Nightly Stress Tests Connection Stability Foreign Interop HA Long-Haul CTT Regression

🆕 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 master378 branch (last release: 1.5.378). All new feature work happens here on master; master378 continues to receive security and critical-bug fixes for the 1.x line.

The official OPC Foundation reference implementation of OPC UA for .NET — a certified, 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.
  • Certified for compliance — the reference server has been certified through an OPC Foundation Certification Test Lab and is continuously verified against the latest Compliance Test Tool (CTT).
  • 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 40200 (Weighing Technology) with OPC 30050 (PackML).
  • Hosting and code generation — Microsoft.Extensions.DependencyInjection hosting (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 the .NET 10 SDK to build the repo. 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 pulls in everything, or reference 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

  • 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, 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.MigrationAnalyzer NuGet — install it in your project to get 26 analyzer rules through UA0030 (excluding UA0013, UA0016, UA0017, and the shim-only UA0029) 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-migration skill walks Copilot / Claude / any coding agent through installing the NuGet, running dotnet format analyzers to 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

S
Description
OPC Unified Architecture .NET Standard
Readme
296 MiB
Languages
C# 99.4%
PowerShell 0.2%