Perhaps we should start with some inalienable truths. One is that ANPR (Automatic Number Plate Recognition) technology is sophisticated stuff and it’s not inexpensive – certainly not if you want performance at the decent end of the accuracy scale. Another is that you may often see near-identical cameras on adjacent poles, or on the same bridge parapet, doing the same thing for different civil authorities; in many countries those same authorities are currently being subjected to swingeing cuts in their budgets.
ANPR equipment (in the UK at least) is often paid for by the taxpayer, who wants less crime, fewer uninsured drivers on the roads and some level of reassurance that terrorism is being effectively countered… as well as less congestion, fewer accidents and, generally, a more efficient road network. Whether or not they realise it, therefore, taxpayers want more ANPR – always provided, of course, that they aren’t somehow its ‘target’. They also want better value for money and, of course, joined-up thinking, and procurement, within government.
A rare breedThe use of ANPR to accomplish multiple tasks would seem a ‘no-brainer’, then (or a ‘slam-dunk’, depending on your vernacular).
However, the truth is that too few ANPR cameras provide data for multiple purposes. The answer why is somewhat less glib than the statements above. It’s to do with protocols, and the difficulties associated with exchanging information between systems that have evolved, to use current jargon, in separate ‘spaces’. It’s also to do with the fact that, until recently, there hasn’t been any kind of a standard for the communication of ANPR data (primarily licence plate reads, timestamps and images of vehicles); suppliers of licence plate reading systems, when there was no kind of common standard, understandably did not knock on the doors of their competitors and ask, “May I have your communications protocol please?”
Not only did ANPR systems speak different ‘languages’, they communicated different content, and in different ways. Some could send only data and no images. Others could send data and images together, while others could send data and then accept subsequent requests to forward related images. Often, a protocol would only provide for communicating with a single host (or instation).
And so, inevitably, instation systems evolved which only understood one language and one type of content. Like their ANPR counterparts, their functionality was defined by the application that they were primarily intended for – be that journey time measurement or police surveillance. It is perhaps inevitable that the path of instation software development takes the shortest route between two points. Any suggestion that ANPR cameras could be shared would then meet stumbling blocks like “The camera doesn’t supply that information”, “We’ll have to re-write the protocol”, “The instation can’t deal with that kind of data”, “IT policy won’t allow the bridging of these two networks” and so on. It is easy to see that the process of finding the optimum solution in the face of the vested interests of up to four suppliers and two customers would be a challenge that many would baulk at, not to mention the impact on implementation timescales of the additional development, testing and system integration.
Unsurprisingly, in many cases the path of least resistance was to buy a second system.
So, camera-sharing has been the exception rather than the norm. But those who have made the effort have reaped significant benefits. Amongst early adopters in the UK were Bristol City Council and Avon & Somerset Constabulary, who amalgamated their small, segregated ANPR systems, giving both parties substantially improved network coverage which they wouldn’t have been able to afford had it meant extending their individual networks.
However, this did involve the challenge of developing a new system architecture including, on the one hand, a central data server to forward the relevant data to the City Council’s journey time processor and, on the other, to the Constabulary’s surveillance system.
But doing something similar has become a whole lot easier. The development of the
Most importantly, in addition to providing a unified data interface, the protocol also makes provision for ANPR sources to transmit information to multiple host systems and to tailor the information sent to suit the individual host applications. So, with a suitable caveat relating to adequate communications bandwidth, a journey time system sees a dedicated journey time camera, and a surveillance system thinks it is talking to a dedicated surveillance camera. Camera sharing couldn’t be simpler.
Making it happenSo what do agencies wishing to share cameras need to do? Basically, each needs to define the information it requires for its applications, and combine these into a joint specification that can be given to an ANPR camera supplier or included in a suitable tender. Then, agreement needs to be reached on how power and communications are to be supplied to each camera installation and, in particular, on the communications bandwidth required. Whether new infrastructure is required for mounting the cameras, or whether existing poles or bridge parapets can be used also needs to be considered.
Then it’s necessary to have a discussion about the sharing of costs. This has the potential to be very straightforward, literally: “Let’s pool our capital and revenue budgets and buy as much equipment as we can afford to run which meets the joint specification.”
Others may take a more measured approach and agree a division of costs which takes account of one of their applications requiring more expensive equipment and running costs than the other. For example, a surveillance camera may need to incorporate a second sensor for providing colour overview images, which is not required, for instance, in a journey time camera. Similarly, the transmission of images requires a communications link of significantly higher bandwidth and cost.
The issue of ANPR performance (primarily accuracy) also needs to be considered. When in the UK one of the agencies is a police force, all cameras must meet NAAS (National ACPO ANPR Standards) performance requirements, which may mean looking towards the upper end of the market.
Compelling argumentGenerally, though, it is not difficult for agencies to agree a basis for collaboration, as the resultant benefits are so compelling. In purely financial terms, the capital and running costs to each agency of every camera can be almost halved, so the result is that agencies get a lot more cameras and network coverage for their (limited) budgets. This fiscal benefit is compounded by the ability to command a lower price for higher volumes.
However the real win is in the increased quality of information which results from a larger, more comprehensive ANPR network. For example, a police force budget may only stretch to funding cameras on half of the arterials into a city. The City Council ITS budget similarly may only provide for journey time measurement on a limited selection of routes into the city centre.
But by combining these budgets and the police force has that ‘Ring of Steel’ that it really wanted and the City Council has a complete journey time network that can give high-quality information to the travelling public and provide comprehensive data to its traffic control centre for the more effective management and planning of its road network.
Living proofThe first such collaboration that required UTMCcompliant ANPR cameras occurred just to the west of London, England, in Buckinghamshire.
There the County Council and Thames Valley Police used the Evo8 camera from
Both Cloud Amber and QRO needed to implement the UTMC interface in their instation software but, since the protocol is XML-based, this was a relatively quick and straightforward exercise which both companies were willing to carry out. Naturally it also positioned them well to undertake further projects requiring UTMC compliance.
The spectacular cost benefits in this project are highlighted by the fact that one of the factors leading to the choice of the Evo8 camera was its capability to monitor two lanes of traffic. As most of the Aylesbury arterials are two-way single carriageways, only one camera is needed at each location to monitor both inbound and outbound traffic. Although only 11 Evo8s were initially required, had there been separate Council and Police networks using single-lane cameras, a total of 44 would have been required.
The idea is now gathering momentum, and the ‘benevolent circle’ of benefits in even larger projects is being realised. For example,
Hertfordshire County Council is currently tendering for 75 ANPR cameras which must be both UTMCand NAAS-compliant, and therefore suitable for use by the Police. It is certain there will be more to follow. Having been at the forefront in urging the industry to develop an open protocol, it seems highly likely that all UK local authorities will in future require UTMC compliance in any ANPR systems they purchase, thereby opening up great potential for future camera sharing.
But the possibilities for co-operation are not restricted to local authorities and police forces. There is the opportunity for commercial companies to generate business intelligence (such as direction of arrival, departure and length of stay of vehicles at retail complexes and amusement parks) by sharing systems with local councils who wish to improve their management of traffic in the locality. There are many other users of ANPR systems such as airports, port authorities and supermarkets all of whom could find benefits in collaboration.
We have yet to see a collaboration of three or more agencies but Buckinghamshire has provided a strong first example of what is already possible.