Demo with simulated data. Not client work.
Every number here is generated in your browser for an invented plant. None of it comes from a real plant or a client project.
Working demo · simulated data
A plant-floor dashboard you can try.
A live, read-only production dashboard for an invented plant. It runs in your browser on simulated data; none of the numbers come from a server.
Live demo
Three packaging lines, live, on simulated data.
Pick a line, or switch to the previous shift. The numbers follow the plant’s clock.
Demo with simulated data. Not client work.
Loading the demo dashboard…
What you’re looking at
Every minute belongs to one state.
Availability, the stop log and the timeline all come from one machine state model, so run, down, changeover and planned time always add up to the time elapsed in the shift.
The states the demo uses and where a real system would detect each one
State: Running
- Meaning:
- Producing, at or below the ideal rate
- Usually detected by:
- Running signal and a rising part counter
State: Down
- Meaning:
- Stopped when it was scheduled to run, with a reason
- Usually detected by:
- Running signal off, fault codes, counter idle
State: Changeover
- Meaning:
- Switching product or setup
- Usually detected by:
- Order change in the MES or an operator selection
State: Planned stop
- Meaning:
- Break or meal, excluded from planned production time
- Usually detected by:
- Shift calendar
- Availability
- Run time ÷ planned production time. Planned breaks are excluded; changeovers count as a loss.
- Performance
- Σ(units × ideal cycle time) ÷ run time, using each product’s ideal rate. Short stops land here.
- Quality
- Good units ÷ total units.
- OEE
- Availability × performance × quality: the share of planned time spent making good units at the ideal rate.
Shift boundaries follow the plant’s local time. A stop that starts at 13:50 and ends at 14:20 counts ten minutes against the day shift and twenty against the evening shift, and the stop log says so. More on these choices in our guide to plant-floor data in web dashboards.
How this would connect in your plant
Read-only by default.
Nothing in the cloud or on the business network opens a connection into the control network. Your controls team signs off on the design before we build, and anything that writes back to the plant is scoped separately.
Where each piece of the dashboard comes from: in this demo, and in a real plant
Piece: Line state and counts
- In this demo:
- Generated in your browser from a fixed seed and the clock
- In your plant:
- Read-only from the historian or an OPC UA server, through your industrial DMZ where you have one
Piece: Shift calendar
- In this demo:
- Three fixed shifts with planned breaks
- In your plant:
- Your shift calendar, with effective dates, e.g. a view in an existing plant database
Piece: Ideal rates
- In this demo:
- Invented, two products per line
- In your plant:
- Your ideal-rate table per product and line, maintained by your team
Piece: Stop reasons
- In this demo:
- Picked from a short invented list
- In your plant:
- PLC fault codes, operator entry or both, as agreed during scoping
See it on paper
The scope before it, the handover after it.
Two illustrative documents for the same invented plant. The demo goes further than the scope in three places: all three lines instead of Line 3 alone, the OEE breakdown and a reason for every stop.
- Illustrative sample · not client work
What a written scope looks like
- Illustrative sample · not client work
What you get at handover
Related:Manufacturing & industrial
Want a dashboard like this on your own data?
Start with a 30-minute scoping call. We'll talk through your lines, where the data lives and what a build would cover.