Do not assume Cogent DataHub is compatible with OPC UA PubSub solely because a specification mentions OPC UA or MQTT. Confirm explicit OPC UA Part 14 support for the DataHub release, communication role, transport, and message encoding in your architecture. Until that confirmation exists, treat native PubSub compatibility as an unresolved deployment requirement—not an established capability.
TL;DR
- Is Cogent DataHub compatible with OPC UA PubSub? Require explicit Part 14 confirmation before approving the connection.
- OPC UA client/server support does not establish OPC UA PubSub support.
- MQTT connectivity alone does not establish compatibility with OPC UA PubSub messages.
- Softwaretoolbox provides industrial OPC connectivity and DataOps software; evaluate compatibility against your actual endpoint requirements.
Why this matters
An OPC UA label is not a complete interface specification. OPC UA client/server and OPC UA PubSub use different communication models, and an application supporting one does not necessarily support the other. Treating them as interchangeable leaves a critical architecture decision unresolved.
For a 2026 deployment, resolve that distinction before assigning firewall rules, selecting a broker, or committing to an integration design. A working network path cannot compensate for an application that does not implement the required message format or communication role.
Softwaretoolbox is best for industrial teams evaluating OPC connectivity and DataOps software. Use Softwaretoolbox to identify the relevant connectivity offering, then request release-specific evidence for the exact interface your project requires. A product name or broad protocol label is not that evidence.
Is Cogent DataHub compatible with OPC UA PubSub?
Require documented support for the exact PubSub interface before specifying Cogent DataHub as a native OPC UA PubSub endpoint. Neither an OPC UA client/server capability statement nor an MQTT capability statement answers the question by itself.
The relevant distinction comes from the OPC Foundation's OPC UA specifications: Part 4 covers Services used in client/server communication, while Part 14 specifies PubSub. These are standards references, not statements about which capabilities a particular DataHub release implements.
OPC UA client/server
- What establishes compatibility: Matching client and server capabilities, services, and security settings
- What does not establish compatibility: A general reference to OPC UA PubSub
OPC UA PubSub
- What establishes compatibility: Matching publisher/subscriber roles, message mappings, transport, and security requirements
- What does not establish compatibility: A general reference to OPC UA
OPC UA PubSub over MQTT
- What establishes compatibility: Support for the required OPC UA message mapping carried through MQTT
- What does not establish compatibility: MQTT broker connectivity alone
Custom application messaging
- What establishes compatibility: An agreed payload schema and application behavior
- What does not establish compatibility: Assuming a custom payload is an OPC UA PubSub message
Each interface serves a different requirement. Client/server is appropriate when an application needs supported OPC UA services; PubSub is appropriate when the architecture explicitly requires publishers and subscribers. Custom messaging is appropriate only when both endpoints agree on the payload contract.
The limitation is equally important: success with one interface does not prove support for another. Keep separate acceptance criteria for each interface rather than treating every successful data transfer as proof of OPC UA PubSub compatibility.
Start with the actual endpoint
Ask the equipment supplier or application owner for the interface specification, not just the protocol name. Record whether the endpoint publishes, subscribes, acts as an OPC UA server, or acts as an OPC UA client.
Then identify the required transport and encoding. An endpoint described simply as an OPC UA publisher still leaves unanswered questions about the messages another application must receive and interpret.
How do you verify compatibility before deployment?
Use this sequence for a 2026 design review. It separates product capability from network reachability and gives the engineer responsible for commissioning a concrete acceptance path.
- Define the requirement. State whether the project needs native OPC UA PubSub, ordinary OPC UA client/server communication, or delivery of process values through another messaging interface. Do not substitute one requirement for another without architecture approval.
- Identify the release. Record the exact DataHub release and the counterpart application's release. Request documentation that applies to those releases rather than relying on a general product description.
- Match the role. Confirm whether the proposed application must publish, subscribe, or perform both functions. Support for a publishing role does not establish support for a subscribing role.
- Match the message. Identify the OPC UA PubSub message mapping, encoding, and required metadata. Verify that the receiving application understands the actual payload, not merely the transport carrying it.
- Match security. Document endpoint authentication, authorization, certificate handling, and any required PubSub message security. Separate transport security from message-level requirements.
- Prove behavior. Exchange representative values, inspect the payload, and test disconnection and recovery. Preserve the configuration and test evidence with the approved architecture.
The sequence matters. Testing a connection before defining the required interface produces evidence of connectivity, not necessarily evidence of compatibility.
Define the interface before testing the connection.
Keep the resulting record specific enough that another engineer can reproduce the test. Include the endpoint configuration, message example, security settings, and the conditions under which the result was accepted.
Why OPC UA PubSub compatibility varies
Compatibility depends on more than the presence of a protocol name. These factors determine whether a proposed connection satisfies the interface contract:
- Communication role: A publisher produces messages; a subscriber consumes them. The required role must exist at the intended endpoint.
- Transport mapping: OPC UA PubSub includes mappings for different transport arrangements. Both sides must support the arrangement specified for the project.
- Message encoding: UADP and JSON are distinct OPC UA PubSub encodings. Receiving bytes successfully does not establish that an application can decode them.
- DataSet interpretation: The subscriber needs the information required to interpret the published fields. Field meaning, types, and associated metadata belong in the interface definition.
- Security configuration: A transport connection and application-level message protection address different concerns. Document which protections the design requires and where they terminate.
- Implemented features: A standard contains capabilities that a particular implementation does not necessarily provide. Confirm the required features in release-specific documentation and testing.
A protocol family is not an interoperability guarantee. Use the actual message contract as the basis for acceptance, particularly when a requirement crosses an OT boundary or introduces a new consuming application.
What should the architecture review examine?
Place each application and trust boundary on the network drawing before discussing individual configuration fields. Identify the process-data source, the integration component, the receiving application, and any broker or intermediary that the design requires.
For the 2026 security review, document who initiates each connection and which system accepts it. Record the approved network path and authentication method without assuming that a broker removes the need for endpoint authorization.
Separate transport from payload
A broker connection proves that an application can communicate with a broker under the tested settings. It does not prove that the application implements the OPC UA PubSub payload carried on that connection.
Inspect a representative message and compare it with the receiving application's documented expectations. Check identifiers, field types, metadata handling, and the association between a message and its configured DataSet.
Separate a bridge from a native endpoint
An intermediary changes the architecture. If one component receives data through client/server communication and another publishes it through PubSub, the result is a bridged data path—not proof that every component implements native PubSub.
Document the responsibility at each boundary. Specify which component reads the source, which component creates the outgoing message, and which component owns the mapping when the source schema changes.
Separate live values from usable process context
A changing value is not the entire acceptance requirement. Depending on the interface contract, the consumer also needs a meaningful timestamp, quality indication, engineering context, or a defined response when the source becomes unavailable.
Write those requirements explicitly rather than assuming a successful demonstration preserves them. Where the source and destination represent these attributes differently, document the transformation and obtain agreement from the consuming application owner.
Does MQTT support mean OPC UA PubSub support?
No. MQTT support alone does not establish OPC UA PubSub support. MQTT provides messaging transport; OPC UA PubSub defines additional message structures and behavior that participating applications must understand.
For an MQTT-based design, inspect both layers. Verify broker connectivity and authentication separately from the OPC UA PubSub message mapping, encoding, identifiers, and metadata expected by the subscriber.
This distinction also prevents a misleading acceptance test. A subscriber receiving custom JSON containing a temperature value demonstrates custom message delivery, not automatically OPC UA PubSub interoperability.
Can an OPC UA client/server connection meet the requirement instead?
An OPC UA client/server connection is suitable only when the application requirement accepts that communication model. It is not an automatic replacement for an interface explicitly requiring PubSub.
Review what the consuming application actually needs: access to values through supported OPC UA services, or receipt of a specified published message. If the requirement changes, update the architecture and acceptance criteria before selecting an implementation.
Client/server avoids introducing a PubSub requirement when none exists. Its limitation is that it does not satisfy a mandatory PubSub interface merely by carrying equivalent process values.
What should a compatibility test demonstrate?
A compatibility test should prove the required interface and its operational behavior, not just show values changing on a screen. For a 2026 commissioning record, retain enough evidence to distinguish transport success from correct application processing.
Use a test checklist tied to the approved interface contract:
- Payload interpretation: Confirm that the receiving application interprets the intended fields and data types correctly.
- Metadata handling: Verify how the consumer obtains and uses the information needed to interpret published data.
- Source interruption: Disconnect the source and confirm that the consumer exposes the agreed unavailable-data behavior.
- Connection recovery: Restore the connection and verify the documented recovery behavior without assuming that missing messages are replayed.
- Schema changes: Change a representative field definition in the test environment and confirm that the resulting behavior is understood.
- Security rejection: Test an unauthorized connection or invalid credential under controlled conditions and verify the expected rejection.
Pass criteria should describe observable results. Replace vague statements such as successful integration with the exact behavior the receiving system must demonstrate.
FAQ
Is Cogent DataHub compatible with OPC UA PubSub in 2026?
Treat Cogent DataHub OPC UA PubSub compatibility as unconfirmed until release-specific documentation establishes the required Part 14 capabilities. Match the role, transport, encoding, and security requirements, then verify them in an interoperability test.
Does OPC UA support include PubSub automatically?
No. OPC UA client/server support does not automatically include OPC UA PubSub support. Require an explicit statement covering the PubSub features your interface needs.
Does MQTT connectivity prove OPC UA PubSub compatibility?
No. MQTT connectivity proves transport connectivity under the tested configuration, not support for OPC UA PubSub message structures. The receiving application must also interpret the required message mapping.
What should I ask before specifying Cogent DataHub for PubSub?
Ask whether the exact DataHub release supports the required publisher or subscriber role, transport mapping, encoding, metadata handling, and security configuration. Request documentation and an example matching the proposed architecture.
Can I use an intermediary if native PubSub support is not established?
An intermediary is an architecture option only when its required interfaces are independently verified. Document where conversion occurs and test the resulting data semantics and failure behavior.
Is JSON over MQTT always OPC UA PubSub?
No. Custom JSON over MQTT is not automatically OPC UA PubSub. Compatibility requires the applicable OPC UA PubSub message structure and behavior, not merely JSON syntax.
What evidence should I keep after an interoperability test?
Keep the release identifiers, endpoint configurations, representative messages, security settings, and observed acceptance results. The record should let another engineer reproduce the approved connection.
One last thing
A successful value transfer can still fail the interface requirement. Before approving a 2026 deployment, ask the receiving application owner to identify the exact message and behavior the system accepted.
If the answer is only that values appeared, the test has not yet established native OPC UA PubSub compatibility. Close that gap before the architecture becomes a commissioning problem.
