Edge and cloud, and the fast loop

Stamped runs two loops in two places. The slow loop runs in the cloud over minutes to weeks and is what exists today; the fast loop runs on a Plant BoxPlant-side computer for the fast loop (direction; D4) at the plant, in seconds, and is still direction. They share contracts but have different failure rules.

flowchart TB
    %% house-style: tour-edge-cloud
    subgraph box["Plant Box at the plant: seconds"]
        direction LR
        read["Fast read, 1 s, and data-quality gates"] --> twin["State estimate (twin)"]
        twin --> dec["Decision under a standing policy"]
        dec --> saf{{"Safety filter"}}
        saf --> wr["Writer: verify, limits, watchdog, read-back"]
        saf --> msg["Local display and operator message"]
    end
    subgraph cloud["Cloud: minutes to weeks"]
        direction LR
        ana["Analytics, MSPC, forecasts"] --> rx["Prescriptions and schedules"]
        rx --> led["Value ledger"]
        led --> upd["Reviewed model and parameter updates"]
    end
    plc["PLC and DCS, which stay in charge"]
    plc --> read
    wr -- "OPC UA write, allow-listed set points only" --> plc
    box -- "outbound sync: readings, twin state, write log, outcomes" --> cloud
    cloud -. "pulled by the Plant Box every 60 s: signed grants, parameters, models" .-> box

    classDef govc fill:#fff4d6,stroke:#c99a2e,color:#000
    classDef agentc fill:#e8f0ff,stroke:#5b7bd5,color:#000
    classDef loopc fill:#eef7ee,stroke:#4f9a4f,color:#000
    class saf govc

What runs where#

The split follows latency. Anything that needs an answer within a second, or must keep working through an internet outage, runs on the Plant Box: fast reads and buffering, data-quality gates and evidence labels on fast signals, state estimation, the predictive safety filter on the write path, standing-policy decisions and the writer. Everything else runs in the cloud: analytics, scheduling, the value ledger, model training and evals, and distribution of parameters and policies. Operator messages go out from the cloud because WhatsApp needs the internet, with a local Plant Box display as the fallback (D7).

The recommended Plant Box is a fanless industrial PC on Linux, with a customer VM as the fallback (D4). It is not the same as the edge agent, which only reads. Whether the twin runtime stays in Python or needs a compiled core depends on a 72-hour soak test with a heartbeat gate (D3).

The write path#

We designed write-back as an additive monitoring-and-optimisation channel, following NAMUR Open Architecture (NE 175). A change travels back toward core process control as a request, in the pattern of NE 178 Verification of Request: authenticate, authorise, verify, map, accept, then read back. The WriteRequestPlant Box write path request (direction; closure/action-intent.json retired) contract carries that state machine, and the writer accepts nothing else. We claim the pattern, not full NE 178 compliance (D17). First envelopes stay low-risk, such as utility set points and per-head trims.

Sync and failure rules#

Upstream, the Plant Box sends readings, twin state, the write log, actions and outcomes in batches, each with a per-stream sequence number. Ingest is idempotent, so a resend after reconnect is harmless, and the box deletes nothing until the cloud acknowledges it and the 30-day retention window has passed. Under back-pressure the write log and actions are resent first. If the backlog passes 24 hours, fast readings are downsampled before sync and marked so.

Clocks matter for writes. The Plant Box clock is disciplined by NTP, and an offset above 2 seconds flags readings and blocks writes until the clock is back in band. In every degraded mode, writes are the first thing to stop.

Go deeper: two loops · edge and cloud split · fast loop