← Back to SOPs catalog
Keedian operations · Standard procedure
Out of service / stoppage.
An elevator or escalator reports an out-of-service state or a stoppage from its controller. The headline signal of the add-on: the building operator learns of the stoppage from the system the moment it happens, not from a tenant complaint at the front desk.
01 Detail
Trigger, action plan, and escalation criteria.
optimization_metric
vertical_transport
high
essential tier
AI: hybrid
- Related metric
vertical_transport_availability- Trigger
unit_state = out_of_service sustained >= oos_ride_through (raises OOS stoppage)- Value drivers
-
Customer experience
Operational continuity
- Preconditions
- Each unit's in-service / out-of-service state mapped from the controller, OEM monitoring interface, or dry-contact / BMS points. The transient ride-through window is a configurable server-side attribute so a normal door cycle or a brief recall is not reported as a stoppage.
- Human role
- Primary — Keedian reads the controller state and raises the alarm; the repair is the certified maintenance provider's. Operators confirm the stoppage is real, notify the building operator, coordinate the vendor referral, and track the unit to restoration.
- Action plan
-
(1) Confirm the out-of-service state is sustained past the ride-through window, not a transient (a held door, a fire recall, or a normal inspection-mode entry).
(2) Attribute the stoppage to the specific unit and capture the controller fault detail so the referral points the provider at the right car or escalator.
(3) Notify the building operator and refer the stoppage to the certified maintenance provider with the fault detail and a recommended action.
(4) Track the unit to restoration and log the downtime as evidence; Keedian surfaces and refers — the repair stays with the provider.
- Escalation
-
(1) A unit serving a critical path (the only accessible car, a lobby escalator) stopped → notify the building operator out of cycle rather than holding for the routine report.
(2) The same unit stops repeatedly after a provider visit → flag a recurring fault for a deeper vendor engagement.
(3) The controller state feed cannot be confirmed → report the unit's state as unknown rather than in-service, and reconcile the mapping.
- Prevention
-
(1) Confirm the in-service / fault point mapping per unit at onboarding before arming the alarm.
(2) Tune the ride-through window to clear normal door cycles and recalls while still catching a genuine stoppage quickly.
(3) Keep a per-unit stoppage log so a unit with a rising stoppage rate surfaces for the provider before it becomes chronic.