Niagara Supervisor

How Stations Connect: Ports, Trust and Device Extensions

A NiagaraNetwork connection is not one port. Fox, the station to station protocol, defaults to 1911 in the clear and 4911 for TLS. The platform connection used for backups, software installation and station transfer is separate again, on 3011 and 5011, and it authenticates against platform credentials rather than station users. Web access sits on 80 and 443. Firewall rules written for the web port alone produce a station an engineer can browse to and the Supervisor cannot add. The diagnostic is that a browser login succeeds while the NiagaraNetwork device stays down reporting a connection failure rather than an authentication failure.

Where TLS is in use, the Supervisor validates each subordinate station's certificate against its trust store before the Fox session opens. A station with a self signed certificate that was never imported shows as down with a handshake or certificate error, which is a different repair from a wrong password even though both leave the device in the same state on screen. Certificates issued to a host name also fail validation when the NiagaraNetwork address is an IP that is not in the subject alternative name, so the address you type into the device is part of the certificate design. One internal CA whose root sits in every Supervisor and Workbench trust store scales across a fleet; per station certificates approved by hand do not, and retrofitting TLS onto a live estate means revisiting every station's certificate, address and trust store entry while the network is running.

Each subordinate station appears under the NiagaraNetwork as a station device, and what actually crosses the link is decided by which device extensions are enabled beneath it and what is configured under each one.

• Points. Proxy points resolve values over Fox only while something subscribes them. A graphic nobody has open costs nothing; the same graphic left up on a wallboard subscribes continuously, all day.
• Histories. Import descriptors pull records the subordinate has already written to its own history table, each on its own execution schedule. Collection interval is a controller setting and import cadence is a Supervisor setting, and the two are independent of one another.
• Alarms. Routing is by alarm class. Records queue at the source when the link is down and deliver on reconnect, within the queue limits set on the alarm class.
• Schedules. Master schedules export downward on their own cycle. An edit made locally at the controller is overwritten at the next export, which is the intended behavior and the most common surprise on a site where operators are used to editing at the panel.
• Users. User synchronization pushes accounts and roles from the Supervisor down, so credentials are administered in one place. Stations still keep local accounts, which is what gets you in when the Supervisor cannot be reached.

Version and License Constraints That Decide the Order of Work

A Supervisor connects down to stations at its own Niagara version or older, never up to newer ones. That makes the Supervisor the first host in any upgrade program and fixes the order of everything that follows. Workbench obeys the same direction: it has to be at or above the version of the platform and station it opens, so the engineering workstation moves before the field does.

The AX to N4 boundary is the harder version question, because it is a migration rather than an upgrade. Station databases do not move across it by restore; they are converted with the migration tooling, which rewrites the station and leaves behind any module that has no N4 build. Third party drivers are where this bites, since the conversion can only carry forward what the vendor has actually released for N4.

Licensing constrains the same work from a different direction. A license is issued against the host ID the installed platform reports and against a brand, so it cannot be generated before the host exists and does not follow the station to different hardware without being reissued. The license also carries a software maintenance expiration date, which does not stop a running station but does govern which builds the host will accept: modules released after that date will not run under that license, so an upgrade plan needs the maintenance status checked before the version is chosen. Drivers are licensed as features, so a Supervisor that has to speak BACnet or Modbus directly, rather than only through its subordinate stations, needs those features on its own license.

Histories: Import Cadence, Capacity and What an Outage Costs

Imported histories are copies, not views. They land on the Supervisor under the source station's name and are appended to by descriptors that poll; nothing streams. That is why a history can look healthy on the controller and be days stale on the Supervisor with no error anywhere in between.

The number that governs load is descriptors multiplied by records per execution, not point count. The useful diagnostic for an import that is falling behind is the gap between the newest imported record and now, compared across stations: a gap that stays constant is a cadence choice, a gap that grows a little every day is an import losing to the collection rate, and a gap that has stopped advancing altogether is almost always the link or the credentials rather than throughput.

Capacity is the quieter problem. Every history has a record capacity and a policy for what happens when it fills, and an imported history inherits both from whatever template created it. Templates written for a controller's local buffer are sized in a few thousand records, which is correct on the controller and wrong on the Supervisor, where the same setting discards the oldest data as new records arrive with no alarm and no visible gap in the chart. Give the Supervisor copy an explicit capacity that covers the full period the estate is required to hold, rather than letting it inherit a controller sized buffer, and enforce that number as a deliberate limit so the database is neither silently truncated nor left to grow without a ceiling.

Backfill after an outage comes out of the controller's local buffer, which means the outage you can survive without data loss equals the controller's local capacity for that history at its collection interval. Five thousand records at a fifteen minute interval is about fifty two days of cover; the same five thousand records at a one minute interval is about three and a half days. Changing an interval to get better resolution silently shortens the outage you can absorb, and that is the trade to make consciously rather than discover after a WAN failure.

Telling One Kind of Slowness From Another

Slow describes at least four unrelated conditions on a Supervisor, and the remedy for one does nothing for the others. The station's own instrumentation separates them: engine cycle time and queue depth show whether the execution loop is the bottleneck, the application director output shows module and database errors, and the host's disk and memory counters show whether the trouble is below the station entirely.

Work from the symptom, because each one points at a different layer.

• Everything is slow, including local logic and alarm delivery. Check engine cycle time against the configured cycle. When execution is overrunning its cycle, the station is oversubscribed at the engine, and query tuning changes nothing.
• One view is slow while the rest are fine. The answer is in what that view resolves. A binding written against a folder or a broad ord subscribes everything beneath it, so the subscribed count for a single page can be an order of magnitude above the number of values on screen. Compare the subscription count on the slow view against a fast one before touching the host.
• Reports or exports time out while the interface stays responsive. The cost is in the query. A wide time range against a history table scans it every run, and a view that refreshes re runs the query each refresh; the same report against periodic rollups does not.
• Histories are behind and nothing else is. This is cadence, link latency or a stopped descriptor, not host capacity. Confirm the records exist on the source station first, because a controller that stopped collecting looks identical from the Supervisor.
• The station pauses at intervals instead of being uniformly slow. Look below the station. A history volume close to full, host backups running against the same disk, and virtual machine snapshots all produce periodic stalls that no station level tuning will remove.

What the Supervisor Is Not

It is a station, which means it can run control logic exactly as a controller can. That is a trap rather than a feature. Logic written on the Supervisor stops when the host stops, and more often when the link between the Supervisor and a site drops while both ends are perfectly healthy, which is the failure that leaves a building running on nothing.

It is not a network design, either. Proxy points, graphics and imports all cross whatever WAN sits between the server and the field, and latency there rarely announces itself as an error. It shows up as views that populate a value at a time and reports that take minutes longer than they did in the lab. It is also not an analytics product: Niagara's analytics capability is separate licensed software, and a Supervisor gives you the data it would run on rather than the rules themselves.

There are cases where the smaller answer is the right one. Where no one needs a single place to see everything and there is no cross building comparison to make, the controllers' own web interfaces reached over a VPN cover the day to day work. For a single building with no cross site comparison in scope, archiving histories out to a database or a metering service is a way to hold long term data, though what that buys is storage alone, without the estate level views, alarm routing and single point of access a Supervisor exists to provide.