Niagara Graphics and Operator Dashboards

The graphics are the building automation system, as far as most of the people using it are concerned. An operator does not experience your integration work or your control logic — they experience the screen at 6am when something is wrong. Niagara graphics and dashboard development is the work of making that screen answer the question quickly.

What We Build

  • Operator graphics — plant and floor views that show state clearly rather than decoratively.
  • HTML5 and mobile-friendly views — usable on a phone in a plant room, not just on a workstation.
  • Alarm and event consoles — prioritised so the important thing is visible, not buried in noise.
  • Energy and performance dashboards — consumption, demand and anomalies in a form a facilities manager can act on.
  • Portfolio and executive views — roll-ups across many buildings for people who will never open Workbench.
  • Custom UX modules — BajaScript and JavaScript where stock widgets stop.

Legibility Is Not Decoration

Operators look at these screens for entire shifts. Colour that carries meaning consistently, hierarchy that puts the abnormal first, and text that is readable in a badly lit plant room are functional requirements, not styling preferences. We also build darker themes for exactly that reason.

An Honest Note on Migration

If you are moving from AX to N4, graphics are usually the largest single item of unexpected effort — legacy Px work often needs rebuilding rather than converting. We scope that explicitly as part of migration services instead of letting it surface halfway through.

Tell us who uses your screens and what they need to see and we will design graphics around that rather than around the equipment list.

Related services

Px or HTML5: Which Should a New Project Use?

Px views are native to Workbench. Your own engineers can maintain them, they inherit the station security model, and for plant and floor graphics they are quick to produce and quick to change on site. For a lot of buildings that is the whole answer, and adding a front-end toolchain would be a commitment with no return.

HTML5 UX modules earn their place when the interface needs to behave like a web application: responsive layouts across devices, charting beyond stock widgets, custom interactions, and components reused across many sites. They also bring a build pipeline and front-end maintenance into the picture, which someone has to own after handover. Webpack / Babel (in UX builds) and WebSockets (used in UX modules) describe what that ownership involves.

A Slow Graphic Is a Binding Problem

When a screen crawls, look at the bindings before the graphics. The causes to check first are subscription volume, unbounded BQL queries firing on page load, and history queries pulling long date ranges to draw a small chart. A view bound to every point in a plant will subscribe to every point in that plant whether or not the operator can see them.

The fixes are unglamorous: bind what is on screen, paginate long lists, summarize on the station side before the browser asks, and cache anything that does not change during a shift. What a Supervisor absorbs comfortably can overwhelm a JACE serving the same view, so the target host matters when the design is decided.

Alarm Consoles Do a Different Job

A plant graphic answers what is happening here. An alarm console answers what needs attention first, which is a triage task. That means grouping related alarms so one failed device does not present as twenty separate problems, distinguishing new events from ones already being worked, and giving the incoming shift a way to see what changed since the last one.

Known-bad points deserve explicit handling. A sensor awaiting replacement that alarms every few minutes teaches operators to clear the console without reading it, and a console nobody reads has stopped doing the job it was built for.

Navigation Across a Portfolio

Once more than a couple of buildings are in scope, navigation becomes the design problem. A hierarchy of portfolio, site, system and equipment only works if the underlying naming is consistent across sites, which is decided during integration long before anyone opens a graphics tool. Building Automation Integration Services and Project Haystack tagging are what make a portfolio view generate itself instead of being hand-built per building.

Where naming is inconsistent, the options are to normalize it first or to accept hand-built navigation and the maintenance that follows. Both are legitimate; only one of them scales.

Decide What Each Role Can Change

Graphics expose control. A screen that offers a setpoint field to someone with no authority to change it generates support calls and, occasionally, a comfort complaint nobody thinks to trace back to the screen. Niagara’s category and role model decides who may write to what, so a contractor sees their own plant, a facilities manager can adjust the setpoints that belong to them, and a tenant view stays read-only. What the permission model does not do is police the value itself. Limits on how far a setpoint may move are enforced on the station side, in the logic, before the write reaches the device.

Settle this during design. Retrofitting permissions onto finished graphics tends to mean rebuilding navigation, because the view structure and the permission structure end up entangled.