IEC 62541 · Domain

Part 100: Device Information Model (DI)

Document number	OPC 10000-100
IEC designation	IEC 62541-100
Colloquially	Part 100
Group	Domain

What it defines

A device is modelled as a topology element - something with parameters, methods and a place in a network - and DeviceType specialises that for actual equipment. Devices live under a standard DeviceSet folder, so a client always knows where to look. Alongside the devices, network objects and connection points describe how they are attached, which is what lets a gateway present a fieldbus segment as a browsable topology rather than a flat list of tags.

Nameplates and identification

The identification data is delivered through interfaces rather than through a fixed inheritance chain. A vendor nameplate interface carries manufacturer, model, hardware and software revision, serial number, and the product identifiers; a tag nameplate interface carries the plant's own asset and function identifiers. Because they are interfaces, a type can pick up identification without committing its inheritance, and a client can look for the interface rather than for a particular device type. This is the single most useful thing DI gives an asset register.

Device health

A device health interface exposes a status enumeration aligned with the NAMUR NE 107 categories: normal, failure, check function, off specification, and maintenance required. That five-way classification is enormously more useful than a boolean fault bit, because it distinguishes a device that has failed from one that is working but outside its calibrated range and one that needs attention soon. Its value depends entirely on the vendor having mapped their internal diagnostics onto it honestly.

Parameters, functional groups and software update

Parameters live in a ParameterSet and methods in a MethodSet, giving one canonical place for each. Functional groups then organise the same parameters into views for different audiences - an operator group, a maintenance group, a calibration group - by referencing them rather than duplicating them. Separately, a package metadata model published alongside DI supports software update: firmware is described as a package and transferred using the Part 20 file mechanism, with a state machine tracking the update.

What it defines

Concept	What it is
DeviceSet	The standard folder under which devices are published. A client's first browse target on any DI server, and the reason DI servers are easy to write generic tooling against.
TopologyElementType	The general base: something with a parameter set, a method set, functional groups and a place in a topology. Devices, blocks and networks all derive from it.
DeviceType	The device specialisation, carrying identification, health and the device-specific parameter and method sets. What a sector model subclasses.
Vendor nameplate interface	Manufacturer, model, hardware and software revision, serial number and product identifiers. Applied as an interface, so look for the interface not the type.
Tag nameplate interface	The plant's own asset and function identifiers, as opposed to the vendor's. The bridge between a device's identity and the maintenance system's.
Device health	A status enumeration aligned with the NAMUR NE 107 categories - normal, failure, check function, off specification, maintenance required. Five states, not one fault bit.
ParameterSet and MethodSet	One canonical location for a device's parameters and its callable methods, so a client does not have to guess where a vendor put them.
FunctionalGroupType	Audience-specific views over the same parameters, built from references rather than copies. An operator view and a maintenance view of one device.
Network and connection point types	Describe how devices attach to a segment, letting a gateway expose a real topology instead of a flat namespace of tags.
Software update and package metadata	A companion model describing firmware as a package, transferred with the Part 20 file mechanism and tracked through a state machine. Optional and separately versioned.

Do you need to read it?

Anyone building an asset register, a maintenance integration or a generic device client, and every modeller writing a sector companion specification - because DI is the layer they are expected to build on. It is also the first thing to check on an unfamiliar server: a populated DeviceSet with real nameplates tells you the vendor took modelling seriously.

Traps that trace back to this part

• Functional groups reference parameters, they do not contain them. A recursive browse that treats every hierarchical reference as containment will see the same parameter three times in three groups and report a device with triple the parameters it has. Deduplicate by NodeId.
• Device health is only as good as the mapping behind it. Plenty of devices report normal permanently, or collapse everything into failure, because nobody mapped the internal diagnostics onto the five categories. Validate it against a deliberately induced fault during factory acceptance rather than trusting the enumeration exists.
• Nearly every DI node is optional. A device can conform to DI while exposing a DeviceSet entry with a device type, no vendor nameplate, no health and an empty parameter set. Support for DI is not a statement about what data you will get, so specify the interfaces and parameters you need by name.
• The version numbering invites a mistake. The device model is at 1.05.0, published 2025-11-15, and the package metadata model at 1.05.0 published 2025-04-01 - these are the models' own versions and are not statements about the core 1.05 release family. Read the version from NamespaceMetadata per namespace.

Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.