Appearance
The Template Workspace
The full-screen workspace behind one placed engineered template: its live schematic, a scan simulation you can run, its generated control loops, signals, calculations and documents.
Which simulation? The Simulate view on this page is a client-side, PLC-style scan simulation of one placed unit, running in your browser. It is not the server-side biokinetic process simulation (ASM1/ASM2d/ASM3/ADM1, Takács clarifier) described under Simulation — different page, different solver, different question. See Which "simulation" this section is about.
Opening it
From a placed engineered template on a drawing:
- double-click the unit on the canvas, or
- select any part of it and use Open template workspace in the Template instance properties section.
The URL is /drawings/<drawingId>/units/<instanceId>, and the view you are looking at is kept in the URL as ?view=… — so a link can point at a particular panel.
The drawing must be open in the same tab. The instance lives in the drawing's own model in your browser. A workspace URL opened cold cannot reach a drawing that has not been loaded, and the workspace says so — "That template instance is not on this drawing" — with a link back.
The header
One line, left to right: back to the drawing, the unit's tag, its name, the template version it is pinned to, and its revision.
- The tag. There is no unit-tagging scheme on a placed instance yet. The badge shows a tag-like parameter when the template declares one, and otherwise the first block of the instance's own id — short enough to read, and unique enough to tell two stations apart.
- The revision. A fresh instance is Rev A. Every setpoint you edit in the workspace counts as a working change, and the header then reads Rev A + 3 WIP. Issuing a revision is not built yet, so there is no Issue button — a button that could not issue anything would be a lie.
No screenshot: the Engineered category shows "No templates published yet" in the demo tenant this guide is captured against, so this screen cannot be shown honestly here.
The nine views
A fixed menu down the left, the same nine items for every engineered unit, in the order an engineer works in — from what is this unit, through running it, to issuing its documents.
| View | What it gives you |
|---|---|
| Overview | The instance's identity and the unit's own headline figures |
| Simulate | The live schematic, setpoints, run controls, inflow, fault injection, a 3-hour trend, live facts and the alarm log |
| Control loops | The generated control graphs, the path taken this scan, a node inspector, and the loop's signals |
| Signals | The generated I/O schedule, its card sizing and the rule set's spare allowance |
| Calculations | The generated calculation sheet, the unit's own tables and its charts |
| Documents | The generated documents, their QA state, a changed flag and a PDF export |
| Validation | The run verdict (PASS / PROTECTED / WARN / FAIL) with its reasons, and the design findings that fired |
| Parameters | The answers the unit was placed with, and its editable setpoints |
| Versions | Not built yet — carries a Slice 2 badge |
Versions is listed rather than hidden, with a visible Slice 2 badge, so that an empty panel is never mistaken for a broken one. It says in words what will be behind it.
Three honest states
Opening the workspace, you may see one of:
- Opening the template workspace… — the engine is initialising and the instance is being read.
- That template instance is not on this drawing — a bad instance id, or a drawing that is not loaded in this tab. The workspace offers the way back rather than rendering an empty unit as if it were real.
- The workspace itself. The header and the menu paint first; the engineering stack — the resolved unit, its graphs, its calculations and the simulation — streams in behind them, so a view may briefly say "Resolving the unit…".
Overview
The instance's own facts — template slug, template version (or not pinned), revision, instance id, and how many drawing elements the unit owns — followed by the unit's headline figures, which each unit states for itself. For the pumping station those are the arrangement, the control method, the duty point, the station capacity, the rising main, the motor rating, the number of design findings and the number of control loops; the other units state the equivalents for what they are. The unit pages list them.
The design findings count is a link: select it to open the Validation view, which lists the findings it counts.
If the engineering stack could not be built, this view says so and shows the reason, rather than showing a blank unit.
Simulate
The run, and everything you need to watch it.
No screenshot: the Engineered category shows "No templates published yet" in the demo tenant this guide is captured against, so this screen cannot be shown honestly here.
The live schematic
Top left: the unit's own P&ID, drawn live. It is per-unit by nature — a wet well is not a dosing skid — so each unit registers its own schematic. For the pumping station it draws the wet well with its water line, the level marks the setpoints sit at, the level transmitter and its reading, the two floats, one body per installed pump with its riser, the rising main with its flow meter, and the station's mode in words.
This is a schematic drawn for the run, not the P&ID from the drawing. It is the only form that can carry live level, speed and fault state.
The run loop
| Control | What it does |
|---|---|
| Run / Pause | Starts and stops the run. The view opens running. |
| Step | Advances exactly one scan, paused. |
| ×1 ×10 ×60 ×300 | Speed multiplier — simulated seconds per real second. The view opens at ×60. |
One scan is one second of simulated time. Real elapsed time multiplied by the speed accumulates into whole scans, with a cap per animation frame, so a tab returning from the background cannot run a thousand hours at once.
The clock is shown as day n · hh:mm, counting from 06:00 on day 1.
The scan order is fixed, and it is what makes a run reproducible:
- due faults applied, expired faults cleared;
- instruments sampled, per-scan flags reset, outputs zeroed if the supply is dead;
- the PLC scan — the generated control graphs in declared order, skipped entirely when the PLC is not energised;
- plant-side outputs the hardwired circuits write are reset;
- the hardwired circuits — which run even when the PLC is dead, and that is the whole point of generating them as graphs;
- the plant integrates one step;
- the outstation — alarms and call-out, after the plant has moved, so an alarm reflects this scan's physics;
- metrics, trends, history.
Setpoints
Top right: the instance's setpoints, grouped by the loop that owns them. The grouping is not a hand-kept list — every generated control node declares the setpoint it owns, so a setpoint belongs to the loop whose node reads it, and the panel quotes that node's own label back at you when the value changes. A setpoint no node claims falls into a trailing group rather than disappearing.
Editing a setpoint:
- writes it back to the placed instance;
- applies it in place to the record the running scan is reading, so the change takes effect on the next scan without restarting the run;
- counts a working change, which the header totals as + n WIP;
- re-derives everything downstream of it — the calculation sheet, and any document whose generated content quotes it.
The same setpoints are also listed on the Parameters view.
Inflow
Five sources, chosen from a dropdown:
| Source | What it drives the unit with |
|---|---|
| From the inlet port (DWF, diurnal) | The inlet port's own declared figures, on the diurnal profile |
| Constant at DWF | A flat dry weather flow |
| Diurnal day | The 24-factor diurnal day |
| Diurnal day with a storm | The diurnal day plus the design storm |
| Random walk with a random storm | A random walk, with a storm arriving at random |
Fault injection
A dropdown of the template's own fault catalogue, already filtered to the instruments this configuration has — so a station with no flow meter is never offered "FT-101 fails". A fault is a single failure of one device, applied to the scan state and cleared again, with no knowledge of the control logic: the control graphs see only what the plant reports — a frozen reading, a float that never closes, a pump that takes no feedback — so what you are testing is the logic, not the injector.
One fault at a time, by default. Injecting a second fault clears the first, unless you turn on Allow more than one — at which point the run is explicitly a double-jeopardy run, and its result is not a single-fault result.
Catalogue sizes, before the filter to what is fitted: pumping station 13, flow balancing tank 21, aeration blower set 22, flow to full treatment control 25, storm tank 32. The unit pages list the families each one covers.
Trend · last 3 h
A stacked trend over one shared time axis, with the panels the unit declares. The pumping station's three are level (with the LT reading dashed over it), flow (inflow and the flow meter) and pumps running; the balancing tank's are level, flow and mixers running; the blower set's four are header pressure, demand against delivered, speed and blowers running; the flow-to-full-treatment unit's four are chamber level, forward flow, spill and device position. Reference lines mark the setpoints and the hardwired levels. Injected faults are marked on the axis.
Live facts and the alarm log
Bottom right. The facts block is the unit's own — titled Station, Vessel, Blower set, Inlet works or Storm tank — and each unit decides what belongs there. The pumping station shows the clock, the level, in/out flows, pump states, starts per hour and spill volume; the others show the equivalents for what they are.
The alarm log below it holds the last 40 entries, newest first: the simulated time, a priority badge (P1 red, P2 amber, P3 informative), the alarm text, and (cleared) on an alarm that is no longer active. "None raised yet." when nothing has.
Control loops
Where a run is inspected rather than watched.
Loop tabs across the top, one per generated graph. For the pumping station: wet well, selector, each pump, floats, rising main, outstation. The other units declare their own — the balancing tank, the blower set and the flow-to-full-treatment unit have eight graphs each; the storm tank has thirteen. Nothing on this page is authored: the graphs, the signal rows and the document references are all generated, so removing a float or choosing a direct-on-line starter over a variable-speed drive changes the tabs, the nodes, the signals and the prose together.
No screenshot: the Engineered category shows "No templates published yet" in the demo tenant this guide is captured against, so this screen cannot be shown honestly here.
The graph is drawn with the path taken this scan highlighted, from the scan trace.
The node inspector shows, for the node you select:
| what it did this scan | ran · TRUE · FALSE · not reached, with its live status text |
| the setpoint it owns | editable here, exactly as on the Simulate view |
| force | auto / force true / force false, for condition and timer nodes |
| breakpoint | pause the run when this node fires |
| signals | the tags it reads and writes, and the graph it hands over to |
| documents | the sentences of the generated control philosophy that cite it |
A forced node's outcome is overridden after evaluation, so a forced timer keeps accumulating.
This view does not open running — a graph redrawing sixty times a second while you read a node is not inspectable. Run and Step are here because a force and a breakpoint are meaningless without them: set a breakpoint, press Run, and the run stops on the scan that node fires and selects it.
Below the graph: the generated I/O schedule, filtered to the selected loop.
Signals
The unit's generated I/O schedule — every point, with:
Tag · Description · Type · Signal · Loop · Equipment · Termination (card · channel) · Hardwired
and beneath it the card sizing table — Type · Used · With n% spare · Channels per card · Cards — where the spare percentage is the rule set's, not a number anyone typed here.
Every row exists because a piece of the configuration exists: a level transmitter brings one analogue input; each pump brings five digital inputs, two digital outputs, one analogue output and two analogue inputs; the panel is sized from the totals plus the rule set's spare. That is what makes the reference pumping station exactly 37 points — 20 DI, 6 DO, 8 AI, 3 AO — and what makes a fourth pump 47 without anyone editing a schedule.
No screenshot: the Engineered category shows "No templates published yet" in the demo tenant this guide is captured against, so this screen cannot be shown honestly here.
Selecting a row selects the loop the point belongs to and the tag itself; the Control loops view then rings every node that reads or writes it. Highlighting the point on the drawing is not available from here — the drawing is a different page with its own selection model — so the row offers the loop and says so, rather than pretending to point at a P&ID it cannot see.
Calculations
The unit's generated calculation sheet. Each row prints its label, its formula or basis, its value and its check — OK, Check or — — and the sheet names the rule set and its version at the top, with a count of rows still to check.
Not one number on this page is computed by the page. The rows come from the unit's calculation generator, and the checks come from the same results the design findings are raised on.
The sheet is generated at the setpoints in force, not the ones the unit was dropped with. Edit Duty start on the Simulate view and the operating volume here follows it; nothing is cached against the drop.
Each unit also contributes its own tables and its own charts — a wet well needs a pump curve, a blower needs a fan curve, and some units need neither — so the chart set is per-unit and is listed on the unit pages.
No screenshot: the Engineered category shows "No templates published yet" in the demo tenant this guide is captured against, so this screen cannot be shown honestly here.
Documents
Four documents are generated from the placed instance today, for every engineered unit:
- I/O schedule
- Control philosophy
- Calculations
- Alarm schedule — listed with the set and exported like the others, but not QA-tracked or change-flagged.
Each carries a QA state — draft, checked or approved, set with Mark checked and Approve — and a changed flag. Export PDF prints the selected document, in the browser, from what is on the page. Export CSV (I/O schedule and alarm schedule) downloads the table, and Export document set downloads all four PDFs plus the two CSVs in one click.
No screenshot: the Engineered category shows "No templates published yet" in the demo tenant this guide is captured against, so this screen cannot be shown honestly here.
The changed flag is the point
A document flags as changed only when its own generated content differs from what it said when the workspace opened — not whenever anything anywhere is edited. Each document is rendered to text, hashed, and compared.
Edit Duty start and the control philosophy and the calculations flag — the philosophy quotes the setpoint, and the calculations derive the operating volume from it — while the I/O schedule does not, because not one of its points mentions a level. That asymmetry is the feature: a system that cleared every approval on every edit is a system whose warnings you learn to ignore.
The same comparison drives QA: a mark remembers the content it was given to, so an approval survives exactly as long as the document does.
What the baseline is, honestly
No issued revision is stored yet, so "the last issued revision" is stood in for by the content as it was when this workspace opened. The view says that in as many words rather than implying a revision that does not exist.
What is not here
The other documents of the full set — the user requirement specification, the cause and effect matrix, the materials list, the factory-acceptance sheets and the hazard findings — are not built, and neither is the tender pack. A tender pack would be a server export running these same generators, and the server holds no copy of these documents today, so nothing here offers one. The export prints a single document from this page.
Parameters
Two blocks:
- Answers — the parameters the unit was placed with, read only. Re-answering them means regenerating the drawing, which is not built yet.
- Setpoints — the same editable setpoints as on the Simulate view, as spinners and switches, writing straight back to the instance.
Validation
Reached from the menu, or from the design-findings count on Overview. It has two parts.
Run verdict. After you have run the simulation on the Simulate view, Validation shows a badge for the run so far, on a four-level ladder from best to worst:
| Badge | Means |
|---|---|
| PASS (green) | The run stayed within its design envelope. |
| PROTECTED (blue) | The run stayed safe, but only because a protection layer independent of the PLC acted. |
| WARN (amber) | Nothing was breached, but an injected fault raised no alarm (a latent fault), or the equipment started more often in an hour than the unit allows. |
| FAIL (red) | The run breached containment, or ran the plant in a damaging state. |
The levels are checked in that order from the worst down, so a run that both breached and used a protection layer is a FAIL. Under the badge the view lists the reasons for this run — for example "breached containment by 3.2 m³" or "no alarm raised: latent fault" — and how long the run has been going and whether a fault was injected. The verdict is computed by the same function the automated fault suites use, so the badge and the suites cannot disagree about what a run means.
The verdict is a snapshot of the run as it stood when you left the Simulate view: the simulation only runs while Simulate is open. If you have not run the simulation yet, Validation says so and asks you to run one rather than showing a verdict.
Design findings. A table of every design finding the unit's rule checks raised for this configuration — the list behind the count on Overview — with each finding's id (such as D4), its severity (fail, warning, advisory or info), its message and the calculation rows it is based on. If none fired, the view says so. Findings are a property of the configuration, not of the run, so this list is there before any simulation.
Not here yet: the single-fault suite, the random stress summary and the library's configuration-test record are still release gates run as automated tests, not something you start from Validation.
Versions
Carries a Slice 2 badge and says what will be behind it: the pinned template version, an upgrade preview, and issued revisions with their parameter diff. Working changes are counted in the header meanwhile.
What we could not verify from the code
Everything on this page is read from the implementation, and the models behind it are covered by a large automated test suite. But nobody has recorded watching one of these units run in a browser, so:
- Frame rates, how the trend looks in motion, and how the schematic animates are not described here. A run at ×300 is bounded per frame by design, but what that feels like has not been observed.
- The workspace is a full-screen layout with grid breakpoints around 1100 px. How it behaves on a narrow window has not been observed.
- The Validation view's verdict badge and findings list are covered by component tests; nobody has yet recorded watching a run's verdict change on screen in a browser.
- Setpoint edits are written back to the placed instance in the open drawing. Exactly how and when that reaches the server has not been verified here; treat the drawing's own save behaviour as the authority.