IEC 62541 · UAFX

Part 81: UAFX Information Model

Document number	OPC 10000-81
IEC designation	IEC 62541-81 - IEC publication not confirmed
Colloquially	Part 81
Group	UAFX

Three namespaces, one part

UAFX ships as three separate information models with three separate namespace URIs - one for the automation component, one for the connection manager, and one for the data types shared between them - and all three are documented against Part 81. That is the practical reason this part matters more than the rest of the series: whatever the other 80-series parts are called, this is the document that defines the types a server actually exposes. The three models are versioned and released together, currently at 1.00.04 with a publication date of 2026-07-22.

The automation component model

AutomationComponentType is the root of the device side. It carries an asset identity through FxAssetType, so a UAFX participant is a properly identified thing rather than an anonymous network endpoint, and it contains one or more instances of FunctionalEntityType. The functional entity is the unit that produces and consumes data, and it is what a connection is actually made to - which means one physical controller can present several independently connectable functions. FxRoot is the standard entry point under which all of this is published, so a client knows where to look without guessing at a vendor folder name.

The connection manager model

ConnectionManagerType is the configuration side. It works from CommunicationFlowConfigurationType, which describes one exchange, and SubscriberConfigurationType, which describes the receiving end of it. Connection endpoints carry a mode enumeration, PubSubConnectionEndpointModeEnum, distinguishing how an endpoint participates. The effect is that establishing field communication becomes a matter of writing configuration into a standard model, which a tool can generate and an operator can read back, rather than of setting PubSub writer and reader parameters by hand on both ends and hoping they match.

Conformance units, and how to check a server

The released models come with named conformance units that make claims testable: UAFX AutomationComponent Base, UAFX FXAsset Type, UAFX FunctionalEntity Base, UAFX ConnectionManager Base, UAFX ConnectionManager PubSubCommunicationFlowConfiguration, UAFX ConnectionEndpoint PubSub Connections, and UAFX FxRoot. Those names are the right currency for a requirement or an acceptance test. On a running server, the capability codes FXAC and FXCM advertise the automation component and connection manager models, and reading the three namespace URIs out of NamespaceArray with their versions from NamespaceMetadata tells you what is genuinely loaded.

What it defines

Concept	What it is
AutomationComponentType	The root object type of a UAFX participant, carrying its asset identity and containing its functional entities. What a UAFX-capable device exposes.
FxAssetType	The asset identity of a UAFX component - the model's answer to which physical thing this is, aligned with device identification practice elsewhere in the standard.
FunctionalEntityType	The connectable unit inside an automation component. Connections attach here, so one device can expose several independently configured functions.
FxRoot	The standard entry point in the address space under which UAFX objects are published, so discovery does not depend on vendor folder naming.
ConnectionManagerType	The object responsible for establishing, monitoring and releasing communication between functional entities from declarative configuration.
CommunicationFlowConfigurationType	The description of one configured exchange. This is the structure a tool writes to set up field communication instead of hand-tuning PubSub parameters.
SubscriberConfigurationType	The receiving side of a communication flow, describing how a subscriber participates in it.
PubSubConnectionEndpointModeEnum	The enumeration distinguishing how a connection endpoint takes part in a PubSub connection.
The three namespaces	Separate namespace URIs for the automation component, connection manager and data models, all released together at version 1.00.04 on 2026-07-22.
FXAC and FXCM capability codes	Advertise the automation component and connection manager models respectively, so a discovery client can filter for UAFX participants before connecting.

Do you need to read it?

Anyone implementing or evaluating UAFX. This is the part to build against and the part to cite, because its content is confirmed and its conformance-unit names are public and testable. Integrators should read it alongside Part 14, since the actual data movement is PubSub and every PubSub concern applies underneath.

Traps that trace back to this part

• All three namespaces are released and versioned together. Check all three in NamespaceArray, not just the automation component one, and read the version from NamespaceMetadata for each. A device that loads two of the three at 1.00.04 and one at an older version is a configuration you do not want to debug on site.
• This is a first-major-version model with an annual release rhythm - 1.00.02 in February 2024, 1.00.03 in July 2025, 1.00.04 in July 2026. Pin the exact version in your design and treat an upgrade as a project step rather than a patch.
• The information model is defined here, not in the overview or networking parts. A datasheet citing a different 80-series number for the type definitions is citing the wrong document, and it is worth asking which namespace URI and version they actually implement.
• The security and delivery guarantees are Part 14's, not this part's. A UAFX connection is PubSub underneath, so message security needs group keys from a Security Key Service, and a subscriber that joins mid-stream has the delta-frame problem like any other. Reading Part 81 alone gives you a model without a threat assessment.

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.