How exhibition access control data should feed show day operations

At 09:40 on the first morning, the queue at hall three was longer than the queue at hall one, and nobody in the show office knew why. The panel logs had the answer in them the whole time. 620 denies, most of them at that door inside a 75 minute window, almost all from badges printed under one registration type.

Exhibition access control data gets treated as a security archive that somebody pulls after the show. It arrives in real time and it carries a reason on every refusal, which makes it the one feed that can tell you a door is failing while there is still time to walk over and fix it.

What does an access control panel actually record?

More than the reporting layer usually asks for. A panel connected to badge readers writes at least six event types, and five of them go nowhere.

A grant records a credential that was read and accepted, with the reader identifier and the timestamp. That is the row that becomes an entry scan and eventually feeds the counting work, and it is the one everybody extracts.

A deny records a credential that was read and refused, with a reason. This is the event class that pays for itself on show morning.

A door held open event fires when a door stays open past its timer. On a hall door propped by a contractor at 07:30, it fires repeatedly, and it tells you that the door has stopped being a counting point.

A forced door event fires when a monitored door opens with no valid grant behind it. A reader offline or communication fail event fires when the panel stops hearing from a reader. A tamper event fires when a reader housing is opened.

Grants are the reporting stream. The other five are the operations stream, and an organiser who only extracts grants has thrown away the half of the data that could have changed something on the day.

Wiegand, OSDP, and why the wire decides what you can see

Two protocols carry most of the traffic between a badge reader and the panel behind it, and the choice between them decides how much of the above you can actually observe.

Wiegand is the older one. The Security Industry Association published AC-01-1996, the access control standard protocol for the 26-bit Wiegand reader interface, defining the electrical signalling that moves card data from reader to control panel. It sends one way. The reader has no channel to report its own state, the panel has no way to ask whether the reader is alive, and the data on the wire is unencrypted. A 26-bit format carries a facility code and a card number, which is a small number of distinct values for a show that issues tens of thousands of badges.

OSDP is the newer one, and it changes what the data can tell you. The Security Industry Association developed it and submitted it to the International Electrotechnical Commission, which approved it in May 2020 and published it as IEC 60839-11-5:2020, specifying communications between an access control unit and its connected peripheral devices over a two-wire RS-485 multi-drop serial channel. Two-way and supervised, so a reader that has stopped responding produces an event instead of silence.

That difference matters for a specific and common failure. A reader on a Wiegand loop that dies at 11:00 looks, in your data, exactly like a door where nobody arrived after 11:00. A supervised reader raises a communication fail and the show office knows within a minute. If you are specifying readers for a venue you control, this is the argument that should decide it, well ahead of the feature lists.

A deny reason taxonomy that maps to a cause

Panels emit deny reasons in vendor vocabulary, and the vocabulary is useless until you map it onto things a person can act on. Five causes cover almost everything at an exhibition.

Wrong ticket class. The badge is valid and the door disagrees about entitlement. Cause sits in the entitlement matrix, which is a configuration file somebody edited under time pressure.

Expired credential. A day-one badge presented on day two, or a badge outside its valid window. Cause is usually a registration policy the attendee did not understand.

Unknown credential. The reader parsed a badge it has never seen. Competitor show badges, hotel key cards, staff passes from the venue.

Anti-passback. The same credential presented twice in the same direction without an intervening exit read. This one is a genuine signal, because it catches a badge being handed back out through a barrier.

Read failure. The reader could not decode anything. Damaged badge, wrong orientation, dirty lens.

The mapping is worth writing once, storing as a lookup table, and reusing every edition. Vendors change their strings between firmware versions, and a mapping table absorbs that where a hardcoded case statement in a report does not.

What 620 denies at one hall door turned out to be

The numbers from that morning, once somebody read the log.

620 denies at hall three across the day. 440 of them, which is 71.0 per cent, came back as wrong ticket class. 96 were expired credentials. 54 were unknown credentials. 30 were anti-passback. That accounts for all 620.

The 440 concentrated in time in a way that told the story on its own. 380 of them fell between 09:00 and 10:15, which is 86.4 per cent of that reason code inside the first 75 minutes of the day. Fraud does not cluster like that. Configuration errors do, because the first wave of arrivals hits the misconfigured rule all at once and later arrivals have already been told at the door to go round to hall one.

The cause was one registration type, a two-day visitor pass sold through a partner association, mapped in the entitlement matrix to the conference halls and never to hall three. 440 people who had paid to be in that hall were turned away from it by a lookup table. The steward on the door had been apologising for an hour and had no way to know the rule was wrong.

Read the deny stream as a rate and it gets more useful still. Hall three took 4,180 grants that day, so 620 denies is a deny rate of 12.9 per cent. Hall one, on the same badges and the same crowd, ran 1.8 per cent. A gap that wide between two doors on the same show is a configuration difference until proven otherwise.

Which of these events should reach the show office within a minute?

Not all of them, because an operations feed that fires constantly gets muted by lunchtime. Three rules keep it honest.

Alert on rates. A single deny means nothing on its own, while a deny rate that runs above some multiple of the same door's own baseline for two consecutive five-minute windows is worth a radio call. Use each door as its own control, because doors genuinely differ and a shared threshold will fire constantly at whichever one has the awkward layout.

Alert on silence. A reader that has produced no grants for ten minutes during show hours, on a door that was producing 40 a minute, is either broken or has been propped open. Both need somebody to walk over. Silence detection is the single highest-value alert in the set and it needs no protocol upgrade to build, though a supervised reader gives it to you for free.

Alert on door-held-open at counting doors specifically. A propped hall door is an operational nuisance and a measurement hole at the same time, and the hole is the part your attendance figure will feel. Which doors count, and what to do about the ones that stop counting, is the subject of gate coverage.

Everything else can wait for the daily review. Tamper alarms, forced doors on service routes, single denies: log them, look at them at 18:00.

Where this stops

The panel knows what the door did. It does not know what the person did, and the gap between those two things is wider at an exhibition than at an office.

An access control system at a corporate building assumes one badge, one person, one direction. A show breaks all three assumptions. Groups walk through on one grant while a steward waves them past. Badges get handed back out. Half your doors are staffed by people who will open them manually when the queue builds, and the manual opening produces no event at all, so the busiest moments are the ones your data understates most.

The second limit is timestamps. Panels keep their own clocks, and clock drift across a dozen panels from two vendors is normal. If you are going to build an arrival curve from this feed, the drift has to be measured and corrected first, or your 15 minute bins will smear across doors. That work belongs with the arrival curve itself, and the taxonomy that keeps panel events separate from the other scan sources belongs with the scan types. None of it lands anywhere useful until the events reach the same place as the rest of your attendee analytics.

Start this week by asking your access control supplier for one thing: an export of every deny event from your last edition, with reason code, reader and timestamp. Group it by reader and by reason, and look for the door where one reason is more than half the total. That door had a configuration error, and you can fix it before the next edition.