PFC 2164

ESCUELA TECNICA SUPERIOR DE INGENIERIA DE TELECOMUNICACION
UNIVERSIDAD POLITECNICA DE CARTAGENA
Proyecto Fin de Carrera
Programacio n de
Redes de Sensores Inalambricas para
moticas
aplicaciones do
Autor
Pedro Jos
e Meseguer Copado
Directores
D. Manuel Jimenez Buenda
D. Fernando Losilla L
opez
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
Las redes de sensores inalambricas estan experimentando un gran crecimiento

en los ultimos a
nos, desarrollandose en aplicaciones de diversos ambitos como la medi-
cina, botanica, militares, etc. La domotica, entendida como automatizacion de viviendas
y edificios, es uno de los campos de aplicacion donde las redes de sensores van a crear
sistemas inteligentes capaces de adaptarse a cualquier tipo de viviendas, del tipo que sean,
as como aumentar las prestaciones, ventajas y aplicaciones dentro de las funcionalidades
que ofrece la domotica: seguridad, ahorro energetico, comunicaciones y confort.
Este proyecto parte de estas bases y esta centrado en la programacion de aplicaciones
domoticas de iluminacion, persianas y sensores, para motes inalambricos del tipo Telos
rev.B, basandose en los protocolos y criterios de la tecnologa domotica EIB.
Titulacion Ingeniero de Telecomunicacion

Intensificaci
on Sistemas y Redes de Telecomunicacion
Departamento Departamento de Tecnologa Electronica
Fecha de Presentaci
on Marzo de 2007
Proyecto Final de Carrera 2

A mi familia
A mis padres
A mis compa
neros y amigos
A mis directores de proyecto
A todos los que, de alguna forma, me han ayudado
Por vuestro apoyo, paciencia y confianza, gracias
La recompensa se encuentra en el esfuerzo y no en el resultado.

Un esfuerzo total es una victoria completa
Mahatma Gandhi

Indice general
Indice General 7
Indice de Figuras 11
Indice de Tablas 13
Introducci
on 15
I. Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.1. Objetivo Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.2. Objetivo Practico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Parte I. Dom
otica 21
Dom
otica 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

INDICE GENERAL
VI.1. Ejemplo Proyecto KNX/EIB . . . . . . . . . . . . . . . . . . . . . . . 73
Parte II. Redes de sensores inal

ambricas 77
Redes de sensores inal

ambricas 77
I. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
I.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
II. Caractersticas de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
II.1. Arquitecturas de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . 83
II.2. Protocolos de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . . 84
II.3. Zigbee, estandar WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
II.4. Problemas de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
III. Aplicaciones de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
III.1. Aplicaciones militares . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
III.2. Aplicaciones medioambientales . . . . . . . . . . . . . . . . . . . . . . 93
III.3. Aplicaciones sanitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
III.4. Aplicaciones del hogar: domotica . . . . . . . . . . . . . . . . . . . . . 94
III.5. Otras aplicaciones comerciales . . . . . . . . . . . . . . . . . . . . . . 95
IV. Nodos sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
V. Ejemplos de motes: Micas y Telos . . . . . . . . . . . . . . . . . . . . . . . . . 100
V.1. Micas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
V.2. Telos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
V.3. Resumen comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
VI. TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
VI.1. nesC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
VI.2. Herramientas de TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 113
VII. Futuro de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Parte III. Proyecto de integraci

on de
WSN y dom otica 121
Proyecto de integraci
on de WSN y dom
otica 121
I. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
I.1. WSAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
I.2. Ventajas de la domotica inalambrica . . . . . . . . . . . . . . . . . . . 123
I.3. Soluciones existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
II. Escenario del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
III. Programacion de las aplicaciones domoticas . . . . . . . . . . . . . . . . . . . 128
III.1. Aplicaciones de iluminacion . . . . . . . . . . . . . . . . . . . . . . . . 134
III.2. Aplicaciones de persianas . . . . . . . . . . . . . . . . . . . . . . . . . 151
III.3. Aplicacion de sensor crepuscular . . . . . . . . . . . . . . . . . . . . . 157
IV. Ejemplo de aplicacion: Vivienda con configuracion estatica . . . . . . . . . . . 160
V. Configuracion de los puertos de expansion de TelosB . . . . . . . . . . . . . . 162
V.1. Configuracion hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 163
V.2. Programacion de los puertos . . . . . . . . . . . . . . . . . . . . . . . 164
VI. Perspectivas de futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Conclusiones 171
Ap
endices 173

INDICE GENERAL
A. C
odigo fuente - Iluminaci on 173
A.1. Nodos pulsadores Iluminacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A.2. Nodos actuadores Iluminacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
B. C
odigo fuente - Persianas 185
B.1. Nodos pulsadores Persianas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
B.2. Nodos actuadores Persianas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
C. C
odigo fuente - Sensores 197
C.1. Nodo Sensor Crepuscular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
D. Diagramas Nesdoc 205

D.1. Diagrama completo de Iluminacion y Persianas . . . . . . . . . . . . . . . . . 205
D.2. Diagrama completo de Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . 207
E. Hardware Telos rev.B 209

E.1. Telos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
E.2. Telos - CC240 802.15.4 Wireless Radio . . . . . . . . . . . . . . . . . . . . . . 211
E.3. Telos - USB Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Bibliografa 213

Indice General

Indice de Figuras
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 tama no 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

Indice General
41. Resolucion de colisiones CSMA/CD en EIB . . . . . . . . . . . . . . . . . . . 63

42. Formato de la trama EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
43. Formato del campo de control . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
44. Formato del campo de direccion destino . . . . . . . . . . . . . . . . . . . . . 64
45. Formato del campo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
46. Campo de comprobacion de la trama . . . . . . . . . . . . . . . . . . . . . . . 66
47. Componentes de un dispostivo EIB . . . . . . . . . . . . . . . . . . . . . . . . 67
48. Componentes y objetos de comunicacion en ETS . . . . . . . . . . . . . . . . 68
49. Konnex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
50. Terminal 5 de Heathrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1. Red de sensores inalambrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2. Tama no de los nodos Smart Dust . . . . . . . . . . . . . . . . . . . . . . . . . 79
3. Elementos de una WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4. Arquitectura WSN centralizada . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5. Arquitectura WSN distribuida . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6. Niveles fsico, red y aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7. Comparativa estandares inalambricos . . . . . . . . . . . . . . . . . . . . . . . 87
8. Espectro de estandares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
9. Aplicaciones Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. Aplicaciones para WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
11. Tracking de animales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
12. Reconocimiento del enemigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
13. Desplegue de sensores para reconocimientos . . . . . . . . . . . . . . . . . . . 92
14. Deteccion de incendios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
15. Aplicacion domotica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
16. Nodos sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
17. Comparacion plataformas para nodos . . . . . . . . . . . . . . . . . . . . . . . 97
18. Estados de un nodo sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
19. Distribucion del consumo de energa . . . . . . . . . . . . . . . . . . . . . . . 99
20. Estructura de red y motes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
21. Micaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
22. Diagrama de bloques Micaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
23. Caractersticas tecnicas de Micas . . . . . . . . . . . . . . . . . . . . . . . . . 101
24. Mica2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
25. Diagrama de bloques Mica2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
26. Mica2dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
27. Diagrama de bloques Mica2dot . . . . . . . . . . . . . . . . . . . . . . . . . . 103
28. Sensores MTS300 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
29. Tipos de sensores para Micas . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
30. TelosB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
31. Diagrama de bloques TelosB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
32. Evolucion de los motes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
33. Comparativa de tiempos y consumos . . . . . . . . . . . . . . . . . . . . . . . 107
34. Estructura de un componente . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
35. Ficheros de una aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
36. TinyViz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
37. Surge View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
38. TinyDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
39. Twister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
40. T
unel WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

INDICE DE FIGURAS
1. Arquitectura WSAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

2. Casa domotica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3. Control4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4. Vivienda escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5. Relacion de componentes en Blink . . . . . . . . . . . . . . . . . . . . . . . . 131
6. Aplicacion Oscilloscope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7. Aplicacion SerialForwarder y captura de mensajes . . . . . . . . . . . . . . . 133
8. Ejemplo de telos sensores y actuadores . . . . . . . . . . . . . . . . . . . . . . 135
9. Diagrama de eib.nc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
10. Diagrama de TimerC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
11. Algoritmo de Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12. Ejemplo de telos en aplicacion de persianas . . . . . . . . . . . . . . . . . . . 152
13. Algoritmo de movimiento de paso . . . . . . . . . . . . . . . . . . . . . . . . . 153
14. Algoritmo de movimiento total . . . . . . . . . . . . . . . . . . . . . . . . . . 155
15. Diagrama Sense.nc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
16. Sensor crepuscular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
17. Vivienda con motes distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18. Estancia con motes configurados . . . . . . . . . . . . . . . . . . . . . . . . . 161
19. Detalle de componentes TelosB . . . . . . . . . . . . . . . . . . . . . . . . . . 162
20. Conectores de expansion TelosB . . . . . . . . . . . . . . . . . . . . . . . . . . 163
21. Esquematico para botones y leds . . . . . . . . . . . . . . . . . . . . . . . . . 163
22. TelosB con leds y botones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
23. TelosB con expansiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Indice de Figuras

Indice de Tablas
I.1. Tipos EIS normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
III.1. Valores e intensidades de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

III.2. Tabla configuracion de motes . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
III.3. Correspondencia de se nales y puertos . . . . . . . . . . . . . . . . . . . . . . . 163
III.4. Configuracion de direcciones de pines . . . . . . . . . . . . . . . . . . . . . . . 166

Indice de Tablas

Introducci
on
I. Presentaci
on
En los u ltimos a
nos 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 a nos, 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 a nadimos la
capacidad de comunicacion inalambrica y la posibilidad de formacion de redes, obtenemos
las Redes de Sensores Inal ambricas, 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.
La dom otica, definida como la automatizacion de viviendas y edificios, es una de las

aplicaciones mas atractivas de las redes de sensores inalambricas por diversos motivos.
En primer lugar, supone un medio economico de introducir los sensores y actuadores nece-
sarios para la automatizacion con bajo impacto para la arquitectura de un edificio. Ademas,
su bajo coste permitira desplegar cientos de nodos que se podran integrar en nuestra vida
diaria y permitir la denominada computacion ubicua, que consiste en la gestion de entornos
inteligentes en el interior de edificios y viviendas basados en la determinacion y prediccion
de la localizacion de usuarios.
As, los dispositivos de la vivienda seran capaces de comunicarse entre s y cooperar entre
ellos, lo que permitira configurar la casa para que la intensidad de luz baje automaticamente
cuando se encienda el televisor, que la temperatura de una estancia se ajuste a los gustos de
un usuario cuando este la ocupe, o, por supuesto, para realizar un control energetico del con-
sumo, mantener un sistema de seguridad en la vivienda monitorizado a distancia o cualquier
comunicacion con otro tipo de redes multimedia o Internet.

Introducci
on
El presente proyecto abarca estos dos grandes campos a un 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. Objetivos
II.1. Objetivo Te
orico
El objetivo teorico del proyecto es conocer e investigar en profundidad los dos puntos
principales que abarcamos:
La dom otica y los edificios inteligentes.

Profundizar en las distintas tecnologas existentes, con sus ventajes e inconvenientes,
posibilidades que ofrecen, aplicaciones existentes, as como los problemas que puedan
ocasionar dichos sistemas.
Las redes de sensores inal ambricas.

Estudiar los distintos tipos de sensores inalambricos existentes hoy en da en el mercado,
concretamente en los micas y telos que utilizaremos para el proyecto, as como sus
lenguajes de programacion y aplicaciones que proporcionan.
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.
En primer lugar, analizaremos los sistemas domoticos, sus caractersticas, prestaciones y

las distintas tecnologas existentes en el mercado, realizando una descripcion mas extensa del
sistema EIB.
A continuacion, abarcaremos las redes de sensores inalambricas, explicando sus caracte-
rsticas y las aplicaciones mas importantes en las que estan destinadas actualmente. Ademas,
veremos los tipos de sensores existentes, centrandonos en los TeloB y en el sistema de pro-
gramacion que utilizan.
Finalmente, desarrollaremos el tema fundamental de nuestro proyecto: las redes apli-
cadas a domotica. Explicaremos las distintas aplicaciones programadas, montajes realizados
y posibles perspectivas de futuro, as como sacaremos conclusiones del estudio realizado y los
resultados obtenidos.
II.2. Objetivo Pr
actico
El objetivo practico consistira en realizar un ejemplo de configuracion de una vivienda
domotica basada en estos dispositivos inalambricos. Por tanto, conllevara el dise
no y la pro-
gramacion de aplicaciones siguiendo un modelo de tecnologa domotica (el sistema EIB) y
posterior implantacion en los sensores.
A modo de ejemplo, tomaremos como escenario una vivienda unifamiliar en la que po-
dremos integrar estos sensores configurados con las aplicaciones que desarrollemos. Veremos
como se programaran dichas aplicaciones en funcion de la configuracion de la vivienda y las
prestaciones que queramos obtener.
Ademas, se realizara una parte de montaje a

nadida a los sensores TelosB, con el dise
no 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.

Introducci
on

Parte I
Dom
otica

Dom
otica
I. Generalidades
La domotica, dicho en muy pocas palabras, es la instalacion e integraci on de varias
redes y dispositivos electr onicos 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 autom atica.
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 u nicamente 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:
Dom
otica, para el sector domestico.
Inm
otica, para el sector terciario.
Urb
otica, para las ciudades. En este caso se tratan temas como el control de la ilumi-
nacion p
ublica, 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
energ etico. Todo ello teniendo en cuenta la facilidad de uso para todos los inquilinos, aun
cuando alguno de ellos presente alguna minusvala fsica.
Desde el punto de vista tecnologico, la definicion podra ser la siguiente: es aquella en la

que se integran los distintos aparatos domesticos que tienen la capacidad de intercomunicarse
entre ellos a traves de un soporte de comunicaciones, de modo que puedan realizar tareas que
hasta ahora se venan haciendo de forma manual.

Dom
otica
El uso de las TIC (Tecnologas de la Informacion y las Comunicaciones) en la vivienda

genera nuevas aplicaciones y tendencias basadas en la capacidad de proceso de informacion y
en la integracion y comunicacion entre los equipos e instalaciones. As concebida, una vivienda
inteligente puede ofrecer una amplia gama de aplicaciones en areas tales como:
Seguridad
Gestion de la energa
Automatizacion de tareas domesticas
Formacion y cultura
Monitorizacion de salud
Comunicacion con servidores externos
Ocio y entretenimiento
Operacion y mantenimiento de las instalaciones
La introduccion de todos estos sistemas y tecnologas en el hogar aun no es una realidad,

salvo en contadas ocasiones, pero s hay muchos catalizadores que ayudaran a que ello se
realice rapidamente.
Por una parte cada vez existen mas dispositivos electronicos en el hogar. Eso provoca una
necesidad real de comunicar unos con otros. Por otra, la estandarizacion de las tecnologas
de comunicacion privadas como las redes Ethernet cableadas o las redes inalambricas Wi-Fi,
han reducido los costes a unos niveles que permiten su despliegue masivo. Y, por supuesto,
la disponibilidad y flexibilidad del elemento base que ha acelerado el desarrollo de la in-
formatica en los ultimos tiempos: los ordenadores, as como la paulatina convergencia de
la informatica y las telecomunicaciones, y la necesidad, cada vez mayor, de la informaci on
a todos los niveles.
Figura 1: Casa domotica

I Generalidades
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 peque
no, que esta siendo
cuidado por otra persona.
Es indudable que cuantas mas posibilidades existen, mayor dificultad entra na su inter-
conexion, por lo que es labor de las empresas integradoras empaquetar soluciones que tengan
una facil instalacion y, a
un 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 a nadirles 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
compa nas de servicios de luz, agua, electricidad, seguridad, etc., se les abre una puerta para
racionalizar sus costes, y a nadir valor para el usuario final.
Segun todo lo expuesto, la domotica no son servicios ni productos aislados, sino la imple-
mentacion e integraci
on 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 energ etico, se incrementan las posibilidades de ocio, etc. En definitiva, se produce
un incremento de la calidad de vida de sus habitantes.

Dom
otica
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, seg
un 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 a nos 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 p ublicas 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.
Figura 2: Pasarela residencial
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 sistemas de control: en instalaciones centralizadas, son los dispositivos encarga-

dos de gestionar y controlar los dispositivos destinados a la automatizacion del edificio,
segun los parametros de actuacion establecidos por los usuarios. En ellos reside toda la
inteligencia del sistema y suelen tener las interfaces de usuario necesarias para presentar
la informacion a este (pantalla, teclado, monitor, etc.).

II Caractersticas
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 se nal 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, seg
un 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 se
nal de conexion/desconexion
seg
un un umbral de temperatura previamente definido.
Figura 3: Detectores de presencia
3. Volum etricos de presencia.

Son de tipo digital y se activan cuando se produce un movimiento en sus inmedia-
ciones. Podemos distinguir cuatro tipos:

Dom
otica
Infrarrojos. Detectan las radiaciones infrarrojas, siendo sensibles a las varia-

ciones de calor.
Microondas. Producen ondas electromagneticas y detectan las variaciones que
haya en sus reflexiones.
Tecnologa dual. Combinan las dos tecnologas anteriores para evitar falsas
alarmas, dando una gran fiabilidad.
Ultrasonidos. Detectan el movimiento mediante ondas sonoras y sus reflexio-
nes.
4. Detectores de incendio.
Son de tipo digital, se activan cuando detectan partculas en el aire, calor o humo.
Hay diversos tipos, dependiendo del mecanismo que utilicen para detectar el humo
o las partculas:
opticos, i
onicos, termovelocmetros o de llama.
5. Detectores de inundaci on.
Son de tipo digital y se activan cuando detectan agua embalsada en el suelo. Se
han de instalar en zonas humedas de la vivienda (ba nos, cocina, etc.) o en recintos
con riesgos de inundacion (salas de calderas para la calefaccion, bombas de piscina,
etc.).
6. Detectores de corriente el ectrica.
Se emplean para medir la intensidad que circula por un determinado cable y se
usan normalmente para activar la funcion de racionalizacion de energa electrica.
Hay dos tipos: Transformador de intensidad y sensor de efecto Hall.
7. Detectores de gas.
Detectan gases toxicos y explosivos, como butano, propano, gas natural, gas ciu-
dad, etc. Estas alarmas nunca deberan faltar en la zonas donde se produzca
cualquier tipo de combusti on como cocinas, garajes, sistemas de calefaccion o
chimeneas.
8. Detectores de puertas y ventanas abiertas.
Son sensores digitales que consisten en unos contactos magneticos formados por
dos piezas: Un iman por un lado y y cuerpo metalico por otro lado. El hecho
de que esten en contacto ambas piezas produce una conmutacion en el circuito o
no, detectando la apertura de una puerta o ventana. Los mas importantes son los
empotrados para puertas y los de superficie para ventanas, puertas de armario,
cuadros, cajas fuertes, etc.
9. Anem ometros.
Miden la velocidad del viento y suelen estar formados por unas peque
nas aspas que
giran y cuya velocidad de giro es proporcional a la fuerza del viento. Se utilizan
para comandar los toldos y persianas motorizadas e impedir que se da nen con el
viento.
Figura 4: Anemometro

II Caractersticas
10. Detectores de lluvia.

Son de tipo digital y formados por un material que cambia su resistividad en fun-
cion del agua. Se utilizan para controlar el riego automatico en jardines, jardineras,
etc. y son importantes a la hora de ahorrar agua y energa.
11. Otros sensores.
Existen otros sistemas sensores para medir radiaciones, nivel de PH, nivel de
humedad relativa en el aire, presion atmosferica, detectores ssmicos, etc. que son
importantes desde el punto de vista del confort.
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. Electromec anicos.
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 se
nal externa. Se pueden
clasificar seg
un 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 m ultiples circuitos
simultaneamente.
Figura 5: Actuador de carril DIN
2. Acusticos.
Producen salidas ac
usticas, como pueden ser sirenas, bocinas, altavoces, etc.
3. Luminosos.
Este u
ltimo tipo genera salidas luminosas con paneles, monitores, etc.
Dependiendo de cada solucion o fabricante, hay equipos que son controladores/sensores/ac-

tuadores al mismo tiempo, ya que en un u nico equipo se dispone de toda la inteligencia nece-
saria para medir una variable fsica, procesarla y actuar en consecuencia (por ejemplo, un
termostato). Pero la mayora de las soluciones del mercado, sean propietarias o no, se cons-
truyen diferenciando los sensores de los actuadores con objeto de aportar mayor flexibilidad
y menor precio de cara a la instalacion e integracion en una vivienda.

Dom
otica
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 m
ultiples sensores y, una vez procesa-
da, genera las ordenes oportunas para los actuadores. Toda la informacion de deteccion
y actuacion se tratan en este u
nico punto.
El cableado es en estrella cuyo centro es la unidad central de control y no existe comu-
nicacion entre sensores y actuadores.
Figura 6: Sistema centralizado
Ventajas:
Bajo coste: ning

un elemento necesita modulo especial de direccionamiento ni in-
terface.
Instalacion sencilla.
Requerimientos mnimos.
Desventajas:
Flexibilidad limitada: las reconfiguraciones son costosas.

Poca robustez: si cae el modulo central cae todo el sistema.
Mayor longitud de cableado dada la topologa, su uso en grandes instalaciones es
limitado.

II Caractersticas
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.
Figura 7: Sistema distribuido, con bus de datos y red de alimentacion
Ventajas:
Alta flexibilidad y una gran facilidad para reconfiguraciones.

Posibilidad de tecnologas plug & play, que simplifican mucho las instalaciones.
Ahorro de cableado en la instalacion, lo que da ventajas respecto a los costes, sobre
todo en instalaciones y proyectos a gran escala.
Desventajas:
Precio elevado de componentes, dado el incremento de complejidad que conllevan.

Necesidad de compatibilidad entre los equipos y componentes.
Escasez de productos, debida a los requisitos exigibles de direccionamientos, pro-
tocolos, etc.
Hay que destacar que algunos sistemas usan un enfoque mixto, esto es, son sistemas
con arquitectura descentralizada en cuanto a que disponen de varios peque nos dispositivos
capaces de adquirir y procesar la informacion de m ultiples 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.

Dom
otica
Hay sistemas que son de arquitectura distribuida en cuanto a la capacidad de proceso,

pero no lo son en cuanto a la ubicacion fsica de los diferentes elementos de control y viceversa,
sistemas que son de arquitectura distribuida en cuanto a su capacidad para ubicar elemen-
tos de control fsicamente distribuidos, pero no en cuanto a los procesos de control, que son
ejecutados en uno o varios procesadores fsicamente centralizados.
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.
Sistemas mixtos: combinan el cableado con el inalambrico.
Figura 8: Sistemas cableados o inalambricos
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 u
nico controlador sobre el que pasa toda la informacion.
La Red de Anillo: cada controlador esta conectado a otros dos, y as sucesivamente,

formado un anillo.
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 dise
no que le posibilita adaptarse a las caractersticas fsicas de cada vivienda en
particular.

II Caractersticas
II.4. Medios de Transmisi

on
En todo sistema domotico los diferentes dispositivos deben intercambiar informacion unos
con otros a traves de un soporte fsico: par trenzado, lnea de potencia o red electrica, radio,
infrarrojos, etc.
Veamos los distintos tipos que se pueden presentar:
1. Lneas de distribuci
on de energa el
ectrica (Corrientes Portadoras).
Si bien no es el medio mas adecuado para la transmision de datos, s es una alternativa
a tener en cuenta para las comunicaciones domesticas dado el bajo coste que implica
su uso, puesto que se trata de una instalacion existente, por lo que es nulo el coste
de la instalacion, y con un conexionado sencillo. Para aquellos casos en los que las
necesidades del sistema no impongan requerimientos muy exigentes en cuanto a la
velocidad de transmision, la lnea de distribucion de energa electrica puede ser suficiente
como soporte de dicha transmision.
2. Soporte met
alico.
La infraestructura de las redes de comunicacion actuales, tanto p
ublicas como privadas,
tiene en un porcentaje muy elevado cables metalicos de cobre como soporte de trans-
mision de las se
nales electricas que procesa.
En general se pueden distinguir dos tipos de cables metalicos:
Par met alico: 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 se nales de vdeo y se
nales 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 n ucleo con un ndice de refraccion menor que el del revestimiento,
que envuelve a dicho n ucleo. 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 inal
ambricas:
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 n
umero de aplicaciones.

Dom
otica
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 Funcionalidad de la dom
otica
III. Funcionalidad de la dom

otica
Como se ha comentado anteriormente, la domotica es un conjunto de servicios realizados
por automatismos o dispositivos con cierto grado de inteligencia dentro del hogar, dirigidos
a la gestion de cuatro funciones basicas: control energetico, confort, seguridad y telecomuni-
caciones.
Aunque en muchos aspectos estas funciones se solapen, vamos a intentar diferenciar cada
una de ellas, puesto que son las que resumen de forma general las prestaciones domoticas que
puede tener una vivienda. Al realizar una instalacion, la proporcion de la inversion realizada
en cada uno de los apartados dependera de cual vaya a ser la finalidad del edificio o residencia,
que vendra en funcion, claro esta, del tipo de usuario que los habite.
III.1. Control energ

etico
La finalidad es satisfacer las necesidades del hogar al mnimo coste. En este control se
pueden distinguir tres aspectos diferenciados:
Regulaci on: con la que se pueda obtener la evolucion del consumo energetico de la
vivienda o edificio.
Programacion: para programar distintos parametros de la vivienda a nivel energetico,

como temperatura seg
un horarios, das de la semana, mes, etc.
Optimizaci on: de modo que se minimice el consumo. El aprovechamiento de la energa

y reduccion de su consumo, es uno de los apartados mas importantes en la instalacion
de un sistema domotico, puesto que revierte a medio y largo plazo en su amortizacion,
ademas de estar muy ligadas al concepto de confort. Las acciones destinadas a reducir
el consumo estan ntimamente ligadas a la integracion de todos los dispositivos de la
vivienda en el sistema. Dichas acciones son del tipo:
Aprovechamiento de las franjas de tarificacion de valle para hacer trabajar aquellos

equipos que lo permitan (p.e., aprovechamiento de tarifas nocturnas en funcion de
las necesidades programadas). Reduccion del consumo para climatizacion fuera de
las horas de trabajo normales.
Deteccion de fuentes de perdidas en sistemas de climatizacion (p.e. suspension del
funcionamiento en estancias donde se detecten ventanas abiertas).
Reduccion del consumo para climatizacion en ausencia de individuos en las es-
tancias mediante la deteccion automatica de presencia.
Actuacion sobre automatismos de persianas para el aprovechamiento de la luz
solar.
Figura 9: Control energetico

Dom
otica
III.2. Seguridad
Actualmente, aunque de manera individualizada (no integrada), es la funcion mas de-
sarrollada, y puede integrar m
ultiples aplicaciones, especialmente si se encuentra integrada
dentro de un sistema domotico. Se puede dividir en seguridad de personas y seguridad de
bienes.
En la seguridad de personas se incluyen tareas como:
Alumbrado automatico en zonas de riesgo por deteccion de presencia (escaleras, etc.)

para evitar accidentes domesticos.
Desactivacion de enchufes de corriente para evitar contactos.
Manipulacion a distancia de interruptores en zonas h

umedas.
Emision de avisos telefonicos a n

umeros prefijados en caso de necesidad de ayuda ur-
gente.
Detectores de fugas de gas o de agua que cierren las valvulas de paso a la vivienda en
el caso de producirse escapes.
Alarmas de salud. En el caso de personas con necesidades especiales (ancianos, personas

discapacitadas) se disponen pulsadores cuya activacion genera un aviso a una central
receptora, un familiar o un hospital para solicitar ayuda sanitaria urgente.
Figura 10: Sistema de alarmas tecnico
En cuanto a la seguridad de bienes se refiere, las funciones principales son:
Avisos a distancia. En ausencia del usuario se emiten avisos en caso de alarma (bien
ac
usticos o telefonicos).
Deteccion de intrusos. Incluye la instalacion de diversos sensores:
Sensores volumetricos para deteccion de presencia.

Sensores de hiperfrecuencia para cristales rotos.
Sensores magneticos para apertura de puertas y ventanas.

III Funcionalidad de la dom
otica
Alarmas tecnicas:
Deteccion de incendios.
Deteccion de fugas de agua y gas.
Ausencia de energa electrica.
En el caso de alarmas tecnicas tambien se pueden realizar acciones correctivas (p.e. si se

detecta escape de gas, cortar el suministro).
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:
Control de los distintos automatismos por infrarrojos o pantallas tactiles.
Automatizacion de riego de jardines.
Apertura automatica de puertas.
Centralizacion y supervision de todos los sistemas de la vivienda.
Accionamiento automatico de distintos sistemas en base a datos del entorno, como la

recogida automatica de toldos y bajada de persianas en caso de tormenta o viento
excesivo, etc.
Informacion de presencia de correo en el buzon.
Figura 11: Control mediante pantalla tactil

Dom
otica
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 seg un el tipo de
edificio, destacaremos:
Sistemas de comunicacion en el interior. Megafona, difusion de audio/vdeo, interco-

municadores, etc.
Sistemas de comunicacion con el exterior. Telefona basica, video-conferencia, e-mail,

Internet, TV digital, TV por cable, fax, radio, transferencia de datos (X25, ATM), etc.
Comunicaciones externas propias de la vivienda. Mensajes de alarma como fugas de gas,

agua, etc., y telecontrol del sistema domotico a traves de la lnea telefonica o conexion
a redes de datos (Internet).
De entre todas ellas, las que mayor auge estan teniendo en los u ltimos 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:
Control de instalaciones domoticas mediante protocolo TCP/IP utilizando html o ap-

plets de Java, para la teleoperacion y monitorizacion de sistemas domoticos en edificios.
Control de instalaciones domoticas mediante mensajes SMS. Consistente en la apli-

cacion de la tecnologa GSM al control de remoto de redes domoticas, ampliando sus
posibilidades con nuevas tecnologas como 3G en el campo del envo de audio y vdeo.
Acceso a redes EIB para personas discapacitadas empleando redes inalambricas de

datos (IEEE 802.11b) mediante aplicaciones cliente-servidor con protocolo TCP/IP,
que facilitan el acceso a todas las funciones de la vivienda a personas discapacitadas a
traves del uso del ordenador personal.
Aplicacion de sistemas de encriptacion y autentificacion en el acceso remoto a instala-

ciones domoticas a traves de Internet, para asegurar la privacidad y seguridad de los
datos en el acceso a traves de redes p
ublicas.
Integracion de redes domoticas en redes de fibra optica ya existentes.
Figura 12: Controlador pronto de Philips

IV Tecnologas existentes
IV. Tecnologas existentes

Actualmente existen numerosos sistemas domoticos comerciales y cada uno de ellos esta o-
rientado a un segmento concreto del mercado. Desde el punto de vista comercial, puede decirse
que los tres sectores mas importantes que precisan actualmente de estos sistemas son las casas
ya construidas, las casas nuevas y los grandes edificios (hoteles, oficinas, residencias). Cada
uno de estos sectores utiliza una tecnologa especfica, adaptada a las necesidades del usuario
final. Basicamente vamos a distinguir entre casas ya construidas, viviendas nuevas, y grandes
edificios.
En una casa construida, se suelen utilizar sistemas denominados de corrientes portado-

ras (traduccion del frances courant porteur), que tienen como soporte de comunicacion la
propia red de alimentacion de baja tension (BT) de 220 V, presente en la vivienda. El motivo
del empleo de este tipo de tecnologa es el elevado coste, y en muchos casos la imposibilidad,
de realizar un nuevo precableado para el sistema domotico. En este caso, los sistemas ma-
yoritariamente adoptados por los instaladores son el sistema europeo CAD de Legrand y el
americano X-10 de Home Systems, comercializado en Europa por Niessen.
Si se trata de una casa nueva, dependiendo de su tama no 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 peque no sin grandes requerimientos. Las gamas
altas de SCC se emplean en viviendas nuevas de tama no 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 Espa na 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 ning un 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.
Figura 13: Sistemas en funcion del tama

no de edificacion

Dom
otica
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.
A continuacion, haremos un repaso de las principales tecnologas existentes que hemos

mencionado, comentando sus pros y contras, para poder establecer una clara comparativa
entre ellas. Estableceremos una distincion entre los sistemas americanos y europeos hasta,
finalmente, ver en detalle el sistema KNX-EIB puesto que, ademas de asentarse como el
estandar europeo mas importante, es el protocolo que hemos elegido para la realizacion de
este proyecto.
Figura 14: Normalizacion de los sistemas domoticos

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.
Figura 15: Arquitectura de CEBus, tomando como referencia el modelo OSI
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.
Los objetivos principales del estandar son:
Facilitar el desarrollo de modulos de interfaz de bajo coste que puedan ser integrados
facilmente en electrodomesticos.
Soportar la distribucion de servicios de audio y vdeo tanto en formato analogico como

digital.
Evitar la necesidad de un controlador central, distribuyendo la inteligencia de la red

entre todos los dispositivos.
Permitir a
nadir 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.
Proporcionar un metodo adecuado de acceso al medio.
En CEBus se diferencian tres areas:
1. El medio fsico y la topologa.
2. El protocolo de comunicaciones: como acceder al medio y construir los mensajes.
3. El lenguaje de programacion: conjunto de acciones que se pueden efectuar en el sistema.

Dom
otica
El protocolo y el lenguaje son comunes a todos los elementos CEBus, pero existen 6
medios fsicos distintos:
Red electrica (PL)
Par trenzado (TP)
Infrarrojo (IR)
Radio frecuencia (RF)
Coaxial (CX)
Fibra optica (FO)
La eleccion del medio se realiza en funcion de parametros como el ahorro energetico,

comodidad, facilidad de instalacion de los productos CEBus, seguridad, coste y sencillez del
sistema. En una instalacion pueden coexistir diversos medios.
Cada uno de ellos constituira una subred local (Local Medium Network ). Las subredes
locales se conectan mediante encaminadores (routers).
CEBus engloba varios canales de comunicacion: uno de control y varios de datos. En el
canal de control se intercambian mensajes y ordenes para el control de los dispositivos de la
instalacion domotica. Los canales de datos se emplean para la transmision de voz, m usica,
TV, video etc., y se asignan por solicitud mediante el canal de control.
Por lo general, la distribucion de las distintas se
nales se realiza de la siguiente manera:
Se
nales de video: mediante dos cables coaxiales, uno para las se
nales internas y otro
para las externas.
Se
nales de voz/datos: cuatro pares trenzados, TP0-TP3 (TP0 se reserva para la ali-
mentacion de 18Vdc).
Resto de senales: a traves de la red de BT, conectando equipos a enchufes estandar. Se

utiliza una tecnica de modulacion con espectro ampliado de Intellon Corp.
La velocidad de transmision de datos que se consigue es de 10Kbps, y puede ser utilizado

tanto en viviendas ya construidas como de nueva construccion. Se trata de un estandar muy
ambicioso, y en el cooperan tanto Europa como Japon, pero no existen muchos productos
comercializados, lo que se debe principalmente a su elevado precio.

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 compa nas 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.
El sistema X-10 se caracteriza principalmente por:
Ser un sistema descentralizado, configurable, no programable.
De instalacion sencilla: conectar y funcionar (plug & play)
De facil manejo por el usuario.
Compatibilidad casi absoluta con los productos de la misma gama, obviando fabricante
y antig
uedad.
Flexible y ampliable.
Figura 16: Instalacion X10
La red de la instalacion es la base de todo el sistema de corrientes portadoras. El elemento

basico y fundamental de la tecnica de corrientes portadoras es el aprovechamiento doble de
la instalacion electrica ya existente, como conductor de energa y de informacion.

Dom
otica
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 se nales 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 compa na. Mas de 100 millones de
equipos se han vendido durante los u ltimos 15 a nos, haciendo de X-10, en este sentido, el
lder en sistemas de control del hogar.

Principio de funcionamiento de X10

Las transmisiones en X-10 estan sincronizadas con el paso por cero de la tension de red,
esta caracterstica es com un a todos los dispositivos X-10 y tiene una doble finalidad: la
primera es sincronizar a los transmisores y receptores, ya que la u nica conexion fsica que
existe entre ellos es la lnea de red, la segunda es debida a que el nivel mnimo de interferen-
cias producidas por otros equipos electricos se produce cuando la se nal de red pasa por cero.
Los dispositivos X-10 no distinguen entre el paso por cero cuando la se nal va de positivo a
negativo o de negativo a positivo; ambos pasos por cero son interpretados de igual modo por
el dispositivo.
Un 1binario del mensaje se representa por un pulso de 120 Khz durante 1 ms, en el
paso por cero de la se
nal 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 seg un se muestra en la figura).
Figura 17: Codificacion de bits en X10
El codigo de comienzo (1110) es el unico que no se enva de forma complementaria, y

sirve para identificar de manera unvoca el inicio de los paquetes de datos.
Figura 18: Codigo de comienzo 1110
El principio de codificacion X10 permite una activacion y respuesta definidas de hasta

256 receptores, puestos de control de aparatos o de grupos de consumidores. Con ello resulta
posible el montaje de amplias redes.

Dom
otica
Un bloque completo de datos o paquete de informacion se compone de codigo de comienzo,

codigo de la letra, codigo de control y sufijo.
Figura 19: Paquete de datos X10
El codigo de control puede ser o una direccion de unidad o un codigo de comandos,

dependiendo de si el mensaje es una direccion o un comando. Las tablas siguientes muestran
los posibles valores de los codigos de casa y control.
Figura 20: Codigos de casa y de control para unidad
Figura 21: Codigos de control para comandos
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.
Figura 22: Ciclos para una transmision completa en X10
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.).
Consideraciones de instalaci
on en X-10
Montaje en sistemas trif
asicos.
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.
Interferencias en la lnea electrica.
La transmision de se
nales de pulsos a alta frecuencia a traves de la red electrica puede
verse afectada por interferencias. Las fuentes tpicas que producen interferencias son aparatos
electricos como TV, VCR, equipos de sonido, computadoras, monitores, transformadores e
incluso los cables preparados con filtros tienen la tendencia de depositar ruido electrico sobre
los cables de la red. Muchos de los nuevos aparatos electronicos que se emplean en el ambito
domestico incluyen circuitos para minimizar los ruidos electricos que generan.
Estas fuentes de ruido sobre la red electrica pueden ocasionar atenuacion o bloqueo de las

Dom
otica
se
nales 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 se
nal 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 se
nales de frecuencia diferente a 120 Khz.
Amplificaci
on.
Cuando las distancias son largas y/o la atenuacion de las se nales X10 elevada en una
instalacion, se pueden emplear elementos amplificadores de se nal. Estos dispositivos trabajan
de la siguiente forma: el amplificador vigila el circuito de se
nales 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 se nal 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. M
ultiples transmisores pueden enviar se
nales al mismo modulo.
Receptores.
Los receptores vienen dotados de dos peque nos 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.
Figura 23: Dispositivos X-10

Bidireccionales.
Tienen la capacidad de responder y confirmar la correcta realizacion de una orden,
lo cual puede ser muy u
til 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.
Inal
ambricos.
Permiten conectarse a traves de una antena y enviar se nales de radio desde una unidad
inalambrica e inyectar la se
nal 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:
Acoplador / Repetidor - X10.

Asegura la calidad de la se nal X10 cuando la distancia entre controlador y modulos
receptores es demasiado larga y la senal sufre atenuacion. Ademas de amplificar la se
nal,
la transmite en las tres fases por lo que servira de acoplador en sistemas complejos no
monofasicos.
Filtro Acoplador / Fases Carril DIN.
Este modulo X10 RAIL-DIN tiene muchas funciones. Impide a las se nales X10 sobre
corriente portadora salir de la vivienda y ocasionar perturbaciones en otra instalacion.
Suprime las interferencias que vienen del exterior, como las parasitarias, ordenes X10
de otra instalacion vecina. Ademas acopla las tres fases, en el caso de una instalacion
de corriente trifasica.
Programador / Verificador.
Es capaz de transmitir y recibir cada uno de los comandos, ademas de los comandos ex-
tendidos X10. Es una herramienta basica para instaladores de dispositivos X10: permite
conocer niveles de ruido, niveles de se
nal, y otras. Tiene modos automaticos de trans-
mision y permite registrar actividad en la lnea durante periodos de 24 horas. Permite
la emision de la se
nal en incrementos de nivel de 33,3mV.
Figura 24: Accesorios X-10

Dom
otica
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 peque
no 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.
Los medios de transmision disponibles son cinco:

1. Par trenzado (categora IV) de cinco hilos: dos de datos, dos de alimentacion y uno de
tierra.
2. Fibra optica.
3. Lnea de baja tension.
4. Radiofrecuencia.
5. Cable coaxial.
El protocolo de ese sistema implementa todos los niveles del modelo de referencia OSI,
como se ilustra en la siguiente tabla.
Figura 25: Protocolos LonWorks y equivalente OSI
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.

Existen vario tipos de direcciones:
1. Direcci on fsica (Neuron ID): consiste en una direccion de 48 bits que viene grabada
de fabrica (como la direccion MAC en una tarjeta de red).
2. Direcci
on de dispositivo, que esta formada por tres campos:
ID de dominio (domain ID): un dominio es una coleccion de dispositivos que

pueden interoperar (en una red virtual), localizados en uno o mas canales. Se
pueden tener hasta 32.385 dispositivos en un dominio. Ocupa 6 bytes.
ID de subred (subnet ID): abarca hasta 127 dispositivos en un canal o canales
conectados por repetidores (mismo enlace de datos). Se utilizan para soportar en-
caminamiento eficiente en redes grandes. Puede haber un maximo de 255 subredes
dentro de un dominio.
ID dispositivo (node ID): identifica al dispositivo en la subred.
3. Direcci on de grupo: coleccion logica de dispositivos en un dominio (no importa su

situacion fsica). Se pueden agrupar hasta 63 nodos. No puede haber mas de 256 grupos
en un dominio.
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 n umero maximo de dispositivos o se
quieren separar para que no puedan interoperar.
Figura 26: Dominio LonTalk
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 u
nica 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.

Dom
otica
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 tama no maximo del campo de datos es
de 228 bytes.
Figura 27: Trama de LonWorks
El proceso de instalacion de una red Lonwork se realizara en tres fases:

1. Direccionamiento. Cada nodo tiene un identificador (ID number) de 48 bits que viene
de fabrica. Se conecta un ordenador personal con el software de control de la red a traves
del puerto serie, y con el se obtiene este identificador mediante la pulsacion del boton
de servicio del nodo. Una vez configurado este n umero, el programa le proporciona
una nueva direccion de red (dominio + subred + nodo), que queda almacenada en su
memoria RAM.
2. Establecimiento l ogico de relacion entre nodos. Con este proceso se asigna a cada
nodo la direccion o direcciones a las que va a mandar sus mensajes.
3. Configuraci on de cada uno de los nodos, con lo que se completa la instalacion logica
de estos. Cada nodo suele tener un conjunto de parametros que han de ser configurados
por el instalador, como por ejemplo, velocidad de la transmision, margenes de alarma,
etc. En la Figura 13 se muestra un esquema de conexionado tpico de una instalacion
Lonworks.
Figura 28: Instalacion LonWork

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 u nicamente 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 se nales de clase 1 (se
nales de control),
algunos distribuyen ademas se nales de clase 2 (voz/datos baja velocidad) e incluso senales de
clase 3 (audio/video/datos alta velocidad).
Figura 29: Caractersticas de los medios de transmision en EHS
En EHS se pueden implementar tantas aplicaciones como dispositivos y funcionalidades se

encuentren en un hogar. Cada dispositivo esta asociado a una determinada area de aplicacion,
dentro de la cual el elemento es un objeto. Para definir cada objeto se utilizan dos bytes,
uno para el area (application area), y otro para el dispositivo (device descriptor ). Existen
diversas areas de aplicacion: telecomunicaciones, audio/vdeo, electrodomesticos, calefaccion,
iluminacion, etc.
Los dispositivos EHS pueden ser de seis tipos:
1. Dispositivos simples (SD: simple devices). Tienen funcionalidad autonoma propia,
pero no son capaces de gestionar autonomamente la integracion en un sistema (p.e.
actuadores on/off, etc.).

Dom
otica
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 n
umero
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:
Un FC difunde su peticion de descriptores de dispositivo (DD) a todos los CoD. Este

mensaje utiliza una direccion de grupo predeterminada para alcanzar a todos los CoDs.
Los CoD reciben el mensaje junto con informacion adicional que les permite conocer la
direccion de su FC. Los CoDs envan entonces su DD al FC, usando su propia direccion.

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.
El FC y el CoD quedan ya enrolados y cada uno almacena la direccion individual del

otro dispositivo.
Por u
ltimo, la estructura de la trama EHS se compone de los siguientes campos:
Figura 30: Tramas EHS
Pre
ambulo: 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.
Direcci
on vivienda: Permite discriminar si una trama viene de otra casa.
C
odigo de prioridad: Para definir el nivel de prioridad del mensaje.
Direcciones: Origen y destino de los dispositivos.
Datos: Datos u tiles 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.

Dom
otica
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 u nica 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 u nico 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 se nal 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. Sistema EIB
V.1. Introducci
on
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 n
umero 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 compa nas (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.

Dom
otica
EIB.RF: Radiofrecuencia: usando varias portadoras, se consiguen distancias de hasta

300 metros en campo abierto. Para mayores distancias o edificios con m
ultiples estancias
se pueden usar repetidores.
EIB.IR: Infrarrojo: para el uso con mandos a distancia en salas o salones donde se
pretenda controlar los dispositivos EIB instalados.
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 u ltimo, esta previsto el
desarrollo de dispositivos por radiofrecuencia, tema del que trata nuestro proyecto.
Figura 31: Bus EIB
Al igual que otros sistemas domoticos, EIB permite la integracion de las funciones basicas
requeridas en viviendas y edificios:
Gesti
on de la energa, para la optimizacion del consumo electrico y en climatizacion
(modos de tarificacion nocturna, prevencion de situaciones de consumo innecesario,
como corte de la calefaccion con las ventanas abiertas, etc.).
Seguridad, tanto en lo referente a la seguridad de las personas (alarmas de incen-
dio, inundacion, humos, etc.), como proteccion contra robos (simulacion de presencia,
deteccion de intrusos, etc.).
Confort. El empleo de un sistema integrado de comunicaciones permite disponer de
comodidades como el control por mando a distancia, programacion de escenas y au-
tomatizacion de tareas como las subida/bajada de persianas.
Comunicaci on. Es posible la conexion con el sistema a distancia, de forma que se
pueda modificar y conocer el estado de funcionamiento de la instalacion. En este campo
esta produciendose una verdadera revolucion en los u ltimos anos, y muchos de los
fabricantes de dispositivos estan comercializando componentes que permite el control
mediante las ultimas tecnologas, entre ellas el control por Internet y mediante telefonos
moviles (SMS, WAP, 3G).
Ademas, EIB presenta las ventajas inherentes a este tipo de sistemas frente a las instala-
ciones tradicionales:
Reduccion del cableado y los costes asociados a la instalacion.

Integracion de diferentes funciones en un solo sistema.
Flexibilidad para ampliaciones y modificaciones futuras. Es posible reprogramar el fun-
cionamiento de la instalacion conectando un ordenador al sistema o incluso a distancia
mediante un enlace telefonico o a traves de Internet.

V Sistema EIB
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: m odulos
de alimentaci on de la red, acopladores de lnea para interconectar diferentes segmentos
de red, y elementos sensores y actuadores.
Figura 32: Esquema general de una instalacion EIB
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.).
Superposici
on de datos / alimentaci
on
Los datos se transmiten como una tension alterna superpuesta sobre la alimentacion en
corriente continua del bus, empleando para ello u nicamente dos hilos. Para ello es necesario,
por una parte, aislar la fuente de alimentacion de los datos, para que esta no suponga una
carga sobre ellos, y por otra, desacoplar los datos de la componente de alimentacion continua
en cada dispositivo.
Cada lnea tiene su propia fuente de alimentacion que suministra la tension a todos los
dispositivos conectados. La fuente dispone de control integrado de corriente y tension y salva
microcortes de hasta 100 us. La tension nominal de alimentacion es de 29V, y cada dispositivo
requiere un mnimo de 21V para mantenerse en zona de operacion segura (SOA), y supone
una carga tpica de 150mW en el bus (en caso de carga adicional, hasta 200mW).
De este modo se aseguran unos margenes de tension y consumo que garanticen un fun-
cionamiento adecuado incluso utilizando el maximo n umero de dispositivos posible en la
instalacion.
La conexion de la fuente de alimentacion al bus se realiza a traves de una bobina de filtro,
de modo que la etapa de filtrado de alimentacion suponga una carga despreciable sobre la
componente de datos y no los interfiera.

Dom
otica
Figura 33: Conexion de alimentacion y dispositivos al bus
Caractersticas de la transmisi
on
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.
Figura 34: Generacion de corriente portadora sobre tension de alimentacion

V Sistema EIB
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.
Figura 35: Distintas topologas de EIB
La topologa de conexion de dispositivos contempla tres niveles de conexionado:
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).
Un
area, que se constituye acoplando hasta 15 lneas en la lnea principal. De este
modo, en un area se pueden conectar hasta 960 dispositivos.
Cada lnea, tanto la principal como las secundarias, deben tener su propia fuente de
alimentacion. Ademas, la lnea principal puede tener conectados directamente hasta 64
dispositivos (incluyendo los acopladores de lnea).
Figura 36: Sistema completo EIB

Dom
otica
Un sistema completo, formado por la union de hasta un total de 15 areas distintas

mediante los denominados Acopladores de Area (AA), que permitira integrar hasta un
maximo de 14.400 dispositivos.
Ademas, mediante pasarelas pueden interconectarse distintos sistemas completos, lo que

se suelen llamar mundos eib, consiguiendo de este modo que el n
umero de componentes y las
posibilidades sean ilimitadas.
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).
Figura 37: Direccion fsica
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 siguiente figura se muestra un ejemplo de direcciones fsicas asignadas a los dispositivos

de un sistema EIB:
Figura 38: Ejemplo de direccionamiento fsico

V Sistema EIB
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 act ua 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.
Figura 39: Niveles en las direcciones de grupo
Habitualmente el campo de grupo principal se utiliza para englobar grupos de funciones

(alarmas, iluminacion, control de persianas, etc.). Se pueden emplear valores de 1 a 13, los
valores 14 y 15 no deben emplearse, ya que no son filtrados por los acopladores y podran
afectar a la dinamica de funcionamiento de todo el sistema. En todos los campos la direccion
0 esta reservada para funciones del sistema.
En la configuracion de una instalacion EIB, la asignacion de direcciones de grupo es basica
para asegurar su correcto funcionamiento. Las direcciones de grupo, que asocian sensores con
actuadores, se pueden asignar a cualquier dispositivo en cualquier lnea (son independientes
de las direcciones fsicas), con las siguientes condiciones:
1. Los sensores solo pueden enviar una direccion de grupo (solo se les puede asociar una
direccion de grupo).
2. Varios actuadores pueden tener la misma direccion de grupo, es decir, responden a un

mismo mensaje o telegrama.
3. Los actuadores pueden responder a mas de una direccion de grupo (pueden estar direc-
cionados o asociados a varios sensores simultaneamente).

Dom
otica
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 n umero de dispositivo.
Figura 40: Ejemplo de asignacion de direcciones de grupo
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 dise
nador, teniendo en cuenta las restricciones descritas en este captulo.
De este modo, se comienza asignando una direccion de grupo u nica 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.

V Sistema EIB
V.5. Formato de las transmisiones

M
etodo de acceso al medio
El metodo de acceso al medio empleado en EIB es de tipo CSMA/CA (Carrier Sense
Multiple Access/Collision Avoidance): Acceso m ultiple por deteccion de portadora, evitando
colisiones.
La codificacion se realiza de modo que el estado logico 0 es dominante (impulso simetrico)
sobre el 1, que se denomina recesivo (no hay impulso).
El mecanismo de resolucion de colisiones es el siguiente:
El dispositivo comprueba el bus, y si esta libre comienza la transmision.
Durante el envo cada dispositivo escucha los datos presentes en el bus, comparandolos
en todo momento con los que ha transmitido.
Si no se producen colisiones, el envo se completa sin contratiempos.
Si, por el contrario, se produce una colision con los datos enviados por otro equipo, el
arbitraje se resuelve por prioridad de los bits dominantes sobre los recesivos.
Por lo tanto, tendran mayor prioridad aquellas tramas que presenten un mayor n
umero
de ceros en su inicio.
Figura 41: Resolucion de colisiones CSMA/CD en EIB
Formato de los mensajes: el telegrama

El envo de un mensaje o telegrama en un sistema EIB se realiza cuando se produce un
evento, p.e. la activacion de un pulsador o la deteccion de presencia.
La transmision se inicia despues de que el bus haya permanecido desocupado por lo menos
durante un periodo de 50 bits, y despues de la transmision los componentes utilizan otro tipo
de 13 bits para comprobar si el telegrama se ha recibido correctamente. Todos los compo-
nentes direccionados envan un acuse de recibo.
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.

Dom
otica
En siguiente figura se muestra el formato de la trama y el tama

no de cada uno de estos
campos.
Figura 42: Formato de la trama EIB
Los campos son los siguientes:

Control.
Este campo de 8 bits incluye la prioridad que dicho telegrama tiene al ser enviado
seg
un el tipo de funcion (alarma, servicios del sistema o servicios habituales). El bit de
repeticion se pone a cero en caso de repetirse alg
un envo a causa del no reconocimiento
de alguno de los destinatarios. De este modo se evita que los mecanismos que ya han
ejecutado la orden la vuelvan a repetir.
A continuacion mostramos los bits de control y los tipos de prioridad:
Figura 43: Formato del campo de control
Direcci
on 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.
Direcci
on 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 u nicamente 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).
Figura 44: Formato del campo de direccion destino

V Sistema EIB
Longitud e informaci
on u
til.
Contiene los datos necesarios para la ejecucion de ordenes y transmision de valores. En
los cuatro bits de longitud se indica cuantos bytes contiene el campo de datos.
El campo de datos u
tiles contiene el tipo de comando (solo hay cuatro) y los datos, de
acuerdo con el EIB Interworking Standard (EIS).
En la figura siguiente podemos ver la estructura que toma la trama y los tipos de comandos
existentes:
Figura 45: Formato del campo de datos
No EIS Funcion EIB No bytes Descripcion

EIS1 Conmutacion (switching) 1 bit Encendido/apagado, habilitar/deshabilitar,
alarma/no alarma, verdadero/falso
EIS2 Regulacion (dimming) 4 bit Se puede utilizar de 3 formas distintas:
como interruptor, como valor relativo
y como valor absoluto.
EIS3 Hora (time) 3 bytes Da de la semana, hora, minutos y segundos.
EIS4 Fecha (date) 3 bytes Da/mes/a no (el margen es de 1990 a 2089).
EIS5 Valor (value) 2 bytes Para enviar valores fsicos con representaci
on
S,EEEE,MMMMMMMMMMM
EIS6 Escala (scaling) 8 bit Se utiliza para transmitir valores relativos
con una resolucion de 8 bit.
EIS7 Control motores (control drive) 1 bit Tiene dos usos: Mover, arriba/abajo o
extender/retraer y Paso a Paso.
EIS8 Prioridad (priority) 1 bit Se utiliza en conjuncion con EIS 1 o EIS 7.
EIS9 Coma flotante (float value) 4 bytes Codifica un numero en coma flotante seg un
el formato definido por el IEEE 754.
EIS10 Contador 16 bit (16b-counter) 2 bytes Representa los valores de un contador
de 16 bit (tanto con signo como sin signo).
EIS11 Contador 32 bit (32b-counter) 4 bytes Representa los valores de un contador
EIS12 Acceso (access) 4 bytes Se usa para conceder accesos a distintas funciones.
EIS13 Caracter ASCII (Character) 8 bit Codifica segun el formato ASCII
EIS14 Contador 8 bit (8b-counter) 8 bit Representa los valores de un contador
EIS15 Cadena (Character String) 14 bytes Transmite un cadena de caracteres ASCII
de hasta 14 bytes.
Tabla I.1: Tipos EIS normalizados

Dom
otica
El EIS contiene los datos u tiles para cada funcion asignada a los objetos de comunicacion.
Seg un 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 comunicaci on 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 u nica
direccion fsica, contiene varios sensores o varios actuadores, cuyo funcionamiento logico es
independiente.
Campo de comprobaci
on.
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 comprobaci
on cruzada.
Figura 46: Campo de comprobacion de la trama

V Sistema EIB
V.6. Componentes EIB

En este apartado analizaremos los componentes EIB, viendo de que partes se componen
fsicamente. Haremos una revision no muy exhaustiva pero que nos servira para ver similitudes
con respecto a los dispositivos y componentes con los que trabajaremos en nuestro proyecto.
Al margen de los elementos auxiliares para posibilitar el funcionamiento de un sistema
EIB, como son la fuente de alimentacion, filtros y cables, los elementos mas importantes en
la instalacion son los dispositivos dotados de una cierta inteligencia.
Al tratarse de un sistema distribuido, las funciones a realizar se encuentran programadas
en forma de objetos de aplicacion en los sensores y actuadores que intercambian informacion,
posibilitando as la realizacion de las acciones de control.
Estos dispositivos constan de tres partes basicas:
1. Acoplador al bus (AB), donde se encuentra el programa de aplicacion.
2. Interfaz de aplicacion (IA).
3. Dispositivo final (DF).
Figura 47: Componentes de un dispostivo EIB
El acoplador al bus (AB o BCU) es un aparato universal, que contiene la electronica

necesaria para gestionar el enlace: envo y recepcion de telegramas, ejecucion de los objetos de
aplicacion, filtrado de direcciones fsicas y de grupo para reconocer los telegramas destinados
al dispositivo, comprobacion de errores, envo de reconocimientos, etc.
El acoplador examina cclicamente la interfaz de aplicacion para detectar cambios de
se
nal. Esta unidad de acoplamiento consta de dos partes:
Un modulo de transmision (MT), que realiza, entre otras, funciones de proteccion,

desacoplos, control de las tensiones, vigilancia de la temperatura de la unidad, etc.
El controlador del enlace al bus (CEB), que contiene:
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.

Dom
otica
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 aplicaci on 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.
Existen dos tipo de componentes EIB dependiendo del modo de instalacion:
Componentes de carril DIN, con el mismo formato que las protecciones eclecticas (in-
terruptores automaticos o diferenciales).
Componentes de empotrar, para su instalacion en cajas universales de empotrar, falso

techo o cajas de empalme.
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.
Ademas, un componente EIB puede disponer de diversas lnea de entrada-salida, de tipo

digital o analogico, con las que realizar diversas funciones (p.e. un actuador puede tener
cuatro salidas binarias que controla de manera independiente).
Para ello, cada programa de aplicacion tiene definidos una serie de objetos (objetos de
comunicaci on) que se asocian a cada una de dichas funciones. Cada objeto se comporta,
a efectos de funcionamiento, como un dispositivo independiente, y tendra asignadas la o las
direcciones de grupo que lo asocian con otros componentes de la instalacion.
Para complicar un poco mas las cosas, un dispositivo puede tener varios objetos de comu-
nicacion asociados a una entrada o salida fsica; por ejemplo, un pulsador puede distinguir
entre una pulsacion corta (de duracion inferior a 0,5 segundos) y una larga, de duracion
superior. Cada uno de estos eventos puede tener asociado a su vez un objeto de comuni-
cacion diferente para, en el caso del pulsador, enviar telegramas de conmutacion o regulacion
respectivamente (tipos EIS 1 y 2).
Cuando se asocia una misma direccion de grupo a varios objetos, estos deben tener obli-
gatoriamente el mismo tipo EIS, de lo contrario no se podra llevar a cabo la comunicacion.
Figura 48: Componentes y objetos de comunicacion en ETS

V Sistema EIB
V.7. Ventajas de EIB. Ejemplos de aplicaci

on
Una vez que hemos desarrollado la composicion y funcionamiento del sistema, podemos
hacer un breve resumen de las ventajas que conlleva la eleccion de esta tecnologa. Las
principales ventajas seran las siguientes:
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
u
nica lnea comun. Con esto se puede dirigir la lnea de energa sin desvos, directa-
mente hasta el aparato consumidor.
Ademas del ahorro en el cableado se presentan adicionalmente otras ventajas: La

instalacion en un edificio se puede realizar de un modo mas sencillo desde el principio,
y despues se puede ampliar y modificar sin problemas (flexibilidad).
Adaptacion simple de la instalacion electrica a los requerimientos de cambio del

usuario.
Ante cambios de uso o reorganizacion del espacio, el EIB consigue una adaptacion rapida
y sin problemas, mediante una facil ordenacion (cambio de parametrizacion) de los com-
ponentes del bus, sin necesidad de un nuevo cableado. Este cambio de parametrizacion
se realiza con un PC, conectado al sistema EIB, que tenga instalado el software ETS
(EIB Tool Software) para proyecto y puesta en servicio, que ya se emplea en la primera
puesta en marcha.
Las instalaciones EIB pueden ser facilmente realizadas por cualquier instalador EIB es-
pecializado debido a que existe una u
nica herramienta informatica de dise no de proyec-
to, puesta en marcha y mantenimiento llamada ETS (Herramienta Software EIB). Es-
ta herramienta no requiere conocimiento alguno de programacion. Cualquier instal-
ador/disenador que haya sido instruido de acuerdo con las pautas de EIBA puede usar
el logo EIB partner y formar parte de la lista de partners repartidos por todo el mundo.
Uso economico y racional de la energa en el funcionamiento de edificios.

El EIB se puede conectar mediante las correspondientes interfaces con los centros de
control de otros sistema de automatizacion de edificios o con una red digital de servicios
integrados (RDSI). De este modo el uso del EIB en una vivienda unifamiliar resulta
tan rentable como en hoteles, escuelas, bancos, oficinas o edificios del sector terciario.
Incremento en la seguridad, debido a la tecnologa que emplea, los metodos de acceso,

las comprobaciones de seguridad, etc.
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 eval uan de distinta forma seg un 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.

Dom
otica
A continuacion, exponemos una serie de ejemplos de aplicacion que pueden conseguirse

con la tecnologa EIB, de manera que pueda verse de una forma mas practica las ventajas
comentadas.
Ejemplo 1: Implementacion de funciones centrales: cuando usted esta dejando el edificio,

todas las luces, el suministro de agua y enchufes especficos (horno electrico, etc.) pueden
apagarse, el sistema de alarma EIB puede activarse y las persianas pueden controlarse
de distinta forma en funcion de la hora del da.
Ejemplo 2: En salas de conferencias, teatros, as como en cuartos de estar, es posible activar

diferentes escenas de iluminacion que, en funcion de la actividad, pueden ser modificadas
por el usuario en cualquier momento. Por ejemplo en edificios administrativos, es posible
lograr una energa que ahorre hasta un 75 % de la iluminacion llevando a cabo un control
de luz constante, con un solo sensor de luminosidad para cada lado del edificio.
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 se nales de alarma automaticamente al n umero
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 ni
nos y el ba
no pueden ser activadas
apretando un boton y pueden ser desactivadas despues de un periodo fijo.
Ejemplo 7: El EIB puede proporcionar un control individual de la calefaccion y ventilacion

de cada cuarto mediante el establecimiento de perfiles de temperatura individuales.
Las entradas de fro o calor en cada cuarto se ajustan automaticamente cuando una
ventana se abre. Estas medidas hacen posible alcanzar un ahorro de energa de mas
de un 30 % al ano. La generacion de calor tambien puede controlarse en funcion de
las necesidades de calor de cada cuarto individual (el calor solo se produce cuando
realmente se requiere).
Ejemplo 8: El EIB tambien puede realizar una simulacion de presencia cuando el usuario
este ausente.

VI Est
andar Konnex
VI. Est
andar Konnex
Como ultimo punto, debemos hacer mencion a un hito importante en lo que a la historia
de la domotica europea se refiere: la creacion de la asociacion Konnex.
La Konnex Association, con sede en Bruselas, fue fundada en 1999 por iniciativa de tres
asociaciones europeas:
1. EIBA, (European Installation Bus Association).
2. Batibus Club International.
3. EHSA (European Home Systems Association).
Se unieron con el objeto de crear un u nico 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.
Figura 49: Konnex
Los objetivos de Konnex Asocciation son los siguientes:
Definicion de est
andares de comprobaci on y normas de calidad mediante grupos
de trabajo y expertos (Especialistas KNX).
Hotline de asistencia t
ecnica para fabricantes que desarrollen soluciones compatibles
con el KNX.
Concesion de la marca KNX en base a las especificaciones mediante certificacion KNX.
Actividades de estandarizaci
on a nivel nacional e internacional.
Fomento de actividades formativas mediante la certificacion en Centros de Forma-

cion.
Actividades promocionales: paginas web, ferias, folletos, etc.
Fomento de la creacion de grupos nacionales.
Scientific Partnership o colaboraci

on cientfica para centros docentes tecnicos y
universidades.
Especificacion, promocion y certificacion de los antiguos sistemas.

Dom
otica
Actualmente la asociacion Konnex dispone de las especificaciones del nuevo estandar, el

cual es compatible con los productos EIB instalados.
Se puede afirmar que el nuevo estandar tiene lo mejor del EIB, del EHS y del Batibus y
que aumenta considerablemente la oferta de productos para el mercado residencial el cual ha
sido, hasta la fecha, la asignatura pendiente de este tipo de tecnologas.
El estandar contempla tres modos de funcionamiento:
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
dise
nada para este proposito, el ETS.
Este metodo es idoneo para proyectistas e instaladores KNX certificados y, sobre todo,
para grandes instalaciones.
2. E-mode (Easy mode): en la configuracion sencilla los dispositivos son programados

en fabrica para realizar una funcion concreta. A un as deben ser configurados algunos
detalles en la instalacion, ya sea con el uso de un controlador central (como una pasarela
residencial o similar) o mediante unos microinterruptores alojados en el mismo dispo-
sitivo, ruedas de codificacion o teclas (similar a muchos dispositivos X-10 que hay en el
mercado).
Los productos compatibles con el E-mode normalmente tienen una funcionalidad limi-
tada y estan concebidos para instalaciones de tama
no medio.
3. A-mode(Automatic mode): en la configuracion automatica, con una filosofa Plug&Play

ni el instalador ni el usuario final tienen que configurar el dispositivo. Este modo esta es-
pecialmente indicado para ser usado en electrodomesticos, equipos de entretenimiento
(consolas, set-top boxes, HiFi, ...) y proveedores de servicios, y es ideal para el usuario
final y para instalaciones peque nas.
La Konnex Association se compona en un principio de nueve miembros, y a finales de

2003 el n umero de miembros superaba los 100, incluyendo empresas que anteriormente no
pertenecan a ninguna de las asociaciones existentes.
Dichas empresas reprentan mas del 80 % del mercado europeo de las instalaciones y los
electrodomesticos. No solo empresas desarrolladoras y fabricantes de productos pueden aso-
ciarse, sino tambien prestadoras de servicios (suministros de energa, etc.) u otras interesadas.
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.
El exito de Konnex en cifras:
Mas de 6.500 productos KNX registrados y certificados.
Mas de 100 miembros KNX.
Mas de 90 centros de formacion reconocidos.
Mas de 6 centros de test europeos.
Mas de 50.000 proyectos llevados a cabo.
Mas de 10 millones de productos de KNX instalados.

VI Est
andar Konnex
VI.1. Ejemplo Proyecto KNX/EIB
Terminal 5 de Heathrow - Londres
El aeropuerto mas innovador del mundo
Figura 50: Terminal 5 de Heathrow
La terminal 5 es el proyecto domotico de construccion mas grande jamas hecho en el Reino

Unido, extendiendose varios kilometros. Esta nueva expansion del aeropuerto fue llevada a
cabo por la Autoridad de Aeropuertos Britanica (BAA) y hara que Heathrow sea uno de los
mas grandes y probablemente mas innovadores aeropuertos del mundo.
El proyecto incluye dos salas principales, un centro de energa, areas de parking, t uneles
de servicio, una red de tren, areas VIP, una torre de control del aeropuerto y varias areas mas.
Caractersticas novedosas
Control de 64000 luces a traves de Pasarelas KNX-DALI.
Control de mas de 910 lneas KNX mediante 236 Pasarelas KNX-IP y una red de area
local.
Integracion de luces de emergencia en la misma red KNX-DALI.
Mensajes de error y defectos de luz enviados al sistema de control.
Integracion de sistemas adicionales a KNX, p.ej. mensajes de error de los ascensores.
Monitorizacion y control de todos los subsistemas desde un sistema de administracion.

Dom
otica

Parte II

ambricas

ambricas
I. Introducci
on
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 Inal ambricas (Wireless Sensor Networks, WSN ) consisten
en un conjunto de nodos de peque no tama no, 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 u ltimamente han surgido una serie de dispositivos que integran
un procesador, una peque na 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.
Figura 1: Red de sensores inalambrica
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 u ltimos son inteligentes, es decir, capaces de poner
en marcha una accion seg un la informacion que vayan acumulando, y no estan limitados

ambricas
geograficamente por un cable fijo.

Los nuevos avances en la fabricacion de microchips de radio, nuevas formas de routers y
nuevos programas informaticos relacionados con redes estan logrando eliminar los cables de
las redes de sensores, multiplicando as su potencial.
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 tama no 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 tama no.
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 redise no 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 u
ltimos 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 ac usticos 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

I Introducci
on
papel activo en las campa

nas de guerra.
A partir de 1980, la DARPA comienza un programa focalizado en sensores denominado

DSN (Distributed Sensor Networks), gracias a el se crearon sistemas operativos (Accent) y
lenguajes de programacion (SPLICE) orientados de forma especfica a las redes de sensores,
esto ha dado lugar a nuevos sistemas militares como CEC (Cooperative Engadgement Ca-
pability) consistente en un grupo de radares que comparten toda su informacion obteniendo
finalmente un mapa com un con una mayor exactitud.
Estas primeras redes de sensores tan solo destacaban por sus fines militares, a
un no satis-
facan algunos requisitos de gran importancia en este tipo de redes tales como la autonoma
y el tama no. Entrados en la decada de los 90, una vez mas DARPA lanza un nuevo programa
enfocado hacia redes de sensores llamado SensIt, su objetivo viene a mejorar aspectos rela-
cionados con la velocidad de adaptacion de los sensores en ambientes cambiantes y en como
hacer que la informacion que recogen los sensores sea fiable.
Ha sido a finales de los a nos 90 y principios de nuestro siglo cuando los sensores han
empezado a coger una mayor relevancia en el ambito civil, decreciendo en tama no e incre-
mentando su autonoma. Compa nas como Crossbow han desarrollado nodos sensores del
tama no 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 compa na llamada Dust Inc, compuesta
por miembros del proyecto Smart Dust ubicado en Berkeley, que ha creado nodos de un
tama no inferior al de un guisante y que, debido a su min
usculo tama no, podran ser creadas
multiples nuevas aplicaciones.
Figura 2: Tama
no de los nodos Smart Dust

ambricas
II. Caractersticas de las WSN

Los recientes avances en microelectronica, wireless y electronica digital han permitido el
desarrollo de nodos sensores de bajo coste, reducido tama no, bajo consumo y que se comu-
nican de forma inalambrica.
El desarrollo de estos nodos sensores ha dado la posibilidad de crear redes basadas en
cooperaci
on de los nodos, con una notable mejora sobre redes de sensores tradicionales, que
se suelen desplegar de dos modos:
Sensores que se encuentran lejos del fenomeno, grandes y muy complejos para distinguir
el objetivo del ruido del entorno.
Muchos sensores con posicion y topologa cuidadosamente seleccionada. Transmiten
datos de adquisicion a nodos centrales que realizan la computacion.
Como ya hemos comentado, las WSN se componen de miles de dispositivos peque nos,
autonomos, distribuidos geograficamente, llamados nodos sensores con capacidad de computo,
almacenamiento y comunicacion en una red conectada sin cables, e instalados alrededor de
un fenomeno objeto para monitorizarlo.
Una vez se produzcan eventos, toma de medidas o cualquier actividad programada con
el fenomeno en cuestion los nodos enviaran informacion a traves de la red, hasta llegar a
un sistema central de control que recogera los datos y los evaluara, ejecutando las acciones
pertinentes en comunicacion con otros sistemas o en la propia red de sensores.
Figura 3: Elementos de una WSN
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
se
nales 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.

II Caractersticas de las WSN
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 com
un o sistema integrado.
5. Red inal
ambrica.
Tpicamente basada en el estandar 802.15.4 - ZigBee.
Caractersticas de una WSN

Aunque la naturaleza de los nodos que emplean las redes pueda ser muy distinta y la
mision a realizar pueda variar dependiendo del tipo de aplicacion, se pueden identificar una
serie de caractersticas comunes a todas ellas y que son las que principalmente las identifican:
Gran Escala.
La cantidad de nodos que se despliega en una red puede llegar hasta los miles, pudiendo
crecer su n
umero 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 dise
nada 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 peque no tama no 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.
Cooperaci
on de nodos sensores.
Realizan operaciones simples antes de transmitir los datos, lo que se denomina un
procesamiento parcial o local.
Comunicaci
on.
Los nodos sensores usan comunicacion por difusion y debido a que estan densamente
desplegados, los vecinos estan muy cerca unos de otros y la comunicaci on 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 aut
onomo.
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.

ambricas
Requisitos para una WSN

Para que una red pueda funcionar de acuerdo con las anteriores caractersticas surgen
una serie de retos que la aplicacion debe resolver. Estos, que se detallan a continuacion, son
los requisitos no funcionales del sistema:
Eficiencia energ
etica.
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 n
umero
de mensajes que generan y retransmiten los nodos.
Autoorganizaci
on.
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 n umero de nodos con que
inicialmente se contaba, sino que tambien debe permitir aumentar ese n umero sin que
las prestaciones de la red caigan drasticamente.
Tolerancia a fallos.
Los sensores son dispositivos propensos a fallar. Los fallos pueden deberse a m ultiples
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 dise

ne 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 peque no 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 dise
no 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.
II.1. Arquitecturas de las WSN

Tomando como elementos principales de la red a los nodos sensores, las pasarelas (gate-
way) y las estaciones base, podemos distinguir dos tipos principales de arquitecturas.
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.
Figura 4: Arquitectura WSN centralizada
Si tenemos en cuenta que el ciclo de vida de un nodo consiste en despertarse, medir,

transmitir y dormirse, y cada vez que transmita su mensaje ira a la pasarela, estaremos
creando dos grandes problemas para la red:
1. Cuello de botella en las pasarelas.
2. Mayor consumo de energa por las comunicaciones.
Como resultado, el tiempo de vida de la red sera relativamente corto.

ambricas
Arquitectura distribuida
Dada la naturaleza intrnseca de las redes de sensores, normalmente se tiende a este

tipo de arquitectura con una computacion distribuida. De hecho, como comentabamos en las
caractersticas principales de una WSN, son redes basadas en cooperaci on de los nodos.
Los nodos sensores se van a comunicar entre sus nodos vecinos y van a cooperar entre
ellos, ejecutando algoritmos distribuidos para obtener una u nica respuesta global que un
nodo (cluster head ) se encargara de comunicar a la estacion base a traves de las pasarelas
pertinentes.
Figura 5: Arquitectura WSN distribuida
De esta forma se evitan los problemas que surgan en la arquitectura centralizada y,

ademas, se mantienen las caractersticas y ventajas que comentamos al comienzo de este
captulo.
II.2. Protocolos de las WSN
Por qu
e son diferentes las WSN?
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 peque no 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 act ua
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:
1. Rutas con los nodos de mayor potencia a lo largo de la ruta.
2. Rutas que consuman la mnima energa.
3. Rutas con el mnimo n

umero de saltos.
4. Rutas en las que la mnima potencia disponible es la maxima entre todos los demas
caminos.

ambricas
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 aplicaci
on
Los nodos sensores tienen muchas aplicaciones distintas. Dise nar 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 u ltimas 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 com un 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 a
nos veremos los resultados
de los esfuerzos que se estan realizando en estas aplicaciones.
Figura 6: Niveles fsico, red y aplicacion

II.3. Zigbee, est

andar WSN
ZigBee es el estandar de la norma IEEE 802.15.4 que define el protocolo y la interconexion
de dispositivos con comunicacion va radio para redes de area personal inalambricas (WPAN)
patrocinado por la ZigBee Alliance.
La tecnologa esta dise
nada con el objetivo de ser mas simple y barata que otras WPANs
tales como Bluetooth, y esta apuntanto su uso al de aplicaciones de bajas tasas de datos y
bajo consumo de potencia.
El estandar usa CSMA/CA como acceso al medio, acceso m ultiple 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.
Figura 7: Comparativa estandares inalambricos
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 a nos.
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 dise
nado para mantener sesiones de voz de forma continuada, aunque pueden construirse
redes que cubran grandes superficies ya que cada ZigBee act ua de repetidor enviando la senal
al siguiente, etc.
En la siguiente grafica se puede ver claramente donde se ajusta cada estandar, en funcion

ambricas
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.
Figura 8: Espectro de estandares
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 peque
na 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 dise
nado 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 peque
nos paquetes de informacion,
bajo consumo, seguro y fiable.
Figura 9: Aplicaciones Zigbee

II.4. Problemas de las WSN

Es evidente que las tecnologas de redes de sensores nos ofrecen multitud de aplicaciones
y utilidades, como veremos en el apartado siguiente, pero tambien conllevan un importante
esfuerzo de produccion eficiente tanto hardware como software.
Las caractersticas que tienen este novedoso tipo de redes requieren, como hemos visto, de
protocolos y estrategias concretas a la hora de crearlas, tanto a nivel de red como a nivel de
componentes individuales, ya sean los sensores con sus limitaciones de potencia o procesador,
las pasarelas para enrutar de forma eficiente este tipo de redes o las estaciones base para
evaluar y ejecutar respuestas de forma adecuada ante los datos que van recibiendo.
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:
1. Optimizaci
on del consumo de energa en los nodos sensores.
Uno de los problemas mas importantes es el consumo de energa de los nodos. Para
lograr que este sea mnimo y, por tanto, conseguir un maximo tiempo de vida de la red
habra que tener en cuenta:
La comunicacion de mensajes es el primer consumidor de energa.

La CPU puede quedarse en un estado sleep de bajo consumo mientras no tenga
que procesar ni enviar nada.
Economizar la distancia de las comunicaciones.
Tecnicas de software: programacion eficiente de lneas de codigo.
2. Ancho de banda y cobertura de red limitados.

Se debe trabajar teniendo en cuenta que estas redes tienen una cobertura limitada,
dadas las caractersticas de sus componentes, y creando sistemas que se ajusten ade-
cuadamente.
3. Los recursos de computaci

on son limitados.
Los nodos tienen ciertas limitaciones tanto a nivel del procesador como la capacidad de
almacenamiento de la memoria. Dependiendo del tipo de sensor, hay diferencias, aunque
gracias a las u
ltimas novedades tecnologicas estas limitaciones se van reduciendo.
4. Soluciones ad-hoc para redes ad-hoc.

Como hemos visto en el captulo de protocolos, muchas de las soluciones ad-hoc no son
validas para este tipo de redes, debido a las diferencias existentes tanto en tecnologa
como en objetivos.
5. La topologa de red es muy din

amica.
Las WSN tienen como uno de sus objetivos crear redes moviles cuya topologa va
cambiando continuamente, redes caracterizadas por:
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.

ambricas
III. Aplicaciones de las WSN

La WSN puede consistir en muchos tipos diferentes de sensores, como pueden ser ssmicos,
magneticos, termicos, ac
usticos, radar, IR, etc. Los distintos tipos de sensores existentes
pueden monitorizar una gran variedad de condiciones ambientales, que incluyen:
Temperatura, humedad, presion.
Condiciones de luz, movimiento de vehculos, niveles de ruido.
Composicion del suelo.
Presencia o ausencia de cierto tipo de objetos.
Niveles de estres mecanico en objetos (maquinaria, estructuras, etc.).
Caractersticas de velocidad, direccion y tama

no de un objeto.
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).
Figura 10: Aplicaciones para WSN
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:
Monitorizaci
on del entorno.
Este tipo de aplicaciones se caracterizan por un gran n
umero de nodos sincronizados que
estaran midiendo y transmitiendo periodicamente en entornos puede que inaccesibles,
para detectar cambios y tendencias.
La topologa es estable y no se requieren datos en tiempo real, sino para analisis futuros.
Ejemplos: control de agricultura, microclimas, etc.

III Aplicaciones de las WSN
Monitorizaci
on 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.
Figura 11: Tracking de animales
Redes hbridas
Son aquellas en las que los escenarios de aplicacion re
unen aspectos de las tres categoras
anteriores.
El concepto de microsensores comunicados de forma inalambrica promete muchas nuevas

areas de aplicacion. De momento las vamos a clasificar en: militares, entorno, salud, hogar y
otras areas comerciales. Por supuesto es posible ampliar esta clasificacion.

ambricas
III.1. Aplicaciones militares

Las WSNs pueden ser parte integral de sistemas militares C4ISRT (command, control,
communications, computing, intelligence, surveillance, reconnaissance and targeting) que son
los que llevan las ordenes, el control, comunicaciones, procesamiento, inteligencia, vigilancia,
reconocimientos y objetivos militares.
El rapido y denso despliegue de las redes de sensores, su autoorganizacion y tolerancia a
fallos las hace una buena solucion para aplicaciones militares. Ofrecen una solucion de bajo
coste y fiable para estas ya que la perdida de un nodo no pone en riesgo el exito de las
operaciones.
Ejemplos de aplicacion en este area son:
Monitorizaci on de fuerzas aliadas, equipamiento y munici on. Cada equipo,

tropa, vehculo o arma crtica lleva integrado un sensor para informar de su estado
a lderes o niveles superiores. Se usan nodos recolectores donde se recopila toda la
informacion para luego transmitirla a niveles superiores.
Reconocimiento del terreno y fuerzas enemigas. Se pueden desplegar y obtener

informacion valiosa antes de que el enemigo los intercepte sobre rutas de acceso, posibles
caminos e incluso movimientos del enemigo.
Figura 12: Reconocimiento del enemigo
Adquisicion de blancos. Se pueden incorporar los nodos a sistemas de guiado de

armas inteligentes.
Valoraci
on de da
nos, antes o despues de los ataques.
Reconocimiento de ataques nucleares, biol ogicos y qumicos, desplegandolos en

la region y usandolos como sistema de aviso. Tambien para reconocimiento despues de
que ocurra sin tener que exponer a equipos de reconocimiento a radiaciones o agentes
qumicos.
Figura 13: Desplegue de sensores para reconocimientos

III.2. Aplicaciones medioambientales

En este campo tenemos aplicaciones como el seguimiento de aves, animales e insectos;
monitorizacion de condiciones ambientales que afectan al ganado y las cosechas; irrigacion;
macroinstrumentos para la monitorizacion planetaria de gran escala; deteccion qumica o
biologica; agricultura de precision (monitorizacion de niveles de pesticidas, polucion y erosion
del terreno); deteccion de incendios; investigacion meteorologica o geofsica; deteccion de
inundaciones; mapeado de la biocomplejidad del entorno; y estudios de la polucion.
Podemos destacar cuatro de estas aplicaciones:
Detecci
on de fuego en bosques.
Se podran desplegar millones de sensores de manera estrategica, aleatoria y densa
en el bosque que informaran del origen exacto de un incendio antes de que se haga
incontrolable. Los sensores podran tener metodos de obtencion de energa como placas
solares, ya que seran abandonados durante meses o a nos sin mantenimiento.
Ademas, debido a la densidad de su despliegue seran capaces de cooperar para realizar
una recoleccion de datos cooperativa y evitar obstaculos en las transmisiones, como
arboles y rocas que pueden bloquear la lnea de vision entre sensores.
Figura 14: Deteccion de incendios
Mapeado de la biocomplejidad del entorno medioambiental.

Requiere enfoques sofisticados para integrar informacion en escalas temporal y espacial.
Avances tecnologicos en sensorizacion remota y recoleccion de datos automatizada han
permitido una resolucion espacial, espectral y temporal con un coste por unidad de area
que se ha reducido en progresion geometrica. Ademas, la conexion de estos sistemas a
Internet permite a usuarios remotos controlar, monitorizar y observar la biocomplejidad
del medio ambiente.
Aunque los satelites y sensores aereos son u
tiles en la observacion a gran escala de la
biodiversidad (p.e. complejidad espacial de especies de plantas dominantes), no tienen
la precision suficiente como para observar la biodiversidad a peque na escala, que es la
parte mas importante en la biodiversidad de un ecosistema. Por ello, se necesita un
despliegue de nodos sensores para observar la biocomplejidad.
Ejemplo: Reserva James en el sur de California con tres redes de monitorizacion, cada
una con 25-100 sensores.
Detecci
on 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).

ambricas
Agricultura de precisi
on.
Beneficios obtenidos de monitorizar niveles de pesticidas en agua potable, niveles de
erosion del suelo y niveles de polucion del aire en tiempo real.
III.3. Aplicaciones sanitarias

Proveer interfaces para los discapacitados; monitorizacion integral de pacientes; diagnosti-
cos; administracion de medicamentos en hospitales; monitorizacion de los movimientos y pro-
cesos internos de insectos u otros pequenos animales; telemonitorizacion de datos fisiologicos
humanos; y seguimiento y monitorizacion de pacientes en un hospital.
Telemonitorizaci
on de datos fisiol
ogicos humanos.
Los datos recolectados se pueden almacenar durante perodos largos de tiempo, usa-
dos para exploracion medica. La WSN instalada puede monitorizar y detectar el com-
portamiento de personas mayores, como por ejemplo una cada. Los sensores, por su
reducido tama no, dan al usuario una mayor libertad de movimiento y permiten a los
medicos identificar antes sntomas predefinidos.
Ademas, permiten una mayor calidad de vida a los usuarios comparados con los centros
de tratamiento. En la facultad de medicina de Grenoble - Francia, se ha dise nado una
Vivienda Inteligente para la Salud para validar la viabilidad de dichos sistemas.
Seguimiento y monitorizaci
on de m
edicos y pacientes.
Cada paciente lleva un sensor peque no y ligero. Cada sensor tiene una tarea especfica,
por ejemplo monitorizar la presion arterial y la frecuencia cardaca. Los medicos tambien
llevan sensores, lo que permite a otros medicos localizarlos en el hospital.
Administraci
on de medicaci
on en hospitales.
Si colocamos un sensor en la medicacion se reduce el riesgo de errores, porque el paciente
tambien llevara un sensor que identifique sus alergias y medicacion requerida.
III.4. Aplicaciones del hogar: dom

otica
Esta aplicacion es la que mas nos interesa para nuestro proyecto, puesto que es precisa-
mente uno de los objetivo que andamos buscando: programar y configurar sensores para
adaptarlos a entornos del hogar, posibilitando aplicaciones que favorezcan los objetivos de la
domotica.
Figura 15: Aplicacion domotica

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 dise no 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.
III.5. Otras aplicaciones comerciales

Otras aplicaciones comerciales son la monitorizacion de la fatiga de materiales; tecla-
dos virtuales de edificios; gestion de inventario; monitorizacion de la calidad de productos;
construccion de oficinas inteligentes; control ambiental en edificios de oficinas; con-
trol de robots y guiado en entornos de fabricacion automatica; juguetes interactivos; museos
interactivos; control y automatizacion de procesos; monitorizacion de desastres; estructuras
inteligentes; maquinas de diagnostico; transporte; instrumentacion de fabricas; control lo-
cal de actuadores; deteccion y monitorizado de robo de coches; seguimiento y deteccion
de vehculos; e instrumentacion de camaras de procesado de semiconductores, maquinara
giratoria, t
uneles de viento y camaras anecoicas.
Algunas de estas aplicaciones que mas nos interesan para el proyecto son:
Control ambiental en edificios de oficinas.

Normalmente la calefaccion o el aire acondicionado se controla desde una central, por lo
que la temperatura dentro de la habitacion puede variar unos pocos grados debido a que
la distribucion de aire no esta uniformemente distribuida y el control es central. Se puede
desplegar una WSN para controlar el flujo de aire y la temperatura en diferentes partes
de la habitacion. Con esta tecnologa se reducira el consumo ahorrando dos cuatrillones
de BTUs (British Termal Unit), que supondra 55 mill de $ en US, reduciendo en 35
millones de toneladas las emisiones de dioxido de carbono.
Museos interactivos.
Para que los ni
nos 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).
Gesti
on de inventarios.
En el almacen, cada artculo lleva pegado un sensor, de modo que se puede conocer en
todo momento su localizacion y n umero de artculos por categora. Para dar de alta
nuevos artculos se les pega el sensor y se llevan al almacen.

ambricas
IV. Nodos sensores

Las redes de sensores inalambricas, como hemos visto, se componen de diversos elementos
formando el conjunto total de la red en s, como son las pasarelas, las estaciones base, la
tecnologa inalambrica, etc. Pero los principales elementos que crean y sobre los que se sus-
tentan estos novedosos sistemas son los nodos sensores. Todo gira entorno a estos nuevos
dispositivos, que constituyen la pieza central de las redes de sensores.
Por lo tanto, dedicaremos este apartado a examinar sus principales caractersticas y los
distintos sensores que estan apareciendo en el mercado, as como los que hemos utilizado en
nuestro proyecto para crear las redes de sensores.
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, tama no 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.
Figura 16: Nodos sensores
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.
2. Estan limitados en diferentes aspectos:
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.
3. Hacen un uso intensivo de la CPU para el procesamiento, y de la Radio para enviar y

recibir mensajes. De hecho, esta es una de las bases de esta tecnologa.

IV Nodos sensores
4. Los sensores son de bajo coste. (1$ en el 2005).
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.
6. Son autonomos y operan de forma independiente.
7. Se adaptan al entorno.
Por otro lado, podemos establecer una serie de factores que eval uan y catalogan los tipos
y caractersticas de los nodos sensores. Estos factores seran: Energa, flexibilidad, robustez,
seguridad, comunicacion, computacion, sincronizacion, tama no y coste.
Un nodo sensor esta formado por cuatro componentes basicos:
1. Unidad sensora. Sensores y conversores analogico-digitales que convierten las se

nales
analogicas en digitales para el microprocesador.
2. Procesador. Normalmente asociado a una peque na unidad de almacenamiento. Ges-

tiona los procesos que permiten al nodo sensor colaborar con otros para realizar las
tareas asignadas.
3. Transceptor. Conecta el nodo a la red, realizando las operaciones de tranmision y

recepcion de mensajes.
4. Alimentaci on. Uno de los componentes mas importantes, se obtiene a partir de bateras
aunque puede estar ayudado de un generador, como placas solares que obtienen energa
del entorno.
Todo esto tiene que caber en un modulo del tama

no de una caja de cerillas y, a veces, en
un tama
no de un centmetro c
ubico para poder suspenderlo en el aire.
Figura 17: Comparacion plataformas para nodos
Aunque cada vez hay procesadores mas peque nos y rapidos, las unidades de proce-
samiento y almacenamiento en los nodos son recursos escasos. Por ejemplo, Smart Dust mote

ambricas
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 peque nos 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. A un as, el dise
no 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 tama no. 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.
En algunas aplicaciones los nodos pueden llevar componentes adicionales: sistema de

localizacion (GPS), generador de energa y movilizador.
Muchas tareas requieren conocer la posicion porque los sensores se despliegan de manera
aleatoria y se dejan desatendidos. Ademas se necesita en muchos protocolos. A menudo, se
supone que los nodos tienen GPS con precision de menos de 5m. Equipar a todos los nodos
con GPS es inviable para WSNs, por ello, un enfoque alternativo es dotar a unos nodos con
GPS que ayudan a los demas a determinar su posicion.
Optimizaci
on del consumo de energa
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.
Un nodo sensor tiene tres estados de funcionamiento:
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.

IV Nodos sensores
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.
Figura 18: Estados de un nodo sensor
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.
Figura 19: Distribucion del consumo de energa

ambricas
V. Ejemplos de motes: Micas y Telos

En este apartado, vamos a describir un tipo de motes en concreto: los Micas y Telos, ya
que son los que han sido objeto de investigacion en nuestro proyecto. Realizaremos un breve
resumen de caractersticas y aplicaciones posibles de ambos tipos, viendo ventajas de cada
uno y la evolucion que han sufrido con los nuevos avances.
En los u
ltimos a
nos 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 a
nos despues, junto
con Intel Research Laboratory Berkeley, han dise nado nuevos motes, los MICA2 y los MI-
CA2DOT, que son los mas usados para investigacion en redes de sensores.
Figura 20: Estructura de red y motes
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 u
ltimas 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.

V Ejemplos de motes: Micas y Telos
Figura 21: Micaz
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.
Figura 22: Diagrama de bloques Micaz
En esta tabla vemos una comparativa de las caractersticas de los Micas:
Figura 23: Caractersticas tecnicas de Micas

ambricas
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:
Dise
nado especficamente para redes de sensores integradas.
Distintas frecuencias de transmision con amplio rango.
Mas de un a
no de batera mediante los modos sleep.
Soportan reprogramacion inalambrica a distancia.
Amplia variedad de placas de sensores compatibles: luz, temperatura, presion, acelera-

cion, ac
ustica, detectores magneticos, etc.
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.
Figura 24: Mica2
Los Mica2 se dividen en tres modelos dependiendo de su frecuencia de uso: MPR400

(915MHz), MPR410 (433MHz), y MPR420 (315MHz). En nuestros laboratorios disponemos
de varios de estos motes, concretamente los MPR400, que trabajan a 915MHz.
Estos motes usan el Chipcon CC1000, con radio modulada en FSK. Todos los modelos
usan un potente microcontrolador Atmega128L y una radio de frecuencia sintonizable en un
rango amplio. Tanto los MPR4x0 como los MPR5x0 son compatibles y pueden comunicarse
entre ellos.
Figura 25: Diagrama de bloques Mica2

Mica2Dot
Los Mica2Dot son un tipo de motes dise nados 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 tama no que poseen, tal y como podemos ver en las imagenes.
Figura 26: Mica2dot
Su correspondiente diagrama de bloques lo podemos ver a continuacion, apreciando que

los pines se han colocado de forma periferica:
Figura 27: Diagrama de bloques Mica2dot
Sensores para Micas
Las series de placas de sensores MTS o de aquisicion de datos MDA han sido dise nadas
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.

ambricas
Figura 28: Sensores MTS300
El modelo MTS310CA incluye tambien acelerometro y magnetometro. Con este tipo de

sensores la variedad de aplicaciones posibles aumenta, incluyendo deteccion de vehculos,
deteccion de sesmos de baja intensidad, movimiento, rangos ac
usticos, robotica, etc.
Figura 29: Tipos de sensores para Micas

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.
Figura 30: TelosB
Las caractersticas generales de los TelosB son:
Transmision RF de acuerdo con la norma IEEE 802.15.4/ZigBee.
Banda de frecuencias desde 2.4 a 2.4835 GHz, compatible con ISM.
Velocidad de transferencia de datos de 250kbps.
Antena integrada.
Figura 31: Diagrama de bloques TelosB
Micro-controlador MSP430 a 8MHz con 10kB de RAM.
Bajo consumo.
Flash externa de 1Mb para almacenamiento de datos.
Programacion y toma de datos va USB.

ambricas
Conjunto de sensores de luz, temperatura y humedad.
Soporta TinyOS para implementacion y comunicacion de redes.
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 a
nadir 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.

V.3. Resumen comparativo

Las diferentes plataformas de motes que hemos visto se diferencian en sus caractersticas
hardware lo que les proporciona distintas cualidades a unas de otras: mayor procesador,
frecuencias de transmision, velocidad de transmision de datos, consumo de energa, etc.
En la siguiente tabla podemos ver la evolucion que han sufrido los distintos prototipos
y, lo que es mas importante para nosotros, la comparacion con las prestaciones que tienen y
ofrecen los TelosB.
Figura 32: Evolucion de los motes
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.
Figura 33: Comparativa de tiempos y consumos

ambricas
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 se
nal radio, concretan a un 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
VI. TinyOS
Las redes de sensores inalambricas estan basadas en nodos de peque
no tama
no 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.
TinyOS (Tiny Micro-Threading Operating System) se trata de un peque no sistema ope-

rativo dirigido por eventos, que ha sido desarrollado por la Universidad de Berkeley y ofrece
un marco para el desarrollo de aplicaciones orientado a componentes.
Su lenguaje de programacion, nesC, es un extension de C que permite la definicion de
componentes y la interconexion de ellos. No tiene gestion de procesos, en su lugar tiene dos
hilos de ejecucion, uno destinado a la ejecucion de eventos y otro a la de tareas, entre los
cuales el cambio de contexto es muy rapido.
Es muy ligero y puede ser ejecutado en dispositivos con prestaciones limitadas pues, tanto
el espacio que ocupa en memoria flash, como la RAM que consume, son muy peque nos. Por
tanto, es ideal para el tipo de dispositivos como los motes.
La creacion de nuevos componentes hardware, tanto motes como placas de sensores, es

posible. Basta con crear un fichero de cabecera en el que se describa el conexionado del
hardware y la creacion de componentes software que, a traves de llamadas a las libreras C
del microcontrolador o a traves de macros, realicen la comunicacion con el hardware.
La gestion de potencia corre a cargo de TinyOS, que se encarga de desactivar los recursos
hardware que no estan siendo usados. Permite un modo de bajo consumo de potencia mientras
no se estan transmitiendo o recibiendo datos as como tambien establecer periodos en los
que, cclicamente, la radio se apaga. Se crean los estados de actividad o de latencia que
comentabamos anteriormente, y se gestionan los tiempos de paso de un estado a otro, tanto
de wakeup, como la vuelta al estado sleep.
En cuanto a las comunicaciones, permite tanto comunicacion broadcast a todos los nodos
como encaminamiento multi-salto. En este segundo caso la aplicacion es libre de elegir el
algoritmo de encaminamiento que desee pero siguiendo unas normas. Todos los algoritmos de
encaminamiento que se desarrollen, deben cumplir con una arquitectura de componentes que
define el sistema operativo para que las aplicaciones puedan facilmente cambiar el algoritmo
que usan por otro.
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 u
nico 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.

ambricas
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 u
ltima le hace requerir menos recursos para su ejecucion.
Tampoco proporciona conectividad con grandes infraestructuras de servicios como Inter-
net. Aunque esto u ltimo 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.
TinOS ha sido incorporado a decenas de plataformas y numerosas placas de sensores.

Una amplia comunidad lo utiliza en simulaciones para desarrollar y probar varios protocolos
y algoritmos. Hasta el momento, hay unas 10000 descargas y 500 grupos de investigacion
y compa nas estan usando TinyOS en los motes de Berkeley/Crossbow. Numerosos grupos
contribuyen activamente con el codigo en su sitio web sourceforge y trabajan juntos para
establecer servicios de red estandar, formados desde una base de experiencia directa y per-
feccionados a traves de analisis competitivos en un entorno abierto.
Proyectos TinyOS
Presentamos una serie de ejemplos de proyectos con TinyOS que se estan realizando
actualmente en la Universidad de Berkeley:
Calamari: Soluciones de localizacion para redes de sensores.
FPS: Un protocolo de red para programacion de la potencia de radio en WSN.
Great Duck Island: Nuestro objetivo es permitir a los investigadores de cualquier parte
del mundo dedicarse a la monitorizaci on no-intrusiva de la vida salvaje y sus habitantes.
Los motes sensores est an 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.
Mat
e: Maquinas virtuales de aplicacion especfica para redes TOS. Permiten la progra-
macion de motes mediante simples scripts.
PicoRadio: Redes inalambricas de muy bajo consumo.
SSIS: Sensores de deteccion de integridad estructural. Informan de la localizacion y da

nos
durante y despues de un terremoto.
TinyDB: Sistema de procesamiento de peticiones para la extraccion de informacion de una

red de sensores TinyOS.
XYZ On A Chip: Redes de sensores inalambricas integradas para el control de entornos

interiores en edificios.

VI TinyOS
VI.1. nesC
nesC es una extension del lenguaje de programacion C dise nado para plasmar los con-
ceptos de estructuracion y los modelos de ejecucion de TinyOS.
Los conceptos basicos que hay tras nesC son:
Separacion de construccion y composicion: los programas se hacen mediante compo-

nentes que son conectadospara formar los programas completos. Los componentes
tienen una concurrencia interna en forma de tareas. Los hilos de control pueden pasar
a un componente a traves de sus interfaces. Estos hilos pueden ser de ejecucion de tareas
o interrupciones hardware.
Las especificaciones del comportamiento de un componente se hacen por medio de

interfaces. Las interfaces pueden ser proporcionadas o usadas por los componentes.
Las interfaces proporcionadas son para representar la funcionalidad que el componente
proporciona al usuario, y las interfaces usadas representan la funcionalidad que el com-
ponente necesita para hacer su trabajo.
Las interfaces son bidireccionales: especifican un conjunto de funciones para ser imple-
mentadas por el proveedor de la interfaz (los m etodos) 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 dise
no robusto y
permitiendo un mejor analisis estatico de los programas.
nesC esta dise

nado 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.
Figura 34: Estructura de un componente

ambricas
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 m ultiples interfaces y m
ulti-
ples instancias de la misma interfaz.
Hay dos tipos de componentes en nesC: los modulos y las configuraciones. Los m odulos
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:
miaplicacion.nc Sera el fichero configuracion del componente. En su codigo con-

tendra dos apartados:
Configuraci
on. En general vaca, solo contendra algo si se pretende crear un com-
ponente no mediante su implementacion de codigo directa (en Module) sino en-
samblando otros componentes ya creados.
Implementaci
on. Aqu es donde se definen las conexiones que hay entre los dife-
rentes componentes que utilizan la aplicacion.
miaplicacionM.nc Sera el modulo del componente. En el se definen las interfaces

que se proporcionan y que se usan y, por supuesto, contiene la implementacion de la
aplicacion en s.
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:
Figura 35: Ficheros de una aplicacion

VI TinyOS
VI.2. Herramientas de TinyOS

Las herramientas que a continuacion se describen ayudan en la tarea del desarrollo de
una aplicacion pero no forman parte de la aplicacion que finalmente se encargara de recoger
informacion en los nodos. Estas herramientas pertenecen al entorno de desarrollo de TinyOS.
Otros entornos de desarrollo tienen sus propias herramientas de simulacion y visualizacion
de datos.
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.
TinyViz es la interfaz grafica de TOSSIM. Permite ver la topologa de la red aunque

la calidad de la imagen que ofrece no es buena. Soporta la adicion de plug-ins con nueva
funcionalidad. Un ejemplo es el mencionado anteriormente que permite forzar los valores que
toman los sensores.
Figura 36: TinyViz
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:
Descubrimiento y configuracion automatica de la red.
Visionado de la topologa de red.

ambricas
Almacenamiento y visualizacion de estadsticas de la red como rendimiento, calidad de

los enlaces, etc.
Herramienta grafica para el visionado de datos.
Figura 37: Surge View
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).
GME(Generic Modeling Environment) es entorno de modelado sobre el que se instala

GRATIS como un metamodelo de NesC.
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

VI TinyOS
la frecuencia de muestreo y el periodo de tiempo durante el que se tomaran muestras entre

otros parametros. Incluso es posible que TinyDB ajuste estos parametros para conseguir un
determinado tiempo de vida de los nodos.
Estas consultas, que son realizadas por una aplicacion ejecutada sobre un PC, provocan en
los nodos la lectura de datos. Cada vez que un dato consultado sea ledo, este se introducira en
un mensaje y se reenviara por la red de vuelta al PC que solicito el dato. Para ahorrar energa,
el numero de mensajes retransmitidos se reduce organizando los nodos en una estructura en
arbol en la que cada nodo solo se comunicara con su nodo padre y sus nodos hijo.
TinyDB esta implementado como un framework extensible. A traves de esta extensibilidad
se pretende que, en un futuro, se anadan nuevos eventos y atributos de los nodos y se pueda
invocar comandos para la realizacion de tareas de control y actuacion.
Figura 38: TinyDB
Bombilla / Mat
e
Mat e es la maquina virtual de TinyOS, Bombilla es el conjunto de componentes que
se sit
uan sobre el sistema operativo para ejecutar los scripts de Mate. El lenguaje en el que
se escriben estos scripts tiene un n
umero 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.

ambricas
VII. Futuro de las WSN

Las caractersticas de flexibilidad, movilidad, alta fidelidad en sensorizacion, bajo coste y
rapido despliegue de las WSN crean muchas nuevas areas de aplicacion interesantes para la
sensorizacion remota. En el futuro, este amplio rango de areas de aplicacion hara de las redes
de sensores una parte integral de nuestras vidas.
Sin embargo, la realizacion de las redes de sensores debe satisfacer las restricciones intro-
ducidas por factores como la tolerancia a fallos, escalabilidad, coste, hardware, cambios en la
topologa, entorno y consumo energetico. Puesto que estas restricciones son muy exigentes y
especficas de las redes de sensores, se requieren nuevas tecnicas para este tipo de redes.
En la actualidad hay muchos investigadores involucrados en el desarrollo de tecnologas

necesarias para las diferentes capas de la pila de protocolo de las redes de sensores. Ademas
de estos proyectos, se requiere mas trabajo en los problemas descritos y mas desarrollos para
solucionar los temas de investigacion abiertos que hemos estado viendo en este captulo.
Debemos tener en cuenta que estamos tratando con una tecnologa bastante reciente en
la que hay muchos dise nos pero pocos funcionan, no existe lo que se llama una killer ap-
plication que cree una nueva forma de mercado (como fue la tecnologa movil) y que el 99 %
de las redes son cableadas.
Si resumieramos los factores que estan actualmente impidendo el desarrollo deberamos

resaltar:
No existen tendencias claras de SO o plataformas harware.
Falta de estandares o protocolos comunes.
Limitacion de recursos: energa, capacidad de CPU, memoria.
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 computaci on: 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.

VII Futuro de las WSN
En la pelcula de Hollywood Twister, los meteorologos persiguen tornados para acoplarles

una barril con sensores en su camino que pudieran meterse en el corazon del tornado. Los
cientficos podan medir as el tornado desde dentro con la informacion que enviaban los
sensores.
El laboratorio nacional de tormentas graves (NSSL) informo de que la pelcula estaba
basada en un trabajo del Dr. Al Bedard que desarrollo un instrumento para observar tornados.
Era un barril dotado de sensores en su exterior para medir viento, presion y temperatura, y
llevaba unas bateras incorporadas. Lo que no tena muy en cuenta eran los inconvenientes
de seguridad como los objetos que podan chocar contra el barril.
Figura 39: Twister
Aunque la pelcula Twister exageraba la realidad en su momento, ahora ya no es imposible

pensar en la utilizacion de redes de sensores para aplicaciones de ese tipo en un futuro.
Nodos sensores de bajo peso pueden introducirse en un tornado, tomar datos y transmi-
tirlos a una red donde los usuarios podran evaluar y analizar los datos. La robustez y el coste
de la red de sensores superara la alta probabilidad de fallo en los nodos para asegurar el exito
del proyecto y, ademas, conseguir una informacion relevante desde el corazon del tornado,
para el bien de los meteorologos.
Otra aplicacion que podramos considerar futurista es la que se expone en este vdeo.
Figura 40: T
unel WSN
En el se muestra un escenario de un t unel con bastante trafico en el que ocurre un

accidente y provoca un incendio en su interior. El t
unel esta dotado de sensores que transmiten

ambricas
informacion de todo tipo a las centrales de control de la ciudad: niveles de temperatura, da

nos,
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.
La comunicacion y el tiempo de respuesta, evidentemente, es inmediato. El trafico es

desviado hacia otras carreteras y los sistemas de emergencia del t unel hacen su parte hasta
que llegan los refuerzos humanos.
Los vehculos de emergencia tambien disponen de sistemas de control con informacion
actualizada de la situacion en el interior del t
unel, e introducen robots de deteccion y rastreo
de los distintos niveles de peligro que pudiera haber.
Finalmente, los propios bomberos son una PAN (Personal Area Network ) movil, y van
provistos de varios sensores que indican sus caractersticas internas y externas, as como su
posicion. Los cascos van provistos de camara y pantallas que informan de cada uno de los
parametros clave para tomar las mejores decisiones.
En EEUU estan ya experimentando en un proyecto para bomberos llamado Wireless

FireFighter System en el que estan disenando este tipo de cascos, as que parece que no
estamos ante una realidad tan futurista.

Parte III
on de
WSN y dom otica

on de WSN y
domotica
I. Introducci
on
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.
En definitiva, esto es lo que se conoce como Redes de Sensores y Actuadores In-

al
ambricas WSAN (Wireless sensor and actor networks), redes que, tal y como ocurre
en una tecnologa domotica, se basan en un grupo de sensores que envan eventos a unos
actuadores para que realicen cierto tipo de funciones.
Se espera que la introduccion de este novedoso tipo de redes sea la revolucion en el sector
de la domotica inalambrica. Iniciativas del estandar IEEE 802.15.4 para WSAN definen la
automatizacion de viviendas como uno de sus principales ambitos de aplicacion.
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 dise
no 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.

on de WSN y dom
otica
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:
Figura 1: Arquitectura WSAN
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 peque
nos, baratos con sensores, capaci-
dad de procesamiento y comunicacion inalambrica limitados, y el hecho de actuar sobre
un fen
omeno es mas complicado y consume mas energa que medir un fen omeno, 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 n
umero 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 ata ne, 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.

I Introducci
on
I.2. Ventajas de la dom

otica inal
ambrica
Las redes de sensores inalambricas proporcionan soluciones con baja tasa de transmision
de datos, bajo consumo, seguridad y fiabilidad que, como ya hemos comentado, son ideales
para los mercados de la automatizacion de viviendas, edificios e industrial.
Veamos algunas ventajas que podremos experimentar para cada uno de estos mercados.
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 m ultiples 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.
Figura 2: Casa domotica
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.

on de WSN y dom
otica
En una fabrica se podran desarrollar redes de monitorizacion para aumentar la seguridad

publica y de los empleados, as como hacer mas eficiente la recoleccion de datos para mejorar
los informes de resultados.
Confort
Todas las instalaciones, actualizaciones y sistemas de control de la redes domoticas son
sin cables, tambien pudiendo configurar y ejecutar m ultiples 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.

I Introducci
on
I.3. Soluciones existentes

Para acabar este captulo introductorio, presentaremos un par de soluciones existentes
en el campo de la domotica mediante redes inalambricas de sensores, llevadas a cabo por la
Zigbee Alliance.
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 compa na lder en automatizacion de edificios, sistemas de seguridad y solu-
ciones de energa. La mision de TAC es proporcionar un valor a nadido 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.

on de WSN y dom
otica
II. Escenario del proyecto

El proposito final de este proyecto es dise
nar una red de sensores y actuadores inalambrica
para su aplicacion en automatizacion y control de viviendas y edificios que satisfaga los
requerimientos propios de las instalaciones domoticas y facilite la introduccion de tecnicas
para la creacion de ambientes inteligentes a traves de las prestaciones que ofrecen este tipo
de redes.
Una WSAN va a funcionar en escenarios que dependen de la aplicacion, pero cuyas carac-
tersticas basicas seran comunes. Por ello, vamos a establecer el escenario de aplicacion sobre
el que se desarrollara nuestro proyecto, que se podra ampliar o modificar en un futuro, si
nuestros resultados se ajustan adecuadamente.
El escenario de nuestro proyecto podra ser el siguiente:

Vivienda unifamiliar de tama no medio con sistemas de calefaccion, aire acondicionado,
iluminacion distribuida por toda la casa y persianas provistas de un motor para la subida
y bajada de las mismas. En principio, una vivienda como la mayora de las existentes, sin
ning
un sistema tecnologico complejo.
Figura 4: Vivienda escenario
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.
De manera periodica para la realizacion de acciones de control. Por ejemplo, la regu-

lacion de temperatura en el sistema de climatizacion.
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.

II Escenario del proyecto
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. Iluminaci
on.
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 u
ltimo se traducira en los giros de lamas en un sentido u otro.
3. Sensores crepusculares y de temperatura.

En este ultimo apartado incluimos las aplicaciones que incorporan sensores de tipo
crepuscular para la activacion o regulacion de luces o motores, dependiendo de la ilu-
minacion solar o, por otra parte, sensores de temperatura que controlaran los sistemas
de calefaccion o AC, dependiendo de la temperatura interna de la vivienda.
Por u
ltimo 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 dom otico: 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.

on de WSN y dom
otica
III. Programaci
on de las aplicaciones dom
oticas
En este captulo expondremos como se ha realizado la programacion de los distintos
nodos para que realicen las funciones domoticas descritas y que, mas adelante, veremos en
profundidad.
Es obvio que para programar los sensores de los que disponemos, como son los TelosB,
deberemos conocer como trabaja el sistema TinyOS, y dominar el lenguaje nesC para la
programacion. Ya vimos un resumen de ambas cosas en apartados anteriores.
No obstante, realizaremos un estudio de una de las aplicaciones basicas, para comprender

un poco mejor el modo de programacion. Tambien realizaremos un breve resumen de otras
aplicaciones ya existentes y que han sido de gran utilidad para la realizacion de codigos en
este proyecto. Ademas, adjuntamos los codigos completos de las aplicaciones desarrolladas en
los apendices de este proyecto.
De esta forma se pretende que, junto con las explicaciones de las partes mas importantes
del codigo, se comprenda perfectamente como recibe cada nodo la informacion, como la proce-
sa y que hace en consecuencia.
Tras estos preliminares, realizaremos un analisis de las aplicaciones domoticas progra-

madas, dividiendolas en los tres apartados que comentamos anteriormente: Iluminacion, per-
sianas y aplicaciones de sensores crepusculares o de temperatura.
Aplicaci
on 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.
La aplicacion esta compuesta por dos componentes: un modulo, llamado BlinkM.nc y

una configuracion llamada Blink.nc. Debe recordarse que todas las aplicaciones requieren
de un archivo de configuracion de alto-nivel que suele llamarse como la aplicacion en s. En
este caso Blink.nc es la configuracion para la aplicacion Blink y es el archivo fuente que el
comilador de nesC utiliza para generar el fichero ejecutable.
Por otra parte, BlinkM.nc realmente proporciona la implementacion de la aplicacion
Blink. El archivo de configuracion dira a que componentes habra que conectar nuestro modulo,
aquellos que requiera la aplicacion.
1 configuration Blink {
2 }
3 implementation {
4 components Main , BlinkM , SingleTimer , LedsC ;
5 Main . StdControl -> SingleTimer . StdControl ;
6 Main . StdControl -> BlinkM . StdControl ;
7 BlinkM . Timer -> SingleTimer . Timer ;
8 BlinkM . Leds -> LedsC ;
9 }
Codigo 2.1: Blink.nc
El archivo Blink.nc contiene la configuracion (que no es necesaria para esta sencilla

aplicacion) y la implementacion, donde se definen las conexiones que hay entre los diferentes
componentes que utilizan la aplicacion.

III Programaci
oticas
La lnea n
umero 4 especifica el conjunto de componentes que esta configuracion referencia,
en este caso Main, BlinkM, SingleTimer, and LedsC. El resto de la implementacion consiste
en la conexion de interfaces usadas por los componentes a las interfaces proporcionadas por
otros.
Main es el componente que se ejecuta primero en una aplicacioin TinyOS. Siendo pre-
cisos Main.StdControl.init() es el primer comando que se ejecuta en TinyOS seguido de
Main.StdControl.start(). De esta forma, un aplicacion TinyOS debe tener siempre un
componente Main en su configuracion.
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;
En estas dos sentencias se conecta o se vincula la interfaz StdControl de Main a las

interfaces StdControl de BlinkM y SingleTimer.
Es decir, SingleTimer.StdControl.init() y BlinkM.StdControl.init() seran lla-
madas por Main.StdControl.init(). Y lo mismo pasara con los metodos start() y stop().
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 m ultiples timers usando un identificador de timer como
parametro.

on de WSN y dom
otica
Los vnculos pueden ser tambien implcitos.
Por ejemplo:
BlinkM.Leds ->LedsC;
Es en realidad una abreviatura de:
BlinkM.Leds ->LedsC.Leds;
Si no se pone ningun nombre de interfaz en la parte derecha de la flecha, el compilador

nesC intenta, por defecto, vincularlo a la misma interfaz que hay en la parte izquierda.
Veamos el fichero del modulo.

1 module BlinkM {
2 provides { interface StdControl ;}
3 uses {
4 interface Timer ;
5 interface Leds ;
6 }
7 }
Codigo 2.3: BlinkM.nc
La primera parte del codigo declara el nombre del modulo y las interfaces que propor-
ciona y que usa. El modulo BlinkM proporciona la interfaz StdControl. Esto significa que la
va a implementar en su codigo. Ademas, BlinkM usa tambien dos interfaces: Leds y Timer.
Quiere decir que BlinkM podra llamar a cualquier metodo declarado en las interfaces que usa
y debera implementar tambien cualquier evento declarado en esas interfaces.
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.nc es tambien interesante:

1 interface Timer {
2 command result_t start ( char type , uint32_t interval ) ;
4 event result_t fired () ;
5 }
Codigo 2.4: Interfaz Timer.nc
La interfaz Timer define los metodos start(), stop(), donde se especificara el tipo de
timer con el intervalo indicando cuando expira el timer. Las unidad de tiempo en el argumento
del intervalo son los milisegundos. Los tipos validos son:
TIMER REPEAT Este timer termina despues de un intervalo especifado.
TIMER ONE SHOT Un timer de este tipo se va repitiendo continuamente hasta que se para con
el metodo stop().

III Programaci
oticas
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 se nalizara cuando se
produzca un evento. En nuestro caso, el evento fired() se se naliza 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.
El resto del codigo de BlinkM:

1 implementation {
2 command result_t StdControl . init () {
3 call Leds . init () ;
4 return SUCCESS ;
5 }
6 command result_t StdControl . start () {
7 return call Timer . start ( TIMER_REPEAT , 1000) ;
8 }
9 command result_t StdControl . stop () {
10 return call Timer . stop () ;
11 }
12 event result_t Timer . fired ()
13 {
14 call Leds . redToggle () ;
15 return SUCCESS ;
16 }
17 }
Codigo 2.5: Continuacion de BlinkM.nc
El modulo implementa los metodos StdControl.init(), StdControl.start(), y
StdControl.stop() y tambien el evento Timer.fired(), ya que proporciona esa primera
interfaz y porque es necesario implementar los eventos de las que use.
El metodo init() simplemente inicializa el subcomponente Leds. El metodo start()
invoca al Timer para crear un temporizador que se repita y expire cada segundo. El metodo
stop() para el timer.
Cada vez que el evento Timer.fired() se dispara, el metodo Leds.redToggle() hace
que parpadee el led rojo.
nesC proporciona tambien la posibilidad de ver una representacion grafica de la relacion

entre componentes. Para esta aplicacion es la siguiente:
Figura 5: Relacion de componentes en Blink

on de WSN y dom
otica
Aplicaciones existentes TinyOS

A continuacion, comentaremos brevemente una serie de aplicaciones ya implementadas
que nos han servido para realizar la programacion de nuestras aplicaciones domoticas, tanto
para el envo de mensajes, como la toma de datos, as como la visualizacion en ordenador de
los campos de esos mensajes.
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.

III Programaci
oticas
Figura 6: Aplicacion Oscilloscope
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.
Figura 7: Aplicacion SerialForwarder y captura de mensajes

on de WSN y dom
otica
III.1. Aplicaciones de iluminaci

on
El sistema EIB establece una direccion fsica para cada uno de sus componentes, de tal
forma que puedan ser identificados dentro de una red. Pero debemos tener en cuenta que esta
direccion no es mas que un nombre que se le da al dispositivo, y no influira en la funcionalidad
final del mismo.
Las direcciones que marcan el funcionamiento de un aparato son las direcciones de grupo.
Estas direcciones establecen el comportamiento y los vnculos entre los objetos de comuni-
cacion de los distintos dispositivos que tendra la red.
En el caso de aplicaciones de iluminacion, seg

un los tipos de punto de datos (DPT)
estandarizados de EIB, lo que llamabamos EIS, dispondremos de tres tipos de objetos de
comunicacion:
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.
Regulaci
on relativa (3.007)
Este objeto de comunicacion pertenece al bloque funcional Regular, anteriormente de-
nominado EIS2 y que constaba de, al menos, la regulacion relativa y el objeto de
conmutacion 1.001. Tambien poda incluir la regulacion absoluta.
Mediante este objeto se enva un comando de regulacion relativo al valor de luz actual.
Consta de cuatro bits de los cuales el mas significativo indica si la regulacion aumenta
o disminuye la luminosidad con respecto a la luminosidad actual.
Regulaci
on absoluta (5.001)
Con la funcion de regulacion absoluta, de 8 bits, se fija directamente un valor de lumi-
nosidad previamente establecido, entre 1 (mnimo) y 255 (maximo).
Este tipo se suele utilizar para crear lo que se denominan escenas en domotica. Por
ejemplo, puede haber una escena-cine en la que ciertas luces que esten cerca de la
pantalla pasen a un 20 % de intensidad y otras al 40 % al pulsar un boton.
Los nodos que se configuren como sensores tendran el comportamiento de pulsadores

convencionales. Es decir, estaran conectados a un pulsador y cuando este sea pulsado, recibiran
un evento de boton y enviaran un mensaje concreto, dependiendo del boton pulsado.
Cada boton tendra asociado un objeto de comunicacion, de tal forma que un mismo
nodo sensor pueda tener varios botones con varias funciones distintas: encender una luz o un
grupo de luces determinado, regular a mas intensidad, regular a menos, o incluso lo que se
denominan funciones centrales, que conciernen a todos los sistemas de iluminacion, por
ejemplo, apagar todas las luces de una casa.
Trasladando todo esto al protocolo EIB, diremos que asociamos una direccion de grupo a
cada uno de estos objetos de comunicacion. Es decir, el objeto de comunicacion que enciende
una luz se asociara con una direccion 1/1/1, por ejemplo. Cada vez que se pulse el boton
vinculado a ese objeto de comunicacion, se enviara un mensaje con esa direccion de grupo.
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.

III Programaci
oticas
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.
A modo de ejemplo, podemos ver este grafico:
Figura 8: Ejemplo de telos sensores y actuadores
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 com un a todas las aplicaciones.

on de WSN y dom
otica
El archivo en cuestion es EIBMsg.h y es com

un a todos los programas que hemos realizado,
con peque nas variaciones, como ampliar la longitud de los datos u
tiles 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.
1 typedef struct EIBMsg {

2 uint8_t control ;
3 uint8_t seqno ;
4 uint16_t dfisica ;
5 uint16_t dgrupo ;
6 uint8_t hop_count ;
7 uint8_t length ;
8 uint16_t datos ;
9 uint8_t seguridad ;
10 } EIBMsg ;
Codigo 2.6: EIBMsg.h
Como vemos, al igual que en un mensaje EIB incluimos los campos:
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 com un para todos, el codigo sera 0xBC
en hexadecimal.
seqno N umero de secuencia del mensaje. Es importante indicar el n umero 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.
dgrupo Direccion de grupo a la que va destinada el mensaje. Es la direccion destino, puesto

que englobara los dispositivos que deben escuchar el mensaje.
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 u
til 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 u tiles. 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.

III Programaci
oticas
Nodos pulsadores de iluminaci

on
Comenzaremos con los nodos pulsadores, cuyo fichero es EIB reg bot denominado
as porque sigue el protocolo de mensajes EIB, y esta destinado a pulsadores o botones para
funciones de regulacion, incluyendo tambien la regulacion absoluta con un valor prefijado.
eib.nc
La parte mas importante del codigo de configuracion es la implementacion, donde veremos

que componentes utilizamos y los vnculos entre ellos:
1 implementation {
2 components Main , eibM , GenericComm , LedsIntensityC , TimerC ;
3
4 Main . StdControl -> eibM ;
5 Main . StdControl -> LedsIntensityC ;
6
7 eibM . CommControl -> GenericComm ;
8 eibM . ReceiveEIBMsg -> GenericComm . ReceiveMsg [ AM_EIBMSG ];
9 eibM . Send -> GenericComm . SendMsg [ AM_EIBMSG ];
10
11 eibM . LedsIntensity -> LedsIntensityC ;
12 eibM . TimerMilli -> TimerC . TimerMilli [ unique (" TimerMilli ") ];
13 }
Codigo 2.7: 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 u ltimo, 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.
Figura 9: Diagrama de eib.nc

on de WSN y dom
otica
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 m ultiples 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;}
Esto es justo una generalizacion de la misma idea. El componente TimerC declara:
provides interface TimerMilli[uint8 t id];
En otras palabras, proporciona 256 instancias diferentes de la interfaz TimerMilli, una

para cada valor uint8 t.
En muchos casos, querremos aplicaciones TinyOS para crear y usar m ultiples timers, cada
uno de los cuales puedan ser manejados independientemente. Por ejemplo, un componente
de una aplicacion puede necesitar un timer que se dispare cada cierto tiempo (una vez por
segundo) para hacer lecturas con un sensor, mientras otro componente puede necesitar un
timer que se dispare en otro momento para controlar la transmision radio. Conectando la
interfaz TimerMilli en cada uno de estos componentes a instancias separadas de la interfaz
TimerMilli proporcionadas por TimerC, cada componente puede conseguir su propio timer
privado.
Figura 10: Diagrama de TimerC
Cuando decimos TimerC.TimerMilli[valor], estamos especificando que eibM.TimerMilli

estara conectado a la instancia de la interfaz TimerMilli especificada por el valor entre

corchetes. Este puede ser cualquier n umero positivo de 8 bits. Si tuvieramos que especificar
un valor particular aqu, como 38 o 42, se podra dar accidentalmente un conflicto con el
timer usado por otro componente (si ese componente uso el mismo valor entre corchetes).
Por eso, usamos la funcion constante en tiempo de compilacion unique(), que genera un
u
nico identificador de 8 bits de la palabra dada como argumento.
En este caso, unique("TimerMilli") genera un u nico numero de 8 bits de un conjun-
to correspondiente a la cadena de caracteres TimerMilli. As, cada componente que use
unique("TimerMilli") se garantiza conseguir un valor diferente de 8 bits con tal de que
la cadena de caracteres usada como argumento sea la misma. Tengase en cuenta que si un
componente usa unique("Timer") y otro usa unique("TimerMilli"), puede que tengan el
mismo valor de 8 bits. Por lo tanto, es bueno en la practica usar el nombre de la interfaz
parametrizada como argumento de la funcion unique().

III Programaci
oticas
Otro caso de interfaces parametrizadas aparece en las sentencias:

eibM.ReceiveEIBMsg -> GenericComm.ReceiveMsg[AM_EIBMSG];
eibM.Send -> GenericComm.SendMsg[AM_EIBMSG];
En este caso se estan conectando los metodos de envo y recibo de eibM con los propor-
cionados por GenericComm. Por ejemplo, para explicar la segunda sentencia podemos ver que
el componente GenericComm declara:
provides {
...
interface SendMsg[uint8_t id];
}
En otras palabras, proporciona 256 instancias diferentes de la interfaz SendMsg. Esta es
la forma en que los identificadores IDs del manejador AM (Active Message) se conectan jun-
tos. En eibM, estamos conectando la interfaz SendMsg correspondiente al ID del manejador
AM EIBMSG a GenericComm.SendMsg. (AM EIBMSG es un valor global definido en EIBMsg.h).
Cuando el metodo SendMsg se invoca, se le proporciona el ID del manejador, esencialmente
como un argumento extra.
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
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.

on de WSN y dom
otica
eibM.nc
La implementacion del modulo eibM.nc esta compuesta de distintas variables, metodos

y eventos. Podemos dividir el codigo en tres partes fundamentales:
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.
Normalmente, un nodo sensor no estara programado para procesar un mensaje, pero

s puede configurarse como nodo de enlace o encaminador de mensajes hacia otros nodos
actuadores que se encuentren en una ubicacion que no esta al alcance del emisor.
Por esto, un nodo sensor o un nodo actuador podra establecerse como retransmisor de
mensajes, si as lo requiere la topologa con la que estemos trabajando. En el caso de topologas
estaticas es relativamente sencillo configurar estos nodos, de acuerdo a las distancias y el al-
cance; en cambio, para topologa dinamicas debe haber un algoritmo que vaya estableciendo
continuamente la posicion de los nodos as como las relaciones establecidas entre ellos.
Transmisi
on de mensajes
Inicialmente, como en toda aplicacion, se ejecutaran los metodos de inicializacion Init(),

Start() y Stop(), pero estos carecen ahora de importancia para nosotros. Unicamente debe-
mos tener en cuenta que en ellos se inicializaran las distintas variables, el timer, y en el metodo
Init() podremos configurar los las funciones de los botones, como veremos.
Los eventos y tareas mas importantes de este apartado son:
event result t TimerMilli.fired()

task void enviarPulsacionCorta()
task void enviarPulsacionLarga()
task void enviarSTOPlarga()
event result t Send.sendDone(TOS MsgPtr msg, result t status)
El proceso es el siguiente: el timer estara saltando periodicamente para detectar cualquier

evento de boton. Cuando este ocurra activara un contador para poder determinar si es una
pulsacion corta o larga.
A continuacion, y dependiendo de esto u ltimo, se invocara la tarea correspondiente. Si
es una pulsacion corta se enviara el mensaje que haya sido programado para pulsacion corta
(encender/apagar) y si es una pulsacion larga se enviara para que regule hacia mas o menos
luminosidad, como se haya definido.
Para parar la regulacion de pulsacion larga existe la tarea de stop y, finalmente se
se
nalizara el evento de que se ha enviado correctamente el mensaje.

III Programaci
oticas
El codigo de la funcion Timer sigue el siguiente algoritmo:
Figura 11: Algoritmo de Timer
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.
Profundizando en el codigo podemos ver como la variable valorBoton nos va a estable-

cer si hay un evento de boton (con 0x0000) o no. Una vez se haya detectado la pulsacion, se
pone en marcha la cuenta del tiempo que esta pulsado, mientras sigue disparandose el timer,
realizandose el algoritmo que acabamos de comentar.

on de WSN y dom
otica
El codigo fuente es el siguiente:
1 event result_t TimerMilli . fired ()

2 {
3 valorBoton = T O S H _ R E AD _ BO TO N _U N O_ PI N () ;
4
5 if ( valorBoton == 0 x0000 ) {
6
7 tpulsado = tpulsado + 100;
8
9 if (( tpulsado > tfrontera ) && ! enviadaLarga ) {
10
11 post enviarPulsacionLarga () ;
12 enviadaLarga = TRUE ;
13 }
14 }
15
16 else {
17
18 if (( tpulsado < tfrontera ) && ( tpulsado != 0) ) {
19
20 post e n v i a rPulsacionCorta () ;
21 tpulsado = 0;
22
23 }
24 else {
25 if ( enviadaLarga ) {
26 post enviarSTOPlarga () ;
27 }
28 tpulsado = 0;
29 enviadaLarga = FALSE ;
30 }
31 }
32 return SUCCESS ;
33 }
Codigo 2.9: Funcion de Timer
Las tareas que se invocan tanto para una pulsacion corta, larga o para dejar de ejecutar una
regulacion, consisten en el envo de un mensaje, diferenciandose u
nicamente en la direccion
de grupo del mensaje y en el campo de los datos.
Para la pulsacion corta (encender/apagar) enviaremos, por ejemplo, la direccion de grupo
1/1/1 mientras que para la larga (regulacion) utilizaremos la 1/1/3. Y en el campo de datos
especificaremos el caso que sea:
ESCRIBIR ON = 0x0081
ESCRIBIR OFF = 0x0080
ESCRIBIR TOGGLE = 0X0082
REGULAR LUZ = 0x0089
REGULAR OSCURIDAD = 0X0081
REGULAR STOP = 0X0088

III Programaci
oticas
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;
En realidad, estamos creando un mensaje AM de TinyOs (TOS Msg), y en su campo de

datos vamos a transmitir un mensaje de tipo EIBMsg. Esto es as, porque si analizamos un
mensaje AM (tinyos-1.x/tos/platform/telos/AM.h) vemos que sus campos de cabecera y
datos son:
typedef struct TOS_Msg {

uint8_t length; /* Longitud del mensaje
uint8_t fcfhi; /* Frame Control Field High Byte para 802.15.4
uint8_t fcflo; /* Frame Control Field Low Byte para 802.15.4
uint8_t dsn; /* Data Sequence Number
uint16_t destpan; /* Destination PAN Identifier
uint16_t addr; /* Set by function of GenericComm.SendMsg.send()
uint8_t type; /* AM type
uint8_t group; /* Group ID
int8_t data[TOSH_DATA_LENGTH]; /* Data (28 bytes)
}
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.

on de WSN y dom
otica
En el resto del codigo de la pulsacion corta debemos destacar algunas sentencias como
la actualizacion del n umero 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:
call Send.send(TOS BCAST ADDR, sizeof(EIBMsg), &data);
Si profundizamos en la interfaz SendMsg, el metodo que proporciona es:
command result t send(uint16 t address, uint8 t length, TOS MsgPtr msg);
Donde los argumentos son:
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().
TOS MsgPtr msg Mensaje o buffer de datos que queremos enviar.
Para la regulacion, con pulsaciones largas, lo u

nico 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:
message->datos = REGULAR OSCURIDAD;
Mientras que para detener la regulacion podemos utilizar la misma direccion de grupo
pero el campo de datos sera:
message->datos = REGULAR STOP;
En el caso de regulacion absoluta, variaremos la longitud e introduciremos el valor en los

datos, por ejemplo:
message->valor = VALOR 20 %;

III Programaci
oticas
Configuraci
on de funciones para los botones
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:
1. Regulacion hacia mas luz.

2. Regulacion hacia mas oscuridad.
int8 t valorAbs: Indica el valor de regulacion absoluta, en el caso de que la pulsacion

corta estuviera configurada para ello. Acepta 9 valores (1-9) que se corresponden con
los valores de intensidad 1 para el 10 %, 2 para el 20 %, etc.
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:
10 message - > datos = REGULACION_ABSOLUTA ; break ;
11 }
Codigo 2.11: Ejemplo de configuracion de funciones de boton

on de WSN y dom
otica
Recepci
on y procesado de mensajes
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:
event TOS MsgPtr ReceiveEIBMsg.receive(TOS MsgPtr pmsg)

command result t ProcessCmd.execute(TOS MsgPtr pmsg)
task void cmdInterpret()
event result t ProcessCmd.done(TOS MsgPtr pmsg, result t status)
task void forwarder()
Cuando se recibe un mensaje se produce el metodo ReceiveEIBMsg.receive eval ua si

es un mensaje nuevo por medio del n umero de secuencia. Si es nuevo, lo evaluaremos y
actualizaremos su n umero de secuencia.
A continuacion se llama al metodo que procesa los comandos ProcessCmd.execute que
actualizara ciertas variables y llamara al interprete de mensajes, que analizaremos mas ade-
lante.
De estos metodos podemos destacar algunas de las variables que se encargan, por ejemplo,
de conseguir que el procesado se realice correctamente y no quede nada pendiente.
int8 t bcast pending Indica si queda algo por enviar.
bool pending1 Indica si hay alg

un mensaje pendiente tras el evento de boton.
int8 t pending2 Indica si hay alg

un proceso pendiente en la recepcion.
El interprete de mensajes cmdInterpret, es quien realmente decidira que hace un nodo

actuador en funcion de los mensajes que reciba. Por lo tanto, este metodo no estara definido
para un nodo sensor sino que directamente pasaremos al evento de tareas y procesado termi-
nados: ProcessCmd.done.
Una vez hecho esto, si el nodo es retransmisior se invocara a la tarea forwarder que
reenviara el mismo mensaje que se ha recibido, sin realizarle cambio alguno o actualizando
los campos que se deseen, como la direccion fsica o el contador de saltos.
El codigo de este metodo es:
1 task void forwarder () {
2
3 struct EIBMsg * message = ( struct EIBMsg *) m - > data ;
5 message - > dfisica = DIRE_F ISICA_1_1_2 ;
6
7 if ( retransmite ) {
8 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , m ) ;
9 }
10 else {
12 bcast_pending = 0;
13 }
14 }
Codigo 2.12: Tarea de retransmision

III Programaci
oticas
Nodos actuadores de iluminaci

on
El fichero con el que tratamos en este caso se denomina EIB reg led ya que ahora
estamos configurando un actuador de regulacion, que transmitira las ordenes a luces o, en
nuestro caso, a los leds.
La mayor parte del codigo ya la hemos desarrollado en el apartado anterior, puesto que
hemos explicado parte de los metodos de recepcion y los metodos de transmision, aunque en
este caso lo habitual es que el nodo no sea preparado para realizar las funciones tpicas de
un sensor.
La tarea que es la base del funcionamiento de un nodo actuador es el interprete de mensajes
cmdInterpret. En ella se analizara el contenido de un mensaje, siendo partes fundamentales:
Direcci on de grupo. Si el mensaje va destinado a una direccion de grupo ante la que

un nodo actuador no debe responder, no se producira ninguna accion. Si el nodo s la
tiene registrada, examinara los datos a continuacion.
Datos u tiles. 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.
En la pagina siguiente tenemos la primera parte del codigo de interprete de mensajes.

En la primera sentencia:
struct EIBMsg *message = (struct EIBMsg *)m->data;
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.
Si examinamos como contin ua el codigo, comprobamos que para la direccion de grupo

1/1/1 el actuador ejecutara diversas acciones dependiendo del campo de datos:
message->datos==ESCRIBIR ON En este caso la funcion LedsIntensity establece la

intensidad de luz al maximo para el led que hayamos designado.
message->datos==ESCRIBIR OFF En este caso daremos la orden de apagar el led, o las

luces que esten incluidas en este comando y esten bajo el control de este nodo actuador,
por supuesto.
message->datos==ESCRIBIR TOGGLE Este caso es diferente, puesto que primero hay

que saber si esta encendida o no la luz (mediante la variable valorLuz) y actuar en
consecuencia para conseguir que se alterne la iluminacion.
message->datos==REGULACION ABSOLUTA Este es el caso de la regulacion absoluta para

la pulsacion corta. Se fijara una intensidad de luz determinada en los leds, configurada
mediante la variable valorAbs.

on de WSN y dom
otica
1 task void cmdInterpret () {

3
4 switch ( message - > dgrupo ) {
5
6 case DIRE_GRUPO_1_1_1 :
7 if ( message - > datos == ESCRIBIR_ON ) {
8 call LedsIntensity . set (0 x00 ,255) ;
9 }
10
11 if ( message - > datos == ESCRIBIR_OFF ) {
13 }
14
15 if ( message - > datos == ESCRIBIR_TOGGLE ) {
16
17 if (! valorLuz ) {
19 valorLuz = TRUE ;
20 intensidad = 255;
21 }
22 else {
24 valorLuz = FALSE ;
25 intensidad = 0;
26 }
27 if ( message - > datos == REGULACION_ABSOLUTA ) {
28 valorRecibido = message - > valor ;
29 call LedsIntensity . set ( 0 x00 ,
valorRecibido ) ;
31 intensidad = valorRecibido ;
32 }
33 break ;
Codigo 2.13: Interprete de mensajes (1)
Para el caso de la direccion de grupo de regulacion, el codigo es el similar. Para la re-

gulacion relativa, se activan dos variables (regular luz y regular sombra) que haran que
comience la regulacion al dispararse el timer.
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.

III Programaci
oticas
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 ) {
18 }
19 else {
21 estadozero = FALSE ;
22 }
23 }}
Codigo 2.14: Interprete de mensajes (2)
1 event result_t TimerMilli . fired () {

2 if ( regular_luz ) {
3
4 if ( intensidad < 255) {
5 intensidad = intensidad + factor ;
6 call LedsIntensity . set (0 x00 , intensidad ) ;
7 }
8 else {
9 call LedsIntensity . set (0 x00 , 255) ;
10 valorLuz = TRUE ;}
11 }
12 if ( regular_sombra ) {
13
14 if ( intensidad > 0) {
15 intensidad = intensidad - factor ;
16 call LedsIntensity . set (0 x00 , intensidad ) ;
17 }
18 else {
19 call LedsIntensity . set (0 x00 , 0) ;
20 estadozero = TRUE ;}
21 }
22 return SUCCESS ;}
Codigo 2.15: Timer de regulacion

on de WSN y dom
otica
El funcionamiento es sencillo, ya que cada vez que se dispara el timer va comprobando si

la variable sigue activada, y si es as, continuara regulando hacia mas o menos luz.
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 seg un 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.

III Programaci
oticas
III.2. Aplicaciones de persianas

Para las aplicaciones de persianas lo que programaremos es lo que se denomina en EIB
el bloque funcional Control de movimiento (anteriormente denominado EIS7) que se emplea
principalmente para el control de mecanismos de persianas y toldos y consta, como mnimo
de los objetos de comunicacion con los siguientes tipos de datos (DPT):
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.
Nodos pulsadores de persianas

Los pulsadores de persianas, al tener tambien la diferenciacion entre pulsacion corta y
larga van a estar programados exactamente igual que los nodos pulsadores de iluminacion.
La u
nica diferencia vendra en el campo de datos, donde habra que indicar si se enva un
objeto para subir o bajar, o si es un paso de subida o bajada, lo que se configurara tambien
facilmente modificando una unica variable. (Podemos ver el codigo en el anexo correspondi-
ente).
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:
1. message->datos = ESCRIBIR ON;

En el caso del DPT 1.008 de subida/bajada total, un actuador atendera ante este co-
mando subiendo totalmente la persiana, es decir, poniendo en marcha el boton durante
el tiempo predefinido para la subida total. En el caso del DPT 1.007 se efectuara un
paso de hacia arriba.
2. message->datos = ESCRIBIR OFF;

Cuando se enve este comando, sera para bajar totalmente una persiana o toldo si es el
primer caso. Si es el caso de un movimiento de paso, se producira un paso hacia abajo.

on de WSN y dom
otica
Nodos actuadores de persianas

Un actuador de persianas recibe ordenes que pueden ser de subida o de bajada y, a su
vez, de paso corto o paso largo: subida o bajada total de la persiana.
Es decir, un boton configurado para la subida de la persiana, podra enviar una direccion
de grupo para que suba totalmente la persiana y otra para que solo realice un paso de subida.
Lo mismo ocurrira con otro boton configurado de bajada.
Ademas, el actuador debera tener prefijados unos tiempos especficos para el buen fun-
cionamiento. Por ello, creamos las variables:
tpaso Tiempo que dura un paso de subida/bajada.
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.
Figura 12: Ejemplo de telos en aplicacion de persianas
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.
Lo mas importante de este actuador es controlar los tiempos de subida/bajada y las

posibles colisiones que pueda haber entre los distintos mensajes, siempre respetando el tiempo
de espera para no da nar el funcionamiento de motores.

III Programaci
oticas
Algoritmo de movimiento de paso
Figura 13: Algoritmo de movimiento de paso
El codigo sera:
2
4
5 if ( total_subir || total_bajar ) {
6 total_subir = FALSE ;
7 total_bajar = FALSE ;
8 call LedsIntensity . set ( 0 x00 , 0 ) ;
10 }
11 else {
12 paso_subir = TRUE ;
13 paso_bajar = FALSE ;
14 tcounter = 0;
15 }}
Codigo 2.16: Paso de subida en persianas

on de WSN y dom
otica
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.
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).
Para las aplicaciones de persianas los diagramas de relaciones de componentes (eib.nc)

son similares a las aplicaciones anteriores, por lo que en el anexo final podemos observar el
diagrama completo, valido tambien para esta aplicacion.

III Programaci
oticas
Algoritmo de movimiento total
Al realizar una peticion de movimiento total de subida o bajada, es muy importante

controlar si ya estaba en movimiento. Si es as, los pasos a seguir seran:
1. Parar el movimiento.
2. Aguardar un tiempo de espera.
3. Comenzar el movimiento contrario.
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.
Figura 14: Algoritmo de movimiento total

on de WSN y dom
otica
El codigo para la subida total de una persiana sera:

3
4 total_subir = TRUE ;
5 if ( total_bajar ) { wait = TRUE ;}
7 tcounter = 0;
8 call LedsIntensity . set ( 0 x02 , 0 ) ;}
Codigo 2.18: Subida total en persianas
Apreciamos como, si estaba realizando el movimiento contrario de bajada, se establece el

tiempo de espera, ademas de parar dicho movimiento para activar el contrario.
1 // SUBIDA TOTAL DE PERSIANA
2 if ( total_subir ) {
4 if ( wait ) { // Caso de colision
5 if ( tcounter > twait ) {
7 if ( tcounter > ttotal ) {
10 tcounter = 0;
11 wait = FALSE ;
12 }}
13 }
14 else { // Caso normal , sin colisi on
19 tcounter = 0;
20 }}}
Codigo 2.19: Timer - Subida total en persianas
En el Timer se distinguen los dos casos:
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.

III Programaci
oticas
III.3. Aplicaci
on de sensor crepuscular
Para configurar un nodo como sensor crepuscular, de temperatura como termostato o de
humedad vimos que disponamos de la aplicacion Sense, que va tomando medidas del sensor
que tenga configurado. A modo de ejemplo, realizaremos la programacion de un nodo sensor
crepuscular, cuyas medidas seran de luz solar.
Los TelosB, ademas del sensor de temperatura y humedad, disponen de dos tipos de
sensores de luz Hamamatsu:
PAR: Photosynthetically Active Radiation. Radiacion fotosintetica activa.
TSR: Total Solar Radiation. Radiacion solar 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:
1 event result_t Timer . fired () {

2 return call ADC . getData () ;
3 }
4
5 async event result_t ADC . dataReady ( uint16_t data ) {
6 call IntOutput . output (( data > >7) &0 x7 ) ;
7 return SUCCESS ;
8 }
Codigo 2.20: Funcionamiento basico de Sense
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.
El diagrama de configuracion de esta aplicacion Sense es el siguiente:
Figura 15: Diagrama Sense.nc

on de WSN y dom
otica
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.
Figura 16: Sensor crepuscular
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.

III Programaci
oticas
Valor Intensidad
7 0
7 32
6 64
5 96
4 128
3 160
2 192
1 224
0 255
Tabla III.1: Valores e intensidades de luz
1 command result_t IntOutput . output ( uint16_t value )

2 {
3
4 if ( value == 5) {
5
6 if ( intensidad != 96) {
7
8 // ENV
I O DE MENSAJE //
9
10 message - > datos = R EGULACION_ABSOLUTA ;
12 message - > valor = 96;
13 }
Codigo 2.22: Aplicacion crepuscular
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.

on de WSN y dom
otica
IV. Ejemplo de aplicaci

on: Vivienda con configuraci
on est
atica
Uno de los objetivos finales de esta union entre las redes de sensores y la domotica, es
que cada mote pueda actuar como un nodo que realice diversas actuaciones: como sensor
pulsador, como un sensor tomando valores, como actuador de luces o persianas, etc.
De esta forma, podremos distribuir por la vivienda un n umero determinado de motes que
llevaran implcitos las funciones de sensor o actuador, dependiendo de donde se encuentren
situados y de como se quieran configurar.
Figura 17: Vivienda con motes distribuidos
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 suponemos un ejemplo de una estancia salon como en la figura de la pagina siguiente,

con varios motes configurados como pulsadores, otros como actuadores y uno como sensor,
podramos establecer las siguientes relaciones, tal y como trabaja el sistema EIB:
Sensores @Grupo Actuadores @Grupo

S1 Luz 1/1/1 AL1 1/1/1, 1/1/2, 1/1/3
P1 Off 1/1/2 AL2 1/1/1, 1/1/2, 1/1/4, 1/1/7, 1/1/8
P2 Toggle 1/1/3 AP1 1/1/2, 1/1/5, 1/1/6
P3 Toggle 1/1/4
P4 Pers Up 1/1/5
P5 Pers Down 1/1/6
P6 Luz Up 1/1/7
P7 Luz Down 1/1/8
Tabla III.2: Tabla configuracion de motes

IV Ejemplo de aplicaci
on: Vivienda con configuraci
on est
atica
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 u ltimo, las luces de abajo tienen dos pulsadores de regulacion, que son P6 y P7.
Figura 18: Estancia con motes configurados
Este es un simple ejemplo de las m ultiples aplicaciones y configuraciones distintas que

permiten este tipo de redes en viviendas domotizadas. Por ahora solo hemos desarrollado
unas pocas aplicaciones, que mas adelante iran aumentando en prestaciones, fiabilidad y
versatilidad, lo que dara un gran beneficio al mundo de las viviendas y edificios inteligentes.

on de WSN y dom
otica
V. Configuraci
on de los puertos de expansi
on de TelosB
En este apartado describiremos la parte fsica del proyecto, que ha consistido en aprovechar
los puertos de expansion de que dispone el mote para a nadirle nuevos botones o leds, de tal
forma que las prestaciones del dispositivo aumentaran.
En esta figura podemos ver como la placa dispone de dos unidades de expansion:
Figura 19: Detalle de componentes TelosB
Los conectores de expansion tienen 10 y 6 pines respectivamente, entre los cuales se

encuentran los pines GIO (General Input Output) que configuraremos como entradas para
posibles pulsadores o salidas para posibles leds.
Primero realizaremos la configuracion hardware para soldar y cablear correctamente los

puertos de expansion a las placas que dise
nemos con los botones o leds.
Una vez montada lo que es la parte fsica de la placa y sus conexiones al mote, configu-
raremos este para que las senales de expansion esten determinadas como entradas o salidas
y no haya problemas ni ambig uedades entre ellas, porque, como veremos, algunos puertos
comparten distintas senales.

V Configuraci
on de TelosB
V.1. Configuraci
on hardware
Inicialmente, debemos indicar que las se
nales que utilizaremos son las GIO: GIO0, GIO1,
GIO2 y GIO3, que se corresponden con los puertos 20, 21, 23 y 26 del procesador MSP430 y,
a su vez, corresponden con distintos puertos de los bloques de expansion. Lo resumimos en
la siguiente tabla:
Se
nal Puerto MSP430 Puerto U2 Puerto U28
GIO0 20 10
GIO1 21 7
GIO2 23 3
GIO3 26 4
Tabla III.3: Correspondencia de se

nales y puertos
Tal y como puede verse en el esquematico:
Figura 20: Conectores de expansion TelosB
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:
Figura 21: Esquematico para botones y leds

on de WSN y dom
otica
V.2. Programaci
on de los puertos
Para programar con las nuevas se nales de expansion, lo primero que se debe hacer es con-
figurar dichas se
nales como entradas o salidas, dependiendo de lo que sean: para leds seran
salidas y para pulsadores las tomaremos como entradas.
El fichero a configurar sera hardware.h que encontraremos en la plataforma de telosb, en
/tinyos-1.x/tos/platform/telosb/hardware.h. , que trataremos de no cambiar su con-
figuracion lo menos posible y realizar la programacion pertinente en nuestro codigo.
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);
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:
void TOSH MAKE name OUTPUT()

void TOSH MAKE name INPUT()
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.
Programaci
on para botones adicionales
Para programar las aplicaciones de botones pulsadores hemos dejado las asingaciones de
los GIO tal y como venan por defecto, y utilizaremos los nombres que vienen dados.
Para establecer la direccion de los pines hemos incluido en nuestro codigo, en el metodo
init(), las sentencias:
TOSH MAKE GIO0 INPUT();

Donde se configuran los pines como entradas. El problema que surge ahora es el hecho de
que algunos pines GIO comparten entrada con algunas se nales ADC (vease el apendice con el
esquematico de hardware del telos). Por tanto, no puede declararse una se
nal como entrada
y la otra se
nal compartida como salida. Para que no haya incompatibilidades, declararemos

V Configuraci
on de TelosB
tambien como entradas los puertos ADC que comparten se

nal con los pines de nuestro interes.
De esta forma no habra problemas, por tanto, a
nadiremos en nuestro codigo:
TOSH MAKE ADC2 INPUT();

Programaci
on para leds adicionales
Este caso es diferente al de los botones, puesto que ademas de asignar pines y direcciones,
los leds van a estar comandados por una serie de funciones que los encenderan y apagaran, y
cuyas funciones implementa el componente LedsC.
Este componente tiene definidas sus funciones con los nombres que tienen asignados los
leds por defecto: RED LED, GREEN LED y YELLOW LED (que, ademas, son solo tres y no cuatro,
como los que podramos a nadir).
Hay dos posibles formas de hacerlo:
1. Creando un nuevo componente en el que se configuraran funciones similares a las de

LedsC pero con los nuevos nombres que asignaramos a los pines de los GIO.
2. Aprovechar las funciones ya creadas y cambiar los pines asignados en el fichero hardware.h.
Hemos programado nuestros motes siguiendo esta u

ltima 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:
TOSH ASSIGN PIN(LED CUATRO, 2, 6);
Y, por supuesto, tendremos que configurar las funciones del codigo LedsC para que se
encienda y apague el nuevo led.

on de WSN y dom
otica
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 n umero 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
Tabla III.4: Configuracion de direcciones de pines
Y tendremos como entradas los pines 22 y 27 (que es precisamente el de UserButton) y

como salidas el resto de pines.
Por lo tanto, para configurar nuestros pines GIO como salidas, deberan estar a 1 los
puertos 20, 21, 23 y 26, y para configurarlos como entradas deberan estar a 0.
El parametro P2OUT es el valor inicial en la salida, y que, por defecto, estara a 0 en los
pines que nos ata nen.
El problema de la comparticion de senales con algunas senales ADC, que corresponden a
pines de P6DIR, lo solucionaremos declarando los pines P6DIR=0x00 (como entradas) y cuando
sean salidas, los declararemos tambien como entradas P6DIR=0x00 para que no interfiera en
la salida que estamos generando.
Finalmente, en nuestros codigos podremos conocer el estado de cada uno de estas se

nales,
mediante los metodos o macros que se proporcionan, como por ejemplo:
valorBoton2 = TOSH READ BOTON DOS PIN();
Habiendo predefinido asignado previamente las se

nales a los nombres como BOTON DOS,
podremos controlar y leer esas se
nales.
Configuraci
on bot
on sin expansi
on
En las codigos de las aplicaciones en las que no hay botones ni leds adicionales no debera
modificarse el codigo de hardware.h.
Para el caso de la programacion de actuadores (leds) no habra ning un problema, pero en
el caso de la programacion de pulsadores (que utilizan el UserButton del mote) deberemos
realizar una asignacion en el codigo de harware.h puesto que el boton que trae el TelosB no
tiene un nombre asignado, y por tanto, no podemos tratar con esta se nal.
Por tanto, tendremos que a nadir:
TOSH ASSIGN PIN(BOTON, 2, 7);
Es el u
nico cambio a realizar, el resto del codigo compilara y funcionara correctamente
en el mote.

V Configuraci
on de TelosB
El resultado final, tras el montaje, soldaduras y acoplo de los motes a las placas puede
verse en estas fotografas.
Figura 22: TelosB con leds y botones
Figura 23: TelosB con expansiones

on de WSN y dom
otica
VI. Perspectivas de futuro

El futuro de la domotica va a estar muy ligado al mundo de las redes inalambricas. Ac-
tualmente, los frentes de actuacion estan centrados en asentar los estandares de los sistemas
existentes, consiguiendo mejoras, aumentando el mercado de productos y las compatibilidades
entre ellos. Pero las limitaciones que tienen estos sistemas siguen estando ah.
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.
Los propositos a solucionar para conseguir la integracion de las redes inalambricas y la

domotica son muchos. Por un lado, las carencias que vimos en las WSN y que se deben
solucionar, como la falta de estandares, protocolos o arquitecturas que marquen el sistema o
las limitaciones de los sensores que deberan ir mejorando con el desarrollo de la tecnologa.
En cuanto al caso concreto de las redes domoticas, hay una serie de puntos que se deberan
trabajar y mejorar para conseguir un buen sistema funcional y fiable.
Interoperatividad con otras redes.

La monitorizacion y el acceso remoto es una de las funcionalidades basicas de las redes
domoticas, ya que permite la comunicacion de incidencias de seguridad en la insta-
lacion, as como algunas funciones de confort. La interoperatividad es necesaria para
la conexion con otras redes inalambricas o cableadas del hogar, como otros sistemas
domoticos ya existentes, redes multimedia o de datos.
Nodos m
oviles.
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.
Alimentaci
on de los nodos.
Se debe satisfacer el requerimiento de un consumo energetico muy bajo para aquellos
nodos que deban funcionar con bateras, y las fuentes alternativas de alimentacion
aprovechando el entorno. Se estan estudiando tecnicas piezoelectricas mediante las
cuales se pueda obtener energa por procesos mecanicos; este tipo de alimentacion es
idonea para pulsadores o sensores que experimenten estmulos de tipo mecanico. Los
sensores de temperatura se podran alimentar por metodos de diferencias termicas, los
de luz con placas solares, etc.

VI Perspectivas de futuro
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 a
un mas la integridad
en caso de ataques externos y manipulacion de nodos.
Dise
no y encapsulado de nodos.
La mayora de nodos se instalaran en interiores por lo que las condiciones ambientales no
seran extremas ni estaran en peligro por los usuarios. Se debera tener en cuenta aspectos
como el aislamiento electrico para nodos alojados en proximidades de instalaciones
electricas y aspectos esteticos, puesto que estaran situados en viviendas o edificios en
los que esta cuestion puede ser importante.
Configuraci
on de los nodos.
La configuracion debera poder ser realizada de forma autom atica al a
nadir un nodo a
la red, de tal forma que el administrador les pueda asignar la funcionalidad. Ademas,
con la introduccion de la computacion ubicua, el tamano de las redes y la ubicacion de
los sensores hace necesario disponer tambien de tecnicas para reconfigurar el software
de los nodos a trav es de la propia red.
La domotica tendera, en unos a

nos, a crear Ambientes Inteligentes, entornos en el que
los usuarios interact
uan de forma transparente con multitud de dispositivos conectados entre
ellos y a Internet, o, en un sentido mas sociologico, conjuntos de personas interconectadas,
quienes, junto con sus ordenadores y otros aparatos, compraran, venderan e intercambiaran
informacion y servicios, todo dentro del entorno de la vivienda.
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 ning un 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 n umero de actividades diferentes se realizan (ocio, trabajo,
relaciones sociales, etc.) se constituira como el Ambiente Inteligente por excelencia.

on de WSN y dom
otica

Conclusiones
Con este proyecto hemos realizado un estudio de dos sectores tecnologicos que a
un 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.
Despues de analizar el estado actual de la automatizacion de viviendas y edificios, hemos

comprobado que desde hace algunos a nos se han puesto esperanzas en proyectos que no han
dado los resultados previstos. La integracion de la domotica en la sociedad es una asignatu-
ra aun pendiente, puesto que estan apareciendo inconvenientes que estan retrasando esta
implantacion.
Al igual que paso con la telefona movil, que experimento una revolucion y un auge casi
inesperados, a la domotica le esta faltando ese factor explosivo que permita integrarla en la
vida cotidiana de cualquier persona, en cualquier casa y edificio. Ese factor seran las redes
inalambricas de sensores y actuadores.
El MIT considera que estas redes seran una de las tecnologas que cambiaran el mundo en
los proximos a
nos y, por supuesto, llevaran sus prestaciones al mundo de la vivienda, as como
a todas las aplicaciones que hemos comentado en este proyecto.
Como conclusiones importantes podemos destacar todas las actividades de desarrollo que
a
un 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.

Conclusiones

Ap
endice A
C
odigo fuente - Iluminaci
on
A.1. Nodos pulsadores Iluminaci

on
El codigo de configuracion es com
un a todos los nodos.
1 includes EIBMsg ;
2
3 configuration eib {
4 }
5 implementation
6 {
7 components Main , eibM , GenericComm , LedsIntensityC , TimerC ;
8
9 Main . StdControl -> eibM ;
10 Main . StdControl -> LedsIntensityC ;
11
15
16 eibM . LedsIntensity -> LedsIntensityC ;
17 eibM . TimerMilli -> TimerC . TimerMilli [ unique (" TimerMilli ") ];
18
19 }
Codigo A.1: eib.nc

Ap
endice A. C
odigo fuente
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
40 signal ProcessCmd . done (m , SUCCESS ) ;
41 }
42
43
45
48 message - > dfisica = 0 xBB ;
50 call Send . send ( TOS_BCAST_ADDR , 8 , m ) ;

Ap
endice A. Aplicaciones de Iluminaci
on
51 }
52 else {
55 }
56 }
57
59
61 if (! pending1 )
62 {
63 pending1 = TRUE ;
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:
76 message - > datos = REGULACION_ABSOLUTA ;
break ;
77 }
78
79 switch ( valorAbs ) {
80 case 1:
81 message - > valor = VALOR_10 ; break ;
82 case 2:
84 case 3:
86 case 4:
88 case 5:
90 case 6:
92 case 7:
94 case 8:
96 case 9:
98 }

Ap
endice A. C
odigo fuente
100 atomic {
106 }
& data ) ;
109 }
110 }
111
112 task void e n v i a r P u l s a c i o n Larga () {
113
115 if (! pending1 )
116 {
119
120 switch ( funcionLarga ) {
121 case 1:
122 message - > datos = REGULAR_LUZ ; break ;
123 case 2:
124 message - > datos = REGULAR_OSCURIDAD ; break ;
125 }
127 atomic {
134 }
135 call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ;
137 }
138 }
139
140 task void enviarSTOPlarga () {
141
144 {
147 message - > datos = REGULAR_STOP ;
148

Ap
on
150 atomic {
157 }
160 }
161 }
162
164
165 m = & buf ;
167 pending2 = 0;
168 lastSeqno = 0;
170 retransmite = FALSE ;
171
172 tpulsado = 0;
173 tfrontera = 1500;
175
176
177 funcionCorta = 3;
178 funcionLarga = 1;
179 valorAbs = 5;
180 return call CommControl . init () ;
181 }
182
184 call TimerMilli . setPeriodic ( 100 ) ;
185 return call CommControl . start () ;
186 }
187
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 ;

Ap
endice A. C
odigo fuente
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 {
229 }
230 if ( status == SUCCESS ) bcast_pending = 0;
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 {
240 }
242 }
243
245 {
246 valorBoton = T O S H_ READ_BOTON_PIN () ;
247
248 if ( valorBoton == 0 x0000 ) {

Ap
on

253 } }
254 else {
257 tpulsado = 0;
258 }
259 else {
262 }
263 tpulsado = 0;
265 }
266 }
268 }
269 }
Codigo A.2: Nodo pulsador de iluminacion eibM.nc

Ap
endice A. C
odigo fuente
A.2. Nodos actuadores Iluminaci

on
eibM.nc
1 includes EIBMsg ;
2
3 module eibM {
4
5 provides {
8 }
9
10 uses {
16 }
17 }
18 implementation {
19 TOS_MsgPtr m ;
21 TOS_Msg buf ;
24 bool pending1 ;
25 TOS_Msg data ;
27
28 bool regular_luz ;
29 bool regular_sombra ;
30 int16_t intensidad ;
31 int16_t factor ;
32 bool valorLuz ;
33 bool estadozero ;
34 int16_t valorRecibido ;
35
37
39 message - > hop_count ++;
40
45 }
48 }

Ap
on
49 if ( message - > datos == ESCRIBIR_TOGGLE ) {

50 if (! valorLuz ) {
54 }
55 else {
58 intensidad = 0;
59 }
60 }
61 if ( message - > datos == REGULACION_ABSOLUTA ) {
62 valorRecibido = message - > valor ;
63 call LedsIntensity . set ( 0 x00 , valorRecibido ) ;
65 intensidad = valorRecibido ;
66 }
67
68 break ;
70 if ( message - > datos == REGULAR_LUZ ) {
71 regular_luz = TRUE ;
72 }
73 if ( message - > datos == RE GULAR_OSCURIDAD ) {
74 regular_sombra = TRUE ;
75 }
76 if ( message - > datos == REGULAR_STOP ) {
79 if (! estadozero ) {
81 }
82 else {
85 }
86 }
87 break ;
88 }
89 pending2 =0;
91 }
92
93
94
96

Ap
endice A. C
odigo fuente
102 }
103 else {
106 }
107 }
108
110 m = & buf ;
112 pending2 = 0;
113 lastSeqno = 0;
116
119 intensidad = 0;
120 factor = 15;
123 valorRecibido = 0;
125 }
126
130 }
131
135 }
136
138
lastSeqno ) ) ;
141 }
145 }
146
148

Ap
on

155 ret = m ;
156 m = pmsg ;
157 }
158 return ret ;
159 }
160
162 pending2 =1;
163 m = pmsg ;
166 }
167
169 {
171 {
173 }
176 }
177
result_t status ) {
179 m = pmsg ;
180 if ( status ) {
182 } else {
184 }
186 }
187
189 {
190 if ( regular_luz ) {
191 if ( intensidad < 255) {
192 intensidad = intensidad + factor ;
193 call LedsIntensity . set ( 0 x00 , intensidad ) ;
194 }
195 else {
198 }
199 }

Ap
endice A. C
odigo fuente
200 if ( regular_sombra ) {
201 if ( intensidad > 0) {
202 intensidad = intensidad - factor ;
203 call LedsIntensity . set ( 0 x00 , intensidad ) ;
204 }
205 else {
207 estadozero = TRUE ;
208 }
209 }
211 }
212 }
Codigo A.3: Nodo actuador de iluminacion eibM.nc

Ap
endice B
C
odigo fuente - Persianas
B.1. Nodos pulsadores Persianas

eibM.nc
1 includes EIBMsg ;
2
3 module eibM {
4
5 provides {
8 }
9
10 uses {
16 }
17 }
18 implementation {
19 TOS_MsgPtr m ;
21 TOS_Msg buf ;
24 bool pending1 ;
25 TOS_Msg data ;
27
28
29 int16_t valorBoton ;
30 int16_t tpulsado ;
31 int16_t tfrontera ;
32 bool enviadaLarga ;
33 int8_t funcionBoton ;
34

Ap
endice B. C
odigo fuente
35
36 /*******************************/
37
40 }
41
43
49 }
50 else {
53 }
54 }
55
57
59 if (! pending1 )
60 {
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 }
73 atomic {
79 }
& data ) ;
82 }
83 }
84

Ap
endice B. Aplicaciones de Persianas
85
86 task void e n v i a r P u l s a c i o n Larga () {
87
89 if (! pending1 )
90 {
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 }
103 atomic {
110 }
// Env
o
113 }
114 }
115
117
118 m = & buf ;
120 pending2 = 0;
121 lastSeqno = 0;
124
125 tpulsado = 0;
126 tfrontera = 1500;
128
129 funcionBoton = 2;
130
132 }
133
134

Ap
endice B. C
odigo fuente

138 }
139
143 }
144
146
lastSeqno ) ) ;
149 }
153 }
154
156
163 ret = m ;
164 m = pmsg ;
165 }
166 return ret ;
167 }
168
170 pending2 =1;
171 m = pmsg ;
174 }
175
177 {
179 {
181 }
184 }

Ap
185
result_t status ) {
187 m = pmsg ;
188 if ( status ) {
190 } else {
192 }
194 }
195
197 {
198 valorBoton = T O S H_ READ_BOTON_PIN () ;
199
200 if ( valorBoton == 0 x0000 ) {
205 } }
206 else {
209 tpulsado = 0;
210 }
211 else {
214 }
215 tpulsado = 0;
217 }
218 }
220 }
221 }
Codigo B.1: Nodo pulsador de persianas eibM.nc

Ap
endice B. C
odigo fuente
B.2. Nodos actuadores Persianas

eibM.nc
1 includes EIBMsg ;
2
3 module eibM {
4
5 provides {
8 }
9
10 uses {
16 }
17 }
18 implementation {
19 TOS_MsgPtr m ;
21 TOS_Msg buf ;
24 bool pending1 ;
25 TOS_Msg data ;
27
28 bool paso_subir ;
29 bool paso_bajar ;
30 bool total_subir ;
31 bool total_bajar ;
32
33 int16_t tcounter ;
34 int16_t tpaso ;
35 int16_t ttotal ;
36 int16_t twait ;
37 bool wait ;
38
40
42 message - > hop_count ++;
43
47
48 if ( total_subir || total_bajar ) {

Ap
53 }
54 else {
55 paso_subir = TRUE ;
57 tcounter = 0;
58 }
59 }
60
62
63 if ( total_bajar || total_subir ) {
68 }
69 else {
71 paso_bajar = TRUE ;
72 tcounter = 0;
73 }
74 }
75 break ;
76
79 total_subir = TRUE ;
80 if ( total_bajar ) { wait = TRUE ;}
82 tcounter = 0;
84 }
85
87 total_bajar = TRUE ;
88 if ( total_subir ) { wait = TRUE ;}
90 tcounter = 0;
92 }
93 break ;
94 }
95 pending2 =0;
97 }
98

Ap
endice B. C
odigo fuente
100
106 }
107 else {
110 }
111 }
112
114 m = & buf ;
116 pending2 = 0;
117 lastSeqno = 0;
120
125
126 tcounter =0;
127 tpaso = 1000;
128 ttotal = 5000;
129 twait = 1000;
130 wait = FALSE ;
132 }
133
137 }
138
142 }
143
145
lastSeqno ) ) ;
148 }

Ap

152 }
153
155
162 ret = m ;
163 m = pmsg ;
164 }
165 return ret ;
166 }
167
169 pending2 =1;
170 m = pmsg ;
173 }
174
176 {
178 {
180 }
183 }
184
result_t status ) {
186 m = pmsg ;
187 if ( status ) {
189 } else {
191 }
193 }
194
195
197 {
198 if ( paso_subir ) {

Ap
endice B. C
odigo fuente

201
205 tcounter = 0;
206 }
207 }
208
209 if ( paso_bajar ) {
213
218 tcounter = 0;
219 }
220 }
221
222 if ( total_subir ) {
224
225 if ( wait ) {
228
232 tcounter = 0;
233 wait = FALSE ;
234 }
235 }}
236 else {
241 tcounter = 0;
242 }
243 }
244 }
245
246 if ( total_bajar ) {
248 if ( wait ) {

Ap

256 tcounter = 0;
257 wait = FALSE ;
258 }
259 }
260 }
261 else {
268 tcounter = 0;
269 }}
270 }
272 }
273 }
Codigo B.2: Nodo actuador de persianas eibM.nc

Ap
endice C. C
odigo fuente

Ap
endice C
C
odigo fuente - Sensores
C.1. Nodo Sensor Crepuscular

Los codigos de configuracion Sense.nc y eib.nc son comunes a todos los nodos.
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

Ap
endice C. C
odigo fuente
eib.nc
1 includes EIBMsg ;
2 configuration eib {
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 ;
16 eibM . Leds -> LedsC . Leds ;
18 }
Codigo C.2: eib.nc

Ap
endice C. Aplicaciones de Sensores
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
26 return call Leds . init () ;
27 }
28
30 return call Timer . start ( TIMER_REPEAT , 2000) ;
31 }
32
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

Ap
endice C. C
odigo fuente
eibM.nc
1 includes EIBMsg ;
2 module eibM {
3 provides {
4 interface IntOutput ;
7 }
8 uses {
11 interface Leds ;
13 }
14 }
15 implementation {
16 TOS_MsgPtr m ;
18 TOS_Msg buf ;
21 bool pending1 ;
22 TOS_Msg data ;
24
25 int16_t intensidad ;
26
27
30 }
31
33
39 }
40 else {
43 }
44 }
45
47 m = & buf ;
49 pending2 = 0;
50 lastSeqno = 0;

Ap
53 intensidad = 0;
55 }
56
59 }
60
63 }
64
66
lastSeqno ) ) ;
69 }
73 }
74
76
83 ret = m ;
84 m = pmsg ;
85 }
86 return ret ;
87 }
88
90 pending2 =1;
91 m = pmsg ;
93 return SUCCESS ;
94 }
95
96 command result_t IntOutput . output ( uint16_t value )
97 {
98 if ( value > 7) {
99

Ap
endice C. C
odigo fuente

102 intensidad = 0;
104 {
110 atomic {
117 }
118 if ( call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , &
data ) )
120 pending1 = FALSE ; }
121 }
122 }
123
124 else if ( value == 7 ) {
129 {
135 atomic {
141 message - > seguridad = 255; }
data ) )
145 }
146 }
147 }
148
149 [...]

Ap
150
151 else if ( value == 0 ) {
156 {
162 atomic {
168 message - > seguridad = 255; }
data ) )
172 }
173 }
174 }
175 return FAIL ;
176 }
177
178
180 {
182 {
184 signal IntOutput . outputComplete ( SUCCESS ) ;
185 }
188 }
189
result_t status ) {
191 m = pmsg ;
192 if ( status ) {
194 } else {
196 }
198 }

Ap
endice C. C
odigo fuente
199
200 default event result_t IntOutput . outputComplete ( result_t
success ) {
202 }
203 }
Codigo C.4: eibM.nc
DemoSensor2C.nc
1 configuration DemoSensor2C
2 {
3 provides interface ADC ;
5 }
6 implementation
7 {
8 components HamamatsuC as DemoSensor ;
9
10 StdControl = DemoSensor ;
11 ADC = DemoSensor ;
12 }
Codigo C.5: DemoSensor2C.nc

Ap
endice D
Diagramas Nesdoc
D.1. Diagrama completo de Iluminaci

on y Persianas
A continuacion, adjutamos el diagrama completo, generado por la herramienta Nesdoc,
de las aplicaciones programadas de iluminacion y persianas.
El diagrama es similar para las aplicaciones de iluminacion y persianas, tanto para los
nodos configurados como pulsadores como los nodos configurados como actuadores.

Ap
endice D. Diagramas Nesdoc

Ap
D.2. Diagrama completo de Sensores

Adjuntamos el diagrama completo, generado por la herramienta Nesdoc, de las aplica-
ciones que configuran un nodo como sensor crepuscular.

Ap

Ap
endice E
Hardware Telos rev.B

Ap
endice E. Hardware Telos
E.1. Telos

Ap
E.2. Telos - CC240 802.15.4 Wireless Radio

Ap
E.3. Telos - USB Interface

Bibliografa
[1] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam y E. Cayirci, A Survey on Sensor Net-

works, IEEE Commun. Mag., August 2000.
[2] Mainwaring, A., Polastre, J., Szewczyk, R., Culler, D., y Anderson, J. Wireless Sensor
Networks for Habitat Monitoring., ACM International Workshop on Wireless Sensor
Networks and Applications, September 2002.
[3] Pottie, J. and Kaiser, W. J. Wireless Integrated Network Sensors, Communications of
the ACM, Vol. 43, no. 5, May 2000.
[4] Schwiebert, L., Gupta, S. K. S., and Weinmann, J. Research Challenges in Wireless
Networks of Biomedical Sensors, International Conference on Mobile Computing and
Networking, 2001.
[5] Shen, C., Srisathapornphat, C., and Jaikaeo, C. Sensor Information Networking Archi-
tecture and Applications, IEEE Pers. Commun., August 2001.
[6] Sorabi, K., Gao, J., Ailawadhu, V., and Pottie, J. Protocols for Self-Organization of a
Wireless Sensor Network IEEE Pers. Commun., October 2000.
[7] Srivastava, M., Muntz, R., and Potkonjak, M. Smart Kindergarten: Sensor-based Wire-
less Networks for Smart Developmental Problem-solving Environments, International
Conference on Mobile Computing and Networking, 2001.
[8] M. Jimenez, Caso de estudio: Redes de sensores/actuadores WSAN para automatizaci on
de viviendas y edificios, Universidad Politecnica de Cartagena, Dpto. Tecnologa Elec-
tronica, 2006.
[9] M. Weiser, The computer for the 21st century., Scientific American, vol. 265, no 3, pp.
94-104, September 1991.
[10] Telefonica, Libro Blanco del Hogar Digital y las Infraestructuras Comunes de Teleco-
municaci on
http://www.telefonica.es/indez/libroblancohogardigital.html
[11] M. Soledad Escolar Daz Wireless Sensor Networks: Estado del arte e Investigaci
on,
2006
[12] S. Helal, B. Winler, C. Lee, Y. Kaddoura, L. Ran, C. Giraldo, S. Kuchibhotla y W.
Mann, Enabling Location-Aware Pervasive Computing Applications for the Edlerly,
Pervasive Computing and Communications, 2003. (PerCom 2003). Proceedings for the
first IEEE International Conference on, 23-26 March 2003.
[13] J. Zheng y M.J. Lee, Will IEEE 802.15.4 Make Ubiquitous Networking a Reality?: A
Discussion on a Potential Low Power, Low Bit Rate Standard , IEEE Communications
Magazine, pp. 140-146, June 2004.

Bibliografa
[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.
[17] EIA Standard EIA-709.1, Control Network Protocol Specification, 1999.
[18] EIA Standard EIA-600.10, Introduction to the CEBus Standard , 1999.
[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.
[25] J. M. Quinteiro, J. Lamas, J. D. Sandoval. Sistemas de control para viviendas y edificios:

Domotica, Paraninfo. 1999.
[26] Manual del ABB i-bus EIB , Niessen, 2002.
[27] KNX Projects: Terminal 5 Heathrow in London, KNX Projects Awards 2006. KNX
Journal, no 2, pp. 3-16, 2006.
[28] Asociaci
on EIB Espa
na, 2007.
http://www.eiba-es.com/
[29] Konnex Association, Estandar Konnex para control de viviendas y edificios, 2007.
http://www.konnex.org/
[30] Futurasmus, S.L., Especialistas en KNX/EIB, 2007.

http://www.futurasmus.es/
[31] EIB Shop Spain, Distribucion de productos KNX/EIB, 2007.

http://www.eibshop-spain.com/
[32] Casadomo, Portal de la domotica y el hogar digital, 2007.

http://www.casadomo.com

Bibliografa
[33] Domotica.net, 2007.

http://www.domotica.net
[34] Domodesk, todo en dom otica de f

acil instalaci
on. Empresa distribuidora, mayorista e
instaladora de productos domoticos, 2007.
http://www.domodesk.com/
[35] Domotium, la dom

otica a otro nivel . Domotium, marca de lujo de Domodesk, 2007.
http://www.domotium.com/
[36] Situacion actual de la domotica y legislacion, 2007.

http://legislaciones.iespana.es/domotica.htm
[37] Inmom atica, domotica y tecnologa para vivir . Control integral de edificios y viviendas.
Tecnologa para el hogar, 2007.
http://www.inmomatica.com/
[38] Royal Philips Electronics - Pronto, 2007.

http://www.pronto.philips.com/
[39] CEBus. Distribuidores de la tecnologa CEBus, 2007.

http://www.intellon.com/
[40] Echelon Corporation, embedded control networking technology.Echelon, compa na lder

en sistemas integrados de redes de control y creadores de la plataforma LonWorks, 2007.
http://www.echelon.com/
[41] TinyOS Community Forum. An open-source OS for the networked sensor regime,
2007.
http://www.tinyos.net
[42] Grupo de investigaci

on nesC , 2007.
http://nesc.sourceforge.net
[43] Crossbow technology Inc. Crossbow: Wireless Sensor Network, 2007.

http://www.xbow.com/
[44] Zigbee Alliance. Wireless control that simply works, 2007.

http://www.zigbee.org/
[45] MoteIV . A leading provider of wireless sensor networking solutions, 2007.

http://www.moteiv.com/
[46] Making sense of Sensor Networks. Crossroads - The ACM Student Magazine, 2007.
http://www.acm.org/crossroads/xrds9-4/sensornetworks.html
[47] Berkeley WEBS . Wireless Embedded System, 2007.

http://webs.cs.berkeley.edu/
[48] Schneider Electric. Worlds power and control specialist, 2007.

http://www.schneider-electric.com/wps/portal/corp/

Bibliografa
[49] Matradi, S.L.. Perspectivas 3D de proyectos de arquitectura e ingeniera, 2007.

http://www.matradi.com/english/3D_House_Plans.htm
[50] CENS . Center for embedded networked sensing, 2007.

http://www.cens.ucla.edu/
[51] BTnode Platform. A distributed environment for prototyping Ad Hoc Networks, 2007.
http://btnode.ethz.ch/
[52] FPS . Network Power Scheduling for WSN, 2007.

http://barbara.stattenfield.org/fps/
[53] Great Duck Island . WSN Project, 2007.

http://www.greatduckisland.net/
[54] TinyDB . A Declarative Database for Sensor Networks, 2007.

http://telegraph.cs.berkeley.edu/tinydb/
[55] Royal Philips Electronics - Pronto, 2007.

http://www.cbe.berkeley.edu/research/briefs-wirelessxyz.htm
[56] Control4 . Welcome to the Digital Home, 2007.

http://www.control4.com/
[57] DAI, Dom otica y Ambientes Inteligentes. Grupo de Domotica y Ambientes Inteligentes
del Departamento de Tecnologa Informatica y Computacion de la Universidad de Ali-
cante, 2007.
http://www.dtic.ua.es/dai/

PFC 2164

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PFC 2164

Cargado por

Copyright:

Formatos disponibles

ESCUELA TECNICA SUPERIOR DE INGENIERIA DE TELECOMUNICACION

UNIVERSIDAD POLITECNICA DE CARTAGENA

Proyecto Fin de Carrera

Las redes de sensores inalambricas estan experimentando un gran crecimiento

Titulacion Ingeniero de Telecomunicacion

Proyecto Final de Carrera 2

A mis directores de proyecto

A todos los que, de alguna forma, me han ayudado

Por vuestro apoyo, paciencia y confianza, gracias

La recompensa se encuentra en el esfuerzo y no en el resultado.

Proyecto Final de Carrera 3

Proyecto Final de Carrera 5

VI.1. Ejemplo Proyecto KNX/EIB . . . . . . . . . . . . . . . . . . . . . . . 73

Parte II. Redes de sensores inal

Redes de sensores inal

Parte III. Proyecto de integraci

Proyecto Final de Carrera 6

D. Diagramas Nesdoc 205

E. Hardware Telos rev.B 209

Proyecto Final de Carrera 7

Proyecto Final de Carrera 8

Proyecto Final de Carrera 9

41. Resolucion de colisiones CSMA/CD en EIB . . . . . . . . . . . . . . . . . . . 63

1. Red de sensores inalambrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Proyecto Final de Carrera 10

1. Arquitectura WSAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Proyecto Final de Carrera 11

Proyecto Final de Carrera 12

I.1. Tipos EIS normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

III.1. Valores e intensidades de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Proyecto Final de Carrera 13

Proyecto Final de Carrera 14

La dom otica, definida como la automatizacion de viviendas y edificios, es una de las

Proyecto Final de Carrera 15

Proyecto Final de Carrera 16

La dom otica y los edificios inteligentes.

Las redes de sensores inal ambricas.

En primer lugar, analizaremos los sistemas domoticos, sus caractersticas, prestaciones y

Ademas, se realizara una parte de montaje a

Proyecto Final de Carrera 17

Proyecto Final de Carrera 18

Proyecto Final de Carrera 19

Desde el punto de vista tecnologico, la definicion podra ser la siguiente: es aquella en la

Proyecto Final de Carrera 21

El uso de las TIC (Tecnologas de la Informacion y las Comunicaciones) en la vivienda

Automatizacion de tareas domesticas

Comunicacion con servidores externos

Operacion y mantenimiento de las instalaciones

La introduccion de todos estos sistemas y tecnologas en el hogar aun no es una realidad,

Figura 1: Casa domotica

Proyecto Final de Carrera 22

Proyecto Final de Carrera 23

Figura 2: Pasarela residencial

Los sistemas de control: en instalaciones centralizadas, son los dispositivos encarga-

Proyecto Final de Carrera 24

Figura 3: Detectores de presencia

3. Volum etricos de presencia.

Proyecto Final de Carrera 25

Infrarrojos. Detectan las radiaciones infrarrojas, siendo sensibles a las varia-

Proyecto Final de Carrera 26

10. Detectores de lluvia.

Figura 5: Actuador de carril DIN

Dependiendo de cada solucion o fabricante, hay equipos que son controladores/sensores/ac-