Sistema de monitorización de marcas RFID en estudios de dispersión de áridos en playas

Sistema de monitorización de marcas RFID en estudios de dispersión de áridos en playas José Antonio Hernández Rodríguez Tutor: Jorge Cabrera Gámez Departamento de Informática y Sistemas Universidad de Las Palmas de Gran Canaria Cotutor: Ignacio Alonso Bilbao Departamento de Física Universidad de Las Palmas de Gran Canaria Las Palmas de Gran Canaria – 29 de Julio de 2013 1 TFG | José Antonio Hernández Rodríguez Índice 1. Introducción ................................................................................................... 5 1.1 Estado Actual ............................................................................................ 5 1.2 Objetivos ................................................................................................... 6 1.3 Organización ............................................................................................. 8 2. Competencias ............................................................................................... 10 3. Aportaciones ................................................................................................ 23 4. Normativa y Legislación ................................................................................ 24 5. Plan del Proyecto ......................................................................................... 28 5.1 Tareas ...................................................................................................... 28 5.2 Planificación Temporal ............................................................................ 28 6. Desarrollo ..................................................................................................... 30 6.1 Análisis .................................................................................................... 32 6.1.1 Interfaz gráfica, Análisis..................................................................... 32 6.1.2 Aplicaciones Waspmote, Análisis ...................................................... 47 6.2 Diseño ..................................................................................................... 53 6.2.1 Diseño de la Interfaz Gráfica ............................................................. 53 6.2.2 Diseño de las aplicaciones Waspmote ............................................... 58 6.3 Construcción ........................................................................................... 62 6.1.1 Construcción de la Interfaz Gráfica .................................................... 63 6.1.2 Construcción de las aplicaciones Waspmote ..................................... 65 7. Conclusión .................................................................................................... 71 2 TFG | José Antonio Hernández Rodríguez 7.1 Conclusión del trabajo realizado ............................................................. 71 7.2 Líneas futuras .......................................................................................... 72 8. Referencias ................................................................................................... 74 Apéndice: Manual de usuario del sistema ........................................................ 76 Preparación e instalación .............................................................................. 76 Manual de Uso .............................................................................................. 78 3 TFG | José Antonio Hernández Rodríguez Listado de Tablas y Figuras  Tablas Tabla 1 – Planificación temporal del desarrollo del proyecto………………… 29 Tabla 2 – Componentes del equipo móvil o de detección de marcas……..50  Figuras Fig. 1 – Actores UML…………………………………………………………………………….. 41 Fig. 2 – Relación asociación UML………………………………………………………….. 41 Fig. 3 – Relación inclusión UML…………………………………………………………….. 42 Fig. 4 – Relación extensión UML……………………………………………………………. 42 Fig. 5 – Relación generalización UML……………………………………………………. 42 Fig. 6 – Casos de uso principales…………………………………………………………... 45 Fig. 7 – Desglose del CdU ‘Realizar Informes’……………………………………….. 46 Fig. 8 – Desglose del CdU ‘Monitorización’…………………………………………… 47 Fig. 9 – Dispositivo Waspmote………………………………………………………………. 48 Fig. 10 – Lector RFID…………………………………………………………………………….. 52 Fig. 11 – Alimentación del lector RFID………………………………………………….. 52 Fig. 12 – Diseño de la base de datos ‘seguimientorfid’………………………….. 54 Fig. 13 – Estructura del sistema…………………………………………………………….. 56 Fig. 14 – Estructura APIs Waspmote……………………………………………………… 59 Fig. 15 – Setup del Waspmote Base………………………………………………………. 60 Fig. 16 – Loop del Waspmote Base……………………………………………………….. 60 Fig. 17 – Setup del Waspmote Rover…………………………………………………….. 61 Fig. 18 – Loop del Waspmote Rover……………………………………………………… 62 Fig. 19 – Imagen de la interfaz gráfica de usuario…………………………………. 65 Fig. 20 – Ejemplo de la precision de los datos obtenidos por el GPS del Waspmote……………………………………………………………………………………………. 68 Fig. 21 – Sistema en funcionamiento 1…………….…………………………………… 69 Fig. 22 – Sistema en funcionamiento 2…………………………………………………. 69 Fig. 23 – Sistema en funcionamiento 3……………..………………………………….. 70 4 TFG | José Antonio Hernández Rodríguez Fig. M1 – Menú XAMPP……………………………………………………………………….. 77 Fig. M2 – Diálogo de configuración de los parámetros de la ET…………….. 79 Fig. M3 – Pantalla principal de la IU………………………………………………………. 79 Fig. M4 – Establecer Ángulo α………………………………………………………………. 80 Fig. M5 – Confirmación punto topográfico……………………………………………. 81 Fig. M6 – Diálogo para editar registro…………………………………………………… 81 Fig. M7 – Diálogo de edición correcta…………………………………………………… 82 Fig. M8 – Entrada de texto del modo siembra………………………………………. 82 Fig. M9 – Ventana de configuración……………………………………………………… 83 Fig. M10 – Diálogo para guardas los informes………………………………………. 84 Fig. M11 – Diálogo de guardado correcto…………………………………………….. 84 Fig. M12 – Menú de búsqueda de la IU…………………………………………………. 85 5 TFG | José Antonio Hernández Rodríguez 1. Introducción El proyecto “Sistema de monitorización de marcas RFID en estudios de dispersión de áridos en la playa” surge con la intención de apoyar un proyecto de fin de Máster del Departamento de Física de la Universidad de Las Palmas de Gran Canaria, y de fomentar la colaboración multidisciplinar. Dicho proyecto consiste en marcar una serie de cantos y colocarlos en una playa, concretamente en el norte de Gran Canaria, con el fin realizar un seguimiento de los mismos y analizar el desplazamiento que sufren por el efecto del oleaje. Nuestro papel en el proyecto consiste en servir de soporte informático para facilitar la obtención y la representación de la información para realizar este proyecto, proporcionando así, más comodidad y sencillez a los encargados de desarrollarlo. Las principales herramientas que se deberán utilizar durante el desarrollo del proyecto para la consecución del mismo son las siguientes: - Dispositivos Waspmotes - Estación total Topcon GTS – 300 - API de Google Maps 1.1 Estado Actual En este apartado se expone el estado en el que se encuentran las distintas herramientas empleadas en el proyecto a día de hoy. En primer lugar tenemos los dispositivos Waspmotes [6] [14] [15], los cuales son plataformas basadas en una placa con microcontrolador y un entorno de desarrollo, diseñada para facilitar el uso de la electrónica en proyectos multidisciplinares. Estos dispositivos han tenido una excelente acogida en todo el mundo, un gran número de empresas han hecho uso de estos dispositivos, tales como Telefónica, Sony Ericsson, Vodafone, IBM, etc., así como distintas universidades a nivel internacional. Esta gran aceptación va condicionada por la gran diversidad de utilidades de estos dispositivos, empleados en proyectos como: 6 TFG | José Antonio Hernández Rodríguez  Monitorización de ruido y polución en ciudades.  Medición de niveles de radiación.  Monitorización de calidad del aire en interiores.  Medición del nivel de radiación ultravioleta.  Prevención de incendios forestales.  Etc. Pieza esencial en el proyecto es la estación total [7] (en este TFG se utiliza la Topcon GTS-300), aparato electro-óptico cuyo funcionamiento se apoya en la tecnología electrónica. Consiste en la incorporación de un distanciómetro y un microprocesador a un teodolito (instrumento de medición para obtener ángulos verticales y horizontales con una alta precisión) electrónico. Este tipo de aparato es usado principalmente en topografía para el cálculo de distancias horizontales, distancias inclinadas, diferencia de alturas entre dos puntos, etc. Y por último tenemos la API de Google Maps [9], la más popular y conocida de las tres herramientas. Ésta es un servidor de aplicaciones de mapas en la web, ofrece imágenes de mapas desplazables, así como fotografías por satélite de todo el mundo. Con la introducción de las herramientas de búsqueda y el movimiento en el mapa, ha hecho crecer el interés en el uso de las imágenes satelitales, tanto para la investigación como para fines personales. Además la posibilidad de integrar la API en cualquier página Web ha revolucionado el uso de la misma. En el siguiente apartado se comenta cual es el papel de cada una de estas herramientas dentro del proyecto. 1.2 Objetivos El objetivo principal de este trabajo de fin de grado está muy claro: desarrollar una interfaz gráfica capaz de almacenar y representar la información obtenida a partir de los distintos sensores y herramientas empleados, además de los programas necesarios para obtener dicha información mediante los dispositivos Waspmotes. 7 TFG | José Antonio Hernández Rodríguez Para lograr este objetivo principal hay que tener claro cuál es el rol que tendrá cada una de las herramientas mencionadas en el apartado anterior dentro del proyecto, aparte de estas, también se debe hacer mención de la interfaz gráfica que posee un papel primordial en el proyecto.  Waspmotes: la función de los Waspmotes será la detección de los distintos cantos marcados con las marcas RFID a lo largo de la playa donde estén situadas.  Estación Total: la estación total se encargará de medir las distancias entre un punto de referencia y las localizaciones de las detecciones registradas por los dispositivos Waspmotes, con la finalidad de obtener las coordenadas geográficas de las mismas.  API Google Maps: la API de Google Maps servirá para representar las coordenadas calculadas a partir de los datos obtenidos de la estación total sobre el mapa correspondiente.  Interfaz Gráfica: la interfaz gráfica tendrá como objetivos la coordinación de las tres herramientas anteriores para la obtención y representación de los datos obtenidos en tiempo real, servir de soporte a la API de Google Maps, y permitir consultas y extracciones de informes posteriores. Pero aparte de este objetivo general se plantea otra serie de objetivos secundarios y secuenciales, que son los que se citan a continuación: 1. Establecer la comunicación entre dos dispositivos Waspmotes y obtener la información oportuna de los sensores de los que están provistos estos dispositivos. 2. Conseguir la comunicación entre el ordenador portátil y los dispositivos Waspmote. 3. Conseguir la comunicación entre el ordenador portátil y la estación total Topcon GTS-300. 4. Conocer y elegir una de entre las distintas APIs disponibles para la representación de puntos en mapas. 5. Representar los datos obtenidos sobre la API de mapas seleccionada. 8 TFG | José Antonio Hernández Rodríguez 6. Desarrollar una interfaz gráfica capaz de coordinar las distintas herramientas empleadas. 1.3 Organización Esta memoria consta de ocho capítulos y dos apéndices. El primero, el presente, es de carácter introductorio. Como ya se ha expuesto en parte, en él se explica de forma general en qué consiste el proyecto, cuál es su finalidad y qué características posee. También se destacan cuáles se destaca cuál es el estado en el que actualmente se encuentran las principales herramientas empleadas en el desarrollo de este trabajo de fin de grado. Posteriormente se mencionan los objetivos que se esperan conseguir una vez finalizado el mismo. Y por último, el presente apartado, se resume la estructura y organización general que presenta la memoria. El segundo capítulo versa sobre cómo se han cubierto las distintas competencias asociadas al título de Grado en Ingeniería Informática con el fin de culminar los estudios y como preparación para el desempeño futuro de actividades profesionales en el ámbito correspondiente a la titulación obtenida. En el tercero se hace referencia a las distintas aportaciones que han surgido gracias al desarrollo de este proyecto. El cuarto capítulo se trata la normativa y legislación vigente que afecta a este trabajo de fin de grado, se mencionan las distintas licencias a las que se acogen algunas de las herramientas empleadas y los propietarios de los derechos de otras aplicaciones también usadas. El quinto expone cuales van a ser las tareas en las que se va a dividir el desarrollo de este trabajo de fin de grado y la temporización de las mismas. El capítulo número seis contiene la parte más importante del proyecto, aquí se cuenta todo lo relacionado con el qué y el cómo se ha realizado. Este capítulo está compuesto por tres apartados: análisis, diseño y construcción; separando así el desarrollo en las principales etapas que se establecen en la ingeniería del software. 15 TFG | José Antonio Hernández Rodríguez - El preacking (utilización de servicios de telecomunicaciones evitando el pago total o parcial de dicho servicio). - La ingeniería social (arte de convencer a la gente de entregar información que en circunstancias normales no entregaría). - La distribución de virus. f. Francia En Enero de 1988, este país dictó la Ley relativa al fraude informático, en la que se consideran aspectos como: - Intromisión fraudulenta que suprima o modifique datos. - Conducta intencional en la violación de derechos a terceros que haya impedido o alterado el funcionamiento de un sistema de procesamiento automatizado de datos. - Conducta intencional en la violación de derechos a terceros, en forma directa o indirecta, en la introducción de datos en un sistema de procesamiento automatizado o la supresión o modificación de los datos que éste contiene, o sus modos de procesamiento o de transmisión. - Supresión o modificación de datos contenidos en el sistema, o bien en la alteración del funcionamiento del sistema (sabotaje). g. Chile Chile fue el primer país latinoamericano en sancionar una Ley contra delitos informáticos, la cual entró en vigencia el 7 de junio de 1993. Esta ley se refiere a los siguientes delitos: - La destrucción o inutilización de los datos contenidos dentro de una computadora es castigada con penas de prisión. Asimismo, dentro de esas consideraciones se encuentran los virus. - Conducta maliciosa tendiente a la destrucción o inutilización de un sistema de tratamiento de información o de sus partes componentes, o que dicha conducta impida, obstaculice o modifique su funcionamiento. 16 TFG | José Antonio Hernández Rodríguez - Conducta maliciosa que altere, dañe o destruya los datos contenidos en un sistema de tratamiento de información. 2. Ámbito europeo Hasta ahora, el principal esfuerzo europeo por regular el tema de los delitos informáticos dio como resultado el “Convenio sobre la Ciberdelincuencia”, del 21 de noviembre de 2011. Este documento fue firmado por los representantes de cada país miembro del Consejo de Europa, aunque su eficacia depende de su posterior refrendo por los órganos nacionales de cada país firmante. El “Convenio sobre la Ciberdelincuencia” permitió la definición de los delitos informáticos y algunos elementos relacionados con éstos, tales como “sistemas informáticos”, “datos informáticos”, o “proveedor de servicios”. Estos delitos informáticos fueron clasificados en cuatro grupos: a. Delitos contra la confidencialidad, la integridad y la disponibilidad de los datos y sistemas informáticos. - Acceso ilícito a sistemas informáticos. - Interceptación ilícita de datos informáticos. - Interferencia en el sistema mediante la introducción, transmisión, provocación de daños, borrado, alteración o supresión de éstos. - Abuso de dispositivos que faciliten la comisión con delitos. b. Delitos informáticos. - Falsificación informática que produzca alteración, borrado o supresión de datos informáticos que ocasionen datos no auténticos. - Fraudes informáticos. c. Delitos relacionados con el contenido. - Delitos relacionados con la pornografía infantil. 17 TFG | José Antonio Hernández Rodríguez d. Delitos relacionados con infracciones de la propiedad intelectual y derechos afines. Conviene destacar que en el “Convenio sobre la Ciberdelincuencia” se encomienda a cada parte que tome las medidas necesarias para tipificar como delito en su derecho interno de cada uno de los apartados descritos en cada categoría. En la Disposición 1441 del BOE num. 226 de 2010, encontramos el Instrumento de Ratificación del “Convenio sobre la CIberdelincuencia”, hecho en Budapest el 23 de Noviembre de 2001 3. Ámbito nacional Ley Orgánica de Protección de datos de carácter personal: régimen sancionador aplicable (BOE nº 298 de 14/XII/99 que publicó la Ley Org. 15/1999 de Dic.). Objeto: proteger y garantizar las libertades públicas y derechos fundamentales de las personas, especialmente su HONOR e INTIMIDAD personal y familiar. Aspectos de interés: serán responsables “los responsables de los ficheros o de los tratamientos” y “los encargados de los tratamientos”. Tipo de infracciones: - Leves (art.44.2): multas de 100.000 a 10 millones de las antiguas pesetas. Ej: rectificar datos o no comunicarlos a la Agencia de Protección Datos. - Graves (art.43): multas de 10 a 50 millones de las antiguas pesetas. Ej: no mantener sistemas de seguridad, obstrucción a inspección, uso en provecho propio. - Muy Graves (art.45): multas de 50 a 100 millones de las antiguas pesetas (“Conductas reprochables”). Ej: vulnerar a propósito el secretismo, etc. 18 TFG | José Antonio Hernández Rodríguez Ley 7/1998 de 13 de Abril que regula las condiciones generales de contratación. R.D. 1906/1999 de 17/XII que regula la contratación telefónica. R.D. Ley 14/1999 de 17/XII sobre Firma Electrónica (BOE Nº 224 de 18/XII). Firma electrónica: dispositivo electrónico que permite la identificación del signatario de las operaciones realizadas por Internet. Identifica: el firmante (autentificación) y evita el retracto (no repudio). Código Penal Ley Orgánica 10/1995 de 23/XI: Tipifica delitos y faltas por el uso de la informática, concretamente contra la Intimidad, Patrimonio, Socioeconómicos y Propiedad Intelectual. Título X: “Delitos contra la intimidad, derecho a la propia imagen y la inviolabilidad del domicilio”. - Apoderarse de papeles, e-mails, mensajes, otros. - Cracks: delitos. - Obtener datos de terceros. Recomendaciones de la APD a. Información en la recogida de datos - Cuando suministre datos personales a cualquier organización (proveedores de acceso, proveedores de contenido, vendedores a través de comercio electrónico, etc.) sea consciente de a quién se los facilita y con qué finalidad. - Procure averiguar la política de sus proveedores y administradores de listas y directorios en lo que se refiere a venta, intercambio o alquiler de los datos que les suministra. Solicite que sus datos personales no vayan unidos a su identificación de acceso a Internet. 19 TFG | José Antonio Hernández Rodríguez b. Finalidad para la que se recogen los datos - Desconfíe si los datos que le solicitan son excesivos para la finalidad con la que se recogen o innecesarios para el servicio que se le presta. - Tenga en cuenta que cuando introduce su dirección de correo electrónico en un directorio, lista de distribución o grupo de noticias, dicha dirección puede ser recogida por terceros para ser utilizada con una finalidad diferente, como por ejemplo remitirle publicidad no deseada. - Cuando navegue por Internet, sea consciente de que los servidores Web que visita pueden registrar tanto las páginas a las que accede como la frecuencia y los temas o materias por las que busca, aunque no le informen de ello. Asimismo, su pertenencia a determinados grupos de noticias y listas de distribución puede contribuir a la elaboración de perfiles más o menos detallados sobre su persona. c. Seguridad en el intercambio de los datos - Utilice, siempre que sea posible, las últimas versiones de los programas navegadores, ya que cada vez suelen incorporar mejores medidas de seguridad. Considere la posibilidad de activar en dichos programas las opciones que alerten sobre los intercambios de datos no deseados y no rellene aquellos datos que no desee hacer públicos (por ejemplo, dirección de correo electrónico, nombre, apellidos, etc.). - No realice transacciones comerciales electrónicas a través de proveedores con sistemas inseguros o no fiables. Consulte el manual de su navegador para averiguar cómo informa de que se ha establecido una conexión con un servidor seguro. - Recuerde que existen sistemas de dinero electrónico que preservan el anonimato de sus compras en Internet. 20 TFG | José Antonio Hernández Rodríguez - Utilice los mecanismos de seguridad que tenga a su alcance para proteger sus datos de accesos no deseados. El medio más fiable para conseguirlo es el cifrado de los mismos. - Salvo que se utilicen mecanismos de integridad, autenticación y certificación (firma digital, notarios electrónicos, etc.) no confíe ciegamente en que la persona u organización que le remite un mensaje es quien dice ser y en que el contenido del mismo no se ha modificado, aunque esto sea así en la inmensa mayoría de las ocasiones. - Siempre que se le soliciten datos personales que no está obligado legalmente a suministrar, sopese los beneficios que va a recibir de la organización que los recoge frente a los posibles riesgos de utilización irregular de los mismos. - Ante cualquier duda sobre la legalidad de la utilización de sus datos de carácter personal, póngase en contacto con la Agencia de Protección de Datos. La protección jurídica de programas de ordenador. Piratería informática - El Real Decreto Legislativo 1/1996, por el que se aprueba el Texto Refundido sobre Propiedad Intelectual, la protección jurídica de los programas de ordenador, antes regulada por la Ley de Protección Jurídica de Programas de Ordenador y por la Ley de Propiedad Intelectual, crea un marco jurídico en contra de la piratería informática. - El Texto Refundido desarrolla una serie de medidas para combatir la piratería informática, como la posibilidad de que los fabricantes de programas de ordenador soliciten a la justicia española la realización de un registro sorpresa en empresas en las que existan sospechas fundadas o evidencias de delito. España es uno de los países en los que se puede acudir a esta medida cautelar. De esta manera se erradica la posibilidad de que los presuntos infractores puedan destruir las pruebas existentes, lo cual, indudablemente ocurrirá si se les notifica por adelantado la realización de un registro. 21 TFG | José Antonio Hernández Rodríguez ¿En qué casos se infringe la Ley? - Al copiar distribuir un programa de ordenador o la documentación que se le acompaña, incluidas aplicaciones, datos, códigos y manuales, sin permiso expreso o licencia del propietario o licencia del propietario de los derechos de explotación. - Al utilizar un programa sin la correspondiente licencia o autorización del fabricante, con independencia de que se utilice en un solo ordenador o en varios de forma simultánea. - Al utilizar programas de ordenador en un número de copias superior al autorizado por el fabricante en sus contratos o licencias de uso. - En empresas y demás organizaciones, al fomentar, consciente o inconscientemente, permitir, obligar o presionar a los empleados a realizar o distribuir copias no autorizadas del programa. - Al efectuar copias no autorizadas porque alguien lo requiere u obliga a ello. Al ceder o prestar el programa de forma que pueda ser copiado o al copiarlo mientras está en su posesión en calidad de cedido o prestado. - Al crear, importar, poseer o negociar con artículos destinados a burlar o neutralizar cualquier medio técnico aplicado para proteger el programa de ordenador. Medidas Judiciales Si finalmente existe evidencia de delito, las medidas judiciales que pueden adoptarse son: - Solicitar al Juez un registro sorpresa de las instalaciones del presunto infractor, tanto por la vía civil como por la penal. - Solicitar al Juez la adopción urgente de medidas cautelares de protección. - Exigir indemnizaciones acordes con los daños materiales y morales causados. - El cierre del centro de actividad del infractor. 22 TFG | José Antonio Hernández Rodríguez - El secuestro de todos aquellos medios destinados a suprimir los dispositivos técnicos que protegen un programa desarrollado y comercializado por un fabricante de programas.  TFG01: Ejercicio original a realizar individualmente y presentar y defender ante un tribunal universitario, consistente en un proyecto en el ámbito de la Ingeniería Informática de naturaleza profesional en el que sinteticen e integren las competencias adquiridas en las enseñanzas. Esta competencia quedará cubierta una vez realizada la presentación de este TFG antes los correspondientes miembros del tribunal. 23 TFG | José Antonio Hernández Rodríguez 3. Aportaciones La realización de este trabajo de fin de grado deja al descubierto distintas aportaciones, que son las siguientes: - Capacidad de obtener, monitorizar y almacenar las posiciones geográficas en tiempo real de marcas RFID, siendo capaz de representar dichas coordenadas en la API de Google Maps, y posibilitando también la consulta de las mismas en un proceso posterior. - Carácter interdisciplinar del proyecto, donde los elementos de tecnología informática que se aportan permiten impulsar tecnológicamente la faceta científica (geológica, en este caso). - Dar a conocer a otras disciplinas la utilidad que pueden aprovechar de utilizar la informática para el desarrollo de sus propios proyectos. - La última y no menos importante, es que se fomente el trabajo multidisciplinar tanto dentro de la ULPGC como fuera de ella, que tan buenos resultados ha dado durante la realización de este proyecto. 24 TFG | José Antonio Hernández Rodríguez 4. Normativa y Legislación En este cuarto capítulo se trata la legislación vigente que afecta a este trabajo de fin de grado, se mencionan las distintas licencias a las que se acogen algunas de las herramientas empleadas y los propietarios de los derechos de otras aplicaciones también usadas. Antes de entrar en estos aspectos, hay que hacer mención del software libre, que tienes un gran protagonismo en este trabajo de fin de grado. El software libre es la denominación del software que respeta la libertad de los usuarios sobre su producto adquirido y , por tanto, una vez obtenido puede ser usado, copiado, estudiado, modificado y redistribuido libremente. Según la Free Software Foundation, el software libre se refiere a la libertad de los usuarios para ejecutar, distribuir, estudiar, modificar el software y distribuirlo modificado. EL software libre suele estar disponible gratuitamente, o al precio de costo de la distribución a través de otros medios; sin embargo no es obligatorio que sea así, por lo que no hay que asociar software libre a “software gratuito” (denominado usualmente freeware) ya que, conservando su carácter de libre, puede ser distribuido comercialmente (“software comercial”). Análogamente, el software gratuito incluye en ocasiones el código fuente; no obstante, este tipo de software no es libre en el mismo sentido que el software libre, a menos que se garanticen los derechos de modificación y redistribución de dichas versiones modificadas del programa. Tampoco debe confundirse software libre con “software de dominio público”. Este último es aquel software que no requiere de licencia, pues sus derechos son de explotación para toda la humanidad, porque pertenece a todos por igual. Cualquiera puede hacer uso de él, siempre con fines legales y consignando su autoría general. Este software sería aquel cuyo autor lo dona a la humanidad o cuyos derechos de autor han expirado, tras un plazo contado desde la muerte éste, habitualmente 70 años. Si un autor condicione su uso bajo una licencia, por muy débil que sea, ya no es de dominio público. 31 TFG | José Antonio Hernández Rodríguez impide la utilización efectiva de los receptores GPS con el grado de precisión requerido en este proyecto. Así que por petición de los usuarios finales después de haberle comunicado la falta de precisión en los datos que proporcionaban los Waspmotes, se decantó por el uso de una estación total, en concreto, la Topcon GTS-300. Este contratiempo provocó la modificación del rumbo del desarrollo del sistema, por lo que prácticamente se hizo una nueva iteración incremental parcial, aplicando también el ciclo de vida clásico o en cascada, pues aparte de añadir nuevas características a la funcionalidad del sistema se tuvo que suprimir otras cuantas. Sin embargo, en este capítulo se muestra el desarrollo del sistema en una sola iteración, como si desde el principio se hubiera especificado como requisito el uso de la estación total. Simplificando y dando más claridad a la lectura de la presente memoria. El sistema desarrollado en este Trabajo de Fin de Grado se puede separar en dos partes claramente diferenciables:  Aplicaciones Waspmote: esta parte del sistema es la encargada de detectar las marcas RFID alojadas en los cantos a lo largo de la playa.  Interfaz gráfica de usuario: la interfaz será la encargada de sincronizar todas las herramientas empleadas en la obtención de las coordenadas geográficas de los cantos, siendo capaz de manipular de distintas formas estos datos. Uno de los aspectos más importantes de la IU es su labor de control sobre la estación total y la manipulación de los datos recibidos por la misma. A continuación se abordan las distintas etapas del desarrollo del sistema en los tres bloques citados anteriormente (Análisis, Diseño y Construcción), dividiéndose cada uno en dos, uno para la parte del sistema encargada de la aplicación de los dispositivos Waspmotes, y otro para la interfaz de usuario. 32 TFG | José Antonio Hernández Rodríguez 6.1 Análisis El primer bloque hace referencia a la Ingeniería de Requisitos. La Ingeniería de Requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer por un software nuevo o modificado. Además, el propósito de ésta es hacer que los requerimientos alcance un estado óptimo antes de llegar a la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc. Estamos aquí ante una etapa crucial en el desarrollo de la aplicación, pues su ejecución tiene repercusiones directas en el posible logro de los objetivos finales. Es muy importante tener claro desde el principio qué es lo que se va a desarrollar; cualquier ambigüedad puede ser desastrosa si no se soluciona antes de cambiar de etapa. Así que este va a ser el primer paso a seguir; una vez queda claro se pasa a la especificación de los requisitos del software. 6.1.1 Interfaz gráfica, Análisis Como ya se ha visto, este proyecto se divide en dos partes principales, en el caso de la interfaz gráfica, su misión consiste en la de sincronizar todos los dispositivos participantes en el sistema de monitorización en tiempo real, es decir, coordinar los dispositivos Waspmote, la estación total y la API de Google Maps (visible desde la propia interfaz) de manera de que el usuario pueda ver el progreso de las detecciones en tiempo real. Además de esta funcionalidad, el usuario puede realizar búsqueda e informes en el postproceso de los datos obtenidos durante la monitorización. Una vez se tiene claro cuál es la idea general de lo que se dispone a desarrollar, se entra ya en la descripción y especificación de los requisitos. En ella se realiza una descripción completa del comportamiento del sistema. Para elaborar la especificación debemos diferencia entre requisitos funcionales y requisitos no funcionales. 33 TFG | José Antonio Hernández Rodríguez Requisitos No Funcionales Un requisito no funcional es aquel que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que ni describen información a guardar ni funciones a realizar. Este tipo de requisitos afecta a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc. Los requisitos no funcionales de este Trabajo de Fin de Grado toman un papel bastante importante en el desarrollo de este proyecto y debido a que la lista es bastante amplia, se clasificarán en cuatro grupos (la información expuesta en este apartado ha sido extraída en su mayoría de [5]):  Hardware: el hardware necesario para el desarrollo de este proyecto es el siguiente:  Ordenador Portátil: en él se desarrollará la interfaz gráfica y las aplicaciones Waspmote, además será el alojamiento de la propia interfaz gráfica donde se llevará a cabo la correspondiente monitorización una vez preparado el sistema. Hay que destacar que para la realización del mismo se han hecho uso de dos ordenadores portátiles distintos, el primero del ordenador personal del autor de este trabajo y otro proporcionado para uso dedicado a este fin.  Dispositivos Waspmotes: como ya se ha visto es necesario el uso de dos dispositivos Waspmotes para la detección de las marcas RFID. Uno de ellos dispondrá de sistema para la detección de las marcas RFID.  Estación Total Topcon GTS-300: dispositivo necesario para calcular las coordenadas geográficas de las detecciones de las marcas RFID.  Módem 3G USB: también es necesario un pincho para realizar la conexión a internet durante la monitorización, ya que es necesario de 34 TFG | José Antonio Hernández Rodríguez usar la API de Google Maps, por lo que el acceso a Internet es fundamental.  Software: el software que se ha utilizado para el desarrollo y el funcionamiento del sistema es el que aparece a continuación:  Windows: la realización del sistema se ha hecho en el sistema operativo Windows, tanto en Windows XP como en Windows 7.  Netbeans: entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para extenderlo, además es un producto libre y gratuito sin restricciones de uso. Netbeans ha sido usado para desarrollar la interfaz gráfica en Java.  Notepad++: editor de texto y de código fuente libre con soporte para varios lenguajes de programación. De soporte nativo a Microsoft Windows. Se distribuye bajo los términos de la GNU General Public License (GPL). Notepad ha sido empelado para confeccionar lo relacionado con las distintas páginas HTML, además de realizar el script para la ejecución de la interfaz gráfica.  Microsoft Word: software destinado al procesamiento de textos. Fue creado por la empresa Microsoft, y actualmente viene integrado en la suite ofimática Microsoft Office. Originalmente fue desarrollado por Richard Brodie para el computador IBM bajo sistema operativo DOS en 1983. Ha llegado a ser el procesador de texto más popular del mundo. Microsoft Word ha sido utilizada para la redacción de la presente memoria.  Microsoft PowerPoint: programa de presentación desarrollado por la empresa Microsoft para sistemas operativos Microsoft Windows y Mac OS, ampliamente usado en distintos campos como la enseñanza, 35 TFG | José Antonio Hernández Rodríguez negocios, etc. Con PowerPoint y los dispositivos de impresión adecuados se puede realizar muchos tipos de resultado relacionados con las presentaciones: transparencias, documentos impresos para los asistentes a la presentación, notas y esquemas para el presentador, o diapositivas estándar de 35mm. Microsoft PowerPoint ha sido necesaria para la elaboración de la presentación de este trabajo de fin de grado.  XAMPP: servidor independiente de plataforma, software libre, que consiste principalmente en la base de datos MySQL, el servidor web Apache y los intérpretes de lenguajes de script: PHP y Perl. EL nombre proviene del acrónimo de X (para cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. El programa está liberado bajo la licencia GNU y actúa como un servidor web libre, fácil de usar y capaz de interpretar páginas dinámicas. XAMPP es empleado como servidor de base de datos (MySQL) y como servidor web interpretando el lenguaje de script PHP. Específicamente, MySQL es usado tanto por la interfaz como por la API de Google Maps, y el servidor web es necesario el correcto funcionamiento de la API de Google Maps.  API Google Maps: Google ofrece una API para su famosa aplicación Maps, que nos permite incorporar un mapa a nuestro dominio web. EL API proporciona diversas utilidades para manipular mapas y añadir contenido al mapa mediante diversos servicios, permitiendo crear sólidas aplicaciones de mapa en los sitios web. En nuestro caso la API de Google Maps se utiliza en la interfaz gráfica para mostrar las coordenadas geográficas de las detecciones de las marcas RFID. Para poder mostrar la API de Google Maps se embebe un navegador dentro de la propia interfaz gráfica, que en definitiva es una aplicación de escritorio.  AJAX: técnica de desarrollo web pare crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador 36 TFG | José Antonio Hernández Rodríguez de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, la interactividad, velocidad y usabilidad en las aplicaciones. JavaScript es el lenguaje interpretado en el que normalmente se efectúan las funciones de llamada de AJAX mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML. AJAX es utilizado para actualizar las detecciones de las marcas RFID en tiempo real la API de Google Maps durante la monitorización.  Librerías  RXTXcomm: esta librería es necesaria para establecer la conexión con los dispositivos Waspmote y la estación total vía USB (puerto serie).  poi-3.9-20121203: las librerías POI son de un proyecto dirigido por Apache Software Foundation, que surgen previamente de un subproyecto de Jakarta Project. Estas librerías proporcionan funcionalidades que permiten leer y escribir fichero en formatos de Microsoft Office como Word, PowerPoint o Excel. Para poder realizar los informes de las coordenadas geográficas de las detecciones de las marcas RFID en Excel se ha hecho uso de esta librería.  jdom-2.0.4: JDOM es una biblioteca de código abierto para manipulaciones de datos XML optimizados para Java. Al ser creado exclusivamente para este lenguaje, se beneficia de las características del mismo, incluyendo sobrecarga de métodos, colecciones, etc. Ha sido utilizada esta librería para el manejo de ficheros XML.  jQuery y jQuery UI: jQuery es una biblioteca de JavaScript, creada inicialmente por John Resig, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, 37 TFG | José Antonio Hernández Rodríguez manejar eventos, desarrollar animaciones FLV y agregar interacción con la técnica de AJAX a páginas web. jQuery es software libre y de código abierto, posee un doble licenciamiento bajo la Licencia MIT y la GNU GPL, permitiendo su uso en proyectos libres y privativos. jQuery, al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerirían de mucho más código, es decir, con las funcionalidades propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio. jQuery UI es una biblioteca de componentes para el framework jQUery que le añaden un conjunto de plug-ins, widgets y efectos visuales para la creación de aplicaciones web. Cada componente o módulo se desarrolla de acuerdo a la filosofía jQuery (find something, manipulate it). Se ha hecho uso de estas herramientas para hacer uso de AJAX y dar estilo a las páginas HTML que contienen la API de Google Maps.  Lenguajes  Java: el lenguaje de programación Java fue originalmente desarrollada por James Gosling de Sun Microsystems y publicado en 1995 como un complemento fundamental de la plataforma Java de la misma compañía. Su sintaxis deriva mucho de C y C++, pero tiene menos facilidades de bajo nivel que cualquiera de ellos. Las aplicaciones de Java son generalmente compiladas a bytecode que pueden ejecutarse en cualquier máquina virtual Java sin importar la arquitectura de la computadora subyacente. Java es un lenguaje de programación de propósito general, concurrente, orientado a objetos y basado en clases que fue diseñado específicamente para tener tan pocas dependencias como fuera posible. Su intención es permitir que los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo, lo que quiere decir que el código que es ejecutado en una plataforma no tiene que ser recompilado para ejecutarse en otra. 38 TFG | José Antonio Hernández Rodríguez Java ha sido el lenguaje elegido para realizar la interfaz gráfica.  XML: lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C). A pesar de ello, XML no ha nacido sólo para su aplicación para Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable. XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen muchos más grande y con unas posibilidades mucho mayores. Tienen un papel muy importante en la actualidad ya que permiten la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil. Se dispondrá de un fichero XML donde se almacenan distintos parámetro de configuración de la interfaz gráfica. Todos los lenguajes que se citan a continuación son necesarios para el control de la API de Google Maps que se encuentra embebida en la interfaz gráfica.  PHP: lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas, y es usado principalmente para la interpretación el lado del servidor. Se encuentra instalado en más de 20 millones de sitios web y en un millón de servidores, y es también el módulo Apache más popular entre los equipos informáticos que usan Apache como servidor web. PHP se usará para acceder a la base de datos para mostrar las coordenadas geográficas que se encuentran guardados en ella.  HTML: son las siglas de HyperText Markup Language, hace referencia al lenguaje de marcado predominante para la elaboración de páginas web que se utiliza para describir y traducir la estructura y la información en forma de texto, así como para complementar el texto con objetos tales como imágenes. EL HTML se escribe en forma de etiquetas, rodeadas por corchetes angulares (<, >). HTML también 39 TFG | José Antonio Hernández Rodríguez puede describir, hasta un cierto punto, la apariencia de un documento, y puede incluir un script (por ejemplo, JavaScript), el cual puede afectar el comportamiento de navegadores web y otros procesadores de HTML. HTML se empleará para estructurar la página donde se mostrará la API de Google Maps.  CSS: las hojas de estilo en cascada (CSS) hacen referencia a un lenguaje de hojas de estilo usado para describir la presentación semántica (el aspecto y formato) de un documento escrito en lenguaje de marcas. Su aplicación más común es dar estilo a páginas web escritas en lenguaje HTML, pero también puede ser aplicado a cualquier tipo de documentos XML, incluyendo SVG y XUL. La información de estilo puede ser adjuntada como un documento separado o en el mismo documento HTML. EN este último caso podrían definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo “<style>”. CSS se usa para dar estilo a los componentes que formas las páginas HTML donde se encuentra la API de Google Maps.  JavaScript: lenguaje de programación interpretado que se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. Al contrario que PHP, se usa principalmente del lado del cliente. Además su uso en aplicaciones externas a la web, como por ejemplo en documentos PDF o aplicaciones de escritorio, es también significativo. Aparte de usarse en la aplicación de jQuery y jQUery UI, su principal uso es el del manejo de la API de Google Maps. Requisitos Funcionales Un requisito funcional define el comportamiento interno del software: cálculo, detalles técnicos, manipulación de datos y otras funcionalidades específicas que muestran cómo serán llevado a la práctica los casos de uso. La 40 TFG | José Antonio Hernández Rodríguez especificación de los requisitos funcionales del software es la fase de análisis del problema, donde se debe aportar un método de análisis y en la que el desarrollador es el máximo responsable. Básicamente el objetivo es obtener una definición del software que se va a construir. Estos requisitos deben describir los servicios o actividades que hay que proporcionar con todo detalle. Sin embargo, éstos por sí solos no están detallados. Los escenarios son descripciones de cómo se utilizará el sistema en la práctica (completan o sustituyen los requisitos funcionales). Estos escenarios son representados mediante los casos de uso, incorporados en UML para describir la interacción entre los actores y el sistema. Un conjunto de casos de uso describe todas las posibles interacciones con el sistema, lo que puede ir mal y cómo manejar en su caso el problema. Para poder crear diagramas de casos de uso hay que entender la semántica para su construcción. UML (Unified Modeling Language) 2.0 definió una notación para cada elemento del diagrama ([21]). Actor: el caso de uso es una descripción funcional de la interacción entre uno o varios actores y el sistema que se está modelando específicamente sobre la funcionalidad desarrollada en el caso de uso. El actor está asociado a un rol específico que cumple en la interacción con el sistema (Ej: Usuario administrador, empleado, etc.). Un actor del sistema generalmente corresponde con un ser humano que tiene un rol de interacción con el caso de uso aunque no siempre es así; un actor puede ser un hardware, otro sistema, un servicio que consume las funcionalidades modeladas en el caso de uso, etc. En UML 2.0 un actor se expresa simplemente con una figura en forma de ser humano. Esta figura va acompañada del nombre del actor que representa. Caso de Uso: un caso de uso define un comportamiento del sistema capaz de cumplir un objetivo particular para un actor particular. Básicamente se podría decir que in requerimiento funcional del sistema puede dar origen a uno o muchos casos de uso. Es por eso que definir correctamente todos los requerimientos funcionales y no funcionales previo al diseño de diagramas de casos de uso es tan importante. EL diagrama de casos de uso no muestra el detalle de estas operaciones pero sí presenta la relación entre el actor y los 47 TFG | José Antonio Hernández Rodríguez puntos topográficos a lo largo de la monitorización), y establecer el modo “siembra”, este modo será necesario solo para la primera campaña, con el fin de ir colocando los cantos a lo largo de la playa de una forma rápida y eficiente sin hacer uso de los dispositivos Waspmote. Este proceso puede llevarse a cabo debido a que todos los cantos se encuentran marcados visiblemente con un ID numérico cada uno, entonces a medida que se van sembrando la IU debe dar la posibilidad de relacionar el ID correspondiente con la coordenada obtenida a través de la estación total. En la siguiente figura se muestra el desglose comentado de este caso de uso: 6.1.2 Aplicaciones Waspmote, Análisis Para el caso de las aplicaciones Waspmote, el objetivo es la detección de las marcas RFID alojadas en una serie de cantos que se distribuirán a lo largo de la playa con la finalidad de estudiar su dispersión. Los dispositivos Waspmotes (Fig. 9) son el resultado de dos años de investigación por parte de la empresa aragonesa Libelium, empresa de diseño y fabricación de hardware para la implementación de redes sensoriales Fig. 8 – Desglose del CdU ‘Monitorización’ 48 TFG | José Antonio Hernández Rodríguez inalámbricas, redes malladas y protocolos de comunicación para todo tipo de redes inalámbricas distribuidas. Waspmote es una plataforma modular para construir redes de sensores inalámbricas de muy bajo consumo. La plataforma comprende: - La placa Waspmote con microcontrolador, memoria, batería, acelerómetro y sockets para añadir módulos. - API y compilador OpenSource. - Diferentes radios de comunicación inalámbrica con alcances de hasta 40 Km. - Diversos módulos opcionales para añadir comunicación Bluetooth, GPRS y GPS. - Una gran variedad de placas de sensores para medir gases, eventos físicos y parámetros necesarios en el smart metering. Para este proyecto se hará uso de dos dispositivos Waspmotes, a los cuales identificaremos de la siguiente manera:  Waspmote Rover: este Waspmote se encontrará conectado al lector RFID y será el equipo que uno de los usuarios habrá de desplazar por el área objeto de estudio para detectar los cantos marcados. Por cada Fig. 9 – Dispositivo Waspmote 49 TFG | José Antonio Hernández Rodríguez detección enviará por radio una serie de parámetros que se indicarán posteriormente, además del identificador RFID del canto en cuestión.  Waspmote Base: este dispositivo tiene como objetivo recibir la información enviada por el Waspmote Rover y pasarla a la interfaz gráfica de usuario que se encuentra en un ordenador portátil al que está conectado, para que este último haga las acciones oportunas. Por tanto, habrá que realizar dos aplicaciones distintas, una para cada Waspmote, para ello será necesaria la consulta de la información de [1] y [13]. A continuación, tal y como se hizo para la interfaz gráfica se hace una distinción entre los requisitos funcionales y no funcionales. Requisitos No Funcionales Los requisitos no funcionales del TFG con respecto a las aplicaciones de los Waspmote se enumeran de la siguiente manera:  Se necesitan dos dispositivos Waspmote para el correcto funcionamiento del sistemas  Necesidad de un ordenador personal con el IDE específico instalado en él para el desarrollo de las aplicaciones correspondientes.  Ambos dispositivos Waspmotes deben disponer del módulo de radio para establecer enlaces en banda ISM (869 MHz), una tarjeta de memoria microSD y del módulo GPS, que a pesar de que no proporciona la precisión deseada, se usarán como un medio secundario de localización y para contrastar los errores de GPS frente las coordenadas proporcionadas por la estación total.  El Waspmote Rover debe contar con una antena para la detección de las marcas RFID Para cubrir estas necesidades, se dispone de dos dispositivos Waspmote con las siguientes características: 50 TFG | José Antonio Hernández Rodríguez Componentes del Waspmote Base: equipado con un receptor GPS SiRF III de 12 canales y un modem radio XBee 868 PRO, conectada por USB a un portátil/netbook. Componentes del Waspmote Rover: equipado con un receptor GPS SiRF III de 12 canales y un modem radio XBee 868 PRO. El sistema de detección RFID se conecta al mote mediante uno de sus puertos serie y se alimenta mediante una batería portátil. En la tabla siguiente se muestran las características específicas de este último dispositivo. Subsistema Componente Modelo Alimentación Batería de 24V@7Ah (2 x 12V@7Ah) PowerSonic 12V Conversor DC/DC Conversor DC/DC Detección RFID Lector RFID RI-CTL-MB2B Módulo RFM RI-RFM-008B Módulo de autosintonización RI-ACC-008B Antena Antena de diseño propio Microprocesador Sistema empotrado Waspmote V1.1 Receptor GPS Receptor SirFIII, 12 canales Modem radio Módulo XBee 868 PRO Adaptador RS232 - 3V3 A continuación se cita la información sobre el lector RFID, su alimentación y el resto de componentes necesarios para su funcionamiento: Alimentación El lector y los módulos RF pueden alimentarse de una única fuente de tensión o de fuentes separadas. Los RI-RFM-007B, RI-RFM-008B y RI-ACC-008B requieren de una tensión de alimentación regulada en el rango 7-24VDC. En esta implementación se ha diseñado un sistema de alimentación mediante dos baterías de gel-plomo de 12V y 7Ah conectadas en serie. La salida de la batería está conectada a un conversor DC-DC que permite convertir y estabilizar la Tabla 2 – Componentes del equipo móvil o de detección de marcas 51 TFG | José Antonio Hernández Rodríguez tensión de salida de las baterías a cualquier tensión en el rango 7-24V y entregar hasta 10A. El rango de detección del lector RFID aumenta con la tensión de alimentación del circuito de radio por lo que en principio la alimentación a 24V, máximo admisible, podría ser la mejor opción. Sin embargo, a la máxima tensión se genera un exceso de calor que es necesario extraer del interior de la caja que aloja la electrónica. Tras experimentar con varias tensiones de alimentación se comprobó que a 18V se obtenía el mejor resultado global; esto es, la temperatura del detector se mantenía dentro de unos límites razonables, mientras que la distancia máxima de detección no disminuía de manera apreciable (alrededor de un metro para una alineación detector - antena óptima). Para evitar dañar las baterías de plomo debido a una descarga excesiva, el conversor DC-DC se ha programado para desconectar las baterías si la tensión de las mismas cae por debajo de 21V. No obstante, dicha tensión se mide simultáneamente mediante uno de los conversores A/D de la mota y se transmite a la estación base para su monitorización por los operadores. De esta manera, es posible estimar el tiempo restante de autonomía del equipo de detección. Lector RFID El sistema de detección de marcas RFID comprende cuatro elementos: el lector RFID (modelo RI-CTL-MB2B), el módulo RFM (modelo RI-RFM-008B) y el módulo sintonización (modelo RC-ACC-008B), todos ellos de Texas Instruments, y una antena de diseño propio. La antena es una estructura circular de 80 cm de diámetro que contiene una bobina de tres vueltas de hilo de cobre macizo. El módulo de sintonización se usó para ajustar el circuito de radiofrecuencia a la frecuencia de resonancia de la antena. El lector está conectado a la mota desde la que se controla a través de una interfaz serie de tres hilos. Dado que el lector opera a los niveles del estándar 52 TFG | José Antonio Hernández Rodríguez RS232 y el puerto serie de la mota lo hace a niveles TTL 3.3V se ha usado un circuito conversor de niveles basado en el IC MAX3223. Desde la mota se monitoriza constantemente el estado del lector, emitiéndose alertas sonoras tanto cuando se produce una detección como cuando la comunicación entre la mota y el lector falla. A continuación se muestra dos imágenes: una del lector RFID (Fig. 10) y otra del sistema completo del lector RFID (Fig. 11), en la parte izquierda de esta imagen se puede ver la antena junto con el Waspmote Rover, en el centro el lector RFID y a su derecha la alimentación de este último. Requisitos Funcionales En cuanto a los requisitos funcionales, no se establecen casos de uso como se hizo para la interfaz gráfica, ya que se trata de una aplicación autónoma y no demasiado compleja, así que se enumerarán los requisitos funcionales de la misma forma que los requisitos no funcionales de esta parte del sistema: Fig. 11 – Sistema RFID completo Fig. 10 – Lector RFID 53 TFG | José Antonio Hernández Rodríguez  El Waspmote Rover debe detectar las marcas RFID, enviándola la información de la misma al Waspmote Base. El Base también debe pasar dicha información al portátil/netbook al que esté conectado. Además ambos Waspmotes deben informar periódicamente para hacer un seguimiento del estado de los mismos.  Todos los mensajes intercambiados deben ser almacenado en las tarjetas microSD de las que disponen los Waspmote.  La aplicación de este sistema en un entorno como el que se puede encontrar en el litoral norte de Gran Canaria requiere el uso de señales visuales y auditivas para informar sobre el estado de la monitorización o de los dispositivos.  El intercambio de mensajes será a través de radio cuando la comunicación sea entre los Waspmote, y a través de USB cuando sea Waspmote Base y el portátil/netbook al que esté conectado.  Los mensajes deberá contener como mínimo información sobre: el Waspmote emisor, temperatura y batería del Waspmote correspondiente, fecha y hora del mensaje, identificador de la marca RFID cuando se trate de una detección, y a pesar de no hacer uso de los datos del GPS deberán incorporarse igualmente en el mensaje por posible necesidad futura. 6.2 Diseño Una vez realizado el correspondiente análisis del desarrollo del sistema, nos encontramos ante una nueva etapa: el Diseño. El diseño hace posible la transformación de los requisitos en un producto software acabado mediante la obtención de modelos físicos del software y tiene como objetivo definir la estructura del sistema y a la facilidad del mantenimiento, ayudando a construir sistemas estables. 6.2.1 Diseño de la Interfaz Gráfica El diseño de la interfaz gráfica de usuario engloba el diseño de tres aspectos principales: 54 TFG | José Antonio Hernández Rodríguez  Diseño de la base de datos Como ya se ha visto, se hace uso de MySQL como gestor de base de datos. Con este gestor se ha creado una nueva base de datos con el nombre de ‘seguimientorfid’, la cual cuenta con una serie de tablas quedando como se muestra en la figura siguiente: En esta base de datos se cuenta con las tablas que se enumeran a continuación:  posicion_base: esta tabla tiene como finalidad guardar la información de los mensajes generados por el Waspmote Base.  showdeteccion: el contenido que almacena esta tabla es temporal, se utiliza para la actualización de la API de Google Maps en tiempo real. Se insertan las coordenadas que se desean mostrar, junto a otros parámetros como el ID de la marca RFID detectada. A continuación, la página que contiene la API de Google Maps ejecuta un script que accede a esta tabla temporalmente para actualizar el mapa, para finalmente eliminar de la tabla los puntos ya dibujados. Fig. 12 – Diseño de la base de datos ‘segimientorfid’ 55 TFG | José Antonio Hernández Rodríguez  campania: aquí se van almacenando las campañas que se van generando a lo largo del estudio de dispersión, es decir, habrá tantos registros como campañas realizadas.  rfid: esta tabla contiene toda la información de las marcas RFID utilizadas en el estudio. El campo ‘num_rfid’ tendrá valores de 1 a n, donde n indica el total de marcas RFID, y el campo ‘id_rfid’ representa el id de cada marca.  waspmote: el contenido que guarda esta tabla hace referencia a los distintos dispositivos Waspmote empleados.  tipo_evento: esta tabla contiene los eventos que pueden producirse en las aplicaciones de los Waspmote, como por ejemplo: encendido del Waspmote, detección de marca RFID, conexión del GPS, etc.  evento: aquí se almacenan los eventos que se han producido durante la monitorización (la funcionalidad de esta tabla no se aplica al 100%).  detección: esta es la tabla más importante, contiene la información de todas las detecciones de las marcas RFID, utilizando distintas ‘foreign key’ para referenciar a otras tablas (waspmote, campania y rfid).  Diseño de la estructura del sistema El siguiente paso es ilustrar como se estructura todo el sistema en su conjunta, a pesar de que este apartado se refiera solo a la interfaz gráfica, ya que éste requiere de todos los elementos para su correcto funcionamiento. Como se puede ver en la Fig. 13, los rectángulos con el borde redondeado hacen referencia al hardware empleado en el sistema, en este caso tenemos cuatro componentes hardware distintos: la estación total, los dos dispositivos Waspmote (Base y Rover) y el portátil o netbook donde estará alojado el resto del sistema. El resto (rectángulos normales) representan el software utilizado, donde los que no se encuentran dentro de otro rectángulo son los principales y los que sí lo están son los “secundarios”. Los principales son la interfaz gráfica, la API de Google Maps y el XAMPP, este último contendrá tanto el servidor Apache como MySQL. Los dispositivos que se comunican con la interfaz gráfica son el Waspmote Base, que a su vez está conectado al Rover, y la estación total. Con respecto a 56 TFG | José Antonio Hernández Rodríguez la interfaz gráfica y la API de Google Maps necesitarán de los servicios proporcionados por el gestor de base de datos MySQL, además los Mapas necesitarán también de Apache.  Diseño de la Interfaz Gráfica Atendiendo al análisis obtenido en la etapa anterior, el diseño de la interfaz gráfica de usuario, resumida con aspectos generales, es el que se describe a continuación: El componente principal de la interfaz gráfica es el JFrame, clase propia de la biblioteca gráfica ‘Swing’ de Java, en concreto se creará una clase que herede de esta primera. Desde esta clase se podrá realizar tres de los cuatro principales casos de uso de la aplicación: ‘Realizar Informes’, ‘Realizar Búsquedas y ‘Manejar Monitorización’. Para el caso de uso ‘Establecer Configuración’ se aplicará una clase que herede de otra clase propia de la biblioteca Swing, JDialog. Fig. 13 – Estructura del sistema 63 TFG | José Antonio Hernández Rodríguez problema. Es muy difícil realizar pruebas ideales para el testeo de un software, así que es muy importante la planificación de las mismas para obtener mejores resultados posibles. En general hay dos grandes formas de organizar un área de pruebas. La primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos sean tan claros que cualquiera pueda entenderlos y el software haga las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría. Cabe destacar el hecho de que el sistema, complejo por el número de componentes hardware que integra, va a ser usada en el campo por usuarios que no son expertos en informática. Por ello es importante que la validación del sistema así como su operación sean robustas. En este apartado se contarán los aspectos en rasgos generales, haciendo hincapié solo en aquellos aspectos más importantes durante el desarrollo del TFG. Básicamente, durante esta etapa las referencias utilizadas para el correcto desarrollo de las mismas han sido [1], [2], [9], [11], [12], [13], [16], [18], [19] y [20]. A continuación se muestra como han sido estas dos etapas en las dos partes en las que se ha dividió el sistema. 6.1.1 Construcción de la Interfaz Gráfica La implementación de la interfaz gráfica se puede separar en dos bloques, uno orientado a la interfaz gráfica pura, escrita en Java, y otro relacionado con la API de Google Maps, donde se encuentran tipos de ficheros que son usados en aplicaciones web: HTML, CSS, PHP y JavaScript. El código de la interfaz gráfica escrita en Java está dividida en varias partes (directorios) principales, que son las siguientes:  estacion_total: este directorio tiene las clases que son usadas para manejar los mensajes recibidos de la estación total, además de realizar 64 TFG | José Antonio Hernández Rodríguez los cálculos para obtener las coordenadas exactas, el ángulo α y otros parámetros que pueden verse en el apartado de ‘Análisis’ de este mismo capítulo.  images: contiene las imágenes que son usadas en la interfaz gráfica.  seguimientorfid: las clases que implementan la propia interfaz gráfica están alojadas en este directorio. Estas clases son las encargadas de cubrir las necesidades expuestas en los casos de uso que aparecen en el apartado de ‘Análisis’ de este mismo capítulo.  serialport: aquí están las clases necesarias para la comunicación por USB, de la interfaz gráfica con la estación total y el Waspmote Base.  util: en este carpeta se encuentran clases complementarias para el desarrollo de la interfaz gráfica, como el manejo de ficheros XML o HTML, paso de coordenadas UTM a decimales y viceversa (utilizando el algoritmo de la referencia [16]), etc. Los ficheros que componen el manejo de la API de Google Maps se encuentran en el directorio específico que es usado por el servidor XAMPP para el alojamiento de las distintas aplicaciones Web desarrolladas. Este directorio está compuesto por:  Dos directorios, ‘css’ y ‘js’, que contienen los ficheros de estilos y de scripts respectivamente, necesarios para el uso de jQuery UI. Obtenido principalmente de [19] y [20].  Un fichero de estilo, estilo.css, encargado de dar formato a los componentes de la página que contienes la API de Google Maps.  La versión de jQuery, 1.8.2 para el uso de JavaScript y AJAX, obtenida de [19].  Un fichero PHP, refresh.php, cuya función es actualizar la API de Google Maps con las detecciones de las marcas RFID en tiempo real, a través del uso de AJAX.  Y finalmente un fichero HTML, index.html, que es la página principal que contiene la API de Google Maps, con el contenido necesario para el manejo de la misma. Este fichero lo irá actualizando la interfaz gráfica durante la ejecución de esta, para mostrar el contenido correspondiente en cada momento. 65 TFG | José Antonio Hernández Rodríguez Las pruebas más significativas de la interfaz gráfica son las realizadas para el correcto funcionamiento de la API de Google Maps, haciéndolas directamente sobre un navegador, en concreto, Google Chrome. Para ello debía tenerse activados el servidor Apache y MySQL del XAMPP previamente, luego en la barra de direcciones del navegador bastaba con escribir “localhost/NombreDirectorioEspecificoEnHTDOCS”. En la siguiente imagen (Fig. 19) puede verse como ha quedado la interfaz gráfica una vez finalizada: 6.1.2 Construcción de las aplicaciones Waspmote Para la parte de implementación de las aplicaciones Waspmote, mencionar que para esta parte del sistema cuenta con dos aplicaciones, una para el Waspmote Rover y otra para el Waspmote Base. Cada una de ellas está compuesta por una serie de ficheros, uno para las declaraciones con extensión “.h” y el resto con extensión “.pde” (Processing Source Code). Ahora se verá cuales son los ficheros que forman cada una de las aplicaciones por separado. Fig. 19 – Imagen de la interfaz gráfica de usuario 66 TFG | José Antonio Hernández Rodríguez  Aplicación Waspmote Base La aplicación del Waspmote Rover, que se encarga de recibir las detecciones del Rover y enviárselas a la interfaz gráfica, es la siguiente:  rfid_fijo.h  En este fichero se establecen todas las declaraciones a nivel global de la aplicación.  rfid_fijo.pde  En este fichero es el principal de la aplicación, aquí es donde se inicia la aplicación, se puede decir que es el método ‘main’ de la misma.  rfid_fijo_comm.pde  Este módulo se encarga de la comunicación por radio con el Waspmote Rover.  rfid_fijo_gps.pde  Aquí se maneja todo lo relacionado con el GPS del Waspmote en cuestión.  rfid_fijo_message.pde  Aquí se encuentra el código necesario para formar los distintos mensajes que se van intercambiando a lo largo de la ejecución del sistema de monitorización durante el estudio.  rfid_fijo_sd.pde  Este módulo se encarga de manejar la tarjeta SD del dispositivo Waspmote para almacenar los mensajes intercambiados durante la monitorización.  rfid_fijo_status.pde  Código necesario para comprobar distintos parámetro del Waspmote, como puede ser la temperatura o la batería.  rfid_fijo_zumbador.pde  Este fichero contiene todo lo relacionado con el zumbador del Waspmote, utilizado para avisar al usuario de los distintos acontecimientos a lo largo de la monitorización.  Aplicación Waspmote Rover La aplicación del Waspmote Rover, que se encarga de detectar las distintas marcas RFID que se encuentran a lo largo de la playa, es la que aparece a continuación:  rfid_movil.h  En este fichero se establecen todas las declaraciones a nivel global de la aplicación. 67 TFG | José Antonio Hernández Rodríguez  rfid_movil.pde  En este fichero es el principal de la aplicación, aquí es donde se inicia la aplicación, se puede decir que es el método ‘main’ de la misma.  rfid_movil_comm.pde  Este módulo se encarga de la comunicación por radio con el Waspmote Base.  rfid_movil_gps.pde  Aquí se maneja todo lo relacionado con el GPS del Waspmote en cuestión.  rfid_movil_message.pde  Aquí se encuentra el código necesario para formar los distintos mensajes que se van intercambiando a lo largo de la ejecución del sistema de monitorización durante el estudio.  rfid_movil_sd.pde  Este módulo se encarga de manejar la tarjeta SD del dispositivo Waspmote para almacenar los mensajes intercambiados durante la monitorización.  rfid_movil_status.pde  Código necesario para comprobar distintos parámetro del Waspmote, como puede ser la temperatura o la batería.  rfid_movil_zumbador.pde  Este fichero contiene todo lo relacionado con el zumbador del Waspmote, utilizado para avisar al usuario de los distintos acontecimientos a lo largo de la monitorización. Con respecto a las pruebas, las aplicaciones Waspmote han sido las primeras que han pasado por esta etapa. Probándose cada módulo por separado antes de probar el conjunto entero, es decir, probar el código destinado al manejo del GPS, de la tarjeta de memoria SD, del módulo de radio, etc. Las pruebas de la interfaz gráfica de usuario serían posteriores a esta, debido a que se consideraba primordial tener unas aplicaciones Waspmote robustas, dejándolas listas para centrarse de lleno en la interfaz gráfica. Mencionar que durante estas pruebas fue cuando se decidió optar por la estación total para la obtención de las coordenadas geográficas de las marcas RFID. Se probó usando la API de Google Maps por separado, evaluando la precisión de los datos obtenidos. En la siguiente figura se muestra un ejemplo de la baja precisión de los mismos, aquí las coordenadas deberían estar sobre la acera que rodea el aparcamiento que aparece en la Fig. 20. 68 TFG | José Antonio Hernández Rodríguez Ya haciendo uso de la estación total los resultados fueron muy buenos, a pesar de no haber un recorrido como en la imagen anterior, se hicieron las pruebas en sitios estratégicos, fácilmente detectables en el mapa para comprobar la exactitud, comprobando que efectivamente los resultados eran bastante precisos. Por último, se añaden una serie de imágenes en las que se puede ver el sistema en funcionamiento durante la realización de las campañas. En la primera imagen (Fig. 21) se puede apreciar la estación total, que aparece a la derecha de la imagen situada encima de un trípode, y a la izquierda de ésta están situados el ordenador portátil y el Waspmote Base sobre una mesa. En la segunda imagen (Fig. 22), la persona que está a la izquierda está sujetando un prisma, que es la herramienta necesaria para hacer las mediciones con la estación total. Y la persona de la derecha transporta la parte del sistema encargada de realizar las detecciones de las marcas RFID, en concreto, el Waspmote Rover y el lector RFID con su correspondiente alimentación y su antena. Fig. 20 – Ejemplo de la precisión de los datos obtenidos por el GPS de los Waspmote 69 TFG | José Antonio Hernández Rodríguez La última (Fig. 23) muestra el ordenador portátil en la que se está ejecutando la IU, y la estación total, donde la persona que se ve en la imagen está realizando una medición con ella. Fig. 21 – Sistema en funcionamiento 1 Fig. 22 – Sistema en funcionamiento 2 70 TFG | José Antonio Hernández Rodríguez Fig. 23 – Sistema en funcionamiento 3 71 TFG | José Antonio Hernández Rodríguez 7. Conclusión En este capítulo se concreta, a modo de resumen, los objetivos conseguidos con el desarrollo del presente proyecto. Asimismo, se indican sucintamente algunas líneas de actuación que permitirán mejorar algunos de los aspectos desarrollados. 7.1 Conclusión del trabajo realizado El trabajo de fin de grado tiene por objetivo la elaboración de un proyecto informático aplicando los conocimientos adquiridos a lo largo de las asignaturas del Grado en Ingeniería Informática. Cuando se inició este trabajo de fin de grado se plantearon una serie de objetivos ligados al prototipo que se quería desarrollar, siendo el objetivo fundamental el dar soporte a las necesidades de los usuarios finales del sistema que plantearon unos requerimientos claros en cuanto a la funcionalidad y robustez del sistema. Para la consecución de este objetivo era necesario la creación de dos subsistemas que trabajaran en conjunto, por un lado estaba la aplicación de los dispositivos Waspmote, cuyo objetivo es la detección de las marcas RFID, y por el otro la interfaz gráfica de usuario, que debe sincronizar y controlar todos los dispositivos participantes en el sistema, esto incluye los dispositivos Waspmote y la estación total, y además de tratar toda la información obtenida por estos, con el fin de monitorizar, almacenar y representarla. Dichos subsistemas han sido desarrollados, tal y como se refleja a lo largo del capítulo de desarrollo y con el material entregado junto con esta memoria. El resultado finalmente obtenido ha sido evaluado por los usuarios como satisfactorio, quedando reflejado en el uso intenso del sistema como herramienta de campo en no menos de seis campañas. Los conocimientos técnicos adquiridos, mejorados y/o empleados en este proyecto comprenden varias áreas de conocimiento: la programación de sistemas empotrables (Waspmote), la programación en el lenguaje Java, la 72 TFG | José Antonio Hernández Rodríguez programación web, el análisis y diseño de base de datos y la ingeniería del software. En definitiva, el desarrollo de este proyecto ha significado una muy buena experiencia a nivel personal y profesional, donde he aprendido muchísimas cosas, tanto por mi cuenta, como por parte de mi tutor, Jorge Cabrera Gámez, y los destinatarios del sistema desarrollado, Mariona Casamayor Font e Ignacio Alonso Bilbao (cotutor), agradeciéndoles enormemente el trato y la ayuda recibido por ellos. 7.2 Líneas futuras En este apartado se exponen las posibles funcionalidades o mejoras que se le pueden añadir al presente trabajo, pero que por falta de tiempo no ha sido posible implementar o que por la experiencia del mismo se ha decidido aplicar en un futuro.  Mejorar la monitorización de los estados de los Waspmote En la interfaz gráfica hay un sector, donde se debe mostrar el estado de los Waspmote durante la monitorización, situado en la parte superior derecha (puede verse en la Fig. 17). La funcionalidad de este bloque informativo no está implementada completamente, por lo que una de las tareas a realizar en un futuro es la de terminar dicha implementación, que no ha podido ser completada debido a la falta de tiempo disponible para ello, ya habiéndose empleadas las 300 horas previstas.  Extensión de aplicación del sistema En consecuencia de los buenos resultados obtenidos, se pretende extender el uso del sistema en otras zonas de estudio, así como incluir más de un Waspmote de tipo Rover en el sistema para abordar zonas más amplias.  Representar el recorrido de los cantos en la API de Google Maps En este momento, la interfaz gráfica de usuario es solo capaz de mostrar las coordenadas geográficas por campañas, es decir, que no puede mostrar al 79 TFG | José Antonio Hernández Rodríguez Si se quieren conservar los parámetros, que aparecen en el diálogo, durante la monitorización se debe hacer click en ‘No Modificar’; en caso contrario se establecen los parámetros oportunos correctamente y se hace click en ‘Modificar’. Tras elegir la opción deseada se muestra la pantalla principal de la interfaz gráfica, esta pantalla se muestra en la Fig. M3. Las acciones que se pueden que realizar con la interfaz gráfica se dividirán en dos partes: una con las acciones que se pueden realizar durante el proceso de monitorización y otra con las que se puede realizar durante el postproceso. Fig. M2 – Diálogo de configuración de los parámetros de la estación total Fig. M3 – Pantalla principal de la IU 80 TFG | José Antonio Hernández Rodríguez  Monitorización Durante la monitorización se puede realizar diferentes acciones. Por ejemplo, previo a la monitorización se puede establecer nuevamente el ángulo α, para ello se debe ir a ‘Detecciones  Calcular Ángulo H’ de el menú superior de la pantalla principal de la IU (Fig. M3), así se deja preparado para que la siguiente medición por parte de la estación total sirva para el cálculo de dicho ángulo. En caso de que el usuario se haya equivocado y no quiere realizar este cálculo de ir a la misma ruta (‘Detecciones  Calcular Ángulo H’) cancelando así el proceso. En la Fig. M4 se puede ver exactamente donde se debe hacer click para realizar esta acción. Además si se selecciona la opción de establecer el ángulo α, deberá aparecer el texto “A la espera de calcular el ángulo H, haga la medida con la estación total” en la barra inferior de la pantalla principal de IU. Otra de las acciones que puede realizarse es realizar una medida topográfica, aquí es necesario apretar el botón con la imagen siguiente: Antes de que se añada el registro en la tabla para proceder a la medición topográfica, se le pide al usuario que confirme la misma, con un diálogo como el de la Fig. M5. Fig. M4 – Establecer Ángulo α 81 TFG | José Antonio Hernández Rodríguez Si el usuario finaliza por confirmar la acción se debe realizar la medición con la estación total para completar el proceso. El usuario también tiene posibilidad de editar los distintos registros que aparecen en la tabla de detecciones, restringiendo la edición al rfid del registro; si se desea realizar esta acción el usuario debe seleccionar previamente el registro que quiere modificar y posteriormente hacer click en el botón que tiene como imagen: Una vez que el usuario selecciona el botón le aparece el diálogo de la Fig. M6, aquí establece el número de RFID correspondiente y se hace click en ‘Aceptar’. Si la edición se produce satisfactoriamente, la IU se encarga de mostrar un mensaje informado al usuario que la edición del registro con el número de RFID que ha establecido se ha realizado correctamente. En la Fig. M7 se muestra dicho diálogo informativo. Fig. M5 – Confirmación punto topográfico Fig. M6 – Diálogo para editar registro 82 TFG | José Antonio Hernández Rodríguez Además de editar los registros, éstos también pueden ser eliminado, el proceso es exactamente igual, se selecciona la fila correspondiente, se elige la opción de eliminar, habiendo un dialogo de eliminado posterior y el informe de que se ha realizado correctamente; la única diferencia es que el botón destinado para la eliminación de los registros es el siguiente: Otro de los aspectos que se puede tratar durante la monitorización, es realizar la siembra, esta es la etapa del estudio de dispersión en que se coloca los cantos a lo largo de la playa. Dicha etapa se tratará como una campaña independiente. Para establecer este modo hay que seleccionar el CheckBox titulado ‘Modo Siembra’ que se encuentra a la derecha de los botones de edición y eliminación de registros vistos anteriormente. Cuando se activa éste se muestra al usuario una entrada de texto donde deberá escribir el número de RFID que se va a sembrar en ese momento, esta entrada de texto puede verse en la Fig. M8. Si se quiere realizar una medida topográfica debe introducirse el número ‘-2’. La interfaz gráfica trabaja de tal manera que cuando recibe una medida de la estación total crea un registro con las coordenadas obtenidas y como rfid el número que se haya puesto en la entrada de texto. En caso de que no se quiere Fig. M7 – Diálogo de edición correcta Fig. M8 – Entrada de texto del modo siembra 83 TFG | José Antonio Hernández Rodríguez sembrar una piedra, y lo que quiera hacerse sea una medida topográfica debe introducirse el número ‘-2’. Por último el usuario puede realizar la configuración de los parámetros de la estación total, de la base de datos y del GPS (estos últimos tienen que ver con las opciones de los Waspmotes, pero que han quedado obsoletas debido al desuso provocado por los malos resultados obtenidos). El usuario deberá ir a ‘Opciones  Configuración’ para proceder a la configuración, entonces se le mostrará una pantalla como la de la Fig. M9, aquí el usuario pondrá los parámetros como considere oportuno y finalizará haciendo click en ‘Aceptar’.  Postproceso En el postproceso las operaciones principales que se pueden realizar son: realizar informes y realizar búsquedas. Para realizar informes hay dos opciones posibles: obtener una imagen del mapa, en formato JPEG, que se está visualizando en la interfaz u obtener un fichero en formato EXCEL con la tabla que aparece a la derecha del mapa (Fig. M3) con la información de las detecciones y de los puntos topográficos resultantes de la realización de las campañas. Fig. M9 – Ventana de configuración 84 TFG | José Antonio Hernández Rodríguez En caso de que se quiere obtener la imagen del mapa en cuestión, se debe hacer click sobre el botón que se encuentra debajo del mapa (Fig. M10) con el texto ‘Guardar Imagen’. Tras haber hecho click en este botón aparecerá un diálogo para guardar la imagen como el que sale en la Fig. M10, aquí se selecciona el directorio deseado y se establece un nombre para la imagen, una vez elegido se hace click en ‘Guardar’. Si el proceso de guardado se ha realizado correctamente, se nos informa con un dialogo como el de la imagen siguiente (Fig. M11). El proceso para obtener el extracto de la tabla de detecciones en formato EXCEL es igual que el anterior, la única diferencia consiste en que para empezar el proceso se debe hacer click en el botón que se encuentra debajo de la tabla de detecciones (Fig. M3) que tiene por nombre ‘Guardar Búsqueda’. Fig. M10 – Diálogo para guardar los informes Fig. M11 – Diálogo de guardado correcto 85 TFG | José Antonio Hernández Rodríguez Si lo que se desea es realizar una búsqueda, debe atenderse al menú que aparece en la Fig. M12, que es una porción de la pantalla principal de la interfaz, que se encuentra en la parte superior central de la misma. Las búsquedas están orientadas a las campañas y a las marcas RFID. Para las campañas hay un SelectBox donde se seleccionará una de las campañas que se hayan realizado, dando la posibilidad también de que se busque en todas las campañas existentes. En cuanto a las marcas RFID hay tres opciones: Todas las marcas RFID. Se debe seleccionar el CheckBox titulado ‘Todos’. Por rango, las marcas están numeradas de 1 a n, entonces el rango debe ser un conjunto dentro de este intervalo. Se selecciona el CheckBox titulado ‘Por rango’ y se establece el rango con los números deseados. Por la selección de una serie de marcas concretas, se hace click en el RFID del que se quiere realizar la búsqueda, y en caso de que sea más de una marca, deberemos ir seleccionándolas mientras se mantiene pulsado el botón ‘Ctrl’ del teclado. Una vez se hayan establecido los parámetro se debe apretar el botón sobre el que aparece una imagen de una lupa. Imagen 1.3 – Diálogo de guardado correcto Fig. M12 – Menú de búsqueda de la IU