Platforms

Software Platforms and Niagara Tridium Development

Software Pile develops and integrates modern software platforms for organizations across the United States and internationally, including Niagara Tridium framework projects, Honeywell Niagara N4 custom modules, Workbench extensions, supervisor workflows, APIs, cloud platforms, and enterprise integrations.

Our team supports platform planning, architecture, custom module development, documentation, testing, deployment, and long-term support for business, facility, security, energy, and building automation systems.

Platform Capabilities

Full-Stack Niagara Development Expertise

Advanced Niagara N4 programming led by a Tridium-certified Niagara Full Stack Developer with NCPD Drivers and NCPD User Interface credentials. Credential verification is available upon request for qualified enterprise clients.

We support custom Niagara modules, custom drivers, Niagara SDK work, Workbench tools, BQL reporting, dashboards, APIs, database integrations, station health checks, BAS/BMS integrations, and Niagara modernization projects.

Software Pile Platforms Software Coverage

Software Pile platform specialists work with Niagara N4, Baja API, Workbench SDK concepts, cloud platforms, ERP and CRM systems, CMS platforms, ecommerce platforms, and API-first enterprise systems across. View complete regional service coverage.

Which Layer of the Niagara Stack Does Your Problem Live In?

Workbench is the engineering tool. The station is the runtime that holds the object model and runs the logic. A Supervisor aggregates stations, holds long-term history and serves the wider user base. JACE and Edge controllers sit in the field, close to the equipment and doing the work that must keep running when the network does not.

Deciding which layer a change belongs to answers most architecture questions on its own. Control that must survive a WAN outage belongs at the edge. Cross-site reporting belongs at the Supervisor. An engineering shortcut that saves your team time every job belongs in Workbench, which is what the Workbench SDK exists for.

Cloud Platforms Are Destinations, Not Replacements

Azure and GCP show up in building projects as places building data goes, with MQTT and REST as the usual transports. What generally stays on premises is control. What travels is telemetry, alarms and history for analytics, reporting and portfolio comparison.

Designing that boundary deliberately avoids the two familiar failure modes: a building that stops responding sensibly when the internet drops, and a cloud project that quietly becomes load-bearing for daily operations without anyone deciding it should be. The MQTT page covers the transport-level detail, including what the station does while a link is down.

ERP, CRM and the Systems That Own Assets

Integrating with SAP, Oracle or a maintenance system usually turns into a naming problem. The station knows AHU-3 on the third floor. The asset system knows an equipment ID assigned during construction. Nothing links them until somebody builds and maintains a mapping, and that mapping ages every time equipment is replaced.

An alarm that raises a work order is straightforward to build and easy to get wrong. Decide first which alarms deserve a ticket, what happens when the same fault reappears before the last ticket closed, and who reconciles the asset list when a unit is swapped.

Versions, Signing and Compatibility

Modules are compiled against a specific Niagara version. A module built for one N4 release may need rebuilding and retesting for another, modules are signed, and licensing is tied to host identity. A fleet running a mix of versions is normal, and it has direct consequences for anything custom you deploy across it.

The practical advice: before assuming any module drops into any station, confirm the versions actually running in your estate. Software Pile settles version compatibility early in scoping for that reason. Our Niagara work is led by a Tridium-certified Niagara Full Stack Developer, with Niagara Certified Professional Developer (NCPD) credentials in Drivers and User Interface, and Niagara 4 Developer certification. Niagara, Azure, GCP, SAP and Oracle are named on this page as systems we work with, and no partnership, authorization or endorsement is implied.

Drawing the Boundary

The recurring question on integration projects is how much logic sits inside the station and how much sits outside. Inside means it keeps running when connectivity fails and it is visible to engineers in Workbench. Outside means easier development, easier scaling, and a dependency on a network path.

There is no universal answer, but there is a useful test: ask what the building should do if the outside system disappears for a day. If the answer is unacceptable, the logic belongs inside. If you want that boundary examined against your own estate, describe the systems involved and the versions you run.