Niagara N4 / Niagara AX

Platform, Station, and the Ports Between Them

A Niagara host runs two things that get conflated: the platform daemon and the station. The platform daemon is the operating system level service on the JACE or Supervisor host, and it handles module installs, backups, station start and stop, TLS configuration and licensing. The station is the running application, meaning the component tree, the drivers, histories, alarms and station users. The credentials are separate too, which is why an engineer can hold working station logins and still be unable to install anything.

On a hardened N4 host the unencrypted ports are disabled and the TLS ports carry everything, which is worth confirming before a failed connection gets blamed on a firewall. The more common problem runs the other way: a rule that opens only the station's web port yields the operator interface and nothing more, because engineering and platform work do not travel over it.

Discovery on the field side has its own constraint. BACnet/IP finds devices by broadcasting Who-Is on the local subnet, and routers do not forward those broadcasts. A station and a device on different subnets will not find each other without a BBMD on the device's subnet or foreign device registration pointed at one. Modbus TCP has no discovery at all, so every device address and register map has to be supplied rather than found.

Default ports worth knowing before a firewall request is written:

• Fox, TCP 1911 unencrypted and 4911 over TLS. This is the station to station protocol across a Niagara Network and the one an engineering session uses.
• Platform daemon, TCP 3011 unencrypted and 5011 over TLS.
• Station web interface, TCP 80 unencrypted and 443 over TLS, which also carries oBIX and any REST client reading out of the station.
• BACnet/IP, UDP 47808 by default, and it is UDP rather than TCP.
• Modbus TCP on 502, SNMP polls on UDP 161 with traps arriving inbound on 162, and MQTT on 1883 or 8883 over TLS.

How a Module Is Structured, Signed and Installed

A module is a JAR file carrying a manifest that declares what it contains and what it needs. A module is installed on the platform, not into the station: the Software Manager view on a platform connection compares the modules in the local database against what is already on the remote host and copies the selected ones to the remote host. The station is then restarted before the new components exist. That sequence is why module delivery is a scheduled event on a live site and not a file drop.

Every N4 module carries a digital signature over its contents, and the platform verifies that signature and its certificate chain at install time. AX had no such requirement, which is part of why an AX module cannot simply be carried forward. The build toolchain differs as well: N4 modules are built with Gradle against the Niagara SDK, where AX used an Ant based build.

The failure most often seen here is not a rejected module but a certificate the host has never seen. The install stalls on an approval prompt or fails outright, and the resolution is approving the certificate in the platform's trust store, under Certificate Management, before retrying. Doing that once per host is normal; doing it silently as a habit is not, because the trust store is the only thing standing between the platform and an arbitrary JAR.

The manifest declares the vendor, the vendorVersion, and every module it depends on with a minimum version for each. A module compiled against a newer Niagara release will not load on an older host. There is no build error to catch it, because the compile happened elsewhere: the host refuses the module and the station log names the unsatisfied dependency, so the symptom on site is a component type that will not resolve.

Modules are split into parts by where the code runs, so a controller only ever receives what it needs:

• A -rt part holds the runtime code, meaning the components and drivers themselves. This is the part a controller has to have.
• A -ux part holds browser side JavaScript and HTML5 widgets, served to clients by the station.
• A -wb part holds Workbench views and engineering tools, and is of no use on a headless controller.
• A -doc part holds documentation and is routinely left off a constrained host.

Polling, Subscription and Values That Look Stale

Niagara does not read every point all the time. A proxy point is polled when something subscribes to it: an open Workbench view, a live graphic, a history extension, an alarm extension, or logic that holds the subscription. Close the view and the reads stop. This is the mechanism behind the most common false alarm in commissioning, a value that updated fine while someone was watching it and shows an hours old timestamp the next morning. The point is not stale, it stopped being read.

The practical consequence is that a link from a proxy point into control logic does not by itself guarantee the point is being polled. Where a value has to be current whether or not anyone is looking, the subscription has to come from something permanent: an extension on the point, or a component that stays subscribed on its own. Discovering this after the logic has been running on stale inputs for a week is worse than designing for it.

Drivers poll on a scheduler with fast, normal and slow buckets, and every proxy point is assigned to one of them. The scheduler reports its actual cycle time against the configured rate, and when the actual time exceeds the configured rate the network is oversubscribed, meaning there are more points in it than the bus or the device can serve. Moving points to the slow bucket is the honest fix. Shortening the configured interval to make the number look right only makes the backlog grow faster.

Tuning policy governs writes as much as reads, and it is where write behavior is decided rather than in the logic. Minimum write time throttles rapid commands so a hunting loop cannot flood a device. Maximum write time forces a periodic rewrite, which is what brings a device that lost power back to the commanded value. Write on start decides whether the station asserts outputs when it comes up. A device that quietly reverts overnight is usually a maximum write time of zero, not a device fault.

When a value does look wrong, the order of the check saves time:

• Check device health first. A device with a failed ping monitor makes every point under it look stale at once, and the device's last ok and last fail times bound the outage before anything else is examined.
• Then read the fault cause string on the point itself, which names the actual error rather than the symptom. On Modbus that is usually a register offset counted from the wrong base or a 32 bit value assembled in the wrong word order, not a communications failure at all.