Servidor web para la comunicación con redes de sensores

Joel Rodríguez Alemán

Tutor: Jorge Cabrera Gámez Cotutor: Antonio Carlos Domínguez Brito

Cotutor: José Daniel Hernández Sosa Profesores Titulares Escuela de Ingeniería Informática Departamento de Informática y Sistemas de la ULPGC

Las Palmas de Gran Canaria – 06 de julio de 2011

ÍNDICE 1. Introducción ................................................................................................. pag 7 2. Estado actual del tema ................................................................................ pag 9 3. Objetivos ...................................................................................................... pag 11 4. Competencias cubiertas .............................................................................. pag 13 4.1. CII01 ............................................................................................... pag 13 4.2. CII02 ............................................................................................... pag 13 4.3. CII04 ............................................................................................... pag 13 4.3.1. Objeto del contrato ............................................................. pag 14 4.3.2. Presupuesto ....................................................................... pag 14 4.3.3. Especificaciones técnicas .................................................. pag 14 4.3.4. Condiciones particulares.................................................... pag 14 4.4. CII18 ............................................................................................... pag 15 4.4.1. Ámbito internacional .......................................................... pag 15 4.4.2. Ámbito europeo .................................................................. pag 17 4.4.3. Ámbito nacional ................................................................. pag 18 5. Aportaciones ................................................................................................ pag 23 6. Normativa y legislación ................................................................................ pag 25 6.1. GNU General Public License .......................................................... pag 25 6.1.1. Software libre ..................................................................... pag 25 6.2. Zope Public License ....................................................................... pag 26 6.3. Dominio público .............................................................................. pag 26 6.4. Digi International ............................................................................. pag 27 7. Requisitos .................................................................................................... pag 29 7.1. Hardware ........................................................................................ pag 29 7.2. Software .......................................................................................... pag 29 7.2.1. Ubuntu ............................................................................... pag 29 7.2.2. X-CTU ................................................................................ pag 29 7.2.3. Cutecom ............................................................................. pag 30 7.2.4. API de Google Maps .......................................................... pag 30 7.2.5. Zope ................................................................................... pag 30 7.2.6. Plone .................................................................................. pag 30 7.3. Librerías .......................................................................................... pag 31 7.3.1. Libxbee .............................................................................. pag 31 7.3.2. SQLite ................................................................................ pag 31 7.4. Lenguajes ....................................................................................... pag 31 7.4.1. C ........................................................................................ pag 31 7.4.2. PHP .................................................................................... pag 31

7.4.3. Javascript ........................................................................... pag 32 7.4.4. Python ................................................................................ pag 32 8. Plan de trabajo y temporización .................................................................. pag 33 8.1. Fase 1 ............................................................................................. pag 33 8.2. Fase 2 ............................................................................................. pag 33 8.3. Fase 3 ............................................................................................. pag 33 8.4. Fase 4 ............................................................................................. pag 33 9. Análisis......................................................................................................... pag 35 9.1. Estructura general del trabajo ......................................................... pag 35 9.1.1. Recepción de los datos...................................................... pag 35 9.1.2. Almacenamiento de la información .................................... pag 36 9.1.3. Impresión de los datos ....................................................... pag 36 9.2. Diseño del programa de análisis sintáctico .................................... pag 37 9.3. Diseño de la base de datos ............................................................ pag 38 9.4. Diseño de la interfaz web ............................................................... pag 38 9.5. Tipos de paquetes que se pueden recibir ....................................... pag 39 9.6. Formato de los paquetes ................................................................ pag 40 9.7. Redes de interconexión .................................................................. pag 41 9.8. Configuración de los módulos de radio .......................................... pag 41 9.9. Problemática del uso combinado de PHP y Javascript .................. pag 42 10. Desarrollo .................................................................................................. pag 43 10.1. Configuración de los módulos de radio ........................................ pag 43 10.2. Programa receptor de datos ......................................................... pag 45 10.2.1. radio.c .............................................................................. pag 45 10.2.2. parsear.h .......................................................................... pag 48 10.3. Interfaz web .................................................................................. pag 48 10.3.1. devices.php ...................................................................... pag 49 10.3.2. tablas.php ........................................................................ pag 50 10.3.3. track.php .......................................................................... pag 50 10.4. Comprobar confirmación de paquetes con Cutecom ................... pag 51 11. Validación experimental ............................................................................. pag 53 12. Conclusiones ............................................................................................. pag 55 13. Trabajo futuro ............................................................................................ pag 57 13.1. Trabajar con N dispositivos ........................................................... pag 57 13.2. Mayor robustez ............................................................................. pag 57 13.3. Mayor flexibilidad .......................................................................... pag 57 13.4. Trabajar con correo electrónico .................................................... pag 58 13.5. Mayor funcionalidad del demonio receptor de datos .................... pag 58

14. Referencias ............................................................................................... pag 59 Apéndice: Manual de usuario y software ......................................................... pag 61 1. Instalación de librerías ....................................................................... pag 61 1.1. SQLite ................................................................................... pag 61 1.2. Libxbee ................................................................................. pag 61 2. Instalación de Python ........................................................................ pag 62 3. Instalación de Zope y Plone .............................................................. pag 62 4. Instalación del plugin PHParser para Zope ....................................... pag 63 5. Configuración de Zope ...................................................................... pag 63 6. Instalación y ejecución del demonio receptor de datos ..................... pag 65

1. INTRODUCCIÓN En el presente trabajo se pretende coordinar la recepción de información proveniente de dispositivos móviles que se comunican de forma inalámbrica. En concreto, se realizará un servidor de comunicaciones que recibe datos de un dispositivo Waspmote. Aunque ya hablaremos de él más tarde, Waspmote es un sistema empotrable diseñado para el desarrollo de redes sensoriales. Es capaz de tomar una serie de medidas y enviarlas a otro Waspmote o a un PC mediante ondas de radio, GPRS o Iridium. La información que recibamos será gestionada mediante una base de datos SQL. Esta base de datos contendrá información que será visualizada posteriormente a través de una interfaz web. Teniendo en cuenta la estructura que posee nuestro trabajo, hemos organizado este documento en una serie de capítulos que a continuación explicaremos. En primer lugar, comenzaremos hablando del estado actual del tema. Es decir, explicaremos en qué situación nos encontramos antes de comenzar a trabajar. En segundo lugar explicaremos los objetivos que pretendemos conseguir en el presente trabajo. A continuación haremos un análisis de las competencias que tenemos que cubrir con este trabajo, y explicaremos de qué forma las hemos cumplido. Posteriormente explicaremos qué aportaciones realiza este trabajo a nuestro entorno socio – económico. En quinto lugar incluiremos la legislación vigente sobre trabajos informáticos que esté relacionada con nuestro trabajo. Seguidamente hablaremos de los diferentes requisitos software y hardware necesarios para la realización de este trabajo. En la parte de hardware hablaremos del dispositivo Waspmote, que es el que hemos utilizado, y en la parte de software detallaremos qué librerías y lenguajes de programación, entre otras cosas, hemos utilizado. En el siguiente capítulo detallaremos el plan de trabajo que seguiremos para desarrollar este trabajo fin de grado. Luego realizaremos un análisis teórico de los pasos a seguir para la realización de este trabajo, así como de ciertas cuestiones que debemos tener en cuenta a la hora de comunicar el dispositivo Waspmote con el PC. En noveno lugar explicaremos la solución planteada al trabajo, así como aquellas acciones que hemos tenido que realizar para el correcto funcionamiento de nuestro código. A continuación veremos la prueba a la que hemos sometido el proyecto tras su terminación para comprobar su correcto funcionamiento. En undécimo lugar expondremos nuestras reflexiones sobre el trabajo realizado, y veremos qué es lo que hemos conseguido. A continuación hablaremos de qué posibles mejoras se pueden aplicar al presente trabajo, y las dejaremos planteadas como posible trabajo futuro sobre el mismo. Por último, detallaremos en un apéndice las fuentes de donde se ha obtenido la información necesaria para desarrollar este trabajo.

2. ESTADO ACTUAL DEL TEMA En este capítulo explicaremos en qué situación nos encontramos antes de comenzar a trabajar. Aunque Waspmote es un dispositivo de muy reciente creación, ha tenido una excelente acogida en todo el mundo. Diferentes empresas han hecho uso de este dispositivo, como Telefónica, Sony Ericsson, Vodafone, IBM, etc., así como diferentes universidades, como la universidad de Cambridge, la universidad Rey Juan Carlos, la universidad de Arizona, etc. Aquí podemos ver un mapa con los diferentes países de todo el mundo en donde se utiliza Waspmote:

Asimismo, Waspmote está siendo usado en multitud de proyectos como:

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. En nuestro caso, lo que pretendemos es colocar este dispositivo junto a unos derivadores en el mar para que se encargue de tomar una serie de medidas y enviarlas mediante ondas de radio a un PC para su visualización. Esta capa de comunicación no está implementada, de modo que tendremos que programarla nosotros. En el plano académico, existen algunos proyectos que han incluido este dispositivo en su implementación, como los siguientes:

1. Calificación energética de edificios: gestión y planificación del proyecto, desarrollado por Fabio Rentero Delgado en la universidad Rey Juan Carlos.

http://eciencia.urjc.es/dspace/bitstream/10115/5027/1/PFC_Fabio%20Rentero.pdf

2. Plataforma modular e interfaces genéricas de transductores para redes de sensores inalámbricas, desarrollado por Jorge Portilla Berrueco en la universidad Complutense de Madrid.

http://oa.upm.es/3086/2/JORGE_PORTILLA_BERRUECO.pdf

3. A viability plan of a unit of research in applications of new telecommunications technologies, desarrollado por Alberto Tena del Pozo en la universidad Politécnica de Cataluña.

http://upcommons.upc.edu/pfc/bitstream/2099.1/7843/1/memoria.pdf

3. OBJETIVOS En este capítulo expondremos los objetivos a cumplir con el presente trabajo. El trabajo presentado en esta memoria se divide en dos partes, cada una con sus objetivos:

1. La primera parte consiste en desarrollar una aplicación que reciba continuamente una serie de datos enviados por un dispositivo Waspmote mediante ondas de radio, GPRS o Iridium. Este dispositivo será colocado en el mar y se dedicará a tomar una serie de medidas a intervalos regulares. Los datos que envíe este dispositivo serán almacenados en una base de datos tan pronto como se vayan recibiendo.

2. La segunda parte consiste en diseñar una pequeña aplicación web que lea la información contenida en la base de datos y la muestre en una cómoda interfaz, además de indicar la ubicación actual de los dispositivos en un mapa. Esta aplicación sólo será accesible por usuarios registrados en el sistema que posean contraseña. De esta forma, nuestra aplicación estará disponible sólo para usuarios autorizados, y además podrá usarse en cualquier infraestructura de red.

El objetivo fundamental de la primera parte del trabajo consiste en garantizar la compatibilidad entre el dispositivo emisor y el equipo informático que recibe los datos. Al tratarse de plataformas diferentes (comunicación entre Waspmote y un PC), tenemos que asegurarnos de que no van a existir problemas de compatibilidad entre los formatos de paquetes que usan ambos dispositivos. El objetivo fundamental de la segunda parte del trabajo consiste en la sencillez. Teniendo en cuenta que la información a almacenar es tremendamente simple, la base de datos será muy sencilla. Consecuentemente, la interfaz web tampoco requerirá de grandes excesos. Por tanto, intentaremos no construir un código excesivamente complejo. En lugar de eso, buscaremos claridad y simplicidad, sin dejar de lado la eficiencia, e intentaremos además que la interfaz web sea intuitiva y fácil de utilizar.

4. COMPETENCIAS CUBIERTAS En el presente trabajo se nos exige el cumplimiento de una serie de competencias profesionales. En este capítulo mostraremos las competencias que debemos cumplir, y explicaremos detalladamente de qué manera hemos cubierto cada una de ellas. 4.1. CII01: capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigente. Esta competencia queda cubierta en los siguientes capítulos:

1. Análisis: se explica a nivel teórico todas las variables que debemos contemplar para planificar la elaboración de nuestro trabajo.

2. Desarrollo: encontramos en este capítulo las decisiones de implementación que hemos tomado, y se explica exhaustivamente nuestra elección frente a otras alternativas igualmente válidas.

Por último, sólo resta comentar que, la decisión de restringir el acceso a nuestra interfaz web mediante la solicitud de un usuario y una contraseña, da como resultado una aplicación que respeta fielmente los principios éticos y la legislación vigente. 4.2. CII02: capacidad para planificar, concebir, desplegar y dirigir trabajos, servicios y sistemas informáticos en todos los ámbitos, liderando su puesta en marcha y su mejora continua y valorando su impacto económico y social. Esta competencia queda cubierta en los siguientes capítulos:

1. Aportaciones: se explica el impacto del trabajo en la economía del sector.

2. Plan de trabajo y temporización: se detallan los pasos a seguir en la elaboración del trabajo y la temporización.

Como se observa en el capítulo de aportaciones, este trabajo supone una mejora en la productividad a la hora de manipular los dispositivos, así como deriva en una reducción de gastos altamente interesante en estos tiempos de crisis. 4.3. CII04: capacidad para elaborar el pliego de condiciones técnicas de una instalación informática que cumpla los estándares y normativas vigentes. A continuación se detallará el pliego de condiciones técnicas que han de regir en la contratación de un servidor web para la comunicación con redes de sensores.

4.3.1. Objeto del contrato El contrato tiene como objeto el desarrollo de una aplicación que monitorice los datos enviados desde una red de sensores. 4.3.2. Presupuesto a) Kit de desarrollo (5 dispositivos Waspmote + Gateway): 1800 €. b) Equipo para el servidor: 700.00 € aproximadamente. c) Coste de desarrollo: 15 € hora x 300 horas de trabajo = 4500 €. En el capítulo de plan de trabajo se expone la repartición de estas horas. El presupuesto para la presente contratación es de 7000.00 €, al que incluyendo el 5 % de I.G.I.C. da como resultado un máximo de 7350.00 €. Este presupuesto no incluye la cuota de conexión a Internet ADSL, puesto que el precio puede variar dependiendo de la operadora con la que se contrate el servicio y las ofertas que ofrezcan. 4.3.3. Especificaciones técnicas

1. La aplicación debe ser capaz de monitorizar varios dispositivos Waspmote al mismo tiempo.

2. La aplicación debe llevar el registro de las diferentes posiciones por donde va moviéndose el dispositivo, y reflejarlas sobre el mapa de la interfaz.

3. Debe exigirse un nombre de usuario y una contraseña para acceder a la interfaz web.

Asimismo, el adjudicatario debe preparar un manual de usuario sin coste adicional alguno, con la suficiente información como para que las personas interesadas puedan utilizar la aplicación sin problemas. 4.3.4. Condiciones Particulares Plazo de ejecución El contratista se compromete a elaborar el software de conformidad con lo establecido en este documento y con la oferta que hubiese presentado, así como a entregarlo al contratante. Dicha entrega deberá hacerse en el plazo máximo de cuatro meses, a contar desde la fecha de firma del contrato. El software se considerará debidamente entregado cuando se haya recibido la aplicación, esté disponible para su inmediato funcionamiento y se haya facilitado el manual y la documentación técnica correspondiente. Penalizaciones Cualquier incumplimiento del servicio técnico postventa y de mantenimiento

y plazos de entrega, conllevará una penalización del 0.001 % por cada día natural de incumplimiento sobre el precio del contrato. En caso de que el pago por parte del contratante estuviera realizado con anterioridad, la empresa contratada, abonar al contratante el importe de la penalización. La penalización máxima por este concepto no excederá del 10 % del importe final del Contrato. Documentación Las empresas licitadoras deberán poner claramente de manifiesto las posibles actualizaciones de la aplicación. 4.4. CII18: conocimiento de la normativa y la regulación de la informática en los ámbitos nacional, europeo e internacional. 4.4.1. Ámbito internacional En el contexto internacional, son pocos los países que cuentan con una legislación apropiada. Entre ellos destacan Estados Unidos, Alemania, Austria, Gran Bretaña, Holanda, Francia, Argentina y Chile.

A continuación se mencionan algunos aspectos relacionados con la ley en los diferentes países, así como con los delitos informáticos que persigue. Estados Unidos Este país adoptó en 1994 el Acta Federal de Abuso Computacional que modificó el Acta de Fraude y Abuso Computacional de 1986. Con la finalidad de eliminar los argumentos hipertécnicos acerca de qué es y qué no es un virus, un gusano o un caballo de Troya, la nueva acta proscribe la transmisión de un programa, información, códigos o comandos que causan daños a la computadora, a los sistemas informáticos, a las redes, información, datos o programas. La nueva ley es un adelanto porque está directamente en contra de los actos de transmisión de virus. Asimismo, en materia de estafas electrónicas, defraudaciones y otros actos dolosos relacionados con los dispositivos de acceso a sistemas informáticos, la legislación estadounidense sanciona con pena de prisión y multa, a la persona que defraude a otro mediante la utilización de una computadora o red informática. En el mes de Julio del año 2000, el Senado y la Cámara de Representantes de este país establece el Acta de Firmas Electrónicas en el Comercio Global y Nacional. La ley sobre la firma digital responde a la necesidad de dar validez a documentos informáticos (mensajes electrónicos y contratos establecidos mediante Internet) entre empresas (para el B2B) y entre empresas y consumidores (para el B2C).

Alemania Este país sancionó en 1986 la Ley contra la Criminalidad Económica, que contempla los siguientes delitos:

Espionaje de datos. Estafa informática. Alteración de datos. Sabotaje informático.

Austria La Ley de reforma del Código Penal, sancionada el 22 de Diciembre de 1987, sanciona a aquéllos que con dolo causen un perjuicio patrimonial a un tercero influyendo en el resultado de una elaboración de datos automática a través de la confección del programa, por la introducción, cancelación o alteración de datos o por actuar sobre el curso del procesamiento de datos. Además contempla sanciones para quienes comenten este hecho utilizando su profesión de especialistas en sistemas. Gran Bretaña Debido a un caso de hacking en 1991, comenzó a regir en este país la Computer Misuse Act (Ley de Abusos Informáticos). Mediante esta ley el intento, exitoso o no, de alterar datos informáticos es penado con hasta cinco años de prisión o multas. Esta ley tiene un apartado que especifica la modificación de datos sin autorización. Holanda El 1 de Marzo de 1993 entró en vigencia la Ley de Delitos Informáticos, en la cual se penalizan los siguientes delitos:

El hacking. 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.

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).

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.

Conducta maliciosa que altere, dañe o destruya los datos contenidos en un sistema de tratamiento de información.

4.4.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 2001. 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 organos 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:

1. 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 de delitos.

2. Delitos informáticos.

Falsificación informática que produzca la alteración, borrado o supresión de datos informáticos que ocasionen datos no auténticos.

Fraudes informáticos.

3. Delitos relacionados con el contenido.

Delitos relacionados con la pornograf ́ infantil.

4. 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 cada uno de los apartados descritos en cada categoría. En la Disposición 14221 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. 4.4.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 13 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”. Tipos de Infracciones:

Leves (art.44.2): multas de 100.000 a 10M pts. Ej: rectificar datos o no comunicarlos a la Agencia de Protección Datos.

Graves (art.43): multas de 10M a 50Mpts: Ej: no mantener sistemas de seguridad, obstrucción a inspección, uso en provecho propio...

Muy Graves (art.45): multas de 50M a 100M (“Conductas reprochables”).

Ej: vulnerar a propósito el secretismo, etc...

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 1. 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.

2. 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.

3. Seguridad en el intercambio de 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.

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.

4. Para terminar

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.

¿En qué casos se infringe la Ley?

Al copiar o distribuir un programa de ordenador o la documentación que le acompaña, incluidas aplicaciones, datos, códigos y manuales, sin permiso expreso 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. 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.

5. APORTACIONES Este trabajo supone una pequeña pero interesante contribución a nuestro entorno socio – económico. En primer lugar, este trabajo ofrece un método sistematizado para la obtención de datos. Al construir una capa de comunicación entre el dispositivo que toma los datos y los envía y entre el equipo informático, es posible recibir a intervalos regulares tantos datos como el dispositivo sea capaz de tomar. De esta forma, nuestro trabajo no es más que un caso concreto de entre las varias aplicaciones potenciales que podría implementar. En segundo lugar, este trabajo conlleva un ahorro significativo de dinero. En efecto, antes del desarrollo de este trabajo los dispositivos tenían que ser programados a mano para recibir datos, tomar medidas con el acelerómetro, etcétera. Por tanto, en nuestro caso concreto, en el que colocamos los dispositivos en el mar, para realizar esta labor es preciso coger un barco para desplazarse hasta la ubicación de los dispositivos. Este trabajo viene a solventar este tedioso problema, con el consiguiente ahorro económico y la contribución medioambiental que eso supone. Entendemos aquí por contribución medioambiental el hecho de no tener que coger el barco para desplazarnos, y por tanto, el hecho de no tener que gastar gasolina para tal fin. Asimismo, existe también una mejora en la productividad a la hora de trabajar con los dispositivos. La razón es obvia: se elimina la necesidad de los desplazamientos para reconfigurar los dispositivos y monitorizarlos.

6. NORMATIVA Y LEGISLACIÓN En este capítulo analizaremos la legislación vigente que afecta a este trabajo fin de grado. 6.1. GNU General Public License Los dispositivos Waspmote, así como Ubuntu, la librería Libxbee, Plone y Cutecom ejecutan código liberado bajo esta licencia. La Licencia Pública General de GNU, o más conocida por su nombre en inglés GNU General Public License, es una licencia creada por la Free Software Foundation en 1989 (su primera versión), y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios. Existen varias licencias “hermanas” de la GPL, como la licencia de documentación libre de GNU (GFDL), la Open Audio License, para trabajos musicales, etcétera, y otras menos restrictivas, como la MGPL, o la LGPL (Lesser General Publical License, antes Library General Publical License), que permiten el enlace dinámico de aplicaciones libres a aplicaciones no libres. La licencia GPL, al ser un documento que cede ciertos derechos al usuario, asume la forma de un contrato, por lo que usualmente se la denomina contrato de licencia o acuerdo de licencia. 6.1.1. Software libre El software libre (en inglés free software, aunque esta denominación también se confunde a veces con “gratis” por la ambigüedad del término en el idioma inglés) 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, copiar, 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 de explotación son 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 original. 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 de éste, habitualmente 70 años. Si un autor condiciona su uso bajo una licencia, por muy débil que sea, ya no es del dominio público. 6.2. Zope Public License El gestor de contenidos Zope se encuentra liberado bajo esta licencia. La Zope Public Licence o ZPL es una licencia de software libre, usada primordialmente para el software de servidores de Zope. La licencia es similar a la licencia BSD, si bien ZPL támbien incluye cláusulas que prohiben el uso comercial y requiere la documentación de todos los cambios al software. La licencia BSD es la licencia de software otorgada principalmente para los sistemas BSD (Berkeley Software Distribution). Es una licencia de software libre permisiva como la licencia de OpenSSL o la MIT License. Esta licencia tiene menos restricciones en comparación con otras como la GPL estando muy cercana al dominio público. La licencia BSD al contrario que la GPL permite el uso del código fuente en software no libre. 6.3. Dominio público La librería SQLite se encuentra bajo lo que se conoce como dominio público. Por dominio público se entiende la situación en que quedan las obras literarias, artísticas o científicas (lo que incluye programas informáticos) al expirar el plazo de protección de los derechos patrimoniales exclusivos que las leyes de derecho de autor reconocen en favor del derecho habiente y que implica que pueden ser explotadas por cualquier persona o corporación, pero siempre respetando los derechos morales (básicamente la paternidad). Esto sucede habitualmente trascurrido un término contado desde la muerte del autor (post mortem auctoris). Las obras cubiertas por el derecho de autor pasan al dominio público pasados 50 años desde la muerte de su autor como mínimo, en concordancia con el Convenio de Berna, aunque dicho convenio reconoce el derecho de los países signatarios a ampliar el plazo de la protección. Por ello, en muchos ordenamientos el plazo es de 70, 80 o 100 años desde la muerte del autor. Países firmantes del Acuerdo de Aspectos de Propiedad Intelectual aplicado al Comercio (ADPIC o TRIPS por su sigla en inglés), uno de los acuerdos de la Organización Mundial del Comercio, se comprometen a un mínimo de 70 años tras la muerte del autor. En algunos países, el autor puede voluntariamente ceder al dominio público una obra, es decir, renunciar a los derechos patrimoniales sobre su obra, manteniendo la paternidad sobre la misma.

6.4. Digi International El programa X-CTU es propiedad de Digi International y está protegido por las leyes de copyright de Estados Unidos. Es software gratuito, en la medida en que puede ser descargado, instalado y distribuido sin límite alguno, pero no es software libre puesto que su código no puede ser modificado o alterado de ninguna forma. Digi International Inc. fue formada en 1985 como una corporación de Minnesota y reorganizado como una corporación de Delaware en 1989, junto con su oferta pública inicial. En sus inicios, esta empresa ofrecía tarjetas inteligentes ISA / PCI con múltiples interfaces asíncronas serie para PC. Hoy en día, este tipo de tarjetas siguen siendo parte de su línea de productos, pero la compañía se está centrando en ofrecer soluciones de comunicación para redes integradas y externas.

7. REQUISITOS En este capítulo mencionaremos todos los recursos que hemos necesitado para llevar a cabo los objetivos propuestos en este trabajo. Dichos recursos pueden clasificarse en cuatro grupos: hardware, software, librerías y lenguajes. 7.1. Hardware En lo que respecta al hardware, el dispositivo con el que nos comunicaremos es Waspmote, desarrollado por Libelium. En esencia, Waspmote es un sistema empotrado que permite realizar mediciones y enviarlas por ondas de radio. Es un sistema compatible con diferentes tipos de sensores: gases, eventos, agricultura, etc, y por tanto aplicable a múltiples ámbitos. Para la comunicación mediante ondas de radio utiliza los módems radio de Xbee, fabricados por Digi. Estos módems pueden adquirirse configurados para operar bajo diferentes protocolos (802.15.4, ZigBee, …) y diferentes frecuencias (868 MHz, 900 MHz, 2.4 GHz). En este proyecto se han seleccionado módems del tipo XBee868 Pro, que operan en banda ISM (sin licencia) y son los que mayor alcance nominal presentan (40 Km).

Además de este dispositivo, disponemos de un Gateway incluido junto con Waspmote que se conecta a un puerto USB para que actúe de receptor de las tramas enviadas por el dispositivo. 7.2. Software 7.2.1. Ubuntu Hemos desarrollado este trabajo sobre el sistema operativo Ubuntu. Ubuntu es un sistema operativo de la familia Linux, basado en Debian, y está orientado hacia el usuario promedio, con un fuerte enfoque en la facilidad de uso y en mejorar la experiencia de usuario. Hemos elegido Ubuntu como sistema operativo porque ofrece un entorno de trabajo mucho más cómodo que Windows. Ubuntu puede obtenerse a partir de esta dirección: http://www.ubuntu.com/ 7.2.2. X-CTU X-CTU es una aplicación desarrollada por Digi que ofrece una forma sencilla de configurar los diversos parámetros de las antenas de radio Xbee, además de monitorizar su tráfico. Esta herramienta fue fundamental en la primera parte del trabajo, pues nos sirvió para ajustar la configuración de los módulos de radio y adaptarla a las necesidades de nuestro trabajo, como veremos en el capítulo de desarrollo. Esta aplicación puede descargarse desde la siguiente dirección:

http://www.digi.com/support/productdetl.jsp?pid=3352&osvid=57&s=316&tp=5&tp2=0 7.2.3. Cutecom Cutecom es una herramienta gráfica que nos permite monitorizar el tráfico de los puertos serie de nuestros equipos. Funciona en Linux, Mac OS X y en FreeBSD. Esta aplicación nos fue de gran ayuda en los compases iniciales del trabajo, cuando tras diseñar el programa receptor de los datos necesitábamos comprobar si el dispositivo Waspmote era capaz de recibir correctamente la confirmación de recepción de las tramas que envió. Para instalar Cutecom en Ubuntu, basta con escribir en la terminal: sudo apt-get install cutecom 7.2.4. API de 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 mapas en nuestro sitio web. Esta herramienta nos será útil para registrar el movimiento de los dispositivos Waspmote de que disponemos. Podremos ver sobre el mapa las diferentes localizaciones por las que ha ido moviéndose el dispositivo, e incluso seremos capaces de comprobar qué paquete se mandó en cada posición. 7.2.5. Zope Zope es un servidor de aplicaciones web de código abierto escrito en el lenguaje de programación Python. Para las funciones de edición de contenidos, así como personalizaciones básicas, puede ser usado mediante un navegador web. Zope tiene miles de desarrolladores en todo el mundo. 7.2.6. Plone Plone es un sistema de gestión de contenidos basado en Zope y programado en Python. Puede utilizarse para construir portales, sitios webs corporativos, sitios de noticias, servidor de extranet o intranet, como sistema de publicación, repositorio de documentos y herramienta colaborativa, entre otras cosas. Plone puede descargarse desde esta dirección: Zope ha sido utilizado junto con Plone en este trabajo como gestor de contenidos de nuestra aplicación web. En concreto, se encarga de habilitar el acceso autorizado a los usuarios que le indiquemos, y de restringir el acceso al resto de usuarios. Además, como Zope incluye su propio servidor, no debemos preocuparnos de instalar servidores como Apache.

Tanto Zope como Plone serán descargados desde la terminal. Explicaremos este proceso en el manual de usuario incluido en el apéndice. 7.3. Librerías 7.3.1. Libxbee Libxbee es una librería escrita en C cuya utilidad es gestionar el trasiego de tramas enviadas por ondas de radio mediante las antenas Xbee. Incluye funciones tanto para enviar como para recibir datos, y permite un seguimiento muy minucioso sobre las estructuras de las tramas a manipular. Hemos usado esta librería como capa de abstracción de alto nivel para capturar los paquetes enviados desde Waspmote. 7.3.2. SQLite SQLite es una librería que permite utilizar sentencias SQL desde el lenguaje de programación C. Esta librería no se conecta a una base de datos externa, sino que crea la suya propia y trabaja sobre ella. Hemos usado esta librería para conseguir automatizar de manera sencilla la inserción de los datos recibidos en una base de datos SQL, sin necesidad de recurrir a otros lenguajes de programación. En el manual de usuario incluido en el apéndice explicaremos cómo se pueden obtener estas librerías. 7.4. Lenguajes 7.4.1. C C es un lenguaje de programación imperativo de alto nivel, aunque con características de bajo nivel, creado en 1972 por Dennis M. Ritchie. Este lenguaje es famoso por la eficiencia del código que produce, y es uno de los lenguajes más populares para crear software de sistemas, aunque también se usa para crear aplicaciones como la que hemos desarrollado en este trabajo. Hemos elegido C como lenguaje de programación para implementar la primera parte de nuestro trabajo, puesto que tanto las librerías Libxbee y SQLite, así como el propio Waspmote, están implementados en este lenguaje. 7.4.2. PHP PHP es un 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 del 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. 7.4.3. Javascript Javascript es un 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. Hemos usado PHP y Javascript para el desarrollo de la interfaz web que mencionamos como segunda parte de nuestro trabajo. 7.4.4. Python Python es un lenguaje de programación de alto nivel cuya filosofía hace hincapié en una sintaxis muy limpia y que favorezca un código legible. Se trata de un lenguaje de programación multiparadigma ya que soporta orientación a objetos, programación imperativa y, en menor medida, programación funcional. Es un lenguaje interpretado, usa tipado dinámico, es fuertemente tipado y multiplataforma. Python es el lenguaje utilizado por el gestor de contenidos Zope. Hemos tenido que instalar una versión de este lenguaje que fuera compatible con nuestra versión de Zope, como veremos.

8. PLAN DE TRABAJO Y TEMPORIZACIÓN En este capítulo vamos a presentar el plan de trabajo desglosado en fases, con una estimación en cada fase del tiempo de trabajo que nos consumirá. 8.1. Fase 1: instalación y verificación del hardware y del entorno de desarrollo El tiempo invertido en esta fase fue de 20 horas. De ese tiempo, 10 horas se dedicaron a la instalación de los paquetes necesarios para el desarrollo (Libxbee, SQLite, Zope…), y las otras 10 horas se dedicaron a la verificación del Gateway en 868 MHz. 8.2. Fase 2: análisis y diseño del sistema de comunicación y control El tiempo invertido en esta fase fue de 80 horas. De ese tiempo, 10 horas se dedicaron al diseño de una capa de abstracción para los diferentes canales de comunicación con la red de sensores, otras 10 horas fueron invertidas en el diseño de la base de datos y del servidor mySQL, otras 30 horas se dedicaron al diseño de la interfaz web del sistema de comunicación y control, y las últimas 30 horas se dedicaron al diseño de la gestión de contenidos con Zope. 8.3. Fase 3: desarrollo del sistema de comunicación y control. Validación experimental El tiempo invertido en esta fase fue de 150 horas. De ese tiempo, 30 horas se dedicaron a la implementación y validación de la capa de abstracción de comunicaciones, otras 25 horas fueron invertidas en la implementación y validación del servidor mySQL, otras 25 horas se dedicaron a la implementación de la interfaz web mediante Zope y patrones html dinámicos, otras 30 horas fueron invertidas en la prueba y depuración del servidor de comunicaciones, y las últimas 15 horas se dedicaron a la redacción de un pequeño manual de usuario. 8.4. Fase 4: documentación y defensa El tiempo invertido en esta fase fue de 50 horas, dedicadas a la documentación sobre las diferentes librerías usadas y la elaboración de la memoria del TFG.

9. ANÁLISIS En este capítulo vamos a explicar el trabajo analítico que hemos realizado para estructurar adecuadamente el trabajo. 9.1. Estructura general del trabajo En este apartado estudiaremos brevemente la estructura general que seguirá nuestro trabajo. Desglosaremos en tres los pasos a seguir por cada trama recibida: 9.1.1. Recepción de los datos He aquí un pequeño esquema que ilustra las fases de esta etapa de nuestro trabajo:

Nuestra aplicación consistirá en un demonio que estará continuamente esperando por la lectura de las tramas enviadas desde los dispositivos Waspmote. A nivel teórico, será posible recibir paquetes de dos fuentes distintas: ondas de radio y correos electrónicos. Si se recibe un paquete mediante ondas de radio, habrá que consultar el puerto USB al que tendremos conectado el Gateway que recibirá las tramas. En nuestro caso, gracias al uso de la librería Libxbee, contamos con una capa adicional de abstracción que nos permite ejecutar funciones de alto nivel que se encargan de esta tarea. Asimismo, tareas como la verificación de los paquetes o la recepción de paquetes fragmentados estarán cubiertas por la librería y serán transparentes para el programador. Por el contrario, si se recibe un paquete mediante un correo electrónico, nuestra aplicación deberá consultar el nuevo mensaje recibido en el servidor de correo del que dispongamos. En cualquier caso, nuestro programa será síncrono; en otras palabras, se quedará esperando a que lleguen los paquetes, y sólo entonces realizará las tareas oportunas.

9.1.2. Almacenamiento de la información He aquí un pequeño esquema que ilustra las fases de esta etapa de nuestro trabajo:

El segundo paso consiste en procesar la información recibida e insertarla en una base de datos. Con cada nuevo paquete recibido, el proceso es el mismo: tras leer el paquete, realizaremos un análisis sintáctico de los datos recibidos (lo que denominamos “parseo” en el esquema) y construiremos una serie de consultas SQL con ellos para almacenar la información en una base de datos. Gracias a que disponemos de la librería SQLite, escrita en C, para la manipulación de nuestra base de datos SQL, todo el proceso de lectura de datos, análisis sintáctico e inserción será realizado desde el mismo demonio encargado de recibir las tramas. De esta forma no necesitaremos hacer uso de otros lenguajes que implementan consultas SQL, como por ejemplo Java. 9.1.3. Impresión de los datos He aquí un pequeño esquema que ilustra este último paso:

Tras la ejecución de los pasos uno y dos, ya tendremos la información de la trama convenientemente almacenada en nuestra base de datos. En el paso tres es cuando el usuario podrá apreciar los datos que el dispositivo Waspmote está enviando. El flujo que seguirá la aplicación es simple: tras iniciar sesión introduciendo un usuario y contraseña, el código de la web leerá la base de datos y, al cargarse, mostrará la información requerida por el usuario.

9.2. Diseño del programa de análisis sintáctico Para realizar adecuadamente esta etapa de análisis sintáctico, consistente en la extracción y creación de consultas, vamos a definir un formato en el que será recibida la información enviada por los dispositivos:

b57t24a13,53,65r0d2011-06-07 12:49:49x+19.33y-16.84k1 La idea subyacente es sencilla: delante de cada medida tomada por el dispositivo habrá un carácter identificador. El programa parseador se encargará de leer, carácter a carácter, la ristra recibida, y según el carácter identificador que lea actualizará la medida correspondiente. Este programa será capaz de leer las medidas sin importar el orden en el que las lea. Además, podrá leer medidas sin una longitud fija. Por ejemplo, medidas como la temperatura o el acelerómetro pueden variar en el número de decimales que presenten, y nuestro parseador deberá estar preparado para ello. Asimismo, esto permite también que la estructura de los mensajes puede cambiar (mayor flexibilidad) en función de los sensores a usar, etc. Las diferentes medidas que podemos recibir dentro de cada mensaje son:

Carácter Medida Longitud (caracteres)

b Batería 3

t Temperatura 10

a Acelerómetro 32

r Reintentos de envío 1

d Fecha 19

x Latitud 11

y Longitud 11

k Tipo de paquete 2

Hemos asumido que la longitud de los diferentes campos que se pueden recibir nunca superará el máximo presentado en esta tabla. Asimismo, debemos aclarar que esta longitud es máxima y no fija. Por ejemplo, la batería tendrá un máximo de tres caracteres (100), pero la mayoría del tiempo tendrá dos o incluso un carácter (valores menores que el 100%).

Asimismo, en la propia estructura del paquete leído por la librería Libxbee, se encuentran dos parámetros adicionales que también necesitaremos: la dirección MAC del dispositivo que envió esa trama y el RSSI, siendo esta última medida la calidad de la señal con la que llegó el paquete.

La decisión de codificar los mensajes en formato ASCII y no en binario responde a la limitación impuesta por las librerías que implementa el dispositivo

Waspmote, que no soportan esta funcionalidad. 9.3. Diseño de la base de datos En este apartado explicaremos el diseño que se ha concebido para la base de datos que almacenará la información recibida desde los dispositivos. Para este trabajo necesitamos una base de datos que será muy sencilla. Teniendo en cuenta las características del problema que estamos resolviendo, y aplicando el modelo entidad-interrelación, parece claro que sólo tenemos que lidiar con dos entidades: 1. La entidad waspmote, haciendo referencia al dispositivo que envía los datos. 2. La entidad paquete, referida a las tramas enviados por el dispositivo. Estas dos entidades se relacionan mediante una interrelación sencilla: waspmote envía paquete. Así pues, añadiendo los atributos que definen a cada entidad, nos queda el siguiente esquema:

El atributo mac sirve como clave primaria para la entidad waspmote, mientras que para la entidad paquete usaremos como clave la combinación de la mac y la fecha. Puesto que los dispositivos enviarán un único paquete cada X segundos, será imposible que se reciban dos paquetes desde la misma mac con exactamente el mismo sello temporal, asumiendo claro está que no se enviarán a la vez paquetes de diferentes tipos. 9.4. Diseño de la interfaz web En este apartado haremos un breve análisis de cómo será la interfaz web que usará el usuario para consultar la información.

Cuando el usuario quiera visualizar los datos recibidos, deberá acceder a una interfaz web de acceso restringido. Solamente aquellos usuarios registrados con contraseña podrán visualizar esta información. Esta capa de seguridad la implementaremos mediante un gestor de contenidos, en nuestro caso Zope. La interfaz web será bastante sencilla y estará dividida en dos partes: un mapa de Google Maps en el que se mostrará la ubicación actual del dispositivo Waspmote y un iframe con un conjunto de tablas que mostrarán la información recibida de ese dispositivo. En lo alto de la interfaz habrá un pequeño menú con los diferentes dispositivos Waspmote con los que estamos trabajando, para así poder seleccionar el dispositivo del que queremos consultar los datos. 9.5. Tipos de paquetes que se pueden recibir Nuestro demonio será capaz de recibir dos tipos de paquetes. En primer lugar, obviamente, será capaz de recibir paquetes normales, con la información medida por los dispositivos. Adicionalmente, estos paquetes podrán exigir confirmación por parte del receptor o no. Así pues, nuestro programa tendrá que comprobar, analizando la estructura Xbee_pkt, perteneciente al paquete leído por la librería Libxbee, si el dispositivo ha requerido que el receptor envíe la confirmación de recepción del paquete. En tal caso, antes de proceder al parseo, enviará un mensaje al dispositivo Waspmote confirmando la recepción. Asimismo, dentro de este tipo de paquetes podremos distinguir subtipos tales como paquetes de estado, paquetes científicos, paquetes de prueba, etc., gracias al campo tipo que se recibe dentro del mensaje. Esta característica puede ser interesante de cara a futuras revisiones del trabajo, por lo que la dejaremos especificada en la base de datos. En segundo lugar, nuestra aplicación será capaz de recibir lo que denominaremos paquetes de sincronización. Estos paquetes no contendrán información, y su cometido será el de solicitar a nuestra aplicación el envío del sello temporal actual. Así pues, nuestro demonio responderá a esta demanda enviando un mensaje con la fecha actual respetando el siguiente formato: YY:MM:DD:SS:hh:mm:ss donde:

YY Año

MM Mes

DD Día

SS Día de la semana

hh Hora

mm Minuto

ss Segundo

Evidentemente, si recibimos paquetes de sincronización, no insertaremos nueva información en la base de datos. 9.6. Formato de los paquetes La librería Libxbee se acoge al formato de paquetes especificado por los módulos Xbee-868. Sin embargo, los dispositivos Waspmote añaden su propia cabecera dentro de la sección de datos definida por el estándar, tal y como se puede apreciar en la siguiente imagen:

En esta imagen, la última fila se corresponde con la cabecera añadida por el propio Waspmote. El resto de las filas definen el estándar Xbee. Las consecuencias directas de la adición de esta cabecera por parte de los dispositivos Waspmote son dos. En primer lugar, en lo que respecta a la recepción de paquetes con el Gateway, necesitaremos tener en cuenta dónde comienzan realmente los datos del usuario. Teniendo en cuenta que Waspmote añade su propia cabecera dentro de la sección de datos, y considerando también la longitud variable de esta cabecera, tendremos que comenzar la lectura de los datos en posiciones diferentes en función de los datos recibidos. En segundo lugar, a la hora de enviar paquetes desde el Gateway al dispositivo Waspmote (por ejemplo, cuando se desea confirmación de recepción), nos veremos obligados a añadir nosotros manualmente esta cabecera a los datos que le enviemos. De lo contrario, los dispositivos Waspmote descartarán el paquete recibido, pues no encontrarán la cabecera que les permite reconocer la trama. En nuestra implementación asumiremos un tamaño máximo de 82 caracteres por mensaje. Esta limitación responde al hecho de que la librería Libxbee, que utilizamos para la recepción de los paquetes, no puede manejar mensajes de tamaños mayores sin ofrecer garantías de funcionar correctamente, sin olvidar que queremos evitar mensajes largos que deriven en la fragmentación de los paquetes, para reducir así al mínimo posible la posibilidad de errores en los

envíos. 9.7. Redes de interconexión Los dispositivos Waspmote y el Gateway que recibe los datos están conectados entre sí por una red con topología mesh, o malla en inglés. Las redes bidimensionales tipo mesh surgen como una extensión de las redes lineales. En las redes mesh bidimensionales cada procesador se conecta directamente con otros cuatro procesadores salvo en los extremos. Cuando los procesadores forman una estructura cuadrada con igual número de procesadores en cada dimensión se denomina mesh cuadrado, y si el número de procesadores es diferente en las dos dimensiones se denomina mesh rectangular. Como es natural los procesadores extremos pueden conectarse entre ellos, como se hace con los arreglos lineales para forma un anillo. A esta topología se le denomina mesh cerrada o toro. En estas topologías mesh la ruta de comunicación puede realizarse a través de una dimensión y seguidamente a través de la otra.

9.8. Configuración de los módulos de radio Los módulos de radio incluidos junto con el dispositivo Waspmote deberán ser sometidos a un proceso de configuración antes de ponerlos a trabajar. En primer lugar, los dispositivos Waspmote trabajan a una frecuencia de 38400 bps. Deberemos pues fijar esta frecuencia de funcionamiento en los módulos de radio para que la comunicación entre ellos sea posible. En segundo lugar, por defecto, estos módulos transmiten a una potencia muy alta, que les permite un alcance de varios kilómetros. Por esta razón, si intentamos hacer pruebas de comunicación entre los dispositivos teniéndolos cerca de nosotros, en una mesa por ejemplo, las señales emitidas pueden saturarse y es posible que las comunicaciones no funcionen adecuadamente. Por tanto, mientras dure la fase de pruebas, deberemos reducir la potencia de emisión de los módulos al mínimo. Asimismo, deberemos tener los dispositivos y el Gateway alejados entre sí como mínimo un metro. Por supuesto, una vez que las pruebas hayan terminado y comencemos a usar los dispositivos Waspmote en un entorno real, donde se encontrarán bastante alejados entre sí, deberemos colocar la potencia de emisión en su valor original.

En tercer lugar, la librería Libxbee, que usaremos para recibir datos del Gateway, usa la API de Xbee para trabajar. Esta funcionalidad no está activada por defecto en los módulos de radio, así que tendremos que activarla nosotros. Por último, deberemos asignar a todos los módulos de radio el mismo valor identificador de la red que establecen los dispositivos Waspmote para conectarse entre ellos y con el Gateway. De esta forma podrán reconocerse y comunicarse entre sí. 9.9. Problemática del uso combinado de PHP y Javascript La API de Google Maps trabaja, esencialmente, sobre Javascript, mientras que la consulta de la información contenida en la base de datos debe hacerse, necesariamente, sobre PHP. Recordando las características de estos lenguajes, PHP se ejecuta del lado del servidor, mientras que Javascript se ejecuta del lado del cliente. Esto supone un problema ya que, para cuando se haya cargado nuestro mapa, el código PHP ya habrá sido interpretado y ejecutado, por lo que no podremos acceder a sus variables para mostrar la información contenida en ellas. Sin embargo, existe una manera de solventar este problema, que consiste en escribir código PHP que muestre por pantalla código Javascript. Este mecanismo resulta un tanto complejo, pero es bastante ingenioso en la medida en que resuelve el problema de cómo incluir en Javascript variables generadas desde PHP, como veremos en el siguiente capítulo.

10. DESARROLLO En este capítulo explicaremos la solución adoptada para resolver el problema planteado en este trabajo. 10.1. Configuración de los módulos de radio Antes de ponernos a trabajar, debemos dejar adecuadamente configurados los módulos de radio que utilizaremos para las comunicaciones. Para ello utilizaremos la herramienta X-CTU, que permite configurar los diversos parámetros de los módulos para ajustarlos a nuestras necesidades. Esta aplicación sólo está disponible en Windows, y aunque puede ser ejecutada en Ubuntu gracias al programa Wine, el proceso de configuración para su correcta ejecución bajo Linux nos ha parecido algo complejo, por lo que hemos preferido simplificar el proceso instalándolo en Windows XP. Una vez instalado el programa, conectamos el módulo al ordenador mediante un puerto USB. Seguidamente, ejecutamos la aplicación X-CTU y pulsamos el botón Test para testear la comunicación entre el PC y el dispositivo.

Tras comprobar que todo marcha correctamente, nos vamos a la pestaña modem configuration, donde tras pulsar read se nos mostrarán los parámetros configurables del dispositivo.

Así pues, realizamos los siguientes cambios en el dispositivo: 1. Modem VID: la ID del módem. Sólo los dispositivos que comparten esta misma ID pueden comunicarse. En nuestro caso, le hemos dado el valor 1234. 2. Node identifier: nombre que le hemos dado al módem. En nuestro caso, le hemos dado el valor "central". 3. Device type identifier: otro tipo de ID más genérica, que sirve para distinguir varios tipos de dispositivos basados en la tecnología Xbee. En nuestro caso, le hemos puesto el valor 6000. 4. Baud rate: frecuencia a la que se comunican los dispositivos. En nuestro caso, le hemos dado el valor 38400. 5. API Enable: habilita la API de Xbee para poder usar las funciones de la librería libxbee. En nuestro caso, le hemos dado el valor 2 - API WITH ESCAPES. Finalmente, pulsamos el botón write para guardar los cambios en el dispositivo. Por último, para probar que el módulo funciona correctamente, nos vamos a la pestaña terminal, en la cual se mostrará el contenido de los paquetes recibidos. Una vez allí, esperaremos por la recepción de un mensaje de prueba por parte de uno de los dispositivos Waspmote. El mensaje de prueba será “OKI DOKI”.

Ignorando la cabecera del mensaje, vemos en la imagen que el mensaje de prueba fue recibido sin problemas. Podemos pues afirmar que el módulo está ya adecuadamente configurado y listo para trabajar. Este proceso de configuración, así como los valores asignados, son idénticos para todos los módulos de radio.

10.2. Programa receptor de datos Tras la configuración de los módulos de radio, ya estamos en disposición de desarrollar nuestro demonio receptor de datos. Nuestra implementación, por razones de tiempo, será bastante básica: simplemente se ejecutará en una consola y, tras mostrar por pantalla el contenido del mensaje, los insertará en la base de datos. Asimismo, mostrará también si se envía o no una confirmación del paquete recibido, o si se recibió un paquete de sincronización y se envía la respuesta a los dispositivos. La aplicación que hemos escrito se compone de dos ficheros: radio.c, que contiene el programa principal que se encarga de todo el trabajo, y parsear.h, que contiene las funciones auxiliares de parseo y de recepción en la base de datos. Empezaremos por el fichero radio.c. 10.2.1. radio.c A continuación mostraremos un pequeño esquema con los pasos más importantes que seguirá nuestra aplicación:

Lo primero que hacemos es inicializar la librería Libxbee, preparándola así para la recepción de paquetes. Este proceso admite una serie de posibilidades tales como visualizar el contenido del fichero log en la pantalla, elegir la frecuencia a la que se recibirán los datos o incluso activar a voluntad el modo API. En nuestro caso, hemos elegido activar este modo y recibir a una frecuencia de 38400 bps. Si todo ha ido bien, ya podremos conectarnos a los dispositivos. Vamos a establecer un total de tres conexiones, una por cada dispositivo Waspmote que tenemos. Cada vez que establecemos una conexión necesitamos especificar un identificador para la conexión, su tipo y la dirección física del dispositivo. En nuestro caso, las conexiones serán de tipo xbee2_data, que es el tipo de conexión reconocible por los dispositivos Waspmote. Tras el establecimiento de las conexiones comenzará el bucle infinito de nuestro programa, cuya primera acción será quedarse esperando por la recepción de un paquete, que podrá llegar indistintamente desde cualquiera de los tres dispositivos Waspmote. Esta espera es síncrona, lo que significa que el programa no avanzará hasta que se reciba un paquete. Cabe destacar que no es necesario ningún recurso de sincronización para recibir los paquetes y almacenarlos, puesto que tan pronto como se lee un paquete se procesa, y mientras dura su procesamiento el resto de paquetes esperarán a ser procesados en el orden en el que llegaron. Una vez que se ha leído un paquete, el primer paso es mostrar su contenido para que el usuario sepa que se ha recibido nueva información. Dependiendo de la manera en que se identifica a la fuente emisora del paquete, el dato empezará en la posición seis o en la doce, por lo que debemos tener esto en cuenta a la hora de mostrar su contenido.

A continuación realizaremos dos comprobaciones: si el dispositivo Waspmote ha solicitado confirmación de la recepción del paquete, o si ha solicitado sincronización de relojes. En cualquier caso, guardaremos esta información para definir nuestras acciones futuras. Posteriormente extraeremos la dirección física del dispositivo del parámetro correspondiente del paquete. Como esta dirección se encuentra en formato unsigned char, deberemos convertirla a formato char * para poder manipularla con facilidad. Realizaremos este mismo proceso en la extracción del RSSI. Estos dos campos se encuentran en la propia estructura xbee_pkt de la librería Libxbee, por lo que podemos extraerlos sin necesidad de que se encuentren dentro del mensaje. Seguidamente, en el caso de que el dispositivo Waspmote nos haya solicitado información (o bien confirmación de recepción o bien sincronización), nos veremos obligados a preparar un paquete para su envío. Si se ha solicitado confirmación, bastará con enviar la siguiente ristra: “Mensaje recibido”. Si por el contrario se requiere sincronización, deberemos crear un sello temporal siguiendo el formato visto en el capítulo anterior y haciendo uso de los métodos de la librería time.h. En cualquier caso, estableceremos la longitud del paquete a enviar y también el desplazamiento a partir del cual el dato estará disponible para los dispositivos Waspmote. Una vez llegados a este punto debemos, en función de lo que se nos solicitó, enviar o no un mensaje al dispositivo emisor con la confirmación o a todos los dispositivos de la red con el sello temporal para su sincronización. En el caso de que se nos requiriera confirmación, tendremos que averiguar a qué dispositivo debemos enviársela comprobando la dirección física que venía incluida en el paquete que hemos recibido, para de este modo elegir la conexión adecuada con la que debemos contactar. Si se nos ha solicitado sincronización no cabe duda alguna: enviaremos el sello temporal a todos los dispositivos de la red. Por último, si no se nos ha pedido información alguna, simplemente indicaremos esta eventualidad por pantalla. Finalmente llegamos a la parte final de nuestro demonio, en la cual insertaremos la información recibida en la base de datos, siempre y cuando no hayamos recibido una solicitud de sincronización, que no contiene información alguna. Es en esta parte del código donde hacemos uso de las funciones auxiliares que hemos declarado en el fichero parsear.h: parsear, para crear una estructura paquete, definida por nosotros, con la información adecuadamente organizada; crearInsercionSQL, que devuelve una ristra con la sentencia SQL de inserción ya creada; y ejecutarSQL, que haciendo uso de la librería SQLite ejecuta la sentencia de inserción. Esta última función devolverá un código de error en caso de que la inserción falle, por lo que si eso ocurre se notificará por pantalla que la operación no pudo realizarse. Si no hubo ningún error, la base de datos ya habrá sido actualizada con éxito, por lo que sólo falta eliminar el paquete que hemos recibido para no gastar memoria innecesariamente.

10.2.2. parsear.h En este fichero definimos un tipo de datos llamado paquete, que en esencia no es más que un struct con los diferentes campos que componen la tabla de paquetes en la base de datos. Hemos creído adecuado el diseño de este tipo de datos para facilitar la manipulación de los datos, así como clarificar el código desarrollado. A continuación nos encontramos la función parsear, que convierte el mensaje recibido al formato paquete antes mencionado. Tras copiar a la estructura paquete que se devuelve los campos mac y RSSI, comienza un bucle en el que leemos carácter a carácter el mensaje recibido. La idea subyacente es simple: cada vez que encontremos un carácter identificador de dato (tal y como se vio en el capítulo de análisis), sabremos qué dato estaremos leyendo y comenzaremos pues a copiarlo, carácter a carácter, en su correspondiente posición en la estructura paquete. Las ventajas que presenta este código son que, por una parte, los datos pueden venir en cualquier orden y ser de cualquier longitud (exceptuando los datos de tamaño fijo como la fecha o el número de reintentos), y por otra parte, en el caso de que se leyera un carácter no reconocido como identificador, simplemente se ignoraría, evitando así la inserción de valores espurios en la base de datos. La siguiente función a analizar es crearInsercionSQL. Esta función recibe la estructura paquete devuelta por parsear y construye con estos datos una sentencia SQL de inserción. La construcción de esta sentencia es tan simple como concatenar el inicio de la sentencia, que siempre es el mismo, con los datos, adecuadamente separados por comillas simples y comas. Por último sólo queda explicar la función ejecutarSQL. Esta función es la que ejecuta la sentencia SQL de inserción gracias al uso de las funciones incluidas en la librería SQLite. El proceso es muy simple: abrimos la base de datos, ejecutamos la sentencia y cerramos la base de datos actualizada. Si ocurre algún error en alguno de estos procesos, se notifica por pantalla y se devuelve un código de error. La función callback es un método auxiliar usado por la función de ejecución de SQLite para realizar la inserción, tal y como se explica en los tutoriales presentes en la propia web de la librería, por lo que no creemos necesario explicarla. 10.3. Interfaz web A continuación procederemos a analizar el código que hemos desarrollado para realizar la interfaz web. Nuestra interfaz se compone de cuatro ficheros: devices.php, con la página principal donde podemos observar los datos recibidos; tablas.php, donde se muestra la información recibida en el último minuto formateada en tablas; track.php, que muestra información exclusiva de un paquete en concreto, como veremos; y por último estilo.css, la hoja de estilos que hemos diseñado para nuestro trabajo.

10.3.1. devices.php Nuestra interfaz debe recibir por la URL el nombre del dispositivo Waspmote que vamos a consultar en ese momento. Esto en principio sólo es relevante para el usuario en un primer acceso, ya que debe incluirse este nombre en la URL. Por lo demás, una vez dentro, podremos cambiar de dispositivo usando un menú que se encargará de agregar el nombre a la dirección. Si no se incluye este valor en la URL, nuestra aplicación no podrá discriminar qué dispositivo queremos consultar y no mostrará nada. Ésta es la manera que hemos elegido de discriminar el dispositivo que consultamos, ante la impracticable idea de mostrarlos todos a la vez. La razón es simple: si los mostráramos todos, todas las rutas seguidas por todos los dispositivos se superpondrían y esta información se volvería un tanto farragosa de analizar. En primer lugar nos encontramos con una etiqueta con un enlace a Google Maps. Esta etiqueta es una clave que debemos solicitar a Google para poder usar la API de Google Maps dentro de nuestro propio dominio. Esta solicitud se puede realizar desde el siguiente enlace: http://code.google.com/intl/es-MX/apis/maps/signup.html A continuación, tras encontrarnos la etiqueta que incluye nuestra hoja de estilo CSS, comienza un primer bloque de código PHP. En este bloque, usando el nombre que recibimos mediante la URL, seleccionaremos de la base de datos todos los paquetes que envió ese dispositivo. Concretamente, nos quedaremos con las latitudes, longitudes y fechas de esos paquetes. Las latitudes y longitudes serán almacenadas en sendos vectores declarados en Javascript, mientras que las fechas se almacenarán en un vector en PHP. Aquí ya podemos apreciar cómo, desde PHP, mostramos por pantalla el código Javascript que realiza este almacenamiento. Cabe destacar que la ristra de código que se muestra por pantalla está concatenada con las diferentes variables PHP que nos interesan, con lo que conseguimos transferir a Javascript el resultado de nuestra consulta SQL realizada en PHP. El segundo bloque de código PHP que viene a continuación es probablemente la sección más importante del código, ya que es en ella donde creamos nuestro mapa y agregamos los iconos con las localizaciones de nuestros dispositivos. Esto lo haremos valiéndonos del mecanismo que ya conocemos de incluir código Javascript en PHP. La función initialize se ejecuta en el instante de carga de la página, y es la que realiza todo el trabajo. Tras comprobar que nuestro navegador web es compatible con las características ofrecidas por la API de Google Maps, declaramos un objeto mapa que representará el mapa que incluiremos en nuestra interfaz. Posteriormente estableceremos el lugar donde queremos que se cargue nuestro mapa al inicio (en nuestro caso, Gran Canaria) y añadiremos unos controles para movernos por el mapa y controlar el zoom a nuestro gusto.

Seguidamente comienza un bucle en el que, en cada iteración, creamos un icono por cada localización en la que estuvo nuestro dispositivo. Nótese cómo usamos el índice PHP incluido dentro del código Javascript para movernos por los vectores que contienen las latitudes y longitudes extraídas de la base de datos. Además, todos estos iconos tendrán asociado un comportamiento para cuando se cliquen sobre ellos. Si esto ocurre, mostraremos a la derecha del mapa los datos correspondientes al paquete que se envió en ese instante de tiempo, razón por la cual seleccionamos la fecha de la base de datos. Adicionalmente, para apreciar visualmente la ruta seguida por nuestro dispositivo, en cada iteración dibujaremos una línea entre el punto actualmente añadido y el inmediatamente anterior. En el tercer y último bloque PHP de este fichero crearemos el menú de dispositivos que se verá en lo alto de la interfaz, y que nos permitirá seleccionar el dispositivo que queremos consultar. Ya que habrá tantas opciones en el menú como dispositivos, simplemente seleccionaremos todos los nombres de dispositivos disponibles en la base de datos y crearemos un enlace con cada uno de ellos a la misma página devices.php, sólo que pasando por la URL el nombre del dispositivo que hemos seleccionado. Tras la creación de este menú, colocaremos las tres secciones de las que se compondrá nuestra interfaz: un iframe con los paquetes recibidos en el último minuto a la izquierda, el mapa de Google Maps en el centro y un iframe que mostrará el paquete enviado en el instante temporal que cliquemos sobre el mapa a la derecha. Por último, con un pequeño script en Javascript haremos que esta página se recargue cada 60 segundos, con el fin de mantenerse actualizada con respecto a los paquetes que se van recibiendo. 10.3.2. tablas.php En este fichero se encuentra el código que obtiene los paquetes recibidos de un dispositivo concreto en el último minuto, que como veremos es bastante simple. Para poder hacer esto, necesitamos hacer uso de los métodos que ofrece PHP para obtener fechas, y guardaremos tanto la fecha actual como la correspondiente a un minuto antes. Nos aseguraremos además de guardarlas en el formato usado por SQL para almacenar fechas. De esta forma, cuando realicemos la consulta SQL, podremos usar estas fechas como rango válido a respetar. Finalmente, el último paso será mostrar la información en formato de tabla. 10.3.3. track.php Este fichero es, en funcionamiento, exactamente igual al anterior. De hecho, su única diferencia reside en la consulta SQL que realizamos. Como este fichero muestra un paquete dado en un instante temporal concreto, no buscaremos un rango de paquetes, sino que buscaremos el paquete específico correspondiente al sello temporal elegido desde la interfaz. En la siguiente imagen podemos comprobar cómo ha quedado el diseño final de nuestra interfaz:

En este ejemplo disponemos de dos dispositivos Waspmote, B y C, que son los que aparecen en el menú superior. En el recuadro izquierdo aparecen los paquetes recibidos en el último minuto. Como esta circunstancia no se dio a la hora de capturar el ejemplo, aparece en blanco. En el centro vemos la pequeña estela que ha seguido el dispositivo WaspmoteB. Hemos clicado en una de las posiciones en que ha estado y nos ha aparecido a la derecha el paquete que envió el dispositivo en ese instante. 10.4. Comprobar confirmación de paquetes con Cutecom Para saber si nuestra aplicación envía correctamente la confirmación de recepción de paquetes (o los paquetes de sincronización) a los dispositivos Waspmote, necesitaremos hacer uso de Cutecom. Para ello, conectaremos el dispositivo Waspmote con el que vayamos a hacer las pruebas a un puerto USB del equipo. Ahora, antes de iniciar Cutecom, deberemos configurar el puerto donde conectamos el dispositivo para que esta aplicación pueda consultar la información que le llega. Esta configuración consta de cuatro simples comandos escritos en la terminal: 1. ls -l /dev/tty*: con este comando averiguaremos en qué puerto USB tenemos pinchado el dispositivo Waspmote. Este puerto se corresponderá con la última entrada que encontremos, en nuestro caso /dev/ttyUSB1. 2. sudo chmod 644 /dev/ttyUSB1: con este comando obtendremos permisos tanto de lectura como de escritura para el puerto USB donde conectamos el dispositivo Waspmote. Para poner a monitorizar el programa Cutecom, lo iniciaremos escribiendo cutecom en la terminal.

Desde aquí, escribiremos /dev/ttyUSB1 en la pestaña device y pondremos la aplicación a trabajar pulsando el botón Open device.

11. VALIDACIÓN EXPERIMENTAL En este capítulo analizaremos la validez de nuestra aplicación mediante una prueba que testee su capacidad de funcionamiento. Vamos a realizar una prueba de esfuerzo, que consistirá en mantener en ejecución nuestra aplicación durante un periodo de 24 horas. Durante ese tiempo, un dispositivo Waspmote enviará un paquete cada quince minutos con nueva información. Si nuestra aplicación está bien implementada, deberá ser capaz de almacenar toda esa información y, en definitiva, funcionar durante todo ese tiempo sin congelarse ni sufrir errores debidos a una mala gestión del código. Es importante destacar que, en esta prueba, los dispositivos Waspmote no estarán en un entorno real como el mar, sino que se encontrarán en un sitio fijo (como puede ser nuestro escritorio) enviando medidas sin parar. Obviamente esto se debe a que, antes de colocar los dispositivos a trabajar, tenemos que probar su robustez con el paso del tiempo. Consecuentemente, como el dispositivo no variará su posición durante la prueba, para este caso concreto nos encargaremos nosotros mismos de asignar unos valores predeterminados a las latitudes y longitudes correspondientes a cada paquete. Esto se puede hacer perfectamente modificando el código de la función parsear para que asigne unos valores por defecto a estos parámetros durante la prueba. Dicho lo cual, ejecutamos nuestra aplicación (en el apéndice explicaremos cómo podemos hacerlo) y la dejamos en funcionamiento durante 24 horas. Al cabo de ese tiempo observamos los siguientes datos en nuestra interfaz:

El paquete que podemos ver a la izquierda es el último paquete recibido por la aplicación, que a simple vista no se puede ver porque se sale del rango del mapa. Si hacemos un poco de zoom hacia los últimos paquetes recibidos podemos

ver lo siguiente:

En esta imagen podemos apreciar claramente la estela que deja el dispositivo durante su movimiento. A la izquierda seguimos viendo el último paquete recibido, mientras que a la derecha podemos ver el paquete que se recibió una hora y media antes, correspondiente al instante temporal representado por el icono rodeado por la elipse.

12. CONCLUSIONES

El trabajo 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 Informática.

La implementación de nuestro servidor web perseguía dos objetivos fundamentales: en la primera parte, que la capa de comunicaciones garantizara un trasiego de datos fiable entre los distintos dispositivos y el PC; en la segunda parte, que la interfaz web resultase intuitiva y fácil de usar.

Como se ha visto a lo largo de la memoria, los objetivos iniciales han sido superados:

1. En el capítulo de validación experimental, se pudo observar los datos reales que obtuvimos en la prueba que realizamos.

2. En el capítulo de desarrollo mostramos el resultado final de nuestra interfaz, y pudimos comprobar que cumplía muy bien su trabajo.

El sistema que hemos desarrollado tiene una serie de puntos fuertes que, además de ofrecer robustez y flexibilidad, permiten mejoras futuras. Dichos puntos son:

1. El sistema está preparado para recibir paquetes de datos de forma muy flexible (radio y correo). Además, esta última forma permite usar dispositivos GSM/GPRS y modems satelitales en los dispositivos, pudiendo así aumentar su radio de autonomía; esto es, con GSM/GPRS accederíamos a las zonas con cobertura de telefonía móvil, y con IRIDIUM dispondríamos de cobertura global.

2. Tras la realización de este trabajo de fin de grado se dispone de una librería en C que permite la comunicación bidireccional por radio con los motes. Esta capacidad no está disponible en el software que vende Libelium.

3. El formato que hemos definido para los paquetes es flexible (es posible recibir diferentes tipos de paquete) y perfectamente adaptado (pequeño tamaño) a las restricciones en el número de caracteres que impone el módem de XBee para cada paquete. Como ya se ha comentado, aunque se pueden enviar paquetes mucho más grandes, esto implicaría un mayor consumo de memoria SRAM en los dispositivos Waspmote (memoria que es escasa, con un total de 8KB) y que las comunicaciones radio serían más frágiles al aumentar la longitud de los paquetes y el número de ellos que es necesario ensamblar para reconstruir el mensaje original.

4. Al incluir los datos en una base de datos mySQL y disponer de un servidor, sería posible servir los datos a varios clientes simultáneamente. Esto implica que el diseño de la infraestructura es escalable y puede crecer.

5. La interfaz es ligera (se carga con rapidez), sencilla, intuitiva, fácil de

usar y es fácil añadirle nuevas capacidades o restructurarla gracias al papel que juegan las herramientas de diseño del sistema.

El tiempo transcurrido desde la elección del proyecto hasta su finalización ha sido de cuatro meses y medio.

Los conocimientos técnicos adquiridos en este proyecto comprenden varias áreas de conocimiento: la programación en sistemas empotrables (Waspmote), la programación imperativa en lenguaje C, la programación web, y el análisis y diseño de bases de datos.

En definitiva, el desarrollo de este proyecto ha significado un gran objetivo a nivel personal, he aprendido y comprendido todos los conceptos y problemas que rodean la planificación, puesta en marcha, documentación y elaboración de un proyecto de tecnología moderna.

13. TRABAJO FUTURO En este capítulo expondremos 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. 13.1. Trabajar con N dispositivos Este trabajo sólo es capaz de operar con los dispositivos Waspmote de los que ya disponemos. Más concretamente, con las direcciones físicas de los módulos de radio que utilizan nuestros dispositivos. Esto significa que, si en un momento dado quisiéramos comprar nuevos Waspmote e incorporarlos a nuestro sistema, o simplemente si cambiáramos de módulos de radio, nuestro trabajo no sería capaz de lidiar con estos cambios. Por tanto, una de las mejoras más importantes pasaría por incorporar un gestor de direcciones físicas, bien en la interfaz web o bien como una pequeña aplicación de escritorio. Este gestor serviría para incorporar a la base de datos los nuevos módulos de radio disponibles, de forma que la interfaz web pueda reconocerlos y mostrar los datos que envíen. 13.2. Mayor robustez Los campos en la base de datos tienen un tamaño determinado que nuestro código asume que nunca será sobrepasado. Por tanto, aunque remota, existe la posibilidad de que nuestro código presente problemas por una medida más larga de lo normal. Consecuentemente, una posible y necesaria mejora sería robustecer el código para que sea capaz de manejar medidas de cualquier tamaño, siempre desde la perspectiva de que hay un tamaño que nunca podrá ser sobrepasado. 13.3. Mayor flexibilidad El tamaño de los paquetes que envía Waspmote está limitado a 82 caracteres. Esta limitación se debe a que la librería Libxbee, que usamos para el tráfico de paquetes desde el Gateway conectado al equipo informático, no es capaz de gestionar con garantías paquetes más largos. Aunque esta eventualidad está controlada en el código, debería ser posible enviar tramas más largas. Una manera de hacerlo sería enviar paquetes en formato binario, en lugar de ristras de caracteres, ya que reduciríamos drásticamente el número de bytes consumidos por trama. Adicionalmente, al enviar paquetes más pequeños, la posibilidad de pérdida de paquetes se reduciría bastante. La flexibilidad también está relacionada con el nivel de interacción del usuario con la interfaz web. Por defecto, nuestro trabajo simplemente se limita a mostrar todos los datos de la base de datos que fueron enviados en el último minuto por el Waspmote que estamos observando en ese momento. Este sistema no es lo suficientemente útil de cara al usuario, ya que debería ser posible visualizar únicamente la información que le interese en un momento dado: paquetes recibidos en un intervalo de tiempo definido, paquetes donde se detecte una medida anormal en alguno de los sensores, etcétera.

13.4. Trabajar con correo electrónico La actual implementación soporta un único canal de comunicaciones, que es el proporcionado por las ondas de radio. Por tanto, si por alguna razón este mecanismo de comunicación falla, todo el trabajo se paralizaría hasta que se restablecieran las conexiones. Por esta razón, sería interesante contar con un mecanismo alternativo de comunicaciones, como puede ser el uso de correos electrónicos agregando un módulo GPRS al dispositivo Waspmote, tal y como se mencionó en el capítulo de análisis. La aplicación debería leer la bandeja de entrada del correo periódicamente y, a partir de ahí, tratar cada correo como una trama independiente, trabajando de manera idéntica a la que ya conocemos. 13.5. Mayor funcionalidad del demonio receptor de datos Nuestra aplicación receptora es tremendamente simple, puesto que se limita a cumplir su función sin ofrecer mayores posibilidades al usuario. Por tanto, una posible mejora de este demonio pasaría por incluir un registro de todo lo que ocurra en un fichero de log, así como la posibilidad de ejecutar el demonio en un segundo plano.

14. REFERENCIAS [1] Universidad de Granada, Centro de Servicios de Informática y Redes de Comunicaciones http://csirc.ugr.es/informatica/ServiciosCorporativos/PaginaWeb/WebDinamica/PasosCreacion.html [2] Tutorial de SQL http://sql.1keydata.com/es/ [3] Web de PHP http://www.php.net/manual/es/book.pdo.php [4] Web de Microsoft Developer Network (MSDN) http://msdn.microsoft.com/es-es/library/ms186724.aspx [5] Web de w3schools http://www.w3schools.com [6] Web de la API de Google Maps http://code.google.com/intl/es-MX/apis/maps/documentation/javascript/v2/basics.html [7] Web de Desarrollo Web http://www.desarrolloweb.com [8] Web de Programación http://www.programacion.com/articulo/zope:_el_servidor_de_aplicaciones_libre_69/3 [9] Web de Ayuda Joomla http://ayudajoomla.com/joomla/tutoriales/248-instalar-joomla-en-linux-ubuntu-con-lamp.html

APÉNDICE: MANUAL DE USUARIO En este capítulo vamos a explicar los pasos a seguir para instalar nuestra aplicación y ejecutarla correctamente. En esta explicación asumiremos que los módulos de radio, tanto de los dispositivos Waspmote como del Gateway, ya han sido configurados convenientemente siguiendo las directrices vistas en el capítulo nueve. 1. Instalación de librerías En primer lugar, tenemos que instalar las librerías SQLite y Libxbee, necesarias para el demonio que recibe paquetes y los almacena. 1.1. SQLite Podemos descargar esta librería desde su web oficial: http://www.sqlite.org/download.html. Una vez hecho esto, descomprimimos el archivo tar.gz y abrimos una terminal para realizar la instalación. La secuencia de comandos a realizar es simple: // Movernos a la carpeta descomprimida cd /ruta/de/sqlite // Creación del archivo makefile ./configure // Compilamos el paquete a partir del makefile make // Instalamos la librería make install Llegados a este punto ya tendremos la librería SQLite instalada. 1.2. Libxbee Libxbee es una librería que se actualiza con relativa frecuencia. Para obtener su última versión estable, la mejor opción es usar el sistema de control de versiones subversion, incluido en Ubuntu por defecto. Así pues, los pasos a seguir para instalar esta librería desde la terminal son: // Movernos a la carpeta donde se instalará cd ~/ // Obtener la última versión estable de la librería svn co http://libxbee.googlecode.com/svn/trunk/ libxbee // Movernos al directorio libxbee, recién descargado cd ~/ libxbee // Instalar la librería make install

2. Instalación de Python Aunque Ubuntu incorpora por defecto un intérprete de Python, no es compatible con Zope. Por tanto, nos vemos obligados a instalar una versión más antigua de Python, compatible con nuestro gestor de contenidos. Así pues, nos dirigimos a la web de Python y, desde su sección de descargas, nos hacemos con la versión 2.4.6: http://www.python.org/download/releases/2.4.6/ Una vez descargado el archivo, lo descomprimimos y abrimos una terminal para instalar el intérprete. La secuencia de comandos a seguir será, siguiendo las instrucciones del archivo README incluido en la carpeta descomprimida: // Creación del archivo makefile ./configure // Compilamos el paquete a partir del makefile make // Cambiamos al usuario root (para lo cual necesitaremos su contraseña) su root // Instalamos la librería make install 3. Instalación de Zope y Plone La instalación de Zope es relativamente laboriosa, pero no conlleva dificultad alguna. Como siempre, abriremos una terminal y realizaremos todo el trabajo desde ahí. // Descargar Zope y Plone wget https://launchpad.net/plone/3.0/3.0.4/+download/Plone-3.0.4.tar.gz wget http://www.zope.org/Products/Zope/2.10.5/Zope-2.10.5-final.tgz // Descomprimir los archivos descargados tar -xvzf Zope-2.10.5-final.tgz tar -xvzf Plone-3.0.4.tar.gz // Nos situamos en la carpeta de Zope cd Zope-2.10.5-final // Creación del archivo makefile ./configure –prefix=/opt/Zope-2.10.5 –with-python=/usr/local/bin/python // Instalación de Zope en la carpeta especificada en prefix sudo make install // Añadimos un usuario en Ubuntu que será el propietario de Zope sudo adduser zope // Creamos el directorio donde situaremos nuestro servidor Zope sudo mkdir /srv/zope/inst_2_10_5 // Otorgamos la propiedad de este directorio al usuario Zope sudo chown zope.zope /srv/zope/inst_2_10_5

// Cambiamos al usuario Zope y ejecutamos mkzopeinstance.py sudo su zope /opt/Zope-2.10.5/bin/mkzopeinstance.py Directory: /srv/zope/inst_2_10_5 Username: admin Password: **** Llegados a este punto, Zope ya estará instalado. Ahora es el momento de instalar Plone. // Copiamos los archivos de Plone a Zope sudo cp -r Plone-3.0.4/Products/* /srv/zope/inst_2_10_5/Products/ sudo cp -r Plone-3.0.4/lib/python/* /srv/zope/inst_2_10_5/lib/python/ // Otorgamos propiedad de la carpeta y sus contenidos al usuario Zope sudo chown -R zope.zope /srv/zope/inst_2_10_5 4. Instalación del plugin PHParser para Zope En su instalación por defecto, Zope no permite la inclusión de páginas PHP a su servidor. Para poder hacer esto, es necesario instalar el plugin PHParser, que puede ser descargado directamente desde la web oficial de Zope: http://www.zope.org/Members/hewei/PHParser/1.1.5. La instalación es muy simple: basta con colocar la carpeta con el plugin dentro de la carpeta ZOPE_HOME/lib/python/Products, siendo ZOPE_HOME el directorio donde se encuentra instalado Zope. 5. Configuración de Zope Tras la instalación de Zope y Plone, sólo falta configurar Zope para que incluya nuestra interfaz web en su servidor y limite su acceso a aquellos usuarios que nosotros permitamos expresamente. Para iniciar el servidor Zope, abriremos una terminal y escribiremos: /srv/zope/inst_2_10_5/bin/zopectl De esta forma se iniciará el “shell” de Zope, en el cual deberemos escribir: start De esta forma tan simple, nuestro servidor Zope se iniciará y ya podremos acceder a los contenidos web que tengamos alojados en él. El siguiente paso es acceder a la pantalla de administración de Zope. Para ello abriremos un navegador web y escribiremos en la barra de direcciones: http://localhost:8080/manage

Se nos requerirá un nombre de usuario y una contraseña, que serán los correspondientes al usuario admin que introdujimos durante la instalación de Zope, cuando ejecutamos mkzopeinstance.py. Una vez logueados en el sistema, podremos realizar todas las tareas administrativas que queramos. En nuestro caso, agregaremos una carpeta nueva que contendrá nuestra interfaz web, compuesta por tres archivos que tendremos que añadir, y añadiremos un usuario que, junto con el administrador, será el único capaz de acceder a la interfaz. A la derecha de la pantalla podemos ver un menú desplegable con los diferentes objetos que podemos añadir al servidor. Comenzaremos por añadir una carpeta, que llamaremos motes, eligiendo la opción Folder. En el formulario que aparecerá entonces, escribiremos motes en ambas casillas y pulsaremos en el botón add. Una vez hecho esto, accederemos a la carpeta recién creada y, una vez dentro, añadiremos el objeto User Folder. Crearemos así una carpeta que contendrá la lista de usuarios que tienen permiso de acceso a la carpeta motes. Al acceder a esta carpeta veremos que, inicialmente, está vacía. Pulsaremos pues en el botón add para añadir un usuario. En el formulario que aparecerá, elegiremos un nombre para el usuario y una contraseña, dejaremos la casilla Domains en blanco y elegiremos el rol Manager. Este usuario será capaz de usar la interfaz web e incluso de modificarla, pero sólo podrá acceder a los contenidos presentes en su carpeta y subcarpetas siguientes. Jamás podrá acceder a contenidos presentes en carpetas superiores. El siguiente paso es indicar que esa carpeta sólo es accesible por usuarios registrados. Para ello, accedemos a la carpeta motes y pulsamos en la pestaña Security, accesible en lo alto de la pantalla. En esta pestaña podemos configurar al milímetro qué acciones permitiremos realizar a nuestro usuario. En principio, la única acción que nos interesa permitir al usuario recién creado es la visualización de la interfaz, por lo que desmarcaremos la casilla view de la columna izquierda acquire y la marcaremos en la columna authenticated. De esta forma, tras guardar los cambios, el acceso a la interfaz web estará limitado en exclusiva al administrador y al usuario que hemos creado. Ahora que la capa de seguridad ya ha sido implementada, es el momento de añadir nuestros archivos al sitio. Para ello, desde dentro de la carpeta creada, añadiremos dos objetos de tipo PHParser y uno de tipo DTML Document, que se corresponderá con la hoja de estilos. El proceso a seguir es el mismo para los tres documentos que añadiremos: pondremos el nombre del documento sin la extensión en los dos primeros campos, y en el tercero agregaremos el fichero correspondiente. Tras este último paso, nuestra interfaz web estará por fin instalada y lista para funcionar. Cada vez que queramos hacer uso de ella, y asegurándonos de que el servidor esté activo, no tendremos más que acceder al siguiente enlace:

http://localhost:8080/motes/devices?nombre=WaspmoteC En esta ruta, WaspmoteC es el nombre de uno de los dispositivos Waspmote que usamos. 6. Instalación y ejecución del demonio receptor de datos Nuestro trabajo, descontando la parte web, se compone de dos ficheros: radio.c, que es el demonio receptor, y parsear.h, que es un fichero auxiliar que contiene las funciones de parseo e inserción en la base de datos. Dadas las pequeñas dimensiones de nuestro trabajo, que en esencia sólo posee dos archivos, no hemos creído necesaria la confección de un makefile. Por tanto, la instalación pasaría por compilar el fichero radio.c escribiendo el siguiente comando en la terminal: gcc -o radio radio.c -lxbee -lsqlite3 Gcc es un compilador de C instalado por defecto en Ubuntu. Con la opción -o especificamos el nombre que tendrá el ejecutable que crearemos. Con -l, estamos agregando las librerías Libxbee (-lxbee) y SQLite (-lsqlite3) a la compilación de nuestro archivo. Una vez hecho esto, ya podemos ejecutar nuestro programa escribiendo en la terminal: ./radio De esta forma, nuestro programa ya estará ejecutándose y esperando indefinidamente por la recepción de los paquetes que envíe el dispositivo Waspmote.