## 5 Use Cases
### Air Quality Monitoring  
The Air Quality Demonstrator [37; 55; 56] was deployed in the industrial zone of the city of Pisa (Italy) in agreement with the local authorities. The main goal was to collect concentration measurements on harmful gases such as Carbon Monoxide, Coal Gas, Liquefied Gas, LPG, Natural Gas, Town Gas. The sensors were installed in the area to monitor gases concentration (see Figure 27). WSN data acquisition for environmental monitoring is challenging, especially for open natural fields. These usually require high reliability and long maintenance-free operation while the nodes can be exposed to variable and extreme climatic conditions. The main network components are one server to save data and provide end user services; one gateway to collect field data; and eight sensors to measure air quality (sensor nodes, see Figure 28). The main purpose of the server is to receive, store, and provide access to field data. It bridges the low power communication segments with latency-energy trade-offs, and the fast and ubiquitous  
Figure 28: Main components of the network. Figure 27: Application scenario for the air quality monitoring demonstrator. end-user field data access. It provides interfaces for reading sensor nodes values. A central software engine controls the server operation and the access to the main database. It is written in Java and has low-level layers written in C and runs on a Linux operating system. The sensor nodes are connected to the central gateway using an XBee RF Modules interface. The main role of the gateway node is to collect, process, and forward to server the field data received from the sensor nodes. The gateway software is composed of: a first component, used to manage high level interface like the REST interface and the relative JSON messages; a controller, that contains the core functions of the gateway (collect data, manage topology, send message, manage component interaction); a second component, used to manage the sensors interactions. The gateway hardware equipment is a Panda Board Rev A2. First, the Planning Tool was used to simulate 13 deployment plans in order to optimize different aspects, especially node types and positions. In fact, using the PT RF simulation tool and its topology services (Connectivity Matrix, Topology Evaluation and Reduction) we discovered without any in-field tests that some nodes were isolated from the gateway either because they were obscured by buildings, or because they were deployed at an inadequate height or too far away from the gateway. Each deployment plan simulation, including RF simulation, connectivity matrix evaluation and topology analysis, required about 7 min (most of the time being spent for RF simulation) for this scenario with ten nodes and a linear size of about two km, by using a four core Intel(R) Xeon(R) CPU E5440 @ 2.83 GHz with 3 GB RAM. Accordingly, all this phase only required about two hours and a half, also including the time needed by the operator to provide input data and to read the simulation results. At the end of this process, we obtained two deployment plan candidates for implementation and proceeded with the use of the Development Tool for node hardware-software synthesis and network simulation. Since we were interested to use ChibiOS real-time embedded operating system for this experiment, we modeled and added to the Development Tool library a suitable set of components for this OS. Moreover, several DT library components were designed to model the sensors that we have selected for this application mainly for hardware requirements, configuration parameters and interfaces. Additionally, to support middleware-like services, we have added to DT library components with blocks that were designed to communicate with the application server and allow run-time retrieving and setting of specific values for in-field node monitoring and configuration. With these supporting elements, we used the Development Tool to explore several node variants and their network-level effects.