Supported by
Each alarm arrives with its exact origin, a priority we calculate, and the racks and customers it affects, so your team knows what to handle first and who to tell.
Today the link between a BMS signal, the equipment behind it and the customers it serves lives in manually built Excel mappings and in the heads of individual operators. Priority rests on the experience of whoever is on shift. Shift staff are scarce, rotate often and rarely have the full context.
Face hundreds of unprioritised alarms and decide from memory which one matters.
High rotation and little context. A new technician cannot know which rack sits behind which signal.
Contracts require prompt notice of impact, yet nobody can say quickly which customer a failing device serves.
Late or wrong actions waste energy and trigger the emergency, carbon-intensive outcome.
During a maintenance handover at a hyperscale site, more than 200 unprioritised alarms were open when a UPS began running down its battery. The one that mattered was not distinguishable from the rest. The battery lasted five minutes, and about 3 MW went dark for 20 minutes. Origin, priority and affected customer would have answered the technician’s first three questions.
The same incident, replayed with Sono: origin, priority and path to the customer, then an action a person approves.
Sono reads the signals your BMS and EPMS already produce and the asset data you already hold, and attaches to every alarm what an operator needs to act.
The controller and point the signal comes from, the equipment it belongs to, and where that equipment sits in the plant. The mapping that is manual today becomes a maintained record.
Your alarm classes set the severity. Sono calculates how urgent the alarm is and what impact it has, and combines them, so priority no longer depends on who is on shift.
From the signal to the equipment, the system it serves, the rack and the customer. The affected customer can be alerted immediately, which most contracts require anyway.
Example values. The signal resolves to its device, the device to the power path it feeds, and the power path to the racks and the client behind them.
What we deliberately do not build: a digital twin of the data centre, a CMMS or a ticketing system. We need enough information to trace a signal to its exact source and down to the racks and clients, and we work with the systems you already run.
Today the mapping from signal to equipment to rack to customer is built by hand in Excel. Sono turns it into a maintained record and puts it behind every alarm.
Sono reads your BMS or EPMS point list and your asset data from your CMMS, as a one-time file upload or through an API.
Signals, equipment and racks are structured into three linked sheets, so every signal can be followed from its source to the customer. An optional pre-analysis fills the gaps with your team.
Operators get alarms ordered by priority, with origin and affected customers attached. A person approves every ticket and every customer alert.
Sono connects to your BMS and EPMS and to your CMMS or ticketing tool. Your data stays in your network, and a person approves every action.
One row per BMS signal: exact signal code, meaning, controller, protocol, address and the equipment tag it belongs to.
One row per device: tag, room, type, what feeds it and what it serves, upstream and downstream.
One row per rack: power feeds A and B, cooling zone, client, suite and SLA tier.
A read-only collector inside your network. Nothing is written back to your control systems.
Operator view, customer alert and a ticket draft that a person approves. Any write-back goes through your CMMS or ticketing API.
A pilot begins with about three alarms, so operators keep control and alerts stay meaningful, then widens as trust grows.
Sono sits beside your control systems, not inside them, and works with the tools your team already uses.
We start with about three alarms on one site, so operators keep control and alerts stay meaningful.
Request a pilot