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.

Four Resource Ceilings, and Telling Them Apart

Resource headroom is not one number. A station has four independent ceilings, they are consumed by different things, and a controller that is comfortable on three can be pinned against the fourth. Treating them as a single "the JACE is slow" symptom is what turns a half hour of diagnosis into a week of guessing.

The measurement that separates them is heap over time against engine cycle time. If cycle time is climbing while heap stays flat, the problem is work: poll load, a driver waiting on a slow device, or a program object doing network I/O or a sleep on the engine thread, which stalls every other component behind it. If heap is climbing between collections and the pauses are getting longer, the problem is retention: an oversized history cache, a leak in a module, or subscriptions that are never released. Those two have opposite fixes, and the license and file system ceilings below do not present as slowness at all.

  • Heap memory. The JVM heap the station runs in. Progressive slowdown, then pauses, then an out of memory entry in the station log and a restart. Read it over hours, not from a single snapshot.
  • Resource units. Niagara 4's own accounting of what the station holds, visible in the Resource Manager and also written as a limit on the license. It refuses at the moment you add the component. It does not degrade first.
  • File space. Histories, logs, alarm records and backups all land on the same flash. Symptoms are history gaps and alarms that do not persist while the station otherwise looks healthy.
  • Engine cycle time. How long one full pass of the station takes. Stale point values, late alarms, schedules that fire a beat behind, and memory sitting flat throughout.

Where the Field Buses Actually Bite

BACnet MS/TP is a fixed pipe, and adding points does not widen it. Every device on the segment has to agree on baud rate, and at 9600 or 38400 baud a segment carrying a few hundred points cannot be polled quickly no matter how the JACE is configured. Max Master has to be set at or above the highest MAC address actually in use, or the token spends bandwidth searching for masters that are not there. A duplicate MAC address on a segment produces the worst class of symptom: intermittent, moving between devices, and clearing whenever someone is watching.

BACnet/IP fails differently. Discovery is broadcast based on UDP 47808, and Who-Is does not cross a subnet boundary, so a routed network needs a BBMD, and a BBMD carrying a stale broadcast distribution table is the usual cause of "half the devices appear." Foreign device registration carries a time to live that has to be renewed, so a device can enumerate correctly at commissioning and quietly stop hours later. Modbus has no discovery at all: the register map comes from a document, the protocol is zero based while most vendor documentation is one based, and a 32-bit value spans two registers whose word order is a vendor choice. Wrong word order reads a plausible number rather than failing, which is why it survives commissioning.

How Licensing Actually Binds to the Box

A Niagara license is issued against the host ID of one specific controller, a string derived from the hardware and readable from the platform before a station is ever installed. The license and its companion certificate authorize a named set of capabilities on that host and nothing else. Restore the same station onto a replacement JACE and it will not start until a license is issued against the new host ID. That is the step in a hardware swap with no technical workaround.

Brand matters as much as capacity. Stations carry a brand ID, and a controller runs stations under the brand it was licensed for, which decides which stations and which Supervisor can join a NiagaraNetwork without licensing work first. This is why an estate that grew through several vendors needs its licensing established before consolidation is scoped, not during it. Read the whole license file, not just the expiration.

  • Host ID, which ties the file to that physical controller.
  • Brand ID, which decides what the station can federate with.
  • The expiration date, which governs which Niagara builds the host will accept, independently of whether the current station runs.
  • Driver entries, which determine whether BACnet, Modbus or a given vendor driver is enabled at all.
  • Device and point capacities, and the resource unit limit, all of which are hard ceilings rather than performance guidance.

What Buffered History Costs You When the Link Returns

Buffering has a size, and the size is a policy you set. Each history has a capacity, either unlimited or a record count, and a full policy that either rolls the oldest records off or stops collecting. If the outage outlasts the buffer, the oldest records are gone, and nothing in the reconnect reports that it happened: the archive simply has a gap where the interval was longest. Size the buffer against a realistic worst-case outage for that site's link, not against a normal week.

Timestamps are the other half. History records are stamped by the controller's clock, so a JACE with no working time source writes records that land in the wrong place in the Supervisor's archive, sometimes ahead of current time, and re-syncing later does not correct records already written. Set a time source at the platform rather than relying on the timezone being right. Reconnection itself can also fail on trust rather than on network: Niagara 4 connections run over TLS, on Fox port 4911 and platform port 5011 rather than the older plaintext 1911 and 3011, and an expired platform certificate stops the link with a handshake error while ping and traceroute look perfectly healthy.

When a Station at That Location Is More Than the Job Needs

Not every location needs a station. The alternative is a protocol gateway that maps Modbus registers into BACnet/IP objects and does nothing else. It is cheaper to buy and cheaper to own, but it holds no history, so an outage between it and the Supervisor leaves a gap in the trend that nothing can back-fill afterward, and it leaves nowhere to put logic later without reopening the decision. A station earns its place when at least one of the conditions below is true, and pays for itself in maintainability when two or more are.

  • Control logic has to keep running while the link upstream is down.
  • History has to survive an outage at the location rather than being collected upstream.
  • More than one protocol has to be normalized before anything above sees it.
  • A firewall boundary is better held by one auditable device than by a field bus full of them.

Frequently Asked Questions

Is a JACE the same thing as a PLC?

No. A JACE is a supervisory and integration controller: it runs a Java virtual machine, hosts a Niagara station, and speaks field protocols to the equipment controllers below it. Its engine cycle is measured in hundreds of milliseconds to seconds, which suits sequences, schedules, setpoint resets, alarming and history, and does not suit interlocks or safeties that must act within a scan. Those stay in the equipment controller, with the JACE as the layer above it rather than a replacement for it.

What has to already exist before development starts on a live controller?

Reachability and credentials for both the platform and the station, which are separate account systems and are often held by different people. Beyond that: the Niagara version and build number as deployed, the license file with its capacities, and a device inventory that matches what is actually in the field rather than what the drawings say. A platform backup taken before anything changes is the last prerequisite, since it captures the station and platform configuration for that host and is the only clean way back.

How does new code actually get onto a JACE?

Modules are JAR files installed at the platform level, not inside the station, and they are pushed to the host with the Software Manager in Workbench. The station restarts to pick them up, so the restart is part of the deployment rather than an accident of it. A module built against one Niagara major version will not load on a station running another, so the build target is fixed by the controller you are deploying to, not chosen.

Can a JACE send data to a cloud service directly?

Yes, over a connection the controller initiates outbound, typically MQTT over TLS on port 8883 or HTTPS on 443, so no inbound firewall rule at the site is required. What has to exist first is name resolution and permitted egress from the controller's VLAN, plus a trust chain the controller will accept. Publish interval deserves more attention than it usually gets: every point at a short interval from every controller can exceed what the site's uplink has spare, and the controller absorbs the backlog.

What do we have to decide rather than you?

Four decisions belong to the owner because they encode policy rather than engineering. Which controller owns which points where equipment spans more than one JACE, because that assignment decides what is a local reference and what becomes a NiagaraNetwork proxy point with a network hop behind it. Which Niagara brand the estate's licenses sit on, settled before any consolidation is scoped, since brand governs what can federate with what. Whether a cloud or MQTT link is export only or may write back to equipment. And who may approve a station restart and inside what window, since module installation and some platform changes require one.

Does moving to N4 change the graphics?

Usually, at least in part. Niagara 4 serves Px pages to browsers through an HTML5 profile instead of the Java applet that browsers no longer run, so pages built around older widgets or embedded Java can render differently or not at all. The Px files migrate with the station, which means the question is per widget rather than per page, and a page can look correct in Workbench and still be wrong in a browser. Treat graphics review as a separate line of work from the station conversion.