If you are building or integrating plate reading at an industrial gate, the camera and the model are the easy part. The hard part is turning noisy reads into reliable events that the rest of your gate system can trust.
One read, one event
Treat every read as an immutable event, not a database row you keep updating. A minimal shape:
{
"event_id": "gate2-in-20261013T061244-0187",
"lane": "gate-2-in",
"plate_raw": "MH43 AB 1234",
"plate_norm": "MH43AB1234",
"confidence": 0.91,
"image_ref": "images/gate2/0187.jpg",
"captured_at": "2026-10-13T06:12:44Z"
}
Keep the raw string and the normalised one. When a dispute comes up, the raw read and the image are your evidence.
Normalise before you match
Strip spaces and separators, force upper case, and handle the classic confusions: O and 0, I and 1, B and 8. Validate against the plate formats you expect, such as Indian state formats or Gulf formats, but do not reject a read just because it fails validation. Route it for review instead.
Use confidence as a routing rule
A single threshold is too blunt. Three bands work better:
- High: match to the booked trip and open the barrier automatically.
- Medium: show the guard the image and the best match, and let them confirm.
- Low: ask for manual entry and store it as an override with a user ID.
Tune the bands on a week of your own lane data, not on vendor samples.
Deduplicate bursts
A truck that stops under the camera can produce several reads. Collapse reads of the same normalised plate in the same lane inside a short window, and keep the highest-confidence image.
Fail soft
Gates cannot stop because a network link dropped. Buffer events at the edge, give each one a stable event_id, and make the server side idempotent so a replay never creates a second trip record.
For the business side, including where plant and port gates use this and what to test in a trial, see the full guide: number plate recognition for plant and port gates.
Top comments (1)
Agree on events and idempotency. Where I'd push back a little is "the camera and the model are the easy part". Doing plate reading at impound yards and parking lots, most of our misses happened before the model: backlight at the gate, dirty or bent plates, the camera angle, read speed, and above all the trigger, when to fire the shot and how to crop it. With recognition running on the server, a motion-blurred frame or a bad crop arrived there with nothing usable to read, and false negatives were high.
On the medium band: human confirmation works on paper, but with real access volume the guard can't keep up, and the review queue becomes the bottleneck. How do you size that band so it stays reviewable at peak hours?