A building that tells you what’s about to happen

Most building systems tell you what already went wrong. xSERVA’s AI and IoT layer is built to get ahead of that — learning the normal behavior of every connected system and flagging the moment something starts to drift, before it becomes a fault, a comfort complaint, or a wasted kilowatt.

Book a Demo
A dim building operations control room at night, a curved desk facing a wall of softly glowing monitors, one operator silhouetted from behind.
Intelligence is only useful if it reaches the person on shift.
A close view of a large pump motor and coupling guard in a plant room, a gloved hand holding a small handheld probe against the bearing housing.
The reading that predicts the failure is one somebody has to be standing there to take — unless the plant takes it continuously.
A gloved hand holding a small handheld inspection instrument toward an electrical panel in a plant room, the instrument screen turned away, panel lamps lit.
An anomaly is only useful if somebody can go and stand in front of the thing it names.

Predictive maintenance

xSERVA’s models learn the operating signature of each piece of equipment — the vibration, runtime, cycling frequency, and load pattern that count as normal for that specific AHU, chiller, or pump. When a unit starts to deviate from its own baseline, the platform flags it as a developing issue, weeks before it would trigger a hard alarm on its own. Maintenance teams get a prioritized list of equipment trending toward failure, with the specific parameter driving the flag, instead of reacting to breakdowns after the fact.

Anomaly detection

Beyond individual equipment, xSERVA watches for patterns that don’t fit — a zone drawing power outside its usual profile, a sensor reporting values inconsistent with its neighbors, a schedule override that keeps recurring. These anomalies often precede the alarms that traditional threshold-based systems eventually catch, giving operators a earlier, quieter signal to investigate before it escalates into something visible to occupants.

A chiller vibration trace stays inside its learned normal band for eight weeks, then begins drifting out of it. xSERVA flags the drift as a bearing wear signature and projects when it would reach the failure threshold, giving nine days of lead time and a service window outside occupied hours, instead of an alarm and an emergency call-out after the breakdown.
The flag comes from the equipment deviating from its own baseline, not from crossing a fixed threshold.
One analyst seen from behind at a desk in a dark office, a single ultrawide monitor showing indistinct blue glow, a notebook and coffee beside the keyboard.
The question is usually simple. Getting to the answer is what takes the afternoon.

Ask your building a question

xSERVA includes a natural-language query interface so operators don’t need to build a custom report to get an answer. Type a question the way you’d ask a colleague — “Ask xSERVA: which AHUs are trending toward failure this month?” — and the platform returns a direct answer drawn from live and historical data, not a dashboard you have to interpret yourself. The same interface handles questions about energy consumption, alarm history, or equipment status across one site or an entire portfolio.

A white architectural scale model of a commercial building on a dark table, lit from one low side so the massing throws long shadows.
A model is only as useful as the data behind it. A twin fed by nothing is an expensive drawing.

Digital twin visualization

A 3D digital twin of the building renders live point data spatially — zone temperatures, equipment status, and alarms mapped onto the actual floor plan rather than a flat list of tags. Operators navigate the building visually to understand where an issue is physically located, which is often faster than reading a point name and translating it to a location in your head.

Edge computing

For latency-sensitive control loops and sites with unreliable connectivity, inference can run at the edge — on local hardware inside the building — so anomaly detection and predictive alerts keep working even if the link back to a central instance drops. Edge and cloud processing share the same models, so insight quality doesn’t degrade depending on where it runs.

Eight small plain sensor modules laid out in a row on a dark bench, one with its lid removed showing a bare circuit board, tiny status LEDs lit.
Individually, each of these is a number. Together, and only together, they are a picture of the room.
A technician's hands fitting a small plain sensor into a ceiling tile from a step ladder, cable tail visible above the tile, the office dark beyond.
Every data point on the AI page starts as somebody on a ladder.

IoT sensor fusion

Modern buildings increasingly layer lightweight IoT sensors — occupancy, air quality, vibration, humidity — on top of traditional BACnet, KNX, and Modbus infrastructure. xSERVA fuses this MQTT-borne sensor data with existing controller and meter data in the same model the AI layer already reads from, so a new occupancy sensor immediately makes every prediction and anomaly check that touches its zone more accurate, without a separate integration project.

Occupancy, air quality, vibration and humidity sensors join the existing BACnet, KNX, MQTT and Modbus estate in one normalised data model. From there, inference splits two ways: edge inference on local hardware for latency-sensitive loops and unreliable links, and platform models across the portfolio for benchmarking and long-horizon trends.
A conclusion drawn from every source at once, rather than from one system in isolation.

Intelligence, grounded in unified protocol data

None of this works as a bolt-on. The AI/Analytics layer sits directly above the unified protocol data that BACnet, KNX, MQTT, and Modbus devices already feed into xSERVA, which is what lets predictions span every subsystem in a building rather than just the one protocol a point-solution happened to support. See how that underlying architecture is structured.

Explore the platform architecture →

Frequently asked questions

What kind of AI does xSERVA use?

xSERVA applies machine learning models trained on live building data for predictive maintenance, anomaly detection, and natural-language querying, running continuously over the same data that powers monitoring and control.

Does the AI layer need extra hardware?

No new field hardware is required. The AI layer runs on top of data already flowing through the protocol layer from existing BACnet, KNX, MQTT, and Modbus devices.

Can I ask xSERVA questions in plain language?

Yes. The natural-language query interface lets operators ask questions like which AHUs are trending toward failure this month and get a direct answer drawn from live and historical data.

How does the AI layer relate to the rest of the platform?

AI and IoT intelligence sit as a layer above the unified protocol data described on the platform architecture page, so every insight is grounded in the same live data as monitoring and alarms.

See the full FAQ →