propuesta para trabajo de gradopegasus.javeriana.edu.co/~cis1230si02/docs/memoria_de... · web...
TRANSCRIPT
CIS1230SI02COMPUTACIÓN MÓVIL NO INTRUSIVA APLICADA A LA COMUNICACIÓN ENTRE DISPOSITIVOS MÓVILES Y DOMÓTICOS A TRAVÉS DE INTERNET
DANIEL HUMBERTO NOVA VALCÁRCEL
PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMASBOGOTÁ, D.C.
2012
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
CIS1230SI02COMPUTACIÓN MÓVIL NO INTRUSIVA APLICADA A LA COMUNICACIÓN ENTRE DISPOSITIVOS MÓVILES Y DOMÓTICOS A TRAVÉS DE INTERNET
Autor(es):
Daniel Humberto Nova Valcárcel
MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TÍTULO DE INGENIERO DE
SISTEMAS
Director
Juan Pablo Garzón Ruiz
Jurados del Trabajo de Grado
Edgar Enrique Ruiz García
Página web del Trabajo de Grado
http://pegasus.javeriana.edu.co/~CIS1230SI02
PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMASBOGOTÁ, D.C.Diciembre, 2012
Página iPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS
Rector Magnífico
Joaquín Emilio Sánchez García S.J.
Decano Académico Facultad de Ingeniería
Ingeniero Luis David Prieto Martínez
Decano del Medio Universitario Facultad de Ingeniería
Padre Sergio Bernal Restrepo S.J.
Director de la Carrera de Ingeniería de Sistemas
Ingeniero Germán Alberto Chavarro Flórez
Director Departamento de Ingeniería de Sistemas
Ingeniero César Julio Bustacara Medina
Página ii
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Página iiiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Artículo 23 de la Resolución No. 1 de Junio de 1946
“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”
Página iv
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
AGRADECIMIENTOS
Deseo agradecer a mis padres por el gran apoyo y dedicación que he recibido durante estos
años y por ser mi mayor inspiración para la realización de mi proyecto de vida.
También quisiera agradecer la dedicación de los profesores que me han guiado durante mis
años de estudio. Especialmente quisiera agradecer a los profesores Edgar Enrique Ruiz,
Miguel Eduardo Torres y por supuesto Juan Pablo Garzón por su importante apoyo durante la
realización de este trabajo.
Página vPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Contenido
INTRODUCCIÓN.......................................................................................................1
I - DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO..............................3
1. OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES....................................................31.1 Descripción del contexto................................................................................................31.2 Formulación del problema que se resolvió...................................................................41.3 Justificación...................................................................................................................41.4 Impacto Esperado..........................................................................................................6
2. DESCRIPCIÓN DEL PROYECTO....................................................................................72.1 Visión global..................................................................................................................72.3 Objetivo general.............................................................................................................72.4 Fases Metodológicas o conjunto de objetivos específicos.............................................72.5 Método que se propuso para satisfacer cada fase metodológica..................................8
II - MARCO TEÓRICO............................................................................................12
1. COMPUTACIÓN UBICUA............................................................................................12
2. TECNOLOGÍAS DE COMUNICACIÓN EN DOMÓTICA....................................................13
3. INGENIERÍA DE REQUERIMIENTOS PARA REDES CASERAS Y DOMÓTICA...................21
4. LEVANTAMIENTO DE REQUERIMIENTOS...................................................................22
5. ESPECIFICACIÓN DE REQUERIMIENTOS....................................................................23Escalabilidad e Interoperabilidad.....................................................................................24Seguridad...........................................................................................................................24Rendimiento.......................................................................................................................25Privacidad y Control..........................................................................................................25
III – DESARROLLO DEL TRABAJO....................................................................26
1. REQUERIMIENTOS DEL SISTEMA...............................................................................261.1 Levantamiento..............................................................................................................271.2 Especificación..............................................................................................................31
2. ARQUITECTURA DEL SISTEMA..................................................................................372.1 Introducción.................................................................................................................372.2 Propósito......................................................................................................................382.3 Alcance.........................................................................................................................382.4 Restricciones y Metas Arquitecturales.........................................................................39
Página vi
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
2.5 Representación Arquitectural......................................................................................40
3. IMPLEMENTACIÓN DEL PROTOTIPO...........................................................................573.1. Implementación Netduino...........................................................................................573.2 Aplicación Android......................................................................................................653.3 Implementación GCM..................................................................................................673.3 Diagramas de clase del prototipo................................................................................68
IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS.............................71
RESULTADOS DE ESTUDIO DE REQUERIMIENTOS..........................................................71
RESULTADOS DE ARQUITECTURA................................................................................72
RESULTADOS DE IMPLEMENTACIÓN.............................................................................73
V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS....75
1. CONCLUSIONES......................................................................................................76
2. RECOMENDACIONES..............................................................................................78
3. TRABAJOS FUTUROS..............................................................................................78
VI - REFERENCIAS Y BIBLIOGRAFÍA..............................................................80
1. REFERENCIAS...........................................................................................................80
2. BIBLIOGRAFÍA..........................................................................................................81
VII - ANEXOS............................................................................................................83
ANEXO 1. GLOSARIO....................................................................................................83
ANEXO 2. POST-MORTEM............................................................................................85
1. METODOLOGÍA PROPUESTA VS. METODOLOGÍA REALMENTE UTILIZADA.............85
2. ACTIVIDADES PROPUESTAS VS. ACTIVIDADES REALIZADAS.................................85
3. EFECTIVIDAD EN LA ESTIMACIÓN DE TIEMPOS DEL PROYECTO.............................86
4. COSTO ESTIMADO VS. COSTO REAL DEL PROYECTO.............................................89
ANEXO 3. ESPECIFICACIÓN DE CASOS DE USO Y DIAGRAMAS DE SECUENCIA.............90
TABLA DE FIGURAS
Figura 1. Stack general Zigbee.................................................................................................15
Figura 2. Stack del protocolo Zigbee. (Figura obtenida de [33]).............................................16
Figura 3. Tabla de requerimientos de usuario..........................................................................29
Página viiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Figura 4. Ejemplo requerimientos de usuario..........................................................................30
Figura 5. Flujo de especificación de requerimientos................................................................32
Figura 6. Especificación de elementos de contexto.................................................................34
Figura 7. Ejemplo de especificación de elementos de contexto...............................................35
Figura 8. Arquitectura general.................................................................................................40
Figura 9. Estructura del patrón Observe and React. (Fig 20.7 de [26])...................................43
Figura 10. Diagrama de casos de uso general..........................................................................48
Figura 11. Diagrama de casos de uso.......................................................................................49
Figura 12. Diagrama de despliegue..........................................................................................50
Figura 13. Vista de Implementación........................................................................................53
Figura 14. Estructura del API de paquetes Zigbee RX. (Fuente: [49])....................................59
Figura 15. Estructura del API de paquetes Zigbee TX. (Fuente: [49])....................................60
Figura 16. Formato XML para persistencia de dispositivos....................................................62
Figura 17. Formato XML para persistencia de clientes...........................................................63
Figura 18. Query de la petición POST.....................................................................................64
Figura 20. Diagrama de Clases aplicación Android.................................................................70
Figura 21. Diagrama de clases Proxy GCM.............................................................................70
Figura 22. Imagen del resultado de implementación...............................................................73
Figura 23 GUI aplicación Android...........................................................................................75
Página viii
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
ABSTRACT
The development of communication technologies in recent years has opened the doors to
achieve the long-term dream of controlling our homes, from light switches to complex appli-
ances. Despite the progress achieved, a solution for existing challenges on developing ubiqui-
tous home automation systems is yet to be seen. System requirements are identified based on
the works made on ubiquitous systems, an architecture and then a prototype are made based
on technologies such as mobile devices, microcontrollers and wireless sensor networks in
order to prove what can be done in product development for home automation systems while
achieving low intrusiveness and cost.
RESUMEN
El desarrollo de tecnologías de comunicación en últimos años ha abierto la posibilidad de
lograr el sueño de controlar nuestros hogares, desde interruptores hasta electrodomésticos. A
pesar de los avances logrados, una solución para los desafíos existentes en el desarrollo de
sistemas domóticos ubicuos debe realizarse. Requerimientos de sistema son identificados
basado en trabajos realizados en sistemas ubicuos, una arquitectura de sistema y un prototipo
son realizados basados en tecnologías como dispositivos móviles, microcontroladores y
dispositivos de redes de sensores, para probar lo que puede lograrse en desarrollo de
productos para sistemas domóticos mientras se logra bajo costo e intrusividad.
Página ixPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
RESUMEN EJECUTIVO
La penetración de sistemas domóticos en el mercado ha permanecido baja durante años a
pesar de los grandes avances que se han realizado en el campo de las tecnologías de
comunicación, lo que incluye entre otras la capacidad de poder comunicar dispositivos
móviles como teléfonos celulares a Internet y el desarrollo de tecnologías orientadas a la
comunicación de dispositivos en redes de sensores; desde hace años existen en el mercado
dispositivos como módulos de radio que funcionan con un consumo de energía reducido y
además se han presentado estándares y especificaciones de protocolos de comunicación
inalámbrica que han sido concebidos para cumplir las necesidades de un sistema donde sus
dispositivos deben tener gran autonomía. El uso de tecnologías con especificaciones abiertas
permiten el desarrollo de sistemas que permitan lograr redes heterogéneas en lo que respecta
a dispositivos, siendo la interoperabilidad uno de las mayores expectativas de los usuarios en
sus redes caseras [10]. Este trabajo de grado tiene como fin proponer una solución que
permita a un usuario poder hacer uso de los servicios provistos por la red domótica de su
hogar de manera ubicua.
Durante el desarrollo de este trabajo se efectuó un análisis de los procesos de ingeniería de
requerimientos orientado al desarrollo de sistemas domóticos y automatización con el
propósito de identificar la manera en la cual se determinan las necesidades que el sistema
debe satisfacer. Una vez que se identificaron las necesidades generales que presentan los
usuarios al momento de hacer uso de las redes de comunicaciones que se encuentran en su
hogar, se obtuvo la base para realizar una propuesta para las actividades de levantamiento y
especificación de requerimientos. Esto dio como resultado las pautas generales para el
desarrollo de una arquitectura de un sistema domótico que permita al usuario el control y
monitoreo de sus dispositivos, basados en esta arquitectura se pueden implementar sistemas
domóticos heterogéneos donde se puede contar con dispositivos y tecnologías de
comunicación diversas; la implementación de un prototipo permitió la validación de la
arquitectura realizada.
Basado en lo anterior, se propone una solución en la que los usuarios hacen uso de sus
dispositivos móviles para comunicarse con su red domótica; la razón del uso de dispositivos
Página x
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
móviles se basa en el hecho que estos se han convertido en uno de las tecnologías ubicuas
más usadas en la actualidad. Se diseña una arquitectura genérica del sistema, la cual está
diseñada para poder ser implementada de manera agnóstica la tecnología usada en los
dispositivos, teniendo en cuenta las necesidades de los usuarios que deben ser satisfechas y
los retos a ser superados en sistemas domóticos y ubicuos. Posteriormente se plantea la
arquitectura para el prototipo que es implementado, dejando de esta forma el diseño sobre el
cual el sistema será desarrollado.
Se desarrollaron tres componentes principales de software, el primero fue un aplicativo que
fue desplegado en un microcontrolador Netduino Plus de Secret Labs, que funciona como el
gestor de comunicación entre la red domótica e Internet, este provee servicios de consulta de
estado de los sensores desplegados en la red y control de un LED que hace parte del mismo
Netduino; esto se logró gracias a que el Netduino incorpora una interface Ethernet que nos
permite comunicarlo a través de los protocolos estándar de Internet (TCP/IP) y también
gracias a que su interface UART permitió la conexión de un módulo Xbee que permite la
transmisión de mensajes haciendo uso de la especificación Zigbee. Los dispositivos que
hacen parte de la red domótica son tarjetas de desarrollo Waspmote de Libelium, que
incorporan algunos sensores y cuyas lecturas pueden ser trasmitidas usando Zigbee como
medio, estos dispositivos fueron programados de forma tal que envíen periódicamente datos
hacía el nodo central de la red (el cual es llamado coordinador en una red Zigbee), el cual en
esta implementación es el Netduino. Una de las razones principales para la escogencia de un
dispositivo como el Netduino fue su bajo costo y tamaño, este dispositivo orientado
desarrolladores tiene un costo de 60 dólares y su pequeño tamaño permiten su incorporación
en el hogar de una manera tal que no sea intrusiva al usuario ni que este requiera hacer
cambios físicos en su hogar para adaptar este microcontrolador. El desarrollo permitió que a
pesar de las limitadas capacidades de cómputo del Netduino este pueda comunicarse con los
dispositivos Waspmote que conforman la red domótica y que además permita la
comunicación de dispositivos externos a la red domótica mediante TCP/IP, particularmente
HTTP y de esta forma logrando que un dispositivo móvil que se encuentra fuera de la red del
hogar realiza la consulta de los datos emitidos por los Waspmote; a esta comunicación
mediante HTTP se le agregó una capa de seguridad que hace uso del algoritmo de cifrado
Página xiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
RC4 la cual permite que los datos transmitidos no puedan ser vistos de manera fácil por un
tercero que esté inspeccionando el intercambio de información proveniente del Netduino.
El segundo componente desarrollado fue el prototipo de una aplicación desplegada en un
dispositivo Nexus S con sistema operativo Android, el cual actúa como cliente de los
servicios provistos por el Netduino. Este obtiene la información del estado de los dispositivos
domóticos enviando peticiones con el uso mensajes HTTP al Netduino a las cuales responde
con una lista de dispositivos y el estado de sus atributos. La aplicación móvil permite también
el control de uno de los componentes en la red, que es el encendido o apagado de un LED que
se encuentra en la placa del Netduino también mediante HTTP, logrando que este pueda ser
controlado remotamente, usando Internet como medio. La información recibida por la
aplicación es almacenada en una base de datos para que pueda ser consultada en caso que el
usuario del dispositivo móvil no se encuentre en un área con una red con acceso a Internet.
Por último fue desarrollado un componente de software que permita enviar mensajes desde el
Netduino hacia el aplicativo móvil incluso cuando éste no se encuentra en ejecución. Esto se
logró haciendo uso del servicio provisto por Google orientado a dispositivos Android llamado
Google Cloud Messaging, o GCM. Los mensajes son enviados a una URL provista por
Google mediante el uso de mensajes POST en HTTPS y estos después son enviados e los
dispositivos móviles deseados. Pero ya que el Netduino no soporta el uso de SSL y por lo
tanto HTTPS se desarrolló un intermediario que recibe las peticiones HTTP emitidas por el
Netduino y las redirige a los servicios GCM de Google.
Finalmente gracias al uso de una metodología de desarrollo ágil, se realizó un desarrollo
orientado a pruebas, en el cual el software fue desarrollado incrementalmente junto con
pruebas para ese nuevo incremento. Esto permitió comprobar el correcto funcionamiento de
los desarrollos de componentes de software antes de realizar la integración de todos los
componentes de software desarrollados. El resultado obtenido permitió validar que la
arquitectura propuesta es válida para cumplir las necesidades de usuario identificadas así
como para superar los retos identificados.
Página xii
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
INTRODUCCIÓN
Existen numerosos aspectos que han entorpecido el desarrollo de productos de sistemas
domóticos, esto a pesar del desarrollo de microcontroladores que pueden ser embebidos a casi
cualquier tipo de dispositivo y que ven aumentadas sus capacidades acorde a lo establecido
en la Ley de Moore, y el hecho que existe una gran cantidad de tecnologías que permiten
comunicar dispositivos mediante conexiones físicas o radio frecuencia. El uso de tecnologías
propietarias hace del desarrollo de sistemas de automatización una labor tediosa,
particularmente por el hecho que estas redes están compuestas por dispositivos heterogéneos.
Por estas razones el espectro de servicios y productos basados de redes domóticas ha sido
limitado y de bajo crecimiento. Pero existen tecnologías en el mercado cuya especificación es
abierta y que siguen los parámetros que se deben cumplir en lo que a redes inalámbricas para
dispositivos de bajo consumo se refiere.
Gracias al desarrollo que se ha presentado en el desarrollo y comercialización de dispositivos
móviles para comunicaciones (e.g. teléfonos inteligentes o smartphones) los usuarios pueden
ahora consumir información y servicios desde virtualmente cualquier ubicación en la que se
encuentren. Esto lleva a que formular una pregunta, ¿podría consumir los servicios de una red
domótica en mi hogar desde mi dispositivo móvil? Las conclusiones a las que se llegan al
realizar el estudio del estado del arte responden esta pregunta. Los dispositivos domóticos no
pueden comunicarse directamente con un punto de acceso a internet debido a que el uso de
tecnologías como Wi-Fi no es apto para implementarse en dispositivos que no cuentan con
una conexión continúa a una fuente eléctrica, como lo son los sensores; por ello se requiere
de un intermediario, un componente que pueda servir de punto de acceso a los dispositivos
domóticos y el cual también pueda proveer servicios a dispositivos que se encuentren fuera
de la red del hogar, haciendo uso de Internet para proveerlos. En este trabajo se propone que
el intermediario sea un dispositivo que no sea intrusivo al usuario, lo que implica que no
requiera cambios en la infraestructura de su hogar y que su presencia se pueda considerar
invisible, por esta razón se determina que un microcontrolador es el dispositivo más
adecuado.
Página 1
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Este trabajo se centra en lograr el consumo de servicios provistos por redes domóticas
haciendo uso de tecnologías de transmisión de datos existentes como las bases para la
comunicación entre quien consume el servicio (el usuario) y el proveedor. La manera en la
que se plantea el consumo es mediante un dispositivo móvil que es usado por el dueño de la
red domótica, y los servicio a ser consumidos son provistos por el intermediario que se
encuentra en el hogar que permite la trasmisión de los datos de los dispositivos domóticos al
usuario final. Para esto se realiza una investigación de requerimientos para estos sistemas, se
propone una arquitectura de sistema que proponga una solución a las necesidades y retos
identificados y se realiza un prototipo para validar dicha arquitectura.
La estructura de este trabajo de grado se organiza de la siguiente forma: El capítulo uno
presenta la descripción de la problemática que se ha identificado, junto con los antecedentes
de la misma, se realiza una descripción del proyecto, la metodología y sus fases que hicieron
parte de su realización y el impacto esperado del proyecto luego de su finalización. En el
capítulo dos se presenta el marco teórico del proyecto, el cual comprende todos los conceptos
y trabajos que hacen parte de la base teórica del desarrollo del proyecto. En el capítulo tres se
describe el desarrollo del proyecto de investigación realizado. Finalmente el capítulo 5
propone las conclusiones obtenidas y los trabajos futuros para desarrollar.
Página 2
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
I - DESCRIPCIÓN GENERAL DEL TRABAJO DE GRADO
1. Oportunidad, Problemática, Antecedentes
1.1 Descripción del contexto
El desarrollo de un gran número de tecnologías de comunicación que han sido desplegadas en
una gran variedad de dispositivos electrónicos ha generado todo un nuevo espectro de
posibilidades respecto a las soluciones informáticas de comunicaciones [1][5]. La
introducción de nuevas tecnologías de comunicación que requieren un bajo consumo de
electricidad y además permiten alta confiabilidad, escalabilidad y seguridad ha sido uno de
los logros más prometedores, ya que los dispositivos ahora pueden lograr mayor autonomía y
ser implementados en áreas donde una conexión eléctrica no es factible. Además el aumento
en la capacidad de cómputo de los dispositivos móviles y su penetración en el mercado, ha
permitido que se generen grandes oportunidades en el desarrollo de nuevos sistemas de
computación ubicuos [1][3]. Pero a pesar de los avances realizados en las tecnologías móviles
y de comunicaciones, la mayoría de dispositivos que se encuentran dentro de nuestros
hogares continúan siendo entes aislados que no realizan más interacción que la que realiza un
usuario al encontrarse físicamente frente al dispositivo. Las nuevas tecnologías proveen las
bases para diseñar e implementar servicios para sistemas de automatización de viviendas, o
sistemas domóticos, más transparentes al usuario final, además de ser seguros, confiables y
claramente proveer aspectos funcionalidades adicionales [2][5].
La creación de sistemas domóticos listos para consumo masivo es posible, la tecnología que
permite comunicar dispositivos domóticos ya existe (e.g. ZigBee, Z-Wave, 6loWPAN) [2][5].
Con el uso de las plataformas móviles y el aumento de la penetración de internet es posible
establecer una comunicación efectiva con los sistemas domóticos sin ser invasivos al
ambiente de trabajo del usuario, ya que basado en el pequeño espacio que ocupan estos
dispositivos y además debido a que el usuario ya cuenta con ellos en la mayoría de casos.
Lograr establecer esta comunicación adecuadamente implica varios retos, entre ellos la
creación de modelos de seguridad y comunicación que deben ser aplicados y el manejo de
disponibilidad de dicho canal de comunicación. Además la ubicuidad de este tipo de sistemas
es vital para su éxito, [1] la automatización del hogar debe realizarse de manera transparente
Página 3
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
al usuario final de forma tal que este solo deba interactuar con el para propósitos de consulta
de su estado y en estados de gran importancia como alertas del sistema [6]. La inclusión de
microcontroladores en un ambiente de automatización permitiría lograr establecer el punto de
control entre dispositivos, y su uso dentro del hogar no es intrusivo al usuario debido a su
pequeño tamaño.
1.2 Formulación del problema que se resolvió
¿Cómo las soluciones basadas en computación móvil permiten la interacción de dispositivos
en un ambiente domótico logrando ubicuidad?
1.3 Justificación
Los beneficios del uso de sistemas domóticos para proveer más funcionalidad y control sobre
los dispositivos dentro del hogar han sido discutidos y expuestos en múltiples ocasiones,
como lo es el control de consumo eléctrico del hogar, detección de intrusos, soporte a
personas con discapacidad, seguridad de sus habitantes, entre muchos otros [6][7][8]. Y con
el uso de dispositivos móviles que cuentan con los mecanismos que le permiten acceder a
servicios provistos a través de Internet mediante TCP/IP ya es posible que el usuario
interactúe remotamente con los dispositivos que se encuentran en su hogar. Existen productos
en el mercado que proveen soluciones a distintas necesidades de los usuarios, pero están
basadas en tecnologías de comunicación que usualmente son propietarias y que además no
permiten la creación de una red de dispositivos domóticos heterogéneos y de manera
transparente al usuario, en varios casos el uso de estos productos limitan al usuario a adquirir
dispositivos de un mismo vendedor evitando así que la red en su hogar sea heterogénea, la
cual es considerada una de las causas principales del lento desarrollo y adopción de los
sistemas domóticos en los hogares [5] [6] [10].
A partir del desarrollo del proyecto se estableció una propuesta para la comunicación de
dispositivos domóticos con móviles a través de Internet que sea adecuada y consistente con
las necesidades que un sistema de esta naturaleza debe cumplir. Estableciendo una solución
que no sea intrusiva al usuario en su ambiente de trabajo, pero que sea capaz de soportar sus
necesidades de control usando como activos importantes los dispositivos móviles y
microcontroladores programables de bajo costo; un sistema no intrusivo implica que el
Página 4
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
usuario no vea alterado de manera significativa el ambiente físico en el que habita, donde no
se agreguen elementos de gran tamaño y donde tampoco sea necesario cambiar la
infraestructura del hogar para realizar la implementación (e.g. instalación de redes de cables
eléctricos adicionales). Al permitir el control remoto de los dispositivos en el hogar se
pretende facilitar las actividades cotidianas que las personas enfrentan en sus hogares, para
las personas de la tercera edad se eliminaría la necesidad de estar físicamente frente a un
dispositivo para hacer uso de sus funciones [32].
La especificación de los requerimientos para estos tipos de sistemas también sirve de ayuda
en un problema común, encontrado en los sistemas con redes en el hogar, que es resaltado en
el trabajo de Edwards[10]. Debido al poco conocimiento técnico del usuario en redes y
comunicaciones, se observa que existe una importante tendencia a identificar erróneamente al
responsable del fallos dentro de la red [8][20]. Para ilustrar este ejemplo, en el caso en que un
usuario no pueda conectarse a Internet desde su computador personal, una de sus primeras
opciones es llamar al servicio técnico de su ISP [10], pero la falla puede que no provenga del
servicio prestado por la ISP. El computador personal o la misma red interna del usuario
pueden ser el problema, con un espectro amplio de posibles fallos, tanto a nivel de hardware
como de software. No encontrar que su problema sea solucionado fácil y rápidamente lleva al
usuario a sentirse frustrado con el uso del producto [20] lo que puede implicar que no compre
mercancías similares de nuevo o incluso las regrese al distribuidor. Las mismas
organizaciones se ven afectadas por este problema de identificación de responsables: Según
una publicación de Accenture Communications sólo el 5% de la cantidad de dispositivos de
electrónica de consumo que fueron devueltos por los consumidores sí tenían problemas de
carácter técnico. En 2007, el costo relacionado con devoluciones alcanzó los 25.300 millones
de dólares en Estados Unidos y Europa, de los cuales 5.060 millones son costos asociados
exclusivamente al proceso de devoluciones de productos funcionales [22].
Las organizaciones que venden productos para automatización del hogar enfrentan un gran
reto en la prestación de sus servicios de manera excepcionalmente satisfactoria al usuario [10]
[6][20]. Esto incluye realizar adaptaciones en todos los departamentos de la organización,
mercadeo, publicidad, desarrollo de productos, investigación, ingeniería, servicio al cliente y
técnico [10]. Es necesario resaltar que las políticas de devolución de productos de las
organizaciones deben ser complemento a las soluciones que proveen las áreas descritas
Página 5
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
anteriormente. No realizarlas afectaría negativamente la percepción del consumidor sobre el
producto y la compañía que lo vende [10][8].
En el caso de los sistemas domóticos, la insatisfacción del cliente respecto al soporte tendría
una gran afectación en su percepción, tanto de la organización que ofrece el servicio, así
como de este segmento de mercado. Esto obedece al costo (el cual actualmente no es bajo
como se pretende) que fue invertido para adquirir dicho sistema con sus servicios asociados
[23]. Una falla real o un “falso-positivo“ en estos sistemas generaría la impresión al usuario
de que toda la información y control sensible de su hogar no están siendo manejados de
forma adecuada y que no sólo su información personal está en riesgo, sino también la
integridad física de quienes habitan su hogar. Debido a lo complejo que es para los usuarios
habituales hacer uso de su red casera y su decepción con el mercado que ofrece dichos
dispositivos y servicios, [1] las organizaciones que brinden servicios domóticos se verían
afectadas de la misma forma, ya que, para el usuario, la forma en la que se comuniquen los
dispositivos domóticos (e.g. sensores) no es diferente a la comunicación en una red de
computadores (e.g. LAN) [10][24].
1.4 Impacto Esperado
Con la realización exitosa del proyecto la propuesta realizada sería utilizada como un marco
común de desarrollo para proyectos de aplicaciones prácticas y de investigación en el área de
redes de comunicación orientada a sensores o dispositivos de bajo consumo enfocados a su
aplicación en hogares y sus aplicaciones en ambientes de uso del usuario donde no se
encuentre físicamente en la misma ubicación física que dichos dispositivos. Los proyectos
futuros no tendrían que preocuparse por la comunicación desde y hacia los dispositivos fuera
de la red donde se encuentran, el desarrollo de nuevos dispositivos de propósito específico
sería su única preocupación.
La divulgación del trabajo realizado a través de conferencias o publicaciones en revistas
especializadas ayudaría a generar mayor interés por parte de la comunidad académica en el
desarrollo de nuevos proyectos que impulsen la creación de nuevas tecnologías en el área de
computación ubicua y sistemas domóticos. Para lograr esto los resultados de este trabajo y
trabajos futuros relacionados podrían ser presentados en el futuro cercano en conferencias.
Página 6
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
2. Descripción del Proyecto
2.1 Visión global
La visión global del desarrollo de este trabajo fue realizar un estudio del estado del arte de
tecnologías de comunicación orientada a dispositivos domóticos para así poder estudiar la
viabilidad de diseñar y crear mecanismos de control de los mismos. También realizar un
estudio sobre el estado actual del manejo de requerimientos de sistema en proyectos que
involucran sistemas domóticos con el propósito de identificar cómo estos sistemas deberían
ser diseñados y desarrollados; luego de este estudio se prosigue a realizar una propuesta sobre
cómo desarrollar el proceso de ingeniería de requerimientos para proyectos de sistemas
domóticos. Una vez investigadas estas tecnologías se procedió a estudiarlas para poder
determinar cuales se ajustan mejor al diseño de un sistema domótico que permita
heterogeneidad. Acorde al estudio realizado de requerimientos se plantea la arquitectura del
sistema para así realizar una implementación que permita el monitoreo y control de
dispositivos domóticos ubicados en una red mediante el uso de dispositivos móviles
inteligentes haciendo uso de protocolos de comunicación estándar de Internet para que de esta
forma puedan ser implementados sistemas heterogéneos y que provean una solución a los
retos que implica el desarrollo de sistemas domóticos y ubicuos.
2.3 Objetivo general
Plantear una solución de software ubicua basada en computación móvil para comunicar
dispositivos domóticos con dispositivos móviles a través de Internet.
2.4 Fases Metodológicas o conjunto de objetivos específicos1. Fase Estado del arte
1.1. Realizar búsqueda bibliográfica referente a proyectos afines, computación ubicua,
tecnologías de comunicación de dispositivos móviles y domóticos.
2. Fase Requerimientos
2.1. Identificar los requerimientos de sistema que una solución de esta naturaleza debe
satisfacer.
2.2. Identificar las tecnologías de comunicación para sistemas domóticos existentes más
adecuadas para una solución de esta naturaleza.
Página 7
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
3. Fase de Diseño
3.1. Plantear el modelo arquitectónico de la solución acorde a los requerimientos
identificados.
4. Fase de Implementación y Validación
4.1. Implementar una aproximación a la solución acorde al diseño planteado y a las
tecnologías escogidas.
4.2. Realizar pruebas de la implementación con el fin de validar la arquitectura propuesta
y refinarla.
2.5 Método que se propuso para satisfacer cada fase metodológicaFase Metodológica 1
Desarrollo del Estado del Arte
Metodología
Se utilizó una metodología de investigación exploratoria, con la cual se formula una hipótesis
para el problema a solucionar mediante la búsqueda y obtención de información, así se
obtiene una propuesta como aproximación a la solución del problema planteado. Durante esta
fase se realizó la recolección y análisis del material bibliográfico necesario para iniciar el
proyecto de investigación, las fuentes principales se comprenden de artículos científicos
publicados en conferencias y revistas pertinentes al tema.
Actividades
1.1. Realizar búsqueda bibliográfica sobre sistemas de automatización en el hogar y las
tecnologías usadas.
1.2. Realizar búsqueda bibliográfica sobre computación ubicua en el área de
computación móvil.
1.3. Realizar búsqueda bibliográfica sobre tecnologías de comunicación orientadas a
dispositivos domóticos, Zigbee, IEEE 802.15.4.
1.4. Realizar búsqueda bibliográfica sobre seguridad en la comunicación de sistemas
móviles.
Página 8
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
1.5. Desarrollar el marco teórico a partir de la investigación realizada
Fase Metodológica 2
Planteamiento de Requerimientos
Metodología
En esta fase se realizaron los procesos de levantamiento, cómo realizar especificación y
análisis de los requerimientos del sistema, estos se realizaron según los datos obtenidos
durante la realización de estado del arte; debido que el proyecto no se concentra en un
producto para un usuario o mercado específico no es posible realizar una especificación
concreta de requerimientos, por lo que dicha especificación no contará con una alta
profundidad.
Actividades
1. Establecer qué requerimientos deben ser satisfechos por un sistema
domótico.
2. Proponer un método para la especificación de requerimientos en sistemas de
esta naturaleza.
3. Definir qué tecnologías existentes de comunicación son las más adecuadas
para un sistema domótico
Fase Metodológica 3
Planteamiento de diseño y arquitectura
Metodología
En esta fase se realizó una descripción de arquitectura basada en el modelo de arquitectura
4+1 con leves modificaciones (particularmente en la vista de escenarios) debido a que en el
modelo 4+1 se plantean las vistas de distintos stakeholders lo que no aplica para este
proyecto, pero se realizó la especificación de las vistas que ahí se plantean, como lo son la
vista física, de proceso, lógica, desarrollo y escenarios tanto para la implementación como
Página 9
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
para el planteamiento arquitectónico general. Lo obtenido en esta fase provee una propuesta
de arquitectura de software que permita cumplir las necesidades que los usuarios desean que
se satisfagan en un sistema domótico, y diseñado de forma tal que este pueda tener
dispositivos heterogéneos.
Actividades.
1. De acuerdo a los requerimientos identificados definir el modelo arquitectónico de
la solución a plantear que refleje las necesidades y retos identificados en la fase
de requerimientos .
2. Definir el modelo arquitectónico específico para la implementación según las
tecnologías escogidas.
3. Para lo anteriormente dicho plantear:
a. Vista lógica
b. Vista de desarrollo
c. Vista de proceso
d. Vista física
e. Escenarios (limitada su especificación y número de escenarios descritos
exclusivamente para el desarrollo del prototipo, debido a la carencia de
stakeholders para este proyecto)
Fase Metodológica 4
Implementación y pruebas
Metodología
Se realizó un prototipo funcional para realizar la validación de la arquitectura y
requerimientos especificados, esto se realizó mediante una metodología de eXtreme
Programming [12], debido a que la realización y especificación de entregables en las distintas
iteraciones del proyecto es más adecuado durante la metodología iterativa escogida para el
proyecto, dichas iteraciones serán definidas durante el desarrollo de esta fase. Se usó una
metodología de solo extreme programming (eXtreme Solo) basado en un desarrollo basado
Página 10
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
en pruebas debido a que es una única persona que realizará la implementación [11], lo
propuesto en eXtreme Solo indica la exclusión de varias prácticas de trabajo conjunto
especificadas en eXtreme Programming. Las prácticas más importantes consisten en el
proceso continuo en el desarrollo, integración, mejoras de diseño, pequeñas entregas y
pruebas unitarias continuas.
El uso de frameworks, dispositivos y otras tecnologías que serán usadas para realizar la
implementación son escogidas acorde a lo encontrado en la fase de estado del arte y de
requerimientos.
Actividades
1) Realizar la codificación del módulo de administración y gestión de
comunicación de dispositivos domóticos en una red casera.
2) Realizar la codificación del gateway que permitirá enviar y recibir mensajes
del modulo de gestión de los dispositivos domóticos a dispositivos móviles a
través de Internet.
3) Realizar la codificación de la aplicación del dispositivo móvil del sistema
mediante el cual se enviarán solicitudes a los dispositivos de la red casera y
se consultará el estado de los mismos.
4) Realizar pruebas de funcionamiento básico de la implementación.
5) Realizar pruebas de seguridad del sistema acorde a lo implementado.
6) Realizar pruebas de tiempos de respuesta de la implementación.
7) Desarrollar el informe de pruebas y su respectivo análisis
Página 11
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
II - MARCO TEÓRICO
La visión que ha tenido el uso de Internet desde sus inicios ha sido la de múltiples
dispositivos de distinta naturaleza conectados a la red de redes para compartir información y
servicios, su gran adopción en las últimas décadas no sólo ha aumentado la cantidad de
usuarios sino también el portafolio de servicios que pueden ser provistos a través de Internet.
Dentro de esta adopción es de interés resaltar el gran uso que tienen las redes domésticas en
los hogares, donde ocho de cada diez las usan en los Estados Unidos según un comunicado de
prensa de The Difussion Group en Marzo de 2012 [2]. Las redes caseras presentan
características y retos semejantes a los que tienen las redes para automatización del hogar,
donde al usuario, la funcionalidad que le interesa obtener, es poder comunicar sus
dispositivos conectados a la red [1][11][12][16]. El término ‘usuario’ en el desarrollo de este
trabajo está asociado con la persona que habita en la casa donde se despliega un sistema
domótico.
1. Computación ubicua
La corriente de pensamiento actual sobre los ambientes de trabajo hace gran énfasis en el uso
de tecnología no intrusiva [18] donde el desarrollo de la tecnología no solo se enfoca en
computadores más poderosos, sino también cómo estos se adaptan a nuestro ambiente y
actividades, en palabras de Weiser, quien es considerado como el padre de la computación
ubicua, una evolución tecnológica no lineal. Uno de los principales retos es lograr un
ambiente de elementos de cómputo que procesen información del ambiente pero que a su vez
no impliquen un obstáculo en las labores cotidianas de los usuarios, la visión de Weiser
consiste en un mundo donde todo lo que nos rodea nos da acceso a la computación. Weiser
define el objetivo de la computación ubicua como la disponibilidad no intrusiva de
computadores en un ambiente físico virtualmente invisible al usuario [18]. Se plante la
información no sea procesada explícitamente bajo el comando de un usuario sino que se
realice principalmente en segundo plano. Desde su planteamiento el uso de tecnologías
inalámbricas es establecida como crucial para lograr ubicuidad, ya que provee la posibilidad
que los dispositivos que deben intercambiar información lo hagan sin necesidad de crear una
Página 12
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
nueva infraestructura física para permitirlo, lo que evitaría el costo de instalar dicha
infraestructura y además no obstruye los diarios quehaceres de las personas gracias a que los
datos son transmitidos por ondas de radio en lugar de un cable que atraviesa una habitación
que genere costos adicionales de mantenimiento. Se han realizado gran cantidad de trabajos
sobre este tema, donde se profundiza en áreas específicas como por ejemplo los sistemas
sensibles al contexto, los cuales pueden adaptar su comportamiento acorde a su ambiente
físico y computacional [34]; donde el contexto se puede definir como el grupo de condiciones
de ambiente y configuraciones que determinan el comportamiento de una aplicación [34].
Los ambientes ubicuos se caracterizan por el uso de numerosos sensores que observan las
lecturas del ambiente en el que se encuentran e interpretan los datos obtenidos [35]. Para
poder realizar esto es necesario tener presente que el ambiente estará compuesto de
componentes heterogéneos.
El gran desarrollo de Internet y la gigantesca penetración que tiene el acceso al este en los
últimos años, alimentan el crecimiento de la gran red de redes que permite a los sistemas
ubicuos acceder a una cantidad casi infinita de información para dar resultados más
satisfactorios al usuario. Esto también permite que los usuarios accedan a recursos de
cómputo desde casi todos los ambientes posibles, también apoyado por el crecimiento en la
industria de la computación móvil; con el uso de estos recursos se puede llegar a lograr el
objetivo de la computación ubicua de proveer los servicios requeridos por el usuario cuando
los necesite.
2. Tecnologías de comunicación en domótica
Como parte de los fundamentos más importantes realizados en el área, se destaca la
especificación y documentación asociada con las tecnologías de comunicación inalámbrica de
bajo consumo, como lo es el caso de Zigbee, IEEE 802.15.4 [15][16]. Esta tecnología puede
ser utilizada como la tecnología adecuada para la comunicación de dispositivos domóticos en
el hogar. Se han escogido estas tecnologías en especial debido a los grandes beneficios que
trae en la realización de sistemas domóticos [5]. A diferencia de múltiples tecnologías
competidoras la pila de comunicación es de carácter abierto, por lo que es accesible a
cualquiera que desee consultarlas; esto permitiría que crear redes con tecnología de
comunicación homogénea pero que cuenta con una red heterogénea de los dispositivos del
Página 13
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
vendedor, por lo que se puede contar con múltiples dispositivos de distintos fabricantes que
mediante una especificación común de comunicación logre redes más escalables [5][4][10].
Varios fabricantes han creado varias tecnologías que soportan la comunicación para
dispositivos de bajo consumo como los domóticos, entre ellas X10, SCS Bus, CBUS, Insteon.
Debido a que varias de estas son tecnologías propietarias, el usuario requiere comprar
únicamente dispositivos de un mismo fabricante, limitando el espectro de productos que
puede incluir un usuario dentro de su red casera. Además en algunos casos, como X10, está
bien documentada su baja confiabilidad en el momento de transferir datos entre distintos
nodos, sin mencionar que el uso de cableado requiere una reconfiguración de la distribución
física dentro de un hogar.
Zigbee además permite multi-hop en las transmisiones realizadas en la red [4], esto permite
que los dispositivos puedan ser esparcidos en el ambiente de trabajo de manera más fácil.
Con propósito ilustrativo se tiene un caso en el que el dispositivo coordinador central de la
red envía una petición a un dispositivo de la red, pero este no se encuentra dentro del radio de
alcance, la capa de red del stack Zigbee se encarga de enviar la solicitud a los dispositivos
adyacentes al dispositivo final con el propósito que esta petición “salte” entre dispositivos
hasta llegar a su destinatario.
Zigbee es un estándar abierto para redes inalámbricas orientado a los campos de control y
monitoreo de dispositivos [15][33]. La definición del estándar IEEE 802.15.4 realiza una
definición de las capas denominadas Física y MAC encargadas de la trasmisión de señales en
su medio con relación al dispositivo y el manejo de creación, interpretación y corrección de
errores de tramas de transmisión respectivamente[16], Zigbee define las capas adicionales de
Red y Aplicación. Éste fue desarrollado por la Zigbee Alliance (una asociación de más de
285 empresas) para cumplir con los siguientes requerimientos:
Bajo costo
Seguridad
Confiabilidad
Muy bajo consumo eléctrico
Uso de bandas de radio sin licencia
Instalación económica y fácil
Página 14
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Redes flexibles y escalables
Inteligencia integrada para la puesta en marcha y enrutamiento de mensajes
Las redes basadas en Zigbee se adaptan a varias áreas de aplicación, las cuales cumplen con
características como:
Baja tasa de transferencia de datos
Nodos que no transmiten o reciben información constantemente
Nodos donde no es posible o inconveniente instalar cableado
La necesidad de modificar la red mientras está en servicio
Dichos nodos pueden consistir en dispositivos que requieran una fuente de energía interna,
como por ejemplo celdas solares o baterías para no ser conectados por medio de cables a una
fuente eléctrica.
2.1.1 Arquitectura de Zigbee
La capa de software de Zigbee ofrece funcionalidad de alto nivel para cumplir con las
necesidades de seguridad, enrutamiento de mensajes y estructura de la red misma[15][16]
[33]. En la figura 1 se puede observar el diseño
general del stack de la especificación Zigbee.
Página 15
Figura 1. Stack genérico Zigbee
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Figura 2. Stack del protocolo Zigbee. (Figura obtenida de [33])
2.1.1.1 Descripción breve de las capas del stack Zigbee
Física/datos
El nivel de capa física y de datos es provisto por el estándar IEEE 802.15.4 sobre la que
Zigbee funciona y se encarga de las operaciones de red de bajo nivel. Esta consiste en dos
capas, la capa física y la capa MAC.
Las bandas sobre las cuales puede trabajar IEEE 802.15.4, y por ende Zigbee, son tres acorde
a la bandas sin licencia en distintas partes del mundo [33], estas son:
868 MHz para Europa
915 MHz para EEUU
2400 MHz para el resto del mundo
Durante la inicialización de la red Zigbee se selecciona el canal disponible menos
congestionado (que van del 0 al 26) para evitar congestión y retrasos en la transmisión de
mensajes.
Capa física IEEE 802.15.4
Esta capa se encarga de la interface con el medio físico de transporte, el cual en este caso son
ondas de radio. Los bits de datos son intercambiados entre el medio físico y la capa superior.
Capa Mac IEEE 802.15.4
Esta capa se encarga del direccionamiento de los datos (a dónde van los datos salientes y de
Página 16
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
dónde llegan los entrantes) y de ensamblar los paquetes de datos de las tramas para el envío
de mensajes y el desentramado en mensajes entrantes.
Stack Zigbee
Provee la funcionalidad Zigbee y es intermediaria entre los niveles de aplicación y físico. Se
encarga de la estructura de la red, enrutamiento y seguridad.
Capa de red
Se encarga del enrutamiento y direccionamiento invocando acciones de la capa MAC, sus
tareas consisten en:
Iniciar la red (coordinador)
Asignar direcciones de red
Agregar/eliminar nodos de la red
Enrutar mensajes a sus destinatarios
Aplicar seguridad a mensajes salientes
Implementar descubrimiento de ruta en topologías de malla y almacenar información
de enrutamiento
Sub Capa de soporte de aplicación (APS)
Se encarga de comunicarse con la aplicación relevante (endpoint) de acuerdo a la solicitud
recibida. El mensaje pasa por Service Access Point que existe entre la capa APS y cada
aplicación. Mantiene información de los nodos conectados directamente.
Se cuenta con un framework de aplicación (AF) que contiene los objetos de aplicación y
facilita la interacción entre aplicaciones y la capa APS. Los mensajes pasan por una interface
Service Access Point (SAP). El SAP implementa las siguientes operaciones:
1. Request
2. Confirm. Se realiza la autorización de la petición.
3. Response. Se pueden manejar respuestas síncronas o asíncronas.
Administración de ZDO (también es incluido en Aplicación)
Permite a los ZDO comunicarse con las capas APS y de Red al realizar tareas internas.
También permite que los ZDO manejen peticiones de aplicaciones para acceso a la red y
funciones de seguridad usando mensajes ZDP (Zigbee device profile)
Aplicación
Página 17
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Comprende las aplicaciones que son ejecutadas en los nodos de la red que dan al dispositivo
funcionalidad. Cada nodo puede tener varias aplicaciones ejecutándose en el mismo, estas
instancias se llaman endpoints, donde los mensajes se originan o terminan.
Para que al enrutar cada mensaje llegue a su destinatario cada aplicación del nodo debe tener
una dirección única. Estas están numeradas de 1 a 240 (la dirección 255 es usada para
broadcast). Debido a esto al enviar un mensaje debe ser provista la dirección de red del nodo
y la dirección de aplicación. La dirección 0 es reservada para el ZDO (Zigbee Device
Objects).
ZDO
Define el rol del dispositivo (coordinador, enrutador o dispositivo final), lo inicia, responde
peticiones de descubrimiento de servicio, participa en la creación/inclusión de la red y
establece una relación segura entre dispositivos de la red.
Framework de Aplicación
Especifica el rango de tipos de datos estándar para perfiles , descriptos para ayudar al
descubrimiento de servicios, formatos de trama para transmitir datos.
Proveedor de servicios de seguridad
Provee mecanismos de seguridad para capas que usen cifrado (red y aplicación). Es iniciado y
configurado mediante el ZDO.
2.1.1.2 Topología de red Zigbee
La manera en la que un mensaje es enrutado en una red depende de la topología de la misma.
Las topologías para una red Zigbee son:
Estrella, consiste en un único coordinador donde todos los dispositivos finales se
encuentran conectados a este.
Árbol, los dispositivos se conectan de manera jerárquica, donde en la cima de la
jerarquía se encuentra el dispositivo coordinador, abajo en la jerarquía se encuentran
los dispositivos enrutadores o dispositivos finales.
Malla, todos los nodos se encuentran interconectados entre si.
El estándar Zigbee soporta una capacidad de 65535 nodos en una sola red, existen tres tipos
de nodos los cuales existen en la capa de red [33]:
Coordinador. Cada red debe tener un único coordinador, en la etapa de inicialización de la
red cumple con las tareas de seleccionar el canal de frecuencia, iniciar la red, permitir a
Página 18
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
otros dispositivos unirse a la red. Y es además el repositorio de llaves de seguridad.
Enrutador. Se necesita mínimo uno para las topologias de malla y árbol. Se encarga
principalmente de la re transmisión de mensajes entre nodos y de permitir que sub-nodos se
conecten a él
Dispositivo final. Su tarea principal es recibir/enviar mensajes de las lecturas que realice,
cuando no se encuentre realizando esto debe entrar a un estado de reposo para ahorrar
energía.
Cada nodo debe tener asignado un identificador único en la red, para lograr esto se hace uso
de la dirección IEEE (o dirección MAC) la cual es una dirección de 64 bits única en el mundo
para ese dispositivo; la otra opción es la dirección de red de 16 bits que identifica el nodo
únicamente en la red, esta es asignada por un nodo enrutador o coordinador cuando el nuevo
nodo se une a la red, la dirección del coordinador siempre debe ser 0x0000.
El uso de tecnologías de comunicación inalámbricas, sobre el uso de conexiones que
requieren el uso de cableado, provee un nivel de intrusión muy bajo cuando se realiza la
inclusión de un nuevo dispositivo de propósito especifico en una red, lo que puede incluir
sensores, cámaras, etc. [41][3][2]. Pero no todas las tecnologías inalámbricas son adecuadas,
el uso de infrarrojo que tiene una tasa de transferencia más alta que Zigbee, requiere un rayo
de comunicación directa entre los dispositivos que se comunican –inconveniente en un
hogar–, a diferencia del uso de ondas de radio que permiten un alcance mayor de la señal.
Otras alternativas como Z-Wave tienen el inconveniente que existen múltiples
implementaciones de su especificación, por lo que no hay consistencia en la comunicación de
dispositivos, además es una tecnología propietaria, lo que limita la inclusión de dispositivos
de distintos fabricantes en la red.
2.1.2 Microcontroladores
El uso de microcontroladores programables es también un aspecto fundamental en el
proyecto, su uso dentro de las redes domóticas podría solucionar múltiples problemas que se
presentan comúnmente en este tipo de sistemas. Los microcontroladores actúan como un
puente entre los mundos del software y el hardware electrónico; algunos de estos, como el
Netduino, permiten realizar la programación del microcontrolador mediante el uso del
middleware Micro .NET Framework [17], el cual provee un lenguaje de programación de alto
Página 19
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
nivel al programador, donde se cuenta con múltiples librerías para hacer más eficiente el
proceso de desarrollo; una de las ventajas principales de Netduino sobre alternativas como
Arduino es la inclusión de librerías para el manejo de hilos de ejecución (o Threads) así como
de manejo de comunicaciones con otros dispositivos mediante protocolos de comunicación
usados en redes de computadores tradicionales, e.g. manejo de peticiones http, sockets y
servicios web, los cuales son indispensables para realizar el modulo de comunicación y
gestión de dispositivos en la red domótica. [9][17]. La plataforma .NET Micro Framework y
so código son distribuidas bajo licencia Apache, por lo que es posible revisar y realizar
cambios necesarios al código fuente. Y el hecho que un chip de 32 bits con un precio menor a
diez dólares [17] permite la incorporación económica de mecanismos de computación en una
gran variedad de dispositivos y ambientes; en el caso de un Netduino Plus, que es un
dispositivo orientado a desarrolladores, el coste es de 60 dólares.
Para el desarrollo del proyecto son importantes los trabajos ya realizados sobre la plataforma
Micro .NET Framework aplicada a los microcontroladores Netduino, el cual es indispensable
para la comunicación de dispositivos en este proyecto ya que además de contar con pins de
propósito general que pueden funcionar como puertos UART cuenta con un puerto Ethernet
que permite el uso de protocolos estándar de Internet. De la misma forma son importantes los
trabajos realizados sobre el estándar IEEE 802.15.4 y la especificación Zigbee como
mecanismos de comunicación efectivos para los dispositivos domóticos. Los trabajos
realizados sobre el control de dispositivos domóticos basados en Zigbee para su
comunicación, como los realizados por Alkar [4] y Gill [5] los cuales comprenden ejercicios
prácticos del uso de Zigbee y su efectividad en un ambiente domótico. Otro trabajo
importante en la realización del proyecto, particularmente en la fase de desarrollo, el trabajo
publicado por Pfister [17] provee una introducción importante en la programación de
sistemas embebidos, particularmente en el uso de Micro .NET Framework en
microcontroladores Netduino.
Trabajos sobre el estudio de las preferencias de los usuarios en el manejo de redes caseras
como el realizado por Edwards [10] además de los desafíos identificados en la
implementación de hogares automatizados y ubicuos [8] que dan un punto de partida
importante para comprender qué es lo que espera un usuario en términos de personalización,
Página 20
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
usabilidad y uso de redes caseras para que pueda cumplir las necesidades particulares del
usuario, las cuales varían significativamente entre usuarios, como lo dicho en Edwards [10]
“…hay tanta variedad de configuraciones como de hogares”.
Respecto a la especificación de los requerimientos orientados a redes caseras, el trabajo
realizado por los miembros de la Universidad de la Plata, Argentina [13], donde se realizó
una investigación y un caso de estudio respecto a cómo deberían ser obtenidos, especificados
y analizados los requerimientos para sistemas basados en el contexto. De la misma forma los
requerimientos de implementación para sistemas domóticos basados en web planteado por
Eckel [6] será una investigación base para el análisis de requerimientos.
3. Ingeniería de requerimientos para redes caseras y domótica
La administración de redes caseras tiene unas implicaciones distintas a las del manejo de una
red en una organización, ya que no cuenta (y no debería contar) con expertos en el manejo de
dichas redes ya que los usuarios de redes caseras en su gran mayoría no cuentan con el
conocimiento técnico necesario para entender como éstas funcionan [1][16]. Esto implica que
el levantamiento de requerimientos de dichos usuarios tiene que ser adaptado a su
conocimiento básico de la conexión a la red, dónde las especificaciones técnicas que permitan
que una red cumpla con las características de escalabilidad, seguridad, entre otras, no sean
preocupación para el usuario [10][14]. En esta clase de sistemas se considera que los
usuarios, son los mismos clientes que pagan por el producto y/o servicio, con las excepciones
en las que el usuario del sistema personalice el sistema para que otros lo puedan usar bajo
ciertos controles de acceso.
Las problemáticas comunes en los sistemas domóticos, que comparten similitudes con los
encontrados en las redes hogareñas, deben ser tratadas dentro del proceso de ingeniería de
requerimientos el cual permitiría establecer claramente los contextos y características de uso
del sistema por parte del usuario, incluyendo requerimientos funcionales y no funcionales,
con el fin de garantizar la calidad del sistema con lo cual aumentaría la adopción del uso de
sistemas domóticos.
Características Generales
El proceso de ingeniería para la construcción de sistemas de automatización en el hogar no
Página 21
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
presenta las mismas características al proceso que es aplicado en la automatización de
industrias y organizaciones comerciales, partiendo de la premisa que las características de los
usuarios y clientes son distintas, lo que implica un reto en todo el proceso de construcción del
sistema [8]. En una organización es común contar con un área de tecnologías de información
(IT), cuyos miembros son expertos en los aspectos técnicos del sistema, de forma tal que si se
presentan fallas en el sistema las pueden rastrear y solucionar fácilmente [10][8]. Además el
manejo de control y acceso del sistema en la organización es impuesto a los usuarios por las
políticas internas que allí rigen. Por otra parte, los usuarios en el hogar no cuentan con el
entrenamiento técnico adecuado para identificar problemas en su red y también esperan
lograr alta personalización de sus redes [10][8]. Esto significa que realizar el escalamiento del
sistema no sólo debe ser un proceso intuitivo para el usuario, sino que le permita agregar
múltiples dispositivos de diferentes fabricantes a su red, de forma que permita lograr
interoperabilidad y contar con una red de dispositivos con tecnologías heterogéneas.
Uno de los más grandes retos en la introducción en el hogar de dichos sistemas es la facilidad
que debe tener el usuario para lograr interactuar con él apenas éste se pone en marcha, donde
las configuraciones generales se realizan de manera automática [10][19][20][21]. Tratar de
encapsular todas las posibles configuraciones que los usuarios podrían dar a sus dispositivos
es una tarea casi imposible, pues cada uno de estos ambientes requiere un grado de
personalización diferente. Citando a Edwards [10] “…pueden encontrarse tantas variaciones
entre estas dimensiones, así como hay hogares...” Pero pueden identificarse configuraciones
generales que cumplan con los requerimientos del usuario.
4. Levantamiento de Requerimientos
En el trabajo de Castelli [13] proponen manejar el levantamiento de requerimientos para
sistemas sensibles al contexto que puede ser aplicado a domótica, acorde a los Elementos de
Contexto del sistema, definiendo como Elemento de Contexto las fuentes de información que
pueden afectar el comportamiento del sistema. En el trabajo de Hong[25] para el proceso de
levantamiento se identifican también los elementos de facilidades de cómputo, usuario
humano y de ambiente; lo que permite determinar el tipo de usuario que usará el sistema,
estimar los contextos típicos de uso, actividades del usuario y como estos son afectados por
los eventos que puedan ocurrir en el sistema.
Página 22
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Más allá del conocimiento del dominio de la aplicación que se obtiene al realizar el proceso
de levantamiento [26][13], los requerimientos del usuario se encuentran fuertemente ligados a
los elementos de contexto del sistema [13][25]. Por esta razón, al realizar el levantamiento de
requerimientos, estos estarán asociados a uno de los elementos en el hogar del usuario: no
necesariamente implica dispositivos específicos que puede que el mismo usuario identifique
explícitamente. En [13] los atributos especificados para los elementos de contexto son
definidos como: Elemento de contexto (e.g. sensor de movimiento, TV), Atributo de contexto
(e.g. estado, operación) y valor (e.g. encendido, apagado, funcionando normalmente). Esto
identifica qué elemento desea manipular el usuario, de esta forma es posible obtener un
ambiente de control que provee la visión general de funcionamiento del sistema acorde al
contexto del usuario y al elemento del sistema con el que desea interactuar. Es también
importante que durante la fase de levantamiento se realicen las aproximaciones del usuario
respecto a tiempos de respuesta esperados y disponibilidad del sistema, debido a los múltiples
contextos en los que se puede encontrar el usuario cuando va a interactuar con este; la
especificación de métricas de los atributos de calidad del sistema cambiarán y debe ser
identificado previo a la etapa de análisis.
5. Especificación de Requerimientos
La especificación de requerimientos describe los requerimientos funcionales y no funcionales
del sistema para que el usuario, quien no posee el conocimiento técnico sobre el
funcionamiento del sistema, comprenda de manera inequívoca las características que éste
tendrá [26]. Poole [27] plantea el uso de un proceso orientado a metas donde cada elemento
en el sistema coopera para alcanzar dicha meta, el framework propuesto en el artículo da la
misma relación que en [13] de los elementos en un contexto sobre los requerimientos del
sistema. Estas metas son inmutables y son definidas en la fase de especificación. El trabajo de
los miembros de la Universidad de la Plata [13] plantea el uso de una plantilla de
especificación, basado en los atributos obtenidos en la fase de levantamiento por cada
elemento de contexto, que consiste en: el requerimiento de usuario y su asociación a un
requerimiento de sistema, tipo de contexto (dónde se encuentra el objeto en cuestión),
elemento de contexto (cuál es el objeto), atributo (la característica o funcionalidad del objeto)
y valor (qué posibles valores pueda tener la funcionalidad del objeto, e.g. cerrado/abierto).
Página 23
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Aunque mediante los casos de estudio expuestos en [13], que demostraron el establecimiento
claro de condiciones de ambiente para obtener respuesta del sistema, es necesario realizar un
análisis más detallado de la especificación de los requerimientos no funcionales,
principalmente las métricas que deben ser cumplidas por parte del sistema domótico.
La especificación de requerimientos no funcionales para los sistemas de automatización
casera abarca un menor número de tipos de requerimientos no funcionales que en los sistemas
en grandes organizaciones. Los tipos de requerimientos de producto, que incluyen
requerimientos de eficiencia, usabilidad, rendimiento, espacio, seguridad, entre otros [26],
abarcan la mayoría del espectro a cubrir. Por otra parte, ciertos requerimientos externos,
particularmente los de Regulación [26], también son de importante consideración. Para
ilustrar la existencia de estos requerimientos se toma como ejemplo a la Comisión Federal de
Comunicaciones de Estados Unidos (FCC por sus siglas en inglés) que incluye políticas que
deben cumplir los fabricantes, como la disponibilidad de mecanismos de accesibilidad para
personas con discapacidad, regulaciones en el uso del espectro para comunicaciones, entre
otros [28]. A continuación, se presentan las categorías de requerimientos a considerar.
Escalabilidad e Interoperabilidad
Debido a la segmentación en tecnologías para domótica que existen, junto al uso de
soluciones de carácter propietario, el mercado de las soluciones domóticas no ha podido
madurar [24]. Esta falta de interoperabilidad entre dispositivos no permite que el sistema
domótico en un hogar sea verdaderamente escalable. Los usuarios esperan adquirir los
productos que cumplan con sus necesidades específicas y esto no puede ser provisto por un
único proveedor [24]. El uso de estándares y especificaciones, como por ejemplo IEEE
802.15.4 [16] y Zigbee [15], son soluciones con un estándar definido sobre las cuales
múltiples fabricantes pueden trabajar para proveer productos que operen bajo diversas
plataformas.
Seguridad
Los mecanismos de seguridad que se encuentran regularmente en las redes hogareñas se
concentran en los niveles “bajos” de la comunicación de dispositivos (e.g. capa de enlace de
datos) que “[…] son difíciles de traducir en políticas de seguridad a nivel del usuario […]”
Página 24
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
[10]. Esto implica que el usuario usualmente no sepa cómo aplicar mecanismos de seguridad
en su red, de manera tal que sólo individuos autorizados hagan uso de sus servicios, en
múltiples ocasiones los usuarios prefieren dejar su red desprotegida, dejándola vulnerable a
riesgos de seguridad [8][23]. Debido a estos inconvenientes percibidos por los usuarios en
“asegurar” sus redes caseras, la preocupación y precaución de la inclusión de una red
domótica en su hogar cobra una alta importancia disminuyendo su adopción[23].
Rendimiento
Beckel [21] propone múltiples características para analizar requerimientos dentro de
ambientes domóticos. Los requerimientos sobre tiempos de respuesta implican retos en el
momento de la especificación, debido a la latencia que existe en el sistema por el cambio
constante de posibles fuentes que hagan que la señal electromagnética que funciona como
medio de comunicación entre dispositivos tarde en transmitirse (e.g. un nuevo mueble en el
hogar que se encuentre en el camino de la señal del dispositivo A al B).
La diferenciación de tiempos de respuesta válidos provee una mejor visión al usuario respecto
a cuando el sistema puede estar presentando una falla o no. Beckel [21] específica ciertos
requerimientos de rendimiento para definir cuál es el tiempo aceptable de respuesta de una
acción del usuario (Soft real-time), donde una respuesta fuera del rango no es considerada un
fallo, pero sí una afectación a la calidad del sistema (Hard real-time). Por otra parte,
especifica un rango de tiempo que siempre debe ser cumplido para obtener respuesta. Aunque
no relacionado con el rendimiento, se hace mención también de una especificación de un
requerimiento de tiempo de vida de dispositivo; la especificación de tiempo de
funcionamiento de un dispositivo que esté limitado a restricciones de energía (e.g. un sensor
de humo que funciona con baterías).
Privacidad y Control
Uno de los retos más grandes en la creación de las redes del hogar es el manejo del control
que pueden tener los usuarios y cómo y quiénes pueden accederlo [10]. La seguridad continúa
siendo una preocupación en las redes caseras, principalmente porque el cliente no tiene el
conocimiento para configurar apropiadamente las funcionalidades de seguridad que provee la
red que está usando [20]. En un sistema domótico, es de vital importancia establecer una
Página 25
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
solución que no límite, pero que tampoco permita el control indebido al usuario respecto a lo
que puede hacer o no con los dispositivos. Ejemplos de dicha situación es el manejo las
cámaras de seguridad, donde estas no deberían ser controladas por todos los miembros del
hogar, así como la manipulación de la temperatura del sistema de calefacción. Edwards [10]
propone soluciones alternativas para el soporte remoto que provee el fabricante a sus clientes.
Se plantea el rastreo y almacenamiento de registro de todo lo que el personal de soporte
realiza de forma que el cliente pueda conocer qué datos han sido consultados y/o modificados
y la implementación de herramientas de diagnóstico que permitan acceso limitado a lo que el
cliente desea mantener oculto. Calvert [20] propone una solución para el rastreo de fallos en
una red casera a nivel del Gateway, usando un mecanismo de almacenamiento de eventos o
logging para mantener registros detallados de los mensajes que transitan por la red. Estos logs
detallados serían el recurso principal de información al realizar un rastreo. Se pretende que
los datos privados del usuario nunca salgan del log de la red casera para mantener la
privacidad de sus acciones. Y [19] plantea una solución basada en el uso de teléfonos
inteligentes para el rastreo de fallos en la conectividad de las redes.
Este capítulo ha establecido los conceptos necesarios para el desarrollo del proyecto. Se ha
realizado un estudio de la computación ubicua como paradigma, un marco de tecnologías de
comunicación orientadas a redes domóticas donde Zigbee es seleccionada como la más apta
en el mercado junto a una descripción de la misma. Posteriormente se mostró lo que se ha
realizado en el área de ingeniería de requerimientos en sistemas domóticos, lo cual es de vital
importancia para lograr establecer un marco común de desarrollo sobre las necesidades de los
usuarios.
III – DESARROLLO DEL TRABAJO
1. Requerimientos del Sistema
Al realizar la evaluación de las propuestas encontradas sobre la aplicación de ingeniería de
requerimientos aplicados a sistemas sensibles al contexto, también aplicables a domótica, se
identificó que es necesario efectuar mejores procesos al momento de realizar el levantamiento
de requerimientos y su especificación.
Durante esta fase es necesario obtener las nociones iniciales del usuario respecto a métricas
Página 26
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
de los atributos de calidad del sistema. Realizar esto durante el levantamiento dará lugar a
efectuar un estudio de factibilidad más oportuno y efectivo.
El proceso de especificación de requerimientos debe contar con una descripción clara de
cómo realizará sus labores el sistema. Para ello, la definición del uso de métricas detalladas
para cada contexto será propuesta junto a la especificación para lidiar con los problemas
descritos en el marco teórico.
La propuesta aquí planteada tiene como objetivo lograr una especificación de un proceso
completo, adecuado y eficiente en las fases de levantamiento y especificación de
requerimientos en sistemas domóticos.
La identificación de elementos por contexto de uso es adecuada para este tipo de sistemas
pervasivos [25], por eso, se propondrá un proceso de levantamiento de identificación de
contextos, junto a las nociones básicas de interacción del usuario, con el propósito de definir
tempranamente la viabilidad del proyecto.
1.1 Levantamiento
La actividad de levantamiento consiste en el descubrimiento y obtención de requerimientos
por parte del usuario y/o cliente que deben ser cumplidos por el sistema a desarrollar [26].
Los elementos de un sistema domótico cuentan con varias características particulares que lo
hacen único dentro del ambiente en el que funcionan, de forma tal que la identificación de los
requerimientos es primordial para abarcar todos los elementos que se pueden encontrar dentro
del sistema.
Partiendo de la meta de usabilidad a lograr planteada por Hong [25] y según los estudios
realizados sobre las expectativas de los usuarios en sistemas de automatización que fueron
expuestos en el marco teórico, podemos observar que ya se han encontrado características
comunes que los usuarios esperan encontrar en un ambiente de automatización que pueden
ser plasmadas como requerimientos del sistema. Estas se concentran principalmente en los
requerimientos no funcionales del sistema, como por ejemplo las características de control de
acceso y tiempo de respuesta de los dispositivos del ambiente domótico [10][8][23]. A partir
del análisis de dichos estudios se ha planteado un marco de especificación para obtener los
requerimientos del sistema que además incluya la identificación de los elementos del
Página 27
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
contexto del dispositivo y su respectiva funcionalidad.
Los elementos comunes de estos sistemas comprenden: los elementos de cómputo, usuarios
humanos y el contexto [25]. Esto nos permite conocer dónde y con el uso de qué dispositivo
el usuario podrá realizar acciones con el sistema, la caracterización del contexto de uso es
importante debido a las particularidades que implica hacer uso del sistema según donde se
encuentre el usuario. Por ejemplo si el usuario desea usar el sistema mientras hace ejercicio
en el parque cercano a su casa usando su teléfono móvil podemos identificar características
importantes. La primera es que el usuario posiblemente no va a contar con una red de
comunicación rápida como una red WLAN usando Wi-Fi y deberá usar la red móvil de su
teléfono (e.g. EDGE o 3G) lo que implica limitaciones técnicas al momento de garantizar
tiempos de respuesta y disponibilidad mayor a que si se encontrase dentro de su red casera.
Además es posible identificar las características de la interface de control, al contar con un
teléfono móvil la interfaz gráfica de usuario tiene que estar adaptada para su uso óptimo en
pantallas pequeñas.
A partir de la identificación de estos elementos es posible identificar quién es el usuario que
interactuará con el sistema, y se identifica qué requerimientos funcionales y no funcionales
necesita que sean satisfechos gracias a que se identifica qué rol juega este usuario en el
funcionamiento del sistema. Esta identificación es importante para cumplir dos de las
necesidades primordiales en los sistemas domóticos, la personalización y seguridad.
La definición de rol del usuario permite identificar hasta qué nivel de interacción puede llegar
el usuario con los elementos de contexto. El rol de jefe, o dueño del hogar, requerirá un
control mayor sobre su hogar, donde pueda monitorear lo que ocurre a su interior sino
también controlar los distintos elementos que allí se encuentran. Para ejemplificar lo dicho se
considera que el dueño del hogar quiere monitorear las cámaras de seguridad de su hogar y
controlar el funcionamiento de las mismas (e.g. mover, activar o desactivar una cámara),
dicho usuario es el que posee el nivel de control total de su red domótica, lo que implica
también que desea imponer restricciones de interacción a los usuarios con roles distintos al
suyo, sus hijos mayores pueden observar lo que es grabado por las cámaras de seguridad,
pero sus hijos pequeños no lo pueden realizar, adicionalmente ninguno de sus hijos puede
encender, apagar o mover las cámaras. Siendo las cámaras elementos críticos dentro del
Página 28
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
hogar, el tiempo de respuesta de una notificación de las mismas debe realizarse a la menor
brevedad, por lo que también es necesario definir un tiempo de respuesta inicial para este
elemento lo que permite evaluar la viabilidad técnica de lo que requiere el usuario.
A partir de lo anteriormente dicho se ha definido una plantilla para la identificación de los
elementos de contexto y sus usuarios basado en lo propuesto en [13] que permite lograr una
aproximación inicial a plasmar las necesidades del usuario que serán satisfechas por el
sistema en forma de requerimientos no refinados. Esta define uno de los requerimientos de
usuario que han sido obtenidos. La plantilla puede observarse en la figura 3 además de un
ejemplo de su uso con una cámara de seguridad en la figura 4 seguido por la descripción de
los campos.
Requerimiento de usuario
Usuario
Elemento de contexto
Atributo de contexto
Valor
Contexto
Elemento de uso
Tiempo de respuesta
Figura 3. Tabla de requerimientos de usuario
Requerimiento de usuario 1: Monitorear lo que ocurre dentro del hogar
Usuario Usuario X
Elemento de contexto Cámara de seguridad puerta principal
Atributo de contexto Operación y Estado
Página 29
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Valor Encender/apagar/mover/monitorear
Contexto Fuera de casa
Elemento de uso Teléfono móvil
Tiempo de respuesta 1 segundo
Figura 4. Ejemplo requerimientos de usuario
Usuario: Identificación única del usuario que interactuará con uno de los elementos del
sistema.
Elemento de contexto: Elemento físico de la red con el que el usuario desea
interactuar, no es necesario que sea asignado a un dispositivo físico en particular (e.g.
sensor de humedad 4 del patio) para que el usuario provea una visión general de su
requerimiento.
Atributo de contexto: Característica medible del elemento de contexto [13].
Valor: Resultado de la medición del atributo de contexto [13], se establece como una
cantidad finita de valores.
Contexto: Ambiente definido en el cual el usuario interactuará con el elemento.
Elemento de uso: Elemento del sistema que será usado por el usuario para interactuar
con el sistema (e.g. computador personal, teléfono inteligente).
Tiempo de respuesta: Tiempo aproximado en el que el usuario espera respuesta.
La identificación de estos pseudo-requerimientos de usuario proveen una visión inicial clara
de cómo serán estructurados los requerimientos del sistema ya que no sólo se cuenta con
elementos para construir requerimientos funcionales sino también los no funcionales. Una
identificación de elementos como esta permite hacer frente a los retos en el uso de redes
caseras y domóticas, ya que al identificar los roles de los usuarios y al identificar qué usarán
para interactuar con el sistema es posible realizar una configuración de comunicación más
efectiva con menos intervención del usuario debido a que se conoce previamente a la
Página 30
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
implementación del producto, cual es el espectro de posibilidades de interacción entre
dispositivos de la red.
La definición de los elementos que se encuentran en la red es también un punto de partida
para determinar el atributo de escalabilidad de la red, debido a que al conocer los elementos
de contexto del sistema, así como sus limitaciones inherentes, es posible determinar qué
limitantes habría para lograr una comunicación homogénea entre los dispositivos de la red, y
de esta forma lograr plantear una solución en la fase de diseño del sistema que contrapese
dichos inconvenientes. La definición de posibles operaciones a realizar en un elemento de
contexto en particular por parte de un usuario permiten definir claramente el control que
pueda tener un usuario dentro del sistema, se define el alcance de sus operaciones logrando
que el dueño de la red pueda establecer con quien compartir elementos en el sistema que
puedan considerarse privados (e.g. compartir la impresora con sólo algunos invitados en el
hogar [10]). Finalmente realizar la identificación de elementos permite realizar un análisis de
los usuarios y elementos que puedan inicialmente conectarse a la red y tener cualquier tipo de
interacción con ella (lo que es limitado por la identificación de los roles de usuario) creando
así un marco común para la implementación de mecanismos de seguridad efectivos que
limiten acorde al elemento de contexto la autorización de conexión al sistema.
Como parte al apoyo de la administración de requerimientos, el uso de una identificación
como esta y plasmarlo como requerimientos de usuario, permite realizar una mejor
trazabilidad respecto al rastreo de usuarios, interfaces, requerimientos funcionales y no
funcionales a través de la especificación; e incluso funciona como apoyo para la realización
de un soporte para una solución de rastreo de fallos en la red como la propuesta por Calvert
[20].
Al efectuar un proceso de levantamiento basado en la identificación de elementos de contexto
como el planteado es posible entender el dominio donde el sistema será implementado, al
obtener una aproximación a las necesidades del usuario que se deben asociar con los
requerimientos junto con sus restricciones. Este planteamiento define las preguntas esenciales
al momento especificar qué desea hacer el usuario, quién lo hace, cómo lo hace y dónde lo
hace. Al obtener esta información es posible continuar con la fase de especificación.
Página 31
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
1.2 Especificación
Posterior a la finalización del levantamiento, se lleva a cabo la fase de especificación. La
especificación de requerimientos es una descripción de las funcionalidades deseadas del
sistema que se va a desarrollar, sin detallar cómo se va a lograr [26]. La especificación se
realiza con base a los resultados obtenidos durante el levantamiento, esto permite rastrear los
requerimientos establecidos de vuelta a la fuente misma del requerimiento, que es la solicitud
del usuario y documentada a través de los requerimientos de usuario incluyendo los
elementos de contexto.
La identificación de los ambientes de funcionamiento de los dispositivos domóticos, junto a
los contextos y elementos usados por el usuario para interactuar con el sistema, permite
establecer varios de los requerimientos en la fase de especificación, este flujo de trabajo se
representa gráficamente en la Figura 5 Las restricciones del sistema, como las impuestas por
interfaces de hardware, software y comunicación pueden ser identificadas y sus
requerimientos asociados especificados. Como ejemplo a considerar, si el usuario desea
interactuar con su red domótica haciendo uso de un teléfono móvil cuando está fuera de su
hogar, es posible deducir que son requeridas interfaces de comunicación que soporten el uso
de las redes de comunicación de las empresas de telefonía celular mediante estándares y
tecnologías como EDGE, 3G o LTE en el caso de teléfonos inteligentes, o mediante
interfaces que permitan enviar y recibir mensajes vía mensaje de texto SMS para los
teléfonos móviles con capacidades más limitadas. Limitaciones en los requerimientos como
restricciones de diseño, requerimientos de desempeño, entre otros, pueden ser identificados
gracias a la documentación realizada en la obtención de requerimientos de usuario según el
contexto de uso e implementación.
Página 32
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 5. Flujo de especificación de requerimientos
La propuesta para apoyar el proceso de especificación de requerimientos aquí planteada
extiende lo realizado en [13], y también con varias de las consideraciones planteadas por
Beckel [21] que a pesar de estar enfocado a los requerimientos asociados con el desarrollo de
aplicaciones para sistemas de automatización (donde los usuarios son desarrolladores),
plantea aspectos importantes que son de gran utilidad para la especificación en el desarrollo
de sistemas domóticos.
Siguiendo lo planteado en [13] es de vital importancia para el proceso de ingeniería de
requerimientos realizar la distinción entre los requerimientos de usuario y de sistema,
considerando que un requerimiento de usuario puede estar asociado a uno o más
requerimientos de sistema. La especificación de requerimientos ahí planteada define
elementos de contexto en los cuales se asocia un requerimiento de usuario con uno de
sistema, junto a los elementos mencionados anteriormente de Tipo de Contexto, Elemento de
Contexto, Atributo y valor.
La aplicación de las tareas especificadas en [13] lograron resultados satisfactorios en los
casos de estudio que fueron expuestos, pero a pesar que existe una asociación clara de los
requerimientos de usuario con elementos del sistema domótico para definir más claramente
los requerimientos de sistema, aún es necesaria la inclusión de las consideraciones que
plantea [25] entre las que se incluyen consideraciones de tiempo y lugar del contexto del
usuario, limitaciones físicas, limitaciones inherentes de los dispositivos domóticos, etc. Una
especificación más enriquecida de los requerimientos permite la creación de un producto que
cuenta con la funcionalidad necesaria y suficiente para cumplir con las necesidades del
usuario en ambientes cambiantes, particularmente la especificación de los grados esperados
Página 33
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
de disponibilidad, dado que en la mayoría de casos los dispositivos domóticos proveen
disponibilidad limitada con tasas de demora fluctuantes [25], la disponibilidad de los
dispositivos no sólo se ve afectada por sus limitantes en consumo eléctrico, sino también en
la intrusión de objetos que puedan dificultar la realización de una comunicación efectiva.
La inclusión de especificación de requerimientos de tiempo de respuesta del sistema, como
los especificados en [25] (tiempos de respuesta aceptables y requeridos), en la especificación
de los requerimientos permite establecer mediante métricas los rangos de aceptación de un
producto y obtener una asociación explícita entre los requerimientos funcionales de un
elemento de contexto con requerimientos no funcionales (o de calidad).
De esta forma se plantea la inclusión de los elementos de tiempo de autonomía del elemento
de contexto en la especificación, es de gran importancia debido a que los sistemas domóticos
consisten principalmente de dispositivos con restricciones de consumo eléctrico y con una
alta expectativa de autonomía. Esto permite realizar en la fase posterior de diseño de sistema,
las consideraciones técnicas que se deben cumplir al implementar un modelo en el contexto
(e.g. Zigbee requiere poco consumo eléctrico y enviando pequeños paquetes de datos [15]).
Basados en lo anteriormente dicho respecto a las limitantes cambiantes de disponibilidad de
un elemento en el sistema es necesario definir qué es aceptable para el usuario en términos de
tiempos de respuesta en un requerimiento. La especificación de tiempos aceptados de
respuesta ya mencionados por [25] da como referente qué tiempo debe cumplirse sin importar
la circunstancia y que rango de tiempo se considera aceptable, pero no implica que el sistema
esté cumpliendo con el nivel de aceptación deseado. El establecimiento de estos tiempos
también permite dar apoyo a solucionar uno de los retos en sistemas domóticos y ubicuos
planteados por Edwards [10][8] y es el soporte para el rastreo de fallos dentro de la red
casera, si una funcionalidad es lograda en la mayoría de casos dentro de un tiempo “Soft real-
time”[25] se puede establecer que dicho elemento tiene un gran potencial de fallar
próximamente y al no cumplir el tiempo “Hard real-time”[25] el dispositivo simplemente no
está funcionando. La especificación de dispositivos/elementos dentro de la especificación de
los requerimientos permite un mejor aislamiento de los problemas y a su vez logra dar mejor
trazabilidad asociada al requerimiento.
A partir de lo anteriormente dicho se plantea realizar una plantilla como soporte para el
Página 34
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
proceso de especificación de requerimientos que puede ser observada en la Figura 6 y la
especificación del requerimiento de usuario de monitoreo de su hogar usando una cámara en
la Figura 7 que se encuentra a continuación.
Elemento de contexto
Requerimiento de usuario
Requerimiento de sistema
Contexto del elemento
Usuario
Contexto del usuario
Atributo
Valor
Tiempo de autonomía
Tiempo de respuesta aceptable
Tiempo de respuesta requerido
Figura 6. Especificación de elementos de contexto
Elemento de contexto: Cámara de seguridad puerta principal
Requerimiento de
usuario
Monitorear lo que ocurre dentro del
hogar
Requerimiento de sistema Observar el video que está siendo
transmitido por la cámara de
seguridad de la puerta principal
usando un teléfono móvil conectado a
Internet
Contexto del elemento Seguridad interna
Usuario Identificador del usuario
Contexto del usuario Red externa a la red hogareña,
Internet
Atributo de contexto Estado mediante transmisión de video
Valor Iniciar/finalizar sesión de transmisión
de video
Tiempo de autonomía 3 meses
Tiempo de respuesta
aceptable
2 segundos
Tiempo de respuesta
requerido
5 segundos
Figura 7. Ejemplo de especificación de elementos de contexto
Mediante la realización de una especificación como la realizada anteriormente es posible
Página 35
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
soportar y rastrear los requerimientos asociados para un elemento de contexto, dando mayor
claridad acerca de los requerimientos funcionales y no funcionales, además provee una
solución a algunos de los retos de la realización de este tipos de redes planteados en [10][8]
[23]. Los campos de la especificación planteada y la razón de su utilidad son descritos a
continuación:
Elemento de contexto: Identifica el elemento de contexto realizado en el proceso de
levantamiento. Es usado para asociar e identificar qué elemento de la red domótica
deberá cumplir con los requerimientos establecidos.
Requerimiento de usuario: Necesidad del usuario que debe ser satisfecha con la
implementación del sistema. Permite identificar el origen de los requerimientos a una
necesidad de usuario, la cual puede estar cubierto por uno o más requerimientos de
sistema.
Requerimiento de sistema: Define qué funcionalidad debe ser implementada en el
elemento de contexto. Permite identificar el alcance y restricciones operacionales de
los servicios provistos por este elemento [26], lo que permite una visión más clara
durante el proceso futuro de diseño.
Contexto del elemento: Ambiente en el que el elemento efectuará sus funciones que
comprende la descripción general de su función. Varias limitantes de diseño,
implementación y despliegue del producto pueden ser identificadas según las
limitaciones inherentes de un ambiente de trabajo sobre el elemento.
Usuario: Identificador del usuario que hará uso de las funciones provistas por el
elemento de contexto. Esto permite establecer la distinción entre los distintos roles del
los usuarios en cuanto al acceso y control de dispositivos en la red.
Contexto del usuario: Ambiente en el que el usuario invocará los servicios provistos
por el sistema domótico, siguiendo los principios de ubicuidad de estos sistemas [29]
[27][23], su funcionalidad debe estar disponible en el momento que el usuario la
requiera, adaptada al ambiente donde se encuentre [18]. Comprender las características
del ambiente donde el usuario recibirá mensajes y realizará solicitudes del sistema
Página 36
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
permite establecer mecanismos de comunicación y seguridad que sean efectivos y que
permitan la adaptación de la información en el ambiente de usuario.
Atributo: Consiste en una característica que puede ser medible del elemento de
contexto. Provee el marco general de descripción de la funcionalidad del elemento.
Valor: Al igual que en la plantilla de levantamiento, consiste en definir los valores que
puede tomar el atributo de contexto. Esto ayuda a limitar las funciones que provee el
elemento para definir el alcance funcional del sistema.
Tiempo de autonomía: Tiempo esperado en el que el elemento sea autosuficiente en su
funcionamiento. Ayuda a definir los criterios de aceptación del sistema así como
provee soporte para el análisis de fallos que puedan ocurrir dentro del sistema.
Tiempo de respuesta aceptable: Como lo establecido por [25] consiste en el tiempo que
se considera aceptable para recibir una respuesta del sistema, el incumplimiento de este
límite (mientras no tenga conflicto con el Tiempo de respuesta requerido) no significa
que haya una falla en el sistema, pero si es una afectación a los criterios de aceptación.
Puede ser usado para identificar fallas de elementos particulares en el sistema, así
logrando un rastreo de fallos más efectivo.
Tiempo de respuesta requerido: Tiempo máximo de respuesta de un elemento de
sistema, se considera que existe una falla con el elemento si no se cumple este tiempo
[25]. Permite establecer medidas de funcionamiento efectivas del sistema.Conclusiones
y trabajos futuros
En esta sección de Requerimientos del Sistema fueron planteados los aspectos más relevantes
a considerar durante en diseño y desarrollo de un sistema domótico. También se realizó una
propuesta para desarrollar el proceso de ingeniería de requerimientos para este tipo de
sistemas, con el propósito de establecer claramente cómo obtener dichos requerimientos y
como especificarlos para el desarrollo de un producto final.
Página 37
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
2. Arquitectura del Sistema
2.1 Introducción
En esta sección se encuentra documentado el modelo arquitectónico que ha sido planteado
como parte de la solución de la problemática establecida, las decisiones tomadas son
sustentadas bajo los lineamientos de requerimientos que el sistema debe cumplir, los cuales
han sido descritos anteriormente como lo son Escalabilidad, Interoperabilidad, Seguridad,
Rendimiento, Privacidad y Control, se propone una arquitectura genérica del sistema que
pueda ser implementada logrando como resultado un sistema heterogéneo y también una
arquitectura para un prototipo. Fue realizado basado en el Documento de Arquitectura de
Software (SAD por sus siglas en inglés) que propone el Rational Unified Process de IBM
[38]. En esta sección se define el diseño general de la arquitectura junto con el diseño
específico del prototipo desarrollado, este último basado en el modelo de arquitectura 4+1. El
uso del modelo 4+1 de Kruchten [37] permite describir en detalle la arquitectura de sistemas
de software, pero no todas las vistas definidas en dicho modelo se ajustan a la descripción que
es requerida para este sistema de comunicación entre dispositivos móviles y domóticos,
particularmente la vista de Escenarios, ya que describe los escenarios de interacción de
múltiples stakeholders y procesos, lo cual no aplica durante la realización de este proyecto ya
que no se planteó la identificación y estudio de los mismos como parte de su alcance. Como
se ha descrito anteriormente en la sección de requerimientos de este documento [vea
Requerimientos de Sistema] los requerimientos y por lo tanto las decisiones arquitecturales se
han basado en estudios realizados sobre las expectativas de los usuarios al interactuar con
redes caseras y sistemas domóticos.
2.2 Propósito
El propósito de la descripción de la arquitectura del sistema es ofrecer un panorama general
pero preciso de la arquitectura de la solución de software que permita la comunicación entre
dispositivos móviles y domóticos a través de Internet independientemente de las tecnologías
de comunicación usadas por los dispositivos domóticos y del dispositivo cliente que consume
los servicios provistos por la red domótica. Mediante las vistas que plantea el modelo 4+1 se
Página 38
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
describen diferentes aspectos del sistema para así lograr una definición clara acerca de la
manera como esta diseñado.
2.3 Alcance
El alcance es establecido como la descripción de las siguientes vistas del modelo 4+1 de
Kruchten:
1. Física
2. Despliegue
3. Lógica
4. Proceso
Se escogieron estas ya que permiten describir el sistema dada la restricción que no se cuenta
con clientes específicos y por ende requerimientos específicos durante la realización de este
trabajo. También se realiza una descripción breve y limitada de algunos elementos de la vista
de Escenario acorde a lo descrito con anterioridad.
2.4 Restricciones y Metas Arquitecturales
Acorde al estudio de Requerimientos de Sistema que se ha realizado previamente una de las
restricciones más importantes que debe acatar esta solución es el uso de dispositivos ubicados
en la red no sean intrusivos en el entorno de trabajo del usuario final, el cual en este caso es
su hogar. Esto implica que dichos dispositivos requieran un mantenimiento casi nulo por
parte del usuario para que funcione de manera correcta y de esta forma ser autosuficientes y
que además no implique cambios en la infraestructura del hogar del usuario (e.g. crear
agujeros en las paredes para el paso de cables para los nuevos dispositivos).
Para dar solución al concurrente problema de interoperabilidad, se propuso la
implementación de un componente en el servidor que permita actuar como puerta de enlace
entre la interface de los dispositivos domóticos con su respectivo protocolo de comunicación.
Esto permite que el servidor pueda interactuar de manera bidireccional con los dispositivos de
la red y además poder crear servicios que puedan ser consumidos externamente mediante la
interpretación de los datos provistos por la interface. Al tener presente constantemente la
Página 39
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
interoperabilidad, se puede proveer un servicio que permita la escalabilidad de la red casera;
esto es posible debido a que al mantener una red de comunicación virtualmente heterogénea,
las limitaciones de adquisición de productos por parte del usuario se ven desvanecidas.
Los requerimientos de seguridad se ven satisfechos mediante el uso de un mecanismo de
autenticación en el servidor que permite validar las solicitudes de los clientes previo a
ejecutarlas, y estas además son cifradas para prevenir que un tercero intercepte e interprete la
información de dichas solicitudes. Los clientes son autorizados acorde a las necesidades que
tiene el usuario respecto a quien desea que tenga acceso a su red casera, esto se logra
mediante la gestión que el usuario puede hacer respecto al uso de los dispositivos móviles
con los que cuenta. Y para cumplir con las necesidades de control que tiene el cliente se
plantea la implementación de un mecanismo de autorización de solicitudes en el servidor, lo
que permitiría que el usuario final, mediante su dispositivo móvil, pueda limitar lo que los
otros usuarios de la red puedan o no hacer en la misma; este componente se plantea en esta
sección pero ya que no hace parte del alcance del prototipo a implementar no se le hará futura
mención en lo que resta de este trabajo.
2.5 Representación Arquitectural
El diseño de la arquitectura del sistema general está basado de manera general en el modelo
cliente-servidor [39] donde un dispositivo (en este caso un dispositivo móvil) actúa como
cliente que realiza solicitudes y recibe respuestas a las mismas por parte de un servidor, el
cual consiste en un dispositivo que almacena, analiza los datos recibidos por los dispositivos
domóticos y los almacena; la arquitectura que se plantea en el manejo de los dispositivos
domóticos dentro de la red casera se plantea mediante el patrón Observe and React [26]; y
por último la arquitectura de la aplicación móvil que permite la consulta y control de los
dispositivos en la red domótica, es basada en un modelo por capas. En la figura 8 se
representa la arquitectura general de la solución.
Página 40
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 8. Arquitectura general
2.5.1 Descripción de vistas
2.5.1 Vista Lógica
En la arquitectura cliente-servidor la funcionalidad del sistema se organiza como un conjunto
de servicios y servidores asociados, donde los clientes acceden y usan los servicios provistos
mediante protocolos de solicitud-respuesta, también es importante resaltar como parte del
Página 41
Vista LógicaObjetivo: Este diagrama tiene como objetivo mostrar cómo está estructurado el sistema basado en los requerimientos funcionales.
Vista de ImplementaciónObjetivo: El objetivo de este diagrama es mostrar cómo se constuye el sistema, se muestra la descomposcion del sistema en subsitemas.
Vista de ProcesoObjetivo: El objetivo de esta vista es mostrar como se comporta el sistema, es decir, como interactúan los diferentes componentes del sistema por medio de protocolos.
Vista de DespliegueObjetivo: El objetivo de esta vista es mostar la topología del sistema.
Vista de Casos de Uso (Escenarios)Artefactos Realacionados: Diagrama de Casos de UsoObjetivo: El objetivo de esta vista es mostrar lo que el sistema puede hacer por medio de los requerimientos funcionales. Se muestran los casos de uso arquitecturalmente significantes.
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
sistema la existencia de una red que permita al cliente consumir servicios [26]. También da
un punto único de control mejorando así la mantenibilidad y da al sistema bajo acoplamiento
e independencia. Algunas de las ventajas de utilizar esta arquitectura es que logra que los
clientes pueden conocer al servidor y los servicios que provee pero el servidor no tiene que
conocer al cliente; y que al existir un único punto de computación, los clientes sólo requieren
uso de presentación. Esto representa la arquitectura de la solución de comunicación general
entre el dispositivo móvil y la red casera ya que el primero sólo se comunica con el
intermediario de la red casera mediante un protocolo común para los dos, en el caso de esta
solución se ha escogido HTTP por ser el protocolo ideal para comunicaciones de solicitud-
respuesta. Se plantea un componente de persistencia que es usado de manera concurrente por
varios hilos de ejecución que permitirá almacenar la información necesaria para autenticación
de solicitudes y para almacenar las últimas lecturas realizadas por los dispositivos domóticos
en caso que sean solicitadas y el dispositivo no se encuentre en línea o aún no haya emitido
comunicaciones.
La arquitectura en capas está organizada de forma tal que la presentación, la lógica de
aplicación y el almacenamiento de datos son componentes independientes que llevan a cabo
una función específica asociada a una capa, lo que permite una mayor mantenibilidad y hace
más sencilla la inclusión de nuevas capas para proveer nuevos servicios y que estas sean
reutilizadas. En esta arquitectura las solicitudes entre componentes del sistema se realizan de
forma jerárquica, las capas superiores sólo pueden hacer solicitudes a la capa inmediatamente
inferior [26] [40].
Las ventajas de esta arquitectura son las siguientes:
Permite diferentes implementaciones de la capa mientras se mantengan las interfaces.
Estandariza interfaces de capas para librerías y otros componentes reutilizables.
Separa la presentación, la lógica de la aplicación y almacenamiento de datos.
Permite añadir capas adicionales en caso de ser necesario.
Facilita el mantenimiento ya que cada componente es independiente de los demás.
Página 42
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Esta arquitectura es escogida ya que permite abstraer los componentes independientemente de
la implementación que se realice, ya sea que el dispositivo móvil funcione bajo la plataforma
iOS de Apple, Android de Google, Windows Phone de Microsoft, etc. Es requerido un
componente de persistencia como parte del sistema para que el usuario pueda consultar las
últimas lecturas realizadas por los dispositivos de su hogar mientras que la conexión es
restablecida; esto se puede presentar por motivos diversos, por ejemplo el usuario se
encuentra den un área sin cobertura de red en su móvil o que el servicio de electricidad (y por
lo tanto de acceso a internet) en su residencia no se encuentra temporalmente disponible.
Aunque no se plantea como parte del alcance de la implementación del prototipo el
componente cliente podría efectuar operaciones específicas de control con la red domótica
acorde al contexto donde el usuario se encuentre, por ejemplo si el usuario estuviese lejos de
casa (determinado por el GPS de su móvil) podría enviar solicitudes al sistema para consultar
el estado de ciertos dispositivos críticos, si el horno se encuentra encendido o apagado.
Figura 9. Estructura del patrón Observe and React. (Fig 20.7 de [26])
El patrón Observe and React [26] que hace parte del diseño del componente servidor general,
este es óptimo cuando se requiere un sistema que monitoree, analice lecturas de sensores y
genere una reacción acorde, y además que estas sean provistas a un consumidor donde se
pueden dar respuestas diferentes según casos excepcionales. Este patrón requiere el uso de
procesos de observación, análisis, presentación, alarma y reacción como se puede observar en
la figura 9. En la arquitectura planteada, este patrón permite diseñar la manera en la que las
lecturas serán entregadas al consumidor final, el dispositivo móvil, posterior a su análisis, y
Página 43
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
también cómo serán manejadas las lecturas excepcionales que requieren atención inmediata
mediante un servicio de alarma.
2.5.1.1 Descripción de componente
Cliente
o Presentación. Consiste en el componente que realiza la gestión de contenido
que es mostrado al usuario mediante la interfaz gráfica de usuario y realiza la
actualización de la información ahí mostrada.
o Lógica. Es el componente que realiza las solicitudes al componente de
comunicación para obtener la información más reciente e interpreta dicha
información para ser actualizada en el componente de persistencia.
o Persistencia. Se encarga de la creación de nuevos elementos en la unidad de
persistencia así como la lectura de lecturas previas de los dispositivos
domóticos.
o Comunicación. Se encarga de enviar y recibir las solicitudes remotas
realizadas hacia el servidor o gestor de red domótica. También se encarga de
recibir las notificaciones o alertas emitidas.
Servidor
o Comunicación. Se encarga de recibir peticiones de lecturas de dispositivos de
la red domótica por parte de dispositivos de control externos a la misma y
enviar respuestas a dichas solicitudes.
o Gestor de notificaciones. Se encarga de enviar alertas a los dispositivos
móviles registrados.
o Lógica. Se encarga de realizar las acciones pertinentes luego de la lectura e
interpretación de los datos de la red domótica. Como por ejemplo solicitar la
emisión de una alerta en caso de un suceso excepcional en la red, almacenar
en la unidad de persistencia nuevos valores de las lecturas. Este componente
es la implementación del proceso Analysis Process del patrón Observe and
React.
Página 44
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
o Observador red domótica. Se encarga de recibir la información provista por
los dispositivos de la red domótica mediante una interface adecuada a las
tecnologías existentes en la red.
o Análisis. Se encarga de analizar las lecturas realizadas para determinar si los
paquetes de datos recibidos están bien estructurados y así determinar si hay
cambios en los datos de los dispositivos de la red.
o Persistencia. Se encarga de almacenar la información de los dispositivos en
la unidad de persistencia y hacer las lecturas de la información de las lecturas
anteriores. También almacena la información de los clientes autorizados con
propósitos de autenticación.
2.5.1.2 Relación Requerimientos-Arquitectura
En la arquitectura planteada (fig. 8) se ven reflejadas algunos de los requerimientos más
importantes a cumplir, los cuales fueron ya mencionados en la sección 1 (Requerimientos del
Sistema).
Interoperabilidad y Escalabilidad
Con el fin de garantizar la interoperabilidad entre dispositivos de distintos fabricantes dentro
del sistema domótico se hace uso de un componente denominado Observador Red
Domótica (fig. 8) el cual corresponde al componente “Observer process” del patrón Observe
and React. Este componente consiste en el enlace del dispositivo servidor con una interface
de comunicación que implementa la interface física que permite la transmisión de datos entre
distintas tecnologías. Estas interfaces de comunicación permiten enviar y recibir datos entre
el servidor y los dispositivos de la red (e.g. sensores con interface de comunicación Zigbee).
Este componente permitiría que haciendo uso de una interface Zigbee se puedan enviar
mensajes a otros dispositivos que usan IEEE 802.15.4 como capa física en su implementación
de stack de comunicación, independiente del protocolo de capa de aplicación que usen los
dispositivos de la red domótica, este componente estructuraría los mensajes a enviar acorde al
protocolo asociado con el dispositivo al cual se desea enviar dicho mensaje; por ejemplo se
podrían intercambiar mensajes a dispositivos que sólo se comuniquen a través de 6LoWPAN
así como también con dispositivos que implementan el stack Zigbee, esto gracias a que estos
Página 45
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
implementan las mismas capas física y MAC y que puede ser provista por el XBee conectado
al Netduino.
Los microcontroladores como los encontrados en un Netduino o Arduino que actúan como
servidor en el sistema permiten la conexión de diversos dispositivos mediante interfaces de
entrada salida con los que éstos cuentan, como por ejemplo puertos de entrada/salida de
propósito general (GPIO), puertos de modulación de ancho de pulsos (PWM), puertos
seriales UART, bus de comunicaciones I2C o bus SPI.
De esta forma mediante estas interfaces pueden conectarse dispositivos al servidor que
permitan el envío y recibimiento de flujos de bytes mediante tecnologías como X10, CBus,
Bluetooth, Zigbee, etc. Esto permite que los dispositivos que se encuentran en el hogar
puedan comunicarse con el servidor, esto acorde a la tecnología de comunicación que
implementan.
Para lograr interoperabilidad de dispositivos de monitoreo y control, como los teléfonos
móviles, se crea un componente denominado Comunicación (fig. 8). Este componente recibe
peticiones mediante el protocolo HTTP y envía respuestas por el mismo medio. Al hacer uso
de HTTP como medio para la transmisión de datos a través de una red externa a la domótica,
como es el caso de Internet, es posible implementar virtualmente cualquier tipo de dispositivo
de control para que el usuario pueda consultar el estado de su red domótica y también
modificar ciertos atributos de la misma; este tipo de dispositivo, representado en la figura 8
como cliente, puede ser implementado en un teléfono móvil como un Smartphone, una
tableta, un cliente web que se usa en un navegador de Internet o una aplicación de
computador de escritorio ya que todos estos implementan el uso de HTTP como parte
fundamental de los mismos.
Gracias al uso de HTTP pueden ser usados los servicios de envío de mensajes que
representen la activación de una alarma del sistema que requiera la atención del usuario, esto
se puede lograr mediante mensajes “Push” que implementan un gran número de dispositivos
con sistemas operativos móviles, como lo es el caso de Android mediante GCM, iOS
mediante Apple Push Notification Service (APNS), Windows Phone mediante Microsoft
Push Notification Service, entre otros. Esto se ve reflejado en el componente Gestor de
Página 46
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Notificaciones de la figura 8 (haciendo uso del componente de comunicación) y en el
componente Alarm Process del patrón Observe and React. En el caso que se requiera que los
mensajes sean enviados mediante mensajes de texto SMS a través de una red de telefonía
celular, el componente de Gestor de Notificaciones requeriría que el Servidor contará con una
interface de telefonía celular o que exista un servicio en Internet que permita dicha
comunicación.
Lo anteriormente mencionado permite que el sistema pueda ser escalado, agregando mayor
cantidad de dispositivos a la red, gracias a la implementación de mecanismos que permiten la
comunicación de dispositivos de manera heterogénea, también gracias al manejo de
concurrencia que provee el servidor, el crecimiento de transmisiones en la red puede ser
manejado por el servidor.
Seguridad y Control
Mediante el uso de los componentes de Comunicación y Observador Red Domóticas proveen
mecanismos de seguridad al sistema. La interface con dispositivos domóticos debe proveer
los elementos de seguridad en comunicación usados en la comunicación de dispositivos
domóticos, en el caso de redes Zigbee, se puede hacer uso de un algoritmo de cifrado AES
para cifrar los mensajes transmitidos en el medio, en el caso de los módulos XBee, estos se
encargan del cifrado y descifrado de los mensajes.
Debido a la vulnerabilidad de los datos que son enviados a través de Internet haciendo uso de
HTTP, existen mecanismos de seguridad que cifran los datos enviados para que un
intermediario no pueda interpretar dichos datos. Se puede realizar la implementación de
HTTPS en el servidor, el cual mediante SSL permite una comunicación cifrada entre dos
dispositivos. O también se pueden cifrar los mensajes que se trasmiten por HTTP y que sólo
dispositivos que cuenten con la llave correcta puedan descifrar.
Haciendo uso del componente de Persistencia y el de Análisis se pueden implementar
mecanismos de autenticación que permitan que el sistema solo pueda ser usado por
dispositivos y/o usuarios autorizados. En la unidad de Persistencia se almacenan los datos de
los autorizados con el fin de validar las solicitudes que realicen desde sus dispositivos.
Página 47
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
También haciendo uso de estos componentes se pueden implementar mecanismos de control
de acceso, donde de acuerdo al rol asignado a un usuario se limiten los servicios que puede
consumir del sistema domótico. Mediante su dispositivo móvil el usuario con los privilegios
más elevados del sistema podría escoger a qué usuarios les permite el control o monitoreo de
dispositivos específicos en el hogar, esta información sería almacenada en la unidad de
persistencia del servidor y el componente de análisis efectuaría la autorización de la ejecución
de las solicitudes del usuario respecto al rol que le fue asignado. Es importante resaltar que la
administración de roles no está dentro del alcance de la implementación del prototipo.
Rendimiento
Es necesario que la implementación del servidor pueda manejar múltiples entradas de
mensajes que llegan desde distintos dispositivos de manera concurrente y que además pueda
responder a las mismas dentro de un tiempo de respuesta adecuado. Haciendo uso del manejo
de Hilos (Threads) en el proceso del mismo es posible lograr manejar múltiples solicitudes,
los procesos identificados en el patrón Observe and React serían ejecutados en Threads
distintos, donde cada mensaje recibido por parte de los dispositivos de la red domótica es
leído en un único Thread. Cada mensaje es analizado en el proceso de Análisis en su propio
Thread, el cual posteriormente invoca los procesos necesarios acorde al mensaje, junto a los
componentes de Persistencia se implementarían mecanismos de control de concurrencia sobre
los datos que son almacenados en memoria secundaria. Y también gracias al uso de HTTP es
posible conocer si los mensajes son recibidos con éxito y cuanto tardan en ser realizados, y
aunque no está dentro del alcance de la implementación se pueden implementar mecanismos
que analicen estos tiempos y tomar medidas acordes.
2.5.3. Visa de Casos de Uso
Esta sección describe los casos de uso que representan la funcionalidad del sistema de
control, es decir los casos que son arquitecturalmente significantes o es una funcionalidad
central del sistema.
Página 48
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 10. Diagrama de casos de uso general
Los diagramas mostrados a continuación son realizados basados en la implementación que se
realizó. En la implementación el cliente consiste en un dispositivo Nexus S con los que
cuenta el departamento de Ingeniería de Sistemas de la Pontificia Universidad Javeriana, este
dispositivo móvil funciona sobre la plataforma Android 4.1.2 de Google. Fueron
seleccionados los dispositivos Waspmote de Libelium [42] que consiste en un
microcontrolador programable basado en Arduino que incluye dentro de la placa un sensor de
temperatura, un acelerómetro, medición de nivel de batería y una antena Xbee con firmware
para hacer uso del stack Zigbee; estos dispositivos tienen como propósito simular el hardware
de dispositivos de un ambiente domótico. El microcontrolador Netduino Plus de Secret Labs
[9][17] fue seleccionado como el dispositivo para recibir solicitudes del cliente Android,
manejar la autorización de los mismos, recibir y almacenar los datos de dispositivos
domóticos y enviar alarmas a los dispositivos móviles. Este cuenta con puertos UART que
permiten el enlace con dispositivo Xbee de Digi pare la recepción y envío de mensajes
mediante Zigbee. También cuenta con un puerto Ethernet para la comunicación mediante
TCP/IP con el dispositivo Android; finalmente cuenta con un LED que puede ser encendido o
apagado programáticamente.
El diagrama de casos de uso no solo muestra los casos más significantes sino también
funcionalidades del sistema que fueron implementadas en el prototipo desarrollado para el
correcto funcionamiento del sistema y el acceso por parte de sus usuarios a todos los
servicios que presta el sistema en sus procesos de lectura de datos de dispositivos Waspmote
Página 49
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
de Libelium y control de un LED en uno de los dispositivos que hacen parte de la red
mediante un dispositivo sobre la plataforma Android.
Figura 11. Diagrama de casos de uso
La especificación de los casos de uso expuestos en la figura 11 pueden ser consultados en el
Anexo 3 Especificación de Casos de Uso y Diagramas de Secuencia. En el mismo anexo
también se pueden observar los diagramas de secuencia establecidos para la funcionalidad del
sistema.
2.5.4 Vista de despliegue
En esta sección se especifican los componentes de carácter físico que serán implementados
por este sistema, también se especifica la relación de la vista del proceso dentro de los nodos
de despliegue; la forma en la que se encuentra configurado el sistema se ha plasmado en el
siguiente diagrama de despliegue UML:
Página 50
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 12. Diagrama de despliegue
2.5.4.1 Waspmote
Este nodo físico representa el microcontrolador con sensores
desarrollado por la empresa Libelium [42] el cual representa un
dispositivo domótico dentro de la red. Este es un buen ejemplo de un
dispositivo domótico para ser implementado ya que gracias a sus
especificaciones permite una autonomía de batería de larga duración.
Además cuenta con sensores de temperatura, acelerómetro, una
antena Xbee para comunicaciones sobre Zigbee e indicador de
batería. Ya que esta es programable, se puede desplegar software en el
microcontrolador para labores específicas. Para este proyecto cada
sensor está ubicado en distintas partes de una casa con el propósito de monitorear la
temperatura del lugar en el que se encuentra, así que solo requiere un programa que lea esta
información de los sensores y los envíe a través de su interface Zigbee.
2.5.4.2 Netduino
Este componente físico desarrollado por Secret Labs, con
apoyo de Microsoft Corporation; actúa como un intermediario en
la comunicación de dispositivos domóticos con Internet. Este
Página 51
Ilustración 1. Waspmote de Libelium
Ilustración 2. Netduino Plus de Secret LabsPreparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
posee pins UART que permite conectar una antena Xbee que funciona como interface entre
Zigbee y el microcontrolador. Este dispositivo interpreta los mensajes recibidos a través de la
interface XBee y almacena la información extraída de los mensajes en su unidad de
persistencia que consiste en archivos en formato XML que son almacenados en una memoria
extraíble SD. Y con el uso de su puerto Ethernet y la implementación de protocolos estándar
de comunicación en el framework Micro .NET permite enviar y recibir mensajes del
dispositivo Android con fines de control. Este dispositivo también cifra los mensajes que son
enviados sobre http para una mayor seguridad en su transmisión.
2.5.4.3. Servidor GAE
En este servidor que es provisto por el servicio de computación en la
nube de Google App Engine (GAE)[45] se encuentra implementado un
Proxy desarrollado específicamente para este proyecto, que permite
retransmitir los mensajes emitidos desde el Netduino hacia los
servidores del servicio GCM (explicado en breve). Fue necesario
implementar este software debido a que para poder enviar mensajes hacia los servidores
GCM es necesario que se realicen las peticiones usando Secure Sockets Layer (SSL) a través
de HTTPS, característica con la cual no cuenta el Netduino por sus limitadas capacidades de
cómputo y de memoria principal. Por esto fue necesario implementar un intermediario que
pudiera comunicarse con el Netduino usando HTTP y que este pudiera redirigir el mensaje a
los servidores GCM usando HTTPS. Se seleccionó GAE ya que provee un servicio de
computación en la nube gratuito, con limites de uso de recursos por supuesto, pero que
provee la solución requerida.
2.5.4.4. Servidores GCM
Estos servidores operados únicamente por Google Inc., proveen un servicio gratuito de
mensajería para dispositivos con sistema operativo Android, denominado Google Cloud
Messaging (GCM)[46]. El servicio ayuda a enviar mensajes desde el Netduino dispositivos
Android. Este servicio maneja todo lo relacionado con encolar los mensajes y la entrega a la
aplicación objetivo en Android, pero no se garantiza el orden de llegada de los mensajes.
Aunque no se hace desarrollo sobre este nodo físico es importante resaltarlo debido a que es
Página 52
Ilustración 3. Módulo XBee de Digi
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
el pilar del envío de alertas hacia el dispositivo móvil incluso si el dispositivo se encuentra
apagado o la aplicación del dispositivo móvil no se encuentra en ejecución.
2.5.4.5. Dispositivo Android
Este nodo consiste en un teléfono inteligente (Smartphone) Nexus S desarrollado por
Samsung y Google que funciona bajo el sistema operativo Android. Este dispositivo es el
objetivo de las alertas que sean generadas por el sistema y además es el que permite
visualizar la información de los dispositivos domóticos en la red del hogar. Este puede
comunicarse directamente con el Netduino mediante HTTP cuando se requiere
explícitamente la información que el Netduino provee. Aunque el uso de HTTPS no es una
opción actualmente para el Netduino esta comunicación es cifrada debido a la información
sensible que por este canal transita. Este dispositivo también cuenta con el servicio de
recepción de mensajes GCM lo que permite recibir e interpretar mensajes pequeños así la
aplicación no esté en ejecución y también cuenta con las librerías de java.net que proveen de
manera más transparente al programador realizar el manejo de peticiones y respuestas
mediante HTTP. Finalmente la aplicación que se desarrolló para esta plataforma almacena
información de los últimos datos recibidos por los dispositivos de la red domótica con
propósitos informativos al usuario en caso que este no se encuentre en una zona con cobertura
de acceso a Internet.
2.5.5. Vista de implementación
El propósito de esta vista es mostrar las decisiones arquitecturales para la implementación del
sistema, se incluyen todos los subsistemas identificados. Esta vista, también conocida como
Desarrollo, está orientada a la especificación de cómo se construirá y configurará el sistema
en términos de software según sus capas.
En esta sección se especifica el diagrama de componentes del sistema, este consiste en
componentes los cuales representan partes modulares del sistema [47].
Página 53
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Figura 13. Vista de Implementación
Como se puede observar en la figura 13 la arquitectura en capas de la aplicación del
dispositivo móvil es aplicada. Se implementan las capas de Persistencia para el manejo de
datos, Lógica para la administración de solicitudes y Fragmentos, los cuales consisten en
elementos de interfaz gráfica que se definen en una capa de Presentación; también existe la
capa de Comunicación que hace soporte de toda comunicación que el aplicativo recibe o
envía. El patrón Observe React se plasma en la implementación de Netduino donde los
procesos de Observación son implementados por los componentes de Interface Xbee y
también por el manejador de peticiones HTTP, el proceso de display se implementa por el
componente de Manejador de peticiones HTTP bajo los comandos del componente Análisis;
el proceso de análisis se implementa mediante el componente denominado Análisis, el
proceso de alarma es implementado a través del Manejador de peticiones HTTP que envía la
alarma a través de GCM. Y finalmente el proceso reactor es ejecutado por el componente
Análisis a través del Manejador de peticiones.
2.5.5.1 Descripción
Waspmote
Página 54
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Consiste de únicamente dos componentes, un programa que se ejecuta en el Waspmote que se
encarga de enviar periódicamente las lecturas obtenidas por sus sensores al coordinador de la
red Zigbee, estas lecturas consisten de la dirección MAC del dispositivo, datos de
acelerómetro (ejes x, y, z), porcentaje de carga de la batería y la temperatura detectada.
También hace uso de la interface Zigbee que tiene incorporada para enviar los mensajes
requeridos a través de Xbee.
Netduino
La implementación del Netduino se divide en secciones acorde al patrón Observe and React
donde se cuenta con un componente que es la interface de comunicación con el dispositivo
Xbee, el cual recibe y envía datos por medio de paquetes Zigbee en la red de dispositivos
domóticos. El componente byte útil se encarga del manejo de los bytes usados en la
comunicación. Reflejado en el componente Interface XBee.
El manejador de peticiones HTTP se encarga de escuchar peticiones remotas que se realicen
y provee la respuesta acorde por el mismo medio. También se encarga de enviar las alarmas
que tienen como objetivo el dispositivo móvil. Estas comunicaciones deben ser cifradas,
aspecto del cual se encarga el componente de cifrado. Soporta peticiones GET para obtener
los datos almacenados en la unidad de persistencia de los dispositivos domóticos y peticiones
POST para encender o apagar el LED incorporado en el Netduino.
El componente de análisis (reflejando el proceso de análisis en el patrón Observe and React)
se encarga de la interpretación de las solicitudes HTTP recibidas y también de los mensajes
recibidos mediante la interface Xbee. Requiere de los componentes de persistencia para
validar las solicitudes (DevicesDAO) y también para almacenar los datos obtenidos por los
dispositivos Waspmote (WaspmoteDAO), en el caso del almacenamiento de los datos del
Netduino, se almacenan en NetduinoDAO. Es necesario almacenar la información de los
dispositivos para poder enviar datos de los mismos cuando estos no se encuentren emitiendo
señales en ese momento.
Servidor GAE
Página 55
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
El componente de Proxy alojado en Google App Engine actúa como intermediario para el
reenvío de mensajes de alerta del Netduino hacia el dispositivo móvil. Este también cuenta
con un componente de cifrado con el fin de añadir una capa de seguridad a las
comunicaciones a través de Internet.
Servidores GCM
Este servicio provisto por Google Inc., se encarga del manejo de mensajes enviados a la
aplicación Android incluso cuando esta no está en ejecución.
Dispositivo Android
Este es el dispositivo que se encarga de controlar y monitorear los dispositivos en la red
domótica. Cuenta con varios componentes encargados de las labores de comunicación con
entes externos; estos componentes consisten en un receptor de mensajes GCM enviados
desde los servidores de Google el cual es transmitido mediante HTTPS. Consiste también en
un componente encargado de enviar y recibir mensajes HTTP haciendo uso de las librerías
Java.net que son provistas con la plataforma Android que tienen como destinatario el
Netduino que se encuentra en el hogar; este componente hace uso de un componente de
cifrado para agregar una capa de seguridad en la comunicación. Cuando la aplicación envía
una solicitud al Netduino para obtener los datos de los dispositivos envía una petición HTTP
GET la cual procesa el Netduino; cuando desea encender o apagar el LED del Netduino envía
una petición HTTP Post.
La persistencia es manejada mediante el uso de la implementación de SQL Lite con la que
cuenta la plataforma Android. Sobre esta se almacena la información de los dispositivos de la
red domótica que ha sido recibida previamente; para realizar esto se implementa un
componente SQL Lite Open Helper.
La interfaz gráfica de usuario implementa Fragmentos de Actividades Android. Esto permite
un manejo más rápido y eficiente en el uso de una cantidad variable de elementos de interfaz
gráfica. Se crean los fragmentos acorde a la información de los dispositivos domóticos, donde
Página 56
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
se genera un fragmento donde se listan los dispositivos y un fragmento por cada dispositivo
registrado.
Finalmente el componente principal de la aplicación cuenta con un administrador de
fragmentos, el cual los genera acorde a la información de dispositivos con la que cuenta el
dispositivo. También cuenta con un manejador de solicitudes, el cual envía solicitudes a los
componentes de mensajería para solicitar la actualización de la información de dispositivos.
2.5.6 Vista de proceso
En esta sección se describe la descomposición del sistema en procesos de control [38]. El
sistema está compuesto por varios procesos de control: proceso de monitoreo de mensajes
Zigbee, proceso de envío y recepción de solicitudes, proceso de registro en las unidades de
persistencia, proceso de alarmas, proceso de consulta información de dispositivos, proceso de
envío de control de dispositivos. El acceso a los servicios prestados por el sistema es se
realiza de manera automática en un intervalo de tiempo determinado, también permite
realizarlo cuando se realiza una solicitud explícita por parte del usuario del dispositivo móvil.
El rendimiento que presenta el sistema es un aspecto que debe ser considerado, los tiempos
de respuesta deben cumplir las necesidades de los usuarios, pero debido a las limitadas
capacidades de computación del Netduino, y además la necesidad de proveer un mecanismo
de seguridad, donde el dispositivo debe realizar el cifrado de los mensajes que salen y llegan
de la red domótica, los tiempos de respuesta que proveerá el Netduino se ve reducido.
Respecto a la tolerancia de fallos el sistema maneja y descarta los mensajes que recibe que no
cuentan con la estructura necesaria, evitando afectar el sistema en la interpretación de
mensajes inválidos.
Durante la ejecución de la aplicación móvil se muestra al usuario las ultimas lecturas que han
sido recibidas para poder proveer al usuario con información mientras se actualizan las
unidades de persistencia; esta actualización se puede ver pospuesta debido a problemas de
comunicación entre el dispositivo Android y el Netduino, que pueden ser causados por alta
congestión en la red de comunicación o porque no se encuentre el usuario en un área de
cobertura de la red de Internet móvil.
Página 57
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Durante esta sección de Arquitectura del Sistema se desarrolló un diseño de los distintos
componentes y la manera en la que estos se comunican y que conforman el desarrollo de
software del prototipo que se desarrolla. Este desarrollo fue basado en lo propuesto en el
proceso de documentación de arquitectura 4+1, donde se especifica por medio de vistas los
distintos aspectos del comportamiento y distribución del software. Eso se realiza haciendo
uso de lo estudiado y establecido en la fase de Requerimientos, lo que provee algunos
parámetros para el diseño de un sistema que permita proveer servicios de manera ubicua al
usuario.
3. Implementación del prototipo
La implementación del prototipo del sistema se realizó basado en los diseños arquitectónicos
realizados anteriormente. Se realizó la codificación de la puerta de enlace implementada en el
Netduino, luego se codificó la aplicación del dispositivo Android para el consumo de
servicios provistos por el Netduino y finalmente se realizó la codificación del servidor Proxy
para el envío de alertas por parte del Netduino a la aplicación Android.
3.1. Implementación Netduino
El primer componente que fue implementado en el dispositivo Netduino Plus fue la interface
de comunicación Zigbee. Esta se realiza realizando la conexión entre el módulo Xbee y el
Netduino. Los pines digitales 0 y 1 del Netduino que funcionan como pines UART RX/TX, el
pin de salida de voltaje de 3.3 voltios (corriente directa) y el pin que actúa como conexión a
tierra (Ground) se conectan a los pines correspondientes del módulo Xbee [48], los cuales
están denominados como Dout, Din, 3.3V y Gnd. Estas conexiones alimentan eléctricamente
el módulo Xbee.
Página 58
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Ilustración 4. Netduino Plus y Xbee
Debido a que un módulo Xbee no puede ser conectado directamente a una protoboard debido
a que la distancia entre sus pines es demasiado angosta fue necesario comprar un dispositivo
que actúe como adaptador (conocido como break out board). El módulo Xbee es conectado a
este adaptador y luego a una protoboard, en la cual también se conectan los cables de cobre
para conexión con el Netduino.
Una vez conectado el Netduino plus con el Xbee se puede realizar la comunicación entre
ellos cómo si se tratase de una conexión a un puerto serial. La comunicación se realiza sobre
el puerto denominado COM1 y con un tasa de baudios de 38400. Esta tasa de baudios se
establece debido a que es la necesaria para el correcto funcionamiento de los Xbee que se
conectan a los Waspmote según su documentación [49].
3.1.1 Comunicación Waspmote-Xbee-Netduino
A continuación se realizó el software para interpretar los datos que por este puerto serial. Para
ello se desplegó un código en los Waspmote, que hace parte de la distribución del API, que
envía por medio de Zigbee al coordinador de la red las lecturas de su acelerómetro, sensor de
temperatura, porcentaje de batería restante y su dirección MAC. El Xbee que fue conectado al
Netduino Plus le fue desplegado el Firmware de Coordinador Zigbee que es provisto por
Digi, mientras que el Firmware desplegado en los Xbee de los Waspmote es el de End Device
o dispositivo final.
Página 59
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Acorde a la especificación del API de Zigbee (Zigbee Receive Packet) el formato de los
paquetes que son enviados por parte de los Waspmote está distribuido de el siguiente orden
de bytes [54]:
1. Byte de inicio
2. Bit más significativo
3. Bit menos significativo
4. Tipo de trama
5. Dirección física de destino (64
bits)
6. Dirección de red de destino (16
bits)
7. Opciones de recepción
8. Carga útil
9. Checksum
Pero el API utilizado por la implementación de Zigbee en los dispositivos Waspmote cuentan
con una capa adicional del API que consiste en campos adicionales en la trama, los cuales
pueden ser vistos en la figura 14.
Figura 14. Estructura del API de paquetes Zigbee RX. (Fuente: [49])
La estructura del API para enviar paquetes Zigbee, también documentada en [49], y que
puedan ser interpretados correctamente por los Waspmote se distribuye según la figura 15.
Página 60
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 15. Estructura del API de paquetes Zigbee TX. (Fuente: [49])
Con esta información se desarrolló un código que recibe los mensajes en formato de bytes
desde la conexión de puerto serial con el Xbee e interpreta los datos que allí se encuentran
acorde a la estructura dada anteriormente. La interpretación de cada uno de estos mensajes es
efectuada en un hilo de ejecución independiente. Si no se encuentran el campo del byte de
inicio (0x7E) se descarta ese mensaje. Se desarrollaron las clases RXPacket y Xbee que
reciben los flujos de bytes del Xbee y recrea el paquete del mensaje en un objeto con los
datos interpretados de dicho flujo.
Se observó que al recibir los datos algunos eran inconsistentes, por ejemplo la dirección
MAC recibida tenía ciertas discrepancias con la dirección real del Waspmote que enviaba el
mensaje. Debido a una organización poco clara de la documentación del manejo del API
Zigbee en los dispositivos Waspmote tomó bastante tiempo descubrir que la razón de estas
discrepancias era el uso de ciertos caracteres de escape en los campos del paquete, sin los
cuales la transmisión no funciona en los Waspmote. Por consiguiente fue necesario hacer
identificar los bytes de escape de la trama recibida para poder así obtener los bytes que
corresponden al mensaje original. Estos consisten en los bytes: 0X7E, 0X7D, 0X11 y 0X13.
Una vez realizado esto ya fue posible recibir e interpretar correctamente todos los campos
recibidos de los mensajes Zigbee.
Luego se continuó con la implementación del código necesario para enviar mensajes Zigbee
del Netduino hacia los Waspmote, con el propósito de proveer una aplicación más completa
Página 61
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
así el prototipo no considere que se envíen comandos hacia los Waspmote. Inicialmente se
creaba un flujo de bytes estructurado según lo requiere el API de paquetes Zigbee para
transmisión (TX), pero se observó que esta información no estaba siendo procesada por los
Waspmote. Se prosiguió a buscar la fuente del error, ya que los mensajes llegaban al
Waspmote pero el API sobre el cual este funciona estaba descartando los mensajes, se
pensaba que al contar con los códigos fuentes del API con los que es distribuido el
dispositivo sería fácil encontrar el fallo; pero se encontró que el código fuente del API se
encuentra pobremente documentado e incluso lo visto en los códigos fuente no correspondía
con lo plasmado en los documentos provistos por Libelium. Luego de una búsqueda a la
solución, se encontraron varios API desarrollados por individuos y su código fuente
distribuido por Internet y después de probar varios de ellos se encontró que el provisto por
Michael Schwarz [55] lograba estructurar los bytes del mensaje de forma tal que lograran ser
interpretados por los Waspmote.
Fue necesario realizar varias modificaciones al código fuente de Michael Schwarz para que
pudiera ser usado con los Waspmote. El código inicial no realizaba el control de los campos
adicionales del API extendido que usa Libelium y además se realizó un cambio de forma tal
que cada vez que llegará un mensaje del Xbee se ejecutara un evento que realiza el análisis
del mismo en su propio hilo de ejecución, esto con el propósito que el Xbee conectado al
Netduino y su buffer se encuentren disponibles para recibir mensajes adicionales de manera
casi inmediata, esto crea uno objeto de la clase RXPacket que estructura los datos del paquete
acorde a los bytes obtenidos donde también se hace la verificación de bytes de escape de esta
forma libreando rápidamente al objeto de la clase para estar atento a la llegada de nuevos
mensajes. Una vez estructurado el paquete se envía a otro componente para que sea
actualizada la información de las lecturas de los Waspmote.
De esta forma se logró establecer una comunicación bidireccional exitosa entre el Netduino
plus y los Waspmote. Al lograr esto se procedió a crear el código que almacene la
información recibida en la unidad de persistencia del dispositivo, el cual es una memoria SD.
La información de los dispositivos es almacenado en un archivo XML. Cada vez que se
reciben nuevos mensajes con nuevas lecturas, esta información es actualizada también en la
unidad de persistencia. Como mecanismos de control de concurrencia para este prototipo
Página 62
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
hace un bloqueo (lock) del componente para que de esta forma sólo un hilo pueda trabajar
con ella, en caso que ocurra un fallo durante la ejecución se dispara una Excepción y el hilo
es terminado. La estructura de este archivo XML puede ser observada en la figura 16.
Figura 16. Formato XML para persistencia de dispositivos
3.1.2 Manejo de peticiones HTTP
La siguiente fase fue la implementación de un manejador de peticiones HTTP en el Netduino.
Este fue conectado directamente mediante un cable Ethernet a un router tradicional que se
encuentra en un hogar dándole a este una dirección IP estática para la comunicación del
mismo en la red. Como parte del inicio de la ejecución de la aplicación, se crea un nuevo hilo
de ejecución en el cual se escuchan peticiones HTTP recibidas haciendo uso de un
HttpListener que es ejecutado en un Thread. Dependiendo si la petición enviada al listener es
de carácter GET o POST se ejecutan instrucciones diversas, otro tipo de métodos son
ignorados.
Las peticiones GET consisten en obtener los datos de las lecturas de los dispositivos de la red
domótica, los cuales en este caso consisten del Netduino, y dos dispositivos Waspmote. Para
poder obtener esta información, el solicitante debe ser autorizado, por lo cual se implementó
un mecanismo de autorización en las solicitudes. Cuando un cliente quiere obtener la
información que se encuentra almacenada en el Netduino debe incluir en el mensaje un
identificador para validar que sea un usuario autorizado. Este identificador consiste en el
grupo de caracteres que identifica de manera única al dispositivo Android cuando este se
Página 63
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
registra en el servicio GCM, cuando la aplicación Android se ejecuta por primera vez. Estos
identificadores son almacenados en un archivo XML en la memoria SD del Netduino, un
ejemplo de este archivo se puede observar en la figura 17.
Figura 17. Formato XML para persistencia de clientes
Una vez autorizado el cliente que realiza la solicitud, se procede a obtener los datos
almacenados en la unidad de persistencia, y se envían de la misma forma en la que es
almacenado en una respuesta HTTP excluyendo el encabezado XML y los fines (i.e. \r\n) de
línea para evitar inconvenientes al momento de escribir el flujo de bytes de la respuesta. En
caso que el cliente no esté autorizado se da como respuesta un código 401, que indica que no
se encuentra autorizado para obtener este recurso. El identificador se envía como parte del
query de la URL de la petición, este se envía cifrado, del cual se discutirá más adelante en el
documento.
Las peticiones POST consisten en el cambio de los elementos de la red domótica, para este
prototipo esto consiste en encender o apagar el LED incorporado en el Netduino. Al igual que
las solicitudes GET requiere que el cliente sea autorizado, en este caso el identificador no se
transmite por la URL de la petición sino como parte del cuerpo de la misma. Una vez se
realiza la autorización se procede a evaluar la solicitud. El cliente envía la información del
dispositivo a modificar, con su respectivo atributo, un ejemplo de dicha petición se ilustra en
la figura 18. Se hace un análisis de los atributos para determinar si el dispositivo existe,
basado en su dirección física MAC y posteriormente obtener el atributo a cambiar, en este
caso si LED se establece como ON, el LED del Netduino es encendido, el caso contrario
cuando el valor es OFF. Posteriormente se realiza la actualización de la información en la
unidad de persistencia. Se envía al cliente in código de respuesta 200 si la solicitud fue
procesada con éxito, un código 401 si no se encuentra autorizado y un código 500 si ocurrió
un error no manejado en el Netduino.
Página 64
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 18. Query de la petición POST
Ya que el Netduino no soporta la implementación de HTTPS mediante SSL, fue necesario
incorporar una capa se seguridad personalizada para que los mensajes enviados desde y hacia
el Netduino no viajaran como texto visible sobre la red. Para lograr esto se implementó un
algoritmo de cifrado RC4 [52] el cual mediante una llave simétrica cifra los datos que se
envían en los query de las solicitudes así como en las respuestas. Se hace uso de una llave de
256 bits para el cifrado y descifrado. Los encabezados HTTP no se cifran, únicamente la
carga útil que es enviada. En el caso de las peticiones GET el identificador del cliente que se
agrega al URL de la petición es cifrado por el cliente y luego descifrado por el Netduino; de
la misma forma las respuestas enviadas (i.e. los datos de los dispositivos) también son
cifrados usando RC4 para que el cliente luego los descifre. En el caso de las peticiones
POST, la carga útil que consiste en los datos a modificar de un dispositivo se cifra al igual
que el identificador del cliente, para que luego el Netduino lo descifre y posteriormente pueda
evaluar la solicitud, las respuestas de estas solicitudes no son enviadas cifradas, ya que solo
consisten en códigos de respuesta (e.g. 200, 401, 500). A pesar que esto implica una carga de
cómputo adicional al Netduino, es de vital importancia agregar este elemento de seguridad a
las comunicaciones hacia y desde el Netduino por el grado de sensibilidad de la información.
Con lo anteriormente expuesto se logró obtener las lecturas de los Waspmote y encender y
apagar el LED del Netduino mediante un programa de prueba realizado en Java. El puerto
asignado para la “escucha” de peticiones en el Netduino es el 5073, se escogió este puerto
para evitar inconvenientes que involucran en uso del puerto 80 cuando las peticiones se
realizan fuera de la LAN a través de Internet. Para lograr la comunicación a través de Internet
fue necesario hacer uso de la funcionalidad NAT del router, donde se redirigen las peticiones
externas al puerto y la dirección IP que tiene asignada la aplicación del Netduino. Durante el
desarrollo se realizaban pruebas de funcionamiento a través de una red LAN, donde el
programa de prueba Java se ejecutaba en un computador personal para realizar las solicitudes
a través de la LAN al Netduino. El identificador usado para la autorización de las solicitudes
estaba ya incorporado a la lista de dispositivos autorizados en el Netduino. Ya que el
Página 65
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Netduino se encuentra únicamente conectado al router del hogar provisto por la ISP y una
conexión eléctrica al mismo, no implica un nuevo elemento intrusivo al usuario final, ya que
el Netduino puede compartir espacio con el router e incluso la toma eléctrica, si el usuario ya
contaba con espacio para su router también lo tendría para este dispositivo; por último ya que
el dispositivo sólo tiene que ser conectado a energía y al router no requiere mayor
intervención del usuario, por lo que no requiere que este haga mantenimiento.
3.2 Aplicación Android
Posteriormente se realizó la codificación de la aplicación Android que actúa como cliente a
los servicios provistos por el Netduino que es el enlace de comunicación entre la red
domótica y el mundo exterior (mediante el uso de peticiones síncronas http).
3.2.1 Interfaz gráfica de usuario
Lo primero que se realizó es la implementación de la interfaz gráfica de usuario que permite
al usuario interactuar con la información. Se hizo uso de Fragmentos de Actividades que
permiten el manejo de elementos de interfaz gráfica de manera dinámica [50]. Un Fragmento
representa la información de un dispositivo de la red domótica y otro adicional que se usa
para mostrar una lista de todos los dispositivos registrados. El manejo de Fragmentos permite
al usuario navegar por toda la información de cada dispositivo dinámico que se genera de
manera acorde a la cantidad de dispositivos existentes, lo que la hace dinámica.
La administración de estos Fragmentos se realiza mediante el uso de un objeto de la clase
SectionsPagerAdapter que extiende a la clase FragmentPagerAdapter. Se encarga de crear los
fragmentos necesarios y también el respectivo tipo (i.e. lista general de dispositivos o detalles
de dispositivo). Este administrador se crea en el método onCreate de la actividad principal
(cuando se abre la aplicación); en este método también se realiza el registro del dispositivo en
el servicio GCM de Google para poder recibir las alertas emitidas por el Netduino. Los
fragmentos son creados acorde a la información almacenada en la unidad de persistencia de la
aplicación, la cual fue desarrollada más adelante.
Cada fragmento es creado según la naturaleza de lo que su información representa, si el
dispositivo a mostrar es un Netduino, se genera una distribución de elementos de interfaz
Página 66
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
gráfica distintos a aquella generada en caso de ser un Waspmote. La clase DefaultFragment
se encarga de generar una distribución de Views acorde al dispositivo a mostrar, y también
genera los manejadores eventos asociados con los eventos de interacción del usuario con la
aplicación móvil. Las clases DeviceListFragment y DevicesListAdapter se encargan de
desplegar una lista de dispositivos registrados en un fragmento que incluye, el número de
dispositivos, el estado del mismo, la hora de la última lectura y una imagen representativa de
cada dispositivo. La navegación entre fragmentos se hace seleccionando el dispositivo
deseado de la lista o mediante swipes que realiza el usuario entre fragmentos, consistente con
la experiencia de usuario de navegación de correos electrónicos en el sistema operativo
Android.
3.2.2 Comunicación y Persistencia
Posteriormente se realizó la codificación de los módulos de comunicación, que permiten a la
aplicación Android intercambiar mensajes con Netduino. Como se ha descrito anteriormente
los mensajes consisten en peticiones HTTP cifradas que pueden ser GET o POST. Para el
manejo de estos mensajes se implementaron clases que heredan de la clase AsyncTask
provista como parte de la plataforma Android, de forma tal que implícitamente al crearse el
objeto e invocar su método, este se ejecuta en un hilo de ejecución que no interrumpa el hilo
de ejecución de la GUI. Las clases implementadas fueron HttpPOSTRequestTask y
HttpGETRequestTask.
HttpGETRequestTask se encarga de enviar una solicitud GET al Netduino con el propósito
de obtener las lecturas de los dispositivos de la red domótica. Envía al Netduino la petición
con los parámetros necesarios y de obtener un mensaje de autorización , en este caso código
200, se procede a interpretar los datos recibidos. Esto es realizado haciendo uso de la clase
DocumentBuilder provista en el paquete javax.xml.parsers de; SDK de Java, lo que permite
fácilmente obtener información de un documento con estructura XML. Luego de obtener la
información, la unidad de persistencia de la aplicación Android es actualizada.
HttpPOSTRequestTask se encarga de enviar solicitudes de cambio de atributos en los
dispositivos de la red domótica, en el caso de esta implementación encender o apagar
remotamente el LED del Netduino usando como parámetro para la solicitud el formato de la
Página 67
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
figura 18. Netduino envía un código de respuesta a la aplicación Android que indica el éxito o
no de la petición.
Al igual que en la implementación del Netduino, es indispensable implementar el mecanismo
de cifrado para los mensajes enviados y recibidos. Se hace uso también del algoritmo RC4
con la misma llave simétrica utilizada en el Netduino. Tanto los parámetros de las peticiones
POST como también el query de las peticiones GET son cifradas. El id de registro que se
obtiene al registrarse en GCM, funciona como llave de autorización en el Netduino y también
es enviada cifrada por parte de la aplicación móvil.
El siguiente paso fue realizar la implementación del manejo de la unidad de persistencia del
dispositivo Android. En esta se almacena la información de los dispositivos que se obtuvo
por última vez por parte del Netduino, la información ahí almacenada consiste en los mismos
campos que los manejados en el Netduino, excepto que se añaden los campos de tiempo y
estado (time and status), estos campos sirven para almacenar la hora de la última lectura del
dispositivo y el estado en el que se encontraba en esa última lectura. Para esto se usa una base
de datos SQL Lite que está incorporada a la plataforma Android, las tablas en las que se
almacena la información se llaman “netduino” y ”waspmote”. La información allí
almacenada puede ser recuperada, actualizada o eliminada.
3.3 Implementación GCM
Para poder enviar alertas a la aplicación móvil, así esta no se esté ejecutando en el dispositivo
Android, se hace uso del Google Cloud Messaging for Android, o GCM, como se ha
explicado anteriormente. Para hacer uso de este servicio se obtuvo una llave para hacer uso
de este API de Google. Con esta llave la aplicación móvil puede registrarse automáticamente
al servicio y así obtener su identificador de registro; esta llave también es requerida para
enviar alertas desde Netduino.
Primero fue necesario registrar el uso del servicio en el Manifiesto de la aplicación y luego
implementar los métodos necesarios para la recepción de los mensajes siguiendo lo
establecido en las guías de GCM provistas por Google [46]. Esto permite que la aplicación
móvil pueda responder acordemente a la alerta. En esta implementación la alerta se recibe en
Página 68
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
el dispositivo Android mostrándose en la barra de notificaciones del sistema, esta muestra
cuando el LED del Netduino ha sido encendido o apagado manualmente usando el botón que
este tiene incorporado en su tarjeta. En este mensaje también se envía la IP pública para poder
comunicarse con el Netduino usando el servicio NAT del router provisto por la ISP del hogar
donde se encuentra.
El envío de alertas a los servidores GCM para ser redirigidas al dispositivo Android se
realizan mediante peticiones HTTP POST, donde se incluye en sus parámetros los datos a
enviar así como el identificador del móvil. Pero ya que la petición debe realizarse sobre
HTTPS, es imposible para el Netduino realizarla, ya que no soporta SSL. Para solucionar este
inconveniente se desarrolló un Proxy para redirigir las peticiones.
Este Proxy permite al Netduino enviar las solicitudes usando HTTP y no HTTPS, el mensaje
que es enviado también es cifrado usando RC4 para agregar la capa de seguridad necesaria.
Netduino envía una petición HTTP POST al Proxy con sus parámetros cifrados, el Proxy
descifra esta información y la redirige a los servidores GCM de Google.
El Proxy se encuentra alojado en el servicio de computación en la nube Google App Engine.
Este consiste en un Servlet Java Http que sólo responde a peticiones POST, descifra los
parámetros de la petición y los reenvía mediante HTTPS a los servidores GCM junto con la
IP y Puerto desde los cuales arribó la solicitud. Consecuentemente con las implementaciones
ya realizadas de cifrado, el Proxy también implementa un algoritmo RC4 con llave simétrica.
Esta implementación apoya la premisa de la no intrusividad para el usuario ya que este proxy
es desplegado fuera de su ambiente y es imperceptible para él.
3.3 Diagramas de clase del prototipo
Esta sección comprende los diagramas de clase del prototipo del sistema que fue
desarrollado.
Página 69
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
3.3.1 Diagrama de clases aplicación Netduino
3.3.2 Diagrama de clases aplicación Android
Página 70
Figura 19. Diagrama de clases aplicaicón Netduino
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Figura 20. Diagrama de Clases aplicación Android
3.3.1 Diagrama de clases aplicación Proxy GCM
Figura 21. Diagrama de clases Proxy GCM
Es importante resaltar que las clases GCM Sender, GCM Message y GCM MulticastResult
son provistas por Google junto al SDK de Android mediante el archivo Java gcm-server.jar.
Página 71
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Estas clases facilitan la creación de mensajes para enviar a los servidores GCM. Por último la
clase HttpServlet la cual extiende SendMessageServlet es la distribuida en el paquete javax.-
servlet.http.
En esta sección se especificó el proceso mediante el cual fue realizado un prototipo de
software que permite comunicar dispositivos móviles con dispositivos domóticos a través de
Internet. Este desarrollo se basó en lo realizado en las secciones anteriores respecto a las
expectativas de usuario determinadas por requerimientos y al diseño arquitectural propuesto.
También se especificaron los dispositivos y tecnologías usadas durante el desarrollo del
proyecto.
IV - RESULTADOS Y REFLEXIÓN SOBRE LOS MISMOS
Resultados de estudio de requerimientos
La realización de este trabajo de estudio de requerimientos presenta una propuesta
complementaria a los trabajos existentes orientados a apoyar las actividades que se efectúan
dentro de la ingeniería de requerimientos [13][25][29][30][31] que permite especificar de
manera más clara, con limites y restricciones mejor definidos, los requerimientos de sistema
que se deben cumplir en el desarrollo de un proyecto de software sobre sistemas domóticos.
Esto también pretende apoyar la identificación de soluciones que apoyen los múltiples
desafíos que la creación de redes domóticas y de automatización [8][21][23][27].
Se realizó una propuesta para identificar con mayor facilidad los distintos factores que
influyen en la identificación y especificación de requerimientos que para los sistemas basados
en contexto y domóticos presenta una labor extensa [13]. Mediante lo propuesto no sólo se
logra identificar los distintos ambientes en los que un usuario interactúa con el sistema, sino
también establecer la base para la construcción de requerimientos no funcionales asociados a
los elementos de contexto.
La propuesta realizada también permitiría realizar una trazabilidad más efectiva de todos los
productos que se obtienen durante todo el proceso de ingeniería de software, ya que es
posible identificar claramente los elementos directamente afectados por una alteración en las
necesidades de usuario, requerimientos de sistema, contextos de uso, etc. Y de esta forma
Página 72
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
lograr mayor calidad y mejor aceptación del sistema por parte de los usuarios, lo que a su vez
permitiría una mayor expansión y adopción de los sistemas de automatización, o domóticos,
en los hogares[10].
Resultados de Arquitectura
El resultado que se obtuvo en la fase de arquitectura de este trabajo de grado especificó la
distribución de componentes y la comunicación entre los mismos para poder realizar de
manera adecuada la implementación de las aplicaciones de software; esto se basó en las
restricciones arquitecturales que fueron establecidas por los requerimientos que fueron
identificados en los resultados obtenidos por la fase de requerimientos.
La arquitectura planteada permitió la correcta implementación de software realizado en la
fase de Implementación, y además debido a que el planteamiento de los mecanismos de
comunicación comprende en uso de tecnologías y protocolos de especificación abierta, se
permite el uso de distintos tipos de dispositivos como parte del sistema. Esto permite que
dispositivos móviles de distintos fabricantes y con diversos sistemas operativos puedan
establecer una transmisión exitosa con el módulo de interface con la red domótica mientras
este tenga las capacidades necesarias para el uso de HTTP sobre TCP/IP y acceso a una
conexión a Internet; esto permite el desarrollo de nuevas aplicaciones móviles así como la
creación de nuevas herramientas de consulta, como un portal web o aplicaciones de escritorio
para proveer al usuario con más alternativas para la consulta de información, pero siempre
teniendo en cuenta la importancia del uso de los dispositivos móviles para crear sistemas
ubicuos. De la misma forma el dispositivo de interface entre la red domótica e Internet puede
ser implementado por cualquier dispositivo que soporte una interface de comunicación
TCP/IP y cuente con una interface UART, de esta forma cuando haya en el mercado nueva
tecnología que permita a los microcontroladores contar con mayores capacidades de cómputo
se puede implementar este como intermediario en la comunicación. Al hacer uso de UART o
similares se puede realizar la implementación de interfaces de tecnologías de comunicación
diversas que son usadas por componentes de Observación y Análisis en el dispositivo
Servidor, de esta forma es posible conectar al servidor interfaces de comunicación de diversas
Página 73
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
tecnologías para así comunicarse con diversos dispositivos logrando una red heterogénea a
nivel de dispositivo y de tecnología de comunicación.
Resultados de Implementación
Figura 22. Imagen del resultado de implementación
El prototipo que resultó de este trabajo comprende varios de los aspectos a considerar para
lograr implementar sistemas domóticos exitosos. Una de las características principales es la
baja intrusividad que un microcontrolador como el Netduino lleva a su hogar, este ocupa un
espacio mucho menor al de un router tradicional y puede ser alimentado por medio de su
cable USB o una conexión eléctrica de sólo 7.5 voltios; además no debe realizar
mantenimiento del dispositivo ya que funciona con sólo conectarlo al router del hogar usando
un cable Ethernet y una fuente eléctrica la cual posiblemente no sea un inconveniente debido
a la cercanía física que debe tener con el router.
A pesar de la limitada capacidad de cómputo del Netduino se pudo observar que los tiempos
de respuesta obtenidos al momento de encender o apagar el LED del Netduino no superaron
los 1.6 segundos al realizar la solicitud sobre la LAN casera, y 2.5 segundos al usar Internet
como medio de comunicación, este tiempo fue medido desde el momento en el que se
oprime el botón en la aplicación del dispositivo Android hasta observar la respuesta reflejada
en el LED que se encuentra en el Netduino (si éste se encendía o apagaba).
Página 74
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Con la implementación de esta solución basada en el uso del Netduino se puede observar que
lograr la interoperabilidad entre dispositivos y tecnologías en una red domótica es posible. El
uso de un mecanismo como UART permite conectar al Netduino las interfaces de
comunicación necesarias, y éste las puede interpretar fácilmente. El uso de Zigbee, por ser
una especificación abierta hizo posible lograr identificar la estructura de los mensajes
recibidos, y también poder crear el mecanismo para enviar mensajes; además por los estudios
ya hechos sobre Zigbee y sus ventajas en su uso en sistemas de redes de sensores dan las
bases para afirmar que es una especificación adecuada para la comunicación de dispositivos
domóticos, exceptuando claro los dispositivos que transmiten multimedia, ya que la tasa de
transferencia de Zigbee no es apta para este uso. En caso de contar con dispositivos
domóticos que solo cuenten con interfaces Wi-Fi la solución planteada puede comunicarse
también con estos sin problemas al estar conectado directamente a la red WLAN mediante su
interface Ethernet con el router. Finalmente el uso de HTTP como medio para la
comunicación desde y hacia el Netduino permite realizar la implementación de clientes de
manera eficaz ya que se cuenta con un protocolo ampliamente usado y documentado, por lo
que es posible crear cualquier cliente que sea capaz de generar peticiones HTTP.
Se tuvieron en cuenta consideraciones de seguridad durante la implementación, todas las
comunicaciones inalámbricas del sistema son cifradas para evitar la fácil identificación del
mensaje que está siendo enviado. En el caso de las comunicaciones Netduino-Android con la
implementación del algoritmo de cifrado RC4 se observó que los mensajes que se transmitían
lo hacían cifrados, esto se observó haciendo uso de la herramienta de monitoreo Wireshark,
que permitió hacer sniffing de los paquetes HTTP. De la misma manera el API de Zigbee para
los Xbee usados permite el uso de llaves de seguridad, que por medio del algoritmo AES
cifran la comunicación en el medio para agregar una capa de seguridad a los mensajes incluso
en el remoto caso que un individuo con un sniffer de mensajes Zigbee logre interceptar los
mensajes.
Otro resultado importante es el uso de dispositivos móviles como mecanismos de control y
monitoreo; estos dispositivos son en la mayoría de casos de carácter personal, por lo que el
dueño es quién tiene el control absoluto sobre el mismo, de forma tal que el tiene el control
sobre lo que otros vean en su móvil. Además siendo los dispositivos móviles uno de los
Página 75
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
elementos de computación ubicua más comunes actualmente se logra que la capacidad de
control de la red domótica del usuario esté con el donde quiera que esté, gracias también a los
avances en tecnologías de comunicación móviles y el gigantesco aumento en las capacidades
de cómputo de los mismos, que permiten entre otros establecer mecanismos de comunicación
seguros, como HTTPS. La aplicación móvil desarrollada para Android permite la
comunicación a través de Internet gracias a las características inherentes del dispositivo. Al
implementar el almacenamiento de las últimas lecturas de los dispositivos domóticos en el
móvil, también se provee al usuario con una experiencia que no carece nunca de falta de
información, así el usuarios e encuentre en una zona sin red, puede observar y tomar
decisiones basado en las lecturas precias realizadas.
Imágenes de la aplicación en funcionamiento se presentan a continuación, incluyendo la
notificación recibida de eventos cuando la aplicación está cerrada (primera imagen de la
izquierda).
Figura 23 GUI aplicación Android
V – CONCLUSIONES, RECOMENDACIONES Y TRABAJOS FUTUROS
Página 76
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
1. Conclusiones
Se puede evidenciar que el proceso de Ingeniería de Requerimientos basado en sistemas de
automatización puede desarrollarse de manera clara y ordenada, lo que permite que el
proceso sea desarrollado formalmente. Al lograr un levantamiento de requerimientos que
permita conocer de manera concisa los requerimientos de usuario se puede realizar un estudio
para lograr generalizar las expectativas de los usuarios en el uso de sistemas domóticos. Un
proceso de especificación claro permite también establecer las pautas claras de desarrollo de
sistemas de automatización el cual puede ser extendido también a sistemas de automatización
de naturaleza industrial o comercial. Esto permite conocer de manera clara los
Requerimientos de usuario y de sistema para el desarrollo exitoso en proyectos de sistemas de
información basados en domótica.
Al realizar un proceso de diseño de arquitectura de software que hace uso exclusivo de
mecanismos de comunicación de especificación abierta permite realizar una implementación
que consista de productos de distinta naturaleza y provistos por diversos fabricantes debido a
que el diseño fue realizado con uno de los requerimientos más importantes en mente, la
heterogeneidad. El diseño de sistema permite la implementación de un sistema que no
requiera al usuario cambiar la infraestructura física de su hogar, ya que es basado en el uso de
tecnologías de comunicación inalámbricas y el uso de dispositivos que son comúnmente
encontrados en el hogar del cliente, cómo es el caso del punto de acceso a Internet y los
dispositivos móviles. Por consiguiente la implementación en los distintos componentes del
sistema pueden ser realizados por distintos dispositivos logrando una red de dispositivos
heterogénea.
Los resultados que fueron obtenidos durante el desarrollo de este trabajo permiten evidenciar
lo qué es posible lograr en el área de computación ubicua basado en tecnologías de
comunicación existentes. Se observó que es posible establecer interfaces de comunicación
eficientes en términos de rendimiento y coste haciendo uso exclusivo de microcontroladores,
sin las necesidad de un equipo de computación más avanzado como es el caso de un
computador de escritorio. Gracias a que estos microcontroladores son programados de forma
tal que únicamente cumplan una necesidad específica, sólo basta con conectar el mismo a una
Página 77
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
conexión Ethernet y a una fuente eléctrica, no requieren intervención del usuario para que
este cumpla sus labores y por consiguiente no requiera realizar mantenimiento del mismo.
Acorde a las conclusiones realizadas anteriormente se puede concluir que el objetivo
establecido fue cumplido, se logró realizar un prototipo de sistema que cumple con varios de
los retos planteados en la creación de sistemas de información ubicuos. El sistema
implementa mecanismos de seguridad que ayuda a ocultar la información sensible que es
transmitidas entre los componentes mediante el uso de algoritmos de cifrado. También se
logró dar una solución que cumple con las necesidades en los requerimientos de
mantenibilidad, interoperabilidad, rendimiento y escalabilidad. El uso de dispositivos móviles
como medio de consumo de servicios apoya el concepto de ubicuidad a lograr hacer uso de
dispositivos con los que ya cuenta el usuario que permiten la portabilidad de los mecanismos
de consumo de servicios de sistemas de información por parte de los usuarios. Mediante la
implementación realizada fue posible que mediante el uso de HTTP sobre TCP/IP y el uso de
Internet comunicar los servicios provistos por dispositivos domóticos en una red casera de
dichos dispositivos con un dispositivo móvil, particularmente un teléfono inteligente con
sistema operativo Android.
El prototipo realizado realiza una aproximación para cubrir las necesidades de seguridad que
debe cumplir el sistema. Se implementaron mecanismos que permiten únicamente a usuarios
autorizados realizar operaciones de control en el sistema domótico, así como la
implementación de un algoritmo de cifrado para agregar una capa de seguridad a la
transmisión de datos. Se pudo ver reflejada la interoperabilidad de dispositivos gracias al uso
de puertos UART provistos por el Netduino fue posible interactuar con dispositivos que usan
Zigbee como medio de comunicación en la red domótica, aunque no se encontraba dentro del
alcance del prototipo haciendo uso de UART también es posible crear interfaces con
tecnologías como Bluetooth, X10, entre otras; y adicionalmente a que el Netduino cuenta con
las capacidades de comunicarse por medio de TCP/IP sobre la red LAN/WLAN del hogar,
también sería posible comunicarse con dispositivos de la red local que usen TCP/IP, como
podría ser el caso de un televisor inteligente.
Página 78
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
2. Recomendaciones
Se recomienda que en los trabajos futuros que se realicen sobre esta área, se certifique que se
cuenta con toda la documentación necesaria al momento de usar plataformas, dispositivos y
tecnologías de fabricantes específicos, y que además el código fuente provisto sea consistente
con dicha documentación. Ya que al hacer rastreo de errores en una de las plataformas ajenas
a quien desarrolló este proyecto tomó una gran cantidad de tiempo a la inconsistencia y falta
de coherencia en los archivos de código fuente. También se recomienda contar con estudios
recientes que pueden desarrollarse después del desarrollo de este proyecto sobre los procesos
de Ingeniería de Requerimientos aplicada a sistemas de automatización ya que en varios de
los trabajos estudiados se plantean trabajos futuros de interés sobre el área. Y sobre la misma
razón hacer estudios sobre nuevas aplicaciones, tecnologías e implementaciones de sistemas
de tecnologías de comunicación orientadas a domótica y automatización. Por último se
recomienda incentivar al Departamento en realizar una mayor cantidad de proyectos de
investigación sobre el área de redes de sensores a partir de la cual se pueden derivar muchos
proyectos aplicados a distintas áreas del conocimiento.
3. Trabajos Futuros
Para la continuación de la investigación del estudio de requerimientos aplicados a sistemas
domóticos deben ser realizados casos de estudio con clientes reales que permitan obtener
resultados en un ambiente de desarrollo real, el proyecto del caso de estudio aplicaría lo
propuesto en el estudio de requerimientos en la producción de un sistema de automatización
preferiblemente para sistemas domóticos pero también aplicaría para proyectos industriales o
comerciales de pequeña escala, de la misma forma mostraría con resultados prácticos el
soporte que proveen las soluciones planteadas en las prácticas de trazabilidad en un proyecto
de ingeniería de redes domóticas. También se realizaría el planteamiento de propuestas que
solucionen los problemas adicionales que presenta el diseño, desarrollo y uso de redes caseras
basados en el soporte para identificación de requerimientos que ha sido desarrollada en este
trabajo. Finalmente profundizar en las actividades de Análisis, Validación y Administración
de Requerimientos orientado a sistemas de automatización y domóticos.
También existe una gran cantidad de proyectos futuros que se pueden realizar en el área,
Página 79
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
realizar un proyecto de investigación orientado a la aplicación de mecanismos de seguridad
de trasmisión de datos orientados a redes de sensores con poca capacidad de cómputo y
estudiar la eficiencia del cifrado. Se plantea también como trabajo futuro el desarrollo de
proyectos de minería de datos, orientado al análisis de flujo de datos que se obtienen a partir
de las lecturas de sensores en una red de dispositivos propósito específico y bajo consumo,
para poder así estudiar y analizar los flujos de datos y así implementar mecanismos que
realicen acciones acorde a la información obtenida. Otro trabajo futuro a realizar es la
implementación de aplicaciones que acorde al contexto del usuario realicen las acciones
adecuadas acorde a su ubicación (por ejemplo apagar los electrodomésticos al salir de casa).
Finalmente se plantea realizar implementaciones con productos de mayor escala a los usadas
como dispositivos de la red domótica, como el uso de switches eléctricos que puedan
controlar el sistema de luces, sistemas de control de temperatura, entre otros; y para lograrlo
tener un conocimiento más profundo en el diseño de circuitos eléctricos.
Página 80
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
VI - REFERENCIAS Y BIBLIOGRAFÍA
1. Referencias[1] S. Poslad, Ubiquitous Computing: Smart Devices, Environments and Interactions, 1st ed.
Wiley, 2009.[2] C. Dixon, R. Mahajan, S.Agarwal,A. J. Brush, B. Lee, S. Saroiu, andV. Bahl,“The home
needs an operating system (and an app store),” in Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks, New York, NY, USA, 2010, pp. 18:1–18:6.
[3] Rosendahl and G. Botterweck, “Mobile Home Automation - Merging Mobile Value Added Ser vices and Home Automation Technologies,” in Management of Mobile Business, 2007. ICMB 2007. International Conference on the, 2007, p. 31–31.
[4] Z. Alkar, H. S. Gecim, and M. Guney, “Web Based ZigBee Enabled Home Automation System,” in Proceedings of the 2010 13th International Conference on Network-Based Information Systems, Washington, DC, USA, 2010, pp. 290–296.
[5] K. Gill, Shuang-Hua Yang, Fang Yao, and Xin Lu, “A zigbee-based home automation system,” IEEE Transactions on Consumer Electronics, vol. 55, no. 2, pp. 422-430, May 2009
[6] C. Eckel, G. Gaderer, and T. Sauter, “Implementation requirements for Web-enabled appliances - a case study,” in Emerging Technologies and Factory Automation, 2003. Proceedings. ETFA ’03. IEEE Conference, 2003, vol. 2, pp. 636– 642 vol.2.
[7] T. Mantoro, M. A. Ayu, and E. E. Elnour, “Web-enabled smart home using wireless node infrastructure,” in Proceedings of the 9th International Conference on Advances in Mobile Computing and Multimedia, New York, NY, USA, 2011, pp. 72–79.
[8] W. K. Edwards and R. E. Grinter, “At Home with Ubiquitous Computing: Seven Challenges,” in Proceedings of the 3rd international conference on Ubiquitous Computing, London, UK, UK, 2001, pp. 256–272.
[9] C. Walker, Getting Started with Netduino. O’Reilly Media, 2012.[10] W. K. Edwards, R. E. Grinter, R. Mahajan, and D. Wetherall, “Advancing the state of home
networking,” Commun. ACM, vol. 54, no. 6, pp. 62–71, Jun. 2011.[11] G. Cronin, “eXtreme Solo, A case study in single developer eXtreme Programming”.
University of Auckland [12] K. Beck, Extreme Programming Explained: Embrace Change, US ed. Addison-Wesley
Professional, 1999. [13] V. Castelli, P. Thomas, R. Bertone, and A. Oliveros, “A requirements engineering process
extended to context information management,” in 2011 Fifth International Conference on Research Challenges in Information Science (RCIS), 2011, pp. 1–6.
[14] European Research Consortium for Informatics and Mathematics, “The future web”, in ERCIM News number 72, January 2008, pp. 54-55
[15] Zigbee Alliance. “Understanding Zigbee”, [Online] available at: http://www.zigbee.org/About/UnderstandingZigBee.aspx. Accesed on May 27
[16] “IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) Amendment 3: Alternative Physical Layer Extension to support the Japanese 950 MHz bands,” IEEE Std 802.15.4d-2009 (Amendment to IEEE Std 802.15.4-2006), pp. c1 –27, 2009.
[17] C. Pfister, Getting Started with the Internet of Things: Connecting Sensors and Microcontrollers to the Cloud, 1st ed. O’Reilly Media, Inc., 2011.
Página 81
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
[18] M. Weiser, “Hot topics-ubiquitous computing,” Computer, vol. 26, no. 10, pp. 71–72, Oct. 1993.
[19] L. Collares, C. Matthews, J. Cappos, Y. Coady, and R. McGeer, “Et (smart) phone home!,” in Proceedings of the compilation of the co-located workshops on DSM’11, TMC’11, AGERE!’11, AOOPES’11, NEAT’11, & VMIL’11, New York, NY, USA, 2011, pp. 283–288.
[20] K. L. Calvert, W. K. Edwards, N. Feamster, R. E. Grinter, Y. Deng, and X. Zhou, “Instrumenting home networks,” SIGCOMM Comput. Commun. Rev., vol. 41, no. 1, pp. 84–89.
[21] C. Beckel, H. Serfas, E. Zeeb, G. Moritz, F. Golatowski, and D. Timmermann, “Requirements for smart home applications and realization with WS4D-PipesBox,” in 2011 IEEE 16th Conference on Emerging Technologies & Factory Automation (ETFA), 2011, pp. 1–8.
[22] Accenture Communications & High Tech Solutions. “Big Trouble with ‘No Trouble Found’ Returns” Technical Report. Dublin, Ireland 2008. [Online]. Available: http://www.accenture.com/siteCollectionDocuments/PDF/22701_returnsrepairsrvn_v04lr.pdf. [Accesed 24-Mar-2012]
[23] A. J. B. Brush, B. Lee, R. Mahajan, S. Agarwal, S. Saroiu, and C. Dixon, “Home automation in the wild: challenges and opportunities,” in Proceedings of the 2011 annual conference on Human factors in computing systems, New York, NY, USA, 2011, pp. 2115–2124
[24] V. Miori, D. Russo, and M. Aliberti, “Domotic technologies incompatibility becomes user transparent,” Commun. ACM, vol. 53, no. 1, pp. 153–157, Jan. 2010.
[25] Hong, Chiu, Shen, “Requirements elicitation for the design of context- aware applications in a ubiquitous environment”, Proceedings of the 7th international conference on Electronic commerce, 2005.
[26] I. Sommerville, Software Engineering, 9th ed. Addison Wesley, 2010.[27] E. S. Poole, C. A. Le Dantec, J. R. Eagan, and W. K. Edwards, “Reflecting on the invisible:
understanding end-user perceptions of ubiquitous computing,” in Proceedings of the 10th international conference on Ubiquitous computing, New York, NY, USA, 2008, pp. 192–201.
[28] Federal Communications Comission, “Bureaus & Offices“ [Online] Available: http://www.fcc.gov/bureaus-offices [Accesed: 25-Mar-2012]
[29] Kolos, Mazuryk, Poulisse, van Eck, Requirements Engineering for Pervasive Services,”. 2nd Workshop on Building software for pervasive computing. October 1”6, 2005.
[30] J. Shen and X. Shen, “User Requirements in Mobile Systems”, Proceedings of the 2001 Americas Conference on Information Systems, August 2-5, 2001, pp. 1341-1344.
[31] Jianchu Huang, Hongji Yang, and Lei Liu, “Reconciling Requirements and Implementation via Reengineering for Context-Aware Service Evolution,” in Computer Software and Applications Conference Workshops (COMPSACW), 2011 IEEE 35th Annual, 2011, pp. 464–469.
[32] S. P. Lim and G. H. Yeap, “Centralised Smart Home Control System via XBee transceivers,” in 2011 IEEE Colloquium on Humanities, Science and Engineering (CHUSER), 2011, pp. 327 –330.
[33] Daintree Networks, “Getting Started with ZigBee and IEEE 802.15.4”, February 2008, [Online] Available: http://www.daintree.net/downloads/whitepapers/zigbee_primer.pdf
[34] T. T. Chen and M. Lee, “Ubiquitous Computing in Prospect: A Bibliographic Study,” in International Symposium on Ubiquitous Multimedia Computing, 2008. UMC ’08, 2008, pp. 57 –62.
[35] D. Lupiana, C. O’Driscoll, and F. Mtenzi, “Taxonomy for ubiquitous computing environments,” in First International Conference on Networked Digital Technologies, 2009. NDT ’09, 2009, pp. 469 –475.
Página 82
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
2. Bibliografía
[36] ZigBee Alliance, “ZigBee Specification”, ZigBee Document 053474r17 January 17, 2008.[37] Michal Varchola, Miloš Druarovsky, “Zigbee Based Home Automation Wireless Sensor
Network”, Acta Electrotechnica Et Informatica No. 4, Vol. 7, 2007.[38] Kruchten Philippe, The “4+1” view model of software architecture, Noviembre 1995.
[Online]; Available: http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf.
[39] RUP, Software Architecture Document; [Online] Available: http://sophia.javeriana.edu.co/~cbustaca/Arquitectura%20Software/Proyectos/Plantillas.zip
[40] Bass Len, Clements Paul, Kazman Rick, Architecture Software in Practice, Editorial Addison Wesley, Segunda Edición, Abril 2003
[41] Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc
[42] Libelium Comunicaciones Distribuidas S.L, “Waspmote, the sensor device for developers” [Online] Available at: http://www.libelium.com/products/waspmote accesed on Aug 3 2012
[43] C. Walker, Getting Started with Netduino. O’Reilly Media, 2012.[44] Secret Labs LLC, “Netduino Plus”, Technical Specification. [Online] Available at:
http://www.netduino.com/netduinoplus/specs.htm Accessed on May 10, 2012. [45] Google Inc., “Google App Engine“, Googe Developers. [Online] Available at:
https://developers.google.com/appengine/ Accesed Aug 25, 2012.[46] Google Inc., “Google Cloud Messaging for Android“, Google Developers [Online] Available
at: http://developer.android.com/guide/google/gcm/index.html Accesed Sept 18, 2012. [47] C. Larman, Applying UML and Patterns, An introduction to Object-Oriented Analysis and
Design and Iterative Development, Third Edition. New Jersey: Prentice Hall. 2010[48] Digi International Inc., “Digi Xbee”, Xbee wireless RF modules [Online] Abailable at:
http://www.digi.com/xbee/ Accessed Sep[49] Libelium Comunicaciones Ditribuidas, “Waspmote Development” [Online] Available at:
http://www.libelium.com/development/waspmote Accesed Sept 20, 2012.[50] Google Inc., “Android Developers”, Google Developers [Online] Available at:
http://developer.android.com/develop/index.html Accesed Oct 18, 2012[51] Lars Vogel, “Android Development”, Vogella [Online] Avaiable at:
http://www.vogella.com/android.html Accesed Nov 1, 2012[52] Simone Spagna, “RC4 Encryption Algorithm: C# Version”, Code Project [Online] Available
at: http://www.codeproject.com/Articles/5068/RC4-Encryption-Algorithm-C-Version Accesed Nov 20, 2012.
[53] Google Inc., “GCM Andvanced Topics”, Google Services [Online] Available at: http://developer.android.com/google/gcm/adv.html#multi-senders Accesed Oct 15, 2012
[54] Robert Faludi, Bulding Wireless Sensor Networks. A Practical Guide to the Zigbee Mes Networking Protocol, First Edition. Sebastopol, California: O’Reilly Media Inc.: 2010
[55] Michael Schwarz, “The .NET Micro Framework Toolkit”. CodePlex [Online] Avalable at: http://mftoolkit.codeplex.com
[56] NXP Semiconductors. “Zigbee e-learning course”, Jennic Wireless Microcontrollers. [Online] Available at: http://www.jennic.com/elearning/zigbee/files/content_frame.htm
Página 83
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
VII - ANEXOS
Anexo 1. Glosario
Automatización : El uso de máquinas, sistemas de control y sistemas de información para
optimizar la producción de bienes.
Domótica: Conjunto de sistemas que tienen como objetivo la automatización del hogar.
Microcontrolador: Circuito integrado pequeño que contiene en el mismo chip el núcleo del
procesador, memoria y periféricos de entrada salida.
SDK: Software development kit, es un set de herramientas de desarrollo de software que
permite la creación de aplicaciones de software para una plataforma específica.
Framework: En el desarrollo de software es una estructura de soporte definida en la cual
otro proyecto de software puede ser organizado y desarrollado.
Micro .NET Framework: Plataforma de código abierto .NET orientada al desarrollo de
software en sistemas embedidos.
Stack: Es una implementación de una suite de protocolos de comunicación en redes de com-
putadores.
Xbee: Marca de módulos de comunicación por radio frecuencia de Digi International.
Android: Sistema operativo desarrollado por Google diseñado para su uso en tabletas y telé-
fonos inteligentes.
GCM: Google Cloud Messaging es un servicio que permite a desarrolladores enviar datos de
servidores de aplicación a dispositivos con la plataforma Android.
GAE: Google App Engine es servicio de computación en la nube, plataforma como servicio
para el desarrollo de aplicaciones web.
Página 84
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
ISP: Internet service provider, organización que que ofrece a sus usuarios acceso a Internet y
servicios relacionados.
NAT: Network address translation es el proceso de modificación de la dirección IP de los
encabezados de paquetes IP mientras está en transito en un dispositivo de enrutamiento.
XML: Xtensible Markup Language, propone como un estándar para el intercambio de infor-
mación estructurada entre diferentes plataformas.
Tasa de Baudios: Número de unidades de señal por segundo en comunicaciones.
Protoboard (breadboard): Es una base reutilizable para la construcción para el prototipado
de elementos electrónicos.
UART: Universal Asynchronous Receiver/Transmitter es una pieza de hardware que traduce
datos entre formas serial y paralela.
Tarjeta SD: Secure Digital, tarjeta de memoria no volátil.
Firmware: Combinación de memoria persistente, código y los datos almacenados.
TCP/IP: Set de protocolos de comunicación usado en Internet y redes similares para permitir
la trasmisión de datos entre computadores.
HTTP: Hypertext transfer protocol, protocolo de aplicación para sistemas de información
distribuidos para la comunicación de datos.
HTTPS: Hypertext Transfer Protocol Secure, protocolo de aplicación para comunicaciones
seguras sobre una red de computadores.
SSL: Secure sockets layer, protocolo de cifrado que provee seguridad de comunicación sobre
Internet.
Página 85
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Anexo 2. Post-Mortem
En esta sección se presenta un Post-Mortem del trabajo de grado que fue realizado en donde
se compara lo que fue desarrollado en la propuesta y lo real.
1. Metodología propuesta vs. Metodología realmente utilizada.
Las fases que fueron la base fundamental para el desarrollo, donde la fase de requerimientos
fue fundamental para el desarrollo y consecuente de la fase de arquitectura y de la misma
forma a la fase de implementación.
La metodología que fue usada en el desarrollo de la fase de requerimientos fue el uso de lo
estudiado en el Marco Teórico, se desarrolló una propuesta para el manejo de las actividades
de levantamiento y especificación de requerimientos acorde a lo planteado en la propuesta,
con la limitante de no contar con un cliente específico para el desarrollo.
La metodología de documentación de arquitectura 4+1 fue adaptada para el desarrollo de este
proyecto donde no se cuenta con un cliente y por lo tanto no se pueden desarrollar varias de
las vistas especificadas para desarrollar la documentación.
Se aplicó en la fase de implementación una metodología de desarrollo ágil, como lo fue
eXtreme Programming, en la cual el desarrollo fue realizado por medio de iteraciones que
luego fueron probadas y hasta que no se pasara estas pruebas de iteración no se continuaba a
una fase siguiente de desarrollo. Y gracias a esta metodología iterativa se lograron realizar
mejoras en iteraciones anteriores, incluidas las realizadas en la fase de arquitectura, como lo
fue el desarrollo inesperado de la aplicación Proxy para mensajes GCM implementada en
Google App Engine.
2. Actividades propuestas vs. Actividades realizadas.
La mayoría de actividades se realizaron según lo que se esperaba. Sin embargo ciertas
actividades tomaron más importancia y tiempo que las otras, particularmente la actividad de
realizar la codificación del módulo de administración de dispositivos domóticos en una red
casera.
Página 86
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
También hubo inconvenientes en las actividades de requerimientos aplicadas a sistemas
domóticos, en parte por la poca documentación y proyectos realizados sobre el tema; pero
que en realidad tomó más tiempo del esperado para realizar la actividad ya que tuvo que
tomar más tiempo realizando la búsqueda.
Finalmente las actividades de prueba fueron desarrollados al final de cada actividad de
desarrollo para comprobar la funcionalidad implementada y realizar oportunamente los
cambios en cada iteración.
3. Efectividad en la estimación de tiempos del proyecto
Todas las fases de desarrollo tomaron tiempos reales para realizarlos diversos a los que se
habían planteado, con la excepción de la elaboración del estado del arte.
Fase Actividad Esperadas Reales
Estado
del arte
Realizar búsqueda de bibliográfica sobre sistemas
de automatización en el hogar y qué tecnologías
son utilizadas
5 5
Realizar búsqueda de bibliográfica sobre
computación móvil y ubicua
5 4
Realizar búsqueda de bibliográfica sobre
tecnologías de comunicación orientadas a
dispositivos domóticos, Zigbee, IEEE 802.15.4
5 6
Realizar búsqueda de bibliográfica sobre técnicas y
tecnologías de seguridad en la comunicación de
dispositivos móviles
5 4
Desarrollar el marco teórico a partir de la 10 10
Página 87
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
investigación realizada
Requer
imiento
s
Establecer qué requerimientos deben ser
satisfechos por un sistema domótico
15 15
Proponer un método para la especificación de
requerimientos en sistemas de esta naturaleza.
(Desarrollo de las tablas de levantamiento y
especificación)
15 18
Establecer los criterios que deben ser cumplidos al
hacer uso de distintas tecnologías de comunicación
10 7
Definir qué tecnologías existentes de
comunicación son las más adecuadas para un
sistema domótico
8 8
Arquite
ctura
De acuerdo a los requerimientos identificados
definir el modelo arquitectónico de la solución a
plantear.
20 20
Definir el modelo arquitectónico específico para la
implementación según las tecnologías escogidas.
10 18
Para lo anteriormente dicho, documentar:
1. Vista lógica
2. Vista de desarrollo
3. Vista de proceso
4. Vista física
5. Escenarios
15 20
Página 88
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Imple
mentac
ión y
prueba
s
Realizar la codificación del módulo de
administración y gestión de comunicación de
dispositivos domóticos en una red casera.
30 50
Realizar la codificación del gateway que permitirá
enviar y recibir mensajes del modulo de gestión de
los dispositivos domóticos a dispositivos móviles a
través de Internet.
30 35
Realizar la codificación de la aplicación del
dispositivo móvil del sistema mediante el cual se
enviarán solicitudes a los dispositivos de la red
casera y se consultará el estado de los mismos.
30 30
Realizar pruebas de funcionamiento básico de la
implementación.
8 5
Realizar pruebas de seguridad del sistema acorde a
lo implementado.
15 8
Realizar pruebas de tiempos de respuesta de la
implementación.
7 4
A pesar que hubo actividades que tomaron un tiempo inferior al planteado como lo fueron las
actividades de pruebas hubo varias que tomaron un tiempo significativamente mayor a aquel
que se esperaba.
Las actividades de arquitectura tomaron mayor tiempo del esperado por sucesos inesperados
que ocurrieron, como lo fue la implementación inesperada del Proxy para GCM, lo que llevo
a cambiar el diseño arquitectural del sistema.
Página 89
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
La actividad más afectada fue el desarrollo del módulo de comunicación con sistemas
domóticos debido a que la documentación provista por Libelium no ha provisto una ayuda
eficiente al momento de hacer rastreo de unos errores que se presentaron al intercambiar
datos entre el nodo coordinador de la red Zigbee y los dispositivos Waspmote.
En general las horas reales en el desarrollo no fueron muy distintas al total de las planteadas,
a pesar que hubo actividades con cambios más drásticos de los planteados que llevaron a
tomar más horas, hubo varias con pequeños cambios que tomaron menor tiempo del
necesario; llevando de esta forma a una diferencia de horas poco significativa.
4. Costo estimado vs. Costo real del proyecto
Debido a los cambios en horas necesarias, cambió el costo de algunos elementos. También
debido a que se rompieron algunos cables durante el desarrollo fue necesario comprar otros.
En el proyecto no se realizó la compra del Xbee wireless kit, pero si de dos módulos Xbee. A
pesar que el departamento de Ingeniería de Sistemas ya contaba con los dispositivos
Waspmote, se incluyeron en los costos.
Elemento Cantidad Costo Parcial Costo Total
Hora de trabajo, ingeniero de sistemas 267 $50,000 $13,350,000
Hora de trabajo, Director de trabajo de grado 54 $70,000 $3,780,000
Papelería - $80,000 $80,000
Cable montaje protoboard 10 $450 $4,500
Protoboard 4.5cmX3,5cm 2 $8,400 $16,800
Módulo Xbee 2 $78,000 $156,000
Computador Personal 1 $2,000,000 $2,000,000
Waspmote starter kit 1 $440,000 $440,000
Página 90
Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Investigación
Visual Studio 2010 para el desarrollo en .net micro
framework (gratuito mediante dreamspark)
0 $0 $0
Netduino Plus 1 $200,000 $200,000
Total $20,027,300
Anexo 3. Especificación de casos de uso y diagramas de secuencia
En este documento se anexa la especificación de los casos de uso que fueron identificados
para la implementación de este trabajo. Revise el documento con el título “Especificación de
casos de uso y diagramas de secuencia”.
5. Efectividad en la estimación y mitigación de los riesgos del
proyecto.
Se planteó el uso de horas adicionales por semana para solucionar los problemas que se
presentaron a lo largo del proyecto, de manera tal que este pudiera entregarse en el límite de
tiempo que fue establecido. También es importante resaltar que a pesar que ciertas
actividades tomaron más tiempo del esperado el hecho que varias tomaron algunas horas
menos, sumando en total un tiempo menor por 3 horas, ayudó a lograr mitigar
satisfactoriamente los riesgos en tiempos aceptables.
A pesar que los dispositivos Waspmote fueron entregados tres semanas más tarde de los
esperado, se prosiguió con el desarrollo de otras actividades para no llevar a que ese tiempo
de espera no fuese aprovechado.
También se presentó uno de los riesgos esperados de pérdida de información en una sección
del documento la cual fue la definición del modelo arquitectónico debido a un error en el
manejo de versiones, pero solucionar este problema tomó únicamente 8 horas.
Página 91
Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008
Ingeniería de Sistemas SIDRe - CIS1230SI02
Página 92