Building Automation & Unified Security Platform

Modern commercial buildings contain 15-25 independent building subsystems—HVAC, lighting, fire alarm, access control, video surveillance, elevator, shade control, irrigation, metering, generator, UPS—each with its own controller, protocol, management software, and vendor support contract. These systems were designed and installed by separate trades with no coordination layer, resulting in operational silos where the HVAC system has no knowledge of occupancy data from access control, lighting schedules ignore real-time vacancy information from video analytics, and security events cannot trigger building-system responses like elevator recall or HVAC isolation.

The lack of cross-system data integration means that buildings operate on static schedules rather than real-time demand. HVAC conditions spaces that are unoccupied, lights illuminate empty floors, and security systems treat all zones identically regardless of building operational mode. Building engineers estimate that 25-40% of commercial building energy consumption is wasted on conditioning and illuminating unoccupied spaces during nominally occupied hours. Beyond energy waste, the inability to correlate data across systems masks fault conditions—a VAV box that stops responding to commands is invisible to the access control team that observes the associated space is uncomfortably warm.

Integration attempts using proprietary vendor platforms create lock-in: a Johnson Controls Metasys installation integrates well with other Johnson Controls products but poorly with Lenel access control (now also JCI-owned but on a different software stack), Axis cameras, and Lutron lighting. Open protocols like BACnet and Modbus provide device-level interoperability but no application-level integration, analytics, or workflow automation. The building operator is left with protocol connectivity but no operational intelligence.

We deploy a Niagara 4 (Tridium) framework as the integration middleware, leveraging its protocol-agnostic driver architecture to normalize data from BACnet/IP HVAC controllers, Modbus TCP/RTU power meters, KNX lighting systems, ONVIF cameras, OSDP access control panels, and OPC UA industrial controllers into a unified object model. Each physical point—temperature sensor, door contact, luminaire, meter register—becomes a Niagara component with standardized metadata (point type, engineering units, location, system association) that enables cross-system queries and automation logic regardless of the underlying protocol.

The automation layer implements event-driven rules that span system boundaries. When the last badge-out event occurs in a zone and video analytics confirm zero occupancy for 15 minutes, the platform commands HVAC to setback mode, dims lighting to security-only levels, and escalates the zone to unoccupied security monitoring with enhanced motion sensitivity. When the first badge-in occurs the following morning, HVAC pre-conditioning begins based on the predicted occupancy pattern from historical access control data, and lighting ramps to scheduled levels. These cross-system automations are defined in a graphical programming environment (Niagara Workbench) and execute on the local JACE controller, ensuring continued operation during WAN outages.

Analytics and fault detection use time-series data exported from Niagara to InfluxDB, visualized in Grafana dashboards customized for each stakeholder: energy managers see consumption trends and demand response readiness, facility engineers see equipment performance baselines and fault conditions, and security directors see integrated security posture views. An automated fault detection and diagnostics (AFDD) engine applies ASHRAE Guideline 36 rule sets to detect equipment faults—stuck dampers, failed sensors, simultaneous heating and cooling—and generates prioritized work orders in the client's CMMS platform.

BACnet integration uses BACnet/IP (ASHRAE 135-2020) with the Niagara BACnet driver acting as both a BACnet client (reading/writing points on third-party controllers) and a BACnet server (exposing Niagara points to other BACnet clients such as the fire alarm system's BMS interface). Device discovery uses BACnet Who-Is/I-Am with configurable BBMD (BACnet Broadcast Management Device) for cross-subnet discovery. Each BACnet object (analog input, binary output, multi-state value) is mapped to a Niagara proxy point with configurable polling intervals (default 15 seconds for analog values, COV subscription for binary status changes). COV (Change of Value) subscriptions use confirmed notifications with a 60-second re-subscription interval, reducing network traffic by 80% compared to polling for binary points that change state infrequently.

The occupancy inference engine fuses data from three sources: access control badge events (Lenel, Genetec, or AMAG via their respective APIs), video analytics people-counting (from Axis ACAP or Hanwha Wisenet analytics), and Wi-Fi device counting (from Cisco DNA Spaces or Aruba ALE). A Kalman filter combines these noisy signals into a per-zone occupancy estimate updated every 30 seconds. The occupancy value is published to a Niagara virtual point that the HVAC and lighting automation sequences reference. Hysteresis logic prevents rapid cycling: HVAC enters setback only after 15 minutes of confirmed zero occupancy, and lighting reduces only after 10 minutes, with configurable thresholds per zone type (conference room, open office, lobby).

Energy analytics uses 15-minute interval data from Modbus TCP power meters (Schneider PM8000, Siemens SENTRON) ingested into InfluxDB via a Telegraf agent running on the Niagara supervisor. Baseline energy models are constructed using ASHRAE Inverse Modeling Toolkit (IMT) regression with outdoor air temperature as the primary independent variable, establishing a weather-normalized consumption baseline. Subsequent months are compared against the baseline to calculate cumulative avoided energy (M&V per IPMVP Option C). Grafana dashboards display real-time power demand, daily energy consumption trending, demand response event performance, and carbon emissions calculated from EPA eGRID emission factors for the facility's utility region.