Building Automation Edge
Local observability and integration for building systems, from plant rooms and meters to distributed facilities.
A building is operationally reliable when local systems can keep collecting, interpreting, and exposing their state even when the wider network or central application is unavailable. Edge computing gives each building or technical zone a supportable local boundary around the equipment, data, and workflows that need to remain close to the site.
Building systems are local before they are portfolio systems
Heating, ventilation, cooling, pumps, lighting, meters, access infrastructure, technical alarms, and local controllers operate in physical spaces with their own maintenance constraints and safety boundaries. A facilities team may want a portfolio view, but the equipment still needs a local path for collection, state validation, evidence retention, and site response when the WAN is unreliable or an upstream service is unavailable.
Many estates also contain a mix of technologies: long-lived controller networks, newer IP devices, meters from several suppliers, room sensors, cameras, and specialist building-management applications. The integration problem is therefore not just connectivity. It is maintaining a trustworthy operating meaning for each value: where it came from, how old it is, which unit it uses, whether it is credible, and who owns the next action.
Banalytics provides a local edge orchestration and observability layer around connected physical systems. An Agent runs on a Windows, Linux x86_64, or Linux ARM64 host at the site, connects approved components and integrations, creates structured events, and exposes selected results to dashboards and authorised users. See What is Banalytics? for the platform overview.
Give each technical zone an explicit local boundary
| Layer | Responsibility | Examples |
|---|---|---|
| Field equipment | Generate measurement, state, alarm, media, or controlled equipment signals. | Controllers, pumps, valves, meters, temperature and humidity probes, relays, cameras, access devices, and local gateways. |
| Building edge node | Acquire data locally, check freshness, retain configured history, run approved tasks, and create events. | Industrial PC, compact server, or ARM host in a plant room, electrical room, floor distribution point, or site network cabinet. |
| Local operational logic | Assess bounded conditions and hand a defined result to the system or person responsible for action. | Stale telemetry, room-condition deviation, plant-room alarm, meter anomaly, communications loss, or equipment-health exception. |
| Building and portfolio integration | Deliver selected, contextualised outputs to authorised building, maintenance, and reporting systems. | BMS, CMMS, energy-management system, dashboard, MQTT consumer, API, historian, or contractor workflow. |
| Protected control authority | Retain the independently engineered controls that command equipment, protect people, or satisfy regulatory requirements. | Dedicated BMS control logic, safety controllers, fire and life-safety systems, protection devices, and emergency procedures. |
The edge node should own the local monitoring path, not the authority of every building control system. Banalytics can make information and workflows around equipment more observable and repeatable; it should not be positioned as a replacement for certified safety systems, fire panels, life-safety controls, or the designated building-management system that holds control authority.
Start with conditions that have a clear facilities response
| Building area | Local edge responsibility | Useful operational outcome |
|---|---|---|
| HVAC and plant rooms | Read controller and sensor state, detect communication or freshness problems, retain local trends, and flag approved operating deviations. | Time-stamped exception with source and quality context for the facilities team or the BMS owner. |
| Energy and metering | Collect meter and equipment state near the source, validate units and update intervals, and create local history. | Consumption or availability summary, stale-meter event, anomaly context, and a governed energy-management handoff. |
| Lighting and technical cabinets | Observe cabinet, relay, controller, or gateway state across floors and remote facilities. | Site-specific maintenance context and a prioritised work item instead of a generic device-down alarm. |
| Water, leak, and environmental observation | Collect permitted sensor and visual inputs locally; retain configured evidence and evaluate bounded thresholds. | Condition event, evidence reference, escalation to the responsible maintenance or building operator, and data for root-cause review. |
| Access and security-adjacent equipment | Provide an approved local integration or observation layer without taking ownership of access-control or security authority. | Selected equipment-health or operational events for the responsible system; access decisions remain with the designated security platform. |
Normalise the site interface before writing the workflow
Building automation often connects to established controllers through a protocol gateway or local service. Where Modbus is the right interface, the Modbus Line component supports serial and network variants, multi-device polling, state tracking, and event generation. The embedded MQTT Server can provide a local publish/subscribe boundary for gateways, applications, and custom integrations; an MQTT Topic Listener converts a defined inbound topic into a Banalytics event.
Where a building relies on BACnet, a proprietary controller protocol, or a specialist BMS API, treat the gateway or sidecar service as an explicit project component with a named owner. Define its data model, authentication, polling or subscription behaviour, quality flags, failure state, and upgrade path. Do not imply native support merely because a value can be shown on a dashboard.
Before a condition becomes an alert, define its semantics: unit, location, expected update interval, timestamp source, calibration or maintenance owner, acceptable range, and the meaning of a missing value. This prevents an old sensor reading, a gateway outage, and a genuine comfort or plant condition from being presented as the same problem.
Keep building context available through upstream disruption
Banalytics Event Manager evaluates configured events and invokes preconfigured actions. A rule can notify a facilities team, retain an evidence record, publish a concise MQTT message, or deliver a carefully scoped integration payload. The event should retain source, time, state or measurement, quality, location, severity, and the expected human response. See Event Manager for the rule-and-action model.
The node that runs the local workflow also needs to be observed. Banalytics System Monitor publishes CPU, memory, disk, thread, media, WebRTC, and user-activity metrics as System state events. Combine these with device freshness and local-storage rules, so a technician can distinguish a full disk, unavailable controller, failed gateway, and slow remote viewer without applying the same restart action to every alert.
For portfolio operations, authorised users can access site context remotely without placing the portal in the local acquisition path. Portal Integration uses signalling to establish a browser-to-Agent WebRTC connection. The building’s local collection, history, and rules remain at the edge boundary while a central team receives the visibility it needs.
Commission one accountable building boundary before scaling
- Choose one service outcome. Start with a plant room, floor, meter group, technical cabinet, or facility that has a named owner and a measurable maintenance or service objective.
- Document the local contract. Define assets, interfaces, units, expected updates, retention, event schema, authorised users, external consumers, and outage behaviour.
- Prove the local path. Test collection, source freshness, local history, event creation, and the intended site response while the upstream connection is unavailable.
- Validate the human workflow. Confirm that a facilities technician, BMS owner, or contractor can understand the event, access the correct context, and close the loop.
- Exercise failure modes. Simulate a stale value, controller loss, full storage, unavailable integration, and host restart; refine the runbook from the result.
- Replicate deliberately. Reuse the pattern where buildings and equipment are comparable, and record each exception created by local controls, contractor scope, or regulatory requirements.
Building automation edge computing is not about adding another screen above a BMS. It is about creating a dependable local operating boundary that preserves context, makes integration explicit, and helps facilities teams act before a small equipment problem becomes a service disruption.