Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes
Try free Book a demo

Platform · Integrations

Deliver to the systems you already run.

Modelled data goes out to databases, message brokers, cloud services and business systems, per target, with the transport strategy each one needs, and a delivery record you can check.

Book a demo See all destinations
Delivers to
18 destination systems: databases, message brokers, cloud IoT services and REST endpoints
Per target
Its own strategy: pass-through on every read, or only on change
Reliability
Queued at the gateway while a target is unreachable and written in order when it returns
Visibility
Status, last success, last failure and last error per target, in the product

Inside Proxus

Where each target stands, in the product.

Recorded in the product, cursor and all · 0:19Simulated plant data

One model. Your existing systems.

Deliver modelled industrial data to databases, cloud services and business applications.

Model once, deliver to your systems Equipment sends data through an edge gateway to Unified Namespace, then to Your enterprise stack. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals 02 / EDGE Proxus Edge Collect / evaluate / buffer 03 / PLATFORM Unified Namespace Modelled industrial signals Your enterprisestack Destination 01 / PLANT FLOOR04 / CONSUMERS Model once, deliver to your systems Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Unified Namespace, then to Your enterprise stack. 01 Plant floor PLCs / CNCs / robots 02 Proxus Edge Collect / evaluate /buffer 03 Unified Namespace Modelled industrialsignals 04 Your enterprisestack Destination

What it solves

What teams run into without it.

  • A pipeline per consumer

    Each new system means another script, another credential and another thing to maintain at 3am.

  • Silent delivery failures

    The dashboard looks fine because it reads a cache; the warehouse has been missing rows for a week.

  • Duplicated transformation

    The same scaling and renaming logic re-implemented slightly differently in every integration.

What you get

Built in, not bolted on.

  • Outbound channels per device

    Choose which signals go where, without rebuilding the collection layer for each destination.

  • Transport strategies

    Pass-through for every reading, or on-change to move only what actually changed.

  • Message brokers

    Kafka, RabbitMQ, MQTT and Sparkplug B for event-driven consumers.

  • Databases

    PostgreSQL, SQL Server, Oracle, MySQL, Firebird, ClickHouse, InfluxDB and TDengine.

  • Cloud services

    AWS IoT Core, Azure IoT and REST endpoints, from your own network outward.

  • Delivery visibility

    Status, last success, last failure and last error per target, and how many messages are queued at the gateway while it is unreachable.

What this enables

What the capabilities add up to, in practice.

  • Add a consuming system without adding a collection layer
  • Match transport to each target instead of flooding all of them
  • Prove a feed is intact before the consumer complains
  • Change where data goes without touching how it is collected

Coverage

Where the data goes

Modelled signals delivered to the systems your business already runs. MES, ERP and QMS connect through their database, REST or message interfaces.

All integrations

Trademarks belong to their respective owners and are shown to indicate supported equipment and systems.

Proven in production

Feeding the systems these teams already run.

All deployments

Questions

What teams ask before the first call.

Ask something else
Do targets read from Proxus, or does Proxus push?
Proxus pushes to configured targets, which means delivery is initiated from inside your network. Targets can also read through the API or the namespace where that suits them better.
What is the difference between pass-through and on-change?
Pass-through sends every reading the gateway takes. On-change sends only when the value actually changes. Choose per target: a historian may want everything, a cloud warehouse usually does not.
How do we know a delivery actually happened?
Each target shows its status, last success, last failure and last error in the product, and while it is unreachable, how many messages are queued at the gateway. A broken feed surfaces before the consuming team notices it.
Can one signal go to several systems at once?
Yes. A signal is defined once and can be attached to any number of outbound channels, each with its own format and strategy.
What if our target system is not on the list?
Most systems accept data through a database write, a message broker or a REST endpoint, all of which are standard targets. Anything genuinely bespoke can be handled with a custom function.

Continue

Two numbers set your price: the gateways you run and the data rate they carry. See pricing

Next step

See it delivering into your own stack.

Bring the target system and the signals it is missing. We will show the path from the controller to your table, topic or service, including what happens when the link drops.

Book a demo Talk to an engineer
  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.