Assumptions
In order to provide a "proof of concept" of the solution some simplification have been made, for example it has been skipped the communication between the smart driver license and the car's device.
A possible way to implement the solution is to put an RFID tag on the smart driver license so the device can read it contactless. However this implementation needs a method to distinguish between different driver's license if there are multiple passengers on board. A simpler implementation can be one that requires the insertion of the driver license inside the car's device to perform the read.
Another semplification made is the usage of WiFi and a WSGI interface as communication protocol between the cars and the speed camera. While it is still a valid choice maybe it is not the best one because it requires the presence of a router to perform the communication. The usage of HTTP requests instead of Web-Server interfaces can be a better choice in a real implementation scenario. Also different protocols can be used such as EnOcean(ISO/IEC 14543-3-10) or Bluetooth (BLE 125k(coded)). It's important to keep in mind that the application scenario requires a protocol that can perform transmission at rather long distances (about 100m) and at high speeds (not much because of the size of data, but rather for the duration of the connection - 3 to 5 seconds).
All the processes of a normal speed-camera are left out of scope. The arrival of a photo is simulated with a boolean variable that becomes true randomly, the photo is actually chosen selecting one of the plate's numbers received by the server before the trigger enable.
Materials
Client (car's on-board device)
 |
A Raspberry Pi 3 model B mounting RaspberryPi OS (32bit) has been used to simulate the connection of different clients. The device will run the script client.py which through a simple loop simulate the sequential connection of 10 different clients. This device was chosen mostly because it runs Python natively and comes with a built-in WiFi module. |
Server (smart-speed-camera)
 |
The server has been simulated using a notebook PC mounting Windows 10 and running Python 3.9.13. Any Python 3.x version can be used but 3.9 is recommended for Tensorflow Object Detection API's best compatibility (accordingly to docs). The server will run the script my_server.py that simulate not only the server side processes of the application (from receiving packets to displaying driver's detalis) but it also simulate the asynchronous arrival of a photo using a simple random integer generator. |
Setup
It's been chosen to control the Raspberry Pi through its own monitor, mouse and keyboard to emphasize the fact that client and server are two different devices in any way not connected but the Raspberry Pi control could also be done via SSH (having only the terminal interface) or VNC (if also the GUI interface is needed).
Video of the simulation
Future developments
- driver's license - on-board device communication interface development
- deeper model's training
- speed-camera common features implementation
As already mentioned a possible implementation of the communication between the smart driver's license and the car's on-board device can be done using RFID technology, maybe with a simple GUI interface to let the driver choose the correct license and a sort of registration/login to perform before the first use of the car to avoid both privacy and security issues.
The plate recognition model needs a better and deeper training with a larger dataset to improve its performance. Unfortunately it is difficult to find an appropriate one on the internet probably for a privacy issue and creating one would take a huge amount of time.
The server side of the application can be improved developing the interface with a real speed-camera in order to mount it on it. In a possible project roadmap this will probably be the last topic to develop after the ones mentioned above.