Products · Plant Dashboard Server
Every device on one screen
One server on your network reads whatever your plant already has — controllers, weighers, meters, sensors, even cameras — keeps it in a proper database, and serves it to any browser on site. It only ever reads, so it can watch everything without being able to touch anything. Where a Factory Data Backbone is in place, it subscribes to that instead of touching a single device.
Read-only. On-prem. No cloud.
Live example
A weighbridge, on the web
One indicator on a TCP socket, one server, one database — and everyone from the gate to the office looking at the same day. This screen is one build; yours would be shaped around what your site actually needs to see.
58,320kg
| Plate | In | Out | Total in | Total out | Net | Status | |
|---|---|---|---|---|---|---|---|
| S412 BQK | 05:47 | 06:12 | 44,180 | 18,640 | 25,540 | Complete | Bridge · auto |
| XB 771 LD | 06:09 | 06:41 | 45,220 | 19,010 | 26,210 | Complete | Bridge · auto |
| S086 TRN | 07:31 | 08:04 | 58,320 | 21,470 | 36,850 | Complete | K. Ward |
| S933 MPV | 08:18 | 08:52 | 42,600 | 17,880 | 24,720 | Complete | Bridge · auto |
| XC 204 JH | 09:22 | 09:58 | 33,840 | 16,240 | 17,600 | Complete | Bridge · auto |
| S551 KQD | 10:14 | — | 16,820 | — | — | On site | Bridge · auto |
Live weight
Straight off the indicator, with the states the operator relies on before a ticket is written.
The whole day at a glance
Every weighing plotted, so a strange load is obvious instead of buried in a list.
A record that survives
Every movement in the database — searchable by plate, exportable to CSV, still there next year.
Representative screen built for this page. All plates, weights and names are fabricated.
Power monitoring
Watch the power bill being written
Electricity is one of the few big costs a factory can actually control — and the network charges you by your worst half hour, not just what you use. You cannot manage a peak you only discover on the invoice.
Site demand now
1,284 kW
Peak this month
1,510 kW
Power factor
0.96
Energy today
18.4 MWh
Out-of-hours baseload
214 kW
What the site draws at 2am with nothing running.
Catch the peak before it sets
Maximum-demand charges are set by one bad half hour a month. Watch demand live against your agreed limit and stagger heavy starts, instead of paying for the coincidence all year.
kWh per unit produced
Because the same database already holds production counts, energy becomes a cost per pallet, per tonne, per batch — a number a manager can act on, not a bill a month later.
Baseload and reporting
What the site draws at 2am with nothing running is usually a surprise. And when ESG or corporate reporting asks for energy figures, they come from metering — not an invoice divided by twelve.
Metering rides on what the plant already has — power meters in the switchboard, energy data from the drives themselves, or clip-on CT meters added without rewiring. It lands in the same database as everything else, which is the whole point.
Where it sits
This is not another HMI
Your HMI runs the machine. The Backbone connects the factory. This watches the plant. They are different jobs, and trying to make one do all three is how you end up with a panel nobody trusts and a report nobody reads.
Operator screens · WinCC Unified
Runs the machine
- Lives on the panel or the runtime PC beside the line
- Operators start, stop, set and acknowledge from it
- Tied to the control system it drives
Factory Data Backbone
Connects the factory
- Reads every machine once into one named tree
- Licensed, clustered broker with history kept
- Decides each line’s state for every screen
Plant Dashboard Server · this page
Watches the plant
- A standalone server app — opens in any browser, on any device
- Read-only by design — no write path back to any machine
- Fed by the Backbone, or reading devices directly on small sites
- Its own database: years of history, searchable, exportable
Most sites end up with all three. They are not competing.
Flexible
If it has a port, it can be read
Nothing on the floor gets replaced and nothing gets reprogrammed. A collector is written for whatever the device already speaks — and where a device speaks nothing standard, one gets written for it.
Controllers
Instruments & devices
Business systems
A live tile next to the numbers, so whoever is reading the screen can also see the bay, the yard or the machine the numbers came from.
A counting sensor on an IO-Link master, read over a REST call — turned into a live product rate and a running shift total.
The indicator streams weight over a plain TCP socket. The server reads it, decides when it is stable, and writes the ticket.
A packaged chiller with nothing but a Modbus port gets its temperatures, setpoints and fault codes trended like everything else.
Beyond the plant floor
An API in, and an API out
Devices are only half the picture. Any provider with a documented API can feed the same screens — and everything the server holds can be read back out by the systems your business already runs.
Data in · from any provider
If someone publishes an API, it can sit next to your plant data: electricity spot prices beside your demand curve, the weather forecast beside your chiller load, ERP orders beside the line rate, supplier and lab systems beside the batch record. The screens that pay for themselves are usually the ones that put a plant number and an outside number side by side — running the energy-hungry work when power is cheap needs both on one screen.
Data out · the server is a provider too
Everything the server holds is available over its own read-only API — so Power BI, Excel, corporate reporting or software you write yourself can pull live values and history without touching the plant network. Scheduled CSV and email reports and webhooks cover the systems that would rather be pushed to. Your data stays yours, in a database you can query, not locked inside a product.
Under the hood
Fed by the Backbone, or straight from the devices
With a Factory Data Backbone in place the server subscribes to the plant's one named tree and never touches a controller. Without one, it keeps its own collectors and reads devices directly. Either way it is a proper database on a machine that lives on your network.
Database, chosen to suit the site
PostgreSQL + TimescaleDB
The default. Relational records and years of time-series history in one place.
SQLite
A single small machine, a single file, nothing to administer.
InfluxDB
When the tag count and the sample rate get big.
Microsoft SQL Server
When the site already runs it and IT would rather not add another engine.
Runs on a small on-prem box or a VM on hardware you already have. No cloud account, no per-tag licence, no subscription to the data you already own. See how the Backbone feeds it →
Reliable
Built to be left alone
A dashboard is only worth anything if people believe it. That means it keeps running when a device does not, and it never lies about how fresh a number is.
Every connection is watched
Each device has its own collector with its own watchdog. If one falls over, it reconnects on its own and nothing else on the dashboard is affected.
A dropout does not lose data
When a link goes down the collector buffers and back-fills once it returns. The history stays whole instead of growing a hole at 3am.
Stale is shown, not hidden
A value that has stopped updating is flagged as stale rather than quietly left on screen. Operators can tell the difference between a steady reading and a dead one.
It cannot upset production
The server reads. There is no write path back to the PLC, so no dashboard, browser or report can ever move a machine — which is also what makes it easy to get approved.
It runs on your site
One small on-prem box or a VM on your existing host. No cloud dependency, so the internet dropping out does not blind the floor.
Backed up and boring
Scheduled database backups, a documented restore, and a service that starts itself after a power cut. Boring is the point.
How it goes in
Data first, screens second
Logging starts before anyone argues about layout — so by the time the screens are designed, there is already real history behind them.
01
Survey
We list what is on site and what each device can already give us — port, protocol, and what it knows. Most plants can hand over far more than anyone realises.
02
Connect & log
A collector per device, straight into the database. Data starts stacking up from day one, before a single screen is designed.
03
Design the screens
Screens built around the question each person actually asks — the yard wants a plate and a net weight, the manager wants the day.
04
Hand over
Documented, backed up, and yours. Reports and CSV exports on a schedule, plus new devices added later without rebuilding anything.
Tell us what you want to see
Send through what is on site — the makes, the models, whatever nameplate you can photograph — and we will tell you what can be read from it and what a dashboard would show.