Service
Station engineering and new controller setup
Standing up a new station or a new controller, properly, from platform commissioning to a handover pack. The boring half done right — naming, tagging, security, histories and backups — because that is the half that decides whether the site is maintainable in year three.
- Platform commissioning
- TLS / certificates
- BACnet & Modbus
- Tagging
- Histories
- Backups
New station, end to end
Platform commissioning
Distribution files and the correct Niagara version for the hardware, platform daemon, licence and certificate install, host ID registration, system passphrase recorded, TLS enabled on the platform and Fox ports.
Security before anything is connected
Default credentials gone, a real user and role model with least privilege, password policy, an authentication scheme that is not the default, and the platform listening only where it should.
Drivers and discovery
BACnet/IP and MS/TP, Modbus TCP and RTU, or whatever the field devices speak. Discovery, device and point creation, poll rates set deliberately rather than left at default — a JACE can be brought to its knees by an over-eager poll scheme long before it runs out of points.
Naming and tagging
A naming convention applied uniformly, and Haystack or Niagara tags applied as the points are created rather than retro-fitted later. This is the single decision that determines whether analytics, standard PX sheets and bulk engineering are cheap or impossible on this site.
Histories, alarms, schedules
History extensions with intervals chosen to fit the flash on the device, alarm classes and routing that a human can actually act on, schedules and calendars modelled once and referenced rather than copied.
Supervisor connection
Station added to the Supervisor, Niagara Network wiring, history and alarm federation, provisioning jobs, and a verified restore — a backup nobody has restored is not a backup.
Handover pack
Point schedule, network diagram, credential and passphrase handover, backup procedure, and a note of every decision a future engineer would otherwise have to reverse-engineer from the station.
Also available on its own
Controller replacement
Moving a station onto new hardware: station copy, licence and certificate transfer, driver revalidation, third-party module check, and a rollback plan.
Health review
An existing station reviewed against the list above — security posture, poll load, history sizing, alarm noise, backup state — with findings ranked by what will bite first.
Tagging retrofit
Applying a consistent tag model across a station that was built without one, scripted rather than clicked, so analytics and standard graphics become possible.
Deliverables
What you actually receive
Fixed price per deliverable, quoted against a written specification. No hourly billing, and no price before the scope is in writing.
| Deliverable | Detail |
|---|---|
| A commissioned station | Licensed, secured, backed up and documented, with TLS on and defaults gone. |
| A point schedule | Every point, its ORD, its tags, its history and alarm configuration, as a document you keep. |
| A verified backup and restore | Proven by performing the restore, not by the backup job reporting success. |
| The handover pack | Credentials, passphrase, diagrams, conventions and decisions, written down. |
Also
Other services
Custom modules & drivers
Bespoke Niagara rt, wb and ux modules and drivers written against the Baja API: pure Java, signed, and stamped to install across a mixed estate.
bajaux widgets
Custom Niagara web widgets built with bajaux and BajaScript: HTML5 dashboards, navigation, equipment views and charts, bound to live station ORDs and BQL.
PX graphics
Niagara PX graphics as a reusable template set: standard sheets per plant type, relative-ORD binding, navigation hierarchy and a graphics standard.
Workbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
Niagara 5 migration
Niagara 5 readiness audits and migration: which third-party modules survive the new runtime and mandatory signing, and porting your modules so they load.
Notes
Written up in more detail
The engineering behind this service, in public, with no pitch attached. All notes.
What a station checks before loading a module
Niagara's three module verification modes, what each one demands of your certificate, and why the setting cannot be relaxed from the command line.
- Module signing
- Certificates
- Deployment
Renaming and tagging points in bulk
Point names arrive from the field device and there is no standard. What to use to select, rename and tag in bulk — and what a rename quietly breaks.
- Bulk engineering
- Tagging
- Workbench
Getting data out of a Niagara station
REST, MQTT, a relational history database, file export or an HTTP client. Which suits which consumer, and what each one costs you to run.
- Integration
- Histories
- MQTT
Scheduled station backups, and the gap
A Supervisor can back up every station in its Niagara Network on a schedule. The station it does not cover that way is its own.
- Backups
- Provisioning
- Supervisor
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.