Niagara Edge / JACE Controllers

The JACE is where Niagara meets the equipment. These edge controllers run stations close to the mechanical systems, talking to field devices over BACnet, Modbus, and the rest, then feeding a Supervisor above. Software Pile develops for JACE and Edge controllers with their real constraints in mind: finite memory, finite CPU, and no tolerance for a station that wedges at 2 a.m.

Development Within Edge Constraints

Code that runs fine on a Supervisor can starve a JACE. We size histories, poll cycles, and logic for the controller’s actual capacity, watch resource headroom, and build modules that fail safe rather than taking the station down. Licensed capacities and host IDs are part of the plan from the start.

What We Deliver on Controllers

  • Field integration: BACnet, Modbus, MQTT, and custom drivers for equipment on the controller’s networks
  • Local control logic and sequences that keep running if the network above goes dark
  • Edge data buffering so histories survive WAN outages and sync when the link returns
  • Migration of stations between controller generations and Niagara versions

Tell us your JACE model and Niagara version – and the field devices it needs to reach.

What Does JACE Stand For?

JACE stands for Java Application Control Engine. It is the family of Tridium edge controllers that run a Niagara station at the equipment level — connecting to field devices over BACnet, Modbus, LonWorks and other protocols, executing control logic locally, and holding history and alarms.

The defining characteristic is local autonomy: a JACE keeps controlling its equipment when the network is down and when the Supervisor is unavailable. That is why control logic belongs on it rather than upstream.

What Is the Difference Between a JACE and a Supervisor?

A JACE is embedded hardware at the edge, sized for controlling equipment: modest storage, limited concurrent users, protocol connections to field devices. A Supervisor runs on server or virtual hardware and exists to aggregate across controllers — long-term history, estate-wide reporting, consolidated graphics and many simultaneous users.

Asking a JACE to serve many users or hold years of history is a common cause of unexplained slowness. Asking a Supervisor to run building control is a common cause of avoidable outages.

Can My JACE Run Niagara N4?

It depends on the model and its resources, and it is the single most important thing to establish before planning a migration. Some JACE hardware has an N4 upgrade path; older models do not and must be replaced, which converts a software project into one with field work, re-addressing and re-commissioning in it.

Establish this per controller from the deployed hardware inventory rather than from the site standard, because estates accumulate exceptions. Finding an unsupported controller during planning is an inconvenience; finding it during a cutover weekend is not.

How Do You Size and Deploy Edge Controllers?

  • Point count and protocol load — how many devices, on which networks, polled how often.
  • Local history — what must be retained on the controller versus archived to the Supervisor.
  • Resource headroom — sizing to today’s point list with nothing spare guarantees a problem at the first extension.
  • Network position and security — how it is reached, by whom, and whether remote access is controlled or has quietly become permanent.
  • Standardisation — consistent configuration across controllers is what makes an estate maintainable and makes tooling possible.

Related services: migration and hardware assessment · BAS integration services.