Bottom line: a successful unlock command is only one-third of an access-control workflow. The integrator must also establish the actual lock and door state and confirm that the expected event or alarm returns to the consuming system.
\nThe official ONVIF Profile C page describes interoperability for physical access control. Its feature overview includes site information, door access control, and event and alarm management for conformant devices and clients.
\nThese functions form a chain but are not identical. A controller can accept a command while the lock does not release, the door-position input can disagree with the commanded state, or an alarm can be delayed or mapped to the wrong opening.
\nThe profile page does not certify a product not present in the official conformance database, guarantee interoperability between exact releases, or approve a door’s fire, egress, accessibility, or security design. It also does not prove field wiring, sensor calibration, lock power, time synchronization, event retention, or cyber hardening. Required features and conditional behavior need product-level confirmation.
\nThe following steps are DSE recommendations based on the cited source.
\nFor every required operation, define the request, expected response, permitted physical transition, expected sensor state, event name, maximum timing, and operator display. Test authorized momentary unlock, relock, held-open and forced-open conditions, invalid command, unavailable device, and restoration. Use a safe test doorway or approved window with fire/life-safety and facility owners present.
\nObserve the door and electrical feedback independently; do not accept an API success message as proof of movement. Verify duplicate and out-of-order events, time alignment, acknowledgement, retention, and client reconnection. Document vendor extensions and any condition that the profile does not carry.
\nInclude a no-motion test in which the controller accepts or rejects a request but the physical door cannot reach the expected state. Confirm the client displays the discrepancy and routes it to a responsible operator rather than reporting a completed unlock from command status alone.
\nRetain official conformance records, version and topology inventory, token mapping, test matrix, sanitized commands and responses, controller and client logs, physical observations, sensor measurements, alarm timing, failure and recovery results, rollback evidence, and acceptance signatures.
\n