Niagara Supervisor

The Supervisor is where a portfolio of buildings becomes one system. Software Pile builds Niagara Supervisor applications that aggregate JACE stations into something operators actually use: portfolio dashboards, cross-site reporting, centralized alarming, and clean integration into enterprise systems.

Supervisor Work We Deliver

  • Station aggregation – NiagaraNetwork architecture, point sharing strategy, and history imports that scale past the first dozen sites
  • Portfolio dashboards – HTML5 views by role: the energy manager, the operator on call, and the executive see different truths from the same data
  • Centralized alarming – routing, escalation, and consoles that separate what needs action now from what needs a work order
  • Enterprise integration – Supervisor as the bridge: histories to databases, alarms to CMMS/ticketing, KPIs to BI platforms, via REST, SQL, or MQTT
  • Provisioning and template discipline – so the fiftieth site onboards like the fifth

Performance at Portfolio Scale

Supervisors degrade quietly: history imports pile up, queries slow, dashboards lag. We design retention, import cadence, and query patterns for the size you will be in three years – and we run station health audits on Supervisors that have already grown past their original design.

Scoping

Tell us your site count, JACE models, and Niagara versions – plus what the Supervisor should feed (reports, dashboards, external systems). Mixed-version fleets are normal; we plan around them.

What Is a Niagara Supervisor?

A Supervisor is the server-level Niagara station that sits above the field controllers. Where a JACE runs the equipment in one building or one part of one, the Supervisor aggregates across them: consolidated graphics, estate-wide alarm handling, long-term history storage, reporting, and a single point of access for users.

It runs on server hardware or a virtual machine rather than on embedded controller hardware, which is what allows it to hold far more history and serve far more concurrent users than a JACE can.

Do You Need a Supervisor?

A single small building with one controller and a handful of users often does not. The case becomes clear when any of the following is true:

  • You have more than one controller and want one place to see everything.
  • You need history retained longer than controller storage allows — most energy and compliance reporting requires this.
  • More users need access than a JACE can comfortably serve.
  • You want alarms routed, escalated and acknowledged consistently across sites rather than per controller.
  • You need estate-level reporting that compares buildings.
  • You are integrating with business systems, analytics or a third-party platform and want one integration point rather than one per controller.

How Should a Supervisor Be Sized?

Sizing is driven by history volume and concurrency far more than by point count alone. The questions that matter: how many points are collecting history and at what interval, how long that history must be retained, how many users will be connected simultaneously, how many graphics they will have open, and what else is querying the station for reports or analytics.

Under-sized Supervisors do not usually fail outright — they get slow, histories fall behind, and reports time out, which is harder to diagnose than a clean failure. Size against the retention policy you actually intend to keep, not the one in the original specification.

Supervisor Architecture Decisions Worth Making Early

  • What lives where. Control logic belongs in the controllers so the building keeps running if the Supervisor is unavailable. Aggregation, reporting and long-term history belong in the Supervisor.
  • History strategy. What is collected locally, what is archived up, at what interval, and for how long. This is the single biggest driver of storage and of report quality later.
  • Backup and recovery. A Supervisor holds years of history that cannot be regenerated. Confirm the backup actually restores rather than assuming it does.
  • Redundancy. Whether the estate can tolerate the Supervisor being down for a day, and what that implies for hosting.
  • Access and network position. Where it sits relative to the business network, and who reaches it how — a question that is also a security question.

Supervisor Performance Problems

The usual causes are history collection configured more aggressively than anyone needs, expensive BQL queries running on refreshing views, graphics subscribing to far more than they display, and retention policies that were never enforced so the database has grown without limit. All are fixable, and all are cheaper to design correctly than to remediate on a live system.

Related services: graphics, dashboards and reporting · BAS integration services.