OPC UA FX v1.00.04 vs v1.00.03: What Changed in Part 81 and Part 84

Open the OPC Foundation’s public online reference for OPC UA Field eXchange today, navigate to any clause in Part 80, and look at the version chip in the left rail. It reads v1.00.03. That is still true on 22 September 2026, weeks after the maintenance document set that moves Part 81 and Part 84 to OPC UA FX v1.00.04 was released to members. The HTML reference most engineers actually read has not been re-cut. So an implementer who checks “the spec” online is, right now, reading a version that no longer matches the released document set for two of the five parts — and nothing on the page says so. That gap is the single most expensive thing about this release, and it has nothing to do with any individual technical change.

What this covers: the structure of the UAFX document set and which parts moved; what the OPC Foundation has said publicly about the Part 81 and Part 84 changes and how confidently you can act on it; the object model those changes touch; why multiple Global Discovery Server addresses is an availability change rather than a feature tweak; and what a conformance-unit delta does to a product you already certified.

Context and Background

OPC UA Field eXchange is the OPC Foundation’s answer to a problem that has resisted solution for thirty years: getting a PLC from vendor A to exchange deterministic process data with a DCS controller from vendor B without a gateway, a mapping spreadsheet, and a commissioning engineer who understands both. Part 80 states the ambition plainly — UAFX “delivers a genuinely multi-vendor interoperable, real-time solution” for controller-to-controller communication, with the first release scoped to exactly that interaction pattern and the others deferred.

Architecturally, UAFX is not a new protocol. It is an information model plus a connection model layered on existing OPC UA machinery. Data exchange in this release rides OPC UA PubSub, optionally over Time-Sensitive Networking, with the IEC/IEEE 60802 TSN Profile for Industrial Automation as the convergence target. Safety data rides the OPC UA safety communication layer from OPC 10000-15 alongside standard process data on the same wire. Security uses ordinary OPC UA certificate and trust-list mechanisms. If you have read our comparison of controller-to-device versus controller-to-controller UAFX topologies, the shape will be familiar.

What makes version tracking hard here is that UAFX is a document set, not a single document. Five parts ship together, they carry independent version numbers, and the OPC Foundation issues maintenance releases that touch a subset. There is no single “UAFX version” to put in a datasheet. Vendors write one anyway, which is where the confusion starts.

The wider ecosystem context matters too. UAFX profiles are how certification works — and certification is how a plant owner decides whether two boxes will actually talk. A change to the profile document is therefore never cosmetic, even when the underlying behaviour is unchanged. The OPC Foundation’s companion specification programme treats these documents as the contract.

The version-lag trap: what “v1.00.04” actually identifies

Direct answer: OPC UA FX v1.00.04 is a maintenance release that updates two of the five UAFX parts — OPC 10000-81 and OPC 10000-84 — while Parts 80, 82 and 83 remain at v1.00.03. There is no single document numbered “UAFX v1.00.04”; the label describes the released document set, and the public online HTML reference still serves v1.00.03 for every part.

Figure 1: The five-part UAFX document set and the version skew introduced by the maintenance release.

The figure shows the five parts of the UAFX specification as enumerated in Part 80 clause 4.1: Part 80 UAFX Overview and Concepts, Part 81 UAFX Connecting Devices and Information Model, Part 82 UAFX Networking, Part 83 UAFX OfflineEngineering, and Part 84 UAFX Profiles. Two boxes are marked as having moved to v1.00.04. Every box feeds into a single node representing the public online reference, which reports v1.00.03 regardless. That convergence is the point: the reference site flattens the skew rather than exposing it.

Standing note on sourcing. The change list below has not been reflected in the public online reference, and this article could not read it from the specification text. It is attributed to the OPC Foundation’s own newsletter reporting. Confirm every item against the member PDF before you make an engineering decision on it. Where a clause number, attribute name, NodeId or ConformanceUnit name is not given below, it is because it is not public — not because it was omitted for brevity.

Three things the document set numbering is not

First, it is not a semantic version of a product. UAFX part numbers move on document-editorial grounds. A part can go to a new patch level because a figure was corrected, because normative language was tightened, or because genuinely new model content landed. The number alone tells you nothing about behavioural impact.

Second, it is not synchronised across parts. Before this release all five parts sat at v1.00.03, which made “we implement UAFX 1.00.03” a meaningful sentence. After it, that sentence is ambiguous — it could mean the pre-maintenance set, or the current set with two parts at v1.00.03 by virtue of not having been touched. A vendor datasheet saying “UAFX v1.00.04 compliant” is, strictly, claiming conformance to Part 84 at v1.00.04. That is a narrower and more checkable claim than it looks.

Third — and this is the subtle one — it is not something Part 80 can protect you from. Clause 2 of Part 80 lists OPC 10000-81 through OPC 10000-84 as reference documents with bare URLs and no edition dates, under the standard preamble: “For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.” Those references are undated. So Part 80 at v1.00.03 already normatively points at Part 81 v1.00.04. The overview document did not need to be reissued for the newer part to become the applicable edition. That is correct standards practice and it is also exactly why the version chip on the Part 80 pages is misleading in a way that is easy to miss: the document you are reading is current, but the documents it binds you to have moved underneath it.

How to establish which version you are actually on

There is a checkable artefact. A document-version record exists in the OPC Foundation’s profile tooling at profiles.opcfoundation.org/documentversion/278, titled “Published Document UAFX v1.00.04 – Parts for review”. That page is a JavaScript application and does not render for automated fetching, but it is reachable in a browser and is the authoritative place to see what the profile database believes is published. If you are building a conformance argument, that database — not the HTML reference, and not a vendor datasheet — is the thing to cite.

For a deployed system, the practical determination runs the other way round. You do not ask what version the specification is at; you ask what your components expose. Read the namespace metadata and the supported profile list off each AutomationComponent with a generic OPC UA client. A component’s declared profiles resolve to specific ConformanceUnits, and the ConformanceUnit set is where a Part 84 revision actually shows up. If two components on the same link declare profile sets that were defined under different Part 84 editions, that is the fact worth knowing — and it is discoverable at runtime without reading a PDF at all.

What the OPC Foundation says changed

According to the OPC Foundation’s Field Level Communications Corner (September 2026), the OPC UA FX Specification Maintenance Release V1.00.04 was published on 27 July 2026 and updates OPC 10000-81 and OPC 10000-84 only, leaving Parts 80, 82 and 83 at v1.00.03.

According to the same source, the Part 81 update brings enhancements to the ConnectionManager and to ConnectionConfigurationSets, including support for Global Discovery Server addresses — specifically the ability to carry multiple GDS addresses rather than one.

Also according to the Field Level Communications Corner (September 2026), Part 81 gains more flexible referencing from the ConnectionEndpoint to DataSetReaders and DataSetWriters, together with additional identification information for those DataSetReaders and DataSetWriters.

The same newsletter reports improved ConnectionConfigurationSet settings covering publishing interval and configurable communication intervals, alongside updated Publisher and Subscriber capabilities, and clarified requirements for the contents of Events and LogObjects.

For Part 84, the OPC Foundation’s Field Level Communications Corner (September 2026) reports new ConformanceUnits covering the functionality introduced in Part 81, plus improvements and clarifications to the ConformanceUnits that deal with Descriptor content.

That is the whole public change list. Notice what is absent: no clause numbers, no attribute names, no NodeIds, no ConformanceUnit identifiers. Any article that supplies those without citing the member PDF has invented them. The rest of this piece therefore does something more useful than paraphrasing a bullet list — it explains the machinery each of those bullets lands on, so that when you do open the PDF you know what you are looking at.

The UAFX object model these changes touch

Every item in the reported change list attaches to one of five concepts, all of which are defined normatively in Part 80 clause 3.1 and elaborated in Part 81. Getting these right is the difference between reading the maintenance release as a list of tweaks and reading it as a coherent move.

Figure 2: How a Descriptor, an AutomationComponent, its FunctionalEntities and the ConnectionManager compose into a running PubSub link.

The figure traces the chain from design-time artefact to wire traffic. A Descriptor feeds an AutomationComponent, which decomposes into Assets and FunctionalEntities. A FunctionalEntity exposes ConnectionEndpoints. A ConnectionConfigurationSet parameterises those endpoints. Endpoints plus a ConnectionManager produce a Connection, which maps onto the PubSub layer’s DataSetWriters and DataSetReaders, which in turn map onto TSN, plain Ethernet, or single-pair Ethernet with APL.

AutomationComponent, Asset and FunctionalEntity

The AutomationComponent is the foundation of the UAFX information model — Part 80 clause 4.2 says so explicitly. It is an entity performing one or more automation functions, composed of Assets and FunctionalEntities, and carrying communication capability and diagnostic information. An Asset is a physical or logical element of the component. A FunctionalEntity is the element “containing the data and methods needed to configure, control and manage functional behaviour”.

That last definition is doing more work than it appears. A FunctionalEntity is not a data block. It is the unit of configurability — the thing a remote party talks to when it wants to negotiate an exchange. Connections are defined between FunctionalEntities, never between AutomationComponents directly. A controller with three independently commissionable control loops models three FunctionalEntities, and a peer can connect to one without touching the others.

All three levels carry identification information. Part 80 clause 6.1 is specific about why: identification on AutomationComponents, Assets and FunctionalEntities allows “compatibility to be verified for each Connection”. This is the mechanism that turns a vendor claim into a runtime check, and it is the reason additional identification information for DataSetReaders and DataSetWriters — one of the reported Part 81 changes — is worth more than it sounds. Identification at the dataset level extends compatibility verification one layer down, from “can these two entities talk” to “do these two specific data flows agree on what they are carrying”.

Connection and ConnectionEndpoint

A Connection is defined as a “logical communication relationship between FunctionalEntities for exchanging information and coordinating joint operations”. Two things follow from the word logical. First, the Connection is an object in the address space with its own lifecycle, independent of whether packets are currently flowing. Second, it is mapped onto a communication model rather than being one — Part 80 clause 6.2 states that Connections “are mapped to a communication model such as PubSub or Client Server and different QoS classes in the application configuration”. This release maps them to PubSub; Client Server mapping is deferred to a future release, as is event exchange. Today, data only.

The ConnectionEndpoint is the FunctionalEntity-side handle on that relationship. It is where the mapping is pinned down: which DataSetWriter publishes for this endpoint, which DataSetReader consumes, what the QoS class is. The reported Part 81 change — more flexible referencing from the ConnectionEndpoint to DataSetReaders and DataSetWriters — is a change to the binding rules at exactly this joint.

Why would flexibility there matter? Because the rigid case forces a structural decision at engineering time. If an endpoint can reference writers and readers only in a constrained pattern, then a topology where one endpoint feeds several subscribers with different filtering, or where one reader aggregates from several writers, has to be modelled as several endpoints. Several endpoints means several Connections, several sets of configuration, several things to commission and diagnose. Loosening the referencing collapses that multiplication. It is an engineering-ergonomics change that shows up as fewer objects in a real plant configuration.

ConnectionManager

The ConnectionManager is the entity “that interacts with AutomationComponents to establish Connections between FunctionalEntities”. Part 80 clause 6.2 adds two deployment facts that are easy to skip and important to internalise: the ConnectionManager “may be part of an AutomationComponent or a separate entity like a central configuration server”, and “there may be multiple ConnectionManagers in the system operating independently of one another”.

Independent, plural connection managers is an unusual design choice for an industrial connection-establishment mechanism, and it is a deliberate one. It means UAFX does not require a plant-wide orchestrator. A pair of controllers can carry their own managers and establish a link between themselves; a line-level configuration server can manage a cell; both can coexist. The cost is that there is no single object that knows the whole connection graph, which pushes diagnostics onto the components themselves — and is very likely part of why clarified requirements for Events and LogObjects appear in the reported change list. If no central entity owns the truth, the per-component event and log surface is the diagnostic system, and ambiguity in what it must contain is a real interoperability hole.

Descriptor

The Descriptor is “a multi-document file (zip package) containing information for using and configuring one or more AutomationComponents”, whose primary purpose is to provide and share information for OfflineEngineering. It contains information model files and other artefacts, and may carry supporting documentation such as manuals and drawings. Part 83 defines its structure.

The Descriptor is the only one of these five concepts defined outside Part 81 — and the reported Part 84 change to “Descriptor-content ConformanceUnits” is therefore a nice illustration of how the parts interlock. Part 83 says what a Descriptor contains. Part 84 says what a product must demonstrate about Descriptor handling to claim conformance. Clarifying the latter changes nothing about the former, but it can change whether your product passes.

From OfflineEngineering to a running Connection

The reported changes to publishing intervals and configurable communication intervals only make sense if you can see where in the lifecycle those values are set, and by whom. Part 80 clause 5.4 lays out an engineering workflow with four distinct actors — Controls Engineer, Network Engineer, Security Administrator, System Commissioner — and that separation of duties is the reason a “configuration interval” is a more interesting parameter than it first appears.

Figure 3: The OfflineEngineering handoff and the runtime connection establishment it produces.

The sequence runs as follows. Engineering Tool A exports a signed Descriptor carrying the inputs and outputs Controller A will share. Engineering Tool B imports it and adds the Connection configuration. Both tools deploy their applications and endpoint configuration to their respective components. The Security Administrator rolls out certificates and trust lists. The ConnectionManager then calls OPC UA Methods on each AutomationComponent to establish the configured Connections, and PubSub traffic begins at the negotiated publishing interval in both directions.

The handoff is asymmetric, and that is the point

Part 80 clause 5.4.3 describes Controls Engineers A and B creating a joint application “while separated in time and space and potentially without the physical devices”. Engineer A exports; Engineer B imports and adds the connection configuration. The specification then adds a note that deserves more attention than it gets: this workflow covers Controller B obtaining the data it needs. “If Controller A needs data from Controller B, it would need to import a Descriptor from Controller B to understand its interface.”

Bidirectional data therefore requires a bidirectional Descriptor exchange. In a two-vendor project that is an extra round trip through two engineering tools, two export steps, and two import steps — each of which can be done by a different organisation at a different time. Anyone who has run a multi-vendor commissioning knows how much schedule risk lives in that loop. It is a genuine advance over a mapping spreadsheet, but it is not a single-step handshake and planning it as one will hurt.

Where intervals get decided

Part 80 clause 5.4.6 assigns the System Commissioner the job of adjusting “the Connection configuration, such as addresses of Connection partners, publishing intervals, and QoS mapping tables”, using a generic OPC UA client or a tool built on standard Client Server services. This is the commissioning-time tuning step, and it happens after the application engineering that fixed the data contract and after the network engineering that set up VLANs, time synchronisation and QoS.

That ordering is what makes the reported improvements to ConnectionConfigurationSet interval settings operationally significant. The publishing interval is not an application constant. It is a commissioning variable that trades network load against control-loop responsiveness, and the person turning the dial is neither of the engineers who wrote the programs. Richer interval configuration in the ConnectionConfigurationSet means more of that tuning can be expressed declaratively in a configuration object a generic client can read and write, instead of being buried in vendor tooling. For a controller-to-controller link, “configurable communication interval” is the difference between a link you can retune at 2 a.m. with a standard client and one that needs the original engineering workstation.

The establishment call is a Method, not a handshake

Clause 5.4.6 is explicit that the ConnectionManager “uses OPC UA Methods exposed by each AutomationComponent to establish the configured Connections when the system goes operational”. Connection establishment is a Client Server operation over a secure channel, and it happens before any PubSub traffic exists. That is the dependency chain that makes the GDS question sharp — which is where we go next.

For readers comparing this model against broker-based approaches, our analysis of UAFX versus MQTT Sparkplug B for a unified namespace walks the same lifecycle from the other side.

Why multiple GDS addresses is an availability change

Of everything in the reported change list, support for multiple Global Discovery Server addresses is the item with the largest operational consequence, and it is the one most likely to be written off as a configuration detail. It is not. It changes the availability characteristics of a certificate-dependent architecture.

Figure 4: What a GDS outage does to a UAFX system with one configured GDS address versus a list of addresses.

The figure contrasts two architectures at the moment a certificate renewal or trust-list update comes due. With a single configured address, a GDS outage means no reachable issuer, the renewal stalls, and when the existing certificate expires the SecureChannel is refused and the Connection drops. With an ordered list, the component moves to the next address, the renewal completes, and running Connections are unaffected.

The dependency, stated precisely

Part 80 clause 5.4.4 describes security commissioning: a Security Administrator, using a Security Provisioning Entity, configures Controllers for OPC UA security and rolls out the site security policy per Controller. The policy “contains, amongst others, certificates, roles, and user management”, and for PubSub it includes SecurityKeyServer configuration. The clause then notes that the Security Administrator “might use a GlobalDiscoveryServer (see OPC 10000-12) for security configuration”.

Note the modal verb. A GDS is not mandatory in UAFX. It is the standard OPC UA mechanism for centralised certificate management, and any site above trivial scale will use one because the alternative — manually distributing certificates and trust lists to every controller — does not scale past a demonstration cell.

Why the single-address failure mode is nastier than it looks

Certificate infrastructure fails differently from data infrastructure. A broker outage stops data immediately and loudly; someone gets paged. A GDS outage stops nothing immediately. Existing certificates remain valid, existing SecureChannels stay up, PubSub traffic continues at its publishing interval, and every dashboard stays green. The failure is latent. It converts into an outage only when the first certificate reaches expiry — which might be days or months later, and which will hit components in whatever order their certificates happen to expire.

That is close to a worst-case failure profile. It has a long, silent incubation; the trigger is a clock rather than an event, so it fires outside any change window; and it produces a staggered cascade rather than a single clean break, which makes it hard to diagnose as one root cause. A controller that cannot complete renewal does not fail over to an insecure mode — OPC UA will refuse the channel — so what an operator sees is a process link going down with no configuration change and no network fault.

Now recall that Connection establishment is a Client Server Method call over a secure channel. A component that has lost its certificate cannot merely limp along on existing PubSub traffic; it cannot be re-established either. Any event that tears down a Connection — a controller restart, a firmware update, a cable pull — becomes unrecoverable until the certificate problem is fixed. The GDS outage and the eventual failure are separated by so much time that nobody connects them.

What a list of addresses actually buys

Carrying multiple GDS addresses in the configuration moves failover from a manual, out-of-band procedure into the component’s own configuration object. The practical differences are worth enumerating precisely:

• Recovery becomes autonomous. With one address, restoring service after a GDS loss means reconfiguring every affected component — a touch-every-box operation, typically requiring vendor tooling, across a plant. With a list, the component retries elsewhere on its own.
• Maintenance stops being a risk window. Patching or migrating a single GDS means every renewal that falls in the outage window stalls. With redundant addresses, you can take one offline deliberately.
• Site topology stops being a constraint. Plants with segmented networks often cannot route every controller to one GDS instance. A list lets a component prefer a local instance and fall back to a central one.
• The dependency becomes auditable. A configured address list is a discoverable object. You can read it from every component and diff it against the intended design. A single hard-coded address in vendor configuration usually cannot be inventoried at all.

That last point is the one worth internalising. The value is not just redundancy — it is that the certificate-infrastructure dependency becomes something you can see from outside the component. Most availability problems in industrial security infrastructure are visibility problems first.

A caveat, stated honestly: the failure analysis above is ours, derived from the OPC UA security model and the dependency structure Part 80 describes. The specification text describing the new GDS-address capability is not public, so the exact configuration semantics — ordering, retry behaviour, whether failover is automatic or requires operator action — are not something this article can state. Treat the analysis as a framework for reading the PDF, not as a substitute for it.

Conformance units and the certification delta

The Part 84 half of the release is the half that decides whether v1.00.04 costs you money.

A Profile, per Part 80 clause 6.5, is “a named aggregation of ConformanceUnits and other Profiles”, defined for UAFX in OPC 10000-84, and “all OPC UA AutomationComponents will support one or more Profiles and any or all of its optional Facets”. A ConformanceUnit is the atomic testable capability. A Profile bundles them. Certification tests a product against the ConformanceUnits in the Profiles it claims.

The reported Part 84 change has two components, and they behave very differently.

New ConformanceUnits for the new Part 81 functionality. New units are additive. A product certified against the v1.00.03 unit set is not retroactively non-conformant; it simply does not hold the new units. In practice this produces a market where two certified products both legitimately claim UAFX conformance while differing in whether they support multiple GDS addresses or the newer endpoint referencing. Conformance is not a single bit, and after this release the distinction between “certified” and “certified against which units” stops being pedantry.

Improvements and clarifications to Descriptor-content ConformanceUnits. Clarifications are the interesting case, because a clarification can be behaviour-preserving in intent and still be test-changing in effect. If a unit was ambiguous, two vendors may have implemented two readings, both passed, and both shipped. A clarification picks one. The vendor who guessed the other way now has a product that passes the old test suite and fails the new one, without a single line of its code having changed. Nobody has done anything wrong, and somebody has to re-engineer.

What this means for your procurement and your roadmap

For a device vendor, the sequence is: obtain the member PDF, diff the ConformanceUnit tables, classify each delta as additive or clarifying, and only then decide whether a re-test is needed. Additive units are a roadmap question. Clarifying units are a risk question and they take priority — a clarification against your interpretation is a latent field-failure you currently cannot see.

For a plant owner or integrator, the question is different and simpler: do not accept “UAFX certified” as a specification line. Ask which Profiles, which Facets, and against which edition of Part 84 the certificate was issued. That is a reasonable, answerable question, and a vendor who cannot answer it has told you something useful.

There is also a timing consideration specific to maintenance releases. Certification laboratories need an updated test suite before they can test against new units, and test-suite development lags document publication. Between the two, there is a window in which a product can implement Part 81 v1.00.04 functionality but cannot be certified for it. If a project specification demands certification against the new units, verify that testing is actually available before writing that requirement into a contract.

Question	Where the answer lives	Can you self-serve it
Which parts moved to v1.00.04	OPC Foundation newsletter; member PDF set	Partly — the newsletter is public
What exactly changed in Part 81	Member PDF of OPC 10000-81	No — not in the public reference
Which Profiles a product claims	The product’s address space	Yes — any OPC UA client
Which ConformanceUnits a Profile contains	OPC 10000-84 and the profile database	Partly — profiles.opcfoundation.org
Whether a certificate covers new units	Certificate metadata plus Part 84 edition	Yes — ask the vendor
Whether test tooling exists yet	Certification laboratory	Yes — ask the lab

Trade-offs, gotchas, and what goes wrong

The reference-lag trap cuts both ways. The obvious failure is reading v1.00.03 and believing it is current. The less obvious one is over-correcting: assuming everything in the online reference is stale. Parts 80, 82 and 83 at v1.00.03 are current. The reference is accurate for three of five parts and silently out of date for two, which is harder to reason about than a wholesale lag.

Undated references mean you inherit changes you did not read. Because Part 80 cites Parts 81–84 undated, the newest edition applies automatically. Your conformance obligations moved when Part 81 v1.00.04 published, whether or not you noticed. This is standard ISO/IEC practice, not an OPC Foundation quirk, and it is why maintenance releases in multi-part standards deserve a formal watch process rather than ad-hoc newsletter reading.

“Maintenance release” understates the Part 84 impact. The phrase implies typo fixes. A ConformanceUnit clarification can invalidate a passing implementation. Treat any Part 84 revision as a certification event until you have diffed it.

A latent certificate dependency will not show up in testing. Nothing in a commissioning test or a factory acceptance test exercises certificate renewal, because certificates are fresh. The single-GDS failure mode only appears at the first renewal cycle, in production, months after sign-off. If you are designing now, design the GDS topology now.

Multiple GDS addresses is not multiple trust anchors. Redundant addresses improve availability of the service. They do not by themselves give you a second certificate authority, and a compromised or misconfigured CA is still a single point of failure however many addresses front it. Do not let an availability improvement be sold as a security improvement.

Do not build on the change list as if it were spec text. This article deliberately refuses to supply clause numbers, attribute names or ConformanceUnit identifiers for the v1.00.04 content, because they are not public. Any source that gives them without citing the member PDF should be treated as unreliable — a wrong BrowseName in an information model is not a typo, it is a failed connection.

Part 81 v1.00.04 does not change the release scope. Controller-to-Controller only. PubSub only. Data only, not events. Client Server connection mapping, event exchange, and the other interaction patterns remain future work, and no maintenance release changes that.

Practical recommendations

Start by establishing ground truth about your own estate rather than about the specification. Walk every UAFX-capable component with a generic OPC UA client and record its declared Profiles and namespace versions. This is discoverable, it is cheap, and it produces the inventory every subsequent decision depends on. Vendor datasheets are not a substitute; they describe what shipped, not what is deployed.

Then obtain the member PDFs for OPC 10000-81 and OPC 10000-84 at v1.00.04 and diff them against v1.00.03. Prioritise the Part 84 ConformanceUnit tables over the Part 81 model changes, because clarifications carry latent risk while new capability carries only roadmap cost.

Treat the GDS topology as an architecture decision with a deadline attached, not a configuration detail. If you have a single GDS today, the question is not whether you will have an incident but when the first certificate expires during an outage.

A working checklist:

• [ ] Inventory declared Profiles and Facets on every component with a standard OPC UA client.
• [ ] Obtain OPC 10000-81 and OPC 10000-84 v1.00.04; diff ConformanceUnit tables first.
• [ ] Classify every Part 84 delta as additive or clarifying; escalate clarifications.
• [ ] Ask each vendor which Part 84 edition their certificate was issued against.
• [ ] Confirm with your certification laboratory that test tooling for the new units exists.
• [ ] Document the current GDS topology and every component’s configured address.
• [ ] Simulate a GDS outage spanning a renewal cycle in a lab before designing around it.
• [ ] Add UAFX part versions to whatever you use to track standards, per part, not per set.
• [ ] Re-check the public online reference periodically for the re-cut to v1.00.04.

Frequently Asked Questions

Is OPC UA FX v1.00.04 a breaking change?

Not in the sense of invalidating v1.00.03 implementations. The reported Part 81 changes are described as enhancements and additional flexibility, and new Part 84 ConformanceUnits are additive — an existing certified product stays certified. The genuine risk sits in the reported clarifications to Descriptor-content ConformanceUnits, where a tightened definition can cause a previously passing implementation to fail re-testing without any code change. Until you have diffed the member PDF, treat that as an open question rather than assuming either answer.

Why does the OPC online reference still show v1.00.03?

Because the HTML reference is generated from the specification documents in a separate publication step, and that step had not been run for the v1.00.04 parts as of 22 September 2026. The version chip in the left rail of every Part 80 page reads v1.00.03. This is a publication-pipeline lag rather than a statement about which document is authoritative — the released member document set governs, and the reference site will catch up.

Do I need to upgrade if my system uses a single Global Discovery Server?

Upgrading the specification version is not what fixes this; the architecture is what fixes it. A single GDS is a single point of failure for certificate renewal and trust-list distribution regardless of which UAFX version you implement, and the failure is latent — it surfaces at the first renewal that falls inside an outage, not at the outage. The reported multiple-GDS-address support makes redundancy expressible in the component’s own configuration, which is a better place for it than vendor tooling.

What is the difference between a Profile and a ConformanceUnit in OPC UA FX?

A ConformanceUnit is the atomic testable capability — one specific behaviour a product either demonstrates or does not. A Profile is a named aggregation of ConformanceUnits and other Profiles, as Part 80 clause 6.5 defines it, and may carry optional Facets. Products claim Profiles; certification tests the ConformanceUnits those Profiles contain. That indirection is why a Part 84 revision can change what certification means without any Part 81 behaviour changing.

Which UAFX parts are still at v1.00.03?

According to the OPC Foundation’s Field Level Communications Corner (September 2026), Part 80 (Overview and Concepts), Part 82 (Networking) and Part 83 (OfflineEngineering) remain at v1.00.03, while Part 81 (Connecting Devices and Information Model) and Part 84 (Profiles) moved to v1.00.04. Because Part 80 cites the other parts as undated references, the unchanged overview document automatically binds to the newest editions of the parts it references.

Does OPC UA FX v1.00.04 add Controller-to-Device or Client Server connections?

No. Part 80 is explicit that this release of the UAFX specification covers Controller-to-Controller interactions, with Controller-to-Device, Controller-to-Compute, Device-to-Device and Device-to-Compute planned for future releases. Likewise, Connections in this release are mapped to OPC UA PubSub, with Client Server mapping and event exchange deferred. A maintenance release does not expand release scope — it refines what is already in scope.

Further Reading

• OPC UA FX C2D vs C2C: controller-to-device and controller-to-controller topologies — where the interaction models diverge and why only one of them is in the current release.
• OPC UA FX field-level communications: a systems analysis — the architectural case for UAFX against incumbent fieldbuses.
• OPC UA FX vs MQTT Sparkplug B for a unified namespace — deterministic field exchange compared with broker-based topic hierarchies.
• Implementing an OPC UA companion specification: a practical tutorial — how information models, profiles and conformance units fit together in practice.
• OPC 10000-80 clause 4.1, UAFX specification parts — the normative enumeration of the five-part document set.
• OPC 10000-80 clause 3.1, terms and definitions — normative definitions of ConnectionManager, Connection, Descriptor, FunctionalEntity and OfflineEngineering.
• OPC Foundation Field Level Communications Corner, September 2026 — the source for the v1.00.04 change list reported above.

By Riju — about