Creating door-specific sequences of operation

What you should be able to do

Draft a coordinated description of how one opening behaves, separating authorization, commanded actions, physical conditions and evidence. Recognize the additional conditions that a normal-entry example does not cover.

Teaching narration

A sequence of operation describes what happens at a particular opening under defined conditions. Start with the opening ID, hardware set, controller assignment and document revision. Describe the normal state from each side: what controls entry, how a person exits, whether the door is closed, and what feedback is actually available. Do not use "secure" as a substitute for several different states that have not been verified.

Use a repeatable structure: starting condition, triggering event, required action, timing, expected feedback, exception response and verification method. Assign specific timer values through the coordinated design; do not borrow a value from a different building simply because the interface has a default. Identify the moment each timer starts and what stops or resets it.

Manufacturer documentation distinguishes access timing, relock options, door-monitor inputs and events such as a door remaining open too long. Those choices have product-specific meanings. A command to release the entry lock is not a measurement of latch position. A door-position input can report closed without proving that a lock or latch is engaged. Use the actual available feedback when describing acceptance evidence. [1]

Also identify the egress method. Some controlled-entry openings allow independent mechanical exit through the door hardware. Others use locking arrangements that affect egress and require different code treatment. Allegion's manufacturer guidance distinguishes these arrangements and notes differences among adopted code provisions. Do not write one emergency-unlock statement and apply it to every opening. Coordinate the actual hardware, occupancy and applicable requirements with the responsible specialists. [2]

Worked through

Scope: a training opening with controlled entry and independent mechanical egress. The normal-entry excerpt is a teaching example, not a product wiring design or approved life-safety sequence. Starting condition: door closed; entry is controlled; mechanical egress is available. A documented verification establishes the initial mechanical condition. Event A: a permitted credential is presented. The controller records an access grant and commands entry release for the specified access interval. Event B: a person opens the door. The door-position input changes to open. The sequence identifies whether and how this event changes the access timer. Event C: the specified release interval ends. In this example the controller ends the release command. This does not guarantee that an open door has closed or that a latch has engaged. Event D: the door closes. The door-position input changes to closed. Latching and locking require the appropriate separate evidence; the position input alone is insufficient.

The poster lists related events, not a claim that every person opens and closes the door in exactly that order. The person may not enter. The door may close before the interval ends, or remain open afterward. Write these branches explicitly in the complete sequence. The example assumes a hardware arrangement suitable for the specified command behavior; it is not permission to apply that behavior to an incompatible lock.

Complete the missing conditions

Add a rejected credential; no opening after an access grant; exit through the mechanical hardware; open-too-long and unexpected-opening conditions; normal scheduled changes; loss of communications; loss of individual power sources; exhausted backup where applicable; required emergency inputs; and restoration after each event. Describe any permitted overrides and their priority, who may initiate them and how they are cleared. Requirements vary by opening and system, so unresolved branches remain open design questions. For power events, distinguish loss of building AC from loss of power at the lock. A battery-backed source can keep equipment energized after AC fails. Record the actual required response for the complete opening, including egress and relevant interfaces.

Original classroom exercise

A fictional event log shows access granted, release commanded, door open, and release command ended. It contains no subsequent closed input. A technician writes "door locked." Correct the record: the command ended, but closure and physical security are not established by this log. State what observation or feedback would be needed. Do not change the log or infer an unrecorded event.

Supervised drafting practice

Use a mock opening schedule and a supervisor-provided operating requirement. Build a table with event, action, timing, feedback, exception and test reference. Mark unknown values as unresolved. Have the responsible hardware and access personnel review the same draft so a programming assumption does not contradict the physical hardware. Walk through a no-entry case and a slow-entry case on paper. Then compare the sequence with the proposed acceptance test. Any live demonstration must follow the site's authorized test process and preserve required egress.

Knowledge check

Sources