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
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.
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
OPC UA PubSub
OPC UA PubSub over MQTT
Custom application messaging
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.
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.
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.
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.
Compatibility depends on more than the presence of a protocol name. These factors determine whether a proposed connection satisfies the interface contract:
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.
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.
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.
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.
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.
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.
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.
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:
Pass criteria should describe observable results. Replace vague statements such as successful integration with the exact behavior the receiving system must demonstrate.
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.
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.