Building automation
Building automation systems, engineered from the software up
A building automation system is plant, controllers, a network and the software that turns all of it into something an operator can read. The job we are handed is almost never a new one. It is a chiller that will not come into the head end, graphics nobody can edit any more, or a trend that stopped three months ago and nobody noticed.
Field device → Protocol and driver → Station and screens
Bold is ours. The plant is the building owner's.
- BMS & BAS integration
- BACnet, Modbus & M-Bus
- MQTT & LoRaWAN
- Supervisory layer
- HVAC plant graphics
- Energy & reporting
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.
The layers, and who supplies each
Most arguments on a building automation project turn out to be about a boundary in this table rather than about the technology either side of it. It is cheaper to agree the boundaries before anyone quotes a number.
| Layer | What is in it | Who normally supplies it |
|---|---|---|
| Field devices | Sensors, valve and damper actuators, VSDs, meters, wireless sensors and their gateways. | Your contractor or supplier. We specify what the software needs from them: protocol, addressing, units, update rate. |
| Control | DDC controllers running the plant sequences — the AHU, the boiler cascade, the zone loops. | The controls contractor. We integrate them. Control logic that works is not rewritten without a reason. |
| Networks | BACnet/IP and MS/TP, Modbus TCP and RTU, M-Bus, LoRaWAN, an MQTT broker, and the IP network under all of it. | Shared. Cable, panels and switches are site work; addressing, discovery, broker topology and topic design are software decisions and ours. |
| Supervisory | The station that talks to every controller, normalises what they say, stores history, raises alarms and serves the screens. | Ours. Usually a Niagara JACE or Supervisor — occasionally something lighter, where there is no BMS to build on. |
| Screens and reports | Plant graphics, zone pages, dashboards, scheduled reports, a navigation tree an operator can learn in a morning. | Ours. |
| Data out | An energy or analytics platform, a CMMS, a customer API, a tenant app. | Ours up to the boundary, theirs beyond it. The buffering either side of it is the part that gets forgotten. |
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.
System shapes
Three shapes a job takes
Almost every enquiry is one of these three, and they are priced and sequenced differently. Naming the shape early is most of the scoping.
A supervisory layer over controls you already have
Mixed plant, several contractors' conventions, no single place to look. A Niagara station goes above what is there: drivers to each controller, one naming and tagging convention, histories and alarm classes that mean something, and a screen set built once and re-pointed per plant item.
Needs: a device list, protocol and addressing per controller, and network access. Delivered as a station plus the engineering behind it.
A monitoring system where there is no BMS
A building, or part of one, with plant worth watching and nothing watching it. Wireless sensors or meters, a LoRaWAN or Modbus gateway, an MQTT broker, and a supervisory layer above that stores, alarms and draws. It integrates with a BMS later rather than being thrown away when one arrives.
Needs: what you want to know, and where power and coverage exist. Sensors and their mounting are your contractor's; everything from the gateway inwards is ours.
Data out of a system that already works
The readings exist and the people who need them cannot get at them. A route outward to an energy platform, an analytics tool, a CMMS or your own API — buffered and retried, with the point list agreed in writing so a renamed point does not silently end a dataset.
Needs: the destination's interface and an agreed point list. Often the cheapest of the three and the one that pays back first.
When there is no BMS to build on
Not every building that needs monitoring justifies a full BMS, and not every plant item worth watching is anywhere near a controller. Retrofit tenancies, remote assets, standalone plant, cold stores, pump houses, a landlord who needs one number per meter per month: the classic answer is a controller and a panel, and it is often more than the question was worth.
The alternative is a small system assembled from open pieces. Battery sensors reporting over LoRaWAN to a gateway, or meters on Modbus; a broker taking their payloads as MQTT; a supervisory layer that decodes them into points with units, keeps history, raises the alarm, and shows a page. Because each hop is an open protocol rather than a product boundary, the system can be extended, re-pointed at a BMS when one appears, or read by somebody else's software without asking permission.
The honest limits are worth saying out loud. LoRaWAN is for telemetry, not for control: a payload every few minutes, no acknowledged setpoint writes, and a battery budget that punishes chattiness. MQTT gives no guarantee about payload shape, so the topic and payload convention has to be designed and written down or the second vendor's sensors will not fit. And a monitoring system is not a control system — it tells you the plant is wrong; somebody's control logic still has to put it right.
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. The two names for the system itself are worth their own note: BAS or BMS, and where a Niagara station actually fits.
| 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. Some of that you can do yourself today, with free tools for reading a building's network.
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 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.