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.
Product Update
%20(1).png)
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 Route 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 runs in the opposite direction, 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 everything on your MQTT bus as ordinary OPC UA data: browsable, labelled, and writable where you allow it.
The Client Route is valuable, but it is ingestion. The Server Route 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 Route pulls device data up onto MQTT. The Server Route serves that unified bus 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. As devices start publishing, they show up for the plant's systems to browse without anyone editing a configuration or restarting anything. The data model grows as the plant grows.
Operator decisions survive a restart. 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.
.png)
%20(2)%20(1).png)