Building automation
Building automation software, built on Niagara
A building management system is plant, controllers, a network and a pile of software. We are hired for the software: the drivers that make equipment legible, the graphics an operator actually uses, and the station configuration that decides whether any of it is maintainable in year five.
- BMS integration
- HVAC plant graphics
- BACnet & Modbus
- Supervisory layer
- Open protocols
Where Niagara sits in a building automation system
A building automation system is usually drawn in three layers. At the bottom is field equipment — valves, dampers, VSDs, meters, sensors — speaking BACnet MS/TP, Modbus RTU, M-Bus or a manufacturer's own protocol. Above that sit DDC controllers running the actual control logic for a plant item: the AHU sequence, the boiler cascade, the zone loop. Above those sits a supervisory layer that talks to every controller at once, normalises what they say, stores history, raises alarms and draws the screens.
The Niagara Framework is that top layer. Its distinguishing feature is that it was built to be vendor-neutral: a BACnet AHU from one manufacturer, a Modbus chiller from another and a metering system from a third all arrive in the same object model, with the same naming, tagging, history and alarm machinery over the top. That is why it turns up in mixed estates that have been extended by four different contractors over fifteen years, which is most estates.
Two pieces of hardware carry it. A JACE is a small ARM controller mounted in a panel, running a Niagara station for one building or one plant room. A Supervisor is the same software on a server, aggregating many JACEs into one head end. Both run the same modules, which is why a module that is built carelessly for the server will not install on the controller.
What “the software layer” means on a real project
On a live BMS project the software work separates into four pieces that get bought separately and fail differently.
Making equipment legible
A driver turns a device on a wire into points in a tree. Stock drivers cover BACnet, Modbus and the common cases. The gap is the equipment that has a published protocol and no Niagara driver — a legacy field bus, a proprietary register map, a vendor REST or MQTT API — which is where a custom driver earns its cost.
Screens people actually use
HVAC plant views, zone pages, meter dashboards and a navigation tree that reaches any unit in three clicks. Done as a small set of standard PX sheets bound relatively, or as responsive web widgets where the view has to work on a phone or carry a brand.
The configuration nobody sees
Naming, tagging, history collection, alarm classes and recipients, schedules, users and roles, certificates, backups. None of it is visible on handover day and all of it decides whether the estate is workable later. Station engineering is this half.
Getting data back out
An energy team, an analytics platform, a CMMS or a customer API wants the data the station is already collecting. That is an integration outward, with buffering and retry, so a network outage costs a gap in a chart rather than a day of readings.
Vocabulary
The same thing, two names
Building automation and Niagara are not different subjects, but they are different words, and a quote can go badly wrong on the gap between them.
| In building automation | In Niagara |
|---|---|
| BMS head end | A Supervisor: the server-side station that aggregates the others and usually owns the long-term history. |
| Field controller / DDC panel | A JACE, where it is Niagara. Third-party DDC controllers stay what they are and are integrated over BACnet or Modbus. |
| Point | A control point component in the station tree, with its own facets, extensions, history and alarm configuration. |
| Graphic / mimic | A PX view, or a bajaux widget inside one. |
| Trend log | A history extension on a point, collected on interval or on change of value, queried with BQL. |
| Alarm / event | Three separate objects: the alarm extension that detects, the alarm class that groups, and the recipient that delivers. |
| Time schedule | A schedule component, optionally mastered on the Supervisor and replicated down to each station. |
| Software driver | A module: a signed jar, stamped to a minimum framework version, installed through the platform rather than copied in. |
Why a separate developer at all
The contractor who installed the system is usually very good at the things the job mostly consists of: panels, field wiring, commissioning, tuning a plant until it behaves. Writing a signed Java module that has to install on an ARM controller, on the oldest framework version in the estate, and keep loading after a security update, is a different discipline with different failure modes. It is a poor use of a commissioning engineer's week and a normal use of a developer's.
So the usual shape is not replacement. A systems integrator keeps the client, the site and the commissioning, and subcontracts the module, the widget set or the graphics standard. The work arrives signed, documented for the engineer who installs it, and with source where that is in scope, so it does not become another orphaned dependency.
What we do not do
No panel building, no field wiring, no on-site commissioning, no electrical design and no maintenance contracts. Work is remote, and it is the software. If a job needs hands in a plant room, it needs your engineers or your contractor's — we work alongside them rather than instead of them.
Who this is for
Three kinds of buyer, three different first jobs
Systems integrators and controls contractors
A module, a widget set or a graphics standard you do not have a developer to write. Usually scoped against one site and then reused across the next ten, which is where a standard sheet set or a themed component library pays for itself.
Building owners and estates teams
You have inherited a BMS, several contractors' worth of conventions, and no inventory. The first job is finding out what is actually installed — normally a readiness audit — before anyone quotes a number for changing it.
Consultants and specifiers
A second opinion on whether a specification is deliverable in Niagara, what a requirement will really cost in station work, and which parts of it stock features already cover. This is frequently half an hour and no invoice.
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.