Demo Plant
Coming soon: a bottling plant that really produces, wears, fails and gets repaired, inside MaestroHub. Enable it into an empty workspace and MaestroHub reads it like any plant.
- Status
- Not part of release 3.0
- Who enables it
- A platform administrator
- What it takes
- 5 connections and 3 pipelines
- For
- Demos and education, never production
The Demo Plant is in development and testing and is not part of release 3.0. This page describes it as it is being built, so names and steps may change before release.
The plant starts when it is enabled and publishes continuously from then on: 73 readings a second, around the clock. Enable it only on an instance used for demos, training or evaluation.
What the plant is
A soft-drinks plant in Trabzon with two filling lines, a mixing hall and an energy centre.
- Line 2 and Line 3 fill 2.5-litre PET bottles: a syrup tank, two pumps, a filler, a capper, a labeller and a palletizer on each. Line 2 changes over to its second pump by itself; Line 3 waits for a technician to switch it in.
- The Mixing Hall blends syrup in numbered lots, pasteurizes it and keeps it in a buffer tank. One transfer pump refills both lines' tanks, so every refill comes from a known lot.
- The energy centre raises steam for the pasteurizer, counts the gas it burns, and makes the compressed air the lines use.
Around them run the plant's business systems:
- MES: production orders, stops, alarms, syrup lots and their transfers.
- CMMS: work orders, raised by the plant, by an operator, or booked.
- ERP: equipment, products, spare parts by lot, what is fitted where, and suppliers' recalls.
- HR: three crews rotating through three shifts, with dated qualifications.
Like a real plant before MaestroHub, it is a set of silos. Its PLCs send bare integers at addresses such as DB104.DBD4, with no names and no units. Each system keeps its own tables, and none of them knows what the others know: the MES does not know who was qualified, the ERP does not know which machine runs worse, the CMMS does not know which order was running. MaestroHub's pipelines give it context: see Where its data lands.
Everything comes from one running model, so the systems agree with each other. A pump's vibration, its alarm, the line's stop and the work order about it carry the same fault. The bottles filled match the syrup used, and the energy meters match the machines' work.
Enabling it
Only a platform administrator can enable, stop or remove the plant. Everyone else sees the Demo Plant pages read-only, and each control they cannot use says why.
Before you start:
- The instance runs the Demo Plant module (
modules.demoplant.enabled: true, see Configuration). - The licence includes the Demo Plant.
- You have an empty workspace: no connections and no pipelines. Create one first if you need to.
Then open Demo Plant in the rail, choose Enable the demo plant, pick the empty workspace and confirm that the instance is not production. Enabling takes about half a minute; the page shows each step.
The plant starts there and then, the way connecting a real factory today would: it has no history to load. Its PLCs send from that moment, and its MES, CMMS, ERP and HR start empty and fill as it runs. The lines are already working that day's orders, released by the MES at 06:00. The plant never runs ahead of the real clock. Orders and shifts are summed up from the first one that starts after the plant was enabled, since an earlier one has no counters to subtract.
Its topics keep their records as long as any topic does: a day by default.
The plant then sets up the workspace through MaestroHub's own API, as an agent named after it:
| What | Created |
|---|---|
| Connections | One MQTT connection to the plant's broker, and one REST connection each to its MES, CMMS, ERP and HR |
| Pipelines | DemoPlant signals: one MQTT trigger per PLC, turning each raw integer into its signal by the plant's tag map, live from enable. DemoPlant business systems: reads every system's tables from where it left off and places each row on its line or machine, keeping the order, lot and crew timelines. DemoPlant summaries: sums up every order and shift. Three of the evaluation licence's ten pipelines |
| Topics | Everything under mHv1.0/<workspace>/trabzon/ |
| Dashboard | DemoPlant Trabzon, the plant at a glance, built only from what its pipelines put in the UNS (see Its dashboard) |
| Plant model | The lines, halls, machines, what feeds what, and a binding from every machine property to its topic, when the licence includes the plant model |
| App | App Studio's Line Pulse, when App Studio (Beta, a paid add-on) is licensed and running |
Its connections, functions, pipelines and dashboard carry the label source: demo-plant, so any list that filters by label finds them. Its topics carry none, since the UNS keeps no labels on a topic; they are all under trabzon/.
The agent's token is revoked as soon as the import is done; the plant keeps no MaestroHub credential. The broker and the REST API have their own credentials, generated for this plant and supplied to the connections at import.
The signals pipeline runs once per reading: with the default tick of one second, the plant's 73 signals make it run 73 times a second. It keeps no execution history of its successful runs (its persistence level is none), so it does not flood Execution History. Failed runs are still kept, with their error, and its metrics count every run.
Where its data lands
Everything lands under mHv1.0/<workspace>/trabzon/, in three levels of context.
1. Readings get their meaning
The plant's broker publishes each reading as a PLC gateway would: a raw integer at its address, trabzon/<plc>/<address>, for example trabzon/plc_l2/DB104.DBD4 with {"v": 780, "ts": "…", "q": "good"}. The signals pipeline knows every address from the plant's tag map. It divides a measurement by its divisor (780 ÷ 100 = 7.8 mm/s), turns a state word into its name (1 is running), and stores the value under the machine's name, at the time the PLC stamped:
| Part | PLC | UNS path |
|---|---|---|
| Line 2 | plc_l2 | filling-hall/line-2/<machine>/<signal> |
| Line 3 | plc_l3 | filling-hall/line-3/<machine>/<signal> |
| Mixing Hall | plc_mh | mixing-hall/blending/<machine>/<signal> |
| Energy centre | plc_ut | utilities/energy-centre/<machine>/<signal> |
2. Records land on their line or machine
The business pipeline reads each system's table from where it left off and publishes every row as a record of its own, at its own time, on the line or machine it belongs to. A row is published again when the system changes it, for example a stop when it starts and again when it ends.
| Table | Read from | Lands on |
|---|---|---|
| Orders | MES | <line>/mes/orders |
| Stops | MES | <line>/mes/stops |
| Alarms | MES | <machine>/alarms |
| Syrup lots | MES | mixing-hall/blending/mes/lots |
| Syrup transfers | MES | <line>/mes/transfers, the line the syrup fed |
| Work orders | CMMS | <machine>/work-orders |
| Parts issued, received | ERP | <machine>/parts, erp/receipts |
| Recalls | ERP | erp/recalls |
| Shifts | HR | hr/shifts |
| Qualifications | HR | hr/people/<person> |
Stops and alarms carry the order, shift and crew the MES recorded when they began.
From the same records the pipeline keeps three timelines, each entry at the moment it began:
<line>/context/order: the order running on the line, from its start to its end;<line>/context/lot: the syrup lot feeding the line;context/crew: the shift and crew at work, and who is in it.
3. Orders and shifts are summed up
The summaries pipeline publishes one record per order and per shift on each line, at its end, from the first that starts after the plant was enabled, to <line>/summaries/orders and <line>/summaries/shifts. Each record holds the bottles and rejects (from the line's counters at the window's two ends), the energy and the energy per bottle, the stops and their minutes, the syrup lots used and the crews at work. It summarizes only up to where the readings are stored, so a summary is never made from half the data.
Its dashboard
DemoPlant Trabzon, under Dashboards, is an example of what to build on your own plant's data. It reads only the UNS: the signals the signals pipeline stores, the records the business pipeline places on lines and machines. Each panel opens with its finding in a sentence, worked out from the data in its time range:
| Panel | What it answers |
|---|---|
| Line speeds, power, tank levels | The lines now |
| Orders | The order each line is working, how far it is, and when it finishes at the pace it has kept |
| Where the lines lose time | Every machine's state side by side, so a stop is seen where it starts |
| Time in state | Each filler's and capper's availability, its biggest loss, and whether the capper stops on its own |
| Pump health | Vibration against the ISO 10816 zones and the plant's alarm and trip limits, with the moments a pump alarmed |
| Syrup tanks | Each tank's level and its refills by syrup lot; a tank falling with no refill coming is projected to the level its pump cavitates at |
| Quality | Product temperature against its 6 °C limit, beside the reject rate from the filler's counters |
| Energy | Each line's power, shaded where it filled nothing, and its energy per bottle |
| What happened | The MES's stops, the alarms and the CMMS's work orders on one time axis, with how long each repair waited |
| Alarm noise | Alarms by machine and code, split by whether they cleared within a minute |
Its custom panels are ECharts code you can open and change in the panel editor. Remove deletes it with the rest.
The plant's pages
The plant belongs to a company, Black Sea Beverages Ltd., and is worked by the people on its HR roster, plus a plant manager who appears only in its story. The company and what its people say are written for the demo. Every event, time, order, crew, lot and repair on these pages is read from the workspace's UNS, so what you see is what MaestroHub stored.
- Overview, before the plant is enabled, introduces the company, a few of its people and the chapters it will run through, with when each would first come, and lets you choose a role to follow. While a restarted plant rebuilds its time since it started, it shows how far it has got. Once it runs, it is a shift board: the shift being worked and who is on site, and a card per line with its order, its progress and when it finishes at the pace it has kept, what needs attention (a stop, an open alarm or repair), its syrup lot and its last order. Below, the Mixing Hall and the energy centre in words. Beside the board, What happened here lists the chapters that have happened so far, and Coming up the next ones; it links to the plant's dashboard.
- The story tells each chapter from its records, the last time it happened: what happened, in order, with the order and crew the MES recorded and who was on shift. It says how often a chapter has happened and when it comes next; one that has not happened yet says when it comes. A chapter seen only in readings (a frozen transmitter, a silent meter) points at the readings to look at. A platform administrator can Make it happen now; everyone else sees why the button is off. People shows each person's job, their day, and the chapters that fell on their crew.
- Live plant draws the plant as it runs: the Mixing Hall feeding both lines, each line from its tank through its pumps, filler, capper and labeller to its palletizer, and the energy centre's steam and air. Every machine is coloured by its state with its value under it, an open alarm sits on the machine, and a stopped line's flow stands still. The few machines the drawing leaves out (valves, meters, transmitters) are listed under it. Select a machine for its panel: its readings and records in the UNS, the chapters it plays a part in, and where its numbers come from on its PLC. Below, what is happening in the plant: alarms raised and cleared, work orders opened, started and closed, lines stopping and running again, and orders finished.
- Signals and systems opens with From silo to sentence: the last time the pump ran dry (or, before it has, when it will), first as each system knows it (the MES's stop, the CMMS's work order, the ERP's bearing and its recall, HR's crew), then as one sentence that only the UNS can give. Below that it follows one signal from its PLC address into the UNS, and shows where each table lands and what MaestroHub adds.
- Setup shows how the plant is connected: each connection and pipeline MaestroHub built, with its job and what it carries, and their health (connections, failed runs, signals live). Reading connection and pipeline health needs permission to read the instance's monitoring; without it, Setup says so.
What happens in it
The plant is not a steady state. It runs through these incidents on a loop that starts when it is enabled, so there is something to see from the first minutes. Each comes from a cause in the plant and leaves its trace in every system it touches. A platform administrator can also make any of them happen now, from The story; the plant's records say who did.
| When, after enabling | What happens | Where you see it |
|---|---|---|
| From the start | P-301 was installed misaligned. Its seal fails every ten days or so of running; an operator raises a work order, the seal is replaced, and it fails again | Repeated seal work orders on one pump; syrup lost from T-3 |
| 10 minutes, then daily | V-15's position switch flickers for an hour | Dozens of POS_MISMATCH alarms, raised and cleared, while nothing on Line 2 changes |
| 30 minutes, then daily | F-2's product cooling drifts warm until the repair booked six hours later | Product temperature above 6 °C, rejects rising with it, HIGH_PRODUCT_TEMP |
| 1 hour, then daily | TT-11, after the pasteurizer, freezes for two hours | One value repeated, still marked good |
| 2 hours, then daily | CP-3 jams a minute at a time, a dozen times an hour, until the repair booked six hours later | Line 3 runs behind its capper; the MES records no stop and no fault |
| 3 hours, then every third day | T-1's level control sticks. Hours later P-101 runs it dry, cavitates and trips, and Line 2 stops until the pump is repaired | The fault, the alarm, the stop and the work order share one id |
| 5 hours, then daily | EM-L3 goes silent for an hour | A gap in Line 3's energy |
| The first night, then every three weeks | Crew C is on nights, and its technician's pump qualification has lapsed. At 23:00 P-301's bearing fails and nobody on site can repair it | Line 3 stands until the morning shift's technician comes in at 06:00; the work order says who started it, and when |
| 2 days | The supplier recalls bearing lot L2607-B, the oldest in the stores, which the first pump repair was fitted with | ERP: the recall names a lot; the parts on each machine say which pump carries it |
Questions it answers
No single system in the plant can answer these; the UNS can, from the records and timelines above, once the incident has happened. MaestroHub's own tests answer the first four this way.
| Question | Where the answer is |
|---|---|
| Which order and crew were on Line 2 when P-101 tripped? | The CAVITATION stop on filling-hall/line-2/mes/stops, and filling-hall/line-2/context/order and context/crew at its start |
| Which machine runs with a bearing from the recalled lot? | The lot in erp/recalls, found among the parts on the pumps, such as filling-hall/line-2/p101/parts |
| Why does P-301 keep leaking? | Its SEAL_LEAK work orders on filling-hall/line-3/p301/work-orders, again and again, and never an ALIGNMENT one |
| Why did Line 3 stand all night? | P-301's work order, started at 06:00 by the morning shift's technician; context/crew (crew C); the technician's lapsed PUMP_MECH in hr/people/E-1024; the stop on filling-hall/line-3/mes/stops |
| Which order used the most energy per bottle? | <line>/summaries/orders |
| Which crew loses the most time to stops? | <line>/summaries/shifts |
Stopping, resuming and removing
Stop pauses the plant. Resume brings it back: its business systems catch up the time it was stopped, as if it had kept running, and its PLCs send again from the moment it resumes. If MaestroHub restarts, the plant comes back as the same plant: it is rebuilt from its seed, its start and everything booked or made to happen through it. A plant that has run for weeks takes a little while to rebuild; the Overview shows how far it has got.
Remove deletes everything the plant created: its pipelines, connections, dashboard, topic tree, plant model and app, and its agent. The workspace is empty again.
Running it elsewhere
A platform administrator can download the plant's bundle from Setup. It is an ordinary MaestroHub bundle: import it into any MaestroHub that can reach the plant, and supply the broker password and the API token when the import asks for them. The file never contains either.
Configuration
The module is off by default. Its settings, under modules.demoplant:
| Setting | Default | What it is |
|---|---|---|
enabled | false | Runs the Demo Plant module |
brokerAddr | 127.0.0.1:21883 | Where the plant's MQTT broker listens. If the port is taken when the plant is enabled, it takes the next free one |
apiAddr | 127.0.0.1:18080 | Where the plant's REST API listens. A taken port is handled the same way |
advertiseHost | 127.0.0.1 | The host MaestroHub's connections use to reach the plant |
tick | 1s | How often the plant's PLCs send a reading, from 1s to 60s, dividing a minute. A plant keeps the tick it was enabled with, since it is rebuilt on it after a restart; a new value applies when the plant is next enabled |
Ports
The plant keeps the ports it took when it was enabled, because its connections point at them. Every restart opens the same ports again. If another program has taken one in the meantime, MaestroHub still starts: the plant alone fails, and its Overview names the port. Free the port and press Resume, or remove the plant and enable it again to choose free ports.