One platform, every protocol

xSERVA is engineered as a single, layered platform — not a bundle of point products stitched together after the fact. Every BACnet controller, KNX bus, MQTT sensor, and Modbus meter in a building flows through the same architecture, from field device to dashboard, so the system stays coherent no matter how large or mixed the site becomes.

Book a Demo
An open building-controls cabinet in a service riser, with neat rows of DIN-rail modules, tidy wiring looms and small green and amber indicator lights.
Every layer above this one depends on what is wired in here.
A lift machine room at the top of a building, geared traction machines with ropes running over sheaves and an overspeed governor beside painted steel beams.
Five layers of software sit on top of rooms like this one. The architecture only matters because the plant does.

Five layers, one coherent system

Rather than treating protocol translation, data storage, intelligence, and user interface as separate products, xSERVA structures them as layers of one platform. Each layer has a clear responsibility and a clean boundary with the layers around it, which is what lets the platform scale from a single floor to a national portfolio without a rewrite.

The five layers from the bottom up: Field and Device, carrying BACnet IP and MS/TP, KNX bus, MQTT sensors and Modbus TCP and RTU; Protocol and Integration, where native drivers normalise them into one data model; the Core Engine holding live and historical data, the cross-protocol rule engine, schedules and alarms; the AI and Analytics layer; and the Presentation layer of dashboards, mobile app, floor plans and reports. Authentication, role-based access and encrypted transport run as a spine through every layer. The Protocol and Core Engine layers are exposed through a documented API.
Security runs through the layers rather than sitting on top of them.

Field / Device Layer

Controllers, sensors, meters, and actuators on the ground — BACnet MS/TP and IP devices, KNX bus lines, MQTT-speaking sensors, and Modbus TCP/RTU meters, all wired the way they already are.

Protocol / Integration Layer

Native drivers normalize BACnet, KNX, MQTT, and Modbus traffic into a single, consistent data model, so nothing above this layer needs to know which protocol a point came from.

Core Engine

The runtime that stores live and historical point data, evaluates rules and schedules, manages alarms, and coordinates every workflow that runs across the platform. This layer also hosts the rule engine, a cross-protocol event-condition-action system that can combine a BACnet sensor reading, a KNX occupancy state, and an MQTT telemetry trigger into a single chained AND/OR condition, then act across protocols — for example driving a Modbus VFD and logging the outcome — with a simulation mode to test rules before they go live and a full execution audit trail once they do.

AI / Analytics Layer

Machine learning models trained on live building data sit above the core engine, generating predictive maintenance signals, anomaly flags, and energy insight without touching the field layer directly.

Presentation Layer

Web dashboards, the mobile companion app, and reporting exports all draw from the same underlying data, so every interface shows the same numbers at the same moment. This layer renders live interactive floor plans with real-time data overlays, historical trend charts, a digital twin 3D view of the building, customizable drag-and-drop dashboard widgets, and cross-site comparison heatmaps for portfolio-wide views.

Cross-Cutting Security

Authentication, role-based access, and encrypted transport run through every layer rather than being bolted on afterward, keeping the whole stack consistently governed.

An electrical services riser with vertical busbar trunking running floor to ceiling and tap-off boxes branching from it, containment and conduit alongside.
Every floor takes its supply from the same riser. The platform is meant to work the same way.
Four commercial towers of one estate seen together across a city at dusk, floors lit warm against deep blue twilight with roads threading between them.
One building is a project. Five is an estate, and the difference is entirely in the reporting.
Edge

What actually sits in the plant room

Deployment is usually discussed as cloud versus on-premise, which is the wrong axis. The real question is where the protocol layer terminates — and the answer is on site, in a gateway that speaks every field protocol locally and exactly one authenticated, encrypted protocol outward. That single decision is what keeps a plant bus off the public internet, what keeps the building running through an outage, and what makes the platform answerable to an IT security review.

A cutaway of the on-premise edge gateway. Southbound, four protocol drivers connect: BACnet over IP and MS/TP, KNX over KNXnet/IP, Modbus over TCP and RTU, and an MQTT client for local sensors. Inside sit a normalised point cache holding 4812 points, a store-and-forward buffer holding 30 days at one-second resolution, a local rule runtime that keeps schedules and interlocks running with no uplink, and TLS 1.3 with a per-site client certificate. Northbound there is a single outbound MQTT-over-TLS connection on TCP port 443 and zero inbound ports, and no plant protocol frame crosses the site boundary. A panel contrasts this with exposing BACnet or Modbus directly, neither of which authenticates anything. Another explains that when the uplink drops control continues locally, history buffers, and on reconnection the buffer drains in timestamp order so the trend has no gap.
The answer to "what have you opened on my network?" is nothing. The gateway dials out; nothing dials in.
Looking straight up a building services riser, rectangular ductwork, insulated pipework and cable containment stacked floor after floor into darkness.
One building is this, repeated. A portfolio is this, repeated, in places nobody visits on the same day.

Deploy the way your site needs

Not every building has the same infrastructure, IT policy, or connectivity, so xSERVA supports four deployment models on the same core engine. Run on-premises when data residency or air-gapped security requirements demand it, keeping all processing inside the building’s own network. Run fully in the cloud when you want centralized management, automatic updates, and zero local server hardware to maintain.

A hybrid model keeps time-critical control loops local while pushing analytics, reporting, and multi-site aggregation to the cloud — the common choice for portfolios that want central visibility without giving up local resilience. And for remote or bandwidth-constrained sites, edge deployment runs the core engine on local hardware that continues operating fault-detection and control logic even if the connection back to a central instance drops.

Built to grow with your portfolio

A single-building deployment and a hundred-building portfolio run on the same underlying architecture. Adding a new site means registering it against the existing core engine and protocol layer, not standing up a parallel system. Facilities teams get one console for the whole portfolio, with role-based access so a regional manager sees every site while a building engineer sees only their own.

Portfolio-wide reporting rolls consumption, alarms, and asset data up across every connected building, letting operations leadership compare performance site to site using consistent, apples-to-apples data — something that is nearly impossible when each building runs its own disconnected system.

Four deployment models on one core engine. On-premises keeps everything inside the building for sites whose IT policy requires it. Cloud is fully hosted with nothing to maintain on site. Hybrid splits the two, keeping time-critical control loops local while analytics and reporting run in the cloud. Edge places inference on local hardware, so decisions keep running when the link drops. Each is labelled as running the same core.
The deployment model is a choice about where the core engine runs, not a different product.
A single operator workstation in a dim building services office at night, two monitors turned away so only their glow shows, with a plant room door ajar behind.
The console is where the platform is judged, by one person, usually alone.

Open by design, not by exception

The Protocol/Integration and Core Engine layers are exposed through a documented API, so system integrators and internal development teams can build against xSERVA rather than working around it. Pull live and historical point data into a BI tool, trigger workflows from an external system, or extend the platform with a custom application — the same API that powers the built-in dashboards is available to you.

Explore the developer documentation →

Frequently asked questions

What are the architecture layers of xSERVA?

xSERVA is built in five layers: Field/Device, Protocol/Integration, Core Engine, AI/Analytics, and Presentation. Each layer is independently scalable, so you can add devices, protocols, or dashboards without re-architecting the platform.

What deployment options does xSERVA support?

xSERVA can run on-premises, fully in the cloud, in a hybrid on-prem/cloud configuration, or at the edge for latency-sensitive or connectivity-constrained sites. The same core engine runs in all four models.

Can xSERVA manage more than one building?

Yes. The platform is built for multi-site and portfolio management from the ground up, with a single console, portfolio-wide reporting, and role-based access across sites of any size.

Does xSERVA expose an API for integrators?

Yes. xSERVA offers an open, documented API and integration layer for custom applications, BI tools, and third-party systems. See the developer documentation for details.

See the full FAQ →