Prove Profile C door commands, state, and alarms as one workflow

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.

Source fact: Profile C spans door control and event management

The 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.

These 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.

Source boundary and applicability

The 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.

Applicability questions

• Which exact client and device versions claim Profile C conformance?
• Which door commands, modes, states, and alarms are required by the operating concept?
• How do ONVIF tokens map to local door, lock, sensor, and alarm identities?
• What is the authoritative state when command response, lock feedback, and door contact disagree?
• What is queued, lost, or repeated during communication failure and recovery?

DSE recommendation: accept a three-part round trip

The following steps are DSE recommendations based on the cited source.

For 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.

Observe 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.

Include 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.

Verification and evidence

Retain 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.

Official references

• ONVIF Profile C – ONVIF