[sistema de recopilaciÓn de informaciÓn...

2013 Escuela Técnica

Superior de Ingenieros de Sevilla Manuel Rodríguez Cáceres

[SISTEMA DE RECOPILACIÓN DE INFORMACIÓN SOBRE EL ESTADO DEL TRÁFICO EN TIEMPO REAL]

SISTEMA DE RECOPILACIÓN DE INFORMACIÓN SOBRE EL ESTADO DEL TRÁFICO EN TIEMPO REAL Manuel Rodríguez Cáceres – ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE SEVILLA -2013

1

Í N D I C E

1. Introducción .......................................................................................................................... 5

1.1. Objetivo ......................................................................................................................... 5

1.2. Motivación y alcance ..................................................................................................... 6

1.3. Grado de innovación ..................................................................................................... 6

1.4. Estructura del trabajo.................................................................................................... 8

2. Antecedentes y estado del arte ............................................................................................ 9

2.1. Tipos de sistemas de recopilación de datos .................................................................. 9

2.2. Tipos de tecnologías utilizadas actualmente .............................................................. 10

2.3. Trabajos relacionados ................................................................................................. 13

3. Hardware del sistema de recolección de datos .................................................................. 14

3.1. Especificaciones técnicas del equipo .......................................................................... 14

3.2. Necesidades energéticas y Sistema de alimentación autónomo ................................ 17

3.3. Solución física para colocación .................................................................................... 20

4. Software del sistema de recolección de datos .................................................................... 22

4.1. Descripción general ..................................................................................................... 22

4.2. Bloques funcionales e interacción .............................................................................. 24

4.2.1. Configuración del sistema ................................................................................... 27

4.2.2. Manejo de datos ................................................................................................. 29

4.2.3. Recopilación y envío de los datos ....................................................................... 35

4.2.4. Comunicación con el servidor ............................................................................. 42

5. Caso práctico: análisis del recorrido Córdoba – Sevilla por A-4 .......................................... 44

5.1. Descripción .................................................................................................................. 44

5.2. Presupuesto de despliegue y mantenimiento ............................................................ 47

5.3. Estudio comparativo de costes ................................................................................... 49

6. Resultados obtenidos .......................................................................................................... 50

6.1. Experimentos .............................................................................................................. 50

6.1.1. Datos obtenidos por el prototipo situado en E-902, Granada ............................ 50

6.1.2. Datos obtenidos por un equipo de cityanalytics situado en un supermercado . 55

7. Conclusiones y trabajo futuro ............................................................................................. 60

8. Bibliografía .......................................................................................................................... 62

9. Anexos ................................................................................................................................. 63


2

9.1. Estudio estadístico representatividad bluetooth ............................................................. 63

9.2. Resolución Agencia Española de Protección de Datos sobre implantación de tecnología

similar en Zaragoza (Empresa Bitcarrier) ................................................................................ 63

Í N D I C E D E F I G U R A S

FIGURA 1. ESQUEMA DE CONEXIÓN DEL EQUIPO DE RECOLECCIÓN DE DATOS ............................................................... 14

FIGURA 2. ESQUEMA BÁSICO RASPBERRY PI Y ESPECIFICACION DE PINES GPIO............................................................... 15

FIGURA 3. CIRCUITO INTERFAZ UART-RS232 ......................................................................................................... 16

FIGURA 4. NÚMERO DE CICLOS DE CARGA EN RELACIÓN A CAPACIDAD Y TASA DE DESCARGA ........................................... 19

FIGURA 5. TIEMPO DE VIDA EN RELACIÓN A PORCENTAJE DE CARGA Y TEMPERATURA .................................................... 19

FIGURA 6. CAJA ESTANCA Y ARMARIO DE INTEMPERIE ............................................................................................. 20

FIGURA 7. SISTEMA DE SUJECIÓN ARMARIO DE INTEMPERIE ..................................................................................... 21

FIGURA 8. SOPORTE PARA PANEL SOLAR............................................................................................................... 21

FIGURA 9. REPRESENTACIÓN DEL SISTEMA A ALTO NIVEL .......................................................................................... 23

FIGURA 10. BLOQUES FUNCIONALES DEL SISTEMA .................................................................................................. 24

FIGURA 11. LOCALIZACIÓN: AUTOVÍA DEL SUR A-4. P.K. 410,00 MARGEN IZQUIERDA ................................................. 44

FIGURA 12.LOCALIZACIÓN: AUTOVÍA DEL SUR A-4. P.K. 435,00 MARGEN IZQUIERDA ................................................. 45



FIGURA 15: DISPOSITIVOS BLUETOOTH DETECTADOS DEL 12 MARZO AL 12 ABRIL ........................................................ 51

FIGURA 16: DISPOSITIVOS WIFI DETECTADOS DEL 12 MARZO AL 12 ABRIL ................................................................. 51

FIGURA 17: DISPOSITIVOS PERSONALES BLUETOOTH DETECTADOS DESDE EL SÁBADO 18 DE MARZO AL VIERNES 24 DE MARZO

........................................................................................................................................................... 52

FIGURA 18: DISPOSITIVOS BLUETOOTH DETECTADOS DESDE EL SÁBADO 18 DE MARZO AL VIERNES 24 DE MARZO ............... 52

FIGURA 19: DISPOSITIVOS BLUETOOTH PROPIOS DE VEHÍCULOS DETECTADOS DESDE EL SÁBADO 18 DE MARZO AL VIERNES 24

DE MARZO ............................................................................................................................................. 53

FIGURA 20: RESULTADOS TRAS EL TRATAMIENTO DE LOS DATOS (PERSONAS). MESES DE MARZO - ABRIL ........................... 53

FIGURA 21: RESULTADOS TRAS EL TRATAMIENTO DE LOS DATOS (VEHÍCULOS). MESES DE MARZO - ABRIL .......................... 54

FIGURA 22: DATOS MARZO ............................................................................................................................... 54

FIGURA 23: DATOS ABRIL ................................................................................................................................. 54

FIGURA 24. VISTA GENERAL DEL PANEL DE CITYANALYTICS ....................................................................................... 56

FIGURA 25. NÚMERO DE PERSONAS POR DÍAS EN JULIO .......................................................................................... 57

FIGURA 26. TIPOLOGÍA DE VISITANTES ................................................................................................................. 57

FIGURA 27. PRIMERA VISITA O VARIAS ................................................................................................................. 58

FIGURA 28. HORAS PUNTA ................................................................................................................................ 58


3

Í N D I C E D E E C U A C I O N E S

ECUACIÓN 3-1: CORRIENTE SUMINISTRADA POR EL PANEL SOLAR .............................................................................. 18

ECUACIÓN 3-2: TIEMPO DE CARGA DE BATERÍA ..................................................................................................... 18

ECUACIÓN 3-3: AUTONOMÍA DEL EQUIPO ............................................................................................................ 18

Í N D I C E D E T A B L A S

TABLA 3-1: HARDWARE EQUIPO RECOLECCIÓN DE DATOS (1) 16

TABLA 3-2: HARDWARE EQUIPO RECOLECCIÓN DE DATOS (2) 16

TABLA 3-3: SISTEMA DE ALIMENTACIÓN AUTÓNOMO 17

TABLA 3-4: CARACTERÍSTICAS ARMARIO INTEMPERIE Y CAJA ESTANCA PARA EQUIPO 20

TABLA 3-5: CARACTERÍSTICAS SOPORTE PANEL SOLAR 21

TABLA 4-1: CLASE CONFIGURACION MODEL 28

TABLA 4-2: CLASE SERVICE CONFIGURATION 29

TABLA 4-3: CLASE BT DATA 30

TABLA 4-4: CLASE WIFI DATA 31

TABLA 4-5: CLASE PERSISTENCE OBJECT 31

TABLA 4-6: CLASE USUARIO 32

TABLA 4-7: CLASE COLA UID'S 32

TABLA 4-8: CLASE NODORC 33

TABLA 4-9: CLASE PASORC 34

TABLA 4-10: CLASE USUARIORC 34

TABLA 4-11: CLASE SERVICE BLUETOOTH MODEL 35

TABLA 4-12: CLASE BLUETOOTH SCANNER THREAD 36

TABLA 4-13: CLASE BLUETOOTH THREAD MONITOR 36

TABLA 4-14: CLASE BLUETOOTH NOTIFIER THREAD 37

TABLA 4-15: CLASE SERVICE WIFI MODEL 37

TABLA 4-16: CLASE WIFI SCANNER THREAD 38

TABLA 4-17: CLASE WIFI THREAD MONITOR 39

TABLA 4-18: CLASE WIFI NOTIFIER THREAD 39

TABLA 4-19: CLASE SERVICE CARD READER MODEL 40

TABLA 4-20: CLASE CARD READER SCANNER THREAD 40

TABLA 4-21: CLASE USER ID THREAD MONITOR 41

TABLA 4-22: CLASE LOCAL PERIPHERALS NOTIFIER THREAD 41

TABLA 4-23: CLASE UID SERVER NOTIFIER THREAD 42

TABLA 4-24: CLASE CITYANALYTICS SERVER 43

TABLA 5-1: PRESUPUESTO TOTAL DEL PROYECTO 48

TABLA 5-2: PRESUPUESTO DE MATERIALES 48

TABLA 5-3: ESTUDIO DE MERCADO 49


4

R E S U M E N E J E C U T I V O

El objetivo del proyecto es desarrollar un sistema autónomo para la recopilación de información sobre el estado del tráfico en tiempo real, en este caso en la ciudad de Córdoba. Además el sistema será de bajo coste, rápida implantación y de escaso mantenimiento.

Para obtener la información necesaria se utilizan antenas Bluetooth y WiFi

conectadas a la placa “Raspberry Pi” que detectan los dispositivos móviles de la población. Además se utilizarán tags RFID activos colocados en los vehículos de la flota de Conservación de Carreteras para obtener más inputs para el sistema. La autonomía del sistema se consigue gracias a un equipo de alimentación basado en energía solar, y la conexión a internet a través de un dispositivo 3G. Se ha especificado que el software es un demonio programado en Java que haciendo uso de una serie de hilos independientes recoge la información proveniente de los escaneos de dispositivos (MAC y timestamp), la encripta y la envía periódicamente al servidor, donde se almacena ya encriptada.

Posteriormente se ha expuesto un caso práctico de implantación del sistema, incluyendo presupuesto y estudio comparativo de costes para posicionar el sistema en el mercado, y se han realizado dos experimentos, uno en carretera y otro en un establecimiento particular, mostrándose en el primero de ellos los datos obtenidos sin ningún tipo de tratamiento y después de un proceso de “minería de datos” integrado en el sistema CityAnalytics, propiedad de la empresa Ciudad 2020 SL.

Se concluye que el sistema propuesto en el presente proyecto cumple con los objetivos que se proponían al inicio, dejando la puerta abierta a numerosas mejoras relacionadas con el tratamiento de los datos obtenidos, así como lo posibilidad de incluir nuevos sensores que permitan trabajar con nuevas variables que actúen como inputs del sistema.

Las posibilidades en el tratamiento de la información recibida son muchas; además de ofrecer los datos a terceros gracias a la conexión al servidor mediante un servicio web, se podría generar un sistema de tratamiento de la información propio, gracias al cual poder ofrecer a la población una página web que contenga información acerca de los principales datos de movilidad en tiempo real, así como predicciones en base a la información recopilada durante cierto tiempo. Podría ofrecerse una estimación de número de vehículos en cada nodo, una matriz de orígenes y destinos, la velocidad media de los vehículos, recurrencia y fidelidad de los usuarios de las vías o el cálculo del tiempo de recorrido entre dos puntos, e integrar esto con redes sociales, generando un servicio de alertas automatizado y en tiempo real cuando se cumplan una serie de condiciones dadas.

Estas ideas pueden dar al sistema una continuidad real, aportando un valor añadido diferente del hecho de contar vehículos o identificar tendencias en una red de carreteras. Por su escalabilidad podría ser una herramienta interesante para muchas empresas que tienen una necesidad real de información significativa sobre la afluencia a sus negocios.


5

1 . I N T R O D U C C I Ó N

1.1. OBJETIVO

El objeto del presente proyecto es desarrollar un sistema recopilación de información sobre el estado del tráfico en tiempo real, en este caso en la ciudad de Córdoba.

Para obtener la información necesaria se utilizarán antenas Bluetooth y WiFi para detectar los dispositivos móviles de la población, esta característica, junto con la naturaleza del hardware que se emplea, se considera básica para cumplir uno de los objetivos del proyecto: que sea un sistema de bajo coste. Además se pretende conseguir un sistema totalmente autónomo desde el punto de vista del consumo energético, de rápida implantación, alta fiabilidad y escaso mantenimiento.

También se utilizarán tags RFID activos colocados en los vehículos de la flota de

Conservación de Carreteras para obtener más inputs para el sistema que se añaden a los datos obtenidos por las antenas Bluetooth y WiFi.

Gracias a la existencia de dispositivos autónomos, el sistema recopilará

información de forma masiva para su posterior interpretación y así buscar, por ejemplo, asociaciones dentro de los datos obtenidos que identifiquen tendencias. Se pretende ofrecer un servicio que genere los datos necesarios para obtener un sistema de ayuda a la toma de decisiones, capaz de aplicar conocimiento en aplicaciones comerciales relacionadas con la movilidad. El sistema es totalmente escalable, su funcionamiento no depende del número de dispositivos a implantar.

La información obtenida se ofrecerá mediante APIs para interconexión con

terceros, por lo que cualquier ciudad o territorio podría sumarse al proyecto extendiendo la plataforma.

Por tanto, los diferentes elementos necesarios para alcanzar los objetivos pretendidos por este sistema de información son los siguientes:

• Sistema de recopilación de datos: identificación de dispositivos Bluetooth y WiFi, así como tags RFID activos, configuración y correcta disposición de hardware y software para capturar señales hasta los 150 km/h, así como la elección de un soporte físico estanco en el que integrar el sistema para que quede protegido de las condiciones meteorológicas y de los actos vandálicos.

• Sistema de alimentación autónomo basado en el uso de energía solar. • Desarrollo de un servicio web necesario para permitir el envío de los datos

recopilados por los dispositivos autónomos en tiempo real a un servidor en el que quedarán almacenados.

• El sistema de procesado e interpretación de datos no es un objetivo de este proyecto; se proporcionará el acceso a los datos almacenados en el servidor mediante un servicio web para que cada empresa u organización usuaria del sistema haga el uso que más le convenga de los mismos.


6

1.2. MOTIVACIÓN Y ALCANCE

Tenemos en cuenta diferentes justificaciones para llevar a cabo un proyecto de este tipo, tanto desde el punto de vista técnico, mejorando notablemente la tecnología existente como desde el punto de vista económico y social.

Tener acceso a un sistema de información continuo y en tiempo real sobre el grado de saturación de las carreteras en cuanto a la tipología de conductores que están utilizando en ese momento las carreteras gracias a la individualización de la toma de datos.

La información obtenida permitirá conocer de manera mucho más clara cuántos y

cómo se mueven los habitantes, en este caso, de la ciudad de Córdoba, aunque podríamos ir más allá; en el caso de una hipotética implantación del sistema en toda Andalucía, se podría obtener una valiosa información sobre las relaciones socioeconómicas que se producen entre las diferentes ciudades de la comunidad autónoma andaluza.

En todo caso, los datos obtenidos son de un alto valor, tanto para la propia

administración pública como para organizaciones o empresas que podrían acceder a ellos y utilizarlos adaptándolos a sus necesidades individuales. Siempre partiendo de la base de que los datos recopilados son anónimos, es decir, a partir de los mismos no es posible identificar a personas concretas, como se detallará posteriormente.

Por otra parte, y posiblemente este sea uno de los puntos fuertes del sistema, en un

escenario de crisis económica como en el que nos encontramos, el sistema se ha diseñado con la premisa de que sea de bajo coste.

Se parte con alta probabilidad de éxito del proyecto. Ciudad 2020, ha venido testando desde el año 2008 la tecnología propuesta, por lo que se parte desde un gran conocimiento acumulado que permite garantizar el éxito del proyecto. El sistema CityAnalytics utiliza un sistema similar al del proyecto que nos ocupa, pero en este caso lo que se controlan son personas, no vehículos.

1.3. GRADO DE INNOVACIÓN

Las contribuciones de este trabajo con respecto a los sistemas de información utilizados actualmente por los organismos reguladores de transporte son numerosas:

• Intrusividad: Frente a otros sistemas la intrusividad del sistema de recopilación de datos es mínima, gracias a las tres antenas Bluetooth y una WiFi que integrarán los equipos de recolección de datos se captarán las ondas que emiten los diferentes dispositivos que ya incorporan los vehículos (manos libres o GPS), así como los propios teléfonos móviles que llevan sus ocupantes. Bluetooth trabaja en la banda de frecuencia de 2.4GHz, y normalmente WiFi también, pero la división que hacen del espectro es muy diferente, Bluetooth lo divide en 79 canales de 1MHz, mientras que WiFi lo hace en 14 canales de 5MHz. Durante un escaneo Bluetooth el número de saltos de frecuencia es mucho macho que durante el escaneo WiFi, es por eso que se ha optado por la multiplicidad de antenas en este caso. El


7

hecho de escoger esta proporción del número de antenas y no otro se debe a que las pruebas realizadas nos dan esta opción como la óptima. Si se recibieran varias señales de distintos vehículos en el mismo instante, el equipo de recolección de datos no tendría problema en captarlas todas, puesto que, además de que la detección WiFi es muy rápida (del orden de milisegundos), y para el Bluetooth contamos con multiplicidad de antenas. Cuando se reciben varias señales provenientes de un mismo vehículo en un determinado instante se recogen todas ellas, es por eso que nos encontramos ante una aproximación. No obstante, en el caso del Bluetooth, el hecho de poseer información sobre el tipo de dispositivo ofrece la posibilidad de discriminar entre vehículos individuales y las personas que van a bordo, por esta razón, la información derivada del escaneo Bluetooth será más fiable para el cometido de nuestro sistema. La información obtenida a través del escaneo WiFi servirá como complemento, y como valor añadido al sistema que podrá ser interesante para un hipotético cliente, usuario del sistema.

• Tipología de información, representatividad y calidad de los datos: Permitirá conocer cómo se mueve la población y cuáles son sus orígenes y destinos. Frente a otras tecnologías, la representatividad de los datos es bastante precisa, estimándose a priori un 8,85% de error tal y como demuestra el estudio aproximativo al error medio encontrado en la representatividad de los datos realizado por la empresa Ciudad2020 y que se incluye como anexo al proyecto.

• Información en tiempo real y de manera continua: El dispositivo incluirá un sistema de comunicación 3G que garantizará el envío de los datos a medida que se vayan recopilando en tiempo real a los servidores, donde se almacenarán, y serán servidos bajo demanda por parte de los usuarios finales u otros sistemas de información.

• Gestión de alertas e información: Frente a los sistemas de información que se tienen actualmente que se describirán posteriormente, el sistema de información se diseñará teniendo en cuenta el futuro uso de la información por parte de las empresas u organizaciones usuarias del sistema, e incluso por parte del ciudadano, para la toma de decisiones sobre su movilidad.

• Privacidad de datos: No es posible asociar los datos recopilados a ningún tipo de usuario ya que no existe ningún tipo de información que haga posible de manera plausible, la identificación de los datos recopilados con la persona en concreto. Para ello se utilizarán técnicas de encriptación unidireccionales con caracteres no estándar que imposibilitan identificar ni tan siquiera el primer dato recopilado: la MAC del dispositivo inalámbrico. Concretamente lo que se almacena es la encriptación hash de la propia MAC.


8

1.4. ESTRUCTURA DEL TRABAJO

Este trabajo se estructura en 9 secciones. La Sección 1 es la Introducción, cuyo contenido ya hemos mostrado; la Sección 2 es “Antecedentes y Estado del Arte”, que consta de 3 subsecciones: “Tipos de sistemas de recopilación de datos”, “Tipos de tecnologías utilizadas actualmente” y “Trabajos relacionados” ; Sección 3 “Hardware del sistema de recolección de datos”, con 3 subsecciones: “Especificaciones técnicas del equipo”, “Necesidades energéticas”, “Sistema de alimentación autónomo” y “Solución física para la colocación del equipo”; Sección 4 “Software del sistema de recolección de datos”, incluye 2 subsecciones: “Descripción general” y “Bloque funcionales e interacción”, a su vez, esta última se divide en 4: “Configuración del sistema”, “Manejo de datos”, “Recopilación y envío de datos” y “Comunicación con el servidor”; Sección 5 “Caso práctico: análisis del recorrido Córdoba – Sevilla por A-4”, 3 subsecciones: “Descripción”, “Presupuesto de despliegue y mantenimiento” y “Estudio comparativo de costes”; Sección 6 “Resultados obtenidos”, subsección “Experimentos”, y esta se divida en 2: “Datos obtenidos por el prototipo situado en E-902, Granada” y “Datos obtenidos por un equipo de CityAnalytics situado en un supermercado”; Sección 7 “Conclusiones y trabajo futuro”; Sección 8, dedicada a la Bibliografía, y finaliza con la sección 9 “Anexos”, que incluye “Estudio estadístico representatividad Bluetooth” y “Resolución Agencia Española de Protección de Datos sobre implantación de tecnología similar en Zaragoza (empresa BitCarrier)”.


9

2 . A N T E C E D E N T E S Y E S T A D O D E L A R T E

2.1. TIPOS DE SISTEMAS DE RECOPILACIÓN DE DATOS

Analizaremos los sistemas de información aplicados a la recopilación de datos y generación de información sobre el grado de congestión de las carreteras, para ello clasificaremos las distintas tipologías existentes de sistemas de este tipo. Se pueden clasificar por la inmediatez de los datos, la exhaustividad en la recopilación y su intrusividad en el entorno vial preexistente.

Por la inmediatez de la toma de datos y en función de la forma de recopilación los sistemas actuales se clasifican en:

• De toma de datos directa: La toma de datos se definirá como directa cuando la fuente obtenga el dato estudiado sin utilizar algoritmos que, partiendo de las variables fundamentales del tráfico (intensidad, velocidad, ocupación o densidad), obtengan un dato de estudio calculado, es decir, cuando obtenga el dato estudiado de forma experimental.

• De toma de datos indirecta: La toma de datos será indirecta si se obtiene el dato a partir de la ejecución de un algoritmo, utilizando una o varias de las variables fundamentales del tráfico. Extrapolando, en general, los datos de un punto particular de la red a toda una sección de la misma.

Por la exhaustividad de la toma de datos los sistemas pueden ser: • De toma de datos cuasi exhaustiva: La toma de datos será cuasi exhaustiva

cuando su representatividad sea casi total, es decir, cuando el número de medidas tomadas coincida con el número de usuarios de ese tramo de la red.

• De toma de datos no exhaustiva: Se definirá la toma de datos como no exhaustiva cuando la fuente sólo aporte datos de un número limitado de usuarios. Siempre se intentará que la muestra de usuarios tenga la mayor representatividad posible.

Por la intrusión de la toma de datos tenemos: • De sensor intrusivo: Un sensor será intrusivo cuando la ubicación de este sea en

el interior del paquete de firme o bien directamente sobre la calzada, es decir en contacto con el firme. Su situación, su instalación y mantenimiento afectan irremediablemente al tráfico en la vía, lo que los hace complejos y costosos.

• De sensor no intrusivo: Pertenecerán a este grupo los sensores que se sitúen en posición cenital o lateral respecto a la vía sin entrar en contacto con la calzada. Para su ubicación utilizan generalmente infraestructuras existentes (puentes sobre la vía, pórticos de paneles de señalización o peajes), pórticos propios o postes. Por su situación, su instalación y mantenimiento pueden resultar más simples que en los sensores intrusivos.

• De vehículo flotante: Son aquellos sensores en los que toda su infraestructura está contenida en un vehículo y en sistemas preexistentes (de comunicación y posicionamiento) que no afectan de forma directa a la gestión de la vía.


10

2.2. TIPOS DE TECNOLOGÍAS UTILIZADAS ACTUALMENTE

• Tubos neumáticos o aforadores Los tubos neumáticos o aforadores son sensores de ejes que detectan el paso del vehículo en base al impulso de presión que se genera. Pueden contar y clasificar, pero sólo para utilización temporal y en tránsitos fluidos.

• Detectores de lazo o espiras Los detectores de lazo o espiras (inductivas, magnética o por procesamiento de vídeo), se pueden utilizar en forma temporal o permanente, siendo esta última la más normal. Detectan el paso del vehículo por variación de la masa magnética sobre el lazo. Permiten detectar de forma directa y exhaustiva la clase de vehículos que están circulando, la ocupación de la vía, el volumen de tráfico y, si se trata de espiras dobles, la velocidad puntual de los vehículos.

Esta fuente de datos es la más extendida en la mayoría de las redes viarias del mundo para su gestión. A diferencia de los sensores no intrusivos, las espiras se caracterizan por un bajo coste unitario (o de adquisición) y un alto coste de mantenimiento. El alto coste de mantenimiento, así como la imposibilidad de individualizar los datos obtenidos constituyen un hándicap para la implantación esta tecnología.

• Vehículos flotantes La utilización de los llamados vehículos flotantes, consiste en un vehículo dotado de sensores que recoge información mientras circula por una ruta predefinida.

Este dispositivo activo de toma de datos es uno de los más extendidos entre los operadores de las redes viarias, utilizado especialmente para la recogida de tiempos de viaje y calibración de los algoritmos de las espiras. Dependiendo de la automatización de la recogida de datos, el coste puede variar.

En algunos ámbitos, como los telepeajes o los sistemas de transporte público, son muy utilizados también los sistemas de Identificación automática de vehículos (AVI). Los sensores AVI son fuentes de datos no exhaustivas que identifican localizadores situados en los vehículos (tags), como por ejemplo en los sistemas de pago sin parada. El sistema reconoce su paso, y los datos son enviados al servidor que los procesa para llevar a cabo un evento (pago del peaje, apertura de la valla, etc).

En los siguientes cuadros analizaremos las diferentes tecnologías utilizadas,

analizándolas desde diferentes perspectivas: datos recopilados, fiabilidad y precisión, representatividad de los datos y coste:


11

TABLA 2-1: COMPARATIVA EN CUANTO A DATOS RECOPILADOS

TABLA 2-2: COMPARATIVA EN CUANTO A FIABILIDAD Y PRECISIÓN


12

Como podemos observar en los cuadros y confirmando el conocimiento acumulado

en los últimos años, la principal desventaja de todos estos sistemas, exceptuando el reconocimiento de matrículas, es que no tienen capacidad para identificar e individualizar los vehículos que detectan, por lo que no es posible la elaboración de matrices origen destino dinámicas con infraestructuras basadas en ellos. Sólo es posible saber que han pasado un número de vehículos y la tipología de los mismos, pero no permiten conocer cómo se producen los flujos de movimiento.

Además, su coste elevado hace muy poco rentable cubrir la red de carreteras secundarias con ellos, por lo que se suelen ubicar en vías principales y en salidas de grandes núcleos de población.

• Reconocimiento automático de matricula

La tecnología de reconocimiento automático de matrícula ha experimentado un fuerte impulso en los últimos años, debido a la funcionalidad añadida de tener la capacidad de detectar vehículos individualizados sin depender de sistemas integrados en los vehículos. Además, se usan para la detección automática de incidencias en la carretera, como por ejemplo el exceso de velocidad de los vehículos. Esa es la principal ventaja sobre los sistemas de información anteriores.

Sin embargo, la fiabilidad del sistema no es la mejor. En condiciones

meteorológicas adversas podrían aparecer problemas relacionados con la estabilidad de la cámara o la claridad de la lente, así como el deslumbramiento provocado por la luz solar.

TABLA 2-3: COMPARATIVA EN CUANTO A COSTE Y REPRESENTATIVIDAD


13

Una implantación en ciudad de un sistema de reconocimiento de matrículas puede encontrarse en el ámbito de 30.000€ por unidad más el mantenimiento asociado a las mismas.

2.3. TRABAJOS RELACIONADOS

Diferentes empresas, tanto a nivel nacional como internacional, están trabajando en el área de la información del tráfico utilizando aproximaciones similares a las que se usarán en este proyecto.

• Bit Carrier: Bit Carrier es una empresa de Barcelona que desde el año 2007 viene trabajando en el ámbito de la gestión del tráfico. Han desarrollado un producto de gestión del tráfico basado en Bluetooth, que les ha permitido llevar a cabo proyectos de conteo de personas y rutas comerciales (pathsolver) por los que han recibido un premio de IBM por el desarrollo avanzado de su tecnología. Sus productos se llaman “roadsolver” (tráfico en carretera) y “citysolver” (tráfico en ciudad). Tienen presencia en Zaragoza, Barcelona, Nueva York y Río de Janeiro entre otras. Han implantado su tecnología de control y monitorización del tráfico en las autopistas gestionadas por la empresa Abertis; actualmente tiene una red de 150 dispositivos en las autopistas de Abertis en Cataluña, lo que le permite conocer los tiempos de viaje de 200.000 personas al día.

• Trafficnow: Producto de medida del número de vehículos y tiempos de viaje basado en Bluetooth. Ofrecen un centro de control virtual, y un Premium Control Site con matrices O/D tomando datos cada 15 o 60 minutos. Han implantado un piloto de 5 puntos de control en Vigo. En el ámbito internacional encontramos dos ejemplos más en este sentido:

• Traffax Inc: Empresa estadounidense que ha desarrollado el producto “BluFAX”, basado también en tecnología Bluetooth, tanto para soluciones móviles como permanentes que permiten conocer matrices O/D así como tiempos medios de transporte entre diferentes puntos.

• Savari Networks: Empresa californiana con otro producto similar a los anteriores, “StreetWAVE”, sistema de monitorización para conocer en tiempo real el estado del tráfico así como su análisis, con el objetivo de poder gestionar el tráfico de manera eficiente.

• TrafficCast: También estadounidense, esta empresa ha desarrollado modelos de predicción de movilidad en ciudades, basándose en la combinación de diferentes tecnologías como cámaras, Bluetooth y lectura de tags RFID incluidos en los vehículos.

En el ámbito de la movilidad peatonal tenemos a Ciudad 2020, una empresa radicada en Córdoba que en el año 2010 pone en el mercado el sistema CityAnalytics, el cual permite estimar con un 8,85% de error el número de personas que pasan por un entorno determinado, el tiempo medio que permanecen en una zona, el origen y destino de las mismas así como la tipología de las personas que concurren en la zona estudiada, en relación a si son visitantes asiduos o esporádicos. Para ello utilizan la misma tecnología que las empresas anteriormente mencionadas. Esta información ha permitido la construcción de un prototipo funcional de un mapa de movilidad de peatones en tiempo real de la ciudad de Córdoba gracias al despliegue de tecnología desarrollada por la empresa.


14

3 . H A R D W A R E D E L S I S T E M A D E R E C O L E C C I Ó N D E D A T O S

3.1. ESPECIFICACIONES TÉCNICAS DEL EQUIPO

El equipo de recolección de datos está formado por la placa SBC (Single-Board Computer) Raspberry Pi, este ordenador del tamaño de una tarjeta de crédito será el corazón del sistema. Conectada a la Raspberry tenemos una placa de fabricación propia que integra el circuito que hace posible la conexión de un lector RFID y un circuito regulador de tensión necesario para alimentar correctamente el equipo autónomo, así como el HUB USB al que se conectan módulos Bluetooth y WiFi que funcionan como sensores para la recopilación de información, además de un módulo 3G que actuará como vía de conexión a internet. El lector RFID servirá para detectar los tags activos que se colocarán en ciertos vehículos de Conservación de Carreteras.

FIGURA 1. ESQUEMA DE CONEXIÓN DEL EQUIPO DE RECOLECCIÓN DE DATOS

Profundizaremos a continuación en el elemento principal del equipo:

La Raspberry Pi integra un SoC (System on a chip) Broadcom BCM2835, que incluye un procesador ARM1176JZF a 700MHz (overclockeable mediante firmware hasta 1 GHz sin pérdida de garantía), una GPU VideoCore IV y 512 megabytes de RAM. La placa carece de disco duro, utiliza una tarjeta SD para el arranque y el almacenamiento de datos. El Sistema Operativo que usará la placa es Raspbian (distribución de Debian para Raspberry). En la siguiente figura se presenta un esquema básico de la placa, así como una descripción gráfica de los pines que componen el puerto GPIO (General Purpose Input-Output):


15

Veremos en profundidad las funciones de cada uno de estos pines:

Pines GPIO0 a GPIO7: Se pueden configurar como entrada o salida de forma

segura en cualquier circunstancia. Pines TxD y RxD: Los usa la UART como pines de transmisión (Tx) y recepción

(Rx). Si se desactiva la consola serie pueden usarse también como pines de entrada-salida de propósito general.

Pin GPIO1: Se puede cambiar la configuración del pin GPIO1 para que actúe como salida PWM (Pulse Width Modulation).

Pines SDA0 y SCL0: Pines I2C, pueden usarse como pines de entrada-salida digital si no se están usando drivers I2C. Incluyen resistencias internas de 1.8KΩ que conectan las señales a 3.3V, lo que los hace fácilmente configurables como entradas, pues poseen la resistencia de pull-up/pull-down ya integrada.

Pines MOSI, MISO, SCLK, CE0 y CE1: Conforman la interfaz SPI, como los pines I2C, si no se están usando como SPI, pueden usarse como pines de entrada-salida de propósito general. Sin embargo estos pines no poseen resistencias de pull-up o pull-down integradas.

Los pines marcados con 0V son conexiones a tierra (GND), y los marcados con 3.3V y 5V proporcionan una fuente de tensión constante a estos valores. Para este proyecto haremos uso de los pines Tx y Rx de la UART, que junto con un pin de señal (5V) y otro de tierra (GND) compondrán la interfaz RS232 necesaria para la conexión del lector RFID. Además habrá que introducir un circuito de conversión intermedio para adaptar la tensión de trabajo de la Raspberry Pi a la del estándar RS232, este circuito está formado por un integrado MAX232 y una serie de condensadores. Un esquema del circuito en cuestión puede verse en la siguiente figura.

FIGURA 2. ESQUEMA BÁSICO RASPBERRY PI Y ESPECIFICACION DE PINES GPIO


16

Cuadro resumen de los elementos que componen el equipo de recolección de datos:

Raspberry Pi *Procesador de arquitectura ARM a 700MHz *512MB de RAM *Almacenamiento en tarjeta SD *Puertos USB

Tarjeta SD *4GB *Clase 10

Placa auxiliar *Circuito UART-RS232 *Circuito regulador de tensión *HUB USB

Módulo Bluetooth *Bluetooth 2.0 *Antena integrada

Módulo WiFi *Estándar IEEE 802.11, 2.4GHz *Antena integrada

Módulo 3G *Estándar 3G *Antena integrada

Lector RFID

*Interno *Frecuencia de comunicación : 2.45 GHz *Rango de frecuencia: 2.40-2.48GHz *Rango de lectura: hasta 10 metros

TABLA 3-1: HARDWARE EQUIPO RECOLECCIÓN DE DATOS (1)

Además, hay que tener en cuenta los tags RFID activos que se colocarán en los vehículos de la flota de conservación de carreteras, cuyas características son las siguientes:

Tag RFID activo *Frecuencia de comunicación 2.45GHz *Programación del intervalo de transmisión *Tamaño: 88x55x8 mm *Indicador visual LED

TABLA 3-2: HARDWARE EQUIPO RECOLECCIÓN DE DATOS (2)

FIGURA 3. CIRCUITO INTERFAZ UART-RS232


17

3.2. NECESIDADES ENERGÉTICAS Y SISTEMA DE ALIMENTACIÓN AUTÓNOMO

El equipo de recolección de datos funciona a 5V, y en su conjunto tiene un consumo aproximado de 800mA, estas serán las especificaciones de corriente y tensión que el sistema de alimentación ha de satisfacer de manera ininterrumpida para un funcionamiento correcto del equipo autónomo.

Para cubrir las necesidades energéticas se utiliza un equipo para la obtención de energía fotovoltaica formado por una placa solar, una batería y un regulador solar al que se conectan tanto la placa solar como la batería y del que se obtendrá la corriente que alimentará nuestro sistema.

Llegados a este punto hemos de dimensionar el equipo fotovoltaico para que cubra nuestras necesidades, se muestra a continuación un cuadro resumen de los elementos que forman el sistema de alimentación autónomo, posteriormente se realizarán una serie de cálculos justificativos del diseño del sistema de alimentación.

Panel solar *Medidas: 608x669x35mm *Peso: 4.88kg *Policristalino *Potencia máxima: 50W *Corriente de salida máxima: 2.78A

Batería *Batería monoblock *Capacidad: 65Ah

Regulador solar *Tensión de salida: 12V *Intensidad máxima de salida: 6A *4 LED indicadores de funcionamiento, estado de carga, avisos de fallo. *Fabricado conforme a ISO 9001 e ISO 14001 *Regulador serie *Regulación de tensión *Selección automática de tensión *Regulación MAP *Tecnología de carga escalonada *Desconexión de carga en función de la corriente *Reconexión automática del consumidor *Compensación de temperatura *Protección contra sobrecarga *Protección contra descarga total *Protección contra polaridad inversa de los módulos, la carga y la batería *Protección contra cortocircuito de la carga y los módulos solares *Protección contra sobretensión en la entrada del módulo *Protección contra corriente inversa por la noche *Protección contra sobretemperatura y sobrecarga *Desconexión por sobretensión en la batería

TABLA 3-3: SISTEMA DE ALIMENTACIÓN AUTÓNOMO


18

Pues bien, según las características del panel solar, tenemos una corriente máxima de salida de 2.78A, esto sería en condiciones excepcionales, pero el rendimiento real, será cercano a un 80%. Por esta razón el valor de corriente suministrada que utilizaremos para los cálculos será menor:

ECUACIÓN 3-1: CORRIENTE SUMINISTRADA POR EL PANEL SOLAR

Por otro lado, aunque la batería tiene una capacidad total de 65Ah, tendremos en cuenta que la carga mínima que aceptaremos tener en la misma, la llamada Carga Mínima Permisible (SOC), será de un 65%. Sabiendo esto podemos calcular el tiempo que tardaría en cargarse nuestra batería (en condiciones normales no se descargará más de un 35%):

ECUACIÓN 3-2: TIEMPO DE CARGA DE BATERÍA

Calculamos ahora la autonomía que tendrá nuestro equipo, partiendo de la base de que el consumo de corriente aproximado será de 800mA, y teniendo en cuenta que no queremos que nuestra batería baje del 65% de carga.

ECUACIÓN 3-3: AUTONOMÍA DEL EQUIPO

Podemos concluir que el equipo alimentado a través de este sistema tiene una

autonomía de unas 28 horas sin bajar del 65% de carga de la batería, la cual tardaría en cargarse en torno a 10 horas en caso de que se llegara a alcanzar esa descarga máxima del 35% fijada como límite. Estos datos teóricos se han corroborado con pruebas reales, la autonomía del equipo sin entrada de corriente desde la placa solar supera sin problemas las 24 horas, y el tiempo de carga de la batería desde su carga mínima admisible se queda por debajo de las 10 horas, aunque eso dependerá mucho de las condiciones de sol, claro está.

Dependiendo de la época del año la media de horas de sol experimenta grandes

variaciones, superándose la cifra de 10 horas en ciertos momentos y no llegando a esta cifra en otros. En cualquier caso, la autonomía nos permite trabajar con un considerable margen de maniobra. Realmente la función del panel solar será la de mantener la batería cargada, rara vez la carga de la batería bajará hasta ese 65%, por consiguiente el tiempo de carga tampoco llegará a los valores establecidos. De hecho habrá momentos en los que el equipo se alimente en tiempo real de la corriente que la placa suministra.

En definitiva, el diseño del sistema es suficientemente robusto como para convertir nuestro equipo en totalmente autónomo, por lo que quedará exento de un mantenimiento diferente del que podría ser necesario con el tiempo por necesidad de rellenar el electrolito de las baterías o su sustitución si se encontraran al final de su vida útil, así como la posible necesidad de sustitución de las placas.


19

Para las placas solares, la vida útil comúnmente efectiva y aceptada de 25 años viene con la garantía ofrecida por los fabricantes. La garantía contempla que el panel solar no disminuirá su eficiencia debajo del 80 % dentro de los primeros 25 años. La proporción actual de degradación coloca al 80 % la eficiencia a los 40 años de vida de un panel solar, haciendo de los 25 años de garantía una apuesta razonablemente segura.

En cuanto a las baterías, su vida útil es muy variable, y depende de factores como la

temperatura o el nivel máximo de descarga que tienen que soportar. En este caso, la batería se encontrará a temperaturas muy variables, dependiendo de las condiciones climatológicas, lo que hace complicado prever la vida útil real que ofrecerá, por otro lado, la tasa máxima de descarga (o profundidad de descarga) que soportará será de un 35%, cuando para este tipo de batería se aceptan niveles del 50%, por tanto, en este aspecto, estamos a niveles más que aceptables. Veremos dos gráficas que ilustran número de ciclos completos de carga (tiempo de vida de una batería) en relación a su capacidad y tasa de descarga (porcentaje de la carga total y temperatura).

Podemos observar que el factor limitante es la tasa de descarga, que limita el número de ciclos de carga para una tasa de descarga del 30% (cercana al 35% que hemos considerado), a aproximadamente 1000 ciclos, esto equivaldría a unos 3 años de vida útil, considerando que todos los días se produce un ciclo de descarga completo.

FIGURA 4. NÚMERO DE CICLOS DE CARGA EN RELACIÓN A CAPACIDAD Y TASA DE DESCARGA

FIGURA 5. TIEMPO DE VIDA EN RELACIÓN A PORCENTAJE DE CARGA Y TEMPERATURA


20

3.3. SOLUCIÓN FÍSICA PARA COLOCACIÓN

El equipo de recolección de datos se colocará en el interior de una caja estanca de plástico ABS, que a su vez se introducirá en un armario de intemperie antivandálico que se situará abrazado al propio poste sobre el que se fijará la placa solar o bien fijado a una pared, dependiendo del caso. Dentro de este armario se colocarán tanto el equipo de recolección de datos como la batería encargada de la alimentación del mismo y el regulador de corriente fotovoltaica. A continuación se muestran las características de la caja estanca y del armario, así como fotos de los modelos elegidos:

Armario de intemperie antivandálico

*Armario para exteriores de doble pared *Medidas: 400x400x300mm *Grado de Resistencia contra impacto IP 55 según EN 60 529 *Armario interior con placa de montaje y cierre de seguridad (CS 9791.045 con 2 cierres de seguridad) *Armario exterior con cierre de seguridad *Material: aluminio AlMg3

Caja Estanca *La caja está hecha de material ABS de alta resistencia al impacto (temperatura de funcionamiento : de -20°C a +100°C) *Medidas: 171 x 121 x 55 mm *Grado de protección: Estas cajas cumplen las normas IP65 de IEC529 y NEMA4

TABLA 3-4: CARACTERÍSTICAS ARMARIO INTEMPERIE Y CAJA ESTANCA PARA EQUIPO

La caja estanca que integra el equipo se fijará a una de las paredes interiores del armario de intemperie.

FIGURA 6. CAJA ESTANCA Y ARMARIO DE INTEMPERIE


21

El armario se fija al báculo de sujeción utilizando bridas de fleje de acero inoxidable 1.4301 (AISI 304). Este sistema permite la fijación a postes redondos de diámetros entre 40 y 190 mm y cuadrados de entre 50 y 150 mm. El sistema de sujeción se muestra en la imagen siguiente:

FIGURA 7. SISTEMA DE SUJECIÓN ARMARIO DE INTEMPERIE

El panel solar irá fijado al poste, bien de los ya existentes en la red de carreteras o

bien uno colocado expresamente para este cometido, utilizando una estructura de soporte de tipo “B” como la de la figura. El soporte consta de una serie de perfiles metálicos cuyas dimensiones coinciden con las del panel solar.

Soporte para panel solar

*Material empleado: acero galvanizado en caliente (normas UNE 37-501 y UNE 37-508), que cumple con los espesores mínimos exigibles según la norma UNE EN ISO 1461 *La tornillería utilizada es galvanizada o de acero inoxidable y cumple la Norma MV-106

TABLA 3-5: CARACTERÍSTICAS SOPORTE PANEL SOLAR

FIGURA 8. SOPORTE PARA PANEL SOLAR


22

4 . S O F T W A R E D E L S I S T E M A D E R E C O L E C C I Ó N D E D A T O S

4.1. DESCRIPCIÓN GENERAL

El sistema escanea en busca de todo tipo de dispositivos que emiten información de forma abierta. El objetivo es capturar la dirección física del dispositivo en cuestión, la MAC.

Cuando se despliega un equipo al que denominamos "nodo", creamos un

identificador único para él que nos permite saber quién está enviando información al servidor. Posteriormente, durante el proceso de escaneo de dispositivos que lleva a cabo dicho nodo autónomo, se realiza un proceso mediante el cual obtenemos información acerca del dispositivo hasta que deja de ser detectado, quedando esta información almacenada. Las especificaciones del software que realiza la captura de información sobre la detección de dispositivos, y su posterior subida al servidor se realizan en base a un demonio para sistemas Linux programado en Java, un “daemon”. Este tipo de procesos se ejecutan en segundo plano e interactúan con el sistema realizando operaciones específicas un número de veces predefinido o en respuesta a ciertos eventos. El término daemon está relacionado con UNIX, en otros sistemas operativos cambia la nomenclatura utilizada, por ejemplo Windows se refiere a esto como “servicio”. Las características de este tipo de programas permiten que su ejecución comience con el arranque del sistema; posteriormente el proceso se puede parar o reiniciar. Varios son los motivos por los cuales se elige Java como lenguaje de programación por la gran extensión y estandarización de la API Java y su extraordinaria documentación, porque pone a disposición del programador un gran universo de librerías Open Source, y además porque se trata de un lenguaje claro y eficiente. Aunque el lenguaje de programación sobre el que se asienta el sistema es Java, en la comunicación directa con el hardware se hace uso de lenguaje C en determinadas ocasiones, para ello se utilizan librerías JNI (Java Native Interface), que permiten la interoperabilidad Java-C, siendo para el programador totalmente transparente el uso del lenguaje C, pues la función de C se llama desde Java como un método más. Se han usado librerías JNI ya existentes: “jpcap” (para el escaneo WiFi) o “pi4j” (para la comunicación directa con los pines de la Raspberry Pi) y una creada expresamente para este proyecto, que permiten el escaneo Bluetooth desde Java haciendo uso de las primitivas de C para la comunicación con este tipo de dispositivos. Con la simple instanciación en Java de la clase BluetoothDeviceScan( ), podemos ejecutar el método bluScan, que se comunica directamente con el método de C encargado del escaneo Bluetooth. La llamada quedaría así (dev_addr es la dirección física de la antena Bluetooth): Se genera un hilo para la realización de la captura continua de cada uno de los inputs del sistema, un lector RFID, tres antenas Bluetooth y una WiFi, cinco hilos en total. Por otro lado tendremos tres hilos (Notifiers) encargados de la subida de información al servidor de forma que esta tarea no interfiera con la de escaneo, uno para cada tipo de input (Bluetooth, Wifi y RFID). Desde la clase principal (Main) se crea una nueva instancia

static BluetoothDeviceScan obds = new BluetoothDeviceScan( ); obds.blueScan(dev_addr);


23

de cada uno de los modelos (Models) a implementar. Estos modelos son la plataforma desde la cual se lanzan los hilos necesarios para llevar a cabo una acción del sistema; también aquí se crean los monitores (Monitors) que llevan el control de estos hilos. En la siguiente figura tenemos una descripción gráfica a alto nivel del funcionamiento del sistema.

Cada cierto tiempo se realiza el envío de un "set" de información al servidor. Dentro de este "set", cada ítem de información (al que denominamos "paso") representa a un dispositivo detectado, y cada paso contiene la siguiente información:

CLIENTE (NODO: idNodo, usuario) SERVIDOR

MÉTODOS

LOCALES

DEL

SERVIDOR

CityAnalyticsServer ConfiguracionModel ServiceConfiguration

Scanners

Notifiers

Synchronize

Monitors

Bluetooth

RFID

WiFi

Bluetooth

WiFi

RFID Local Notifier

Paso Nuevo (MAC, fechaInicio, fechaFin)

WEB SERVICE

Paso Nuevo (MAC, fechaInicio, fechaFin)

Nuevo Check-in (MAC, timestamp)

Actualización BBDD local

Establecimiento conexión con el servidor

Comprobación configuración: idNodo, usuario…

FIGURA 9. REPRESENTACIÓN DEL SISTEMA A ALTO NIVEL


24

Identificador único del dispositivo detectado (encriptación de la MAC Bluetooth o Wi-Fi).

Identificador único del "nodo" desde el que se envía la información. Timestamp en milisegundos del instante en el que el dispositivo comenzó a ser

detectado. Timestamp en milisegundos del instante en el que el dispositivo dejó de ser

detectado. MajorDeviceClass, identificador dentro de la MAC que permite identificar el tipo

genérico de dispositivo, sólo para dispositivos Bluetooth. MinorDeviceClass, identificador dentro de la MAC que permite identificar el tipo

específico de dispositivo, sólo para dispositivos Bluetooth ServiceClass, identificador que permite la identificación de los tipos de servicio

ofrecidos por el dispositivo, sólo para dispositivos Bluetooth

4.2. BLOQUES FUNCIONALES E INTERACCIÓN

Estructuraremos el sistema en cuatro agrupaciones funcionales: configuración del sistema, manejo de datos (acceso y transferencia), recopilación y envío de los datos al servidor, y por último comunicación con el servidor, que se llevará a cabo a través de un servicio web.

FIGURA 10. BLOQUES FUNCIONALES DEL SISTEMA

CONFIGURACIÓN DEL SISTEMA

*Verifica el archivo de local de configuración (identificadores de nodo y de usuario del sistema)

*Comprueba la conexión con el servidor

RECOPILACIÓN Y ENVÍO DE DATOS

*Escaneo de dispositivos al alcance: Bluetooth, WiFi y RFID

*Notificación al servidor, creando un nuevo paso (Bluetooth y WiFi) o realizando un nuevo check-in (RFID)

COMUNICACIÓN CON EL SERVIDOR

*Uso de un Servicio Web que provee al cliente de los métodos necesarios para comunicarse con el servidor (aspectos de configuración, notificación de nuevos pasos o sincronización)

MANEJO DE DATOS

*Uso de patrones DAO-DTO para el acceso a los datos y la transferencia de los mismos

*Códigos RFID detectados: comprobación de base de datos local previa a la notificación al servidor

*MACs Bluetooth y Wifi: notificación directa al servidor


25

Configuración del sistema: para obtener la configuración del sistema, comprobar que es correcta o cambiarla existe un conjunto de métodos implementados en ConfiguracionModel. En esta clase además se incluyen otros métodos, como los de identificación de usuario o nodo del sistema, que posteriormente describiremos en profundidad.

Manejo de datos. En este apartado tenemos dos formas de proceder claramente diferenciadas:

Por un lado, para la información proveniente de la lectura de tags RFID tenemos una base de datos local, almacenada en el propio dispositivo autónomo, y otra en remoto, almacenada en el servidor; ambas se sincronizan periódicamente para que la base de datos local esté actualizada. En estas bases de datos se almacenan los vehículos dados de alta y su identificador RFID correspondiente, de forma que al pasar un vehículo concreto podamos identificarlo individualmente. El acceso a los datos y la transferencia de los mismos se realizan usando patrones DAO-DTO; esta arquitectura nos brinda una forma de acceso a los datos totalmente abstracta. El DAO proporciona un conjunto de métodos de acceso al modelo de datos que podremos usar de forma transparente, mientras que el DTO sirve para transferir datos, sólo incluye getters, setters y constructores acordes a los campos de cada objeto concreto.

En cuanto a la información obtenida sobre dispositivos Bluetooth y Wi-Fi, esta se almacena en los tipos de datos “BtData” y “WifiData” respectivamente, como paso previo a la asignación de ciertos campos a otros de “PasoRc”, que es el DTO autogenerado desde el servidor para la transferencia de datos a través de un servicio web. Estos “pasos” contendrán información acerca del dispositivo Bluetooth o Wifi detectado, en concreto la hora de detección, la MAC y el nombre del dispositivo. Los pasos se almacenarán en un array de datos local, y se enviarán al servidor cada cierto tiempo; este tiempo se fijará en el archivo de configuración del sistema. Normalmente el tiempo entre envíos de datos al servidor será de media hora. La creación de la tabla en base de datos se hará en el servidor, desde el cliente se usarán los métodos proporcionados por el servicio web para tal efecto.

En este punto sería interesante comentar que la estabilidad del sistema se

ha probado en zonas muy transitadas del centro de Córdoba (Calle José Cruz Conde), alcanzándose picos de carga unas 200 detecciones en el mismo escaneo y no ha aparecido ningún tipo de problema.

Recopilación y envío de los datos: en este bloque incluimos escaneo Bluetooth, escaneo WiFi y lectura RFID, estas tres serán las fuentes de información del sistema. El envío de los datos lo realizan los hilos de notificación creados para tal efecto, existen tres, cada uno de ellos encargado de uno de los inputs de información: Bluetooth, WiFi y RFID.

Comunicación con el servidor: para la comunicación con el servidor se hace uso de un servicio web, basado en la implementación de un framework en Java para el envío de peticiones SOAP, usando para ello WSDL (Web Service Description Language). Una descripción WSDL de un servicio nos proporciona una interfaz al servicio, los tipos de datos que usa y donde se encuentra localizado este servicio. “Apache Axis” dispone de la herramienta “WSDL2Java”, que autogenera los proxys y los tipos de datos en Java que permiten la invocación de métodos remotos alojados en el servidor. La clase CityAnalyticsServer es la que implementa los métodos que, haciendo uso de las clases autogeneradas por Axis que componen el servicio web, se utilizan para la comunicación con el servidor.

Las diferentes capas que componen el protocolo de comunicación cliente-servidor

se implementan de la siguiente forma:


26

- Capa física/enlace: el equipo se conecta a internet usando la red de datos 3G de una operadora de telefonía móvil

- Capa de red: el cliente, alojado en el equipo de recolección de datos, establece una conexión con el servidor, quedando ambos extremos identificados por su dirección IP.

- Capa de transporte: se utiliza el protocolo TCP, orientado a conexión. - Capa de aplicación: protocolo HTTP. Servicio web con intercambio de mensajes

basado en SOAP. Autenticación basada en WS-Security de OASIS, que incorpora características de seguridad en el encabezado de los mensajes SOAP, permitiendo que un “consumidor” del servicio web pueda identificarse con un usuario y una contraseña.

Primero vamos a describir algunos de los elementos del sistema de los que haremos uso en la descripción del mismo, y luego veremos cómo interactúan estos bloques para describir el funcionamiento del sistema. Cada usuario del sistema, es decir, cada empresa u organización que utilice los servicios ofrecidos, tendrá asignado un identificador único que la diferencia de forma unívoca de los demás usuarios, este será el identificador de usuario del sistema, que junto con una contraseña rige la comunicación entre el equipo de recolección de datos (cliente) y el servidor. Este identificador de usuario sería independiente de un nombre de usuario de acceso a un hipotético panel de datos del sistema. Por otro lado, cuando hablamos del proceso de check-in nos referimos a la notificación de que se ha detectado un determinado identificador RFID. Desde la clase principal se comprueba la configuración del equipo, accediendo a un archivo de propiedades local del que se extrae el identificador único de nodo (equipo autónomo individual) y el identificador de usuario del sistema (el usuario o usuarios autorizado o autorizados para acceder a este nodo concreto), y se inicia una conexión con el servidor. Para ello se hace uso de los métodos “comprobarConfiguracion” e “iniciarSesion”, ambos pertenecientes a la clase “CityAnalyticsServer”, que además es la que provee el acceso a los métodos remotos de comunicación con el servidor para la creación de nuevos pasos, la realización del proceso de check-in, así como el inicio y la finalización de sesiones. Posteriormente, también desde la clase principal se procede a crear los modelos de escaneo Bluetooth “ServiceBluetoothModel” y WiFi “ServiceWifiModel”, así como como de lectura de RFID “ServiceCardReaderModel”. Estos modelos son básicamente “wrappers” (contenedores) para la instanciación y el lanzamiento de los hilos que forman parte de cada uno de estos procesos, así como para la creación de los monitores, encargados de controlar todo el código implicado. ServiceBluetoothModel instancia BluetoothThreadMonitor y lanza los hilos BluetoothScannerThread y BluetoothNotifierThread, encargados del escaneo y la notificación al servidor de los pasos recopilados respectivamente. ServiceWifiModel.java tiene la misma estructura, en este caso con WifiThreadMonitor, WifiScannerThread y WifiNotifierThread. Muy similar es la estructura de ServiceCardReaderModel, sólo que en este caso además de un monitor (UserIdThreadMonitor) y un hilo de notificación (UidServerNotifierThread), tenemos otro hilo de notificación, LocalPeripheralsNotifier, que realiza las operaciones pertinentes con los códigos de identificación de las tarjetas RFID en local, de forma instantánea, mientras que UidServerNotifierThread notifica al servidor de la realización de estas operaciones periódicamente. La razón de que el driver del lector de


27

tarjetas se haya estructurado de esta forma es porque este proceso también se utiliza en aplicaciones de control de acceso, relacionadas con otros proyectos distintos al que nos atañe, en las que la instantaneidad y la fiabilidad del proceso son muy importantes. El objetivo es conseguir independizar totalmente cada proceso y de esta forma poder lanzar sólo el que nos interesa en un momento dado. O también, en el caso de que falle uno de ellos por algún motivo, que esto no sea razón para que los demás también fallen y dejen de recopilar una información que podría ser valiosa. Cualquier excepción que se produzca en alguno de los hilos que componen el sistema es reportada a un log almacenado en local en el equipo de recolección de datos. Los hilos monitores de los escaneos Bluetooth, WiFi y RFID realizan una llamada a los métodos comprobarBluetoothConf, comprobarWifiConf y comprobarRfidConf periódicamente, y estos métodos se encargan de comprobar el estado de conexión del módulo correspondiente y de enviar un email en el caso de que existiera algún error. De esta forma se identifica cuál es el nodo que tiene un problema, y cuál es el módulo que está fallando, posteriormente, accediendo al log del equipo en cuestión podemos identificar de una manera más exacta la naturaleza del problema para poder solucionarlo rápidamente. Una vez se ha completado el proceso y la información se encuentra almacenada en el servidor, se provee a los usuarios del sistema de los métodos generados por un servicio web, similar al usado para la comunicación de cada equipo autónomo con el servidor. De esta forma cada usuario puede acceder a toda la información y hacer el tratamiento de ella que estime oportuno.

4.2.1. CONFIGURACIÓN DEL SISTEMA La configuración del sistema se realiza gracias a los métodos de acceso a los datos de configuración implementados en “ConfigurationModel” y a los métodos setters y getters que provee “ServiceConfiguration”. De nuevo se repite la estructura DAO-DTO. ConfiguracionModel se implementa con un patrón singleton, este patrón está diseñado para restringir la creación de objetos pertenecientes a una clase a un único objeto. Se garantiza que la clase en cuestión sólo tenga una instancia, esto es posible gracias a que la propia clase es responsable de crear la única instancia, además se permite el acceso global a dicha instancia mediante un método de la clase. Para que no sea instanciada directamente, el constructor de la clase se declara como privado.

public class ConfiguracionModel Clase que maneja el acceso a los datos de configuración del sistema

Constructor private ConfiguracionModel(): fija la localización y el nombre de los ficheros de propiedades del sistema

Métodos

public static ConfiguracionModel getInstance(): devuelve la instancia única de la clase


28

TABLA 4-1: CLASE CONFIGURACION MODEL

public class ServiceConfiguration Clase que maneja la transferencia de datos

de configuración del sistema

Constructor public ServiceConfiguration()

Métodos

public String getIdNodo(): obtiene el identificador de nodo

public void setIdNodo(String idNodo): fija el identicador de nodo

public String getIdUsuarioWs(): obtiene el identificador de usuario para el servicio web

public void setIdUsuarioWs(): fija el identificador de usuario para el servicio web

public int comprobarConfiguracion(CityAnalyticsServer oRemoteService): comprueba si los ficheros de configuración existen y son accesibles para la aplicación. Obtiene el identificador de nodo del equipo y configura la lista de nodos (NodoRc) a los que el usuario (UsuarioRc) tiene acceso

public synchronized ServiceConfiguration getConfiguracion(): Obtiene la configuración del sistema

public synchronized boolean storeConfiguracion(ServiceConfiguration oConf): Guarda la configuración con los valores de los atributos en el objeto pasado como parámetro

public UsuarioRc getUsuario(): Obtiene el usuario del sistema con el que nos vamos a autenticar para consumir los servicios web, obteniéndolo desde la configuración guardada. Devuelve un objeto UsuarioRc con los datos de identificación y autenticación.

Public NodoRc getNodo(): Obtiene el nodo que tengamos configurado tras habernos conectado y seleccionado el nodo correspondiente. Devuelve un objeto NodoRc con los valores obtenidos de la configuración del sistema.


29

public String getPassWs(): obtiene la contraseña para el servicio web

public void getPassWs(): fija la contraseña para el servicio web

public String getUrlWs(): obtiene la URL para el servicio web

public void setUrlWs(String urlWebService): fija la URL para el servicio web

public String getNombreNodo(): obtiene el nombre del nodo

public void setNombreNodo(String nombreNodo): fija el nombre del nodo

TABLA 4-2: CLASE SERVICE CONFIGURATION

4.2.2. MANEJO DE DATOS

Primero describiremos las clases BtData y WifiData donde almacenamos los datos obtenidos de los escaneos Bluetooth y WiFi respectivamente.

public class BtData Clase que define los campos de un objeto de datos Bluetooth e implementa los métodos setters y getters correspondientes

Constructores public BtData()

public BtData(Long fecha, String mac, String name, int majorDevClass, int minorDevClass, int serviceDevClass): asigna los valores pasados como parámetros a los campos correspondientes

Métodos

public Long getFecha(): obtiene la fecha de detección

public void setFecha(Long fecha): fija la fecha de detección

public String getMac(): obtiene la MAC del dispositivo

public void setMac(String mac): fija la MAC del dispositivo

public String getName(): obtiene el nombre del dispositivo

public void setName(String name): fija el nombre del dispositivo


30

TABLA 4-3: CLASE BT DATA

public class WifiData Clase que define los campos de un objeto de datos Wi-Fi e implementa los métodos setters y getters correspondientes

Constructores public WifiData()

public WifiData(Long fecha, String mac): asigna los valores pasados como parámetros a los campos correspondientes

Métodos

public Long getTinicio(): obtiene el instante de detección

public void setTinicio(Long tInicio): fija el instante de detección

public Long getTfin(): obtiene el instante en que se deja de detectar el dispositivo

public void setTfin(Long Tfin): fija el instante en que se deja de detectar el dispositivo

public String getMac(): obtiene la MAC del dispositivo

public void setMac(String mac): fija la MAC del dispositivo

public int getMajorDevClass(): obtiene el tipo genérico de dispositivo

public void setMajorDevClass(int majorDevClass): fija el tipo genérico de dispositivo

public int getMinorDevClass(): obtiene el tipo específico de dispositivo

public void setMinorDevClass(int minorDevClass): fija el tipo específico de dispositivo

public int getServiceDevClass(): obtiene el identificador de servicios soportados por el dispositivo

public void setServiceDevClass(int serviceDevClass): fija el identificador de servicios soportados por el dispositivo


31

TABLA 4-4: CLASE WIFI DATA

Las clases que atañen al manejo de los datos obtenidos vía lectura RFID son la clase “PersistenceObject” se ocupa del acceso a los datos (DAO), y las clases “Usuario” y “ColaUids” de la transferencia de datos (DTO), aunque en este caso también implementan la clase abstracta “createTables” de PersistenceObject, que será diferente para cada una de ellas.

public abstract class PersistenceObject Clase que maneja el acceso a la base de datos local de usuarios con identificador RFID

Constructor public PersistenceObject(): llama al método tableExists

Métodos

private boolean tableExists(): comprueba la existencia de la tabla

public abstract String createTables(): método abstracto que se implementa en cada instancia de la clase

public String getTableName(): obtiene el nombre de la tabla

public boolean storeDataFrom(Object newValuesObject): edita un objeto (un DTO), asignando al objeto los valores de los campos del objeto de su misma clase pasado como parámetro

public boolean create(): crea o edita un objeto en función de los valores de los campos del objeto actual en el objeto identificado por el valor del campo de primary key.

public List<Object> find(): obtiene los objetos del tipo en una lista, filtrando por los valores del objeto.

public List<Object> findAll(): obtiene todos los objetos del tipo en un array

public boolean delete(): elimina un objeto del DS identificado por el valor del campo de primary key.

TABLA 4-5: CLASE PERSISTENCE OBJECT


32

public class Usuario Clase que se extiende de PersistenceObject y maneja la transferencia de datos de objetos de tipo Usuario

Métodos

public String getUserId(): obtiene el identificador de usuario

public void setIUserId(String userId): fija el identicador RFID de usuario

public Long getFechaInicio(): obtiene la fecha de alta del usuario en el sistema

public void setFechaInicio(Long fechaInicio): fija la fecha de alta del usuario en el sistema

public Long getFechaFin(): obtiene la fecha de baja del usuario en el sistema

public void setFechaFin(Long fechaFin): fija la fecha de baja del usuario en el sistema

public String createTables(): crea la tabla con los campos específicos del objeto Usuario

TABLA 4-6: CLASE USUARIO

public class ColaUids Clase que maneja la cola de identificadores RFID pendientes de enviar al servidor

Métodos

public String getUserId(): obtiene el identificador de usuario en cola

public void setIUserId(String userId): fija el identicador RFID de usuario en cola

public Long getFecha(): obtiene la fecha de detección del usuario en cola

public void setFecha(Long fecha): fija la fecha de detección del usuario en cola

public String createTables(): crea la tabla con los campos específicos del objeto ColaUids

TABLA 4-7: CLASE COLA UID'S


33

public class NodoRc Clase autogenerada por la herramienta

WSDL de Apache Axis, implementa los métodos setters y getters

Constructor NodoRc()

Métodos

public String getDescripcion(): obtiene la descripción del nodo

public void setDescripcion(String): fija la descripción del nodo

public Float getLatitud(): obtiene la latitud del nodo

public void setLatitud(Float): fija la latitud del nodo

public Float getLongitud(): obtiene la longitud del nodo

public void setLongitud(Float): fija la longitud del nodo

public Long getIdNodo(): obtiene el identificador de nodo

public void setIdNodo(Long): fija el identificador de nodo

TABLA 4-8: CLASE NODORC

public class PasoRc Clase autogenerada por la herramienta WSDL de Apache Axis, implementa los métodos setters y getters

Constructor PasoRc()

Métodos

public String getMajorDeviceClass()

public void setMajorDeviceClass(String)

public String getMinorDeviceClass()

public void setMinorDeviceClass(String)

public String getServiceClass()


34

public void setServiceClass(String)

public Long getIdNodo(): obtiene el identificador del nodo que ha detectado el paso

public void setIdNodo(Long): fija el identificador del nodo que ha detectado el paso

public Long getTinicio(): obtiene el instante de detección del paso

public void setTinicio(Long): fija el instante de detección del paso

public Long getTfin(): obtiene el instante de fin de detección del paso

public void setTfin(Long): fija el instante de fin de detección del paso

TABLA 4-9: CLASE PASORC

public class UsuarioRc Clase autogenerada por la herramienta WSDL de Apache Axis, implementa los métodos setters y getters

Constructor UsuarioRc()

Métodos

public Long getIdUsuario(): obtiene el identificador de usuario

public void setIdUsuario(Long): fija el identificador de usuario

public String getPassword(): obtiene la contraseña de usuario

public void setPassword(String): fija la contraseña de usuario

public String getEmail(): obtiene el email del usuario

public void setEmail(String): fija el email del usuario

TABLA 4-10: CLASE USUARIORC


35

4.2.3. RECOPILACIÓN Y ENVÍO DE LOS DATOS

Llegados a este punto vamos a describir de una forma más detallada clases y métodos implicados en cada uno de los procesos de captura y envío de datos: Bluetooth, Wi-Fi y lectura RFID.

public class ServiceBluetoothModel Clase contenedor del escaneo Bluetooth

Constructor ServiceBluetoothModel(): inicializa un nuevo ConcurrentHashMap(K,V), donde la clave es el índice de antena Bluetooth y el valor un nuevo BluetoothScannerThread

Métodos

public boolean iniciar (CityAnalyticsServer oServer): inicia las actividades de escaneo comprobando previamente que la configuración del sistema está completa y se puede realizar el escaneo

public void parar(): detiene el escaneo de dispositivos del sistema

public int getEstado(): Obtiene un código que indica el estado de los hilos en el instante de la llamada. Los códigos están definidos en esta misma clase como constantes.

TABLA 4-11: CLASE SERVICE BLUETOOTH MODEL

public class BluetoothScannerThread Clase que se genera como hilo y realiza el escaneo de dispositivos

Constructor BluetoothScannerThread(BluetoothThreadMonitor oMonitor, String dev_addr): recibe una lista con las MAC de las antenas Bluetooth conectadas

Métodos

public void run(): realiza una llamada al método nativo blueScan, que obtiene los datos de los dispositivos detectados y los guarda en un array de BtData. Implementa un listener que llama al método onBTscan del monitor paśandole el array de datos recogido


36


TABLA 4-12: CLASE BLUETOOTH SCANNER THREAD

public class BluetoothThreadMonitor Clase que sincroniza los hilos en sus

acciones de generar pasos y enviarlos al servidor usando un servicio web

Constructor BluetoothThreadMonitor(ServiceConfiguration oConf): crea los ficheros “lastScanned.csv” y “lastSendNum.csv” encargados de almacenar los últimos dispositivos escaneados y enviados al servidor respectivamente. Además fija el intervalo de tiempo entre envíos

Métodos

public synchronized void onBTScan(BtData[] dataBuffer): a partir del array de datos de dispositivo recibido genera los pasos pertinentes

public void insertarPasos(PasoRC[] oPaso): inserta en el fichero almacén de pasos los nuevos pasos escaneados

public synchronized void devolverPasos(PasoRC[] oPaso): devuelve al comienzo del fichero almacén de pasos los pasos que no se han podido enviar

public synchronized PasoRC[] obtenerPasos(): lee los pasos almacenados en el archivo almacén de pasos

private PasoRc[] convertToPasoArray(String content): convierte los datos del archivo .csv de almacén de pasos en un array de objetos de tipo PasoRC

public int comprobarBluetoothConf(): comprueba el estado del dispositivo Bluetooth, así como su configuración general (hora, estado de conexión o versión del cliente)

TABLA 4-13: CLASE BLUETOOTH THREAD MONITOR


37

public class BluetoothNotifierThread Clase que se genera como hilo y notifica al servidor los datos de usuarios recopilados

Constructor BluetoothNotifierThread(BluetoothThreadMonitor oMonitor)

Métodos

public void run(): crea una instancia del usuario del sistema con el que nos conectaremos a partir del método getUsuario de una instancia de ConfiguracionModel, obtiene los pasos desde el monitor con el método obtenerPasos y los envía al servidor, si no fuera posible se devuelven al propio monitor con devolverPasos.

public void parar(): detiene el proceso de notificación al servidor

TABLA 4-14: CLASE BLUETOOTH NOTIFIER THREAD

public class ServiceWifiModel Clase contenedor del escaneo Wifi

Constructor ServiceWifiModel()

Métodos

public boolean iniciar (CityAnalyticsServer oServer): inicia las actividades de escaneo comprobando previamente que la configuración del sistema está completa y se puede realizar el escaneo



TABLA 4-15: CLASE SERVICE WIFI MODEL


38

public class WifiScannerThread Clase que se genera como hilo y realiza el escaneo de dispositivos

Constructor WifiScannerThread(WifiThreadMonitor oMonitor)

Métodos

public void run(): comienza la captura de paquetes “raw” en modo promiscuo usando la librería “jpcap”. La información de interés obtenida, es decir, las direcciones físicas WiFi obtenidas se le pasan al monitor a través del método onWifiScan


TABLA 4-16: CLASE WIFI SCANNER THREAD

public class WifiThreadMonitor Clase que sincroniza los hilos en sus acciones de generar pasos y enviarlos al servidor usando un servicio web

Constructor WifiThreadMonitor(ServiceConfiguration oConf): crea los ficheros “wifiLastScanned.csv” y “wifiLastSendNum.csv” encargados de almacenar los últimos dispositivos escaneados y enviados al servidor respectivamente. Previamente a la inserción de nuevas MAC detectadas en los ficheros almacén, estas se guardan en un array auxiliar, en el que se “resumen”, es decir, se eliminan las repetidas en el mismo intervalo temporal. Esta clase además fija el intervalo de tiempo entre envíos

Métodos

public synchronized void onWifiScan(WifiData[] dataBuffer): a partir del array de datos de dispositivo recibido genera los pasos pertinentes

public void insertarPasos(PasoRC[] oPaso): inserta en el fichero almacén de pasos los nuevos pasos escaneados

public synchronized void devolverPasos(PasoRC[] oPaso): devuelve al comienzo del fichero almacén de pasos los pasos que no se han podido enviar

public synchronized PasoRC[] obtenerPasos(): lee los pasos almacenados en el archivo almacén de pasos


39

private PasoRc[] convertToPasoArray(String content): convierte los datos del archivo .csv de almacén de pasos en un array de objetos de tipo PasoRC

private ArrayList<PasoRc> resumirPasos(PasoRc[] aPasos): resume los pasos realizados en función de un intervalo definido para el tiempo máximo entre pasos de un mismo dispositivo

public int comprobarWifiConf(): comprueba el estado del dispositivo Wi-Fi, así como su configuración general (hora, estado de conexión o versión del cliente)

TABLA 4-17: CLASE WIFI THREAD MONITOR

public class WifiNotifierThread Clase que se genera como hilo y notifica al servidor los datos de usuarios recopilados

Constructor WifiNotifierThread(WifiThreadMonitor oMonitor)

Métodos

public void run(): crea una instancia del usuario del sistema con el que nos conectaremos a partir del método getUsuario de una instancia de ConfiguracionModel, obtiene los pasos desde el monitor con el método obtenerPasos y los envía al servidor, si no fuera posible se devuelven al propio monitor con devolverPasos.


TABLA 4-18: CLASE WIFI NOTIFIER THREAD

public class ServiceCardReaderModel Clase contenedor de las actividades de lectura RFID

Constructor ServiceCardReaderModel()


40

Métodos

public boolean iniciar (CityAnalyticsServer oServer): inicia la lectura RFID

public void parar(): detiene la lectura RFID del sistema


TABLA 4-19: CLASE SERVICE CARD READER MODEL

public class CardReaderScannerThread Clase que se genera como hilo y realiza el escaneo RFID

Constructor CardReaderScannerThread(UserIdThreadMonitor oMonitor): implementa un Listener en el puerto serie y, tras un evento, captura los datos recibidos en el mismo. Descarta caracteres de inicio y fin de trama y se queda con el identificador RFID si la lectura se ha realizado correctamente. Notifica el identificador leído a través del método notificarUIDLeido de UserIdThreadMonitor

Métodos

public void run(): abre el puerto serie y se queda a la escucha


TABLA 4-20: CLASE CARD READER SCANNER THREAD

public class UserIdThreadMonitor Clase que sincroniza los hilos en sus acciones de obtener identificadores RFID y notificar local y remotamente los datos obtenidos

Constructor UserIdThreadMonitor(): inicializa dos objetos ConcurrentHashMap(K,V), uno para la cola de identificadores RFID local y otro para la cola de envío al servidor, donde la clave será el número de elementos en cola y el valor el identificador RFID


41

Métodos

public synchronized void onServerNotificationCompleted (String uid, Long fecha): elimina de la cola de identificadores a enviar al servidor el identificador pasado como argumento

public synchronized void notificarUIDLeido(String uid): añade a las colas de identificadores RFID local y remota un nuevo identificador pasado como argumento

public synchronized ColaUids[] obtenerUIDs(): obtiene todos los registros de la cola remota de identificadores RFID

public synchronized String obtenerLocalUID(): obtiene todos los registros de la cola local de identificadores RFID

public int comprobarRfidConf(): comprueba el estado del dispositivo RFID, así como su configuración general (hora, estado de conexión o versión del cliente)

TABLA 4-21: CLASE USER ID THREAD MONITOR

public class LocalPeripheralsNotifierThread

Clase que se genera como hilo y notifica de forma local los identificadores de usuario leídos

Constructor LocalPeripheralsNotifierThread(UserIdThreadMonitor oMonitor)

Métodos

public void run(): llama al método obtenerLocalUID de UserIdThreadMonitor para obtener el identificador RFID leído, comprueba que existe en la base de datos y lo añade a la cola de envío

public void parar(): detiene el proceso de notificación local

TABLA 4-22: CLASE LOCAL PERIPHERALS NOTIFIER THREAD


42

public class UidServerNotifierThread Clase que se genera como hilo y notifica al servidor los identificadores de usuario leídos

Constructor UidServerThread(UserIdThreadMonitor oMonitor)

Métodos

public void run(): llama al método obtenerUIDs de UserIdThreadMonitor para obtener a partir de la cola local de identificadores RFID los que están por notificar al servidor. Luego llama al método doCheckin de CityAnalyticsServer para realizar la notificación remota, y finalmente con onServerNotificationCompleted se eliminan de la cola los identificadores ya notificados


TABLA 4-23: CLASE UID SERVER NOTIFIER THREAD

4.2.4. COMUNICACIÓN CON EL SERVIDOR

public class CityAnalyticsServer Clase que Provee el acceso a los métodos remotos para creación de pasos e inicio de sesiones.

Constructor CityAnalyticsServer()

Métodos

public UsuarioRc[] getSyncData(Long idNodo, String user, String md5Pass): obtiene del servidor la lista de nodos en la que el usuario puede crear pasos

public NodoRc[] getNodos(): obtiene del servidor la lista de nodos en la que el usuario puede crear pasos


43

public PasoRc[] crearPaso(PasoRc[] aPasos, UsuarioRc oUsuario): crea un nuevo paso en el servidor según los valores indicados en el objeto que se pasa como primer parámetro, el segundo parámetro se refiere al usuario que realiza la inserción del paso con los datos de identificación del mismo.

public boolean iniciarSesion(NodoRc oNodo, UsuarioRc oUsuario, Long fechaInicio): inicia una nueva sesión de uso del sistema para la creación de pasos sobre un nodo concreto

public boolean finalizarSesion(NodoRc oNodo, UsuarioRc oUsuario): finaliza una sesión de uso del sistema de creación de pasos sobre un nodo concreto

public boolean doCheckin(Long idNodo, String user, String password, String uid, Long time): realiza la acción de check-in en un nodo especificado por idNodo accediendo al sistema con un usuario y una contraseña especificados por el segundo y el tercer argumento. Uid es el Identificador RFID que realiza el check-in.

public void configureService(): realiza la configuración del servicio

TABLA 4-24: CLASE CITYANALYTICS SERVER


44

5 . C A S O P R Á C T I C O : A N Á L I S I S D E L R E C O R R I D O C Ó R D O B A –

S E V I L L A P O R A - 4

Vamos a analizar un ejemplo de implantación de este sistema en una zona concreta, en este

caso en la principal arteria de comunicación entre Córdoba y Sevilla, el tramo de la autovía A-4

que une ambas ciudades.

5.1. DESCRIPCIÓN

Para la implantación del sistema en esta zona concreta se propone la instalación de los nodos

de recopilación de datos en puntos kilométricos situados después de las salidas de las

localidades principales que se encuentran a lo largo de este tramo de autovía entre Córdoba y

Sevilla. Con esta arquitectura el sistema sería capaz de proporcionar información concreta no

sólo de los vehículos que salen de Córdoba hacia Sevilla, sino también de cuáles de ellos se

desvían hacia una zona específica y cuáles no.

Se propone colocar cuatro nodos autónomos en la autovía: a la salida de Córdoba y a

su paso por las localidades de La Carlota, Écija y Carmona. Las localizaciones se especifican a

continuación junto con una fotografía del lugar exacto, en una de ellas se aprovechará una

farola como poste, en las otras tres instalaremos un poste para ello.

FIGURA 11. LOCALIZACIÓN: AUTOVÍA DEL SUR A-4. P.K. 410,00 MARGEN IZQUIERDA


45

FIGURA 12.LOCALIZACIÓN: AUTOVÍA DEL SUR A-4. P.K. 435,00 MARGEN IZQUIERDA


46



47

En el siguiente apartado, se especificará el presupuesto de despliegue y mantenimiento

del sistema para este hipotético caso práctico.

5.2. PRESUPUESTO DE DESPLIEGUE Y MANTENIMIENTO

A continuación se muestran las tablas de presupuestos. Se incluye una tabla con el presupuesto total por partidas, desglosando el IVA por separado. Asimismo se incluyen otra tabla detallando el presupuesto de materiales.



48

Presupuesto total del proyecto:

Componentes hardware 2.613,32 €

Sistema de alimentación 1.736,42 €

Total materiales 4.349,74 €

Instalación de los equipos 475,71 € por equipo 1.902,84 €

Instalación poste 428,31 € por poste 1.284,93 €

Total instalación 3.187,77 €

Mantenimiento del sistema 209 € por equipo al año

836 € al año

Total 7.537,51 € + 836 €/año

IVA 1.582,88 € + 175,56 €/año

Total del proyecto 9.120,39 € + 1.011,56 €/año

TABLA 5-1: PRESUPUESTO TOTAL DEL PROYECTO

Presupuesto de materiales:

Elemento Precio unitario Unidades Total

Componentes hardware

Raspberry Pi 19,75 € 4 79,00 €

Antena Bluetooth 4,74 € 4 18,96 €

Antena WiFi 32,39 € 4 129,56 €

Modem 3G 27,65 € 4 110,60 €

Tag RFID activo 7,11 € 20 142,20 €

Placa auxiliar 18,96 € 4 75,84 €

Lector RFID 110,60€ 4 442,40 €

Armario de intemperie antivandálico 394,21 € 4 1.576,84 €

Caja estanca 9,48 € 4 37,92 €

Sistema de alimentación

Panel solar 73,47 € 4 293,88 €

Soporte para panel solar 60,04 € 4 240,16 €

Poste para instalación 244,9 € 3 734,70 €

Regulador solar 28,44 € 4 113,76 €

Batería 88,48 € 4 353,92 €

Total del presupuesto de materiales 4.349,74 €

TABLA 5-2: PRESUPUESTO DE MATERIALES

Este es un caso hipotético en el cual la instalación de los equipos de recopilación de datos se realiza en todos los casos en armarios colocados específicamente para este fin y con alimentación basada en energía solar, sin embargo en un caso real se trataría de evitar en la medida de lo posible la instalación de esta infraestructura específica, usando en su lugar armarios ya existentes pertenecientes a la Dirección General de Tráfico o a la Red de Carreteras de la Junta. De esta forma se suprimirían gastos importantes tanto en material como en instalación y mantenimiento.


49

5.3. ESTUDIO COMPARATIVO DE COSTES

Andalucía cuenta actualmente con una red de carreteras autonómicas de aproximadamente 10000 kilómetros y una red provincial de 9000 kilómetros. Implantar un sistema de información como el que se pretende, con los costes actuales de las empresas que operan e introduciendo precios tipo para acuerdos de este tipo anuales y por descuento de volúmenes de información, tendría un coste de implantación prácticamente inviable. Realizando una estimación conservadora, podría llevarse a cabo una rápida implantación del sistema de información con un ahorro de entre un 73 y un 85% frente a los sistemas de reconocimiento por cámaras, o frente a los competidores actuales Bluetooth, según podemos ver en el siguiente estudio de mercado:

Sistema por cámaras Competidores actuales Bluetooth

Sistema propuesto

Coste de implantación por

dispositivo

25.000 – 30.000 € 7.500 – 15.000 € 2.449,33 €

Coste mantenimiento por dispositivo/año

1.000 € 500 € 252,89 €

Dispositivos necesarios por cada

100 km (aproximadamente)

15 20 20

Dispositivos necesarios para

carreteras autonómicas en

Andalucía (aproximadamente)

2.850 3.800 3800

Coste de implantación

78.375.000 € 42.750.000 € 9.307.455,52 €

Coste de mantenimiento anual

3.420.000 € 1.900.000 € 960.982 €

Inversión en 5 años 92.625.000 € 52.250.000 € 14.112.365,52 €

Ahorro producido 84,65 % 72,99 % -

TABLA 5-3: ESTUDIO DE MERCADO

Estos datos sitúan los costes, tanto de implantación como de mantenimiento, del

sistema propuesto como sensiblemente inferiores a sus inmediatos competidores.


50

6 . R E S U L T A D O S O B T E N I D O S

Debido a que el caso práctico propuesto no se encuentra aún implantado, se mostrarán y

analizarán los datos obtenidos a partir de un prototipo del equipo de recolección de datos

situado en la carretera E-902, en Granada, dónde se implantó en un armario de la DGT,

aprovechando la alimentación existente. La razón de que se implantara en este lugar y no

en Córdoba es simplemente que no era necesario ningún proceso burocrático por tratar

directamente con el responsable de la DGT en esta zona. De esta forma podíamos hacer

pruebas de campo desde el primer momento sin realizar ningún tipo de instalación de

sistema de alimentación.

Posteriormente se hará una descripción del sistema CityAnalytics y veremos cómo

quedan estos datos después del proceso de data mining al que los somete este sistema

propiedad de Ciudad 2020 SL. El objetivo es observar un ejemplo real de uso por parte de

un tercero de los datos recopilados por los equipos.

También veremos un ejemplo realizado con los equipos propios de CityAnalytics,

que aunque son totalmente distintos en hardware y software a los que tiene como objeto

este proyecto, sí son similares en cuanto a los datos que recopilan. Este ejemplo es muy

ilustrativo y refleja de una manera clara la importante cantidad de información útil para

un eventual usuario que albergan los datos obtenidos, en este caso no se trata de contar

vehículos, sino personas que acuden a un supermercado.

6.1. EXPERIMENTOS

6.1.1. DATOS OBTENIDOS POR EL PROTOTIPO SITUADO EN E-902, GRANADA

Para nuestro primer experimento nos centraremos en la captura de dispositivos Bluetooth y WiFi, en este caso no vamos a utilizar el lector RFID, pues no existen tags activos que poder detectar en esta situación.

Usando el prototipo del equipo de recolección de datos situado en la carretera E-902 de Granada obtendremos el número de dispositivos detectados en cada instante en una franja temporal, veremos por un lado los detectados vía Bluetooth y por otro los detectados vía WiFi. Además, en el caso del Bluetooth, vamos a diferenciar entre vehículos y personas, gracias a la información incluida en la MAC. Los datos obtenidos corresponden al mes transcurrido entre el 12 de marzo y el 12 de abril del año 2013, y para observar un periodo de tiempo más completo también nos centraremos en la semana del 18 de marzo al 24 de marzo.

En primer lugar mostraremos las gráficas correspondientes al mes completo, para los dispositivos detectados por Bluetooth y WiFi respectivamente. Se diferencian claramente los días, así como una tendencia a la detección de un menor número de dispositivos los fines de semana, esto se debe a que se trata de una zona frecuentada por


51

0

500

1000

1500

2000

2500

3000

3500

4000

4500

13

65

71

72

76

82

91

36

56

74

07

68

29

13

65

63

08

76

82

91

36

55

87

67

68

29

13

65

54

44

76

82

91

36

55

01

27

68

29

13

65

45

80

76

82

91

36

54

14

87

68

29

13

65

37

16

76

82

91

36

53

28

47

68

29

13

65

28

52

76

82

91

36

52

42

07

68

29

13

65

19

88

76

82

91

36

51

55

67

68

29

13

65

11

24

76

82

91

36

50

69

27

68

29

13

65

02

60

76

82

91

36

49

82

87

68

29

13

64

93

96

76

82

91

36

48

96

47

68

29

13

64

85

32

76

82

91

36

48

10

07

68

29

13

64

76

68

76

82

91

36

47

23

67

68

29

13

64

68

04

76

82

91

36

46

37

27

68

29

13

64

59

40

76

82

91

36

45

50

87

68

29

13

64

50

76

76

82

91

36

44

64

47

68

29

13

64

42

12

76

82

91

36

43

78

07

68

29

13

64

33

48

76

82

91

36

42

91

67

68

29

13

64

24

84

76

82

91

36

42

05

27

68

29

13

64

16

20

76

82

91

36

41

18

87

68

29

13

64

07

56

76

82

91

36

40

32

47

68

29

13

63

98

92

76

82

91

36

39

46

07

68

29

13

63

90

28

76

82

91

36

38

59

67

68

29

13

63

81

64

76

82

91

36

37

73

27

68

29

13

63

73

00

76

82

91

36

36

86

87

68

29

13

63

64

36

76

82

91

36

36

00

47

68

29

13

63

55

72

76

82

91

36

35

14

07

68

29

13

63

47

08

76

82

91

36

34

27

67

68

29

13

63

38

44

76

82

91

36

33

41

27

68

29

13

63

29

80

76

82

91

36

32

54

87

68

29

13

63

21

16

76

82

91

36

31

68

47

68

29

13

63

12

52

76

82

91

36

30

82

07

68

29

Nú

me

ro d

e d

isp

osi

tivo

s

Tiempo

0

500

1000

1500

2000

2500

3000

3500

4000

13

65

71

72

76

82

91

36

56

74

07

68

29

13

65

63

08

76

82

91

36

55

87

67

68

29

13

65

54

44

76

82

91

36

55

01

27

68

29

13

65

45

80

76

82

91

36

54

14

87

68

29

13

65

37

16

76

82

91

36

53

28

47

68

29

13

65

28

52

76

82

91

36

52

42

07

68

29

13

65

19

88

76

82

91

36

51

55

67

68

29

13

65

11

24

76

82

91

36

50

69

27

68

29

13

65

02

60

76

82

91

36

49

82

87

68

29

13

64

93

96

76

82

91

36

48

96

47

68

29

13

64

85

32

76

82

91

36

48

10

07

68

29

13

64

76

68

76

82

91

36

47

23

67

68

29

13

64

68

04

76

82

91

36

46

37

27

68

29

13

64

59

40

76

82

91

36

45

50

87

68

29

13

64

50

76

76

82

91

36

44

64

47

68

29

13

64

42

12

76

82

91

36

43

78

07

68

29

13

64

33

48

76

82

91

36

42

91

67

68

29

13

64

24

84

76

82

91

36

42

05

27

68

29

13

64

16

20

76

82

91

36

41

18

87

68

29

13

64

07

56

76

82

91

36

40

32

47

68

29

13

63

98

92

76

82

91

36

39

46

07

68

29

13

63

90

28

76

82

91

36

38

59

67

68

29

13

63

81

64

76

82

91

36

37

73

27

68

29

13

63

73

00

76

82

91

36

36

86

87

68

29

13

63

64

36

76

82

91

36

36

00

47

68

29

13

63

55

72

76

82

91

36

35

14

07

68

29

13

63

47

08

76

82

91

36

34

27

67

68

29

13

63

38

44

76

82

91

36

33

41

27

68

29

13

63

29

80

76

82

91

36

32

54

87

68

29

13

63

21

16

76

82

91

36

31

68

47

68

29

13

63

12

52

76

82

91

36

30

82

07

68

29

Nú

me

ro d

e d

isp

osi

tivo

s

Tiempo

trabajadores y estudiantes. También se observa un comportamiento fuera de lo normal durante la semana correspondiente a Semana Santa.

Podemos ver como las gráficas obtenidas por los medios se asemejan mucho entre ellas, lo que nos dice que la fiabilidad de ambos métodos es similar, no obstante, en el caso que nos ocupa, que es contar vehículos, el Bluetooth ofrece el plus de darnos la posibilidad de diferenciar entre dispositivos móviles personales o dispositivos propios de un vehículo, como podría ser un manos libres o un GPS. En las tres siguientes gráficas nos centramos en

FIGURA 15: DISPOSITIVOS BLUETOOTH DETECTADOS DEL 12 MARZO AL 12 ABRIL

FIGURA 16: DISPOSITIVOS WIFI DETECTADOS DEL 12 MARZO AL 12 ABRIL


52

0

500

1000

1500

2000

2500

3000

3500

Nú

me

ro d

e d

isp

osi

tivo

s

Tiempo

0

200

400

600

800

1000

1200

1400

1600

13

64

16

23

91

62

4

13

64

14

79

91

62

4

13

64

13

35

91

62

4

13

64

11

91

91

62

4

13

64

10

47

91

62

4

13

64

09

03

91

62

4

13

64

07

59

91

62

4

13

64

06

15

91

62

4

13

64

04

71

91

62

4

13

64

03

27

91

62

4

13

64

01

83

91

62

4

13

64

00

39

91

62

4

13

63

98

95

91

62

4

13

63

97

51

91

62

4

13

63

96

07

91

62

4

13

63

94

63

91

62

4

13

63

93

19

91

62

4

13

63

91

75

91

62

4

13

63

90

31

91

62

4

13

63

88

87

91

62

4

13

63

87

43

91

62

4

13

63

85

99

91

62

4

13

63

84

55

91

62

4

13

63

83

11

91

62

4

13

63

81

67

91

62

4

13

63

80

23

91

62

4

13

63

78

79

91

62

4

13

63

77

35

91

62

4

13

63

75

91

91

62

4

13

63

74

47

91

62

4

13

63

73

03

91

62

4

13

63

71

59

91

62

4

13

63

70

15

91

62

4

13

63

68

71

91

62

4

13

63

67

27

91

62

4

13

63

65

83

91

62

4

13

63

64

39

91

62

4

13

63

62

95

91

62

4

13

63

61

51

91

62

4

13

63

60

07

91

62

4

13

63

58

63

91

62

4

13

63

57

19

91

62

4

Nú

me

ro d

e d

isp

osi

tivo

Tiempo

una semana concreta, y mostramos los resultados Bluetooth obtenidos para el total de dispositivos detectados, personas y vehículos.

FIGURA 17: DISPOSITIVOS PERSONALES BLUETOOTH DETECTADOS DESDE EL SÁBADO 18 DE MARZO AL VIERNES 24 DE MARZO

FIGURA 18: DISPOSITIVOS BLUETOOTH DETECTADOS DESDE EL SÁBADO 18 DE MARZO AL VIERNES 24 DE MARZO


53

0

200

400

600

800

1000

1200

1400

1600

1800

Nú

me

ro d

e d

isp

osi

tivo

s

Tiempo

Las dos últimas gráficas nos permiten conocer el número de vehículos y de personas

que pasan por este punto en el periodo de tiempo especificado. Obviamente hablamos de

tendencias y de aproximaciones, el número real será el resultado de aplicar un sesgo positivo

al resultado obtenido. Esta es una de las cosas que hace CityAnalytics, y a continuación

veremos los resultados obtenidos por este sistema partiendo de los datos obtenidos por

nuestro prototipo de recopilación de datos situado en Granada.

En las gráficas siguientes mostramos los resultados para vehículos y personas en los

meses completos de abril y marzo, a los cuales se corresponden los datos que veremos

después. Con un cuadro a modo de ventana temporal hemos seleccionado el período que va

desde el 12 de marzo al 12 de abril.

FIGURA 19: DISPOSITIVOS BLUETOOTH PROPIOS DE VEHÍCULOS DETECTADOS DESDE EL SÁBADO 18 DE MARZO AL VIERNES 24 DE MARZO

FIGURA 20: RESULTADOS TRAS EL TRATAMIENTO DE LOS DATOS (PERSONAS). MESES DE MARZO - ABRIL


54

Estos datos pueden considerarse “reales”, pues tienen aplicado el sesgo estadístico

correspondiente. Sin embargo la tendencia está marcada por los datos especificados

anteriormente. Además, en la misma gráfica se incluye información adicional, relacionada con

las personas (vehículos) que se detectan como primera visita o como recurrentes.

A continuación los datos numéricos obtenidos agrupados en meses, concretamente los

de marzo y abril.

En los cuadros de datos se habla de personas y vehículos que han pasado por un

establecimiento, esto se debe a la naturaleza original del sistema, pero se está refiriendo a

vehículos y personas que pasan por ese punto de la carretera.

FIGURA 21: RESULTADOS TRAS EL TRATAMIENTO DE LOS DATOS (VEHÍCULOS). MESES DE MARZO - ABRIL

FIGURA 22: DATOS MARZO

FIGURA 23: DATOS ABRIL


55

6.1.2. DATOS OBTENIDOS POR UN EQUIPO DE CITYANALYTICS SITUADO EN UN SUPERMERCADO

El sistema CityAnalytics, en funcionamiento desde el año 2010 ha sido la idea base desde la que ha partido el presente proyecto. Este sistema hace un análisis pormenorizado del tránsito de personas por numerosas localizaciones de la ciudad de Córdoba, basándose en este caso únicamente en las redes Bluetooth detectadas y usando una serie de algoritmos para estimar, de una forma muy aproximada a la realidad (como se expresa en el estudio anexo a este proyecto), información derivada de los datos obtenidos.

Un usuario abonado al servicio, en este ejemplo se trata de uno de los supermercados de una conocida cadena, tiene acceso a un panel de control en el que puede observar las estimaciones derivadas de los datos recopilados por el equipo situado en dicha localización, la figura 24 es una vista general de dicho panel.

La información que aparece en el panel se resume en: número de personas en cada momento, fidelidad de la visita (personas recurrentes), visitantes nuevos, y una consideración de tipología de los visitantes en base a si son habituales o no. Esta información se presenta tanto de forma numérica como gráfica, y se puede obtener en base al día, mes o año que se seleccione.


56

La gráfica que aparece en la parte superior derecha del panel se puede seleccionar

entre los datos recopilados, la tipología de los visitantes y la fidelidad de los mismos.

En las figuras siguientes se muestran estos datos para este caso concreto. En este caso

hemos seleccionado el mes de Julio de 2013, y podemos observar que la gráfica que ilustra el

número de personas en relación al tiempo tiene una forma muy similar para cada una de las

semanas, además también se observa cierto decaimiento en el número de visitantes a lo largo

del mes, quizás debido al comienzo del período vacacional.

FIGURA 24. VISTA GENERAL DEL PANEL DE CITYANALYTICS


57

FIGURA 26. TIPOLOGÍA DE VISITANTES

FIGURA 25. NÚMERO DE PERSONAS POR DÍAS EN JULIO


58

Otra de las gráficas que podemos consultar es la que muestra las horas punta en

relación a, en este caso, el número de visitantes al comercio en cuestión.

FIGURA 28. HORAS PUNTA

FIGURA 27. PRIMERA VISITA O VARIAS


59

Estos ejemplos dan una idea del camino a seguir tanto en el tratamiento de la

información obtenida por los equipos de recopilación de datos como en el modelo de

presentación de la información al usuario. Además muestran el potencial que tiene el sistema

propuesto en este proyecto para infinidad de usuarios que deseen tener datos reales de

afluencia a su negocio.


60

7 . C O N C L U S I O N E S Y T R A B A J O F U T U R O

El sistema de recopilación de información sobre el estado del tráfico desarrollado en el

presente proyecto, a diferencia de las tecnologías usadas actualmente, y gracias al uso de

tecnología Bluetooth y WiFi, es prácticamente no intrusivo. Además ofrece una

representatividad en los datos con un error aproximado de un 8,85%, lo que es bastante

aceptable debido a su bajo coste, rápida implantación y escaso mantenimiento, los datos

económicos que muestra el caso práctico propuesto demuestran este extremo. La

privacidad de los datos está garantizada, pues no se almacena ninguna información que

pueda identificar a una persona concreta, sólo una encriptación de la dirección física de su

dispositivo electrónico.

El equipo de recolección de datos basa su estructura en un ordenador integrado en

una única placa y del tamaño de una tarjeta de crédito, la Raspberry Pi, que cumple

también con los objetivo de bajo coste y bajo consumo impuestos para este proyecto. El

equipo, usando el sistema de alimentación propuesto, basado en energía solar, alcanza una

autonomía total. El software que integra el equipo de recolección de datos está

programado en Java, y se integra en un programa de tipo daemon, lo que garantiza el inicio

automático del mismo con el arranque del sistema.

La información recopilada por el sistema se ofrecerá a terceros a través de un

servicio web, estos podrán tratarla y utilizarla como mejor se adapte a sus necesidades.

Por todas estas razones podemos concluir que se han cumplido los objetivos

marcados al inicio, aunque este proyecto tiene todavía un largo recorrido. Como trabajo

futuro queda por un lado, añadir nuevas variables al sistema, nuevos inputs con los que

poder trabajar, y por otro la realización de un sistema de tratamiento de la información lo

más completo posible.

Centrándonos en las nuevas variables que podríamos añadir al sistema, estas podrían ser variables como la temperatura o el nivel de ruido. Para ello sería necesario añadir nuevos sensores al hardware del equipo y crear los hilos pertinentes para el manejo de estas variables.

Las posibilidades en el tratamiento de la información recibida, estas son infinitas, además de ofrecer los datos a terceros gracias a la conexión al servidor mediante un servicio web, se podría generar un sistema de tratamiento de la información propio, gracias al cual poder ofrecer a la población una página web que contenga información acerca de los principales datos de movilidad en tiempo real, así como predicciones en base a la información recopilada durante cierto tiempo.


61

Podría ofrecerse una estimación de número de vehículos en cada nodo, una matriz de orígenes y destinos, la velocidad media de los vehículos, recurrencia y fidelidad de los usuarios de las vías o el cálculo del tiempo de recorrido entre dos puntos. Además podría generarse un servicio de alertas automatizado y en tiempo real cuando se cumplan una serie de condiciones dadas. Este servicio sería configurable para su envío a una dirección de correo electrónico, por ejemplo, “quiero recibir un correo electrónico cada día con el tiempo medio que en ese momento se tarda en ir desde el punto A al punto B de la ciudad de Córdoba” e integrable en redes sociales, los seguidores de la cuenta de Twitter asociada el proyecto tendrían información en tiempo real y de primera mano sobre el estado del tráfico. En cuanto al sistema de check-in RFID, determinador usuarios del sistema podrían estar interesados en colocar tags activos en vehículos de empresa para obtener información sobre si estos vehículos realizan un determinado recorrido.

El hecho de contar en el mismo equipo con un sistema de conteo de dispositivos y

otro de check-in RFID abre las posibilidades de mercado hacia la organización de eventos multitudinarios, como podría ser el EBE (Evento Blog España), dónde mi empresa ha utilizado equipos similares al que es objeto de este proyecto para fines de registro e identificación con integración en redes sociales.

El punto más negativo de este sistema podría ser que los datos obtenidos no dejan

de ser una aproximación, y la fiabilidad real del número de vehículos que se obtiene es relativa, y depende en gran porcentaje del tratamiento posterior que se haga de la información. Sin embargo, no se pretende que esta sea la fortaleza del sistema, sino que lo sea la posibilidad de analizar grandes cantidades de datos y encontrar tendencias gracias a la identificación individual, lo que puede posibilitar la continuidad del proyecto gracias al interés comercial real que podría suscitar esta información en potenciales clientes. Además otro de sus puntos fuertes sería su bajo coste de implantación y mantenimiento.


62

8 . B I B L I O G R A F Í A [Abeijón Monjas, David] Fusión de datos para obtención de tiempos de viaje en

carretera: http://upcommons.upc.edu/pfc/handle/2099.1/4376

[Fernando López Hernández, MacProgramadores] JNI: Java Native Interface:

http://macprogramadores.org/documentacion/jni.pdf [Albert Huang, Larry Rudolph, MIT] Bluetooth for Programmers:

http://people.csail.mit.edu/rudolph/Teaching/Articles/BTBook-march.pdf [Apache Axis] Documentation:

http://axis.apache.org/axis/java/overview.html

[Gordon Henderson] Gordons Projects, Raspberry-Pi: https://projects.drogon.net/raspberry-pi/ [Consejería Fomento y Vivienda]: http://www.juntadeandalucia.es/fomentoyvivienda/portal-web/web/areas/carreteras/texto/92023603-8bb1-11df-9aa8-00163e67c14a [OASIS] SOAP Message Security: https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf [OASIS] Username Token Profile: https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

[bitcarrier]: http://www.bitcarrier.com/ [trafficnow]: http://www.trafficnow.eu/es [Traffax Inc.]: http://www.traffaxinc.com/

[Savari]: http://www.savarinetworks.com/

http://upcommons.upc.edu/pfc/handle/2099.1/4376

http://macprogramadores.org/documentacion/jni.pdf

http://people.csail.mit.edu/rudolph/Teaching/Articles/BTBook-march.pdf

http://axis.apache.org/axis/java/overview.html

https://projects.drogon.net/raspberry-pi/

http://www.juntadeandalucia.es/fomentoyvivienda/portal-web/web/areas/carreteras/texto/92023603-8bb1-11df-9aa8-00163e67c14a

http://www.juntadeandalucia.es/fomentoyvivienda/portal-web/web/areas/carreteras/texto/92023603-8bb1-11df-9aa8-00163e67c14a

https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

https://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

https://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

http://www.bitcarrier.com/

http://www.trafficnow.eu/es

http://www.traffaxinc.com/

http://www.savarinetworks.com/


63

9 . A N E X O S

9.1. ESTUDIO ESTADÍSTICO REPRESENTATIVIDAD BLUETOOTH

9.2. RESOLUCIÓN AGENCIA ESPAÑOLA DE PROTECCIÓN DE DATOS SOBRE IMPLANTACIÓN DE

TECNOLOGÍA SIMILAR EN ZARAGOZA (EMPRESA BITCARRIER)

Estudio estadístico

City Analytics

Ciudad 2020 S.L.Calle José Cruz Conde,

14001 CórdobaTelf: 957 76 00 33

2

Índice

1. Objetivo City Analytics 4

2. ¾Cómo estimamos el número de personas? 4

3. Principios estadísticos de City Analytics 4

4. De�nición del experimento 5

4.1. Proceso muestral. Obtencion de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5. Análisis de datos 7

5.1. Organización de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75.2. Medidas grá�cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75.3. Medidas de centralización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.4. Observaciones anormales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.5. Medidas de dispersión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.6. Medidas de forma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.8. Tipo de distribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6. Estimación estadística 12

6.1. Estimación por punto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.2. Características de un estimador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.2.1. Insesgadez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.2.2. Consistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.2.3. Su�ciencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.2.4. E�cacia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.3. Estimación por intervalo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.3.1. Error de la estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7. Resumen 15

7.1. Estamos estudiando una muestra del 27,077% de la población . . . . . . . . . . . . . . . . . . 157.2. El número de personas con el Bluetooth abierto es constante y muy robusto . . . . . . . . . . 157.3. Estimamos el porcentaje de personas con el Bluetooth activado con un error del 1,264% . . . 157.4. El error en la estimación del número personas está en torno al (8, 85%) . . . . . . . . . . . . 157.5. Ejemplo de estimación de City Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3

Índice de �guras

1. Datos de muestra para la explicación teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62. Datos agrupados. Tabla de frecuencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73. Diagrama de barras de los datos agrupados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74. Diagrama de barras de la frecuencia acumulada. . . . . . . . . . . . . . . . . . . . . . . . . . 85. Diagrama de barras de la frecuencia acumulada. . . . . . . . . . . . . . . . . . . . . . . . . . 96. Datos eliminando observaciones anormales. Tabla de frecuencias . . . . . . . . . . . . . . . . 97. Diagramas de frecuencia de los datos de�nitivos . . . . . . . . . . . . . . . . . . . . . . . . . . 108. Resumen valores medidas de centralización eliminando los valores anormales . . . . . . . . . . 119. Resumen valores medidas de dispersión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1110. Desarrollo cálculo intervalo de con�anza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1411. Estimación City Analytics día 25 de Junio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612. Estimación City Analytics día 16 de Julio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Estudio estadístico City Analytics 4

1. Objetivo City Analytics

El objetivo de este estudio es analizar la �abilidad de la tecnología que ha desarrollado la empresa Ciudad2020 para la estimación de personas que pasan por un entorno.

2. ¾Cómo estimamos el número de personas?

Gracias a nuestro dispositivo Intelify, vamos contando los dipositivos que tienen el Bluetooth abier-to, in�riendo el porcentaje de personas que llevan dispositivos con Bluetooth activado, mediante mediantemuestras en tiempo real y conteos visuales.

Una vez obtenido el porcentaje exacto inferimos el número de personas que pasan por una zona contandoen tiempo real el número de dispositivos BT personales y aplicando inferencia estadística.

3. Principios estadísticos de City Analytics

Utilizando la técnica del muestreo podemos producir información sobre un dominio dado a partir de laobservación de una parte de dicho dominio. Antes de abordar el método de muestreo que se va a emplear,vamos a de�nir las bases de nuestro estudio.

Universo (población), W(): Número exacto de personas que pasan por un área determinada duranteun intervalo grande de tiempo determinado.

Unidades estadísticas: Los elementos que componen nuestro universo son individuos.

Muestra: P() número de personas que pasan por esta zona en un intervalo de tiempo determinado.

Característica (X): Porcentaje de personas con dispositivos móviles con el bluetooth encendido.

En ocasiones, el muestreo puede ser más exacto que el estudio de toda la población porque el manejode un menor número de datos provoca también menos errores en su manipulación. En cualquier caso, elconjunto de individuos de la muestra son los sujetos realmente estudiados.

El estudio de muestras es preferible a los censos (o estudio de toda la población) por las siguientes razones:

La población es muy grande (en ocasiones, in�nita, como ocurre en determinados experimentos aleato-rios) y, por tanto, imposible de analizar en su totalidad.

Las características de la población varían si el estudio se prolonga demasiado tiempo.

Reducción de costos: al estudiar una pequeña parte de la población, los gastos de recogida y tratamientode los datos serán menores que si los obtenemos del total de la población.

Rapidez: al reducir el tiempo de recogida y tratamiento de los datos, se consigue mayor rapidez.

Viabilidad: la elección de una muestra permite la realización de estudios que serían imposible hacerlosobre el total de la población.

La población es su�cientemente homogénea respecto a la característica medida, con lo cual resultaríainútil malgastar recursos en un análisis exhaustivo (por ejemplo, muestras sanguíneas).

El proceso de estudio es destructivo o es necesario consumir un artículo para extraer la muestra(ejemplos: vida media de una bombilla, carga soportada por una cuerda, precisión de un proyectil,etc.).

Una vez introducido nuestro objetivo y aclarados nuestros principios vamos a entrar a analizar estadís-ticamente qué estamos haciendo.


4. De�nición del experimento

Teniendo en cuenta que nuestro universo W son las personas que pasan por una calle determinadano tenemos una lista o marco de todos los elementos, vamos a realizar un muestreo aleatorio simple

con reemplazamiento. Quiere decir esto que una persona, que es nuestra unidad estadística, puede serseleccionada para la muestra más de una vez.

4.1. Proceso muestral. Obtencion de datos

Nuestra característica es el porcentaje de personas que llevan el Bluetooth encendido en su movil por loque vamos a obtener una relación entre personas que pasan y número de dispositivos Bluetooth personalesabiertos.

Esta relación se obtiene contando visualmente las personas que pasan por una zona determinada queestá atacada a la misma vez por nuestra tecnología City Analytics que se encarga de contar el número dedispositivos Bluetooth que pasan en tiempo real.

Con estos dos datos obtenemos un porcentaje de personas que pasan en relación con BT abiertos, estaserá nuestra característica a estudiar.

Vamos a utilizar los datos obtenidos de las mediciones en el supermercado DEZA Zoco durante los días20 y 25 de Junio, el experimento consiste en contar visualmente las personas que entran al supermercadoy relacionarlo con el número de dispositivos bluetooth personales detectados mediante la tecnología CityAnalytics.


Tramo horario Personas contadas BT detectados Ratio

9:30 - 10:30 802 195 24,31%

10:30 - 11:30 556 167 30,04%

11:30 - 12:30 656 143 21,80%

12:30 - 13:30 540 87 16,11%

13:30 - 14:30 347 82 23,63%

14:30 - 15:30 210 71 33,81%

15:30 - 16:30 159 59 37,11%

16:30 - 17:30 281 125 44,48%

17:30 - 18:30 447 186 41,61%

18:30 - 19:30 794 435 54,79%

19:30 - 20:30 856 252 29,44%

20:30 - 21:30 265 86 32,45%

9:30 - 10:30 802 195 24,31%

10:30 - 11:30 908 252 27,75%

11:30 - 12:30 802 216 26,93%

12:30 - 13:30 483 161 33,33%

13:30 - 14:30 275 85 30,91%

14:30 - 15:30 179 67 37,43%

15:30 - 16:30 216 25 11,57%

16:30 - 17:30 247 67 27,13%

17:30 - 18:30 391 97 24,81%

18:30 - 19:30 547 160 29,25%

19:30 - 20:30 819 187 22,83%

20:30 - 21:30 401 113 28,18%

9:30-10:30 251 74 29.48%

10:30-11:30 554 142 25.63%

11:30-12:30 1045 190 18.18%

12:30-13:30 700 156 22.29%

13:30-14:30 300 140 46.67%

14:30-15:30 275 112 40.73%

15:30-16:30 179 86 48.04%

16:30-17:30 216 25 11.57%

17:30-18:30 247 81 11.57%

18:30-19:30 391 128 32.79%

19:30-20:30 547 209 32.74%

20:30-21:30 819 234 32.74%

21:30-22:30 401 122 28.57%

9:30-10:30 250 39 30.42%

10:30-11:30 629 131 15.60%

11:30-12:30 773 180 20.83%

12:30-13:30 886 214 23.29%

13:30-14:30 604 117 24.15%

14:30-15:30 391 105 19.37%

15:30-16:30 239 66 26.85%

16:30-17:30 154 44 27.62%

17:30-18:30 191 54 28.27%

18:30-19:30 203 65 32.02%

19:30-20:30 425 91 21.41%

20:30-21:30 641 141 22%

21:30-22:30 616 128 20.78%

Figura 1: Datos de muestra para la explicación teórica


5. Análisis de datos

Nos encontramos ante una variable univariante, puesto que vamos a estudiar si un individuo lleva o noel bluetooth encendido aunque estamos aúnando datos ya que la muestra sería inmanejable si controlamosuno a uno la característica objeto del estudio.

5.1. Organización de los datos

Lo primero que debemos de hacer ante cualquier set de datos es organizarlo de manera adecuada. Va-mos a agrupar los datos para facilitar su lectura, poder así visualizar la distribución que siguen y calcularfrecuencias.

Figura 2: Datos agrupados. Tabla de frecuencias

5.2. Medidas grá�cas

Una vez agrupados los datos en forma de tabla, ahora es posible disponer de medidas grá�cas de rep-resentación basadas en las frecuencias obtenidas, que nos van a permitir tener una idea más amplia delcomportamiento o características de los datos.

Diagrama de barras de frecuencia

Figura 3: Diagrama de barras de los datos agrupados.


Frecuencia acumulada

Figura 4: Diagrama de barras de la frecuencia acumulada.

5.3. Medidas de centralización

Este tipo de medidas se utilizan para dar una idea de la posición del centro de los datos, las más utilizadasson la media, la moda y la mediana.

La moda (mo) es el valor que se presenta con mayor frecuencia, en nuestro ámbito será el ratio dedispositivos Bluetooth que es más habitual en el ámbito de las medidas tomadas. Los datos agrupadosnos muestran claramente que la clase modal es el intervalo del 25% al 30% , por lo que la moda serála marca de clase de la clase modal.

mo = 27, 5% (5.1)

La mediana ( me ) es el valor númerico que deja el mismo número de datos antes y después de él.La mediana coincide con el percentil 50 de la distribución. Para la obtención de este valor vamos atrabajar con los datos originales ordenandolos y obteniendo la mediana.

me = 27, 97% (5.2)

La media aritmética muestral ( x) es la suma de todos las muestras dividida entre el número demuestras tomadas.

x =1

n

n∑i=1

xi = 27, 731% (5.3)

La media truncada de Tukey al k% (xk%) no es más que una medida de centralización en la queeliminamos datos extremos de una distribución, por lo que solventamos el problema que tiene la mediade ser sensible a ante este tipo de datos. Para la mayoria de los usos en estadística se elimina entre el5 al 25% de los elementos de la muestra en los extremos. En nuestro caso como vamos a eliminar el8% que corresponde a eliminar los dos primeros y dos últimos datos de la distribución.

x8% = 27, 922 (5.4)

Se observa de forma evidente gracias a las medidas de centralización que estamos ante una distribución dedatos muy centrada, ya que moda, mediana y media distan menos de un 2%. Esto nos va a falicitar laestimación de la información requerida para toda la muestra.


5.4. Observaciones anormales

Para detectar datos anormales vamos a tipi�car los datos que no es más que obtener el número deunidades que un individuo queda por encima o por debajo de la media del grupo. Los datos tipi�cadostienen la propiedad de que su media es cero y desviación típica 1.La mayoría de los datos ti�cados zi estarán comprendidos en el intervalo (−3;+3). Si algún dato está fuerade este intervalo e incluso fuera del intervalo (−2;+2), es sospechoso y debe estudiarse en detalle.

zi =xi − xS

(5.5)

Los datos tipi�cados quedan de la siguiente forma,

Figura 5: Diagrama de barras de la frecuencia acumulada.

Se observa claramente como unos de los datos es erroneo puesto tiene un valor de más de 4 al tipi�car,el resto de los valores están centrados entre el 0 y el 1 por lo que son correctos. Viendo esta grá�ca podemoseliminar de nuestro set de datos el valor 93,68% puesto que claramente es erróneo.

Basandonos en las �guras 3, 4 y 5 se aprecia claramente como el valor 93,68% está totalmente fuera derango y se puede eliminar perfectamente de nuestra distribución. Por lo que de aquí en adelante eliminaremosese dato de nuestra distrubución quedando ésta distribuida de la siguiente forma.

Figura 6: Datos eliminando observaciones anormales. Tabla de frecuencias

5.5. Medidas de dispersión

Como su propia palabra dice, estas medidas nos van a indicar los índices de variabilidad de nuestradistribución, es decir, si los datos de nuestra muestra son muy parecidos o muy distintos entre sí.

Desviación media viene dada por la media aritmética de los valores absolutos de las desviacionesobservadas con respecto a la media.


Frecuencia relativa Frecuencias absolutas

Figura 7: Diagramas de frecuencia de los datos de�nitivos

Dm =|(x1 − x)|+ ...+ |(xn − x)|

n=

1

n

n∑i=1

|(xi − x)| = 6, 61% (5.6)

Varianza ( S2) es el valor medio del cuadrado de las desviaciones de los datos con respecto a su mediaaritmética.

S2 =1

n

n∑i=1

(xi − x)2 = 0, 0078 (5.7)

Desviación típica (S) es la raíz cuadrada de la Varianza.

S = +√S2 = 8, 85% (5.8)

Error estándar Nos da una idea de la precisión de la media.

es =S√n− 1

= 1, 264% (5.9)

5.6. Medidas de forma

Es conveniente conocer la forma de una distribución de datos mediante indices o coe�cientes para podercomparar con otras distribuciones de datos y conocerd las principales características de la distribución

� Coe�ciente de asimetría Nos mide la simetría de una distribución, indicandonos si la curva defrecuencias tiene una cola a un lado u otro o por lo contrario es simétrica.

ϕ1 =m3

S3= 0, 695 (5.10)

� Coe�ciente de curtosis mide el grado de apuntamiento de la distribución comparandolo con lanormal .

ϕ2 =m4

S4− 3 = 0, 843 (5.11)


5.7. Conclusiones

Una vez calculadas una batería de medidas para analizar el tipo y forma de distribución a la que nosenfrentamos vamos a sacar todas las conclusiones posibles para conseguir la máxima precisión a la hora de lainferencia matemática del número real de personas. Vamos a empezar mostrando los valores de centralizaciónrecalculados una vez eliminadas las observaciones anormales.

mo = 27, 5% me = 27, 75% x = 27, 077% x8% = 27, 784%

Figura 8: Resumen valores medidas de centralización eliminando los valores anormales

Se aprecia notablemente que estamos ante una distribución altamente centrada puesto que todaslas medidas de forma calculadas varían en menos del 1% . Esto nos indica que el parámetro con el queestamos trabajando apenas tiene variaciones en toda la muestra recogida, por lo que se facilita la utilizacióndel mismo a través de una estimación simple como puede ser la media para el resto de la población.

Para conocer con detalle un conjunto de datos, no basta con conocer las medidas de tendencia central,sino que necesitamos conocer también la desviación que representan los datos en su distribución respectode la media aritmética de dicha distribución, con objeto de tener una visión de los mismos más acorde conla realidad al momento de describirlos e interpretarlos para la toma de decisiones. Vamos a pasar a ver unresumen de las medidas de dispersión de la distribución,

Dm = 6, 617% S2 = 0, 0078 S = 8, 85% es = 1, 264%

Figura 9: Resumen valores medidas de dispersión

Todas estas medidas nos aportan la desviación media que tienen los datos respecto a la media muestralde la distribución. Es decir, nos van a con�rmar o no si podemos tomar la media como parámetro válido paratoda la población. La desviación típica o estándar S nos informa de la media de las distancias que tienen losdatos respecto a su media aritmética pero expresada en las mismas unidades que la variable, por lo que esun indicador claro de la precisión de nuestros datos.

En nuestro caso S = 8, 85% que nos indica que los datos varían un promedio de 8, 85 puntosde la media, lo cual es un dato bastante aceptable para los valores cualitativos que estamos

tratando.

El error estandar es es el índice que cuanti�ca cuanto se apartan los valores en la muestra de sus cor-respondientes valores en la población. Es decir, el error estándar de la media cuanti�ca las oscilacionesde la media muestral (media obtenida en los datos) alrededor de la media poblacional (verdadero valorde la media). No es por lo tanto un índice de variabilidad, aunque depende de ella, sino una medida delerror que se comete al tomar la media calculada en una muestra como estimación de la media de la población.

Gracias a este indicador podemos saber si la media muestral es o no representativa de la media poblacional,con un es = 1, 264% estamos en condiciones de utilizar la media muestral como representativa

de la población para nuestra aplicación. Quiere decir que la media de nuestra población va a variar entorno a 1, 264 puntos de la media muestral.

Aunque con estas dos medidas, de centralización y dispersión, tenemos bastante información sobre lacalidad de nuestra muestra, analicemos también las medidas de forma de la distribución puesto que nos vana servir para completar este estudio. Las medidas de forma se suelen utilizar cuando no se puede dibujar ladistribución, o cuando no se quiere gra�car, para tener una idea de la forma de la misma. En nuestro casola tenemos gra�cada y estas medidas nos van a corroborar que los datos tomados son correctos.

Por un lado tenemos el coe�ciente de asimetría de Fisher, ϕ1 = 0, 695, si ϕ1 = 0 estamos ante unadistribución totalmente simétrica, si ϕ1 > 0 ésta será asimétrica a la derecha. Si observamos la �gura 7 se


ve claramente que tenemos una pequeña cola a la derecha, lo que nos con�rma que efectivamente estamostrabajando con datos correctos.

El coe�ciente de curtosis también denominado de apuntamiento trata de estudiar la mayor o menorconcentración de frecuencias alrededor de la media y en la zona central de la distribución. En nuestro casoϕ2 = 0, 843 que se encuentra en el escalón de ϕ2 > 0 pero en un valor bajo, por lo que estamos anteuna distribución leptocúrtica. Es decir que la distribución está más apuntada que la normal, nuevamente siobservamos la �gura 7 se nota este apuntamiento.

5.8. Tipo de distribución

Una vez desarrollado el análisis en profundidad de la muestra, estamos ante una población en la quese observa una característica X (porcentaje de dispositivos Bluetooth) que es Normal de media y varianzadesconocidas, X ∈ N(µ;σ2 por lo que lo que vamos a estudiar es una muestra aleatoria simple (estudiorealizado en los apartados anteriores) con estadísticos media muestral y varianza muestral.

X =1

n

n∑i=1

xiXiS2 =

1

n

n∑i=1

(Xi −X)2 (5.12)

En la práctica basádonnos en los teoremas de Fishr y Craig, ∈ se puede estimar mediante S2, y si la muestraes su�cientemente grande (n > 20), el estadístico

Z =X − µS/√n

(5.13)

sigue una distribución normal N(0; 1).

El error estandar calculado en la equación (5.9) nos da una medida de precisión de la estimación de lamedia poblacional (µ) cuando se usa como estimador la media muestral X.

6. Estimación estadística

Se llama estimación al conjunto de técnicas que permiten dar un valor aproximado de un parámetro deuna población a partir de los datos proporcionados por una muestra. En nuestra aplicación estamos bus-cando el porcentaje de la población que lleva el Bluetooth encendido dentro de la zona estudiada y muestreada

Por lo que nuestro objetivo �nal es estimar a partir de una muestra el porcentaje de personas que ll-evan el Bluetooth de su dispositivo móvil encendido, para más adelante obtener una aproximación lo máscertera posible de las personas que pasan utilizando los datos recogidos por nuestra tecnología City Analytics.

6.1. Estimación por punto

Un estimador por punto no es más que una función de los datos muestrales, también llamada estadístico.Por ejemplo un estimador de la media poblacional µ puede ser la media muestral x según la siguiente función,

µ ≈ x =1

n

n∑i=1

xi (6.14)

Para estimar un parámetro desconocido se pueden utlizar distintos estimadores, pero tenemos que dis-cernir si el estimador que vamos a utilizar veri�ca ciertas propiedades deseadas.

Vamos a tomar el estimador más simple, el arriba nombrado, la media muestral como media poblacional,pero antes de nada tenemos que estudiar a fondo si realmente sirve este estimador para nuestra muestra.


6.2. Características de un estimador

Todas estas características están referidas a la distribución muestral del estimador, es decir, lo queocurriría por término medio en un muestreo repetido, aplicando el proceso a todas las posibles muestras. Esimportante destacar que no se puede juzgar un estimador por un valor numérico determinado, o sea por unaestimación asociada a una muestra concreta.

6.2.1. Insesgadez

Un estimador es insesgado si su esperanza coincide con el parámetro desconocido θ, por el contrarioserá sesgado si existe sesgo, es decir que existe una desviación sistemática cometida en cada estimación. Sedemuestra que la media muestral X es un estimador insesgado de /mu

E(X) = E(1

n

n∑i=1

Xi) =1

n

n∑i=1

E(Xi) =1

n

n∑i=1

µ = µ (6.15)

6.2.2. Consistencia

Un estimador se considera consistente si al aumentar la muestra se obtienen cada vez estimaciones máspróximas. El estimador X de µ es consistente claramente ya que,

X = µ, si n→∞ , X → µ (6.16)

6.2.3. Su�ciencia

Un estimador se dice su�ciente con respecto de un parámetro de la distribución si contiene toda lainformación meustral relativa al mismo. Es por tanto deseable que el estimador θ(X) sea su�ciente respectoal parámetro estimado θ. Se demuestra mediante el teorema de factorización que la media es un estimadorsu�ciente.

6.2.4. E�cacia

Un estimador se dice que es e�ciente o de mínima varianza, y se representa como,

θ(X) ∈ BLUE(θ) (6.17)

Las siglas BLUE corresponden 'mejor estimador lineal insesgado' (Best Linear Unbiased Estimator). Sedemuestra mediante la cota de Frechet, Cramer y Rao 1 que la media muestral X es el estimador máse�ciente para nuestra distribución.

6.3. Estimación por intervalo

Una de las formas de cuanti�car la incertidumbre asodiada a una estimación es construyenso un intervalode valores alrededor de la estimación, de tal forma que se tenga una con�anza pre�jada en que dcichointervalo contenga al verdadero valor. Este intervalo se denomina intervalo de con�anza.

Vamos a analizar el intervalo de con�anza para nuestra muestra,

1No desarrollamos la demostración por su complejidad matemática y porque no es el �n de este documento, puede consultarse

en cualquier texto estadístico


La estimación obtenida es,

X = µ = 27, 077% (6.18)

Para cuanti�car la incertidumbre se estudia la distribución muestral,

E(X) = µ; V (X) = S4 (6.19)

Para obtener un intervalo de con�anza de µ , y al ser σ desconocida, se utiliza el estadístico:

Z =X − µS/√n

(6.20)

Vamos a calcular el intervalo para un nivel de con�anza del 95% , o sea (1−α) = 0, 95, utilizando las tablasde la distribución N(0; 1), y sustituyendo Z se tiene,

I0,95 = ±2, 45% I0,98 = ±2, 91% (6.21)

Por lo que los intervalos de con�anza quedan de la siguiente forma,

I0,95 = (24, 624%, 29, 530%) I0,98 = (24, 165%, 29, 988%) (6.22)

Figura 10: Desarrollo cálculo intervalo de con�anza

Quiere decirse con esto que con un valor medio entre el 24,165% y el 29,988% vamos a acertar en el 98%de las estimaciones que realicemos en la población.

6.3.1. Error de la estimación

Es una medida de precisión de nuestros cálculos que coincide con la amplitud del intervalo de con�anza,poniendonos en el caso de trabajar con un límite de con�anza del 2% estaríamos ante un error en laestimación,

E2% = 5, 823% (6.23)


7. Resumen

Después de realizar todo el estudio vamos a resumir muy brevemente las conclusiones del mismo para suaplicación a nuestro producto City Analytics,

7.1. Estamos estudiando una muestra del 27,077% de la población

Después de organizar los datos, eliminar los valores anormales detectados (Punto 5.4 página 8) y recalcu-lar las medidas de dispersión (Punto 5.7 página 10) obtenemos un valor medio del 27, 077% de dispositivoscon el Bluetooth abierto con una desviación del 8, 85%

7.2. El número de personas con el Bluetooth abierto es constante y muy robusto

La distribución que nos encontramos es centrada (Figura 8 página 10), con una dispersión muy baja(Figura 9 página 10) y normal (Punto 5.8 página 11). Con estos datos obtenidos estamos en disposición deasegurar que la característica que estamos estudiando es muy robusta, lo que nos permite una extracción deconclusiones muy �ables.

7.3. Estimamos el porcentaje de personas con el Bluetooth activado con unerror del 1,264%

Como estamos ante una característica tan �able y robusta, tras los cálculos realizados podemos estimarla media de personas con el bluetooth activado en una población con un error del 1, 264% como hemoscalculado en la ecuación 5.9.

7.4. El error en la estimación del número personas está en torno al (8, 85%)

Teniendo en cuenta la precisión de nuestra tecnología contando dispositivos Bluetooth y las característicasde la distribución vistas anteriormente, podemos asegurar que estimamos el número de personas que pasanpor una zona con un error medio del 8, 85% que es la desviación típica respecto a la media que encontramosen la muestra. (Ecuación 5.8)

7.5. Ejemplo de estimación de City Analytics

Para ejempli�car todo el estudio mostramos un par de grá�cas en las que se muestran el número real depersonas contadas visualmente (línea azul) y el número de personas estimadas gracias a la tecnología CityAnalytics. Son dos ejemplos de dos días tomados al azar.


Figura 11: Estimación City Analytics día 25 de Junio.

Figura 12: Estimación City Analytics día 16 de Julio.

1/5

Expediente Nº: E/00680/2011

RESOLUCIÓN DE ARCHIVO DE ACTUACIONES

De las actuaciones practicadas por la Agencia Española de Protección de Datos ante el AYUNTAMIENTO DE ZARAGOZA y en base a los siguientes

HECHOS

PRIMERO: En relación con la noticia publicada por el diario HERALDO DE ARAGÓN, al respecto de la instalación, en las calles de la ciudad de Zaragoza, de determinados dispositivos electrónicos que detectan la congestión del tráfico urbano y realizan estimaciones sobre el tiempo invertido por los conductores en sus recorridos, a partir del seguimiento de los dispositivos de comunicación por radiofrecuencia instalados en los vehículos (identificados a través de su dirección MAC), el Director de la Agencia ordena, en fecha 23 de febrero de 2011, el inicio de las oportunas actuaciones previas de investigación con objeto de analizar la adecuación de este tratamiento a la legislación vigente en materia de protección de datos.

SEGUNDO: A partir de las actuaciones practicadas por la Inspección de Datos, se ha teniendo conocimiento de los siguientes extremos:

1. El Servicio de Movilidad Urbana del Ayuntamiento de Zaragoza, en adelante el AYUNTAMIENTO, adjudicó el concurso de la obra denominada “Obra Construcción de un Sistema de Aforos compuesto por Espiras, Detectores Inalámbricos y Visión Artificial en Pº Pamplona angular c/ Dr. Cerrada y Pl. Paraíso s/n Zaragoza 50004” a la Unión Temporal de Empresas AFOROS ZARAGOZA 2010, formada por CERMA & ARRIAXA S.L, IMESA S.A. y ENRIQUE COCA S.A.

La obra consiste en la instalación de un sistema de control del tráfico mediante el que se pretende mejorar los tiempos de recorrido de los vehículos en la ciudad, aconsejar a los ciudadanos sobre las mejores rutas para circular y reducir el consumo de carburantes y la emisión de CO2.

2. El sistema se basa en el análisis de los datos aportados por cuatro tipos de sensores:

2.1. Espiras electromagnéticas

2.2. Botes detectores del magnetismo geoterrestre

2.3. Cámaras de visión artificial

2.4. Sistema de detección de dispositivos Bluetooth

Son los últimos dos dispositivos los que se han analizado, dado que los dos primeros son meros sistemas de conteo de vehículos.

3. Respecto de las cámaras de visión artificial.

3.1. Las cámaras están enfocadas a la calzada y permiten definir un área, dentro de la

c. Jorge Juan 6 28001 Madrid www.agpd.es

http://www.agpd.es/

zona enfocada, y un sentido de paso.

Cuando un vehículo pasa por el área definida en el sentido configurado, la cámara envía un impulso eléctrico al sistema que actualiza la suma de vehículos.

3.2. Las cámaras no tienen la capacidad de almacenar o transmitir las imágenes captadas.

Para acceder a las imágenes que está captando la cámara, siempre en tiempo en real, debe accederse a la caja de control eléctrico del alumbrado público más cercana y conectar un ordenador al equipo allí dispuesto para su conexión con la cámara.

3.3. En el pliego de prescripciones técnicas se requiere que el sistema sea “Capaz de proveer los siguientes datos: volumen, velocidad, ocupación de zona y clasificación de vehículos, durante el día o la noche y en todas las condiciones climatológicas.”

3.4. Las imágenes captadas por este tipo de cámaras son de tan baja calidad que no permiten la identificación de viandantes o vehículos.

La baja calidad de las imágenes captadas por la cámara hace que los objetos aparezcan con una escasa definición pero el nivel de detalle es suficiente como para que el sistema distinga el paso de los vehículos, que es su función.

4. Respecto de los sensores de dispositivos “bluetooth” y el sistema de gestión de los datos proporcionados por estos:

4.1. La instalación de esta red de dispositivos fue subcontratada a la sociedad BITCARRIER, S.L.

El producto instalado se denomina “Citysolver”.

4.2. La red de sensores de dispositivos “bluetooth” consta de 150 elementos.

Los sensores son capaces de detectar tanto dispositivos “bluetooth” como dispositivos WiFi pero dado que en el pliego de prescripciones técnicas del proyecto sólo se requiere la detección de dispositivos “bluetooth”, el sistema ha sido configurado para ignorar las señales WiFi.

4.3. Los sensores tienen como objetivo medir los tiempos de recorrido entre dos puntos de la vía y, para ello, el sistema almacena información sobre los recorridos realizados por cada vehículo.

El sistema necesita identificar mediante algún tipo de código único a los vehículos que circulan, de cara a calcular dichos tiempos y con el fin de poder realizar ajustes en caso necesario (p.e. descartar los datos recibidos de un vehículo que no se mueve y cuyos tiempos medios falsearían los resultados).

4.4. El pliego de prescripciones técnicas del AYUNTAMIENTO previene: “Para realizar la captura y posterior auditoría del dispositivo, se utilizará la porción pública de éstos, sin que sea necesario capturar o almacenar ningún dato de carácter personal asociado. El sistema debe codificar la información captada, de tal forma que sea imposible técnicamente, relacionar los datos almacenados con los datos de carácter personal.”

4.5. Según las manifestaciones y la documentación aportada por los representantes de BITACARRIER, S.L., respecto a este sistema:

3/5

4.5.1.Los sensores, antes de transmitir los datos captados, realizan una serie de procesos sobre estos.

Dado que no interesan los datos de todos los dispositivos “bluetooth”, los propios sensores clasifican y filtran los datos recibidos en base a un dato incluido en las transmisiones denominado “código de dispositivo”.

Por otro lado, con el fin de poder identificar los vehículos manteniendo la privacidad de los conductores, el sensor transforma el identificador único recibido (la dirección MAC), proporcionándole a una función de resumen (función hash) la dirección MAC, además de otros datos, de forma que el resultado de aplicar la citada función sea un identificador único que puede ser calculado por cualquiera de los sensores, sin que la dirección MAC origen pueda ser obtenida ni por el responsable del sistema ni por una tercera entidad.

4.5.2.Los nodos conservan una lista de los identificadores disociados para poder ignorar las detecciones de aquellos que tengan un comportamiento irregular (p.e. un vehículo parado) que pudiese falsear los resultados finales.

4.5.3.Los datos obtenidos por la red de sensores, una vez disociada la dirección MAC, se almacenan en una base de datos sobre cuyos datos se efectúan procesos de agregación.

Los datos agregados son insertados en una segunda base de datos. Es la información contenida en esta segunda base de datos la que es accesible por los usuarios del sistema.

4.5.4.La información almacenada en la primara base de datos, se corresponde con las detecciones realizadas durante las últimas tres horas ya que el sistema está diseñado para que los datos sean borrados cuando su antigüedad sea mayor de tres horas.

4.6. Durante la inspección realizada en la sede del AYUNTAMIENTO los inspectores actuantes accedieron a las dos bases de datos. No se localizó, ni en la definición de la base de datos ni en su contenido, ningún dato de carácter personal.

5. Respecto a los sistemas de consulta de los datos obtenidos.

5.1. El sistema instalado prevé la consulta de la información contenida en el mismo mediante una aplicación web, los paneles informativos repartidos en las vías de la ciudad y una aplicación desarrollada para “smartphones”.

5.2. Durante la inspección realizada en la sede del AYUNTAMIENTO los inspectores actuantes accedieron a la aplicación web que permite ver la información recogida por el sistema y no hallaron ninguna función o dato que indique que sea posible el acceso a los datos de un vehículo concreto.

FUNDAMENTOS DE DERECHO


I

Es competente para resolver el Director de la Agencia Española de Protección de Datos, conforme a lo establecido en el artículo 37.d) en relación con el artículo 36, ambos de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (en lo sucesivo LOPD).

II

El artículo 28 del Estatuto de la Agencia Española de Protección de Datos, aprobado mediante Real Decreto 428/1993, de 26 de marzo, establece en su apartado primero: “Compete, en particular, a la Inspección de Datos efectuar inspecciones, periódicas o circunstanciales, de oficio o a instancia de los afectados, de cualesquiera ficheros, de titularidad pública o privada, en los locales en los que se hallen los ficheros y los equipos informáticos correspondientes […]”.

El artículo 124 del Reglamento de desarrollo de la Ley Orgánica 15/1999, aprobado mediante Real Decreto 1720/2007, de 21 de diciembre, prevé, por su parte: “Los inspectores podrán recabar cuantas informaciones precisen para el cumplimiento de sus cometidos. A tal fin podrán requerir la exhibición o el envío de los documentos y datos y examinarlos en el lugar en que se encuentren depositados, como obtener copia de los mismos, inspeccionar los equipos físicos y lógicos, así como requerir la ejecución de tratamientos y programas o procedimientos de gestión y soporte del fichero o ficheros sujetos a investigación, accediendo a los lugares donde se hallen instalados.

Del análisis técnico preventivo realizado por la Inspección de Datos sobre el sistema implantado por el AYUNTAMIENTO DE ZARAGOZA para el control de la congestión del tráfico urbano, no se desprenden incumplimientos de la normativa vigente de protección de datos, no habiéndose hallado constancia, en particular, de que en los ficheros analizados se conserven datos de carácter personal que pudieran identificar a los conductores o propietarios de los vehículos.

Por lo tanto, de acuerdo con lo señalado,

Por el Director de la Agencia Española de Protección de Datos,

SE ACUERDA:

1. PROCEDER AL ARCHIVO de las presentes actuaciones.

2. NOTIFICAR la presente Resolución a AYUNTAMIENTO DE ZARAGOZA.

De conformidad con lo establecido en el apartado 2 del artículo 37 de la LOPD, en la redacción dada por el artículo 82 de la Ley 62/2003, de 30 de diciembre, de medidas fiscales, administrativas y del orden social, la presente Resolución se hará pública, una vez haya sido notificada a los interesados. La publicación se realizará conforme a lo previsto en la Instrucción 1/2004, de 22 de diciembre, de la Agencia Española de Protección de Datos sobre publicación de sus Resoluciones y con arreglo a lo dispuesto en el artículo 116 del Real Decreto 1720/2007, de 21 diciembre, por el que se aprueba el Reglamento de desarrollo de la

5/5

LOPD.

Contra esta resolución, que pone fin a la vía administrativa (artículo 48.2 de la LOPD), y de conformidad con lo establecido en el artículo 116 de la Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común, los interesados podrán interponer, potestativamente, recurso de reposición ante el Director de la Agencia Española de Protección de Datos en el plazo de un mes a contar desde el día siguiente a la notificación de esta resolución, o, directamente recurso contencioso administrativo ante la Sala de lo Contencioso-administrativo de la Audiencia Nacional, con arreglo a lo dispuesto en el artículo 25 y en el apartado 5 de la disposición adicional cuarta de la Ley 29/1998, de 13 de julio, reguladora de la Jurisdicción Contencioso-Administrativa, en el plazo de dos meses a contar desde el día siguiente a la notificación de este acto, según lo previsto en el artículo 46.1 del referido texto legal.

Sin embargo, el responsable del fichero de titularidad pública, de acuerdo con el artículo 44.1 de la citada LJCA, sólo podrá interponer directamente recurso contencioso administrativo ante la Sala de lo Contencioso-administrativo de la Audiencia Nacional con arreglo a lo dispuesto en el artículo 25 y en el apartado 5 de la disposición adicional cuarta de la LJCA, en el plazo de dos meses a contar desde el día siguiente a la notificación de este acto, según lo previsto en el artículo 46.1 del referido texto legal.

Madrid, 20 de febrero de 2012EL DIRECTOR DE LA AGENCIA ESPAÑOLA

DE PROTECCIÓN DE DATOS

Fdo.: José Luis Rodríguez Álvarez


[sistema de recopilaciÓn de informaciÓn...

Documents