How OEMs Can Prepare Their Products for OPC UA FX

If you're an OEM building drives, sensors, robots, controllers, or industrial communication devices, here's a question worth considering: when your biggest customer asks whether your product is ready for OPC UA FX, will you have a confident answer?

That conversation is already beginning to appear in discussions around Industry 4.0, digital transformation, and future-ready automation architectures. While OPC UA FX is still progressing through industry adoption and ecosystem maturation, many OEMs are evaluating how their products can align with emerging requirements for interoperability, vendor independence, and field-level communication.

In our previous blogs, we explored what OPC UA FX is, how its architecture brings together controllers, field devices, and TSN, and the challenges organizations should consider when planning future deployments.

This article focuses on the practical steps OEMs can take today to prepare their products for OPC UA FX and position themselves for the next generation of industrial connectivity.

What OPC UA FX for OEMs Actually Means

Preparing a product for OPC UA FX involves more than simply adding an OPC UA server.

The goal is to enable devices to participate within a standardized communication framework that supports interoperable information exchange, Publisher-Subscriber communication, and future field-level integration across multi-vendor environments.

Depending on the target application and maturity of the relevant device profiles, OEMs may need to consider:

• Standardized information modeling

• OPC UA PubSub communication

• Functional Entity representation

• Connection Manager integration workflows

• TSN readiness for deterministic communication

• Companion specification alignment

The earlier these considerations are incorporated into product planning, the easier future adoption becomes.

Start With Your Hardware Platform Assessment.

Before implementing OPC UA FX functionality, OEMs should evaluate whether their current hardware platform can support the required software architecture.

Many organizations discover late in development that their existing processor, memory resources, or networking hardware were originally designed for traditional communication protocols and may require optimization or redesign to support additional functionality.

Key considerations include:

• Whether the processor has sufficient capacity to handle OPC UA communication, security services, and the product's primary control functions simultaneously.

• Whether available RAM and storage resources can accommodate information models, communication services, and future feature expansion.

• Whether the networking hardware can support TSN capabilities if deterministic communication becomes a target requirement.

• Whether the current platform allows future software updates as OPC UA FX profiles and companion specifications continue to evolve.

Conducting this assessment early helps avoid costly redesign efforts later in the development cycle.

Align With Relevant Companion Specifications 

Companion Specifications provide standardized information models for specific industries and device categories.

For OEMs, companion specification alignment is one of the most important steps toward achieving interoperability.

Organizations should:

• Identify whether an applicable Companion Specification exists for their device category.

• Map device parameters, methods, alarms, and states to standardized definitions whenever possible.

• Avoid creating custom structures where standard models already exist.

• Design extensions carefully when unique functionality is required.

• Plan for future updates as OPC UA FX device profiles and related specifications continue to mature.

Where specifications are still evolving, OEMs should prioritize extensibility so future changes can be accommodated without major architectural redesign.

Design Information Models for Interoperability 

An information model determines how other systems understand and interact with a device.

A well-designed model simplifies integration, while a poorly designed model can create challenges throughout the product lifecycle.

When preparing products for OPC UA FX environments, OEMs should focus on:

• Representing the physical and functional structure of the device clearly.

• Supporting standardized discovery and configuration workflows.

• Exposing capabilities in a consistent and predictable manner.

• Optimizing the model for embedded resource constraints.

• Validating information models using appropriate modeling and validation tools before deployment.

As OPC UA FX adoption grows, information models will become increasingly important in enabling seamless interoperability across vendors and automation platforms.

Plan for Functional Entities and Future Device Profiles

Functional Entities (FEs) are a key concept within the OPC UA FX architecture.

They provide a standardized way to represent device capabilities, interfaces, and communication behavior within a field-level automation environment.

Although device profiles and Functional Entity definitions continue to evolve as part of the OPC UA Field Level Communications initiative, OEMs can begin preparing by:

• Structuring software architectures around modular device capabilities.

• Designing configurable InputSets and OutputSets where applicable.

• Separating communication interfaces from core application logic.

• Maintaining flexibility for future profile enhancements and standardization efforts.

Products designed with modularity and extensibility in mind will be easier to adapt as the OPC UA FX ecosystem matures.

Evaluate TSN Readiness Early 

Time-Sensitive Networking (TSN) provides the deterministic communication capabilities that enable real-time industrial applications over Ethernet.

Not every OPC UA FX deployment will immediately require full TSN functionality. However, OEMs targeting motion control, synchronized control systems, or time-critical industrial applications should evaluate TSN readiness early in product development.

Areas to assess include:

• TSN-capable network interfaces.

• Support for IEEE 802.1 time synchronization mechanisms.

• Integration between network timing and device control functions.

• Performance under realistic network load conditions.

• Alignment with the IEC/IEEE 60802 industrial automation profile.

Hardware decisions made during early product development often determine how easily TSN support can be added later.

Build for Future Profile Evolution

One of the most important realities of OPC UA FX adoption is that the ecosystem continues to evolve.

As Field Level Communications (FLC) specifications, device profiles, and interoperability frameworks mature, product requirements may continue to develop.

OEMs should avoid tightly coupling their implementation to a single interpretation of today's requirements.

Instead, product architectures should emphasize:

• Modular software design.

• Configurable communication mappings.

• Update-friendly firmware architectures.

• Flexible information modeling approaches.

• Scalable interoperability strategies.

This approach helps protect development investments while supporting future industry requirements.

Validate Early and Often

Interoperability and compliance validation should begin as early as possible during development.

Organizations preparing products for OPC UA FX should consider:

• Regular testing using the OPC Foundation Compliance Test Tool (CTT).

• Validation of information models against relevant Companion Specifications.

• Interoperability testing with representative third-party devices.

• Participation in industry interoperability events and workshops where applicable.

• Documentation of compliance and validation results for customers and certification activities.

Because the OPC UA FX ecosystem is still developing, practical interoperability testing remains just as important as formal compliance validation.

OEM Preparation Checklist : Quick Reference

Preparation Area	Key Focus
Hardware Platform	CPU, memory, networking, future scalability
Companion Specifications	Standards alignment and interoperability
Information Models	Structured and standardized device representation
Functional Entities	Future field-level communication readiness
TSN Readiness	Deterministic communication support
Software Architecture	Flexibility for evolving requirements
Validation & Testing	Compliance and interoperability verification

Preparing for the Future of Industrial Connectivity

OPC UA FX represents an important step toward more interoperable, vendor-independent industrial automation systems. While the technology continues to mature and industry adoption grows, OEMs that begin preparing today will be better positioned to meet future customer requirements and emerging interoperability expectations.

Preparation is not a single project. It is a long-term product strategy that spans hardware architecture, information modeling, communication design, interoperability validation, and ongoing standards alignment.

At Eclatron, we help OEMs evaluate, design, and implement OPC UA-based communication solutions across embedded systems, industrial devices, gateways, and automation platforms. From information modeling and embedded stack integration to interoperability testing and architecture consulting, we support organizations as they prepare their products for the next generation of industrial connectivity.

Frequently Asked Questions

Q1. What is the first step an OEM should take to prepare for OPC UA FX? 

Start with a hardware platform assessment to confirm your processor, memory, and network interface can support a full UAFX stack. Discovering hardware limitations after firmware development starts creates the most expensive rework.

Q2. Do all OEM products need TSN support for OPC UA FX compatibility? 

Devices targeting real-time control like motion or synchronized I/O need IEC/IEEE 60802-compliant TSN hardware. Products without TSN can still participate in non-time-critical UAFX communication scenarios.

Q3. How do OPC UA companion specifications affect OEM product development? 

They define the standardized information model your device must follow for its product category. Skipping the relevant companion spec means customers need custom mapping work every single deployment.

Q4. How early should OEMs start compliance testing during product development? 

Start during development, not at the end, by running the OPC Foundation's Compliance Test Tool regularly. Structural issues caught early are far cheaper to fix than those discovered after architecture is locked.