If you work around building automation, you have heard the word JACE. It shows up in specs, on wiring diagrams, and in maintenance contracts, often without anyone explaining what it actually is. Here is the plain version: a JACE is the small but critical computer that makes a Niagara building system work at the edge — and understanding it makes the whole architecture click.
What a JACE Is
JACE stands for Java Application Control Engine. It is a compact, dedicated controller that runs a Niagara station — the software that connects to your field devices, runs control logic, stores trends and alarms, and serves the data upward. Physically it is a small device in a panel; functionally it is the on-site brain that keeps working whether or not anything above it is reachable.
That last point is the whole reason it exists at the edge. Because the JACE runs its logic locally, the building keeps operating — schedules run, alarms fire, control loops hold — even if the network or the central server goes down. Edge control means the building does not stop when the cloud does.
Where It Sits in the Architecture
A Niagara system is layered, and the JACE is the middle:
- Field devices — sensors, actuators, meters, and unit controllers, speaking BACnet, Modbus, and other protocols.
- The JACE — connects to those devices, normalizes their data, runs local control, and stores history. One JACE typically serves one building or one section of a large one.
- The Supervisor — the server tier that aggregates many JACEs into one view for an enterprise, campus, or portfolio, with central dashboards, reporting, and long-term data.
So a single building might have one JACE talking to a few dozen devices; a campus might have twenty JACEs rolled up under one Supervisor. The pattern scales by adding controllers at the edge and aggregating them above.
Why It Matters When You Are Planning a System
Two practical implications. First, JACE sizing and placement are real design decisions — how many devices each one carries, how the control logic is distributed, and whether a given model can run the Niagara version you need (a live concern for anyone still on older hardware facing an N4 upgrade). Second, because the JACE holds your control logic and integrations, how well it is configured and documented determines how maintainable the whole system is. A well-built JACE station is a pleasure to work on years later; a tangled one is a liability.
The Takeaway
A JACE is the edge controller that runs a Niagara station: it connects to your field devices, runs control locally so the building keeps working independent of the network, and feeds a Supervisor above it. Get the JACE layer right — sized, configured, and documented well — and everything built on top of it is easier.
SoftwarePile designs, builds, and maintains Niagara systems at every layer — JACE stations, Supervisors, and the integrations between them. Tell us about your building or portfolio and we will help you architect it properly.
The Three Connections to a JACE, and What Each One Proves
Three separate connections reach a JACE, and each one proves a different thing about it. Knowing which one failed narrows the problem before anyone opens a panel. One caveat before the list: recent N4 releases ship with the plaintext ports disabled, so Workbench reports a refused connection on 1911 or 3011 against a controller that is answering normally on its secure ports. Try 5011 and 4911 before driving to the site.
- Platform connection, TCP 3011 plaintext or 5011 over TLS. This talks to the platform daemon, not to the station, and it authenticates against a platform user account held by the host rather than against station users. It answers even when the station is stopped, which is what makes it the path for commissioning, license and certificate installation, module installs, TCP/IP and time settings, and backups.
- Fox connection, TCP 1911 plaintext or 4911 over TLS. This is Workbench talking to the running station, authenticated against the station's own user service. It is also the link a Supervisor uses to pull data from the JACEs beneath it, which is why a firewall rule that misses it produces a Supervisor with empty views and healthy controllers.
- HTTP or HTTPS to the station web server, port 80 or 443. This proves the web service is enabled and serving pages. A station can be entirely healthy over Fox and still return nothing in a browser because the web service is disabled or the certificate is not accepted by the client.
What the Field Side Has to Agree On Before Discovery Works
A JACE discovers devices; it does not invent addresses for them. Every device on a trunk needs an address that is unique in the scope its protocol defines, and getting that wrong is a common self-inflicted fault. BACnet device instance numbers have to be unique across the whole internetwork rather than just the local segment, with the range running 0 to 4194302, and two devices sharing an instance will appear and vanish from discovery depending on which one answered last. Modbus slave IDs only have to be unique per trunk, range 1 to 247, but a duplicate there returns plausible looking data from the wrong device instead of an error, which is worse.
- BACnet device instance numbers, or Modbus slave IDs, per device.
- The vendor register map for every Modbus device: which addresses are holding registers and which are input registers, the data type and word order of anything wider than 16 bits, and the scaling factor. Modbus carries none of this on the wire, so none of it is discoverable.
- The points list with engineering units, so a value arriving as 725 lands as 72.5 degrees F rather than a raw count sitting in a trend nobody can interpret two years later.
- Serial trunk parameters: baud rate, parity, and stop bits, plus the Max Master setting for BACnet MS/TP. Max Master has to be at least the highest MAC address in use on that trunk, or the devices above it never receive the token and never appear at all.
Reading a Point That Is Not Working
Niagara does not simply mark a point good or bad. The status flags on a proxy point narrow a fault to a layer before anyone puts a meter on a wire, and the four you see most are distinguishable from each other by what they imply about who answered.
One aggregation rule saves a lot of wasted time here. A device marked down carries all of its points down with it, so a screen full of down points is usually one device or one trunk rather than fifty broken points. Work up from the device, not across from the points.
- Down: the driver's device level health check is failing. The device is not answering at all, so the suspects are the address, the wiring, the trunk parameters, or the device's own power.
- Fault: the device is reachable and rejected the request. That means an object or register that does not exist, a data type mismatch, a write to a read-only address, or a license limit refusing to bring the point online.
- Stale: the value is real but is no longer being refreshed inside the subscription's tolerance. This points at a saturated poll scheduler rather than a broken device. Niagara drivers poll on tuning policies with fast, normal, and slow rates, and when a trunk is oversubscribed the symptom is late graphics and stale points, not dead ones.
- Null: no value has ever been received. On a new integration this usually means the point was created from a template or a spreadsheet import and its address never matched anything on the device.
Versions, Certificates, and What Does Not Carry Forward
Every N4 controller presents a server certificate for its platform and Fox connections, self-signed on first boot unless it is replaced. Workbench and browsers keep warning or refusing until that certificate is approved into the client's trust store or reissued from your own CA. Certificates also expire, so a controller that has run untouched for years can stop accepting connections on a specific date while the station itself is still running and controlling the building normally.
Workbench has to be at least the version of the platform and station it connects to. An older Workbench against a newer station is not a supported combination and tends to fail in ways that look like a network problem. The same rule runs upward: keep the Supervisor at or above the version of the JACEs reporting into it, which is why version planning is a system decision rather than a per-controller one.
The AX to N4 move is a conversion rather than an upgrade in place. Station databases convert one way only, custom modules and drivers written against the AX API have to be recompiled against the N4 API and in practice partly rewritten, and Px graphics come across but usually need rework. Older QNX based JACE hardware does not run N4 at all, so for that generation the question is hardware replacement, not a software project.
When the JACE Layer Is Not Buying You Anything
A JACE earns its place when you need local logic, local history, scheduling, alarming, or a user interface that survives on its own. It is expensive overhead when all you need is a data path. If the requirement is only to get points from a BACnet/IP or Modbus TCP system onto a dashboard, and nothing has to keep running while the server is unreachable, a Supervisor with direct IP drivers or a protocol gateway does the same job with one less device to license, patch, and back up.
What that arrangement gives up is edge survivability, and specifically the history. A JACE keeps collecting trends through a WAN outage and backfills to the Supervisor when the link returns, while a direct connection from the server leaves a gap in the data for the length of the outage. The question is not device count on its own: a 400 point building that is only being monitored may not need a JACE, while a 30 point building running a chiller sequence does.
Frequently Asked Questions
Is a JACE a PLC, and does it have inputs and outputs?
No. The base controller has no onboard I/O, and physical points normally arrive over a network trunk rather than off the controller itself. Where local I/O is genuinely needed, it comes from expansion modules that attach over a serial expansion trunk. A JACE is also not a substitute for an equipment controller: sequence logic that has to execute on a millisecond scale, such as an actuator's own loop, belongs in the device that owns the actuator, not in a station polling it over MS/TP.
What does a JACE need on the network before it can do its job?
A static IP address or a reservation, with the subnet and gateway settled, plus firewall rules that let the Supervisor reach it on the secure Fox port. It also needs a time source. The station timestamps its own histories and runs its own schedules, so a controller with a drifting clock produces trends that will not line up with anything else at the Supervisor and schedules that fire at the wrong hour. Point NTP at the same server the rest of the site uses, and set the time zone at the platform rather than only inside the station.
What does the site have to have ready before commissioning?
The physical work comes first: RS-485 trunks landed on the correct terminals with consistent polarity, terminated at both ends of each run and biased at one point on the segment, and panel power the controller will actually run on rather than a temporary cord. On the network side, the IP addressing decided and the firewall rules already in place, since these usually involve someone outside the mechanical trades. Administratively, a license entitlement and access to the panel during the hours the work is scheduled. A controller powered on a bench with no trunk attached can be commissioned as a platform, but nothing beyond that.
How does a JACE integration actually proceed, in order?
Platform first: connect to the controller, install the Niagara distribution matching the version the rest of the system runs, install the license and certificate, and set the IP address and time. Then create or restore the station and start it. Then add the driver network, run discovery, and add devices and points, because logic and graphics cannot be bound to points that do not exist yet. Control logic, histories, alarms, and graphics follow, and the join to the Supervisor comes last, since that step assumes everything below it is already stable.
How many devices can one JACE handle?
There is no single number, and device count is the wrong unit to think in. Two limits apply independently: what the license permits in points, devices, and histories, and what the trunk and poll scheduler can service within the update rate the sequences and graphics actually need. A JACE well under its licensed point count will still show stale values if an MS/TP trunk carries more devices than it can poll at the fast rate. The driver's poll statistics answer this question directly, and they answer it before anyone complains about a slow graphic.
What is in a JACE backup, and what is lost if the controller dies?
A platform backup produces a .dist file holding the station database along with the platform configuration, which is what you want when rebuilding a controller. A station save or a .bog export is narrower: it is the station database only, useful for offline editing but not a full restore. Either way, everything accumulated since the last backup is gone, and that means histories and alarm records, which is why backup discipline matters. Nothing on the Supervisor substitutes for it, because the Supervisor holds imported history rather than the JACE's own configuration.
Workbench will not connect. How do I tell what is actually wrong?
Work up the stack rather than guessing. If the host does not answer a ping, it is power, the switch port, or the IP configuration, and nothing on the Niagara side is in play yet. If the platform connects but Fox does not, the controller is fine and the station is stopped or failing to start, so open the Application Director and read the station output, where a start failure usually names its own cause, most often a module missing at the version the station expects or a license limit being hit. If Fox connects and only the browser fails, you are looking at the web service or the certificate rather than the station.