SCADA dashboard: what the owner should see

Most SCADA dashboards are built by an engineer for an engineer: hundreds of tags, mimic diagrams, pressure and temperature trends. For commissioning that is right. But the owner opens the dashboard with a different question — is everything fine, and is the site earning — and finds no answer on that screen. Within a week they stop opening it, and an expensive system becomes one technician's tool. Here is what belongs on the owner's screen and what does not.

Two screens, not one for everyone

The engineer needs detail: every register value, signal history, the controller's error log. The owner needs state and money. Squeezing both into one screen produces a dashboard nobody finds convenient. What works is two layers: a home screen for decisions, and a separate engineering layer you drill into once it is clear what to look for and where.

Five questions the home screen answers in ten seconds

What is not working right now? A list of devices out of service, and how long each has been down. Not "all green / some red", but specifically: which bay, since what time.

Is this data fresh? Next to each site, when the last data arrived. A green status received three hours ago is not green, it is unknown. A site with no link should look exactly like that, not like "all good".

What did each device earn? Revenue yesterday and today per device, not one total per site. A device that brought in noticeably less than its neighbours on the same traffic is the first place to look.

Does the money reconcile? The gap between starts, payments and receipts as one number per device. Zero stays quiet. Anything else is highlighted.

What is already being handled? Every alarm has a status: seen, taken by whom, closed. Otherwise three people see the same fault and nobody goes.

What to remove from the home screen

Raw sensor values without thresholds, mimic diagrams for decoration, charts nobody acts on. The rule is simple: if a number on the screen cannot change any decision the owner makes, it belongs in the engineering layer. Every extra element takes attention away from the five that matter.

Alarms people believe

A dashboard that turns red ten times a day for no reason teaches people to ignore red. So an alarm should fire on a state that persists, not a single spike; duplicates should merge; a dropped link should be its own event type, not "everything failed". And the channel should match the urgency: urgent to the phone, the rest to a morning summary.

A phone, not a control room

Owners rarely sit in front of a monitor. The home screen has to read on a phone: the same five questions, no horizontal scrolling, no tiny diagrams. A morning summary that arrives on its own is more useful than a dashboard you have to go and check.

Access and security

The owner does not need to control equipment from the dashboard, only to see it. Control stays with people who have the right role, and every action is logged. The equipment itself never faces the internet directly: the dashboard reads data through a gateway rather than exposing Modbus to the outside.

Frequently asked

Can an owner dashboard sit on top of our existing SCADA?

Often, yes, if the existing system exposes its data. The owner's screen is then a separate layer reading the same data without touching the engineering side.

How many indicators belong on the home screen?

As many as it takes to answer five questions: what is down, is the data fresh, what each device earned, does the money reconcile, what is already being handled. Everything else goes one level down.

Why was our "green" site actually down?

Most often because the dashboard showed the last known state without the time it was received. The site lost its link and the screen kept saying "normal".

Do we need a dedicated monitor or control room?

For the owner, no. A phone and a morning summary are enough; a control room is for operations with a shift that responds around the clock.