ALPR for parking: how plate recognition works

Automatic number-plate recognition (ALPR, in Europe often called ANPR) has moved from expensive specialist hardware to software that runs on standard cameras. Car parks, logistics yards, company campuses and residential complexes use it to open barriers for permit holders, record entries and exits, and alert security when an unauthorised vehicle appears.

We built an ALPR system as the recognition engine for the parking module of Smart DigiBuild, the platform we develop for Four Corners Technology. This article explains how such a system works, what affects accuracy, and what you need to consider for data protection in Germany.

The pipeline in four steps

A modern ALPR system is a chain of specialised steps rather than a single model.

1. Capture

A camera covers the entry or exit lane. Image quality matters more than anything else downstream: the camera angle (ideally less than 30 degrees off the plate), shutter speed (fast enough to avoid motion blur), lighting (infrared illumination for night operation) and resolution at the plate (as a rule of thumb at least 100–150 pixels across the plate width). Most accuracy problems we see in practice are camera-placement problems, not AI problems.

2. Detection

An object-detection model finds the licence plate in each frame. We use YOLOv8, a fast, well-supported model family that can be trained on plate datasets and runs in real time on modest hardware. The detector outputs a bounding box and a confidence score. To avoid processing every frame of a slow-moving car, we track vehicles across frames and keep the best image.

3. Recognition (OCR)

The detected plate is cropped, straightened and enhanced, then an OCR model reads the characters. We use EasyOCR, combined with image pre-processing in OpenCV. Post-processing is crucial: the raw text is normalised (spaces, hyphens), corrected for typical confusions such as 0/O or 8/B, and validated against the plate format of the country. German plates, for example, follow a known pattern of district code, letters and digits.

4. Decision and action

The normalised plate is compared with the list of authorised vehicles, such as employee permits, visitor passes or tenants. Then the system acts: open the barrier, log the event, or raise an alert. In our implementation, unauthorised vehicles trigger a real-time notification via AWS SNS (email or SMS), and each event is stored with its image in Amazon S3 for review.

The service around the model

Models are only one part. A production system also needs:

• An API (we use FastAPI) for events, statistics, permit management and configuration.
• Monitoring of throughput, latency and errors, in our case with CloudWatch, so you notice when a camera goes dark.
• Deployment with Docker, so the same service runs on an edge box next to the camera or in the cloud.
• A human review screen for uncertain reads, with the image and the model's confidence.

What affects accuracy

• Camera placement and lighting, by far the biggest factor.
• Plate condition: dirt, damage, stickers and non-standard fonts.
• Weather: rain, snow and low sun.
• Speed: barrier lanes are easy; free-flow lanes at speed need better cameras.
• Local plate formats: a model trained only on one country's plates will struggle with others.

Realistic accuracy for a well-installed barrier lane is high, but never perfect. Design the process for the exceptions: a fallback for unread plates (an intercom or ticket), and confidence thresholds that send uncertain reads to a human. We are collecting accuracy figures from our deployment to publish them.

Edge or cloud?

Recognition can run on site or in the cloud. On site (edge) means lower latency, no video upload and continued operation when the internet fails; only events leave the location. Cloud processing simplifies operations for many sites but requires uploading images. For barrier control we recommend the edge; for analytics across many locations, a combination.

Data protection in Germany

Licence plates are personal data under the GDPR, because they can be linked to a vehicle owner. That does not make ALPR impossible, but it requires care:

• Purpose limitation: define the purpose (access control, security) and use the data only for that.
• Legal basis: typically legitimate interest (Art. 6(1)(f) GDPR) for access control on your premises; document the balancing of interests.
• Transparency: signs at the entrance informing people about camera use and ALPR, with a link to the full privacy information.
• Data minimisation and retention: store plates of authorised vehicles only as long as needed, and delete images of normal entries quickly. Automatic lifecycle rules in storage help enforce this.
• Access control: only authorised staff may view images and logs.
• Works council: if employees' vehicles are recorded, involve the works council.
• DPIA: for larger installations, a data protection impact assessment is often required.

Building privacy into the architecture from the start, for example by processing on the edge and keeping only events, is far easier than adding it later.

Typical use cases

• Employee car parks with permits and visitor passes
• Logistics yards with time slots for trucks
• Hotels and residential complexes with guest parking
• Car parks without tickets, with payment linked to the plate
• Security monitoring of restricted zones

Frequently asked questions

Do we need special ALPR cameras?

Not always. Good IP cameras with sufficient resolution, a fast shutter and infrared illumination are often enough for barrier lanes. For fast free-flow lanes or long distances, dedicated ANPR cameras are worth it.

Can ALPR work with foreign plates?

Yes, if the models and the format rules cover them. Near borders or at airports, plan for plates from several countries and test with real examples.

What happens when a plate cannot be read?

The system must have a fallback: an intercom, a ticket, or a manual review by staff. Uncertain reads should never silently deny access.

How long may we store the data?

As short as possible for the purpose. For access control, events of authorised vehicles are often kept for a few days or weeks, and images of normal entries can be deleted much sooner. Define the periods with your DPO and enforce them automatically.

Planning checklist for an ALPR project

1. Define the purpose and the lanes to be covered.
2. Survey camera positions, angles, distances and lighting at each lane.
3. Decide edge or cloud processing, and how the system connects to barriers.
4. Prepare the permit data: who maintains it, and how visitors get access.
5. Agree retention periods, signage and access rights with your DPO and works council.
6. Run a pilot on one lane for several weeks, including night and bad weather.
7. Review uncertain reads and tune thresholds before rolling out.

Conclusion

ALPR combines a detection model, OCR, careful post-processing and a solid service layer. The AI part is well understood; success depends on camera placement, handling exceptions and privacy by design. If you are considering plate recognition for your site, we are happy to share what we learned and to check feasibility in a short AI sprint.

Talk to us about computer vision