Properly used, technology can enable one law enforcement officer to perform the work of many officers in less time. Automated license plate recognition (ALPR) is an example of one of these technologies. Cops once used “hotsheets” of recently stolen vehicle license plate numbers to check cars they saw or were about to stop while on patrol. The hotsheet fell into obsolescence when mobile data came to patrol cars, allowing officers to key in plates to determine their wanted and registration status.
With ALPR, that task has been automated and augmented so that the officer need not look out for wanted plates or vehicles at all. The ALPR system scans every plate within its view and compares it against an internal hotsheet of thousands of plate numbers, immediately notifying the officer when a hit occurs.
The first license plates in the U.S. were issued by Massachusetts in 1903. So, it may have taken over a hundred years before we had ALPR, but the progress of the technology has accelerated dramatically. The earliest ALPR pilot projects in the U.S. targeted stolen cars, and their performance was nothing short of brilliant.
Even limited deployment of ALPR resulted in more than six times the number of stolen vehicles recovered via conventional methods. Now that the technology is mature and its value recognized, ALPR vendors have added multiple bells and whistles and implemented software features that take ALPR well beyond its value as a stolen vehicle detector. The Basics
ALPR brings together specialized cameras, lighting, optical character recognition and electronic databases to identify license plates, read the characters from them, and compare them against a list of license plates of interest. The cameras, mounted on a patrol vehicle’s bumper or lightbar or at a fixed point, scan vehicles that come within their view. The cameras have a built-in infrared light source that either burns steadily or (more often) pulses at varying intensities to exploit the reflective surfaces manufactured into most plates.
Algorithms built into the camera software locate the area on the vehicle where the plate is most likely found, and isolate the image of the plate from other artifacts such as fancy grilles or reflective bumper stickers. At the same time, the camera records a conventional photo of the vehicle with the license plate in context.
An optical character recognition engine, optimized to allow for plates viewed at extreme angles that distort the characters on the plate, converts the image to the numbers and letters that make up the license plate. This information is sent to the database comparison application, which contains a list of license plate numbers. When the string of characters from a scanned plate match a string in the database, the system operator is alerted.
The operator typically sees a multi-pane display showing the captured image of the vehicle with or without an enlarged portion isolating the license plate. Another pane shows the characters read from that plate, and the details of the database entry matching the plate. The details may identify the license plate as stolen, a plate associated with a wanted person, one whose registration is suspended or has been flagged as having no liability insurance, associated with multiple unpaid parking tickets, or any other reason the agency operating the system chooses as something to watch for.
The operator first compares the actual plate against the database entry to guard against a misread by the system. If the reason for the plate to be flagged is something contained in a national or local database, he runs a separate inquiry to determine if the “want” is still current. If everything checks out there, the operator either goes after the vehicle himself or directs a separate unit to stop the car, relaying the reason for the stop.
All this can happen while the patrol vehicle is stationary or moving. A stationary vehicle on a freeway overpass or traffic median might be able to monitor as many as eight lanes of traffic, both oncoming and in the same direction as the patrol car, simultaneously. A fixed-point camera can do the same thing. This is accomplished by having multiple cameras mounted on the same car or fixed object, facing in opposite directions.
When the cameras are moving, they can capture license plate images of both parked vehicles and moving vehicles at closing speeds of up to 160 miles per hour (vehicles moving toward each other, each at 80 mph). The cameras never look down at the speedometer or their cup of coffee, never get tired and never blink. It’s easy to see how this can be a force multiplier for patrol officers. One officer with an ALPR system can scan and compare more license plates than a whole squad of cops and still perform other tasks while doing it.
There is a computing standard characterized as “Garbage In, Garbage Out.” This means that the analysis of your data is only as good as the data itself. If the database being used by the ALPR system is outdated or full of errors, the alerts it provides will be useless, too. It would be like a 1980s cop going on patrol with a hotsheet from 1970.
In the most basic sense, the list of license plate numbers of interest is nothing more than a flat-file database with two fields per record: the plate number and the reason the number is on the list. This is dynamic data that changes from one hour to the next as stolen vehicles are recovered, arrests are made, fines are paid, and new items of interest are identified.
In an ideal environment, every license plate identified by the ALPR system would be run against NCIC and any regional and local online databases to determine if the vehicle is wanted, all in real time. This is impractical. The sheer volume of inquiries would overwhelm most automated switchers and servers, and most wireless public safety data systems aren’t capable of carrying that much traffic.
The second-best solution is to maintain a database of license plate numbers on the same computer running the ALPR system, and then verify each hit by voice radio or over a wireless data network. Refreshed at least once per duty tour, this is a sufficiently reliable system for practical use, although that independent verification step is critical. The question here is: How do you update your database?
The solution most commonly used is “sneakernet,” meaning that someone runs (or walks) between the base station and the mobile computer with a device carrying the data. For most applications, the database will be small enough to fit onto a flash drive. Flash drives with capacities of 16 gigabytes are commonly available for under $50. One gigabyte (GB) equals 1024 megabytes (MB). If your data doesn’t take up that much space, the flash drive required is smaller, and a lot cheaper. If you need more data than a flash drive will hold, external hard drives of 200 GB and larger can be purchased for less than $200.
Most vendors have or are adding wireless synchronization solutions to their features list. A wireless link can work over the existing wireless data network, but the more common medium is a local Wi-Fi network. Wi-Fi networks set up with the proper encryption standards and restricted access filters are secure enough for public safety use. They aren’t uncrackable, but they require considerable expertise, time and effort to hack successfully. Frequently changing the encryption codes and encrypting the data itself before it’s sent makes such a system very secure.
In the most basic configuration, the database contains only the aforementioned list of license plate numbers and reasons the plates are on the list. But most ALPR systems record and store each license plate that is scanned, plus the infrared and conventional photographs of the vehicle carrying the plate. This adds a lot of bulk to the file size.
For example, one vendor estimates that 50,000 to 60,000 plate reads require about one gigabyte of storage on their server. Their system is capable of reading four plates per second, so that works out to around 3.5 hours of scanning time per GB of storage if the system was running constantly at max capacity. Unless the system was monitoring a busy freeway, it’s unlikely it would be accumulating data that rapidly.
Adding GPS information to the recordings of plate scans doesn’t add a lot to the file size, but it makes the data gathered by a mobile ALPR unit far more valuable. Criminal intelligence is like any other form of operational data in that you often don’t know what is valuable when you’re collecting it.
Most field interview (FI) cards filled out by patrol officers go into a file, never to be seen again. If those FI cards are properly indexed, they are great sources for investigative leads on burglary, robbery, prowling and other crimes. They place individuals at a specific place and time, or establish that they frequent a particular location. ALPR systems gather the same sort of information.
For example, say that a patrol car outfitted with ALPR is assigned to regular patrol duties. The officer driving the car makes his way down the various streets in his district while he is not assigned to a call or while responding to calls. He may drive through some parking lots of malls, businesses, grocery stores and such, recording each license plate as he passes it. At the end of watch, the scanned plate information is uploaded to a “back end” server.
The back end server, which is a critical component of a ALPR system, resides at headquarters or at a remote site linked to headquarters. The back end server maintains the master database of both license plates of interest and scanned plates and their associated information. The back end server interfaces with other data networks like NCIC, and parses that information so it can be used by the field ALPR units.
The back end server is also a rich source of criminal intelligence, and it becomes more useful as the database grows. As an example, say that your community has experienced a series of residential burglaries. The modus operandi reflected in the crime scenes suggests the crimes were committed by a single person or crew, but it doesn’t match any M.O. familiar to your investigators.
Armed with the location and time windows for each offense, you query your ALPR back end server. “Search for any license plate that appeared within 200 yards of these addresses during the following hours and dates.” There may be no plates found, but if your system has been running for a while and ALPR-equipped patrol vehicles were scanning plates in those areas during the target periods, you’re likely to come up with a vehicle of special interest.
You won’t just have the license number of the vehicle—you’ll have a photo showing the color, make and model, as well. If you can’t locate the vehicle to have a chat with the owner / occupants, just include the plate in the list that goes to the field ALPR units. They’ll probably run across the vehicle, quite possibly with your burglar inside.
Another use for the scanned plate database is for wild card searches. When a witness sees a vehicle leaving the scene of a robbery, they report only a partial plate: A****4 on a dark-colored SUV. If your state uses a three letter / three number license plate format (e.g. ABC123), there are more than 67,000 plates that could bear those characters in those positions.
You can run an offline search of your state’s license plate files, but you’ll still have a big list to sort through, and although you’ll have the make and model of each vehicle, you probably won’t have colors. Instead, you take your wild card search to the ALPR server. The result will be a list of only vehicles seen in your city (and you’ll know where and when), with a color photo of each. Your list of investigative leads is now very much shorter.
Some mobile ALPR systems can be configured for wild card searches, as well. Field operators will be alerted to any license plate that matches the template in the database, and decide whether to investigate further.
ALPR is also useful for keeping track of sex offenders and people restricted by protective orders. Use of the technology in this way is called “geo-fencing.” The mobile system is programmed with the GPS coordinates of target locations such as schools and homes and businesses where persons under protective orders live and work.
If a vehicle belonging to a sex offender is scanned within X feet of a school, or a stalker is close to the home or workplace of his victim, the field ALPR operator is alerted. If a probation officer wants to check up on one of these offenders, he can request a search of the back end server database to see if his client has been someplace he wasn’t supposed to be, how often, and if he was stationary or moving.
Legal and Privacy Issues
There aren’t many legal barriers to the use of ALPR. So long as the ALPR system is “looking” at areas in public view, there is no reasonable expectation of privacy in the location / time / place of that vehicle. There may be laws in your state affecting what criminal intelligence records may be retained, for how long, and for what purpose, so each agency has to ensure it is in compliance.
Privacy advocates are more likely to create political barriers to the acquisition and use of an ALPR system. There is plenty of room for misuse and abuse of this information. Cheating spouses, closet gamblers and drinkers, and even workers playing hooky can be exposed by the information in an ALPR database. It’s a sure bet that someone will try and use it that way, so it’s very important to create safeguards against improper exploitation of the system. But even if you make unauthorized access to the system bulletproof, you may have to contend with citizens who just don’t like the idea of their police department keeping track of their comings and goings.
This is the time to look into acquiring an ALPR system. There is grant money available, and vendors will assist you with the grant application process. Talk to vendors, talk to their existing customers, and make sure you have support available at your location. Once you’ve done that, tell the people who maintain your evidence lot to clear some space.
Tim Dees is a retired police officer and the technical editor of LAW and ORDER. He can be reached at firstname.lastname@example.org.