Niagara N4 / Niagara AX

Software Pile develops on Niagara 4 and Niagara AX – custom modules, protocol drivers, Workbench tooling, and station applications for systems integrators, OEMs, and facility teams. The work is led by a Tridium-certified Niagara Full Stack Developer holding NCPD credentials in both Drivers and User Interface.

N4 Development We Deliver

  • Custom modules – control logic, data processing, engineering tools, and packaged components built against your station architecture and Niagara version, signed and compatibility-tested
  • Custom drivers – Baja driver architecture for proprietary and OEM equipment: protocol analysis, point discovery, proxy extensions, histories, and alarms validated against real hardware
  • Workbench tools – bulk tagging, station audits, deployment utilities, and custom views that cut engineering hours
  • Station and Supervisor applications – HTML5 and Hx dashboards, BajaScript interfaces, BQL reporting, alarm consoles, and role-based operator screens
  • Program objects and kitControl extensions where the built-in palette runs out

N4 and AX: Where Each Fits

New development belongs on N4. But AX is still running real buildings, and we support it: maintaining existing AX modules and AXScripting, keeping stations serviceable, and – when the time comes – planning AX-to-N4 migration so histories, alarms, and graphics survive the move. PX-to-HTML5 modernization is part of that path.

How Niagara Projects Are Scoped

Every engagement starts from your station reality: Niagara version and build, Supervisor or JACE target, host IDs, licensed capacities, and the protocols in play (BACnet, Modbus, MQTT, SNMP, oBIX, or proprietary). We develop against representative station exports, test on matching versions, and deliver signed modules with documentation – so commissioning holds no surprises.

Common Questions

Can you build a driver for equipment with no published protocol? Often, yes – via protocol capture and analysis against the physical device. We will tell you feasibility after a short assessment.

Do your modules survive Niagara updates? Modules are built against the Niagara API surface for your version line and compatibility-tested; we document version dependencies and support recompilation when you upgrade.

Can you work inside our integrator workflow? Yes – many clients are integrators. We deliver modules and tools into your engineering process, white-label where needed.

Is the certification verifiable? Yes – credential verification is available on request.

Send your Niagara version and target environment – Supervisor or JACE, and the protocol or device in question – and we will scope the work from the first call.

What Is the Difference Between Niagara AX and Niagara N4?

N4 is the current generation of the Niagara Framework; AX is the previous one. The distinction that matters commercially is not the feature list — it is that AX is a legacy platform, and a station still running it is running on borrowed time in terms of browser compatibility, security posture and vendor support.

The differences that drive migration effort:

  • User interface. AX graphics were built for an era of browser plugins that modern browsers no longer run. N4 is HTML5-based. This is usually the largest single line in a migration budget.
  • Security model. N4 handles users, roles and permissions differently. Accounts are reviewed and rebuilt rather than copied across.
  • Tagging and search. N4 adds a tagging and relation model, including Project Haystack support, which AX did not have.
  • Module format. Modules are built and signed differently. Every third-party module needs an N4 equivalent or a replacement.
  • Hardware requirements. N4 needs more resources; some older JACE controllers cannot run it at all.

Is Niagara AX Still Supported?

AX is a legacy platform and should be treated as end-of-life for planning purposes. Confirm the current support position for your specific version with Tridium or your OEM — support and security-update policies change, and the answer should come from the vendor rather than from a web page. What is not in question is the direction of travel: new development, new drivers and current security work target N4.

Can a JACE Running AX Be Upgraded to N4?

Sometimes. It depends on the controller model and its available memory and storage. Some JACE hardware supports an N4 upgrade path; some does not and must be replaced. This is the single most important thing to establish early, because it changes a software project into a project with field work, re-addressing and re-commissioning in it.

Establish it per controller, from the actual deployed hardware inventory — not from an assumption about what the site standard was supposed to be.

What Happens to AX Graphics in N4?

Conversion tooling will bring Px graphics across, and simple pages often survive well. What does not survive is anything that depended on the old plugin-based client, custom widgets written against AX-era APIs, or layouts built for a fixed workstation resolution. Those are rebuilt, not converted.

The honest planning assumption is that graphics are their own workstream with its own estimate. Treating them as a rounding error on the station conversion is the most common reason these projects overrun.

How Long Does an AX to N4 Migration Take?

There is no useful average, because the schedule is set by the inventory rather than by the station count. A single-station site with stock drivers and simple graphics can be done quickly. A multi-site estate with vendor-specific modules, custom AX graphics and controllers that cannot run N4 is a programme, not a project.

What makes an estimate credible is that someone has enumerated, per station: the Niagara version and build, every installed module and its N4 availability confirmed by the vendor, the controller model and its resource headroom, the graphics inventory, and every integration consuming data out of the station. Any timeline offered before that exists is a guess.

Migrating Without a Risky Cutover

Convert a copy of the station in a lab first and document the exact steps. Pilot on the least critical real site. Keep the AX station recoverable, with a tested backup and documented rollback, until the N4 station has run a full operational cycle including alarms, schedules and reports. Reversibility at every stage is what separates a migration from an outage.

Related services: Niagara AX to N4 migration services · graphics and dashboard rebuilds.