Smart mobility, parking and plate recognition
A car park or a fleet that runs with nobody in the booth: the camera identifies, the system calculates, the payment closes.
The problem this solves
In a car park or a fleet, every second of waiting at the barrier is visible to everyone. The vehicle arrives, the camera takes its picture, and from that moment the system has a fraction of a second to know who the driver is, whether there is a subscription, and how much is owed.
The difficulty is that the information lives in two worlds. Edge hardware speaks its own protocol, and the subscription and payment systems speak another. Without a layer that joins them, you are left with a person in the booth fixing things by hand.
Payment adds to that: it has to work from the app, from the barrier and from the office, and land in the same accounting system.
How Target runs such projects
We either own the project end to end, or join an existing team that already runs a system. On these projects we always start with a survey of the hardware in the field, because it sets what can be promised.
The specification defines the scenarios: entry, exit, subscriber, visitor, exception. The architecture separates the hardware layer, the recognition and payment engine, and the management screens, so a camera model can be replaced without touching the rest. Development moves in versions, and we test in the field against real traffic.
After going live there is monitoring of stations and recognition rates, handling of field faults, and further development.
Example project
We built a platform for parking and fleet management that serves thousands of end users a day. It identifies vehicles by license plate recognition, closes payment quickly, and connects directly to the central admin systems. Entries and exits run fully automated.
How a project starts
- 01 Project ownership
We either own the project end to end, or join the client's existing team and work alongside it. We agree on which way to work at the start.
- 02 Specification and architecture
The specification is written with the people who actually use the system. The architecture follows: separation between components, a permission model, and the way external systems connect.
- 03 Build and production
Development moves in versions, with code review and a fixed code standard. After going live there is ongoing monitoring, incident handling and further development.
Questions we get asked
Our cameras and sensors are already installed. Can you work with them?
Usually yes. We work against existing edge hardware through its interfaces and add a software layer that normalizes the data. If an interface is missing or partial, we check it before committing to a schedule.
What happens when recognition gets it wrong?
No recognition system is right one hundred percent of the time. We build an exception path: the case is stored with its image, goes to a control room or a service person, and the vehicle is released without holding up the queue.
Can the system connect to our existing management systems?
Yes. Entry, exit, subscription and payment data flows into your admin and financial systems through APIs, and operational reports can be pulled from there.