Skip to content
Proxus 2.0.1 Licence and sign-in fixes after the 2.0 upgrade Release notes
Try free Book a demo

Platform · Architecture

Built like plant infrastructure, explained like a drawing.

Two tiers, one model, and a plan for the day the network fails.

Book a demo Deployment and security
Shape
One hub, many autonomous gateways
Configuration
Defined centrally, run at the edge
Offline behaviour
Gateways keep collecting and buffering without the hub
Scales from
One server to a multi-site fleet, same model

The whole system

Four layers, and what travels between them.

Field, edge, hub and consumers Equipment sends data through an edge gateway to Proxus Hub, then to Dashboards & systems. Deployment configuration travels from the hub back down to the edge. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals EDGE Proxus Edge Collect / evaluate / buffer PLATFORM Proxus Hub Namespace / history / access Dashboards &reports Inside Proxus Databases & cloud Optional destinations Business systems MES / ERP / QMS Configuration: hub to edge PLANT FLOORCONSUMERS Field, edge, hub and consumers Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Proxus Hub, then to Dashboards & systems. Deployment configuration travels from the hub back down to the edge. Deployment manifest Plant floor PLCs / CNCs / robots Proxus Edge Collect / evaluate /buffer Proxus Hub Namespace / history /access Dashboards &systems Built-in views +optional targets

Enterprise

Systems Proxus delivers into

  • MES / ERP / QMS

    business systems

  • Cloud & warehouse

    analytics platforms

  • BI tools

    where teams already work

  • Brokers & streams

    event consumers

  • AI assistants

    governed, permission-limited access

Hub

Model, history, screens and administration

  • Unified Namespace

    one address per signal

  • Historian

    telemetry and logs

  • Dashboards

    built in, same data

  • Reports

    scheduled, in platform

  • Orchestration

    deployment manifests

  • Access control

    roles and paths

Edge gateway

Configuration from the hub, buffer at the site

  • Collect

    poll and receive MQTT

  • Evaluate

    rules and anomalies

  • Functions

    your own logic

  • Buffer

    store and forward

  • Publish

    namespace and MQTT

Plant floor

Controllers, machines and meters

  • PLCs

    S7, CIP, MELSEC

  • CNC & robots

    FOCAS, MTConnect

  • Meters & SCADA

    Modbus, OPC UA

  • OPC UA servers

    existing estate

  • MQTT devices

    publish to the built-in broker

Data flows from equipment through the edge to the hub; configuration travels back to the edge and is never authored on the box. Dashboards and reports sit inside the platform. External systems are destinations, not prerequisites for seeing your data.

Division of labour

What each tier is responsible for.

What must survive an outage happens at the edge; what must match across sites happens centrally.

Each tier, item by item

The hub

Where the truth is defined.

  • Single source of truth

    Device profiles, rules, functions and delivery targets are defined once, centrally. Nothing is configured on a gateway directly.

  • Orchestration

    The hub decides which gateway runs which workload and hands it a deployment manifest: the current job list for that gateway.

  • Central history

    Telemetry from every gateway is collected and retained centrally, in a store built for time-series volume.

  • Management console

    One window into every connected site: configuration, live values, dashboards, reports and operational logs.

  • Health monitoring

    Heartbeats and metrics from every gateway, so a silent site is visible before someone notices the missing data.

The gateways

Where the work is done.

  • Acquisition

    Reads controllers, machines, meters and OPC UA servers over their own protocols, at the interval each signal needs.

  • Local execution

    Rules, anomaly detection and custom functions evaluate on the gateway, without waiting for the hub to answer.

  • Buffering

    What cannot be delivered, to the hub or to any outbound target, is held locally and written in order when the link returns.

  • Local publication

    The modelled namespace is published from the gateway itself, so plant-side consumers do not depend on the centre.

  • No local configuration

    A gateway keeps only its identity on the host; its devices, rules and functions come from the hub. Replacing one is a hardware task, not a rebuild.

The live topology: two plants, their gateways, the hub and the historian, then one plant selected.

The path a value takes

From a register to a decision, in ten steps.

Scroll: the drawing shows where each step happens.

  1. Hub

    Configure centrally

    Someone defines a device, a rule or a target in the console, and nowhere else.

  2. Edge Gateway

    Distribute to the gateway

    The change reaches the gateway, even one that was offline.

  3. Edge Gateway

    Start the workload

    The gateway starts the work on its job list.

  4. Edge Gateway

    Read the equipment

    Values arrive by polling a controller or over the gateway’s own MQTT broker.

  5. Edge Gateway

    Detect what changed

    New values go to the rules, the targets, or both.

  6. Edge Gateway

    Evaluate locally

    Rules and live anomaly checks run on the gateway itself.

  7. Edge Gateway

    Publish the modelled signal

    The value is published under its asset path, and in Sparkplug B where enabled.

  8. Your systems

    Deliver outward

    Your systems receive it; each delivery shows in the target’s status.

  9. Hub

    Store centrally

    The hub keeps the telemetry and the operational records.

  10. Hub

    Show it without a refresh

    Live values reach the console as the data arrives.

When the link drops

The part most architectures leave for later.

A gateway keeps reading and holds each value with its time, 48 hours by default, up to 30 days. When the link returns, the history has no gap.

Step through an outage

Online: every value reaches the history as it is read.

Deployment shapes

The same architecture, seven layouts.

All deployment scenarios
Technical details Governance decisions built into the platform, and how it is engineered

Governance in the architecture

Decisions that are structural, not settings.

  • One address per signal

    Signals are published under an ISA-95-shaped path (enterprise, site, area, process cell, equipment module, device, tag) so the same value has the same address at every site.

  • Permissions enforced server-side

    Access is checked in the service layer, not only in the interface. Bypassing the screen does not bypass the rule.

  • Operational logs stay readable

    Customer-facing logs carry a safe summary, severity, reason code, source and occurrence count. Repeated events are grouped rather than repeated.

  • Diagnostic evidence is separated

    Stack traces, absolute paths and raw payloads live in support bundles for the team investigating, not on an operator’s screen.

  • Query access is constrained

    Reporting and dashboard SQL paths enforce read-only, single-statement queries through one shared guard.

  • Alerts you can look back on

    Anomaly detection runs live at the edge. The trend workspace shows the stored alert moments, so a flagged deviation can be read against the history around it.

How it is built

One codebase, not a bundle of other products.

A lot of industrial platforms are an assembly: a flow tool, a dashboard tool, a broker and a database, packaged together and called one product. Every seam in that assembly is a version to reconcile, a process to supervise and a failure mode nobody owns. Proxus is written as one system, which is why the footprint at the edge stays small.

  • One gateway process at the line

    Drivers, rule evaluation, anomaly detection, its MQTT broker and every outbound client run in one gateway process, not as separate applications supervised together. A messaging container next to it holds the local buffer.

  • One script, two pieces

    A site needs the gateway process and the messaging container that holds its buffer, set up by one install script. Configuration comes from the hub. No database at the edge and no runtime to provision by hand, which is what makes an industrial PC a reasonable host.

  • Built for the hot path

    Binary internal messaging rather than JSON, an actor-based runtime, allocation-aware libraries and workstation garbage collection. Built on .NET.

  • Infrastructure only where it belongs

    The hub uses a transactional store, a columnar store and a durable message backbone, the things infrastructure is genuinely good at. The application layer above them is ours, not an assembly of other people’s applications.

These are architectural properties you can verify in a running deployment. We do not publish throughput or latency figures without the hardware, workload and measurement boundary that would make them mean something. Ask for a scoping call and we will size it against your own data rate.

Proven in production

Running in this shape, in production.

All deployments

An architecture call

Draw it on your own sites.

Tell us your sites and what is already there; an engineer replies with a drawing within one working day.

Already in place

We use your email to answer this check. Marketing emails only if you tick the box; no resale. Privacy notice

Draw it Live demo