Pfc David Herrador Muñoz [625332]

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA UNIVERSITARIA DE
INGENIERÍA TÉCNICA DE
TELECOMUNICACIÓN

SISTEMA DE APARCAMIENTO
INTELIGENTE APLICADO A
LAS SMART CITIES

Autor
David Herrador Muñoz

Tutor
José Fernán Martínez Ortega
Dr. Ingeniero de Telecomunicación

Julio 2013

PROYECTO FIN DE CARRERA
PLAN 2000
E.U.I.T. TELECOMUNICACIÓN
RESUMEN DEL PROYECTO: TEMA:
TÍTULO:
AUTOR:
TUTOR: Vș Bș.
DEPARTAMENTO:
Miembros del Tribunal Calificador:
PRESIDENTE:
VOCAL:
VOCAL SECRETARIO:
DIRECTOR:
Fecha de lectura:
Calificación: El Secretario,
Aplicación de la Tecnología Actual en el Marco de la Smart Mobility
Sistema de Aparcamiento Inteligente Aplicado a las Smart Cities
David Herrador Muñoz
José Fernán Martínez Ortega
Julio Medina Cano
José Fernán Martínez Ortega
Vicente Hernández Díaz DIATEL
El objetivo principal de este Proyecto Final de Carrera es el de realizar una aplicación potencialmente
implantable en el marco de la Smart Mobility, tomando como punto de partida el estudio de las
aplicaciones actuales para obtener una mejora sustancial en el aspecto económico, ambiental y social.
Se centrará en aplicaciones de control del flujo del trafico rodado en ciudades, gestionando de manera
directa los aparcamientos en superficie y facilitando al usuario la decisión de ruta haciendo así más ágil y
fluido el tráfico vehicular.
Para lograr esos objetivos, se fundamentará en la utilización de la tecnología de las Redes de Sensores
Inalámbricas aportando así cierta inteligencia a objetos comunes de los viales y enmarcando , por lo tanto,
en la categoría de Internet of the Things.
El proyecto consta de la aplicación completa, por lo que finalmente se ha desarrollado una aplicación en
Visual Basic para poder tener información en tiempo real de la ocupación de plazas de aparcamiento,
otorgando al conductor el conocimiento del nivel de ocupación de cada calle para así optimizar las rutas a
seguir en búsqueda de aparcamiento.

3

<< Salga de su zona de confort. Sólo se puede crece r si usted está dispuesto a sentirse
incómodo y molesto al intentar algo nuevo>>
Brian Tracy

4
AGRADECIMIENTOS

A mis padres, Carmen y Vicente, por haberme brindad o la oportunidad de contar con una
educación adecuada tomando como base que la más imp ortante es la que no se enseña en los
libros.
A la Pandi, por no haber discutido nunca entre noso tros desde aquel “Bueno, pues habrá que ir
pasando, ¿no?” de hace más de 10 años.
A todos los que me rodean, porque todos aportan su granito de arena sea para bien o para
mal.
A ti, porque sin pedir tu ayuda ya estás ahí. Porqu e mereces especial mención en un día como
hoy. ¡Gracias por tu ayuda y apoyo Laura!
¡Gracias!

5
RESUMEN

En las últimas décadas el mundo ha sufrido un aumen to exponencial en la utilización de
soluciones tecnológicas, lo que ha desembocado en l a necesidad de medir situaciones o
estados de los distintos objetos que nos rodean.
A menudo, no es posible cablear determinados sensor es por lo que ese aumento en la
utilización de soluciones tecnológicas, se ha visto traducido en un aumento de la necesidad de
utilización de sensórica sin cables para poder hace r telemetrías correctas.
A nivel social, el aumento de la demografía mundial está estrechamente ligado al aumento de
la necesidad de servicios tecnológicos, por lo que es lógico pensar que a más habitantes, más
tecnología será consumida.
El objetivo de este Proyecto Final de Carrera está basado en la utilización de diversos nodos o
también llamados motas capaces de realizar transfer encia de datos en modo sin cables,
permitiendo así realizar una aplicación real que so lvente problemas generados por el aumento
de la densidad de población. En concreto se busca l a realización de un sistema de
aparcamiento inteligente para estacionamientos en s uperficie, ayudando por tanto a las tareas
de ordenación vehicular dentro del marco de las Sma rt cities. El sistema está basado en el
protocolo de comunicaciones 802.15.4 (ZigBee) cuyas características fundamentales radican en
el bajo consumo de energía de los componentes hardw are asociados.
En primer lugar se realizará un Estado del Arte de las Redes Inalámbricas de Sensores,
abordando tanto la arquitectura como el estándar Zi gbee y finalmente los componentes XBee
que se van a utilizar en este Proyecto. Seguidament e se realizará la algoritmia necesaria para el
buen funcionamiento del sistema inteligente de esta cionamiento y finalmente se realizará un
piloto demostrador del correcto funcionamiento de l a tecnología.

6
ABSTRACT

In the last decades the world has experienced an ex ponential increase in the use of
technological solutions, which has resulted in the need to measure situations or states of the
objects around us.
Often, wired sensors cannot be used at many situati ons, so the increase in the use of
technological solutions, has been translated into a increase of the need of using wireless
sensors to make correct telemetries.
At the social level, the increase in global demogra phics is closely linked to the increased need
for technological services, so it is logical that m ore people, more technology will be consumed.
The objective of this Final Project is based on the use of various nodes or so-called motes,
capable of performing data transfer in wireless mod e, thereby allowing performing a real
application solving problems generated by the incre ase of population densities. Specifically
looking for the realization of a smart outdoor park ing system, thus helping to vehicular
management tasks within the framework of the Smart Cities. The system is based on the
communication protocol 802.15.4 (ZigBee) whose main characteristics lie in the low energy
consumption associated to the hardware components.
First there will be a State of the Art of Wireless Sensor Networks, addressing both architecture
and finally the Zigbee standard XBee components to be used in this project. Then the
necessary algorithms will be developed for the prop er working of the intelligent parking
system and finally there will be a pilot demonstrat or validating the whole system.

7
ÍNDICE DE CONTENIDOS
Capítulo 1 Introducción y Objetivos …………… ……………………. 11
1.1 INTRODUCCIÓN A LAS SMART CITIES …………… …………………………………………… …… 12
1.2 OBJETIVOS DEL PROYECTO……………………. …………………………………………… ………… 13
1.3 ORGANIZACIÓN DE CONTENIDOS ……………….. …………………………………………… ……. 14
Capítulo 2 Estado del Arte …………………… ………………………… 16
2.1 ORIGEN DE LAS SMART CITIES ……………….. …………………………………………… ………… 17
2.2 LAS SMART CITIES COMO SISTEMA DE SISTEMAS ….. …………………………………………. 2 0
2.2.1 Smart Mobility ………………………… …………………………………………… ………………………………….. 21
2.2.2 Smart Water …………………………… …………………………………………… ………………………………….. 22
2.2.3 Smart Environment ……………………… …………………………………………… ………………………………. 23
2.2.4 Smart Government ………………………. …………………………………………… ……………………………… 25
2.2.5 Smart Grid ……………………………. …………………………………………… …………………………………….. 26
2.3 PROFUNDIZANDO EN EL CONCEPTO DE SMART MOBILITY ………………………………….. 27
2.3.1 Gestión del tráfico ……………………. …………………………………………… …………………………………. 30
2.3.2 Gestión de medios de transporte público ….. …………………………………………… …………………… 30
2.3.3 Gestión de aparcamientos ……………….. …………………………………………… …………………………… 31
2.3.4 Gestión de vehículos eléctrico ………….. …………………………………………… …………………………… 32
2.4 INTERNET OF THE THINGS …………………… …………………………………………… ………….. 32
2.5 RELACIÓN ENTRE IOT Y SMART CITIES …………. …………………………………………… ……. 35
2.5.1 Dispositivos Finales …………………… …………………………………………… …………………………………. 36
2.5.2 Puertas de Enlace ……………………… …………………………………………… ………………………………… 36
2.5.3 Estación Base …………………………. …………………………………………… …………………………………… 36
2.6 TECNOLOGÍAS HABILITADORAS ………………… …………………………………………… …….. 36
2.6.1 Sistema de Posicionamiento Global (GPS) ….. …………………………………………… …………………… 37
2.6.2 Módulos de comunicación inalámbrica Xbee …. …………………………………………… ……………….. 41
2.6.3 Protocolo de comunicaciones 802.15.4 …….. …………………………………………… ……………………. 42
2.6.4 Microsoft Visual Studio y Visual Basic .NET . …………………………………………… …………………….. 47
2.6.5 HTML …………………………………. …………………………………………… ………………………………………. 48
2.7 PROYECTOS Y APLICACIONES RELACIONADAS ……… ………………………………………….. 48
2.7.1 Sistema de Aparcamiento Robotizado ………. …………………………………………… ……………………. 49
2.7.2 Sistema de detección de plazas de aparcamient o libres …………………………………… ……………. 51
Capítulo 3 Análisis de Requisitos ………………………. ……………. 58
3.1 Descripción del problema real y su resolución . …………………………………………… ……. 59
3.1.1 Introducción ………………………….. …………………………………………… ……………………………………. 59
3.1.2 Descripción del sistema ………………… …………………………………………… ……………………………… 59
3.1.3 Actores intervinientes …………………. …………………………………………… ……………………………….. 61
3.2 Requisitos del sistema …………………… …………………………………………… ………………. 69

8
3.2.1 WaspMote ……………………………… …………………………………………… ………………………………….. 69
3.2.2 Xbee …………………………………. …………………………………………… ……………………………………….. 72
3.2.3 GPS ………………………………….. …………………………………………… ………………………………………… 73
Capítulo 4 Escenario de Validación ……………………… ………….. 75
4.1 Escenario del demostrador ………………… …………………………………………… …………… 76
4.1.1 Definición de requisitos del demostrador …. …………………………………………… ……………………. 77
4.1.2 Estudio de viabilidad (cobertura GPS, distanc ias, etc.) …………………………………. ………………… 78
4.1.3 Caracterización de zonas de aparcamientos. .. …………………………………………… …………………. 78
4.1.4 Programación de los equipos controladores de zona. ……………………………………… …………….. 79
4.1.4 Instalación de equipos. ………………… …………………………………………… ………………………………. 80
4.2 Validación ……………………………… …………………………………………… ……………………. 81
Capítulo 5 Conclusiones y Trabajos Futuros ………………. ……… 83
5.1 Conclusiones ……………………………. …………………………………………… ………………….. 84
5.2 Impacto del Proyecto …………………….. …………………………………………… ……………… 85
5.2.1 Impacto Económico ……………………… …………………………………………… ……………………………… 85
5.2.2 Impacto Ambiental ……………………… …………………………………………… ………………………………. 88
5.2.3 Impacto social ………………………… …………………………………………… …………………………………… 89
5.3 Trabajos Futuros ………………………… …………………………………………… ………………… 89
Anexos …………………………………….. ……………………………….. 91
Anexo 1: Código fuente motas …………………. …………………………………………… …………… 92
Anexo 2: Código fuente panel …………………. …………………………………………… ………….. 114
REFERENCIAS BIBLIOGRÁFICAS …………………… ………………… 124

9
ÍNDICE DE FIGURAS
FIGURA 1 – UNITED NATIONS , DEPARTMENT OF ECONOMIC AND SOCIAL AFFAIRS , POPULATION DIVISION : WORLD
URBANIZATION PROSPECTS , THE 2011 REVISION . 1960 ………………………………………. ……………………….. 18
FIGURA 2 – UNITED NATIONS , DEPARTMENT OF ECONOMIC AND SOCIAL AFFAIRS , POPULATION DIVISION : WORLD
URBANIZATION PROSPECTS , THE 2011 REVISION . 2011 ………………………………………. ……………………….. 18
FIGURA 3 – DESCRIPCIÓN GRÁFICA DEL RESULTADO DEL AUMENTO DE LA POBLACIÓN EN LAS GRANDES CIUDADES . ……….. 19
FIGURA 4 – SUB -SISTEMAS PRINCIPALES DE UNA SMART CITY ………………………………………….. ………………………. 20
FIGURA 5 – EDIFICIO CERO EMISIONES ACCIONA ……………………………………. ………………………………………… 24
FIGURA 6 – IMAGEN MODELO DEL DNI ELECTRÓNICO ESPAÑOL . …………………………………………. …………………….. 26
FIGURA 7 – MUESTRA DEL TRÁFICO EN MADRID A FECHA 23 DE ENERO DE 2013 (8.30 H) ………………………………….. 29
FIGURA 8 – EJEMPLO DE TRIANGULACIÓN CON 3 SATÉLITES ………………………………………….. …………………………. 38
FIGURA 9 – ÓRBITAS NAVSTAR ……………………………………. …………………………………………… ……………….. 39
FIGURA 10 – ESTACIONES DEL SEGMENTO DE CONTROL GPS ……………………………………….. …………………………. 39
FIGURA 11 – ESQUEMA DE GENERACIÓN DE ONDAS GPS ……………………………………….. ……………………………… 41
FIGURA 12 – MÓDULOS XBEE Y XBEE PRO DE DIGI INTERNATIONAL ………………………………………….. ………………. 42
FIGURA 13 – TOPOLOGÍAS DE RED DEL ESTÁNDAR IEEE 802.15.4 …………………………………… ……………………….. 44
FIGURA 14 – CAPAS DE IEEE 802.15.4 …………………………………… …………………………………………… ………… 45
FIGURA 15 – INTERIOR DE APARCAMIENTO ROBOTIZADO ………………………………………….. ……………………………. 50
FIGURA 16 – DISTRIBUCIÓN INTERIOR DEL APARCAMIENTO ROBOTIZADO ………………………………………….. …………. 51
FIGURA 17 – ESQUEMA RESUMEN PARK HELP OFFSTREET ………………………………………….. …………………………… 53
FIGURA 18 – SENSOR DE OCUPACIÓN DE PLAZA DE APARCAMIENTO PARK HELP ONSTREET ………………………………….. 55
FIGURA 19 – ESQUEMA RESUMEN PARK HELP OFFSTREET ………………………………………….. …………………………… 55
FIGURA 20 – SENSOR INDUCTIVO DE LIBELIUM ………………………………………….. ……………………………………….. 56
FIGURA 21 – MOTA DE SMART PARKING INSTALADA ………………………………………….. ………………………………… 56
FIGURA 22 – ESQUEMA DE CONEXIONES SMART PARKING ………………………………………….. ………………………….. 57
FIGURA 23 – DIAGRAMA EXPLICATIVO DEL ENTORNO DEL DEMOSTRADOR ………………………………………….. ………… 60
FIGURA 24 – ESQUEMA HARDWARE DEL SISTEMA DE MONITORIZACIÓN DE AP ARCAMIENTOS ……………………………….. 61
FIGURA 25 – PANEL INFORMATIVO DE LA APLICACIÓN ………………………………………….. ………………………………. 68
FIGURA 26 – PLACA WASPMOTE DE LI BELIUM ………………………………………….. ……………………………………….. 69
FIGURA 27 – ESQUEMA HW DE LA PLACA ………………………………………….. …………………………………………… .. 70
FIGURA 28 – VISTA SUPERIOR DE WASPMOTE ………………………………………….. ……………………………………….. 71
FIGURA 29 – VISTA INFERIOR WASPMOTE ………………………………………….. …………………………………………… . 71
FIGURA 30 – MÓDULO DE COMUNICACIONES XB EE ………………………………………….. …………………………………. 72
FIGURA 31 – ESPECTRO DE FRECUENCIAS XB EE ………………………………………….. ………………………………………. 72
FIGURA 32 – DISTRIBUCIÓN DE CANALES POR FRECUENCIAS ………………………………………….. ………………………… 73
FIGURA 33 – MÓDULO GPS ……………………………………….. …………………………………………… …………………. 74
FIGURA 34 – VISTA GOOGLE MAPS DEL ENTORNO DEL DEMOSTRADOR ………………………………………….. ……………. 76
FIGURA 35- VISTA DEL DEMOSTRADOR . IZDA : OESTE -ESTE . DCHA : NORTE -SUR ………………………………………….. … 77
FIGURA 36 – CARACTERIZACIÓN DE LAS COORDENADAS DE CADA ZONA DE A PARCAMIENTO . ………………………………… 79
FIGURA 37 – DETALLE DE INSTALACIÓN DE LA MOTA ROUTER DE LA ZONA 1 …………………………………………. ……….. 80
FIGURA 38 – DISTRIBUCIÓN DE MOTAS EN EL ESCENARIO DEMOSTRADOR ………………………………………….. …………. 80
FIGURA 39 – COMPARACIÓN DE COSTES ENTRE MODELO ACTUAL Y PROPUEST O ………………………………………….. ….. 87
FIGURA 40 – ILUSTRACIÓN DE LA PRUEBA REALIZADA EN 2003 POR EL RACC ………………………………………. ……….. 88

10
ÍNDICE DE TABLAS
TABLA 1- DISTRIBUCIÓN DE PLAZAS DE APARCAMIENTO POR CALLE ………………………………………….. ……………….. 77
TABLA 2 – COTAS MÁXIMAS Y MÍNIMAS DE LATITUD Y LONGITUD POR ZO NA DE APARCAMIENTO …………………………… 79

Capítulo 1
Introducción y Objetivos

Capítulo 1: Introducción y Objetivos
12
1.1 INTRODUCCIÓN A LAS SMART CITIES

Existe una definición de lo que es una Smart City q ue está aceptada por prácticamente la
totalidad de las entidades que participan en los di ferentes proyectos que versan sobre la
temática. Es la siguiente:
“Se considera una Smart City, a aquella ciudad que usa las tecnologías de la información y las
comunicaciones para hacer que tanto su infraestruct ura crítica, como sus componentes y
servicios públicos ofrecidos sean más interactivos, eficientes y los ciudadanos puedan ser más
conscientes de ellos. Es una ciudad comprometida c on su entorno, tanto desde el punto de
vista medioambiental como en lo relativo a los elem entos culturales e históricos.”
Sin embargo, a día de hoy no existe una definición oficial para describir qué es una Smart City.
Smart City es mucho más que una simple definición; es un concepto, una vía de desarrollo y
una forma de enfocar el crecimiento controlado y so stenible de las grandes urbes. Existen
numerosos puntos de vista para definir qué es una S mart City:
Desde el punto de vista del ciudadano, lo correcto es decir que una Smart City es aquella
ciudad que le hace la vida más fácil y cómoda sin a penas darse cuenta. Todo está encaminado
a optimizar el tiempo de las personas, evitando pér didas del mismo en tareas cotidianas de
escaso valor añadido.
Por otro lado y desde el punto de vista industrial, una Smart City es aquella en la cual se han
minimizado los gastos de energía, las emisiones de elementos contaminantes y optimizado las
vías de distribución de mercancías para tenerlas co ntroladas en todo momento desde su
origen hasta su destino.
Existe el, quizás, punto de vista más importante. E ste es el tecnológico.
Consiste en el uso de la tecnología en todos sus ni veles para alcanzar nuevos productos
innovadores que faciliten la forma de hacer que cua lquier servicio o aplicación relativa a la
ciudad, esté interconectada con un mundo global.
En este sentido, el término Smart City afecta a tod os y cada uno de los servicios presentes en
cualquier ciudad. Se trata de interconectar cada el emento para poder controlar su información
y utilizarla convenientemente para alcanzar los obj etivos descritos anteriormente. Se crea así
una “ciudad virtual” capaz de gestionar todos los r ecursos acorde con la necesidad de uso de
los mismos.

Capítulo 1: Introducción y Objetivos
13
Es aquí donde entra en juego el término Internet of Things (IoT), traducido al castellano:
Internet de las Cosas. Más adelante se profundizará sobre este término y se ahondará en sus
características.
Hemos alcanzado un conocimiento claro de lo que es una Smart City y el porqué de su
creación. Lo que a simple vista parece algo tan sim ple como interconectar dispositivos para
dinamizar el flujo de información, se torna en algo mucho más complejo una vez que se
estudia un poco más a fondo. Viendo los retos que s e plantean ante la superpoblación en
determinados núcleos urbanos, es razonable pensar q ue no se puede abordar el concepto de
Smart City como un “todo”, sino que debe dividirse en sistemas más pequeños y enfocados a
satisfacer una serie de necesidades concretas.
Estas necesidades concretas son muy variadas y aunq ue están relacionadas entre sí, hay que
establecer una serie de diferenciaciones para no de jar nada al azar. Es donde cobra sentido el
término “sistema de sistemas” que se explicará a co ntinuación.
1.2 OBJETIVOS DEL PROYECTO

Según se ha explicado en el epígrafe anterior, una Smart City consiste aquella ciudad que
fundamenta el uso de la tecnología en todos sus niv eles para alcanzar nuevos productos
innovadores que faciliten la forma de hacer que cua lquier servicio o aplicación relativa a la
ciudad, esté interconectada con un mundo global.
Sumado esto al aumento incesante de la población mu ndial a todos los niveles, se hace
necesaria la creación de aplicaciones que faciliten la vida a los habitantes, dotando a las
ciudades de soluciones tecnológicas para gestionar sus servicios y recursos.
En este marco, se persigue como objetivo principal de este Proyecto Final de Carrera la
creación de una aplicación tecnológica capaz de ord enar automáticamente el flujo de
vehículos en búsqueda activa de aparcamiento. Es la tente el problema que crea el exceso de
vehículos circulando por las ciudades, por lo que s e debe evitar a toda costa la existencia de
vehículos que no lleven una acción determinada ni e specífica.
Paralelamente se buscan los siguientes objetivos:
• Eliminación de la barrera que suponen los costes de implantación de sistemas
similares en la actualidad.

Capítulo 1: Introducción y Objetivos
14
• Eliminación de la sensórica instalada a pie de call e, evitando así posibles actos que la
deteriore.
• Reducción del impacto ambiental contaminante que su pone al planeta los millones de
kilómetros que recorren a diario multitud de vehícu los en búsqueda de plaza de
aparcamiento libre.
Para alcanzar estos objetivos se desarrollará un al goritmo de control de ocupación de zonas
geográficas, determinando así la disponibilidad o n o de ciertas plazas de aparcamiento. Este
algoritmo tomará los datos del hardware necesario a decuando las distintas señales de control
que sean necesarias.
1.3 ORGANIZACIÓN DE CONTENIDOS

Capítulo 1: En este capítulo se realiza una pequeña descripción de lo que es y lo que significa
una Smart City. A continuación se analizan los obje tivos que se persiguen con la realización de
este Proyecto Final de Carrera.
Capítulo 2: Este capítulo es en el que se aborda la realizació n del Estado del Arte tanto de las
Smart Cities como de las Redes Inalámbricas de Sens ores. Se describe en él la proliferación de
las grandes ciudades a través de la historia y las razones por las cuales estas ciudades
necesitan de los servicios tecnológicos para gestio nar sus recursos. En la parte del Estado del
Arte referente a las Redes de Sensores Inalámbricas se presenta la arquitectura y los actores
que las conforman. Así mismo se estudia los compone ntes asociados a las motas tales como
sistemas de alimentación externa, transceptores, se nsores, etc.
Capítulo 3: Se aborda la descripción del sistema propuesto par a alcanzar los objetivos
marcados en el capítulo 1. Se hace una descripción de los actores intervinientes en el
desarrollo tecnológico y las funcionalidades de cad a uno de ellos. Se describe toda la
arquitectura del sistema
Capítulo 4: En este capítulo se desarrolla la validación del Pr oyecto, describiendo los pasos que
se han seguido para poder realizar el piloto demost rador a modo de justificación de Proyecto.
Se ha realizado una estimación del impacto que tend ría este desarrollo tecnológico si se
implantase en las ciudades, arrojando unos datos mu y positivos a la vez que sorprendentes.
Capítulo 5: Este capítulo se centra en las conclusiones de este Proyecto Fin de Carrera,
detallando las bondades del mismo y no olvidando lo s problemas que han surgido con sus
posibles correcciones. Finaliza con una serie de pr oposiciones de trabajos futuros que están

Capítulo 1: Introducción y Objetivos
15
muy relacionados con la temática y ayudarían a apor tar fuerza a esta tecnología para ser
implantada realmente.

16

Capítulo 2
Estado del Arte

Capítulo 2: Estado del Arte
17
2.1 ORIGEN DE LAS SMART CITIES

La revolución industrial comenzó en el siglo XVIII en Gran Bretaña y poco a poco se fue
extendiendo al resto de Europa. Este fenómeno se ca racterizó por el aumento de la industria y
la sustitución de la mano de obra humana por tareas realizadas por máquinas. Por este hecho,
surgieron grandes transformaciones a nivel sociológ ico, cultural y tecnológico entre otros.
Las mejoras de las redes de transporte, situaciones geográficas estratégicas o el aumento de la
calidad de los servicios, fueron algunas de las raz ones para que diversas factorías se fueran
instalando en zonas muy acotadas y poco dispersas d el terreno.
La mayor consecuencia social y visible aún en nuest ros días es el denominado éxodo rural,
término referido a la población emigrante de las zo nas rurales que con el paso del tiempo se
asentaron en poblaciones crecientes urbanas.
Existe un estudio de la Organización de las Nacione s Unidas (ONU [1] ) denominado World
Urbanization Prospects [2] que se publica cada dos años. En él, se contabiliza n las últimas
estimaciones de la población tanto urbana como rura l. Además se realizan interpretaciones de
los datos obtenidos, dando como resultado una serie de gráficas, tablas y registros que sirven
para predecir el comportamiento social en el futuro .
De la publicación del año 2011 se pueden obtener lo s datos del último siglo. La ONU explica en
su documento que la población urbana mundial crecer á un 75% en las próximas cuatro
décadas. Según el documento, en 2050 se alcanzarán cifras de 6.300 millones de personas
residentes en núcleos urbanos, debidos en gran medi da al aumento significativo de las grandes
urbes situadas en los continentes asiático y africa no.
Los mayores crecimientos se registrarán en La India , con 497 millones de personas; China, con
341 millones e Indonesia, con 92 millones. Estados Unidos tendrá 103 millones de personas
viviendo en zonas urbanas.
De los siguientes gráficos se desprende la informac ión del aumento de la población residente
en municipios urbanos. La Figura 1 describe la situación en el año 1950, mientras la Figura 2
describe la situación actual. Es altamente palpable cómo la población en municipios urbanos
ha crecido desproporcionadamente debido a las causa s anteriormente expuestas.

Capítulo 2: Estado del Arte
18

Figura 1 – United Nations, Department of Economic and Social Affa irs, Population Division: World Urbanization Prospects, the
2011 Revision. 1960

Figura 2 – United Nations, Department of Economic and S ocial Affairs, Population Division: World Urbanization
Prospects, the 2011 Revision. 2011
Este hecho de “superpoblación urbana” tiene asociad o una serie de consecuencias y es que
hoy en día las grandes ciudades se han convertido e n un “todo” en lo relacionado al desarrollo
del país del cual forman parte. En las grandes ciud ades es donde se desarrollan los grandes
núcleos industriales y las sedes de grandes empresa s. Por consiguiente es donde se ofertan
mayor número de empleos, conllevando que se asiente n el grueso del número de habitantes
de cada comarca. Esto hace que sea necesaria la cre ación de una serie de servicios para el día a
día de estas personas, ya sean servicios sanitarios , de alimentación, de ocio…

Capítulo 2: Estado del Arte
19

Figura 3 – Descripción gráfica del resultado del aumento de la población en las grandes ciudades.
Con el análisis de estos datos, puede llegarse a la conclusión clara de que es necesario regular
varios factores en las grandes ciudades para hacer que sean sostenibles, ya que de lo
contrario, existirá un consumo de energía despropor cionado, no existirá orden en la
construcción de nuevas infraestructuras y se llegar á al punto en que estas grandes ciudades no
sean ni económica ni socialmente rentables.
Es justo en este momento cuando nace la necesidad d e que se produzca un cambio en el
modelo de gestión de estas ciudades, generando nuev os sistema de comunicaciones, de
transportes, de distribución, etc.
En este cambio del modelo de gestión es en lo que s e fundamenta el concepto de Smart City.
El concepto se centra en el uso de la tecnología, y a sea de nueva creación o existente, para
realizar una innovación y llevar a cabo los cambios necesarios en las grandes ciudades,
haciendo así que estas se desarrollen de forma sost enible con el mínimo esfuerzo posible.
El concepto de Smart City está muy presente en la p oblación a todos los niveles. Es en estos
últimos años cuando más fuerza ha tomado, debido a la concienciación que desde los
gobiernos se trata de realizar. Las empresas trabaj an para ofrecer unos servicios integrables
dentro de las Smart Cities, haciendo así participes a los ciudadanos de a pie de lo necesario de
este nuevo modelo de ciudad.
Es por todo lo anterior, que estamos encaminados af ortunada e irremediablemente hacia un
cambio en la forma de ver las ciudades actuales, cr eando espacios, procesos, transportes o

Capítulo 2: Estado del Arte
20
sistemas inteligentes capaces de facilitar las tare as cotidianas, reduciendo los consumos
energéticos, agilizando al máximo las comunicacione s y optimizando el tiempo de las personas
que componen dichas ciudades.
2.2 LAS SMART CITIES COMO SISTEMA DE SISTEMAS

No cabe duda que una Smart City [3] es un gran sistema que engloba multitud de sub-sis temas
para hacer frente a todos los retos que se le plant ean en un entorno tan hostil como puede ser
una gran ciudad. Plantear las Smart Cities como un sistema de sistemas, hace que todo se
encamine hacia la mejora de los servicios y comunic aciones. Esta red de sub-sistemas hace
posible que todo “funcione” cada día proveyendo a l as ciudades de sus servicios, suministros y
necesidades.
Al igual que su concepto, no está definido oficialm ente de qué sub-sistemas se compone el
gran sistema denominado Smart City. Cada empresa u organismo define los sub-sistemas que
mejor le ayudan a alcanzar los objetivos de gestion ar sosteniblemente su entorno.
Cuando se dice que una Smart City se compone de div ersos sistemas, se habla de tal cantidad
de sistemas que sería imposible enumerarlos todos y cada uno de ellos. Es por eso que
sistemas similares se engloban en términos más gené ricos.
Así pues, se podría decir que una Smart City se com pone de los sub-sistemas que se muestran
en la Figura 4 :

Figura 4 – Sub-sistemas principales de una Smart City

Capítulo 2: Estado del Arte
21
2.2.1 Smart Mobility
Las grandes ciudades modernas siguen, casi todas, u n mismo patrón de construcción. Y es que
todas comenzaron siendo pequeñas poblaciones, por l o que los múltiples ensanches y
ampliaciones tienen distinta arquitectura que las z onas interiores o centrales.
Esta diferencia de construcción está basada en que es interesante crear grandes “ciudades
dormitorio” capaces de albergar una multitud de per sonas que se desplazarán a través del
interior de las grandes ciudades hacia sus puestos de trabajo u obligaciones diarias. Con el
paso del tiempo, los núcleos urbanos han ido ganand o terreno a los nuevos ensanches,
haciendo aparecer grandes ciudades que carecen de o rden
Debido a este fenómeno, es altamente palpable el ef ecto de millones de desplazamientos que
se realizan diariamente a lo largo de todo el mundo . Por poner un ejemplo, Madrid soporta
una media de 100 kilómetros de atascos a diario, lo que desemboca en una cantidad inmensa
de dinero desperdiciado en combustible sumado a la pérdida de tiempo de los ciudadanos.
Actualmente existe una red de transportes públicos inimaginable hace unas décadas. Por
seguir con el ejemplo de Madrid, existe una red de metro con 293 kilómetros de longitud y 300
estaciones, una red de RENFE con 725 kilómetros y 1 95 estaciones, una red de autobuses
urbanos que prestan servicio a un total de 425 mill ones de viajeros anualmente y
aproximadamente 15500 licencias de auto taxi. Hay q ue sumar a todo lo anterior, los datos
que proporciona la Dirección General de Tráfico [4] de que el 60% de los desplazamientos
diarios de los madrileños se realiza en vehículos p rivados. Analizando estas cifras, se llega a la
conclusión de que la movilidad y el transporte son algo vital en el desarrollo socio-económico
de una gran ciudad. No se pueden reducir el número de desplazamientos de las personas, por
lo que habrá que optimizar las distancias, las inte rconexiones y el tiempo invertido en ellos.
Es aquí donde juega un papel importante el concepto de Smart Mobility, cuyas apuestas son el
mejorar las condiciones del transporte, mejorar la movilidad de las personas, lograr un ahorro
del gasto energético asociado a la movilidad, supri mir los tiempos muertos que las personas
realizan en los atascos y brindar información en ti empo real del estado del tráfico.
Para lograr estos retos, es decisiva la introducció n del mundo de las TIC en todo este nuevo
desarrollo. Según datos de 2011 en el mobile world congress [5] , un 45% de los usuarios de
terminales móviles en España dispone de un Smart Ph one, lo que les permite estar conectados
a la red de forma permanente y que interactúen con el flujo de datos constante teniendo así
información actualizada y muy útil para sus desplaz amientos.

Capítulo 2: Estado del Arte
22
El grueso de este Proyecto Final de Carrera se cent rará en el concepto de Smart Mobility, por
lo que más adelante lo estudiaremos en más profundi dad.
2.2.2 Smart Water
Con el incremento de población se produce el consig uiente aumento en las necesidades
básicas de las personas, como el agua, la energía, etc. Las infraestructuras de
aprovisionamiento que se realizaron años atrás, no podrán abastecer al nuevo número de
residentes en las ciudades, debido a que la demanda se multiplica mientras dichas
infraestructuras siguen siendo las mismas.
Este aumento de necesidades de la población, va cre ciendo según su nivel de vida aumenta,
pongamos un ejemplo:
Hace años, la ropa se lavaba a mano, con un jabón m uchas veces fabricado en casa y con el
único inconveniente del tiempo invertido para la ta rea. A día de hoy, existen máquinas
lavadoras que no faltan casi en ningún hogar, cuyo gasto en energía eléctrica es significativo
unido al mismo gasto en agua comparado con el métod o tradicional. Ahorran un tiempo muy
valioso a las personas encargadas de las tareas de lavado, a costa de un mayor gasto
energético.
Debe referenciarse que el aumento de las necesidade s de agua no es sólo debido al aumento
de la población de las ciudades. De hecho, el mayor consumo de agua potable dentro de una
ciudad desarrollada es realizado por la industria a ledaña. La industria del metal consume
grandes cantidades de agua para el calentamiento de sus hornos y el posterior enfriamiento de
los materiales resultantes. Por su parte la industr ial textil disuelve en grandes tanques de agua
los colorantes que más tarde teñirán las prendas. O tro claro ejemplo es el de la industria
papelera, que sumerge en agua la materia prima nece saria tanto para fabricar el papel como
para blanquearlo.
Por tanto, queda palpable la necesidad de control d e la acumulación y suministro del agua y es
justo el momento en el que recobra sentido el conce pto de Smart Water.
Smart Water centra su actividad sobre la red de cap tación y suministro de agua para grandes
ciudades. Esta red incorporará sistemas de control y gestión inteligentes que serán decisivos
para el buen tratamiento y distribución de las agua s. Centrarán su trabajo en el control de las
pérdidas de agua, problema muy acusado en todas las redes de distribución. Con una
actuación rápida sobre dichas redes, se logrará evi tar la pérdida de numerosos metros cúbicos

Capítulo 2: Estado del Arte
23
de agua, evitando también cortes de suministros y a islamiento de determinadas zonas
geográficas.
2.2.3 Smart Environment
No hay que echar más que un vistazo al mundo que no s rodea para darse cuenta de que un
edificio para un determinado fin, tiene dimensiones mucho más grandes en las grandes urbes
que en municipios pequeños.
Se pasa de un pequeño consultorio médico con unos p ocos despachos, a grandes hospitales
con zonas bien diferenciadas de atención en distint os grados. Un colegio en una zona rural
dispone de un reducido número de aulas en contrapos ición de grandes centros de enseñanza o
universidades en las grandes ciudades.
Los edificios que en su tiempo eran adecuados para las necesidades existentes, se han
quedado obsoletos en según qué condiciones. Un ejem plo es la funcionalidad de algunos
edificios, que se ha visto mermada por la acumulaci ón de tareas a desarrollar en su interior.
Otro inconveniente de los edificios heredados del p asado es su nula automatización, que evita
que se puedan alcanzar niveles saludables de temper atura, luminosidad, humedad…
Todo lo anterior acarrea una serie de consecuencias que desembocan en un descontrol del
consumo de energía real que se produce en el edific io, produciendo derroches en muchos de
los casos. También se crean situaciones en las cual es no existe el confort necesario para
desempeñar tareas adecuadamente, haciendo que el re ndimiento y productividad de las
personas disminuya considerablemente.
Precisamente la rama de las Smart Cities dedicada a realizar que estos aprovechamientos se
lleven a cabo, es la denominada Smart Environment.
Trata de optimizar la gestión que se realiza de los edificios, minimizando los gastos de energía
para hacer cómodas las distintas estancias. También se trabaja en el estudio de nuevos
materiales y técnicas para realizar fachadas inteli gentes que sean adaptables al entorno. Se
pretende alcanzar paralelamente un diseño de los nu evos edificios en los cuales tenga cabida
la modularidad de sus estancias, adecuándolas en po co tiempo a las necesidades reales.
Por último se pretende dotar de sistemas de segurid ad capaces de evitar una tragedia, o en
caso de que se produzca, minimizar las consecuencia s para los residentes.
Para realizar las adecuaciones tecnológicas, los di señadores de estos edificios inteligentes se
basan en la domótica. Con la ayuda de sensores dist ribuidos por todos los espacios del edificio

Capítulo 2: Estado del Arte
24
y junto con el control activo que se brinda sobre t odos los actuadores, se pueden controlar
tantas variables como se deseen desde el mismo edif icio o desde un lugar remoto.
Con la inclusión de este tipo de tecnología se alca nza un equilibrio entre eficiencia energética,
confort y limitación de emisiones. Pero no debemos olvidar que un edificio inteligente debe
alcanzar un compromiso entre la incorporación de te cnología, los recursos económicos que
sean necesarios para llevarse a cabo y el logro de una alta capacidad operativa.
Un claro ejemplo de la aplicación del concepto de S mart Environment a un edificio real, es el
construido por ACCIONA para su filial de Energía en Pamplona [6] :

Figura 5 – Edificio Cero Emisiones ACCIONA
• Situación: Ciudad de la Innovación, Sarriguren (N avarra)
• Superficie total construida: 2.591 m2
• Capacidad: 100 personas
• Usos: oficinas, almacén y aparcamiento cubierto
• Inversión: 4 millones de euros

Las principales funcionalidades son:
• Cero emisiones: El edificio es capaz de cubrir toda s sus necesidades energéticas sin
emitir gases de efecto invernadero, manteniendo el máximo confort y funcionalidad.
• Arquitectura bioclimática: Diseñada para maximizar la captación de energía y
minimizar las pérdidas. A ello responde su forma co mpacta, el muro cortina sur con
invernadero automatizado, las fachadas diseñadas en función del nivel de insolación y
las claraboyas o el jardín interior que favorecen l a entrada de luz natural. Un sistema
geotérmico de tubos soterrados contribuye a reforza r la climatización de forma
natural, con aire frío en verano y cálido en invier no.

Capítulo 2: Estado del Arte
25
• Instalaciones eficientes: Iluminación artificial y climatización dimensionadas a las
necesidades reales previamente simuladas y con solu ciones tales como reguladores de
intensidad lumínica, detectores de presencia y clim atización inteligente distribuida por
suelos y techos radiantes.
• Bajo consumo energético: Las soluciones y sistemas descritos hacen que el Cero
Emisiones consuma un 52% menos energía que un edifi cio convencional equivalente.
• Uso de energías renovables: Cubre toda su demanda e nergética con renovables. El
89% de esa energía la produce el propio edificio co n sistemas solares y el 11% con el
biodiésel de refuerzo que ACCIONA produce en una pl anta a 60 kms.
2.2.4 Smart Government
La razón de que haya una rama de las Smart Cities d enominada Smart Government radica en
que a mayor densidad de población en una ciudad, ma yor es la cantidad de servicios públicos
requeridos por dicha población. Se trata de alcanza r una mayor calidad de vida para esos
ciudadanos haciendo que su día a día sea lo más fác il posible, evitando siempre un gasto
directo o indirecto superior a los servicios tradic ionales.
Con este sub-sistema de las Smart Cities, se preten de centralizar la gestión que se realiza de
cada uno de los servicios públicos, pudiendo inclus o en algunos de ellos, interactuar
remotamente para optimizar los procesos evitando as í demoras en el tiempo de actuación.
Para un ciudadano de a pie, realizar una gestión of icial consiste en tener que elegir un día
laborable para ir a la institución pertinente, espe rar un tiempo de atención que suele ser
bastante amplio y realizar la gestión. A veces esa gestión se compone de varias acciones, por lo
que el tiempo invertido en ella, se dilata innecesa riamente. Con este modelo, se pierde
productividad del ciudadano, pues en condiciones no rmales tiene que escoger un día de sus
vacaciones o bien faltar unas horas a su trabajo pa ra realizar esa gestión. Este modelo
instaurado también incluye un gasto de energía y un a complicación en el estado del tráfico
innecesaria. A menudo ocurre que con las prisas, el ciudadano no sabe si realmente ha
realizado correctamente todo el proceso o se ha que dado algo sin hacer. ¿Por qué soportar
este modelo? ¿Por qué no cambiarlo y hacerlo más se ncillo?
El concepto de Smart Government hará que este ejemp lo expuesto anteriormente pase a ser
mucho más sencillo para el ciudadano, tenga un gast o energético menor y evite pérdidas de
productividad añadidas. Un ejemplo de ello es la in stauración del DNI electrónico ( Figura 6 ).

Capítulo 2: Estado del Arte
26

Figura 6 – Imagen modelo del DNI electrónico español.
Con este nuevo sistema de identificación se logrará una mayor conciliación de la vida personal
y la laboral, evitando desplazamientos innecesarios de las personas que quieran realizar
gestiones oficiales. Cada ciudadano podrá realizar desde el sitio que lo desee las gestiones
oportunas, agilizando los trámites y reduciendo los tiempos de espera, ya que con este
documento de identidad, se consigue la identificaci ón certera de la persona, permitiéndole
firmar electrónicamente documentos y otorgándole va lidez jurídica similar a la conseguida con
la firma manuscrita de documentos.
2.2.5 Smart Grid
Los ritmos actuales de crecimiento y la dependencia de la electricidad de la sociedad digital
nos obligan indudablemente a replantear el modelo c lásico de la cadena de valor de la
electricidad (Generación-Transmisión-Distribución-C omercialización-Consumo)
Efectivamente no puede pensarse en una Smart City s in pensar en la comunión de una red de
distribución independiente y del concepto de Eficie ncia energética. Sin embargo desde una
perspectiva conceptual también es el cliente o quie n se sitúa en el primer plano de la escena
ya que en la Smart City que se propone serán los cl ientes o usuarios finales quienes se
beneficiarán en primer lugar de los servicios desar rollados.
Está demostrado que existe una relación directa ent re el consumo de electricidad de un país y
su PIB. No puede dudarse por ello que electricidad es equivalente a bienestar y prosperidad.
Como conclusión lógica y natural, esta ecuación nos induce a la necesidad de aumentar la
relación calidad/precio de la electricidad. Esto es , proporcionar electricidad a la mayor calidad
posible y al mínimo precio. Conseguir esto pasa por invertir el modelo actual de la generación
y consumo de la electricidad. En efecto, el modelo actual está basado en:

Capítulo 2: Estado del Arte
27
• Unas pocas grandes centrales generadoras muy crít icas y ubicadas en los lugares de
generación (habitualmente lejos de los lugares de c onsumo). La característica crítica de estas
centrales hace que sean instalaciones muy caras de mantener.
• Una infraestructura de líneas de transporte de mu y alta tensión para llevar la generación al
consumo. Este transporte provoca unas pérdidas de e nergía por efecto Joule de
aproximadamente el 5 % del total de la energía tran sportada.
• Un conjunto de millones de consumidores a los que debe llegar la energía en baja tensión. El
proceso de pasar de muy alta tensión a baja tensión también provoca unas pérdidas de
alrededor de otro 5 % del total.
Para conseguir el objetivo que nos proponemos, mejo rar la relación calidad/precio de la
electricidad, es necesario invertir el modelo eléct rico y de esta forma optimizar las
infraestructuras necesarias para dar servicio. Si e n lugar de unos pocos grandes generadores
tenemos muchos y pequeños, la red es mucho más segu ra pues el efecto de un fallo en alguno
de los generadores repercute en menor medida en el sistema global. Al mismo tiempo, si
disponemos estos generadores lo más cerca posible d e los puntos de consumo, es posible
evitar las pérdidas de energía debidas al transport e y la distribución antes mencionadas.
La clave fundamental del concepto Smart City puede resumirse en obtener una red segura,
auto-cicatrizante y eficiente. Para ello será neces ario intercomunicar todas las infraestructuras
eléctricas mediante comunicaciones con niveles adec uados de fiabilidad y ancho de banda. No
está de más insistir en que para este proceso, será ideal reutilizar al máximo las
infraestructuras eléctricas, en especial, cables de distribución y dependencias asociadas.

2.3 PROFUNDIZANDO EN EL CONCEPTO DE SMART MOBILITY

Como se ha comentado anteriormente, el objetivo fun damental que pretende alcanzar el
concepto de Smart Mobility, es el de gestionar razo nada y sosteniblemente la red de
infraestructuras de transportes con el fin de hacer que los desplazamientos de personas y
mercancías se desarrollen en el tiempo mínimo y sin incidentes.
Para alcanzar ese objetivo fundamental, es necesari o que la gestión que se realice haga que se
cumplan una serie de requisitos indispensables, y e stos son:
– Reducción del gasto energético derivado.
– Reducción del tiempo invertido en los traslados.

Capítulo 2: Estado del Arte
28
– Reducción del número de siniestros.

Es razonable decir que se encuentran ciertas limita ciones a la hora de alcanzar los objetivos
marcados para conseguir una movilidad inteligente. Algunos ejemplos de estas limitaciones
son la imposibilidad de aumentar en tanto en cuanto sean necesarias las infraestructuras
existentes o la realización de grandes desembolsos económicos para adecuar dichas
infraestructuras. Por lo tanto, es obligado que las tareas que se realicen con el fin de cumplir
estos objetivos, sean lo suficientemente elaboradas y además se caractericen por conseguir un
equilibrio económico entre la inversión y el result ado obtenido.
Según el estudio de las congestiones en los corred ores de acceso a Madrid [7] editado en
enero de 2009 por la Fundación RACC Cerca de un mil lón de personas soportan a diario
atascos en las carreteras de acceso o circunvalació n de Madrid. De este millón de personas, el
68% se corresponde a vehículos privados y el 32% re stante se corresponde a usuarios de
autobús.
Estos atascos se traducen en la pérdida anual de 81 millones de horas al año, lo que supone un
coste aproximado de 840 millones de Euros equivalen tes al 0.6% del PIB de la Comunidad de
Madrid.
Individualizando gastos, el atasco diario que sufre n los ciudadanos madrileños, se corresponde
con la pérdida anual de 7 jornadas de trabajo, lo q ue correspondería a un promedio de 538€.
En la Figura 7 puede observarse el tráfico que soporta la ciudad de Madrid un día cualquiera. En
concreto la imagen muestra el estado el 23 de enero de 2013 a las 8.30h, un día sin especial
retención ni ningún accidente reseñable que provoca ra el colapso de ninguna carretera.

Capítulo 2: Estado del Arte
29

Figura 7 – Muestra del tráfico en Madrid a fecha 23 de en ero de 2013 (8.30h)
Se observa que el problema de la movilidad en las grandes ciudades es muy palpable y por lo
tanto, es indispensable que se generen actuaciones que hagan mención al concepto de Smart
Mobility con carácter de urgencia.
En este sentido, han comenzado a crearse una serie de actuaciones muy variada pero que se
pueden englobar en los siguientes títulos:
– Gestión del tráfico
– Gestión de medios de transporte público
– Gestión de aparcamientos
– Gestión de vehículos eléctrico

Capítulo 2: Estado del Arte
30
2.3.1 Gestión del tráfico
Uno de los aspectos clave a la hora de hablar de Sm art Mobility, es hablar de la gestión del
tráfico de las áreas urbanas. La gestión del tráfic o se basa en registrar, monitorizar y actuar
sobre el tráfico rodado de las ciudades en tiempo r eal, permitiendo así optimizar tiempos de
viaje y minimizando gastos de combustible y atascos .
Son múltiples los proyectos de investigación que se dedican a abordar esta temática aunque se
puede tomar como ejemplo el proyecto MARTA (Movilid ad y Automoción con Redes de
Transporte Avanzadas) [8] . Es un proyecto enmarcado en la iniciativa INGENIO 2010
promovida por el Centro para el Desarrollo Tecnológ ico Industrial (CDTI).
El proyecto está liderado por Ficosa Interanacional y cuenta con un presupuesto de 35
millones de Euros. Su duración está prevista para 4 años y engloba a 18 empresas privadas y 19
Centro de Investigación y Universidades.
El proyecto MARTA tiene como objetivo sentar las ba ses científicas y tecnológicas para la
movilidad en el siglo XXI para permitir al sector I TS (Intelligent Transport Systems) español
responder a los retos de seguridad, eficiencia y so stenibilidad.
El proyecto MARTA persigue ofrecer nuevas respuesta s y soluciones orientadas a mejorar la
seguridad y la eficiencia en el transporte, mediant e la generación de conocimiento útil
relacionado con las nuevas tecnologías, infraestruc turas y servicios de forma que sea posible
realizar una conducción más cómoda y segura, favore ciendo la reducción de la siniestralidad
vial.
2.3.2 Gestión de medios de transporte público
No sólo es interesante la gestión del tráfico priva do ya que es elevado el número de personas
que optan por moverse en transporte público. El con trol y monitorización de los diferentes
servicios de transporte público (autobús, metro y t axi principalmente) ahorran tiempo en el
desplazamiento de los ciudadanos, y a menudo es una solución económica comparada con el
transporte privado.
El gran impedimento de este tipo de transportes es el tiempo indefinido de espera
normalmente a la intemperie. Cuando el viaje que de be realizarse contiene algún tipo de
conexión entre líneas, este tiempo se multiplica.
El control, monitorización y seguimiento de los dif erentes servicios de transporte público
(autobuses, taxis y bicicletas) ahorraran a los ciu dadanos tiempo y harán el transporte en la

Capítulo 2: Estado del Arte
31
ciudad más eficiente. Con el fin de conseguir esto, el servicio de transporte público puede
rastrear la posición de sus vehículos y su grado de ocupación, equilibrando la frecuencia de
paso para ofrecer un mejor servicio a los usuarios.
La Empresa Municipal de Transportes (EMT), pionera en la aplicación de las nuevas tecnologías
en todo lo referente a la información al usuario, h a puesto en marcha "Navega Madrid" [9] . El
servicio está dedicado al transporte de público en el interior de la ciudad de Madrid mediante
líneas de autobús.
Con el uso de esta herramienta el usuario puede cal cular itinerarios personalizados, consultar
líneas que pasan por un punto concreto, consultar e l tiempo de espera en cada parada,
conocer incidencias del servicio, etc.
2.3.3 Gestión de aparcamientos
Es común en todas las ciudades (ya sean grandes o p equeñas) el gran problema de encontrar
aparcamiento tanto en espacios públicos como privad os.
La búsqueda de aparcamiento produce en el usuario d esatención hacía la tarea de conducción,
aumentando la inseguridad al volante. Así mismo se produce un incremento en el vertido a la
atmósfera de gases contaminantes, y a su vez, incre menta la congestión de vehículos en las
calles.
A primera vista, no hay nada positivo en la tarea d e buscar aparcamiento. Por esto, ¿Por qué
no gestionar razonadamente la tarea de búsqueda de emplazamiento y ayudando en tiempo
real al conductor a estacionar su vehículo?
El proceso en apariencia interminable de dar vuelta s hasta encontrar un lugar donde aparcar
es una experiencia demasiado común entre los conduc tores. Los retrasos motivados por el
aparcamiento producen frustración a los usuarios, a fectan negativamente al medio ambiente,
reducen la seguridad y suponen una pérdida de ingre sos para usted. Tanto si gestiona un
aparcamiento de una sola o diversas plantas, ¿cómo puede optimizar de forma rápida y eficaz
el proceso de gestión del aparcamiento y mejorar la experiencia del usuario?
El proyecto CIPSU [1] (Circuit Intelligent Pour Stationnement Urbain) es capaz de ofrecer un
sistema de navegación con el fin de guiar a los con ductores hacia es estacionamiento libre más
próximo. El sistema requiere apoyo activo de la com unidad y permite a los conductores llegar
a su emplazamiento de estacionamiento en el menor t iempo posible y evitando cualquier
atasco.

Capítulo 2: Estado del Arte
32
2.3.4 Gestión de vehículos eléctrico
Anteriormente se ha expuesto que uno de los grandes problemas de las grandes ciudades es el
gran efecto que tiene el tráfico rodado en relación a la generación de gases generantes de
efecto invernadero. No es tarea sencilla erradicar esta problemática y todas las acciones que
se realizan con relación a las Smart Cities tienen más o menos que ver con esto, ya que unas
buscan optimizar las rutas, otras descongestionar l as calles…
El vehículo eléctrico es una gran apuesta de muchas ciudades e incluso gobiernos, pues en los
casos en los que sea posible es una gran oportunida d de realizar trayectos en el mismo tiempo
con emisiones 0.
El Plan MOVELE [11] , nombre del Plan de Acción 2010-2012, se enmarca d entro de la
Estrategia Integral de Impulso al Vehículo Eléctric o en España 2010-2014. Este Plan está
compuesto por una serie de medidas a implementar du rante los próximos dos años para
incentivar de manera decisiva la introducción del v ehículo eléctrico.
El objetivo de la citada Estrategia es alcanzar la cifra de 250.000 vehículos eléctricos a final de
2014 circulando por nuestras calles y carreteras.
2.4 INTERNET OF THE THINGS

2.405.518.376 [12] . Ese es el número de usuarios de internet a 30 de junio de 2012, por lo que
casi seguramente hoy, se habrá incrementado sustanc ialmente. Estos usuarios tienen acceso a
la red casi desde cualquier sitio, pudiendo consult ar información o mantener conversaciones
con sus conocidos mediante mensajería instantánea.
Esto permite interactuar en tiempo real con las per sonas que sea necesario, pero ¿Por qué no
ir un paso más allá? ¿Por qué no interactuar con ob jetos inanimados? La respuesta a esta
pregunta se engloba en el término “Internet de las Cosas” (IoT, del inglés Internet of Things),
acuñado por el Auto-ID Center del Massachusetts Ins titute of Technology (MIT [13] ) a finales
de los años noventa.
El concepto IoT [14] [15] [16] tiene como objetivo conectar a internet tanto sere s animados
como inanimados, permitiendo así conocer el estado de todo lo conectado e interactuar con
ello de forma activa.
Puede parecer un despropósito conectar objetos a la red, ya que estos no son capaces de
mantener conversaciones razonables con un usuario, pero tampoco es lo que se pretende. Lo

Capítulo 2: Estado del Arte
33
que se busca es adquirir información relevante acer ca del estado de un objeto o de su
entorno, para con esto realizar acciones determinad as.
Mark Weiser, ideólogo del término “computación ubic ua”, explicó a principios de los años
noventa que el futuro de la computación sería aquel que nos permitiera formar parte de ella
sin ser conscientes.
Si se piensa detenidamente, el término de computaci ón ubicua, también se ha mencionado
implícitamente en el concepto de Smart City y esto es porque la inteligencia de la que se dota
a la ciudad, se canaliza a través de esta tecnologí a. Es por esta razón que IoT debe enmarcarse
como la principal tecnología habilitadora de las Sm art Cities.
Esto es debido a que para que exista cierta intelig encia, debe existir un conocimiento del
entorno y el conocimiento se alcanza gracias a la s ensorización e interconexión de multitud de
dispositivos y ambientes a internet.
El Internet de las Cosas ha propiciado que se estab lezcan una serie de cambios como los
acontecidos en la repartición de direcciones IP púb licas. Es debido al creciente número de
dispositivos que requieren conexión a Internet.
Cuando se utilizan los servicios de Internet, la co municación se establece gracias al
denominado Protocolo de Internet (IP, Internet Prot ocol). Hasta hace unos meses, estaba
vigente la versión 4 del protocolo (IPv4). Con este protocolo, existe posibilidad de direccionar
232 equipos y con el paso del tiempo IPv4 se ha quedad o obsoleto debido a la creciente
demanda de conexiones a Internet.
IPv6 [17] es la nueva versión del protocolo, capaz de direcc ionar 2 128 equipos terminales.
El despliegue de IPv6 se irá realizando gradualment e, en una coexistencia ordenada con IPv4,
al que irá desplazando a medida que dispositivos de cliente, equipos de red, aplicaciones,
contenidos y servicios se vayan adaptando a la nuev a versión del protocolo de Internet.
Con esta nueva versión del protocolo, no existirán problemas de conexión de la multitud de
equipos que requerirán estar permanentemente visibl es en la red.
Existen otras tecnologías habilitadoras de las Smar t Cities que están íntimamente ligadas al
IoT. Con estas tecnologías se pretende dotar a los objetos de una identidad no sólo numérica,
sino también física.
La principal se puede considerar la tecnología RFID (del inglés, Radio Frequency IDentification).

Capítulo 2: Estado del Arte
34
La tecnología RFID se define como un sistema de alm acenamiento y envío de información en
un entorno más o menos local. Los transmisores son etiquetas RFID las cuales almacenan una
pequeña cantidad de información y posteriormente pe rmite la lectura de la misma mediante
algún tipo de equipo análogo.
Existen varios tipos de etiquetas que se clasifican según su alcance y su tipo de alimentación.
Las etiquetas pasivas no tienen alimentación extern a pero tienen un alcance bastante limitado,
algo menos de 6m. Por el contrario, las etiquetas a ctivas si disponen de alimentación externa,
lo que le permite almacenar mayor cantidad de infor mación y enviarla hasta a 500m.
Esta tecnología habilitadora, aunque principal, va gradualmente quedando obsoleta, ya que el
gran impedimento de limitación de la información a almacenar hace que no tenga suficientes
prestaciones como para cumplir con los requerimient os actuales del mercado.
La tecnología RFID se ha visto completada por la te cnología sensórica, ya que con etiquetas
RFID no es posible hacer una buena aproximación al estado del objeto a monitorizar, sino que
más bien se limita a dotarle de cierta identidad fí sica.
La sensórica abre un amplio abanico de posibilidade s ya que existen multitud de sensores
capaces de medir, monitorizar, y enviar datos de di stinta naturaleza a las distancias que se
requieran. Esta tecnología permite monitorizar esta dos, eventos, alarmas, niveles… Se ajustan
a las necesidades del concepto IoT debido a que es tan amplio el mercado de los sensores
como necesidades tiene el IoT:
– Sensores de posicionado GPS
– Sensores de niveles de fluidos
– Sensores de gases
– Sensores de posición relativa
– Etc.
Con estas tecnologías habilitadoras, sólo cabe preg untarse cuán inteligentes son las cosas hoy
en día. Para dar respuesta a esta pregunta, se debe saber que existen diferentes niveles de
inteligencia para las cosas, se puede describir de la siguiente manera:
– Nivel 1: Identidad
– Nivel 2: Ubicación
– Nivel 3: Estado
– Nivel 4: Entorno

Capítulo 2: Estado del Arte
35
El nivel 1 podemos suplirlo con la tecnología RFID, ya que se limita a darle un nombre a ese
objeto inanimado. Por supuesto que es posible dotar de nombre a cada objeto ayudándose de
la sensórica, pero también es mucho más caro, por l o que se suele determinar el equipamiento
tecnológico de cada objeto según las necesidades de l mismo.
El nivel 2 quedaría cubierto por sensores GPS, pero no se debe olvidar que en el interior de
edificios o en zonas exteriores con condiciones de visión espacial reducidas, no suelen
funcionar correctamente. También se incluirían las balizas que dotarían al objeto de
localización relativa en zonas interiores o con esc asa cobertura GPS.
El nivel 3 se completaría con la gama de sensores d e estado existente en el mercado. Se puede
medir luminosidad, presión atmosférica, humedad, pr esencia, temperatura…
El nivel 4 quedaría en manos del administrador del sistema, que será el encargado de dotar de
cierta inteligencia a los objetos inanimados con el fin de que sean capaces de entender e
interactuar con el entorno según sus condiciones.
A modo de ejemplo de una aplicación a la que se le ha añadido el concepto de Internet of the
Things, se puede mostrar un sistema de gestión de f lotas de vehículos. Hace años, no se podía
controlar el estado de un vehículo con funciones de reparto de mercancías. A día de hoy
existen multitud de aplicaciones capaces de localiz ar espacialmente el vehículo, describir su
estado, consumo, recorrido…
2.5 RELACIÓN ENTRE IOT Y SMART CITIES

Para poder procesar la información de los distintos niveles de inteligencia expuesta
anteriormente, se deben utilizar nodos de canalizac ión de dicha información hasta un sistema
central capaz de interpretar los datos obtenidos de todos los sensores.
En este proyecto se aborda la tecnología inalámbric a de los nodos encaminadores, y es que a
menudo es muy complicado cablear ciertos nodos o di rectamente no interesa por
complicaciones técnicas o económicas. Es por eso qu e la gran mayoría de nodos recolectores
de información proveniente de sensores enmarcados e n el IoT, gozan de tecnología
inalámbrica.
Así pues, al conjunto de nodos inalámbricos acompañ ados de una serie de sensores capaces de
parametrizar el entorno que les rodea y que colabor an para el buen desarrollo de una tarea
común, se denomina “Red de Sensores Inalámbricos” [18] . (RSI o WSN del inglés Wireless
Sensor Network).

Capítulo 2: Estado del Arte
36
Una red de sensores inalámbricos [19] [20] está formada por un conjunto de actores que se
engloban en 3 categorías: dispositivos finales; dis positivos puerta de enlace; dispositivo
estación base. Además, no existen tamaño prefijado ni infraestructura asociada fija en la red
de sensores inalámbricos, por lo que prima la modul aridad y la distribución de nodos allá
donde sea necesario.
2.5.1 Dispositivos Finales
Los dispositivos finales de una RSI son equipos ele ctrónicos capaces de realizar la
recolección de la sensórica asociada a ellos mismos . Recopilan dicha información y
realizan algún tipo de procesamiento de la misma an tes de enviarla a las puertas de
enlace de la RSI. Normalmente se asocian a una fuen te de alimentación externa como
pueden ser pilas o baterías y además cuentan con al gún tipo de transceptor para
realizar las comunicaciones inalámbricas.
2.5.2 Puertas de Enlace
El papel de las puerta de enlace en las RSI es el d e encaminar la información que
reciben de los dispositivos finales hasta la estaci ón base, realizando frecuentemente
algún tipo de transformación o bien en el contenido o bien en el formato de dichos
datos. Estos equipos electrónicos no llevan sensóri ca asociada, por lo que quedan
únicamente unidos a una fuente de alimentación exte rna y a un módulo transceptor.
2.5.3 Estación Base
La estación base de una RSI es comúnmente llamado c ontrolador de red. Realiza tareas
de supervisión de red, control de paquetes y de adq uisición de los datos procesados
por las puertas de enlace. Es el punto visible de l a red, desde el cual se pueden realizar
comunicaciones con otras redes o servicios.
2.6 TECNOLOGÍAS HABILITADORAS

El desarrollo del proyecto no se podría realizar si n una serie de tecnologías habilitadoras que
permitieran el desarrollo de las distintas activida des previstas. Estas tecnologías habilitadoras
son la base para el buen funcionamiento del sistema que se propone y sin en claro
entendimiento de todas ellas, sería inviable adentr arse en el desarrollo del mismo.
Así pues, se pueden decir que las tecnologías en la s que se basa este Proyecto Final de Carrera
son fundamentalmente:

Capítulo 2: Estado del Arte
37
– GPS
– Módulos de comunicación inalámbrica Xbee
– Protocolo de comunicaciones Zigbee
– Microsoft Visual Studio
2.6.1 Sistema de Posicionamiento Global (GPS)
La principal tecnología habilitadora es el GPS (Glo bal Positioning System, del inglés Sistema de
Posicionamiento Global). [21]
El GPS es un sistema que permite determinar la posi ción de un dispositivo receptor en la
superficie de la tierra, aportando coordenadas de L atitud, Longitud y Altura. Se basa en la
extracción de una estimación de posición gracias a las ondas de radio que le son transmitidas
desde un mínimo de 4 satélites.
Hay diversos sistemas GPS definidos, tales como el NAVSTAR [22], GALILEO [23], GLONASS [24]
o EGNOSS [25], pero es el primero el que se va a describir a con tinuación, debido a que es el
que actualmente se encuentra operativo totalmente y mayor funcionalidad otorga a día de
hoy.
El sistema GPS NAVSTAR está dirigido por el Departa mento de Defensa de Estados Unidos. Este
Sistema de Posicionamiento Global se creó en 1973 c on el fin de eliminar los problemas de
navegación de los vehículos militares y de las trop as en actos bélicos
Es en 1980 cuando El Presidente de los Estados, Ron ald Reagan, decretó que el sistema podría
ser utilizado por usuarios civiles, pero se aprobó que el sistema no trabajara con las mismas
tolerancias y precisiones para estos últimos. A est e fenómeno se le denominó “Disponibilidad
Selectiva” y consistía en una degradación intencion ada de los valores de las efemérides
transmitidas y del reloj del satélite, ocasionando errores de localización de hasta 100 metros.
En mayo de 2000, El Presidente de los Estados, Bill Clinton, ordena que se elimine la
Disponibilidad Selectiva [26], dando así una precisión al sistema civil de 3 a 5 metros.
¿Cómo se determina la posición en los sistemas GPS?
La base de la localización de un móvil mediante el sistema GPS está en la triangulación con la
ayuda de los satélites anteriormente descritos. Cad a satélite envía ondas que viajan hacia el
receptor y gracias a la sincronización de los reloj es del satélite y del receptor, se puede
determinar la distancia que hay entre estos dos obj etos.

Capítulo 2: Estado del Arte
38
Con la información aportada por varios satélites (c on un mínimo de 3) se puede determinar la
posición exacta de un receptor gracias a los puntos de intersección que tiene las esferas que
indican la distancia a cada uno de los satélites.
En la Figura 8 queda explicado cómo con la ayuda de tres satélite s se puede obtener la posición
de un receptor. Se obtienen dos puntos posibles de localización, pero uno de ellos está muy
alejado de la superficie terrestre, por lo que pued e desecharse. Además, con la ayuda de un
cuarto satélite, podría desecharse automáticamente ese punto inválido.

Figura 8 – Ejemplo de triangulación con 3 satélites
¿De qué está compuesto el sistema de posicionamient o global (GPS)?
El sistema GPS se compone de 3 segmentos los cuales hacen conjuntamente que exista una
comunicación coherente entre los satélites y los re ceptores de las señales, son los
denominados:
– Segmento Espacial
– Segmento de Control
– Segmento de Usuario
El segmento espacial está compuesto por la red de s atélites, esto es, 30 unidades de las cuales
prestan servicio activo 24 de ellas, resultado 6 en reserva preparadas para entrar en reserva
inmediatamente si alguno de las 24 activas entra en avería o en modo de mantenimiento. Los
satélites orbitan de forma geoestacionaria a la tie rra a una distancia de 20.200 km de altitud y
distribuidos en 6 planos orbitales inclinados 55ș r especto al ecuador.

Capítulo 2: Estado del Arte
39

Figura 9 – Órbitas NAVSTAR
El segmento espacial está diseñado de forma que sie mpre existen de 5 a 8 satélites visibles de
forma directa por encima de un ángulo de elevación de 15ș, por lo tanto se garantiza que se
pueda estimar una posición con poco error del recep tor.
Por otro lado, el segmento de control se compone de todas las estaciones estratégicamente
posicionadas en tierra y destinadas al ajuste de la s señales que emiten los satélites.

Figura 10 – Estaciones del Segmento de Control GPS
El envío de datos de corrección se realiza desde la estación maestra de control (MCS) que se
encuentra situada en en Falcon AFB en Colorado Spri ng.
Todas las estaciones de control se encargan de reci bir y analizar las señales recibidas por cada
uno de los satélites puestos en órbita. Con esta in formación se realizan cálculos de ajustes de
órbita y correcciones en los relojes atómicos de ca da satélite.

Capítulo 2: Estado del Arte
40
Por último, el segmento de usuario se compone de lo s usuarios finales propiamente dicho. Los
receptores son adquiridos por las personas interesa das en realizar tareas de navegación o de
geo-localizacion. Los receptores son los encargados de recibir las señales que envían los
distintos satélites, transformando esa información en algo entendible para el usuario.
¿Cómo se envían las tramas de datos?
Las señales del sistema de GPS se componen de tres partes bien diferenciadas:
– Señal portadora
– Datos de navegación
– Secuencia de ensanchado
Existen dos señales portadoras denominadas “L” por el IEEE. Las dos frecuencias de las
portadoras derivan de una frecuencia fundamental f 0 = 10.23 MHz.
Se denominan L1 y L2 y se engloban por lo tanto en las portadoras:
– L1 /barb2right fL1 = 154f 0 = 1575.42 MHz
– L2 /barb2right fL2 = 120f 0 = 1227.60 MHz

L1 está destinada para usos civiles y militares, no así L2 que tiene función exclusiva para fines
militares. Esto es así ya que estas frecuencias dua les son esenciales para eliminar el error
causado por la refracción ionosférica, cosa inneces aria para fines civiles pero muy útil para
fines militares.
En la actualidad existen L3, L4 y L5. L3 se utiliza para fines militares, por lo tanto no tiene
trascendencia en el mundo civil. L4 se utiliza como complemento de L2 para correcciones de
posición de los errores originados en la ionosfera. L5 se utilizará como señal de emergencias y
de protección civil.

Los datos de navegación albergan la información ace rca de las efemérides de cada satélite
GPS, es decir información acerca del reloj del prop io satélite como del estado del mismo. Estos
datos tienen un bit rate de 50 bps y son transmitid os en la portadora L1.

La secuencia de ensanchado, al igual que los datos de navegación son únicos de cada satélite.
Esta secuencia está formada por:
– Código de Adquisición (C/A): Se trata de una secuen cia de 1023 “chips” (similar al
concepto de bit, pero recibe este nombre porque no pertenece a una palabra o byte

Capítulo 2: Estado del Arte
41
de información sino a un código de identificación) Este código se repite cada
milisegundo y es único para cada satélite. Sólo es enviado sobre la señal L1, lo que
hace que se reciba en dispositivos militares y civi les.
– Código de Precisión (P): Se encuentra encriptado y da servicio a fines militares. Tiene
una longitud de 2.35 10 14 chips y una tasa de repetición de 10.23 Mhz. Es mod ulado
únicamente sobre L2, lo que hace que tenga solament e fines militares.

El diagrama de bloques de la generación de una onda de radio GPS, se detalla a continuación:

Figura 11 – Esquema de generación de ondas GPS
2.6.2 Módulos de comunicación inalámbrica Xbee
Xbee [27] es el nombre a través del cual Digi International [28] comercializa una familia de
módulos inalámbricos capaces de realizar comunicaci ones con salida sencilla a una red Zigbee
[29]. La tecnología Zigbee permite conexiones a bajo co ste y consumo de dispositivos a una
red de sensores autoconfigurable y autorreparable. Gracias a ello, se pueden obtener datos en
tiempo real de forma remota de los distintos nodos de la red, resultando ser módulos
perfectos para aplicaciones de seguridad, domótica, control de eventos, etc.
En 2005 fueron introducidos al mercado bajo la marc a MaXStream y fueron desarrollados con
la capacidad de mantener conexiones punto a punto y punto a multipunto de hasta 250
kbit/s.Inicialmente se presentaron dos modelos, Xbe e y Xbee Pro. El primero de ellos
desarrolla una potencia de hasta 1mW mientras que e l módulo Xbee Pro desarrolla 100mW de
potencia, lo que le permite tener mayor alcance de comunicaciones.

Capítulo 2: Estado del Arte
42
En su forma más básica, solamente es necesario cone ctar los pines de alimentación, tierra,
entrada de datos y salida de datos para funcionar c on la UART del sistema. Existen versiones
que incorporan entradas de Reset, de Sleep, entrada s salidas digitales y analógicas…
A día de hoy existen multitud de placas Xbee dispon ibles en el mercado, operando en
numerosas frecuencias de comunicaciones y diseñadas así para adecuarse al mercado global,
añadiendo distintas posibilidades de alcance de las comunicaciones.
Para dar mayor versatilidad a los desarrolladores, Digi presenta las placas Xbee de distinta
forma de montaje, tanto superficial como de inserci ón. En las distintas placas se montan
distintas antenas para la variedad de alcances, per o siempre se respeta el formato del pineado,
haciendo así posible que un desarrollador pase de u n módulo Xbee a otro según varíen sus
necesidades.

Figura 12 – Módulos Xbee y Xbee Pro de Digi Internati onal
Se comercializan con una multitud de posibilidades de conexionado, destacando
principalmente los detectores inductivos, los de ga ses, temperatura y luminosidad…
Los módulos requieren una fuente de alimentación de 3.3V realizando consumos de 2mW para
los módulos más básicos, alcanzando unas distancias de comunicación de hasta 120m en
exteriores sin elementos que perturben la señal. Pa ra módulos Xbee Pro, esos consumos
aumentan a 50mW, pero en contrapartida se aumentan las posibilidades de comunicación a
una media de 3.200m en ambientes exteriores y en au sencia de elementos intermedios.
2.6.3 Protocolo de comunicaciones 802.15.4
IEEE 802.15 [30] [31] [32] se define como un grupo de trabajo dentro de IEEE 802, cuya
especialización reside en las redes inalámbricas de área personal (WPAN). Está formado por 5
grupos, de los cuales el denominado 802.15.4 se ded ica a las WPAN de baja velocidad.

Capítulo 2: Estado del Arte
43
Este grupo desarrolló en 2003 el estándar 802.15.4, cuya finalidad es la de la estandarización
del nivel físico y el control de acceso al medio de redes inalámbricas de área personal con bajas
tasas de trasmisión de datos.
802.15.4 fue creado con el claro propósito de defin ir los niveles de red básicos para dar
servicio a un tipo de red destinada a la comunicaci ón de dispositivos inalámbricos que
requieren baja velocidad de transferencia. Se busca ba con ello lograr una reducción del
consumo de los dispositivos inalámbricos, permitién doles alcanzar grandes periodos de tiempo
siendo autónomos en cuanto a alimentación se refier e.
Se pueden puntualizar las características más impor tantes como:
– Doble capa física (2.4GHz y 868/915 MHz)
– Velocidad de envío de datos desde 20 kbps a 250 kbp s
– Optimización de energía debido a su bajo ciclo de t rabajo
– Método de acceso a canal CSMA-CA
– Reducido consumo de energía
– Topologías aceptadas: star, cluster tree, mesh
– Capaz de direccionar 65535 dispositivos
– Alcance desde 1m a 75m
Por tanto, y resumiendo, se puede entender el están dar IEEE 802.15.4 como el creado para las
comunicaciones que requieran el bajo consumo de ene rgía, la flexibilidad de la red y el bajo
costo de desarrollo. Con estas características, tie ne grandes funcionalidades tanto a niveles
industriales como en aplicaciones domóticas, siendo este último punto donde se han
alcanzado mayores niveles de desarrollo.
En IEEE 802.15.4 existen dos tipos de dispositivos, estos son:
– Dispositivos de Funcionalidad Total (Full-Function Device o FFD).
– Dispositivos de Funcionalidad Reducida (Reduced-Fun ction Device o RFD).

La diferencia entre estos dos tipos de dispositivos es que mientas que los FFD tienen acceso al
uso de todos los servicios de la MAC, los dispositi vos RFD tienen un acceso limitado a esos
servicios.

Partiendo de eso, se define, como miembros de una r ed perteneciente a IEEE 802.15.4:

Capítulo 2: Estado del Arte
44
– Coordinador PAN
o Se trata de un dispositivo FFD del cual existe uno por red.
o Constituye la red y gestiona las comunicaciones ent re los elementos de la
misma.
– Router
o Se trata de un dispositivo FFD y puede haber varios en cada red.
o Se asocia con el coordinador de la red o con otro r outer.
o Puede actuar como Coordinador.
o Es el encargado del enrutamiento de saltos múltiple s de los mensajes.
– Dispositivos Final
o Se trata de un dispositivo RFD el cual sólo se comu nica con nodos FFD.
o No realiza ninguna tarea de enrutamiento.
o Pueden existir múltiples Dispositivos Finales en un a misma red.

En una red 802.15.4 puede haber hasta 254 nodos. No obstante, según la agrupación que se
haga, se pueden crear hasta 255 conjuntos (clusters ) de nodos, con lo cual, alcanzar un total de
64770 nodos. A tal efecto, existe la posibilidad de utlilizar varias topologías de red: en estrella,
en malla o en grupos de árboles, tal y como se repr esenta en la Figura 13 :

Figura 13 – Topologías de red del estándar IEEE 802.15. 4
En la Figura 14 se exponen las capas a las que hacer referencia en el estándar IEEE 802.15.4

Capítulo 2: Estado del Arte
45

Figura 14 – Capas de IEEE 802.15.4
La capa física es la encargada de interactuar tanto con el medio de transmisión de la red como
con la capa MAC, proveyéndola de dos servicios:
– Servicios de Datos PHY
– Servicio de Administración
Los Servicios de Datos PHY habilitan la transmisión y recepción de Unidades de Datos del
Protocolo PHY (PPDU), mientras que el Servicio de A dministración brinda los mecanismos para
el control y configuración de la interfaz de radio desde la capa MAC.
El protocolo IEEE 802.15.4 ofrece dos opciones de s ervicios de datos (PHY) que combinan con
el MAC para permitir un amplio rango de aplicacione s de redes. Las dos variantes se basan en
métodos de Secuencia Directa de Espectro Extendido (DSSS), caracterizados por bajos costos
de implementación digital, y ambas comparten la mis ma estructura básica de paquetes con
operaciones de bajo consumo de energía.
Las principales diferencias entre las dos vertiente s se detallan se resumen a continuación:
– Capa física a 2.4 GHz
o Especifica la operación en la banda Industrial, Méd ica y Científica (ISM). Está
disponible en practicamente todo el mundo.
o Permite una transmisión de 250 kb/s
– Capa física a 868/915 MHz
o Especifica la operación en la banda de 865 MHz en E uropa y 915 MHz en la
banda ISM en Estados Unidos.
o Rangos de transmisión de 20 kb/s y 40 kb/s respecti vamente.
Estas diferencias se pueden explotar para logar una variedad de objetivos o aplicaciones. Por
ejemplo, la baja densidad de datos en la capa físca a 868/915 MHz se puede aprovechar para

Capítulo 2: Estado del Arte
46
lograr mayor sensibilidad y mayors áreas de cobertu ra, con lo que se reduce el número de
nodos requeridos para cubrir un área geográfica. El rango superior de transmisión en la capa
físca a 2.4 GHZ se puede aprovechar para conseguir salidas superiores y de poca latencia.
Zigbee se ha implementado en la banda mundial de 2. 4 GHz.
El estándar IEEE 802 divide la Capa de Enlace de Da tos en dos sub-capas diferenciadas:
– Sub-capa de enlace al Control de Acceso al Medio (M edium Access Control, MAC)
– Sub-capa de Control de Enlaces Lógicos (Logical Lin k Control, LLC)
La diferencia de IEEE 802.15.4 respecto al resto de estándares IEEE 802 reside en la sub-capa
MAC, ya que la sub-capa LLC es común a todos ello. La sub-capa MAC depende del hardware y
varía respecto a la implementación física de esta c apa.
Las características principales del MAC IEEE 802.15 .4 pueden resumirse en :
– asociación/disociación, reconociminetos de entrega de trama (ACK), mecanismos de
acceso al canal, validación de trama, control de ga rantía de ranuras de tiempo (Slot
Time), control de guías (Beacon), y barrido de cana l.
La sub-capa MAC ofrece los siguientes servicios a l as capas superiores:

– Servicios de Datos MAC(MCPS)
– Servicio de Administración MAC (MLME)
El Servicio de Datos MAC permite enviar y recibir d atos a la siguiente capa superior, mientras
el Servicio de Administración MAC brinda mecanismos para el control y configuración de
comunicaciones, interfaz de radio y creación de red es desde la siguiente capa superior.
La información se encapsula en 4 tipos distintos de tramas, estas son:
– Data Frame , utilizada para la propia transferencia de datos. La trama empieza con un
encabezado de sincronización (SHR, Synchronization HeadeR), seguido de un
encabezado de capa física para indicar la longitud del paquete (PHR, Phy HeadeR), y
seguidamente la capa física de la unidad de servici o de datos (PSDU, Phy Service Data
Unit, PSDU).
– Acknowledgment Frame , utilizada para la confirmación de la recepción de las tramas
de datos. Es lo que se conoce como trama de asentim iento (ACK). La envía el receptor
del paquete al emisor para notificarle de la correc ta recepción de los datos.
Inmediatamente después de realizar una transmisión por la red, la norma establece un

Capítulo 2: Estado del Arte
47
tiempo de espera antes de iniciar una nueva transmi sión. La optimización de la red
aprovecha este “silencio” para enviar las tramas AC K de asentimiento.
– MAC Command Frame , utilizada para el control de la entidad MAC. Tal y como se ha
explicado anteriormente, el Coordinador de la red e s el encargado de construir y
gestionar la red. Para ello, se hacen necesarias la s Tramas de Comandos MAC como
mecanismo para enviar información de configuración y control a los diferentes
dispositivos que se conectan a la red. Independient emente de lo grande que sea la
red, todo dispositivo que se conecte a ella, recibi rá tramas de configuración para
iniciar el intercambio de datos.
– Beacon Frame utilizada por el coordinador para transmitir “beac ons”. Una de las
características relevantes en este tipo de redes es el ahorro de energía. Los nodos que
no estén participando en ninguna transferencia de d atos, pasan a un estado de
dormido, esperando recibir una señal para comenzar a escuchar. Esta señal o Beacon
Frame notifica a un nodo para que despierte y se ma ntenga a la escucha ante la
llegada de información por el canal de transmisión. Si pasado un determinado tiempo,
no recibe ninguna trama o señal por su dirección, p asa de nuevo al estado de dormido.

Se consigue de esta forma mantener a todos los nodo s sincronizados sin necesidad de
que estén continuamente a la escucha por el canal d e transmisión, evitando un
importante consumo de energía.
Los dispositivos que operan en la banda de 2.4 GHz pueden recibir interferencias causadas por
otros servicios. Esta situación es aceptable en las aplicaciones que utilizan el estándar IEEE
802.15.4, las cuales requieren una baja calidad de servicio, no requieren comunicación
asíncrona, y se espera que realice varios intentos para completar la transmisión de paquetes.
Por el contrario, un requerimiento primario de las aplicaciones del IEEE802.15.4 es una larga
duración en las baterías; esto se logra con poca en ergía de transmisión y muy pocos ciclos de
servicio.
Dado que los dispositivos IEEE 802.15.4 se pasan do rmidos el 99,9% del tiempo, y ocupan
transmisiones de baja energía en el espectro extend ido, parece evidente que, a pesar de las
posibles interferencias, trabajen en la banda de lo s 2.4 GHz.
2.6.4 Microsoft Visual Studio y Visual Basic .NET
Microsoft Visual Studio [33] es un entorno de desarrollo integrado (IDE, por su s siglas en
inglés) para sistemas operativos Windows. Proporcio na un editor, un compilador y un

Capítulo 2: Estado del Arte
48
depurador de código. En dicho entorno de desarrollo , están soportados varios lenguajes de
programación tales como Visual C++, Visual C#, Visu al J#, y Visual Basic .NET, al igual que
entornos de desarrollo web como ASP.NET.
Visual Studio permite a los desarrolladores crear a plicaciones, sitios y aplicaciones web, así
como servicios web en cualquier entorno que soporte la plataforma .NET. Así se pueden crear
aplicaciones que se intercomuniquen entre estacione s de trabajo, páginas web y dispositivos
móviles.
En este Proyecto Final de Carrera se ha utilizado V isual Basic .NET para el desarrollo de la
aplicación de la interfaz gráfica que recoge datos del puerto serie del ordenador y muestra por
pantalla la situación actual del entorno controlado .
Visual Basic .NET es un lenguaje de programación o rientado a objetos y dirigido por eventos,
desarrollado por Alan Cooper para Microsoft. La pri mera versión apareció en el año 1991 con
un entorno relativamente sencillo para facilitar la creación de programas gráficos y se puede
definir como un dialecto del clásico lenguaje BASIC implementado sobre el Framework .NET.
Visual Basic .NET suele considerarse un sistema RAD (Rapid Application Development), porque
permite crear aplicaciones de forma rápida, especia lmente para prototipos.
2.6.5 HTML
HyperText Markup Language [34]. Lenguaje de marcado predominante para la elaborac ión de
páginas web. Fue desarrollado por la Organización E uropea de Investigación Nuclear (CERN) en
el año 1945 con el fin de desarrollar un sistema de almacenamiento. Es un lenguaje sencillo
cuya codificación se lleva a cabo mediante el uso d e etiquetas, que permiten interconectar
diversos conceptos y formatos. Mediante estas etiqu etas se crean diferentes tipos de
elementos que tendrán sentido tanto por su contenid o como por la especificación de sus
atributos. Cabe destacar, que HTML permite la incor poración de ciertos códigos adicionales
que se conocen como script, los cuales aportan func ionalidad a la página web. Entre los scripts
que pueden agregarse, destacamos JavaScript que ha sido el utilizado en el Proyecto actual.

2.7 PROYECTOS Y APLICACIONES RELACIONADAS

Existen multitud de proyectos y soluciones tecnológ icas relacionadas con las Smart Cities, y no
es menos cuando se habla en concreto acerca de la g estión inteligente de aparcamientos.
Lleva mucho tiempo siendo investigado a lo largo de todo el mundo por múltiples empresas y

Capítulo 2: Estado del Arte
49
centros tecnológicos, dando resultados satisfactori os en la ordenación del tráfico rodado en el
interior de las ciudades.
A continuación se presentan una serie de soluciones tecnológicas a día de hoy totalmente
operativas, las cuales han servido como base de ins piración para la realización de este
Proyecto Final de Carrera.
2.7.1 Sistema de Aparcamiento Robotizado
Una de las soluciones para agilizar la búsqueda de aparcamiento, es la proporcionada por
múltiples empresas dedicadas a la instalación de ap arcamientos robotizados.
Se tratan de sistemas en los cuales el usuario posi ciona su vehículo en una zona de recepción y
el sistema se encarga de ubicar automáticamente el vehículo en una posición disponible.
Esta idea no es nueva, pero es en los últimos años cuando se han desarrollado sistemas
totalmente automatizados. Principalmente ha sido a partir de la década de los 50 cuando se ha
trabajado más en este sentido debido a que fue a pa rtir de esta fecha cuando varias empresas
presentaron sus trabajos mayormente en Europa y Asi a. La corporación Krupp fue la más
aventajada ofreciendo un total de 1.600.000 plazas solamente en Japón.
En España es un mercado emergente aun por consolida rse, pero no son pocas las iniciativas
que se han desarrollado hasta ahora.
El sistema ofrece unas claras ventajas para el usua rio, ya que se reducen los tiempos de
búsqueda de aparcamiento, se aumenta la seguridad e n varios campos ya sea respecto a
circular por ambientes mal iluminados o contra acto s de vandalismo, se ahorra espacio, se
reducen los ruidos y la emisión de gases contaminan tes…
Una muestra de cómo se conformar los aparcamientos robotizados es la siguiente imagen:

Capítulo 2: Estado del Arte
50

Figura 15 – Interior de aparcamiento robotizado

PARK-IN [35] es una empresa española compuesta por personal técn ico especializado con
varios años de experiencia en el sector de la arqui tectura, construcción e implantación de
sistemas robotizados en el país. Representa a la fi rma alemana Stolzer Parkhaus que
pertenece al Grupo STOPA , fabricante de este tipo de aparcamientos desde ha ce más de 25
años con miles de plazas instaladas en todo el mund o, tanto bajo su propia marca, como llave
en mano para otras importantes empresas del sector.
Ha desarrollado parkings robotizados a lo largo de ciudades de todo el mundo como Madrid,
Estambul, New York, Grünwald…
Por poner un ejemplo, en el caso de Madrid se ha de sarrollado el siguiente aparcamiento:
En uno de los ejes comerciales más importantes del barrio Salamanca, se instaló un sistema
LPS, de 71 plazas en 7 niveles bajo rasante. El pri mer sótano del edificio es de uso comercial. El
ascensor lateral atraviesa este sótano y es el enca rgado de llevar los coches hasta la zona de
almacenamiento.
Las estanterías de almacenamiento están configurada s en 7 niveles, fueron diseñadas para
permitir la construcción de forjados intermedios ne cesarios para la estructura del edificio. El
acabado de la estructura es galvanizado. El robot, encargado de recoger los vehículos del
ascensor lateral y ubicarlos en la posición de apar camiento designada por el sistema, como

Capítulo 2: Estado del Arte
51
también el proceso inverso, de retirada de los vehí culos. Incorpora un dispositivo de giro, para
entregar los coches en la cabina de transferencia e n dirección de circulación. El sistema cuenta
con capacidad para vehículos normales y altos. En e ste aparcamiento se ha instalado un
almacén de pallets vacíos y un ascensor lateral con intercambiador de pallets, dispositivos
innovadores de Stolzer Parkhaus para optimizar los tiempos.

Figura 16 – Distribución interior del aparcamiento robo tizado
2.7.2 Sistema de detección de plazas de aparcamient o libres
Otro sistema que se utiliza para la ordenación del tráfico rodado en búsqueda de un
estacionamiento es el basado en informar a los cond uctores de las plazas de aparcamiento que
quedan libres, para que así éstos se puedan dirigir hacia ellas en el menor tiempo posible y sin
la necesidad de realizar movimiento aleatoriamente para hallarlas.
Estos sistemas se diferencian en dos vertientes:
– Aparcamientos al aire libre o en superficie.
– Aparcamientos subterráneos o cubiertos.
Por facilidad de desarrollo, se encuentran más avan zadas las soluciones en entornos interiores,
ya que éstos favorecen un mayor control sobre las p lazas otorgando mucha mayor facilidad
para conocer el estado de las mismas.

Capítulo 2: Estado del Arte
52
A menudo son usados sensores determinantes de ocupa ción, basados en tecnología de
ultrasonidos. En cuanto el sensor detecta que la pl aza ha sido ocupada por un vehículo,
informa al sistema central de esa alteración de su estado, por lo que se elimina de la red de
plazas disponible.
Normalmente estos sensores de ultrasonidos son alim entados mediante cableado destinado a
tal efecto, aprovechando la infraestructura del pro pio aparcamiento, cosa que no es posible en
aparcamientos de ambiente exterior.
Es por esta simple razón que los sensores que se ut ilizan para aparcamientos exteriores, deben
ser completamente autónomos. Normalmente llevan aco pladas unas baterías que les dotan de
una autonomía de aproximadamente 5 años.
Así mismo, los sensores de aparcamientos exteriores suelen ser de tecnología inductiva por la
razón de que a diferencia de los de aparcamientos i nteriores, no se pueden colocar sobre la
plaza de aparcamiento, sino que deben soterrarse ba jo la superficie de la plaza de
aparcamiento.
Existen multitud de empresas que se dedican a comer cializar sistemas de control de
aparcamientos, como ejemplo las que se enumeran a c ontinuación.
ParkHelp Mobility and Soustainability Solutions [36] es una empresa de capital español
fundada en 2006. Está presente en más de 45 países y cuenta con un parque instalado de más
de 200.000 plazas de aparcamiento.
Su objetivo principal es la de guiar el tráfico rod ado en búsqueda de aparcamiento hacia una
plaza de aparcamiento que se encuentre disponible y susceptible de ser usada por el vehículo
guiado.
Sus 2 líneas de trabajo son las denominadas Off Str eet y On Street y como se ha explicado
anteriormente, se basan en la instalación de sensor es en el suelo en el caso de la línea
OnStreet y en el techo en el modo OffStreet, siendo éstos capaces de detectar si la plaza de
aparcamiento se encuentra libre u ocupada. Dicha in formación la traslada a un centro de
control que es el encargado de plasmar esa informac ión en paneles informativos destinados al
efecto. Existe otra variante basada en aplicaciones M2M, poniendo a disposición del usuario
vía remota de la información de plazas de aparcamie nto libres.
Utiliza las siguientes tecnologías:

Capítulo 2: Estado del Arte
53
– Sensor ParkHelp con tecnología inalámbrica

Se encuentra en un estado de implantación muy avanz ado como se muestra a continuación.
Tiene presencia en 45 países, como ejemplo:
– India HQ Common Whealth (Nueva Delhi)
– Francia Metz Cathedrale (Metz)
– USA Los Angeles Towers (los Angeles)
– Finlandia Koskikeskus (Tampere)

Se trata de un tipo de sensor con tecnología ultras ónica que detecta la presencia de vehículos
en un campo de visualización determinado. Los senso res no son autónomos, ya que van
cableados desde un nodo central a través del cual e nvían la información de ocupación y
reciben la alimentación necesaria para el funcionam iento.

Este sistema de sensores es totalmente inviables pa ra exteriores, pero es muy apropiado para
ambientes interiores que permitan la instalación de l cableado

Cada sensor manda la información de ocupación a un display que es el encargado de mostrar
el estado actual de cada zona de aparcamiento.

– Señalización dinámica (displays)

Se trata de displays que informan en tiempo real de l estado de ocupación de una área
determinada. Simplemente se dedica a recolectar la información proveniente de las líneas de
sensores instaladas en la calzada, mostrando el núm ero de plazas libres de cada zona de
aparcamiento y recomendando un camino para llegar a la plaza libre más cercana.

Figura 17 – Esquema resumen ParkHelp Offstreet

Capítulo 2: Estado del Arte
54
ParkHelp tiene en Madrid ejemplos de implantación d e su tecnología, como pueden ser el
aparcamiento del Centro Comercial La Vaguada y el a parcamiento de la Terminal 4 del
Aeropuerto de Madrid-Barajas.
En el centro comercial La Vaguada se implantó el si stema de guiado inteligente ParkHelp, con
sensores y pilotos que informan sobre el estado de ocupación de la plaza y paneles dinámicos
distribuidos estratégicamente en el parking para re dirigir el tráfico a las plazas disponibles.
El sistema controla 1.641 plazas estándar en la pla nta 1, 1.774 plazas estándar en la planta 2 y
70 paneles informativos de 2 dígitos.
Como resultado después de la implantación del siste ma, se tienen las siguientes conclusiones:
1. El parking ha mejorado su accesibilidad, evitando c olas en entradas y salidas gracias al
guiado.
2. El parking ha mejorado su movilidad, disminuyendo e l tiempo de circulación por
vehículo a la hora de buscar aparcamiento y aumenta ndo el tiempo de permanencia
en el centro comercial, por lo tanto el tiempo de c onsumo.
3. Se han eliminado los colapsos en el parking los día s punta del año.
4. Incremento del tiempo de estacionamiento medio a me nos de 2 minutos.
5. Mejora de la gestión del tráfico en la ronda perime tral exterior.
6. Reducción de cruces innecesarios en la Calle Centra l del aparcamiento.
7. Reducción notoria de las retenciones a la salida.
8. Mejora del reparto del tráfico de entradas y salida s.
9. Reducción de aglomeraciones en la Calle Central.
El sistema OnStreet es similar al expuesto anterior mente, con la única diferencia de la
sensórica diseñada para detectar la ocupación de pl aza de aparcamiento libre.
En la tecnología OnStreet se trata de un tipo de se nsor con tecnología wireless y que lleva
acoplada una batería para dotarle de autonomía. Inc orpora tecnología que mediante la
utilización de la variación en un campo magnético p ermite saber el estado de ocupación de la
plaza de parking que le corresponde controlar. Incl uye una batería que le dota de una
autonomía de 4 años de vida, después de este tiempo , hay que sustituir esa batería. Consumo
medio de 4W. Cada sensor manda la información de oc upación a un display que es el
encargado de mostrar el estado actual de cada zona de aparcamiento.

Capítulo 2: Estado del Arte
55
–
Figura 18 – Sensor de ocupación de plaza de aparcamiento P arkHelp Onstreet
–
Además para la tecnología OnStreet existe una aplic ación denominada Infopark , disponible
para SmartPhones y la cual es capaz de indicar en t iempo real el estado de ocupación de un
aparcamiento determinado por el usuario, ayudando a este a dirigirse a la plaza de
aparcamiento seleccionada.

Figura 19 – Esquema resumen ParkHelp Offstreet
Existen soluciones similares a la proporcionada por el sistema ParkHelp, una de ellas es la
aportada por Libelium [37] , empresa de capital español con una fuerte presenc ia en mercados
que requieren de comunicaciones inalámbricas.
Se trata de un sensor de campo magnético que se inc orpora a su conocido desarrollo
WaspMote [38] , tarjeta que incorpora tecnología ZigBee para las comunicaciones
inalámbricas. La solución aportada por Libelium, es denominada Smart Parking [39].

Capítulo 2: Estado del Arte
56

Figura 20 – Sensor inductivo de Libelium
Es muy similar al caso de parkhelp para exteriores, a diferencia de que el sensor de libelium
queda integrado totalmente en la calzada mediante l a realización de una obra, es decir, el
sensor no queda expuesto a actos vandálicos de ning ún tipo. Este sistema tiene un
inconveniente y es que caso de necesitarse mantenim iento, habría que realizar de nuevo obra
para la extracción del sensor, lo que encarece en d emasía el producto.

Figura 21 – Mota de Smart Parking instalada
El sistema de comunicaciones que se presenta en lib elium es el siguiente:

Capítulo 2: Estado del Arte
57

Figura 22 – Esquema de conexiones Smart Parking
Los módulos de análisis de ocupación transmiten la información de la disponibilidad de la plaza
de aparcamiento a nodos de la red que actúan como p asarelas hacia el nodo central o
coordinador. El nodo coordinador puede estar en con exión con un router que puede transmitir
la información allá donde sea necesario utilizando tecnología Wifi.
Existen multitud de empresas con sistemas similares , pero no es razonable exponer aquí todas
ellas, ya que la tecnología utilizada es en mayor o menor medida similar.

58

Capítulo 3
Análisis de Requisitos

Capítulo 3: Análisis de Requisitos
59
3.1 Descripción del problema real y su resolución
3.1.1 Introducción
Ha quedado demostrado que conforme aumenta el númer o de habitantes de una ciudad, se
resta capacidad de movimiento de los mismos debido al incremento de los vehículos,
aglomeración en las calles y reducción del espacio disponible.
Este problema tiene difícil solución, por eso debe trabajarse en un sentido que permita reducir
el número instantáneo de desplazamientos. Esto pued e conseguirse de muchas maneras,
entre ellas haciendo más atractivo el uso del trans porte público, fomentando y adecuando las
infraestructuras para aumentar el uso de vehículos privados de forma compartida o
simplemente haciendo que los vehículos que no tenga n una clara necesidad de estar en
movimiento, no lo estén.
Este Proyecto Final de Carrera versa en este último sentido. Se busca reducir al mínimo el
número de usuarios de vehículos privados que no tie nen necesidad expresa de realizar
movimientos con sus vehículos. Sabiendo que la caus a principal de estos movimientos es que
no existan plazas de aparcamiento libres para estac ionar el vehículo, parece lógico que se
intente eliminar la necesidad de realizar una búsqu eda activa de aparcamiento, ya que pueden
existir soluciones tecnológicas que realicen esa bú squeda y una posterior asignación a los
usuarios, permitiendo así realizar el estacionamien to en el menor tiempo posible, reduciendo
costes, eliminando vehículos de la circulación acti va de las ciudades y evitando contaminar en
esos desplazamientos.
3.1.2 Descripción del sistema
Para alcanzar todos los objetivos expuestos anterio rmente, se pretende desarrollar una mejora
al sistema actual de reconocimiento de plazas de ap arcamiento libres. Se puede explicar
tomando como base el siguiente diagrama:

Capítulo 3: Análisis de Requisitos
60

Figura 23 – Diagrama explicativo del entorno del demostr ador
Aunque la tecnología desarrollada puede aplicarse a casi cualquier situación, se pretende
validar en entorno demostrador similar al mostrado en la Figura 23 – Diagrama explicativo del entorno
del demostrador . Se trata de una intersección de 4 vías la cual cu enta con zonas de aparcamiento
en 3 de ellas. La vía que no cuenta con zonas de ap arcamiento se utilizará para situar el panel
informativo del estado del resto de zonas de aparca miento. La intersección se divide en 3
zonas de aparcamiento: Zona 1, zona 2 y zona 3, sit uadas una en cada extremo de la
intersección.
A diferencia de los sistemas actuales que controlan todas y cada unas de las plazas con un
sensor individual en cada plaza, el sistema propues to apuesta por controlar un conjunto de
plazas de aparcamiento, reduciendo costes de instal ación y mantenimiento sin perder
operatividad.
La forma de conocer si un vehículo ha ocupado o no una plaza disponible, es porque lleva
embarcada otra mota con un sensor GPS, por lo que e n la tarea de ocupación de la plaza,
informará a los controladores de zona de la intenci ón del conductor. Posteriormente cada
controlador de zona analizará las coordenadas recib idas de cada vehículo y realizará las
acciones adecuadas según sea necesario.
Si un vehículo aparca en una zona controlada por un a mota encargada de ello, la mota
encargada enviará un mensaje al coordinador de la r ed para actualizar en ese preciso instante
la tabla de ocupación general.

Capítulo 3: Análisis de Requisitos
61
3.1.3 Actores intervinientes
Para dejar más clara la configuración hardware que se va a seguir, se muestra un esquema tipo
a continuación:

Figura 24 – Esquema hardware del sistema de monitorizació n de aparcamientos
A modo resumen, puede decirse que las atribuciones de cada tipo de mota, son las siguientes:
Motas tipo End Device: Embarcadas en los vehículos y encargadas de report ar su presencia en
zona de parking a las motas tipo Router.
Motas tipo Router: Dispuestas de manera fija en cada zona de aparcami entos y encargadas de
monitorizar las mismas recibiendo información de pr esencia de las motas tipo End Device y
reportando a las motas tipo Controlador dicha infor mación.
Motas tipo Controlador: Instaladas junto al panel de visualización y encar gadas de recibir la
información desde las motas tipo Router acerca de p resencia o abandono de plazas de parking.
Así mismo se encuentran encargadas de actualizar lo s datos del panel visualizador.
Por otro lado, el panel informativo será el encarga do de mostrar los datos de las posiciones
libres y de su ubicación.

Capítulo 3: Análisis de Requisitos
62
El Pseudocódigo que detalla la actuación de cada ac tor interviniente en el sistema será el
siguiente:
PSEUDOCÓDIGO END_DEVICE
Declaración de variables
Bucle de configuración
{
Configurar módulo Xbee
Configurar módulo GPS
Obtener MAC del dispositivo
}

Bucle de ejecución
{
Obtener valores de latitud y longitud
Determinar si se encuentra en reposo u ocupado

Si (ocupado)
{
Si (solicitud de alta y estado anterior = baja)
{
Preparar paquete de alta
}
Si no, si (solicitud de baja y estado anterior = al ta)
{
Preparar paquete de baja
}

Si (paquete preparado para envío)
{
Enviar paquete a Router
}
Si no
{
ERROR
}
}
Si no, si (hay solicitud activa y no hay ACK)
{
Espera la llegada de paquete ACK desde el router

Si (no llega)
{
Reenviar el paquete
}
}
Si no, si (hay que reenviar)
{
Se reenvía
}
}

Capítulo 3: Análisis de Requisitos
63
PSEUDOCÓDIGO ROUTER
Declaración de variables

Bucle de configuración

Bucle de ejecución
{
Si (no ocupado)
{
Si (hay paquete)
{
Si (paquete de baja)
{
Preparar paquete baja para Controlador
Enviar ACK a End_device
Enviar paquete a controlador = 1
}
Si no, si (paquete de alta)
{
Preparar paquete alta para Controlador
Enviar ACK a End_device
Enviar paquete a controlador = 1
}
Si no
{
ERROR AL RECIBIR
}

Si (enviar ACK)
{
Enviar ACK al End Device
}

Si (enviar paquete a controlador)
{
Enviar paquete a controlador
}
}
}
Si no, si (paquete enviado a CONTROL y no hay ACK)
{
Espera la llegada de paquete ACK desde el CONTROL

Si (no llega)
{
Reenviar el paquete
}
}
Si no, si (hay que reenviar)
{
Se reenvía
}
}

Capítulo 3: Análisis de Requisitos
64
PSEUDOCÓDIGO CONTROLADOR
Declaración de variables

Bucle de configuración

Bucle de ejecución
{
Si (hay paquete)
{
Si (paquete de alta)
{
Enviar ACK a Router = 1
Si (no está ya dado de alta)
{
Recorre estructuras para buscar su d irección
Si (quedan plazas libres)
{
Recorre para buscar posi ción en blanco
Asigna datos de alta

}
}
}
Si no, si (paquete de baja)
{
Enviar ACK a Router = 1
Se recorren todas las estructuras para buscar la MA C
Si (encontrada)
{
Se libera posición en la estructura
}
}
}

Si no, si (Enviar ACK a Router)
{
Se envía ACK al router
}

Enviar a Panel información actualizada

}

Capítulo 3: Análisis de Requisitos
65
Así mismo, el panel informativo se ha implementado con la ayuda de un PC y sobre el entorno
de desarrollo Microsoft Visual Studio. El lenguaje utilizado para llevar a cabo la programación
ha sido Visual Basic .NET, caracterizado fundamenta lmente por ser uno de los lenguajes más
apropiado para el desarrollo de aplicaciones basada s en formularios. La estructura de la
aplicación se resume en:

Clase Windows Form1: formulario de inicio que se mu estra al ejecutar la aplicación y que
se mantiene fijo durante todo el tiempo de ejecuci ón. Es la interfaz que se muestra al
usuario. Contiene elementos gráficos para la repres entación y una base de programación
que controla el comportamiento de dichos elementos.
Clase GoogleMaps.vb: define las funciones de escrit ura sobre un fichero de texto para
componer la página html que muestra el estado de oc upación de las plazas de
aparcamiento en un Google Maps, siempre en función del estado de las plazas de
aparcamiento recibido a través del puerto serie. La llamada a estos métodos se lleva a
cabo desde el formulario principal cada vez que se recibe una notificación de actualización
a través del puerto serie. Los métodos de escritura se componen de:
– Llamadas de impresión sobre el fichero con las dife rentes sentencias de código html.
– Llamadas de impresión sobre el fichero con sentenci as Google Maps, obtenidas de la
API de Google, basadas fundamentalmente en localiza r la zona mediante coordenadas
GPS, y especificar, para cada uno de los marcadores de plaza, su color y su animación
en función de su estado actual.

La comunicación entre la aplicación de formulario y la mota controlador se lleva a cabo
mediante la monitorización del puerto serie al que está conectada. Visual Basic .NET ofrece la
posibilidad de abrir un puerto serie específico y e scuchar y procesar todos los datos que se
reciben a través de él. En el caso del proyecto act ual, cuando se detecta información de
cambio de estado, que entra por el puerto serie al que está conectada la mota, se genera un
evento para llevar a cabo todo el proceso de actual ización de la interfaz gráfica: por un lado, se
actualizan los elementos del formulario y por otro se actualiza el código html de la página que
contiene el Google Map, recargando esta nueva infor mación sobre la aplicación para
completar la actualización de todos los elementos v isuales.

Los diferentes elementos para la representación de los datos se dividen en:
– Elementos de diseño del Windows Form, tales como et iquetas, contenedores de
imágenes y paneles de agrupación. Los datos se mues tran en la interfaz, y se actualiza

Capítulo 3: Análisis de Requisitos
66
su valor en función de la información de estado rec ibido desde la mota a través del
puerto serie.
– Página web, enmarcada en un panel de diseño de Wind ows Form, que se actualiza con
la ejecución del código de la clase GoogleMaps.vb c ada vez que se genera un evento
de actualización, y se recarga de manera inmediata en la interfaz.

Capítulo 3: Análisis de Requisitos
67
PSEUDOCÓDIGO Form1

Declaración de variables

Función New
{
Llamada a función para inicializar todos los compo nentes del formulario
Llamada a función para inicializar puerto serie
}

Función prepararOcupacion
{
Bucle de ejecución
{
Actualizar valor de todas las filas de la variabl e global arrayCalle
}
}

Función actualizar_calle1_num
{
Asignar el nuevo número de plazas libres a la call e1
}

Función actualizar_calle2_num
{
Asignar el nuevo número de plazas libres a la call e2
}

Función actualizar_calle3_num
{
Asignar el nuevo número de plazas libres a la call e3
}

Funcion recargarDatos
{
Llamada a la función que actualiza los datos de la calle1
Llamada a la función que actualiza los datos de la calle2
Llamada a la función que actualiza los datos de la calle3
}

Funcion leerSerialData
{
Abrir puerto serie al que la mota está conectada
}

Funcion recibirDatos que maneja el evento de recepc ión de datos del puerto serie
{
Si (paquete útil)
{
Llamada a la función prepararOcupacion
Llamada a la función recargarDatos
Llamada a la función de escritura de código html y GoogleMaps
Refrescar interfaz
}
}

Capítulo 3: Análisis de Requisitos
68
PSEUDOCÓDIGO GoogleMaps.vb

Función escribirGoogleMaps
{
Escribir en archivo sentencias de cabecera html
Escribir en archivo sentencias GoogleMaps calle1
Escribir en archivo sentencias GoogleMaps calle2
Escribir en archivo sentencias GoogleMaps calle3
Escribir en archivo sentencias html
}

El panel creado, queda de la siguiente manera:

Figura 25 – Panel informativo de la aplicación

Capítulo 3: Análisis de Requisitos
69
3.2 Requisitos del sistema

El sistema anteriormente expuesto, ha de tener una serie de equipos que serán instalados o
bien en el mobiliario urbano, o bien en los vehícul os que buscan una plaza de aparcamiento
libre.
Así mismo se ha de dotar con un panel de visualizac ión el cual mostrará las plazas de
aparcamiento libres junto con su ubicación.
3.2.1 WaspMote
El equipo que se montará como parte del mobiliario urbano, consiste en una placa electrónica
asociada a una placa Xbee (mota), siendo así capaz de recibir y enviar datos a través de
radiofrecuencia. En este Proyecto Final de Carrera, se ha optado por la placa WaspMote del
fabricante Libelium, debido a la gran oferta y modu laridad de sus equipos.
Waspmote es una placa electrónica modular basada en el microcontrolador ATmega1281, a la
que se le puede añadir casi cualquier tipo de senso r o periférico, lo que le permite que pueda
ser usada indistintamente como coordinador de red, router o dispositivo final, incluyendo así
facilidad de manejo a la hora del desarrollo final.

Figura 26 – Placa Waspmote de LIbelium
Su característica principal es que está diseñada pa ra consumir muy poca energía, lo que le
confiere una autonomía de funcionamiento tal, que p uede ser usada independiente y durante
espacios muy prolongados de tiempo sin un suministr o de energía de red, sino de una batería
externa de pequeñas dimensiones.
Los periféricos disponibles para integrar en Waspmo te se clasifican en:
• Módulos ZigBee/802.15.4 (2.4GHz, 868MHz, 900MHz). B aja y alta potencia.
• Módulo GSM/GPRS (Quadband: 850MHz/900MHz/1800MHz/19 00MHz).
• Módulo GPS.
• Módulos Sensoriales (Placas de Sensores).
• Módulo de almacenamiento SD Memory Card.

Capítulo 3: Análisis de Requisitos
70

El esquema hardware de una placa Waspmote es el que se presenta a continuación:

Figura 27 – Esquema HW de la placa

Microcontrolador: ATmega1281
Frecuencia:8MHz
SRAM: 8KB
EEPROM: 4KB
FLASH: 128KB
SD Card: 2GB
Peso: 20gr
Dimensiones: 73.5 x 51 x 13 mm
Rango de Temperatura: [-20șC, +65șC]

Capítulo 3: Análisis de Requisitos
71

La distribución de componentes dentro de la placa, es la siguiente:

Figura 28 – Vista superior de Waspmote

Figura 29 – Vista inferior Waspmote
Waspmote tiene la capacidad de comunicación con otr os dispositivos mediante los diferentes
puertos de entrada-salida que posee la placa.

Waspmote tiene 4 modos de funcionamiento.

– ON: modo normal de funcionamiento. El consumo en es te estado es de 9mA.
– Sleep: El programa principal se detiene, el microco ntrolador pasa a un estado de
latencia, del que puede ser despertado por todas la s interrupciones asíncronas y por la
interrupción síncrona generada por el Watchdog. El intervalo de duración de este
estado va de 32ms a 8s. El consumo en este estado e s de 62μA.
– Deep Sleep: El programa principal se detiene, el mi crocontrolador pasa a un estado de
latencia del que puede ser despertado por todas las interrupciones asíncronas y por la
interrupción síncrona lanzada por el RTC. El interv alo de este ciclo puede ir de 8
segundos a minutos, horas, días. El consumo en este estado es de 62μA
– Hibernate: El programa principal se detiene, el mic rocontrolador y todos los módulos
de Waspmote quedan completamente desconectados. La única forma de volver a

Capítulo 3: Análisis de Requisitos
72
activar el dispositivo es a través de la alarma pre viamente programada en el RTC
(interrupción síncrona). El intervalo de este ciclo puede ir de 8 segundos a minutos,
horas, días. Al quedar el dispositivo totalmente de sconectado de la batería principal el
RTC es alimentado a través de una batería auxiliar de la que consume 0,7μA.

Además, hay que dotar a las motas de los periférico s necesarios tanto para realizar las
comunicaciones vía radio frecuencia como para adqui rir los datos del entorno. Hablamos por
tanto de módulos Xbee y módulos GPS:
3.2.2 Xbee
Todas las placas Waspmote han de montar un módulo d e comunicaciones por radiofrecuencia
con el fin de enviar datos a través de ondas de rad io.
Waspmote puede integrar módulos XBee del fabricante Digi para la comunicación en bandas
de frecuencia libre ISMB (Industrial Scientific Med ical Band).Estos módulos se comunican con
el microcontrolador utilizando la UART_0 a una velo cidad de 38400bps.

Figura 30 – Módulo de comunicaciones XBee
La frecuencia utilizada es la banda libre de 2,4GHz , utilizando 16 canales con un ancho de
banda de 5MHz por canal.

Figura 31 – Espectro de frecuencias XBee

Capítulo 3: Análisis de Requisitos
73

Figura 32 – Distribución de canales por frecuencias
Los módulos XBee 802.15.4 cumplen con el estándar I EEE 802.15.4 que define el nivel físico y
el nivel de enlace. A las funcionalidades aportadas por el estándar, los módulos XBee añaden
ciertas funcionalidades como:
• Descubrimiento de nodos: se añade cierta informació n a las cabeceras de los paquetes
de forma que se pueden descubrir otros nodos dentro de la misma red. Permite enviar
un mensaje de descubrimiento de nodos, de forma que el resto de nodos de la red
responden indicando sus datos (Node Identifier, @MA C, @16 bits, RSSI).
• Detección de paquetes duplicados: Esta funcionalida d no se establece en el estándar y
es añadida por los módulos XBee
3.2.3 GPS
Las motas embarcadas en los vehículos, deben dispon er de un módulo GPS integrado en las
plazas Waspmote aportándolas funcionalidad de poder estar localizado en ambientes
exteriores siempre y cuando haya cobertura GPS.
Modelo: A1084 (Vincotech)
Sensibilidad en movimiento: -159dBm
Sensibilidad de adquisición: -142dBm
Tiempo de arranque en caliente (Hot Start): <1s
Tiempo de arranque en templado (Warm Start): <32s
Tiempo de arranque en frío (Cold Start): <35s
Conector de antena: UFL
Antena externa: 26dBi

Capítulo 3: Análisis de Requisitos
74

Figura 33 – Módulo GPS
El módulo GPS aporta información sobre latitud, lon gitud, altura, velocidad, rumbo, fecha/hora
y efemérides.

El receptor GPS utiliza la UART_1 para comunicarse con el microcontrolador, compartiendo
dicha UART con el módulo GPRS. Dado que los 2 módul os comparten esta UART se ha
habilitado un multiplexor con el fin de poder selec cionar el módulo con el que nos queremos
comunicar en cada momento. Esto no es un problema p uesto que como todas las acciones
son secuenciales por haber un único microprocesad or en la práctica sí existe disponibilidad en
paralelo a los 2 dispositivos.

El módulo GPS arranca por defecto a 4800bps, aunque esta velocidad puede ser variada a
demanda del desarrollador. El receptor GPS tiene 2 modos de funcionamiento: modo NMEA
(National Marine Electronic Association) y modo bi nario.

El modo NMEA utiliza sentencias de este estándar p ara obtener la localización, hora y fecha. El
modo binario se basa en el envío de tramas estructu radas para establecer la comunicación
entre el microcontrolador y el receptor GPS.

Dependiendo de la información que posea almacenada el receptor GPS, se pueden dividir los
arranques en varios tipos:

• Arranque en caliente (HOT START): arranque teniendo establecida la hora, fecha y
teniendo en memoria las efemérides y almanaques vál idos. Tiempo : <1s
• Arranque en templado (WARM START): arranque teniend o establecida la hora, fecha y
teniendo en memoria los almanaques válidos. Tiempo: <32s
• Arranque en frío (COLD START): arranque sin tener e stablecido ni hora, ni fecha, ni
almanaques o efemérides. Tiempo: <35s
Se observa que no son despreciables las disminucion es de los tiempos de arranque entre los
distintos modos de funcionamiento, por lo que es mu y aconsejable que el receptor GPS
almacene cierta información con vistas a futuro. La información que se puede conocer es
relativa a la posición actual de los satélites (efe mérides) o la trayectoria que van a seguir en los
próximos días (almanaques). Los almanaques indican la trayectoria que van a seguir los
satélites durante los próximos días, teniendo una v alidez de unos 2-3 meses. Las efemérides
indican la posición actual de los satélites y tiene n una validez de unas 3-5 horas.

75

Capítulo 4
Escenario de Validación

Capítulo 4: Escenario de Validación
76
4.1 Escenario del demostrador

El escenario en el que se realizará el demostrador para validar la tecnología desarrollada, se
localiza en el municipio de Alcorcón. Concretamente en el barrio residencial de La Princesa,
que cuenta con las características necesarias para llevar a cabo las tareas de demostración.
Se ha seleccionado un entorno que cuenta con baja d ensidad de tráfico rodado con la finalidad
de poder realizar todos los ensayos y ajustes que s ean necesarios sin tener que ralentizar
dichas tareas a causa del aumento del volumen del t ráfico.
La zona elegida para el demostrador contiene un cru ce de calles con zona de aparcamientos
adyacentes, permitiendo así la instalación de los e quipos necesarios en esas zonas. A
continuación se muestra un gráfico descriptor del e scenario:

Figura 34 – Vista GoogleMaps del entorno del demostrado r
Se aprecia que la intersección está compuesta por l as calles de la Diversidad y Gabriela Mistral.
El escenario del demostrador cuenta con 3 zonas de aparcamientos bien diferenciadas, las
cuales se han caracterizado con las coordenadas GPS de sus límites. Esta acción ha servido
para dar a conocer a las motas que controlarán cada una de esas zonas los mensajes que
provienen de los vehículos aparcados que deben aten der, desestimando cualquier mensaje
que les pueda llegar de un vehículo ajeno a su zona de control.

Capítulo 4: Escenario de Validación
77

Figura 35- Vista del demostrador. Izda: Oeste-Este. Dch a: Norte-Sur
La mota encargada del control de cada zona de aparc amiento, atenderá los mensajes que
provienen de los vehículos de su zona controlada, y enviará un paquete de datos al
coordinador de la red con el fin de actualizar la t abla de ocupación general con la situación de
cada aparcamiento.
La mota coordinadora será la encargada de recibir l os paquetes de datos de los Router de cada
zona de aparcamientos próxima, actualizando automát icamente la tabla de ocupación y
enviando la situación de la misma al sistema de vis ualización de datos por parte de los
conductores.
Cada zona de aparcamientos se ha dimensionado para albergar un número de coches
suficientes y razonable para lograr la demostración de la tecnología, sabiendo que la única
limitación de ello es la distancia entre la mota em barcara en el vehículo y la mota controladora
de cada zona de aparcamiento.
En concreto, las zonas de aparcamiento controladas se constituyen en una extensión de
1800m 2 y se distribuyen de la siguiente manera:
Calle Número de plazas
Zona Parking 1 De la Diversidad (izda) 5
Zona Parking 2 Gabriela Mistral 5
Zona Parking 3 De la Diversidad (dcha) 5
Tabla 1- Distribución de plazas de aparcamiento por calle
4.1.1 Definición de requisitos del demostrador
El entorno demostrador contiene una serie de condic ionantes que son necesarios para el buen
funcionamiento de la tecnología. Es decir, no se pu ede encontrar una localización
aleatoriamente y poner a funcionar el sistema insta ntáneamente. Sería necesario realizar una

Capítulo 4: Escenario de Validación
78
serie de trabajos previos a la instalación para alc anzar los objetivos propuestos, se detallan a
continuación:
– Estudio de viabilidad (cobertura GPS, distancias, e tc.).
– Caracterización de zonas de aparcamientos.
– Programación de los equipos controladores de zona.
– Instalación de equipos.
4.1.2 Estudio de viabilidad (cobertura GPS, distanc ias, etc.)
Se pretende que esta tecnología pueda ser utilizada en el 100% de la superficie de cualquier
ciudad, pero es prácticamente imposible realizar es a acción. Como punto fundamental, sólo
puede instalarse en zonas donde exista cobertura GP S, ya que de lo contrario sería muy difícil
determinar la zona en la que se encuentra un vehícu lo. Se podrían dar zonas aproximadas,
pero nunca con la certeza necesaria para determinar si se encuentra en una zona concreta de
aparcamiento o en otra, ya que se puede medir la di stancia de un nodo embarcado en un
vehículo al nodo controlador de aparcamiento según su nivel de señal, pero eso otorga una
medida que puede ser errónea.
Paralelamente es necesario que las distancias a cub rir no excedan de los límites que son
capaces de cubrir las motas mediante su comunicació n por radiofrecuencia.
La distancia máxima entre motas con el protocolo Di gimesh, es de 30 metros. Por lo tanto las
distancias máximas entre nodos, corresponden con es as distancias máximas, ya que de lo
contrario se perderían paquetes y se desestructurar ía la lista de aparcamientos disponibles.
4.1.3 Caracterización de zonas de aparcamientos.
La caracterización de la zona de aparcamientos es f undamental para el correcto
funcionamiento del sistema, ya que de lo contrario las motas encargadas del control de cada
aparcamiento, no tendrían información acerca de los límites que deben controlar.
Para realizar esta caracterización se toman las cot as externas del aparcamiento y si un vehículo
realiza una petición de alta en el sistema, se comp rueba la zona de aparcamiento a la que
pertenece y a continuación, si es posible, se reali za la actualización de la tabla.

Capítulo 4: Escenario de Validación
79
El resultado de la caracterización arroja lo siguie nte:

Figura 36 – Caracterización de las coordenadas de cada zona de aparcamiento.
Tras la caracterización de cada zona de aparcamient o, es necesario extraer la latitud y la
longitud máxima y mínima que serán utilizadas en la s motas tipo router para conocer los
límites de las zonas a supervisar. Son las siguient es:

Latitud Máx. Latitud Mín. Longitud Má x. Longitud Mín.
Zona 1 6446 6306 6245 6137
Zona 2 6590 6490 6040 5920
Zona 3 6456 6330 5806 5730
Tabla 2 – Cotas máximas y mínimas de latitud y longitud po r zona de aparcamiento

4.1.4 Programación de los equipos controladores de zona.
Con las zonas de aparcamiento caracterizadas, es ne cesario realizar una programación de cada
mota controladora de aparcamiento debido al cambio de las coordenadas GPS a controlar.
Para una industrialización masiva del producto, ser ía muy conveniente poder realizar esta
acción sin tener que tocar nada de código, sino con algún tipo de aplicación mucho más
intuitiva para el usuario final

Capítulo 4: Escenario de Validación
80
4.1.4 Instalación de equipos.
Una vez que se tienen programados todos los equipos , sólo queda pendiente la tarea de la
instalación de los mismos. En cada vehículo sería m ediante algún sistema o bien embarcado de
serie o bien con un equipo supletorio, pero no habr ía que hacer una instalación muy acusada.
En la parte de los controladores de aparcamiento (R outer) simplemente bastaría con una
colocación en una posición que permitiera visión di recta con la zona a controlar, ya que todo lo
necesario se encuentra en la propia mota.
En la parte del controlador y del panel habría que hacer una pequeña actuación sobre el
mobiliario urbano, para dejar instalado el panel y embebida la mota controladora.

Figura 37 – Detalle de instalación de la mota router de la zona 1
La distribución de motas en todo el escenario demos trador ha sido la siguiente:
De izquierda a derecha: router zona 1, router zona 2, controlador, router zona 3.

Figura 38 – Distribución de motas en el escenario dem ostrador

Capítulo 4: Escenario de Validación
81
4.2 Validación

Ha habido una serie de ensayos que han ido creciend o paulatinamente en número de
dispositivos asociados.

El primero escoyo que ha habido que superar es la v elocidad de adquisición de coordenadas
GPS desde los End Devices. La frecuencia de adquisi ción definida por el fabricante de los
equipos es de 1 vez cada 30 segundos, claramente in suficiente para la aplicación definida en
este Proyecto Final de Carrera. Se realizó una vari ación en la librería del fabricante para
permitir hacer lecturas a frecuencias de 1 Hz, evit ando así almacenar posiciones erróneas en
las tareas de ocupación de plazas de aparcamiento.

Seguidamente se inició la comunicación End Device – Router, obteniendo buenos resultados
tanto en el envío de las tramas de datos, como en l a recepción de los paquetes de
asentimiento desde el Router hasta el End- Device.

Para continuar se añadió el controlador. Aquí surgi ó un gran problema, ya que comenzó a
haber duplicidades de paquetes circulando por la re d. Después de un estudio exhaustivo se
localizó el error, radicando en los tiempos de espe rar para recibir los paquetes de
asentimiento.

La secuencia original era la siguiente:

Donde:
1.- Solicitud de alta.
2.- Solicitud de inscripción en tabla.
3.- Asentimiento a 2.
4.- Asentimiento a 1.

Capítulo 4: Escenario de Validación
82
Esta secuencia fue modificada a la siguiente:

Donde:
1.- Solicitud de alta.
2.- Asentimiento a 1.
3.- Solicitud de inscripción en tabla.
4.- Asentimiento a 3.

Con esta modificación se solucionó que el End Devic e reenviara los paquetes de solicitud de
alta repetidamente al Router correspondiente por la ausencia del paquete de asentimiento.

Una vez corregida la problemática surgida, se fuero n sumando dispositivos a la red y al tratarse
de dispositivos gemelos a los ya existentes, no se encontraron nuevos problemas o fallos.

Los tiempos de respuesta son mínimos, resulta una a plicación prácticamente instantánea.
Únicamente se ve ralentizada por los tiempos defini dos en el código de los distintos
dispositivos para realizar esperas en el reconocimi ento del asentimiento de los equipos
destino.

No existe tiempo mínimo entre aparcamientos, ya que si dos vehículos aparcaran
prácticamente a la vez, el segundo vehículo volverí a a reenviar los mensajes de solicitud de
aparcamiento por no haber recibido los mensajes de asentimiento.

83

Capítulo 5
Conclusiones y Trabajos Futuros

Capítulo 5: Conclusión y Trabajos Futuros
84
5.1 Conclusiones

El funcionamiento del sistema ha resultado como se esperaba, detectando instantáneamente y
tras la pulsación del botón de ocupación de plaza p or el usuario. Se trata de un sistema que
permite identificar de un vistazo las calles que co ntienen más plazas de aparcamiento libres,
obtenido así una mayor fluidez del tráfico debido a la rápida toma de decisiones de los
conductores de los vehículos.
Resulta importante remarcar algunos errores encontr ados tales como:
– Dificultad en algunas ocasiones para recibir una s eñal GPS válida. Esto no se debe a la
mala cobertura de la localización del demostrador, sino a la mediocre calidad del
receptor GPS utilizado para esta prueba. Para solve ntar esta problemática se
recomienda el uso de una antena de calidad.
– Asimismo y con la misma fuente de error del punto a nterior, es interesante remarcar
la inestabilidad de la señal GPS recibida por las m otas, tanto a la hora de hacer las
mediciones de cada zona de aparcamiento como a la d e situar en un punto concreto a
los vehículos. El proceso de caracterización de zon as de aparcamiento ha debido
hacerse con minuciosidad en la toma de datos.
– Una vez en el entorno del demostrador real ha sido necesario modificar pequeñas
partes del código de las motas en referencia a la i ntroducción de retardos que hicieran
al programa ejecutarse más lentamente, ya que de lo contrario se perdían paquetes de
datos de forma desmedida.

Es interesante enunciar una serie de mejoras que se deberían añadir al proyecto para
conseguir un óptimo funcionamiento del mismo:

– Sería interesante eliminar la mano del hombre a la hora de seleccionar si se ocupa o se
abandona una plaza de aparcamiento, evitando así po sibles errores por la
equivocación o el sabotaje de ciertos usuarios. Com o alternativa se propone la
creación de un sistema de detección del estado del vehículo, determinando si ha
procedido a una ocupación o desocupación de una pla za de parking.
– Es vital para el correcto funcionamiento del sistem a que el rango de alcance de la señal
para los equipos embarcados sea amplio. Esto es así debido a que se han encontrado
ciertos problemas a la hora de realizar las pruebas de funcionamiento ya que

Capítulo 5: Conclusión y Trabajos Futuros
85
constantemente se ven muy reducidas las distancias de alcance que los fabricantes
anuncian para protocolos Digimesh u 802.15.4.
5.2 Impacto del Proyecto

Actualmente existen soluciones tecnológicas que pue den realizar la función del control de
aparcamientos en superficie, pero ninguna ha tenido una implantación real y productiva
debido, en gran medida, al escaso impacto que puede n llegar a lograr. Es por eso que con esta
alternativa se pretende aumentar ese nivel de impla ntación, pues se ha desarrollado un
impacto mucho mayor en 3 niveles: económico, social y ambiental. Para desarrollar este plan
de impacto, se ha tenido en cuenta diversa document ación [40] [41] [42] [43].
El impacto económico se divide en dos apartados dis tintos; el impacto económico directo, en
el que se analiza las ventajas económicas de los si stemas actuales frente al sistema propuesto,
y el impacto económico indirecto, en el que se anal izan las ventajas derivadas de la utilización
del sistema propuesto para el control de los aparca mientos de una ciudad.
En el impacto social se analizan las ventajas socia les que incluiría el sistema de control de
aparcamiento propuesto.
En el impacto ambiental se han analizado los benefi cios en términos de contaminación que
conllevaría la utilización del sistema propuesto en este Proyecto Final de Carrera.
5.2.1 Impacto Económico
Las soluciones aportadas hasta el momento por la in dustria, tienen unos costes desmesurados
en equipos, instalación y mantenimiento de los mism os, por lo que los números que ofrecen
no resultan del todo atractivos para las administra ciones. A continuación y tomando los datos
demográficos de la ciudad de Seattle, se analizan l os costes directos que habría que
presupuestar si se realizaran las obras de monitori zación de todas y cada una de las plazas de
aparcamiento en superficie existentes. Así mismo, s e compara con el sistema propuesto en
este Proyecto Final de Carrera:
Datos demográficos de Seattle (2010):
– Total población: 608.660 habitantes
– Total viviendas: 280.688 viviendas
– Total vehículos: 399.493 vehículos [44]
– Total plazas parking: 525.000 plazas

Capítulo 5: Conclusión y Trabajos Futuros
86
/square4 Estimación costes directos

Costes de los materiales a utilizar:
– Mota transmisora de datos + batería + sensor induct ivo : 240,00 €
– Mota transmisora de datos + batería: 165,00 €
– Mota transmisora de datos + Sensor GPS : 185,00 €

Con estos datos, se pueden hacer las siguientes est imaciones:

Método tradicional:
– Coste de sensorización de plazas de aparcamiento:
o 525.000 X 240,00 = 126.000.000€
– Coste de Routers:
o 13.125 X 165,00 = 2.165.625€
– Coste de Coordinadores:
o 3281 X 165,00 = 541.365€

– Total sistema tradicional: 128.706.990€
Método propuesto:
– Coste de sensorización de vehículos:
o 399.493 X 185,00 = 73.906.205€
– Coste de Routers:
o 13.125 X 165,00 = 2.165.625€
– Coste de Coordinadores:
o 3281 X 165,00 = 541.365€

– Total sistema propuesto: 76.613.195€

Capítulo 5: Conclusión y Trabajos Futuros
87

Figura 39 – Comparación de costes entre modelo actual y propuesto
Se llega a la conclusión de que si hubiera que moni torizar toda la ciudad de Seattle, habría un
ahorro bruto de 52.093.795€, o lo que es lo mismo, una reducción del presupuesto del 40.47%.
Además, hay que tener en cuenta que la gran diferen cia entre los dos sistemas, es la movilidad
de los sensores que recogen la ocupación de la plaz a de aparcamiento. Así, mientras en el
sistema tradicional el sensor es fijo, en el sistem a propuesto es móvil, lo que hace abaratar
mucho más los costes en muchos sentidos:
– Eliminación del cambio del sensor fijo por motivos de reasfaltado o rotura del vial
– Duplicidad de los sensores embarcados en los vehícu los y reutilización de ellos en otras
ciudades
– Eliminación del mantenimiento de las baterías en lo s sensores fijos
– Eliminación de costes de obra para la instalación d e los sensores fijo.

Con los números aportados y las reducciones de cost es asociados, queda claramente visto que
el sistema propuesto en este Proyecto Final de Carr era, es mucho más ventajoso
económicamente hablando que cualquier tecnología ex istente.
/square4 Estimación costes indirectos
A los costes directos, hay que sumar el ahorro econ ómico que supone la implantación de la
tecnología descrita. Y es que en el Anuario estadís tico de Movilidad publicado por el
Ayuntamiento de Madrid en 2012 se contabilizan una media de 2.388.351 desplazamientos en
vehículo privado al cabo de un día laborable.
Si es estima que 1.200.000 de esos vehículos se dir igen de un punto a otro de la ciudad sin un
aparcamiento predefinido y que ese 1.200.000 dedica n una media de 3 minutos diarios a la
búsqueda activa de una plaza de aparcamiento, se ob tiene una media de 3.600.000 minutos

Capítulo 5: Conclusión y Trabajos Futuros
88
diarios perdidos por todos los madrileños buscando aparcamiento, o lo que es lo mismo
60.000 horas es lo que dedican a diario los madrile ños para buscar una plaza de aparcamiento
disponible.
Si se prosigue con la estimación de una velocidad m edia de búsqueda de aparcamiento de 20
km/h, se obtiene como resultado la cantidad de 1.20 0.000 kilómetros diarios en el proceso de
búsqueda de aparcamiento. Conjuntamente con estos d atos y sabiendo que el gasto medio de
combustible de un vehículo a esa velocidad es de 5 litros cada 100 kilómetros, se obtiene una
cantidad de 60.000litros de combustible que se podr ían ahorrar. Multiplicando el precio del
litro de combustible (1.30€), se obtiene que se pod rían ahorrar 78.000 Euros diariamente en
combustible, lo que al año significa la nada despre ciable cantidad de 28.470.000 Euros.
Hay que tener en cuenta que los datos vertidos son muy benévolos, ya que no se ha tenido en
cuenta para el cálculo (por su complicada forma de medición) el atasco producido por los
vehículos en actividad de búsqueda de aparcamiento y que afectan al resto de usuarios de la
vía.
5.2.2 Impacto Ambiental
Bien es sabido por todas las personas que la contam inación que producen los vehículos es muy
abundante y para un mismo recorrido, la aumenta seg ún se producen retrasos en la llegada al
destino. Estos retrasos son fundamentalmente produc idos por los atascos de las ciudades.
En un estudio realizado en 2003 por el RACC [45] se contabilizó un aumento de un 74% en la
cantidad de contaminantes vertidos por el mismo veh ículo en el mismo recorrido, con la única
salvedad de la hora a realizar el estudio. En ausen cia de atascos, el recorrido se hacía en
mucho menos tiempo, lo que se traduce en menos cont aminación:

Figura 40 – Ilustración de la prueba realizada en 2003 por el RACC

Capítulo 5: Conclusión y Trabajos Futuros
89
Tomando como base los datos de kilómetros realizado s en tareas de búsqueda de
aparcamiento, se ha comprobado que diariamente en M adrid, se llegan a realizar una media
de 1.200.000 kilómetros, lo que unido a los 159 gr/ km de CO 2 que produce un vehículo de
medianas dimensiones (Citroën C4 120cv), desvela un a contaminación diaria de 190.800
toneladas diarias de CO 2 extras que se vierten a la atmósfera.
Al año sumarían una cantidad de 69.642.000 de tonel adas de CO 2 cantidad nada despreciable y
que se podría reducir en gran medida si se aplicara n métodos de control de aparcamiento
sobre la ciudad de Madrid.
5.2.3 Impacto social
En el apartado de impacto económico se ha analizado que se pierden en Madrid 3.600.000
minutos diarios (60.000 horas) mientras se busca ap arcamiento.
En ese tiempo se producen incontables sensaciones d e cansancio, ansiedad y estrés. Además,
se deja de prestar la atención necesaria para la co nducción, produciéndose pequeños
accidentes o atropellos que a menudo no son de gran envergadura, pero pueden llegar a
producir graves daños a las víctimas.
Además, se eliminan ruidos de las calles, aumento d e la sensación de bienestar y mejora de las
condiciones de vida.
5.3 Trabajos Futuros

Este Proyecto Final de Carrera no es en sí una solu ción terminada de cómo encauzar el tráfico
rodado en búsqueda de aparcamiento, sino que es un desarrollo de la tecnología principal para
desarrollar el sistema al completo.
Para lograr un sistema totalmente funcional, se pre vén una serie de actuaciones para
complementar la técnica y hacer una aplicación atra ctiva para ser implementada. Entre estas
actuaciones se encuentran las siguientes:
Aplicación para SmartPhone que indique el camino a seguir para alcanzar plaza de
aparcamiento libre.
Con el gran aumento de la utilización de los SmartP hones entre el público en general, se antoja
atractivo el desarrollo de una aplicación tanto iOS como Android que sirva de guiado hasta la
plaza de aparcamiento libre más cercana. Habría que realizar un protocolo de comunicaciones
tipo TPC/IP con el controlador de la zona de aparca miento seleccionada para así tener un
punto de origen y un punto de destino claro.

Capítulo 5: Conclusión y Trabajos Futuros
90
A través de las APIs de Google Maps sería muy senci llo llegar a mostrar el camino a seguir.
Eliminación de la mota del vehículo y sustituirla p or el Smartphone del usuario, para ahorrar
costes, problemas de entrada a la tecnología, etc.
En la parte del vehículo, se ha utilizado una Waspm ote junto con un módulo GPS. Esto ha sido
así porque se ha visto que era lo más idóneo para d emostrar la validez de la tecnología. Aún
así, hay que admitir que para lograr una total expa nsión de la misma, sería conveniente
eliminar este sobre coste y la mejor manera de hace rlo, es sustituir esa mota por un
SmartPhone, que dispone de GPS y distintos protocol os de datos para comunicarse con la
infraestructura fija creada en las zonas de aparcam iento.
Creación de aplicación de toma de datos para la con figuración de las zonas de aparcamientos
y no tener que modificar el código de las motas dir ectamente.
Como se ha visto apartados anteriores, para que la tecnología sea totalmente funcional, ha de
modificarse el código de las motas tipo Router para adecuarlas a las zonas de control de
aparcamiento que supervisen. Esta metodología no es funcional para la distribución de la
tecnología, pues ha de ser mano de obra cualificada la que realice la tarea, con el consiguiente
aumento de coste.
Es razonable que exista una aplicación que mediante comandos de configuración a través de
una interfaz gráfica, permita la adecuación del cód igo de las motas, eliminando toda tarea de
modificar el código fuente de las mismas.

Anexos

Anexos
Anexo 1: Código fuente motas
Código de los End Device
/************************************************** ****************
* Código fuente: End_device; Autor: David Herrador Muñoz; Año: 2013 *
************************************************** ****************/
packetXBee* paq_sent;
// paquete para ser enviado
long previous = false; // estado previo de la mota
int8_t state = false; // estado actual de la mota
char* macHigh = " "; // parte alta de la MAC de la mota
char* macLow = " "; // parte baja de la MAC de la mota
char* latitude = "EEEE.EEEE"; // latitud
char* longitude = "EEEEE.EEEE"; // longitud
char* datos_envio; // buffer para paquetes recibidos
boolean reenviar = false;
// flag de reenvío
boolean ACK_recibido = false; // flag de ACK
boolean ocupado = false; // ocupación de la mota
char* solicitud = " "; // solicitud que realiza la mota
char* estado = "B"; // estado actual de la mota
boolean paquete_preparado = false; // paquete preparado para envío
uint8_t direccionBROADCAST[8]={0x00,0x00,0x00,0x00, 0x00,0x00,0xFF,0xFF};
//dirección genérica de BROADCAST

93
void setup(){ XBee.setMode(XBEE_ON);
// Inicialización de XBee
XBee.begin(9600); XBee.setMode(XBEE_OFF); XBee.close(); xbeeDM.init(DIGIMESH,FREQ2_4G,NORMAL);
// Inicialización de la Librería DIGIMESH
xbeeDM.ON(); // Habilitación XBee
delay(500); int counter = 0; while(xbeeDM.getOwnMac()==1&&counter<4){
// Obtención MAC del dispositivo
xbeeDM.getOwnMac(); counter++; } Utils.hex2str(xbeeDM.sourceMacHigh,macHigh,4); Utils.hex2str(xbeeDM.sourceMacLow,macLow,4); GPS.ON();
// Habilitación GPS

while( !GPS.check() ) delay(1000); //Espera de conexión de GPS
pinMode(DIGITAL1,OUTPUT);
//Declaración del pin1 como salida digital
pinMode(DIGITAL2,INPUT); //Declaración del pin 2 como entrada digital
pinMode(DIGITAL8,INPUT); //Declaración del pin 8 como entrada digital
digitalWrite(DIGITAL1, HIGH);
//Activación de pin1 con Pull-up
}

94
void loop() {
if (ocupado == false)
/////////////////////////////////////////////////// /////////
{ // Si la mota no está ocupada, obtiene posición GPS //
latitude=GPS.getLatitude(); // continuamente. //
longitude=GPS.getLongitude(); // //
} /////////////////////////////////////////////////// ////////
if (digitalRead(DIGITAL8) && ocupado == fal se)
/////////////////////////////////////////////////// /////////////////
{ // Si se decide ocupar una plaza, se envía //
strncpy(solicitud, "A", 1); // una petición de alta. //
} /////////////////////////////////////////////////// /////////////////
else if (digitalRead(DIGITAL2) && ocupado = = false) /////////////////////////////////////////////////// /////////////////
{ // Si se decide liberar una plaza, se envía / /
strncpy(solicitud, "B", 1); // una petición de baja. //
} /////////////////////////////////////////////////// /////////////////
if(ocupado == false && strncmp(solicitud, " ", 1) != 0)
// Si mota no ocupada y hay solicitud de cualquier tipo, entonces…
{ ocupado = true;
// Se modifica el estado de la mota a “ocupado”
paquete_preparado = false; // Se indica que no hay paquete de envío preparado
if (strncmp(solicitud, "A", 1) == 0) // Si la solicitud existente es de ”ALTA”, entonces …
{ if(strncmp(estado, "B", 1) == 0)
// Se comprueba que el estado anterior fuera de “BA JA”
{ datos_envio = (char *) malloc(3 6*sizeof(char));
sprintf(datos_envio,"%s%s%s%sA" ,macHigh,macLow,latitude,longitude);
// Se forma el paquete con los datos apropiados
paquete_preparado = true; // Se etiqueta como “paquete preparado” para utiliz arlo más adelante
} }

95
else if (strncmp(solicitud, "B", 1) == 0) // Si la solicitud existente es de ”BAJA”, entonces …
{ if(strncmp(estado, "A", 1) == 0)
// Se comprueba que el estado anterior fuera de “AL TA”
{ datos_envio = (char *) malloc(1 7*sizeof(char));
sprintf(datos_envio,"%s%sB",mac High,macLow);
// Se forma el paquete con los datos apropiados
paquete_preparado = true; // Se etiqueta como “paquete preparado” para utiliz arlo más adelante
} } if(paquete_preparado == true)
// Si hay paquete preparado para enviar, entonces…
{
paq_sent=(packetXBee*) malloc(sizeof(packetXBee)); // Se reserva memoria para el paquete de datos
paq_sent->mode=BROADCAST; // Inicialización de parámetros de envío
paq_sent->packetID=0x52; paq_sent->opt=0; xbeeDM.setOriginParams(paq_sent,MAC_TYPE); xbeeDM.setDestinationParams(paq_sent, direccionBROA DCAST, datos_envio, MAC_TYPE, DATA_ABSOLUTE);
xbeeDM.sendXBee(paq_sent); ACK_recibido = false;
// se marca como ACK no recibido para realizar la e spera del mismo
} else { ocupado = false;
// Se deja todo en estado inicial
strncpy(solicitud, " ", 1); } }
//if(ocupado == false && strncmp(solicitud, " ", 1) != 0)
else if (reenviar == true)
// Si fuera necesario reenviar el paquete de datos, entonces…
{ xbeeDM.setOriginParams(paq_sent,MAC_TYP E);
xbeeDM.setDestinationParams(paq_sent, d ireccionBROADCAST, datos_envio, MAC_TYPE, DATA_ABSO LUTE);
xbeeDM.sendXBee(paq_sent);
// Se envía

96
reenviar = false; } if(ACK_recibido == false && strncmp(solicit ud, " ", 1) != 0)
//Si no se ha recibido ACK y existe algún tipo de s olicitud, entonces…
{ previous=millis(); while((millis()-previous) < 3000 && ACK _recibido == false)
// Espera la llegada del paquete ACK de asentimient o durante 3 segundos
{ if(XBee.available())
// Se comprueba si hay paquetes disponibles
{ xbeeDM.treatData();
// Se procesa el paquete
if( !xbeeDM.error_RX ) // Si no hay errores al procesar el paquete
{ while(xbeeDM.pos>0) { char *datos_recepcion = ( char*)malloc(xbeeDM.packet_finished[xbeeDM.pos-1]-> data_length);
////////////////////////////////////////////////// ///
for(int f=0;f<xbeeDM.pack et_finished[xbeeDM.pos-1]->data_length;f++) // Se reserva memoria del tamaño del paquete //
{ // recibido y se copia el contenido del mismo //
datos_recepcion[f] = xbeeDM .packet_finished[xbeeDM.pos-1]->data[f]; // a la variable “datos_recepcion” //
} /////////////////////////////////////////////////// //
if(strncmp(datos_recepcio n, "ACK", 3) == 0 && strncmp(datos_recepcion+3, mac High, 8) == 0 && strncmp(datos_recepcion+11, macLow , 8) == 0)
{ ACK_recibido = true;
/////////////////////////////////////////////////// /////
ocupado = false; // Si el paquete recibido tiene el formato: //
strncpy(estado, solicitu d, 1); // ACK+MAC_End_Device //
strncpy(solicitud, " ", 1); // //
reenviar = false; // Se asocial el estado a la solicitud y se //
free(paq_sent); // deja la mota en “libre” para otros traba jos //
free(datos_envio); /////////////////////////////////////////////////// /////

paquete_preparado = f alse;
XBee.print("ACK recib ido");

97
} free(datos_recepcion); free(xbeeDM.packet_finish ed[xbeeDM.pos-1]);
xbeeDM.packet_finished[xb eeDM.pos-1]=NULL;
xbeeDM.pos–; }
// Liberación de buffer de datos de recepción
} //if
} //if
} //while
if(ACK_recibido == false)
// Si después del tiempo de espera, no ha recibido asentimiento, entonces…
{ reenviar = true;
// Se activa la variable “reenviar” para volver a e nviar el paquete
}
} //else
delay(1000); }
//loop

98
Código de los Router
/************************************************** *************
* Código fuente: Router; Autor: David Herrador Muñ oz; Año: 2013 *
************************************************** *************/
packetXBee* paq_sent; char *MAC = " ";
// MAC del ED
char* macHigh = " "; // Parte alta MAC propia
char* macLow = " "; // Parte baja MAC propia
long previous = 0; char *latitud = " "; char *longitud = " "; char *latitud_aux = " "; char *longitud_aux = " "; int latitud_int; int longitud_int;
//variables para las cuenta de zonas
int j; // Variable recorrido de matriz
int k; // Variable recorrido de matriz
char *solicitud = " "; //Variable solicitud alta o baja
int enviar_ACK = 0; // control de ACK
char *texto_ACK = "ACK"; //inicio del paquete ACK
char *paqueteACK = " "; //reserva paquete ACK
char *datos_envio; char *direccion = "Gabriela";
// Nombre de la calle a controlar
char *estado = " "; // estado
int latitud_maxima= 6590;
// Definición de los límites a controlar
int latitud_minima= 6490; int longitud_maxima= 6040; int longitud_minima= 5920;

99
boolean ACK_recibido = true; //Variable control ACK
boolean ocupado = false; //Variable control ocupación
boolean reenviar = false; //Variable control reenvio
uint8_t direccionBROADCAST[8]={0x00,0x00,0x00,0x00, 0x00,0x00,0xFF,0xFF};

100
void setup() { xbeeDM.init(DIGIMESH,FREQ2_4G,NORMAL);
// Inicialización de librería DIGIMESH
xbeeDM.ON();
// Activa XBee
int counter = 0; // Obtención MAC propia
while(xbeeDM.getOwnMac()==1&&counter<4){ xbeeDM.getOwnMac(); counter++; } Utils.hex2str(xbeeDM.sourceMacHigh,macHigh,4); Utils.hex2str(xbeeDM.sourceMacLow,macLow,4); }

101
void loop() {
if(ocupado == false)
// Si la mota no está ocupada, entonces recibimos p aquete…
{
if(xbeeDM.available() > 0) // Se comprueba si hay paquetes disponibles
{ ocupado = true; xbeeDM.treatData();
// Se procesa el paquete
if(!xbeeDM.error_RX) // Si no hay errores al procesar el paquete, entonc es…
{
while(xbeeDM.pos>0)
{ char *datos = (char*)malloc(xbeeDM.pack et_finished[xbeeDM.pos-1]->data_length);
// Se crea variable del tamaño del paquete
for(int f=0;f<xbeeDM.packet_finishe d[xbeeDM.pos-1]->data_length;f++) // Desde el inicio del paquete recibido hasta el fi nal del mismo…
{ datos[f] = xbeeDM.packet_finished [xbeeDM.pos-1]->data[f];
// Se copia todo el contenido en la variable creada
}
if(datos[16] == 'B') // Si el paquete es una solicitud de baja, entonces ….
{
strncpy(MAC, datos, 16); // Se extrae la MAC para tratar posteriormente
strncpy(solicitud, datos+16, 1); // Se extrae el tipo de solicitud para tratar poste riormente
enviar_ACK = 1; // Se solicita envío de ACK hacia End_device
estado = "B"; // Se inicializa a BAJA el estado para enviarlo al controlador
} else if(datos[16] != 'E')
// Si no, si no hay error, es que es solicitud de A LTA, por lo tanto…
{ strncpy(MAC, datos, 16);
// Se extrae la MAC para tratar posteriormente
strncpy(latitud, datos+16, 9); // Se extrae la latitud para tratar posteriormente
strncpy(longitud, datos+25, 10); // Se extrae la longitud para tratar posteriormente
strncpy(solicitud, datos+35, 1); // Se extrae el tipo de solicitud para tratar poste riormente
enviar_ACK = 1; // Se solicita envío de ACK hacia End_device
estado = "A"; // Se inicializa a ALTA el estado para enviarlo al controlador

102
for (j=0;j<9;j++) /////////////////////////////////////////////////// /////
{ // //
latitud_aux[j] = latitud [j+5] ; // //
latitud_int = atoi(latitud_aux ); // //
} // Transformación de las //
// variables a tipo entero //
for (k=0;k<10;k++) // para el cálculo de zonas //
{ // //
longitud_aux[k] = longitud [k+ 6]; // //
longitud_int = atoi(longitud_a ux); // //
} /////////////////////////////////////////////////// /////
} if(enviar_ACK == 1)
//Si hay que enviar un ACK, entonces…
{ sprintf(paqueteACK,"%s%s",texto_A CK,MAC);
//formatea el paquete ACK con las variables mencion adas
paq_sent=(packetXBee*) calloc(1,sizeof(pack etXBee)); // Se reserva memoria para el paquete de datos
paq_sent->mode=BROADCAST; // Inicialización condiciones de envío
paq_sent->packetID=0x52; paq_sent->opt=0;
xbeeDM.setOriginParams(paq_s ent,MAC_TYPE);
xbeeDM.setDestinationParams(paq_sent, direccionB ROADCAST, paqueteACK, MAC_TYPE, DATA_ABSOLUTE);

xbeeDM.sendXBee(paq_sent);
// Se envía el paquete
free(paq_sent); paq_sent = NULL;
enviar_ACK = 0; ocupado = false; } free(xbeeDM.packet_finished[xbeeDM. pos-1]);
xbeeDM.packet_finished[xbeeDM.pos-1 ]=NULL;
xbeeDM.pos–;

103
free(datos); if( ((latitud_int<latitud_maxima)&& (latitud_int>latitud_minima)&&(longitud_int<longitu d_maxima)&&(longitud_int>longitud_minima)&&strncmp( estado,"A",1)==0))
{ datos_envio = (char*) calloc(35+strlen(direccion), sizeof(char));
// Se reserva espacio de memoria para la variable a enviar al controlador
ocupado = true;
if(strlen(direccion) < 10) ////////////////////////////////////////////////
{ // Si el nombre de la calle contiene //
sprintf(datos_envio, "%s0%d%s% s%s%s", estado, strlen(direccion), direccion, macHi gh, macLow, MAC); // menos de 10 caracteres… //
} ////////////////////////////////////////////////
Else { sprintf(datos_envio, "%s%d%s%s%s% s", estado, strlen(direccion), direccion, macHigh, macLow, MAC);
} paq_sent=(packetXBee*) calloc(1,s izeof(packetXBee));
// Se reserva memoria para el paquete de datos
paq_sent->mode=BROADCAST; // Se selecciona el modo de difusión Broadcast
paq_sent->packetID=0x52; // Inicialización condiciones de envío
paq_sent->opt=0; paq_sent->MY_known=0; xbeeDM.hops=0; xbeeDM.setOriginParams(paq_sent,M AC_TYPE);
xbeeDM.setDestinationParams(paq_s ent, direccionBROADCAST, datos_envio, MAC_TYPE, DAT A_ABSOLUTE);
xbeeDM.sendXBee(paq_sent); ACK_recibido = false; }
else if(strncmp(estado,"B",1) == 0)
//Si se ha solicitado una BAJA, entonces…
{ datos_envio = (char*) calloc(33, sizeof(char));
//Se reserva memoria para el paquete a enviar
ocupado = true;
sprintf(datos_envio, "%s%s%s%s", es tado, macHigh, macLow, MAC);

104
paq_sent=(packetXBee*) calloc(1,sizeof(packetXBee)) ; // Se reserva memoria para el paquete de datos
paq_sent->mode=BROADCAST; // Se selecciona el modo de difusión Broadcast
paq_sent->packetID=0x52; // Inicialización condiciones de envío
paq_sent->opt=0; paq_sent->MY_known=0; xbeeDM.hops=0; xbeeDM.setOriginParams(paq_sent,M AC_TYPE);
xbeeDM.setDestinationParams(paq_s ent, direccionBROADCAST, datos_envio, MAC_TYPE, DAT A_ABSOLUTE);
xbeeDM.sendXBee(paq_sent); ACK_recibido = false; } }
// while(xbeeDM.pos>0)
} // if(!xbeeDM.error_RX)
} // if if(xbeeDM.available() > 0)
} //if(ocupado == false)
else if(reenviar == true) // Si hubiera que reenviar el paquete, entonces…
{
xbeeDM.setOriginParams(paq_sent,MAC_TYPE);
xbeeDM.setDestinationParams(paq_sent, direccio nBROADCAST, datos_envio, MAC_TYPE, DATA_ABSOLUTE);
xbeeDM.sendXBee(paq_sent); reenviar = false; } if(ACK_recibido == false)
// Si no se ha recibido el ACK desde el controlador , entonces se espera…
{
previous=millis(); while((millis()-previous) < 3000)
// Espera la llegada del paquete ACK de asentimient o durante 3 segundos
{ if(XBee.available())
// Se comprueba si hay paquetes disponibles
{ xbeeDM.treatData();
// Se procesa el paquete
if( !xbeeDM.error_RX ) // Si no hay errores al procesar el paquete
{ while(xbeeDM.pos>0)

105
{ char *datos_recepcion = (char*)mal loc(xbeeDM.packet_finished[xbeeDM.pos-1]->data_leng th);
////////////////////////////////////////////////// ///
for(int f=0;f<xbeeDM.p acket_finished[xbeeDM.pos-1]->data_length;f++) // Se reserva memoria del tamaño del paquete //
{ // recibido y se copia el contenido del mismo //
datos_recepcion[f] = xbe eDM.packet_finished[xbeeDM.pos-1]->data[f]; // a la variable “datos_recepcion” //
} /////////////////////////////////////////////////// //
if(strncmp(datos_recepcion, "ACK", 3)==0 && s trncmp(datos_recepcion+3, macHigh, 8) == 0 && strnc mp(datos_recepcion+11, macLow, 8) == 0)
{ ACK_recibido = true;
////////////////////////////////////////////
ocupado = false; // Si el paquete recibido tiene //
reenviar = false; // el formato: //
free(paq_sent); // ACK+MAC end device, se ha //
free(datos_envio); // recibido correctamente //
paq_sent = NULL; ////////////////////////////////////////////
} free(datos_recepcion); free(xbeeDM.packet_finished[xbeeDM .pos-1]);
xbeeDM.packet_finished[xbeeDM.pos- 1]=NULL;
xbeeDM.pos–; }
// while(xbeeDM.pos>0)
} // if( !xbeeDM.error_RX )
} //if if(XBee.available())
} //while
if(ACK_recibido == false)
// si después de la espera, sigue sin recibirse el ACK, se vuelve a reenviar el paquete al controlador
{ reenviar = true;
// Se activa variable para volver a enviar el paque te al controlador de la red
}
} // else*/
delay(1000);
} //loop

106
Código del Controlador
/************************************************** *************
* Código fuente: controlador; Autor: David Herrado r Muñoz; Año: 2013 *
************************************************** *************/
char *MACvacia = " ";
// Declaración de MAC
char *mensajeInterfaz = (char*) calloc(14, sizeof(c har)); // mensaje enviado al panel
typedef struct{ char direccion[100]; int plazas_libres; char* MAC_aparcadas[5]; }Tabla_direccion; Tabla_direccion dir1 = { "Diversidad izda", 5, { (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)) } }; Tabla_direccion dir2 = { "Gabriela", 5, {

107
(char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)) } }; Tabla_direccion dir3 = { "Diversidad dcha", 5, { (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)), (char *)calloc(16,sizeof(char)) } }; Tabla_direccion direcciones[3] = { dir1, dir2, dir3 }; char* MAC_router;
// MAC router
char* MAC_ED; // MAC ED
char* direccion_ED; // Dirección del router
char* solicitud = "N"; // Tipo de solicitud, alta o baja
char* texto_ACK = "ACK"; // inicio del paquete de asentimiento

108
packetXBee* paq_sent; char *paqueteACK = " ";
// reserva de memoria del paquete de asentimiento
char* macHigh = " "; // parte alta de la MAC propia
char* macLow = " "; // parte baja de la MAC propia
boolean MAC_existe = false; // existe MAC definida o no
int indice1, indice3; boolean encontrada_posicion = false;
//si MAC encontrada den tablas
boolean enviar_ACK = false; //variable de control de envío de ACK
uint8_t direccionBROADCAST[8]={0x00,0x00,0x00,0x00, 0x00,0x00,0xFF,0xFF};
void setup() { xbeeDM.init(DIGIMESH,FREQ2_4G,NORMAL);
// inicialización de la librería DIGIMESH
xbeeDM.ON();
// habilitación de Xbee
int counter = 0;
// Obtención de MAC propia
while(xbeeDM.getOwnMac()==1&&counter<4){ xbeeDM.getOwnMac(); counter++; } Utils.hex2str(xbeeDM.sourceMacHigh,macHigh,4); Utils.hex2str(xbeeDM.sourceMacLow,macLow,4); for(int i=0; i<3; i++)
//inicialización de los char* de MAC_aparcadas y lo s deja como MAC en blanco
{ for(int j=0; j<5; j++) { strncpy(direcciones[i].MAC_aparcada s[j], MACvacia, 16);
} } }

109
void loop() {
if(XBee.available())
// Se comprueba si hay paquetes disponibles
{ xbeeDM.treatData();
// Se procesa el paquete
if( !xbeeDM.error_RX ) // Si no hay errores al procesar el paquete
{ while(xbeeDM.pos>0) {
char *datos = (char*)malloc(xbeeDM.packet_finished[ xbeeDM.pos-1]->data_length);
////////////////////////////////////////////////// ///
for(int f=0;f<xbeeDM.pac ket_finished[xbeeDM.pos-1]->data_length;f++) // Se reserva memoria del tamaño del paquete //
{ // recibido y se copia el contenido del mismo //
datos[f] = xbeeDM.packet_fi nished[xbeeDM.pos-1]->data[f]; // a la variable “datos” //
} /////////////////////////////////////////////////// //
strncpy(solicitud, datos, 1);
// Se extraen los datos de la solicitud

if(strncmp(datos, "ACK", 3) == 0)
{ strncpy(solicitud, "N" , 1);
// Si se recibe un paquete que empieza por ACK, no se le presta atención.
} if(strncmp(solicitud, "A", 1) == 0)
// Si se recibe un paquete que con una solicitud de alta, entonces…
{ char *aux = " "; int longitud_direccion = 0; strncpy(aux, datos+1 , 2);
longitud_direccion = atoi(aux); direccion_ED = (char*) calloc(longitud_ direccion, sizeof(char));
// Reserva memoria para almacenar direccion
MAC_router = (char*) calloc(16, sizeof( char)); // Reserva memoria para almacenar MAC_router
MAC_ED = (char*) calloc(16, sizeof(char )); // Reserva memoria para almacenar MAC_ED

110
strncpy(direccion_ED, datos+3, longitud _direccion);
// Se extrae el contenido de la dirección desde el paquete recibido
strncpy(MAC_router, datos+3+longitud_di reccion, 16); // Se extrae el contenido de la MAC_router desde el paquete recibido
strncpy(MAC_ED, datos+19+longitud_ direccion, 16); // Se extrae el contenido de la MAC_ED desde el paq uete recibido
sprintf(paquete ACK,"%s%s",texto_ACK,MAC_router);
/////////////////////////////////////////////////// /////
paq_sent=(packetXBee*) calloc(1, sizeof(packetXBee)); // //
paq_sent->mode=BROADCAST; // Se envía el paquete de asentimiento al router / /
paq_sent->packetID=0x52; // //
paq_sent->opt=0; // //
xbeeDM.setOriginParams(paq_sent, MAC_TYPE); // //
xbeeDM.setDestinationParams(paq_ sent, direccionBROADCAST, paqueteACK, MAC_TYPE, DAT A_ABSOLUTE); //
xbeeDM.sendXBee(paq_sent); // //
free(paq_sent); /////////////////////////////////////////////////// /////
int indice_busc ar1 = 0;
int indice_busc ar2 = 0;
while(indice_bu scar1 < 3 && MAC_existe == false)
// Se busca la MAC solicitante para evitar problema s de sobreescritura
{ indice_buscar2 = 0;
while(ind ice_buscar2 < 5 && MAC_existe == false)
{ if( strn cmp(direcciones[indice_buscar1].MAC_aparcadas[indic e_buscar2], MAC_ED, 16) == 0)
// MAC encontrada en la lista de elementos dados de alta
{ M AC_existe = true;
} in dice_buscar2++;
}
indice_bu scar1++;
}
if(MAC_existe == false)
// Si la direccion MAC no ha sido dada de alta prev iamente
{

111
indice1 = 0; encontrad a_posicion = false;
while(indice1 < 3 && encontrada_posicion == false)
{ if( strncmp(direcciones[indice1].direccion, direccion_ED, longitud_direccion) == 0 )
// Se encuentra la posición de la dirección recibid a
{ if(direcciones[indice1].plazas_libre s > 0)
// Si quedan plazas libres
{
for(int indice2 = 0; indice2 < 5 && encontrada_posi cion == false; indice2++) // recorre la matriz de MAC_aparcadas, buscando una posición libre
{
if( strncmp(direcciones[indice1].MAC_apar cadas[indice2], MACvacia, 16) == 0) //Si encuentra posición libre, escribe la MAC del E D en ella
{
strncpy(direcciones[indice1].MAC_aparcadas[indice2] , MAC_ED, 16);
direcciones[indice1].plazas_libres = direcciones[in dice1].plazas_libres – 1; // y se manda mensaje a interfaz
encontrada_posicion = true; strncpy(solicitud, "N", 1); sprintf(mensajeInterfaz, "PANTALLA,%d,%d,%d", direc ciones[0].plazas_libres, direcciones[1].plazas_libr es, direcciones[2].plazas_libres);
}
}
}
}
in dice1++;
}
} free(direccion_ED);
free(MAC_router) ;
free(MAC_ED);
}
else if(strncmp(solicitud, "B", 1) == 0)
{ MAC_router = (char*) calloc(16, sizeof( char));
// Reserva memoria para almacenar MAC_router

112
MAC_ED = (char*) calloc(16, sizeof(char)); // Reserva memoria para almacenar MAC_ED
strncpy(MAC_router, datos+1, 16); // Se extrae el contenido de la MAC_router desde el paquete recibido
strncpy(MAC_ED, datos+17, 16); // Se extrae el contenido de la MAC_ED desde el paq uete recibido

sprintf(paqueteACK,"%s%s",texto_ACK,MAC_router); /////////////////////////////////////////////////// /////
paq_sent=(packetXBee*) calloc(1, sizeof(packetXBee)); // //
paq_sent->mode=BROADCAST; // Se envía el paquete de asentimiento al router / /
paq_sent->packetID=0x52; // //
paq_sent->opt=0; // //
xbeeDM.setOriginParams(paq_sent, MAC_TYPE); // //
xbeeDM.setDestinationParams(paq_ sent, direccionBROADCAST, paqueteACK, MAC_TYPE, DAT A_ABSOLUTE); //
xbeeDM.sendXBee(paq_sent); // //
free(paq_sent); /////////////////////////////////////////////////// /////

indice1 = 0; indice3 = 0; encontrada_posicion = false; while(indice1 < 3 && encontrada_posicion == false) {
indice3 = 0; while(indice3 < 5 && encontrada_posicion == false)
{
if( strncmp(direcciones[indice1].MAC_aparcadas[indi ce3], MAC_ED, 16) == 0)
// MAC encontrada en la lista de elementos dados de alta
{
strncpy(direcciones[indice1].MAC_aparcadas[indice3] , MACvacia, 16); //Si encuentra posición, escribe la MAC vacía en el la
direcciones[indice1].plazas_libres = direcciones[in dice1].plazas_libres + 1;
encontrada_posicion = true; strncpy(solicitud, "N", 1);
} indice3++;
} indice1++;
}

113
if(encontrada_posicion == true) { sprintf(mensajeInterfaz, "PANTALLA,%d,%d,%d" , direcciones[0].plazas_libres, direcciones[1].plaz as_libres, direcciones[2].plazas_libres);
XBee.println("–––"); XBee.println(mensajeInterfaz);
} free(MAC_router); free(MAC_ED);
} free(datos); free(xbeeDM.packet_finished[xbeeDM.pos-1]); xbeeDM.packet_finished[xbeeDM.pos-1]=NULL; xbeeDM.pos–;
}
}
// error
} // available
delay(1000); }
// loop

114
Anexo 2: Código fuente panel

' ––––––––––––––– ––––––– Código adicional –––– ––––––––––––––––– –
Dim arrayCalle(16) As String Dim arrayControlador() Dim WithEvents com As IO.Ports.SerialPort = Not hing
Public Sub New() InitializeComponent() LeerSerialData() End Sub Public Sub prepararOcupacion()
//algoritmo de ocupación de calles
Dim i As Integer = 1 While (i < 6 – arrayControlador(1)) arrayCalle(i) = 1 i = i + 1 End While While (i < 6) arrayCalle(i) = 0 i = i + 1 End While While (i < 5 – arrayControlador(2) + 6) arrayCalle(i) = 1 i = i + 1 End While While (i < 11) arrayCalle(i) = 0 i = i + 1 End While

115
While (i < 5 – arrayControlador(3) + 11) arrayCalle(i) = 1 i = i + 1 End While While (i < 16) arrayCalle(i) = 0 i = i + 1 End While i = 0 End Sub Public Delegate Sub myDelegate(ByVal numero As String)

'CALLE 1 ––––––––––––– –––––––––––– // sentencias d e actualización del valor numérico
Public Sub actualizar_calle1_num(ByVal numero A s String)
Calle1_num.Text = numero End Sub
'CALLE 2 ––––––––––––– ––––––––––––
Public Sub actualizar_calle2_num(ByVal numero A s String)
Calle2_num.Text = numero End Sub
'CALLE 3 ––––––––––––– ––––––––––––
Public Sub actualizar_calle3_num(ByVal numero A s String)
Calle3_num.Text = numero End Sub Public Sub recargarDatos()
// Sentencias de actualización del valor de plazas ocupadas de cada calle controlada
Calle1_num.Invoke(New myDelegate(AddressOf actualizar_calle1_num), New _
Object() {arrayControlado r(1)})
calle2_num.Invoke(New myDelegate(AddressOf actualizar_calle2_num), New _
Object() {arrayControlado r(2)})

116
calle3_num.Invoke(New myDelegate(AddressOf actualizar_calle3_num), New _
Object() {arrayControlado r(3)})
End Sub Public Sub LeerSerialData() com = My.Computer.Ports.OpenSerialPort("COM 3", 38400, Parity.None, 8, StopBits.One)
//función de lectura de serial con sus parametros a decuados
End Sub Private Delegate Sub SetRefreshCallback()
//Función de refresco de panel
Private Sub SetRefresh() If Me.InvokeRequired Then Dim d As New SetRefreshCallback(Address Of SetRefresh)
MyBase.Invoke(d) Else MyBase.Refresh() End If End Sub Public Overloads Sub Refresh() SetRefresh() End Sub

117
Public Sub recibirDatos() Handles com.DataRecei ved
Dim miMapa As GoogleMaps = New GoogleMaps()
Dim leido As String = "" leido = com.ReadLine() If (leido <> "–––") Then If (leido.Substring(0, 8).Equals("PANTA LLA")) Then
// Si recibe un paquete que comienza por “PANTALLA” entonces…
arrayControlador = Split(leido, "," ) // Separa con el marcador “,”
prepararOcupacion() // invocación a preparar ocupación
recargarDatos() // invocación a recargar datos
miMapa.escribirGoogleMaps(arrayCall e) // escritura en mapa
CajaMapa.Url = New System.Uri(Appli cation.ExecutablePath.Substring(0, Application.Exec utablePath.LastIndexOf("\") + 1) + "GoogleMaps.html ", System.UriKind.Absolute)
CajaMapa.Refresh() //refrescar panel
Me.Refresh() End If End If End Sub

118
API GOOGLE MAPS
// Esta clase reescribe el código de GoogleMaps.html pa ra actualizar los datos de la página web mostrados en e l panel
Public Class GoogleMaps Public Sub escribirGoogleMaps(ByVal arrayCalle( ))
Dim fic As String = Application.ExecutableP ath.Substring(0, Application.ExecutablePath.LastInd exOf("\") + 1) + "GoogleMaps.html"
Dim sw As New System.IO.StreamWriter(fic) sw.WriteLine("<!DOCTYPE html>") sw.WriteLine("<html>") sw.WriteLine("<head>") sw.WriteLine("<meta name=""viewport"" conte nt=""initial-scale=1.0, user-scalable=no"" />")
sw.WriteLine("<style type=""text/css"">") sw.WriteLine("html { height: 100% }") sw.WriteLine("body { height: 100%; margin: 0; padding: 0 }")
sw.WriteLine(" #map_canvas { height: 100% } </style>")
sw.WriteLine("<script type=""text/javascrip t""")
sw.WriteLine("src=""http://maps.googleapis. com/maps/api/js?key=AIzaSyB7VyJX8DfZTX6VxZ2SzyL4rXl udhHsF34&sensor=false"">")
sw.WriteLine("</script>") sw.WriteLine("<script type=""text/javascrip t"">")
sw.WriteLine("function initialize() {") sw.WriteLine("var mapOptions = {") sw.WriteLine("center: new google.maps.LatLn g(40.32735,-3.826598),")
sw.WriteLine("zoom: 19,") sw.WriteLine("mapTypeId: google.maps.MapTyp eId.ROADMAP};")
sw.WriteLine("var map = new google.maps.Map (document.getElementById(""map_canvas""),")
sw.WriteLine("mapOptions);") sw.WriteLine("var calle1_marker1 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327268,-3.826638),")
sw.WriteLine("map:map,")

119
If (arrayCalle(1) = 1) Then // Si ocupado, mostrar en rojo
sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
//si libre, mostrar en verde y saltando
sw.WriteLine("calle1_marker1.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle1_marker2 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327268,-3.826679),")
sw.WriteLine("map:map,") If (arrayCalle(2) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle1_marker2.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle1_marker3 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327268,-3.826732),")
sw.WriteLine("map:map,") If (arrayCalle(3) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle1_marker3.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle1_marker4 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327266,-3.826783),")
sw.WriteLine("map:map,") If (arrayCalle(4) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else

120
sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle1_marker4.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle1_marker5 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327268,-3.826823),")
sw.WriteLine("map:map,") If (arrayCalle(5) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle1_marker5.setAnimati on(google.maps.Animation.BOUNCE);")
End If ' Marcadores para calle2 sw.WriteLine("var calle2_marker1 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327311,-3.826595),")
sw.WriteLine("map:map,") If (arrayCalle(6) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle2_marker1.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle2_marker2 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327385,-3.826603),")
sw.WriteLine("map:map,") If (arrayCalle(7) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")

121
sw.WriteLine("calle2_marker2.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle2_marker3 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327459,-3.826603),")
sw.WriteLine("map:map,") If (arrayCalle(8) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle2_marker3.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle2_marker4 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327532,-3.826606),")
sw.WriteLine("map:map,") If (arrayCalle(9) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle2_marker4.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle2_marker5 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327598,-3.826603),")
sw.WriteLine("map:map,") If (arrayCalle(10) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle2_marker5.setAnimati on(google.maps.Animation.BOUNCE);")
End If

122
' Marcadores para calle3 sw.WriteLine("var calle3_marker1 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327268,-3.826561),")
sw.WriteLine("map:map,") If (arrayCalle(11) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle3_marker1.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle3_marker2 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.32727,-3.826528),")
sw.WriteLine("map:map,") If (arrayCalle(12) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle3_marker2.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle3_marker3 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.32727,-3.826491),")
sw.WriteLine("map:map,") If (arrayCalle(13) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle3_marker3.setAnimati on(google.maps.Animation.BOUNCE);")
End If

123
sw.WriteLine("var calle3_marker4 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327272,-3.826456),")
sw.WriteLine("map:map,") If (arrayCalle(14) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle3_marker4.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("var calle3_marker5 = new goog le.maps.Marker({")
sw.WriteLine("position: new google.maps.Lat Lng(40.327272,-3.826413),")
sw.WriteLine("map:map,") If (arrayCalle(15) = 1) Then sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/red/blank.png ' });")
Else sw.WriteLine("icon: 'http://gmaps-sam ples.googlecode.com/svn/trunk/markers/green/blank.p ng' });")
sw.WriteLine("calle3_marker5.setAnimati on(google.maps.Animation.BOUNCE);")
End If sw.WriteLine("}") sw.WriteLine("</script>") sw.WriteLine("</head>") sw.WriteLine("<body onload=""initialize()"" >")
sw.WriteLine("<div id=""map_canvas"" style= ""width:100%; height:100%""></div>")
sw.WriteLine("</body>") sw.WriteLine("</html>") sw.Close() End Sub End Class

REFERENCIAS BIBLIOGRÁFICAS

[1] Página web de la ONU. [En línea]. http://www.un.or g/es/aboutun/ (Junio 2013).
[2] United Nations, Department of Economic and Social Affairs, Population Division: World
Urbanization Prospects. New York, 2012
[3] AMETIC, Informe Smart Cities 2012. Foro TIC para la sosteni bilidad. Madrid 2012
[4] Página web del Portal Estadístico de la Dirección General de Tráfi co. [En línea].
http://apl.dgt.es/IEST2/ (Junio 2013).
[5] Página web del Mobile World Congress. [En línea]. h ttp://www.mobileworldcongress.com/
(Junio 2013).
[6] Dossier informativo del Edificio Cero Emisiones de ACCIONA Energía S.A. Pamplona 2011.
[7] Fundación RACC. La Congestión en los Corredores de Acceso a Madrid. Madrid 2009
[8] Página web de Madrid+d relacionado con el proyecto MARTA. [En línea].
fttp://www.madrimasd.org/informacionidi/noticias/no ticia.asp?id=34888&tipo=g. Junio 2013
[9] Página web de la Empresa Municipal de Transportes, sección Navega por Madrid. [En
línea]. http://www.emtmadrid.es/Home/Destacados/Nav ega-por-Madrid.aspx junio 2013
[10] Página web del Proyecto CIPSU (Circuit Intelligent Pour Stationnement Urbain). [En línea]
http://www.presse-web.fr/circuit-intelligent-pour-s tationnement-urbain.html Junio 2013
[11] Página web del Plan MOVELE [En línea]. http://movel e.es/ Junio 2013
[12] Página web de la organización de Estadísticas de In ternet. [En línea]
http://www.internetworldstats.com/stats.htm Junio 2 013.
[13] Página web del Massachusetts Institute of Technolog y. [En línea]. http://www.mit.edu/
Junio 2013.
[14] Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, Marimuthu Palaniswami. Internet
of Things (IoT): A Vision, Architectural Elements, and Future Directions. [Artículo]. Octubre
2011
[15] K. Ashton, That ―Internet of Things ‖ Thing, RFiD Journal. [Artículo]. 2009
[16] J. Hernández Muñoz, J. Vercher. Smart cities at the forefront of the future internet, The
Future Internet. [Artículo]. 2011
[17] Página web del Protocolo de Internet V6. [En línea] http://www.ipv6.es/es-
ES/Paginas/Index.aspx Junio 2013
[18] S. Escolar. Wireless Sensor Networks: Estasdo del A rte e Investigación [Artículo] 2012

125
[19] Roberto Fernández Martínez, Joaquín Ordieres Meré, Francisco Javier Martínez de Pisón
Ascacíbar, Ana González Marcos, Fernando Alba Elías , Rubén Lostado Lorza, Alpha Verónica
Pernía Espinoza e Integrantes del grupo de investig ación EDMANS. “Redes inalámbricas de
sensores: teoría y aplicación práctica”. Universida d de la Rioja. ISBN 978-84-692-3007-7.
[Libro]. 2009.
[20] Ana Belén García Hernando, José Fernán Martínez Ort ega, Juan Manuel López Navarro,
Aggeliki Prayati y Luis Redondo López. “Problem Sol ving for Wireless Sensor Networks”. Ed
Springer ISBN 978-1-84800-202-9. [Libro]. 2008.
[21] Página web del Sitio Oficial del Sistema de Posicio namiento Global. [En línea].
http://www.gps.gov/ Junio 2013
[22] Sitio web de NAVSTAR en Wikipedia. [En línea]. http ://es.wikipedia.org/wiki/Navstar Junio
2013
[23] Página web del Sitio Oficial del Sistema de posicio namiento Galileo. [En línea].
http://www.satellite-navigation.eu/ Junio 2013
[24] Página web del Sitio Oficial del Sistema de posicio namiento Glonass. [En línea].
http://glonass-iac.ru/ Junio 2013
[25] Página web de la ESA referenciando el sistema de po sicionamiento EGNOS. [En línea].
http://www.esa.int/Our_Activities/Navigation/The_pr esent_-_EGNOS/What_is_EGNOS Junio
2013
[26] Bill Clinton, Presidente de los Estados Unidos de A mérica. Nota de prensa sobre GPS.
[Artículo]. 2001
[27] Página web de los transceptores Xbee y Xbee Pro. [E n línea]
http://ftp1.digi.com/support/documentation/90000976 _G.pdf Junio 2013
[28] Página web del fabricante DIGI internacional. [En lí nea] http://www.digi.com/es/ Junio
2013
[29] Página web de la Alianza Zigbee. [En línea] http:// www.zigbee.org/ Junio 2013
[30] Página web de IEEE 802.15 Working Group for WPAN. [ En línea]
http://www.ieee802.org/15/Junio 2013
[31] Alberto Bielsa Noveleta. Evaluación de rendimiento y prestaciones de dispositivos
sensoriales autónomos en redes 802.15.4 y zigbee en un entorno real. [Proyecto Final de
Carrera] Universidad de Zaragoza 2009
[32] David Gascón Cabrejas. IEEE 802.15.4 and new produ ct features. [Artículo] 2009
[33] Página web de Microsoft Visual Studio. [En línea]
http://www.microsoft.com/visualstudio/esn Junio 201 3
[34] Página web principal de HTML [En línea] http://www. w3.org/html/ Junio 2013

126
[35] Página web de la empresa PARK-IN [En línea] http:// www.park-in.es/ Junio 2013
[36] Página web de la empresa Parkhelp [En línea] http:/ /www.parkhelp.com/sistemas-
parking/ Junio 2013
[37] Página web de la empresa Libelium [En línea] http:/ /www.libelium.com/es/ Junio 2013
[38] Datasheet de Waspmote [En línea] http://www.libeliu m.com/es/products/waspmote/
Junio 2013
[39] Sitio de la Aplicación Smart parking de Libelium [E n línea]
http://www.libelium.com/es/smart_parking/ Junio 201 3
[40] Anuario Estadístico de Movilidad 2012. Ayuntamient o de Madrid [Artículo] Marzo 2013
[41] Sitio web del departamento de Movilidad del Gobier no de Seattle. [En línea]
http://onthemove.seattle.gov/2010/10/18/seattle-on- street-parking-data-available-on-the-
internet/ Junio 2013
[42] Estudio de Movilidad IBM. [Artículo] Septiembre 20 11
[43] Análisis del aparcamiento en superficie. Fundación RACC. [Artículo] Febrero 2008
[44] Sitio web del departamento de Estadística del Gobi erno de Seattle. [En línea]
http://www.clrsearch.com/Seattle-Demographics/WA/Nu mber-of-Vehicles-per-Household
[45] Revista DGT. Número 107 2005. [Revista] 2005

127