Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1230SI02/docs/Memoria_de... · Web...

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


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

http://pegasus.javeriana.edu.co/~CIS1230SI02

Ingeniería de Sistemas SIDRe - CIS1230SI02


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


Página iiiPreparado por el Grupo Investigación Istar- Versión 1.0 – 12/03/2008


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


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


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


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


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


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


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


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


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


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


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


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



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


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



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


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



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


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


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



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)


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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


[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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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.



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


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



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


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



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


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



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


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



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


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


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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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



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


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


http://www.zigbee.org/About/UnderstandingZigBee.aspx


[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

http://www.daintree.net/downloads/whitepapers/zigbee_primer.pdf

http://www.accenture.com/siteCollectionDocuments/PDF/22701_returnsrepairsrvn_v04lr.pdf

http://www.accenture.com/siteCollectionDocuments/PDF/22701_returnsrepairsrvn_v04lr.pdf


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


http://developer.android.com/guide/google/gcm/index.html

https://developers.google.com/appengine/

http://www.netduino.com/netduinoplus/specs.htm

http://www.libelium.com/products/waspmote

http://sophia.javeriana.edu.co/~cbustaca/Arquitectura%20Software/Proyectos/Plantillas.zip

http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf

http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf


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


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



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


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



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


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



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


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



Página 92

Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1230SI02/docs/Memoria_de... · Web...

Documents

Transcript of Propuesta para Trabajo de Gradopegasus.javeriana.edu.co/~CIS1230SI02/docs/Memoria_de... · Web...