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.

What Actually Consumes Engine Cycle Time

Load on a station is not constant, and the part that varies most is subscription. A proxy point is polled while something is subscribed to it and falls back to its unsubscribed state when nothing is, so opening a Px graphic carrying several hundred points subscribes all of them at once. That is why a station can be unremarkable at 3 am and sluggish at shift change. The exception is worth knowing: a point carrying a history extension or an alarm extension is subscribed permanently, so adding a trend to a point converts it from occasionally polled to always polled.

The other half is the engine. Component logic executes on the engine thread, one pass at a time, and the reported cycle time is how long the last pass took to work through everything queued for it. Whatever occupies that thread delays everything else on it, including alarm evaluation and schedule transitions, which is why a stretched cycle usually shows up first as alarms arriving late rather than as logic producing wrong answers. The usual occupants of that thread:

  • Long link chains, where one input change propagates through dozens of components in the same pass.
  • Program objects that block on a file read, a network call or a sleep inside their execute method, holding the thread until the call returns.
  • Interval-driven components such as timers, ramps and counters set to intervals far shorter than anything downstream can act on.
  • Alarm extensions with tight deadbands on noisy analog inputs, re-evaluating and changing state on every poll.

Slow Station: Load Problem or Memory Problem?

A station that feels slow is usually short of one of two things: thread time or heap. From an operator's chair the two are indistinguishable, since both produce a graphic that takes ten seconds to paint and values that update late. They need different fixes.

Four readings separate them. Heap use against the maximum the station's JVM was started with, visible in the Resource Manager view, answers the memory question directly. A poll scheduler whose actual cycle time sits well above its configured fast, normal or slow rate points at driver load rather than at logic. Long device ping times point past the station altogether, at the network or the field device, and no amount of station tuning will move them. Garbage collection or out of memory entries in the Application Director output settle the argument on their own. Two counts are worth recording before anything is changed:

  • Subscribed point count against total point count, which shows how much of the database is actually being polled at the moment you are looking.
  • History extension count and their intervals, since collection load is fixed at configuration time and does not rise and fall with operator activity.

What a Station Connects To, and On Which Ports

On the field side, the constraints come from the protocols rather than from Niagara. BACnet/IP is UDP on 47808 by default and does not cross a subnet boundary on its own, because the broadcasts it relies on stop at the router; discovery across subnets needs a BBMD on each subnet and foreign device registration for anything outside them. Modbus TCP is TCP on 502 and tolerates several masters polling the same registers, while Modbus RTU is a serial bus where a second master is not an option and the poll rate is bounded by baud rate and device turnaround time rather than by anything configured in the station. A controller with two network interfaces is normally split so field traffic stays on one and the owner's network on the other, which also decides which side a Supervisor has to reach.

On the management side, Workbench opens two different connections to the same host. The platform connection is on 3011, or 5011 with TLS, and it talks to the host daemon. The station connection is Fox, on 1911 or 4911 with TLS, and it talks to the running station. That split is a useful first diagnostic on a site nobody can reach: if the platform connection opens and Fox does not, the host is up and the station is not, which is a different problem from a host that answers nothing at all. Three kinds of client connect to a running station:

  • A Supervisor over the Niagara Network, which is a Fox connection carrying import and export descriptors for points, histories and alarms.
  • Workbench for engineering work, including the wiresheet, property sheets and BQL queries.
  • Browser profiles for operators over HTTPS, which present Px or HTML5 views but are not an engineering tool.

Resource Limits, Licensing, and Restoring to Different Hardware

Niagara 4 meters a station in resource units rather than in points alone, and different objects carry different weights: proxy points, devices, histories and network connections all draw from the same pool. The license sets the ceiling and the station reports consumption against it. The failure mode is what surprises people, because nothing degrades gradually. Components added past the limit go into fault or refuse to be added at all, so a routine device addition can fail on a station that has run for years without complaint.

That same license is what makes a restore onto replacement hardware more than a file copy. Six things have to line up:

  • A license issued against the target host ID. Licenses are bound to the host, not to the station.
  • A matching brand ID where the source station was branded. A branded station will not run on a host carrying another brand.
  • A Niagara version on the target at least as new as the source. A station saved by a newer build does not open on an older one, and there is no downgrade path.
  • The same modules, at compatible versions. A station referencing a module the target does not have starts with unresolved types, and the components that depended on it are missing from the tree until it is installed.
  • The source system passphrase, which is what decrypts the protected values inside the station, including stored credentials and private keys.
  • Enough licensed capacity on the target for the resource units the station actually uses now, not the count it had when it was first commissioned.

Frequently Asked Questions

Does every site need a Supervisor?

No. A single building with one controller, where the people who need access can reach that station directly, runs indefinitely without one. Storage is usually what forces the decision, since a controller keeps histories on its own flash and that flash was sized for control rather than for archives. The other trigger is how many people need to be looking at graphics simultaneously, which is a load question on the controller rather than a question about access rights.

Should new logic go on the wiresheet or into a program object?

Start from what it costs the engine thread. Both run on it, but a wiresheet block cannot block, whereas a program object that waits on a file, a socket or a sleep holds the thread and stalls every other component in the station while it waits. The second consideration is review: a wiresheet is legible to whoever opens the view and comparable across stations, while program object source has to be opened one station at a time, which matters when the same logic exists on twenty controllers and one of them misbehaves. If a program object is the right tool, keep every call inside it non-blocking and push anything that waits onto its own thread.

How much history can a controller hold?

There is no single station-wide number, because capacity is set per history extension. Each one has a record capacity and a policy for what happens when it fills, with rolling discarding the oldest records and an unlimited setting growing until the host file system runs out, which is the more damaging of the two. Estimate record volume before deciding retention: a point trended on a one-minute interval produces 1,440 records a day whether or not the value moved, while a change-of-value extension produces records only on change, which makes a noisy analog input expensive and a stuck sensor almost free.

What has to be in place before station work can start?

Two practical things beyond the station itself. First, a working remote access route and confirmation of what it actually reaches, since a VPN or jump host that forwards only HTTPS lets someone view graphics but not connect Workbench: platform and Fox are separate ports and engineering and commissioning need both. Second, a decision about restarting the station, because installing a module, changing platform network settings and some license changes cannot be done without one, and control stops for the duration. On an occupied building that is a scheduling question rather than a technical one.

Does adding a new field network need anything from licensing?

Yes, if the network uses a driver the host is not entitled to. Driver entitlement is listed feature by feature in the license file, so bringing a BACnet network onto a host licensed only for Modbus is a licensing task rather than an engineering one, and it is better arranged before the work than discovered during it. The symptom when it is missed is specific: the module installs and the network component appears in the tree, but the network faults on start and no devices under it come online.

What is the platform, as opposed to the station?

The platform is everything running on the host outside any station: the daemon itself, TCP/IP and hostname settings, platform user accounts, the license and certificate stores, and the set of installed modules and distributions. None of it lives in the station database, so copying a station onto another host brings none of it along and the target has to be commissioned separately. It also means the tasks that touch it, including module installation, license installation and certificate management, are performed over a platform connection from Workbench and cannot be done from a browser session regardless of the operator's permissions.