IoT & Traffic Systems · Capability · Visibility
Control-centre dashboards that put exceptions before decoration.
GA Applications designs role-based control-centre dashboards for road-equipment operations: an operator's queue, a coordinator's plan, a maintainer's work list and a manager's portfolio view — all reading the same validated records. Stale data is shown loudly, every figure can be drilled to its source, and command controls appear only where separately authorised.
For control-room and operations teams who are tired of screens that impress visitors and inform no one: a good dashboard is the one that is nearly empty on a good day.
- Gateway G-07 silent 26 min — unassigned, escalates 08:52; last known state kept and labelled offline.
- VMS T-03 voltage low — owned by R. Demo, acknowledged 08:40, on-site ETA 09:15.
- Permanent VMS V-108 data stale since 07:58 — not shown as healthy; source check requested.
- Estate counts (illustrative): 142 normal, 3 warning, 1 fault, 2 stale, 1 offline.
Four screens, four jobs, one set of records
Each role gets a screen shaped around the decisions that role actually makes — not one dashboard with the widgets rearranged. Switch between the demonstration views; all four read the same underlying registry and alert records.
Operator
Decision supported: what needs my attention right now? The queue leads: unacknowledged alerts with escalation countdowns, then acknowledged work in progress, then stale and unknown states that need a source check. Estate counts sit below, subordinate. The operator acknowledges, annotates and escalates — the screen contains no command affordances, because the operator role has none.
Shift handover is a view, not a verbal download: open items with owners, ages and next steps, filterable to exactly what the incoming operator inherits.
Coordinator
Decision supported: who and what goes where, today and this week? Forward deployment windows with readiness gaps; unassigned alerts awaiting dispatch; maintainers' current commitments. Assignment happens here, and every assignment writes back to the same record the operator watches — no side channels, no contradictory screens.
The coordinator's exception view is deliberately separate from the plan view: today's fires and next week's gaps never compete for the same pixels.
Maintainer
Decision supported: what am I fixing, and what do I need to know before I arrive? A work list, not a map of dots: assigned jobs ordered by agreed priority, each with the asset's fault history, past photos and parts notes attached. Field capture — checks, photos, restoration confirmation — happens on the same screen flow, so evidence is filed where everyone else will read it.
Works on a phone in gloves: large targets, high contrast, offline-tolerant capture that queues evidence when coverage drops and files it on reconnection.
Manager
Decision supported: is the operation healthy, and where should money and attention go next? Readiness by fleet, alert-ownership health, repeat-fault leaders, evidence completeness — trends over weeks, built from the same records the field uses. Every figure is defined on screen and drills to the records beneath it; a number without a definition is not displayed.
No vanity metrics: the manager's view reports measured distributions with their definitions and periods, and says so. It promises nothing it cannot trace.
Design rules that survive contact with a real control room
Exceptions before decoration
The first screen region belongs to items needing a decision. Ambient visualisations, if they exist at all, load after and rank below. A dashboard that looks identical on a bad day and a good day has failed its only job.
Stale data is loud
Age is displayed beside values, and data past its freshness window changes style — dashed, muted, labelled — so nothing old can masquerade as now. Freshness rules are agreed per source and shown, not buried in documentation.
Everything drills to source
Alert → asset → timeline → the original record with its source interface and timestamp, plus attached documents and photos. If a figure cannot be traced, it is removed. This is what makes the screen defensible in a review.
Commands are gated or absent
Most deployments ship with zero command controls. Where an authorised action exists — approved in writing, on supported equipment — it follows preview → confirm → result: see exactly what will be sent and to what, confirm as the right role, then see the outcome including failure. A demonstration like this site never includes a live command path.
Detect, degrade, fallback, recover
The dashboards themselves are monitored like the equipment they show. When something in the chain fails, the screen degrades honestly rather than freezing in a plausible-looking lie:
- Detect — source silence, validation failures and platform faults are detected on their own schedules and surfaced as banner states, not hidden in logs.
- Degrade — affected regions of the screen are restyled and labelled: “data from this source is 45 minutes old” beats a quietly stale green dot.
- Fallback — agreed manual modes are documented on the screen itself: who to call, what the field crews do while the view is degraded, how records are kept meanwhile.
- Recover — restoration is verified against source data and declared on screen with a time, so nobody wonders whether the fix “took”.
What these screens are not
They are not an official traffic authority interface, and are designed to be visibly distinct from one. They are not a control system: monitoring and command are separate capabilities, and command is absent unless separately authorised. And they are not a replacement for procedures — when the screen and the procedure disagree, the procedure wins, and the discrepancy becomes an item to fix.
Accessibility is operational, not cosmetic
Keyboard-complete operation, visible focus, state by more than colour, tables alongside every chart, and layouts that hold from a phone to a video wall. A control room that excludes people excludes responders.
Keep exploring
Control-centre dashboard questions
Can operators control equipment from these dashboards?
Not by default — most deployments contain no command controls at all. Where an authorised action is justified, it requires written owner approval, supported equipment, role-based permissions and a preview → confirm → result flow with full logging and tested fallback. It is designed as its own exercise, never as a checkbox on a dashboard order.
How do the screens handle stale or missing data?
Loudly. Every value carries its age; anything past its agreed freshness window is restyled — dashed, muted, labelled — and silence raises its own alert with an owner. The design principle is that old data must never be able to pass as current, even at a glance across the room.
Do the four roles really need separate screens?
They need separate arrangements of the same truth. An operator triaging a 2am alert and a manager reviewing the quarter are making different decisions, and a screen that tries to serve both serves neither. Sharing one record set underneath means nobody's view contradicts anyone else's.
What happens when the dashboard platform itself has a problem?
It says so on the screen. Platform faults and source silences become banner states; affected regions degrade visibly with their data age shown; documented fallback procedures appear where operators can see them; and recovery is verified against source data and announced with a time.
Can this sit alongside our existing systems?
Yes — the dashboards read the monitoring layer, which in turn reads confirmed interfaces. Existing systems remain authoritative for what they already do; these views aggregate, validate and present. Anything the sources cannot support is simply not shown.
Screens your night shift will thank you for
Bring one room, one team and one honest account of what breaks. We will design the views around your roles and prove them against your data before anyone depends on them.