Niagara Engineering Tools

Access, Ports and Credentials Before Anything Runs

Every tool here falls into one of two access classes, and they authenticate separately. Anything reporting host identity, Niagara and operating-system version, installed software or module status is reading the platform daemon, which keeps its own user store on the host. Anything reading the component tree, running BQL, or pulling histories is logging into the station as a Niagara user. In Niagara 4 those are separate credential stores, and holding one does not get you the other, so a collector that covers both kinds of data needs both sets.

The network path has to allow the right ports in the right direction. Niagara 4 defaults to the TLS variants: foxs on 4911 for station connections and platform TLS on 5011 for platform work, with plain 1911 and 3011 disabled unless someone deliberately turned them back on. TLS brings a certificate decision with it. Most JACEs carry a self-signed platform certificate, so the collecting machine either has that certificate approved into its trust store ahead of time, or every connection stops on an approval prompt that no one is present to answer during an unattended run.

Account handling deserves a decision before the first run rather than after it. Use a named account created for the tool, with a role scoped to read on the branches it actually queries. The reason is blunt: one stale password in a scheduled fleet pass can lock the same account on every station in the estate, and if that account is also the one engineers log in with, the outage is self-inflicted and estate-wide.

Beyond credentials, four things have to be settled before an unattended run makes sense:

• An agreed collection window. A fleet pass opens Fox sessions and runs queries on every station at roughly the same time, and that is load the building owner should know about in advance rather than discover.
• Where the collection runs from. One machine with a route to every station is simplest. Multiple collection points across segmented networks means multiple credential sets and multiple certificate trust stores to keep current, and the second one always drifts first.
• A destination the output can be written to. Reports and archives have to land somewhere with space and a retention rule, and if that destination is an SFTP target, its host key needs to be accepted interactively once before anything runs unattended against it.
• What happens to the accounts afterward. Service accounts created for a one-time audit outlive the audit unless someone is named to disable them when it closes.

Reading a Failed Connection in the Right Order

When a station will not answer, the discipline that saves time is working the layers in a fixed sequence and stopping at the first one that fails: TCP reachability to the port, then the TLS handshake and certificate acceptance, then authentication, then the account's permissions on what is being asked for, and only then the host's own capacity. Symptoms from different layers look alike from the client end, and skipping ahead is how an afternoon disappears into a firewall that was never the problem.

One case gets misread in a predictable direction: a connection that broke after one side was upgraded. Fox negotiates between client and station, and Workbench is supported against stations at its own version or older, not newer. A laptop left behind at an earlier build while the site moved forward will connect for some operations and fail on others rather than refusing cleanly, which presents as an intermittent network fault and is not one. When the timing lines up with an upgrade, compare the two version numbers before touching anything else.

The common failures and the check that separates them:

• Connection refused immediately on the port: nothing is listening there. If the platform answers on 5011 but the station does not answer on 4911, the station is stopped or never started, and the platform is where to look.
• A handshake that fails outright, or a certificate warning nothing is present to dismiss: the host certificate has expired, or the address in use does not match it. Approving a certificate for an IP address does not cover the same host reached by hostname.
• Authentication rejected on a host that worked yesterday: check whether the account is locked rather than wrong. A locked account and a bad password return the same rejection to most clients, and unlocking without correcting the stored credential simply restarts the cycle on the next pass.
• Login succeeds and the query returns an empty result: check the role's read permission on the branch being queried. A denied branch and a genuinely empty branch produce identical blank cells in a CSV.
• Everything connects but responses are slow or truncated: check host CPU, heap and resource use before touching the network.

What the Middle Category in a Compliance Report Is Telling You

The output already separates compliant, mismatched and needs-review, so the question worth answering is what puts a point in that middle category, because the conditions that land there are not equivalent and they do not go to the same person. Sorting them is the difference between a report someone acts on and a spreadsheet that gets forwarded twice and then ignored.

Matching is the hard part, and it is where most first-pass noise comes from. A CPL row and a station point rarely agree on spelling: delimiters differ, equipment prefixes are abbreviated one way in the spreadsheet and another way in the station, and a single CPL line often corresponds to a value point plus its alarm extension plus its history extension. A first run that flags a large fraction of the list is usually reporting that the naming rules need tuning, not that the installation is wrong. Tune, rerun, then read the results.

One prerequisite decides whether any of it means anything: the exported alarm and trend configuration and the CPL have to describe the same revision of the job. If the point list moved after the export was taken, the comparison is between two different buildings and every conclusion drawn from it is noise. With that established, the conditions underneath needs-review sort into five kinds:

• The point is absent from the station entirely. Installation or field gap, and the first check is whether the device it belongs to was ever discovered and added at all.
• The point exists with no alarm or history extension on it. Engineering omission, resolved in the station, and usually resolved in batches because omissions cluster by equipment type.
• The extension exists but its alarm class, notification level, delay or trend interval differs from the CPL. This may be a deliberate site decision nobody wrote down or a straightforward error, and it needs the engineer who made the change rather than a bulk correction applied over the top.
• The point exists under a different name or in a different place than the CPL predicted. That is a matching result, not a defect, and it belongs back in the naming rules before it is escalated to anyone.
• The CPL row is ambiguous or contradicts another row. The design document is the thing to fix, and quietly picking an interpretation is how a discrepancy survives all the way to handover.

What Has to Be True Before a Station Publishes to a Broker

An MQTT client in a station is an outbound TCP connection, and most of the work sits around it rather than in it. The host needs name resolution and a route out, and a JACE on a controls VLAN frequently has neither, because nothing it did before required leaving the building. If the broker requires TLS, the certificate authority that issued the broker's certificate has to be present in the host's trust store, and a broker certificate issued for a hostname will not validate when the station is configured to reach it by IP address.

Topic namespace and payload structure are design decisions rather than settings, and they are the expensive part to change later because every subscriber is coupled to them. Publishing on change of value instead of a fixed interval sounds cheaper until a noisy analog input publishes on every least significant digit; a deadband is what makes change-of-value viable, and a fixed interval is easier to size a broker against. QoS is the other axis: QoS 0 costs least and drops messages on a bad link, QoS 1 guarantees delivery at the price of duplicates the subscriber has to tolerate, and QoS 2 removes the duplicates at the cost of more round trips per message.

The concrete items to have decided before configuration starts:

• Broker address and port: 1883 for plain TCP, 8883 for TLS, and whether authentication is username and password or a client certificate.
• Password-typed slots for any credential, so it is stored encrypted in the station rather than sitting readable in a string property and in every backup taken of that station afterward.
• A client ID that is unique per station. Two stations sharing one client ID will disconnect each other in a loop, and the symptom looks exactly like an unstable network.
• Whether the station only publishes or also subscribes. Accepting writes from a broker changes the permission model and the risk profile, and it is a different conversation from telemetry.
• Behavior when the broker is unreachable. A client that buffers without a bound turns a broker outage into a memory problem on a controller that has little memory to spare.

Where the Toolkit Stops

Tooling of this kind reads, compares and moves data. It does not repair anything. A fleet report that finds hosts on mismatched module versions has told you the truth and left the work exactly where it was, and module updates are platform operations with a restart per host, scheduled around an occupied building. A compliance report behaves the same way: it locates discrepancies, it does not decide which side of a discrepancy is correct.

There are also things none of it can see, and those matter more than the things it declines to do. Every tool here reads the station, so anything that never made it into a station is invisible. A field device sitting on the wire that was never discovered and added has no component tree entry, which means it cannot appear in an inventory, a compliance check or an export. Control logic is the other blind spot: a sequence can be entirely wrong and still produce a clean report, because the report checks that points, alarms and trends exist and match a specification, not that the specification produces comfortable spaces or sensible energy use.

Inputs that are not machine readable are a third boundary. A point list delivered as a scanned drawing set is not an input to anything until a person retypes it into structured columns, and that transcription carries a person's error rate into everything downstream of it. Worth knowing which format yours is in before scoping anything around it.