Comparison · OPC middleware
Tunnelling OPC safely is a solved problem. It is not the same problem.
Cogent DataHub, Matrikon and Softing solve something specific and solve it well: getting OPC data across network boundaries without DCOM, bridging OPC DA to OPC UA, and exposing it to other protocols. If that is your problem, buy that. It is not what a data layer does.
- What it is
- OPC middleware: OPC tunnelling and gateway software, from Skkynet (Cogent DataHub), Honeywell (Matrikon), Softing
- What Proxus is
- An industrial data platform: collect, model, govern, store, deliver
- Honest summary
- Excellent at moving OPC across networks safely. A different job from modelling and storing it.
- Your options
- Keep the tunneller at the network boundary and put Proxus on the safe side, or let Proxus read the devices directly where it can reach them. Both paths are below.
Give them their due
What OPC middleware is genuinely good at.
A comparison that only lists the other product's weaknesses is a sales sheet, not a decision aid. These are real strengths, and some of them are reasons not to buy Proxus.
-
DCOM problems, permanently solved
OPC DA tunnelling without DCOM configuration is the reason this category exists. Anyone who has spent a day on DCOM permissions understands the value immediately.
-
Deep OPC standards work
DA, UA, A&E bridging, redundancy and protocol conversion, from vendors who have specialised in this for decades.
-
Small, predictable and proven
These are focused products that do one thing without asking you to adopt a platform. In a conservative plant, that is a feature.
-
Often already in the architecture
Many sites already run one for remote access or vendor segregation, and it works.
Attribute by attribute
Where the two actually differ.
Both columns are filled in. Where OPC middleware is ahead, the row says so.
-
Primary job
Proxus
Collect, model, govern, store and deliver industrial data.
OPC middleware
Move and convert OPC data safely across networks and protocol boundaries.
-
Protocol reach
Proxus
Native drivers for 66 protocols across 30 vendor and standard families, including OPC UA, plus MQTT.
In the docs: Protocol reachOPC middleware
OPC-centric. Some products add PLC connectors (Softing dataFEED) or web screens (Cogent DataHub WebView); the focus remains transport and conversion, not modelling and history.
-
Data model
Proxus
Signals modelled into an asset hierarchy with units, quality and asset context.
In the docs: Data modelOPC middleware
Point-to-point mapping. A tag on one side becomes a tag on the other.
-
History
OPC middleware
Logging options to databases in some products; not a historian with a retention policy.
-
Dashboards and rules
OPC middleware
Some products add web screens and scripting (Cogent DataHub WebView); dashboards and rules are not the core of the category.
-
Governance
Proxus
Role and namespace-path permissions across every consumer, including AI clients.
In the docs: GovernanceOPC middleware
Connection-level security, which is what tunnelling requires.
-
Where it sits
Proxus
Between the equipment and every system that consumes its data.
OPC middleware
Between two networks, or between two protocol worlds.
Proxus figures come from the current build's own driver and target inventory. OPC middleware figures come from the vendor's published material, linked at the end of this page. Nothing here is measured on a benchmark neither party has agreed to.
Choose OPC middleware
When we are not the answer.
- The problem is genuinely OPC transport: DCOM, a firewall boundary, or DA-to-UA bridging.
- You need a small, focused component rather than a platform, and the architecture around it is settled.
- A vendor requires segregated OPC access and a tunneller is the cleanest way to give it to them.
Choose Proxus
When the shape of the problem fits.
- Once the data has crossed the network, something still has to model, store and deliver it.
- Devices that have no OPC server at all are part of the scope.
- The same values are needed in several systems, in a consistent shape.
- Access has to be governed per signal rather than per connection.
If this column describes you:
Bring the devices that have no OPC server to a demoNot either/or
How they are used together.
-
Tunnel first, model second
Where a tunneller already carries OPC across a boundary safely, Proxus consumes the OPC UA endpoint on the safe side and models what arrives.
-
Cover what OPC does not reach
CNCs, robots and small controllers without an OPC server are read natively by Proxus, alongside the tunnelled OPC sources.
-
Keep the network boundary intact
Nothing in this arrangement requires opening a new path through the firewall the tunneller was bought to protect.
Sources
Last checked against vendor material: October 2026.
Products change. If something on this page is out of date or wrong, tell us and we will fix it, including when the correction favours OPC middleware.
Questions
Proxus and OPC middleware: short answers.
- Do we still need OPC tunnelling with Proxus?
- Where a tunneller already carries OPC across a network boundary, keep it: Proxus consumes the OPC UA endpoint on the safe side, and no new path through the firewall is needed.
- Can Proxus read devices that have no OPC server?
- Yes. CNCs, robots and small controllers without an OPC server are read natively, alongside the tunnelled OPC sources.
- Is Proxus an OPC tunnel?
- No. If the problem is genuinely OPC transport (DCOM, a firewall boundary or DA-to-UA bridging), a focused OPC middleware product is the better choice.
Proven in production
Running in production at these sites.
-
Manufacturing
Digital factory data management
MEXT Digital Factory
Read the case study -
Mining & energy
Mining, fleet and solar on one platform
Kaltun Mining
Ask us about this deployment -
Energy
Grid monitoring at the edge
CK Enerji
Ask us about this deployment -
Manufacturing
Unified Namespace with Oracle ERP
Pilenpak
Ask us about this deployment
Next step
Keep the tunnel, cover what it cannot reach.
Tell us where your OPC boundary sits and which devices have no OPC server. In thirty minutes we show where Proxus goes on the safe side and how those devices are read directly.
- 01
Scoping call
Equipment, protocols, sites and the systems the data has to reach.
- 02
Technical walkthrough
A working demo against a scenario that resembles your plant, not a generic tour.
- 03
Pilot plan
A defined first line or site, with the deployment and security questions answered up front.
- 04
Roll-out
The same templates bring the next lines and sites online.