Data paths · network and computers
From the control cabinet to the GPU server
Where the cables run, where the data arises, where it is buffered — and at which two places a model computes: at the edge in milliseconds, in the data centre overnight. The paths are labelled with the numbers this plant produces.
Measured values. Continuous operation. The controllers are sampled every 250 ms, the edge device publishes only changes — resulting in about 125 values per second that land in the historian. Everything flows in one direction: upwards.
Intervention. The rare path back: an approved setpoint command goes as Sparkplug DCMD to the edge device, which writes it to OPC UA. It passes the same firewall in the opposite direction and hits one of 21 writable process points. This is the only process write path; the separate model rollout writes no process values.
Training and delivery. At night the GPU server reads a 14-day window from the historian — as a block, not a stream. If the new model passes evaluation against held-out data, it goes into the registry as a signed artefact; the edge device pulls it over its own initiated TLS session. If it fails, the old one stays in service.
Forecast. Expansion stage 2. The model at the edge calculates the remaining life of the saw blade from motor current and cut counter and publishes it every 20 s — over the same line as every other value. The point ends in the control loop, in the proposal list. It does not turn off onto the write path.
Click a component
What runs on which link
| Link | Protocol | Cycle | Volume | Direction |
|---|---|---|---|---|
| PLC → edge | OPC UA | 250 ms | 628 variables | Subscription — the controller reports of its own accord |
| Band saw → edge | Modbus RTU/TCP | 1 s | 15 registers | Query — this machine reports nothing on its own |
| Edge → broker | Sparkplug B | 1 s | ~125 values/s | changes only; on disconnect the edge device buffers |
| Broker → historian | MQTT | ongoing | 11 GB / 2 days | append-only, nothing is overwritten |
| Historian → GPU | SQL, read-only | at night | 14-day window | Block, not a data stream. The GPU server never sees the plant. |
| Registry → edge | signed artefact | rare | a few MB | only after passing evaluation; version is recorded in the ledger |
| Edge → control loop Expansion stage 2 | Sparkplug B | 20 s | 1 value + band | Forecast as a finding — it takes the path of every measured value and ends in the proposal list, not at the controller |
| Control loop → PLC | DCMD → OPC UA | after approval | 21 points | only process write path to the PLC; no model rollout |
Throughput and database size measured on 23 August 2026 on the running plant.
What lies on the forecast link
A network diagram shows cables and keeps quiet about the cargo. On this link a single quantity runs: how much longer the saw blade will last. It is worth the effort because on this machine wear and quality are the same thing — visible only at different times. The current rises as the blade goes dull; the scrap shows it only once the part has already been sawn.
One blade life · band saw ZS-100
calculated from the plant model
Both quantities run linearly with wear in the model — the lines are not drawn simplified but calculated that way. Source: sim/zuschnitt/saege.py and sim/common/machine.py.
Changed too early
15 min
That is how long the saw stands still for a blade change. Plus a blade that would still have lasted. Whoever changes early to be safe pays for that every time — and never sees what they have given away.
Changed too late
3,6 %
Scrap on the worn blade instead of 0,6 % on the fresh one — six times as much. Plus 18 % longer cycle time because the dull blade cuts more slowly. Both accrue before anyone notices.
Today · without a model
342
At 90 % wear the machine reports BladeChangeDue. That is a fixed threshold, not a finding: it knows neither the material nor the order and reports at the same point for every blade.
Between the two costs lies a point, and that is what the model looks for — not the end of the blade. It moves no manipulated variable, it moves an appointment. What the forecast looks like is on Model; what a saved hour is worth is on What it delivers.
Where the computing happens
Inference belongs at the edge, training in the data centre. Whoever puts both in the same place gets either a plant that is blind without a network, or a GPU server in the control cabinet.
At the edge · milliseconds
Inference on the edge device
A fully trained, quantised model. It computes in under 50 ms, needs no GPU and above all no network: if the connection to the plant network drops, the forecast keeps running and the edge device buffers. A plant that loses its assistance during a network outage is not accepted on the shop floor.
In the data centre · hours
Training on the GPU server
Runs at night, on the history — not on the live stream. The server has no connection to the plant and needs none: it reads a 14-day window from the historian and writes an artefact back to the registry.
In between · the gate
Evaluation decides on delivery
A newly trained model is checked against a held-out window. If it is worse than the running one, it is not delivered. The same logic as the trial run in the control loop, one level up.
Never
No model in the write path
Inference at the edge produces findings, not commands. The path to the controller leads for it too through gate, approval, trial run and watchdog — and through the same firewall through which nothing else may come in.
OT security architecture as its own demo track
ZenFactory is also a test bench for the work of an OT Security Architect. The deeper pages turn this into its own demo track: architecture, controlled write path and resilience behaviour can be explained separately and are reachable from the navigation.
Zones · conduits · DMZ
Develop architecture
Control network, OT-DMZ and IT/Analytics are separate zones. Broker and historian-facing components sit logically in the DMZ, not with the controllers.
Governed write-back
Take responsibility for architecture
The process write path is deliberately narrow: 21 writable points, Policy Gate, human approval, canary, watchdog, rollback and ledger. Model rollout is a separate artefact path; no model gets direct PLC write access.
Audit · operation · risk
Communicate architecture
Every path is visible: measured values upwards, model training from the historian, findings into the control loop, setpoint commands only in a controlled way back. That makes risks explainable.
| Security question | ZenFactory evidence | Boundary |
|---|---|---|
| May IT access OT directly? | No: data flows upwards through edge, broker/historian and AAS. | The public showcase is a recording, not live access. |
| Who may write? | Only the defined write path via Sparkplug DCMD → Edge → OPC UA, with Policy Gate in front. | The band saw remains connected read-only via Modbus. |
| What happens with wrong proposals? | Policy rejection, Human Approval, Canary, Watchdog and Rollback are separate states. | LLM/AI does not provide authoritative safety approval. |
| How is what happened proven? | Ledger entries are hash-chained and record proposal, gate, approval, execution and effect. | The showcase verifies hashes; signing keys remain in the OT zone. |
| How is an outage controlled? | Edge degraded mode, buffering, backfill, validation and data-loss metrics are visible. | Outage buttons change only simulation or demo state, not real infrastructure. |
What of it runs in production today
The topology above is the picture for a real plant. In this demo, every building block runs on one machine: eight services and two containers, broker and database on 127.0.0.1. No switch, no firewall, no edge device in a control cabinet. That changes nothing about the paths — the protocols, the directions, the process write path and the separate model-artefact path are the same. It does change the numbers: latencies are unrealistically good, because nothing travels over a real network.
| Component in the diagram | Today | In a plant |
|---|---|---|
| PLCs and plants | simulated, but with a real OPC UA server | existing controllers, unchanged |
| Serial converter | not present — the simulated saw speaks Modbus/TCP directly | Device server on a DIN rail, RS-485 to Ethernet |
| Managed switch, VLAN | not present — everything on one computer | separate OT network, no route into the office network |
| Edge device | two processes on the same computer | fanless industrial PC in the control cabinet |
| Firewall and OT-DMZ | not present | one port into the DMZ, no direct access into the OT network |
| Broker, historian, control loop | running — exactly what this page is served by | Broker and historian-facing services in the OT-DMZ; control loop behind Policy Gate |
| AI inference, forecast link | Expansion stage 2 · interface exists | Model in the control cabinet, finding every 20 s into the proposal list |
| GPU server, training, registry | Expansion stage 2 · planned | a computer in the data centre, busy at night |
Expansion stage 2 is drawn dashed: AI inference at the edge, training, evaluation and model registry. The docking point for it is built and secured by tests, the model is trained — only operation in the control loop is still outstanding. Everything else in this picture runs and can be checked on these pages.