T20: Capstone — A Complete Plant
Build a whole small factory from a specification, using everything in the track — and review it against a real checklist.
What you will build: a complete plant model from a written specification, then review it as you would review someone else's work.
Time: three to four hours. Do it in sittings.
You need: T01–T19 completed. This tutorial gives you a specification and gets out of the way.
The specification#
Riverside Beverages runs a small bottling plant. They want Infohub reporting for the plant manager, the shift supervisors, and a control room screen.
Plant structure#
Riverside Plant
+-- Utilities
| +-- Boiler House steam for the pasteuriser
| +-- Water Treatment mains water in
| +-- Power incoming electricity
+-- Production
| +-- Filler 1
| +-- Filler 2
| +-- Filler 3
+-- Quality
+-- Laboratory
Fillers 2 and 3 are identical to Filler 1 in every respect except their tags and design capacity.
What they measure#
| Area | Measures |
|---|---|
| Boiler House | steam flow, steam pressure, boiler temperature |
| Water Treatment | mains flow, cumulative consumption |
| Power | line power (for peak demand), cumulative energy |
| Each filler | bottle count, reject count, energy, machine state |
| Laboratory | Brix and pH, entered per shift |
What they want to know#
Plant manager, daily and month-to-date: production against target · OEE per filler · specific energy per 1000 bottles · water per 1000 bottles · cost per 1000 bottles · quality pass rate
Shift supervisors, per shift: production against shift target · downtime minutes with reasons · a stoppage log they can complete · lab results entry
Control room, live: each filler's state · current hourly rate · availability · anything out of specification
Constraints#
- Production day starts at 06:00; three eight-hour shifts
- Financial year starts in July
- Monthly production target is entered by planning
- Ideal rate and planned production minutes are entered per day
- Energy price is entered monthly
- Peak demand must be captured — the billing basis
- Fillers must be templated
- Everything must be built by script and re-runnable
How to approach it#
Do not start creating measures. Work in this order — it is the order the whole track has been teaching.
1. Design on paper first (30 minutes)#
- The folder tree, complete, including the empty areas
- Which model attributes each level carries
- Which structures repeat and therefore get templated
- The enumerations you will need
- The time schemes and shifts
- Which measures are manual
Half an hour here saves a rebuild. See Folder Structure Best Practices and Model Attributes.
2. Foundations#
Time scheme with hour offset 6 and month offset July. Shift scheme with three shifts. Enumerations for machine state, stoppage category and reason. Custom functions — SafeDivide, PercentOfTarget, AttrAsDouble, PerDay. Limits you know you will need.
3. Build Filler 1 completely, by hand#
Every measure, every calculation, its event schemes, its limits, its charts. Confirm the numbers are right — availability between 0 and 100, states reconciling to the interval, OEE in a plausible range.
Only then template it.
4. Template and instantiate#
Author the template in the Template view with attribute tokens in the tags. Set attributes on the three filler folders. Release, then instantiate. Verify one instance completely before the others.
5. Utilities and Quality#
Not templated — each is different. Boiler house, water, power (with the minutely peak demand chain), laboratory manual entries.
6. Plant-level rollups#
Site totals, plant OEE, cost per unit. Aggregate the quantities and recalculate the ratios — never average a ratio.
7. Three dashboards, one per audience#
Do not try to make one serve all three. Each has a different interval, density, and viewing distance.
8. Script it#
Rebuild the whole thing as a script, following T19. This is the step that proves you understood the model rather than clicked your way to it.
The review checklist#
When you think you are finished, review it as if it were someone else's work. This checklist is the useful part of this tutorial.
Structure#
- [ ] Folder tree mirrors the plant, not the historian or the org chart
- [ ] Parallel things look parallel — the three fillers are identical in shape
- [ ] Three to five folder levels, balanced
- [ ] No folder named
New,Temp,Copy, or a year - [ ] Metrics group related measures; none holds exactly one
Measures#
- [ ] Every measure has a unit, and the spellings are consistent
- [ ] Every measure has a format, and it suits the quantity
- [ ] No
%in a format on a value already in percent - [ ] Aggregation chains are contiguous — no skipped intervals
- [ ] Every totaliser chain has exactly one Counter, then Sum above
- [ ] Rates use Average; quantities use Sum; peak demand uses Maximum throughout
- [ ] Only one route to each interval — no measure derived two ways
- [ ] Minutely used only where genuinely needed
- [ ] Names read as a family: same base, interval as suffix
Calculations#
- [ ] Every division is guarded, or uses
SafeDivide - [ ] Null versus zero chosen deliberately, especially on ratios that get averaged
- [ ]
Period.Durationused instead of hard-coded interval lengths - [ ] Result units set from the arithmetic, not from habit
- [ ] Dependencies declared for everything the expression references
- [ ] No formatting inside expressions
- [ ] Period ratios recalculated from period totals, not averaged
Events#
- [ ] Every trigger has a sensible
For Periodhold time - [ ] Events close — none left open-ended
- [ ] State events reconcile to the interval length
- [ ] Duration measures use Active Duration
- [ ] Every categorical attribute is an enumeration
- [ ] A reason capture rate measure exists, with a limit
- [ ] Planned and unplanned are separable
Templates#
- [ ] Repeated structures are templated, not copied
- [ ] Tags use attribute tokens
- [ ] Attribute values match the source format exactly, including leading zeros
- [ ] Template released; instances verified individually
- [ ] No local edits to templated members
Visualisation#
- [ ] One dashboard per audience
- [ ] Every dashboard has a heading and states its period
- [ ] Colour comes from limits and enumerations, never hard-coded
- [ ] Red appears only where it means "act"
- [ ] Bar chart axes include zero
- [ ] No more than two axes per chart
- [ ] Every panel would change a decision if it were absent
Operations#
- [ ] Everything Deployed, nothing Different or Faulted
- [ ] Platform host name correct
- [ ] Freeze point set sensibly
- [ ] Retention settings decided, and backups outlive them
- [ ] Manual entry measures excluded from any purge
- [ ] Limits set where somebody would actually act
- [ ] Notifications few enough that people will read them
The script#
- [ ] Credentials from the environment
- [ ] Exit code checked after every step
- [ ] Instance verified after
--create - [ ] Instantiation count asserted
- [ ] Chart content asserted
- [ ] No hard-coded ids
- [ ] Honest summary and exit code
- [ ] Does not deploy
Then do the harder review#
The checklist catches technical faults. These questions catch the ones that matter more.
Show a dashboard to somebody who knows the plant but not Infohub. Ask them: what is this for? Is anything wrong right now? What period does it cover? What would you do about the worst thing on it? If they cannot answer all four in a minute, the dashboard needs work — and the question they stumble on tells you which part.
Verify one KPI by hand. Pick a day, get the inputs from their source systems, compute it yourself, and compare. Any difference is almost always period alignment.
Ask what happens when a source fails. Does the KPI go absent, or does it silently report a wrong number from stale inputs?
Ask who owns each manual measure. If the answer is "somebody in production", it will not be filled in.
Count how many notifications a supervisor would receive in a week. If it is more than a handful, they will filter them.
What the whole track has taught#
Looking back across twenty tutorials, the durable lessons are few:
The model is the value. Not the dashboards — the contextualised, calendar-aligned, correctly-aggregated numbers underneath them.
Get the shape right before the volume. Structure, then one good example, then repeat by template.
Retrieve once, derive everything else. Chains beat repeated retrieval on cost, consistency, and diagnosability.
Guard every division. It is the single most common way an Infohub model quietly loses data.
Choose the aggregation from what the source value is. Rate, quantity, register, or state.
Events describe what was happening. Anything with a start, an end, and attributes is an event.
Active Duration is the anchor that sums.
Ask the period its length. Never hard-code an interval duration.
Colour must mean one thing, driven by configuration.
Configuration is not activation. Save, then deploy — and watch for Different.
Manual data is irreplaceable.
Verify, do not assume. Assert outcomes, reconcile totals, check one value by hand.
Where to go next#
- Modelling in Flow Config — deeper on templates and federation
- Automation & the Config CLI — the audit recipes are worth running against any model you inherit
- Administration & Troubleshooting — the symptom index, for when something breaks
- Data Consumers & Integration — if Riverside becomes one of eight plants