Klaus LandsdorfandMarc Schier 0bd7aaaad6 AutoID: keep every reader reachable from DeviceSet, and let a reader be a component of a machine (#4853)
# Description

Follow-up to the AutoID companion (#4825). Two changes to where the
AutoID server places its readers:

1. **`IAutoIdReaderBuilder.WithParent` is made conformant with OPC
10000-100 4.9.** Until now it placed a reader below another node
*instead of* `DeviceSet`, and the docs suggested "a component of a
machine" as the use case. A machine in the Machinery `Machines` folder
is not reachable from `DeviceSet`, so such a reader could not be located
from `DeviceSet`, which DI 4.9 requires for every `ComponentType`
instance (every AutoID device type derives from DI `DeviceType`). Now
the reader is still placed below the parent (`HasComponent`, unchanged),
and:
- when `DeviceSet` already reaches the parent through hierarchical
references (for example another reader, or any device it organizes),
nothing else is added: the reader is a component of a composed device
and DI 4.9 wants "only the root instance" referenced from `DeviceSet`;
- otherwise `DeviceSet` also organizes the reader (`Organizes`, both
directions), so it stays locatable.
2. **New opt-in `IAutoIdReaderBuilder.AsComponentOf(BaseObjectState
machine)`**, available only when AutoID is composed with Machinery
(`AddAutoIdToMachinery`, or a DI owner that loads the Machinery model).
It makes the reader an identifiable component of the machine per OPC
40001-1 11:
- the reader is placed below the machine's `Components` add-in
(`HasComponent`, as `MachineComponentsType` declares for `<Component>`);
- it gets the `2:Identification` add-in (`HasAddIn`) typed
`MachineryComponentIdentificationType`, which holds no copies: it
references the reader's own DI nameplate properties with `HasProperty`
(`Manufacturer`, `SerialNumber`, and those of `Model`,
`ManufacturerUri`, `ProductCode`, `HardwareRevision`,
`SoftwareRevision`, `DeviceRevision`, `DeviceClass`,
`ProductInstanceUri` that are set, plus `AssetId`/`ComponentName` when
published; `DeviceManual` and `RevisionCounter` are left out as 40001-1
10.2 recommends);
- the reader stays a device: the same `DeviceSet` rule as for
`WithParent` applies with `Components` as the parent, so in the usual
case (a machine in `Machines` that `DeviceSet` does not reach)
`DeviceSet` organizes it directly. It is not added to `Machines`.
- Checked before anything is registered, each failing with
`Bad_ConfigurationError` and a message naming the way out: the server
has no Machinery model (names `AddAutoIdToMachinery`), the machine is
not a node of the AutoID owner, the machine has no `Components` add-in
(names `WithComponents`), or the reader nameplate lacks `Manufacturer`
and/or `SerialNumber` (mandatory in `MachineryItemIdentificationType`).
`WithParent` and `AsComponentOf` exclude each other
(`InvalidOperationException`).

Default behaviour is unchanged: a reader built without
`WithParent`/`AsComponentOf` is organized by `DeviceSet` and not added
to `Machines`. Rollback on failure covers the new references: a failed
build removes the `DeviceSet` reference, the component and its add-in,
so the name can be used again.

## Specification basis

| Statement | Source |
| --- | --- |
| "The DeviceSet Object is the starting point to locate Devices. It
shall either directly or indirectly reference all instances of a subtype
of ComponentType with a Hierarchical Reference. For complex Devices that
are composed of various components that are also Devices, only the root
instance shall be referenced from the DeviceSet Object. The components
of such complex Devices shall be locatable by following Hierarchical
References from the root instance." | OPC 10000-100 (DI) 1.05.0, 4.9 |
| AutoID device types are "Subtype of DeviceType defined in OPC
10000-100". OPC 30010 does not mention `DeviceSet`, Machinery or
`Machines`. | OPC 30010 (AutoID) 1.01, 6.1 Table 7 |
| "Each Machine providing this building block provides the Components
Object, which directly references all identifiable components of a
Machine." / "Note: That does not preclude that a Machine is organizing
its components in various other hierarchies as well." | OPC 40001-1
(Machinery) 1.04.2, 11.1 |
| "The MachineComponentsType provides HasComponent References to all
identifiable components of a Machine"; Table 27: `0:HasComponent Object
<Component> 0:BaseObjectType OP`; Table 28: `<Component> 0:HasAddIn
Object 2:Identification MachineryItemIdentificationType M`; "As all
identifiable components shall contain the Identification Object". | OPC
40001-1 1.04.2, 11.2 |
| `MachineryItemIdentificationType`: `2:Manufacturer` M,
`2:SerialNumber` M, all other members O. | OPC 40001-1 1.04.2, 8.3 Table
16 |
| `MachineryComponentIdentificationType` is the component subtype of
`MachineryItemIdentificationType` (adds `2:DeviceRevision`); "It is not
recommended to use the optional Properties 2:RevisionCounter and
2:DeviceManual"; a missing component `2:ProductInstanceUri` "shall be
omitted". | OPC 40001-1 1.04.2, 10.2 |
| "it is recommended to keep this approach and let several References
lead to the same Node, rather than duplicating the Node" / Robotics
example: identification Properties "are only referenced from the
Identification functional group". | OPC 40001-1 1.04.2, 7.3 and Annex
B.2 (informative) |
| "It is expected that domain-specific companion specifications using
this specification will define what assets of the domain in what usage
are considered to be Machines or components of Machines." | OPC 40001-1
1.04.2, 11.1 (Note) |
| Organizes "can be used to span multiple hierarchies"; more than one
hierarchical path to a Node is allowed. | OPC 10000-3 1.05, 7.11, 7.5 |

**SDK decisions** (not specified by OPC 30010, which predates
Machinery):

- A reader is never added to `Machines`: no specification classifies an
AutoID device as a machine (40001-1 11.1 leaves that to the domain
specifications, AutoID is silent).
- A reader becomes a component of a machine only when the application
asks for it (`AsComponentOf`).
- `WithParent` keeps its parent and adds the `DeviceSet` reference
rather than rejecting parents outside `DeviceSet` (see below).
- The component `Identification` references the reader's nameplate
instead of copying it.
- AutoID does not add Machinery conformance units; the Machinery owner
advertises them for what its builders created.

### Why `WithParent` adds a reference instead of rejecting

DI 4.9 asks for reachability, not for a particular parent, and OPC
10000-3 allows several hierarchical paths to one node. Adding
`Organizes` from `DeviceSet` satisfies the "shall" while keeping the
parent the application asked for, and it is the same reference type
`DeviceSet` already uses for every reader (and the DI node manager for
every device). Rejecting such parents with `Bad_ConfigurationError`
would break existing callers that hang a reader below a machine or
folder. When `DeviceSet` already reaches the parent, no reference is
added, so the "only the root instance" rule of 4.9 holds for composed
devices. Reachability is decided once when the reader is built, by
following the forward hierarchical references of the owner's nodes.

### Why `AsComponentOf` keeps the reader referenced from `DeviceSet`

Machinery does not require machines to be in `DeviceSet` (the stock
builders put them in `Machines` only), so a reader that is only below
`Components` would again be unreachable from `DeviceSet`. The same
reachability rule as for `WithParent` applies: if the machine is itself
reachable from `DeviceSet` (for example a machine that is also a DI
device organized by `DeviceSet`), the reader is reached through it and
gets no direct reference, otherwise `DeviceSet` organizes it.

### Shape of `AsComponentOf`

It takes the machine's `BaseObjectState`, like `WithParent(NodeState)`
and `IMachineryBuildContext.BindMachine(TState, ...)`; with the stock
builders that is `IMachineHandle<TState>.State`. It requires the
machine's `Components` add-in to exist
(`IMachineBuilder.WithComponents`, or a companion-declared one bound
with `WithComponents(components, ...)`) instead of creating one, so the
Machinery builders stay the only place that creates Machinery building
blocks (`MachineryBuildingBlocks` organization, facets). The reader's
NodeState parent is the `Components` object, so the DI node manager
attaches it with `HasComponent` and the existing registration and
rollback code applies unchanged.

## Behaviour change for existing callers

- `WithParent(parent)` with a parent that `DeviceSet` does not reach
(for example a machine in `Machines`, or an application folder): the
reader is now *also* browsable from `DeviceSet` (one extra `Organizes`
reference, both directions), and an
`AutoIdClient.EnumerateReadersAsync()` (which browses `DeviceSet`) now
finds it. Its parent, NodeId and `HasComponent` reference are unchanged.
- `WithParent(parent)` with a parent `DeviceSet` reaches (for example
another reader): unchanged.
- Default placement: unchanged.
- `IAutoIdReaderBuilder` gains a member. The interface is implemented
only inside the package (instances come from `AutoIdRuntime.Reader`),
and the package is new in 2.0.

## Changes

- `src/Opc.Ua.AutoID.Server/AutoIdReaderPlacement.cs` (new, internal):
`DeviceSet` lookup, the reachability check, the `Organizes` reference
and its removal, `Components` resolution and validation, the nameplate
check, and the `Identification` add-in.
- `src/Opc.Ua.AutoID.Server/AutoIdRuntime.cs`: the builder's nameplate
delegate runs once (validated before anything is registered, then copied
into the DI builder); `AsComponentOf` resolves `Components` as the
parent before the device is created; after registration the add-in is
added and the `DeviceSet` reference kept; rollback removes the
reference.
- `src/Opc.Ua.AutoID.Server/Builders/IAutoIdReaderBuilder.cs`,
`AutoIdReaderBuilder.cs`: `AsComponentOf`, mutual exclusion with
`WithParent`, XML docs stating the exact behaviour.
- `docs/AutoID.md`: new "Placement" subsection under "Hosting readers"
(what DI 4.9 and Machinery 11 require, what is an SDK decision, a table
per builder call, an example), the composition table rows for readers
and `Machines`, the test fixture table.
`src/Opc.Ua.AutoID.Server/NugetREADME.md`: a short paragraph.
- Tests (below).

## Tests

- `AutoIdReaderLifecycleTests` (stand-alone owner):
`ReadersCanHangBelowAnExplicitParentAsync` now also asserts that
`DeviceSet` does not organize a reader below another reader;
`AReaderBelowAParentOutsideTheDeviceSetIsStillOrganizedByItAsync`;
`AFailedCreationBelowAnOutsideParentLeavesNoDeviceSetReferenceAsync`
(rollback); `AStandaloneReaderCannotBeAComponentOfAMachineAsync`
(`Bad_ConfigurationError` naming `AddAutoIdToMachinery`); argument
checks for `AsComponentOf(null)` and both call orders of
`WithParent`/`AsComponentOf`.
- `AutoIdCompositionTests` (Machinery owner, in process):
`AReaderBecomesAComponentOfAMachineAndStaysADeviceAsync` (parent is
`Components`, `HasComponent`, `DeviceSet` organizes it, `Machines` does
not, `Identification` with `HasAddIn` and the component type,
`HasProperty` to the reader's own `Manufacturer`/`SerialNumber`/`Model`
nodes, no `DeviceManual`, owned subtree);
`AComponentNeedsAMachineWithComponentsAndRegistersNothingOtherwiseAsync`;
`AComponentNeedsTheMandatoryIdentificationAsync`;
`AComponentNeedsAMachineOfTheOwnerAsync`;
`AFailedComponentCreationIsRolledBackAsync`.
- `AutoIdPlacementEndToEndTests` (new, hosted Machinery + AutoID over a
real session): a default reader, a reader below that reader, a reader
`AsComponentOf` a machine and a reader `WithParent` the machine.
Browsing `DeviceSet` finds the three roots and not the nested reader,
the outer reader reaches the nested one;
`MachineryClient.DiscoverMachinesAsync` returns only the machine and
`Machines` contains no reader;
`MachineryClient.EnumerateComponentsAsync` lists only the component
reader, `ReadIdentificationAsync` reads `Manufacturer`, `SerialNumber`,
`ProductCode` through the add-in, which is `HasAddIn`-referenced and
typed `MachineryComponentIdentificationType` and whose `HasProperty`
targets are the reader's own nameplate nodes;
`AutoIdClient.EnumerateReadersAsync` finds the three roots.
- The existing default assertions
(`TheReadersShareTheDeviceSetWithThePumpAndStayOutOfTheMachinesFolderAsync`,
`TheMachineryAndPumpsClientsStillFindTheirInstancesAsync`,
`ComposedReadersLiveBelowTheSharedDeviceSetAsync`) are unchanged.
- Fail-without: with the runtime wiring reverted to master (builder
surface kept so the tests compile), 10 of the new tests fail: all
`AsComponentOf` cases, both `WithParent` cases outside `DeviceSet` and
the three session tests that look for the component or the extra
`DeviceSet` reference. Removing only the rollback of the `DeviceSet`
reference makes both rollback tests fail. `NoReaderBecomesAMachineAsync`
and the existing default tests pass with and without the change, as
intended.

Local results (macOS arm64, SDK 10.0.402, head `238ed9b69` on master
`9bfc780e1`; the same three commits are now based on master `ac24123dd`
as `c6d70909b`, no AutoID file changed in between):
`Opc.Ua.AutoID.Tests` net10.0 318/318 passed; `Opc.Ua.AutoID.Server` all
TFMs and the test project with `CustomTestTarget=net48` build with 0
warnings, 0 errors (net48 tests run on Windows CI; there is no mono host
here). `dotnet format whitespace/style/analyzers --verify-no-changes` on
the changed files: no new findings beyond the conventions of the
surrounding test files.

## Commits

1. `fix(autoid): keep every reader reachable from DeviceSet`
2. `feat(autoid): make a reader a component of a machine`
3. `docs(autoid): document where readers are placed`

The branch is based on OPCFoundation/master `ac24123dd` (#4852, the last
master commit with a green build). Fork CI was not repeated on this
head: earlier fork runs of this branch failed only in test projects
outside this PR (the master build was broken by the NUnit 5 migration
#4840 and fixed in #4852; master is currently broken again in
`Opc.Ua.Core.Tests` by #4849). The upstream checks of this PR test it
against the current master.

## Related Issues

- Follow-up to #4825 (tracking issue #4824).
- #4823 (open) edits prose in other paragraphs of `docs/AutoID.md`
(table of contents, the DI-owner paragraph, providers). This PR adds a
subsection and changes two rows of the composition table and one row of
the test table; no hunk overlaps. The table of contents is deliberately
not touched here because #4823 adds the subsection entries for "Hosting
readers"; the "Placement" entry can be added there or after both are
merged.

## 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.
- [x] I have added all necessary documentation.
- [x] I have verified that my changes do not introduce (new) build or
analyzer warnings. (Local build of the changed projects: 0 warnings, 0
errors.)
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed. (Locally
the AutoID test project on net10.0; net48 is built but runs only on
Windows CI.)
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings. (Pending the upstream checks; see the CI note
above.)
- [x] I have addressed **all** PR feedback received.

---------

Co-authored-by: Marc Schier <marcschier@users.noreply.github.com>
2026-10-21 05:24:38 +00: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 30010 (AutoID Devices), 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, 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.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
290 MiB
Languages
C# 99.4%
PowerShell 0.2%