11 Alarms§
AGREED New in v0.2. v0.1 represented alarms as a point kind and a boolean flag, which carried almost none of the configuration.
11.1 Alarm definitions are intent§
An alarm definition states a condition under which the building is to draw attention to itself, and what is to happen then. Limits, delays, priorities, routing, and acknowledgment policy are engineered decisions about how the building should behave, which places them in intent rather than in configuration.
bus:AlarmDefinition is attached to its subject by bus:appliesTo.
11.2 Content§
| Field | Requirement |
|---|---|
alarmKind | REQUIRED. limit, deviation, rateOfChange, status, digital, calculated, or communication. |
severity, priority | RECOMMENDED. priority is the source system value, preserved verbatim, not normalized to a BUS scale. |
limits | For limit and deviation alarms: highHigh, high, low, lowLow, deviation, and a referenceRef for deviation from a setpoint. |
triggerStates | For status and digital alarms: the enumeration members that raise the alarm. |
deadband, onDelay, offDelay | RECOMMENDED. The timing that separates a real alarm from a nuisance one, and the most common cause of a migrated system flooding. |
requiresAcknowledgement | RECOMMENDED. Operator-safety policy, not interface behavior. |
shelvable, maxShelveDuration | OPTIONAL. Whether an operator may suppress the alarm and for how long. |
enabledByScheduleRef | OPTIONAL. Alarms that apply only during occupancy. |
routing | RECOMMENDED. Ordered destinations with channel, party, schedule, and escalation interval. |
message | RECOMMENDED. What the operator is told. |
11.3 Preservation§
NOTE Priority renormalization is the specific failure to guard against. A source priority of 120 on a 0-to-255 scale mapped onto a receiver’s 1-to-5 scale is not recoverable, and the resulting alarm order is subtly wrong in a way nobody notices until an incident.