Skip to content

AutoID.md

Latest commit

 

History

History
1108 lines (955 loc) · 65.3 KB

AutoID.md

File metadata and controls

1108 lines (955 loc) · 65.3 KB
Raw

AutoID Devices

The AutoID packages implement OPC 30010 OPC UA for AutoID Devices (release 1.01, 2020-06-18): RFID readers, OCR readers, optical (barcode) readers and verifiers, and real-time locating systems (RTLS), with their scan results, tag access methods, diagnostics events and optional read-only diagnostic variables.

Provider-backed runtime parameters and variable-triggered scanning share the existing configuration and operation-ownership paths. Optional RFID and OCR/optical parameters require explicit provider capabilities. Typed Data Access clients configure readers and observe acquisition timestamps. Optional CodeTypesRWData uses a provider formatter for diagnostic user data; the simulated RFID provider supports RAW:BYTES. This projection changes neither method outputs nor event payloads. Hardware-specific IOData definitions remain application-owned. WithIOData composes their bindings; WithImages publishes acquired image files through standard FileType transfer. SDK support covers the defined mandatory and optional capabilities, with the published contract limits documented explicitly rather than supplied with invented signatures.

Package What it adds
Opc.Ua.AutoID The information model: node states, DataTypes, identifiers, encodeables and client proxies
Opc.Ua.AutoID.Server Reader hosting on the Device Integration node manager, a provider contract for the reader hardware, the OPC 30010 methods and events, simulated readers
Opc.Ua.AutoID.Client Reader discovery, typed scan and tag calls, device snapshots and an asynchronous stream of events
Opc.Ua.Mcp.AutoID Nine bounded MCP tools; no tool changes a tag

The AutoID sample runs a simulated RFID reader end to end.

Contents

Model and dependencies

Item Value
Package OPCFoundation.NetStandard.Opc.Ua.AutoID
Model URI http://opcfoundation.org/UA/AutoID/
Model version 1.01, published 2020-06-18
Required models OPC UA 1.03, Device Integration 1.01 (lower bounds)
Generated CLR namespace Opc.Ua.AutoID
Source UA-Nodeset latest/AutoID

AutoIdDeviceType derives from the DI DeviceType, so the package references Opc.Ua.Di and loads the DI model the stack ships, which is newer than the required 1.01.

What the model package contains

  • The device types AutoIdDeviceType (abstract), RfidReaderDeviceType, OcrReaderDeviceType, OpticalReaderDeviceType, OpticalVerifierDeviceType and RtlsDeviceType, with their methods (Scan, ScanStart, ScanStop, ReadTag, WriteTag, WriteTagID, KillTag, LockTag, SetTagPassword, GetLocation, ...) as typed method states.
  • The event types AutoIdScanEventType with one subtype per reader kind, AutoIdDiagnosticsEventType, AutoIdAccessEventType, RfidAccessEventType, AutoIdLogEntryEventType and AutoIdPresenceEventType.
  • The DataTypes: the ScanData and Location unions, the abstract ScanResult with RfidScanResult, OcrScanResult, OpticalScanResult, OpticalVerifierScanResult and RtlsLocationResult, the access results AccessResult and RfidAccessResult, ScanSettings, RfidSighting, ScanDataEpc, the coordinate structures and six enumerations.
  • AutoIdModel (model identity, GetNamespaceUris()) and the AddAutoIdTypeSystem registration overloads.

The scan event subtypes and RfidAccessEventType narrow the DataType of their ScanResult or AccessResult property to a structure subtype. The generated states expose the property with that type, for example RfidScanEventState.ScanResult is a PropertyState<ArrayOf<RfidScanResult>>.

Loading the model

using Opc.Ua;
using Opc.Ua.AutoID;

// Encodeables (DI and AutoID); the caller commits the builder.
messageContext.Factory.Builder.AddAutoIdTypeSystem().Commit();

// Type nodes for a node manager's predefined nodes.
var predefinedNodes = new NodeStateCollection();
predefinedNodes.AddAutoIdTypeSystem(systemContext);

// Typed node states for instances of the AutoID types.
nodeStateFactory.AddAutoIdTypeSystem();

AddAutoIdTypeSystem loads DI before AutoID, registers missing namespaces and skips roots that are already present, so it can be combined with other models that also load DI.

Scan data and scan results

ScanData is a union: SwitchField selects the ByteString, String, Epc or Custom arm. The scan and access results have optional fields; set the corresponding bits in EncodingMask to send them.

var result = new RfidScanResult
{
    CodeType = "EPC",
    ScanData = new ScanData
    {
        SwitchField = ScanDataFields.Epc,
        Epc = new ScanDataEpc { PC = 0x3000, UId = ByteString.From(epc) }
    },
    Timestamp = DateTimeUtc.Now,
    Sighting = [new RfidSighting { Antenna = 1, Strength = -52 }]
};

The NodeSet defines binary and XML encodings; JSON uses the DataType NodeIds.

Hosting readers

A server has one Device Integration DeviceSet, and exactly one node manager owns the DI namespace. Readers are therefore hosted in one of two ways:

  • AddAutoId registers a node manager of its own that loads the DI and AutoID models and creates one device per reader below DeviceSet. Use it when AutoID is the only DI-based companion of the server.
  • AddAutoIdModel loads the AutoID model into the Machinery node manager of AddMachinery, which then owns DI for every companion of the server; the readers are created in that manager, below the same DeviceSet as the machines, pumps or scales. See Coexisting with a server that already owns DI.
using Microsoft.Extensions.DependencyInjection;
using Opc.Ua.AutoID.Server;

services.AddOpcUa()
    .AddServer(options => { /* application name, endpoints, PKI */ })
    .AddAutoId(options => options.MaximumScanDuration = TimeSpan.FromSeconds(10))
    .ConfigureAutoId(async context =>
    {
        AutoIdReader reader = await context.Runtime
            .Reader(new QualifiedName("DockDoor1", context.Manager.InstanceNamespaceIndex), hardware)
            .WithDeviceInfo("Dock door antenna portal")
            .WithDeviceLocationName("Dock 1, gate A")
            .WithAntennaNames([new AntennaNameIdPair { AntennaId = 1, AntennaName = "Left post" }])
            .WithIdentification(nameplate => nameplate.SerialNumber = "R100-0001")
            .BuildAsync(context.CancellationToken);
    });

Reader(...) returns a builder; nothing is registered before BuildAsync. The builder materialises exactly the components the provider supports (a reader without a Scan provider has no Scan method), registers the device, makes it an event notifier and attaches the provider. A failure at any step is rolled back: the browse name can be used again and a provider the build owns (OwnsProvider()) is disposed. Concurrent builds of one name admit exactly one. Disposing the runtime (the node manager does so on shutdown) stops every reader's scans, detaches its provider and, for a provider the reader owns (OwnsProvider()), disposes it.

AutoIdServerOptions bounds what a client can ask for:

Option Default Effect
MaximumScanDuration 30 s A synchronous Scan asking for more is Bad_InvalidArgument; a provider that does not return in time is cancelled and the call fails with Bad_Timeout
MaximumTagReadLength 65536 A longer ReadTag is Bad_InvalidArgument
MaximumScanResults 1000 More results fail the scan with Bad_ResponseTooLarge instead of being truncated
PublishAccessEvents true Whether commands that reach a tag raise access events
AdditionalNamespaceUris none Extra namespaces to register

The readers keep their scan state (Idle_0, Scanning_2, Busy_3, Error_1) in DeviceStatus. AutoIdReader.SetFaultedAsync(true) reports Error_1: new scans then return DEVICE_NOT_READY_17 and an active asynchronous scan stops. Fault and recovery operations retain admission through status callbacks and the optional stop; disposal waits for them before disposing an owned provider. The error status is published before stopping. A rejected or cancelled stop retains the active scan and error status until provider confirmation; repairing the device restores the status of its current activity. SetDeviceLocation moves the DeviceLocation of a mobile reader.

Coexisting with a server that already owns DI

AddAutoId claims the Device Integration address space like AddOpcUaDi, AddMachinery, AddPumps or AddScales, so registering it together with another DI owner, in either order, throws InvalidOperationException while the services are registered; the message names the current owner and the composition API. The check prevents duplicate DI address spaces: two DI owners would each load their own copy of DeviceSet, the server would route DeviceSet to the first one, and readers created in the second one would not be browsable.

To host readers next to machines, call AddAutoIdModel after AddMachinery and create the readers with ConfigureAutoIdFor<TNodeManager>. Other Machinery-based companions compose into the same owner:

using Microsoft.Extensions.DependencyInjection;
using Opc.Ua;
using Opc.Ua.AutoID.Server;
using Opc.Ua.Machinery.Server;

services.AddOpcUa()
    .AddServer(options => { /* application name, endpoints, PKI */ })
    .AddMachinery(options =>
    {
        options.Parts = MachineryParts.BuildingBlocks;
        options.InstanceNamespaceUri = "urn:acme:plant:instances";
    })
    .AddPumpsToMachinery()                       // optional, any *ToMachinery companion
    .AddAutoIdModel(options => options.MaximumScanDuration = TimeSpan.FromSeconds(10))
    .ConfigureMachinery(async (machinery, ct) =>
    {
        await machinery.AddMachine(new QualifiedName("Press1", machinery.InstanceNamespaceIndex))
            .WithIdentification(id =>
            {
                id.Manufacturer = new LocalizedText("Acme");
                id.SerialNumber = "PR-1";
                id.ProductInstanceUri = "urn:acme:press:1";
            })
            .BuildAsync(ct);
    })
    .ConfigureAutoIdFor<MachineryNodeManager>(async (context, ct) =>
    {
        AutoIdReader reader = await context.Runtime
            .Reader(new QualifiedName("PressInfeed", context.Runtime.InstanceNamespaceIndex), hardware)
            .WithDeviceInfo("Infeed portal of Press1")
            .BuildAsync(ct);
    });
Item In the composed server
Node managers The MachineryNodeManager alone; no AutoIdNodeManager is created
Device Integration model, DeviceSet Loaded once by the Machinery owner's core model provider
AutoID model Added to the owner by AutoIdModelProvider, with AdditionalNamespaceUris
Readers Below the owner's DeviceSet (Organizes), NodeIds in MachineryServerOptions.InstanceNamespaceUri; take browse names from context.Runtime.InstanceNamespaceIndex. WithParent and AsComponentOf place a reader elsewhere and keep it reachable from DeviceSet, see Placement
Machines folder Readers are devices, not machines, and are not added to it; AsComponentOf makes one a component of a machine
Methods, events, providers As in the stand-alone server; the readers are event notifiers of the owner
Conformance The runtime contributes the AutoID units and facets to the owner, which publishes them with the DI and Machinery ones
Lifetime The owner disposes the runtime on shutdown: scans stop, providers detach, owned providers are disposed

Successive ConfigureAutoIdFor<MachineryNodeManager> delegates run in registration order in the DI post-setup pipeline. Register Machinery configuration first; then the reader callbacks run after it and share one AutoIdRuntime. context.Manager is the Machinery owner. ConfigureAutoIdFor<AutoIdNodeManager> works with AddAutoId and receives the stand-alone runtime, so configuration code can be shared by both hosting paths. Opc.Ua.AutoID.Server references only the Machinery model for component identification. A stand-alone server loads only the DI and AutoID models.

AddAutoIdToMachinery remains available as an obsolete alias of AddAutoIdModel in the same server package. It forwards options and model registration without claiming an owner or depending on the Machinery server package. Use AddAutoIdModel in new code and register owner configuration before dependent reader callbacks.

For a plain DI owner, use AddOpcUaDi().AddAutoIdModel() and ConfigureAutoIdFor<DiNodeManager>. The DI hosting guide describes AddDiModel<AutoIdModelProvider, TNodeManager>(configure), which combines model registration with an owner-targeted callback. The same helper accepts other companion providers and DI-derived owners without another integration package.

Placement

OPC 30010 does not say where readers live in the address space; the rules come from the specifications it builds on.

Rule 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." Every AutoID device type derives from DI DeviceType, a ComponentType. OPC 10000-100 1.05.0 4.9; OPC 30010 6.1
"For complex Devices that are composed of various components that are also Devices, only the root instance shall be referenced from the DeviceSet Object." OPC 10000-100 1.05.0 4.9
The Components object of a machine "directly references all identifiable components of a Machine", with HasComponent, and each component carries the 2:Identification add-in (HasAddIn) whose Manufacturer and SerialNumber are mandatory. OPC 40001-1 1.04.2 11.1, 11.2 (Tables 27, 28), 8.3
Machinery and DI place no requirement on each other: a machine need not be in DeviceSet, and a device need not be in Machines. OPC 40001-1 1.04.2, OPC 10000-100 1.05.0

The SDK applies them as follows:

Builder call Where the reader is Reference from DeviceSet
none (default) Below DeviceSet Organizes
WithParent(parent), DeviceSet reaches parent (for example another reader) Below parent (HasComponent) None: the reader is a component of a composed device whose root DeviceSet references
WithParent(parent), DeviceSet does not reach parent Below parent (HasComponent) Organizes to the outermost DI component in the parent chain, added by the owner
AsComponentOf(machine) Below the machine's Components (HasComponent), with an Identification add-in As for WithParent with the Components object as parent: usually Organizes, because a machine in Machines is not necessarily reachable from DeviceSet

Whether DeviceSet reaches the parent is decided when the reader is built, by following the forward hierarchical references of the owner's nodes. A child attached by a non-hierarchical reference, such as a condition by HasCondition, is no path from DeviceSet.

Where OPC 30010 is silent, these are SDK decisions: a reader is not added to the Machines folder, because no specification classifies an AutoID device as a machine (OPC 40001-1 11.1 leaves that to the domain specifications), and a reader is a component of a machine only when the application asks for it.

AsComponentOf needs AutoID composed into the Machinery owner (AddMachinery().AddAutoIdModel() or a DI owner that loads the Machinery model) and a machine of that owner that publishes the Components add-in, here built with WithComponents. The runtime finds the add-in through the HasAddIn reference from the machine's MachineryBuildingBlocks folder (OPC 40001-1 7.1). This also finds a container declared by a companion model and bound with WithComponents(existing, ...), regardless of its parent or browse name. Without that folder, the runtime uses the machine's MachineComponentsType child:

IMachineHandle<BaseObjectState>? press = null;
builder
    .ConfigureMachinery(async (machinery, ct) =>
        press = await machinery.AddMachine(new QualifiedName("Press1", machinery.InstanceNamespaceIndex))
            .WithIdentification(id =>
            {
                id.Manufacturer = new LocalizedText("Acme");
                id.SerialNumber = "PR-1";
                id.ProductInstanceUri = "urn:acme:press:1";
            })
            .WithComponents(_ => { })
            .BuildAsync(ct))
    .ConfigureAutoIdFor<MachineryNodeManager>(async (context, ct) =>
        await context.Runtime
            .Reader(new QualifiedName("PressInfeed", context.Runtime.InstanceNamespaceIndex), hardware)
            .AsComponentOf(press!.State)
            .WithIdentification(nameplate =>
            {
                nameplate.Manufacturer = new LocalizedText("Acme");
                nameplate.SerialNumber = "R100-0001";
            })
            .BuildAsync(ct));

The reader gets the 2:Identification add-in typed MachineryComponentIdentificationType. It holds no copies: it references the reader's own DI nameplate properties with HasProperty. This follows the approach of OPC 40001-1 7.3 ("let several References lead to the same Node, rather than duplicating the Node") and of the Robotics example in Annex B.2, whose identification Properties "are only referenced from the Identification functional group". It references Manufacturer, SerialNumber and those of Model, ManufacturerUri, ProductCode, HardwareRevision, SoftwareRevision, DeviceRevision, DeviceClass and ProductInstanceUri that are set, plus AssetId and ComponentName when the reader publishes them; DeviceManual and RevisionCounter are left out as OPC 40001-1 10.2 recommends. A missing Manufacturer or SerialNumber, a machine of another node manager, a machine without Components or with more than one, or a server without the Machinery model fail the build with Bad_ConfigurationError before anything is registered. WithParent and AsComponentOf exclude each other. The runtime does not add Machinery conformance units; the Machinery owner advertises them for what its builders created.

Direct composition and lifetime

Without dependency injection, pass new AutoIdModelProvider() in the provider collection of the four-argument DiNodeManager constructor, or load AutoID from a custom owner's LoadPredefinedNodesAsync with nodes.AddAutoIdTypeSystem(context). Once the address space is created:

AutoIdRuntime autoId = owner.CreateAutoIdRuntime();
AutoIdReader reader = await autoId.CreateReaderAsync(
    new QualifiedName("PressInfeed", autoId.InstanceNamespaceIndex), hardware, ct);

The first CreateAutoIdRuntime(options) call selects the options; later calls return the same runtime, and on an AutoIdNodeManager it returns its Runtime. The stand-alone AutoIdNodeManager is built from the same pieces: a Device Integration owner that loads DI and then AutoIdModelProvider. Any DI owner can call CreateAutoIdRuntime() or use ConfigureAutoIdFor<TOwner>. The runtime registers its lifetime with DiNodeManager.RegisterResource, so the owner disposes it automatically. Custom owners no longer need a Machinery-specific disposal override.

Providers

A reader exposes a hardware provider through OPC UA. The base contract IAutoIdReaderProvider (kind, attach, detach) is enough for a device that scans on its own (OPC 30010 6.1.1 option 3): the provider reports through the IAutoIdReaderSink it receives when attached. Capabilities are added by implementing more interfaces:

Interface Methods it enables
IAutoIdScanProvider Scan
IAutoIdAsyncScanProvider ScanStart, ScanStop
IAutoIdRfidProvider (SupportedOperations) ReadTag, WriteTag, WriteTagID, KillTag, LockTag, SetTagPassword, each only when listed
IAutoIdRtlsProvider GetLocation, GetSupportedLocationTypes
IAutoIdScanParametersProvider Opt-in RuntimeParameters; with IAutoIdAsyncScanProvider, opt-in ScanActive
IAutoIdReaderParametersProvider Optional standard reader-specific parameters through the same configuration snapshot and commit

The sink pushes ReportScanAsync (scan event and LastScanData), CompleteScanAsync (a termination condition ended the asynchronous scan), ReportPresenceAsync, ReportLogEntryAsync and ReportAccessAsync. Provider calls are made without any runtime lock held, scans never overlap on one reader, and the sink throws ObjectDisposedException after the reader was disposed.

Four simulated providers ship in the package and back the tests and the sample: InMemoryRfidReaderProvider (an EPC Gen2 reader with memory banks, passwords, locks and kill), InMemoryScanReaderProvider (OCR and optical), InMemoryOpticalVerifierProvider and InMemoryRtlsProvider. Their scan cycle defaults to one second (CycleInterval), so an unbounded ScanStart raises at most one scan event per second; pass a cycleInterval to the constructor for another interval. InMemoryRtlsProvider stores each object's location in the type it was registered with. A locationConverter translates it into the other supported types, for example from the configured local coordinate system (OPC 30010 9.3.4) into WGS84:

// A site whose local origin is at 48 N 11 E, X pointing east and Y north, in metres.
var rtls = new InMemoryRtlsProvider(locationConverter: (location, type) =>
    type == LocationTypeEnumeration.WGS84 && location.SwitchField == LocationFields.Local
        ? new Location
        {
            SwitchField = LocationFields.WGS84,
            WGS84 = new WGS84Coordinate
            {
                N_S_Hemisphere = "N",
                Latitude = 48.0 + (location.Local.Y / 111_320.0),
                E_W_Hemisphere = "E",
                Longitude = 11.0 + (location.Local.X / 74_600.0)
            }
        }
        : null);

Without a converter, or when it returns null, GetLocation for another type answers Bad_InvalidState.

Runtime parameters and Data Access control

WithRuntimeParameters(enableScanControl: true) exposes RuntimeParameters/ScanSettings with Duration (milliseconds), Cycles, DataAvailable and CodeType, together with the writable CodeTypes selection and its EnumStrings. The provider implements IAutoIdScanParametersProvider to supply the initial settings, supported code names and configuration commits. Existing providers need no changes unless the application enables this capability. The in-memory RFID provider supports the EPC format.

AutoIdReader reader = await runtime
    .Reader(new QualifiedName("Portal", runtime.InstanceNamespaceIndex), hardware)
    .WithRuntimeParameters(enableScanControl: true)
    .BuildAsync(ct);

Each parameter write validates the complete resulting configuration and awaits the provider's commit before publishing it. Negative or non-finite durations, negative cycle counts, unknown formats and invalid or duplicate code indexes are rejected. Standard parameters cannot change while scanning. Several writes in one OPC UA Write request remain independent operations, not a transaction. The provider owns persistence and must leave its previous configuration intact when it rejects or cancels a commit.

A True write to ScanActive starts the existing asynchronous scan path with a snapshot of these settings. Repeating True while an asynchronous scan is active does not restart it or transfer ownership. False stops either a variable-started or method-started asynchronous scan; repeating False while idle succeeds. Natural completion resets the variable, including completion during startup. A rejected startup returns a bad write status. A rejected or cancelled stop keeps the active scan tracked until the provider confirms completion or a later stop succeeds, so a second scan cannot start on the same hardware.

Variable-started scans belong to the device and survive the writing session's closure. ScanStart retains its existing session ownership, including when another client repeats a True write. ScanStop can stop either asynchronous control path. A synchronous Scan cannot be stopped through ScanActive. Shutdown cancels queued operations, stops scanning and detaches the provider. WithScanWritePermissions applies standard RolePermissionType entries to ScanActive and every standard writable runtime parameter; the owning server enforces them through its normal write authorization.

The original IAutoIdReaderBuilder contract remains unchanged. The fluent WithRuntimeParameters and WithScanWritePermissions extensions require IAutoIdRuntimeParametersBuilder; WithDiagnostics requires IAutoIdDiagnosticsBuilder. The SDK builder implements both optional interfaces. Import Opc.Ua.AutoID.Server to use the extensions. A third-party builder can implement either capability independently; requesting an unsupported option throws NotSupportedException without changing the builder.

Standard reader-specific parameters

A provider can additionally implement IAutoIdReaderParametersProvider. WithRuntimeParameters() then binds the parameters declared in its ReaderParameterCapabilities; it does not infer support from the reader kind, antenna names or diagnostic values. Existing providers remain unchanged.

Reader kind Optional standard parameters
RFID CodeTypesRWData, TagTypes, RfPower, MinRssi, EnableAntennas
OCR, optical and optical verifier TemplateName, MatchCode
RTLS No additions to the common runtime parameters

Table 15 and the pinned NodeSet declare both CodeTypesRWData and TagTypes as UInt32 arrays with MultiStateDiscreteType, ValueRank 1, ArrayDimensions [0] and mandatory namespace-zero EnumStrings properties. The binder implements both selections with read-only EnumStrings properties. The provider declares a stable tag-name catalogue and supplies the selected indexes in AutoIdScanParameters. Null arrays omit the capability; empty selected arrays select no entries. Invalid or duplicate indexes are rejected.

TemplateName selects a template already configured on the device; it does not create or upload one. For example, an OCR provider with an existing PalletLabel template can declare the following capability and extend its otherwise valid common-parameter snapshot:

public AutoIdReaderParameterCapabilities ReaderParameterCapabilities { get; } =
    new() { TemplateNames = ["PalletLabel"], SupportsMatchCode = true };

AutoIdScanParameters parameters = currentParameters with
{
    TemplateName = "PalletLabel",
    MatchCode = "PALLET"
};

The provider implements ReadParametersAsync and WriteParametersAsync from IAutoIdScanParametersProvider for the complete snapshot, including these fields. The SDK rejects unknown templates; the provider applies the selected template and match value to its actual decoding operation.

RFID RfPower is scalar SByte, MinRssi is scalar Int32 and EnableAntennas is scalar UInt32, matching Table 15 and the pinned NodeSet. The specification describes power adjustment per antenna but provides no antenna selector for this scalar parameter. The binding does not invent one: only a provider that implements the scalar setting can declare SupportsRfPower, and its antenna mapping remains device-specific. No generic power range or RSSI unit is imposed.

ConfiguredAntennas is the provider's actual general device configuration. Runtime selections can only remove bits from that mask. Bit zero denotes antenna one; a zero write succeeds without committing or changing the cached value, quality or timestamp, as required by OPC 30010 6.5.3.1. The SDK never derives this mask from AntennaNames. Capability catalogues and the general mask remain fixed for the reader lifetime; recreate the reader when they change.

CodeTypesRWData configures diagnostic RWData as described in OPC 30010 6.5.3.1. A provider implements IAutoIdRfidDiagnosticFormatter, declares its actual format catalogue in AutoIdReaderParameterCapabilities.CodeTypesRWData, and commits selected indexes in AutoIdScanParameters.CodeTypesRWData. Declaring that catalogue without implementing the formatter is a configuration error. The existing WithRuntimeParameters() and WithDiagnostics() builder options enable the selection and its diagnostic projection; providers without the capability retain their existing report projection.

Empty selection disables diagnostic RWData on subsequent access reports: the value becomes null with BadNoData, while the other access fields continue to update. A selection write does not reformat historical diagnostics. Multiple selected indexes are accepted without defining an order of preference. The formatter receives the selected names and returns one selected code type with its corresponding ScanData value. The runtime validates membership and the union field defined in OPC 30010 Table 32. Clients can browse and write this reader-specific selection through standard OPC UA services.

The formatter receives independent user-data storage, not credentials, and its output is copied before publication. If formatting fails or returns an invalid representation, the runtime records the failure and publishes RWData as unavailable; it does not change an already executed tag command's outcome or suppress its access event. Formatting changes neither byte-valued method outputs nor access-event payloads. Public ReportAccessAsync awaits formatting, change notifications and asynchronous event reporting, retaining operation admission through those callbacks. Providers must also override ReportEventAsync on custom node states if they customize asynchronous reporting; a synchronous-only override is not called by that path. Cancellation before diagnostic publication propagates without updating part of the diagnostic group. Formatters must not await reader disposal or an operation waiting for their own callback.

ReportScanAsync forwards its cancellation token through acquisition change notifications, scan events and access publication. Cancelling a provider's report loop can therefore release a cancellation-aware pending sink. Cancellation during notification does not roll back values already published to the cache. Presence and log-entry reports also forward cancellation to diagnostic change notifications; values cached before cancellation remain available.

InMemoryRfidReaderProvider declares only RAW:BYTES, initially selected as index zero, and formats byte-valued user data. Additional formats require a provider that implements their actual conversion; the runtime does not infer String, EPC or vendor representations from arbitrary bytes.

For example, enable the simulated provider's raw diagnostic capability through the existing fluent builder:

var provider = new InMemoryRfidReaderProvider();
AutoIdReader reader = await runtime.Reader(new QualifiedName("DockDoor", instanceNamespace), provider)
    .OwnsProvider()
    .WithRuntimeParameters()
    .WithDiagnostics()
    .BuildAsync(cancellationToken);

An application provider implementing IAutoIdRfidDiagnosticFormatter uses the same builder path. Its FormatRWDataAsync implementation returns an AutoIdRfidDiagnosticData containing the selected code-type name and the converted union value; the catalogue must not advertise conversions it cannot perform.

All optional writes use the same authorization, scan-idle check, cancellation and complete-snapshot provider commit as the common parameters. Rejected or cancelled commits retain the previous published value, quality and timestamp. The SDK copies provider and caller arrays; a later array mutation does not change its saved configuration or catalogues. The typed client's ReadScanParametersAsync and WriteScanParametersAsync convenience methods cover the common fields; their writes preserve reader-specific values on the server. Use standard session Browse, Read and Write for the optional variables.

The optional configure callback of WithRuntimeParameters adds application-specific variables under RuntimeParameters before registration. Use the application's namespace and supply their declared types, access metadata and value bindings; the standard parameter binder preserves those bindings. Reader-specific bindings also enforce their own policy for writes during scanning.

Diagnostics through Data Access

WithDiagnostics() publishes the read-only standard diagnostic variables of OPC 30010 6.1.3.3. It uses the reader's existing reports and method results; no additional provider interface or event source is required.

AutoIdReader reader = await runtime
    .Reader(new QualifiedName("Portal", runtime.InstanceNamespaceIndex), hardware)
    .WithRuntimeParameters(enableScanControl: true)
    .WithDiagnostics()
    .BuildAsync(ct);

ReportPresenceAsync updates Diagnostics/Presence. A scan does not imply a presence count: the provider reports that measurement separately. ReportLogEntryAsync updates Diagnostics/Logbook/LastLogEntry, with LogColumns set to "Message" for the sink's single text column. These reports retain their existing events; the projection does not keep a second logbook.

Diagnostics/LastAccess contains Client, Command, Identifier and Timestamp. Scans, tag methods and ReportAccessAsync update it through the same access-report path. As with LastScanData, the first result of a multi-result report is selected. Identifier contains the selected ScanData union arm, not an encoded union wrapper. All fields in an access update have the same source timestamp. Clients reading several fields must compare their SourceTimestamp values before treating them as one acquisition; use access events when all results are needed.

The diagnostic cache copies ByteString buffers and EPC fields before retaining them. Custom values are snapshotted through the existing UA binary codec and the runtime's encodeable factory, then compared with the original Variant using the existing semantic equality rules, including nested structures and arrays. Custom structures encoded as ExtensionObjects require compatible registered activators. If a decoded structure becomes an opaque ExtensionObject, or the copied value otherwise compares unequal, the diagnostic copy throws Bad_EncodingError before any LastAccess field changes. Already-opaque values are accepted when their type and body round-trip unchanged; a representation change that compares unequal is rejected rather than silently retained with Good quality. Codec errors and encoding limits leave the previous LastAccess values, quality and timestamps unchanged. Custom structures must implement IEncodeable.IsEqual according to their value semantics.

For provider scan reports and completed physical commands, the runtime logs Bad_EncodingError, Bad_DecodingError or Bad_EncodingLimitsExceeded from this projection and continues publishing the enabled access event. A provider scan report still updates LastScan and raises its scan event; a completed Scan retains its provider result and operation status. LastAccess retains its previous acquisition rather than retaining caller-owned data or an unequal copy. Direct ReportAccessAsync calls still propagate these errors before publishing their access event. Diagnostic isolation does not suppress validation errors for invalid report types. This isolation surrounds snapshot creation only. A change-notification callback that throws after LastAccess has changed is not treated as a copy rejection: provider reporting propagates that failure. Completed physical commands retain their existing logging and result policy for publication failures.

Providers must keep the report stable until the reporting operation completes; later buffer reuse does not change diagnostic values, quality or timestamps. This copying applies only to the diagnostic projection and does not change access-event payloads.

RFID readers also publish RWData, Antenna, CurrentPowerLevel, PC, Polarization and Strength, as defined in Table 15. Optional fields absent from a later report become null with Bad_NoData; they do not retain an earlier tag's data. Unreported measurements start with Uncertain_InitialValue. Method RWData uses the existing IAutoIdRfidAccessEventPolicy classification, including the reserved-bank credential exclusion; password changes never populate it. Providers reporting autonomous access results remain responsible for excluding credentials from those reports.

Diagnostics is opt-in and does not depend on PublishAccessEvents. Disabling access events does not disable an explicitly configured Data Access projection. Normal server read authorization applies to the variables, which reject writes. Disposal rejects further reports through the existing reader lifetime checks. The server sample enables the projection on its simulated RFID portal.

The runtime does not invent vendor IO definitions. OPC 30010 6.1.3.2 defines IOData as an optional FunctionalGroup for application or reader-specific sensor and actuator variables, without standard children. WithIOData((context, group) => ...) creates that group and invokes the application's composition callback before registration. The application adds its own variables, access permissions and asynchronous hardware bindings; the runtime preserves them. A callback failure aborts registration and leaves the reader name available for retry. Without that callback the group remains absent. No such hardware points are defined by the simulated reader, so it does not publish that group. Clients use ordinary Browse, Read, Write and subscriptions for these application-defined variables; the SDK does not invent a universal IO schema. Standard reader-specific runtime parameters require the explicit provider capability described above; WithDiagnostics() alone does not publish writable configuration. The sample's in-memory RFID provider implements raw-byte diagnostic formatting but does not implement RF configuration or tag-type filtering, so those optional parameters remain absent rather than advertising simulated hardware capabilities it does not implement.

Acquired images

OCR and optical readers, including optical verifiers, can publish acquired images through WithImages. OPC 30010 6.2.3.2 and 6.3.3.2 define an optional Images folder containing named FileType objects. Each file publishes MimeType; image encoding remains the provider's responsibility.

QualifiedName frame = new("Frame", context.Runtime.InstanceNamespaceIndex);
AutoIdReader reader = await context.Runtime
    .Reader(new QualifiedName("Camera", frame.NamespaceIndex), opticalHardware)
    .WithImages([new AutoIdImageSlot(frame, "image/png", maximumBytes: 1024 * 1024)])
    .BuildAsync(ct);

// A provider obtains this optional capability from its attached IAutoIdReaderSink.
await ((IAutoIdImageSink)reader).ReportImageAsync(frame, pngBytes, ct);

The catalogue is fixed when the reader is built: at most 16 slots, with unique qualified browse names and a positive per-slot byte limit no larger than 16 MiB. These are SDK resource limits, not limits imposed by OPC 30010. Other reader kinds reject image configuration. No configured slots means no Images folder. A null initial value means that the image is not yet available; an explicitly empty byte string is a readable, zero-length file. Reports must be nonnull and fit the configured slot. Unknown names, oversized values and canceled reports leave the last accepted image unchanged.

The reader copies initial and reported bytes. An update replaces the content used by subsequent opens; handles already open retain their prior snapshots. Standard read-only FileType methods enforce session-owned handles and the existing binder's 64-handle limit per file. Reader shutdown retires these handles and rejects further reports; failed registration also disposes bindings already created. The reader owns the bindings, not the injected binder service. Register IFileTypeBinder before hosting to supply another binder; direct construction and CreateAutoIdRuntime also accept one and otherwise use FileTypeBinder. A composed owner's first runtime creation selects the binder.

The typed client discovers the files and reuses the File System client for metadata and transfer:

await foreach (UaFileInfo image in autoId.EnumerateImagesAsync(camera, ct))
{
    Console.WriteLine(image.MimeType);
    byte[] content = await image.ReadAllBytesAsync(ct);
}

These are detached UaFileInfo objects because Images is a FolderType, not a FileDirectoryType. File reads do not depend on a server-wide file-system root. An absent optional folder yields no files; service failures propagate. The sample verifier publishes a small portable graymap and the client reads it through this same path. Images are independent of scan result/event payloads and diagnostic formatting.

Behavior of the methods

Method Result codes and semantics
Scan (6.1.3.4) Bad_InvalidArgument for an infinite scan (duration 0, cycles 0, no DataAvailable), a negative or non-finite value, an undefined location type or a duration above the limit; Bad_InvalidState while another scan is active. The first result becomes LastScanData/LastScanTimestamp with one source timestamp
ScanStart (6.1.3.5) Infinite settings allowed; Bad_InvalidState while a scan is active. The scan stops through ScanStop, when the provider completes it, when the starting session closes, or at shutdown
ScanStop (6.1.3.6) Bad_InvalidState when no scan is active; any session may stop a scan
ReadTag, WriteTag, WriteTagID, KillTag, LockTag, SetTagPassword A malformed identifier, empty code type, over-long read or undefined enumeration is Bad_InvalidArgument. Everything the tag decides (PASSWORD_ERROR_4, OUT_OF_RANGE_ERROR_7, ...) is returned in Status with a good call result
GetDeviceLocation (6.1.3.7) Available when a location is configured. Same mapping as GetLocation: an undefined location type is Bad_InvalidArgument, a location that is not available in the requested type Bad_InvalidState. 6.1.3.7 lists only the Call Service codes of OPC 10000-4 5.12.2, where Bad_NotSupported would mean the method is not supported for the object; 5.12.2.4 allows reusing a code with the same canonical meaning
GetLocation, GetSupportedLocationTypes (6.6.3) The result carries the location in the requested type. An unsupported location type is Bad_InvalidArgument, an unknown object Bad_NotFound, and a supported type the object's location is not available in Bad_InvalidState (6.6.3.2: not available, for example due to the configuration)

A method the provider does not support is not instantiated; calling it fails with the stack's status for an unpublished method.

Events

Scan results are raised as the scan event of the reader kind (RfidScanEventType, OcrScanEventType, OpticalScanEventType, OpticalVerifierScanEventType, RtlsLocationEventType) with DeviceName and the typed ScanResult array. AutoIdPresenceEventType and AutoIdLogEntryEventType come from the sink. Commands that reached an identifier (a scan with results, and each tag command except those answering NO_IDENTIFIER_8, MULTIPLE_IDENTIFIERS_9, NOT_SUPPORTED_BY_DEVICE_15, DEVICE_NOT_READY_17, INVALID_CONFIGURATION_18 or DEVICE_FAULT_20) raise RfidAccessEventType on RFID readers and AutoIdAccessEventType otherwise, with Client, Command and the access results. Client names the client application that originated the command (OPC 30010 6.1.3.3 and 7.10): the application name of the client description the session was created with, else its application URI, else OPC UA client. The results of an asynchronous scan name the client that called ScanStart; scans the device reports on its own name AutoID device.

Generic ReadTag and WriteTag access events do not automatically broadcast tag memory. The injected RFID provider may also implement IAutoIdRfidAccessEventPolicy to approve an entire (codeType, region, offset, length) byte range as non-secret telemetry. Missing, rejected or failing classifications omit both RWData and CodeTypeRWData, including their encoding-mask bits; identifiers and command metadata remain available. Unsuccessful operations and empty results omit data. EPC Gen2 reserved-bank ranges overlapping password bytes 0 through 7 are always omitted, even if a policy approves them. The in-memory EPC provider approves ordinary banks 1 through 3 and never approves the reserved bank.

This projection does not redact an authorized caller's direct ReadTag result, change provider arguments, or disable access events. Password-management commands never include passwords in their access events. Applications whose existing RFID providers need ordinary memory in events must opt in through this provider policy; only approve known layouts and never credential-bearing or unclassified memory.

Conformance

The runtime contributes the OPC 30010 conformance units and server facets (Tables 82 to 85) of the readers it hosts; a facet is advertised only when a reader implements all its mandatory units.

Unit Implemented when
AutoID DeviceType A reader exists
AutoID Simple Sync Access A reader exists (LastScanData is updated by every scan)
AutoID Sync Access A reader has a Scan method
AutoID Async Access A reader exists (scan events)
AutoID Async Access Control A reader has ScanStart and ScanStop
AutoID Device Parameters A reader was built with provider-backed runtime parameters
AutoID Simple Sync Access Control A reader was built with writable ScanActive and its settings

The Simple Sync, Base Sync and Base Async facets are advertised accordingly. Simple Sync Access Control is optional in Table 82, not a mandatory requirement for the Simple Sync facet. The runtime advertises the Full AutoID Server Facet when one reader implements all mandatory capabilities; units from unrelated readers do not establish that one reader supports that facet. DeviceInfo, DeviceLocation, DeviceLocationName and AntennaNames are published when configured.

For Table 85, a Full candidate must provide Device Parameters and Async Access Control on the same reader and satisfy the included Simple Sync, Base Sync and Base Async facets. The host must also load the DI device model, encode the AutoID complex types and support event subscriptions. A parameter-enabled RFID reader with synchronous and asynchronous providers supplies that reader-level combination; a parameter-only reader or a different reader's scan methods do not. Table 85 defines scan operation modes, not every optional method on every device kind. Advertising this facet does not resolve the verifier and RTLS contract discrepancies described below or assert product certification.

Client

Opc.Ua.AutoID.Client wraps the generated ObjectType proxies:

using Opc.Ua.AutoID.Client;

AutoIdClient autoId = session.AutoId(telemetry);   // or AddAutoIdClient() in DI
await foreach (AutoIdReaderEntry reader in autoId.EnumerateReadersAsync())
{
    AutoIdDeviceSnapshot device = await autoId.ReadDeviceAsync(reader);
    AutoIdScanResponse scan = await autoId.ScanAsync(
        reader, new ScanSettings { Duration = 1000, DataAvailable = true });
}

await foreach (AutoIdScanEventTypeRecord e in
    autoId.ObserveScanEventsAsync(session.DefaultStreaming, reader, ct))
{
    // e.ScanResult holds RfidScanResult, OcrScanResult, ... instances
}

Discovery finds the devices whose type derives from one of the five concrete reader types. A browse the server rejects throws ServiceResultException rather than yielding an empty list, a rejected method call throws with the server's status, and every asynchronous member honours cancellation. The status a device reports for a tag command is returned as data. AutoIdReadOptions limits which variables ReadDeviceAsync reads: Default reads everything the device publishes, StatusOnly reads DeviceStatus and DeviceName. Every ReadDeviceAsync call costs one Browse of the children of the device (and BrowseNext only when the server pages the result) and one Read, whatever the options. The snapshot carries the NodeIds of DeviceStatus, LastScanData, LastScanTimestamp and DeviceLocation and the browse names of the methods the device publishes, taken from that browse. RefreshDeviceAsync takes such a snapshot and reads DeviceStatus, LastScanData, LastScanTimestamp and DeviceLocation again through these NodeIds: one Read of up to four variables and no Browse. The client keeps no state, so a poller reads once and then refreshes the snapshot:

Call Network cost
ReadDeviceAsync(reader) One Browse, one Read of every published variable
ReadDeviceAsync(reader, AutoIdReadOptions.StatusOnly) One Browse, one Read of two variables
RefreshDeviceAsync(snapshot) One Read of up to four variables, no Browse 
AutoIdDeviceSnapshot device = await autoId.ReadDeviceAsync(reader, AutoIdReadOptions.StatusOnly);
if (device.HasMethod(BrowseNames.ScanStart))
{
    // monitor device.DeviceStatusId and device.LastScanDataId, then start the scan
}
device = await autoId.RefreshDeviceAsync(device); // poll without browsing

RefreshDeviceAsync copies every other member of the snapshot, including Methods, and does not check the snapshot against the server. When the snapshot no longer matches the device (the device or one of its variables was deleted, or the server assigned other NodeIds after a restart), the status of the Read surfaces: a bad status for DeviceStatus, for example BadNodeIdUnknown, is thrown as ServiceResultException, and a bad status for LastScanData is returned in LastScanStatus with a null value. The caller then reads the device again with ReadDeviceAsync, which also picks up optional variables and methods published after the snapshot was taken.

Observe*Async methods (scan, access, presence and log entry events) take a streaming subscription the caller owns; the monitored item lives as long as the enumeration.

For Data Access clients, parameter browsing is explicit and independent of ReadDeviceAsync and RefreshDeviceAsync:

AutoIdScanParameterReadResult current = await autoId.ReadScanParametersAsync(reader, ct);
AutoIdScanParameterStatus written = await autoId.WriteScanParametersAsync(
    reader, current.Parameters with { Duration = 0, Cycles = 0, DataAvailable = false }, ct);
// Check every field in written before starting; writes are independent.
StatusCode started = await autoId.SetScanActiveAsync(reader, true, ct);
AutoIdScanActiveReadResult active = await autoId.ReadScanActiveAsync(reader, ct);
AutoIdDeviceSnapshot acquired = await autoId.ReadLastScanAsync(reader, ct);
StatusCode stopped = await autoId.SetScanActiveAsync(reader, false, ct);

Parameter reads preserve each field's status and expose supported code names. ObserveScanActiveAsync uses a caller-owned streaming subscription; ending its enumeration removes only the monitored item. Missing components return BadNotFound; a present value of the wrong type returns BadTypeMismatch. ReadLastScanAsync compares acquisition timestamps for LastScanData, LastScanTimestamp and available RFID antenna/RSSI values, retries a changing acquisition at most three times and reports BadDataLost if good values still disagree. Bad per-value statuses remain visible instead of being reported as a successful coherent acquisition. A scan without an RFID sighting marks antenna/RSSI BadNoData, rather than retaining a previous scan's values. Ordinary refreshes retain one Read and no nested browse. The server reads each acquisition variable's value, status and source timestamp under the publication lock. Separate variable reads can still cross acquisitions, so clients retain the timestamp comparison and retry.

MCP tools

AddOpcUaMcpAutoId() and WithOpcUaAutoIdTools(McpToolProfile.AutoId) (profile autoid) add autoid_list_readers, autoid_read_device, autoid_scan, autoid_scan_start, autoid_scan_stop, autoid_observe_scan_events, autoid_read_tag, autoid_get_supported_location_types and autoid_get_location. No tool writes, locks or kills a tag or carries a password. See the MCP server guide.

Sample

samples/AutoID contains AutoIdServer, a dock door with a simulated RFID portal whose pallets enter and leave the antenna field, and AutoIdClient, which discovers the reader, scans, reads and writes tag memory and prints the scan and presence events. Test-AutoIdSamplePair.ps1 runs both and checks the output.

Specification notes

  • OPC 30010 6.1.3.16 prescribes the AutoIdModelVersion string "1.00" although the released model is 1.01; the server publishes "1.00".
  • The NodeSet orders the GetLocation arguments identifier, location type, code type; the specification text orders them identifier, code type, location type. The generated proxy and the server follow the NodeSet.
  • The NodeSet declares the Scan method of OpticalVerifierDeviceType with WGS84Coordinate results where OPC 30010 6.4.3.1 names OpticalVerifierScanResult. The local model corrects the Results argument to OpticalVerifierScanResult[] from the published method table. The method NodeId i=7054, OutputArguments property i=6076, argument order and value rank are unchanged. Generated server/client contracts use the corrected type; the in-memory verifier supports synchronous Scan alongside ScanStart and scan events.
  • Table 16 lists RtlsDeviceType.GetUnits as Optional, but neither the NodeSet nor the published method chapter defines its inputs or outputs. Reader instances omit that method. The mandatory LengthUnit, RotationalUnit, GeographicalUnit and SpeedUnit properties remain published as EUInformation; applications configure them with WithRtlsUnits.

The published reference still identifies version 1.01 as current. The UA-Nodeset/latest/AutoID XML has Git blob 2cdca69cd86c4f46c61ea4da9ce7d625a02ed53a, identical to the pinned source. No corrected upstream artifact has been established. The verifier correction follows the published method table and is recorded explicitly in Model/provenance.json; it is not represented as an upstream model revision. RTLS signatures remain unchanged. The Full Server Facet is evaluated separately for each hosted reader's implemented capabilities.

Support scope and published contract limits

The SDK supports the defined optional capabilities as well as mandatory reader behavior. Devices expose only their configured provider capabilities. Acquired images use bounded FileType slots, and WithIOData composes application-defined sensor and actuator nodes without assigning them invented standard semantics.

One optional wire method is deliberately omitted because the published model provides no signature:

  • RTLS GetUnits is deliberately omitted until its inputs, outputs, types and value ranks are defined by an authoritative contract. The four unit properties do not determine a method signature. No output array or structure is invented.

The SDK retains the released NodeSet's GetLocation wire order for compatibility; the typed convenience API accepts identifier, code type and location type and translates them to that order. AutoIdModelVersion retains the specification's prescribed value. These are explicit implementation decisions, not pending features. Current-head client/server, sample and NativeAOT execution is recorded separately as validation evidence; pending tests alone do not make implemented support Partial. Hardware-specific IO definitions and additional real-world formatter capabilities are provider responsibilities, not missing universal SDK wire contracts.

Data Access regression evidence

The AutoID test project covers the SDK contract without requiring physical readers. These cases are implementation evidence, not OPC certification.

Requirement Test in tests/Opc.Ua.AutoID.Tests
IOData composition for every reader kind, application-owned access/bindings and real-service writes IODataCompositionPreservesApplicationBindingsAsync
Unconfigured IOData and callback rollback without reserving the reader name IODataConfigurationFailureRollsBackAndUnconfiguredGroupRemainsAbsentAsync
Images for OCR, optical and verifier readers, copied bytes, MIME metadata, read-only access and session-owned snapshot handles ImageSlotsPublishReadOnlySnapshotsThroughStandardFilesAsync
Unknown, null, oversized and canceled image reports; unavailable and empty content ImagePublicationRejectsUnknownNullOversizedAndCanceledUpdatesAsync
Image binding cleanup after shutdown or partial setup failure; accepted notifications retain reader lifetime DisposingAReaderRetiresImageBindingsAsync, FailedImageBindingDisposesEarlierSlotsAndAllowsRegistrationRetryAsync, ImagePublicationKeepsReaderLifetimeUntilNotificationsCompleteAsync
Invalid image catalogues, bounds and reader kinds ImageConfigurationRejectsInvalidSlots
Corrected verifier method metadata, typed synchronous results and unchanged asynchronous events VerifierScanMetadataUsesPublishedResultType, AVerifierReturnsTypedSynchronousResultsAndRetainsScanEventsAsync, TheVerifierReportsVerificationResultsAsync
Opt-in capability and legacy-provider compatibility CapabilityIsOptInAndExistingProvidersRemainCompatibleAsync
Runtime metadata and configured conformance units; async-only parameters do not qualify for Full ParametersHavePublishedMetadataAndContributeOnlyConfiguredUnitsAsync
Full-facet eligibility for all mandatory capability combinations, without optional ScanActive FullFacetRequiresAllMandatoryCapabilitiesOnOneReaderAsync
Separate readers cannot combine capabilities to qualify for Full FullFacetCannotCombineCapabilitiesOfSeparateReadersAsync
Parameter-enabled RFID provider contributes Full through the fluent API and owning manager ParameterEnabledRfidReaderAdvertisesFullFacetAsync
Validation and provider-commit failures preserve the old configuration InvalidCodeTypeAndIndexesAreRejectedWithoutChangingConfigurationAsync, ProviderCommitFailurePreservesPublishedAndProviderValuesAsync
Commit/start serialization and cancellation ParameterCommitSerializesStartAndCancelledCommitLeavesPreviousValuesAsync
Gate release and preservation of independent cleanup failures SerializedCleanupPreservesBothOperationFailuresAsync
Reader-specific parameter composition and standard role metadata ReaderSpecificParameterBindingsAndConfiguredRolePermissionsArePreservedAsync
Standard reader-kind metadata, ranks and mandatory EnumStrings ReaderParametersMatchKindCapabilitiesAndPublishedMetadataAsync
Unsupported capabilities and invalid initial declarations UnsupportedReaderParametersRemainAbsentAsync, InvalidInitialReaderParameterDeclarationsAreRejectedAsync
Complete reader-specific commits and rejected values ReaderParameterWritesCommitThroughTheExistingProviderAsync, InvalidReaderValuesPreserveConfigurationAndQualityAsync
Antenna zero and the general configuration boundary AntennaZeroIsNoOpAndUnconfiguredBitsAreRejectedAsync
Reader-specific cancellation, scan serialization and shutdown ReaderParameterCancellationSerializesStartAndShutdownRejectsWritesAsync
Provider rejection and unchanged quality/timestamps ReaderParameterCommitFailureCancellationAndActivityPreserveValuesAsync
Copied provider arrays and frozen catalogues CapabilityMismatchIsRejectedAndParameterArraysAreCopiedAsync
Real-service optional writes, EnumStrings write denial and common-client preservation ReaderSpecificParametersUseRealServicesAndPreserveCoreWritesAsync
Optional-variable access, index ranges and real-service role enforcement ReaderParameterAccessDenialAndIndexRangePreserveSettingsAsync, ReaderSpecificWritesHonorServerRolePermissionsAsync
Repeated control writes and session ownership RepeatedWritesDoNotRestartAndVariableScanSurvivesSessionClosureAsync, MethodAndVariableControlsShareActivityButPreserveMethodOwnershipAsync
Completion, startup rejection and shutdown RejectedStartAndImmediateCompletionNeverLeaveScanActiveTrueAsync, NaturalCompletionAndShutdownResetScanActiveAsync, WritesAfterShutdownAreRejectedWithoutTouchingDisposedResourcesAsync
Provider-stop failure retains the active scan RejectedStopKeepsTheScanTrackedUntilProviderConfirmationAsync
Real-session parameter/control workflow without scan method calls ParametersControlAndCoherentResultsWorkWithoutScanMethodCallsAsync
Caller-owned ScanActive subscription and session lifetime ScanActiveObservationUsesTheSharedSubscriptionWithoutOwningItsSessionAsync
Mixed acquisition timestamps and bad RFID value statuses InconsistentAcquisitionTimestampsAreRejectedAndBadAntennaStatusIsPreservedAsync
Acquisition reads share the publication lock AcquisitionReadsKeepValueQualityAndTimestampTogetherAsync
Report cancellation reaches acquisition, scan and access sinks ScanReportCancellationReleasesEveryPublicationStageAsync
Fault and recovery callbacks retain owned-provider lifetime FaultStatusNotificationKeepsOwnedProviderAliveAsync
Opt-in Diagnostics metadata across all reader kinds DiagnosticsAreOptInReadOnlyAndUseStandardQualifiedMetadataAsync
Existing reports update variables without duplicate events or invented presence PresenceAndLogReportsUpdateValuesAndRetainSingleEventsAsync, ScanReportsShareAccessProjectionAndDoNotInventPresenceAsync
Timestamp consistency and removal of absent RFID values with events disabled AccessProjectionIsIndependentOfEventsAndClearsAbsentRfidFieldsAsync
Invalid, cancelled and disposed reports retain previous diagnostics InvalidCancelledAndDisposedReportsDoNotReplacePreviousDiagnosticsAsync
RFID credential exclusions also govern projected method data SecurityR14ReservedBankReadAndWriteNeverPublishCredentialsAsync, SecurityR14CredentialRangeOverlapAndUnknownClassificationFailSafeAsync
Real-session diagnostic browsing, typed tag access and write denial DiagnosticsAreBrowsableReadOnlyAndProjectTypedClientAccessAsync

DiagnosticReportsExecuteAndReadThroughDataAccessAsync in tests/Opc.Ua.Aot.Tests also exercises report projection and Data Access encoding in the NativeAOT test binary. RuntimeParametersAndScanControlExecuteThroughTypedClientAsync includes the four optional RFID parameter encodings and complete-snapshot commits.

Provenance

src/Opc.Ua.AutoID/Model holds the NodeSet and identifier table from UA-Nodeset revision 9f6c7660b94af24d32c4248d4b13bf60adab0301; provenance.json records the source URLs and upstream SHA-256 hashes, and the effective NodeSet hash after the documented verifier argument correction. Reversing that single correction recovers the byte-identical publication. The published identifier table predates model 1.01 and lacks 67 NodeSet declarations, so Opc.Ua.AutoID.Derived.NodeIds.csv is generated from it with tools/nodesets/derive-identifier-table.py and used as the source generator's drift guard. NodeIds always come from the NodeSet.

The AutoID tests pin the file hashes, compare the generated identifiers with the NodeSet and the identifier table, load the model with DI, and round-trip the DataTypes through the binary, JSON and XML encodings.

Fixture Covers
AutoIdHostingTests AddAutoId registration, DI ownership, options, node manager and client factories
AutoIdCompositionTests Stock Machinery owner, ordered providers, DI loaded once, instance ownership, rollback, cancellation, runtime disposal, a second DI owner rejected
AutoIdMachineryCompositionEndToEndTests Machinery, Pumps and AutoID in one hosted server, read back by the AutoID, Machinery and Pumps clients over a real session, with the published profiles and conformance units
AutoIdPlacementEndToEndTests Reader placement over a real session: every reader reachable from DeviceSet, only roots organized by it, a reader as a component of a machine with its Identification, no reader in Machines
AutoIdReaderEndToEndTests The stand-alone server driven by AutoIdClient over a real session