Grab a chair before proceeding.
You’re about to access the full Coreflux platform. Some people report weakness in their knees upon first contact.
You’ve been warned.
%2520(1).png)
Product Update
Ask a SCADA vendor whether their product can read MQTT. The answer is usually: buy a gateway.
So the plant ends up running two systems. An MQTT broker for the devices, and a separate OPC UA server for the plant software. Both licensed, both secured, both patched, both audited. The same values duplicated across them, an integration project to keep the two agreeing with each other, and a standing question about which one is right when they do not.
That is the two-stack wall. Almost everyone with a real unified namespace ambition hits it.
OPC UA is the language plant software uses to ask a system what data it has and what that data means. Values arrive organised and labelled, browsable much like folders on a shared drive, with security built in from the start. Practically every SCADA system, HMI, historian and modern PLC speaks it. When plant software needs to discover and understand data rather than just receive it, OPC UA is how it asks.
MQTT answers a different question: how do I move a value from anywhere to anywhere, quickly, at scale, without either side needing to know about the other.
Plants need both answers. Until now that meant running both systems.
Coreflux has been able to talk to OPC UA equipment for a while. A Connector went out to devices and servers, read their data, and put it on the MQTT bus. This release is not a bigger version of that. It reverses the direction of initiation, and that difference is the whole story.
Coreflux now hosts the OPC UA server itself. SCADA systems, HMIs and PLCs connect to Coreflux and see the topics you expose as ordinary OPC UA data: browsable, labelled, and writable where you allow it.
| Before (Client Connector) | Now (Server Connector) | |
| Who starts the conversation | Coreflux goes out to a device or server | The plant's systems come to Coreflux |
| How data flows | Inbound-led: Coreflux pulls device data onto the bus, and can write back per tag | Outbound-led: Coreflux serves the topics you expose, and clients can write to the tags you declare |
| How the plant sees Coreflux | One more leaf hanging off someone else's system | The system everyone else points at |
| What it delivers | Ingestion, help getting data in | Convergence, the source everyone reads from |
The distinction is direction of initiation, not one way versus two way. Both Connectors can write. What changes is who opens the connection, and that turns out to matter more than it sounds.
The Client Connector is valuable, but it is ingestion. The Server Connector is what lets Coreflux be the single source of truth the whole plant reads from. That is the difference between a broker with good connectors and a convergence layer.
Together they close the loop. The Client Connector pulls device data up onto MQTT. The Server Connector serves the topics you choose back out over OPC UA. Same governed data, both directions, no second system in the middle.
Your SCADA can read the bus with no changes on its side. No custom drivers, no adapter software, no vendor conversation. It connects to Coreflux the way it already connects to any OPC UA system, and browses a structure that mirrors how your data is organised.
Control flows both ways. An operator adjusting a setpoint in SCADA writes it back through Coreflux and onto the bus, within limits you set. The same governed path serves data out and takes instructions in.
New equipment appears on its own. Point a mapping at a topic pattern and every device matching it shows up for the plant's systems to browse as it starts publishing, with no configuration edit and no restart. These auto-discovered nodes are read-only. Declare a tag explicitly for anything a client needs to write.
Operator decisions can survive a restart. With persistence enabled, a setpoint someone entered is still there afterwards, while live measurements pick straight back up from the bus rather than showing a stale snapshot.
One product to buy instead of two. One system to secure and patch instead of two. One place the truth lives.
The same data is both the MQTT source and what OPC UA clients see, with a clear ownership model: one value, one owner, two protocol faces. There is no synchronisation job, because there is nothing to synchronise.
System integrators who have been quoting an MQTT broker plus an OPC UA server as two line items on every proposal. Manufacturing and energy customers with a real unified namespace ambition who kept hitting the two-stack wall. Anyone whose SCADA vendor's answer to "can it read MQTT?" was "buy a gateway".
Security policies, data types and the full set of configuration options are in the technical documentation.
%20(1).png)
%20(1).png)