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

Deployment scenarios · Several lines or networks

A hub for the plant, a gateway at each line.

Edge Gateways sit next to the machines and do the reading; the hub keeps the model, the history and the screens. Each gateway opens its own connection to the hub, so nothing on the control network has to accept one, and each keeps its data on disk while the hub is out of reach.

Book a demo All deployment scenarios
Where
The hub at L3, a gateway next to each line or cell
Install
The hub with Docker; each gateway with one command the hub generates
Fits
Plants with several lines, cells or network segments

The layout

Where everything sits.

L4–L5 Enterprise and cloud L3.5 Plant DMZ L3 Operations L1–L2 Control and machines Your systems ERP, MES, databases, cloud Proxus hub Namespace, historian, screens Edge Gateway Line 1 Buffering Edge Gateway Line 2 Buffering PLCs Line 1 Robots Line 1 Meters Line 2 MQTT sensors Line 2
  • Proxus
  • Your systems
  • Reads machines
  • Values, buffered by the sender

What you install

The hub
One server with Docker, or a Kubernetes cluster (see High availability).
Each Edge Gateway
A Linux machine with Docker, x86-64 or ARM (arm64, armv7). The hub generates the install command; the gateway creates its own key on its host and enrols with it.
On every gateway
The drivers, an MQTT broker for local subscribers, rules, functions, pipelines and deliveries to your systems. Configuration comes from the hub.

How it connects

Gateway to hub
Outbound only, to port 7422 over TLS, plus the hub’s web address while installing. The gateway checks the hub against the platform’s certificate authority.
Hub to gateway
Nothing. Configuration travels back over the connection the gateway opened.
Local subscribers
MQTT on the gateway, on 1883 or 8883 with TLS.
Users
The hub’s web interface on 8443.

When something fails

The link to the hub drops
Each gateway keeps reading, runs its rules and functions and serves its own MQTT broker. Values wait on its disk with their original time and reach the hub in order when the link returns.
A gateway stops
Docker starts it again. Its machines are not read in the meantime; the other gateways are not affected.
The hub stops
The gateways keep collecting and buffering. Screens, history and alarms in the hub are unavailable until it is back, then the backlog arrives.
A gateway is lost
Revoke it in the hub: its key stops working within seconds, and no other gateway shares it.

The limits

One gateway per set of machines
A gateway runs as a single instance. If it stops, its machines are not read until it is back; no second gateway takes over.
A restart during a hub outage
A running gateway rides out a hub outage. A gateway that is restarted while the hub is out of reach starts processing when the hub answers again.
Disk on the gateway
The buffer needs disk for its retention time at the gateway’s data rate: 48 hours by default, up to 30 days.
Licensed rate
Data above a gateway’s licensed rate is neither delivered nor buffered.

Other layouts

Layouts combine. These are the other six.

Next step

Place it on your own plant.

Bring a sketch of your networks and the machines you want to connect. An engineer places the hub and the gateways on it with you, with the firewall rules your IT team will ask for.

Book a demo Talk to an engineer

  1. Scoping call

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

  2. Technical walkthrough

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

  3. Pilot plan

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

  4. Roll-out

    The same templates bring the next lines and sites online.