Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes

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 reach

    OPC 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 model

    OPC middleware

    Point-to-point mapping. A tag on one side becomes a tag on the other.

  • History

    Proxus

    Built-in telemetry historian with retention and query access.

    In the docs: History

    OPC middleware

    Logging options to databases in some products; not a historian with a retention policy.

  • Dashboards and rules

    Proxus

    Included, with edge rule evaluation and anomaly detection.

    In the docs: 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: Governance

    OPC 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.

Not 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.

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.

  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.