Deployment scenarios · IT and OT kept apart
The hub outside the control network, gateways inside it.
Put the hub where IT wants it: the plant DMZ, your data centre or a private cloud. Gateways on the control network connect out to it, and business systems talk to the hub, never to a gateway or a PLC.
- Where
- The hub at L3.5 or L4, gateways at L3
- Install
- As Hub and edge gateways, with the hub’s public address and certificate names set
- Fits
- Sites with an IT/OT firewall or a zones-and-conduits design
The layout
Where everything sits.
- Proxus
- Your systems
- Reads machines
- Values, buffered by the sender
What you install
- The hub
- With Docker or Kubernetes, behind your reverse proxy if you use one, under its own path if needed. Set the address the gateways use and the names on its certificate.
- Certificates
- From the platform’s built-in certificate authority, or from your corporate one.
- The gateways
- As in Hub and edge gateways: Linux with Docker, one command each.
How it connects
- The firewall rule
- From the gateways’ network to the hub: port 7422 for the gateway link, and the hub’s web address while installing. Nothing from the hub to the control network.
- Business systems
- Read from the hub’s API and receive its deliveries. None of them needs a route into the control network.
- Users
- The hub’s web interface, through your proxy if you have one.
When something fails
- A firewall change blocks the link
- The gateways keep collecting and buffering, and catch up in order once the rule is fixed.
- 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
- Deliveries from a gateway
- A delivery runs on the gateway that reads the device, so its destination must be reachable from the control network. To keep everything behind the DMZ, let your systems read from the hub instead.
- In a cloud
- Give the hub a fixed address and open 7422 to your plants only.
- 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.
Other layouts
Layouts combine. These are the other six.
- Single server The hub and its built-in gateway on one machine next to the machines.
- Hub and edge gateways Edge Gateways next to the machines, one hub for the plant.
- Many sites, one hub Gateways at every plant, one central hub with one namespace for the group.
- High availability On Kubernetes: two hubs, a three-node message cluster, replicated databases.
- Air-gapped Installed from a package, licensed offline, no path to the internet.
- Siemens Industrial Edge Installed from Industrial Edge Management, running on one Industrial Edge Device.
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.
-
Scoping call
Equipment, protocols, sites and the systems the data has to reach.
-
Technical walkthrough
A working demo against a scenario that resembles your plant, not a generic tour.
-
Pilot plan
A defined first line or site, with the deployment and security questions answered up front.
-
Roll-out
The same templates bring the next lines and sites online.