DI
| Document | OPC 10000-100 |
|---|---|
| Version | 1.05.0 |
| Published | 2025-11-15 |
| Namespace | http://opcfoundation.org/UA/DI/ |
| Sector | Devices |
OPC UA for Devices (DI, Part 100) is the base information model that almost every other companion specification builds on. It defines DeviceType and TopologyElementType, the identification nameplate, the ParameterSet and MethodSet pattern, device health, the locking service and the software update model.
Where it sits in the stack
DI sits directly on core Parts 3 to 5 and is the root of the companion-spec tree: IA, Machinery, MachineTool, Robotics, PA-DIM, AutoID, LADS and the VDMA sector models all reference it, which is why a server loading any of them also loads Opc.Ua.Di.NodeSet2.xml. Software update lives in a second namespace, http://opcfoundation.org/UA/DI/PackageMetadata/ (also 1.05.0). Nothing above DI works if the DI version your client assumes is not the one the device shipped.
The types that matter
| Type | What it carries |
|---|---|
DeviceType | The base object type for a physical or logical device. Everything a vendor exposes as a device instance is normally a subtype of this, and it is the first thing to check with HasTypeDefinition. |
TopologyElementType | The abstract parent of DeviceType and of network and component types. It is what introduces the ParameterSet, MethodSet, and functional-group structure that the whole DI tree reuses. |
DeviceSet | The standard folder where a DI server enumerates its devices. If a server advertises the DI capability code, this is the first place to browse. |
FunctionalGroupType | Groups parameters into a view that makes sense to an engineer (configuration, diagnostics, identification) without duplicating the underlying variables. |
ParameterSet | The instance declaration holding a device's configuration and process parameters as Variables, so a client can find them structurally instead of by tag name. |
MethodSet | The matching declaration for the device's callable Methods, keeping methods out of the parameter tree. |
IVendorNameplateType | The identification interface: manufacturer, model, serial number, hardware and software revision, product instance URI. This is what lets you join machine data to an asset register. |
IDeviceHealthType | Applies the NAMUR NE 107 style health signal to a device, exposed as a DeviceHealth variable plus optional health alarms. |
DeviceHealthEnumeration | The health values themselves: NORMAL, FAILURE, CHECK_FUNCTION, OFF_SPEC and MAINTENANCE_REQUIRED. Useful as a coarse asset-health signal, not as an OEE state. |
LockingServicesType | An exclusive lock a client takes before reconfiguring a device, so two engineering tools cannot write conflicting configuration at once. |
SoftwareUpdateType | The firmware and software update model, with the UpdateParent and CanUpdate structure that tells a client whether an update can be applied and by whom. |
Using it on a real machine
- Confirm DI is really loadedRead the server's NamespaceArray and look for http://opcfoundation.org/UA/DI/. Note the index, because it is assigned per server and changes when a vendor adds or removes a model.
- Browse DeviceSetUnder Objects, open DeviceSet and read HasTypeDefinition on each child. A device typed only as BaseObjectType means the vendor has folders but no model.
- Read the nameplate before anything elseManufacturer, Model, SerialNumber, SoftwareRevision. Store them with every sample you collect; without them a historian full of values cannot be attributed to an asset later.
- Check DeviceHealthSubscribe to DeviceHealth rather than polling it, and treat MAINTENANCE_REQUIRED and CHECK_FUNCTION as advisory: they are device self-diagnosis, not machine state.
- Take the lock before writing configurationIf LockingServices is present, call InitLock, do the writes, then ExitLock. Skipping it is how two tools end up fighting over the same parameter.
What it gives you for OEE
DI contributes identity and device health, not OEE. Identity is still load-bearing: the nameplate properties are what let availability, counts and reasons be attributed to a specific asset in an ERP or CMMS. DeviceHealth is a five-value self-diagnosis, so do not use it as an availability state; take availability from MachineryItemState in the Machinery model instead. DI carries no counters, no cycle data and no downtime reasons.
Gotchas
- DI 1.05.0 is recent (2025-11-15) and is not what installed field devices ship. Devices in service are commonly on DI 1.01 or 1.02, where optional nodes and the software-update model differ. Check the Model element in the device's own nodeset, not the latest one on GitHub.
- Most nameplate properties are optional. A device can be fully DI-conformant and still expose no serial number, so browse before you promise identification to a customer.
- The DI server capability code only says the model is claimed, not that anything under DeviceSet is populated.
- Software update spans two namespaces: the DI namespace and DI PackageMetadata. Loading only the first leaves update nodes undecodable.
Once the machine speaks a companion spec, the OEE mapping is portable across vendors, which is the point at which analytics stops being a per-machine project.
See Jemba →Last verified 7 September 2026 against OPC UA 1.05.07. Version and publication date read from the released nodeset. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.