Niagara SDK (Software Development Kit)

The Niagara SDK is the toolkit behind every custom module and driver. Working in it well takes more than the API – it takes a build environment, module packaging, signing, and versioning discipline that most integrators do not want to maintain in-house. Software Pile does this daily.

SDK Work We Handle

  • Module development against the SDK for your Niagara version line, using Baja components, services, and drivers
  • Build tooling with Gradle and the Workbench SDK, reproducible across engineers and CI
  • Module packaging and third-party-certificate signing so modules install cleanly on secured stations
  • Version compatibility management and recompilation when you move Niagara versions

Delivered as Real Software

We treat Niagara modules like the production software they are: source-controlled, documented, signed, and versioned – not one-off JARs with no history. When you upgrade Niagara or hand the work to another engineer, the trail is there.

Describe the module or driver you need and your Niagara version. We will scope the build and the ongoing compatibility path.

What Is the Niagara SDK?

The Niagara SDK is the toolchain for building Niagara modules: the framework libraries, the build system, and the tooling needed to compile, package and sign a module so a station will load it. It is what turns Java source into a deployable .jar module that Niagara recognises.

N4 module builds use Gradle. Getting a working, repeatable build — correct dependencies, correct target version, signing configured, output that installs cleanly — is usually the first real task in any Niagara development project, and it is more involved than a standard Java build.

Why Do Niagara Modules Have to Be Signed?

Modern Niagara stations will not load unsigned modules. Signing establishes that a module came from an identified source and has not been altered since. It is a security control and it is not optional in current deployments.

The commercial implication matters more than the technical one: signing requires a certificate, and that certificate belongs to somebody. Establish before development starts who signs, who holds the key, what happens if the relationship with the developer ends, and whether you can rebuild and re-sign the module yourself later. Source code you cannot sign is source code you cannot deploy.

What Does a Niagara Development Environment Need?

  • A matching Niagara installation for the target version — the SDK is tied to a Niagara release.
  • A compatible JDK, as required by that release.
  • Gradle and a working module build configuration.
  • A signing certificate configured in the build.
  • A test station — ideally real target hardware, not only a local simulation, since resource behaviour differs.
  • Version control, which is startlingly often absent in Niagara projects and is the root of most “which version is deployed?” incidents.

What About Supporting Multiple Niagara Versions?

Most integrators run an estate spanning several Niagara releases, and a module built for one will not automatically load on another. That means either maintaining separate builds per target version or restricting a module to a defined version range and being explicit about it.

This is a specification question, not an implementation detail. Decide up front which versions must be supported over the expected life of the station, because it drives build configuration, testing effort and long-term maintenance cost more than any feature in the module.

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