93559d06d3
## Why the CTT *Alarms and Conditions* group was so slow
I measured every A&C CU with a fresh `ConsoleReferenceServer --ctt` (CTT
1.05.06, scripts 1.05.513), read the per-test `ResultNode` timestamps,
and added `addLog` timing/counter instrumentation to a copy of the CTT
project.
| Cause | Effect |
| --- | --- |
| **CertificateExpiration** opens a modal dialog in `initialize.js`
("adjust the clock on the server"), and it also appears in `--hidden`
runs | The CTT never exits. This is why the whole group "did not finish
in 40 minutes". |
| **Limit/Level CUs:** `initialize.js` idles the CU session for one
Alarm Cycle Time (60 s) during the initial capture.
`RequestedSessionTimeout` is also 60 s. | The server correctly closes
the session. `LimitHelper` then gets `BadSessionIdInvalid` for its 5
filter subscriptions, and Test_003–006 each run 180 s, about 14 min per
CU. |
| Alarm `Test_002` never gives the AcknowledgeableCondition type a
result | Always runs 3 × cycle (180 s). |
| Enable `Test_003` needs every alarm type to go active within cycle/10
| Timed out in 6 of 7 runs, because boolean and analog alarms changed
state on different ticks. |
| Enable `Err_004` answers each event with Disable/Disable/Enable |
Feedback burst, after which the CTT alarm thread sometimes returns no
events. Details below. |
| Comment `Test_001`–`004` compare against
`CallHelper.ServerTimeOfCall`, which the CTT never sets (`0001-01-01`) |
Every comment event counts as unrelated, and the tests skip after 3
retries. The server's events carry the expected comment. |
Measured CU by CU, the group took **about 87 min plus the hang**. With
the fixes below, running the whole group in one CTT process without
CertificateExpiration takes **18:45** at Alarm Cycle Time 30. The per-CU
table is in `plans/ctt-testing.md` §6.
## Server changes
- **Refresh one subscription per request, not one per Call**
(`AlarmNodeManager.CallAsync`). The sample answered every
ConditionRefresh/ConditionRefresh2 after the first one in a Call with
`Bad_RefreshInProgress`, even for other subscriptions, and never
forwarded them. So CTT Refresh `Err_004` (10 subscriptions per Call)
only ever refreshed one of them. The check is now keyed by
SubscriptionId and MonitoredItemId.
- Regression tests:
`AlarmsAndConditionsRefreshTests.ConditionRefresh[2]OfDifferentSubscriptionsInOneCallSucceedsAsync`.
Both fail without the fix.
- **Boolean alarm source now uses the analog source's steps and limits**
(`AlarmController`, `ConditionTypeHolder.GetSeverity`). OffNormal,
Discrete and SystemOffNormal alarms now change state on the same tick as
the limit alarms (5 per second, 70/90/30/10), and the shortest state
still lasts 4 s.
- With this, Enable `Test_003` passed in 4 s instead of a timeout.
Confirm `Test_001` for the boolean types also stopped failing in both
group runs.
- Test:
`AlarmControllerTests.BooleanAndAnalogSourcesChangeStateOnTheSameStep`
(fails without the change).
- **Alarm controllers step on shared interval boundaries**
(`AlarmController.SetNextInterval`). Scheduling relative to the last
step let the two controllers drift up to one 100 ms simulation tick
apart, so the boolean events sometimes landed in a later publish and
Enable `Test_003` still timed out in 3 of 5 runs. With shared boundaries
it passed in 6 of 6 runs.
- Test:
`AlarmControllerTests.ControllersScheduleTheirStepsOnSharedIntervalBoundaries`.
I did not make the simulation faster. Acknowledge, Confirm and Comment
tests call methods with the EventId of the event they just received, and
a shorter state would make them race the next transition.
## Not reproduced / not a server defect
- **Refresh `Err_004` `BadSubscriptionIdInvalid` cascade.** In the
original run the alarm-thread session's subscriptions (15.5 s lifetime)
were gone after the script's 30 s wait. Nine further CTT runs passed all
28 Refresh/Refresh2 cases. An in-process replay with a sequential
publisher kept every subscription; that replay is what exposed the
refresh defect above.
- **Enable event stall (C43) is inside the CTT.** A server build that
logs every returned notification message showed that during a stall the
server sent 435 and 420 events to the two CTT event items in 173
messages, and the CTT acknowledged all of them, while its alarm-thread
buffers returned nothing. It only happens after `Err_004`'s
Disable/Enable feedback burst, in 8 of 28 runs.
## Docs
- `plans/ctt-testing.md`: new §6 *Alarms and Conditions*, covering the
recommended run, where the time goes, how to instrument a run and the
expected result. Also a note that a hidden CTT run can block on dialogs,
so always use a timeout.
- `plans/ctt-issues.md`: the A&C "open server findings" are replaced
with these results, and there are new CTT script defects C39–C44 plus
configuration notes (Shelving chattering alarms, Alarm Cycle Time vs
session timeout).
## Tests
- `Opc.Ua.History.Tests` A&C + AlarmClient: 155 passed.
- `Opc.Ua.Server.Tests` `AlarmControllerTests` /
`QuickstartsServerUtilitiesTests`: 4 passed.
- CTT whole-group runs (27 CUs, 128 cases): 18:45 at cycle 30 and 29:23
at cycle 60 on this branch; 23:43 and 24:21 with only the refresh fix.
The spread comes from the Enable stall (C43).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: romanett <7413710+romanett@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 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, and .NET Standard 2.1; 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 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), 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), OPC 40001-1 (Industrial Automation), OPC 40010-1 (Robotics).
- Modern developer surface — first-class
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
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.
Official public 2.0 preview releases are also on nuget.org. Enable prerelease
packages and use 2.0.0-preview.* to float to the latest published
2.0.0-preview.N release.
Samples
The stack also includes a large collection of platform-independent sample applications that turn its core services and companion models into runnable 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 that exposes OPC UA client operations as MCP tools for LLMs and Copilot. The tools also ship as libraries (
…Opc.Ua.Mcp.Core,.PubSub,.Diagnostics,.PubSub.Diagnostics) so an application can embed them next to its own MCP tools.
🔧 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 small residual manual patterns. The skill knows which sub-doc to load for each symptom so it stays context-efficient.
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.