Run data-center cooling as an operation, not an alarm feed.
A supply-air sensor crosses its limit at 03:14. Four minutes later a qualified technician is moving, with the unit history, the procedure and the live readings already attached — because the system did the part in the middle.
A limit breaks at 03:14. Nobody is awake.
Supply air on CRAH-07 crosses 27 °C and stays there. In most halls that becomes an amber row on a graphics page, then a phone call, then a decision made by whoever picked up.
Here it is a rule with a scope and a consequence, written once in the language the shift already uses: which point, which limit, for how long, in which hall — and what happens when it holds.
- Create work orderType: Cooling — critical · Priority from thermal margin
- Fold in related signalsSame loop, same 10 min window → one incident
- Attach live pointsSupply air, return air, valve, loop ΔP · last 60 min
- Require qualificationMechanical · OEM-authorised for CRAH-07 class
- NotifyOn-call mechanical, hall lead
The work order writes itself, with the equipment already on it.
Two seconds after the rule holds, a work order exists. Not a ticket with an alarm string pasted into the description — a record carrying the unit, the hall, the loop it feeds, the redundancy it just consumed, and the procedure that applies.
The dispatcher stops asking what this is. The question becomes whether it is right, and that is a question a person can answer in seconds.
CRAH-07 supply air above limit
- ✓Confirm redundancy state at panel
- ✓Isolate per LOTO — CHW-B branch
- Inspect valve actuator travel
- Verify supply air returns below 24 °C
- Restore N+1 and record final state
Open the work order. The equipment is still live inside it.
A work order carrying a screenshot of an alarm is out of date before it is assigned. This one carries the points themselves — supply air, return air, valve position, loop differential pressure — still moving while the technician drives.
It is the same view the technician opens at the unit, and the same series the system reads back after the work is called complete.
A CRAH is not a line item. It gets its own object.
Field service systems model a customer, a job and an invoice. None of those describe a hall, a chilled-water loop, a coolant distribution unit or an N+1 state, so teams push them into notes and custom fields until the model stops carrying weight.
The objects here are the ones the work has: Hall, Loop, Unit, Point, Alert, Work order, Verification. Every record page is assembled from blocks that read those fields — a telemetry block, a redundancy block, a procedure block.
Every system you run already holds a true part of this.
Each is authoritative about its own slice and blind to the others. None of them is wrong, and none of them is the missing piece.
What no system owns is the span between them: deciding what a set of physical signals means, who is permitted to act on it, and whether the action worked.
- BMS · BAS
- Controls and observes the plant. Knows the setpoint and the current state.
- DCIM
- Holds assets, capacity and environmental history for the hall.
- Controls · sensors
- Report temperature, pressure, flow and valve position.
- CMMS · EAM
- Holds asset history and the maintenance record.
- Field service
- Moves technicians and closes work orders.
The repair is physical. A person still has to make it.
Nothing here takes control authority over a cooling plant. Every connection is read-only, and the write scopes that would let it act on equipment are not requested and not available.
It reads, interprets and proposes. Dispatch inside an approved scope happens on its own; anything outside that scope waits for a person. A human puts hands on the unit, which is also the moment the decision gets tested against reality.
Does it control our cooling equipment?
No. The boundary is read-only. It observes points, builds topology, interprets conditions and raises work, and it makes workflow decisions inside a scope you approve. It never changes a setpoint, commands a valve or starts equipment. Humans keep physical repair and every safety-critical approval.
How is this different from BMS-to-CMMS alarm integration?
Alarm integration transports a signal and opens a ticket, which is a real capability and several products do it well. This is about what sits between those two events: folding many signals into one physical condition, working out what it threatens through the cooling topology, and deciding whether the response is authorised at all.
What actually creates the work order?
A rule you can read. Point, limit, dwell time, hall scope, and the actions that follow — create the work order, attach the live points, require the qualification, notify the on-call. Interpretation runs on top of that rule to fold related signals into one incident, never underneath it as an unexplained decision.
Can we model our own equipment types?
That is the point of the object model. A hall, a chilled-water loop, a coolant distribution unit, a rear-door heat exchanger and a monitoring point are objects with their own fields, not custom fields bolted to a generic job. Record pages are assembled from blocks that read those fields.
What has to agree before an incident closes?
A pre-work baseline, an expected recovery signal, an observation window and a recurrence rule, all defined before the work starts. Telemetry returning to baseline and the technician's findings must agree. Where they disagree the incident stays open — a sensor can be wrong, and a fix can be temporary.