A turnstile looks like hardware, but most of the engineering sits behind it. If you are integrating readers and barriers into a gate platform, the data model decides whether the first week is smooth or full of denied entries.
The decision the controller must make
When someone presents a credential, the controller has roughly a second to answer one question: open or stay locked. That needs three lookups.
- Identity: does this credential map to an active person?
- Policy: is this person allowed at this gate, in this zone, at this time?
- State: are they already inside (anti-passback), or has the pass expired?
A minimal schema
person(id, name, type, status)
credential(id, person_id, kind, value, valid_from, valid_to)
policy(person_id, gate_id, zone, shift_start, shift_end)
event(id, gate_id, credential_id, ts, result, reason)
Keep event append-only. Denied attempts are as valuable as granted ones, because they expose data errors and misplaced readers.
Offline first
Gate hardware should keep a local copy of the allow-list and keep deciding when the network drops. Queue events locally and sync later. A turnstile that waits for a server on every read will fail on the first bad connection.
Fail-safe is not optional
Treat fire alarm and power loss as hard inputs that release the barrier regardless of software state. Test this during commissioning.
Metrics worth tracking
- Read success rate per reader
- Average passage time at peak
- Denials per hundred reads, split by reason
- Tailgating alerts, if you use presence sensors
For the physical side, barrier types and a rollout plan, see the turnstile access control system guide.
Top comments (0)