Design Concepts of an Application Platform for Traffic ...

Design Concepts of an Application Platform for Traffic Law Enforcement and Vehicles Registration Comprising RFID Technology Vladimir M. Vishnevsky

Andrey Larionov

R&D “INNET” Moscow, Russia Email: [email protected]

R&D “INNET” Moscow, Russia Email: [email protected]

Abstract—The article describes design concepts of a novel application platform for vehicles identification and traffic rules violations registration. The platform adopts different equipment including RFID-readers, video-cameras and speed-radars. The platform supports both wired and wireless interfaces for data transmission and can provide police stations with up to date data about traffic rules violators. Design background and key features of the platform are presented. We also discuss the platform internal structure, key functional elements and protocols. Finally, we provide some results on testing the system and its key components.

I. I NTRODUCTION Most road traffic accidents are caused by people violating traffic law. In particular, one third of fatal crashes are caused by drivers violating speed limits. To face this problem the most countries implement automated traffic law violations registration systems. Traditionally, these systems enclose various equipment for vehicle video capturing and violation recognition. There are lots of systems for different traffic laws including speed limits, red light, bus lanes and even parking. One should also notice speed cameras measuring average speed over a fixed distance - these systems can avoid speed radars usage and make drivers more strictly observe speed limits. Traffic laws violations registration is usually considered as the main objective of such automated systems. But the performance of the law enforcement system significantly increases when that system can inform police about the violator as soon as it recognizes the violation. To make this happen, the system must have some interfaces to communicate with the police in real time. Moreover, as soon as traffic law enforcement systems perform license plates recognition they can also deal with stolen cars identification and help police in searching for criminals. The traffic law enforcement systems can be either placed statically, or move with the police cars from one place to another. Moreover, some systems can operate inside the moving car, for instance - parking law enforcement systems. Concerning the case when the system moves, it should be provided with additional information about rules in force in the specific geographical region. Such information can be

provided manually (which can be difficult and error prone), automatically via wireless networks, or via some predefined values. Anyway, the system should determine its current position using GPS or, for instance, using some data it can read from RFID tags, preliminary established on the roadside. General overview of a traditional traffic law enforcement system can be found at fig. 1. The primary disadvantage of the video-based vehicle identification approach is its dependence on weather conditions and license plates status. If license plates are muddied or if it is heavy raining or snowing such identification becomes practically impossible. Violator driving style can also prevent the identification. For instance, some systems fail when the driver frequently changes his driving lanes near the cameras or instantly slowdowns. At the best, the recognized number can be used in the police for the subsequent visual identification by the officer. Worse, the violation won’t be registered though it took system time for the recognition attempt. Perhaps, the best way to deal with this disadvantage is to attach an additional identification source to the vehicle. Passive UHF RFID [1] tags fit very well for this purpose: they do not need additional power source, while being small enough to fit on the license plate and have enough memory to carry license plate number and even hold some additional data like VIN code, vehicle model and color in the user memory. The latter can be very useful for stolen cars prompt disclosure. If placed on license plates, RFID tags can also prevent plates frauds. Data can be previously encrypted to make the tag falsification very difficult. 10 meters of tag effective range is usually enough for automated law enforcement system and prevents unnecessary reads. The ability to communicate with police stations in real time should also be provided by the law enforcement system. When designing a system, one should consider different solutions and take into account the environment. For instance, in Russia there are thousands kilometers of roads without roadside fiber-optic cables. Though wired solutions fit well when the system needs to send a large amount of video data, their absence should not break the ability to communicate with the police. Today there are different wireless solutions providing

Fig. 1.

Traditional automated traffic law enforcement system general overview

high enough throughputs for carrying multimedia data. These technologies include IEEE 802.11n MIMO, free-space optics (FSO) and millimeter-wave links. Anyway, the traffic law enforcement system should utilize any of the existing wired or wireless technologies and it shouldn’t depend on any specific wired communication technology. Despite the evolution and prevalence of traditional videobased traffic law enforcement systems [2], the alternative ones created based on the principals of the wireless broadband communications [3] and RFID technology [4] doesn’t exist at the present time. One more disadvantage of existing traffic law enforcement systems from integrator and developer point of view exhibits when somebody needs to integrate them in the common database or to add some additional features. Different data formats and system designs make the task of implementing new features across several systems very laborious and hardly supportable. A modular application platform enclosing legacy systems can solve the problem by localizing communication with the system at the level of a single adapter and providing open interfaces to the other world. All the background mentioned above leaded to the necessity to design and implement a modular application platform which can enclose traditional traffic law enforcement systems, video cameras, speed radars, RFID-readers and other sources of identification and laws violations recognition related data. The system must be able to communicate with the other world across wired or wireless networks. Each platform should also be able to collect traffic from its neighbors to provide the data aggregation, processing and forwarding to the next platform or, if directly connected, police stations. The platform also must be able to collect data from its environment like roadside

RFID-tags, positioning information from satellites and other kinds of data. To make the solution universal enough, the platform should be able to perform different algorithms of collected data processing, which should be added to the system as modules, depending on the current use case. In the long term perspective such application platform can be integrated with face recognition solutions for criminalists assessment and other identification techniques. The paper is organized as follows. In the second section we define the primary requirements and observe main features of the application platform. The third section contains an overview of the platform structure and provides a platform example. Some platform insights, including its entities, modules and protocols, are given in the fourth section. The fifth section contains a description of the current development and testing status. Section six concludes the paper. II. A PPLICATION

PLATFORM REQUIREMENTS

The platform must be able to handle identification of different objects, while each object can be identified by a set of attributes. The objects can move within wide speed range, up to 160 kmph or above. The primary identification sources are photo pictures, video data and RFID tags. Other data sources may include satellites, neighbor platforms, external databases and others. The platform must provide different physical interfaces for management, administration, statistics aggregation and for collecting identified objects. The platform has the following features: • simultaneous execution of several identification algorithms - for instance, identify speed violators and send online video from a camera; • data protection from theft or falsification - when transmitting data to the police station or between neighbors,

•

•

•

•

•

•

•

•

•

•

•

the data can become a subject for an attack; data from neighbor platforms aggregation, processing and forwarding - if some platform is not directly connected to the police station it should send its collected data to the neighbor which will combine the data with what it has collected and forward the combined data to the police; modularity for the ease of platform reconfiguration and customization - most of the platform features are implemented as software applications which can be added without even system reboot; reserve all platform or separate modules - it is not necessary to make all the platform redundant, but it is desirable to reserve supervisor, logging and management modules; independence from any specific physical communication interfaces - platform should be able to communicate via means it has at the moment; provide the support for data communications via wireless channels that are subjects to noise and errors - using wireless channels is a common option and often it is the single choice; reliability and high performance - reservation and platform distribution across several servers provide the feature; users identification and authentication - different users may have different access privileges in the system; compatibility with the existing management and administration protocols and technologies like SNMP, SOAP, etc. - ability of the platform to work in enterprise environments and connect with existing administration and management tools; provide separate channels for signalization and data protocols - at least, data shouldn’t go through the control path to avoid overloads leading to lack of control; divide data flows based on identified objects nature for instance, the information about recognized violators should go to one database, while the information about found mismatches between license plates pictures and RFID tags EPCs - to another; provide transparent control of enclosed devices for compatibility with existing applications - ability of the platform to work with existing application, the platform provides gateways which act as systems those are actually integrated inside the platform. For instance, if the platform comprises RFID-reader supporting LLRP [5], the client application can work with the platform via the predefined port as though the application works directly with the reader.

The key logical entity in the platform is a query. A query is an entity that holds information about what the platform should do, how long it should do it, which modules inside the system should do it and where they should send the result. A single query can cause several additional queries spanning inside the platform, as it will be shown in the example below. For instance, “find speed mode violators and send time, photo

picture, recognized license plate number and read EPC tag” is a query. Another query example - “make the pictures of all the cars on all lanes once and send them”. The latter should be performed once, while the first one - till somebody stops it. The queries are being served by the applications. Each platform can hold a specific user-defined set of applications. A user can promptly add or remove one without even need to reboot the platform. To start the interaction with any application, the user must subscribe to it. The subscription ability is being determined based on the user access rights. In the following sections we will briefly describe the key elements the platform consists of. III. A PPLICATION PLATFORM STRUCTURAL OVERVIEW An example platform is illustrated in fig.2. The platform consists of three separate servers connected via gigabit ethernet local network: • Access Server - acts as an interface to the outside world. It has one gigabit ethernet interface, one RS232 port and one wireless link. Each physical interface is connected to a separate logical interface, for instance RS232 port is connected to IFACErs232 logical interface. The server also holds a TrunkAdapter which acts as data source and connects to the same wireless interface the IFACEip connects to. The server holds a Supervisor which is connected to the terminal and WWW-server and logical switch CBUS which interconnects all the internal modules and processes internal signaling protocols. • App Server - holds several applications performing different tasks. For instance, PlateRecogApp collects data from radar-based external violation registration system and RFID reader, and processes the collected information to identify the violators, TrunkDataMerger applications merges data about violations received from neighbor platform with the data collected by itself. The latter is being received from TrunkDataManager. • Adapter Server - holds several adapters connected to identification devices: one video camera, one radar- and photo-based violations registration system and two readers, one of them has LLRP interface. It should be mentioned, all the modules illustrated in the figure can be placed on a single server or separate servers can be allocated for each module - the choice depends on the performance requirements and environment conditions. Also notice, that a single physical interface can act as the data source and sink (wireless interface in the example). The example encloses a single logical switch CBUS, while several CBUSes can be defined. The main goal of the logical switch is to route messages between different logical modules, and when some part of the system have a heavy signaling exchange (for instance - several connected applications), a separate CBUS can be placed to reduce the traffic load in the main CBUS. While signaling goes through the CBUS, data flows are sent directly between modules. Actually, it is possible to send data

Fig. 2.

Application platform example

flows via special proxy module, but this feature is out of the scope of the article. Modules use xIDCP signaling protocol and xIDDP data protocol for interconnection inside the platform. To cooperate with external devices the platform uses rIDCP and rIDDP. These protocol are quite similar, but there are differences between them, caused by additional services like authentication, data sessions creations and others, provided to the outside devices. Detailed description of the protocols is also out of the scope of the paper, but we will illustrate a simple session initiation below. One can notice, that the approach used in the identification platform design has much in common with the VoIP softswitches and application platforms. Moreover, the start of serving queries process is mostly similar to the initiation of a one-way SIP session used in some types of conferences, for instance. Exactly, one can think about the process of querying a platform for a specific type of data like “calling” it. Unfortunately, identification data nature and platform requirements have own specifics making impossible to fully adopt the VoIP approach.

IV. P LATFORM

COMPONENTS OVERVIEW

This section briefly observes key components, logical entities of the system and provides an example of session initiation. The application platform consists of several modules: adapters, interfaces, applications, buses, supervisors and different service modules for logging and management. Each module has its own role, while some modules have several roles. From the logical perspective, the system comprises different entities - data sources, data sinks, controllers and queries. A. Names Most entities in the system have hierarchical names. This approach allows easily address different entities and also make the new entities registration easy. Below we describe naming rules for modules, data types and queries. 1) Modules naming: Each module in the platform has three addresses. First of all, it has its own hierarchical name, based on its type. The typical name has the following format: NAME ::= IDM:[BUS|IF|APP|AD]:[subtype:]*(ASCIIstring|MAC)

C. Queries

Fig. 3.

Data types naming example

Fig. 4.

Data types naming example

This approach is very suitable when finding a specific module, but takes too much space in the xIDCP messages. To enable communication between modules, each module also has its associated IP-address and ports for processing xIDDP and xIDCP protocols messages. To address a particular module in the system, other modules can also use a dynamic 16-bit identifier that is gained by the module when it starts. 2) Data types: When a client starts a query, it must specify desired data types. Considering that various identification data have different nature, data types names also utilize hierarchical structure approach based on the data nature, see example at fig.3. However, a typical problem is that data type specifies too small amount of data. For instance, if one module needs EPC memory, it likely also needs a timestamp when the tag was read and signal strength. Such second-rate data types are called attributes. They can be specified along with the data type in the query. To make the discovery of modules supporting different data types easy, each data source announces data types it provides when the system or just the relevant module starts. 3) Queries: Queries names are also hierarchical. Current implementation defines only four different queries, see fig.4. Queries hold all actual information in their parameters, which exactly describe the query. Two queries with the same name but different parameters may act in different ways. B. Data sources and sinks Entities providing data to other modules are called data sources. Each data source specifies types of queries it can serve, a set of data types it can provide and the geographical regions the data relates to (for instance, number of lane for an RFID reader or a photo camera). Adapters and applications act as data sources. Entities that initiate queries and gather data from different sources are called data sinks. For instance, interfaces and applications act as data sinks.

Query is a temporal entity that is created by data sink and being sent to a data source. When the query terminates, the data sink and source loose their connection (of course, if they were not connected by some other query). Actually, when query is initiated, the sink attempts to find and connect sources via xIDCP. When the connection is established, sources send data to the sink via xIDDP. After the query is served, or when source or sink asks for session termination, the source and sink disconnect and the query is treated as terminated. Queries have the following attributes: • query type (see fig. 4); • a set of data types (see fig. 3); • priority; • instruction to encapsulate data in signaling protocol; • target sources set; • privileges; • additional parameters. Query and data types were already discussed above. Priority attribute helps to determine which query should be served if the same source can not simultaneously serve both queries. Data encapsulation allows the source to encapsulate gathered data into xIDCP messages rather then create xIDDP connection with the sink. Privileges specify access rights of the user that initiated the query (or initiated the query that initiated the current query several steps after). The query can also specify a set of sources that are allowed to serve the query. In particular, the query can specify a single source, or a subset of all sources. Sometimes a query needs to specify additional parameters. These parameters and attributes specified above are analyzed by the data source and depending on them the source either serves the query, or not. D. Buses Control buses are logical switches connecting different modules of the platform. For instance, when a sink initiates a query, it sends QUERY message to the CBUS and CBUS forwards it to the sources. CBUS doesn’t process xIDDP data flows messages. If proxy functions for data flows needed, special proxies can be instantiated in the platform. E. Adapters Adapters connect a platform with the actual data sources. A typical traffic law enforcement platform with RFID and photo camera devices contains adapters connected with RFID readers, cameras and, possibly, radar systems. To integrate an existing law enforcement system into the platform, the developer only needs to create an adapter acting as a gateway between xIDCP/xIDDP and the system interface, and also describe data types provided by the system. Adapters can act only as data sources. Note, that different adapters can have limitations on simultaneously served queries. For instance, a typical RFID reader won’t be able to read the user memory from a specific tag while reading all tags in the background mode via the same antenna. In these

cases, priority field allows the adapter to decide to serve the query or not. F. Interfaces An interface provides a gateway between platform and clients. It communicates with clients via rIDCP/rIDDP and with platform modules via xIDCP/xIDDP. Inside the platform, interfaces act as the data sinks only. Besides that, interfaces allow the user to transparently operate with the platform as it is a single device connected via some adapter. If the interface supports several connections, the client may want to create data flow session with one or more databases before sending any queries. This situation was illustrated in the example above. In this case, rIDCP information will be sent by the interface to the controller that is connected to the interface, while the data will be forwarded through the previously created data connections. G. Applications Applications specify the actual services the platform can provide. They collect data from different sources, process it and send to the sink that initiated the query. When query is being initiated, the application may need to initiate several queries with other data sources, some of which may also be applications and so on. As any other data source, application announces supported data types when it starts. H. Supervisor The supervisor checks system status, restarts the modules if needed and configures the platform. It can be accessed via several administrative interfaces, including SSH, TELNET (if connected via RS232) or specific protocol for remote provisioning, for instance SOAP. This module should be a subject for reservation if possible. I. Protocols As already described, the platform communicates with users via rIDCP/rIDDP and with modules via xIDCP/xIDDP. Unfortunately, protocol details are out of the scope of current paper. A simplified example of the session initialization is illustrated in fig.5. V. I MPLEMENTATION STATUS Our company R&D “Information and Networking Technologies” works on the project which aims are embedding the RFID tags into license number plates, integration of the RFIDbased identification data with the data obtained from license plates recognition services and wireless communication lines between traffic law enforcement systems establishment. On the first project stage a pilot IEEE 802.11n-based wireless network between systems placed over the road M7 “Volga” (Tatarstan, Russia) was built and now is being in operational stage. The network was developed by Tatarstan Republic Road Traffic Safety Inspection and our company. Later, in May, 2012 we performed the first tests of a traffic law violations registration platform utilizing RFID-technology.

Fig. 5. Query initialization simplified example: CTRL and DB are client devices, IFACE is an interface, CBUS is a communication xIDCP bus and APP is some application serving the query.

RFID-equipment operated in UHF band using protocol Class1 Gen2 / ISO 1800-6C standard [1]. The license plates for the tests were provided by T¨onnjes Group [6]. The trial proved the concept and allowed to register vehicles moving with speed up to 160 kmph. To this end, our goal is to find a solution for RFID readers integration with different camera-based traffic law enforcement systems already installed. We have implemented a prototype of an application platform described in this paper and perform its stress-testing and integration with several traffic law enforcement systems vendors. The aim of the platform is to integrate RFID readers with the most of existing traffic law violations registration systems and the equipment for wireless data transmission. VI. C ONCLUSION In this paper we have discussed the design concept of an advanced application platform that can integrate traditional traffic law enforcement systems with the RFID technologies and various communication interfaces. The proposed design allows rapidly develop highly customizable traffic law enforcement systems, utilizing strengths of the different identification techniques. Implementation of the proposed platform will speed up advanced traffic law enforcement systems development, increase the probability of traffic law violations registration and provide additional methods for stolen cars disclosure. R EFERENCES [1] EPC Radio-Frequency Identify Protocols. Class-1 Generation-2 UHF RFID. Protocol for Communications at 860 MHz – 960 MHz, EPCglobal Inc. Standard, Rev. 1.2.0, 2008. [2] R. N. Minnikhanov, “Speed cameras for traffic law violations registration application experience (by the example of tatarstan republic) (in russian),” GU “NC BZD”, p. 128, 2009. [3] V. M. Vishnevsky, S. L. Portnoy, and S. L. Shakhnovich, Encyclopedia of WiMAX. The way to 4G (in Russian). Moscow, Russia: Technosfera, 2010. [4] K. Finkenzeller, RFID-Handbook, 3rd ed. Willey & Sons LTD, 2010. [5] Low Level Reader Protocol (LLRP), EPCglobal Inc. Standard, Rev. 1.0.1, 2007. [6] Tonnjes group. [Online]. Available: http://www.toennjes.de/company.html