ANPR, ticketing or RFID: choosing and sizing a parking system

Write the purpose down before the technology. Revenue collection from transient visitors, access control for a known contract population, occupancy measurement and guidance, enforcement, and integration with a wider security system are five different requirements. Ranking them takes ten minutes and prevents most of the mistakes that follow.

The ranking matters because it determines where complexity is allowed to sit. A staff car park for a fixed population can tolerate a slow enrolment process and no cash handling at all. A shopping centre cannot: it must accept a first-time visitor with no account, in a car it has never seen, at the busiest hour of the week, and take money from them reliably.

It also determines whether a barrier is needed at all. A barrier is a traffic management device that stops honest drivers and shapes queues. It is not a security device, and if the requirement is to physically stop a vehicle from entering, that is a rated vehicle security barrier and a completely different specification.

Ticketing remains the most robust way of handling a driver the system has never seen. A dispenser issues a ticket, the driver pays at a station or on exit, and the transaction is anonymous and self-contained. The costs are consumables, jams, cash handling and, above all, time: a ticket transaction requires the driver to stop, lower a window and interact, which sets a floor under the lane cycle time.

Long-range RFID, typically a UHF windscreen tag, is the fastest option for a known fleet. It reads hands-free at a distance, works regardless of plate condition, and is cheap per additional vehicle. Its weaknesses are administrative rather than technical: a tag identifies a vehicle, not a person, so it can be moved between cars or lent, and read zones have to be controlled carefully or a tag will open the wrong lane from the adjacent queue.

Plate recognition identifies the vehicle with no credential at all, which makes it excellent for contract parking, whitelist access and ticketless transient operation where payment is tied to a registered account. It is also the model most often specified on the strength of a demonstration and then disappointing in service, for the reasons in the next section.

In practice the right answer is usually a hybrid: plate recognition as the primary path, with a ticket, an intercom, or a barcode from a mobile app as the defined fallback. Specify the fallback explicitly, because the failure mode of a plate-only design is a stopped vehicle blocking the entry lane while somebody looks for a telephone number.

Recognition accuracy is a property of the installation, not of the camera. The same camera will read well in one lane and poorly in the next, and the difference is almost always geometry, lighting and vehicle positioning.

Give the system a repeatable read zone. A vehicle that stops in a defined position presents its plate far more consistently than one moving freely, which is one of the underrated advantages of keeping a barrier. Keep the horizontal and vertical angles between the camera and the plate within the manufacturer stated limits, and prove that on the actual lane geometry rather than on a section drawing. Specify dedicated infrared illumination matched to the camera; plates are designed to be retro-reflective, and a properly illuminated infrared image is far more reliable than a colour image fighting headlight glare at night or low sun in the morning.

Then deal with the plates themselves. Saudi plates carry both Arabic and Latin characters, and the vehicle population includes temporary, transit, diplomatic and foreign plates as well as trailers and towed equipment. Require the recognition engine to be demonstrated on Saudi and GCC plate formats, and require the accuracy figure to be defined rather than quoted: measured on site, over a defined trial period, against a manual count, reported separately as a read rate and a character accuracy, and broken down by day and night.

Finally, accept that a residual will always exist. Damaged, obscured, non-standard and foreign plates will not read, so the specification must state the no-read procedure, how long it takes, and who deals with it at 23:00 on a Thursday.

Almost every congested car park was sized on average demand. Use peak demand, and treat entry and exit separately because they peak at different times and have different transaction lengths.

Start with the number of vehicles arriving in the busiest fifteen minutes and multiply by four to get a peak hourly rate. Then measure the full transaction time in seconds: vehicle detected, credential read or ticket taken, decision returned, barrier raised, vehicle driven through, safety loop cleared, barrier lowered. Lane capacity per hour is 3,600 divided by that figure. Divide the peak hourly rate by lane capacity to get the theoretical lane count.

Then apply two corrections. Design at roughly seventy to eighty percent utilisation, because queues grow without bound as a lane approaches full capacity — the difference between a lane at eighty percent and one at ninety-eight percent is the difference between a short wait and a blocked junction. And provide reservoir space: state, in metres, the queue storage required inside the site so that a queue never reaches the public road, calculated from the arrival rate, the expected wait and an average vehicle length.

Exit almost always needs more capacity than entry, because payment tends to happen there. The most effective single intervention on a large transient facility is to move payment away from the exit lane entirely — pay on foot, or pre-payment through an app — which turns the exit transaction into a verification and can halve the cycle time. That is a design decision with architectural consequences, so it belongs in the brief, not in the commissioning phase.

The barrier is the part of the system that will run millions of cycles and the part most often specified in one line. Give it its own clause.

In European-referenced projects, EN 12453 covers safety in use of power operated doors, gates and barriers, including force limitation — the commonly cited limits are 400 N for crushing and 1,400 N for impact. Where the project is referenced to North American standards instead, UL 325 addresses the operator and ASTM F2200 addresses the construction of the gate itself; the two are intended to be used together. Name whichever framework the project is working to, and require the safety devices to be listed: safety photocells, safety loops, and anti-drop protection.

Specify the mechanical reality as well. Boom length and cycle time trade against each other, so state the required opening and closing time for the actual boom length rather than quoting a figure for a shorter boom. Ask for cycle life as a tested figure with the test conditions stated, and ask what is consumable. State the behaviour on power failure — manual release, battery operation, or fail-open — and whether the entry lane is permitted to fail open while the exit lane does not.

For outdoor installations in the Kingdom, state the ambient temperature range and dust conditions, and specify the housing finish accordingly. Cabinet interior temperature under direct sun is the figure that matters for the drive electronics.

Payment is where parking projects meet a completely different approvals process, and it is routinely left until too late. Decide early whether the model is pay on exit, pay on foot, or account-based ticketless operation, and confirm which payment instruments must be accepted — local cards, international cards and mobile wallets each involve different acquiring arrangements. Involve the client finance team early, and settle the tax invoicing requirement in writing, because retrofitting compliant invoicing into a pay station is not a software setting.

On integration, require documented interfaces rather than promises. The parking system will need to exchange data with access control for staff, with tenant or visitor management, and often with a building or city platform. Ask for the API to be documented, ask what data can be exported and in what format, and make the client the owner of the data and the account.

There is a data protection dimension here that specifications often miss. A plate number combined with timestamps becomes personal data as soon as it can be linked to an identifiable individual, which is exactly what a contract parking database does. Under the Saudi Personal Data Protection Law that brings obligations around lawful basis, retention and disclosure, so state a retention period for recognition images and movement records, state who may access them, and state the deletion process. Deciding this at design stage is far cheaper than discovering it during an audit.

Occupancy figures come from two fundamentally different methods, and the difference should be stated rather than assumed.

Counting at the barrier is cheap and gives a facility total, but it drifts: tailgating vehicles, manual barrier raises, motorcycles and maintenance passes all introduce error that accumulates over days. If counting is the method, specify a reconciliation procedure and a frequency, and specify what triggers a reset.

Single-space detection, whether sensor or camera based, gives per-bay status and enables real guidance, at a higher cost per space and with its own failure modes. If guidance is required, specify the accuracy expected per bay, the behaviour with a badly parked vehicle, the recalibration method and the maintenance regime.

In both cases, ask for the accuracy figure to be defined the same way as the recognition figure: measured on site, over a stated period, against a manual reference. An accuracy percentage with no measurement method attached is not a requirement, and it cannot be failed at handover.

A parking specification is complete when it contains all of these:

• A ranked statement of purpose: revenue, access control, occupancy, enforcement, integration.
• The credential model per user group, and the defined fallback when the primary path fails.
• For plate recognition: read zone geometry proven on the actual lane, dedicated infrared illumination, and demonstrated performance on Saudi and GCC plate formats.
• Recognition accuracy defined as measured on site over a stated trial period against a manual count, reported as read rate and character accuracy, split day and night.
• The no-read procedure, including how a driver at the barrier is resolved and by whom, out of hours.
• Peak fifteen-minute arrival and departure counts, entry and exit sized separately.
• Measured end-to-end transaction time, the resulting lane count, and the design utilisation used.
• Required queue reservoir length in metres, demonstrated not to reach the public road.
• The payment model and the decision on whether payment happens at the exit lane or away from it.
• Barrier safety standard named — EN 12453, or UL 325 with ASTM F2200 — with safety photocells, loops and anti-drop protection listed.
• Barrier opening and closing time stated for the actual boom length, plus tested cycle life and behaviour on power failure.
• Ambient temperature range, dust conditions and housing finish for outdoor equipment.
• Documented API, data export format, and client ownership of data and accounts.
• Retention period, access rights and deletion process for recognition images and movement records under the Personal Data Protection Law.
• Occupancy accuracy defined by measurement method, with a reconciliation procedure where counting is used.