Recent Changes - Search:

Our Outdoor City-based Santander Testbed


The Santander testbed is composed of around 3000 IEEE 802.15.4 devices, 200 devices (mainly mobile) with GPRS communication capabilities and 2000 joint RFID tag/QR code labels deployed both at static locations (streetlights, facades, bus stops), as well as on-board of mobile vehicles (buses, taxis). Current deployment is shown in the next figure (mainly in the centre of the city), being this map continuously updating with new/replaced devices.

Figure1: Santander deployment (constantly updated)

All the devices shown in Figure 1 have been deployed associated to determined use cases developed within the project:

  • Static environmental Monitoring. Around 2000 devices installed, at streetlights, facades, provided with two 802.15.4 radio interfaces, one reserved for experimentation and the other one for service provision. These devices offer measurements on different environmental parameters, such as temperature, CO, noise, light and car presence.
  • Outdoor parking area management. Almost 400 parking sensors (based on ferromagnetic technology), with an 802.15.4 radio module for communication, have been buried under the asphalt have at the main parking areas of the city centre, in order to detect parking sites availability in these zones.
  • Parks and gardens irrigation: Around 50 devices have been deployed in two green zones of the city, to monitor irrigation-related parameters, such as pluviometer, anemometer, moisture temperature and humidity, in order to make irrigation as efficient as possible. Nodes associated to this use case are shown in the upper-right part of Figure 1, depicting nodes installed in a park in the city of Santander. In terms of communication skills, they are provided with two radio interfaces as the ones in charge of static environmental monitoring.
  • Mobile Environmental Monitoring: In order to extend the static environmental monitoring use case, apart from measuring parameters at static points, devices located at vehicles retrieve environmental parameters, such as CO, NO2, O3, PM10, associated to determined parts of the city. In this sense, 150 devices are installed in public vehicles, including buses, taxis and police cars. In some of the buses, values retrieved from CAN-BUS will be also gathered and sent to the SmartSantander platform. All installed devices offer a GPRS interface for sending the environmental data and an 802.15.4 interface to interact with the deployed architecture for experimentation issues.
  • Traffic Intensity Monitoring: Around 60 devices located at the main entrances of the city of Santander have been deployed to measure main traffic parameters, such as traffic volumes, road occupancy, vehicle speed or queue length. These devices are provided with an 802.15.4 interface for carrying out the communications.
  • Guidance to free parking lots: Taking information retrieved by the deployed parking sensors, 10 panels implementing located at the main streets’ intersections have been installed in order to guide drivers towards the available free parking lots. All panels are provided with a GPRS interface to receive the information of free/occupied sites from SmartSantander platform, showing them accordingly.
  • Augmented Reality: Around 2000 RFID tag/QR code labels have been deployed, offering the possibility of “tagging” points of interest in the city, such as touristic point of interest, shops and public places, i.e. parks, squares, etc. In a small scale, the service provides the opportunity to distribute information in the urban environment as location based information.
  • Participatory Sensing: In this scenario users, utilize their mobile phones to send physical sensing information, e.g. GPS coordinates, compass, environmental data such as noise, temperature, etc. This information feeds the SmartSantander platform. Users can also subscribe to services such as “the pace of the city”, where they can get alerts for specific types of events currently happening in the city. Users can also themselves report the occurrence of such events, which will subsequently be propagated to other users that are subscribed to the respective type of events, etc

Figure2: Participatory Sensing (constantly updated)

In Figure 2, two maps regarding to Participatory Sensing are shown. The upper-right map shows the different events reported by the citizens, such as those related to traffic issues (traffic jams), incidences (state of street furniture). The citizens, as producers of information, generate the corresponding events, and can also behave as consumers of the generated information, subscribing to the notifications reported by other citizens. On the other hand, in the bottom-left map, they are shown the anonymous measurements retrieved by the citizens, associated to the different sensors the mobile phones are provided with, such as temperature, light, noise, accelerometer, which are sent periodically to the platform.

Apart from service offered by the aforementioned use cases, and in order to cover the twofold approach, experimentation and service provision, pursued by the project; within these use cases researchers are also provided with the possibility of experimenting with the deployed nodes. In this sense, two types of experimentation can be carried out over the facility:

  • Native experimentation: Most of the deployed IoT Nodes (those with fewer constraints in terms of battery) can be flashed, as many times as required with different experiments, through OTAP (over-the-air programming) or MOTAP (Multihop OTAP), for nodes more than one hop away from the gateway. In this sense, researchers can test their own experiments, such as routing protocols, data mining techniques or network coding schemes. This experimentation is made available by using an additional IEEE 802.15.4 transceiver, thus isolating data traffic associated to experimentation from the generated by the service provision. Figure 3 shows a screenshot about the experimentation skills offered by the platform.

Figure3: Native experimentation skills

  • Experimentation at service level: Some of the deployed nodes, due to battery constraint or memory capacity issues, are not provided with an additional 802.15.4 transceiver and cannot be flashed over the air to load different experiments. For these cases, data generated by the different services (described in next section) provided by the project, is offered to the researchers for developing new services on top of it. In this sense, development of new added value services, as well as, correlation between information retrieved by different services, could be examples of this type of experimentation.

Apart from experimentation and service provision, network management is needed in order to access deployed nodes to send/receive commands from them, update the firmware running on them, or load experiments if allowed (OTAP). All these functionalities are performed through the Testbed Runtime (TR) module, which in order to manage these new wireless devices, implements a mux/demux functionality as well as the corresponding device drivers. Furthermore, in order to fulfill experiments support, platform management and service provision in a joint way at the node level, it is needed to flash node with a default program (called golden image), at network start-up. Considering the aforementioned hardware and software architecture, Santander testbed allows the service provision and the experimentation in a simultaneous way, as well as network management, i.e. sending commands or flashing nodes.

Software Architecture

Based on the logical testbed architecture summarized above, one of the first achievements of the SmartSantander project has been to provide a careful integration of components coming from different existing projects (namely WISEBED [WISEBED], SENSEI [SENSEI] and TELCO 2.0 [TELCO]) in order to fulfil the described requirements. A graphical representation of the provided integration and the involved components for all the aforementioned use cases is shown in Figure 4.

Figure4: SmartSantander logical architecture

In Figure 4, they can be identified the main components composing the SmartSantander architecture: Portal Server, Service Provision GW (SPGW), GW for Experimentation (GW4EXP) and IoT nodes.

The Portal Server represents the access point to the SmartSantander facility for Administrators, Services and Experiment Users. It hosts an adapted version of the WISEBED Testbed Runtime components, including Sensor Network Authentication and Authorization (SNAA), Reservation System (RS) and iWSN API/WSN APP implementation. The SNAA component offers the basic functions for access control through Shibboleth-based authentication and authorization. Therefore, at this stage, no account-based access control and other accounting functions are provided. The Resource Reservation system (RS API from Testbed Runtime) is instead used for making, querying and editing reservations of IoT nodes and supports a number of solutions for the persistence of these reservations, such as in-memory persistence, Google Calendar persistence and database persistence. The iWSN API represents the back-end implementation of the set of functionalities required for interacting with the IoT nodes with commands such as reset, reprogramming, checking if a node is alive, adding/removing virtual links and many others. The iWSN API provides also the implementation of a channel for exchanging debug and control message between the Portal Server and the corresponding GW for experimentation (GW4EXP), as well as with IoT nodes. This type of gateway is only needed for use cases and IoT nodes with capacity for running native experimentation. The communication is achieved by exploiting the protocol buffer message scheme. The iWSN API counterpart on the GW4EXP is indeed extended with a new component, named WSN Device App, that allows for a [1:N] message exchanges between the IoT node directly connected to the GW (by means of a wired USB/serial connection) and purely wireless nodes, as per in the SmartSantander architecture. This new module permits to overcome the limit of the previous iWSN API implementation that assumed a 1:1 [sensor device, serial port] pairing.

Overcoming a previous limitation of the initial Testbed Runtime implementation, relying on statically maintained configuration files (to define the network topology and to correctly forward messages to and from nodes), that need to be manually updated and distributed to all nodes where the Testbed Runtime runs, the new architecture provides also features for automating this process within the Resource Manager module. In this sense, information sent from the different SPGW (Service Provision GW) through the corresponding NodeManager module is received by the EventBroker, which interacts with IoT Manager, TR Configurator and USN Configurator. IoT Manager is in charge of updating the Resource Directory (inherited from SENSEI project), chosen for storing the required configuration parameters. The TRConfigurator and USNConfigurator, have then been developed in order to automatically complete the reconfiguration process of the new resources. An adaptation of the RD has been realized in order to provide a notification mechanism to the components that subscribe it for, when a new resource is added. In this way, the TRConfigurator and the USNConfigurator can receive notifications when respectively; a new experimental or service node is added to the RD. Upon receiving a new notification and after fetching the required configuration information, the TRConfigurator and the USNConfigurator can build the needed configuration files and distribute them to the respectively controlled subsystem, namely the SmartSantander Tesbed Runtime (inherited from WISEBED project) and the USN (data platform provided by Telefonica IDAS). This distribution is achieved by means of a secure ftp connection. By means of an Admin GUI, an administrator can configure the addition of a new resource (either a new experimental or service node), before physically connecting it to the testbed and powering it up.

In order to run an experiment, by means of a Native Experiment Client, the experimenters are allowed to access to the Portal Server, using an authentication and authorization mechanism (provided by the SNAA feature), and to reserve resources (using the Reservation System) on which they can perform experiments configuring them through the iWSN API, thus accessing to the peer iWSN API module within the corresponding Experimentation GW. It must be taken into consideration that not all developed use cases allow native experimentation under their deployed nodes.

In order to allow the user to access services provided data, a Service Level Experiment Client has been developed. Through it, the user can access to the USN component providing a number of useful functions for the development of IoT applications and services ranging from sensor discovery, observation storage, publish-subscribe-notify to a trigger mechanism for the remote execution of tasks on IoT nodes and actuators. The service data generated by all use cases running under the SmartSantander facility can be then available to the USN system pushing them through an HTTP post method and then to the corresponding user.

Finally, within the SmartSantander project, applications have been also developed using information provided by deployed nodes (through the USN) and generating the corresponding service for the user.

Use Cases

In this section, the eight use cases developed within the city of Santander will be described in a detailed way, indicating how they fulfill the service-experimentation duality prosecuted by the project,at the same time as correct network management is also assured.

Environmental Monitoring, Outdoor parking area management, Parks and gardens irrigation

These three use cases share the same architecture, conceived as a 3-tiered approach and defined next:

  1. IoT node: Responsible for sensing the corresponding parameter (temperature, CO, noise, light, car presence, soil temperature, soil humidity). The majority of them are integrated in the repeaters, whilst the others stand alone communicating wirelessly with the corresponding repeaters (it is the case for the parking sensor buried under the asphalt). For these devices, due to the impossibility of powering them with electricity, they must be fed with batteries.
  2. Repeaters: These nodes are high-rise placed in street lights, semaphores, information panels, etc, in order to behave as forwarding nodes to transmit all the information associated to the different measured parameters. The communication between repeaters and IoT nodes performs through 802.15.4 protocol.
  3. Gateways: Both IoT nodes and repeaters, are configured to send all the information (through 802.15.4 protocol), experiment-driven as well as service provision and network management to the gateway. Once information is received by this node, it can either store it in a database which can be placed in a web server to be directly accessed from internet, or send it to another machine (central server), through the different interfaces provided by it (WiFi, GPRS/UMTS or ethernet).

Taking into account the twofold approach, experimentation and service provision, prosecuted by the project, it is needed to define an infrastructure that allows executing both experimentation and user-addressed services in a joint manner, thus providing flexibility for researchers to try their applications on the testbed, at the same time that a service addressed to ease and fulfill citizens’ requirements is running. To handle this execution concurrency in an efficient way, a solution based on hardware independence is posed. This solution, provided by the Spanish company Libelium, consists of nodes implementing two different physical interfaces, as shown in the Figure5

Figure5: Deployed IoT node and gateway

The node depicted in Figure 5 is composed of the following parts:

  • Main board: This board (called Waspmote) is in charge of processing and memory issues, providing a set of interfaces for attaching different types of sensors (both analogue and digital), as well as to plug several radio modules to communicate with other nodes. The Waspmote comes with with a ATmega1281 microcontroller, and several types of memory, 8KB SRAM, 4KB EEPROM, 128KB FLASH and an extra storing SD memory with 2GB capacity. On the other hand, 7 analogue and 8 digital interfaces are available for external sensor connection, as well as 1 PWM, 2UART, 1 I2C and 1 USB interfaces for attaching different communication modules. All the development tools (libraries, API’s, etc.) provided by Libelium are based on a pseudo-wiring solution which aims to promote the simplicity of the functioning of the micro-processor based on events and loops. Attached to the main board, they are placed the sensor boards with the corresponding sensing capabilities, such as temperature, luminosity, noise, parking, CO, soil temperature.
  • Two XBee-PRO radio modules: Both modules manufactured by Digi company, run over 2.4 GHz frequency. One of the modules implements 802.15.4 protocol in a native way, and the other one runs 802.15.4 protocol modified with a proprietary routing protocol called Digimesh. This is a proprietary peer-to-peer networking topology protocol for use in wireless end-point connectivity solutions, allowing addressing in a simple way.

The three components composing the infrastructure: IoT nodes, repeaters and gateways, are equipped of the aforementioned component in order to guarantee the service provision as well as the experimentation over the same node in a simultaneous and independent way. In the case of the gateway node, as it is intended to gather and facilitate all the information taken from the WSN, either to external networks (internet) or application level services, it needs to implement high memory/processor capacity and added communication skills. To fulfill all these requirements, another device (called Meshlium), also manufactured by Libelium, with higher capacity in terms of processor (500MHz) and memory (256MB RAM and up to 32GB hard disk) is utilized. Regarding to its communication skills, apart from the two Xbee radio modules for communication with the deployed nodes, also WiFI, GPRS, Bluetooth and Ethernet interfaces are provided.

Taking into account the aforementioned experiment-service duality and the two radio modules availability, the way IoT Nodes interact with the rest of the SmartSantander system is as follows:

  1. SmartSantander experimental facility needs to be managed in a wireless way which basically involves wireless transmission/reception of commands to/from all nodes and node reflashing over the air. For this purpose, the Digimesh radio module provides the routing protocol for communication between nodes and gateway. In this sense, it will be possible to manage the IoT Nodes from the gateway by sending the appropriate commands and receiving the corresponding responses as they are issued by the IoT Nodes. On the other hand, IoT Nodes will be flashed also from the gateway as many times as required, through OTAP (over-the-air programming) or MOTAP (Multihop OTAP), for nodes more than one hop away from the gateway.
  2. All the information derived from both service provider and city service use cases is retrieved by the deployed nodes to the gateway, which is the entrance towards the SmartSantander system, through WiFI, GPRS, Ethernet. In order to send all this data in a reliable and transparent way, the Digimesh-enabled network is used.
  3. Regarding to experimentation use cases, researchers will flash the nodes with the corresponding programs, through (M)OTAP using the Digimesh interface. However, once the code is loaded in the node, all the data regarding to the experiment will be transmitted and received through the 802.15.4 native module.

In this respect, it is guaranteed that both management and service traffics are transmitted in a physically independent way from the experimentation information, thus obtaining interesting results:

  • The provided service will never be interfered nor interrupted by experiments, thus avoiding the disruption of this service because of a misuse of the network by some experiment.
  • The results retrieved from the experiment might be assumed as if the testbed were only for experimentation purposes, as there is no interfering traffic within the network, but only the one associated to the corresponding experiment.
  • The management of the network is more reliable as all traffic running on the Digimesh interface is predictable (all services are installed at start-up); so no external traffic will affect the communications. In this sense, nodes will be provided with a default program (called “golden image”), which will carry out the functionality associated to the corresponding service, as well as all the management issues needed for the correct network operation. This image will be loaded in the nodes at the network start-up, and re-flashed when a node is restored to its default state.

Deployment of Environmental Monitoring and Outdoor Parking Management

Outdoor parking management and environmental monitoring use cases share the same infrastructure, where several parking sensors (IoT nodes) provided with one transceiver (running the Digimesh protocol) send their parking state (free or occupied), to the corresponding gateway through the repeaters placed at the streetlights. In addition to this, all these repeaters are equipped with temperature, CO, noise and luminosity sensors, thus sending this information to the gateway. The received information is stored and processed in the gateway, in order to be used by different applications running over it, both in a local way or accessing from Internet through the SmartSantander backbone.

Figure6: Architecture of the environmental monitoring and parking use cases

Regarding to the data associated to experimentation, as it can be observed in Figure 6, this is transmitted through the 802.15.4 native interface that works in an independent way from the Digimesh one, thus assuring no disturbance between experimentation and service provision/network management data. Santander testbed composes of several clusters, being a cluster the set of IoT nodes and repeaters that are associated to a determined gateway.

Figure7: Detail of installation of parking nodes

In Figure 7, installation of different parking sensors buried under the asphalt are shown.

Figure8: Detail of installation of repeaters

In Figure 8, they are shown several pictures of the installation of repeaters on both streetlights and facades.

Figure9: Detail of installation of meshliums and panel

Figure9 shows different meshliums installed on steetlights and facades, as well as, the panel installed on a lamppost, indicating some environmental parameters, as well as free parking lots in a determined zone of the city.

Deployment of Parks and Gardens Irrigation

In order to control and make it more efficient the irrigation in certain parks and gardens within the city of Santander, several type of sensors will be installed in order to firstly monitor and evaluate the current situation and then to act over the irrigation systems making it more efficient the use of water. For this purpose, the following types of sensors are deployed:

  • Weather station: Anemometer, pluviometer.
  • Atmospheric pressure, solar radiation, air humidity and temperature sensors.
  • Soil temperature and humidity sensors.
  • Evaluation of water consumption sensor.

Soil temperature and humidity sensors are buried in the grass, being connected to the corresponding repeaters through a wired connection.

Figure10: Architecture of the parks and gardens irrigation use case

Figure 10 shows the deployment topology of the different sensors deployed in a park/garden, thus retrieving main parameters associated to soil and air status.

Mobile Environmental Monitoring

As previously indicated, within the SmartSantander project more than 2,000 environmental monitoring sensors have been already deployed. These sensors are monitoring CO index, temperature, noise level and light intensity. Although this deployment is very representative as it is located at the Santander city centre, it is necessary to extend the Environmental Monitoring service to other areas of the city. Hence, instead of continuing with fixed deployments all over the city, the hardware to be supplied will be deployed on municipal public buses, police cars and other municipal service vehicles. This way we will be able to cover a much wider area on a much more efficient way.

The architecture deployed divides in several parts:

  1. Sensors Board: Responsible for sensing the corresponding environmental parameters (temperature, humidity, CO, PM10, O3, NO2), sending these values through a serial port to a local processing unit.
  2. CANBUS module: This module is in charge of measuring main parameters associated to the vehicle (GPS position, altitude, speed, course and odometer), sending them to the local processing unit.
  3. Waspmote board: For this use case, nodes similar to those already deployed (waspmote nodes) have been installed. For this case, waspmotes are only provided with the 802.15.4 interface for experimentation issues, as service-related information and network management data is transmitted by the local processing unit.
  4. Local processing unit (LPU): This unit, called CLV, is in charge of managing the service provision (data retrieved from sensor board and CANBUS module), experimentation (sending the log messages generated by 802.15.4 interface) and network management (OTAP procedures, transmission/reception of commands).
  5. Gateway for mobile nodes (GWM): Equipment with high capacity in terms of computational power and memory which is in charge of gathering and processing all the information sent from the LPUs, just storing the information in the SmartSantander backbone.

All the buses will be provided with a sensor board, a CANBUS module, an IoT device and an LPU, whilst in each taxi and police car only a sensor board and an LPU will be installed (no native experimentation allowed at taxis and police cars).

From the hardware point of view, in Figure 11 they are shown the LPU and the waspmote, the sensor and waspmote boards.

Figure11: Detail of LPU, sensors and waspmote boards

Hardware modules shown in Figure 11 have the following characteristics:

  • LPU (called as CLV): 32-bit RISC processor with up to 60 MIPS ARM7 at 70 MHz or higher under a Linux operating system and with a 8 MB Flash memory for user applications and 16MB of RAM. Regarding to connectivity issues, it is provided with RS232/485 and CAN interfaces for devices, 7 digital inputs, 5 digital outputs and 2 analog inputs. In terms of communication, it provides a GPRS interface.
  • Sensor board: Measures several environmental parameters, such as CO, NO2, O3, PM10, temperature and humidity, including a box adapted for air circulation, as well as a basic RISC Micro-Controller at 8MHz for simple operations. Power and data transmission/reception is carried out through an RJ45 specific connector.
  • Waspmote board: It is provided with an 802.15.4 native interface with an antenna of 5dBi, used for experimentation issues within coverage areas of the static 802.15.4 static network already deployed. On the other hand, a serial communication (through a RJ45 connection) is enabled between the waspmote board and the LPU.

Figure12: Mobile environmental monitoring scenario

As it can be derived from Figure 12, mobile nodes send the retrieved information (through GPRS interface) to the internet/intranet, and also, interact with the corresponding static nodes (through 802.15.4 interface) placed at streetlamps and facades, already deployed.

In order to perform network management, at the same time the service is running as well as an eventual experiment could be executed over the platform, the operation would be as follows:

  1. Network management: Considering that LPU is provided with a GPRS interface which offers global coverage, both commands as well as MOTAP packets will be transmitted to this interface. Once these messages have been received in the LPU, this will process and forward them to either sensor board or GWM, accordingly.
  2. Service provision: Measurements carried out by sensors board and CANBUS module (where installed), will send periodic measurements to the LPU which forwards these values to the GWM, thus providing service data to the SmartSantander backbone.
  3. Experimentation: For the flashing of the corresponding experiments, the image to be loaded is sent from the GWM to the LPU through the GPRS interface. From the LPU, the image code is transmitted to the waspmote board through the corresponding serial interface.

In this respect, it is guaranteed that both management and service traffics are transmitted in a physically independent way from the experimentation information, thus obtaining interesting results:

  • The provided service will never be interfered nor interrupted by experiments, thus avoiding the disruption of this service because of a misuse of the network by some experiment.
  • The results retrieved from the experiment might be assumed as if the testbed were only for experimentation purposes, as there is no interfering traffic within the network, but only the one associated to the corresponding experiment.
  • The management of the network is more reliable as all traffic running on the GPRS interface is predictable (all services are installed at start-up); so no external traffic will affect the communications. In this sense, nodes will be provided with a default program (called “golden image”), which will carry out the functionality associated to the corresponding service, as well as all the management issues needed for the correct network operation. This image will be loaded in the nodes at the network start-up, and re-flashed when a node is restored to its default state.

Traffic Intensity Monitoring

Nowadays, the measure and classification of vehicles in road traffic is accomplished by inductive loops placed under the pavement. These inductive loops allow monitoring vehicle passing by means of different configurations which provide us a number of data in order to control several parameters of the traffic (vehicle speed, traffic congestion, traffic accidents). However, these systems have several problems and disadvantages like their deployment, maintenance, high cost, and put into gear, among others. In this sense, within the SmartSantander project a solution based on sensors buried under the asphalt has been deployed to control traffic parameters at main entrances of the city of Santander.

From the hardware point of view, in Figure 13 they are shown the traffic sensor, the repeater and the access point.

Figure13: Detail of traffic sensor, repeater and access point

Main characteristics of deployed hardware are indicated next:

  • Traffic Sensor: It uses magneto-resistive sensors to detect the presence and movement of vehicles, working at a frequency of 2.4 GHz and a data rate of 250Kbps. Furthermore, it is provided with an IP68 ingress protection.
  • Repeater: It extends the range and coverage of an installation’s access point. Both access point and repeater antennas provide a 120°, so for increasing coverage area a repeater can be mounted on the same pole or mast as the access point, but pointed in the opposite direction. Repeaters are battery powered (battery replacement every two years), as they present a low power consumption.
  • Access Point: Intelligent device operating under the Linux operating system that maintains two-way wireless links to sensors and repeaters, as well as it uses a wired or wireless connection to relay the sensor detection to the corresponding SmartSantander remote server. For this purpose, access points are provided with an 802.15.4 interface and an Ethernet or GPRS/UMTS interface, respectively.

The architecture deployed divides in several parts:

  1. Traffic Sensor: Buried under the asphalt, they are accountable for sensing the corresponding traffic parameters (traffic volumes, road occupancy, vehicle speed, queue length), sending these values through an 802.15.4 interface to the indicated repeaters.
  2. Repeater: This module is in charge of forwarding the measurements retrieved from the traffic nodes, making it available to the corresponding access point.
  3. Access point: Both traffic sensors and repeaters, are configured to send all the information to the access point. Once information is received by this node, it can either store it in a database which can be placed in a web server to be directly accessed from internet, or send it to another machine (central server), through the different interfaces provided by it (GPRS/UMTS or ethernet).

Figure14: Intended traffic intensity monitoring scenario

In Figure 14, some traffic monitoring sensors are deployed in different road lanes, thus retrieving information on vehicle speed, flow and queue length.

Guidance to free parking lots

During the first phase deployment of the SmartSantander project, around 400 parking sensors have been installed in order to detect the occupancy degree of determined parking lots. Once the nodes are providing information on the occupancy status of the different parking places, the next step is to guide the drivers towards available free lots through the use of several panels, mainly placed at the streets’ intersections.

The architecture deployed divides in two parts:

  1. Panel: According to the information received from the Central Station, the panel will show the number of places available in a determined parking zone, displaying it in different colors depending on the occupancy degree. The panel can show other information and messages that are not necessarily related to parking (e.g. 'street closed for renovation').
  2. Central Station: It receives, from the Portal Server, all data retrieved by the sensors already deployed to detect parking lots availability, thus processing it accordingly and transmitting the suitable information to the corresponding panel. In addition to the reception of information from SmartSantander architecture, Central Station also sends incidences and other data related to the gathered information.

Figure 15 shows an overview of the guidance to parking lots scenario.

Figure15: Guidance to free parking lots scenario

As it can be derived from Figure 15, several panels are in charge of showing the number of free lots in different streets, green colour for streets with lots available, whilst red one for streets with no free parking lots.

From the hardware point of view, main characteristics of the panels are indicated next:

  • Panel: Panel is provided with a multicolor LED display (green/red/amber) and a 120 mm digit height alphanumeric, assuring a reading distance up to 50 meters. Panels must have uninterruptible power supply (220 V), although they are also equipped with a UPS (Uninterruptible Power Supply) to protect against small outages (30 minutes). Furthermore, panel is provided with an IP67 protection and a GPRS connection for transmitting/receiving information.

For this use case, native experimentation is not supported, but only experimentation at service level is provided. In this sense, deployed platform must only support service provision and network management, as indicated next:

  1. Network management: Panels can be accessed from the Central Station in order to modify several parameters, such as refresh period of available parking lots. Panels can also send incidences regarding to communication problems, operation failures. Direct communication between panels is not available.
  2. Service provision: For service provision, data retrieved from Portal Server (provided by the static parking sensors buried under the asphalt) is sent to the Central Station that will process it, transmitting to each panel the information associated to the zone covered by this panel. Apart from the traffic associated to this service, Central Station also process the information received, sending statistical information to the Portal Server.

In this sense, main service parameters can be varied in order to adapt service to the corresponding requirements.

Edit - History - Print - Recent Changes - Search
Page last modified on December 05, 2012, at 01:55 PM