Documente Academic
Documente Profesional
Documente Cultură
Programacion de
Redes de Sensores Inalambricas para
aplicaciones domoticas
Autor
Pedro Jose Meseguer Copado
Directores
D. Manuel Jimenez Buenda
D. Fernando Losilla Lopez
Marzo de 2007
Autor Pedro Jose Meseguer Copado
eMail del Autor pedro.meseguer@gmail.com
Directores Manuel Jimenez Buenda
Fernando Losilla Lopez
eMail de los Directores manuel.jimenez@upct.es
fernando.losilla@upct.es
Ttulo del PFC Programacion de Redes de Sensores Inalambricas
para aplicaciones domoticas
Descriptores Domotica, Redes de sensores inalambricas
Resumen
A mis padres
Mahatma Gandhi
Indice General 7
Indice de Figuras 11
Indice de Tablas 13
Introduccion 15
I. Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.1. Objetivo Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.2. Objetivo Practico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Parte I. Domotica 21
Domotica 21
I. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
II. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
II.1. El sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
II.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
II.3. Topologas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
II.4. Medios de Transmision . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
III. Funcionalidad de la domotica . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
III.1. Control energetico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
III.2. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
III.3. Confort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
III.4. Telecomunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV. Tecnologas existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
IV.1. CEBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
IV.2. X-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
IV.3. LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
IV.4. EHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
IV.5. Batibus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
V. Sistema EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
V.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
V.2. Tecnologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
V.3. Topologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
V.4. Direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
V.5. Formato de las transmisiones . . . . . . . . . . . . . . . . . . . . . . . 63
V.6. Componentes EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
V.7. Ventajas de EIB. Ejemplos de aplicacion . . . . . . . . . . . . . . . . . 69
VI. Estandar Konnex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Conclusiones 171
Apendices 173
Bibliografa 213
1. Casa domotica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2. Pasarela residencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3. Detectores de presencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. Anemometro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Actuador de carril DIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Sistema centralizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Sistema distribuido, con bus de datos y red de alimentacion . . . . . . . . . . 29
8. Sistemas cableados o inalambricos . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Control energetico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Sistema de alarmas tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. Control mediante pantalla tactil . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Controlador pronto de Philips . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
13. Sistemas en funcion del tamano de edificacion . . . . . . . . . . . . . . . . . . 37
14. Normalizacion de los sistemas domoticos . . . . . . . . . . . . . . . . . . . . . 38
15. Arquitectura de CEBus, tomando como referencia el modelo OSI . . . . . . . 39
16. Instalacion X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
17. Codificacion de bits en X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
18. Codigo de comienzo 1110 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
19. Paquete de datos X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
20. Codigos de casa y de control para unidad . . . . . . . . . . . . . . . . . . . . 44
21. Codigos de control para comandos . . . . . . . . . . . . . . . . . . . . . . . . 44
22. Ciclos para una transmision completa en X10 . . . . . . . . . . . . . . . . . . 45
23. Dispositivos X-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
24. Accesorios X-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
25. Protocolos LonWorks y equivalente OSI . . . . . . . . . . . . . . . . . . . . . 48
26. Dominio LonTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
27. Trama de LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
28. Instalacion LonWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
29. Caractersticas de los medios de transmision en EHS . . . . . . . . . . . . . . 51
30. Tramas EHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
31. Bus EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
32. Esquema general de una instalacion EIB . . . . . . . . . . . . . . . . . . . . . 57
33. Conexion de alimentacion y dispositivos al bus . . . . . . . . . . . . . . . . . 58
34. Generacion de corriente portadora sobre tension de alimentacion . . . . . . . 58
35. Distintas topologas de EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
36. Sistema completo EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
37. Direccion fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
38. Ejemplo de direccionamiento fsico . . . . . . . . . . . . . . . . . . . . . . . . 60
39. Niveles en las direcciones de grupo . . . . . . . . . . . . . . . . . . . . . . . . 61
40. Ejemplo de asignacion de direcciones de grupo . . . . . . . . . . . . . . . . . 62
I. Presentacion
En los ultimos anos estamos asistiendo a un incremento vertiginoso de la presencia de
las comunicaciones inalambricas en nuestra sociedad. As, existen diferentes tecnologas que
utilizamos cada da dependiendo de la aplicacion a la que esten destinadas. No solo el telefono
movil se ha convertido en imprescindible, tambien para muy corto alcance se esta imponiendo
el uso de Bluetooth, por ejemplo. Existen multitud de dispositivos como PDAs, manos libres,
vehculos, etc. que ya disponen de esta tecnologa.
Por otro lado, si queremos disponer de comunicaciones en un ambito local sin necesi-
dad de cables, existen diferentes tecnologas como las WiFi. En definitiva, la sociedad va
descubriendo las ventajas de los entornos inalambricos y en un futuro proximo apareceran
nuevas aplicaciones, incluso algunas aun no imaginadas.
Una vez introducido este tipo de tecnologas en la sociedad, comienzan a aparecer sistemas
y servicios basados en tecnologas inalambricas, mejorandose los procedimientos que tradi-
cionalmente requeran una interaccion directa con el ser humano y pueden ahora realizarse
de forma distribuida por medio de sistemas gestores inteligentes.
Concretamente, desde hace algunos anos, han comenzado a emerger las Redes de Sen-
sores. Los sensores son fuentes de informacion tan variados como lo son las medidas que
realizan. Los hay de temperatura, de luminosidad, de presion, de humedad, de velocidad,
de aceleracion, de presencia, de volumen y un sinfn de magnitudes que se nos ocurran. Si
a estos sensores que nos reportan informacion valiosa para nuestras vidas, les anadimos la
capacidad de comunicacion inalambrica y la posibilidad de formacion de redes, obtenemos
las Redes de Sensores Inalambricas, que estan teniendo un auge cada vez mayor debido
principalmente a la multitud de aplicaciones que se estan desarrollando, como aplicaciones
de seguimiento, de seguridad, de salud, de gestion, etc.
El presente proyecto abarca estos dos grandes campos aun sin relacionar practicamente:
la domotica y las redes de sensores inalambricas. Las instalaciones domoticas basadas y
controladas mediantes dispositivos inalambricos es un area en estudio y poco desarrollada
por el momento, pero es considerada como el futuro de la domotica, por las facilidades y
prestaciones que aporta y que, como ocurre con las nuevas tecnologas, tras una adaptacion
a la sociedad y mercado, experimentara un crecimiento y asentamiento en nuestros hogares.
Implementaremos una serie de aplicaciones domoticas que integraremos en sensores de una
red, programandolos y configurandolos, de tal forma que logremos crear una red inalambrica
de sensores que tenga como funcionalidad el control de aspectos de una vivienda como la
iluminacion, las persianas o la climatizacion.
Nuestro objetivo final es poder crear entornos inteligentes en una vivienda. Este concepto
muestra una vision de la Sociedad de la Informacion en el que se enfatiza la facilidad de uso,
el soporte eficiente de los servicios y la posibilidad de mantener interacciones naturales con
el ser humano. El objeto central se materializa a grandes rasgos en un individuo rodeado de
interfaces inteligentes e intuitivas que se encuentran integradas en partes y objetos corrientes
de su vivienda, todo esto en un entorno que sea capaz de reconocer y responder a la presencia
y necesidades de diferentes individuos, de una forma completamente discreta e imperceptible
mas que a traves de los resultados. Nuestra conviccion es que esto se hara realidad gracias a
la integracion de las redes de sensores en el ambito de la vivienda inteligente.
Aunque las posibilidades que ofrece la tecnologa son ya muy atractivas, es innegable
que son necesarias mas y mejores aplicaciones. Los cambios tecnologicos mas importantes
son aquellos que dejan de ser visibles y conscientes para formar parte de la vida, y ser
indistinguibles en ella. Por tanto, el objetivo de las tecnologas en el hogar es permitir que
las facilidades que ofrece se integren en la existencia cotidiana y la hagan mas comoda, pero
de manera que estos cambios no precisen un esfuerzo por parte de los usuarios.
II. Objetivos
II.1. Objetivo Teorico
El objetivo teorico del proyecto es conocer e investigar en profundidad los dos puntos
principales que abarcamos:
El sistema domotico en el que nos basaremos sera la tecnologa EIB, siguiendo su protoco-
lo de configuracion y transmision de mensajes. Los sensores que utilizaremos seran los TelosB
de Crossbow que, como veremos, nos proporcionaran unas caractersticas idoneas para este
tipo de aplicaciones.
Ademas, se realizara una parte de montaje anadida a los sensores TelosB, con el diseno de
una placa adjunta compuesta por pulsadores y leds configurados previamente, para ampliar
las posibilidades de la instalacion.
De esta forma, podremos tener varios pulsadores en un mismo nodo sensor, o varias salidas
de luz, para realizar nuestras pruebas y poder tener una mejor simulacion de la vivienda.
Domotica
I. Generalidades
La domotica, dicho en muy pocas palabras, es la instalacion e integracion de varias
redes y dispositivos electronicos en el hogar, que permiten la automatizacion de ac-
tividades cotidianas y el control local o remoto de la vivienda, o del edificio inteligente.
Por ejemplo, un sensor de presencia aislado puede servir para abrir una puerta siempre
que alguien se acerque, pero si esta integrado en una red, proporciona informacion sobre fre-
cuencia de uso, horas punta de entrada, etc.; una informacion que puede resultar muy valiosa
para otras aplicaciones y as, por ejemplo, no abrira la puerta fuera del horario comercial,
para evitar la entrada de intrusos, o la mantendra permanentemente abierta en las horas de
mayor afluencia al recinto.
Desde el punto de vista etimologico, la palabra domotica fue inventada en Francia (pas
pionero en Europa) y esta formada por la contraccion de domus (vivienda) mas automatica.
En este sentido ha habido cierta polemica en lo referente a la idoneidad de su denominacion,
puesto que el objeto de esta disciplina no es unicamente la vivienda, sino cualquier tipo
de edificacion. Ademas, la domotica va mas alla de la mera automatizacion de un edificio,
integrando el control del mismo con el uso que se hace de el.
En cualquier caso, el uso de este termino se ha extendido ampliamente, pero se pueden
distinguir tres sectores distintos dependiendo del alcance de su aplicacion:
Urbotica, para las ciudades. En este caso se tratan temas como el control de la ilumi-
nacion publica, la gestion de semaforos, las telecomunicaciones, medios de pago, etc.
Para definir una vivienda automatizada habra que tener en cuenta al menos dos puntos
de vista: el del usuario y el punto de vista tecnico.
Desde el punto de vista del usuario, una vivienda domotica podra ser aquella que pro-
porciona una mayor calidad de vida a traves de las nuevas tecnologas y comunicaciones,
ofreciendo una reduccion del trabajo domestico, un aumento del bienestar y la seguridad
de sus habitantes, y una racionalizacion de los distintos consumos, mediante un control
energetico. Todo ello teniendo en cuenta la facilidad de uso para todos los inquilinos, aun
cuando alguno de ellos presente alguna minusvala fsica.
Seguridad
Gestion de la energa
Formacion y cultura
Monitorizacion de salud
Ocio y entretenimiento
Para que le sirve a alguien tener todos estos sistemas y con que nivel de complejidad?
Inicialmente, hay que tener en consideracion que los requerimientos de los usuarios residen-
ciales son distintos a los de los usuarios profesionales, ubicados en oficinas o fabricas, algo que
hay que tener en cuenta al evaluar la tecnologa y los sistemas mas adecuados para satisfacer
sus necesidades que, fundamentalmente, se dirigen a hacer mas amigable su relacion con el
entorno en el que pasa la mayor parte de su tiempo.
Y despues el caso dependera de cada usuario. Podemos ver algunos ejemplos:
El anciano que vive solo le bastara con un sistema de teleasistencia muy simple tec-
nologicamente, pero con un alto nivel de servicio que garantice poder ofrecerle asistencia
inmediata en caso de urgencia.
Para una familia con varios hijos puede ser mas importante el poder disponer de acceso
a Internet en todas las habitaciones.
Para personas que viven solas, poder encender la calefaccion o el aire acondicionado
desde la oficina o disponer de un sistema automatico de riego puede tener mucho interes.
Para una pareja trabajadora puede que lo mas interesante sea disponer de una camara
IP en su casa, que les permita ver a traves de Internet a su hijo pequeno, que esta siendo
cuidado por otra persona.
Es indudable que cuantas mas posibilidades existen, mayor dificultad entrana su inter-
conexion, por lo que es labor de las empresas integradoras empaquetar soluciones que tengan
una facil instalacion y, aun mas importante, un mantenimiento sencillo. Pero es todava mas
importante que los fabricantes tengan en cuenta que sus productos no solo van a integrar
cada vez mas opciones, sino que tambien van a tener que ser capaces de compartir sus fun-
cionalidades e informacion con otros, por lo que tienen que facilitar la transferencia de datos,
permitir la gestion remota e, idealmente, ser capaces de ofrecer soluciones completas que
requieran de la mnima intervencion por el usuario.
Ademas, para las empresas promotoras dotar a las viviendas que construyen de una ins-
talacion domotica supone anadirles valor, lo que les permite venderlas mejor y mientras, las
empresas de telecomunicaciones y los proveedores de contenidos y servicios ven la posibili-
dad de aumentar los servicios que ofrecen a sus clientes, generando nuevos ingresos; a las
companas de servicios de luz, agua, electricidad, seguridad, etc., se les abre una puerta para
racionalizar sus costes, y anadir valor para el usuario final.
Segun todo lo expuesto, la domotica no son servicios ni productos aislados, sino la imple-
mentacion e integracion de todos los aparatos del hogar (electricos, electronicos, informaticos,
etc.). No obstante, la incorporacion e integracion de estas redes y dispositivos en la vivienda
domotica posibilitan una cantidad ilimitada de nuevas aplicaciones y servicios en el hogar,
consiguiendo as un mayor nivel de confort, se aumenta la seguridad, se reduce el con-
sumo energetico, se incrementan las posibilidades de ocio, etc. En definitiva, se produce
un incremento de la calidad de vida de sus habitantes.
II. Caractersticas
II.1. El sistema
Para que todos los dispositivos que integran una red domotica puedan trabajar de forma
conjunta es necesario que esten conectados a traves de una red interna, red que generalmente
se suele conocer por HAN (Home Area Network ). Esta red, cableada o inalambrica, suele
dividirse en tres tipos de redes, segun el tipo de dispositivos que se vayan a interconectar y
de las aplicaciones que se vayan a ofrecer:
La red de control
La red de datos
La red multimedia
Estas tres redes suelen estar constituidas en la actualidad por distintas tecnologas, aunque
es bastante probable que durante los proximos anos se produzca una integracion de todas
ellas. Por otro lado, es necesario la conexion de la HAN con el exterior, lo cual se realiza
a traves de las redes publicas de telecomunicacion (RTC, RDSI, Internet, etc.). De entre
todos los dispositivos de la vivienda domotica cabe destacar un elemento imprescindible, el
conocido por pasarela residencial (residencial gateway). Este dispositivo es el que permite
la convivencia de todas estas redes y dispositivos internos, interconectandolos entre s y con
el exterior. Esta pasarela debe garantizar la seguridad de las comunicaciones hacia/desde el
hogar y debe ser gestionable de forma remota.
Ademas de la pasarela residencial, los dispositivos que se deben instalar en los edificios
o viviendas domoticas para posibilitar un sistema de automatizacion y control podramos
clasificarlos de las siguiente forma:
Los sensores son los dispositivos encargados de recoger la informacion de los diferentes
parametros a controlar: la temperatura ambiente, la existencia de un escape de agua o
gas, la presencia de un intruso, activacion de un interruptor, etc. y enviarsela al sistema
de control o actuador para que ejecute automaticamente las tareas programadas. Los
hay de diversos tipos: gas, temperatura, agua, humedad, luz, movimiento, rotura, etc.
y estan distribuidos por todo el edificio.
A continuacion, establecemos los principales tipos de sensores y sus caractersticas:
1. Luminosidad.
Se usan para ajustar los niveles de iluminacion en funcion de la luz exterior o
para encender/apagar/regular las luces. Su colocacion se realiza en exteriores, en
lugares protegidos de las inclemencias del tiempo y evitando la exposicion directa
de la luz del sol.
Se pueden diferenciar entre:
Sensores de luminosidad propiamente dichos, en los que se produce una salida
analogica proporcional a la luz incidente.
Sondas crepusculares que producen salidas digitales (da/noche) y en las que
es posible ajustar un umbral de conmutacion mediante un potenciometro de
modo que proporcione una senal digital que active un rele.
2. Temperatura.
A partir de cambios de temperatura generaran una salida analogica o digital,
dependiendo del tipo:
Sondas
Producen una salida analogica al estimularlos con cambios de temperatura.
Cada tipo lo hace de una forma diferente:
Termopar. Genera una tension al cambiar de temperatura.
RTP. Varan su resistencia con la temperatura, segun un coeficiente.
NTC y PTC. Resistencia semiconductora que vara con los cambios de
temperatura.
CI. Circuitos integrados semiconductores que miden la temperatura.
Termostatos.
Son sensores de tipo digital que mandan una senal de conexion/desconexion
segun un umbral de temperatura previamente definido.
3. Volumetricos de presencia.
Son de tipo digital y se activan cuando se produce un movimiento en sus inmedia-
ciones. Podemos distinguir cuatro tipos:
Figura 4: Anemometro
Los actuadores son los dispositivos utilizados por el sistema de control para mod-
ificar el estado de ciertos equipos o instalaciones: encendido/apagado, subida/bajada
de persianas, el aumento o la disminucion de la calefaccion o el aire acondicionado, el
corte del suministro de gas o agua, el envo de una alarma a una centralita de seguri-
dad, etc. Estan distribuidos por todo el edificio y podemos distinguir diferentes tipos
de actuadores:
1. Electromecanicos.
Frente a las entradas o estmulos de los sensores van a producir una salida elec-
tromecanica. Estos son los mas utilizados en domotica y podemos distinguir:
Motores. Sus aplicaciones principales son las persianas y toldos.
Electrovalvulas. Controlan las valvulas de agua o gas y algunas permiten in-
cluso la regulacion.
Reles. Abren o cierran un circuito en funcion de una senal externa. Se pueden
clasificar segun el numero de circuitos que accionan a la vez, el valor de inten-
sidad que pueden soportar, el tipo y valor de tension que los acciona o por si
son temporizados o instantaneos.
Contactores. Tienen una funcion similar a la de un rele pero con un sistema
mecanico diferente y mas robusto. Son de montaje en carril DIN y se les
asocia con aplicaciones de control de grandes cargas o de multiples circuitos
simultaneamente.
2. Acusticos.
Producen salidas acusticas, como pueden ser sirenas, bocinas, altavoces, etc.
3. Luminosos.
Este ultimo tipo genera salidas luminosas con paneles, monitores, etc.
II.2. Arquitectura
Desde el punto de vista de donde reside la inteligencia del sistema domotico, y gracias al
desarrollo actual de las tecnologas de la informacion (en concreto los microcontroladores),
hacen viables dos tipos distintos de sistemas domoticos:
Sistemas Centralizados.
Un controlador centralizado recibe informacion de multiples sensores y, una vez procesa-
da, genera las ordenes oportunas para los actuadores. Toda la informacion de deteccion
y actuacion se tratan en este unico punto.
El cableado es en estrella cuyo centro es la unidad central de control y no existe comu-
nicacion entre sensores y actuadores.
Ventajas:
Desventajas:
Sistemas Distribuidos.
En este caso no existe la figura del controlador centralizado, sino que toda la inteligen-
cia del sistema esta distribuida por todos los modulos sean sensores o actuadores. Cada
elemento dispone de capacidad para tratar la informacion que recibe y actuar en con-
secuencia de forma autonoma.
Suele ser tpico de los sistemas con topologa en bus y es necesario un protocolo de
comunicaciones. Todos los elementos disponen de un acoplador al bus con una interfaz
de acceso compartido y tecnicas de direccionamiento para que la recepcion y el envo
de informacion quede definida y el dialogo entre elementos asegurado.
Ventajas:
Desventajas:
Hay que destacar que algunos sistemas usan un enfoque mixto, esto es, son sistemas
con arquitectura descentralizada en cuanto a que disponen de varios pequenos dispositivos
capaces de adquirir y procesar la informacion de multiples sensores y transmitirlos al resto
de dispositivos distribuidos por la vivienda. Hoy en da hay buenos sistemas centralizados y
distribuidos, todos ellos con elevadas prestaciones. Ambas arquitecturas tienen sus ventajas
y sus inconvenientes, lo cual, a priori, no ayuda a decidir cual es la mejor solucion para una
vivienda.
Por otra parte, tambien se pueden clasificar los sistemas en tres tipos a nivel tecnologico:
Sistemas cableados: todos los sensores y actuadores (sirenas, etc), estan cableados a la
central o entre ellos, la cual es el controlador principal de todo el sistema. Esta tiene
normalmente una batera de respaldo, para en caso de fallo del suministro electrico,
poder alimentar a todos sus sensores y actuadores y as seguir funcionando normalmente
durante unas horas.
Sistemas inalambricos: en este caso usan sensores inalambricos alimentados por pilas o
bateras y transmiten va radio la informacion de los eventos entre ellos o a la central,
la cual esta alimentada por red electrica y tiene sus bateras de respaldo.
II.3. Topologas
En los sistemas de arquitectura distribuida que utilizan como medio de transmision el
cable, existe un concepto a tener en cuenta que es la topologa de la red de comunicaciones.
La topologa de la red se define como la distribucion fsica de los elementos de control
respecto al medio de comunicacion. Es el metodo para interconectar los equipos y sistemas
conectados a ella as como la forma que adoptan. La topologa depende del sistema de control
que se utilice y el cableado en funcion de los requerimientos del sistema.
Tipos de topologas:
La Red de Estrella: es la conexion utilizada por los sistemas centralizados donde
existe un unico controlador sobre el que pasa toda la informacion.
La Red en Bus: es una arquitectura donde todos los elementos conectados a ella
tengan la estructura de controladores, y que sean conectados al bus.
Cada elemento del sistema tiene su propia capacidad de proceso y puede ser ubicado en
cualquier parte de la vivienda. Esta caracterstica proporciona al instalador domotico una
libertad de diseno que le posibilita adaptarse a las caractersticas fsicas de cada vivienda en
particular.
2. Soporte metalico.
La infraestructura de las redes de comunicacion actuales, tanto publicas como privadas,
tiene en un porcentaje muy elevado cables metalicos de cobre como soporte de trans-
mision de las senales electricas que procesa.
En general se pueden distinguir dos tipos de cables metalicos:
Par metalico: Los cables formados por varios conductores de cobre pueden dar
soporte a un amplio rango de aplicaciones en el entorno domestico. Este tipo de
cables pueden transportar voz, datos y alimentacion de corriente continua.
Coaxial: Un par coaxial es un circuito fsico asimetrico, constituido por un con-
ductor filiforme que ocupa el eje longitudinal del otro conductor en forma de tubo,
manteniendose la separacion entre ambos mediante un dielectrico apropiado. Este
tipo de cables permite el transporte de las senales de vdeo y senales de datos a
alta velocidad.
3. Fibra optica.
La fibra optica es el resultado de combinar dos disciplinas no relacionadas, como son
la tecnologa de semiconductores (que proporciona los materiales necesarios para las
fuentes y los detectores de luz), y la tecnologa de guiado de ondas opticas (que pro-
porciona el medio de transmision, el cable de fibra optica).
La fibra optica esta constituida por un material dielectrico transparente, conductor de
luz, compuesto por un nucleo con un ndice de refraccion menor que el del revestimiento,
que envuelve a dicho nucleo. Estos dos elementos forman una gua para que la luz se
desplace por la fibra. La luz transportada es generalmente infrarroja, y por lo tanto no
es visible por el ojo humano. Permite altas velocidades para datos, television, etc.
4. Conexiones inalambricas:
Infrarrojos
El uso de mandos a distancia basados en transmision por infrarrojos esta amplia-
mente extendido en el mercado residencial para controlar equipos de audio y vdeo.
Los controladores de equipos domesticos basados en la transmision de ondas en
la banda de los infrarrojos presentan gran comodidad y flexibilidad y admiten un
gran numero de aplicaciones.
Radiofrecuencias
La introduccion de las radiofrecuencias como soporte de transmision en la vivienda
ha venido precedida por la proliferacion de los telefonos inalambricos y sencillos
telemandos. Este medio de transmision puede parecer, en principio, idoneo para el
control a distancia de los sistemas domoticos, dada la gran flexibilidad que supone
su uso. Sin embargo, puede resultar sensible a las perturbaciones electromagneticas
producidas, tanto por los medios de transmision, como por los equipos domesticos.
III.2. Seguridad
Actualmente, aunque de manera individualizada (no integrada), es la funcion mas de-
sarrollada, y puede integrar multiples aplicaciones, especialmente si se encuentra integrada
dentro de un sistema domotico. Se puede dividir en seguridad de personas y seguridad de
bienes.
Detectores de fugas de gas o de agua que cierren las valvulas de paso a la vivienda en
el caso de producirse escapes.
Avisos a distancia. En ausencia del usuario se emiten avisos en caso de alarma (bien
acusticos o telefonicos).
Alarmas tecnicas:
Deteccion de incendios.
Deteccion de fugas de agua y gas.
Ausencia de energa electrica.
III.3. Confort
El concepto de confort va dirigido principalmente a las instalaciones CVC (climatizacion,
ventilacion y calefaccion), auque tambien se incluyen en este campo los sistemas de audio
y vdeo, control de iluminacion, riego y jardines, mando a distancia y todo aquello que
contribuya al bienestar y la comodidad de las personas que utilicen las instalaciones. En los
sistemas de CVC es donde mayores inversiones se estan realizando, pues ademas de abarcar
una gran parte del consumo energetico, estan presentes en casi todas las instalaciones y
son la primera contribucion. Se hace necesario que el control de estos sistemas este lo mas
distribuido posible, esto es, que cada habitacion, local o recinto, disponga de sistemas de
control individual.
Entre los sistemas destinados al confort cabe destacar, ademas de las instalaciones CVC:
III.4. Telecomunicaciones
En este sentido, existen numerosas posibilidades en funcion del tipo de edificio. La apari-
cion de nuevas tecnologas en el campo de las comunicaciones y redes de transmision de datos,
y el hecho de que los sistemas domoticos avanzados se basan en el empleo de estos tipos de
redes, hacen de este un campo fertil para la investigacion y el desarrollo de nuevas arquitec-
turas y sistemas de integracion. Entre las posibilidades de telecomunicacion segun el tipo de
edificio, destacaremos:
De entre todas ellas, las que mayor auge estan teniendo en los ultimos anos, desde el
punto de vista de aportaciones de investigacion e implantacion de nuevas tecnologas, son las
iniciativas de telecontrol del sistema domotico desde el exterior. En este sentido se pueden
destacar trabajos como:
Si se trata de una casa nueva, dependiendo de su tamano y de los requisitos, los sistemas
centralizados comerciales (SCC) suelen ser bastante apropiados. Las gamas bajas de SCC se
suelen aplicar a nuevas viviendas de tamano pequeno sin grandes requerimientos. Las gamas
altas de SCC se emplean en viviendas nuevas de tamano medio-grande con necesidades mas
avanzadas, aunque tambien se esta extendiendo cada vez mas la implantacion de sistemas
distribuidos en este tipo de viviendas.
Existe un producto centralizado muy popular entre los instaladores europeos denominado
IHC (Innovation House Control ), que en Espana ha sido adoptado por la empresa Simon
y lo comercializa bajo el nombre de SimonVIS. Tiene la ventaja de tener un coste muy
reducido y no requiere ningun tipo de especializacion para su instalacion. Tambien existen
otros sistemas menos populares como Amigo (Merln Gerin), Microdelta (Delta Dore), Do-
moconcept, y otros muchos propietarios de diferentes fabricantes.
En el caso de un edificio, las necesidades son mas complejas que en las de una casa. En
este caso, y teniendo en cuenta la cantidad de cableado necesario, son los sistemas en bus
los que ganan terreno respecto a los demas, aunque en algunos casos las gamas altas de SCC
tambien se pueden aplicar si la relacion cableado/componentes lo permite. Los sistemas tipo
bus mas instalados en Europa eran el BatiBus de Merlin Gerin y el EIB desarrollado por
un consorcio europeo que engloba empresas como Siemens, Niessen, ABB, Legrand, Hager,
etc., y que ahora englobados en el estandar Konnex.
Existe otro sistema tambien muy popular en Estados Unidos, el Lonworks de Echelon,
pero en Europa esta poco introducido. Otros sistemas aplicables en este tipo de instalaciones
son CEBus de la EIA, EHS de EHSA, Smart House de la NAHB, y en el caso de SCC de
gama alta: Sysmac de Omron, B3d de Performer 2000, D2B de Philips, etc.
Por tanto, se puede decir que los sistemas mas instalados en la actualidad son los ameri-
canos, y de entre ellos, los que ellos mismos denominan como los cuatro grandes, a saber:
CEBus, X-10, Lonworks y Smart House. A nivel europeo, los sistemas mas importantes son:
EIB, SimonVIS, Batibus y EHS. Cabe destacar que los sistemas Batibus, EIB y EHS se han
unido formando un consorcio para conseguir la compatibilidad de productos entre ellos. Este
proceso lo han denominado convergencia (Konnex, KNX), siendo el sistema EIB el que lidera
la iniciativa y prevaleciendo sobre los otros dos.
IV.1. CEBus
En Estados Unidos, la EIA (Electronic Industries Association) reconocio la necesidad de
desarrollar un estandar acerca de los sistemas de comunicacion de los hogares automatizados.
En 1983 se organizo un comite que tuvo como fruto en 1988 un estandar (el Home Automation
Standard IS-60) conocido como Consumer Electronic Bus, CEBus.
El documento final, despues de varias revisiones, estuvo disponible en 1992. Este cubre
tanto las caractersticas electricas como los procedimientos de los modulos del sistema de
comunicacion. La arquitectura del CEBus sigue el modelo de referencia OSI (Open Systems
Interconnection), ocupandose cada uno de los niveles de determinadas funciones de la red de
comunicacion.
El CEBus solo utiliza cuatro de los siete niveles: Fsico, Enlace, Red y Aplicacion. La
interfaz entre los diferentes niveles del nodo CEBus esta definido como un conjunto de pri-
mitivas de servicio, proporcionando cada nivel servicio al inmediatamente superior.
Facilitar el desarrollo de modulos de interfaz de bajo coste que puedan ser integrados
facilmente en electrodomesticos.
Permitir anadir y quitar componentes de la red sin que afecte al rendimiento del sistema
ni que requiera un gran esfuerzo la configuracion por parte del usuario.
El protocolo y el lenguaje son comunes a todos los elementos CEBus, pero existen 6
medios fsicos distintos:
Infrarrojo (IR)
Coaxial (CX)
Senales de video: mediante dos cables coaxiales, uno para las senales internas y otro
para las externas.
Senales de voz/datos: cuatro pares trenzados, TP0-TP3 (TP0 se reserva para la ali-
mentacion de 18Vdc).
IV.2. X-10
El formato de codificacion X-10 es un estandar basado en la transmision de corrientes
portadoras (Power Line Carrier = P.L.C.). Esta tecnologa fue desarrollada entre 1976 y
1978 por ingenieros en Pico Electronics Ltd, en Glenrothes, Escocia. Proviene de una familia
de chips, que son los resultados de los proyectos X (la serie X). Esta empresa comenzo a
desarrollar el proyecto con la idea de obtener un circuito que se pudiera implementar
en un dispositivo para ser controlado remotamente.
En 1978 se introdujo para el Sistema de Control del Hogar de Sears y para los sistemas
de un gran distribuidor llamado Radio Shack que lo vendio a miles hasta que en 1979 los
fabrico por su cuenta y los llamo Plug n Power, y mas tarde X10.
Desde entonces, X-10 ha desarrollado y manufacturado versiones O.E.M. (Original Equip-
ment Manufacturer ) de su Sistema de Control del Hogar para muchas companas incluyendo
Leviton Manufacturing Co., Stanley Healtth / Zenith Co., Honeywell, Norweb y Busch Jaeger,
existiendo en la actualidad mas de ocho millones de instalaciones. Todos estos sistemas uti-
lizan el formato de codificacion X-10. Todos son compatibles y virtualmente cualquier sistema
para el hogar sin cableados utiliza X-10 con modulos PLC.
Compatibilidad casi absoluta con los productos de la misma gama, obviando fabricante
y antiguedad.
Flexible y ampliable.
Con los componentes X-10 la red, ademas de suministro de corriente, se encarga tambien
de la transmision de senales de mando para los diversos aparatos electricos. Con ello se puede
enviar senales de corrientes portadoras a cualquier punto de la instalacion que se desee, y a
su vez pueden solicitarse de dicho punto las informaciones pertinentes.
El sistema permite el accionamiento a distancia y control remoto de diversos receptores
electricos, desde uno o desde varios puntos y puede funcionar tanto en redes de corriente
alterna monofasica como trifasica.
Por la popularidad e importancia de que goza el sistema X-10, haremos un estudio mas
detallado de su tecnologa ya que mas de cinco millones de hogares en todo el mundo disponen
de productos X-10, y es el fabricante de sistemas de control del hogar que ha vendido mas
sistemas de control de iluminacion que ninguna otra compana. Mas de 100 millones de
equipos se han vendido durante los ultimos 15 anos, haciendo de X-10, en este sentido, el
lder en sistemas de control del hogar.
Un 1binario del mensaje se representa por un pulso de 120 Khz durante 1 ms, en el
paso por cero de la senal de red, y el 0binario del mensaje se representa por la ausencia de
ese pulso de 120 Khz.
Cuando se transmite codigo, se utilizan dos pasos por cero para transmitir cada bit
como una pareja de bits complementarios (en otras palabras, un cero se representa por
0-1 y un uno es representado por 1-0 segun se muestra en la figura).
Debido a las caractersticas del medio de transmision utilizado se transmite dos veces
cada uno de estos bloques de informacion para conseguir una mayor fiabilidad.
Ademas, cada par de bloques de informacion debe estar precedido por seis pasos por cero
(tres ciclos de red). Este tiempo de espera es necesario para que el receptor procese los datos
de direccion recibidos.
Una vez que el receptor ha procesado sus datos de direccion, esta listo para recibir una
orden de comando. Al igual que se haba hecho al enviar la direccion, el bloque de datos
del comando debe empezar por el codigo de comienzo, seguido del codigo de la letra y el
codigo de control. Finalmente ira el sufijo, teniendo que ser en este caso igual a 1 para que el
codigo de control sea interpretado como un comando y no como una direccion por el receptor.
En la figura siguiente se muestran los ciclos totales que necesita un transmisor para realizar
una transmision completa.
Cada once ciclos de red se transmite un bloque de datos, y una transmision estandar X-10
normal necesita 47 ciclos de la senal de red. A una frecuencia de 50 Hz esto supone un tiempo
igual a 0,94 segundos en transmitir una orden completa.
Hay excepciones a esta regla. Por ejemplo, el codigo de Aumentar Intensidad (Bright) y
Atenuar intensidad (Dim) no requiere los tres ciclos de espera entre comandos consecutivos
Dim o comandos consecutivos Bright. Sin embargo, s son necesarios los tres ciclos de espera
entre codigos diferentes (p.e. entre Atenuar y Aumentar, o entre Encender y Atenuar, etc.).
Para poder llegar, en las redes de corriente trifasica, a todos los aparatos distribuidos por
las diferentes fases, se emiten los paquetes de impulsos tres veces, cada impulso desplazado
frente al impulso anterior el tiempo del desplazamiento de fases, las unidades deben conec-
tarse al sistema trifasico por medio de un acoplador de fases.
senales transmitidas o recibidas en los dispositivos X-10. Un efecto tpico del ruido electrico
es el encendido aleatorio de los modulos receptores o el tener un transmisor y un receptor
cercanos y aun as no tener suficiente senal debido al ruido electrico.
El aparato electrico que esta generando dicho ruido no tiene necesariamente que estar
encendido, tal es el caso de elementos como ordenadores o aparatos de TV, que siguen encen-
didos en standby cuando se apagan. Todos estos problemas se solucionan con la utilizacion
de filtros que atenuan las senales de frecuencia diferente a 120 Khz.
Amplificacion.
Cuando las distancias son largas y/o la atenuacion de las senales X10 elevada en una
instalacion, se pueden emplear elementos amplificadores de senal. Estos dispositivos trabajan
de la siguiente forma: el amplificador vigila el circuito de senales en todas las fases en busca
de senales. Tras el envo de un datagrama de direccion, este se repite, amplificado a las tres
fases, exactamente en el momento de la repeticion de la senal original. Lo mismo ocurre
con los datagramas de funciones, en los cuales se amplifican exclusivamente las ordenes de
conexion, desconexion o conmutacion.
Dispositivos X-10
Existen tres tipos de dispositivos X-10: los que solo pueden transmitir ordenes, los que
solo pueden recibirlas y los que pueden enviar y recibir estas. A continuacion se incluyen
algunos de ellos a modo de ejemplo:
Transmisores.
Un transmisor es capaz de enviar informacion hasta 256 dispositivos sobre el cableado
electrico. Multiples transmisores pueden enviar senales al mismo modulo.
Receptores.
Los receptores vienen dotados de dos pequenos conmutadores giratorios, uno con 16
letras y el otro con 16 numeros, que permiten asignar una direccion de las 256 posibles.
En una misma instalacion puede haber varios receptores configura con la misma direc-
cion, todos realizaran la funcion preasignada cuando un transmisor enve una trama
con esa direccion. Cualquier dispositivo receptor puede recibir ordenes de diferentes
transmisores.
Bidireccionales.
Tienen la capacidad de responder y confirmar la correcta realizacion de una orden,
lo cual puede ser muy util cuando el sistema X-10 esta conectado a un programa de
ordenador que muestra los estados en que se encuentra la instalacion domotica de la
vivienda.
Inalambricos.
Permiten conectarse a traves de una antena y enviar senales de radio desde una unidad
inalambrica e inyectar la senal X-10 en el cableado electrico. Estas unidades no estan
habilitadas para controlar directamente a un receptor X-10, debe utilizarse un modulo
transceptor.
Ademas de estos dispositivos, que son los mas utilizados, existen una serie de accesorios y
componentes que ayudan a solucionar problemas en las instalaciones, entre los que podemos
destacar los siguientes:
IV.3. LonWorks
Echelon surgio como una iniciativa de Mike Markkula (exdirectivo de Fairchild Semicon-
ductor, Intel y Apple), que en 1990 desarrollo LonWorks. Inicialmente se pretenda ocupar
el espacio dejado por X-10, pero actualmente el ambito de aplicacion de este sistema abarca
desde industrias, edificios, viviendas y automoviles hasta cualquier otro pequeno dispositivo
susceptible de ser controlado.
El protocolo de comunicacion empleado, LonTalk, es un protocolo de comunicaciones
basado en el modelo de referencia OSI de ISO. Este protocolo (LonTalk) es abierto (previo
pago de tasas).
Los componentes basicos de una red LonWorks son dos:
Neuronas. Son unos circuitos integrados que contienen dispositivos de entrada/salida,
tres microprocesadores y memoria en la que reside el sistema operativo.
Transceptores. Son dispositivos emisores-receptores que se encargan de conectar las
neuronas con el medio de transmision.
Existe tambien un sistema de desarrollo, LonBuilder, que consiste en un software y dos
emuladores de neuronas que pueden comunicarse entre s.
Las neuronas (neuron chips), fabricadas por Toshiba y Motorola, constituyen el nodo
basico de las redes de control. Mediante los transceptores se consigue que el protocolo de
comunicacion sea totalmente independiente del medio utilizado (IR, PL, TP, etc.), y con la
herramienta LonBuilder se pueden desarrollar aplicaciones orientadas a redes.
En cuanto a la topologa del cableado de la red, existe versatilidad para emplear cualquiera
de las existentes: en bus, anillo o libre, consiguiendo velocidades que superan el mega para la
topologa en bus, o de 78 kbps para la topologa libre.
1. Direccion fsica (Neuron ID): consiste en una direccion de 48 bits que viene grabada
de fabrica (como la direccion MAC en una tarjeta de red).
Un nodo puede pertenecer como maximo a 2 dominios. Cada nodo tiene una direccion
de subred y una direccion de nodo para cada dominio al que pertenezca. Asimismo, un nodo
puede pertenecer a 15 grupos como maximo en cualquier dominio en el que este.
Tambien se utilizan direcciones de difusion en un dominio o una subred (a veces se utilizan
en lugar de las de grupo para preservarlas).
Se utilizan varios dominios cuando se excede el numero maximo de dispositivos o se
quieren separar para que no puedan interoperar.
En esta figura vemos un ejemplo de un Dominio LonTalk, donde podemos establecer que:
Un canal es la union fsica de distintos nodos.
Un grupo es la union logica de distintos nodos.
Una unica red puede abarcar distintos canales mediante puentes.
Un canal puede transportar paquetes de distintas subredes.
Un canal puede estar formado por nodos que pertenezcan a distintas subredes.
Un grupo puede estar formado por miembros de distintas subredes y canales. Es decir,
un grupo no depende de la topologa ni del medio fsico que se emplee.
El formato de las tramas es el mostrado en la figura siguiente, con los siguientes campos:
un campo de control, la direccion de nodo, la direccion de dominio, los datos de usuario y un
campo de CRC (codigo de redundancia cclica). El tamano maximo del campo de datos es
de 228 bytes.
IV.4. EHS
A finales de los 80 la comision europea propicio el desarrollo de un par de proyectos
SPRIT (el Home System 2341 y el Integrated Interactive Home Project), de los que surgira
la European Home System Association (EHSA) en 1990, de la que inicialmente formaban
parte companas como ABB, BT, Legrand, Philips, Siemens, Thomson y Thorn EMI.
Los objetivos de esta asociacion fueron:
Posibilidad de interoperacion entre los distintos equipos de diferentes fabricantes.
Facil instalacion y reconfiguracion por parte del usuario.
Posibilidad de integracion de todos los dispositivos y medios disponibles en una vivienda
convencional.
El bus EHS surgio como un sistema abierto, consecuencia de esta iniciativa, con control
y gestion distribuida, y preparado para su uso en distintos medios simultaneamente. Sigue el
modelo de referencia OSI, implementando unicamente las capas fsica, de enlace, de red y de
aplicacion.
Los medios fsicos que se pueden emplear son: red electrica (PL), par trenzado de clases
1 y 2 (TP1 y TP2), cable coaxial, radio frecuencia e infrarrojos, como se puede observar en
la tabla siguiente. Todos los medios pueden distribuir senales de clase 1 (senales de control),
algunos distribuyen ademas senales de clase 2 (voz/datos baja velocidad) e incluso senales de
clase 3 (audio/video/datos alta velocidad).
2. Dispositivos complejos (CoD: complex devices). Son como los anteriores pero s tienen
capacidad para integrarse autonomamente al sistema.
3. Encaminadores (Routers). Permiten la interconexion de distintos medios en EHS.
4. Pasarelas (Gateways). Integran distintos sistemas.
5. Coordinador de dispositivos (DC: device coordinator ). Sirven de pasarela entre los
dispositivos simples y los controladores de prestaciones (FC). No tienen funcionalidad
autonoma propia, pero son capaces de gestionar de modo autonomo la integracion en
un sistema de dispositivos simples.
6. Controlador de prestaciones (FC: feature controller ). Utilizan las prestaciones de
los dispositivos simples (a traves de los coordinadores) y complejos. Proporcionan in-
teligencia a la aplicacion en el sentido de control, monitorizacion, toma de decisiones,
etc.
Una red EHS puede estar formada por distintas subredes EHS, e incluso por redes dis-
tintas a EHS, en cuyo caso se emplean pasarelas. En EHS cada dispositivo recibe el nombre
de unidad. Cada unidad conectada a una subred tiene su propia direccion de subred. Una
direccion de unidad se compone de la direccion de subred de la unidad destinataria, el numero
de rutas y las direcciones de los distintos encaminadotes para alcanzar la subred de destino.
El procedimiento de registro (registration procedure) es una funcion de EHS que per-
mite la asignacion dinamica de direcciones. Por ejemplo, si dos unidades de dos subredes de
pares trenzados tienen la misma direccion, al mover una de las unidades a la otra subred,
habra un problema, que se soluciona con el procedimiento de registro.
Este procedimiento tiene lugar en el momento de la instalacion (registro de categora I) o
cada vez que el sistema se pone en funcionamiento (registro de categora II). Mediante este
procedimiento, cada unidad nueva conectada a la red negocia su direccion a traves de una
unidad denominada Controlador de Medios (MdC), que es la responsable de la asignacion
de direcciones en cada subred. La unidad MdC es opcional, ya que sus tareas pueden ser
realizadas por un controlador de prestaciones (FC).
Cuando no hay un MdC en la subred, el registro se hace mediante un mecanismo de
asignacion distribuida de direcciones (DAA). Las acciones llevadas a cabo en este registro
son:
1. La unidad elige una direccion de modo aleatorio y manda un mensaje a esa direccion.
2. Si no recibe respuesta, la unidad mantiene esa direccion.
3. Si hay respuesta, la unidad elige una nueva direccion y repite el proceso hasta que
obtenga una direccion propia.
Para la cooperacion de las diferentes unidades dentro de una aplicacion deben crearse una
serie de vnculos entre ellas. Esto es lo que se conoce como procedimiento de enrolado.
Este procedimiento requiere que las unidades intercambien sus direcciones, y es esencial para
el funcionamiento autonomo del sistema, ya que permite a las unidades detectar la presencia
de las demas.
El enrolado comienza al encender una unidad, una vez completado el registro, y se realiza
llevando a cabo las siguientes acciones:
El FC recibe los DD de los distintos CoDs junto con sus direcciones. Si el FC estuviera
interesado en un CoD concreto, enviara su mensaje de enrolado positivo al CoD en
cuestion.
Preambulo: Para sincronizacion del envo de datos entre los dispositivos emisor y receptor.
Cabecera: Que marca el inicio de los datos y permite reconocer una trama EHS.
Datos: Datos utiles del mensaje, informacion de la accion de control a realizar o datos a
transferir.
FCS: Campo de correccion de errores, en el que se utilizan 2 bytes para garantizar la fiabil-
idad de la comunicacion.
IV.5. Batibus
Dentro de los buses industriales, en Europa se ha utilizado, dentro del marco domotico, el
bus BatiBus. Fue desarrollado por la empresa francesa Merlin Gerin. Se basa en la tecnologa
de par trenzado, con una velocidad binaria unica de 4800 bps, la cual es mas que suficiente
para la mayora de las aplicaciones de control distribuido. El sistema se basa en apertura y
cierre de circuito en lo equivalente a modulacion OOK.
La instalacion de este cable se puede hacer en diversas topologas: bus, estrella, anillo,
arbol o cualquier combinacion de estas. Lo unico que hay que respetar es no asignar direcciones
identicas a dos dispositivos de la misma instalacion.
El tamano de las redes, considerado como la distancia entre la unidad central y los puntos
de control, depende de la resistividad de los conductores empleados, sin embargo, la longitud
de la red dependera fundamentalmente de la capacidad de resistir la interferencia inducida
por la lneas de potencia sobre las lneas del bus (capacidad de acoplo maxima de 250 nano-
faradios).
El sistema es centralizado, pudiendo controlar cada central hasta 500 puntos de control.
A nivel de acceso, este protocolo usa la tecnica CSMA-CA, (Carrier Sense Multiple Access
with Collision Avoidance) similar a Ethernet pero con resolucion positiva de las colisiones.
Esto es, si dos dispositivos intentan acceder al mismo tiempo al bus ambos detectan que se
esta produciendo una colision, pero solo el que tiene mas prioridad continua transmitiendo el
otro deja de poner senal en el bus. Esta tecnica es muy similar a la usada en el bus europeo
EIB y tambien en el bus del sector del automovil llamado CAN (Controller Area Network ).
La filosofa es que todos los dispositivos BatiBUS escuchen lo que han enviado cualquier
otro, todos procesan la informacion recibida, pero solo aquellos que hayan sido programados
para ello, filtraran la trama y la subiran a la aplicacion empotrada en cada dispositivo.
Al igual que los dispositivos X-10, todos los dispositivos BatiBUS disponen de unos micro-
interuptores circulares o miniteclados que permiten asignar una direccion fsica y logica que
indentifican unvocamente a cada dispositivo conectado al bus.
Este protocolo de domotica esta totalmente abierto, esto es, al contrario de los que sucede
con el protocolo LonTak de la tecnologa Lonworks, el protocolo del BatiBUS lo puede im-
plementar cualquier empresa interesada en introducirlo en su cartera de productos.
BatiBUS ha conseguido la certificacion como estandar europeo CENELEC. Existen una
sere de procedimientos y especificaciones que sirven para homologar cualquier producto que
use esta tecnologa como compatible con el resto de productos que cumplen este estandar.
A su vez, la propia asociacion BCI ha creado un conjunto de herramientas para facilitar el
desarrollo de productos que cumplan esta especificacion.
Sin embargo, el estandar se ha quedado obsoleto debido a sus limitaciones y actualmente
se ha integrado junto a los estandares EIB y EHS en Konnex.
V. Sistema EIB
V.1. Introduccion
El European Installation Bus o EIB es un sistema domotico desarrollado bajo los aus-
picios de la Union Europea con el objetivo de contrarrestar las importaciones de productos
similares que se estaban produciendo desde el mercado japones y el norteamericano, donde
estas tecnologas se han desarrollado antes que en Europa.
El objetivo era crear un estandar europeo, con el suficiente numero de fabricantes, de ins-
taladores y usuarios, que permitiera comunicarse a todos los dispositivos de una instalacion
electrica como: contadores, equipos de climatizacion, de seguridad, de gestion energetica y
los electrodomesticos.
El EIB surgio con la idea de introducir en el mercado un sistema unificado para la gestion
de edificios, creado por el consorcio europeo EIBA (European Installation Bus Association),
creado en 1990 por mas de setenta companas (ABB, Siemens, Niessen, Temper, etc.).
En la actualidad la asociacion tiene mas de cien miembros, existiendo unas veinte empresas
que suministran productos, siendo las mas importantes Siemens, ABB, Temper, Grasslin y
Niessen. Tambien existen miembros cientficos que colaboran en el desarrollo de actividades
de I+D, especialmente universidades y centros de investigacion.
Las funciones de la asociacion son basicamente el soporte para la preparacion de normas
unificadas y la definicion de los tests y requisitos de homologacion que garanticen la calidad
y compatibilidad de los productos.
Se trata, ademas, de un sistema abierto bajo las mismas premisas que otros sistemas de
comunicacion como los buses de campo abiertos: tanto las especificaciones del protocolo como
los procedimientos de verificacion y certificacion estan disponibles, as como los componentes
crticos del sistema (microprocesadores especficos con la pila del protocolo y electronica de
acoplamiento al bus).
Segun la EIBA (EIB Association) hay unos 10 millones de dispositivos EIB instalados
por todo el mundo, unas 70.000 instalaciones, una gama de 4.500 productos diferentes, 113
empresas asociadas a la EIBA, y 70.000 instaladores cualificados.
El EIB esta basado en la estructura de niveles OSI y tiene una arquitectura descentra-
lizada. Este estandar europeo define una relacion extremo-a-extremo entre dispositivos que
permite distribuir la inteligencia entre los sensores y los actuadores instalados en la vivienda.
Aunque en un principio solo se contemplo usar un cable de dos hilos como soporte fsico
de las comunicaciones, se pretenda que el nivel EIB.MAC (Medium Access Control ) pudiera
funcionar sobre los siguientes medios fsicos:
EIB.TP: sobre par trenzado a 9600 bps. Ademas por estos dos hilos se suministra 24
Vdc para la telealimentacion de los dispositivos EIB. Usa la tecnica CSMA con arbitraje
positivo del bus que evita las colisiones evitando as los reintentos y maximizando el
ancho de banda disponible.
EIB.PL: Corrientes portadoras sobre 230 Vac/50 Hz (Powerline) a 1200/2400 bps.
Usa la modulacion SFSK (Spread Frequency Shift Keying) similar a la FSK pero con
las portadoras mas separadas. La distancia maxima que se puede lograr sin repetidor
es de 600 metros.
EIB.net: usando el estandar Ethernet a 10 Mbps (IEC 802-2). Sirve de backbone entre
segmentos EIB ademas de permitir la transferencia de telegramas EIB a traves del
protocolo IP a viviendas o edificios remotos.
En la practica, solo el par trenzado ha conseguido una implantacion masiva mientras que
la instalacion sobre red electrica de baja tension, que funciona por corrientes portadoras de
manera similar a otros sistemas, como X10, se reserva a viviendas o edificios ya construidos,
donde la instalacion de nuevo cableado sera muy costosa. No obstante, este tipo de medio
es muy poco empleado por mayor coste y menor fiabilidad. Por ultimo, esta previsto el
desarrollo de dispositivos por radiofrecuencia, tema del que trata nuestro proyecto.
Al igual que otros sistemas domoticos, EIB permite la integracion de las funciones basicas
requeridas en viviendas y edificios:
Ademas, EIB presenta las ventajas inherentes a este tipo de sistemas frente a las instala-
ciones tradicionales:
V.2. Tecnologa
El EIB es un sistema descentralizado (no requiere de un controlador central de la insta-
lacion), en el que todos los dispositivos que se conectan al bus de comunicacion de datos
tienen su propio microprocesador y electronica de acceso al medio.
En una red EIB podemos encontrar basicamente cuatro tipos de componentes: modulos
de alimentacion de la red, acopladores de lnea para interconectar diferentes segmentos
de red, y elementos sensores y actuadores.
Los sensores son los responsables de detectar cambios de actividad en el sistema (operacion
de un interruptor, movimientos, cambio de luminosidad, temperatura, humedad, etc.), y
ante estos, transmitir mensajes (denominados telegramas) a los actuadores, que se encargan
de ejecutar los comandos adecuados. Los sensores funcionaran por tanto como entradas al
sistema, y los actuadores como salidas para la activacion y regulacion de cargas.
En la version de par trenzado, la lnea de bus, que sirve como soporte para la transmision
de datos, llega a todos los dispositivos, pero la red electrica solo se conectara a los elemen-
tos actuadores para el control de las cargas (iluminacion, motores de persianas, etc.). Las
instalaciones de tipo EIB pueden abarcar mas de 14.000 de estos dispositivos, por lo que son
aplicables a edificaciones desde viviendas unifamiliares a grandes edificios (hospitales, hoteles,
etc.).
Caractersticas de la transmision
El medio fsico empleado en la red es un cable de par trenzado (simetrico, de seccion 0.8
mm2 e impedancia caracterstica Z0 =72 Ohm). Los datos se transmiten en modo simetrico
sobre este par de conductores (no se ponen a tierra). El empleo de transmision diferencial,
junto con la simetra de los conductores, garantiza que el ruido afectara por igual a los
conductores, de modo que la diferencia de tensiones permanece invariante.
Esta es una tecnica empleada en la mayora de las redes de comunicacion de datos. La
inmunidad al ruido mejora por la baja resistencia del enlace de los dispositivos mediante
acoplamiento aislado (transformador).
La transmision de datos se realiza en modo asncrono, a una velocidad de 9600bps.
Los datos se codifican en modo simetrico, como se ha descrito, correspondiendo a un 1 logico
la ausencia de impulso, y a un 0 logico la presencia de un impulso simetrico. As, los 0s
representan como un impulso negativo-positivo de -5V a +5V. Para conseguir la simetra en la
transmision, cada dispositivo produce tan solo la onda negativa por absorcion de corriente del
bus, y es la bobina de acoplamiento de la fuente de alimentacion conectada a esa lnea la que
genera una fuerza contraelectromotriz responsable de la generacion de la semionda positiva.
Por ello la onda real obtenida no es perfectamente simetrica, aunque s muy aproximada, tal
y como se puede apreciar en la figura siguiente.
V.3. Topologa
Para el conexionado de dispositivos del bus en cada lnea se permite cualquier topologa:
arbol, estrella, bus o anillo, lo que facilita la instalacion en viviendas y edificios. Unica-
mente no se permite cerrar anillos entre lneas situadas topologicamente en diferentes subre-
des.
Una lnea.
Es la unidad mnima de instalacion. En ella se pueden conectar hasta 64 dispositivos
(dependiendo de la capacidad de la fuente de alimentacion y de la carga maxima pro-
ducida por los dispositivos existentes).
Si se desean conectar mas componentes al bus, se habra de instalar una nueva lnea,
que se acoplara, junto con la primera, a una lnea principal mediante acopladores de
lnea (AL).
V.4. Direccionamiento
Los diferentes elementos existentes en una instalacion EIB quedan perfectamente identi-
ficados gracias al sistema de direccionamiento. Existen dos tipos de direcciones: direcciones
fsicas y direcciones de grupo.
Direcciones fsicas
Las direcciones fsicas identifican unvocamente cada dispositivo y corresponden con su
localizacion en la topologa global del sistema (area - lnea secundaria - dispositivo).
La direccion fsica consta de tres campos, que se representan separados por puntos:
Area (4 bits). Identifica una de las 15 areas. A=0 corresponde a la direccion de la lnea
de areas del sistema.
Lnea (4 bits). Identifica cada una de las 15 lneas en cada area. L=0 se reserva para
identificar a la lnea principal dentro del area.
Dispositivo (8 bits). Identifica cada uno de los posibles dispositivos dentro de una
lnea, hasta 255. D=0 se reserva para el acoplador de lnea.
En la lnea de areas se conectan hasta 15 acopladores de area (AA), cuyas direcciones iran
desde 1.0.0 hasta 15.0.0. Esta lnea puede tener conectados dispositivos normales (direcciones
0.0.>0). Cada area tiene una lnea principal, con su fuente de alimentacion, a la que se
conectan los acopladores de lnea (AL), con direcciones 1.1.0 a 15.0.0, y a cada lnea secundaria
conectada a un acoplador de lnea pueden conectarse hasta 64 dispositivos.
Para la interconexion de diferentes lneas y diferentes areas se emplea la unidad de
acoplamiento. Este elemento es el mismo para los diferentes tipos de conexion, y depen-
diendo de la direccion fsica que se le asigne actuara como acoplador de lnea, acoplador de
area, o incluso repetidor dentro de una misma lnea.
En el caso del acoplador de lnea o de area, la unidad de acoplamiento actua como en-
caminador (router), y mantiene una tabla interna de direcciones de las subredes que conecta
para aislar el trafico entre ellas.
Direcciones de grupo
Las direcciones de grupo se emplean para definir funciones especficas del sistema, y son
las que determinan las asociaciones de dispositivos en funcionamiento (y la comunicacion
entre sus objetos de aplicacion).
Las direcciones de grupo asignan la correspondencia entre elementos de entrada al sistema
(sensores) y elementos de salida (actuadores). Se pueden utilizar dos tipos de direccionamiento
de grupo: de dos y tres niveles, dependiendo de las necesidades en la jerarquizacion de las
funciones del sistema.
1. Los sensores solo pueden enviar una direccion de grupo (solo se les puede asociar una
direccion de grupo).
3. Los actuadores pueden responder a mas de una direccion de grupo (pueden estar direc-
cionados o asociados a varios sensores simultaneamente).
Ejemplo de direccionamiento
La siguiente figura ilustra un ejemplo sencillo de asociacion de elementos en una instalacion
EIB. En el se dispone de nueve componentes distribuidos en dos salas, y cableados en la misma
lnea de bus (una sola fuente de alimentacion).
Los pulsadores P1 y P2 se emplean para encender y apagar simultaneamente todas las
luces de sus respectivas salas, y el sensor crepuscular S para apagar las mas proximas a
las ventanas cuando entra luz del exterior. Para realizar la asignacion de direcciones fsicas
debera decidirse en que area y lnea vamos a trabajar. En este caso supondremos que los
elementos estan en el area 1, lnea 1, por lo que las direcciones fsicas se asignaran arbitrari-
amente como 1.1.X, siendo X el numero de dispositivo.
Para realizar las asociaciones sensores-actuadores, sera necesario asignar las direcciones
de grupo a los componentes. En este caso emplearemos direcciones de dos niveles con la
nomenclatura P/S, siendo P el grupo principal (valores de 1 a 13) y S el grupo secundario
(puede tomar valores de 1 a 2047). La asignacion, en este caso se realiza tambien a criterio
del disenador, teniendo en cuenta las restricciones descritas en este captulo.
De este modo, se comienza asignando una direccion de grupo unica a cada sensor: P1
se asocia a 1/1, de manera que cuando el usuario pulse la tecla, se enviara por el bus un
telegrama que contendra, entre otros campos, la direccion de grupo 1/1. Dicha direccion de
grupo se asociara tambien a los actuadores L11, L12 y L13, de forma que cuando escuchen
el telegrama con esa direccion, se activaran simultaneamente.
El mismo proceso se sigue para P2, al que enviara la direccion 1/2, que se asocia tambien
a L21, L22 y L23.
Por ultimo, el sensor crepuscular S se programa para enviar la direccion 2/11, a la que
responden los actuadores L11 y L21.
Los telegramas se transmiten en modo asncrono, a una velocidad de 9600 baudios, donde
cada caracter o byte consta de 1 bit de inicio, 8 bits de datos, 1 bit de paridad par, 1 bit de
parada y una pausa de 2 bits hasta la siguiente transmision.
De este modo las transmision de un byte supone un tiempo de 1,35 ms, y la de un tele-
grama completo entre 20 y 40 ms (la mayora de las ordenes son de marcha-paro y suponen
un tiempo de envo de 20 ms).
El telegrama que se transmite por el bus, y que contiene la informacion especfica sobre el
evento que se ha producido, tiene siete campos, seis de control para conseguir una transmision
fiable y un campo de datos utiles con el comando a ejecutar.
Direccion de origen.
El dispositivo que retransmite la trama enva su direccion fsica (4 bits con el area, 4
bits de identificador de lnea y 8 bits de identificador de dispositivo), de modo que se
conozca el emisor del telegrama en las tareas de mantenimiento.
Direccion de destino.
La direccion de destino puede ser de dos tipos, en funcion del valor que tome el bit de
mayor peso de este campo (bit 17). Si tiene valor 0, se trata de una direccion fsica,
y el telegrama se dirige unicamente a un dispositivo. Si tiene valor 1, se trata de una
direccion de grupo, y el telegrama se dirige a todos los mecanismos que deben escucharlo
(los que tengan esa direccion de grupo).
En la figura siguiente podemos ver la estructura que toma la trama y los tipos de comandos
existentes:
El EIS contiene los datos utiles para cada funcion asignada a los objetos de comunicacion.
Segun este estandar existen siete tipos diferentes, cada uno asignado a un tipo de accion de
control (conmutacion, regulacion de luz, envo de valor absoluto, envo de valor en punto
flotante, etc.). De este modo se garantiza la compatibilidad entre dispositivos del mismo tipo
de diferentes fabricantes.
Los objetos de comunicacion son instancias de clases definidas en el estandar, y se
incluyen en los programas almacenados en la memoria de los dispositivos para realizar una
determinada accion. Normalmente, el programa de aplicacion que se ejecuta en un dispositivo
dispone de varios objetos de comunicacion, que pueden ser de diferentes tipos EIS.
Por ejemplo, un pulsador de dos teclas con un programa de control de iluminacion puede
tener cuatro objetos: dos de conmutacion (uno para cada tecla), tipo EIS 1, que envan las
ordenes de encendido-apagado, y otros dos de regulacion (uno para cada tecla), tipo EIS 2,
para el envo de ordenes de incremento-decremento de luminosidad.
Las asociaciones de direcciones de grupo, descritas con anterioridad, se realizan para cada
uno de estos objetos de comunicacion, de modo que un componente EIB, con una unica
direccion fsica, contiene varios sensores o varios actuadores, cuyo funcionamiento logico es
independiente.
Campo de comprobacion.
Consiste en un byte que se obtiene del calculo de la paridad longitudinal impar (LRC,
Longitudinal Redundancy Check ) de todos los bytes anteriores incluidos en el telegrama,
obteniendo cada uno de sus bits a partir del calculo de la paridad impar de los bits de
igual peso en el resto de campos.
Este campo de comprobacion es independiente del bit de paridad par que se obtiene
al realizar la transmision en modo asncrono de cada byte del telegrama, y se emplea
como una medida adicional para garantizar la fiabilidad en la transmision.
La combinacion de ambas medidas se denomina comprobacion cruzada.
Memoria ROM permanente, que contiene el software del sistema (el sistema ope-
rativo de la BCU).
Memoria RAM volatil, que contiene datos durante la operacion normal del dispo-
sitivo.
Memoria EEPROM, donde se almacenan el programa de aplicacion, la direccion
fsica y la tabla de direcciones de grupo.
Los programas de aplicacion se encuentran en una base de datos que proporciona ca-
da fabricante, y pueden ser descargados a las BCU a traves del bus utilizando el software
adecuado (ETS, EIB Tool Software).
La interfaz de aplicacion es un conector estandar de diez pines, de los cuales cinco se
usan para datos (4 digitales o analogicos y uno digital, de entrada o salida), tres se utilizan
para las tensiones de alimentacion, y uno es una entrada analogica al acoplador al bus que
se emplea para la identificacion del tipo de dispositivo final en funcion de una resistencia
situada en el mismo.
Componentes de carril DIN, con el mismo formato que las protecciones eclecticas (in-
terruptores automaticos o diferenciales).
Los componentes basicos del sistema como la fuente de alimentacion, filtro y acopladores
solo estan disponibles en la version de carril, mientras que el resto pueden encontrarse en
ambas versiones.
En las instalaciones tradicionales cada funcion requiere una lnea electrica propia, y ca-
da sistema de control precisa una red separada. Por el contrario, con el EIB se pueden
controlar, comunicar y vigilar todas las funciones de servicio y su desarrollo, con una
unica lnea comun. Con esto se puede dirigir la lnea de energa sin desvos, directa-
mente hasta el aparato consumidor.
Mayor grado de confort, gracias a la versatilidad que se consigue con este sistema,
los ilimitados recursos, la cantidad de aplicaciones que abarca y las necesidades que
satisface a los distintos tipos de usuarios.
Los anteriores argumentos se evaluan de distinta forma segun el punto de vista del
cliente o del usuario. Por ejemplo, un edificio funcional en comparacion con un edificio
residencial, personas discapacitadas en comparacion con no discapacitados, personas
jovenes en comparacion con personas mayores, etc.
Ejemplo 3: Pueden visualizarse y controlarse por medio de displays todos los estados de
un piso (temperatura, estado de apertura de puertas y ventanas o encendido de luces,
etc). Esto puede llevarse a cabo de la misma manera en instalaciones mas grandes por
medio de PCs y software de visualizacion.
Ejemplo 4: Uniendo una instalacion EIB con la red telefonica, el usuario puede controlar o
consultar el estado de las funciones del edificio (por ej. la calefaccion) usando un telefono
movil. Tambien pueden redirigirse las senales de alarma automaticamente al numero
de telefono que se desee. Igualmente, pueden repararse remotamente instalaciones EIB
y pueden ser configuradas por el instalador usando cualquier medio de comunicacion
disponible (por ej. Internet). Se reduce as de forma considerable el tiempo requerido
para el mantenimiento de la gestion del edificio.
Ejemplo 5: Una sala de conferencias grande debe poder ser divida en varias areas inde-
pendientes si la necesidad lo requiere. Insertando tabiques (paneles) de separacion. La
instalacion EIB detecta automaticamente la asignacion de interruptores y luminarias
requerida para cada seccion de la sala, no siendo necesario por consiguiente cambiar el
cableado existente.
Ejemplo 6: Instalacion de interruptores de panico (activacion por ej. de todas las luces).
Por la noche, las luces entre el dormitorio de los ninos y el bano pueden ser activadas
apretando un boton y pueden ser desactivadas despues de un periodo fijo.
Ejemplo 8: El EIB tambien puede realizar una simulacion de presencia cuando el usuario
este ausente.
Se unieron con el objeto de crear un unico estandar europeo y abierto KNX para apli-
caciones de domotica e inmotica y consolidar la marca KNX como smbolo de calidad e
interoperabilidad entre distintos fabricantes.
1. S-mode (System mode): la configuracion de Sistema usa la misma filosofa que el EIB
actual, esto es, los diversos dispositivos o nodos de la nueva instalacion son instalados
y configurados por profesionales con ayuda de la aplicacion software especialmente
disenada para este proposito, el ETS.
Este metodo es idoneo para proyectistas e instaladores KNX certificados y, sobre todo,
para grandes instalaciones.
A finales de 2003 el estandar KNX fue aprobado por el CENELEC (Comite Europeo de
Normalizacion Electrotecnica) como norma europea (EN 50090) para domotica e inmotica.
Caractersticas novedosas
Control de mas de 910 lneas KNX mediante 236 Pasarelas KNX-IP y una red de area
local.
I. Introduccion
El MIT identifico en Febrero de 2003 las diez tecnologas emergentes que cambiaran el
mundo y las redes de sensores inalambricas aparecan en primer lugar.
Las Redes de Sensores Inalambricas (Wireless Sensor Networks, WSN ) consisten
en un conjunto de nodos de pequeno tamano, de muy bajo consumo y capaces de una co-
municacion sin cables, interconectados entre s a traves de una red y a su vez conectados a
un sistema central encargado de recopilar la informacion recogida por cada uno de los sensores.
Este novedoso tipo de redes se han convertido en un campo de estudio que se encuentra en
continuo crecimiento, ya que ultimamente han surgido una serie de dispositivos que integran
un procesador, una pequena memoria, sensores y comunicacion inalambrica.
Al estar dotados con procesador, estos nodos son capaces de realizar ciertas computaciones
locales sobre los datos tomados, lo que permite una serie de ventajas como una reduccion de
trafico a traves de la red, ya que sera procesada localmente, y consecuentemente una logica
descarga de trabajo del computador central.
Las redes de sensores con cables no son nuevas y sus funciones incluyen medir niveles de
temperatura, lquido, humedad etc. Muchos sensores en fabricas o coches por ejemplo, tienen
su propia red que se conecta con un ordenador o una caja de controles a traves de un cable
y, al detectar una anomala, envan un aviso a la caja de controles.
La diferencia entre los sensores que todos conocemos y la nueva generacion de redes
de sensores inalambricas es que estos ultimos son inteligentes, es decir, capaces de poner
en marcha una accion segun la informacion que vayan acumulando, y no estan limitados
El ambito de aplicacion de este tipo de sistemas, como veremos, es muy amplio: monitori-
zacion de entornos naturales, aplicaciones para defensa, aplicaciones medicas en observacion
de pacientes, etc. El motivo del exito de este tipo de redes de sensores se debe a sus especiales
caractersticas fsicas.
A los nodos de las redes se les imponen unas restricciones de consumo severas. El motivo
de la imposicion de estas restricciones es la necesidad de que los nodos sean capaces de operar,
por s mismos, durante periodos largos de tiempo, en lugares donde las fuentes de alimentacion
son si no inexistentes, de baja potencia. El tamano es otra restriccion que cada vez se hace
mas necesaria para la mayora de las aplicaciones, de manera que las tarjetas o nodos que
forman las redes de sensores sean cada vez de menor tamano.
Desde el punto de vista del software, para la realizacion de las aplicaciones para redes de
sensores, la Universidad de Berkeley e Intel han desarrollado una plataforma especfica para
este tipo de sistemas, que tiene en cuenta las restricciones de los nodos. En particular se ha
desarrollado un sistema operativo, llamado TinyOS, cuya caracterstica principal reside en
que al ser modular resulta ideal para instalarse en sistemas con restricciones de memoria.
Se desarrollo tambien un lenguaje de programacion, llamado nesC, de sintaxis muy pare-
cida a C, basado en componentes, y a partir del cual se rediseno una primera version de
TinyOS de modo que actualmente esta ntegramente implementado sobre nesC.
Tanto nesC como TinyOS estan basados en componentes e interfaces bidireccionales.
Ademas, actualmente, Berkeley e Intel han desarrollado diversas aplicaciones a modo de
ejemplo, simuladores de ejecucion, y varias universidades internacionales estan dedicando
esfuerzos al desarrollo de aplicaciones usando esta emergente tecnologa.
Existen otras empresas que son proveedores de esta tecnologa, el mayor de estos es Cross-
bow Technology, que ha desarrollado redes de sensores a gran escala para su uso comercial.
Las ultimas investigaciones apuntan hacia una eventual proliferacion de redes de sensores
inteligentes, redes que recogeran enormes cantidades de informacion hasta ahora no registrada
que contribuira de forma favorable al buen funcionamiento de fabricas, al cuidado de cultivos,
a tareas domesticas, a la organizacion del trabajo y a la prediccion de desastres naturales
como los terremotos. En este sentido, la computacion que penetra en todas las facetas de la
vida diaria de los seres humanos esta a punto de convertirse en realidad.
Si los avances tecnologicos en este campo siguen a la misma velocidad que han hecho en
los ultimos anos, las redes de sensores inalambricas revolucionaran la capacidad de interaccion
de los seres humanos con el mundo.
I.1. Historia
Las redes de sensores nacen, como viene siendo habitual en el ambito tecnologico, de
aplicaciones de caracter militar.
La primera de estas redes fue desarrollada por Estados Unidos durante la guerra fra y
se trataba de una red de sensores acusticos desplegados en el fondo del mar cuya mision
era desvelar la posicion de los silenciosos submarinos sovieticos, el nombre de esta red era
SOSUS (Sound Surveillance System). Paralelamente a esta, tambien EE.UU. desplego una
red de radares aereos a modo de sensores que han ido evolucionando hasta dar lugar a los
famosos aviones AWACS, que no son mas que sensores aereos. SOSUS ha evolucionado hacia
aplicaciones civiles como control ssmico y biologico, sin embargo AWACS sigue teniendo un
Ha sido a finales de los anos 90 y principios de nuestro siglo cuando los sensores han
empezado a coger una mayor relevancia en el ambito civil, decreciendo en tamano e incre-
mentando su autonoma. Companas como Crossbow han desarrollado nodos sensores del
tamano de una moneda con la tecnologa necesaria para cumplir su cometido funcionando
con bateras que les hacen tener una autonoma razonable y una independencia inedita.
El futuro ya ha empezado a ser escrito por otra compana llamada Dust Inc, compuesta
por miembros del proyecto Smart Dust ubicado en Berkeley, que ha creado nodos de un
tamano inferior al de un guisante y que, debido a su minusculo tamano, podran ser creadas
multiples nuevas aplicaciones.
Tal y como vemos en esta figura podemos establecer, por tanto, una serie de elementos
que componen de forma general una WSN:
1. Sensores.
De distinta naturaleza y tecnologa, toman del medio la informacion y la convierten en
senales electricas.
2. Nodos sensores.
Son los procesadores de radio, que toman los datos del sensor a traves de sus puertas
de datos, y envan la informacion a la estacion base.
3. Pasarelas o Gateways.
Elementos para la interconexion entre la red de sensores y una red TCP/IP.
4. Estaciones base.
Recolector de datos basado en un ordenador comun o sistema integrado.
5. Red inalambrica.
Tpicamente basada en el estandar 802.15.4 - ZigBee.
Gran Escala.
La cantidad de nodos que se despliega en una red puede llegar hasta los miles, pudiendo
crecer su numero a lo largo de la vida de la red. La red se va a componer de muchos
sensores densamente desplegados en el lugar donde se produce el fenomeno y, por lo
tanto, muy cerca de el.
Topologa variable.
La posicion en que se coloca cada nodo puede ser arbitraria y normalmente es desconoci-
da por los otros nodos. La localizacion no tiene porque estar disenada ni preestablecida,
lo que va a permitir un despliegue aleatorio en terrenos inaccesibles u operaciones de
alivio en desastres. Por otro lado, los algoritmos y protocolos de red deberan ser au-
toorganizativos.
Recursos limitados.
Los sensores, a cambio de su bajo consumo de potencia, coste y pequeno tamano dispo-
nen de recursos limitados. Los dispositivos actuales mas usados, los mica2, cuentan con
procesadores a 4 MHz, 4 Kbytes de RAM, 128 Kbytes de memoria de programa y 512
Kbytes de memoria flash para datos. Su radio permite trasmitir a una tasa de 38.4
KBaudios.
Comunicacion.
Los nodos sensores usan comunicacion por difusion y debido a que estan densamente
desplegados, los vecinos estan muy cerca unos de otros y la comunicacion multihop
(salto multiple de uno a otro) consigue un menor consumo de potencia que la comu-
nicacion single hop (salto simple). Ademas, los niveles de transmision de potencia se
mantienen muy bajos y existen menos problemas de propagacion en comunicaciones
inalambricas de larga distancia.
Funcionamiento autonomo.
Puede que no se acceda fsicamente a los nodos por un largo periodo de tiempo. Incluso
tal vez esto nunca ocurra. Durante el tiempo en el que el nodo permanece sin ser
atendido puede que sus bateras se agoten o su funcionamiento deje de ser el esperado.
Eficiencia energetica.
Es uno de los asuntos mas importantes en redes de sensores. Cuanto mas se consiga
bajar el consumo de un nodo mayor sera el tiempo durante el cual pueda operar y,
por tanto, mayor tiempo de vida tendra la red. La aplicacion tiene la capacidad de
bajar este consumo de potencia restringiendo el uso de la CPU y la radio FM. Esto se
consigue desactivandolos cuando no se utilizan y, sobre todo, disminuyendo el numero
de mensajes que generan y retransmiten los nodos.
Autoorganizacion.
Los nodos desplegados deben formar una topologa que permita establecer rutas por
las que mandar los datos que han obtenido. Los nodos necesitan conocer su lugar en
esta topologa, pero resulta inviable asignarlo manualmente a cada uno, debido al gran
numero de estos. Es fundamental, por tanto, que los nodos sean capaces de formar la
topologa deseada sin ayuda del exterior de la red. Este proceso no solo debe ejecutarse
cuando la red comienza su funcionamiento, sino que debe permitir que en cada momento
la red se adapte a los cambios que pueda haber en ella.
Escalabilidad.
Puesto que las aplicaciones van creciendo con el tiempo y el despliegue de la red es
progresivo, es necesario que la solucion elegida para la red permita su crecimiento. No
solo es necesario que la red funcione correctamente con el numero de nodos con que
inicialmente se contaba, sino que tambien debe permitir aumentar ese numero sin que
las prestaciones de la red caigan drasticamente.
Tolerancia a fallos.
Los sensores son dispositivos propensos a fallar. Los fallos pueden deberse a multiples
causas, pueden venir a raz del estado de su batera, de un error de programacion, de
condiciones ambientales, del estado de la red, etc. Una de las razones de esta probabili-
dad de fallo radica precisamente en el bajo coste de los sensores. En cualquier caso, se
deben minimizar las consecuencias de ese fallo. Por todos los medios se debe evitar que
un fallo en un nodo individual provoque el mal funcionamiento del conjunto de la red.
Tiempo real.
Los datos llegan a su destino con cierto retraso. Pero algunos datos deben entregarse
dentro de un intervalo de tiempo conocido. Pasado este dejan de ser validos, como
puede pasar con datos que impliquen una reaccion inmediata del sistema, o se pueden
originar problemas serios como ocurrira si se ignora una alarma crtica. En caso de
que una aplicacion tenga estas restricciones debe tomar las medidas que garanticen la
llegada a tiempo de los datos.
Seguridad.
Las comunicaciones wireless viajan por un medio facilmente accesible a personas ajenas
a la red de sensores. Esto implica un riesgo potencial para los datos recolectados y para el
funcionamiento de la red. Se deben establecer mecanismos que permitan tanto proteger
los datos de estos intrusos, como protegerse de los datos que estos puedan inyectar en
la red.
Segun la aplicacion que se disene algunos de los anteriores requisitos cobran mayor im-
portancia. Como ejemplo podemos considerar una aplicacion que controle el comportamiento
de animales salvajes dentro de un parque natural. Para determinar su localizacion, cada uno
de estos animales llevara sujeto un pequeno sensor. En esta situacion la capacidad de au-
toorganizacion cobrara gran importancia. Sin embargo, si pensamos en una red con nodos
inmoviles, como los usados en la red domotica de una oficina, este mismo atributo sera de
menor importancia.
Es necesario encontrar el peso que cada uno de estos requisitos tiene en el diseno de la red,
pues normalmente unos requisitos van en detrimento de otros. Por ejemplo, dotar a una red
de propiedades de tiempo real podra implicar aumentar la frecuencia con la que se mandan
mensajes con datos, lo cual repercutira en un mayor consumo de potencia y un menor tiempo
de vida de los nodos.
Esto lleva a buscar, para cada aplicacion, un compromiso entre los requisitos anteriores
que permita lograr un funcionamiento de la red adecuado para la mision que debe realizar.
Arquitectura centralizada
En este tipo de arquitectura los nodos de una red que estudian un fenomeno enviaran sus
datos directamente a la pasarela mas cercana, que dirige el trafico de esa red en concreto.
Arquitectura distribuida
A continuacion vamos a ver por que son diferentes las WSN de las redes tradicionales y
por que existen algoritmos y protocolos que no se ajustan a las redes de sensores, ya que se
encuentran diferencias fundamentales en los principales objetivos de ambas redes.
Las WSN utilizan una comunicacion inalambrica y, obviamente, son diferentes de las
redes cableadas. Tambien son diferentes de las tradicionales redes inalambricas como las
redes celulares, Bluetooth o las moviles ad hoc (MANETS). En estas redes, el objetivo es
optimizar el rendimiento y el retardo. Aunque las MANETS comparten las caractersticas
de desarrollo ad hoc y autoconfiguracion de los nodos, el consumo de potencia no es una
prioridad. Bluetooth tambien trata los mismos problemas de limitacion de potencia pero el
grado de bajo consumo de potencia que se requiere en las WSN es mucho mayor. Ademas, los
nodos sensores son frecuentemente expuestos a extremas condiciones ambientales, haciendolos
propensos a frecuentes fallos en los nodos. Esto conlleva unas restricciones estrictas en las
WSN, no como en las otras redes.
Capa fsica
Aunque la transmision en las WSN puede ser por infrarrojos, radio o medio optico, la
banda industrial, cientfica y medica de los 915MHz (ISM) se ha hecho muy popular en las
redes de sensores. La deficiencia de usar infrarrojos o medios opticos para la tranmision es que
requieren que los nodos transmisor y receptor mantengan una lnea de contacto visible. Sin
embargo, algunas especificaciones inalambricas como Bluetooth, HomeRF, y las redes LAN
Wireless especificadas por el IEEE 802.11b operan todas en la frecuencia de los 2.4GHz.
Capa de enlace
La responsabilidad de la capa de enlace es establecer un enlace fiable o una infraestructura
de red sobre la que los datos puedan ser encaminados. Existen especificaciones como Bluetooth
que utilizan la multiplexacion por division en el tiempo (TDMA) con saltos de frecuencia
mientras que las redes LAN inalambricas especificadas por el 802.11b utilizan un metodo de
acceso al medio con deteccion de portadora y evitando colisiones (CSMA/CA).
La necesidad de un nuevo protocolo de capa MAC para WSN radica en que las dificultades
de las WSN son muy distintas de los problemas que tenan las especificaciones existentes. Por
ejemplo, el alcance de un piconet, que es una coleccion de ocho nodos, en una red Bluetooth
es de 32 pies, mientras que el alcance requerido es mucho mas pequeno en una WSN. En
las redes celulares, las estaciones base forman una columna cableada proporcionando una
estructura parcial a la red. En las WSN, no hay estaciones base.
Un protocolo de capa MAC para las WSN es el llamado MAC autoorganizado para redes
de sensores (SMACS), que configura la capa de enlace. El algoritmo de escucha y registro
(EAR) permite a los nodos sensores moviles interconectar nodos estacionarios. SMACS actua
al crear la red detectando los nodos vecinos usando transferencia de mensajes. En SMACS,
un canal se define con un par de intervalos de tiempo. La deteccion de vecinos y la asignacion
de canales se combina en una fase, para que cuando los nodos vayan a escuchar a sus vecinos,
ya hayan formado una red conectada. No hay jerarquas asumidas en SMACS y por esto se
forma una topologa llana. El algoritmo EAR tiene el problema del control de la movilidad
cuando se introducen nodos moviles en la red.
Capa de red
El encaminamiento en las WSN es bastante similar al de los protocolos ad hoc en las
redes MANETS. La diferencia es que en los algoritmos de enrutamiento ad hoc, el consumo
de potencia es secundario. En redes Bluetooth, las comunicaciones de un nodo master con
siete esclavos definen un piconet. Cuando los piconets estan interconectados para formar redes
dispersas, las diferentes topologas limitan a los nodos que las forman. Para una WSN con
la posibilidad de cientos de nodos, esto no sera suficiente. Y no solo eso, sino que tambien el
coste proyectado de un dispositivo Bluetooth es menos de $4 mientras que el precio estimado
de un nodo sensor es de menos de $1. Ademas, los requisitos de potencia de los nodos sensores
son mucho menores que para Bluetooth.
Varios algoritmos se han propuesto para el encaminamiento de WSN. El principal objetivo
de los algoritmos es el bajo consumo. Se pueden clasificar como aquellos que determinan:
4. Rutas en las que la mnima potencia disponible es la maxima entre todos los demas
caminos.
Capa de transporte
La necesidad de una capa de transporte radica en que las WSN necesitan ser conectadas a
una red mas grande, como Internet. Las WSN se conectan a Intenet por medio de pasarelas.
El protocolo de la capa de transporte que conecta el usuario con la pasarela podra ser TCP
o UDP, ya existentes.
Sin embargo, el protocolo que conecta la pasarela y los nodos sensores tendra que ser
diferente ya que no hay un esquema de direccionamiento global en una red de sensores. La
limitacion de memoria en los nodos sensores conlleva una cuestion importante en tanto que
se prefieren protocolos que requieran un bajo almacenamiento de informacion de estado antes
que otros del tipo TCP.
Capa de aplicacion
Los nodos sensores tienen muchas aplicaciones distintas. Disenar un capa de aplicacion
tiene el merito de que las WSN pueden ser conectadas a grandes redes como Internet. El
direccionamiento de nodos es una cuestion importante aqu ya que, no como en otras redes,
los nodos sensores no tienen un identificativo global.
Los protocolos de la capa de aplicacion como el Protocolo de Administracion de Sensores
(SMP) y el Protocolo de Peticion de Sensores y Entrega de Datos (SQDDP) estan actualmente
en investigacion. El SQDDP introduce una interfaz de peticiones para emitir peticiones,
responderlas y recopilar las respuestas de las peticiones.
Aunque las aplicaciones de las WSN son diversas, las ultimas investigaciones indican que
se van a tener que realizar mas desarrollos en el direccionamiento de varios protocolos en todas
las capas. Ademas, se necesita una plataforma comun donde se puedan probar los algoritmos
propuestos. Las simulaciones de WSN son difciles y normalmente estan vinculadas a una
aplicacion en particular.
El area de las WSN es un area en expansion y en los proximos anos veremos los resultados
de los esfuerzos que se estan realizando en estas aplicaciones.
El estandar usa CSMA/CA como acceso al medio, acceso multiple con deteccion de por-
tadora evitando colisiones y soporta topologas en estrella y punto a punto.
Opera en las bandas libres de los 2.4 Ghz, 915 MHz y 868 MHz, y, al igual que WiFi, usa
DSSS (Direct Sequence Spread Spectrum) como metodo de transmision y se focaliza en las
capas inferiores de red (Fsica y MAC).
La transimision se realiza a 20 kbps para el caso de las frecuencias de 915/868 MHz
mientras que aumenta a 250 kbps para las que son de 2.4 GHz. Finalmente, el rango de
transmision esta entre los 10 y 75 metros, dependiendo de la potencia de transmision y del
entorno.
En esta tabla comparativa podemos observar como cada estandar tiene unas caractersti-
cas distintas en cuanto a velocidad de transmision, memoria necesaria o vida de las bateras,
por lo que se enfocan para unas aplicaciones y parametros clave muy distintos.
Una red ZigBee puede estar formada por hasta 255 nodos los cuales tienen la mayor
parte del tiempo el transmisor ZigBee dormido con objeto de consumir menos que otras
tecnologas inalambricas. El objetivo es que un sensor equipado con un transmisor ZigBee
pueda ser alimentado con dos pilas AA durante al menos 6 meses y hasta 2 anos.
Como comparativa, la tecnologa Bluetooth es capaz de llegar a 1 Mbps en distancias de
hasta 10 m operando en la misma banda de 2,4 GHz, solo puede tener 8 nodos por celda y
esta disenado para mantener sesiones de voz de forma continuada, aunque pueden construirse
redes que cubran grandes superficies ya que cada ZigBee actua de repetidor enviando la senal
al siguiente, etc.
En la siguiente grafica se puede ver claramente donde se ajusta cada estandar, en funcion
de su alcance y su tasa de datos, aunque habra que tener en cuenta factores que diferencian
el Bluetooth de Zigbee como es el consumo de potencia que hemos comentado.
Se espera que los modulos ZigBee sean los transmisores inalambricos mas baratos jamas
producidos de forma masiva, con un coste estimado alrededor de los 2 euros. Dispondran de
una antena integrada, control de frecuencia y una pequena batera.
ZigBee Alliance es una alianza, sin animo de lucro, de mas de 100 empresas, la ma-
yora de ellas fabricantes de semiconductores, con el objetivo de auspiciar el desarrollo e
implantacion de una tecnologa inalambrica de bajo coste. La alianza de empresas esta tra-
bajando codo con codo con IEEE para asegurar una integracion, completa y operativa. Los
principales mercados de la ZigBee Alliance son la automatizacion de viviendas, edificios y la
automatizacion industrial.
Ademas de ser el estandar aceptado y utilizado por las WSN, ZigBee es un sistema ideal
para redes domoticas, especficamente disenado para reemplazar la proliferacion de sensores
y actuadores individuales. ZigBee fue creado para cubrir la necesidad del mercado de un
sistema a bajo coste, un estandar para redes Wireless de pequenos paquetes de informacion,
bajo consumo, seguro y fiable.
Podemos, por tanto, describir una serie de problemas que estan en estudio para conseguir
posibles soluciones o mejoras, tanto a nivel hardware como de programacion:
Nodos moviles.
Nodos con alta probabilidad de fallo.
Nodos que entran en el sistema.
Cuanto mas nodos haya en la red mayor sera el rendimiento.
Los nodos sensores pueden adoptar diversas formas de trabajo, pueden actuar en modo
continuo, por deteccion de eventos, por identificacion de eventos, toma de datos localizados
o como control local de actuadores (idoneo para aplicaciones domoticas).
Si tenemos el tipo de monitorizacion que van a realizar los sensores, podemos hacer
una primera clasificacion de aplicaciones, en tres tipos distintos que tendran las siguientes
propiedades:
Monitorizacion de seguridad.
Son aplicaciones para detectar anomalas o atanques en entornos monitorizados conti-
nuamente por sensores. No estan continuamente enviando datos, consumen menos y lo
que importa es el estado del nodo y la latencia de la comunicacion: se debe informar en
tiempo real.
Como ejemplos tenemos el control de edificios inteligentes, deteccion de incendios, apli-
caciones militares, seguridad, etc.
Tracking.
Aplicaciones para controlar objetos que estan etiquetados con nodos sensores en una
region determinada. La topologa aqu va a ser muy dinamica debido al continuo
movimiento de los nodos: se descubriran nuevos nodos y se formaran nuevas topologas.
Redes hbridas
Son aquellas en las que los escenarios de aplicacion reunen aspectos de las tres categoras
anteriores.
Deteccion de inundaciones.
Ejemplo: sistema ALERT desplegado en EEUU. Hay sensores de lluvia, nivel de agua y
meteorologicos. Proporcionan informacion a una estacion base centralizada. Hay proyec-
tos de investigacion que investigan enfoques distribuidos en interaccion con los nodos
sensores en campo para proporcionar consultas en momentos fijos (snapshot) o en es-
pacios temporales largos (long-running queries).
Agricultura de precision.
Beneficios obtenidos de monitorizar niveles de pesticidas en agua potable, niveles de
erosion del suelo y niveles de polucion del aire en tiempo real.
Los nodos sensores pueden ser introducidos en aparatos domesticos como aspiradoras,
microondas, hornos, frigorficos y VCRs. Esto permite que sean manejados remotamente por
los usuarios finales mediante una comunicacion que se realizara va satelite o Internet.
A traves de las redes de sensores pueden crear hogares inteligentes donde los nodos se
integran en muebles y electrodomesticos. Los nodos dentro de una habitacion se comunican
entre ellos y con el servidor de la habitacion. Estos servidores de habitaciones se comunican
tambien entre ellos dando as conectividad entre distintas habitaciones.
Se crea lo que llamamos un entorno inteligente, cuyo diseno puede tener dos enfoques:
Desde el punto de vista humano: el entorno se adapta a necesidades del usuario final
en terminos de capacidades de entrada-salida.
Desde el punto de vista tecnologico: hay que desarrollar nuevas tecnologas hardware,
soluciones de redes y servicios middleware.
Los sensores pueden integrarse en muebles y aparatos. Se comunican entre ellos y con
servidores o actuadores de habitacion, que a su vez se comunican con otros servidores de
habitacion. Todos ellos se integran y organizan con los dispositivos integrados existentes para
autoorganizarse, autorregularse y autoadaptarse basandose en modelos de control.
Museos interactivos.
Para que los ninos interactuen con objetos y experimentos, y reaccionen al toque o
al habla. Tambien permitira el aviso y localizacion de personas dentro del recinto.
(Ejemplo: exploratorium en museo de San Francisco).
Gestion de inventarios.
En el almacen, cada artculo lleva pegado un sensor, de modo que se puede conocer en
todo momento su localizacion y numero de artculos por categora. Para dar de alta
nuevos artculos se les pega el sensor y se llevan al almacen.
Un mote, tambien conocido como nodo sensor, es un elemento que, como ya hemos
descrito anteriormente, es un dispositivo capaz de observar y tomar medidas de un fenomeno.
Es lo que se denomina en ingles como sensing.
El mote combina capacidades de recoleccion, procesado y transmision de datos en un
mismo dispositivo, logrando todo esto con un reducido coste economico, tamano y consumo
de potencia.
Los sensores que lleva incorporado el nodo pueden ser de diferentes tipos: presion, humedad,
temperatura, movimiento, etc. dando lugar a las distintas aplicaciones posibles que comen-
tamos en el apartado anterior.
De esta forma, podemos establecer una serie de caractersticas generales que se dan para
los nodos sensores:
1. Integran sensores para realizar mediciones. Estos pueden ser de luz, temperatura, pre-
sion, humedad, etc.
Energa. Ya que suelen estar alimentados por medio de bateras y el bajo consumo
es una de sus prioridades.
Capacidad de computo y memoria. Aun no disponen de grandes capacidades de
procesador y de almacenamiento, aunque este campo esta desarrollandose y am-
pliandose cada da.
Memoria. La capacidad de alacenamiento tambien es limitada.
5. Alta probabilidad de fallo, teniendo en cuenta las condiciones a las que se exponen los
sensores. Deben tener costes de produccion muy bajos y ser desechables.
7. Se adaptan al entorno.
Por otro lado, podemos establecer una serie de factores que evaluan y catalogan los tipos
y caractersticas de los nodos sensores. Estos factores seran: Energa, flexibilidad, robustez,
seguridad, comunicacion, computacion, sincronizacion, tamano y coste.
Todo esto tiene que caber en un modulo del tamano de una caja de cerillas y, a veces, en
un tamano de un centmetro cubico para poder suspenderlo en el aire.
Aunque cada vez hay procesadores mas pequenos y rapidos, las unidades de proce-
samiento y almacenamiento en los nodos son recursos escasos. Por ejemplo, Smart Dust mote
lleva un Atmel AVR8535 de 4MHz con memoria flash de instrucciones de 8K y 512 bytes de
RAM y 512 bytes de EEPROM. El sistema operativo TinyOS que usan ocupa 3500 bytes de
memoria quedadndo 5400 para codigo. Otro caso: uAMPS tiene un microprocesador SA-1110
de 59-206 MHz y ejecuta un sistema operativo multihilo.
Los transceptores pueden ser dispositivos opticos activos o pasivos (como en smart dust
motes), o radiofrecuencia. Radiofrecuencia requiere modulacion, filtro pasa banda, filtrado,
demodulacion y circuito multiplexor, lo que los hace complejos y caros. Ademas, las perdidas
en la transmision pueden llegar a ser mayores que la distancia a la cuarta, porque estan muy
cerca del suelo.
Aun as, se prefieren transceptores RF en la mayora de proyectos de investigacion porque
los paquetes transportados son pequenos y las tasa de transferencia pequenas (generalmente
menores a 1Hz), y la reutilizacion de frecuencias es alta debido a las cortas distancias de
comunicacion.
Por ello se puede usar electronica de radio de bajo ciclo de trabajo. Aun as, el diseno de
una electronica de comunicaciones energeticamente eficiente es todava un reto. Por ejemplo,
Bluetooth consume demasiada energa solo en encendidos y apagados.
Como muchas veces son inaccesibles, la vida del sensor depende de la fuente de energa,
que ademas es escasa por las limitaciones en el tamano. En una Smart Dust mote se dispone
de 1J de capacidad de batera. En WINS (Wireless Integrated Network Sensors) el consumo
medio es de 30uA para proporcionar tiempos de vida largos. Se puede ampliar la vida con
recoleccion de energa, en muchos casos con celulas solares.
El consumo de energa de los nodos sensores, como ya hemos comentado, es uno de las
principales limitaciones que tienen estos dispositivos. Por ello, se han realizado ciertas es-
trategias hardware y software para conseguir un ahorro de energa, de modo que el tiempo y
la duracion del mote en la red con suficiente energa sea el maximo posible.
1. Sleep.
Estado en el que el mote esta durmiendo o inactivo. Se pretende que este la mayor parte
del tiempo posible en este estado y que su consumo sea el mnimo.
2. Wakeup.
Estado de cambio, en el que el nodo se despierta y va a pasar a un estado activo.
Se produce cuando el sensor recibe algun cambio, estmulo o interrupcion programada
dentro de sus funciones de deteccion y analisis. Uno de los objetivos es que el tiempo
de wakeup sea mnimo para pasar rapidamente al estado de trabajo.
3. Active.
Es el estado activo del mote, donde esta realizando el trabajo de adquisicion, procesado
y tranmision de datos. Por supuesto, este tiempo debe ser mnimo para volver cuanto
antes al estado sleep, ya que el consumo sera el mayor de los tres que se dan en cada
fase.
A continuacion, podemos ver en una serie de tablas las cantidades de energa que se
consumen tanto para la recepcion como la transmision de mensajes. Se puede apreciar como
ademas de las operaciones de radio, otras como la modulacion o el manejador radio tambien
consumen su parte de energa y utilizan parte el procesador.
Por supuesto, la recepcion y tranmision radio hacen que los niveles de consumo de energa
puedan llegar hasta los 4uJ en el caso de la transmision, por lo que un factor importante para
reducir estos consumos sera reducir el tiempo de estado activo del mote, como sabemos.
En los ultimos anos las WSN han evolucionado mucho, principalmente por la creacion de
estos nuevos motes. La Universidad de Berkeley se puede considerar la principal responsable
de este avance, ya que fue all donde se desarrollo el primer mote. Varios anos despues, junto
con Intel Research Laboratory Berkeley, han disenado nuevos motes, los MICA2 y los MI-
CA2DOT, que son los mas usados para investigacion en redes de sensores.
Dentro de una arquitectura WSN, los nodos sensores se diferencian en dos partes: MPR,
placa del procesador y radio y MTS, placa de sensores o tambien puede que lleve adquisicion
de datos. En el caso de los Micas son placas que pueden ir por separado y unirlas mediante
pines de conexion, mientras que en el caso de los Telos, esta todo integrado en el mismo mote,
teniendo una serie de sensores concretos, dependiendo del tipo de Telos.
V.1. Micas
Dentro de la familia de los micas, podemos encontrar varios tipos. Veremos las carac-
tersticas de los Micaz, Mica2 y Mica2Dot. En la tabla de caractersticas de la siguiente
pagina podemos apreciar como ha evolucionado el tipo de procesador o, por otro lado, como
se ha pasado a trabajar en frecuencias de 2.4GHz con el Micaz comparado con la banda de los
433MHz o 915MHz de los otros modelos. La tasa de datos es mucho menor en los de menor
frecuencia, pero no es un inconveniente para nuestros objetivos.
Micaz
Los Micaz son una de las ultimas generaciones de motes que trabaja en la banda de
frecuencias de 2400 MHz a 2483.5 MHz. El MPR2400 (Micaz) usa el Chipcon CC2420, bajo
la norma protocolo IEEE 802.15.4, un transmisor integrado ZigBee y un microcontrolador
Atmega128L.
Usa, al igual que el Mica2, 51 pines de conexion I/O y una memoria flash. Ademas, sus
aplicaciones son compatibles.
A continuacion, vemos el diagrama de bloques.
Mica2
Los motes Mica2 son los modulos de tercera generacion de motes que se usan para redes de
sensores inalambricas de baja potencia. Mejoran bastante las caractersticas del Mica original:
Las distintas aplicaciones en las que se utilizan estos motes son, principalmente, las WSN,
la seguridad y vigilancia, la monitorizacion ambiental o las redes inalambricas de gran escala.
Mica2Dot
Los Mica2Dot son un tipo de motes disenados especialmente para aplicaciones donde
el tamano fsico es fundamental. Al igual que los Mica2 hay tres modelos dependiendo de
su frecuencia: MPR500 (915MHz), MPR510 (433MHz), y MPR520 (315MHz). El resto de
caractersticas son similares a las de los Mica2, lo mas importante es la forma fsica y el
reducido tamano que poseen, tal y como podemos ver en las imagenes.
Las series de placas de sensores MTS o de aquisicion de datos MDA han sido disenadas
para la familia de los Micas. Hay una gran variedad de sensores que permiten un amplio mar-
gen de modalidades diferentes. La tabla de la siguiente pagina muestra los sensores disponibles
actualmente para cada tipo de mote.
A modo de ejemplo, presentamos el modelo con el que hemos realizado algunas pruebas
de aplicaciones junto con los Mica2 de que disponemos en el laboratorio.
La placa sensor es el modelo MTS300CA. Este tipo de placa lleva incorporada sensores
de luz y temperatura. Ademas llevan un microfono para detectar sonidos, y un resonador
piezoelectrico, lo que se denomina un buzzer, para producir un sonido a una frecuencia de-
terminada.
V.2. Telos
Los TelosB (TPR2400) son los motes que mas importancia tienen para nosotros, ya que
hemos desarrollado la mayor parte del proyecto con ellos, programando las aplicaciones en
varios de estos dispositivos.
Este tipo de motes reune todo lo esencial para estudios de laboratorio en una plataforma
simple, incluyendo la capacidad de programacion por USB, una antena integrada con sis-
tema radio IEEE 802.15.4, un procesador de bajo consumo con una memoria extendida y un
conjunto de sensores, concretamente en el modelo TPR2420.
Antena integrada.
Bajo consumo.
Esta plataforma consigue un bajo consumo de potencia permitiendo una larga vida a las
bateras ademas de tener un tiempo mnimo en el estado de wakeup, otro de los objetivos
dentro de las estrategias de bajo consumo.
Los TelosB se alimentan de dos bateras AA, aunque si es conectado mediante el puerto
USB para programacion o comunicacion, la alimentacion la proporciona el ordenador.
Tambien se proporciona la capacidad de anadir dispositivos adicionales. Los dos conectores
de expansion de los que dispone pueden ser configurados para controlar sensores analogicos,
perifericos digitales y displays LCD.
Con todas estas caractersticas, el mote TelosB no solo proporciona mas facilidad para
programacion, mas flexibilidad y mas prestaciones, sino que es el que menos consumo de
potencia ofrece, muy por debajo de los que haba hasta ahora, permitiendo alargar la vida de
los nodos considerablemente y siendo esta su principal baza frente a los otros dispositivos.
Como ya hemos comentado anteriormente, se puede apreciar que los consumos de poten-
cia del procesador son muy inferiores en comparacion con los otros motes, la velocidad de
transferencia es bastante superior y facilidades como la conexion USB para la programacion
o el llevar la antena integrada, hacen de este prototipo uno de los mejores.
En la figura siguiente, observamos mas concretamente los tiempos de cambio de estado,
as como la potencia consumida en cada estado, obteniendo siempre los mnimos resultados
para los Telos, y consiguiendo un mayor tiempo de vida del nodo.
Conclusiones
Los Telos son los motes con el menor consumo de potencia hasta la fecha. Incluyen nu-
merosas mejoras que permiten investigar en las WSN mientras que los dispositivos van siendo
mas faciles de usar y mas baratos en lo que al coste se refiere.
Otras caractersticas, como la proteccion hardware contra escritura y la estabilidad de
la senal radio, concretan aun mas las actuales investigaciones. Los investigadores pueden
experimentar con el nuevo estandar IEEE 802.15.4 y usar trabajos existentes con TinyOS.
Una flexibilidad adicional permite que el software pueda configurar o deshabilitar modulos
hardware.
Los TelosB son modulos robustos con unas grandes prestaciones de bajo consumo de
potencia que no existan en disenos anteriores, ajustandose de forma eficiente a los objetivos
de este proyecto.
VI. TinyOS
Las redes de sensores inalambricas estan basadas en nodos de pequeno tamano que tienen
ciertas limitaciones tanto de memoria como de procesador. Ademas, sufren tambien el im-
portante inconveniente del consumo de potencia, por lo que toda mejora tanto en hardware
como software tiene que ir enfocada hacia esos objetivos que incrementen las prestaciones de
estos dispositivos.
El sistema operativo que lleva a cabo estas estrategias de software y, por tanto, se ha
convertido en la base de la programacion de los motes, es el TinyOS.
Existen otras caractersticas dignas de mencionar sobre TinyOS, como son la reprogra-
macion en red de todo el codigo de un mote, o el uso de componentes para cifrado de datos
(TinySec). Estas caractersticas y el hecho de que estuviera disponible bastante antes que
otros sistemas operativos, desde principios de 2003, han hecho que sea el sistema operativo
mas extendido para redes de sensores.
Sin embargo, TinyOS tiene algunos inconvenientes. Puesto que solo hay un hilo de eje-
cucion para tareas y el planificador de estas es una cola FIFO, no se tienen garantas de
tiempo real. Este hilo de ejecucion para tareas no ofrece gestion de prioridades, lo unico que
TinyOS hace al respecto es permitir que los nuevos eventos desalojen a las tareas que puedan
ejecutarse.
El entorno de programacion que ofrece puede resultar muy complicado para progra-
madores novatos, que deben tratar con cuestiones de programacion asncrona y temporizacion.
Ademas hay algunas caractersticas de las que este sistema operativo no dispone, como me-
canismos fiables de sincronizacion de datos entre nodos o proteccion de memoria, si bien el
carecer de esta ultima le hace requerir menos recursos para su ejecucion.
Tampoco proporciona conectividad con grandes infraestructuras de servicios como Inter-
net. Aunque esto ultimo es un problema menor, ya que es posible el uso de aplicaciones que
sirvan de puente entre las redes de sensores y otras redes como las basadas en TCP/IP. La
reprogramacion en red s es posible, pero, como se comento anteriormente, se debe reprogra-
mar todo el codigo que se ejecuta en el mote.
Proyectos TinyOS
Presentamos una serie de ejemplos de proyectos con TinyOS que se estan realizando
actualmente en la Universidad de Berkeley:
Great Duck Island: Nuestro objetivo es permitir a los investigadores de cualquier parte
del mundo dedicarse a la monitorizacion no-intrusiva de la vida salvaje y sus habitantes.
Los motes sensores estan monitorizando el habitat de la isla y transmitiendo sus lecturas
por satelite, lo que permite a los investigadores descargar los datos del entorno en tiempo
real a traves de Internet.
Mate: Maquinas virtuales de aplicacion especfica para redes TOS. Permiten la progra-
macion de motes mediante simples scripts.
VI.1. nesC
nesC es una extension del lenguaje de programacion C disenado para plasmar los con-
ceptos de estructuracion y los modelos de ejecucion de TinyOS.
Los conceptos basicos que hay tras nesC son:
Las interfaces son bidireccionales: especifican un conjunto de funciones para ser imple-
mentadas por el proveedor de la interfaz (los metodos) y un conjunto para ser im-
plementados por el usuario de la interfaz (los eventos). Esto permite que una interfaz
simple represente una interaccion compleja entre componentes (por ejemplo, registrar
algo de interes de un evento, seguido por una llamada cuando el evento ocurre). Esto es
importante porque todos los metodos largos en TinyOS (por ejemplo, enviar paquetes)
son de no-bloqueo; se indica que se han completado a traves de un evento (envo reali-
zado). Mediante las especificaciones de las interfaces, un componente no puede llamar
al metodo enviar hasta que proporcione una implementacion del evento envo realizado.
Los componentes estan conectados estaticamente a otros por medio de las interfaces.
Esto incrementa la eficiencia del tiempo de ejecucion, fomentando el diseno robusto y
permitiendo un mejor analisis estatico de los programas.
nesC esta disenado bajo la expectacion de que el codigo sera generado por compiladores
de programas-completos. Esto debera tambien permitir una mejor generacion de codigo
y analisis.
Estructura de un componente
Una aplicacion nesC consiste en uno o mas componentes unidos para formar un ejecutable.
Un componente proporciona y usa interfaces. Estas interfaces son el punto de acceso al com-
ponente y son bidireccionales. Una interfaz declara un conjunto de funciones (metodos) que
la proveedora debe implementar y otro conjunto de funciones (eventos) que la usuaria debe
implementar. Para llamar a los metodos de una interfaz, se deben implementar los eventos de
esa interfaz. Un componente simple puede usar o proporcionar multiples interfaces y multi-
ples instancias de la misma interfaz.
Hay dos tipos de componentes en nesC: los modulos y las configuraciones. Los modulos
proporcionan el codigo de la aplicacion, implementando una o mas interfaces. Las configu-
raciones se usan para ensamblar los componentes unos con otros, conectando las interfaces
que usan unos componentes a las interfaces que les proporcionan otros. Esto es lo que se
llama wiring (conexionado). Cada aplicacion nesC se describe por una configuracion de alto
nivel que conecta todos los componentes que contiene.
Los ficheros que van a componer una aplicacion seran:
Puede haber mas ficheros para una misma aplicacion, si se incluyen libreras en las que
se definen diferentes estructuras necesarias para la aplicacion, como en el ejemplo:
TOSSIM / TinyViz
Es un simulador de eventos discretos para TinyOS. TOSSIM (TinyOS SIMulator ) se
compila directamente desde componentes TinyOS a la plataforma destino especificada. Gra-
cias a esto se pueden introducir sentencias en el codigo generado que informen del estado
de la simulacion. Por ejemplo, se puede saber cuando la simulacion transmite un paquete,
enciende un led, provoca una interrupcion del reloj, etc.
Permite una simulacion bastante completa de una red. Entre sus posibilidades se encuen-
tra la simulacion de las transmisiones de datos a nivel de bit fijando una probabilidad de
error de bit. Tambien puede tomar lecturas de los sensores, los datos obtenidos de ellos son
en principio aleatorios, aunque existe la posibilidad de que sean introducidos por el usuario
de TOSSIM.
Surge View
Surge View es una aplicacion Java que viene incluida con TinyOS. Permite monitorizar
una red y analizar el funcionamiento del mallado de la red. Sus caractersticas incluyen:
SerialForwarder
Esta aplicacion java permite recibir paquetes por el puerto serie del PC y reenviarlos a
traves de otros puertos del PC. De esta forma otros programas, como por ejemplo Surge
View, pueden comunicarse con la red de sensores a traves de un nodo conectado al PC que
hace de pasarela.
NesDoc
Esta utilidad permite generar documentacion automaticamente a partir del codigo fuente
de un programa. Por cada fichero fuente genera un fichero HTML con un grafico que describe
el conexionado de los componentes del fichero a traves de sus interfaces y una descripcion
textual sacada de los comentarios de los ficheros fuente. Por esto, para aprovechar todas
las caractersticas de NesDoc es necesario seguir una serie de reglas al comentar los ficheros
fuente.
GRATIS II / GME
GRATIIS II (Graphical Development Environment for TinyOS ) es un entorno que ofrece
una representacion grafica de los componentes implicados en una aplicacion tinyOS. Ofrece
un traductor que permite transformar entre los modelos graficos que usa y los ficheros de
configuracion de NesC (en ambos sentidos).
TinyDB
TinyDB es un sistema de procesado de consultas para extraer informacion de una red de
sensores con TinyOS. Convierte la red en una tabla de una base de datos distribuida, donde
existe una columna por cada tipo de dato que se pretende leer (temperatura, luz, etc.).
Las consultas se realizan en el lenguaje TinySQL, una extension del lenguaje de consultas
SQL. Las extensiones realizadas a SQL permiten que al pedir una lectura se puedan especificar
Bombilla / Mate
Mate es la maquina virtual de TinyOS, Bombilla es el conjunto de componentes que
se situan sobre el sistema operativo para ejecutar los scripts de Mate. El lenguaje en el que
se escriben estos scripts tiene un numero muy limitado de operaciones pero permite que las
aplicaciones se implementen con pocas lneas de codigo.
El codigo en Bombilla se divide en capsulas de 24 bytes. Una de estas capsulas se encarga
de la recepcion de mensajes, otra de la transmision de mensajes y otra de los eventos del reloj
que permiten disparar la adquisicion de datos. Si es necesario el uso de algoritmos puede haber
otras cuatro capsulas adicionales que los contengan.
Las instrucciones de Mate hacen que la programacion ya no sea asncrona, ahora se
sabe que momento van a llegar datos de los sensores, lo cual facilita la tarea de programar
la aplicacion. Cuando se pide un dato, el programa queda esperando hasta que el sensor
obtiene y devuelve ese dato. La desventaja es clara: mientras se espera ese dato se pueden
dar situaciones de bloqueo.
Mate es adecuado para aplicaciones simples que necesitan ser reprogramadas a menudo.
Para la reprogramacion basta introducir las nuevas capsulas en la red y los propios nodos las
adoptaran si contienen una version mas moderna que la que estan ejecutando. Sin embargo,
Mate no permite realizar operaciones matematicas que sean mas complejas que una resta, ni
tampoco puede ejecutar programas extensos.
David Culler: The lack of an overall sensor network architecture(La falta de una
arquitectura general para redes de sensores).
Sin embargo, hay mucho trabajo por hacer en todos estos aspectos. Tanto a nivel fsico,
como de computacion: sistemas operativos, algoritmos distribuidos, etc. como de comu-
nicacion: protocolos de enrutamiento, mantenimiento de la topologa, descubrimiento de
vecinos, etc.
Cada vez van saliendo nuevas soluciones que permiten mejorar cada uno de estos aparta-
dos. Por ejemplo, una posible solucion distribuida sera la creacion de Middleware, que es-
tablezca una interoperabilidad entre los sistemas operativos y una aplicacion, de tal forma
que proporcione interfaces de alto nivel para enmascarar la complejidad de las redes y pro-
tocolos o que permita a los desarrolladores centrarse en cuestiones especficas de la aplicacion.
En un futuro no muy lejano veremos como las redes de sensores empezaran a verse en
todo tipo de aplicaciones como las que hemos visto en este captulo y en muchas mas que
iran surgiendo.
Problemas como las limitaciones de memoria o procesador iran desapareciendo con las
nuevas nanotecnologas y MEMs, lo que permitira bajar mucho mas el consumo de potencia,
alargar la vida de los nodos y quiza cambiar la perspectiva de estas redes hacia nuevos campos
de actuacion.
Otra aplicacion que podramos considerar futurista es la que se expone en este vdeo.
informacion de todo tipo a las centrales de control de la ciudad: niveles de temperatura, danos,
numero de coches y sus caractersticas, etc.
Cada coche implicado se muestra como una red de sensores propia, as como cada persona
lleva sus sensores que indican sus niveles de salud.
Proyecto de integracion de
WSN y domotica
I. Introduccion
Este proyecto de integracion de redes de sensores en el ambito de la domotica consiste,
basicamente, en la programacion de nodos sensores que formaran redes inalambricas dedicadas
a funciones y aplicaciones domoticas, como pueden ser el control de iluminacion, persianas,
sistemas de calefaccion, etc.
Tal y como se describe en un sistema domotico, ciertos nodos seran los sensores, que in-
teractuan con el medio, recibiendo estmulos, tomando datos o midiendo distintos parametros,
dependiendo de para que hayan sido programados.
Por otra parte, otros nodos seran configurados como actuadores. Los actuadores recibiran
la informacion de los sensores cuando se produzca un cambio, un evento o cualquier cosa que
queramos indicar y estos, en funcion de la informacion recibida, actuaran de una forma u otra,
tomando decisiones, activando aparatos, reenviando la informacion a otros nodos o incluso a
una unidad central de control.
Por estas razones, ademas de la importancia y relevancia para el futuro que ya poseen las
redes inalambricas de sensores, consideramos muy interesante y con mucho trabajo por hacer
el campo de la utilizacion de tecnologas de WSN para el diseno de una red de automatizacion
de viviendas y edificios.
Estos estudios permitiran la introduccion de la domotica en viviendas ya construidas o la
ampliacion de instalaciones existentes, proporcionaran las prestaciones de confort, seguridad,
ahorro energetico e interoperabilidad con otras redes, y habilitaran un escenario para la
creacion del ambiente inteligente y la computacion ubicua.
En primer luegar veremos algunas caractersticas de este tipo de redes que se ajustan
fielmente a nuestros objetivos.
I.1. WSAN
Las WSAN consisten en un grupo de actuadores y sensores conectados inalambricamente
para realizar medidas de sensores de forma distribuida y tareas de actuadores. La arquitectura
fsica de una WSAN es la siguiente:
En una red de este tipo, los sensores van reuniendo informacion sobre el medio fsico
mientras que los actuadores toman decisiones y ejecutan las acciones apropiadas sobre el
entorno, permitiendo a un usuario detectar y actuar a distancia.
Sin embargo, debido a la presencia de actuadores las WSAN tienen algunas diferencias
con respecto a las WSN:
Mientras que los nodos sensores son dispositivos pequenos, baratos con sensores, capaci-
dad de procesamiento y comunicacion inalambrica limitados, y el hecho de actuar sobre
un fenomeno es mas complicado y consume mas energa que medir un fenomeno, los
actuadores deberan ser nodos de recursos mas caros, con mejor capacidad de proceso,
una potencia de transmision mayor y unas bateras con mayor tiempo de vida.
En las WSAN, dependiendo del tipo de aplicacion puede que se necesite un tiempo de
respuesta rapido ante un evento. Ademas, para ejectuar las acciones correctas, los datos
medidos deben ser validos en el momento de la ejecucion. Por lo tanto, la comunicacion
en tiempo real es una cuestion muy importante en las WSAN.
El numero de nodos sensores dedicado al estudio de un fenomeno puede llegar al orden
de cientos de miles. Sin embargo, no es necesaria tal cantidad para nodos actuadores.
Para conseguir un trabajo de deteccion y actuacion efectivo, es necesario un mecanismo
local de coordinacion entre sensores y actuadores.
En el caso que nos atane, el mundo de la domotica y automatizacion de edificios tiene
unas caractersticas concretas que le diferencian de otro tipo de mercados. No sera lo mismo
unos sensores que detecten movimientos ssmicos y tengan que advertir posibles terremotos
en tiempo real, que unos sensores de una oficina que controlen la temperatura para activar
el sistema de aire acondicionado.
Por tanto, estas caractersticas de las redes WSAN se ajustan a las redes que controlaran
las viviendas inteligentes, siempre teniendo en cuenta el tipo de aplicaciones con el que estemos
tratando. Normalmente, factores como la velocidad de transferencia o el envo en tiempo real
no seran problema para el control de iluminacion o persianas, pero s con aplicaciones de
seguridad y vigilancia que estaran basadas en esos factores y de los cuales dependera que el
sistema sea fiable y efectivo.
Control
En el caso de la automatizacion de viviendas se conseguiran ventajas como una admi-
nistracion flexible de luz, calefaccion y sistemas de aire acondicionado desde cualquier parte
de la vivienda. En un edificio, por ejemplo de oficinas, tendremos una gestion centralizada e
integrada de iluminacion, calefaccion, AC y seguridad, as como para aplicaciones industriales
se podra ampliar la fiabilidad de los procesos de control e industriales y mejorar las ventajas
de administracion mediante una monitorizacion contnua de equipos importantes.
En todos los ambitos podremos tener un control automatico de multiples sistemas que
mejoran aspectos como el consumo, la flexibilidad, el confort y la seguridad.
Consumo
En el caso de viviendas con este tipo de redes podremos obtener una captura detallada de
datos utiles de utilizacion de electricidad, agua y gas, ademas de una inteligencia integrada
para optimizar el consumo de recursos naturales.
En edificios o sistemas industriales la reduccion de los gastos de energa vendra mediante
un control optimizado de los sistemas HVAC y con medidas como destinar equitativamente
los costes utiles basandose en el consumo actual. Tambien se podran identificar operaciones
ineficientes o equipos de bajo rendimiento.
Seguridad
En una vivienda individual podremos destacar una facil instalacion de sensores inalambri-
cos que monitoricen una amplia variedad de condiciones y se reciban notificaciones au-
tomaticas cuando detecten eventos inusuales dentro del marco de la seguridad.
Por otro lado, para edificios habra redes y datos integrados desde multiples puntos de con-
trol de acceso as como el desarrollo de redes de monitorizacion inalambricas para aumentar
la proteccion perimetral.
Confort
Todas las instalaciones, actualizaciones y sistemas de control de la redes domoticas son
sin cables, tambien pudiendo configurar y ejecutar multiples sistemas a distancia de forma
remota.
Flexibilidad
En el caso de automatizacion de edificios se podra efectuar una reconfiguracion rapida
de sistemas de iluminacion para crear espacios de trabajo adaptables, ademas de ampliar y
actualizar las infraestructuras del edificio con el mnimo esfuerzo.
Eficiencia
Esta ventaja puede verse claramente en sistemas industriales donde se podra realiar una
adquisicion automatica de datos mediante sensores remotos para reducir la intervencion hu-
mana y proporcionar datos detallados para mejorar los programas de mantenimiento preven-
tivos.
Control4
Control4, un lder creciente en los sistemas asequibles y de facil uso para el control
domotico y el entretenimiento, reconocio que el mejor y mas asequible de los estandares
inalambricos, combinado con la tecnologa IP, permitira la automatizacion de viviendas en
todas las casas existentes. El objetivo era desarrollar productos que se pudieran ajustar al
99 % de las viviendas, sin que tuvieran que ser de lujo ni de nueva construccion.
Control4 crea los primeros productos de control en viviendas basados en el estandar
Zigbee, que proporciona la red inalambrica para la comunicacion entre los dispositivos de la
casa.
Figura 3: Control4
Soluciones TAC
TAC es una compana lder en automatizacion de edificios, sistemas de seguridad y solu-
ciones de energa. La mision de TAC es proporcionar un valor anadido mediante servicios
de entorno de viviendas como la climatizacion interior, la seguridad y el uso de la energa,
desarrollados con tecnologas avanzadas para poder llegar a todos los usuarios y propietarios
del mundo.
Las soluciones inalambricas TAC estan basadas en una familia de controladores que se ins-
talan en todo el mundo y que proporcionan una administracion del sistema con herramientas
graficas en tiempo real para controlar la red inalambrica.
Los nodos de la red seran instalados en la vivienda con una expectativa de funcionamiento
a muy largo plazo, como cualquier interruptor habitual de nuestra casa. Los nodos dispondran
de elementos sensores y actuadores, y los datos se enviaran por dos posibles causas:
Dirigidos por eventos externos al nodo. Por ejemplo, la pulsacion de un interruptor para
dar una orden de encendido.
Por tanto, distinguiremos por un lado los nodos sensores, que detectaran los cambios
que se produzcan en la magnitud que esten midiendo o los eventos ante los que tengan que
efectuar una respuesta. Normalmente, esta respuesta sera el envo de un mensaje concreto al
nodo actuador.
Por otro lado estaran los nodos actuadores, que seran los que reciban la informacion
conveniente de los sensores y ejectuara la accion en consecuencia, ya sea encender o apagar
luces, activar o desactivar un motor de persiana o la calefaccion.
Hemos enfocado el proyecto en tres campos domoticos distintos, en cada uno de los cuales
la programacion de los sensores y actuadores depende la aplicacion que se quiera realizar:
1. Iluminacion.
Dentro de este apartado incluimos la interaccion de sensores y actuadores para realizar
distintas funciones de iluminacion: conmutacion On/Off de grupos de luces, regulacion
relativa o regulacion absoluta.
2. Persianas.
Aqu las aplicaciones seran las exclusivas de persianas, ya sean las convencionales o las
persianas de lamas, pudiendo efectuar funciones de subida/bajada total o por pasos.
Este ultimo se traducira en los giros de lamas en un sentido u otro.
Por ultimo indicar las dos importantes elecciones a la hora de afrontar el proyecto: el tipo
de sensores y la tecnologa domotica adaptada para la programacion de los mismos.
Sistema domotico: Dada su importancia actual y la expansion que esta teniendo en Eu-
ropa, elegimos el sistema EIB-KNX. En la primera parte de este proyecto vimos las
caractersticas, ventajas y desventajas de este sistema, as como las tecnicas de envo de
mensajes por medio de datagramas. Utilizaremos los mismos metodos y campos para la
programacion de nuestros sensores, de manera que sigan este mismo sistema y sean lo
mas compatibles posible, con la gran diferencia de que ya no sera un sistema cableado,
sino inalambrico.
Nodos sensores: Despues de todo lo expuesto en la segunda parte del proyecto, llegamos
a la conclusion de que los motes TelosB eran los que proporcionaban las mejores
caractersticas en cuanto a bajo consumo, haciendolos superiores al resto. Ademas de
algunas pruebas que realizamos con Micas, los TelosB han sido los utilizados para las
aplicaciones domoticas.
Aplicacion Blink
La aplicacion Blink es la tpica que se utiliza para mostrar como se implementa un pro-
grama en nesC, sus componentes y las conexiones entre las distintas interfaces.
Consiste en una aplicacion que hace parpadear un led del mote a cada interrupcion de
reloj y dicha interrupcion esta programada para cada sengundo.
StdControl es la interfaz que se usa para inicializar y arrancar los componentes TinyOS.
1 interface StdControl {
2 command result_t init () ;
3 command result_t start () ;
4 command result_t stop () ;
5 }
Codigo 2.2: Interfaz StdControl.nc
Vemos que StdControl define tres metodos: init(),start(), y stop(). init() es lla-
mado cuando un componente es incializado por primera vez, y start() cuando es arrancado,
esto es, ejecutado en realidad por primera vez. stop() es llamado cuando el componente
se para, por ejemplo, para apagar el dispositivo que esta controlando. Estos tres metodos
tienen una semantica profunda: llamar al metodo init() de un componente implica llamar
a init() en todos sus subcomponentes.
Main.StdControl ->SingleTimer.StdControl;
Main.StdControl ->BlinkM.StdControl;
Con respecto a las interfaces utilizadas, es importante advertir que las funciones de ini-
cializacion de un subcomponente deben ser explcitamente llamadas por el componente que
las use. Por ejemplo, el modulo BlinkM usa la interfaz Leds, as que Leds.init() es llamado
explcitamente por BlinkM.init().
nesC utiliza flechas para determinar la relacion entre interfaces. Para entenderlo, se puede
pensar que la flecha hacia la derecha significa se vincula a. La parte de la izquierda de la
flecha vincula una interfaz a una implementacion de la parte derecha. En otras palabras, el
componente que usa la interfaz esta en la izquierda y el componente que proporciona esa
interfaz esta en la derecha.
BlinkM.Timer ->SingleTimer.Timer;
En esta sentencia se vincula la interfaz Timer usada en BlinkM a la interfaz Timer que
proporciona SingleTimer.
nesC soporta multiples implementaciones de una misma interfaz. La interfaz Timer es
un ejemplo. El componente SingleTimer implementa un Timer simple mientras que otro
componente, TimerC, implementa multiples timers usando un identificador de timer como
parametro.
Por ejemplo:
BlinkM.Leds ->LedsC;
BlinkM.Leds ->LedsC.Leds;
La interfaz Leds define varios metodos como redOn() o redOff(), que encienden o apa-
gan los diferentes LEDs del mote. Como BlinkM usa esa interfaz, podra invocar esos metodos
para su aplicacion. Pero se debe tener en cuenta que Leds es solo una interfaz: la imple-
mentacion esta especificada en el fichero de configuracion Blink.nc (que la vinculaba con el
componente LedsC).
TIMER ONE SHOT Un timer de este tipo se va repitiendo continuamente hasta que se para con
el metodo stop().
Una aplicacion sabe que su timer ha expirado cuando recibe un evento. Esta interfaz
proporciona el evento fired().
Un evento es una funcion que la implementacion de una interfaz senalizara cuando se
produzca un evento. En nuestro caso, el evento fired() se senaliza cuando pasa el intervalo
de tiempo especificado.
Esto es un ejemplo de interfaz bidireccional: una interfaz no solo proporciona metodos
que pueden ser llamados por los usuarios de la interfaz, sino que tambien produce eventos
que llaman a los manejadores del usuario. Un modulo que usa una interfaz debe implementar
los eventos que usa esa interfaz.
CntToLedsAndRfm
Esta aplicacion es la union de dos aplicaciones existentes: CntToLeds y CntToRfm. Por
una parte, mediante un timer crea un contador que se va incrementando (en nuestro
caso, al disponer solo de tres leds el contador va de 0 a 7 y vuelve a empezar).
En la primera aplicacion muestra esa cuenta en los leds. En la segunda, a cada evento
de reloj, incrementa el contador y enva un mensaje con ese valor.
Esta aplicacion reuna ambas: incrementa el contador, lo muestra en los leds y lo enva
por radio. De aqu es importante ver como se consiguen realizar diferentes tareas, como
la cuenta del contador, tomar cierta variable para que ejecute algo concreto (encender
leds) o, lo que es mas importante, crear un mensaje que contenga dichos datos, funcion
basica de los nodos sensores.
RfmToLeds
Al programar un mote con esta aplicacion, se dispondra en estado de espera hasta que
reciba un mensaje. Concretamente, recibira un mensaje con un valor de un contador,
que mostrara en sus leds.
Esta aplicacion tambien es fundamental para nuestros objetivos, puesto que con ella
conseguimos recibir mensajes, desglosar sus campos, tomar los datos de los campos
que deseemos, procesarlos y realizar acciones dependiendo de los datos que hayamos
recibido. Es basicamente la funcion de un nodo actuador.
Sense
Esta aplicacion en concreto programa el mote para que su sensor de luz haga un
muestreo periodico y, a partir de esta lectura, muestre en los leds los tres bits mas
significativos, para poder apreciar los cambios de la intensidad de luz.
Por un lado, podemos configurar un sensor del mote, como es el de luz, pero tambien
veremos que, de forma sencilla y gracias a la programacion por modulos de nesC, tam-
bien se podra llamar a cualquiera de los sensores de que dispone el mote, para medir
temperatura o humedad.
OscilloscopeRF
Estas dos ultimas aplicaciones podemos englobarlas en lo que es la visualizacion de
datos. OscilloscopeRF lo que hace es mandar por radio las medidas que hace un sensor.
Otro mote que haga de pasarela hacia un PC, tomara estos datos y los mostrara en
pantalla.
Con esta aplicacion pudimos ver los distintos niveles de luz, las medidas que tomaban,
as como definir umbrales para ciertas aplicaciones.
A modo de ejemplo, podemos ver un grafico con las medidas de luz de dos motes.
TOSBase
La aplicacion TOSBase es la que programa un mote como pasarela para recibir pa-
quetes de datos por radio y transmitirlos por el puerto serie o USB a un ordenador.
Simplemente retransmite los paquetes que recibe y llegaran a la aplicacion que corra
en el ordenador para mostrar los datos.
En el caso anterior podamos ver un osciloscopio, pero tambien hay otras aplicaciones
como SerialForwarder o Listen, que son de gran utilidad, ya que muestran en pantalla
los mensajes al completo, con todos sus campos y valores en hexadecimal. Con esta
valiosa informacion, pudimos configurar los mensajes de acuerdo a nuestro sistema y
realizar las pruebas pertinentes.
Encender/Apagar (1.001)
Este tipo de punto de datos se utiliza para conmutar el estado de un actuador. Ante-
riormente denominado EIS1, actualmente se le llama DPT 1.001. Consta de un solo bit,
donde sus valores podran ser 1 (Encender/Abrir/Verdadero/Alarma) o 0 (Apagar/Cer-
rar/Falso/No alarma). En nuestro caso sera solo Encender o Apagar luces.
Los mensajes enviados por los nodos pulsadores llegaran a los nodos configurados como
actuadores, que llevaran asociadas una serie de direcciones de grupo ante las que tendran
que efectuar ciertas acciones.
Si un nodo actuador tiene asociada la direccion 1/1/1 y le llega un mensaje con esa di-
reccion, realizara la accion consecuente, en este caso, encender una luz.
En este caso, tenemos un nodo configurado como pulsador, cuya direccion fsica es 1.1.1.
Observamos que tiene cuatro tipos distintos de objetos de comunicacion (en realidad son solo
dos, conmutacion y regulacion relativa pero configurados para diferentes propositos) asociados
a cuatro direcciones de grupo.
Por ejemplo, la direccion 1/1/3 ordenara que haya una regulacion que disminuya la lu-
minosidad pero no sabe a que luces afectara. Enviara el mensaje y todos aquellos actuadores
que tengan asociada esa misma direccion 1/1/3 seran los que ejecuten dicha regulacion.
Por otro lado, tenemos dos actuadores con sus direcciones fsicas. En uno de ellos vemos
que tiene asociadas las direcciones de grupo 1/1/1 y 1/1/4, lo que quiere decir que se encen-
dera o se apagara de forma conmutada cuando le lleguen esos eventos de boton. Y el otro
nodo, con las direcciones 1/1/2 y 1/1/3 se regulara hacia mas o menos luz, pero tambien se
apagara con 1/1/4.
Esto es lo que se denomina funcion central: con la pulsacion del boton que enva la direc-
cion 1/1/4 realizaremos un apagado de todos los nodos existentes, ya que todos los actuadores
responden ante ese evento, realizando la misma accion.
Teniendo en cuenta esta diferenciacion entre nodos sensores y actuadores, veamos como
se ha realizado la programacion de ambas partes. Examinaremos las partes mas importantes
del codigo que nos ayuden a comprender el proceso que tiene lugar en cada uno de los nodos,
pudiendo comprobar el codigo completo en el apendice.
Para todas las aplicaciones que vamos a ver, tendremos que el archivo principal de con-
figuracion es eib.nc y el modulo eibM.nc. Ademas, como ya dijimos, para una aplicacion
poda incluirse un tipo de archivo que especificara el tipo de mensajes, como es lo que ocurre
en nuestro caso de forma comun a todas las aplicaciones.
El archivo en cuestion es EIBMsg.h y es comun a todos los programas que hemos realizado,
con pequenas variaciones, como ampliar la longitud de los datos utiles en el caso de regulacion
absoluta.
Incluye los campos de los mensajes que se envan entre los nodos. Tambien, para mayor
comodidad hemos incluido una enumeracion de distintas direcciones de grupo posibles y de
los valores que pueden tomar los DPT en el campo de datos.
control Configuramos este byte de control para que indique que es un telegrama con prior-
idad baja para todos los mensajes. Se podra configurar para otras prioridades, repeti-
ciones o incluso para mensajes de control. En comun para todos, el codigo sera 0xBC
en hexadecimal.
seqno Numero de secuencia del mensaje. Es importante indicar el numero de secuencia para
la sincronizacion de mensajes entre emisores y receptores. Este campo no estaba descrito
para EIB pero lo hemos considerado necesario en este tipo de redes.
dfisica Direccion fsica que se le quiera dar al dispositivo, como si fuera la direccion origen.
hop count Contador de saltos del mensaje. Es como el contador de ruta en EIB, aqu sirve
para saber por cuantos nodos ha pasado un mensaje hasta llegar a su destino y puede
ser util para dar informacion de la red o realizar otras configuraciones.
length Longitud del mensaje. En nuestros tipos de mensaje tendra valor 1 excepto en los de
regulacion absoluta que sera de 2.
datos Conjunto de datos utiles. Llevara incluido el comando y los datos. En caso de regu-
lacion absoluta tambien incluiremos el valor definido.
seguridad Byte de seguridad o comprobacion como vimos que haba en el sistema EIB.
Permitira comprobar el correcto envo de tramas para metodos de comprobacion de
bits.
eib.nc
Los componentes que se utilizan en este codigo los podemos apreciar en la lnea 2 y son:
Main, eibM, GenericComm, LedsIntensityC y TimerC.
En las dos primeras lneas vemos como la interfaz StdControl, que ya vimos que realiza
las funciones de inicializacion, es implemetada en eibM y por el componente LedsIntensityC.
En las lneas 7-9 se establece el vnculo con el componente GenericComm, que sera quien
implemente las comunicaciones, tanto los metodos de envo de mensajes (SendMsg) como la
recepcion (ReceiveMsg).
Por ultimo, se asignan los componentes que van a implementar el comportamiento de los
leds, as como el que va a establecer el reloj, que en este caso son LedsIntensityC y TimerC.
En particular, LedsIntensityC proporcina la interfaz LedsIntensity que permitira regular
los leds con distintos valores de intensidad en un rango de 0 a 255. Gracias a esta interfaz,
aplicaremos la regulacion relativa y absoluta a los leds.
El diagrama de este componente que nos proporciona la herramienta nesdoc es el siguiente.
En un anexo adjuntamos el diagrama completo de la aplicacion.
Por otro lado, analizaremos la sentencia siguiente con un poco mas de detalle:
eibM.TimerMilli ->TimerC.TimerMilli[unique("TimerMilli")];
Con esta sentencia podemos explicar lo que son las interfaces parametrizadas. Una
interfaz parametrizada permite a un componente proporcionar multiples instancias de una
interfaz, que son parametrizadas por un valor en tiempo de ejecucion o de compilacion.
Recordemos que es posible para un componente proveer multiples instancias de una misma
interfaz y darles nombres distintos, como por ejemplo:
provides{
interface StdControl as fooControl;
interface StdControl as barControl;}
Para nuestras aplicaciones hemos elegido TimerMilli porque ofrece mas posibilidades que
la interfaz Timer original. Si observamos el codigo de la interfaz:
1 interface TimerMilli
2 {
3 command result_t setPeriodic ( int32_t millis ) ;
4 command result_t setOneShot ( int32_t millis ) ;
5
6 command result_t stop () ;
7
8 command bool isSet () ;
9 command bool isPeriodic () ;
10 command bool isOneShot () ;
11 command int32_t getPeriod () ;
12
13 event result_t fired () ;
14 }
Codigo 2.8: Interfaz TimerMilli.nc
Como se puede observar, ademas de los metodos para establecer un timer de un solo
disparo o periodico, el metodo stop() y el evento fired(), disponemos de nuevas funciones.
Estos nuevos metodos (lneas 8-11) nos permiten saber:
isSet() si el Timer esta activado.
isPeriodic() si el Timer es periodico.
isOneShot() si el Timer es de un solo disparo.
getPeriod() el perodo que tiene configurado el Timer.
Estos metodos nos han sido de ayuda a la hora de realizar comprobaciones en las aplica-
ciones, para saber si estaba activado el timer en un determinado momento, por ejemplo.
eibM.nc
1. Transmision de mensajes.
2. Procesado de mensajes.
3. Recepcion de mensajes.
Puesto que estamos analizando un nodo sensor, este estara dedicado a las labores de
transmision de mensajes cuando se produzca un evento de boton en el. En cambio, la parte
de procesado y recepcion de mensajes es labor fundamental de los nodos actuadores.
Sin embargo, debemos tener en cuenta que estamos tratando con redes inalambricas de
sensores, distribuidos geograficamente en sitios distintos. Esto quiere decir que quiza un nodo
sensor este situado de tal forma que deba encaminar un mensaje.
Si, ademas, tenemos en cuenta que, tal y como describe el sistema EIB, un mensaje es
enviado de forma broadcast, todos los nodos recibiran el mensaje pero solo actuaran los que
deben hacerlo, de acuerdo con la poltica de direcciones de grupo.
Transmision de mensajes
Las variables mas importantes son: tpulsado, que lleva la cuenta del tiempo que esta pul-
sado el boton; tfrontera, que es el tiempo frontera establecido para diferenciar una pulsacion
corta de una pulsacion larga; enviadaLarga, un booleano que indica si se ha enviado o no
un mensaje de pulsacion larga.
Las tres opciones que pueden ocurrir son:
EnviarLarga: Cuando el boton sea pulsado y supere la frontera, querra decir que es una
pulsacion larga y, por tanto, se invocara a la tarea enviarPulsacionLarga.
EnviarCorta: Si, por el contrario, el boton ha sido pulsado pero deja de estar pulsado
antes de pasar el tiempo frontera, determinaremos una pulsacion corta y se invocara a
la tarea enviarPulsacionCorta.
EnviarStop: Por ultimo, este sera el caso en que se libere el boton y, previamente, se
haba enviado una pulsacion larga, por lo que habra que detener el proceso.
ESCRIBIR ON = 0x0081
ESCRIBIR OFF = 0x0080
ESCRIBIR TOGGLE = 0X0082
REGULAR LUZ = 0x0089
REGULAR OSCURIDAD = 0X0081
REGULAR STOP = 0X0088
A modo de ejemplo, veamos el codigo del envo de mensaje para pulsacion corta:
1 task void e n v i a r P u l s a c i o n C orta () {
2 EIBMsg * message = ( EIBMsg *) data . data ;
3 if (! pending1 )
4 {
5 pending1 = TRUE ;
6 lastSeqno = lastSeqno + 1;
7 message - > seqno = lastSeqno ;
8
9 message - > datos = ESCRIBIR_TOGGLE ;
10
11 atomic {
12 message - > control = 0 xBC ;
13 message - > dfisica = DIRE_FISICA_1_1_2 ;
14 message - > dgrupo = DIRE_GRUPO_1_1_1 ;
15 message - > hop_count = 0 x00 ;
16 message - > length = 0 x01 ;
17 message - > seguridad = 255;
18 }
19 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) ,
& data ) ;
20 pending1 = FALSE ;
21 } }
Codigo 2.10: Tarea de envo para pulsacion corta
De esta forma se crea un mensaje de tipo EIBMsg:
EIBMsg *message = (EIBMsg *)data.data;
Mediante alguna de las herramientas que vimos antes, podemos visualizar en pantalla la
recepcion de un mensaje obteniendo:
0E 01 08 03 FF FF FF FF 04 7D | BC 02 ... 00
A destacar los campos de direccion (address) que establecimos como broadcast (0xFFFF)
y el tipo de mensaje (type) que toma el valor de AM EIBMSG.
En el resto del codigo de la pulsacion corta debemos destacar algunas sentencias como
la actualizacion del numero de secuencia del mensaje (lneas 6-7), o que en el campo de
datos se asigna para que se realice la funcion TOGGLE, (lnea 9) que hara encender la luz si
esta apagada y apagarla si esta encendida, aunque esto corre a cargo del actuador.
Aqu hemos presentado las principales sentencias del codigo, aunque si revisamos el codigo
completo veremos que para asignar el valor del campo de datos hemos establecido un switch
para elegir la funcion del boton, tanto para pulsacion corta, larga, como el valor de regulacion
absoluta, como veremos un poco mas adelante.
Para finalizar, tambien se ve definida la direccion de grupo claramente (lnea 14) y como
se enva finalmente el mensaje (lnea 19) mediante la llamada:
uint16 t address Direccion de destino. En nuestro caso, con TOS BCAST ADDR = 0xFFFF,
hacemos un envo broadcast.
uint8 t length La longitud del buffer de datos que enviamos. La obtenemos en nuestro caso
con la funcion sizeOf().
Para la regulacion, con pulsaciones largas, lo unico que cambiaremos sera la direccion de
grupo, puesto que se trata de otro objeto de comunicacion y el valor de los datos podra ser,
por ejemplo, para disminuir la luminosidad, tal y como se ha definido en EIBMsg.h:
Mientras que para detener la regulacion podemos utilizar la misma direccion de grupo
pero el campo de datos sera:
message->valor = VALOR 20 %;
Con el objetivo de que la programacion de los motes sea mas sencilla, hemos establecido
unas variables para configurar la funcion que tendra cada boton del dispositivo. Dependiendo
del valor que se les de, el boton encendera, apagara, regulara hacia mas luz u oscuridad, o lo
que deseemos para sus pulsaciones corta y larga.
Las variables pueden modificarse en el metodo Init() y sus configuraciones posibles son:
int8 t funcionCorta: Determina la funcion para una pulsacion corta. Puede tomar 4
valores (1-4) consistentes en:
1. Funcion On.
2. Funcion Off.
3. Funcion Toggle, alternar.
4. Funcion de regulacion absoluta, con un valor que estableceremos con la variable
valorAbs.
int8 t funcionLarga: Determina la funcion para una pulsacion larga de boton. Puede
tomar 2 valores (1-2) que son:
Esto, en lneas de codigo, se traduce de la siguiente forma al crear el mensaje y darle valores
a sus campos, por ejemplo, para el caso de pulsacion larga y elegir el tipo de regulacion:
1 switch ( funcionCorta ) {
2 case 1:
3 message - > datos = ESCRIBIR_ON ; break ;
4 case 2:
5 message - > datos = ESCRIBIR_OFF ; break ;
6 case 3:
7 message - > datos = ESCRIBIR_TOGGLE ; break ;
8 case 4:
9 message - > length = 0 x02 ;
10 message - > datos = REGULACION_ABSOLUTA ; break ;
11 }
Codigo 2.11: Ejemplo de configuracion de funciones de boton
Aunque ya hemos comentado que esta parte es la que realizan los nodos actuadores,
estableceremos aqu los metodos generales mas importantes para la configuracion de un nodo
sensor como retransmisor de mensajes.
Los principales metodos y eventos son:
bool pending1 Indica si hay algun mensaje pendiente tras el evento de boton.
Datos utiles. Dependiendo de la funcion que establezcan los datos, como pueden
ser ESCRIBIR TOGGLE o REGULAR LUZ, se ejecutaran los comandos pertinentes. Cuando
sean funciones de conmutacion la ejecucion sera mas simple, en cambio, para funciones
de regulacion relativa entrara en juego el timer.
Longitud. Para el caso de regulacion absoluta, variaremos este campo del mensaje
puesto que es diferente de la regulacion relativa. Si se trata de una absoluta se tratara de
transmitir ese valor determinado a las luces.
Se esta creando una estructura de tipo EIBMsg llamada message en la que extraemos los
datos (data) del mensaje completo m. De ah iremos analizando las partes que nos interesen:
longitud, direccion de grupo, etc.
De la misma forma, una vez que termina una pulsacion larga se enviara un mensaje de
tipo REGULAR STOP que hara que pare la regulacion del tipo que sea. Dentro de esta opcion,
se baraja la posibilidad de que se de una pulsacion corta tras una regulacion de luz, y lo que
hacemos es establecer, por convenio, que siempre se apaguen. Esto puede ser definido por el
gusto del usuario, puede decidir que siempre se apaguen o se enciendan o que un boton de
regulacion hacia mas luz siempre encienda o al contrario.
Veamos el resto de codigo del interprete as como el Timer, que ira realizando la regulacion
de cada tipo.
1 case DIRE_GRUPO_1_1_3 :
2 if ( message - > length == 0 x01 ) {
3
4 if ( message - > datos == REGULAR_LUZ ) {
5 regular_luz = TRUE ;
6 }
7
8 if ( message - > datos == REGULAR_OSCURIDAD ) {
9 regular_sombra = TRUE ;
10 }
11
12 if ( message - > datos == REGULAR_STOP ) {
13 regular_luz = FALSE ;
14 regular_sombra = FALSE ;
15
16 if (! estadozero ) {
17 valorLuz = TRUE ;
18 }
19 else {
20 valorLuz = FALSE ;
21 estadozero = FALSE ;
22 }
23 }}
Codigo 2.14: Interprete de mensajes (2)
Lo que s que hay que tener en cuenta es marcar claramente cuando una luz esta encendida
o apagada totalmente (estadozero) para que no haya incongruencias al recibir peticiones de
pulsacion corta. Es decir, si se regula hacia oscuridad dejando apagada la luz y despues se
ejecuta una pulsacion corta pero no se enciende porque a la funcion TOGGLE le tocaba apagar
la luz, mostrara aparentemente que el sistema no funciona bien.
En el sistema domotico EIB hay varias formas de controlar estos casos, una de ellas se re-
aliza mediante el envo de mensajes con unos objetos de comunicacion auxiliares que indican
el estado de una luz cada vez que se produce un cambio en ella. De esta forma los pulsadores
que la controlan saben en que estado se encuentra y no se produciran fallos de este tipo.
Por otro lado, cuando una luz esta a medio regular y recibe una pulsacion corta, se suele
definir a gusto del usuario lo que se desea que ocurra. En este caso decidimos que se apaguen
las luces y se consigue simplemente indicando, cuando se produce el stop de la regulacion,
que las luces estan encendidas; de esta forma lo que hara una pulsacion corta sera apagarlas.
Aunque ya decimos que esto se puede configurar segun preferencias, un boton que regula
hacia mas luz puede configurarse para que siempre encienda totalmente las luces con una
pulsacion corta, y al contrario con un boton de regulacion hacia mas oscuridad.
Subir/Bajar (1.008)
Cuando se escribe este objeto de comunicacion se pone en marcha un motor en reposo
o se cambia de direccion si ya estaba en movimiento, tras un breve tiempo de espera.
Consta de 1 bit y se corresponde con la accion de subir o bajar totalmente una persiana
o toldo: si es 0 indicara Subiendo/Recogiendo y si es 1 sera Bajando/Extendiendo.
Paso (1.007)
Tambien consta de un solo bit y permitira, mediante una pulsacion corta, parar un
motor que estaba en marcha o bien poner en marcha durante breves instantes un motor
que estaba detenido. Esto produce un paso de subida/bajada en una persiana conven-
cional o un giro breve en una persiana de lamas. El bit indicara un Stop/Paso abajo si
es 1 y un Stop/Paso arriba si es 0.
En este caso los nodos pulsadores tambien deberan distinguir entre pulsacion corta y
larga, asociandose a un tipo de objeto de comunicacion o a otro: la pulsacion corta a un
movimiento de paso y la pulsacion larga a un movimiento de subida o bajada.
Para nuestras aplicaciones realizaremos los algoritmos que activan un posible motor de
persiana o toldo, pero realizaremos las pruebas encendiendo o apagando una luz de nuestros
motes. Por ejemplo, que un led este encendido indicara que esta subiendo y si esta apagado
es que esta parado.
Pero incluso esta parte estara controlada casi en su totalidad por los nodos actuadores,
porque en los pulsadores estableceremos una direccion de grupo para un objeto de comuni-
cacion y otra direccion distinta para el otro objeto, sin mas complicacion.
El campo de datos podra tomar uno de los dos valores siguientes:
Ademas, el actuador debera tener prefijados unos tiempos especficos para el buen fun-
cionamiento. Por ello, creamos las variables:
ttotal Tiempo establecido para hacer una subida/bajada total, que de tiempo a toda la
carrera de la persiana.
twait Tiempo de espera que hay que respetar cuando hay colision subida/bajada, es de-
cir, cuando, estando en movimiento, se hace una peticion de movimiento en sentido
contrario.
En este ejemplo podemos ver como un telos nodo sensor esta provisto de dos botones
configurados uno de subida y el otro de bajada para las direcciones de grupo 1/1/4 y 1/1/5
para un paso o movimiento total, respectivamente.
El actuador efectuara la subida o bajada (representada por la luz verde o roja) en fun-
cion de lo que reciba. Por ejemplo, si se hace una pulsacion corta con el boton de subida se
enviara la direccion 1/1/4 y el actuador recibira ese mensaje, evaluara los datos que llevaran
la accion ESCRIBIR ON y, por tanto, encendera la luz verde de subida durante el tiempo de
un paso. Si, por el contrario, se hace una pulsacion larga de bajada, se enviara la 1/1/5 pero
con el comando ESCRIBIR OFF, lo que encendera el led rojo durante el tiempo ttotal, a no ser
que sea interrumpido con una pulsacion corta de cualquiera de los botones, que se traduce
como un stop del movimiento.
El codigo sera:
1 case DIRE_GRUPO_1_1_4 :
2
3 if ( message - > datos == ESCRIBIR_ON ) {
4
5 if ( total_subir || total_bajar ) {
6 total_subir = FALSE ;
7 total_bajar = FALSE ;
8 call LedsIntensity . set ( 0 x00 , 0 ) ;
9 call LedsIntensity . set ( 0 x02 , 0 ) ;
10 }
11 else {
12 paso_subir = TRUE ;
13 paso_bajar = FALSE ;
14 tcounter = 0;
15 }}
Codigo 2.16: Paso de subida en persianas
En este algoritmo, cuando se hace una peticion de paso de subida, por ejemplo con la
direccion 1/1/4 del ejemplo anterior, primero se comprueba si ya estaba en movimiento de
subida o bajada, por lo que la pulsacion corta pasa a ser un comando de stop.
Si no es as, saltara el timer y empezara a correr un contador de tiempo. El motor se
pondra en marcha hasta que se supere el tiempo establecido como el tiempo de paso. Una
vez se rebase ese tiempo, el motor se parara.
1 event result_t TimerMilli . fired ()
2 {
3 if ( paso_subir ) {
4
5 tcounter = tcounter + 100;
6 call LedsIntensity . set ( 0 x00 , 255 ) ; // motor ON
7
8 if ( tcounter > tpaso ) {
9 call LedsIntensity . set ( 0 x00 , 0 ) ;; // motor OFF
10 paso_subir = FALSE ;
11 tcounter = 0;
12 }
Codigo 2.17: Timer - Paso de subida en persianas
El algoritmo es similar para un paso de bajada, con la salvedad de que el actuador acti-
vara el motor de bajada correspondiente (luz verde en nuestro caso).
1. Parar el movimiento.
Veamos el algoritmo. Una vez se ha parado el movimiento, comienza el contador que nos
dira cuando hemos superado ese tiempo de espera. Una vez superado, podremos poner el
motor en marcha hasta que se pase lo que hemos predefinido como tiempo total.
1. Con colision: en el que esperara el tiempo determinado twait y luego pondra el motor
en marcha hasta que pase el tiempo total.
2. Sin colision: simplemente pondra en marcha el motor hasta que el contador determine
que se ha superado el tiempo total.
Activaremos el sensor de radiacion solar, con el que ira tomando medidas de luz a cada
salto de reloj. Los metodos mas importantes de este componente Sense son:
Cuando se dispara el timer se toman los datos, procesados por el componente ADC
mediante el metodo:
call ADC.getData();
Una vez se han tomado los datos (ADC.dataReady) se invoca al metodo IntOutput.output
que pasara la informacion a nuestro codigo.
IntOutput.output((data7) &0x7);
Con esa sentencia, los datos son desplazados lo necesario para tomar los bits mas signi-
ficativos y que esten, ademas, en una escala de 0-7.
En el diagrama podemos apreciar la relacion entre SenseM y eib, mediante el metodo que
hemos comentado, IntOutput. Ademas, destacamos tambien la relacion con el componente
DemoSensor2C, que sera el que configure el sensor como luz, vinculandolo a los sensores de luz
Hamamatsu. Podemos ver parte de este codigo completo que encontraremos en los apendices
finales, a continuacion:
1 configuration DemoSensor2C
2 {
3 provides interface ADC ;
4 provides interface StdControl ;
5 }
6 implementation
7 {
8 components HamamatsuC as DemoSensor ;
9
10 StdControl = DemoSensor ;
11 ADC = DemoSensor ;
12 }
Codigo 2.21: Configuracion de DemoSensor2C
Un sensor crepuscular de este tipo puede configurarse para que cuando se sobrepasa cier-
to umbral de luz u oscuridad, se enve un mensaje a un actuador de conmutacion para que
encienda o apague luces. Ese es el funcionamiento mas sencillo.
Sin embargo, ya que podemos programar actuadores de regulacion que consiguen regu-
lacion absoluta, nos aprovechamos de esta utilidad para completar esta aplicacion, creando un
sensor crepuscular que enviara mensajes cuando se sobrepasen ciertos umbrales, produciendo
en el sistema de iluminacion un encendido o apagado gradual.
En una vivienda se traducira en una programacion de ciertas luces, por ejemplo del
jardn, que se iran encendiendo gradualmente conforme se hace de noche y, por el contrario,
se iran apagando gradualmente cuando se haga de da.
Para ello, el codigo va evaluando los niveles de luz que recibe y si se supera alguno y el
nivel de luminosidad no es el adecuado, se enviara un mensaje al actuador para que regule la
luz. Solo ocurrira en ese caso, as evitaremos un mayor consumo de potencia con el envo de
mensajes innecesarios.
En nuestro caso, dividimos los valores en diez tipos (0-7) y diez grados de iluminacion (0-
255 para nuestros leds) de tal forma que, cuando el valor recibido sea maximo, la intensidad
que enviaremos en el mensaje al actuador sea mnima.
Valor Intensidad
7 0
7 32
6 64
5 96
4 128
3 160
2 192
1 224
0 255
Como vemos en esta parte del codigo, si el valor medido no corresponde con la intensidad
que debe haber en las luces, se enviara un mensaje de regulacion absoluta. En este caso,
hemos destacado los campos mas importantes: el campo de datos donde indicamos que es un
mensaje de regulacion absoluta, el campo de longitud con la correspondiente a este DPT, y
el valor de intensidad que marcara la luminosidad de las luces.
En otros casos, por ejemplo un termostato, configuraremos el sensor de tal forma que
cuando se sobrepase un umbral se enve un mensaje determinado para encender la calefaccion,
el aire acondicionado o lo que queramos controlar.
En este ejemplo el mote del balcon o el de la buhardilla podran tener configuradas fun-
ciones de sensor crepuscular y pulsadores de persianas, el mote de la puerta principal podra
llevar funciones centrales de apagado de luces y bajada de persianas de toda la casa cuan-
do nos marchamos, y el mote central podra ser un nodo retransmisor precisamente para ese
tipo de funciones, por si el alcance del mote de la planta baja no llega a las plantas superiores.
Si nos fijamos en la tabla anterior y en el grafico podemos ver que el sensor S1 controlara los
actuadores de luces de los dos pisos (AL1 y AL2), encendiendolas cuando no haya luz solar.
Por otro lado, en la puerta tenemos tres pulsadores. Dos de ellos (P2 y P3) controlan
de forma alternada las luces de los dos pisos, respectivamente, mientras que el pulsador P1
realiza una funcion central de apagar todas las luces y bajar las persianas del actuador AP1,
mediante la direccion de grupo 1/1/2.
La persiana del piso de arriba es controlada tambien mediante los pulsadores P4 y P5,
que estan vinculados al actuador AP1.
Y, por ultimo, las luces de abajo tienen dos pulsadores de regulacion, que son P6 y P7.
Lo importante de esta parte es que para habilitar las entradas GIO0 y GIO1 es nece-
sario puentear las resistencias R14 y R16 que, por defecto, estan en circuito abierto. De
esta forma ya podremos generar interrupciones externas conectadas a estos pines. Si no, las
entradas activadas seran ADC2 y ADC3. Con GIO2 y GIO3 no encontramos este problema.
Por otra parte, para anadir botones o leds a nuestro mote, realizamos el montaje de unas
placas que dispusieran de cuatro pulsadores o leds, siguiendo el mismo esquematico de los
botones existentes en el mote o el de los propios leds:
Lo primero que hay que hacer es realizar la asignacion de pines. Si se observa el fichero
detenidamente se puede comprobar como los pines ya estan asignados y asociados a sus nom-
bres GIO con las sentencias. As los mantendremos para la programacion de botones:
//GIO pins
TOSH ASSIGN PIN(GIO0, 2, 0);
TOSH ASSIGN PIN(GIO1, 2, 1);
TOSH ASSIGN PIN(GIO2, 2, 3);
TOSH ASSIGN PIN(GIO3, 2, 6);
De todas formas, podemos cambiar dichas asignaciones e introducir los nombres que nos
parezcan apropiados.
Una vez hechas las asignaciones, debemos configurar la direccion de los pines. Podemos
hacerlo de dos formas, cambiando las direcciones de los pines en este mismo fichero, o en
nuetra propia aplicacion.
En nuestra aplicacion definiremos las direcciones de los pines mediante unas macros que
nos permiten hacerlo:
De esta forma podremos establecer si son de entrada o de salida en nuestro codigo, pero
debemos llevar cuidado de que no haya algunos puertos definidos como entrada y salida, o
que puedan influir.
Donde se configuran los pines como entradas. El problema que surge ahora es el hecho de
que algunos pines GIO comparten entrada con algunas senales ADC (vease el apendice con el
esquematico de hardware del telos). Por tanto, no puede declararse una senal como entrada
y la otra senal compartida como salida. Para que no haya incompatibilidades, declararemos
tambien como entradas los puertos ADC que comparten senal con los pines de nuestro interes.
De esta forma no habra problemas, por tanto, anadiremos en nuestro codigo:
2. Aprovechar las funciones ya creadas y cambiar los pines asignados en el fichero hardware.h.
Hemos programado nuestros motes siguiendo esta ultima opcion, aprovechando el codigo
ya existente, pero realizando la asignacion:
//GIO-Leds pins
TOSH ASSIGN PIN(RED LED, 2, 0);
TOSH ASSIGN PIN(GREEN LED, 2, 1);
TOSH ASSIGN PIN(YELLOW LED, 2, 3);
Por defecto, en hardware.h los pines correspondientes estan configurados como salidas,
por lo que no habra que asignarles direcciones en nuestro codigo, pero s a los ADC que in-
terfieren. De nuevo, habra que configurarlos como entradas, para que no se solape una salida
con nuestras salidas:
Si queremos configurar la cuarta entrada para un led mas, entonces deberemos crear una
nueva asignacion en hardware.h:
Y, por supuesto, tendremos que configurar las funciones del codigo LedsC para que se
encienda y apague el nuevo led.
Existe otro metodo de asignar las direcciones de pines, modificando el fichero hardware.h.
En el, encontraremos el metodo void TOSH SET PIN DIRECTIONS que mediante unas sen-
tencias en las que asigna un numero hexadecimal, se establecen como entrada o como salida
los pines.
El parametro PxDIR es el que realiza esta funcion, abarcando todos los puertos desde el
x0 al x7 y estableciendo una entrada cuando el bit es 0 y una salida cuando el bit es 1.
Por ejemplo, si P2DIR=0x7b, estaremos hablando de los puertos 20-27 y la configuracion
sera:
P2DIR 27 26 25 24 23 22 21 20
0X7b 0 1 1 1 1 0 1 1
Finalmente, en nuestros codigos podremos conocer el estado de cada uno de estas senales,
mediante los metodos o macros que se proporcionan, como por ejemplo:
Habiendo predefinido asignado previamente las senales a los nombres como BOTON DOS,
podremos controlar y leer esas senales.
El resultado final, tras el montaje, soldaduras y acoplo de los motes a las placas puede
verse en estas fotografas.
Las tecnologas existentes son muy heterogeneas, presentando soluciones cableadas, por
corrientes portadoras o inalambricas, aunque no muy desarrolladas. El principal problema de
las soluciones cableadas es la necesidad de prevision de su instalacion en la fase de proyec-
to y construccion del edificio, lo que limita su ambito de aplicacion a viviendas de nueva
construccion.
Para la implantacion en viviendas ya construidas, el sistema mas extendido es el de corrien-
tes portadoras pero tambien presenta grandes inconvenientes de fiabilidad o funcionamiento.
En cambio, las redes inalambricas de sensores estan creciendo a un ritmo muy alto en
cuanto a desarrollo, prestaciones y aplicaciones. Se espera que gracias a las WSAN se produz-
ca una revolucion en el mundo de la domotica, permitiendo la introduccion de la domotica
avanzada en viviendas ya construidas, ampliando instalaciones existentes o proporcionando
grandes avances en las prestaciones de confort, seguridad, ahorro energetico, interoperativi-
dad con otras redes, etc.
Nodos moviles.
La determinacion de la posicion de nodos moviles, en los que se identificara el perfil del
usuario que lo transporta es uno de los requerimientos para la creacion de ambientes
inteligentes. La localizacion de ocupantes en una vivienda y su revision propone entornos
inteligentes con prediccion de rutas de los usuarios para incrementar su confort y realizar
usos eficientes de la energa. Otro campo de interes es la aplicacion para viviendas con
personas mayores, discapacitadas o con necesidades especiales.
Seguridad.
La seguridad es fundamental en estas aplicaciones por varios motivos. El primero es
la naturaleza inalambrica del medio, facilmente accesible a personas ajenas de la red.
El segundo radica en que se trata de una red de control de la que se puede extraer
informacion valiosa de los usuarios de una vivienda. Ademas, entre sus funciones se
incluyen la de gestion de la seguridad, lo que puede comprometer aun mas la integridad
en caso de ataques externos y manipulacion de nodos.
La creacion de estos entornos inteligentes se dara gracias a la expansion de las redes in-
alambricas de sensores, con nodos moviles cuya posicion estara determinada y gracias a la
computacion ubicua, creando de un hogar un centro neuralgico de computacion y comuni-
cacion, pero a la vez perfectamente integrado con los usuarios humanos.
El Ambiente Inteligente no se limitara a ningun lugar fsico determinado sino que com-
prendera todos ellos: la casa, el coche, el lugar de trabajo, etc. El Ambiente estara donde
nosotros estemos y respondera a nuestras necesidades de una forma natural. Pero, dado que
el hogar es el lugar donde mayor numero de actividades diferentes se realizan (ocio, trabajo,
relaciones sociales, etc.) se constituira como el Ambiente Inteligente por excelencia.
Con este proyecto hemos realizado un estudio de dos sectores tecnologicos que aun estan
en sus comienzos, poniendo nuestro granito de arena en una de las salidas con mas perspec-
tivas de futuro para la domotica, como son las redes inalambricas de sensores.
Como conclusiones importantes podemos destacar todas las actividades de desarrollo que
aun se necesitan hacer para conseguir que estas tecnologas emergentes se vayan asentando.
Por una parte, la integracion de tecnologas inalambricas en los estandares domoticos, es-
tableciendo nuevos frentes de actuacion. Por otro lado, avanzar tecnologicamente e ir encon-
trando nuevas soluciones para las redes de sensores inalambricas, desarrollando aplicaciones
con mas prestaciones, nuevos sensores exclusivos para domotica, ampliacion de topologas
para redes moviles, etc.
Muchas aplicaciones para redes de sensores se estan realizando en diversos campos, y
el de la domotica es uno que esta pendiente por desarrollar. Estudios como este proyecto
con la programacion de sensores de acuerdo a un estandar domotico, la creacion de nuevas
aplicaciones para viviendas o la programacion de aplicaciones con interfaces graficas que
permitan la configuracion de sensores de una red WSAN son distintos frentes en los que
habra que ir trabajando para conseguir que estas nuevas tecnologas sean una realidad.
eibM.nc
1 includes EIBMsg ;
2
3 module eibM {
4
5 provides {
6 interface StdControl ;
7 interface ProcessCmd ;
8 }
9
10 uses {
11 interface ReceiveMsg as ReceiveEIBMsg ;
12 interface StdControl as CommControl ;
13 interface SendMsg as Send ;
14 interface TimerMilli ;
15 interface LedsIntensity ;
16 }
17 }
18 implementation {
19 TOS_MsgPtr m ;
20 int8_t bcast_pending ;
21 TOS_Msg buf ;
22 int8_t pending2 ;
23 int8_t lastSeqno ;
24 bool pending1 ;
25 TOS_Msg data ;
26 bool retransmite ;
27
28 int16_t valorBoton ;
29 int16_t tpulsado ;
30 int16_t tfrontera ;
31 bool enviadaLarga ;
32 int8_t funcionCorta ;
33 int8_t funcionLarga ;
34 int8_t valorAbs ;
35
36 /********************************************/
37
38
39 task void cmdInterpret () {
40 signal ProcessCmd . done (m , SUCCESS ) ;
41 }
42
43
44 task void forwarder () {
45
46 struct EIBMsg * message = ( struct EIBMsg *) m - > data ;
47 message - > seqno = lastSeqno ;
48 message - > dfisica = 0 xBB ;
49 if ( retransmite ) {
50 call Send . send ( TOS_BCAST_ADDR , 8 , m ) ;
51 }
52 else {
53 pending1 = FALSE ;
54 bcast_pending = 0;
55 }
56 }
57
58 task void e n v i a r P u l s a c i o n C orta () {
59
60 EIBMsg * message = ( EIBMsg *) data . data ;
61 if (! pending1 )
62 {
63 pending1 = TRUE ;
64 lastSeqno = lastSeqno + 1;
65 message - > length = 0 x01 ;
66
67 switch ( funcionCorta ) {
68 case 1:
69 message - > datos = ESCRIBIR_ON ; break ;
70 case 2:
71 message - > datos = ESCRIBIR_OFF ; break ;
72 case 3:
73 message - > datos = ESCRIBIR_TOGGLE ;
break ;
74 case 4:
75 message - > length = 0 x02 ;
76 message - > datos = REGULACION_ABSOLUTA ;
break ;
77 }
78
79 switch ( valorAbs ) {
80 case 1:
81 message - > valor = VALOR_10 ; break ;
82 case 2:
83 message - > valor = VALOR_20 ; break ;
84 case 3:
85 message - > valor = VALOR_30 ; break ;
86 case 4:
87 message - > valor = VALOR_40 ; break ;
88 case 5:
89 message - > valor = VALOR_50 ; break ;
90 case 6:
91 message - > valor = VALOR_60 ; break ;
92 case 7:
93 message - > valor = VALOR_70 ; break ;
94 case 8:
95 message - > valor = VALOR_80 ; break ;
96 case 9:
97 message - > valor = VALOR_90 ; break ;
98 }
99 message - > seqno = lastSeqno ;
100 atomic {
101 message - > control = 0 xBC ;
102 message - > dfisica = DIRE_FISICA_1_1_1 ;
103 message - > dgrupo = DIRE_GRUPO_1_1_1 ;
104 message - > hop_count = 0 x00 ;
105 message - > seguridad = 255;
106 }
107 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) ,
& data ) ;
108 pending1 = FALSE ;
109 }
110 }
111
112 task void e n v i a r P u l s a c i o n Larga () {
113
114 EIBMsg * message = ( EIBMsg *) data . data ;
115 if (! pending1 )
116 {
117 pending1 = TRUE ;
118 lastSeqno = lastSeqno + 1;
119
120 switch ( funcionLarga ) {
121 case 1:
122 message - > datos = REGULAR_LUZ ; break ;
123 case 2:
124 message - > datos = REGULAR_OSCURIDAD ; break ;
125 }
126 message - > seqno = lastSeqno ;
127 atomic {
128 message - > control = 0 xBC ;
129 message - > dfisica = DIRE_FISICA_1_1_1 ;
130 message - > dgrupo = DIRE_GRUPO_1_1_3 ;
131 message - > hop_count = 0 x00 ;
132 message - > length = 0 x01 ;
133 message - > seguridad = 255;
134 }
135 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ;
136 pending1 = FALSE ;
137 }
138 }
139
140 task void enviarSTOPlarga () {
141
142 EIBMsg * message = ( EIBMsg *) data . data ;
143 if (! pending1 )
144 {
145 pending1 = TRUE ;
146 lastSeqno = lastSeqno + 1;
147 message - > datos = REGULAR_STOP ;
148
149 message - > seqno = lastSeqno ;
150 atomic {
151 message - > control = 0 xBC ;
152 message - > dfisica = DIRE_FISICA_1_1_1 ;
153 message - > dgrupo = DIRE_GRUPO_1_1_3 ;
154 message - > hop_count = 0 x00 ;
155 message - > length = 0 x01 ;
156 message - > seguridad = 255;
157 }
158 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ;
159 pending1 = FALSE ;
160 }
161 }
162
163 command result_t StdControl . init () {
164
165 m = & buf ;
166 bcast_pending = 0;
167 pending2 = 0;
168 lastSeqno = 0;
169 pending1 = FALSE ;
170 retransmite = FALSE ;
171
172 tpulsado = 0;
173 tfrontera = 1500;
174 enviadaLarga = FALSE ;
175
176
177 funcionCorta = 3;
178 funcionLarga = 1;
179 valorAbs = 5;
180 return call CommControl . init () ;
181 }
182
183 command result_t StdControl . start () {
184 call TimerMilli . setPeriodic ( 100 ) ;
185 return call CommControl . start () ;
186 }
187
188 command result_t StdControl . stop () {
189 call TimerMilli . stop () ;
190 return call CommControl . stop () ;
191 }
192
193 inline char is_new_msg ( struct EIBMsg * bmsg ) {
194
195 if ( bcast_pending ) return 0;
196 return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) <
lastSeqno ) ) ;
197 }
198 inline void remember_msg ( struct EIBMsg * bmsg ) {
199 lastSeqno = bmsg - > seqno ;
200 bcast_pending = 1;
201 }
202
203 event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) {
204
205 TOS_MsgPtr ret = m ;
206 result_t retval ;
207 struct EIBMsg * datos = ( struct EIBMsg *) m - > data ;
208 if ( is_new_msg ( datos ) ) {
209 remember_msg ( datos ) ;
210 retval = call ProcessCmd . execute ( pmsg ) ;
211 ret = m ;
212 m = pmsg ;
213 }
214 return ret ;
215 }
216
217 command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) {
218 pending2 =1;
219 m = pmsg ;
220 post cmdInterpret () ;
221 return SUCCESS ;
222 }
223
224 event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status )
225 {
226 if ( pending1 && msg == & data )
227 {
228 pending1 = FALSE ;
229 }
230 if ( status == SUCCESS ) bcast_pending = 0;
231 return SUCCESS ;
232 }
233
234 default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg ,
result_t status ) {
235 m = pmsg ;
236 if ( status ) {
237 post forwarder () ;
238 } else {
239 bcast_pending = 0;
240 }
241 return SUCCESS ;
242 }
243
244 event result_t TimerMilli . fired ()
245 {
246 valorBoton = T O S H_ READ_BOTON_PIN () ;
247
248 if ( valorBoton == 0 x0000 ) {
249 tpulsado = tpulsado + 100;
100 if ( retransmite ) {
101 call Send . send ( TOS_BCAST_ADDR , 8 , m ) ;
102 }
103 else {
104 pending1 = FALSE ;
105 bcast_pending = 0;
106 }
107 }
108
109 command result_t StdControl . init () {
110 m = & buf ;
111 bcast_pending = 0;
112 pending2 = 0;
113 lastSeqno = 0;
114 pending1 = FALSE ;
115 retransmite = FALSE ;
116
117 regular_luz = FALSE ;
118 regular_sombra = FALSE ;
119 intensidad = 0;
120 factor = 15;
121 valorLuz = FALSE ;
122 estadozero = FALSE ;
123 valorRecibido = 0;
124 return call CommControl . init () ;
125 }
126
127 command result_t StdControl . start () {
128 call TimerMilli . setPeriodic ( 100 ) ;
129 return call CommControl . start () ;
130 }
131
132 command result_t StdControl . stop () {
133 call TimerMilli . stop () ;
134 return call CommControl . stop () ;
135 }
136
137 inline char is_new_msg ( struct EIBMsg * bmsg ) {
138
139 if ( bcast_pending ) return 0;
140 return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) <
lastSeqno ) ) ;
141 }
142 inline void remember_msg ( struct EIBMsg * bmsg ) {
143 lastSeqno = bmsg - > seqno ;
144 bcast_pending = 1;
145 }
146
147 event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) {
148
149 TOS_MsgPtr ret = m ;
200 if ( regular_sombra ) {
201 if ( intensidad > 0) {
202 intensidad = intensidad - factor ;
203 call LedsIntensity . set ( 0 x00 , intensidad ) ;
204 }
205 else {
206 call LedsIntensity . set ( 0 x00 , 0 ) ;
207 estadozero = TRUE ;
208 }
209 }
210 return SUCCESS ;
211 }
212 }
Codigo A.3: Nodo actuador de iluminacion eibM.nc
1 includes EIBMsg ;
2
3 module eibM {
4
5 provides {
6 interface StdControl ;
7 interface ProcessCmd ;
8 }
9
10 uses {
11 interface ReceiveMsg as ReceiveEIBMsg ;
12 interface StdControl as CommControl ;
13 interface SendMsg as Send ;
14 interface TimerMilli ;
15 interface LedsIntensity ;
16 }
17 }
18 implementation {
19 TOS_MsgPtr m ;
20 int8_t bcast_pending ;
21 TOS_Msg buf ;
22 int8_t pending2 ;
23 int8_t lastSeqno ;
24 bool pending1 ;
25 TOS_Msg data ;
26 bool retransmite ;
27
28
29 int16_t valorBoton ;
30 int16_t tpulsado ;
31 int16_t tfrontera ;
32 bool enviadaLarga ;
33 int8_t funcionBoton ;
34
35
36 /*******************************/
37
38 task void cmdInterpret () {
39 signal ProcessCmd . done (m , SUCCESS ) ;
40 }
41
42 task void forwarder () {
43
44 struct EIBMsg * message = ( struct EIBMsg *) m - > data ;
45 message - > seqno = lastSeqno ;
46 message - > dfisica = 0 xBB ;
47 if ( retransmite ) {
48 call Send . send ( TOS_BCAST_ADDR , 8 , m ) ;
49 }
50 else {
51 pending1 = FALSE ;
52 bcast_pending = 0;
53 }
54 }
55
56 task void e n v i a r P u l s a c i o n C orta () {
57
58 EIBMsg * message = ( EIBMsg *) data . data ;
59 if (! pending1 )
60 {
61 pending1 = TRUE ;
62 lastSeqno = lastSeqno + 1;
63
64 switch ( funcionBoton ) {
65 case 1:
66 message - > datos = ESCRIBIR_ON ;
67 break ;
68 case 2:
69 message - > datos = ESCRIBIR_OFF ;
70 break ;
71 }
72 message - > seqno = lastSeqno ;
73 atomic {
74 message - > control = 0 xBC ;
75 message - > dfisica = DIRE_FISICA_1_1_1 ;
76 message - > dgrupo = DIRE_GRUPO_1_1_1 ;
77 message - > hop_count = 0 x00 ;
78 message - > seguridad = 255;
79 }
80 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) ,
& data ) ;
81 pending1 = FALSE ;
82 }
83 }
84
85
86 task void e n v i a r P u l s a c i o n Larga () {
87
88 EIBMsg * message = ( EIBMsg *) data . data ;
89 if (! pending1 )
90 {
91 pending1 = TRUE ;
92 lastSeqno = lastSeqno + 1;
93
94 switch ( funcionBoton ) {
95 case 1:
96 message - > datos = ESCRIBIR_ON ;
97 break ;
98 case 2:
99 message - > datos = ESCRIBIR_OFF ;
100 break ;
101 }
102 message - > seqno = lastSeqno ;
103 atomic {
104 message - > control = 0 xBC ;
105 message - > dfisica = DIRE_FISICA_1_1_1 ;
106 message - > dgrupo = DIRE_GRUPO_1_1_5 ;
107 message - > hop_count = 0 x00 ;
108 message - > length = 0 x01 ;
109 message - > seguridad = 255;
110 }
111 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ;
// Envo
112 pending1 = FALSE ;
113 }
114 }
115
116 command result_t StdControl . init () {
117
118 m = & buf ;
119 bcast_pending = 0;
120 pending2 = 0;
121 lastSeqno = 0;
122 pending1 = FALSE ;
123 retransmite = FALSE ;
124
125 tpulsado = 0;
126 tfrontera = 1500;
127 enviadaLarga = FALSE ;
128
129 funcionBoton = 2;
130
131 return call CommControl . init () ;
132 }
133
134
185
186 default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg ,
result_t status ) {
187 m = pmsg ;
188 if ( status ) {
189 post forwarder () ;
190 } else {
191 bcast_pending = 0;
192 }
193 return SUCCESS ;
194 }
195
196 event result_t TimerMilli . fired ()
197 {
198 valorBoton = T O S H_ READ_BOTON_PIN () ;
199
200 if ( valorBoton == 0 x0000 ) {
201 tpulsado = tpulsado + 100;
202 if (( tpulsado > tfrontera ) && ! enviadaLarga ) {
203 post enviarPulsacionLarga () ;
204 enviadaLarga = TRUE ;
205 } }
206 else {
207 if (( tpulsado < tfrontera ) && ( tpulsado != 0) ) {
208 post e n v i a rPulsacionCorta () ;
209 tpulsado = 0;
210 }
211 else {
212 if ( enviadaLarga ) {
213 post enviarSTOPlarga () ;
214 }
215 tpulsado = 0;
216 enviadaLarga = FALSE ;
217 }
218 }
219 return SUCCESS ;
220 }
221 }
Codigo B.1: Nodo pulsador de persianas eibM.nc
49 total_subir = FALSE ;
50 total_bajar = FALSE ;
51 call LedsIntensity . set ( 0 x00 , 0 ) ;
52 call LedsIntensity . set ( 0 x01 , 0 ) ;
53 }
54 else {
55 paso_subir = TRUE ;
56 paso_bajar = FALSE ;
57 tcounter = 0;
58 }
59 }
60
61 if ( message - > datos == ESCRIBIR_OFF ) {
62
63 if ( total_bajar || total_subir ) {
64 total_subir = FALSE ;
65 total_bajar = FALSE ;
66 call LedsIntensity . set ( 0 x00 , 0 ) ;
67 call LedsIntensity . set ( 0 x01 , 0 ) ;
68 }
69 else {
70 paso_subir = FALSE ;
71 paso_bajar = TRUE ;
72 tcounter = 0;
73 }
74 }
75 break ;
76
77 case DIRE_GRUPO_1_1_5 :
78 if ( message - > datos == ESCRIBIR_ON ) {
79 total_subir = TRUE ;
80 if ( total_bajar ) { wait = TRUE ;}
81 total_bajar = FALSE ;
82 tcounter = 0;
83 call LedsIntensity . set ( 0 x01 , 0 ) ;
84 }
85
86 if ( message - > datos == ESCRIBIR_OFF ) {
87 total_bajar = TRUE ;
88 if ( total_subir ) { wait = TRUE ;}
89 total_subir = FALSE ;
90 tcounter = 0;
91 call LedsIntensity . set ( 0 x00 , 0 ) ;
92 }
93 break ;
94 }
95 pending2 =0;
96 signal ProcessCmd . done (m , SUCCESS ) ;
97 }
98
99 task void forwarder () {
100
101 struct EIBMsg * message = ( struct EIBMsg *) m - > data ;
102 message - > seqno = lastSeqno ;
103 message - > dfisica = 0 xBB ;
104 if ( retransmite ) {
105 call Send . send ( TOS_BCAST_ADDR , 8 , m ) ;
106 }
107 else {
108 pending1 = FALSE ;
109 bcast_pending = 0;
110 }
111 }
112
113 command result_t StdControl . init () {
114 m = & buf ;
115 bcast_pending = 0;
116 pending2 = 0;
117 lastSeqno = 0;
118 pending1 = FALSE ;
119 retransmite = FALSE ;
120
121 paso_subir = FALSE ;
122 paso_bajar = FALSE ;
123 total_subir = FALSE ;
124 total_bajar = FALSE ;
125
126 tcounter =0;
127 tpaso = 1000;
128 ttotal = 5000;
129 twait = 1000;
130 wait = FALSE ;
131 return call CommControl . init () ;
132 }
133
134 command result_t StdControl . start () {
135 call TimerMilli . setPeriodic ( 100 ) ;
136 return call CommControl . start () ;
137 }
138
139 command result_t StdControl . stop () {
140 call TimerMilli . stop () ;
141 return call CommControl . stop () ;
142 }
143
144 inline char is_new_msg ( struct EIBMsg * bmsg ) {
145
146 if ( bcast_pending ) return 0;
147 return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) <
lastSeqno ) ) ;
148 }
149 inline void remember_msg ( struct EIBMsg * bmsg ) {
Sense.nc
1 configuration Sense {
2 }
3 implementation
4 {
5 components Main , SenseM , LedsC , TimerC , DemoSensor2C as
Sensor , eib ;
6
7 Main . StdControl -> Sensor ;
8 Main . StdControl -> TimerC ;
9 Main . StdControl -> SenseM ;
10 Main . StdControl -> eib ;
11
12 SenseM . ADC -> Sensor ;
13 SenseM . ADCControl -> Sensor ;
14 SenseM . Leds -> LedsC ;
15 SenseM . Timer -> TimerC . Timer [ unique (" Timer ") ];
16
17 SenseM . IntOutput -> eib . IntOutput ;
18 }
Codigo C.1: Sense.nc
eib.nc
1 includes EIBMsg ;
2 configuration eib {
3 provides interface StdControl ;
4 provides interface ProcessCmd ;
5 provides interface IntOutput ;
6 }
7 implementation
8 {
9 components eibM , GenericComm , LedsC ;
10
11 IntOutput = eibM ;
12 StdControl = eibM ;
13 ProcessCmd = eibM . ProcessCmd ;
14 eibM . ReceiveEIBMsg -> GenericComm . ReceiveMsg [ AM_EIBMSG ];
15 eibM . CommControl -> GenericComm ;
16 eibM . Leds -> LedsC . Leds ;
17 eibM . Send -> GenericComm . SendMsg [ AM_EIBMSG ];
18 }
Codigo C.2: eib.nc
SenseM.nc
1 module SenseM {
2 provides {
3 interface StdControl ; }
4 uses {
5 interface Timer ;
6 interface ADC ;
7 interface StdControl as ADCControl ;
8 interface Leds ;
9 interface IntOutput ;
10 }
11 }
12
13 implementation {
14 result_t display ( uint16_t value )
15 {
16 if ( value &1) call Leds . yellowOn () ;
17 else call Leds . yellowOff () ;
18 if ( value &2) call Leds . greenOn () ;
19 else call Leds . greenOff () ;
20 if ( value &4) call Leds . redOn () ;
21 else call Leds . redOff () ;
22 return SUCCESS ;
23 }
24
25 command result_t StdControl . init () {
26 return call Leds . init () ;
27 }
28
29 command result_t StdControl . start () {
30 return call Timer . start ( TIMER_REPEAT , 2000) ;
31 }
32
33 command result_t StdControl . stop () {
34 return call Timer . stop () ;
35 }
36
37 event result_t Timer . fired () {
38 return call ADC . getData () ;
39 }
40
41 async event result_t ADC . dataReady ( uint16_t data ) {
42 display (7 -(( data > >7) &0 x7 ) ) ;
43 call IntOutput . output (( data > >7) &0 xf ) ;
44 return SUCCESS ;
45 }
46
47 event result_t IntOutput . outputComplete ( result_t success ) {
48 return SUCCESS ; }}
Codigo C.3: SenseM.nc
eibM.nc
1 includes EIBMsg ;
2 module eibM {
3 provides {
4 interface IntOutput ;
5 interface StdControl ;
6 interface ProcessCmd ;
7 }
8 uses {
9 interface ReceiveMsg as ReceiveEIBMsg ;
10 interface StdControl as CommControl ;
11 interface Leds ;
12 interface SendMsg as Send ;
13 }
14 }
15 implementation {
16 TOS_MsgPtr m ;
17 int8_t bcast_pending ;
18 TOS_Msg buf ;
19 int8_t pending2 ;
20 int8_t lastSeqno ;
21 bool pending1 ;
22 TOS_Msg data ;
23 bool retransmite ;
24
25 int16_t intensidad ;
26
27
28 task void cmdInterpret () {
29 signal ProcessCmd . done (m , SUCCESS ) ;
30 }
31
32 task void forwarder () {
33
34 struct EIBMsg * message = ( struct EIBMsg *) m - > data ;
35 message - > seqno = lastSeqno ;
36 message - > dfisica = 0 xBB ;
37 if ( retransmite ) {
38 call Send . send ( TOS_BCAST_ADDR , 8 , m ) ;
39 }
40 else {
41 pending1 = FALSE ;
42 bcast_pending = 0;
43 }
44 }
45
46 command result_t StdControl . init () {
47 m = & buf ;
48 bcast_pending = 0;
49 pending2 = 0;
50 lastSeqno = 0;
51 pending1 = FALSE ;
52 retransmite = FALSE ;
53 intensidad = 0;
54 return call CommControl . init () ;
55 }
56
57 command result_t StdControl . start () {
58 return call CommControl . start () ;
59 }
60
61 command result_t StdControl . stop () {
62 return call CommControl . stop () ;
63 }
64
65 inline char is_new_msg ( struct EIBMsg * bmsg ) {
66
67 if ( bcast_pending ) return 0;
68 return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) <
lastSeqno ) ) ;
69 }
70 inline void remember_msg ( struct EIBMsg * bmsg ) {
71 lastSeqno = bmsg - > seqno ;
72 bcast_pending = 1;
73 }
74
75 event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) {
76
77 TOS_MsgPtr ret = m ;
78 result_t retval ;
79 struct EIBMsg * datos = ( struct EIBMsg *) m - > data ;
80 if ( is_new_msg ( datos ) ) {
81 remember_msg ( datos ) ;
82 retval = call ProcessCmd . execute ( pmsg ) ;
83 ret = m ;
84 m = pmsg ;
85 }
86 return ret ;
87 }
88
89 command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) {
90 pending2 =1;
91 m = pmsg ;
92 post cmdInterpret () ;
93 return SUCCESS ;
94 }
95
96 command result_t IntOutput . output ( uint16_t value )
97 {
98 if ( value > 7) {
99
100 if ( intensidad != 0) {
150
151 else if ( value == 0 ) {
152 if ( intensidad != 255) {
153 EIBMsg * message = ( EIBMsg *) data . data ;
154 intensidad = 255;
155 if (! pending1 )
156 {
157 pending1 = TRUE ;
158 lastSeqno = lastSeqno + 1;
159 message - > datos = R EGULACION_ABSOLUTA ;
160 message - > valor = 255;
161 message - > seqno = lastSeqno ;
162 atomic {
163 message - > control = 0 xBC ;
164 message - > dfisica = DIRE_FISICA_1_1_2 ;
165 message - > dgrupo = DIRE_GRUPO_1_1_1 ;
166 message - > hop_count = 0 x00 ;
167 message - > length = 0 x02 ;
168 message - > seguridad = 255; }
169 if ( call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , &
data ) )
170 return SUCCESS ;
171 pending1 = FALSE ;
172 }
173 }
174 }
175 return FAIL ;
176 }
177
178
179 event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status )
180 {
181 if ( pending1 && msg == & data )
182 {
183 pending1 = FALSE ;
184 signal IntOutput . outputComplete ( SUCCESS ) ;
185 }
186 if ( status == SUCCESS ) bcast_pending = 0;
187 return SUCCESS ;
188 }
189
190 default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg ,
result_t status ) {
191 m = pmsg ;
192 if ( status ) {
193 post forwarder () ;
194 } else {
195 bcast_pending = 0;
196 }
197 return SUCCESS ;
198 }
199
200 default event result_t IntOutput . outputComplete ( result_t
success ) {
201 return SUCCESS ;
202 }
203 }
Codigo C.4: eibM.nc
DemoSensor2C.nc
1 configuration DemoSensor2C
2 {
3 provides interface ADC ;
4 provides interface StdControl ;
5 }
6 implementation
7 {
8 components HamamatsuC as DemoSensor ;
9
10 StdControl = DemoSensor ;
11 ADC = DemoSensor ;
12 }
Codigo C.5: DemoSensor2C.nc
Diagramas Nesdoc
El diagrama es similar para las aplicaciones de iluminacion y persianas, tanto para los
nodos configurados como pulsadores como los nodos configurados como actuadores.
E.1. Telos
[14] F. Losilla, Estado del arte para redes de sensores y perspectivas desde el punto de vista
de la ingenieria del software, Universidad Politecnica de Cartagena, Octubre 2005.
[15] EIB implementation on Twisted Pair , EIB Handbook 3.0 v1.0, Vol2, 1999.
[16] European Standard EN 50090 for Home and Building Electronic Systems.
[19] Callaway, E., Gorday, P., Hester, L., Gutierrez, J.A., Naeve, M., Heile, B., Bahl, V.,
Home networking with IEEE 802.15.4: a developing standard for low-rate wireless per-
sonal area networks, Communications Magazine, IEEE, Volume 40, Issue 8, pp. 70-77,
August 2002.
[20] D. Culler, D. Estrin, Overview of Sensor Networks, IEEE Computer Society 0018-
9162/04 August 2004.
[21] Taylor, K., Ward, J., Gerasimov, V., James, G., Local Computer Networks, 2004. 29th
Annual IEEE International Conference on, pp. 463-470. November 2004.
[22] Noury, N., Virone, G., Barralon, P., Ye, J., Rialle, V., Demongeot, J., Enterprise Net-
working and Computing in Healthcare Industry, 2003. Healthcom 2003 Proceedings. 5th
International Workshop on, pp. 118-127, June 2003.
[23] European Installation Bus System Specification, European Installation Bus Associa-
tion Handbook Series. Vol I, version 1.0, July 1999.
[24] Project Engineering for EIB Installations. Basic Principles, European Installation
Bus Association. 4a revision. 1998.
[27] KNX Projects: Terminal 5 Heathrow in London, KNX Projects Awards 2006. KNX
Journal, no 2, pp. 3-16, 2006.
[29] Konnex Association, Estandar Konnex para control de viviendas y edificios, 2007.
http://www.konnex.org/
[35] Domotium, la domotica a otro nivel . Domotium, marca de lujo de Domodesk, 2007.
http://www.domotium.com/
[37] Inmomatica, domotica y tecnologa para vivir . Control integral de edificios y viviendas.
Tecnologa para el hogar, 2007.
http://www.inmomatica.com/
[41] TinyOS Community Forum. An open-source OS for the networked sensor regime,
2007.
http://www.tinyos.net
[46] Making sense of Sensor Networks. Crossroads - The ACM Student Magazine, 2007.
http://www.acm.org/crossroads/xrds9-4/sensornetworks.html
[51] BTnode Platform. A distributed environment for prototyping Ad Hoc Networks, 2007.
http://btnode.ethz.ch/