For the realization of QuTi, we opted for a layered architecture, in which we paid carefull attention to a clean separation of concerns. This allows us to easily replace the different components of each layer (e.g., the detection technique, the database) without the necessity to change other layers. Furthermore, is facilitates different client applications, which can be seamlessly built on top of our generic architecture. The QuTi architecture is shown in the figure below; an explanation of each layer follows the figure.
The bottom layer is the detection layer, which consists of the technical setup that is necessary to monitor in- and outgoing traffic for a certain area. This setup typically consists of an amount of sensors, both for in- and outgoing traffic, and a sensor server, that receives the data from the sensors and stores it in a detection system specific format (as provided by the supplier). Different detection systems can be used, and even work in parallel.
The next layer is the data abstraction layer, that stores the specific traffic data obtained from the detection layer, and stores it in a QuTi specific and supplier independent format. A relational database is used as a storage medium, with accompanying data processing component: a generic API that is used to populate the database. The extraction of the data from the detection layer, and communication of it to the data abstraction layer, depends on the particular detection technique that was used. Consequently, for each detection system a dedicated extraction component needs to be implemented. These dedicated extraction components utilize the generic data processing component to populate the QuTi database. To expose the information in the QuTi database to the upper layer, a Web Service is used, which allows an implementation-independent way of communicating traffic information of QuTi supported events.
The upper layer, the client application layer, consists of the QuTi client applications. These applications communicate with the data abstraction layer using the QuTi Web Service. In the current prototype, three client applications were developed: a Web-based and a mobile application, both supplying the user with queueing information of time-sensitive events, and a management application to create, configure, update or delete events.