Control de Ambientes

UNIVERSIDAD DE CONCEPCION FACULTAD DE INGENIER IA DEPARTAMENTO DE INGENIER IA ELECTRICA
Prof. Patrocinante: Jorge E. Pezoa, Ph.D.
Desarrollo de un sistema de control de ambientes mediante una aplicaci on m ovil

Francisco Marcelo Malt es Canales
Informe de memoria de t tulo para optar al t tulo de Ingeniero Civil en Telecomunicaciones
Concepci on, Chile 11 de enero de 2013
Resumen
En este trabajo se ha desarrollado un sistema que permite aprovechar las caracter sticas de los actuales smartphones o tablets con el n de poder controlar un determinado ambiente cerrado de forma remota, ya sea una habitaci on, ocina o casa. Para implementar el sistema se ha desarrollado una aplicaci on m ovil bajo la plataforma Android. Esta aplicaci on interact ua con un servidor mediante el protocolo Secure SHell (SSH) y se encarga de ejecutar distintos comandos de forma remota mediante una interfaz gr aca de f acil uso, controlando por ejemplo la m usica del ambiente denido a trav es de un reproductor multimedia en el servidor. Una caracter stica importante es la posibilidad de guardar preferencias de usuario para ejecutarlas posteriormente en el dispositivo m ovil sin la necesidad de ingresar a la aplicaci on. El sistema, en su parte de servidor, tiene asociado una placa Arduino, la cual es una plataforma de prototipado electr onico Open Source basado en hardware y software exible, que adem as de recibir comandos de forma remota tiene asociada una Red de Sensores Inal ambricos (RdSI) de bajo costo que utiliza el protocolo ZigBee. Respecto a la RdSI, para su implementaci on se ha utilizado una red con topolog a estrella en la cual el nodo coordinador, conectado al Arduino, recibe los datos de otros nodos que integran sensores tanto de luminosidad como de temperatura los cuales son procesados por el microcontrolador. Una vez procesados estos datos, el coordinador interact ua con distintos nodos actuadores, encendiendo o apagando artefactos como una l ampara, ventilador y una cafetera. Finalmente, en el presente trabajo adem as de describir el dise no e implementaci on del sistema propuesto se realiza un an alisis sobre el consumo energ etico del mismo, aspecto importante de toda RdSI y sistema dom otico actual.
Indice general
Resumen Indice de guras Indice de tablas Lista de acr onimos Agradecimientos 1. Introducci on 1.1. Antecedentes hist oricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Denici on del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2. Objetivos espec cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. Aspectos legales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7. Metodolog a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8. Temario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Marco te orico 2.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Redes de sensores inal ambricos . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
VII
VIII
IX
1 1 3 3 6 6 6 7 8 8 9 10 10 10
ii
2.3. El est andar ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. M odulos RF Xbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1. Componentes de una aplicaci on . . . . . . . . . . . . . . . . . . . . . . . 3. Dise no e implementaci on 3.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Requerimientos t ecnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Dise no general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Dise no detallado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Dise no de la aplicaci on m ovil . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. Dise no de las aplicaciones en el servidor . . . . . . . . . . . . . . . . . . 3.4.3. Dise no de la RdSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4. Dise no del subsistema Arduino . . . . . . . . . . . . . . . . . . . . . . . 4. Resultados y an alisis 4.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Consumo energ etico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Conclusiones 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliograf a A. Especicaciones m odulos RF Xbee y Xbee-Pro B. Consideraciones en las antenas de los m odulos RF
12 15 19 21 22 25 25 25 27 28 28 42 44 51 56 56 56 62 70 70 72 74 78 79
iii
Indice de guras
1.1. Est andar Z-wave [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Arquitectura del sistema Habeetat de la empresa Solidmation [11] . . . . . . . . 2.1. Esquema de una RdSI sobre un a rea volc anica [20] . . . . . . . . . . . . . . . . . 2.2. Bandas de frecuencia de operaci on [22] . . . . . . . . . . . . . . . . . . . . . . . 2.3. Topolog as de una red ZigBee [23] . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. M odulos Xbee con distintas antenas [23] . . . . . . . . . . . . . . . . . . . . . . 2.5. Estructura de un frame en modo API [24] . . . . . . . . . . . . . . . . . . . . . 2.6. Variantes de una placa Arduino [15] . . . . . . . . . . . . . . . . . . . . . . . . . 2.7. Interfaz gr aca de Android 2.2 [25] . . . . . . . . . . . . . . . . . . . . . . . . . 2.8. Ciclo de vida de una actividad [26] . . . . . . . . . . . . . . . . . . . . . . . . . 2.9. Ciclo de vida de un servicio [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Sistema general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Estructura de navegaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Diagrama de ujo correspondiente a la actividad de presentaci on de la aplicaci on 3.4. Diagrama de ujo correspondiente a la actividad de conexi on al servidor . . . . 3.5. Diagrama de ujo correspondiente a la actividad de men u de opciones . . . . . . 5 5 12 13 15 16 17 20 21 22 24 27 29 30 32 33
3.6. Diagrama de ujo correspondiente a la actividad de ejecuci on manual de actuadores 34 3.7. Herramienta gr aca TimePicker utilizada para programar ejecuciones por horario 35 3.8. Diagrama de ujo correspondiente a la actividad de programaci on horaria . . . . 3.9. Diagrama de ujo correspondiente al servicio ejecutado por alarma horaria . . . 36 37
iv
3.10. Herramienta gr aca SeekBar utilizada para regular umbrales de temperatura y luminosidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11. Diagrama de ujo correspondiente a la actividad de conguraci on de sensores . . 3.12. Diagrama de ujo correspondiente a la actividad de conguraci on y accionamiento de perles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13. Herramientas gr acas ImageButton utilizadas para el control del reproductor multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14. Diagrama de ujo correspondiente a la actividad de control del reproductor multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15. Diagrama de ujo correspondiente al servicio ejecutado por el Widget . . . . . . 3.16. Nodo coordinador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.17. Nodo nal sensor de temperatura alimentado por bater as . . . . . . . . . . . . 41 42 45 48 49 52 53 54 55 57 58 40 39 37 38
3.18. Nodo nal actuador, sensor de temperatura y luminosidad . . . . . . . . . . . . 3.19. Secuencia l ogica de Arduino, bloque 1 . . . . . . . . . . . . . . . . . . . . . . . . 3.20. Secuencia l ogica de Arduino, bloque 2 . . . . . . . . . . . . . . . . . . . . . . . . 3.21. Secuencia l ogica de Arduino, bloque 3 . . . . . . . . . . . . . . . . . . . . . . . . 3.22. Secuencia l ogica de Arduino, bloque 4 . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Nodos implementados en la RdSI . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Capturas de la aplicaci on m ovil desarrollada . . . . . . . . . . . . . . . . . . . . 4.3. Consumo promedio del nodo nal en funci on del porcentaje del ciclo de trabajo en que duerme el m odulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Capacidad estimada de la bater a en funci on del porcentaje del ciclo de trabajo en que duerme el m odulo Xbee . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Capacidad estimada de la bater a en funci on del porcentaje del ciclo de trabajo en que duerme el m odulo Xbee-Pro . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Descarga de corriente constante t pica en una pila alcalina AA Duracell [31] . .
64
65
66 67 68 81 82
4.7. Vida u til del nodo nal utilizando dos pilas alcalinas AA en serie . . . . . . . . . B.1. Patr on de radiaci on antena dipolo acoplada a un Xbee-Pro . . . . . . . . . . . . B.2. Patr on de radiaci on antena whip acoplada a un Xbee-Pro . . . . . . . . . . . . .
B.3. Patr on de radiaci on antena chip acoplada a un Xbee-Pro . . . . . . . . . . . . .
82
vi
Indice de tablas
1.1. Cuota de mercado de sistemas operativos para smartphones, a nos 2012 y 2016 [7] 3.1. Caracter sticas de la placa Arduino Uno [16] . . . . . . . . . . . . . . . . . . . . 3.2. Comandos ejecutados por la aplicaci on para controlar el reproductor moc . . . . 3.3. Tareas realizadas por Arduino en funci on del dato serial recibido . . . . . . . . . 3.4. Asignaci on de pines en m odulos Xbee [24] . . . . . . . . . . . . . . . . . . . . . 3.5. Funci on de cada m odulo Xbee y direcci on MAC asociada . . . . . . . . . . . . . 3.6. Conguraci on modo sleep en nodos nales alimentados por bater as . . . . . . . 3.7. Conguraci on modo sleep en nodos actuadores/sensores . . . . . . . . . . . . . . 4.1. Consumo de nodos nales para distintos estados . . . . . . . . . . . . . . . . . . A.1. Desempe no m odulos Xbee y Xbee-Pro [24] . . . . . . . . . . . . . . . . . . . . . A.2. Requerimientos de potencia m odulos Xbee y Xbee-Pro [24] . . . . . . . . . . . . B.1. Desempe no de las antenas en m odulos Xbee y Xbee-Pro para distintos escenarios [30] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3 26 40 44 46 47 50 51 63 78 78
vii
Lista de acr onimos

SSH Secure SHell RdSI Red de Sensores Inal ambricos S.O. Sistema Operativo IDE Entorno de Desarrollo Integrado SDK Kit de Desarrollo de Software USB Universal Serial Bus LSB Byte Menos Signicativo MSB Byte M as Signicativo ST Sleep Timer SP Sleep Period
viii
Agradecimientos
En primer lugar a Dios, ya que sin el nada de esto habr a sido posible. En segundo lugar a mis padres, ya que me apoyaron en todo momento y sin ellos no habr a podido cumplir las metas que me propuse. Tambi en a mis hermanos, que siempre me acompa naron en este proceso estando pendientes y preocupados en todo momento. Al profesor Pezoa, por tener siempre la mejor disposici on a todo tipo de consultas lo que sin duda ayud o a simplicar el desarrollo de este trabajo. Finalmente, a Carmen, por su compa n a y apoyo incondicional en estos a nos. A todos uds. gracias. Sinceramente, Francisco Malt es Canales
ix
Cap tulo 1 Introducci on

1.1. Antecedentes hist oricos
Integrar la tecnolog a al dise no inteligente de un recinto es una idea que siempre ha estado presente en nuestras vidas por lo que es dif cil asociar sus or genes a un hecho puntual, sin embargo, es en las u ltimas d ecadas que con el auge de la electr onica y la inform atica se ha comenzado a asociar esta automatizaci on de los ambientes al t ermino dom otica, el cual se reere a la integraci on de los elementos tecnol ogicos en el hogar con el n de satisfacer las necesidades del usuario y su entorno (en el caso de uso no residencial, como ocinas, se usa el t ermino inm otica) [1, 21]. Dentro de estas necesidades y usos se encuentran la optimizaci on del consumo energ etico, mejorar la seguridad y comunicaci on, entretenimiento y facilitar el d a a d a a personas con discapacidades f sicas. Comercialmente, el inicio de la dom otica es en el a no 1978 con el ingreso al mercado del sistema X-10, el cual permite el control de las luces y los electrodom esticos del hogar a trav es de la instalaci on el ectrica existente, inyectando y leyendo se nales contenidas en esta. A pesar de que este sistema es 100 % escalable, permitiendo agregar y quitar componentes con mucha facilidad, su mayor inconveniente es que depende directamente de la calidad con la que llega la se nal el ectrica, lo que lo hace un sistema no muy able a pesar de que se han creado ltros para minimizar este problema [2]. Luego, con el auge de los computadores personales a nes de la d ecada de los 80 comenzaron a aparecer sistemas propietarios que contienen Sistemas de
1.1. ANTECEDENTES HISTORICOS
CAP ITULO 1. INTRODUCCION
Cableado Estructurado (SCE) para facilitar la conexi on de todo tipo de terminales y perif ericos entre s , utilizando un cableado est andar repartido por todo el recinto automatizado, logrando un gran exito en los a nos siguientes sobretodo en Europa. Ya en el nuevo milenio, se comienzan a consolidar nuevos est andares en comunicaciones inal ambricas que en el corto plazo se incorporan al mundo de la dom otica, como Wi-Fi y Bluetooth, pero estas tecnolog as presentan el inconveniente de no ser creadas con este prop osito. Por ejemplo, Wi-Fi est a destinado a la conexi on a Internet y redes de computadoras, mientras que Bluetooth a conexi on entre perif ericos, lo que las hace estar sobredimensionadas para aplicaciones de dom otica. Finalmente, con el avance de la tecnolog a y en consecuencia la reducci on de los costos de fabricaci on, a mediados de la u ltima d ecada comienzan a surgir los sistemas dom oticos inal ambricos que aprovechan las RdSI, sustituyendo poco a poco a los sensores tradicionales que depend an de instalaciones cableadas. Dentro de estos est andares destaca ZigBee, el cual fue pensado para lograr sistemas de bajo costo, con una baja tasa de transmisi on de datos y admitiendo tanto sensores como actuadores dentro de la red [3, 6, 18]. En forma paralela, respecto a la telefon a m ovil, en los u ltimos a nos comenzaron a aparecer dispositivos inteligentes con prestaciones superiores a las t picas, los llamados smartphones y tablets. No existe una denici on clara sobre lo que es un smartphone, para algunos se trata de un tel efono que corre un sistema operativo completo e identicable, que provee una interfaz est andar y una plataforma para desarrollo de aplicaciones, mientras que para otros es simplemente un tel efono m ovil con funcionalidades avanzadas como conectarse a redes sociales, reproducir contenido multimedia y administrar cuentas de correo electr onico. As , como estos dispositivos de uso diario se han convertido en herramientas que ya no s olo se utilizan para comunicarse a distancia con otras personas, han comenzado a desarrollarse aplicaciones de todo tipo, donde la dom otica es un area que abre un sinf n de posibilidades para los desarrolladores [5].
DEL PROBLEMA 1.2. DEFINICION
1.2.
Denici on del problema
El problema consiste en desarrollar un sistema que aproveche las caracter sticas de los actuales dispositivos m oviles, ya sea smartphones o tablets, con el n de poder monitorear y controlar un determinado ambiente cerrado de forma remota, ya sea una habitaci on, ocina o una casa.
1.3.
Estado del arte
En la actualidad los principales sistemas operativos bajo los cuales operan los smartphones y tablets actuales son Android, propiedad de Google, e iOS, propiedad de Apple, donde la principal diferencia entre Android y el resto de los sistemas operativos es que es software libre, basado en Linux, y la mayor parte es de c odigo abierto. Esto quiere decir que cualquiera puede modicarlo y a nadirle mejoras, a diferencia de los sistemas propietarios donde s olo el fabricante puede hacer modicaciones. La Tabla 1.1 muestra la cuota de mercado de los principales sistemas operativos m oviles el a no 2012 y sus proyecciones para el a no 2016 seg un IDC1 , donde se puede observar que Android liderar a el mercado, seguido por Windows Mobile. Tabla 1.1: Cuota de mercado de sistemas operativos para smartphones, a nos 2012 y 2016 [7].
Sistema operativo Android Windows Phone 7/Windows Mobile iOS Blackberry Otros Total Cuota de mercado 2012 61.0 % 5.2 % 20.5 % 6.0 % 7.2 % 100 % Cuota de mercado 2016 52.9 % 19.2 % 19.0 % 5.9 % 3.0 % 100 %
En relaci on a los sistemas de control de ambientes, las tecnolog as existentes se pueden clasicar en las que utilizan un medio cableado de transmisi on y las que utilizan radiofrecuencia. En el primer caso, est an aquellos sistemas que pueden utilizar la red el ectrica ya instalada (X-10, Insteon, etc.) o un cableado dedicado. La segunda categor a, si bien a un no es tan masiva como
1
International Data Corporation
1.3. ESTADO DEL ARTE
la primera, ha ido ganando terreno y todo indica que es la tecnolog a que m as se desarrollar a en los pr oximos a nos [6]. Ac a se distingue Bluetooth, IEEE 802.11b (Wi-Fi) y 802.11.4 (ZigBee). Adem as, se tienen diversos sistemas propietarios que pueden utilizar el cableado dedicado o radiofrecuencia, pero con el inconveniente de ser cerrados, en el sentido de que sus m odulos no permiten interacci on con dispositivos de la competencia. En Chile la situaci on ha comenzado a despegar en los u ltimos a nos, aunque todav a instalar un sistema dom otico en una vivienda es privilegio de las familias m as acomodadas debido a su alto costo donde, por ejemplo, seg un datos del a no 2010 instalar un sistema que controle la casa desde un celular cuesta en promedio CLP$2.000.0002 . Dentro de las empresas que entregan este tipo de servicios destacan: Casa Dom otica Evolution: esta empresa centra sus productos en la tecnolog a X-10, que como ya se mencion o en 1.1 es bastante antigua y presenta problemas de abilidad. Housetek: su sistema se basa en la tecnolog a Z-wave, el cual es un est andar propietario creado por Zensys y comprado por Sigma Designs en 2008. Trabaja con RdSI y fue 100 % creado pensando en dom otica y con caracter sticas muy similares a Zigbee. Hoy en d a este est andar tiene m as de 650 productos interoperables certicados en todo el mundo y es la tecnolog a inal ambrica de control en el hogar l der en el mercado actual. La Figura 1.1 muestra la tecnolog a Z-wave y sus aplicaciones. Sidco Chile: esta empresa tiene como producto el sistema Lonworks, el cual fue desarrollado por la empresa Echelon en 1990 y presenta un control distribuido y descentralizado, donde sus m odulos se comunican por par trenzado, Ethernet, RF o la l nea de conducci on el ectrica. Es un sistema abierto que permite aparatos de distintos fabricantes a trav es de un chip que debe contener todo aparato LonWorks, llamado Neuron chip, el cual tiene implementado el protocolo Lontalk [9, 10].
Dato obtenido por el diario La Tercera en un art culo publicado en su edici on del 28 de octubre de 2010
1.3. ESTADO DEL ARTE
Fig. 1.1: Est andar Z-wave [8].
Solidmation: el sistema presentado por esta empresa, llamado Habeetat, combina los est andares inal ambricos Zigbee y Wi-Fi, estableciendo un sistema que puede ser controlado desde cualquier lugar a trav es del software propietario llamado HabeetatPlanner, permitiendo ser utilizado por cualquier dispositivo m ovil. En la Figura 1.2 se exhibe la arquitectura del sistema mencionado.
Fig. 1.2: Arquitectura del sistema Habeetat de la empresa Solidmation [11].
1.4. OBJETIVOS
1.4.
1.4.1.
Objetivos
Objetivo general
El objetivo de esta memoria de t tulo es dise nar e implementar un sistema que sea capaz de controlar de forma remota distintas variables de un ambiente cerrado a trav es de una aplicaci on m ovil, en la cual el usuario pueda de forma simple interactuar con la aplicaci on a trav es de una interfaz gr aca, ejecutando conguraciones pre-denidas.
1.4.2.
Objetivos espec cos
Desarrollar bajo el Sistema Operativo (S.O.) Android una aplicaci on m ovil que realice una conexi on SSH, actuando como cliente, con un servidor. Implementar una RdSI de bajo costo que contenga actuadores, sensores de luminosidad y de temperatura, cuyos valores sean le dos por un microcontrolador y a su vez por el dispositivo m ovil. Programar de forma remota ciclos horarios mediante los cuales los actuadores que componen la RdSI se encender an/apagar an seg un el horario establecido. Poder establecer de forma remota un umbral de temperatura o luminosidad mediante los cuales los actuadores se encender an/apagar an bajo esta condici on. Controlar de forma remota un reproductor de m usica en el servidor, cargando una lista de reproducci on previamente establecida y poder ejecutar controles b asicos de todo reproductor de este tipo (adelantar, retroceder, pausar, etc.). Ejecutar preferencias pre-denidas de forma remota, donde el usuario pueda decidir que quiere encender/apagar y una vez guardadas estas preferencias se puedan ejecutar sin la necesidad de entrar a la aplicaci on.
1.5. ALCANCES Y LIMITACIONES
1.5.
Alcances y limitaciones
De acuerdo a la investigaci on realizada, Android corre con ventaja respecto al resto de sistemas operativos, por lo que la aplicaci on m ovil se realiza bajo esta plataforma. Sin embargo, ya que la aplicaci on est a asociada a un sistema espec co el cual contiene una RdSI y distintos artefactos el ectricos, no se desarrolla con el n de publicarla en el Android Market. Un aspecto importante a considerar en el desarrollo de la aplicaci on es la versi on de Android bajo la cual se trabaja, ya que desarrollar bajo las versiones m as recientes de esta como Ice Cream Sandwich (4.0) o Jelly Bean (4.1) si bien permite utilizar herramientas gr acas m as avanzadas, tiene el inconveniente de que la aplicaci on ser a incompatible con dispositivos que trabajen con versiones m as antiguas de Android. En base a esto, con el n de que sea compatible con la mayor cantidad de dispositivos posibles, la aplicaci on de este trabajo es desarrollada con Android 2.1 como objetivo. Dentro de las limitaciones, la RdSI contiene actuadores que encienden/apagan distintos artefactos, en concreto una cafetera, una l ampara y un ventilador pero sin regular la potencia de este ni la intensidad de iluminaci on. Adem as, la red se limita a dos sensores inal ambricos alimentados por bater as y tres actuadores, lo que es suciente para conseguir el objetivo propuesto en un ambiente. Respecto al an alisis del consumo energ etico del sistema, este se centra en los sensores inal ambricos del mismo, ya que es importante analizar la autonom a de estos con el n de concluir si es correcto el sistema de alimentaci on realizado en este trabajo o es necesario sustituirlo. Finalmente, para la comunicaci on entre el dispositivo m ovil y el servidor se aprovecha la conexi on Wi-Fi que tienen a mbos y de esta forma comunicarse mediante el protocolo SSH. La elecci on de este protocolo se debe a que si bien se puede aprovechar la conexi on a Internet de los dispositivos m oviles, no es estrictamente necesaria, ya que se puede crear una red LAN inal ambrica y a un as controlar el sistema. Adem as, no solo permite controlar la RdSI, sino tambi en software asociado al servidor, como un reproductor multimedia.
1.6. ASPECTOS LEGALES
1.6.
Aspectos legales
La RdSI a implementar en este trabajo opera bajo el est andar ZigBee, utilizando la banda de 2.4 [GHz] ISM de uso industrial, cient co y m edico, la cual est a abierta a todo el mundo sin necesidad de licencia, respetando las regulaciones que limitan los niveles de potencia transmitida. En este aspecto, los m odulos RF que componen la red est an dise nados para formar un sistema de baja potencia de transmisi on, donde los m odulos no superan los 10 [mW] de potencia transmitida.
1.7.
Metodolog a
Para el desarrollo de la aplicaci on m ovil bajo el S.O. Android se utiliza el Entorno de Desarrollo Integrado (IDE) Eclipse y el Kit de Desarrollo de Software (SDK) de Android, el cual contiene todas las herramientas necesarias para desarrollar aplicaciones bajo el lenguaje Java. Ya que la aplicaci on creada establece una conexi on SSH con el servidor, es necesaria una biblioteca en Java que realice esta tarea, por lo cual se utiliza Orion SSH2, la cual se integra f acilmente a Eclipse [12]. Respecto a la RdSI, se utilizan los m odulos Xbee debido a que se ajustan a las necesidades del sistema en el sentido de crear una red de bajo costo. Estos m odulos trabajan bajo el est andar Zigbee el cual es uno de los m as actuales y con un gran presente y futuro en sistemas dom oticos. Es importante se nalar que la RdSI tendr a una topolog a estrella, por lo tanto un elemento importante dentro la red es el nodo coordinador. Aqu juega un papel fundamental en el sistema la plataforma Arduino, la cual contiene un microcontrolador que se encarga de procesar las o rdenes recibidas por puerto serial y los datos recibidos de los sensores con el n de tomar las decisiones requeridas [13]. En relaci on a la comunicaci on entre el Arduino y el dispositivo m ovil, esta se realiza mediante scripts bajo el lenguaje de programaci on Python ejecutados de forma remota mediante el protocolo SSH, los cuales una vez ejecutados env an un dato por puerto serial al Arduino para que este lo procese.
1.8. TEMARIO
Para nalizar, como ya se coment o en 1.4.2 y 1.5 el sistema controlar a un reproductor de m usica en el servidor, moc para Linux, el cual presenta las caracter sticas de poder ejecutarse por consola, sin la necesidad de una interfaz gr aca y consumiendo muy pocos recursos, lo que lo hace ideal para utilizarlo en servidores [17].
1.8.
Temario
En el Cap tulo 2 se analiza la teor a que hay detr as de esta memoria de t tulo, comenzando con las RdSI y el est andar ZigBee, revisando sus caracter sticas y ventajas para crear un peque no sistema dom otico. Luego, se estudia la plataforma Arduino, en donde se revisan sus aspectos t ecnicos y caracter sticas. Finalmente se describe Android, comentando y analizando sus caracter sticas, estructura y componentes de una aplicaci on. El Cap tulo 3 describe en profundidad tanto el dise no como la implementaci on general y por etapas del sistema desarrollado, partiendo por la aplicaci on m ovil creada y su interacci on con el servidor mediante el protocolo SSH. Luego se detalla la RdSI implementada mediante diagramas y esquemas que expliquen tanto el funcionamiento de la placa Arduino como los m odulos ZigBee que componen la red y la interacci on entre ellos. En el Cap tulo 4 se muestran los resultados y an alisis del sistema, mostrando guras que demuestren tanto el funcionamiento de la aplicaci on m ovil como de la RdSI, adem as de un estudio sobre el consumo energ etico del sistema en funci on de los sensores que lo componen. Finalmente, en el Cap tulo 5 se entregan las conclusiones correspondientes a esta memoria de t tulo en base al trabajo realizado y los resultados obtenidos en 4. Adem as, se proponen ideas para desarrollar un trabajo futuro en base a lo desarrollado.
Cap tulo 2 Marco te orico

2.1. Introducci on
Este cap tulo presenta toda la teor a relevante en el desarrollo de esta memoria de t tulo. En primer lugar se describen las RdSIs, mencionando sus caracter sticas y aplicaciones. En segundo lugar, se analiza el est andar Zigbee, estudiando sus ventajas respecto a otros protocolos y su estrecha relaci on con las RdSIs, adem as de sus caracter sticas, topolog as de red, etc. Luego, se describen los m odulos Xbee ya que son una parte fundamental dentro de la red implementada, describiendo datos t ecnicos y como implementan el est andar Zigbee para comunicarse. En cuarto lugar se realiza una peque na descripci on de la plataforma Arduino con el n de entender su importancia en el sistema implementado, describiendo sus caracter sticas, lenguaje de programaci on, etc. Finalmente se analiza el S.O. Android bajo el cual se crea la aplicaci on m ovil desarrollada, describiendo los componentes de una aplicaci on y su estructura.
2.2.
Redes de sensores inal ambricos
Una RdSI consiste en dispositivos aut onomos, miniaturas, multifuncionales, de bajo costo y baja potencia, los cuales pueden observar y reaccionar a cambios en fen omenos f sicos del ambiente que los rodea. Al trabajar en conjunto a trav es de un medio inal ambrico, estos dispositivos pueden entregar un resultado global del medio que miden. Los nodos de una RdSI
10
2.2. REDES DE SENSORES INALAMBRICOS
CAP ITULO 2. MARCO TEORICO
al ser desplegados en grandes cantidades sobre un terreno pueden autom aticamente organizarse entre ellos para formar una red ad hoc multi-hop (multi-salto), es decir, sin una infraestructura espec ca y con la habilidad de comunicarse entre s y con uno o m as nodos puente. Un usuario remoto puede ingresar comandos a la red v a el nodo puente para asignar recopilaci on de datos, procesamiento y traspasar tareas a los sensores, para luego recibir la informaci on medida por la red a trav es del nodo puente. Una variedad de sensores mec anicos, t ermicos, biol ogicos, qu micos, o pticos y magn eticos pueden ser a nadidos al nodo sensor para medir propiedades del ambiente. Ya que los sensores tienen memoria limitada y son generalmente desplegados en zonas de dif cil acceso, estos tienen la capacidad de comunicarse inal ambricamente y as traspasar informaci on a la estaci on base (por ejemplo un laptop o un dispositivo m ovil) [18, 19]. El consumo energ etico es uno de los factores m as determinantes de una red de sensores, pues en la mayor a de los casos los distintos nodos pueden ser instalados en zonas sin alimentaci on el ectrica y su funcionamiento debe ser a partir de bater as. Teniendo en cuenta los diversos componentes de los que estar a compuesto cada nodo, la elecci on de estos ser a vital para reducir el consumo al m nimo y aumentar su autonom a. Otra propiedad importante es la capacidad de reconguraci on de la red en caso de aver a de un nodo, ya que teniendo en cuenta que las comunicaciones inal ambricas no son tan ables como las conexiones por cable, es imprescindible que los elementos de la red tengan gran tolerancia a los distintos fallos de comunicaci on que puedan producirse, como interferencias o atenuaci on de la se nal, corrigiendo en la medida de lo posible los errores que se detecten o al menos informando de estos. Otro factor importante es la escalabilidad, es decir, la red puede crecer incorporando nuevos nodos, aumentando su cantidad de elementos y su extensi on f sica, abarcando una mayor supercie. Aunque los factores anteriores denen en gran medida los objetivos que se persiguen con este tipo de redes, inuyen otras propiedades, como podr a ser el costo y tama no de cada nodo, que debe ser el menor posible. Las RdSI tienen un gran potencial para muchas aplicaciones en escenarios tales como seguimiento de objetivos militares y vigilancia, ayuda en desastres naturales, monitoreo en salud biom edica, automatizaci on y control de ambientes y exploraci on de ambientes peligrosos y s smicos. En seguimiento de objetivos militares y vigilancia, una RdSI puede asistir en detecci on
11
2.3. EL ESTANDAR ZIGBEE
de intrusos e identicaci on. Ejemplos espec cos incluyen coordinaci on y correlaci on espacial de movimientos de tanques y tropas. En el caso de desastres naturales, los nodos monitorean y detectan desastres ambientales antes de que ocurran. En aplicaciones biom edicas, implantes quir urgicos de sensores pueden ayudar a monitorear la salud de un paciente. Para monitoreo de ambientes s smicos, redes ad hoc en un a rea volc anica pueden detectar el desarrollo de un terremoto o erupci on [19]. La Figura 2.1 muestra un esquema para el caso de una RdSI desplegada sobre un a rea volc anica.
Fig. 2.1: Esquema de una RdSI sobre un area volc anica [20].
2.3.
El est andar ZigBee
ZigBee es una alianza sin n de lucro de 25 empresas, la mayor a de ellas fabricantes de semiconductores, con el objetivo de auspiciar el desarrollo e implantaci on de una tecnolog a inal ambrica de bajo costo. Destacan empresas como Invensys, Mitsubishi, Philips y Motorola que trabajan para crear un sistema est andar de comunicaciones, v a radio y bidireccional, para usarlo dentro de dispositivos para automatizaci on de edicios, control industrial, perif ericos de PC y sensores m edicos. Los miembros de esta alianza justican el desarrollo de este est andar para cubrir el vac o que se produce por debajo del Bluetooth [6]. ZigBee utiliza la banda ISM (868 MHz en Europa, 915 MHz en Estados Unidos y 2.4 GHz en todo el mundo) y en la Figura 2.2 se puede observar las bandas de frecuencia utilizadas.
12
Fig. 2.2: Bandas de frecuencia de operaci on [22]. El nodo ZigBee m as completo requiere en teor a cerca del 10 % del software de un nodo Bluetooth o Wi-Fi t pico; esta cifra baja al 2 % para los nodos m as sencillos. No obstante, el tama no del c odigo en s es bastante mayor y se acerca al 50 % del tama no del de Bluetooth [21]. Por otro lado, la alianza ZigBee adopt o la norma IEEE 802.15.4, la cual dene las principales funciones de ZigBee, tal como administraci on de energ a, direccionamiento, correcci on de errores, formato de mensajes y otras especicaciones punto a punto necesarias para una comunicaci on inal ambrica apropiada. As , ZigBee se puede entender como un conjunto de capas construidas sobre 802.15.4. Estas capas a naden tres importantes caracter sticas: Enrutamiento: las tablas de ruteo denen como un nodo pasa mensajes a trav es de una serie de otros nodos en el camino hasta llegar a su destino nal. Creaci on de una red ad hoc : como se ha mencionado anteriormente, este proceso crea una red entera de forma espont anea, sin infraestructura espec ca, estando todos los nodos en igualdad de condiciones. Red mesh Self-healing : este proceso detecta autom aticamente si uno o m as nodos fallan y recongura la red reparando las rutas da nadas. Una red ZigBee est a compuesta por tres tipos de dispositivos o nodos, los cuales se describen a continuaci on:
13
Coordinador (Coordinator ): una red ZigBee siempre tiene un dispositivo coordinador, el cual se encarga de formar la red, entregando direccionamientos y administrando las otras funciones que la denen. Nunca se tendr a m as de un coordinador en la red. Ruteador (Router ): un ruteador es un nodo que tiene todas las funciones. Puede unir redes existentes, enviar, recibir informaci on y tambi en rutearla. Una red puede tener m ultiples ruteadores y deben estar encendidos todo el tiempo por lo que generalmente est an conectados a la l nea el ectrica. Dispositivo nal (End device ): hay muchas situaciones donde el hardware y la energ a de un ruteador a tiempo completo es excesiva para lo que un nodo en particular necesita hacer. Los dispositivos nales son esencialmente versiones limitadas de un ruteador. Pueden unir redes y recibir/enviar informaci on, pero solo eso. No act uan como mensajeros entre otros dispositivos, por lo que utilizan menos hardware y pueden apagarse intermitentemente (sleep mode ) y as ahorrar energ a. Un dispositivo nal siempre necesita un ruteador o coordinador para trabajar en conjunto ya que guardan mensajes para los nodos que est an dormidos. De hecho, una red puede estar compuesta por un coordinador, muchos dispositivos nales y ning un ruteador. Los nodos se pueden conectar entre s de acuerdo a distintas topolog as, las cuales se ilustran en la Figura 2.3 y se explican a continuaci on [23]: Par (Pair ): es la red m as simple. Contiene s olo dos nodos, donde uno debe ser coordinador para formar la red y el otro puede ser congurado como ruteador o dispositivo nal. Estrella (Star ): en esta topolog a, un nodo coordinador se queda en el centro y se conecta a un c rculo de dispositivos nales. Cada mensaje en el sistema debe pasar por el nodo coordinador, el cual lo rutea entre los dispositivos. Los nodos nales no se comunican entre ellos directamente. Malla (Mesh ): una conguraci on mesh emplea nodos ruteadores adem as del coordinador. Estos nodos pueden pasar mensajes a otros ruteadores y dispositivos nales que
14
Fig. 2.3: Topolog as de una red ZigBee [23]. lo necesiten. El coordinador gestiona la red y tambi en puede rutear mensajes. Varios dispositivos nales pueden ser a nadidos a cualquier ruteador o coordinador. Arbol (Cluster tree ): en este caso los ruteadores forman una columna vertebral en la red, con dispositivos nales agrupados alrededor de cada ruteador. No hay mucha diferencia respecto a una conguraci on mesh.
2.3.1.
M odulos RF Xbee
Los m odulos Xbee est an dise nados para operar bajo el protocolo ZigBee con el n de poder desarrollar RdSIs de bajo costo y baja potencia. Existen varios tipos de m odulos, diferenciados mayormente por el rmware utilizado y el tipo de antena. Por ejemplo, existen los m odulos Series 1 y Series 2 donde la gran diferencia es que los segundos pueden crear redes mesh mientras que el rmware de los primeros no implementan el protocolo ZigBee en su totalidad, pudiendo crear solo redes punto a punto. Respecto al tipo de antena, se tienen m odulos con antena chip, wire, entre otros, con lo cual var a el patr on de radiaci on de cada m odulo. Finalmente existen versiones Pro, que si bien son m as costosas, tienen mayor alcance entre otras ventajas. La Figura 2.4 ilustra distintos m odulos donde se puede apreciar la variedad de antenas existentes.
15
Fig. 2.4: M odulos Xbee con distintas antenas [23]. Modos de comunicaci on serial Dependiendo del rmware que se carga en el m odulo, este se podr a comunicar de dos formas: modo transparente y modo API.
En modo transparente, el m odulo act ua como reemplazo de una l nea serial, transmitiendo toda la informaci on que le llega tal cual la recibe, es decir, el puerto serial recibe la informaci on y la transmite al nodo destino de la misma forma. Luego, para establecer comunicaci on directa con un m odulo y congurarlo se puede entrar en modo de comandos AT con el f n de conocer el estado de un pin, cambiar alg un par ametro, etc.
En modo API los datos van contenidos en paquetes de datos (frames ), lo cual permite una comunicaci on entre m odulos de forma altamente estructurada. A diferencia del modo transparente, ac a toda la informaci on que llega es ignorada a menos que sea un comando API, incluso se pueden enviar comandos AT como en modo de comandos pero debe ser dentro de un frame API. Dentro de las ventajas que ofrece este modo se tiene [24]: Transmitir datos a m ultiples destinos sin entrar en modo de comandos.
16
Recibir un estado de exito/falla de cada paquete RF transmitido. Identicar la fuente de cada paquete recibido. Recibir muestras de sensores a nadidos en m odulos remotos. En redes de comunicaciones un frame es la unidad fundamental de transporte de informaci on, componiendose de tres elementos: una cabecera (header ) que contiene la informaci on necesaria para transmitir el paquete desde el receptor al emisor, el a rea de datos (payload ) que contiene la informaci on a enviar y el c odigo vericador (checksum ), que contiene un chequeo de errores. As , los paquetes de datos transmiten los bytes de forma estructurada. La Figura 2.5 detalla la estructura de un frame en modo API.
Fig. 2.5: Estructura de un frame en modo API [24]. Como se observa, todo frame comienza con 0x7E, por lo cual se descarta todo dato previo a este byte. Luego, los dos bytes siguientes indican la longitud del frame mediante el Byte M as Signicativo (MSB) y el Byte Menos Signicativo (LSB). Despu es vienen los bytes que indican el mensaje a transmitir, por ejemplo, si se quiere enviar un comando AT el valor que lo indica corresponde a 0x17, seguido de aquellos que especican la direcci on de 64 bits (direcci on MAC) del m odulo receptor, direcci on de 16 bits y el comando AT espec co que se quiere transmitir. Modo sleep en nodos nales Los nodos nales permiten 2 tipos de modos en los cuales el m odulo entra en un estado de bajo consumo energ etico: Pin Sleep y Cyclic Sleep. En el primero, un microcontrolador externo puede determinar el momento en que el m odulo debe dormir y despertar, a trav es de un pin odulo duerme en per odos c clicos los cuales espec co (pin Sleep RQ). En el segundo caso, el m
17
pueden ser congurables. En el sistema implementado se utiliza el modo Cyclic Sleep debido a que el u nico nodo que posee un microcontrolador externo es el coordinador. Es importante se nalar que el m odulo al estar dormido no responde a datos seriales ni RF, por lo tanto los m odulos deben dormir de forma que siempre puedan recibir la informaci on que tiene el coordinador para ellos. Cyclic Sleep permite al m odulo despertar por peque nos per odos de tiempo en el cual el nodo consulta al coordinador si hay alg un mensaje almacenado en el buer para el, para luego volver a dormir. Esta acci on es llamada Poll Request. Los par ametros congurables en este modo son 3 y se describen a continuaci on: Sleep Timer (ST): este par ametro se reere al tiempo sin actividad que espera el m odulo para volver a dormir. Durante este tiempo el nodo env a un Poll Request apenas despierta, volviendo a dormir apenas se cumpla el ST si es que no se encuentra un mensaje en el buer. En el caso de encontrarse un mensaje, el valor de ST se reinicia enviando un Poll Request cada 100 [ms] hasta que se cumpla ST y vuelve a dormir. Sleep Period (SP): dene el tiempo que duerme el m odulo. El valor m aximo congurable es de 28 segundos pero se puede extender congurando un par ametro que sirve como multiplicador de SP, llamado SN. Ahora, es importante se nalar que al congurar SP en el coordinador se especica el tiempo en que el buer almacenar a un frame antes de ser transmitido a un nodo nal, por lo que es importante que el valor de SP en el nodo nal sea menor al valor congurado en el coordinador y asi evitar el riesgo de perder frames que se quieran enviar a los nodos nales. As , debido a que el coordinador solo puede almacenar un frame por 28 segundos y el nodo nal puede dormir por m as tiempo si se congura el par ametro SN, se puede concluir que es recomendable congurar per odos largos de SP solo en nodos nales que env an datos al coordinador pero no esperan recibir nada de el. Otro par ametro importante en nodos nales y que est a relacionado con los par ametros reci en explicados es el IO sampling, el cual se reere al muestreo de las entradas/salidas digitales y an alogas del m odulo. Al estar esta opci on habilitada el m odulo env a una muestra al coordinador apenas comienza el tiempo ST, enviando una cantidad de muestras dada por la tasa de muestreo IR dentro del tiempo ST establecido. Por lo tanto, si se quiere enviar por ejemplo una sola
18
2.4. ARDUINO
muestra cada vez que el m odulo despierta, el valor de IR debe ser mayor a ST ya que el m odulo no alcanzar a a enviar una segunda muestra antes de que se cumpla el timer.
2.4.
Arduino
Seg un la propia p agina ocial de Arduino, este se dene como una plataforma de electr onica abierta para la creaci on de prototipos basada en software y hardware exibles y f aciles de usar. Se cre o para artistas, dise nadores, acionados y cualquiera interesado en crear entornos u objetos interactivos [13]. As , se tiene una placa con un microcontrolador bajo la cual se pueden crear objetos interactivos, leer datos de sensores, controlar motores, etc. gracias a sus salidas digitales y entradas an alogas, creando proyectos que pueden interactuar con un software externo en un computador o ser aut onomos. Dentro de sus ventajas se tiene [14], Bajo costo: en el caso particular de Chile, la placa m as utilizada (Arduino Uno) cuesta alrededor de CLP$13.000. Entorno de programaci on: se llama Arduino IDE, el cual es multi-plataforma, ya que puede trabajar bajo Windows, OSX y Linux. Se caracteriza por su facilidad de uso y exibilidad. Software y hardware ampliable y de c odigo abierto: el software de Arduino est a publicado bajo una licencia libre por lo cual puede ser ampliado por cualquier programador, mientras que su hardware est a basado en los microcontroladores ATMEGA168, ATMEGA328 y ATMEGA1280 y los planos de los m odulos est an publicados bajo la licencia Creative Commons, con lo cual cualquier persona puede ampliar/modicar las placas. Sobre la programaci on del microcontrolador de la placa, esta se realiza utilizando el Arduino IDE, programando bajo el lenguaje de programaci on de Arduino, el cual se basa en Wiring 1 y su estructura es bastante simple. Sin entrar en detalles, la estructura de un programa contiene dos funciones: la primera, setup(), la cual es llamada cuando comienza un sketch y se utiliza para inicializar variables, congurar pines, empezar a usar bibliotecas, etc. Esta funci on se llama
1
http://wiring.org.co/
19
2.4. ARDUINO
solo una vez al energizar o resetear la placa. La segunda funci on es loop(), la cual se ejecuta secuencialmente respondiendo como lo requiera el programa. Dependiendo del objetivo que se tenga en el proyecto a realizar, se tienen distintas placas, donde puede variar el microcontrolador, cantidad de salidas digitales, entradas an alogas, tama no, tipo de alimentaci on, interfaces e incluso el material sobre el cual est a montado el microcontrolador. Por ejemplo, se tiene la placa Arduino Mega ADK la cual es de mayor tama no que el resto de placas, contiene m as entradas an alogas, m as salidas digitales y posee un puerto Universal Serial Bus (USB) basado en el circuito integrado MAX3421e capaz de conectarse a dispositivos Android. Tambi en destaca el Arduino Lilypad capaz de adherirse a textiles con la nalidad de crear ropa inteligente o proyectos similares; Arduino Pro Mini el cual es el m as peque no de todos y Arduino BT con la cualidad de poder establecer una comunicaci on inal ambrica mediante Bluetooth. La Figura 2.6 muestra los m odulos mencionados.
(a) Arduino Uno
(b) Arduino Mega ADK
(c) Arduino Lilypad
(d) Arduino Pro Mini
(e) Arduino BT
Fig. 2.6: Variantes de una placa Arduino [15].
20
2.5. ANDROID
2.5.
Android
Android es un sistema operativo para dispositivos m oviles lanzado en noviembre de 2007 por Google, bajo la Open Handset Alliance, el cual es un conglomerado de empresas desarrolladoras de hardware y software. A diferencia de otros sistemas operativos, las aplicaciones bajo esta plataforma no se construyen bajo sistemas proprietarios, los cuales priorizan aplicaciones nativas sobre las creadas por terceros y restringen la comunicaci on entre las aplicaciones y la informaci on nativa del dispositivo. Android ofrece nuevas posibilidades para el desarrollo de aplicaciones m oviles al ofrecer un ambiente de desarrollo abierto creado bajo un kernel de Linux Open Source. El acceso al hardware est a disponible para todas las aplicaciones a trav es de una serie de bibliotecas APIs. Adem as, en Android todas las aplicaciones tienen la misma importancia, es decir, aplicaciones nativas o creadas por terceros son creadas con las mismas APIs y se ejecutan en el mismo tiempo de ejecuci on. Los usuarios pueden borrar aplicaciones nativas y reemplazarlas por aplicaciones creadas por terceros, lo cual lo convierte en un sistema sumamente exible [28]. La Figura 2.7 muestra la interfaz gr aca de la versi on 2.2 de Android, Froyo.
Fig. 2.7: Interfaz gr aca de Android 2.2 [25].
21
2.5. ANDROID
2.5.1.
Componentes de una aplicaci on
Una aplicaci on en Android consiste en los siguientes componentes [26, 27, 28, 29]: Actividades (Activities ): una actividad representa la capa de presentaci on de una aplicaci on, o en otras palabras son componentes de la interfaz que corresponde a una pantalla. Por ejemplo, una aplicaci on de correo electr onico puede tener una actividad que muestra la lista de nuevos correos, otra puede encargarse de componer un correo y otra para leerlos. Son independientes entre ellas pero pueden interactuar entre s , por ejemplo una aplicaci on de la c amara puede iniciar una actividad de la aplicaci on de correo electr onico para compartir una fotograf a al componer un correo.
Fig. 2.8: Ciclo de vida de una actividad [26]. La Figura 2.8 muestra el ciclo de vida de una actividad. Como se puede observar, todo el ciclo de vida ocurre entre las llamadas a onCreate() y onDestroy(), donde la
22
2.5. ANDROID
primera, como su nombre lo indica, es llamada cuando se crea la actividad, inicializando los componentes principales, como la interfaz gr aca, onDestroy(), por el contrario, se encarga de destruir la actividad liberando los recursos que se estaban utilizando. Por otro lado, el ciclo de vida visible ocurre entre onStart() y onStop(), ya que es dentro de estos m etodos que el usuario puede ver la actividad en pantalla e interactuar con ella, por lo cual pueden ser llamadas m ultiples veces en un ciclo de vida cuando el usuario manipula varias actividades. En resumen, onStart() es llamada antes de aparecer la actividad en pantalla, seguido por onResume(), mientras que onStop() es llamada cuando comienza otra actividad y esta deja de ser visible. Finalmente, el ciclo de vida en primer plano ocurre entre las llamadas a onResume() y onPause(), aqu la actividad est a corriendo al frente de las otras actividades en pantalla. Es muy f acil transitar entre estos dos estados ya que basta con que el dispositivo se duerma o surja un di alogo para que se llame a OnPause() por lo cual se recomienda no sobrecargar con c odigo estos m etodos y as evitar una transici on lenta entre actividades [26]. Servicios (Services ): son componentes que corren en segundo plano para ejecutar operaciones de larga duraci on o para ejecutar procesos remotos. Un servicio no provee una interfaz de usuario. Por ejemplo, un servicio puede reproducir m usica en segundo plano mientras el usuario utiliza otra aplicaci on, o puede obtener datos a trav es de la red sin bloquear la interacci on del usuario con una actividad. La Figura 2.9 ilustra el ciclo de vida de un servicio. Como se puede observar, es m as simple que el de una actividad, sin embargo, hay que tener cuidado ya que a diferencia de una actividad ac a el proceso puede estar corriendo en segundo plano sin que el usuario se percate debido a la ausencia de una interfaz gr aca. Al igual que en el caso de una actividad, OnCreate() y OnDestroy() se encargan de iniciar y nalizar el ciclo, seteando las variables a utilizar y liberando los recursos, respectivamente. Luego, en el ciclo de vida activo se distinguen dos ciclos dependiendo de la implementaci on de este: OnStartCommand() se utiliza cuando el servicio es iniciado por otro componente, como una actividad, para realizar una tarea espec ca, como descargar un archivo. En este caso el servicio debe ser detenido por s mismo (mediante stopSelf()) o mediante otro
23
2.5. ANDROID
Fig. 2.9: Ciclo de vida de un servicio [27]. componente (utilizando stopService()). Por otro lado, OnBind() se utiliza cuando otro componente necesita unirse al servicio para interactuar mediante una conexi on de larga duraci on, el cual retorna un IBinder y as denir la interfaz con la cual se comunicar an los componentes. Para cerrar el enlace entre los componentes se utiliza onUnBind(). Proveedores de contenido (Content providers ): se utilizan para manejar y compartir bases de datos de las aplicaciones, con lo cual las aplicaciones pueden solicitar estos datos y modicarlos si se requiere, los cuales pueden estar en la web, en una base de datos SQLite o en cualquier lugar de almacenamiento donde la aplicaci on pueda acceder. Intenciones (Intents ): son mensajes que provocan noticaciones o cambios de estado, que al ser recibidos por actividades o servicios pueden levantar procesos. De esta forma se unen componentes dentro de la misma aplicaci on o de aplicaciones diferentes. Receptores de radiodifusi on (Broadcast receivers ): son componentes que responden a avisos del sistema (bater a baja, llamada entrante, etc.) o a intenciones impl citas. No despliegan una interfaz de usuario pero a veces muestran una barra de progreso para noticar cuando un evento de difusi on ocurre.
24
Cap tulo 3 Dise no e implementaci on

3.1. Introducci on
El presente cap tulo describe en detalle el dise no e implementaci on tanto del sistema general como por etapas, donde para una mejor comprensi on la descripci on se divide entre la RdSI y la aplicaci on m ovil. En el primer caso, la descripci on se enfoca en la implementaci on de cada nodo de la red, donde toma gran relevancia la conguraci on de los m odulos Xbee y en el caso particular del nodo coordinador la interacci on de estos m odulos con la placa Arduino y la l ogica del algoritmo implementado. En el caso de la aplicaci on m ovil se muestra paso a paso el dise no de la interfaz gr aca y mediante diagramas de ujo se explica el funcionamiento de la aplicaci on en general y de algunas etapas espec cas si se requieren.
3.2.
Requerimientos t ecnicos
Los requisitos para el dispositivo m ovil son: S.O. Android 2.1 (Eclair ) o superior Conexi on Wi-Fi Memoria RAM igual o superior a 512 [MB] Memoria interna igual o superior a 170 [MB]
25
3.2. REQUERIMIENTOS TECNICOS
E IMPLEMENTACION CAP ITULO 3. DISENO
Procesador igual o superior a 600 [MHz] La placa espec ca que se utiliza es la Arduino Uno la cual se basa en el microcontrolador ATmega328. Tiene 14 pines de entradas/salidas digitales (de las cuales 6 se pueden utilizar como salidas PWM1 , 6 entradas an alogas, un oscilador de cristal a 16 MHz, conexi on USB, conector de alimentaci on, pines ICSP2 para programar el bootloader de la placa y un bot on de reseteo. La Tabla 3.1 resume sus principales caracter sticas. Tabla 3.1: Caracter sticas de la placa Arduino Uno [16].
Microcontrolador Voltaje de operaci on Voltaje de entrada (recomendado) Voltaje de entrada (l mites) Pines digitales E/S Pines an alogos de entrada Corriente DC por pin E/S Corriente DC para pin 3.3 V Memoria ash SRAM EEPROM Velocidad de reloj ATMega 328 5V 7-12 V 6-20 V 14 (6 salidas PWM) 6 40 mA 50 mA 32 KB (de los cuales 5 son usados por el bootloader ) 2 KB 1 KB 16 MHz
Por el lado del servidor, como S.O. debe tener alguna distribuci on de Linux ya que el reproductor de m usica moc no est a disponible para otro tipo de S.O. Adem as, para controlar remotamente el sistema es necesario montar un servidor SSH, como puede ser por ejemplo OpenSSH. Es importante se nalar que el puerto por defecto que utiliza este protocolo es el 22, por lo tanto es necesario que el router asociado a la red permita el acceso a este puerto. Sobre la RdSI, ya que los m odulos Xbee Series 1 y Series 2 no son compatibles entre s es necesario elegir uno de los 2. Si bien ambos permiten topolog a estrella en la red a implementar, en estricto rigor los m odulos Series 1 no trabajan con el est andar ZigBee, lo que implica que no permiten topolog a mesh en la implementaci on de la red entre otras desventajas. Adem as, los m odulos Series 2 poseen una mayor exibilidad en su conguraci on y tienen un mejor rendimiento en alcance y consumo que el tipo Series 1. Concluyendo, se recomienda utilizar
1 2
Modulaci on por ancho de pulsos Programador Serial En Chip
26
GENERAL 3.3. DISENO
los m odulos Series 2. Por otro lado, dentro de los m odulos de este tipo se pueden utilizar los m odulos Xbee o Xbee-pro, siendo interoperables entre s y con diferentes caracter sticas de alcance y consumo.
3.3.
Dise no general del sistema
El sistema implementado (ver Figura 3.1) consiste en un dispositivo m ovil con Android 2.1 o superior, el cual mediante la aplicaci on m ovil creada establece una comunicaci on SSH con un servidor, el que a su vez tiene asociada una RdSI utilizando los m odulos Xbee Series 2 con el n de poder comunicarse bajo el protocolo Zigbee. El nodo coordinador de la red, con el prop osito de leer los datos le dos de los sensores y tomar decisiones en funci on de estos trabaja en conjunto con la plataforma Arduino. Adem as, el servidor est a dotado del reproductor multimedia moc, el cual puede ser controlado por l nea de comandos, sin la necesidad de interfaz gr aca y con un bajo consumo de recursos, convirti endolo en un reproductor ideal para ser utilizado en servidores de forma remota.
Fig. 3.1: Sistema general. Una vez que la aplicaci on m ovil establece la conexi on con el servidor, a trav es de un men u de opciones puede realizar diversas tareas interactuando con la RdSI. En primer lugar, se pueden accionar los actuadores de forma manual, encendiendo o apagando el ventilador, l ampara y
27
DETALLADO 3.4. DISENO
cafetera pertenecientes a la red. En segundo lugar, se puede observar en pantalla la temperatura medida por los sensores y jar el umbral en estos para que accione el ventilador de forma autom atica, adem as de poder jar tambi en el umbral de luminosidad y actuar de la misma forma sobre la l ampara. Por otro lado, se puede programar por horario el accionamiento de los actuadores adem as de guardar preferencias las cuales pueden ser ejecutadas m as tarde incluso sin acceder a la aplicaci on. Finalmente como ya se ha comentado la aplicaci on puede interactuar con un reproductor de m usica ejecutando una lista de reproducci on guardada. Un factor importante dentro del sistema es que el Arduino adem as de controlar la red de forma aut onoma a trav es de la lectura de los sensores en los nodos nales, tambi en es capaz de recibir datos por puerto serial, y es aqu donde la aplicaci on m ovil juega un papel primordial ya que su forma de operar es ejecutando comandos remotos a trav es de la comunicaci on SSH establecida. Estos comandos remotos ejecutan scripts almacenados en el servidor que cumplen la funci on de enviar un dato al Arduino con el n de que este ejecute una tarea espec ca sobre la RdSI.
3.4.
3.4.1.
Dise no detallado del sistema

Dise no de la aplicaci on m ovil
Como ya se ha comentado, la aplicaci on m ovil desarrollada se comunica con el servidor mediante el protocolo SSH y as interact ua con la RdSI. Para ello, se utiliza una biblioteca en Java llamada Orion SSH2 la cual permite una f acil integraci on al IDE Eclipse y por lo tanto en el desarrollo de una aplicaci on en Android. Respecto al dise no de la interfaz gr aca se utilizan herramientas gr acas disponibles con el Android SDK las cuales son sucientes para el completo desarrollo de la aplicaci on excepto en el caso de la interfaz para el control del reproductor de m usica. En este caso se utilizan ImageButton, que no son m as que im agenes externas las cuales adquieren propiedades de un bot on seg un lo requiera la aplicaci on. Por otro lado, la aplicaci on se desarrolla con Android 2.1 como objetivo, de esta forma la aplicaci on podr a ser utilizada por todos los dispositivos m oviles que utilicen este S.O. o una versi on superior. Ya que el sistema creado est a pensado para todo tipo de usuario y no s olo para aquellos
28
con alto conocimiento en uso de smartphones, la interfaz no hace uso de herramientas gr acas complejas, incluso la mayor parte est a implementada con las herramientas que provee el SDK. Ahora, como se detalla en la Secci on 2.5.1 uno de los componentes principales de la aplicaci on son las actividades, donde cada una posee una interfaz gr aca que interact ua con el usuario, comunic andose y pasando informaci on entre ellas. As , cada interfaz gr aca creada es pensada como una actividad dentro de la aplicaci on.
Fig. 3.2: Estructura de navegaci on. La Figura 3.2 presenta la estructura de navegaci on de la aplicaci on implementada. Como se puede observar se tienen distintos bloques donde cada uno posee una interfaz gr aca y realiza una tarea espec ca, por lo tanto se pueden considerar como actividades independientes. Es importante se nalar respecto a la creaci on de perles que estos se utilizar an para la creaci on de un Widget 3 . De esta forma, una vez creado un perl dentro de la aplicaci on, a trav es del Widget se podr a ejecutar sin la necesidad de ingresar nuevamente datos del servidor y navegar innecesariamente dentro de cada interfaz gr aca. A continuaci on se detalla el dise no e implementaci on de cada bloque incluyendo el Widget mencionado.
3
Un Widget es una especie de acceso directo a la aplicaci on la cual posee su propia interfaz gr aca, ya sea
para mostrar informaci on relevante o realizar una tarea espec ca.
29
Presentaci on
Como en casi toda aplicaci on, antes de entrar a los componentes realmente trascendentes respecto al funcionamiento de la misma, se tiene una interfaz en la cual se despliega informaci on relevante y como su nombre lo indica, se presenta la aplicaci on. Los componentes utilizados son TextView, el cual se encarga de desplegar texto en pantalla; ImageView, que se encarga de desplegar im agenes, en este caso el logo de la Universidad de Concepci on; y Button, que son los botones proporcionados por el SDK y en este caso se utiliza para continuar a la siguiente actividad. La Figura 3.3 presenta el diagrama de ujo de esta actividad.
Fig. 3.3: Diagrama de ujo correspondiente a la actividad de presentaci on de la aplicaci on. Para describir el diagrama, es necesario recordar el ciclo de vida de una actividad descrito en la Figura 2.8. En este caso s olo es necesario implementar la funci on onCreate(), encargada de cargar la interfaz gr aca cuando se crea la actividad. Luego, esta espera a que ocurra un evento, en este caso la pulsaci on de un bot on, para luego pasar a la actividad siguiente una vez pulsado el bot on mencionado. Para implementar la acci on a realizar en la pulsaci on de un bot on se utiliza un listener, el cual es un objeto de una clase que ejecuta una funci on en el caso de que se produzca un evento determinado. As , la funci on a utilizar dentro del listener se llama onClick(), y es dentro de ella que se implementa la tarea a realizar al pulsar el bot on creado. Finalmente, para implementar dentro de la funci on onClick() que lo que se quiere al pulsar el
30
bot on es pasar a la siguiente actividad, se utiliza una intenci on (descrita en la Secci on 2.5.1) ingresando como par ametros la actividad actual y la de destino.
Ingreso de datos del servidor
En este bloque el usuario ingresa los datos para establecer la comunicaci on SSH entre el dispositivo m ovil y el servidor. Como en toda conexi on de este tipo, se debe ingresar la IP del servidor, Usuario y Contrase na de la cuenta del servidor al cual se conecta la aplicaci on. Para realizar lo anterior se utilizan cuadros de textos en los cuales el usuario puede ingresar datos, llamados EditText. Para guardar los datos en el caso de que el usuario lo requiera se utiliza un cuadro que se puede activar o desactivar, llamado CheckBox. Adem as, se utilizan dos botones, uno para volver a la actividad de presentaci on y otro que realiza la conexi on y contin ua al men u de opciones. La Figura 3.4 expone el diagrama de ujo correspondiente. En esta actividad, aparte de OnCreate() se implementa OnPause() y OnResume() para un correcto manejo de los datos de conexi on. Esto es as ya que en OnPause() se guardan los datos dependiendo del estado del CheckBox, mientras que en OnResume() se recuperan estos datos y se completan los EditText correspondientes. Para guardar los datos se utiliza una clase llamada SharedPreferences, la cual contiene el m etodo getSharedPreferences. Para manipular los datos se utiliza un editor utilizando edit() y para guardar los datos se hace uso de putBoolean(), putString(), etc. seg un el tipo de dato a guardar. De esta forma el inicio del diagrama de ujo lo marcan las funciones OnCreate() y OnResume() seg un sea el caso. Luego, la actividad espera que ocurra un evento. En el caso de que se presione el bot on Conectar, se intenta establecer la conexi on utilizando los datos ingresados por el usuario y se pasa al men u de opciones si la conexi on es exitosa, adem as de desplegar un mensaje informando del exito en la conexi on (Toast ); en el caso de no poder establecer el enlace tambi en se informa mediante un Toast. Una vez realizada la conexi on y pasar al siguiente bloque, la actividad llama a OnPause() y es en este m etodo donde se guardan los datos dependiendo del estado del CheckBox. Finalmente si se pulsa el bot on Atr as la aplicaci on vuelve a la interfaz de presentaci on.
31
Fig. 3.4: Diagrama de ujo correspondiente a la actividad de conexi on al servidor. Men u de opciones
Una vez establecida la conexi on, el usuario debe decidir que tarea realizar. Para ello, se implementa un men u en el cual aparecen todas las opciones disponibles para controlar el sistema desarrollado. La herramienta gr aca utilizada para realizar esta tarea se llama RadioGroup la cual consiste en un n umero determinado de botones excluyentes entre s , con el n de poder seleccionar una sola opci on. Al lado de cada bot on seleccionable se utiliza un TextView explicando en que consiste la opci on a seleccionar y nalmente se utilizan dos botones donde uno lleva a la opci on seleccionada, mientras el otro naliza la conexi on y vuelve a la actividad previa, es decir, al bloque donde se ingresan los datos para realizar la conexi on. La Figura 3.5 muestra el
32
diagrama de ujo de esta actividad.
Fig. 3.5: Diagrama de ujo correspondiente a la actividad de men u de opciones. Como se puede observar, el funcionamiento de esta actividad es similar a las que ya se han detallado, con la diferencia que al implementar un RadioGroup, es una vez que se ha pulsado el bot on Continuar que se comprueba cual es la opci on que se ha seleccionado para luego proceder a la actividad correspondiente. En el caso particular de la primera opci on, antes de pasar a la actividad se ejecutan dos comandos remotos con el n de desactivar los sensores, expl citamente los scripts sensortempo.py y sensorluzo.py, que como ya se detall o en la Secci on 3.3, al ejecutarlos env an un caracter al Arduino para que realice la tarea correspondiente. Por problemas de espacio en el diagrama no se incluyen las opciones 3 y 4, pero de forma an aloga al resto de las opciones estas llevan a los bloques de conguraci on de sensores y creaci on de perles, respectivamente.
33
Ejecuci on manual de actuadores
La tarea de esta actividad es bastante simple y corresponde a la ejecuci on inmediata de los actuadores en la red. Para ello, se utilizan botones Toggle los cuales tienen la particularidad de tener dos estados, de esta forma al pulsar el bot on se enciende el actuador requerido y al volver a pulsarlo se apaga. As , se presenta una interfaz en la cual se tienen tres botones Toggle que corresponden a cada actuador de la red (ventilador, l ampara y cafetera). La Figura 3.6 muestra el diagrama de ujo respectivo,
Fig. 3.6: Diagrama de ujo correspondiente a la actividad de ejecuci on manual de actuadores. Como se puede observar, una vez presionado un bot on Toggle, inmediatamente se ejecuta un comando remoto ya sea para encender o apagar un actuador, dependiendo del estado del bot on. Finalmente, al igual que en las actividades anteriores, se tiene un bot on para volver al men u de opciones.
Programar ciclos horarios
La implementaci on de esta interfaz diere de las anteriores ya que en este caso se utilizan pesta nas (tabs ), donde cada una corresponde a un actuador o al reproductor multimedia, formando un total de cuatro pesta nas independientes entre s permitiendo la posibilidad de programar la hora en que se quiere encender/apagar cada uno de los elementos mencionados.
34
En estricto rigor, la implementaci on de este bloque consiste en cinco actividades, donde se crea una que aloja a las pesta nas restantes tratando cada pesta na como una actividad independiente. Respecto al dise no de las pesta nas, este es pr acticamente el mismo para todas, consistiendo en dos TextViews que muestran la hora de encendido y apagado seleccionadas, dos botones que al ser presionados despliegan un di alogo que contiene un TimePicker, herramienta gr aca que permite seleccionar la hora de encendido o apagado seg un sea el caso, y dos CheckBox, que al ser activados establecen la alarma de encendido o apagado. La Figura 3.7 ilustra el TimePicker utilizado para establecer el horario mientras que la Figura 3.8 muestra el diagrama de ujo correspondiente a una pesta na. Como se ha mencionado, el resto de pesta nas poseen un funcionamiento exactamente igual por lo que con explicar el funcionamiento de una sola es suciente.
Fig. 3.7: Herramienta gr aca TimePicker utilizada para programar ejecuciones por horario. Del diagrama se puede observar la relaci on entre los distintos elementos gr acos utilizados en la implementaci on de esta actividad, donde como se ha mencionado, una vez presionado el bot on Cambiar hora se despliega un di alogo que muestra un TimePicker para establecer la hora que se desea, pero es una vez que se activa el CheckBox que la alarma queda completamente activada. Es importante se nalar que para la implementaci on de alarmas se utiliza la clase AlarmManager, el cual dentro de sus funciones permite al dispositivo m ovil despertar para que realice una tarea espec ca en un tiempo determinado. De esta forma, al crear la alarma se implementa una intenci on pendiente (PendingIntent), que no es m as que una intenci on que tiene como par ametros la actividad actual y un servicio, que ser a ejecutado en un momento
35
Fig. 3.8: Diagrama de ujo correspondiente a la actividad de programaci on horaria. determinado. En otras palabras, lo que se implementa es que el dispositivo m ovil despierte en la hora indicada por el TimePicker y realice una tarea espec ca, en este caso la ejecuci on de un servicio. As , una vez activada una alarma mediante un TimePicker y un CheckBox, el sistema ejecutar a una tarea espec ca en el momento establecido por el usuario, tal como muestra la Figura 3.9 donde se observa el diagrama de un servicio a ejecutar en el caso de haber activado la alarma para encender el ventilador. Como se observa en el diagrama el servicio debe establecer la conexi on con el servidor, ya que es probable que el usuario no est e utilizando la aplicaci on y por lo tanto no est e conectado. Para ello utiliza los datos de conexi on guardados en la actividad de conexi on. Luego, ejecuta el comando remoto correspondiente al encendido del ventilador y posteriormente naliza la conexi on con el servidor.
36
Fig. 3.9: Diagrama de ujo correspondiente al servicio ejecutado por alarma horaria. Congurar sensores
En esta actividad se establecen los umbrales de temperatura y luminosidad de los sensores con el n de que el Arduino encienda o apague un actuador si estos umbrales son sobrepasados. Para el dise no de esta interfaz se utiliza un Seekbar, que como se puede observar en la Figura 3.10 corresponde a una barra deslizante con un valor m nimo y m aximo establecido en su dise no. As , se tiene un Seekbar para seleccionar el umbral de temperatura y otro para el umbral de luminosidad. Por otro lado, se tiene un TextView que muestra la temperatura promedio medida por los sensores y que es actualizable de dos maneras. La primera, al ingresar a la actividad y de forma autom atica, y la segunda, a trav es de un bot on. Finalmente, se tienen otros dos botones encargados de ejecutar el comando remoto con el umbral seleccionado por el usuario y dos TextViews que muestra en pantalla el valor del umbral actual que se est a seleccionando al mover el Seekbar. La Figura 3.11 muestra el diagrama de ujo de la actividad.
Fig. 3.10: Herramienta gr aca SeekBar utilizada para regular umbrales de temperatura y luminosidad.
37
Fig. 3.11: Diagrama de ujo correspondiente a la actividad de conguraci on de sensores. Como se observa, inmediatamente al ingresar a la actividad se ejecuta un comando remoto que obtiene la temperatura promedio medida por los sensores, mostr andola en pantalla adem as de los u ltimos umbrales establecidos por el usuario, los cuales han sido guardados mediante la clase SharedPreferences. Por otro lado, para establecer un umbral es necesario pulsar el bot on Establecer correspondiente al umbral deseado ya sea de luminosidad o temperatura. Finalmente, al salir de la actividad, se guardan los valores de umbrales utilizados para luego volver al men u de opciones.
Congurar y accionar perles
El dise no de la interfaz perteneciente a este bloque tiene similitudes con los bloques de ejecuci on manual de actuadores y programaci on horaria, en el sentido que ac a tambi en se utilizan pesta nas con la nalidad de poder crear tres perles de forma independiente y en la interfaz de cada pesta na o perl se utilizan botones Toggle con el n de decidir si se quiere que un actuador est e encendido o apagado. Para guardar un perl, primero se debe decidir que es lo que se quiere que est e encendido y apagado mediante los botones Toggle correspondientes, para luego guardar el perl mediante
38
un bot on. En estricto rigor, al guardar el perl lo que la aplicaci on realiza es guardar el estado de cada bot on Toggle. Luego, para ejecutar un perl se tienen dos opciones, la primera es a trav es de un bot on en la misma interfaz, ejecutando comandos remotos de acuerdo al estado de los botones Toggle guardados, y la segunda opci on, detallada m as adelante, es mediante un Widget. La Figura 3.12 resume el proceso descrito anteriormente.
Fig. 3.12: Diagrama de ujo correspondiente a la actividad de conguraci on y accionamiento de perles. Controlar reproductor de m usica
Como se ha comentado, a trav es de la aplicaci on el dispositivo m ovil puede interactuar con el reproductor multimedia moc, ejecutando de forma remota los distintos comandos por consola que lo controlan. La Tabla 3.2 muestra los comandos a ejecutar por la aplicaci on y la funci on que realizan.
39
Tabla 3.2: Comandos ejecutados por la aplicaci on para controlar el reproductor moc.
Comando mocp -r mocp -Q %artist mocp -Q %song mocp -k -5 mocp -S mocp -c mocp -a lista.m3u -p mocp -G mocp -k +5 mocp -f mocp -v +10 mocp -v -10 mocp -x Funci on Inicia canci on previa de la lista Obtiene nombre del artista en la canci on actual Obtiene nombre de la canci on actual Retrocede canci on en 5 segundos Inicia reproductor Borra lista de reproducci on actual A nade e inicia lista de reproducci on desde la primera canci on Play/Pause Adelanta canci on en 5 segundos Inicia siguiente canci on de la lista Aumenta volumen Disminuye volumen Cierra el servidor
Para el dise no de esta interfaz gr aca se utiliza la herramienta ImageButton, que no es m as que una imagen que cumple la funci on de un bot on. As , algunos comandos como adelantar/retroceder, pausar, aumentar volumen, etc. son ejecutados mediante esta herramienta. La Figura 3.13 ilustra los ImageButtons utilizados en esta interfaz.
Fig. 3.13: Herramientas gr acas ImageButton utilizadas para el control del reproductor multimedia. Complementando los botones mencionados, se tiene un bot on que al igual que en el caso de la programaci on horaria despliega un di alogo, que en este caso tiene como n que el usuario introduzca por teclado la lista de reproducci on que quiera ejecutar, y otro que cierra el reproductor. Finalmente, mediante Textviews se muestra el nombre de la lista de reproducci on seleccionada y el nombre del artista y la canci on que se est e reproduciendo. El diagrama de ujo correspondiente a esta actividad se muestra en la Figura 3.14.
40
Fig. 3.14: Diagrama de ujo correspondiente a la actividad de control del reproductor multimedia. Como se observa, cada bot on ya sea un ImageButton o no, ejecuta uno o varios comandos remotos con el n de controlar el reproductor. Al igual que en otras actividades descritas, para guardar los datos se utiliza la clase SharedPreferences, que en este caso tiene la gran utilidad de guardar el nombre de la lista de reproducci on seleccionada por el usuario, con el n de que no sea necesario ingresarla cada vez que se utilice la aplicaci on.
Creaci on de Widgets
Tal como se detall o en el caso de la creaci on y conguraci on de perles, una vez que se guardan hay dos formas de ejecutarlos. La primera es dentro de la misma interfaz a trav es de un bot on y la segunda es a trav es de un Widget, que como ya se ha mencionado tiene la ventaja de no ser necesario entrar a la aplicaci on para ejecutarlo. En la implementaci on de la aplicaci on se han creado tres Widgets, uno por cada perl creado,
41
de esta forma en un perl se puede seleccionar que solo se encienda la cafetera, en otro que se encienda el reproductor de m usica y la l ampara, etc. Respecto al dise no, este es bastante simple, ya que s olo contiene un bot on y un texto jo que indica a que perl hace referencia el Widget. De esta forma, al pulsar el bot on se ejecuta un servicio similar al creado en el caso de la programaci on de tareas por horario. Utilizando los datos guardados mediante la clase SharedPreferences, el servicio obtiene los datos de conexi on guardados en la actividad de conexi on al servidor y los datos del perl a ejecutar, es decir el estado de cada bot on Toggle con el n de ejecutar los comandos remotos correspondientes. Luego, establece la conexi on con el servidor para posteriormente ejecutar los comandos remotos respectivos. Una vez ejecutados los comandos cierra la conexi on con el servidor. La Figura 3.15 resume la implementaci on del servicio ejecutado por el Widget.
Fig. 3.15: Diagrama de ujo correspondiente al servicio ejecutado por el Widget.
3.4.2.
Dise no de las aplicaciones en el servidor
Como se mencion o en la Secci on 3.3, a trav es de la aplicaci on m ovil se ejecutan de forma remota scripts alojados en el servidor los cuales env an por puerto serial datos al Arduino. Para enviar estos datos se utiliza una biblioteca en python llamada pySerial 4 que permite el acceso
4
http://pyserial.sourceforge.net/
42
transparente a puertos seriales (virtuales o reales) y de esta forma crear peque nos programas ejecutables por consola los cuales, en este caso, se encargan de enviar un caracter, ya sea una A, B, C, etc. As , por ejemplo, la aplicaci on m ovil puede ejecutar el archivo alojado en el servidor ventiladoro.py el cual se encarga de enviar por puerto serial una J al Arduino para que este apague el ventilador interactuando con la RdSI. A continuaci on se muestra el c odigo descrito.
1 2 3 4 5 6 7 8 9 10
#!/ u s r / b i n / env python
im po rt s y s im po rt s e r i a l
# Setea puerto s e r i a l s e r = s e r i a l . S e r i a l ( / dev /ttyACM0 , 9 6 0 0 )
l e t r a= J ; ser . write ( letra ) ;
Como se puede observar, el c odigo simplemente congura el puerto serial por el cual se enviar a el dato, dene la variable y la env a. De esta forma, el servidor aloja distintos scripts creados con el n de ser ejecutados de forma remota por la aplicaci on m ovil y enviar el caracter correspondiente al Arduino para que este realice la acci on correspondiente. La Tabla 3.3 especica la funci on a realizar seg un el dato serial recibido.
43
Tabla 3.3: Tareas realizadas por Arduino en funci on del dato serial recibido.
Dato recibido A B C D E F G H I J K L M Tarea a realizar Setea umbral de luminosidad Setea umbral de temperatura Desactiva sensores de temperatura Activa sensores de temperatura Desactiva sensores de luminosidad Activa sensores de luminosidad Enciende l ampara Apaga l ampara Enciende ventilador Apaga ventilador Enciende cafetera Apaga cafetera Env a temperatura promedio por puerto serial
3.4.3.
Dise no de la red de sensores inal ambricos
La RdSI implementada posee una topolog a estrella, es decir, los nodos nales se comunican directamente con el nodo coordinador ya sea enviando o recibiendo datos de este. La red creada la componen 5 nodos nales y el nodo coordinador. Los nodos nales se dividen en 2 nodos alimentados por bater as los cuales contienen un sensor de temperatura cada uno y 3 nodos sensores/actuadores los cuales combinan sensores de temperatura, luminosidad y rel es para poder accionar una l ampara, un ventilador y una cafetera. Nodo coordinador Es importante se nalar que Arduino utiliza los pines 0 y 1 para recibir y transmitir datos por el puerto serial, por lo tanto para conectar un m odulo Xbee en teor a se deben utilizar estos pines, lo cual interere con los datos provenientes v a USB. Es por esto que se utiliza la biblioteca SoftwareSerial para Arduino la cual permite utilizar otros pines como puerto serial, por ejemplo pines utilizados para salidas digitales. De esta forma los datos recibidos/enviados por el m odulo Xbee al Arduino no intereren con los datos recibidos ejecutando scripts remotos alojados en el servidor. La Figura 3.16 ilustra la conexi on entre el m odulo Xbee y Arduino
44
formando el nodo coordinador.
(a) Protoboard
(b) Esquema
Fig. 3.16: Nodo coordinador.
Como se puede observar, los pines 2 y 3 de Arduino han sido congurados para comunicarse con el m odulo Xbee. Adem as, aprovechando que la placa tiene un pin que entrega 3.3 [V] de salida, este se utiliza para alimentar el m odulo Xbee. Otro punto importante es el uso de un condensador de 10 [F] entre los pines RESET y GND de Arduino, ya que sin este condensador cada vez que la placa reciba un dato por puerto serial se resetear a, comenzando el programa cargado en el microcontrolador desde el inicio. Para una mejor comprensi on de este esquema y los siguientes en relaci on a los pines utilizados del m odulo Xbee, se tiene la Tabla 3.4. Respecto a la conguraci on del m odulo, se debe cargar el rmware coordinador en modo API, de esta forma se facilita la comunicaci on con los nodos nales ya que se pueden enviar frames a nodos espec cos indicando la direcci on de 64 bit (MAC) de cada uno dentro del frame. Adem as, se debe establecer una PAN ID para la red con el n de que todos los nodos se puedan comunicar bajo esta ID y no intereran con otras redes Zigbee. La ID de la red creada es 234
45
Tabla 3.4: Asignaci on de pines en m odulos Xbee [24].

# pin 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Nombre del pin VCC DOUT DIN DIO12 RESET RSSI PWM/DIO10 DIO11 RESERVED SLEEP RQ/DIO8 GND DIO4 DIO7 ON/DIO9 VREF ASSOC/DIO5 DIO6 AD3/DIO3 AD2/DIO2 AD1/DIO1 AD0/DIO0 Descripci on Alimentaci on del m odulo Salida de datos UART Entrada de datos UART Entrada/Salida digital 12 Reseteo del m odulo Indicador de potencia de se nal recibida / Entrada/Salida digital 12 Entrada/Salida digital 12 No conectar Pin de control modo sleep / Entrada/Salida digital 8 Tierra Entrada/Salida digital 4 Entrada/Salida digital 7 Indicador de encendido / Entrada/Salida digital 9 No utilizado en m odulos Series 2 Indicador de asociaci on a una red / Entrada/Salida digital 5 Entrada/Salida digital 6 Entrada an aloga 3 / Entrada/Salida digital 3 Entrada an aloga 2 / Entrada/Salida digital 2 Entrada an aloga 1 / Entrada/Salida digital 1 Entrada an aloga 0 / Entrada/Salida digital 0
y se debe establecer al congurar cada nodo. Es importante se nalar respecto al direccionamiento de los nodos en una red Zigbee que adem as de la direcci on MAC de cada m odulo se utiliza una direcci on de 16 bits, pero esta es asignada din amicamente por el coordinador a cada nodo de la red, por lo tanto no es necesario congurarla. A diferencia de la direcci on MAC, esta es u nica s olo dentro de la red creada. La Tabla 3.5 muestra la direcci on MAC de cada nodo en la red y la funci on que cumple cada m odulo. En relaci on a las bandas de operaci on de la red, el est andar ZigBee opera en la banda de frecuencia ISM utilizando los canales disponibles en la banda de 2.4 [GHz] (ver Figura 2.2). De esta forma, los m odulos Xbee soportan 14 de los 16 canales mientras que en su versi on Pro soportan los 16 canales en su totalidad. Respecto a la conguraci on del coordinador en este aspecto, una vez que el coordinador selecciona una PAN ID tambi en selecciona de forma autom atica uno de los 16 canales el cual es com un para toda la red.
46
Tabla 3.5: Funci on de cada m odulo Xbee y direcci on MAC asociada.

Funci on Nodo coordinador Direcci on MAC SH=0013a200 SL=402c6415 Sensor de T alimentado por bater as
SH=0013a200 SL=4086dcc0
Sensor de T alimentado por bater as
SH=0013a200 SL=404b8793
Sensor de T y luminosidad/Actuador (cafetera)
SH=0013a200 SL=4086dc76
Sensor de luminosidad/Actuador (ventilador)
SH=0013a200 SL=4086dd6d
Actuador (l ampara)
SH=0013a200 SL=408c52f0
Finalmente otro par ametro importante a congurar es el tiempo en que el coordinador puede almacenar en el buer el dato a transmitir a un nodo nal, ya que este puede estar durmiendo y por ende no estar disponible para recibir ning un tipo de informaci on. El valor establecido es de 28 segundos, el cual es el m aximo valor congurable y suciente para las necesidades del sistema ya que los nodos que recibir an informaci on del coordinador son los nodos actuadores/sensores, los cuales al no estar alimentados por bater as estar an despiertos la mayor parte del tiempo y por ende disponibles para recibir alg un dato que el coordinador tenga para ellos. Nodos nales Dentro del sistema se tienen 5 nodos nales, 2 de los cuales est an alimentados por bater as y realizan exactamente la misma funci on, la cual es sensar la temperatura del ambiente cada cierto tiempo establecido y enviar este valor al nodo coordinador para que sea procesado por el Arduino. La Figura 3.17 muestra el dise no de estos nodos.
47
(a) Protoboard
(b) Esquema
Fig. 3.17: Nodo nal sensor de temperatura alimentado por bater as.
Como se puede observar, el m odulo Xbee est a alimentado por 2 bater as AA, las cuales proveen al m odulo del voltaje necesario para operar. El sensor de temperatura utilizado es el LM35 el cual entrega a la salida 10 [mV]/ [C], lo cual asegura una lectura correcta del sistema hasta 120 [C] (1.2 [V]) ya que este es el valor m aximo que leen las entradas an alogas de un Xbee. Finalmente la salida del sensor est as asociada al pin 20 del Xbee el cual es congurado como entrada an aloga. Los otros 3 nodos nales corresponden a actuadores, los cuales como se observa en la Tabla 3.5 pueden o no poseer un sensor de luminosidad y/o temperatura. Debido a que el dise no de estos 3 nodos es similar y el que est a asociado a la cafetera es el m as completo, su dise no se presenta en la Figura 3.18. De la gura se observa que la alimentaci on proviene de un transformador de 5 [V] el cual alimenta directamente la bobina del rel e. Este valor es demasiado alto para alimentar el Xbee por lo tanto se utiliza un regulador de voltaje de 3.3 [V] a la salida. Los condensadores se utilizan como desacopladores eliminando alg un ruido de baja frecuencia que puede provenir de los 220 [V] y otro de alta frecuencia proveniente del regulador, de esta forma se previene interferencia en el Xbee. El sensor de luminosidad utilizado es una fotoresistencia que forma parte de un divisor de voltaje, por lo cual se utiliza una resistencia de 510 [k] con el n de que el valor de voltaje a la salida est e en el rango de 0 - 1.2 [V]. Debido a que el Xbee no puede proporcionar el
48
(a) Protoboard
(b) Esquema
Fig. 3.18: Nodo nal actuador, sensor de temperatura y luminosidad.
voltaje ni la corriente necesaria para alimentar la bobina del rel e, se utiliza un transistor NPN para este prop osito. Finalmente, el sensor de temperatura se implementa de la misma manera que en los nodos alimentados por bater as. Los pines del Xbee utilizados son el 18, 19 y 20. El primero de ellos se congura como salida digital ya que dependiendo del estado de este pin se encender a la cafetera (o ventilador/l ampara en el caso de los otros 2 nodos), mientras que los otros dos se conguran como entradas an alogas debido a que se integran sensores en ellos. Finalmente, respecto a la conguraci on de cada nodo, como ya se ha mencionado es tarea del coordinador determinar el canal de operaci on de la red, pero si es necesario establecer la forma en que se comportar an en esta, por ejemplo determinando la tasa de muestreo de los sensores y reduciendo el consumo energ etico en los nodos alimentados por bater as, tema que se discute a continuaci on.
49
Conguraci on de modo sleep en nodos nales Como se ha comentado, en el sistema implementado se utiliza el modo Cyclic Sleep para congurar el tiempo que duermen los nodos nales, mediante los par ametros SP, ST, SN e IR. En primer lugar, los nodos alimentados por bater as deben reducir su consumo energ etico con el n de que duren el mayor tiempo posible. Debido a que la temperatura medida en un ambiente cerrado no suele sufrir cambios bruscos (a menos de que alg un suceso anormal suceda) no es necesario muestrear de forma continua. Adem as, estos nodos solo se dedican a sensar temperatura y no a recibir datos desde el nodo coordinador, por lo tanto no est an restringidos a la limitaci on de 28 segundos que este puede almacenar un dato en el buer. Dicho esto, la conguraci on de estos nodos est a dada por la Tabla 3.6, Tabla 3.6: Conguraci on modo sleep en nodos nales alimentados por bater as.
Par ametro SP ST SN IR Valor 0x7d0 (20000 [ms]) 0x96 (150 [ms]) 0xf (15) 0xa0 (160 [ms])
Con esta conguraci on los nodos duermen un tiempo total de SN SP = 5 minutos, despertando durante 150 milisegundos y enviando una sola muestra del valor de temperatura medido cada vez que despierta.
En el caso de los nodos nales actuadores/sensores al no estar alimentados por bater as no es necesario que est en durmiendo todo el tiempo, por el contrario, al funcionar como actuadores es necesario que est en despiertos el mayor tiempo posible ya que en cualquier instante podr an recibir una orden remota ya sea para apagar la l ampara, encender la cafetera, etc. Teniendo esto en consideraci on, la Tabla 3.7 presenta la conguraci on acorde a los requerimientos comentados. Como se puede observar, los nodos solo dormir an 320 milisegundos en cada ciclo (el m nimo congurable), manteni endose despiertos por 1 minuto enviando una muestra de los valores muestreados dentro de cada ciclo.
50
Tabla 3.7: Conguraci on modo sleep en nodos actuadores/sensores.

Par ametro SP ST SN IR Valor 0x20 (320 [ms]) 0xea60 (60000 [ms]) 1 0xea6a (60010 [ms])
3.4.4.
Dise no del subsistema Arduino
Antes de analizar el algoritmo implementado es importante mencionar que debido a lo extenso del diagrama este se ha dividido en cuatro bloques para facilitar su visualizaci on. Adem as, se mencionan dos puertos seriales, puerto serial 1 y puerto serial 2, los cuales corresponden en primer lugar a la comunicaci on serial entre el Arduino y el m odulo Xbee asociado utilizando la biblioteca SoftwareSerial y los pines 2 y 3 de Arduino (ver Figura 3.16). El segundo puerto serial mencionado corresponde a la comunicaci on entre el Arduino y el servidor. En primer lugar se inicializan todas las variables involucradas, umbrales de temperatura y luminosidad, temperatura y luminosidad promedio, etc. Luego, se setean los puertos seriales indicando el baud rate (9600 baudios para ambos). Despu es de eso, se entra inmediatamente al loop del programa donde se analiza si hay alg un frame de datos en el puerto serial el cual debe comenzar con el valor hexadecimal 0x7E (ver Figura 2.5). De no ser as , se procede al bloque 2, en caso contrario se descartan los 10 bytes siguientes hasta llegar al u ltimo valor de la direcci on MAC del m odulo con el n de determinar el origen del frame recibido seg un la Tabla 3.5. As , al saber el origen del dato recibido se puede saber de antemano si el frame contiene valores de luminosidad y/o temperatura analizando los bytes siguientes. Una vez descartados los bytes siguientes a la direcci on MAC se llega a los valores hexadecimales que contienen los valores sensados por los nodos nales los cuales son convertidos para obtener el valor de temperatura y luminosidad correspondiente. Finalmente, una vez realizado lo anterior se vuelve a analizar si hay alg un dato serial recibido repitiendo el bloque o en caso contrario procediendo al bloque 2. La Figura 3.19 resume el proceso descrito.
51
Fig. 3.19: Secuencia l ogica de Arduino, bloque 1. En el bloque 2 (ver Figura 3.20), una vez que se obtienen los valores de temperatura y luminosidad de los sensores se establece la luminosidad promedio para luego analizar si los sensores de luminosidad est an encendidos. De ser as , se realiza la comparaci on entre el valor promedio y el umbral establecido determinando si se encender a la l ampara o apagar a de acuerdo a esta comparaci on, asignando un valor true o false a la variable indicador. Luego de esta comparaci on se realiza el mismo procedimiento con los valores de temperatura recibidos y la
52
decisi on de encender o no el ventilador para nalmente pasar al bloque 3. Es importante se nalar que la variable indicador no enciende o apaga inmediatamente los artefactos asociados, sino que este valor es comparado con otra variable relacionada para nalmente enviar el frame al nodo nal, como se observar a en el bloque 4.
Fig. 3.20: Secuencia l ogica de Arduino, bloque 2. Al igual que en el bloque 1, en el bloque 3 se analiza si hay alg un dato en el puerto serial, pero en este caso el an alisis se centra en la comunicaci on entre el Arduino y el servidor, es decir, se analiza si se ha enviado alg un dato al haberse ejecutado alg un script de forma remota en el servidor. Por simplicidad en el dise no del sistema se ha determinado que los valores recibidos sean caracteres desde la A hasta la M, donde se realizar a una tarea espec ca dependiendo del caracter recibido, tal como se detall o en la Tabla 3.3 de la Secci on 3.4.2.
53
Fig. 3.21: Secuencia l ogica de Arduino, bloque 3. Como se coment o en el bloque 2, las variables indicador no encienden ni apagan inmediatamente el artefacto indicado, esto es debido a que al correr un loop indenidamente, si se toma por ejemplo la decisi on de encender el ventilador, se enviar a el frame al nodo nal en cada iteraci on del loop lo que claramente es innecesario e inundar a el puerto serial. Es por esto que en cada iteraci on se realiza una comparaci on con una variable llamada ultimo indicador, la cual es la misma variable indicador pero en la iteraci on anterior. De esta forma solo se env a el frame al nodo nal al comparar ambas variables y concluir que son distintas. El proceso descrito se puede observar en la Figura 3.22.
54
Fig. 3.22: Secuencia l ogica de Arduino, bloque 4. Finalmente se observa que una vez enviado el frame se actualiza la variable ultimo indicador con el n de volver a realizar la comparaci on en la pr oxima iteraci on, para luego llegar al nal del loop y comenzar de nuevo. El frame enviado a los nodos nales para encender/apagar cada artefacto tiene la estructura vista en la Figura 2.5, indicando expl citamente la direcci on MAC del nodo destino y especicando que el dato enviado es un comando AT, el cual setea el pin digital del m odulo Xbee en low o high seg un corresponda.
55
Cap tulo 4 Resultados y an alisis

4.1. Introducci on
En este cap tulo se presenta el resultado del sistema implementado, ilustrando en primer lugar los nodos de la red tal como se describi o en la Secci on 3.4.3. En segundo lugar, se muestra la interfaz gr aca de la aplicaci on m ovil desarrollada en funci on de las tareas que realizan de acuerdo a la implementaci on descrita en la Secci on 3.4.1. Adem as, se comprueba el funcionamiento de la aplicaci on registrando tanto en el dispositivo m ovil como en el servidor las tareas realizadas. Finalmente, considerando los sensores alimentados por bater as pertenecientes a la RdSI, se realiza un an alisis de estos con el n de determinar la duraci on de las bater as en funci on del tiempo en que duermen los nodos.
4.2.
Resultados
Como se detall o en la Secci on 3.4.3 cada nodo de la red est a compuesto por un m odulo Xbee Series 2, ya sea en su variante regular o pro. En el caso del nodo coordinador se utiliza la plataforma Arduino para procesar los datos recibidos del resto de los sensores. La Figura 4.1 presenta los nodos que componen la red.
56
4.2. RESULTADOS
CAP ITULO 4. RESULTADOS Y ANALISIS
(a) Nodo nal sensor de temperatura.
(b) Nodo coordinador.
(c) Nodo nal actuador, sensor de temperatura y luminosidad.
Fig. 4.1: Nodos implementados en la RdSI. Si bien la red est a compuesta por 3 nodos m as, estos cumplen la misma funci on que los nodos nales reci en expuestos, es decir, se tiene otro nodo sensor de temperatura donde la u nica diferencia es el tipo de m odulo Xbee utilizado y se tienen dos nodos actuadores m as, donde s olo se diferencian con el nodo mostrado en los sensores que poseen, donde uno s olo posee un sensor de luminosidad y el otro s olo es actuador. Las pruebas del sistema fueron realizadas con exito en un ambiente cerrado, espec camente el laboratorio de redes de datos de la Universidad de Concepci on utilizando como servidor un laptop con Ubuntu Linux como S.O. y OpenSSH como servidor SSH, adem as de un perl de usuario llamado wsnserver. No se realizaron pruebas del rango de alcance de la red ya que se han realizado previamente estudios caracterizando los m odulos Xbee en este aspecto (ver Ap endice B). En el caso de la aplicaci on m ovil, en la Figura 4.2 se pueden apreciar las capturas correspondientes, donde cada interfaz est a asociada a una actividad implementada como se detall o en el Cap tulo 3. Adem as, se observan los Widgets desarrollados una vez desplegados en la pantalla de inicio de Android.
57
4.2. RESULTADOS
(a) Presentaci on.
(b)
Datos
de
(c) Men u.
(d) Actuadores.
conexi on.
(e) Horarios.
(f) Di alogo de hora.
(g) Sensores.
(h) Perles.
(i) Reproductor.
(j) Di alogo de ingreso de lista.
(k) Widgets.
Fig. 4.2: Capturas de la aplicaci on m ovil desarrollada. 58
4.2. RESULTADOS
Por otro lado, para comprobar el correcto funcionamiento de la aplicaci on se utiliza una aplicaci on externa (logcat ) que guarda un registro de todos los eventos en el dispositivo m ovil. As , a continuaci on se tienen dos ejemplos que prueban el funcionamiento del mismo. En el primero, se tiene un registro que indica una conexi on exitosa al servidor, realizada en la actividad de conexi on tras haber navegado por la actividad de presentaci on. Luego, una vez establecida la conexi on se despliega la interfaz correspondiente a la actividad del men u de opciones. En este caso, la opci on seleccionada es la ejecuci on manual de actuadores, por lo que el registro muestra el despliegue de la interfaz asociada a esta actividad precedida por la ejecuci on remota del comando que desactiva los sensores de luminosidad y temperatura. Una vez desplegada esta interfaz, se presionan los botones correspondientes para encender los artefactos asociados a los actuadores de la red, es decir, la l ampara, el ventilador y la cafetera. Finalmente se regresa hasta la interfaz de presentaci on, nalizando la conexi on. El registro se puede ver a continuaci on, indicando en color rojo la conexi on al servidor y los comandos remotos ejecutados desde la aplicaci on m ovil.
16:37:09.890 I/ActivityManager(560): START act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=net.wsnhome/.PresentationActivity u=0 from pid 756 16:37:10.089 I/ActivityManager(560): Start proc net.wsnhome for activity net.wsnhome/.PresentationActivity: pid=26896 uid=10030 gids=3003, 1028 16:37:11.312 I/ActivityManager(560): Displayed net.wsnhome/.PresentationActivity: +1s319ms 16:37:12.312 I/ActivityManager(560): START cmp=net.wsnhome/.ConnectionActivity u=0 from pid 26896 16:37:13.308 I/ActivityManager(560): Displayed net.wsnhome/.ConnectionActivity: +963ms 16:37:21.898 I/logs (26896): Conexi on exitosa
16:37:21.898 I/ActivityManager(560): START cmp=net.wsnhome/.OptionsActivity u=0 from pid 26896 16:37:22.320 I/ActivityManager(560): Displayed net.wsnhome/.OptionsActivity: +364ms 16:37:27.394 I/logs (26896): Comandos remotos ejecutados para apagar sensores
16:37:27.402 I/ActivityManager(560): START cmp=net.wsnhome/.ManualActivity u=0 from pid 26896 16:37:27.761 I/ActivityManager(560): Displayed net.wsnhome/.ManualActivity: +301ms 16:37:34.070 I/logs 16:37:36.101 I/logs 16:37:38.722 I/logs (26896): Comando remoto para encender l ampara ejecutado (26896): Comando remoto para encender ventilador ejecutado (26896): Comando remoto para encender cafetera ejecutado
16:37:40.750 I/ActivityManager(560): START cmp=net.wsnhome/.OptionsActivity u=0 from pid 26896 16:37:41.066 I/ActivityManager(560): Displayed net.wsnhome/.OptionsActivity: +272ms 16:37:42.621 I/ActivityManager(560): START cmp=net.wsnhome/.ConnectionActivity u=0 from pid 26896 16:37:42.808 I/ActivityManager(560): Displayed net.wsnhome/.ConnectionActivity: +152ms 16:37:46.488 I/ActivityManager(560): START cmp=net.wsnhome/.PresentationActivity u=0 from pid 26896
De la misma forma en el servidor se registra que efectivamente se hayan ejecutado los scripts correspondientes a cada comando remoto ejecutado en el dispositivo m ovil1 . Utilizando el mismo
1
Para registrar lo realizado en una sesi on SSH se ha utilizado el software Snoopy logger, el cual funciona de
forma completamente transparente al usuario y sus aplicaciones.
59
4.2. RESULTADOS
ejemplo, se observa el inicio de sesi on con la IP y nombre de usuario correspondientes, la ejecuci on de los scripts y el cierre de sesi on.
16:37:22 fmaltes-laptop sshd[5181]: pam_sm_authenticate: Called 16:37:22 fmaltes-laptop sshd[5181]: pam_sm_authenticate: username = [wsnserver] 16:37:22 fmaltes-laptop sshd[5181]: Accepted password for wsnserver from 192.168.1.101 port 42217 ssh2 16:37:22 fmaltes-laptop sshd[5181]: pam_unix(sshd:session): session opened for user wsnserver by (uid=0) 16:37:27 fmaltes-laptop snoopy[5295]: [uid:1001 sid:5295 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/sensortempoff.py 16:37:27 fmaltes-laptop snoopy[5295]: [uid:1001 sid:5295 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/sensortempoff.py]: codigos_memoria/sensores_y_actuadores/sensortempoff.py 16:37:27 fmaltes-laptop snoopy[5296]: [uid:1001 sid:5296 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/sensorluzoff.py 16:37:27 fmaltes-laptop snoopy[5296]: [uid:1001 sid:5296 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/sensorluzoff.py]: codigos_memoria/sensores_y_actuadores/sensorluzoff.py 16:37:34 fmaltes-laptop snoopy[5297]: [uid:1001 sid:5297 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/lamparaon.py 16:37:34 fmaltes-laptop snoopy[5297]: [uid:1001 sid:5297 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/lamparaon.py]: codigos_memoria/sensores_y_actuadores/lamparaon.py 16:37:36 fmaltes-laptop snoopy[5298]: [uid:1001 sid:5298 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/ventiladoron.py 16:37:36 fmaltes-laptop snoopy[5298]: [uid:1001 sid:5298 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/ventiladoron.py]: codigos_memoria/sensores_y_actuadores/ventiladoron.py 16:37:38 fmaltes-laptop snoopy[5299]: [uid:1001 sid:5299 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/cafeteraon.py 16:37:38 fmaltes-laptop snoopy[5299]: [uid:1001 sid:5299 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/cafeteraon.py]: codigos_memoria/sensores_y_actuadores/cafeteraon.py 16:37:43 fmaltes-laptop sshd[5293]: Received disconnect from 192.168.1.101: 11: Closed due to user request. 16:37:43 fmaltes-laptop sshd[5181]: pam_unix(sshd:session): session closed for user wsnserver
Como segundo ejemplo se tiene la conguraci on de umbrales en los sensores, actividad fundamental dentro de la aplicaci on. Al igual que en el ejemplo anterior en el dispositivo se registra el procedimiento realizado, donde se observa la conexi on al servidor, la ejecuci on de un comando remoto para obtener la temperatura medida por los sensores inmediatamente tras haber ingresado a la interfaz de conguraci on de umbrales, y la ejecuci on de comandos remotos activando los sensores de temperatura y luminosidad adem as de establecer los umbrales correspondientes. El registro se observa a continuaci on.
60
4.2. RESULTADOS
21:38:04.304 I/ActivityManager(559): START act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=net.wsnhome/.PresentationActivity u=0 from pid 768 21:38:04.421 I/ActivityManager(559): Start proc net.wsnhome for activity net.wsnhome/.ConnectionActivity: pid=12342 uid=10030 gids=3003, 1028 21:38:06.046 I/ActivityManager(559): Displayed net.wsnhome/.ConnectionActivity: +1s638ms 21:38:16.062 I/logs (12342): Conexi on exitosa
21:38:16.066 I/ActivityManager(559): START cmp=net.wsnhome/.OptionsActivity u=0 from pid 12342 21:38:16.378 I/ActivityManager(559): Displayed net.wsnhome/.OptionsActivity: +277ms 21:38:23.621 I/ActivityManager(559): START cmp=net.wsnhome/.SensorsActivity u=0 from pid 12342 21:38:24.003 I/logs (12342): Se ha ejecutado comando remoto obteniendo temperatura de los sensores
21:38:24.121 I/ActivityManager(559): Displayed net.wsnhome/.SensorsActivity: +475ms 21:38:48.070 I/logs 21:38:54.324 I/logs (12342): Se han ejecutado comandos remotos activando sensores y seteando umbral de luminosidad (12342): Se han ejecutado comandos remotos activando sensores y seteando umbral de temperatura
21:39:02.332 I/ActivityManager(559): START cmp=net.wsnhome/.OptionsActivity u=0 from pid 12342 21:39:02.578 I/ActivityManager(559): Displayed net.wsnhome/.OptionsActivity: +212ms 21:39:06.980 I/ActivityManager(559): START cmp=net.wsnhome/.ConnectionActivity u=0 from pid 12342 21:39:07.332 I/ActivityManager(559): Displayed net.wsnhome/.ConnectionActivity: +321ms 21:39:11.023 I/ActivityManager(559): START cmp=net.wsnhome/.PresentationActivity u=0 from pid 12342 21:39:11.332 I/ActivityManager(559): Displayed net.wsnhome/.PresentationActivity: +269ms
Finalmente, al igual que en el caso anterior, se tiene el registro en el servidor que comprueba que se ha establecido una conexi on exitosa desde el dispositivo m ovil, adem as de la ejecuci on de los scripts correspondientes desde la aplicaci on. El registro se puede observar a continuaci on.
21:38:15 fmaltes-laptop sshd[3163]: pam_sm_authenticate: Called 21:38:15 fmaltes-laptop sshd[3163]: pam_sm_authenticate: username = [wsnserver] 21:38:15 fmaltes-laptop sshd[3163]: Accepted password for wsnserver from 192.168.2.9 port 36691 ssh2 21:38:15 fmaltes-laptop sshd[3163]: pam_unix(sshd:session): session opened for user wsnserver by (uid=0) 21:38:23 fmaltes-laptop snoopy[3275]: [uid:1001 sid:3275 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/obtenertemp.py 21:38:23 fmaltes-laptop snoopy[3275]: [uid:1001 sid:3275 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/obtenertemp.py]: codigos_memoria/sensores_y_actuadores/obtenertemp.py 21:38:48 fmaltes-laptop snoopy[3276]: [uid:1001 sid:3277 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/sensorluzon.py 21:38:48 fmaltes-laptop snoopy[3276]: [uid:1001 sid:3277 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/sensorluzon.py]: codigos_memoria/sensores_y_actuadores/sensorluzon.py 21:38:48 fmaltes-laptop snoopy[3277]: [uid:1001 sid:3277 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/umbral_de_luminosidad/luz2.py 21:38:48 fmaltes-laptop snoopy[3277]: [uid:1001 sid:3277 tty: cwd:/home/wsnserver filename:codigos_memoria/umbral_de_luminosidad/luz2.py]: codigos_memoria/umbral_de_luminosidad/luz2.py 21:38:52 fmaltes-laptop snoopy[3278]: [uid:1001 sid:3279 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/sensores_y_actuadores/sensortempon.py 21:38:52 fmaltes-laptop snoopy[3278]: [uid:1001 sid:3279 tty: cwd:/home/wsnserver filename:codigos_memoria/sensores_y_actuadores/sensortempon.py]: codigos_memoria/sensores_y_actuadores/sensortempon.py 21:38:53 fmaltes-laptop snoopy[3279]: [uid:1001 sid:3279 tty: cwd:/home/wsnserver filename:/bin/bash]: bash -c codigos_memoria/umbral_de_temperatura/26.py 21:38:53 fmaltes-laptop snoopy[3279]: [uid:1001 sid:3279 tty: cwd:/home/wsnserver filename:codigos_memoria/umbral_de_temperatura/26.py]: codigos_memoria/umbral_de_temperatura/26.py 21:39:06 fmaltes-laptop sshd[3274]: Received disconnect from 192.168.2.9: 11: Closed due to user request. 21:39:06 fmaltes-laptop sshd[3163]: pam_unix(sshd:session): session closed for user wsnserver
61
4.3. CONSUMO ENERGETICO
4.3.
An alisis del consumo energ etico en nodos nales alimentados por bater as
Considerando que el sistema est a compuesto por dos nodos nales encargados de realizar la tarea fundamental de sensar temperatura con una tasa de muestreo ja y alimentados por bater as (ver Figura 3.17), es importante que la vida u til de estas sea la mayor posible y as mejorar la autonom a del sistema y reducir costos en el mantenimiento de la red, por lo que es necesario determinar el consumo de los nodos y estimar su vida u til de acuerdo a distintos par ametros que se exponen en este apartado. En primer lugar se determina el consumo de cada nodo considerando los tres estados por los que se encuentra durante un ciclo de trabajo, es decir cuando duerme, cuando transmite un frame y cuando est a en estado de reposo (no duerme, no recibe ni transmite). Acorde a lo mencionado, el consumo del nodo est a dado por: IIdle tIdle + IT x tT x + ISleep tSleep , tIdle + tT x + tSleep
I=
(4.1)
donde tIdle , tT x y tSleep se reeren al porcentaje del ciclo de trabajo en que el nodo se encuentra en estos estados. Por lo tanto, se tiene:
tIdle + tT x + tSleep = 1
(4.2)
Por otro lado, el consumo de los nodos en cada uno de estos estados depende del m odulo utilizado. Para efectos de an alisis, se utilizan los m odulos Xbee y Xbee-Pro, los cuales tienen diferencias en su potencia de transmisi on, consumo y alcance, entre otras caracter sticas (ver Ap endice A). Para medir el consumo de los nodos en modos Idle y Sleep basta con utilizar un mult metro, mientras que en modo de transmisi on, debido al corto tiempo en que el nodo env a un frame (en el orden de los milisegundos), es necesario utilizar los valores nominales entregados por el fabricante. La Tabla 4.1 especica el consumo en los nodos utilizados. Es importante se nalar que al hacer referencia al consumo del nodo, este no s olo involucra al m odulo RF, sino tambi en al sensor de temperatura que como bien se se nal o en la Secci on 3.4.3
62
Tabla 4.1: Consumo de nodos nales para distintos estados.

Tipo de m odulo Xbee Xbee Xbee-Pro Modo Idle (IIdle ) 9.35 [mA] 16.73 [mA] Modo Sleep (ISleep ) 110.6 [A] 116.1 [A] Modo de transmisi on (IT x ) 40 [mA] 170 [mA]
corresponde al sensor LM35, el cual seg un datos del fabricante su consumo es menor a 60 [A]. En la Secci on 3.4.3 se establecieron par ametros en la conguraci on de los nodos nales con el n de determinar el tiempo en que duermen y se mantienen despiertos, los cuales tienen relaci on directa con tSleep y tIdle . En estricto rigor, SP determina el tiempo en que el nodo duerme en cada ciclo mientras que ST determina el tiempo en que el nodo se mantiene despierto, una vez que se haya enviado el sample correspondiente de temperatura al coordinador, hasta que vuelve a dormir. En el caso del tiempo en que el nodo transmite un frame, este depende de la cantidad de bytes enviados, siendo 21 bytes los que se env an al coordinador al enviar un sample de temperatura. Seg un el fabricante de los m odulos Xbee, Digi R , a un m odulo le toma 3.94 [ms] enviar un frame con 21 bytes. De acuerdo a lo anterior, no es necesario realizar el presente an alisis en funci on de la variaci on de tT x ya que este depende directamente del tiempo en que demora el m odulo en enviar un frame y como ya se mencion o esto en la pr actica no es congurable. Por otro lado, el sistema implementado est a dise nado para enviar un solo sample de temperatura una vez que el m odulo despierta, por lo que incrementar este tiempo mediante el par ametro ST solo mantendr a el m odulo despierto por m as tiempo pero sin enviar m as samples, por lo que se malgasta energ a. De esta forma, la variable a manipular en el presente an alisis es el par ametro SP el cual determina el tiempo en que duerme el m odulo. Finalmente, ST se ha mantenido jo con un valor de 150 [ms], tal como se especic o en la Secci on 3.4.3. La Figura 4.3 ilustra el consumo promedio de los nodos sensores, ya sea utilizando el m odulo Xbee o Xbee-pro.
63
Fig. 4.3: Consumo promedio del nodo nal en funci on del porcentaje del ciclo de trabajo en que duerme el m odulo. Se puede observar que a mayor porcentaje del ciclo de trabajo en que los m odulos duerman, menor es el consumo. Adem as, teniendo en cuenta que el valor de ST utilizado en este an alisis es de 150 [ms], se observa que si el m odulo duerme m as de 1 minuto no se obtienen importantes reducciones en el consumo. Es decir, si el m odulo duerme 5, 10 o 30 minutos los resultados obtenidos ser an similares ya que se ha alcanzado un porcentaje del ciclo de trabajo en que los m odulos duermen mayor al 99 %. Finalmente, comparando los m odulos Xbee y Xbee-pro se observa que s olo se obtienen diferencias signicativas con valores bajos de tSleep , ya que la gran diferencia en t erminos de consumo entre estos 2 m odulos es cuando el m odulo transmite (ver Tabla 4.1), por lo que mientras mayor es tSleep menos signicativa es esta diferencia. De acuerdo al sistema implementado, ya que los nodos nales sensan temperatura no es necesario que la tasa de muestreo sea muy alta. Sensar temperatura cada 5, 15 o incluso 30 minutos es una buena elecci on dependiendo del ambiente espec co en el cual se implementa el sistema. Acorde a lo anterior, es importante estimar la capacidad de la bater a a utilizar en los nodos nales para diferentes escenarios de vida u til de los nodos. La Figura 4.4 muestra esta
64
estimaci on utilizando el m odulo Xbee.
Fig. 4.4: Capacidad estimada de la bater a en funci on del porcentaje del ciclo de trabajo en que duerme el m odulo Xbee. Se observa que si se tiene como objetivo que los sensores duren 6 meses, se necesita una bater a entre 500 y 1000 [mAh] de capacidad dependiendo del porcentaje del ciclo de trabajo en que dormir an los sensores. Pilas alcalinas AAA tienen esta capacidad. En el caso de que se requiera que los sensores tengan una vida u til de 1 a no se necesita una bater a entre 1000 y 2000 [mAh] de capacidad, con lo que bastar a utilizar pilas alcalinas AA. Para el resto de curvas se observa que se necesitan bater as con capacidades m as altas. Bater as de litio-ion o pilas alcalinas conectadas en paralelo pueden lograr este prop osito. La Figura 4.5 ilustra, al igual que en el caso anterior, la estimaci on de la capacidad de la bater a a necesitar seg un la vida u til que se necesita en los nodos, pero en este caso utilizando un m odulo Xbee-pro.
65
Fig. 4.5: Capacidad estimada de la bater a en funci on del porcentaje del ciclo de trabajo en que duerme el m odulo Xbee-Pro. Como es de esperar, al utilizar un m odulo Xbee-pro el consumo es mayor y por ende la capacidad de la bater a a necesitar tambi en es mayor. Sin embargo, a valores de tSleep cercanos al 100 %, con valores de SP alrededor de los 20 minutos, esta diferencia se ve altamente reducida ya que como se ha explicado la mayor diferencia en consumo entre ambos m odulos se produce con valores de tSleep bajos. Es importante se nalar que el an alisis anterior no considera como factor el voltaje de operaci on de los m odulos y el del sensor de temperatura por lo que el ideal es seleccionar una bater a que se descargue completamente hasta dejar de alimentar los sensores. El m odulo Xbee trabaja en un rango de 2.1 - 3.6 [V] mientras que el m odulo Xbee-pro en un rango de 2.8 - 3.4 [V]. El sensor de temperatura LM35 por su parte opera con un voltaje m nimo de 2.9 [V]. Lo anterior quiere decir que acorde el sistema implementado al alimentar los nodos nales mediante 2 pilas alcalinas AA conectadas en serie como se mencion o en la Secci on 3.4.3, el sensor de temperatura dejar a de operar correctamente una vez que las pilas dejen de entregar 2.9 [V] al sensor. Considerando
66
que 2 pilas alcalinas AA nuevas conectadas en serie proveen de 3.25 [V] al nodo, esto implica que cuando el sensor deje de funcionar las pilas a un tendr an carga. Duracell R provee de un datasheet en el cual se muestra una curva que relaciona las horas de servicio de una pila alcalina AA en funci on de la descarga de corriente promedio de la aplicaci on para un voltaje de corte dado en el cual se considera la pila descargada, tal como se puede apreciar en la Figura 4.6.
Fig. 4.6: Descarga de corriente constante t pica en una pila alcalina AA Duracell [31]. Considerando la curva mostrada en la Figura 4.6, esta se puede replicar con el n de obtener una estimaci on del tiempo de servicio del nodo nal en funci on del consumo promedio del mismo, utilizando como voltaje de corte 1.45 [V] el cual es el voltaje m nimo con el que opera el sensor de temperatura (en estricto rigor 2.9 [V] al utilizar 2 pilas en serie). As , teniendo esto en consideraci on y el bajo consumo de los m odulos Xbee, se puede interpolar la curva deseada con el n de obtener lo datos necesarios en el rango menor a los 5 [mA] de consumo. La Figura 4.7 muestra la vida u til del nodo nal en funci on del consumo del nodo utilizando el m odulo Xbee o Xbee-Pro. En el caso del m odulo Xbee, se puede observar que reduciendo el consumo del nodo al m nimo se puede obtener una vida u til de un poco m as de 10 meses, esto es con un consumo de un poco m as de 110 [A] que corresponde a un tSleep cercano al 100 %. Con la conguraci on establecida
67
Fig. 4.7: Vida u til del nodo nal utilizando dos pilas alcalinas AA en serie. en el dise no esto corresponde a que el nodo duerma m as de 5 minutos en cada ciclo de trabajo. Por otro lado, en el caso del m odulo Xbee-Pro se observa que para valores de tSleep altos el consumo del nodo es similar al caso del m odulo Xbee, obteniendo una vida u til de alrededor de 10 meses. Con la conguraci on especicada en el dise no en que el m odulo duerme 5 minutos en cada ciclo de trabajo se tiene una vida u til de alrededor de 9 meses, algo menor que en el caso del m odulo Xbee. Es importante se nalar que la vida u til del nodo se puede incrementar con conexiones de pilas en paralelo. Por ejemplo en este caso al utilizar un par de pilas AA en paralelo a las que ya alimentan el nodo se puede duplicar la vida u til del mismo, obteniendo un resultado de alrededor de 20 meses. Finalmente, si bien haber interpolado la curva mostrada en la Figura 4.6 con el n de obtener una estimaci on de la vida u til de los nodos es una opci on v alida, es importante considerar como peor escenario el caso en que la vida u til m axima de las bater as est e dada por el valor mostrado al tener un consumo promedio de 5 [mA], manteni endose constante en el rango inferior a este
68
valor. Esto indica que con un consumo menor o igual a los 5 [mA] no hay un aumento en la vida u til de los nodos, independiente del tiempo en que estos duerman en un ciclo de trabajo. Teniendo esto en consideraci on, al considerar como voltaje de corte 1.45 [V] al igual que en la estimaci on anterior, se obtiene una duraci on m axima de los nodos de alrededor de 325 horas (entre 13 y 14 d as), sin importar si se utiliza el m odulo Xbee o Xbee-Pro.
69
Cap tulo 5 Conclusiones

5.1. Conclusiones
La aplicaci on m ovil creada, gracias al SDK de Android, la biblioteca Orion SSH2 para Java y la alta documentaci on existente, cumple con todos los objetivos planteados, ya que a trav es de la aplicaci on se puede controlar un ambiente cerrado a trav es de una RdSI. El SDK de Android permiti o el desarrollo de una interfaz gr aca simple en la que el usuario puede realizar cada tarea de forma intuitiva. La RdSI implementada se basa en dos elementos fundamentales: los m odulos Xbee y la placa Arduino. Estos componentes mostraron una perfecta integraci on para formar la RdSI, espec camente en el caso del nodo coordinador de la red donde el m odulo Xbee recibe las muestras de temperatura y luminosidad de los nodos nales y el Arduino se encarga de procesarlas. Respecto a la escalibilidad de la red, debido a la utilizaci on del est andar ZigBee por parte de los m odulos Xbee, el nodo coordinador integra autom aticamente nuevos nodos a la red, agreg andolos a su tabla de nodos hijos. Sin embargo, es necesario manipular el c odigo del Arduino para integrar completamente un nuevo nodo, ya que este debe saber a trav es de la direcci on MAC del m odulo Xbee si los datos recibidos corresponden a muestras de temperatura, luminosidad u otro tipo de sensor integrado a la red. Por otro lado, dentro de los objetivos establecidos se tiene que la RdSI debe ser de bajo costo. Esto se ha cumplido a cabalidad ya que el costo de los nodos alimentados por bater as
70
5.1. CONCLUSIONES
CAP ITULO 5. CONCLUSIONES
no supera los CLP$20.000 en el caso de utilizar un m odulo Xbee y CLP$30.000 al utilizar un m odulo Xbee-pro. En el caso de los nodos actuadores el costo es ligeramente mayor debido a los componentes electr onicos que este posee, pero a un utilizando los m odulos Xbee-pro no supera los CLP$35.000. Para el caso del nodo coordinador, debido a la integraci on de la plataforma Arduino su costo se eleva a los CLP$30.000 en el caso de utilizar el m odulo Xbee y CLP$40.000 al utilizar el Xbee-pro. Adem as, siguiendo la misma l nea, la aplicaci on m ovil puede ser utilizada por un dispositivo m ovil de gama baja, los cuales hoy en d a se encuentran alrededor de los CLP$50.000. Respecto al consumo de los nodos nales alimentados por bater as, debido a que los nodos solo est an compuestos por el sensor de temperatura y el m odulo Xbee, sin reguladores de voltaje ni otro elemento de por medio en su alimentaci on, su consumo es m nimo. Los nodos pueden llegar a consumir alrededor de 110 [A] cuando duermen lo que implica una vida u til de meses e incluso a nos seg un el tipo de bater as utilizadas en su alimentaci on. En el caso espec co del tipo de alimentaci on utilizado en este trabajo para la implementaci on del sistema (2 pilas alcalinas AA conectadas en serie) se determin o que la duraci on m axima de los nodos es de 10 meses debido al voltaje de operaci on del sensor de temperatura. Lo anterior implica que el nodo dejar a de funcionar cuando las bater as a un tienen carga en su interior, por lo que se sugiere utilizar otro m etodo de alimentaci on que aproveche toda la carga de las bater as manteniendo el bajo consumo de los nodos. En caso de querer aumentar la vida u til de los nodos manteniendo el mismo m etodo de alimentaci on se sugiere utilizar otro par de pilas alcalinas conectadas en paralelo, lo que duplicar a la vida u til de los nodos. Finalmente, se determin o que independiente del m odulo Xbee utilizado (Xbee o Xbee-pro), si el nodo est a congurado para que duerma la mayor parte del tiempo en un ciclo de trabajo, con valores sobre el 99 %, el consumo del nodo ser a similar ya que su mayor diferencia en consumo radica cuando el m odulo est a transmitiendo datos. Finalmente, si bien el sistema implementado no posee todos los elementos que posee un sistema dom otico actual, como puede ser monitoreo de video a distancia, alarmas y reguladores de intensidad de iluminaci on; debido a los puntos reci en expuestos el sistema es ideal en aplicaciones donde el bajo costo en la implementaci on y mantenimiento de la red es un requisito. Adem as, debido a que se utiliza el protocolo SSH para la interacci on entre el dispositivo m ovil y
71
5.2. TRABAJO FUTURO
la RdSI, al crear una red WLAN en el sistema no es necesaria la conexi on a Internet, por lo que el sistema propuesto se convierte en una excelente alternativa en ambientes rurales donde Internet es de dif cil acceso, como pueden ser invernaderos que necesitan de un monitoreo constante de temperatura.
5.2.
Trabajo futuro
De acuerdo al sistema presentado en este trabajo, se desprenden ciertos aspectos en los cuales se podr a mejorar con el n de crear un sistema m as completo y con mayor funcionalidad, los cuales se exponen a continuaci on: De la misma forma en que el dispositivo m ovil recibe la temperatura promedio del ambiente a trav es del Arduino, puede recibir una noticaci on debido a un mal funcionamiento de alg un nodo en la red, ya sea por deciencia en las bater as u otro motivo. Una forma simple de implementar esto es registrando en el Arduino la u ltima vez en que se recibi o un frame de cada nodo y este tiempo poder ser enviado al dispositivo m ovil. Optimizar el rendimiento energ etico de los nodos nales, ya sea utilizando bater as de litio-i on de mayor capacidad o utilizando un sensor de temperatura con un voltaje de operaci on m as bajo que el utilizado en el sistema desarrollado en este trabajo. Integrar m as sensores a la RdSI. Dependiendo del ambiente que se quiere controlar, se pueden integrar sensores de humedad, gases, movimiento, etc. Mejorar el sistema de perles. En el sistema desarrollado cada usuario puede establecer preferencias dentro de la aplicaci on m ovil las que una vez guardadas pueden ser ejecutadas posteriormente ignorando si otro usuario dentro de la misma red ha ejecutado recientemente otras preferencias, por lo que que el sistema siempre ejecutar a la u ltima conguraci on seleccionada. Una forma de solucionar esto puede ser implementando un sistema de perles en el servidor, registrando las preferencias de cada usuario y por ejemplo establecer valores promedio entre cada perl en la red.
72
5.2. TRABAJO FUTURO
Utilizar otra topolog a en la red. Una de las limitaciones en la topolog a estrella utilizada en el sistema desarrollado es que el alcance de la red est a limitado por el rango de alcance entre el nodo coordinador y los nodos nales. Utilizar una topolog a mesh puede solucionar este problema gracias a la propiedad multi-hop en la cual la informaci on pasa entre nodo y nodo hasta llegar al nodo destino. Exportar la aplicaci on m ovil a otros sistemas operativos. Si bien Android es el S.O. m as utilizado en la actualidad, esta tendencia puede cambiar por lo que es importante estudiar su desarrollo en otros sistemas como Windows Phone, iOS o mejor a un desarrollar una aplicaci on multi plataforma.
73
Bibliograf a
[1] DomoWeb, La p agina esencial sobre la dom otica. [Online] Disponible en: http://www2. udec.cl/~carlosalvial/domotica/pages/que_es.htm [2] Sitio web de Dom otica Chile. An alisis del ruido el ectrico en tecnolog as X-10. [Online]. Disponible en: http://www.domoticachile.org/index.php?option=com_content&view= article&id=55:ruido&catid=44:teoria&Itemid=61 [3] Renzo Bertuzzi et al., Automatizaci on del hogar utilizando el protocolo de comunicaci on X-10, Escuela de Ingenier a Civil en Inform atica, Universidad Austral de Chile, Valdivia, 2004. [Online]. Disponible en: http://www.domoticachile.org/index.php?option=com_ docman&task=cat_view&Itemid=57&gid=41 [4] Lorena Aguirre Solvez, Estudio de una red de sensores sin hilos basada en la tecnolog a Arduino bajo protocolos de comunicaciones Zigbee, informe de memoria de t tulo de Ingenier a T ecnica de Telecomunicaciones especialidad Sistemas de Telecomunicaci on, Universidad Polit ecnica de Catalunya, Espa na, 2009. [5] Belatrix Software Factory BSF S.A. (2008). Documento de investigaci on sobre el an alisis de las caracter sticas de los dispositivos m oviles inteligentes (Smart phones). [Online]. Disponible en: http://www.belatrixsf.com/downloads/Belatrix_PlataformasMoviles_SP.pdf [6] Area de Ingenier a de Sistemas y Autom atica, Universidad de Oviedo (2009). Redes para los edicios y la industria. Dom otica e ingenier a ambiental. Tema 7: Buses y protocolos en dom otica e inm otica. [Online]. Disponible en: http://isa.uniovi.es/~sirgo/doctorado/ UD7.pdf
74
BIBLIOGRAF IA
BIBLIOGRAF IA
[7] IDC Worldwide Quarterly Mobile Phone Tracker (2012): World-wide Smartphone Market Expected. [Online]. Disponible en: http://www.idc.com/getdoc.jsp?containerId= prUS23523812 [8] Z-Wave: The New Standard in Wireless Remote Control. [Online]. Disponible en: http: //www.z-wave.com/modules/AboutZ-Wave/ [9] Sitio web de Sidco Chile. [Online] Disponible en: http://www.sidco.cl/ [10] Area de Ingenier a de Sistemas y Autom atica, Universidad de Oviedo. Automatizaci on integral de edicios. Principales sistemas dom oticos/inm oticos: Sistema Lonworks. [Online]. Disponible en: http://isa.uniovi.es/docencia/AutomEdificios/transparencias/ Lonworks.pdf [11] Sistema de Dom otica Solidmation. Arquitectura del sistema [Online]. Disponible en: http://www.solidmation.com/domotica-arquitectura.shtml [12] Sourceforge.net. Orion SSH2 library for Java. [Online] Disponible en: http:// sourceforge.net/apps/mediawiki/orion-ssh2/index.php?title=Main_Page [13] Sitio web de Arduino. [Online]. Disponible en: http://www.arduino.cc [14] Sitio web de Arduino - Introducci on. [Online]. Disponible en: http://arduino.cc/es/ Guide/Introduction [15] Sitio web de Arduino - Hardware. [Online]. Disponible en: http://arduino.cc/en/Main/ Hardware [16] Sitio web de Arduino: Arduino Uno. [Online]. Disponible en: http://arduino.cc/en/ Main/ArduinoBoardUno [17] Sitio web de moc. [Online]. Disponible en: http://moc.daper.net [18] Lorena Aguirre Solvez, Estudio de una red de sensores sin hilos basada en la tecnolog a Arduino bajo protocolos de comunicaciones Zigbee, informe de memoria de t tulo de
75
BIBLIOGRAF IA
BIBLIOGRAF IA
Ingenier a T ecnica de Telecomunicaciones especialidad Sistemas de Telecomunicaci on, Universidad Polit ecnica de Catalunya, Espa na, 2009. [19] I.F. Akyildiz et al., Wireless sensor networks: a survey, Computer Networks, 38 (2002), p aginas 393-422. [20] Harvard Sensor Networks Labs: Volcano Monitoring. [Online]. Disponible en: http://fiji. eecs.harvard.edu/Volcano [21] Luis Felipe Falconi Cepeda y Carlos Ramiro Jimenez Yedra, Estudio e implementaci on de dom otica activado por comandos de voz y comunicaci on en ZigBee, informe de memoria de t tulo de Ingenier a en Electr onica y Computaci on, Facultad de Inform atica y Electr onica, Escuela Superior Polit ecnica de Chimborazo, Riobamba, Ecuador, 2009. [22] Mobile and Wireless communication systems: Wireless communication technologies. [Online]. Disponible en: http://wireless.arcada.fi/MOBWI/material/PAN_5_4.html [23] Robert Faludi, Building Wireless Sensor Networks, Primera Edici on, OReilly Media, Inc., 2010. [24] Product Manual: Xbee/Xbee-PRO ZB RF Modules. [Online]. Disponible en: http: //www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/ zigbee-mesh-module/xbee-zb-module#docs [25] Gizmodo.com - Android 2.2 Froyo Review [Online]. Disponible en: http://gizmodo.com/ 5549260/android-22-review [26] Sitio web ocial para desarrolladores de Android: Activities. [Online]. Disponible en: http://developer.android.com/guide/components/activities.html [27] Sitio web ocial para desarrolladores de Android: Services. [Online]. Disponible en: http: //developer.android.com/guide/components/services.html [28] Reto Meier, Getting started, Professional Android 2 Application development, Primera Edici on, Wiley Publishing, Inc., 2010, Cap tulo 2, p aginas 17-48.
76
BIBLIOGRAF IA
BIBLIOGRAF IA
[29] Sitio web ocial para desarrolladores de Android: Application Fundamentals. [Online]. Disponible en: http://developer.android.com/guide/topics/fundamentals.html [30] Digi application note. Xbee and Xbee-Pro OEM RF Module Antenna Considerations. [Online]. Disponible en: ftp1.digi.com/support/images/XST-AN019a_XBeeAntennas.pdf [31] Duracell Coppertop MN1500 Datasheet. [Online] Disponible en: http://www.duracell. com/en-US/Global-Technical-Content-Library/Product-Data-Sheets.jspx
77
Ap endice A Especicaciones m odulos RF Xbee y Xbee-Pro

Tabla A.1: Desempe no m odulos Xbee y Xbee-Pro [24].
Especicaci on Alcance Indoor Alcance Outdoor (l nea de vista) Potencia de transmisi on Xbee hasta 40 [m] hasta 120 [m] 2 [mW] (+3 [dBm]) en modo boost habilitado 1.25 [mW] (+1 [dBm]) en modo boost deshabilitado Tasa de transferencia (Data Rate ) RF Tasa de transferencia en interfaz serial Sensibilidad del receptor (Receiver Sensitivity ) 250,000 [bps] 1200 [bps] - 1 [Mbps] -96 [dBm] en modo boost habilitado -95 [dBm] en modo boost deshabilitado 250,000 [bps] 1200 [bps] - 1 [Mbps] -102 [dBm] Xbee-Pro hasta 90 [m] hasta 1500 [m] 10 [mW] (+10 [dBm])
Tabla A.2: Requerimientos de potencia m odulos Xbee y Xbee-Pro [24].

Especicaci on Voltaje de alimentaci on Corriente de operaci on (transmitiendo, m axima potencia a la salida) Corriente de operaci on (recibiendo) Corriente en reposo (Idle, receptor apagado) Corriente en modo sleep Xbee 2.1 - 3.6 [V] 40 [mA] (@3.3 [V]) en modo boost habilitado 35 [mA] (@3.3 [V]) en modo boost deshabilitado 40 [mA] (@3.3 [V]) en modo boost habilitado 38 [mA] (@3.3 [V]) en modo boost deshabilitado 15 [mA] < 1 [A] @25 [C] 15 [mA] 3.5 [A] @25 [C] 40 [mA] (@3.3 [V]) Xbee-Pro 2.8 - 3.4 [V] 170 [mA] (@3.3 [V])
78
Ap endice B Consideraciones en las antenas de los m odulos RF Xbee y Xbee-Pro.

Digi R provee un documento en el cual se analiza el desempe no de los m odulos Xbee y XbeePro, comparando sus distintas antenas en escenarios de ambientes interiores como exteriores [30]. Las pruebas para el alcance en interiores fueron llevadas a cabo en el interior de un edicio de ocinas y en el interior de un almac en con pasillos de estanter as. Las pruebas en exteriores se realizaron en un parque rodeado de edicios, a rboles y una zona residencial.
Tanto los m odulos Xbee como Xbee-Pro est an disponibles con una antena whip, PCB, conector RPSMA o conector U.FL (con lo cual se puede conectar una antena externa). El m odulo Xbee puede transmitir hasta con 1 [mW] de potencia, mientras que el Xbee-Pro lo hace hasta con 60 [mW] de potencia. En adici on a la potencia de transmisi on, Xbee-Pro es capaz de recibir se nales m as d ebiles que el Xbee, lo que signica que tiene una mejor sensibilidad de recepci on. De esta forma, ya que el Xbee-Pro posee mejor sensibilidad de recepci on y mayor potencia de transmisi on, puede enviar y recibir informaci on a una distancia mayor. El rango de alcance fu e determinado midiendo la entrega de paquetes de un tranmisor a un receptor. El transmisor se mantuvo en un lugar jo, mientras que el receptor se movi o en distintos puntos. Los lugares en los que se j o el receptor fueron elegidos con el n de que la distancia entre el transmisor y el receptor se fuera incrementando gradualmente hasta que la
79
APENDICE B. CONSIDERACIONES EN LAS ANTENAS DE LOS MODULOS RF
calidad del enlace comenzara a verse afectada. La mayor a de los puntos en los que se j o el receptor en el caso de las mediciones en exteriores fueron en l nea de vista con el transmisor. El transmisor fue programado para transmitir paquetes conteniendo un n umero que fue incrementado con cada paquete (1, 2, 3 y as ...). El receptor (y el laptop asociado) fueron congurados para cuanticar la entrega de paquetes exitosos como un porcentaje del n umero total de paquetes enviados. El transmisor y el receptor fueron iguales, es decir, mismo m odulo y tipo de antena. 99 % de paquetes exitosos entregados fue elegido como referencia de comparaci on. El receptor no entrega conrmaci on al transmisor cuando los paquetes llegan exitosamente. Por otro lado, el transmisor env a cada paquete solo una vez. La Tabla B.1 resume los resultados de la evaluaci on. Las distancias presentadas representan lo que un usuario podr a esperar alcanzar en su aplicaci on1 . Tabla B.1: Desempe no de las antenas en m odulos Xbee y Xbee-Pro para distintos escenarios [30].
M odulo Tipo de antena Distancia Outdoor (L nea de vista) Xbee Chip Whip Xbee-Pro Chip Whip 143 [m] 258 [m] 515 [m] 1335 [m] Distancia Indoor (Edicio de ocinas) 24 [m] 24 [m] 43 [m] 43 [m] Distancia Indoor (Almac en ) 26 [m] 108 [m]
La antena dipolo tambi en fue analizada, entregando resultados similares a la antena whip. Adem as, la antena PCB se comporta dentro del 5 % mejor que la antena whip.
Al analizar la Tabla B.1, se pueden realizar las siguientes observaciones: La antena whip tiene peor alcance en comparaci on con la antena chip, pero solo en exteriores. La antena PCB tiene un desempe no superior en un 5 % a la antena whip
1
Es importante se nalar que el desempe no tambi en depende de varios factores ambientales por lo que los
resultados podr an variar. Dentro de los factores se incluyen: orientaci on de la antena, altura de la antena, proximidad de la antena con otros objetos, arboles, lluvia, nieve, veh culos, etc. Por otro lado, la presencia de otras redes inal ambricas tambi en podr a afectar el desempe no.
80
El Xbee-Pro tiene mejor alcance que el Xbee Tanto el Xbee como el Xbee-Pro tienen mayor alcance en exteriores que en interiores. La antena whip en el m odulo Xbee posee un alcance adicional en aplicaciones en exteriores, sin embargo, tambi en ocupa mayor espacio f sico. Si en la aplicaci on se requiere un gran alcance y el espacio es un factor a considerar, entonces es m as apropiado utilizar un m odulo Xbee-Pro con antena PCB. Por otro lado, si se requiere un gran alcance y el espacio no es un problema, entonces un m odulo Xbee con una antena whip o dipolo puede ser la mejor opci on. Las Figuras B.1, B.2 y B.3 ilustran el patr on de radiaci on de las antenas mencionadas2 . Se puede observar que el patr on de radiaci on de la antena whip es similar al de la antena dipolo, como una dona. En otras palabras, el desempe no de un m odulo utilizando la antena whip es relativamente insensible a su orientaci on en el plano perpendicular a la antena. Por otro lado, el patr on de radiaci on de la antena chip no es tan uniforme como el de la antena whip, por lo tanto, orientaciones espec cas obtendr an un mejor desempe no que otras. En las pruebas, la orientaci on de la antena fu e establecida con el n de obtener el mejor desempe no.
Fig. B.1: Patr on de radiaci on antena dipolo acoplada a un Xbee-Pro.

2
Todos los patrones de radiaci on est an normalizados al peak de la antena dipolo mostrada en la Figura B.1,
con el n de permitir una f acil comparaci on.
81
Fig. B.2: Patr on de radiaci on antena whip acoplada a un Xbee-Pro.
Fig. B.3: Patr on de radiaci on antena chip acoplada a un Xbee-Pro.
82

Control de Ambientes

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Control de Ambientes

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE CONCEPCION FACULTAD DE INGENIER IA DEPARTAMENTO DE INGENIER IA ELECTRICA

Prof. Patrocinante: Jorge E. Pezoa, Ph.D.

Desarrollo de un sistema de control de ambientes mediante una aplicaci on m ovil

Informe de memoria de t tulo para optar al t tulo de Ingeniero Civil en Telecomunicaciones

Concepci on, Chile 11 de enero de 2013

B.3. Patr on de radiaci on antena chip acoplada a un Xbee-Pro . . . . . . . . . . . . .

Lista de acr onimos

Cap tulo 1 Introducci on

1.1. ANTECEDENTES HISTORICOS

CAP ITULO 1. INTRODUCCION

DEL PROBLEMA 1.2. DEFINICION

CAP ITULO 1. INTRODUCCION

Denici on del problema

Estado del arte

International Data Corporation

1.3. ESTADO DEL ARTE

CAP ITULO 1. INTRODUCCION

1.3. ESTADO DEL ARTE

CAP ITULO 1. INTRODUCCION

Fig. 1.1: Est andar Z-wave [8].

Fig. 1.2: Arquitectura del sistema Habeetat de la empresa Solidmation [11].

CAP ITULO 1. INTRODUCCION

Objetivos espec cos

1.5. ALCANCES Y LIMITACIONES

CAP ITULO 1. INTRODUCCION

1.6. ASPECTOS LEGALES

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Cap tulo 2 Marco te orico

Redes de sensores inal ambricos

2.2. REDES DE SENSORES INALAMBRICOS

CAP ITULO 2. MARCO TEORICO

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

El est andar ZigBee

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

2.3. EL ESTANDAR ZIGBEE

CAP ITULO 2. MARCO TEORICO

CAP ITULO 2. MARCO TEORICO

CAP ITULO 2. MARCO TEORICO

(a) Arduino Uno

(b) Arduino Mega ADK

(c) Arduino Lilypad

(d) Arduino Pro Mini

Fig. 2.6: Variantes de una placa Arduino [15].

CAP ITULO 2. MARCO TEORICO

Fig. 2.7: Interfaz gr aca de Android 2.2 [25].

CAP ITULO 2. MARCO TEORICO

Componentes de una aplicaci on

CAP ITULO 2. MARCO TEORICO

CAP ITULO 2. MARCO TEORICO

Cap tulo 3 Dise no e implementaci on

3.2. REQUERIMIENTOS TECNICOS

E IMPLEMENTACION CAP ITULO 3. DISENO

Modulaci on por ancho de pulsos Programador Serial En Chip