A batch plant’s control system carries two decades of production know-how nobody ever wrote down. When the integrator who built it winds down, that knowledge has to come from the code itself.
An illustrative scenario — a composite of the situations we build for, not a customer reference.
A batch producer runs lines controlled by PLC programs written and modified over twenty years — largely by one system integrator, who is approaching retirement. The dosing sequences, hold times, interlocks and abort conditions encode the actual production knowledge: why this step waits, what really stops a batch, which parameters an operator may safely change.
The binder documentation describes the plant as designed. The code describes the plant as it runs. After twenty years of modifications, those are not the same plant — and only one of them is loaded in the controllers.
Every behaviour — hold times, interlock chains, abort conditions — is tied to the exact source line that proves it, with the verbatim quote kept in the model. A claim whose quote is not at its cited location is rejected automatically.
What the code proves and what is design-level structure are reported as separate tiers, never blended. You always know which kind of statement you are reading.
An automation engineer verifies the model against the evidence, resolves the ambiguities, and puts their name on the result.
When the program changes, the model is re-checked against the new code — the record stays current instead of becoming the next stale binder.
From a synthetic process & batch manufacturing system — we never show customer data.
Tell us what you run — an Orientation assessment takes days, not months.