Part 83: UAFX Offline Engineering
| Document number | OPC 10000-83 - title and status not confirmed |
|---|---|
| IEC designation | IEC 62541-83 - publication not confirmed |
| Colloquially | Part 83 |
| Group | UAFX |
Part 83 is our understanding of the offline-engineering part of the UAFX series - engineering a field-exchange system before the devices are on the network, by exchanging descriptions of them between tools. The title and released-versus-draft status are unconfirmed, so this page describes what is verifiable around it.
Why offline engineering exists
A field-exchange system has to be designed before it can be built. The controllers are on order, the panel is not wired, and somebody still has to decide which functional entity talks to which, at what cycle time, and produce a configuration that can be downloaded when the hardware arrives. That requires a device description a tool can consume without the device being present - the same role a GSD or an EDS file plays in a fieldbus world - plus a way for one vendor's engineering tool to hand a partial design to another's.
The confirmed artefact: AutomationML packaging
The observable evidence of offline engineering in the released UAFX material is AutomationML packaging. The UAFX release bundles ship .amlx archives containing the nodesets a tool needs to work offline: the core OPC UA nodeset, the device information model nodeset, the safety nodeset, and the three UAFX nodesets. AutomationML is the established XML container for exchanging engineering data between industrial tools, so bundling the information models into it is exactly the shape of an offline-engineering artefact. That the bundles exist and what they contain is confirmed; which part defines their use is not.
How it relates to the online path
Offline engineering produces a design; the connection manager in Part 81 applies it. The intended flow is that a tool works out the communication flows against device descriptions, and the resulting configuration is written into the connection manager model on real hardware, which then establishes the connections. Understanding that split matters for tool selection: a tool that can only configure a live device gives you no design phase, and a tool that can only produce a design gives you nothing to download.
What we are not stating
We have not confirmed this part's title, number, or whether it is released or in draft, and we do not name its types or describe its file formats beyond the AutomationML packaging we can see in the release material. Tool support for any of this is vendor-specific and early, so treat vendor claims about offline UAFX engineering as claims to test on a pilot rather than as a specification to write against.
What it defines
| Concept | What it is |
|---|---|
| The number and title - not confirmed | We believe the offline-engineering part of the series sits at 83, and we have not verified the number, the title or whether it is released or draft. |
| The subject matter | Designing a field-exchange system before the hardware is on the network, by exchanging machine-readable device and system descriptions between engineering tools. |
| AutomationML packaging - confirmed | The UAFX release material ships .amlx archives, the standard container for exchanging engineering data between industrial tools. |
| What the bundles contain - confirmed | The core OPC UA nodeset, the device information model nodeset, the safety nodeset and the three UAFX nodesets, packaged for offline tool consumption. |
| Relationship to the connection manager | Offline engineering produces the configuration; the Part 81 connection manager applies it on real hardware. Design and commissioning are two distinct steps. |
| The fieldbus analogy | The role is that of a device description file in a fieldbus workflow: enough machine-readable detail to design a system around a device that is not present. |
| Tool support | Vendor-specific and early. Whether a given engineering tool can import a UAFX device description and export a downloadable configuration is a question to answer on a pilot. |
| What to cite instead | Part 81 for the models a design targets, and the AutomationML standard directly for the container format. |
Do you need to read it?
Anyone selecting engineering tools for a UAFX project, and machine builders who will have to hand a partial design to a system integrator or receive one. The AutomationML packaging is the concrete thing to ask a tool vendor about, because it exists in the release material and can be tested.
Traps that trace back to this part
- Do not cite Part 83 in a specification from this page. Confirm the number, the title and the status against the publisher's own current reference documentation, and specify the AutomationML container and the Part 81 models instead, both of which are confirmed.
- A tool that imports a nodeset is not the same as a tool that supports offline engineering. Importing types tells you what a device could expose; designing a system needs the tool to produce a communication-flow configuration that a connection manager will accept. Ask for a round trip on a pilot: design offline, download, and connect.
- The nodeset bundles pull in the core, device and safety models alongside the UAFX ones, which means offline engineering carries their version dependencies too. A design built against one core nodeset version and downloaded to hardware loaded with another is a version-skew problem that surfaces at commissioning.
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.