## 3 Traffic-Volume-Monitoring System  
Figure 3 depicts a schematic diagram revealing the architectural layout of the traffic-volume-monitoring system. The developed system consists of four central camera units for the indirect method. It can be used for multi-entry and multi-exit parking lots. The system layout presented in Figure 3 may be divided into five cofunctional entities: an uninterruptible power management system, visual data acquisition units (cameras), local visual-data-processing nodes (on-site SoC units), a networking layer (Ethernet switch,  
Figure 3: Schematic diagram of the traffic-volume-monitoring system (NIC—Network Interface Controller; SoC—System on Chip; WAN—Wide Area Network). Figure 2: Distribution of cameras for the indirect method. broadband radio modem), and a classification mainframe unit (WUoT server). Furthermore, presented in Figure 4 is the algorithmic path developed for the purpose of the designed and deployed measurement system referred to in Figure 3.  
The dedicated algorithm (Figure 4), designed over the functional modules of the deployed measurement system, may be categorized into three sequentially connected layers. Those are a camera unit, a System-on-a-Chip node, and the main processing server (WUoT Server). As far as connectivity features are considered, the essential interconnection between the respective camera units and the SoC units was realized by means of a classical Local Area Network (i.e., ethernet interfaces) conversely to the SoC--WUoT Server path, where broadband data exchange was achieved through a Wide Area Network radio link (i.e., 4G/LTE networking stack). The essential stages of the aforementioned algorithm consisted of the following steps, divided over the three nodes:  
- IP Camera: visual data acquisition;  
- SoC unit: video stream analysis, object detection, vehicle tracking, and vehicle extraction;  
- WUoT server: vehicle classification, vehicle counting by categories, and result visualization. After visual measurement data acquisition was performed (in a looped, cyclic manner), the first stage of data processing was run on the SoC unit. It was based on an optimal data decomposition--a video stream was prepared to be processed further (an optimal data structure was prepared based on a dynamic link to a video format). Secondly, the user-selected Region of Interest (ROI) determined the scope of the visual cues to be analyzed. Incoming data processing was held over the selected window while the rest of the data was withdrawn (bandwidth effectiveness was kept). Time averages of the pixel values within that region enabled the execution of the object detection stage, where by means of luminance masking (OpenCV's featured procedure), a foreground detection was performed, and thus an object of interest could be detected. Based within Gaussian Mixture Models [28], the algorithmic path enabled feedback tuning of the blocks-of-pixels being indicated as an object; therefore, the appropriate weighing of picture elements led to the creation of  
Figure 4: The algorithm dedicated to the designed measurement system. dynamic datasets (i.e., candidates) that were further tracked as a vehicle. Each plausible contender from the list must have beforehand met the requirements in terms of shape and size (aspect ratios relevant to the field of view (FoV) of the camera were preset empirically). Afterward during the tracking procedure, over the course of consecutive images, the optimal polling for the representative of a detected vehicle was performed, and the actual image was passed further to the extraction module, where the image was prepared to be sent over to the WUoT server. A set of bounded-box images was ready to be stored locally on the SoC unit (cyclic, limited-redundancy buffer) and simultaneously transferred via a secure link to the mainframe node. Whenever consecutive, preprocessed images were uploaded to the WUoT server, each SoC unit began its workflow in a looped manner.