Niagara Station
The station is the running heart of a Niagara installation – the live database of components, points, histories, and logic that actually controls and monitors the building. Software Pile builds, tunes, and repairs stations that have to run for years without drama.
Station Work We Do
- Station architecture: component hierarchy, naming standards, and structure that stays maintainable as the site grows
- History and alarm design that captures what matters without bloating the station database
- Control logic in wire sheets, program objects, or Baja when the palette runs out
- Performance tuning: engine cycle time, history collection load, and the slow-poll problems that make stations sluggish
- Station health audits and remediation on installations that have grown past their original design
When a Station Needs Rescue
Stations that were fine at commissioning drift: engine cycles stretch, alarms flood, histories fall behind. We diagnose the actual cause – not just the symptom – and fix structure, logic, or load so the station is serviceable again.
Tell us the station’s Niagara version and target platform – Supervisor or JACE – and what it needs to do or stop doing.
What Is a Niagara Station?
A station is a running Niagara application — the configured database and logic that actually controls and monitors equipment. A JACE or a Supervisor is the host; the station is what runs on it. One host runs one station, and everything that makes the system do anything — drivers, points, logic, schedules, alarms, histories, users, graphics — lives inside it.
The distinction matters when discussing backups, migrations and licensing, where “the JACE” and “the station” are routinely conflated and mean different things.
What Is Inside a Station?
- Drivers and devices — the network configuration reaching field equipment over BACnet, Modbus, LonWorks and others.
- Points — the values read from and written to that equipment.
- Control logic — the wiresheet programming that makes decisions.
- Schedules — occupancy and time-based behaviour.
- Alarms — what constitutes a fault, who is told, and how it escalates.
- Histories — what is trended, at what interval, and retained how long.
- Users, roles and permissions — who can see and do what.
- Graphics — the Px or HTML5 views presented to operators.
How Should a Station Be Backed Up?
Station backups are the difference between a controller failure being an afternoon and being a rebuild from memory. The points that matter:
- Take backups on a schedule, and take one before any change — not only after.
- Store them somewhere other than the controller. A backup on the device that failed is not a backup.
- Verify by restoring to a test platform occasionally. Untested backups fail exactly when they are needed.
- Keep history separately in mind — depending on configuration, long-term history may not be inside the station backup.
- Record the Niagara version, module versions and licensing alongside the file. A backup you cannot legally or technically restore onto available hardware is not much use.
Station Architecture: What Goes Where?
Control logic belongs in the controller that owns the equipment, so the building keeps running when the network or the Supervisor is unavailable. Aggregation, long-term history, estate-wide reporting and consolidated user access belong in the Supervisor. Stations that depend on a Supervisor to perform basic control are fragile in exactly the circumstances where robustness matters.
Station Health Worth Checking
Stations degrade quietly. Recurring findings on estates we assess: points configured to collect history that nobody reads, alarms with no valid recipient so they are never acted on, devices that have been offline for months without anyone noticing, logic left in place from a since-removed piece of equipment, and user accounts belonging to people who left. None of these announce themselves — they surface in an audit or in an incident.
Related services: station audits and engineering tools · migration services.