OPC UA FX Implementation: RFP and FAT/SAT for Thai Factories

An OPC UA FX implementation should not begin with a shopping list of controller and switch models. A Thai factory first needs to define the Controller-to-Controller (C2C) and Controller-to-Device (C2D) scope, the boundary of any TSN-enabled segment, the interfaces to the installed network, multi-vendor maintenance ownership, and the evidence required at FAT and SAT. This guide stays out of general industrial-network design and focuses on procurement: how to specify a 90-day proof of concept and reach a defensible GO or HOLD decision.

Executive answer: procure a verifiable connection contract, not an “OPC UA-ready” claim

OPC UA FX is not another name for reading PLC tags through a conventional OPC UA Client/Server connection. It is also not created merely by forwarding PLC values as JSON through MQTT. It is a multi-part extension of OPC UA for interoperable field-level automation, covering information models, connection establishment and monitoring, networking, offline engineering, and profiles.

An RFP line that says “must support OPC UA” therefore produces incomparable bids. Each bidder should state the exact UAFX profiles, facets, conformance units and specification versions implemented; the communication model and connection lifecycle used; the device and firmware combinations tested; and every excluded or roadmap function. A successful C2C test is not evidence that C2D is ready. A PlugFest result is evidence for the configurations tested at that event, not proof that every commercial product is mature.

The procurement deliverables should include five items:

1. Separate C2C and C2D connection matrices, mapped to AutomationComponents, Assets and FunctionalEntities.
2. A network boundary drawing covering VLAN, QoS, time synchronization, redundancy and non-TSN segments.
3. Repeatable multi-vendor FAT/SAT cases with configuration snapshots, raw logs and pass/fail evidence.
4. An ownership model for initial diagnosis, certificate renewal, firmware updates, escalation and spare replacement.
5. A 90-day PoC scorecard with explicit GO/HOLD conditions and a list of risks deferred before rollout.

September 2026 status: a valuable PlugFest, not universal commercial proof

The OPC Foundation reports that a four-day OPC UA FX PlugFest was held at Festo in Germany on 7–10 September 2026, with 28 participants from 16 companies. Multi-vendor controllers controlled virtual machines that were dynamically combined as a production line. C2C connections were established and closed on demand. Prototypes of I/O, drives and other field devices were connected to parent controllers through C2D. According to the report, all C2C and C2D paths tested during the event succeeded. The event also exercised UDP multicast, priority-based QoS using VLAN tagging and gPTP time synchronization across implementations. The work supports a Demo Wall planned for SPS on 24–26 November 2026.

This is meaningful interoperability evidence. Its correct boundary, however, is “the tested paths and participating implementations succeeded at that event.” It does not certify every product, firmware, switch, installed Thai network or support process. The report explicitly places C2D I/O and drives in a prototype context. Procurement must keep those prototypes and demonstrations separate from the formally released profile scope of the exact model proposed for production.

On 27 July 2026, the Foundation published OPC UA FX maintenance release v1.00.04, updating Parts 81 and 84. The reported Part 81 changes include improved Asset–FunctionalEntity linking, multiple GDS addresses, additional DataSetReader/DataSetWriter identification and configurable communication intervals. Part 84 received related conformance units. This is positive progress, but citing v1.00.04 is not enough. The bid must disclose the implemented subset, limitations, update plan and compatibility for every model and version.

Translate Parts 80–84 into RFP answers

OPC UA FX consists of five parts. A purchasing team does not need to memorize them, but using their roles makes vendor answers comparable.

Part 81 v1.00.04 is especially practical for an RFP. An AutomationComponent is not merely a synonym for the physical PLC enclosure. Assets represent physical or logical items, FunctionalEntities describe functions and their inputs, outputs and configuration, and a ConnectionManager participates in creating, monitoring and closing connections. Ask the bidder to map an actual packer, conveyor, inspection station, remote I/O and drive to those concepts and to show how compatibility is verified after a replacement.

Recheck the OPC Foundation profile database immediately before award. A series-level scope must not be silently converted into a declaration for every model. Link the claim to the exact model, hardware revision, firmware, library and functions in use. Put formal release, limited release, evaluation build, PlugFest implementation and future roadmap in separate fields.

Do not equate OPC UA FX with Client/Server or simple MQTT forwarding

All three can be useful, but they solve different problems. Conventional OPC UA Client/Server is suitable when a client accesses data or methods in a server address space. MQTT is widely used as lightweight broker-based messaging. OPC UA FX addresses interoperable meaning and connection behavior among industrial automation components; it does not make the other methods invalid.

If a gateway reads tags from PLC A, converts them to JSON and publishes them to MQTT, that may be a sound IIoT design. It is not by itself proof of UAFX C2C or C2D. Likewise, two PLCs exchanging data over Client/Server do not necessarily implement the UAFX information model, profile requirements or ConnectionManager lifecycle. Every architecture drawing should identify the communication model and mark the exact segment tested as OPC UA FX.

Treat Controller-to-Controller and Controller-to-Device as separate acceptance units

C2C: verify functional connections between machines and cells

C2C testing should show how production permission, state and interlock-related information is mapped to FunctionalEntity inputs and outputs across different controller vendors. Separate safety functions from standard control at the start. “UAFX capable” is not a basis for replacing a safety-certified fieldbus or hardwired safety circuit.

FAT should cover much more than a healthy connection. Test restart of either side, mismatched connection definitions, an obsolete descriptor, loss of time synchronization, stopped publishers, delayed subscribers, expired certificates and changed network paths. Capture what error the ConnectionManager exposes, which state follows, and whether an operator could mistakenly see “connected.”

C2D: verify commercial readiness model by model

C2D extends the scope to I/O, drives and other field devices. The September 2026 PlugFest report uses prototype language, so the event cannot guarantee the production status of a proposed device. The RFP should require model, hardware revision, firmware, profile/facet scope, official sales status, certification status, supported country and maintenance period.

Test replacement, not only cyclic communication. When a failed device is replaced, verify Asset identity and compatibility, determine who approves ConfigurationData, and confirm how a wrong model or old firmware is rejected. This workflow crosses technology and maintenance responsibility; a lab screenshot from the integrator does not close it.

Define the OPC UA FX TSN boundary from requirements

OPC UA FX and TSN are related, but an OPC UA FX project does not automatically require factory-wide TSN. Start with cycle, latency, jitter, concurrent traffic, availability, time accuracy and failure behavior. Assign networking capabilities only where those requirements call for them.

The September PlugFest exercised UDP multicast, priority-based QoS with VLAN tags and gPTP time synchronization across implementations. Those are useful RFP test candidates. A TSN-capable switch alone, however, cannot establish end-to-end behavior. Validate the complete route: endpoints, switches, time grandmaster, VLANs, queue settings, management tools and every non-TSN segment.

The broader the TSN scope, the broader the shared configuration responsibility. The contract should say who owns the grandmaster, VLAN plan, queues, diagnostics and firmware-compatibility matrix across the PLC vendor, switch vendor, SIer and factory IT/OT. A conformity claim and an end-to-end factory acceptance test are different forms of evidence.

Avoid cannibalizing the existing guidance

This article addresses OPC UA FX procurement and acceptance, not general networking or a general treatment of Thai interoperability standards.

Use those guides for the physical and logical network, local standards context and edge role. Use this guide to decide what belongs in the OPC UA FX RFP and how the proposed system will be accepted.

Twelve questions for an OPC UA FX RFP

Require a common response matrix containing Requirement ID, answer, evidence, exception, owner and verification gate.

“Planned support” may appear in a bid, but not in the same field as a current feature. Separate generally available, limited release, evaluation, prototype and roadmap capabilities. If a future feature is mandatory for production, define the fallback and contractual consequence if it is not delivered.

Use certification and PlugFest evidence correctly

The OPC Foundation certification program evaluates minimum operability requirements such as specification compliance, interoperability with other vendors, robustness, usability and resource efficiency. A product tested by an accredited lab is important evidence. However, an SDK itself cannot be certified directly because the customer application still defines the address space, data handling and security. Even an application based on an SDK with a certified reference implementation needs its own testing to become an officially certified product.

Check that the certification record covers the exact product, version and profiles used in the project. The September 2026 Compliance Corner also states that certification support for OPC UA 1.03 is due to end at the end of 2026 and that vendors should target 1.05. This does not mean an installed 1.03 system stops operating. It means a new RFP should ask for the certification and upgrade roadmap and the support model during coexistence.

PlugFest finds integration issues across implementations. Certification evaluates a defined product scope against a program. FAT/SAT accepts the factory’s configuration, load, network and operating procedure. They are complementary and none replaces the other.

Multi-vendor FAT: freeze the combination, configuration and evidence

FAT should produce a reproducible record, not a photograph of two green connection indicators. The Bill of Test must identify the controller, I/O or drive, switches, time source, ConnectionManager, engineering tools, certificates, configuration files and traffic generator.

At minimum, test:

• C2C establishment, monitoring, planned close and abnormal loss from either side.
• C2D discovery, compatibility, replacement and rejection of wrong models or firmware.
• UDP multicast join/leave, multiple subscribers and prevention of unintended reception.
• Matching and mismatched VLAN/QoS under normal and competing traffic.
• gPTP synchronization, grandmaster change, loss and recovery indication.
• Certificate renewal, expiry, trust-list mismatch and insufficient privilege.
• Descriptor or OfflineEngineering version mismatch, reapplication and rollback.
• Log export, cross-device correlation and repeat-test consistency.

Never copy a performance figure from a catalogue into the acceptance record. Store message size, publisher/subscriber count, cycle, traffic load, switch settings, measurement points and time source with each result. Derive thresholds from factory requirements and do not invent savings, success rates or payback periods.

Multi-vendor SAT: turn Thai factory conditions into evidence

SAT brings in the real power, wiring, panels, installed VLANs, time system, access rights, maintenance laptop and shift handover. Replace every FAT simulator or substituted device with its production equivalent and test again. Acceptance should also require the Thai maintenance team to export evidence and perform initial diagnosis without hidden vendor access.

The SAT plan should include the following scenarios:

1. Recover connections when cells start in a nonstandard order.
2. Restart controller, field device and switch separately.
3. Add competing traffic at the legacy uplink or non-TSN boundary.
4. Remove gPTP synchronization temporarily and verify diagnosis, alarm and recovery.
5. Replace a spare and verify identity, compatibility and configuration.
6. Exercise remote-maintenance approval, session logging and termination.
7. Have factory personnel assemble a package containing configuration snapshots, packet capture and UAFX logs.

Do not close an issue as merely “minor.” Record impact, reproduction steps, workaround, permanent action, owner, due date and retest condition. Define before contract award which exceptions block GO and which may enter production under formal risk acceptance.

Make the evidence package and maintenance ownership contractual deliverables

Multi-vendor incidents stall when every supplier says its component is healthy and nobody owns the end-to-end record. Require this FAT/SAT package:

• As-built diagram plus model, serial and hardware/firmware/software versions.
• UAFX profile, facet and conformance-unit scope.
• AutomationComponent, Asset, FunctionalEntity and Connection definitions.
• Snapshots of switch, VLAN/QoS, gPTP, multicast and ACL configuration.
• Test input, expected and measured output, raw logs, packet capture and time status.
• Certificate and key owner, renewal, expiry monitoring and revocation procedure.
• Open items, exceptions, workaround, retest record and approver.
• Backup/restore, spare replacement, rollback and vendor-escalation instructions.

Assign product diagnostics to product vendors, integrated configuration to the SIer, operating configuration to plant OT, identity/certificates/remote access to IT-security and commercial gates to procurement. Then fill the seams: name the party that gathers the first end-to-end logs and the party that convenes the incident call while root cause is still unknown.

A 90-day PoC with explicit GO/HOLD gates

Ninety days is a scope constraint for a buying decision, not a promised performance improvement. Limit the PoC to one representative C2C pair, one C2D branch, at least two vendors and one TSN boundary.

Days 1–30: DEFINE requirements and evidence

Agree the target process, allowed downtime, safety boundary, C2C/C2D scope, communication model, timing and availability needs, installed network, and formal release status of each candidate. Approve the profile/CU response, Asset–FunctionalEntity map, ownership matrix, test cases and evidence format.

The gate is not “hardware delivered.” Each requirement must have a test ID and owner; prototypes and roadmap features must be separate from GA functions; and the evidence needed for GO/HOLD must be defined. If material unknowns remain, HOLD before implementation.

Days 31–60: PROVE C2C/C2D and break the TSN boundary in the lab

Exercise connect, disconnect, restart, version mismatch, sync loss, VLAN/QoS mismatch, multicast, certificates and replacement. Freeze the Bill of Test and retain raw evidence. If a C2D component is a prototype, state that fact and the conditions for migration to the production product.

The gate is a repeatable pass of every mandatory case, a named cause and owner for each fail, and agreement on tests deferred to SAT. A single successful connection is not a gate.

Days 61–90: VALIDATE at the factory and transfer operation

Deploy in a representative cell and use the real network, clock, access model and maintenance staff. Thai personnel demonstrate configuration checks, log export, spare replacement and first-line diagnosis. Close contractual, support, cybersecurity and training items.

GO requires more than technical passes. The exact models must have acceptable supply, formal-release status, certification scope, support contact, update policy, responsibility and residual risk. HOLD is not project failure. It is a documented decision such as waiting for a C2D production release, closing a profile gap, defining the TSN boundary or completing a support agreement, with a clear restart condition.

Thailand BOI measures are a qualification topic, not a guarantee

Thailand’s BOI publishes a Measure for Industrial Upgrades towards Smart and Sustainable Industry. Its official page describes support for eligible new and existing investors in Group B activities and states conditions including a minimum efficiency-enhancement investment of THB 1 million excluding land and working capital. It also describes machinery import-duty exemption and conditional corporate-income-tax incentives, with specific treatment related to machinery linked to the domestic automation industry.

An official BOI OSOS article reports 132 applications and approximately THB 17.2 billion for Smart and Sustainable Industry in the first half of 2026. These are application figures, not OPC UA FX deployments, approvals, tax advice or proven returns. Eligibility depends on the current announcements, activity, timing, expenditure and documentation. Confirm it with BOI or a qualified adviser and never distort the technical requirement merely to fit an incentive.

Common failure patterns

Buying “OPC UA support” as one undivided item

Conventional UA, UAFX, PubSub, Client/Server and MQTT gateways become mixed in one price. Fix C2C/C2D, communication model, profile/facet/CU and exact model in the response matrix.

Buying TSN as a label

The switch feature is checked, while endpoints, gPTP and QoS operations are omitted. Test an end-to-end path under a declared load.

Reading a PlugFest result as a product warranty

The event is valuable interoperability evidence, but its versions and cases may differ from the plant. Separate prototype, demo, GA and certified status.

Delegating all ownership to the SIer

An integrator cannot control each vendor’s roadmap or certification. Divide product, integration, network, certificate and operations ownership, then add an end-to-end first-response owner.

Ending the PoC with a dashboard demo

Normal values do not prove maintainability. Intentionally disconnect, restart, desynchronize, misconfigure, replace and update components and retain the evidence.

OPC UA FX implementation FAQ

How is OPC UA FX different from ordinary OPC UA?

It is a multi-part framework that uses OPC UA technologies for field-level information models, connections, networking, offline engineering and profiles. It is not synonymous with reading a tag or forwarding a payload through MQTT.

Is TSN mandatory for OPC UA FX?

Not uniformly across every segment. Determine it from cycle, latency, jitter, time, load and availability requirements. Test endpoints, switches, gPTP and VLAN/QoS together.

Can C2C and C2D be evaluated in one PoC?

Yes, but accept them separately. Do not generalize a C2C pass to C2D. Confirm each C2D model, hardware/firmware, formal release, profile scope and replacement behavior.

Did the September 2026 PlugFest prove that C2D is commercially complete?

No. It demonstrated success for the paths tested at the event and included prototypes of I/O and drives. It does not establish the commercial maturity, availability, certification or factory performance of all products.

Does OPC Foundation certification replace FAT and SAT?

No. Certification is evidence for a defined product and profile; PlugFest is cross-implementation learning; FAT/SAT accepts the plant configuration. Use all three at their correct boundaries.

What should be decided first for multi-vendor PLC interoperability?

Define functional boundaries, data meaning, connection lifecycle, models and versions, time/network conditions and failure ownership. Include replacement, updates, diagnosis and evidence export.

What makes a 90-day PoC ready for GO?

Mandatory C2C/C2D cases pass reproducibly, TSN and non-TSN boundaries are explainable, local staff can collect logs and perform initial diagnosis, and release, support and ownership risks are acceptable for rollout. Do not invent a benefit rate or ROI.

Summary: accept interoperability through evidence, not a specification name

A sound OPC UA FX implementation separates C2C and C2D, ties Parts 80–84 and profile scope to exact versions, and defines the TSN boundary from measurable requirements. The September 2026 PlugFest is promising evidence, but not a blanket statement of commercial maturity; its C2D prototype and demonstration context must stay separate from formal product releases. Standardize the RFP answers, reproduce healthy and failure behavior at FAT/SAT, and retain configuration, logs, results and owners in one evidence package.

TOMAS TECH can support pre-product RFP definition, C2C/C2D scoping, multi-vendor FAT/SAT design and a 90-day GO/HOLD scorecard. You can contact us while the project is still comparing options.

Primary and official references

• OPC Foundation, Field Level Communications Corner – September 2026: https://opcconnect.opcfoundation.org/2026/09/field-level-communications-corner-september-2026/
• OPC UA Part 80, UAFX Overview and Concepts: https://reference.opcfoundation.org/specs/OPC-10000-80/4.1
• OPC UA Part 81 v1.00.04: https://reference.opcfoundation.org/specs/OPC-10000-81/4
• OPC Foundation Profile Database, document 25: https://profiles.opcfoundation.org/document/25
• OPC Foundation Certification, Overview & Benefits: https://opcfoundation.org/certification/overview-benefits/
• OPC Foundation, Compliance Corner – September 2026: https://opcconnect.opcfoundation.org/2026/09/compliance-corner-september-2026/
• Thailand BOI, Smart and Sustainable Industry measure: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
• Thailand BOI OSOS, 1H 2026 investment news: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/