Niagara Workbench

Workbench is where Niagara engineers spend their day – and most of them are doing something repetitive that a tool could do faster. Software Pile builds Workbench extensions and engineering utilities that turn hours of clicking into minutes of review.

Tools We Build

  • Bulk operations – mass tagging (including Project Haystack), renaming to naming standards, point re-parenting, and property edits across whole station trees
  • Station audits – automated checks against your engineering standards: orphaned points, missing histories, alarm classes without routing, license headroom
  • Custom views and managers – purpose-built Workbench views for tasks your team does constantly that the stock views make slow
  • Deployment utilities – checklist-driven station commissioning, config export/compare between stations, and pre-cutover validation
  • Migration helpers – inventory and readiness tooling for AX-to-N4 moves

Why Integrators Commission These

The math is simple: a tool that saves each engineer an hour a week pays for itself across a team in a quarter – and it encodes your standards, so quality stops depending on who did the work. Tools are built as proper signed modules, versioned, and documented for your engineering group. White-label delivery for integrators is standard.

Start With the Bottleneck

Describe the task your engineers grumble about – what it involves, how often, on which Niagara versions. We will tell you what a tool would look like and what it would save.

What Is Niagara Workbench?

Workbench is the engineering tool for the Niagara Framework. It is the desktop application used to build and configure stations: wiring logic on the wiresheet, configuring drivers and points, building Px graphics, managing users and permissions, setting up histories and alarms, and provisioning controllers. Operators generally use a browser; engineers use Workbench.

It is also a platform in its own right. Workbench can be extended with custom views, tools and wizards, which is what makes it possible to automate engineering work that would otherwise be done by hand across hundreds of points.

What Is the Difference Between Workbench and Workbench Web?

Workbench is the full desktop engineering environment with the complete toolset. The browser-based experience is aimed at operational and lighter configuration tasks and does not replace it for engineering work — module development, wiresheet engineering at scale and platform-level provisioning belong in the desktop tool. Check what your Niagara version and licence actually permit, as capabilities differ by release.

What Can You Build as a Custom Workbench Tool?

Anything repetitive an engineer currently does by hand is a candidate. In practice the tools that pay for themselves fastest are:

  • Bulk tagging and point naming — applying a naming or Haystack tagging standard across thousands of points instead of one at a time.
  • Station audits — reporting on points with no history, alarms with no recipient, disabled devices, duplicated logic, or drift from the site standard.
  • Deployment and provisioning utilities — pushing a standard configuration to many controllers consistently.
  • Migration helpers — mapping and validating changes during an AX to N4 migration.
  • Import and export tools — getting engineering data in and out of spreadsheets or an asset system without manual re-keying.
  • Commissioning checklists — verifying a station against a standard before handover and producing the evidence.

Which Workbench Version Do You Need?

Workbench version must be compatible with the stations you are connecting to, and a tool built for one Niagara release will not automatically load in another. If you support an estate spanning several Niagara versions — which most integrators do — version compatibility is part of the tool’s specification, not an afterthought. Tools are built and signed against defined target versions, and retesting is part of any station upgrade.

Is a Custom Tool Worth It?

The arithmetic is usually straightforward: multiply the time a task takes by how often it happens across your estate, and compare it to a bounded development effort. A tagging task that takes an engineer two days per building, repeated across twenty buildings, is a clear case. A task done once a year is not.

The second argument is consistency rather than time. A tool applies the same standard every time; a person working through a point list at 5pm does not. For anything that feeds reporting, analytics or a tagging model, that consistency is often worth more than the hours saved.

Related services: Niagara engineering tools · custom module and driver development.

How Workbench Connects to a Host: Platform and Station Are Two Connections

Workbench opens two different connections to a host, and confusing the two is a common cause of "cannot connect" reports. A platform connection talks to the platform daemon on the host and is how you install software, manage licenses, set the TCP/IP settings, take a station backup and start or stop the station. A station connection talks to the running station over Fox and is how you reach the component tree, the wiresheet, points, histories and alarms. They use different ports and different credentials: platform credentials are host level accounts held by the daemon, station credentials are users inside the station database.

That split is also the fastest diagnostic. The daemon answers whether or not the station is running, so if the platform connection opens and the station connection does not, the host and the network path are fine and the problem is the station: stopped, failed to start, listening on a port you are not using, or refusing the station user. Open Application Director on the platform connection and read the station output. If neither connection opens, the problem is upstream of Niagara entirely, in a firewall rule or the daemon itself.

Niagara 4 defaults both connections to TLS. On first connect the host presents its own certificate and Workbench asks you to approve it, and that approval is remembered in Workbench certificate management. After a host rename, a controller swap or a station rebuild the certificate changes, and the connection then fails with a certificate error rather than a login error, which is worth recognizing before anyone starts resetting passwords. The default listeners are the first thing to check on a hardened site or behind a firewall rule someone else wrote.

  • Platform over TLS listens on 5011. The older plain platform port 3011 still exists in legacy configurations and is normally disabled.
  • Fox over TLS listens on 4911. The plain Fox port is 1911.
  • The station web server defaults to 443 for https, with plain http off.
  • A tool that only reads and writes points needs a station account, not a platform account. Asking for platform credentials when the tool never installs software or touches the license is a scope error worth catching in the specification.

What the Stock Tools Already Cover

Before scoping a tool it is worth being precise about where the stock features stop, because five of them already cover part of what people ask a custom tool to do: the Batch Editor, BQL, the Provisioning Service, tag dictionaries with their auto tagging rules, and station templates.

Scoping a tool to the gap between those features rather than to the whole task keeps it working across upgrades, because it depends on less of the stock user interface. A tool that runs a BQL query to build its list and then does the one thing BQL cannot do survives an upgrade far better than one that reimplements the query builder around it. Custom work earns its place where these features run out: a rule a query cannot express, a round trip through a spreadsheet, a change that has to be reviewed before it is committed, or a job that has to run the same way on forty stations.

  • Batch Editor edits properties across a multi selection. It works on properties the selected components have in common, it does not create, delete, rename or re-parent anything, and you still have to gather the selection yourself.
  • BQL reads. It is the fastest way to build an inventory of what is actually in a station and it exports to a table, but it is a query language with no update side, so anything the query finds is still fixed by hand.
  • The Provisioning Service runs its fixed set of batch job types against the stations in a Niagara Network: software install and upgrade, station backups, running a BQL query, syncing tag dictionaries. It is a licensed feature, and its job types are what they are. A step it does not have is not a step you can add to it.
  • Tag dictionaries and auto tagging rules apply tags by rule instead of by hand, but the rules match on type, name and path, so they inherit whatever naming the station already has. They cannot repair the inconsistency they key off.
  • Templates stamp a saved component subtree into another station with parameters substituted. They help with equipment built from now on. They do not reconcile equipment already built by hand across different years by different engineers.

Where the Code Runs: Workbench, Station, or Browser

A Niagara module can put code in three places, and the module file names say which: a runtime part that loads in the station, a Workbench part that loads only in the desktop tool, and a browser part for the HTML5 profile. That choice decides what the tool can reach, when it can run and whether anyone has to be logged in for it to do anything.

A Workbench side tool does its work through the open Fox connection, so every read and write is a round trip. A bulk job is bound by latency rather than by processing, and the same operation that finishes in seconds against a Supervisor on the local network can take an hour against a controller at the end of a slow VPN. Bulk tools therefore need batching, a progress indicator and a cancel that leaves the station in a defined state. A station side service does the same work locally and can be scheduled, so it runs overnight with nobody connected. The cost is that it has to be installed on every host that needs it, and it restarts when the station restarts.

Permissions follow the same split. A Workbench tool acts as the station user who is logged in, so it can do nothing that user's role does not already permit, which is usually the right constraint. A station side service runs as part of the station. The host also has a say: a platform's runtime profile determines which module parts it will accept, so a Workbench only module is not installable on a controller that carries the runtime profile alone.

  • The rt part holds types and services that run in the station. Workbench loads it too, so that it can see and edit those types.
  • The wb part holds views, managers and wizards, anything with a Workbench user interface. It never runs on a controller.
  • The ux part holds the browser side code for the HTML5 profile, which is what an operator sees rather than an engineer.

AX to N4: What the Conversion Does Not Carry

The conversion itself runs from an AX backup using the migration tool that ships with Niagara 4 Workbench, not against the live station, and AX stations are normally brought up to 3.8 first because that is what the tool expects to read. The component tree, control logic, most driver configuration and history data come across. The work is concentrated in what does not.

Niagara 4 enforces stricter rules on slot names, so the migrator escapes characters that AX allowed. The slot name changes while the display name is preserved, which means the converted station reads correctly in the nav tree and fails quietly anywhere something addressed a point by path.

Custom and third party AX modules do not load in N4 at all. They have to be rebuilt against the N4 API and signed, and where a third party never shipped an N4 version of a driver, that integration is replaced rather than migrated. Hardware is the other hard stop: N4 does not run on JACE-2 or JACE-6 class controllers, so those sites are a hardware replacement with a station conversion inside it. The items below are where rework tends to appear after a conversion that otherwise looked clean.

  • Slot path references break in specific forms: Px bindings written as absolute ords, ords stored inside string properties such as report parameters and saved queries, points imported into a Supervisor by path, and a BACnet or Modbus export table whose object names were derived from the point names rather than typed in.
  • Px graphics convert, but the AX web profiles used to view them do not. The Java applet profiles have no N4 equivalent, and Hx, which Niagara 4 kept for backward compatibility, is deprecated and being removed across releases. An AX site whose operator screens depended on either is planning for the HTML5 profile.
  • User accounts convert but passwords do not, and N4 applies its own password rules and role model on top. The permission review is manual work to be scheduled, not a step a tool performs for you.
  • History identifiers carry the station name. Renaming the station during the move orphans the existing trend data, so the rename is a decision to make before the conversion, not after.
  • Licensing is per host id. An N4 host needs its own N4 license and certificate; the AX license does not carry across.

Frequently Asked Questions

Is a Workbench extension the same thing as a custom driver?

No. A driver implements a protocol so that a station can talk to equipment it could not talk to before. A Workbench extension changes how an engineer works on a station whose drivers are already in place. They are built with the same module structure and can ship in the same jar family, which is why they get confused. The test is simple: if the points do not exist because nothing speaks the protocol, that is driver work; if the points exist and managing them is the bottleneck, that is tool work.

Does the tool run inside Workbench or inside the station?

Either, and it is the first thing to settle. A Workbench side tool is a view or wizard an engineer opens against a connected station, which suits interactive work where a person reviews and approves what is about to change. A station side service runs in the station itself, which is what you need when the job has to run on a schedule, run with nobody logged in, or run identically on every host in an estate. Settling this first matters because it decides the module split and usually the whole design.

What has to already exist before tool work can start, and what do you need from us?

Three things: a station to work against, the Niagara releases in scope, and the written rule the tool is meant to enforce. The station can be a restored copy rather than the live site, and a copy is preferable while anything is being written for the first time. The written rule is the usual blocker, because teams know their naming or tagging standard well enough to apply it by hand and have never had to state it precisely enough for code. For access, expect to provide a VPN or jump host route, platform and station accounts scoped to what the tool actually does, and a window in which writes are allowed.

How does a finished module get installed?

A Workbench side module is a jar placed in the Workbench modules directory on each engineer's machine, and Workbench is restarted to load it. A station side module is installed through the platform's Software Manager and takes effect when the station restarts, so anything doing live control needs an outage window. The signing certificate also has to be trusted on the host; if it is not, the platform flags the module at install even though the file itself is intact. The first install belongs on a test station or a restored copy rather than on the site.

What stops a bulk tool from wrecking a station?

A report pass before the write pass. A bulk tool should be able to run in a mode that produces exactly the list of changes it would make, so the change set is reviewed as a table before anything is committed. Beyond that, a station backup or a BOG export of the affected subtree is the rollback, because Niagara has no transaction spanning a few thousand slot writes and an undo would have to be a second pass carrying the old values. Writes go in batches, with a cancel that stops between batches rather than halfway through a rename.

When is a custom tool the wrong answer?

When a stock feature reaches the task, and when the work is genuinely one time. A single station needing a one off cleanup is usually faster as a BQL export, a spreadsheet review and a Batch Editor pass than as a module, with no build, no signing and no version testing behind it. A recurring report is often a saved query and a hierarchy rather than a view someone has to write and maintain. The case for code appears when the task repeats across an estate, has to produce the same result every time, or needs a step no stock feature performs.