Sensores Inalambricos

ESCUELA TECNICA SUPERIOR DE INGENIER IA DE TELECOMUNICACION UNIVERSIDAD POLITECNICA DE CARTAGENA
Proyecto Fin de Carrera
n de Programacio mbricas para Redes de Sensores Inala moticas aplicaciones do
Autor Pedro Jos e Meseguer Copado Directores D. Manuel Jim enez Buend a D. Fernando Losilla L opez
Marzo de 2007
Autor eMail del Autor Directores eMail de los Directores T tulo del PFC Descriptores Resumen
Pedro Jos e Meseguer Copado pedro.meseguer@gmail.com Manuel Jim enez Buend a Fernando Losilla L opez manuel.jimenez@upct.es fernando.losilla@upct.es Programaci on de Redes de Sensores Inal ambricas para aplicaciones dom oticas Dom otica, Redes de sensores inal ambricas
Las redes de sensores inal ambricas est an experimentando un gran crecimiento en los u ltimos a nos, desarroll andose en aplicaciones de diversos ambitos como la medicina, bot anica, militares, etc. La dom otica, entendida como automatizaci on de viviendas y edicios, es uno de los campos de aplicaci on 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 dom otica: seguridad, ahorro energ etico, comunicaciones y confort. Este proyecto parte de estas bases y est a centrado en la programaci on de aplicaciones dom oticas de iluminaci on, persianas y sensores, para motes inal ambricos del tipo Telos rev.B, bas andose en los protocolos y criterios de la tecnolog a dom otica EIB.
Titulaci on Intensicaci on Departamento Fecha de Presentaci on
Ingeniero de Telecomunicaci on Sistemas y Redes de Telecomunicaci on Departamento de Tecnolog a Electr onica Marzo de 2007
Proyecto Final de Carrera
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 conanza, 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 Indice de Figuras Indice de Tablas 7 11 13
Introducci on
I. II. Presentaci on . Objetivos . . . II.1. Objetivo II.2. Objetivo . . . . . . . . . . . . Te orico . Pr actico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15 17 17 17
Parte I. Dom otica Dom otica

I. II. Generalidades . . . . . . . . . . . . . Caracter sticas . . . . . . . . . . . . II.1. El sistema . . . . . . . . . . . II.2. Arquitectura . . . . . . . . . II.3. Topolog as . . . . . . . . . . II.4. Medios de Transmisi on . . . . III. Funcionalidad de la dom otica . . . . III.1. Control energ etico . . . . . . III.2. Seguridad . . . . . . . . . . . III.3. Confort . . . . . . . . . . . . III.4. Telecomunicaciones . . . . . . IV. Tecnolog as existentes . . . . . . . . IV.1. CEBus . . . . . . . . . . . . . IV.2. X-10 . . . . . . . . . . . . . . IV.3. LonWorks . . . . . . . . . . . IV.4. EHS . . . . . . . . . . . . . . IV.5. Batibus . . . . . . . . . . . . V. Sistema EIB . . . . . . . . . . . . . . V.1. Introducci on . . . . . . . . . V.2. Tecnolog a . . . . . . . . . . . V.3. Topolog a . . . . . . . . . . . V.4. Direccionamiento . . . . . . . V.5. Formato de las transmisiones V.6. Componentes EIB . . . . . . V.7. Ventajas de EIB. Ejemplos de VI. Est andar Konnex . . . . . . . . . . . Proyecto Final de Carrera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . aplicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 21
21 24 24 28 30 31 33 33 34 35 36 37 39 41 48 51 54 55 55 57 59 60 63 67 69 71 5
INDICE GENERAL
VI.1.
Ejemplo Proyecto KNX/EIB . . . . . . . . . . . . . . . . . . . . . . .
73
Parte II. Redes de sensores inal ambricas Redes de sensores inal ambricas
I. II. Introducci on . . . . . . . . . . . . . . . . I.1. Historia . . . . . . . . . . . . . . Caracter sticas de las WSN . . . . . . . II.1. Arquitecturas de las WSN . . . . II.2. Protocolos de las WSN . . . . . II.3. Zigbee, est andar WSN . . . . . . II.4. Problemas de las WSN . . . . . . Aplicaciones de las WSN . . . . . . . . . III.1. Aplicaciones militares . . . . . . III.2. Aplicaciones medioambientales . III.3. Aplicaciones sanitarias . . . . . . III.4. Aplicaciones del hogar: dom otica III.5. Otras aplicaciones comerciales . Nodos sensores . . . . . . . . . . . . . . Ejemplos de motes: Micas y Telos . . . . V.1. Micas . . . . . . . . . . . . . . . V.2. Telos . . . . . . . . . . . . . . . . V.3. Resumen comparativo . . . . . . TinyOS . . . . . . . . . . . . . . . . . . VI.1. nesC . . . . . . . . . . . . . . . . VI.2. Herramientas de TinyOS . . . . Futuro de las WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77 77
77 78 80 83 84 87 89 90 92 93 94 94 95 96 100 100 105 107 109 111 113 116
III.
IV. V.
VI.
VII.
Parte III. Proyecto de integraci on de WSN y dom otica Proyecto de integraci on de WSN y dom otica
I. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . I.1. WSAN . . . . . . . . . . . . . . . . . . . . . . . . . . I.2. Ventajas de la dom otica inal ambrica . . . . . . . . . I.3. Soluciones existentes . . . . . . . . . . . . . . . . . . II. Escenario del proyecto . . . . . . . . . . . . . . . . . . . . . III. Programaci on de las aplicaciones dom oticas . . . . . . . . . III.1. Aplicaciones de iluminaci on . . . . . . . . . . . . . . III.2. Aplicaciones de persianas . . . . . . . . . . . . . . . III.3. Aplicaci on de sensor crepuscular . . . . . . . . . . . IV. Ejemplo de aplicaci on: Vivienda con conguraci on est atica . V. Conguraci on de los puertos de expansi on de TelosB . . . . V.1. Conguraci on hardware . . . . . . . . . . . . . . . . V.2. Programaci on de los puertos . . . . . . . . . . . . . VI. Perspectivas de futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
121 121
121 122 123 125 126 128 134 151 157 160 162 163 164 168
Conclusiones Ap endices
171 173
6
INDICE GENERAL
A. C odigo fuente - Iluminaci on 173 A.1. Nodos pulsadores Iluminaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 A.2. Nodos actuadores Iluminaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Iluminaci on 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
Bibliograf a
213
Indice General
Indice de Figuras
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. Casa dom otica . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pasarela residencial . . . . . . . . . . . . . . . . . . . . . . . . . . Detectores de presencia . . . . . . . . . . . . . . . . . . . . . . . Anem ometro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actuador de carril DIN . . . . . . . . . . . . . . . . . . . . . . . Sistema centralizado . . . . . . . . . . . . . . . . . . . . . . . . . Sistema distribuido, con bus de datos y red de alimentaci on . . . Sistemas cableados o inal ambricos . . . . . . . . . . . . . . . . . Control energ etico . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema de alarmas t ecnico . . . . . . . . . . . . . . . . . . . . . Control mediante pantalla t actil . . . . . . . . . . . . . . . . . . . Controlador pronto de Philips . . . . . . . . . . . . . . . . . . . . Sistemas en funci on del tama no de edicaci on . . . . . . . . . . . Normalizaci on de los sistemas dom oticos . . . . . . . . . . . . . . Arquitectura de CEBus, tomando como referencia el modelo OSI Instalaci on X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Codicaci on de bits en X10 . . . . . . . . . . . . . . . . . . . . . C odigo de comienzo 1110 . . . . . . . . . . . . . . . . . . . . . . Paquete de datos X10 . . . . . . . . . . . . . . . . . . . . . . . . C odigos de casa y de control para unidad . . . . . . . . . . . . . C odigos de control para comandos . . . . . . . . . . . . . . . . . Ciclos para una transmisi on completa en X10 . . . . . . . . . . . Dispositivos X-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . Accesorios X-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocolos LonWorks y equivalente OSI . . . . . . . . . . . . . . Dominio LonTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . Trama de LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . Instalaci on LonWork . . . . . . . . . . . . . . . . . . . . . . . . . Caracter sticas de los medios de transmisi on en EHS . . . . . . . Tramas EHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bus EIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esquema general de una instalaci on EIB . . . . . . . . . . . . . . Conexi on de alimentaci on y dispositivos al bus . . . . . . . . . . Generaci on de corriente portadora sobre tensi on de alimentaci on Distintas topolog as de EIB . . . . . . . . . . . . . . . . . . . . . Sistema completo EIB . . . . . . . . . . . . . . . . . . . . . . . . Direcci on f sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ejemplo de direccionamiento f sico . . . . . . . . . . . . . . . . . Niveles en las direcciones de grupo . . . . . . . . . . . . . . . . . Ejemplo de asignaci on de direcciones de grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 24 25 26 27 28 29 30 33 34 35 36 37 38 39 41 43 43 44 44 44 45 46 47 48 49 50 50 51 53 56 57 58 58 59 59 60 60 61 62 9
Indice General
41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
Resoluci on de colisiones CSMA/CD en EIB . . . Formato de la trama EIB . . . . . . . . . . . . . Formato del campo de control . . . . . . . . . . . Formato del campo de direcci on destino . . . . . Formato del campo de datos . . . . . . . . . . . . Campo de comprobaci on de la trama . . . . . . . Componentes de un dispostivo EIB . . . . . . . . Componentes y objetos de comunicaci on en ETS Konnex . . . . . . . . . . . . . . . . . . . . . . . Terminal 5 de Heathrow . . . . . . . . . . . . . . Red de sensores inal ambrica . . . . . . . . . Tama no de los nodos Smart Dust . . . . . . Elementos de una WSN . . . . . . . . . . . Arquitectura WSN centralizada . . . . . . . Arquitectura WSN distribuida . . . . . . . Niveles f sico, red y aplicaci on . . . . . . . . Comparativa est andares inal ambricos . . . . Espectro de est andares . . . . . . . . . . . . Aplicaciones Zigbee . . . . . . . . . . . . . . Aplicaciones para WSN . . . . . . . . . . . Tracking de animales . . . . . . . . . . . . . Reconocimiento del enemigo . . . . . . . . . Desplegue de sensores para reconocimientos Detecci on de incendios . . . . . . . . . . . . Aplicaci on dom otica . . . . . . . . . . . . . Nodos sensores . . . . . . . . . . . . . . . . Comparaci on plataformas para nodos . . . . Estados de un nodo sensor . . . . . . . . . . Distribuci on del consumo de energ a . . . . Estructura de red y motes . . . . . . . . . . Micaz . . . . . . . . . . . . . . . . . . . . . Diagrama de bloques Micaz . . . . . . . . . Caracter sticas t ecnicas de Micas . . . . . . Mica2 . . . . . . . . . . . . . . . . . . . . . Diagrama de bloques Mica2 . . . . . . . . . Mica2dot . . . . . . . . . . . . . . . . . . . Diagrama de bloques Mica2dot . . . . . . . Sensores MTS300 . . . . . . . . . . . . . . . Tipos de sensores para Micas . . . . . . . . TelosB . . . . . . . . . . . . . . . . . . . . . Diagrama de bloques TelosB . . . . . . . . . Evoluci on de los motes . . . . . . . . . . . . Comparativa de tiempos y consumos . . . . Estructura de un componente . . . . . . . . Ficheros de una aplicaci on . . . . . . . . . . TinyViz . . . . . . . . . . . . . . . . . . . . Surge View . . . . . . . . . . . . . . . . . . TinyDB . . . . . . . . . . . . . . . . . . . . Twister . . . . . . . . . . . . . . . . . . . . T unel WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63 64 64 64 65 66 67 68 71 73 77 79 80 83 84 86 87 88 88 90 91 92 92 93 94 96 97 99 99 100 101 101 101 102 102 103 103 104 104 105 105 107 107 111 112 113 114 115 117 117 10
INDICE DE FIGURAS
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Arquitectura WSAN . . . . . . . . . . . . . . . . . Casa dom otica . . . . . . . . . . . . . . . . . . . . Control4 . . . . . . . . . . . . . . . . . . . . . . . . Vivienda escenario . . . . . . . . . . . . . . . . . . Relaci on de componentes en Blink . . . . . . . . . Aplicaci on Oscilloscope . . . . . . . . . . . . . . . Aplicaci on SerialForwarder y captura de mensajes Ejemplo de telos sensores y actuadores . . . . . . . Diagrama de eib.nc . . . . . . . . . . . . . . . . . . Diagrama de TimerC . . . . . . . . . . . . . . . . . Algoritmo de Timer . . . . . . . . . . . . . . . . . Ejemplo de telos en aplicaci on de persianas . . . . Algoritmo de movimiento de paso . . . . . . . . . . Algoritmo de movimiento total . . . . . . . . . . . Diagrama Sense.nc . . . . . . . . . . . . . . . . . . Sensor crepuscular . . . . . . . . . . . . . . . . . . Vivienda con motes distribuidos . . . . . . . . . . . Estancia con motes congurados . . . . . . . . . . Detalle de componentes TelosB . . . . . . . . . . . Conectores de expansi on TelosB . . . . . . . . . . . Esquem atico para botones y leds . . . . . . . . . . TelosB con leds y botones . . . . . . . . . . . . . . TelosB con expansiones . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
122 123 125 126 131 133 133 135 137 138 141 152 153 155 157 158 160 161 162 163 163 167 167
11
Indice de Figuras
12
Indice de Tablas
I.1. Tipos EIS normalizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
III.1. Valores e intensidades de luz . . . . III.2. Tabla conguraci on de motes . . . . III.3. Correspondencia de se nales y puertos III.4. Conguraci on de direcciones de pines
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
159 160 163 166
13
Indice de Tablas
14
Introducci on
I. Presentaci on
En los u ltimos a nos estamos asistiendo a un incremento vertiginoso de la presencia de las comunicaciones inal ambricas en nuestra sociedad. As , existen diferentes tecnolog as que utilizamos cada d a dependiendo de la aplicaci on a la que est en destinadas. No s olo el tel efono m ovil se ha convertido en imprescindible, tambi en para muy corto alcance se est a imponiendo el uso de Bluetooth, por ejemplo. Existen multitud de dispositivos como PDAs, manos libres, veh culos, etc. que ya disponen de esta tecnolog a. Por otro lado, si queremos disponer de comunicaciones en un ambito local sin necesidad de cables, existen diferentes tecnolog as como las WiFi. En denitiva, la sociedad va descubriendo las ventajas de los entornos inal ambricos y en un futuro pr oximo aparecer an nuevas aplicaciones, incluso algunas a un no imaginadas. Una vez introducido este tipo de tecnolog as en la sociedad, comienzan a aparecer sistemas y servicios basados en tecnolog as inal ambricas, mejor andose los procedimientos que tradicionalmente requer an una interacci on 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 Sensores. Los sensores son fuentes de informaci on tan variados como lo son las medidas que realizan. Los hay de temperatura, de luminosidad, de presi on, de humedad, de velocidad, de aceleraci on, de presencia, de volumen y un sinf n de magnitudes que se nos ocurran. Si a estos sensores que nos reportan informaci on valiosa para nuestras vidas, les a nadimos la capacidad de comunicaci on inal ambrica y la posibilidad de formaci on de redes, obtenemos las Redes de Sensores Inal ambricas, que est an teniendo un auge cada vez mayor debido principalmente a la multitud de aplicaciones que se est an desarrollando, como aplicaciones de seguimiento, de seguridad, de salud, de gesti on, etc. La dom otica, denida como la automatizaci on de viviendas y edicios, es una de las aplicaciones m as atractivas de las redes de sensores inal ambricas por diversos motivos. En primer lugar, supone un medio econ omico de introducir los sensores y actuadores necesarios para la automatizaci on con bajo impacto para la arquitectura de un edicio. Adem as, su bajo coste permitir a desplegar cientos de nodos que se podr an integrar en nuestra vida diaria y permitir la denominada computaci on ubicua, que consiste en la gesti on de entornos inteligentes en el interior de edicios y viviendas basados en la determinaci on y predicci on de la localizaci on de usuarios. As , los dispositivos de la vivienda ser an capaces de comunicarse entre s y cooperar entre ellos, lo que permitir a congurar la casa para que la intensidad de luz baje autom aticamente 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 energ etico del consumo, mantener un sistema de seguridad en la vivienda monitorizado a distancia o cualquier comunicaci on con otro tipo de redes multimedia o Internet.
15
Introducci on
El presente proyecto abarca estos dos grandes campos a un sin relacionar pr acticamente: la dom otica y las redes de sensores inal ambricas. Las instalaciones dom oticas basadas y controladas mediantes dispositivos inal ambricos es un area en estudio y poco desarrollada por el momento, pero es considerada como el futuro de la dom otica, por las facilidades y prestaciones que aporta y que, como ocurre con las nuevas tecnolog as, tras una adaptaci on a la sociedad y mercado, experimentar a un crecimiento y asentamiento en nuestros hogares. Implementaremos una serie de aplicaciones dom oticas que integraremos en sensores de una red, program andolos y congur andolos, de tal forma que logremos crear una red inal ambrica de sensores que tenga como funcionalidad el control de aspectos de una vivienda como la iluminaci on, las persianas o la climatizaci on. Nuestro objetivo nal es poder crear entornos inteligentes en una vivienda. Este concepto muestra una visi on de la Sociedad de la Informaci on en el que se enfatiza la facilidad de uso, el soporte eciente 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 m as que a trav es de los resultados. Nuestra convicci on es que esto se har a realidad gracias a la integraci on de las redes de sensores en el ambito de la vivienda inteligente. Aunque las posibilidades que ofrece la tecnolog a son ya muy atractivas, es innegable que son necesarias m as y mejores aplicaciones. Los cambios tecnol ogicos m as 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 tecnolog as en el hogar es permitir que las facilidades que ofrece se integren en la existencia cotidiana y la hagan m as c omoda, pero de manera que estos cambios no precisen un esfuerzo por parte de los usuarios.
16
II Objetivos
II.
II.1.
Objetivos
Objetivo Te orico
El objetivo te orico del proyecto es conocer e investigar en profundidad los dos puntos principales que abarcamos: La dom otica y los edicios inteligentes. Profundizar en las distintas tecnolog as 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 inal ambricos existentes hoy en d a en el mercado, concretamente en los micas y telos que utilizaremos para el proyecto, as como sus lenguajes de programaci on y aplicaciones que proporcionan. El sistema dom otico en el que nos basaremos ser a la tecnolog a EIB, siguiendo su protocolo de conguraci on y transmisi on de mensajes. Los sensores que utilizaremos ser an los TelosB de Crossbow que, como veremos, nos proporcionar an unas caracter sticas id oneas para este tipo de aplicaciones. En primer lugar, analizaremos los sistemas dom oticos, sus caracter sticas, prestaciones y las distintas tecnolog as existentes en el mercado, realizando una descripci on m as extensa del sistema EIB. A continuaci on, abarcaremos las redes de sensores inal ambricas, explicando sus caracter sticas y las aplicaciones m as importantes en las que est an destinadas actualmente. Adem as, veremos los tipos de sensores existentes, centr andonos en los TeloB y en el sistema de programaci on que utilizan. Finalmente, desarrollaremos el tema fundamental de nuestro proyecto: las redes aplicadas a dom otica. 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 pr actico consistir a en realizar un ejemplo de conguraci on de una vivienda dom otica basada en estos dispositivos inal ambricos. Por tanto, conllevar a el dise no y la programaci on de aplicaciones siguiendo un modelo de tecnolog a dom otica (el sistema EIB) y posterior implantaci on en los sensores. A modo de ejemplo, tomaremos como escenario una vivienda unifamiliar en la que podremos integrar estos sensores congurados con las aplicaciones que desarrollemos. Veremos c omo se programar an dichas aplicaciones en funci on de la conguraci on de la vivienda y las prestaciones que queramos obtener. Adem as, se realizar a una parte de montaje a nadida a los sensores TelosB, con el dise no de una placa adjunta compuesta por pulsadores y leds congurados previamente, para ampliar las posibilidades de la instalaci on. 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 simulaci on de la vivienda.
17
Introducci on
18
Parte I
Dom otica
19
Dom otica
I. Generalidades
La dom otica, dicho en muy pocas palabras, es la instalaci on e integraci on de varias redes y dispositivos electr onicos en el hogar, que permiten la automatizaci on de actividades cotidianas y el control local o remoto de la vivienda, o del edicio inteligente. Por ejemplo, un sensor de presencia aislado puede servir para abrir una puerta siempre que alguien se acerque, pero si est a integrado en una red, proporciona informaci on sobre frecuencia de uso, horas punta de entrada, etc.; una informaci on que puede resultar muy valiosa para otras aplicaciones y as , por ejemplo, no abrir a la puerta fuera del horario comercial, para evitar la entrada de intrusos, o la mantendr a permanentemente abierta en las horas de mayor auencia al recinto. Desde el punto de vista etimol ogico, la palabra dom otica fue inventada en Francia (pa s pionero en Europa) y est a formada por la contracci on de domus (vivienda) m as autom atica. En este sentido ha habido cierta pol emica en lo referente a la idoneidad de su denominaci on, puesto que el objeto de esta disciplina no es u nicamente la vivienda, sino cualquier tipo de edicaci on. Adem as, la dom otica va m as all a de la mera automatizaci on de un edicio, integrando el control del mismo con el uso que se hace de el. En cualquier caso, el uso de este t ermino se ha extendido ampliamente, pero se pueden distinguir tres sectores distintos dependiendo del alcance de su aplicaci on: Dom otica, para el sector dom estico. Inm otica, para el sector terciario. Urb otica, para las ciudades. En este caso se tratan temas como el control de la iluminaci on p ublica, la gesti on de sem aforos, las telecomunicaciones, medios de pago, etc. Para denir una vivienda automatizada habr a que tener en cuenta al menos dos puntos de vista: el del usuario y el punto de vista t ecnico. Desde el punto de vista del usuario, una vivienda dom otica podr a ser aquella que proporciona una mayor calidad de vida a trav es de las nuevas tecnolog as y comunicaciones, ofreciendo una reducci on del trabajo dom estico, un aumento del bienestar y la seguridad de sus habitantes, y una racionalizaci on 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 minusval a f sica. Desde el punto de vista tecnol ogico, la denici on podr a ser la siguiente: es aquella en la que se integran los distintos aparatos dom esticos que tienen la capacidad de intercomunicarse entre ellos a trav es de un soporte de comunicaciones, de modo que puedan realizar tareas que hasta ahora se ven an haciendo de forma manual.
21
Dom otica
El uso de las TIC (Tecnolog as de la Informaci on y las Comunicaciones) en la vivienda genera nuevas aplicaciones y tendencias basadas en la capacidad de proceso de informaci on y en la integraci on y comunicaci on entre los equipos e instalaciones. As concebida, una vivienda inteligente puede ofrecer una amplia gama de aplicaciones en areas tales como: Seguridad Gesti on de la energ a Automatizaci on de tareas dom esticas Formaci on y cultura Monitorizaci on de salud Comunicaci on con servidores externos Ocio y entretenimiento Operaci on y mantenimiento de las instalaciones La introducci on de todos estos sistemas y tecnolog as en el hogar a un no es una realidad, salvo en contadas ocasiones, pero s hay muchos catalizadores que ayudar an a que ello se realice r apidamente. Por una parte cada vez existen m as dispositivos electr onicos en el hogar. Eso provoca una necesidad real de comunicar unos con otros. Por otra, la estandarizaci on de las tecnolog as de comunicaci on privadas como las redes Ethernet cableadas o las redes inal ambricas Wi-Fi, han reducido los costes a unos niveles que permiten su despliegue masivo. Y, por supuesto, la disponibilidad y exibilidad del elemento base que ha acelerado el desarrollo de la inform atica en los u ltimos tiempos: los ordenadores, as como la paulatina convergencia de la inform atica y las telecomunicaciones, y la necesidad, cada vez mayor, de la informaci on a todos los niveles.
Figura 1: Casa dom otica Proyecto Final de Carrera 22
I Generalidades
Para qu e le sirve a alguien tener todos estos sistemas y con qu e nivel de complejidad? Inicialmente, hay que tener en consideraci on que los requerimientos de los usuarios residenciales son distintos a los de los usuarios profesionales, ubicados en ocinas o f abricas, algo que hay que tener en cuenta al evaluar la tecnolog a y los sistemas m as adecuados para satisfacer sus necesidades que, fundamentalmente, se dirigen a hacer m as amigable su relaci on con el entorno en el que pasa la mayor parte de su tiempo. Y despu es el caso depender a de cada usuario. Podemos ver algunos ejemplos: El anciano que vive solo le bastar a con un sistema de teleasistencia muy simple tecnol ogicamente, 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 m as importante el poder disponer de acceso a Internet en todas las habitaciones. Para personas que viven solas, poder encender la calefacci on o el aire acondicionado desde la ocina o disponer de un sistema autom atico de riego puede tener mucho inter es. Para una pareja trabajadora puede que lo m as interesante sea disponer de una c amara IP en su casa, que les permita ver a trav es de Internet a su hijo peque no, que est a siendo cuidado por otra persona. Es indudable que cuantas m as posibilidades existen, mayor dicultad entra na su interconexi on, por lo que es labor de las empresas integradoras empaquetar soluciones que tengan una f acil instalaci on y, a un m as importante, un mantenimiento sencillo. Pero es todav a m as importante que los fabricantes tengan en cuenta que sus productos no s olo van a integrar cada vez m as opciones, sino que tambi en van a tener que ser capaces de compartir sus funcionalidades e informaci on con otros, por lo que tienen que facilitar la transferencia de datos, permitir la gesti on remota e, idealmente, ser capaces de ofrecer soluciones completas que requieran de la m nima intervenci on por el usuario. Adem as, para las empresas promotoras dotar a las viviendas que construyen de una instalaci on dom otica 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 posibilidad de aumentar los servicios que ofrecen a sus clientes, generando nuevos ingresos; a las compa n as de servicios de luz, agua, electricidad, seguridad, etc., se les abre una puerta para racionalizar sus costes, y a nadir valor para el usuario nal. Seg un todo lo expuesto, la dom otica no son servicios ni productos aislados, sino la implementaci on e integraci on de todos los aparatos del hogar (el ectricos, electr onicos, inform aticos, etc.). No obstante, la incorporaci on e integraci on de estas redes y dispositivos en la vivienda dom otica 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 consumo energ etico, se incrementan las posibilidades de ocio, etc. En denitiva, se produce un incremento de la calidad de vida de sus habitantes.
23
Dom otica
II.
II.1.
Caracter sticas
El sistema
Para que todos los dispositivos que integran una red dom otica puedan trabajar de forma conjunta es necesario que est en conectados a trav es de una red interna, red que generalmente se suele conocer por HAN (Home Area Network ). Esta red, cableada o inal ambrica, 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 tecnolog as, aunque es bastante probable que durante los pr oximos a nos se produzca una integraci on de todas ellas. Por otro lado, es necesario la conexi on de la HAN con el exterior, lo cual se realiza a trav es de las redes p ublicas de telecomunicaci on (RTC, RDSI, Internet, etc.). De entre todos los dispositivos de la vivienda dom otica 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, interconect andolos 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 Adem as de la pasarela residencial, los dispositivos que se deben instalar en los edicios o viviendas dom oticas para posibilitar un sistema de automatizaci on y control podr amos clasicarlos de las siguiente forma: Los sistemas de control: en instalaciones centralizadas, son los dispositivos encargados de gestionar y controlar los dispositivos destinados a la automatizaci on del edicio, seg un los par ametros de actuaci on establecidos por los usuarios. En ellos reside toda la inteligencia del sistema y suelen tener las interfaces de usuario necesarias para presentar la informaci on a este (pantalla, teclado, monitor, etc.).
24
II Caracter sticas
Los sensores son los dispositivos encargados de recoger la informaci on de los diferentes par ametros a controlar: la temperatura ambiente, la existencia de un escape de agua o gas, la presencia de un intruso, activaci on de un interruptor, etc. y envi arsela al sistema de control o actuador para que ejecute autom aticamente las tareas programadas. Los hay de diversos tipos: gas, temperatura, agua, humedad, luz, movimiento, rotura, etc. y est an distribuidos por todo el edicio. A continuaci on, establecemos los principales tipos de sensores y sus caracter sticas: 1. Luminosidad. Se usan para ajustar los niveles de iluminaci on en funci on de la luz exterior o para encender/apagar/regular las luces. Su colocaci on se realiza en exteriores, en lugares protegidos de las inclemencias del tiempo y evitando la exposici on directa de la luz del sol. Se pueden diferenciar entre: Sensores de luminosidad propiamente dichos, en los que se produce una salida anal ogica proporcional a la luz incidente. Sondas crepusculares que producen salidas digitales (d a/noche) y en las que es posible ajustar un umbral de conmutaci on mediante un potenci ometro de modo que proporcione una se nal digital que active un rel e. 2. Temperatura. A partir de cambios de temperatura generar an una salida anal ogica o digital, dependiendo del tipo: Sondas Producen una salida anal ogica al estimularlos con cambios de temperatura. Cada tipo lo hace de una forma diferente: Termopar. Genera una tensi on al cambiar de temperatura. RTP. Var an su resistencia con la temperatura, seg un un coeciente. NTC y PTC. Resistencia semiconductora que var a 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 conexi on/desconexi on seg un un umbral de temperatura previamente denido.
Figura 3: Detectores de presencia 3. Volum etricos de presencia. Son de tipo digital y se activan cuando se produce un movimiento en sus inmediaciones. Podemos distinguir cuatro tipos: Proyecto Final de Carrera 25
Dom otica
Infrarrojos. Detectan las radiaciones infrarrojas, siendo sensibles a las variaciones de calor. Microondas. Producen ondas electromagn eticas y detectan las variaciones que haya en sus reexiones. Tecnolog a dual. Combinan las dos tecnolog as anteriores para evitar falsas alarmas, dando una gran abilidad. Ultrasonidos. Detectan el movimiento mediante ondas sonoras y sus reexiones. 4. Detectores de incendio. Son de tipo digital, se activan cuando detectan part culas en el aire, calor o humo. Hay diversos tipos, dependiendo del mecanismo que utilicen para detectar el humo o las part culas: opticos, i onicos, termoveloc metros 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 h umedas de la vivienda (ba nos, cocina, etc.) o en recintos con riesgos de inundaci on (salas de calderas para la calefacci on, 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 funci on de racionalizaci on de energ a el ectrica. Hay dos tipos: Transformador de intensidad y sensor de efecto Hall. 7. Detectores de gas. Detectan gases t oxicos y explosivos, como butano, propano, gas natural, gas ciudad, etc. Estas alarmas nunca deber an faltar en la zonas donde se produzca cualquier tipo de combusti on como cocinas, garajes, sistemas de calefacci on o chimeneas. 8. Detectores de puertas y ventanas abiertas. Son sensores digitales que consisten en unos contactos magn eticos formados por dos piezas: Un im an por un lado y y cuerpo met alico por otro lado. El hecho de que est en en contacto ambas piezas produce una conmutaci on en el circuito o no, detectando la apertura de una puerta o ventana. Los m as importantes son los empotrados para puertas y los de supercie 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: Anem ometro
26
II Caracter sticas
10. Detectores de lluvia. Son de tipo digital y formados por un material que cambia su resistividad en funci on del agua. Se utilizan para controlar el riego autom atico en jardines, jardineras, etc. y son importantes a la hora de ahorrar agua y energ a. 11. Otros sensores. Existen otros sistemas sensores para medir radiaciones, nivel de PH, nivel de humedad relativa en el aire, presi on atmosf erica, detectores s smicos, etc. que son importantes desde el punto de vista del confort. Los actuadores son los dispositivos utilizados por el sistema de control para modicar el estado de ciertos equipos o instalaciones: encendido/apagado, subida/bajada de persianas, el aumento o la disminuci on de la calefacci on o el aire acondicionado, el corte del suministro de gas o agua, el env o de una alarma a una centralita de seguridad, etc. Est an distribuidos por todo el edicio y podemos distinguir diferentes tipos de actuadores: 1. Electromec anicos. Frente a las entradas o est mulos de los sensores van a producir una salida electromec anica. Estos son los m as utilizados en dom otica y podemos distinguir: Motores. Sus aplicaciones principales son las persianas y toldos. Electrov alvulas. Controlan las v alvulas de agua o gas y algunas permiten incluso la regulaci on. Rel es. Abren o cierran un circuito en funci on de una se nal externa. Se pueden clasicar seg un el n umero de circuitos que accionan a la vez, el valor de intensidad que pueden soportar, el tipo y valor de tensi on que los acciona o por si son temporizados o instant aneos. Contactores. Tienen una funci on similar a la de un rel e pero con un sistema mec anico diferente y m as robusto. Son de montaje en carril DIN y se les asocia con aplicaciones de control de grandes cargas o de m ultiples circuitos simult aneamente.
Figura 5: Actuador de carril DIN 2. Ac usticos. 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 soluci on o fabricante, hay equipos que son controladores/sensores/actuadores al mismo tiempo, ya que en un u nico equipo se dispone de toda la inteligencia necesaria para medir una variable f sica, procesarla y actuar en consecuencia (por ejemplo, un termostato). Pero la mayor a de las soluciones del mercado, sean propietarias o no, se construyen diferenciando los sensores de los actuadores con objeto de aportar mayor exibilidad y menor precio de cara a la instalaci on e integraci on en una vivienda. Proyecto Final de Carrera 27
Dom otica
II.2.
Arquitectura
Desde el punto de vista de d onde reside la inteligencia del sistema dom otico, y gracias al desarrollo actual de las tecnolog as de la informaci on (en concreto los microcontroladores), hacen viables dos tipos distintos de sistemas dom oticos: Sistemas Centralizados. Un controlador centralizado recibe informaci on de m ultiples sensores y, una vez procesada, genera las ordenes oportunas para los actuadores. Toda la informaci on de detecci on y actuaci on se tratan en este u nico punto. El cableado es en estrella cuyo centro es la unidad central de control y no existe comunicaci on entre sensores y actuadores.
Figura 6: Sistema centralizado Ventajas: Bajo coste: ning un elemento necesita m odulo especial de direccionamiento ni interface. Instalaci on sencilla. Requerimientos m nimos. Desventajas: Flexibilidad limitada: las reconguraciones son costosas. Poca robustez: si cae el m odulo central cae todo el sistema. Mayor longitud de cableado dada la topolog a, su uso en grandes instalaciones es limitado. Proyecto Final de Carrera 28
II Caracter sticas
Sistemas Distribuidos. En este caso no existe la gura del controlador centralizado, sino que toda la inteligencia del sistema est a distribuida por todos los m odulos sean sensores o actuadores. Cada elemento dispone de capacidad para tratar la informaci on que recibe y actuar en consecuencia de forma aut onoma. Suele ser t pico de los sistemas con topolog a 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 t ecnicas de direccionamiento para que la recepci on y el env o de informaci on quede denida y el di alogo entre elementos asegurado.
Figura 7: Sistema distribuido, con bus de datos y red de alimentaci on Ventajas: Alta exibilidad y una gran facilidad para reconguraciones. Posibilidad de tecnolog as plug & play, que simplican mucho las instalaciones. Ahorro de cableado en la instalaci on, 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, protocolos, 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 informaci on de m ultiples sensores y transmitirlos al resto de dispositivos distribuidos por la vivienda. Hoy en d a 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 cu al es la mejor soluci on para una vivienda. Proyecto Final de Carrera 29
Dom otica
Hay sistemas que son de arquitectura distribuida en cuanto a la capacidad de proceso, pero no lo son en cuanto a la ubicaci on f sica de los diferentes elementos de control y viceversa, sistemas que son de arquitectura distribuida en cuanto a su capacidad para ubicar elementos de control f sicamente distribuidos, pero no en cuanto a los procesos de control, que son ejecutados en uno o varios procesadores f sicamente centralizados. Por otra parte, tambi en se pueden clasicar los sistemas en tres tipos a nivel tecnol ogico: Sistemas cableados: todos los sensores y actuadores (sirenas, etc), est an cableados a la central o entre ellos, la cual es el controlador principal de todo el sistema. Esta tiene normalmente una bater a de respaldo, para en caso de fallo del suministro el ectrico, poder alimentar a todos sus sensores y actuadores y as seguir funcionando normalmente durante unas horas. Sistemas inal ambricos: en este caso usan sensores inal ambricos alimentados por pilas o bater as y transmiten v a radio la informaci on de los eventos entre ellos o a la central, la cual est a alimentada por red el ectrica y tiene sus bater as de respaldo. Sistemas mixtos: combinan el cableado con el inal ambrico.
Figura 8: Sistemas cableados o inal ambricos
II.3.
Topolog as
En los sistemas de arquitectura distribuida que utilizan como medio de transmisi on el cable, existe un concepto a tener en cuenta que es la topolog a de la red de comunicaciones. La topolog a de la red se dene como la distribuci on f sica de los elementos de control respecto al medio de comunicaci on. Es el m etodo para interconectar los equipos y sistemas conectados a ella as como la forma que adoptan. La topolog a depende del sistema de control que se utilice y el cableado en funci on de los requerimientos del sistema. Tipos de topolog as: La Red de Estrella: es la conexi on utilizada por los sistemas centralizados donde existe un u nico controlador sobre el que pasa toda la informaci on. La Red de Anillo: cada controlador est a 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 caracter stica proporciona al instalador dom otico una libertad de dise no que le posibilita adaptarse a las caracter sticas f sicas de cada vivienda en particular. Proyecto Final de Carrera 30
II Caracter sticas
II.4.
Medios de Transmisi on
En todo sistema dom otico los diferentes dispositivos deben intercambiar informaci on unos con otros a trav es de un soporte f sico: par trenzado, l nea de potencia o red el ectrica, radio, infrarrojos, etc. Veamos los distintos tipos que se pueden presentar: 1. L neas de distribuci on de energ a el ectrica (Corrientes Portadoras) . Si bien no es el medio m as adecuado para la transmisi on de datos, s es una alternativa a tener en cuenta para las comunicaciones dom esticas dado el bajo coste que implica su uso, puesto que se trata de una instalaci on existente, por lo que es nulo el coste de la instalaci on, 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 transmisi on, la l nea de distribuci on de energ a el ectrica puede ser suciente como soporte de dicha transmisi on. 2. Soporte met alico . La infraestructura de las redes de comunicaci on actuales, tanto p ublicas como privadas, tiene en un porcentaje muy elevado cables met alicos de cobre como soporte de transmisi on de las se nales el ectricas que procesa. En general se pueden distinguir dos tipos de cables met alicos: Par met alico: Los cables formados por varios conductores de cobre pueden dar soporte a un amplio rango de aplicaciones en el entorno dom estico. Este tipo de cables pueden transportar voz, datos y alimentaci on de corriente continua. Coaxial: Un par coaxial es un circuito f sico asim etrico, constituido por un conductor liforme que ocupa el eje longitudinal del otro conductor en forma de tubo, manteni endose la separaci on entre ambos mediante un diel ectrico apropiado. Este tipo de cables permite el transporte de las se nales de v deo y se nales de datos a alta velocidad. 3. Fibra optica . La bra optica es el resultado de combinar dos disciplinas no relacionadas, como son la tecnolog a de semiconductores (que proporciona los materiales necesarios para las fuentes y los detectores de luz), y la tecnolog a de guiado de ondas opticas (que proporciona el medio de transmisi on, el cable de bra optica). La bra optica esta constituida por un material diel ectrico transparente, conductor de luz, compuesto por un n ucleo con un ndice de refracci on menor que el del revestimiento, que envuelve a dicho n ucleo. Estos dos elementos forman una gu a para que la luz se desplace por la bra. La luz transportada es generalmente infrarroja, y por lo tanto no es visible por el ojo humano. Permite altas velocidades para datos, televisi on, etc. 4. Conexiones inal ambricas: Infrarrojos El uso de mandos a distancia basados en transmisi on por infrarrojos esta ampliamente extendido en el mercado residencial para controlar equipos de audio y v deo. Los controladores de equipos dom esticos basados en la transmisi on de ondas en la banda de los infrarrojos presentan gran comodidad y exibilidad y admiten un gran n umero de aplicaciones. Proyecto Final de Carrera 31
Dom otica
Radiofrecuencias La introducci on de las radiofrecuencias como soporte de transmisi on en la vivienda ha venido precedida por la proliferaci on de los tel efonos inal ambricos y sencillos telemandos. Este medio de transmisi on puede parecer, en principio, id oneo para el control a distancia de los sistemas dom oticos, dada la gran exibilidad que supone su uso. Sin embargo, puede resultar sensible a las perturbaciones electromagn eticas producidas, tanto por los medios de transmisi on, como por los equipos dom esticos.
32
III Funcionalidad de la dom otica
III.
Funcionalidad de la dom otica
Como se ha comentado anteriormente, la dom otica es un conjunto de servicios realizados por automatismos o dispositivos con cierto grado de inteligencia dentro del hogar, dirigidos a la gesti on de cuatro funciones b asicas: control energ etico, confort, seguridad y telecomunicaciones. 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 dom oticas que puede tener una vivienda. Al realizar una instalaci on, la proporci on de la inversi on realizada en cada uno de los apartados depender a de cu al vaya a ser la nalidad del edicio o residencia, que vendr a en funci on, claro est a, del tipo de usuario que los habite.
III.1.
Control energ etico
La nalidad es satisfacer las necesidades del hogar al m nimo coste. En este control se pueden distinguir tres aspectos diferenciados: Regulaci on: con la que se pueda obtener la evoluci on del consumo energ etico de la vivienda o edicio. Programaci on: para programar distintos par ametros de la vivienda a nivel energ etico, como temperatura seg un horarios, d as de la semana, mes, etc. Optimizaci on: de modo que se minimice el consumo. El aprovechamiento de la energ a y reducci on de su consumo, es uno de los apartados m as importantes en la instalaci on de un sistema dom otico, puesto que revierte a medio y largo plazo en su amortizaci on, adem as de estar muy ligadas al concepto de confort. Las acciones destinadas a reducir el consumo est an ntimamente ligadas a la integraci on de todos los dispositivos de la vivienda en el sistema. Dichas acciones son del tipo: Aprovechamiento de las franjas de taricaci on de valle para hacer trabajar aquellos equipos que lo permitan (p.e., aprovechamiento de tarifas nocturnas en funci on de las necesidades programadas). Reducci on del consumo para climatizaci on fuera de las horas de trabajo normales. Detecci on de fuentes de p erdidas en sistemas de climatizaci on (p.e. suspensi on del funcionamiento en estancias donde se detecten ventanas abiertas). Reducci on del consumo para climatizaci on en ausencia de individuos en las estancias mediante la detecci on autom atica de presencia. Actuaci on sobre automatismos de persianas para el aprovechamiento de la luz solar.
Figura 9: Control energ etico
33
Dom otica
III.2.
Seguridad
Actualmente, aunque de manera individualizada (no integrada), es la funci on m as desarrollada, y puede integrar m ultiples aplicaciones, especialmente si se encuentra integrada dentro de un sistema dom otico. Se puede dividir en seguridad de personas y seguridad de bienes. En la seguridad de personas se incluyen tareas como: Alumbrado autom atico en zonas de riesgo por detecci on de presencia (escaleras, etc.) para evitar accidentes dom esticos. Desactivaci on de enchufes de corriente para evitar contactos. Manipulaci on a distancia de interruptores en zonas h umedas. Emisi on de avisos telef onicos a n umeros prejados en caso de necesidad de ayuda urgente. Detectores de fugas de gas o de agua que cierren las v alvulas 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 activaci on genera un aviso a una central receptora, un familiar o un hospital para solicitar ayuda sanitaria urgente.
Figura 10: Sistema de alarmas t ecnico En cuanto a la seguridad de bienes se reere, las funciones principales son: Avisos a distancia. En ausencia del usuario se emiten avisos en caso de alarma (bien ac usticos o telef onicos). Detecci on de intrusos. Incluye la instalaci on de diversos sensores: Sensores volum etricos para detecci on de presencia. Sensores de hiperfrecuencia para cristales rotos. Sensores magn eticos para apertura de puertas y ventanas. Proyecto Final de Carrera 34
III Funcionalidad de la dom otica
Alarmas t ecnicas: Detecci on de incendios. Detecci on de fugas de agua y gas. Ausencia de energ a el ectrica. En el caso de alarmas t ecnicas tambi en 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 (climatizaci on, ventilaci on y calefacci on), auque tambi en se incluyen en este campo los sistemas de audio y v deo, control de iluminaci on, 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 est an realizando, pues adem as de abarcar una gran parte del consumo energ etico, est an presentes en casi todas las instalaciones y son la primera contribuci on. Se hace necesario que el control de estos sistemas est e lo m as distribuido posible, esto es, que cada habitaci on, local o recinto, disponga de sistemas de control individual. Entre los sistemas destinados al confort cabe destacar, adem as de las instalaciones CVC: Control de los distintos automatismos por infrarrojos o pantallas t actiles. Automatizaci on de riego de jardines. Apertura autom atica de puertas. Centralizaci on y supervisi on de todos los sistemas de la vivienda. Accionamiento autom atico de distintos sistemas en base a datos del entorno, como la recogida autom atica de toldos y bajada de persianas en caso de tormenta o viento excesivo, etc. Informaci on de presencia de correo en el buz on.
Figura 11: Control mediante pantalla t actil
35
Dom otica
III.4.
Telecomunicaciones
En este sentido, existen numerosas posibilidades en funci on del tipo de edicio. La aparici on de nuevas tecnolog as en el campo de las comunicaciones y redes de transmisi on de datos, y el hecho de que los sistemas dom oticos avanzados se basan en el empleo de estos tipos de redes, hacen de este un campo f ertil para la investigaci on y el desarrollo de nuevas arquitecturas y sistemas de integraci on. Entre las posibilidades de telecomunicaci on seg un el tipo de edicio, destacaremos: Sistemas de comunicaci on en el interior. Megafon a, difusi on de audio/v deo, intercomunicadores, etc. Sistemas de comunicaci on con el exterior. Telefon a b asica, 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 dom otico a trav es de la l nea telef onica o conexi on a redes de datos (Internet). De entre todas ellas, las que mayor auge est an teniendo en los u ltimos a nos, desde el punto de vista de aportaciones de investigaci on e implantaci on de nuevas tecnolog as, son las iniciativas de telecontrol del sistema dom otico desde el exterior. En este sentido se pueden destacar trabajos como: Control de instalaciones dom oticas mediante protocolo TCP/IP utilizando html o applets de Java, para la teleoperaci on y monitorizaci on de sistemas dom oticos en edicios. Control de instalaciones dom oticas mediante mensajes SMS. Consistente en la aplicaci on de la tecnolog a GSM al control de remoto de redes dom oticas, ampliando sus posibilidades con nuevas tecnolog as como 3G en el campo del env o de audio y v deo. Acceso a redes EIB para personas discapacitadas empleando redes inal ambricas 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 trav es del uso del ordenador personal. Aplicaci on de sistemas de encriptaci on y autenticaci on en el acceso remoto a instalaciones dom oticas a trav es de Internet, para asegurar la privacidad y seguridad de los datos en el acceso a trav es de redes p ublicas. Integraci on de redes dom oticas en redes de bra optica ya existentes.
Figura 12: Controlador pronto de Philips
36
IV Tecnolog as existentes
IV.
Tecnolog as existentes
Actualmente existen numerosos sistemas dom oticos comerciales y cada uno de ellos est a orientado a un segmento concreto del mercado. Desde el punto de vista comercial, puede decirse que los tres sectores m as importantes que precisan actualmente de estos sistemas son las casas ya construidas, las casas nuevas y los grandes edicios (hoteles, ocinas, residencias). Cada uno de estos sectores utiliza una tecnolog a espec ca, adaptada a las necesidades del usuario nal. B asicamente vamos a distinguir entre casas ya construidas, viviendas nuevas, y grandes edicios. En una casa construida, se suelen utilizar sistemas denominados de corrientes portadoras (traducci on del franc es courant porteur), que tienen como soporte de comunicaci on la propia red de alimentaci on de baja tensi on (BT) de 220 V, presente en la vivienda. El motivo del empleo de este tipo de tecnolog a es el elevado coste, y en muchos casos la imposibilidad, de realizar un nuevo precableado para el sistema dom otico. En este caso, los sistemas mayoritariamente 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 tama no peque no sin grandes requerimientos. Las gamas altas de SCC se emplean en viviendas nuevas de tama no medio-grande con necesidades m as avanzadas, aunque tambi en se est a extendiendo cada vez m as la implantaci on 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 especializaci on para su instalaci on. Tambi en existen otros sistemas menos populares como Amigo (Merl n Gerin), Microdelta (Delta Dore), Domoconcept, y otros muchos propietarios de diferentes fabricantes. En el caso de un edicio, las necesidades son m as 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 dem as, aunque en algunos casos las gamas altas de SCC tambi en se pueden aplicar si la relaci on cableado/componentes lo permite. Los sistemas tipo bus m as 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 est andar Konnex.
Figura 13: Sistemas en funci on del tama no de edicaci on Proyecto Final de Carrera 37
Dom otica
Existe otro sistema tambi en muy popular en Estados Unidos, el Lonworks de Echelon, pero en Europa est a 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 m as instalados en la actualidad son los americanos, 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 m as 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 continuaci on, haremos un repaso de las principales tecnolog as existentes que hemos mencionado, comentando sus pros y contras, para poder establecer una clara comparativa entre ellas. Estableceremos una distinci on entre los sistemas americanos y europeos hasta, nalmente, ver en detalle el sistema KNX-EIB puesto que, adem as de asentarse como el est andar europeo m as importante, es el protocolo que hemos elegido para la realizaci on de este proyecto.
Figura 14: Normalizaci on de los sistemas dom oticos
38
IV.1.
CEBus
En Estados Unidos, la EIA (Electronic Industries Association ) reconoci o la necesidad de desarrollar un est andar acerca de los sistemas de comunicaci on de los hogares automatizados. En 1983 se organiz o un comit e que tuvo como fruto en 1988 un est andar (el Home Automation Standard IS-60) conocido como Consumer Electronic Bus, CEBus. El documento nal, despu es de varias revisiones, estuvo disponible en 1992. Este cubre tanto las caracter sticas el ectricas como los procedimientos de los m odulos del sistema de comunicaci on. La arquitectura del CEBus sigue el modelo de referencia OSI (Open Systems Interconnection ), ocup andose cada uno de los niveles de determinadas funciones de la red de comunicaci on.
Figura 15: Arquitectura de CEBus, tomando como referencia el modelo OSI El CEBus s olo utiliza cuatro de los siete niveles: F sico, Enlace, Red y Aplicaci on. La interfaz entre los diferentes niveles del nodo CEBus est a denido como un conjunto de primitivas de servicio, proporcionando cada nivel servicio al inmediatamente superior. Los objetivos principales del est andar son: Facilitar el desarrollo de m odulos de interfaz de bajo coste que puedan ser integrados f acilmente en electrodom esticos. Soportar la distribuci on de servicios de audio y v deo tanto en formato anal ogico 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 conguraci on por parte del usuario. Proporcionar un m etodo adecuado de acceso al medio. En CEBus se diferencian tres areas: 1. El medio f sico y la topolog a. 2. El protocolo de comunicaciones: c omo acceder al medio y construir los mensajes. 3. El lenguaje de programaci on: conjunto de acciones que se pueden efectuar en el sistema.
39
Dom otica
El protocolo y el lenguaje son comunes a todos los elementos CEBus, pero existen 6 medios f sicos distintos: Red el ectrica (PL) Par trenzado (TP) Infrarrojo (IR) Radio frecuencia (RF) Coaxial (CX) Fibra optica (FO) La elecci on del medio se realiza en funci on de par ametros como el ahorro energ etico, comodidad, facilidad de instalaci on de los productos CEBus, seguridad, coste y sencillez del sistema. En una instalaci on pueden coexistir diversos medios. Cada uno de ellos constituir a una subred local (Local Medium Network ). Las subredes locales se conectan mediante encaminadores (routers ). CEBus engloba varios canales de comunicaci on: 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 instalaci on dom otica. Los canales de datos se emplean para la transmisi on de voz, m usica, TV, video etc., y se asignan por solicitud mediante el canal de control. Por lo general, la distribuci on 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 alimentaci on de 18Vdc). Resto de se nales: a trav es de la red de BT, conectando equipos a enchufes est andar. Se utiliza una t ecnica de modulaci on con espectro ampliado de Intellon Corp. La velocidad de transmisi on de datos que se consigue es de 10Kbps, y puede ser utilizado tanto en viviendas ya construidas como de nueva construcci on. Se trata de un est andar muy ambicioso, y en el cooperan tanto Europa como Jap on, pero no existen muchos productos comercializados, lo que se debe principalmente a su elevado precio.
40
IV.2.
X-10
El formato de codicaci on X-10 es un est andar basado en la transmisi on de corrientes portadoras (Power Line Carrier = P.L.C.). Esta tecnolog a 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 comenz o 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 vendi o a miles hasta que en 1979 los fabric o por su cuenta y los llam o Plug n Power, y m as tarde X10. Desde entonces, X-10 ha desarrollado y manufacturado versiones O.E.M. (Original Equipment Manufacturer ) de su Sistema de Control del Hogar para muchas compa n as incluyendo Leviton Manufacturing Co., Stanley Healtth / Zenith Co., Honeywell, Norweb y Busch Jaeger, existiendo en la actualidad m as de ocho millones de instalaciones. Todos estos sistemas utilizan el formato de codicaci on X-10. Todos son compatibles y virtualmente cualquier sistema para el hogar sin cableados utiliza X-10 con m odulos PLC. El sistema X-10 se caracteriza principalmente por: Ser un sistema descentralizado, congurable, no programable. De instalaci on sencilla: conectar y funcionar (plug & play ) De f acil manejo por el usuario. Compatibilidad casi absoluta con los productos de la misma gama, obviando fabricante y antig uedad. Flexible y ampliable.
Figura 16: Instalaci on X10 La red de la instalaci on es la base de todo el sistema de corrientes portadoras. El elemento b asico y fundamental de la t ecnica de corrientes portadoras es el aprovechamiento doble de la instalaci on el ectrica ya existente, como conductor de energ a y de informaci on. Proyecto Final de Carrera 41
Dom otica
Con los componentes X-10 la red, adem as de suministro de corriente, se encarga tambi en de la transmisi on de se nales de mando para los diversos aparatos el ectricos. Con ello se puede enviar se nales de corrientes portadoras a cualquier punto de la instalaci on 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 el ectricos, desde uno o desde varios puntos y puede funcionar tanto en redes de corriente alterna monof asica como trif asica. Por la popularidad e importancia de que goza el sistema X-10, haremos un estudio m as detallado de su tecnolog a ya que m as 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 m as sistemas de control de iluminaci on que ninguna otra compa n a. M as de 100 millones de equipos se han vendido durante los u ltimos 15 a nos, haciendo de X-10, en este sentido, el l der en sistemas de control del hogar.
42
Principio de funcionamiento de X10 Las transmisiones en X-10 est an sincronizadas con el paso por cero de la tensi on de red, esta caracter stica es com un a todos los dispositivos X-10 y tiene una doble nalidad: la primera es sincronizar a los transmisores y receptores, ya que la u nica conexi on f sica que existe entre ellos es la l nea de red, la segunda es debida a que el nivel m nimo de interferencias producidas por otros equipos el ectricos 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 c odigo, 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 gura).
Figura 17: Codicaci on de bits en X10 El c odigo de comienzo (1110) es el u nico que no se env a de forma complementaria, y sirve para identicar de manera un voca el inicio de los paquetes de datos.
Figura 18: C odigo de comienzo 1110 El principio de codicaci on X10 permite una activaci on y respuesta denidas de hasta 256 receptores, puestos de control de aparatos o de grupos de consumidores. Con ello resulta posible el montaje de amplias redes.
43
Dom otica
Un bloque completo de datos o paquete de informaci on se compone de c odigo de comienzo, c odigo de la letra, c odigo de control y sujo.
Figura 19: Paquete de datos X10 El c odigo de control puede ser o una direcci on de unidad o un c odigo de comandos, dependiendo de si el mensaje es una direcci on o un comando. Las tablas siguientes muestran los posibles valores de los c odigos de casa y control.
Figura 20: C odigos de casa y de control para unidad
Figura 21: C odigos de control para comandos Debido a las caracter sticas del medio de transmisi on utilizado se transmite dos veces cada uno de estos bloques de informaci on para conseguir una mayor abilidad. Adem as, cada par de bloques de informaci on 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 direcci on recibidos. Proyecto Final de Carrera 44
Una vez que el receptor ha procesado sus datos de direcci on, est a listo para recibir una orden de comando. Al igual que se hab a hecho al enviar la direcci on, el bloque de datos del comando debe empezar por el c odigo de comienzo, seguido del c odigo de la letra y el c odigo de control. Finalmente ir a el sujo, teniendo que ser en este caso igual a 1 para que el c odigo de control sea interpretado como un comando y no como una direcci on por el receptor. En la gura siguiente se muestran los ciclos totales que necesita un transmisor para realizar una transmisi on completa.
Figura 22: Ciclos para una transmisi on completa en X10 Cada once ciclos de red se transmite un bloque de datos, y una transmisi on est andar X-10 normal necesita 47 ciclos de la se nal 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 c odigo 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 c odigos 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 trif asica, 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 conectarse al sistema trif asico por medio de un acoplador de fases. Interferencias en la l nea el ectrica. La transmisi on de se nales de pulsos a alta frecuencia a trav es de la red el ectrica puede verse afectada por interferencias. Las fuentes t picas que producen interferencias son aparatos el ectricos como TV, VCR, equipos de sonido, computadoras, monitores, transformadores e incluso los cables preparados con ltros tienen la tendencia de depositar ruido el ectrico sobre los cables de la red. Muchos de los nuevos aparatos electr onicos que se emplean en el ambito dom estico incluyen circuitos para minimizar los ruidos el ectricos que generan. Estas fuentes de ruido sobre la red el ectrica pueden ocasionar atenuaci on o bloqueo de las Proyecto Final de Carrera 45
Dom otica
se nales transmitidas o recibidas en los dispositivos X-10. Un efecto t pico del ruido el ectrico es el encendido aleatorio de los m odulos receptores o el tener un transmisor y un receptor cercanos y a un as no tener suciente se nal debido al ruido el ectrico. El aparato el ectrico que est a generando dicho ruido no tiene necesariamente que estar encendido, tal es el caso de elementos como ordenadores o aparatos de TV, que siguen encendidos en standby cuando se apagan. Todos estos problemas se solucionan con la utilizaci on de ltros que aten uan las se nales de frecuencia diferente a 120 Khz. Amplicaci on. Cuando las distancias son largas y/o la atenuaci on de las se nales X10 elevada en una instalaci on, se pueden emplear elementos amplicadores de se nal. Estos dispositivos trabajan de la siguiente forma: el amplicador vigila el circuito de se nales en todas las fases en busca de se nales. Tras el env o de un datagrama de direcci on, este se repite, amplicado a las tres fases, exactamente en el momento de la repetici on de la se nal original. Lo mismo ocurre con los datagramas de funciones, en los cuales se amplican exclusivamente las ordenes de conexi on, desconexi on o conmutaci on. Dispositivos X-10 Existen tres tipos de dispositivos X-10: los que s olo pueden transmitir ordenes, los que s olo pueden recibirlas y los que pueden enviar y recibir estas. A continuaci on se incluyen algunos de ellos a modo de ejemplo: Transmisores. Un transmisor es capaz de enviar informaci on hasta 256 dispositivos sobre el cableado el ectrico. 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 n umeros, que permiten asignar una direcci on de las 256 posibles. En una misma instalaci on puede haber varios receptores congura con la misma direcci on, todos realizar an la funci on preasignada cuando un transmisor env e una trama con esa direcci on. Cualquier dispositivo receptor puede recibir ordenes de diferentes transmisores.
Figura 23: Dispositivos X-10
46
Bidireccionales. Tienen la capacidad de responder y conrmar la correcta realizaci on de una orden, lo cual puede ser muy u til cuando el sistema X-10 est a conectado a un programa de ordenador que muestra los estados en que se encuentra la instalaci on dom otica de la vivienda. Inal ambricos. Permiten conectarse a trav es de una antena y enviar se nales de radio desde una unidad inal ambrica e inyectar la se nal X-10 en el cableado el ectrico. Estas unidades no est an habilitadas para controlar directamente a un receptor X-10, debe utilizarse un m odulo transceptor. Adem as de estos dispositivos, que son los m as 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 m odulos receptores es demasiado larga y la se nal sufre atenuaci on. Adem as de amplicar la se nal, la transmite en las tres fases por lo que servir a de acoplador en sistemas complejos no monof asicos. 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 instalaci on. Suprime las interferencias que vienen del exterior, como las parasitarias, ordenes X10 de otra instalaci on vecina. Adem as acopla las tres fases, en el caso de una instalaci on de corriente trif asica. Programador / Vericador. Es capaz de transmitir y recibir cada uno de los comandos, adem as de los comandos extendidos X10. Es una herramienta b asica para instaladores de dispositivos X10: permite conocer niveles de ruido, niveles de se nal, y otras. Tiene modos autom aticos de transmisi on y permite registrar actividad en la l nea durante periodos de 24 horas. Permite la emisi on de la se nal en incrementos de nivel de 33,3mV.
Figura 24: Accesorios X-10
47
Dom otica
IV.3.
LonWorks
Echelon surgi o como una iniciativa de Mike Markkula (exdirectivo de Fairchild Semiconductor, Intel y Apple), que en 1990 desarroll o LonWorks. Inicialmente se pretend a ocupar el espacio dejado por X-10, pero actualmente el ambito de aplicaci on de este sistema abarca desde industrias, edicios, viviendas y autom oviles hasta cualquier otro peque no dispositivo susceptible de ser controlado. El protocolo de comunicaci on 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 b asicos 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 transmisi on. Existe tambi en 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 b asico de las redes de control. Mediante los transceptores se consigue que el protocolo de comunicaci on 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 transmisi on disponibles son cinco: 1. Par trenzado (categor a IV) de cinco hilos: dos de datos, dos de alimentaci on y uno de tierra. 2. Fibra optica. 3. L nea de baja tensi on. 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 topolog a 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 topolog a en bus, o de 78 kbps para la topolog a libre. Proyecto Final de Carrera 48
Existen vario tipos de direcciones: 1. Direcci on f sica (Neuron ID ): consiste en una direcci on de 48 bits que viene grabada de f abrica (como la direcci on MAC en una tarjeta de red). 2. Direcci on de dispositivo, que est a formada por tres campos: ID de dominio (domain ID ): un dominio es una colecci on de dispositivos que pueden interoperar (en una red virtual), localizados en uno o m as 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 encaminamiento eciente en redes grandes. Puede haber un m aximo de 255 subredes dentro de un dominio. ID dispositivo (node ID ): identica al dispositivo en la subred. 3. Direcci on de grupo: colecci on l ogica de dispositivos en un dominio (no importa su situaci on f sica). Se pueden agrupar hasta 63 nodos. No puede haber m as de 256 grupos en un dominio. Un nodo puede pertenecer como m aximo a 2 dominios. Cada nodo tiene una direcci on de subred y una direcci on de nodo para cada dominio al que pertenezca. Asimismo, un nodo puede pertenecer a 15 grupos como m aximo en cualquier dominio en el que est e. Tambi en se utilizan direcciones de difusi on 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 m aximo de dispositivos o se quieren separar para que no puedan interoperar.
Figura 26: Dominio LonTalk En esta gura vemos un ejemplo de un Dominio LonTalk, donde podemos establecer que: Un canal es la uni on f sica de distintos nodos. Un grupo es la uni on l ogica 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 topolog a ni del medio f sico que se emplee.
49
Dom otica
El formato de las tramas es el mostrado en la gura siguiente, con los siguientes campos: un campo de control, la direcci on de nodo, la direcci on de dominio, los datos de usuario y un campo de CRC (c odigo de redundancia c clica). El tama no m aximo del campo de datos es de 228 bytes.
Figura 27: Trama de LonWorks El proceso de instalaci on de una red Lonwork se realizar a en tres fases: 1. Direccionamiento. Cada nodo tiene un identicador (ID number) de 48 bits que viene de f abrica. Se conecta un ordenador personal con el software de control de la red a trav es del puerto serie, y con el se obtiene este identicador mediante la pulsaci on del bot on de servicio del nodo. Una vez congurado este n umero, el programa le proporciona una nueva direcci on de red (dominio + subred + nodo), que queda almacenada en su memoria RAM. 2. Establecimiento l ogico de relaci on entre nodos. Con este proceso se asigna a cada nodo la direcci on o direcciones a las que va a mandar sus mensajes. 3. Conguraci on de cada uno de los nodos, con lo que se completa la instalaci on l ogica de estos. Cada nodo suele tener un conjunto de par ametros que han de ser congurados por el instalador, como por ejemplo, velocidad de la transmisi on, m argenes de alarma, etc. En la Figura 13 se muestra un esquema de conexionado t pico de una instalaci on Lonworks.
Figura 28: Instalaci on LonWork
50
IV.4.
EHS
A nales de los 80 la comisi on europea propici o el desarrollo de un par de proyectos SPRIT (el Home System 2341 y el Integrated Interactive Home Project ), de los que surgir a la European Home System Association (EHSA) en 1990, de la que inicialmente formaban parte compa n as como ABB, BT, Legrand, Philips, Siemens, Thomson y Thorn EMI. Los objetivos de esta asociaci on fueron: Posibilidad de interoperaci on entre los distintos equipos de diferentes fabricantes. F acil instalaci on y reconguraci on por parte del usuario. Posibilidad de integraci on de todos los dispositivos y medios disponibles en una vivienda convencional. El bus EHS surgi o como un sistema abierto, consecuencia de esta iniciativa, con control y gesti on distribuida, y preparado para su uso en distintos medios simult aneamente. Sigue el modelo de referencia OSI, implementando u nicamente las capas f sica, de enlace, de red y de aplicaci on. Los medios f sicos que se pueden emplear son: red el ectrica (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 adem as se nales de clase 2 (voz/datos baja velocidad) e incluso se nales de clase 3 (audio/video/datos alta velocidad).
Figura 29: Caracter sticas de los medios de transmisi on en EHS En EHS se pueden implementar tantas aplicaciones como dispositivos y funcionalidades se encuentren en un hogar. Cada dispositivo est a asociado a una determinada area de aplicaci on, dentro de la cual el elemento es un objeto. Para denir cada objeto se utilizan dos bytes, uno para el area (application area ), y otro para el dispositivo (device descriptor ). Existen diversas areas de aplicaci on: telecomunicaciones, audio/v deo, electrodom esticos, calefacci on, iluminaci on, etc. Los dispositivos EHS pueden ser de seis tipos: 1. Dispositivos simples (SD: simple devices ). Tienen funcionalidad aut onoma propia, pero no son capaces de gestionar aut onomamente la integraci on en un sistema (p.e. actuadores on/o, etc.). Proyecto Final de Carrera 51
Dom otica
2. Dispositivos complejos (CoD: complex devices ). Son como los anteriores pero s tienen capacidad para integrarse aut onomamente al sistema. 3. Encaminadores (Routers ). Permiten la interconexi on 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 aut onoma propia, pero son capaces de gestionar de modo aut onomo la integraci on en un sistema de dispositivos simples. 6. Controlador de prestaciones (FC: feature controller ). Utilizan las prestaciones de los dispositivos simples (a trav es de los coordinadores) y complejos. Proporcionan inteligencia a la aplicaci on en el sentido de control, monitorizaci on, toma de decisiones, etc. Una red EHS puede estar formada por distintas subredes EHS, e incluso por redes distintas 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 direcci on de subred. Una direcci on de unidad se compone de la direcci on 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 funci on de EHS que permite la asignaci on din amica de direcciones. Por ejemplo, si dos unidades de dos subredes de pares trenzados tienen la misma direcci on, al mover una de las unidades a la otra subred, habr a un problema, que se soluciona con el procedimiento de registro. Este procedimiento tiene lugar en el momento de la instalaci on (registro de categor a I) o cada vez que el sistema se pone en funcionamiento (registro de categor a II). Mediante este procedimiento, cada unidad nueva conectada a la red negocia su direcci on a trav es de una unidad denominada Controlador de Medios (MdC), que es la responsable de la asignaci on 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 asignaci on distribuida de direcciones (DAA). Las acciones llevadas a cabo en este registro son: 1. La unidad elige una direcci on de modo aleatorio y manda un mensaje a esa direcci on. 2. Si no recibe respuesta, la unidad mantiene esa direcci on. 3. Si hay respuesta, la unidad elige una nueva direcci on y repite el proceso hasta que obtenga una direcci on propia. Para la cooperaci on de las diferentes unidades dentro de una aplicaci on deben crearse una serie de v nculos 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 aut onomo del sistema, ya que permite a las unidades detectar la presencia de las dem as. 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 petici on de descriptores de dispositivo (DD) a todos los CoD. Este mensaje utiliza una direcci on de grupo predeterminada para alcanzar a todos los CoDs. Los CoD reciben el mensaje junto con informaci on adicional que les permite conocer la direcci on de su FC. Los CoDs env an entonces su DD al FC, usando su propia direcci on. Proyecto Final de Carrera 52
El FC recibe los DD de los distintos CoDs junto con sus direcciones. Si el FC estuviera interesado en un CoD concreto, enviar a su mensaje de enrolado positivo al CoD en cuesti on. El FC y el CoD quedan ya enrolados y cada uno almacena la direcci on 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 sincronizaci on del env o 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 denir el nivel de prioridad del mensaje. Direcciones: Origen y destino de los dispositivos. Datos: Datos u tiles del mensaje, informaci on de la acci on de control a realizar o datos a transferir. FCS: Campo de correcci on de errores, en el que se utilizan 2 bytes para garantizar la abilidad de la comunicaci on.
53
Dom otica
IV.5.
Batibus
Dentro de los buses industriales, en Europa se ha utilizado, dentro del marco dom otico, el bus BatiBus. Fue desarrollado por la empresa francesa Merlin Gerin. Se basa en la tecnolog a de par trenzado, con una velocidad binaria u nica de 4800 bps, la cual es m as que suciente para la mayor a de las aplicaciones de control distribuido. El sistema se basa en apertura y cierre de circuito en lo equivalente a modulaci on OOK. La instalaci on de este cable se puede hacer en diversas topolog as: bus, estrella, anillo, arbol o cualquier combinaci on de estas. Lo u nico que hay que respetar es no asignar direcciones id enticas a dos dispositivos de la misma instalaci on. El tama no 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 depender a fundamentalmente de la capacidad de resistir la interferencia inducida por la l neas de potencia sobre las l neas del bus (capacidad de acoplo m axima de 250 nanofaradios). El sistema es centralizado, pudiendo controlar cada central hasta 500 puntos de control. A nivel de acceso, este protocolo usa la t ecnica CSMA-CA, (Carrier Sense Multiple Access with Collision Avoidance ) similar a Ethernet pero con resoluci on positiva de las colisiones. Esto es, si dos dispositivos intentan acceder al mismo tiempo al bus ambos detectan que se est a produciendo una colisi on, pero s olo el que tiene m as prioridad continua transmitiendo el otro deja de poner se nal en el bus. Esta t ecnica es muy similar a la usada en el bus europeo EIB y tambi en en el bus del sector del autom ovil llamado CAN (Controller Area Network ). La losof a es que todos los dispositivos BatiBUS escuchen lo que han enviado cualquier otro, todos procesan la informaci on recibida, pero s olo aquellos que hayan sido programados para ello, ltrar an la trama y la subir an a la aplicaci on empotrada en cada dispositivo. Al igual que los dispositivos X-10, todos los dispositivos BatiBUS disponen de unos microinteruptores circulares o miniteclados que permiten asignar una direcci on f sica y l ogica que indentican un vocamente a cada dispositivo conectado al bus. Este protocolo de dom otica est a totalmente abierto, esto es, al contrario de los que sucede con el protocolo LonTak de la tecnolog a Lonworks, el protocolo del BatiBUS lo puede implementar cualquier empresa interesada en introducirlo en su cartera de productos. BatiBUS ha conseguido la certicaci on como est andar europeo CENELEC. Existen una ser e de procedimientos y especicaciones que sirven para homologar cualquier producto que use esta tecnolog a como compatible con el resto de productos que cumplen este est andar. A su vez, la propia asociaci on BCI ha creado un conjunto de herramientas para facilitar el desarrollo de productos que cumplan esta especicaci on. Sin embargo, el est andar se ha quedado obsoleto debido a sus limitaciones y actualmente se ha integrado junto a los est andares EIB y EHS en Konnex.
54
V Sistema EIB
V.
V.1.
Sistema EIB
Introducci on
El European Installation Bus o EIB es un sistema dom otico desarrollado bajo los auspicios de la Uni on Europea con el objetivo de contrarrestar las importaciones de productos similares que se estaban produciendo desde el mercado japon es y el norteamericano, donde estas tecnolog as se han desarrollado antes que en Europa. El objetivo era crear un est andar europeo, con el suciente n umero de fabricantes, de instaladores y usuarios, que permitiera comunicarse a todos los dispositivos de una instalaci on el ectrica como: contadores, equipos de climatizaci on, de seguridad, de gesti on energ etica y los electrodom esticos. El EIB surgi o con la idea de introducir en el mercado un sistema unicado para la gesti on de edicios, creado por el consorcio europeo EIBA (European Installation Bus Association ), creado en 1990 por m as de setenta compa n as (ABB, Siemens, Niessen, Temper, etc.). En la actualidad la asociaci on tiene m as de cien miembros, existiendo unas veinte empresas que suministran productos, siendo las m as importantes Siemens, ABB, Temper, Grasslin y Niessen. Tambi en existen miembros cient cos que colaboran en el desarrollo de actividades de I+D, especialmente universidades y centros de investigaci on. Las funciones de la asociaci on son b asicamente el soporte para la preparaci on de normas unicadas y la denici on de los tests y requisitos de homologaci on que garanticen la calidad y compatibilidad de los productos. Se trata, adem as, de un sistema abierto bajo las mismas premisas que otros sistemas de comunicaci on como los buses de campo abiertos: tanto las especicaciones del protocolo como los procedimientos de vericaci on y certicaci on est an disponibles, as como los componentes cr ticos del sistema (microprocesadores espec cos con la pila del protocolo y electr onica de acoplamiento al bus). Seg un 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 cualicados. El EIB est a basado en la estructura de niveles OSI y tiene una arquitectura descentralizada. Este est andar europeo dene una relaci on extremo-a-extremo entre dispositivos que permite distribuir la inteligencia entre los sensores y los actuadores instalados en la vivienda. Aunque en un principio s olo se contempl o usar un cable de dos hilos como soporte f sico de las comunicaciones, se pretend a que el nivel EIB.MAC (Medium Access Control ) pudiera funcionar sobre los siguientes medios f sicos: EIB.TP: sobre par trenzado a 9600 bps. Adem as por estos dos hilos se suministra 24 Vdc para la telealimentaci on de los dispositivos EIB. Usa la t ecnica 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 modulaci on SFSK (Spread Frequency Shift Keying ) similar a la FSK pero con las portadoras m as separadas. La distancia m axima que se puede lograr sin repetidor es de 600 metros. EIB.net: usando el est andar Ethernet a 10 Mbps (IEC 802-2). Sirve de backbone entre segmentos EIB adem as de permitir la transferencia de telegramas EIB a trav es del protocolo IP a viviendas o edicios remotos. Proyecto Final de Carrera 55
Dom otica
EIB.RF: Radiofrecuencia: usando varias portadoras, se consiguen distancias de hasta 300 metros en campo abierto. Para mayores distancias o edicios 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 pr actica, s olo el par trenzado ha conseguido una implantaci on masiva mientras que la instalaci on sobre red el ectrica de baja tensi on, que funciona por corrientes portadoras de manera similar a otros sistemas, como X10, se reserva a viviendas o edicios ya construidos, donde la instalaci on de nuevo cableado ser a muy costosa. No obstante, este tipo de medio es muy poco empleado por mayor coste y menor abilidad. Por u ltimo, est a previsto el desarrollo de dispositivos por radiofrecuencia, tema del que trata nuestro proyecto.
Figura 31: Bus EIB Al igual que otros sistemas dom oticos, EIB permite la integraci on de las funciones b asicas requeridas en viviendas y edicios: Gesti on de la energ a, para la optimizaci on del consumo el ectrico y en climatizaci on (modos de taricaci on nocturna, prevenci on de situaciones de consumo innecesario, como corte de la calefacci on con las ventanas abiertas, etc.). Seguridad, tanto en lo referente a la seguridad de las personas (alarmas de incendio, inundaci on, humos, etc.), como protecci on contra robos (simulaci on de presencia, detecci on de intrusos, etc.). Confort. El empleo de un sistema integrado de comunicaciones permite disponer de comodidades como el control por mando a distancia, programaci on de escenas y automatizaci on de tareas como las subida/bajada de persianas. Comunicaci on. Es posible la conexi on con el sistema a distancia, de forma que se pueda modicar y conocer el estado de funcionamiento de la instalaci on. En este campo est a produci endose una verdadera revoluci on en los u ltimos a nos, y muchos de los fabricantes de dispositivos est an comercializando componentes que permite el control mediante las u ltimas tecnolog as, entre ellas el control por Internet y mediante tel efonos m oviles (SMS, WAP, 3G). Adem as, EIB presenta las ventajas inherentes a este tipo de sistemas frente a las instalaciones tradicionales: Reducci on del cableado y los costes asociados a la instalaci on. Integraci on de diferentes funciones en un solo sistema. Flexibilidad para ampliaciones y modicaciones futuras. Es posible reprogramar el funcionamiento de la instalaci on conectando un ordenador al sistema o incluso a distancia mediante un enlace telef onico o a trav es de Internet.
56
V Sistema EIB
V.2.
Tecnolog a
El EIB es un sistema descentralizado (no requiere de un controlador central de la instalaci on), en el que todos los dispositivos que se conectan al bus de comunicaci on de datos tienen su propio microprocesador y electr onica de acceso al medio. En una red EIB podemos encontrar b asicamente cuatro tipos de componentes: m odulos de alimentaci on de la red, acopladores de l nea para interconectar diferentes segmentos de red, y elementos sensores y actuadores.
Figura 32: Esquema general de una instalaci on EIB Los sensores son los responsables de detectar cambios de actividad en el sistema (operaci on 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 funcionar an por tanto como entradas al sistema, y los actuadores como salidas para la activaci on y regulaci on de cargas. En la versi on de par trenzado, la l nea de bus, que sirve como soporte para la transmisi on de datos, llega a todos los dispositivos, pero la red el ectrica s olo se conectar a a los elementos actuadores para el control de las cargas (iluminaci on, motores de persianas, etc.). Las instalaciones de tipo EIB pueden abarcar m as de 14.000 de estos dispositivos, por lo que son aplicables a edicaciones desde viviendas unifamiliares a grandes edicios (hospitales, hoteles, etc.). Superposici on de datos / alimentaci on Los datos se transmiten como una tensi on alterna superpuesta sobre la alimentaci on en corriente continua del bus, empleando para ello u nicamente dos hilos. Para ello es necesario, por una parte, aislar la fuente de alimentaci on de los datos, para que esta no suponga una carga sobre ellos, y por otra, desacoplar los datos de la componente de alimentaci on continua en cada dispositivo. Cada l nea tiene su propia fuente de alimentaci on que suministra la tensi on a todos los dispositivos conectados. La fuente dispone de control integrado de corriente y tensi on y salva microcortes de hasta 100 us. La tensi on nominal de alimentaci on es de 29V, y cada dispositivo requiere un m nimo de 21V para mantenerse en zona de operaci on segura (SOA), y supone una carga t pica de 150mW en el bus (en caso de carga adicional, hasta 200mW). De este modo se aseguran unos m argenes de tensi on y consumo que garanticen un funcionamiento adecuado incluso utilizando el m aximo n umero de dispositivos posible en la instalaci on. La conexi on de la fuente de alimentaci on al bus se realiza a trav es de una bobina de ltro, de modo que la etapa de ltrado de alimentaci on suponga una carga despreciable sobre la componente de datos y no los interera. Proyecto Final de Carrera 57
Dom otica
Figura 33: Conexi on de alimentaci on y dispositivos al bus Caracter sticas de la transmisi on El medio f sico empleado en la red es un cable de par trenzado (sim etrico, de secci on 0.8 mm2 e impedancia caracter stica Z0 =72 Ohm). Los datos se transmiten en modo sim etrico sobre este par de conductores (no se ponen a tierra). El empleo de transmisi on diferencial, junto con la simetr a de los conductores, garantiza que el ruido afectar a por igual a los conductores, de modo que la diferencia de tensiones permanece invariante. Esta es una t ecnica empleada en la mayor a de las redes de comunicaci on de datos. La inmunidad al ruido mejora por la baja resistencia del enlace de los dispositivos mediante acoplamiento aislado (transformador). La transmisi on de datos se realiza en modo as ncrono, a una velocidad de 9600bps. Los datos se codican en modo sim etrico, como se ha descrito, correspondiendo a un 1 l ogico la ausencia de impulso, y a un 0 l ogico la presencia de un impulso sim etrico. As , los 0s representan como un impulso negativo-positivo de -5V a +5V. Para conseguir la simetr a en la transmisi on, cada dispositivo produce tan s olo la onda negativa por absorci on de corriente del bus, y es la bobina de acoplamiento de la fuente de alimentaci on conectada a esa l nea la que genera una fuerza contraelectromotriz responsable de la generaci on de la semionda positiva. Por ello la onda real obtenida no es perfectamente sim etrica, aunque s muy aproximada, tal y como se puede apreciar en la gura siguiente.
Figura 34: Generaci on de corriente portadora sobre tensi on de alimentaci on
58
V Sistema EIB
V.3.
Topolog a
Para el conexionado de dispositivos del bus en cada l nea se permite cualquier topolog a: arbol, estrella, bus o anillo, lo que facilita la instalaci on en viviendas y edicios. Unicamente no se permite cerrar anillos entre l neas situadas topol ogicamente en diferentes subredes.
Figura 35: Distintas topolog as de EIB La topolog a de conexi on de dispositivos contempla tres niveles de conexionado: Una l nea. Es la unidad m nima de instalaci on. En ella se pueden conectar hasta 64 dispositivos (dependiendo de la capacidad de la fuente de alimentaci on y de la carga m axima producida por los dispositivos existentes). Si se desean conectar m as componentes al bus, se habr a de instalar una nueva l nea, que se acoplar a, junto con la primera, a una l nea principal mediante acopladores de l nea (AL). Un area, que se constituye acoplando hasta 15 l neas en la l nea principal. De este modo, en un area se pueden conectar hasta 960 dispositivos. Cada l nea, tanto la principal como las secundarias, deben tener su propia fuente de alimentaci on. Adem as, la l nea principal puede tener conectados directamente hasta 64 dispositivos (incluyendo los acopladores de l nea).
Figura 36: Sistema completo EIB
59
Dom otica
Un sistema completo, formado por la uni on de hasta un total de 15 areas distintas mediante los denominados Acopladores de Area (AA), que permitir a integrar hasta un m aximo de 14.400 dispositivos. Adem as, 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 instalaci on EIB quedan perfectamente identicados gracias al sistema de direccionamiento. Existen dos tipos de direcciones: direcciones f sicas y direcciones de grupo. Direcciones f sicas Las direcciones f sicas identican un vocamente cada dispositivo y corresponden con su localizaci on en la topolog a global del sistema ( area - l nea secundaria - dispositivo).
Figura 37: Direcci on f sica La direcci on f sica consta de tres campos, que se representan separados por puntos: Area (4 bits). Identica una de las 15 areas. A=0 corresponde a la direcci on de la l nea de areas del sistema. L nea (4 bits). Identica cada una de las 15 l neas en cada area. L=0 se reserva para identicar a la l nea principal dentro del area. Dispositivo (8 bits). Identica cada uno de los posibles dispositivos dentro de una l nea, hasta 255. D=0 se reserva para el acoplador de l nea. En siguiente gura se muestra un ejemplo de direcciones f sicas asignadas a los dispositivos de un sistema EIB:
Figura 38: Ejemplo de direccionamiento f sico Proyecto Final de Carrera 60
V Sistema EIB
En la l nea de areas se conectan hasta 15 acopladores de area (AA), cuyas direcciones ir an desde 1.0.0 hasta 15.0.0. Esta l nea puede tener conectados dispositivos normales (direcciones 0.0.>0). Cada area tiene una l nea principal, con su fuente de alimentaci on, a la que se conectan los acopladores de l nea (AL), con direcciones 1.1.0 a 15.0.0, y a cada l nea secundaria conectada a un acoplador de l nea pueden conectarse hasta 64 dispositivos. Para la interconexi on de diferentes l neas y diferentes areas se emplea la unidad de acoplamiento. Este elemento es el mismo para los diferentes tipos de conexi on, y dependiendo de la direcci on f sica que se le asigne actuar a como acoplador de l nea, acoplador de area, o incluso repetidor dentro de una misma l nea. En el caso del acoplador de l nea o de area, la unidad de acoplamiento act ua como encaminador (router), y mantiene una tabla interna de direcciones de las subredes que conecta para aislar el tr aco entre ellas. Direcciones de grupo Las direcciones de grupo se emplean para denir funciones espec cas del sistema, y son las que determinan las asociaciones de dispositivos en funcionamiento (y la comunicaci on entre sus objetos de aplicaci on). 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 jerarquizaci on 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, iluminaci on, control de persianas, etc.). Se pueden emplear valores de 1 a 13, los valores 14 y 15 no deben emplearse, ya que no son ltrados por los acopladores y podr an afectar a la din amica de funcionamiento de todo el sistema. En todos los campos la direcci on 0 est a reservada para funciones del sistema. En la conguraci on de una instalaci on EIB, la asignaci on de direcciones de grupo es b asica para asegurar su correcto funcionamiento. Las direcciones de grupo, que asocian sensores con actuadores, se pueden asignar a cualquier dispositivo en cualquier l nea (son independientes de las direcciones f sicas), con las siguientes condiciones: 1. Los sensores s olo pueden enviar una direcci on de grupo (s olo se les puede asociar una direcci on de grupo). 2. Varios actuadores pueden tener la misma direcci on de grupo, es decir, responden a un mismo mensaje o telegrama. 3. Los actuadores pueden responder a m as de una direcci on de grupo (pueden estar direccionados o asociados a varios sensores simult aneamente). Proyecto Final de Carrera 61
Dom otica
Ejemplo de direccionamiento La siguiente gura ilustra un ejemplo sencillo de asociaci on de elementos en una instalaci on EIB. En el se dispone de nueve componentes distribuidos en dos salas, y cableados en la misma l nea de bus (una sola fuente de alimentaci on). Los pulsadores P1 y P2 se emplean para encender y apagar simult aneamente todas las luces de sus respectivas salas, y el sensor crepuscular S para apagar las m as pr oximas a las ventanas cuando entra luz del exterior. Para realizar la asignaci on de direcciones f sicas deber a decidirse en qu e area y l nea vamos a trabajar. En este caso supondremos que los elementos est an en el area 1, l nea 1, por lo que las direcciones f sicas se asignar an arbitrariamente como 1.1.X, siendo X el n umero de dispositivo.
Figura 40: Ejemplo de asignaci on de direcciones de grupo Para realizar las asociaciones sensores-actuadores, ser a 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 asignaci on, en este caso se realiza tambi en a criterio del dise nador, teniendo en cuenta las restricciones descritas en este cap tulo. De este modo, se comienza asignando una direcci on de grupo u nica a cada sensor: P1 se asocia a 1/1, de manera que cuando el usuario pulse la tecla, se enviar a por el bus un telegrama que contendr a, entre otros campos, la direcci on de grupo 1/1. Dicha direcci on de grupo se asociar a tambi en a los actuadores L11, L12 y L13, de forma que cuando escuchen el telegrama con esa direcci on, se activar an simult aneamente. El mismo proceso se sigue para P2, al que enviar a la direcci on 1/2, que se asocia tambi en a L21, L22 y L23. Por u ltimo, el sensor crepuscular S se programa para enviar la direcci on 2/11, a la que responden los actuadores L11 y L21.
62
V Sistema EIB
V.5.
Formato de las transmisiones
M etodo de acceso al medio El m etodo de acceso al medio empleado en EIB es de tipo CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance ): Acceso m ultiple por detecci on de portadora, evitando colisiones. La codicaci on se realiza de modo que el estado l ogico 0 es dominante (impulso sim etrico) sobre el 1, que se denomina recesivo (no hay impulso). El mecanismo de resoluci on de colisiones es el siguiente: El dispositivo comprueba el bus, y si est a libre comienza la transmisi on. Durante el env o cada dispositivo escucha los datos presentes en el bus, compar andolos en todo momento con los que ha transmitido. Si no se producen colisiones, el env o se completa sin contratiempos. Si, por el contrario, se produce una colisi on con los datos enviados por otro equipo, el arbitraje se resuelve por prioridad de los bits dominantes sobre los recesivos. Por lo tanto, tendr an mayor prioridad aquellas tramas que presenten un mayor n umero de ceros en su inicio.
Figura 41: Resoluci on de colisiones CSMA/CD en EIB
Formato de los mensajes: el telegrama El env o de un mensaje o telegrama en un sistema EIB se realiza cuando se produce un evento, p.e. la activaci on de un pulsador o la detecci on de presencia. La transmisi on se inicia despu es de que el bus haya permanecido desocupado por lo menos durante un periodo de 50 bits, y despu es de la transmisi on los componentes utilizan otro tipo de 13 bits para comprobar si el telegrama se ha recibido correctamente. Todos los componentes direccionados env an un acuse de recibo. Los telegramas se transmiten en modo as ncrono, a una velocidad de 9600 baudios, donde cada car acter 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 transmisi on. De este modo las transmisi on de un byte supone un tiempo de 1,35 ms, y la de un telegrama completo entre 20 y 40 ms (la mayor a de las ordenes son de marcha-paro y suponen un tiempo de env o de 20 ms). El telegrama que se transmite por el bus, y que contiene la informaci on espec ca sobre el evento que se ha producido, tiene siete campos, seis de control para conseguir una transmisi on able y un campo de datos u tiles con el comando a ejecutar. Proyecto Final de Carrera 63
Dom otica
En siguiente gura 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 funci on (alarma, servicios del sistema o servicios habituales). El bit de repetici on se pone a cero en caso de repetirse alg un env o 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 continuaci on 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 env a su direcci on f sica (4 bits con el area, 4 bits de identicador de l nea y 8 bits de identicador de dispositivo), de modo que se conozca el emisor del telegrama en las tareas de mantenimiento. Direcci on de destino. La direcci on de destino puede ser de dos tipos, en funci on del valor que tome el bit de mayor peso de este campo (bit 17). Si tiene valor 0, se trata de una direcci on f sica, y el telegrama se dirige u nicamente a un dispositivo. Si tiene valor 1, se trata de una direcci on de grupo, y el telegrama se dirige a todos los mecanismos que deben escucharlo (los que tengan esa direcci on de grupo).
Figura 44: Formato del campo de direcci on destino
64
V Sistema EIB
Longitud e informaci on u til. Contiene los datos necesarios para la ejecuci on de ordenes y transmisi on de valores. En los cuatro bits de longitud se indica cu antos bytes contiene el campo de datos. El campo de datos u tiles contiene el tipo de comando (s olo hay cuatro) y los datos, de acuerdo con el EIB Interworking Standard (EIS). En la gura siguiente podemos ver la estructura que toma la trama y los tipos de comandos existentes:
Figura 45: Formato del campo de datos No EIS EIS1 EIS2 Funci on EIB Conmutaci on (switching) Regulaci on (dimming) No bytes 1 bit 4 bit Descripci on Encendido/apagado, habilitar/deshabilitar, alarma/no alarma, verdadero/falso Se puede utilizar de 3 formas distintas: como interruptor, como valor relativo y como valor absoluto. D a de la semana, hora, minutos y segundos. D a/mes/a no (el margen es de 1990 a 2089). Para enviar valores f sicos con representaci on S,EEEE,MMMMMMMMMMM Se utiliza para transmitir valores relativos con una resoluci on de 8 bit. Tiene dos usos: Mover, arriba/abajo o extender/retraer y Paso a Paso. Se utiliza en conjunci on con EIS 1 o EIS 7. Codica un n umero en coma otante seg un el formato denido por el IEEE 754. Representa los valores de un contador de 16 bit (tanto con signo como sin signo). Representa los valores de un contador de 32 bit (tanto con signo como sin signo). Se usa para conceder accesos a distintas funciones. Codica seg un el formato ASCII Representa los valores de un contador de 8 bit (tanto con signo como sin signo). Transmite un cadena de caracteres ASCII de hasta 14 bytes.
EIS3 EIS4 EIS5 EIS6 EIS7 EIS8 EIS9 EIS10 EIS11 EIS12 EIS13 EIS14 EIS15
Hora (time) Fecha (date) Valor (value) Escala (scaling) Control motores (control drive) Prioridad (priority) Coma otante (oat value) Contador 16 bit (16b-counter) Contador 32 bit (32b-counter) Acceso (access) Caracter ASCII (Character) Contador 8 bit (8b-counter) Cadena (Character String)
3 bytes 3 bytes 2 bytes 8 bit 1 bit 1 bit 4 bytes 2 bytes 4 bytes 4 bytes 8 bit 8 bit 14 bytes
Tabla I.1: Tipos EIS normalizados Proyecto Final de Carrera 65
Dom otica
El EIS contiene los datos u tiles para cada funci on asignada a los objetos de comunicaci on. Seg un este est andar existen siete tipos diferentes, cada uno asignado a un tipo de acci on de control (conmutaci on, regulaci on de luz, env o de valor absoluto, env o de valor en punto otante, 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 denidas en el est andar, y se incluyen en los programas almacenados en la memoria de los dispositivos para realizar una determinada acci on. Normalmente, el programa de aplicaci on que se ejecuta en un dispositivo dispone de varios objetos de comunicaci on, que pueden ser de diferentes tipos EIS. Por ejemplo, un pulsador de dos teclas con un programa de control de iluminaci on puede tener cuatro objetos: dos de conmutaci on (uno para cada tecla), tipo EIS 1, que env an las ordenes de encendido-apagado, y otros dos de regulaci on (uno para cada tecla), tipo EIS 2, para el env o 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 comunicaci on, de modo que un componente EIB, con una u nica direcci on f sica, contiene varios sensores o varios actuadores, cuyo funcionamiento l ogico es independiente. Campo de comprobaci on. Consiste en un byte que se obtiene del c alculo 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 c alculo de la paridad impar de los bits de igual peso en el resto de campos. Este campo de comprobaci on es independiente del bit de paridad par que se obtiene al realizar la transmisi on en modo as ncrono de cada byte del telegrama, y se emplea como una medida adicional para garantizar la abilidad en la transmisi on. La combinaci on de ambas medidas se denomina comprobaci on cruzada.
Figura 46: Campo de comprobaci on de la trama
66
V Sistema EIB
V.6.
Componentes EIB
En este apartado analizaremos los componentes EIB, viendo de qu e partes se componen f sicamente. Haremos una revisi on no muy exhaustiva pero que nos servir a 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 alimentaci on, ltros y cables, los elementos m as importantes en la instalaci on 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 aplicaci on en los sensores y actuadores que intercambian informaci on, posibilitando as la realizaci on de las acciones de control. Estos dispositivos constan de tres partes b asicas: 1. Acoplador al bus (AB), donde se encuentra el programa de aplicaci on. 2. Interfaz de aplicaci on (IA). 3. Dispositivo nal (DF).
Figura 47: Componentes de un dispostivo EIB El acoplador al bus (AB o BCU) es un aparato universal, que contiene la electr onica necesaria para gestionar el enlace: env o y recepci on de telegramas, ejecuci on de los objetos de aplicaci on, ltrado de direcciones f sicas y de grupo para reconocer los telegramas destinados al dispositivo, comprobaci on de errores, env o de reconocimientos, etc. El acoplador examina c clicamente la interfaz de aplicaci on para detectar cambios de se nal. Esta unidad de acoplamiento consta de dos partes: Un m odulo de transmisi on (MT), que realiza, entre otras, funciones de protecci on, 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 operativo de la BCU). Memoria RAM vol atil, que contiene datos durante la operaci on normal del dispositivo. Memoria EEPROM, donde se almacenan el programa de aplicaci on, la direcci on f sica y la tabla de direcciones de grupo. Proyecto Final de Carrera 67
Dom otica
Los programas de aplicaci on se encuentran en una base de datos que proporciona cada fabricante, y pueden ser descargados a las BCU a trav es del bus utilizando el software adecuado (ETS, EIB Tool Software). La interfaz de aplicaci on es un conector est andar de diez pines, de los cuales cinco se usan para datos (4 digitales o anal ogicos y uno digital, de entrada o salida), tres se utilizan para las tensiones de alimentaci on, y uno es una entrada anal ogica al acoplador al bus que se emplea para la identicaci on del tipo de dispositivo nal en funci on de una resistencia situada en el mismo. Existen dos tipo de componentes EIB dependiendo del modo de instalaci on: Componentes de carril DIN, con el mismo formato que las protecciones ecl ecticas (interruptores autom aticos o diferenciales). Componentes de empotrar, para su instalaci on en cajas universales de empotrar, falso techo o cajas de empalme. Los componentes b asicos del sistema como la fuente de alimentaci on, ltro y acopladores s olo est an disponibles en la versi on de carril, mientras que el resto pueden encontrarse en ambas versiones. Adem as, un componente EIB puede disponer de diversas l nea de entrada-salida, de tipo digital o anal ogico, 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 aplicaci on tiene denidos 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 tendr a asignadas la o las direcciones de grupo que lo asocian con otros componentes de la instalaci on. Para complicar un poco m as las cosas, un dispositivo puede tener varios objetos de comunicaci on asociados a una entrada o salida f sica; por ejemplo, un pulsador puede distinguir entre una pulsaci on corta (de duraci on inferior a 0,5 segundos) y una larga, de duraci on superior. Cada uno de estos eventos puede tener asociado a su vez un objeto de comunicaci on diferente para, en el caso del pulsador, enviar telegramas de conmutaci on o regulaci on respectivamente (tipos EIS 1 y 2). Cuando se asocia una misma direcci on de grupo a varios objetos, estos deben tener obligatoriamente el mismo tipo EIS, de lo contrario no se podr a llevar a cabo la comunicaci on.
Figura 48: Componentes y objetos de comunicaci on en ETS
68
V Sistema EIB
V.7.
Ventajas de EIB. Ejemplos de aplicaci on
Una vez que hemos desarrollado la composici on y funcionamiento del sistema, podemos hacer un breve resumen de las ventajas que conlleva la elecci on de esta tecnolog a. Las principales ventajas ser an las siguientes: En las instalaciones tradicionales cada funci on requiere una l nea el ectrica propia, y cada 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 l nea com un. Con esto se puede dirigir la l nea de energ a sin desv os, directamente hasta el aparato consumidor. Adem as del ahorro en el cableado se presentan adicionalmente otras ventajas: La instalaci on en un edicio se puede realizar de un modo m as sencillo desde el principio, y despu es se puede ampliar y modicar sin problemas (exibilidad). Adaptaci on simple de la instalaci on el ectrica a los requerimientos de cambio del usuario. Ante cambios de uso o reorganizaci on del espacio, el EIB consigue una adaptaci on r apida y sin problemas, mediante una f acil ordenaci on (cambio de parametrizaci on) de los componentes del bus, sin necesidad de un nuevo cableado. Este cambio de parametrizaci on 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 f acilmente realizadas por cualquier instalador EIB especializado debido a que existe una u nica herramienta inform atica de dise no de proyecto, puesta en marcha y mantenimiento llamada ETS (Herramienta Software EIB). Esta herramienta no requiere conocimiento alguno de programaci on. Cualquier instalador/dise nador 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 econ omico y racional de la energ a en el funcionamiento de edicios. El EIB se puede conectar mediante las correspondientes interfaces con los centros de control de otros sistema de automatizaci on de edicios 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, ocinas o edicios del sector terciario. Incremento en la seguridad, debido a la tecnolog a que emplea, los m etodos 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 edicio funcional en comparaci on con un edicio residencial, personas discapacitadas en comparaci on con no discapacitados, personas j ovenes en comparaci on con personas mayores, etc.
69
Dom otica
A continuaci on, exponemos una serie de ejemplos de aplicaci on que pueden conseguirse con la tecnolog a EIB, de manera que pueda verse de una forma m as pr actica las ventajas comentadas. Ejemplo 1: Implementaci on de funciones centrales: cuando usted est a dejando el edicio, todas las luces, el suministro de agua y enchufes espec cos (horno el ectrico, etc.) pueden apagarse, el sistema de alarma EIB puede activarse y las persianas pueden controlarse de distinta forma en funci on de la hora del d a. Ejemplo 2: En salas de conferencias, teatros, as como en cuartos de estar, es posible activar diferentes escenas de iluminaci on que, en funci on de la actividad, pueden ser modicadas por el usuario en cualquier momento. Por ejemplo en edicios administrativos, es posible lograr una energ a que ahorre hasta un 75 % de la iluminaci on llevando a cabo un control de luz constante, con un s olo sensor de luminosidad para cada lado del edicio. 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 m as grandes por medio de PCs y software de visualizaci on. Ejemplo 4: Uniendo una instalaci on EIB con la red telef onica, el usuario puede controlar o consultar el estado de las funciones del edicio (por ej. la calefacci on) usando un tel efono m ovil. Tambi en pueden redirigirse las se nales de alarma autom aticamente al n umero de tel efono que se desee. Igualmente, pueden repararse remotamente instalaciones EIB y pueden ser conguradas por el instalador usando cualquier medio de comunicaci on disponible (por ej. Internet). Se reduce as de forma considerable el tiempo requerido para el mantenimiento de la gesti on del edicio. Ejemplo 5: Una sala de conferencias grande debe poder ser divida en varias areas independientes si la necesidad lo requiere. Insertando tabiques (paneles) de separaci on. La instalaci on EIB detecta autom aticamente la asignaci on de interruptores y luminarias requerida para cada secci on de la sala, no siendo necesario por consiguiente cambiar el cableado existente. Ejemplo 6: Instalaci on de interruptores de p anico (activaci on 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 bot on y pueden ser desactivadas despu es de un periodo jo. Ejemplo 7: El EIB puede proporcionar un control individual de la calefacci on y ventilaci on de cada cuarto mediante el establecimiento de perles de temperatura individuales. Las entradas de fr o o calor en cada cuarto se ajustan autom aticamente cuando una ventana se abre. Estas medidas hacen posible alcanzar un ahorro de energ a de m as de un 30 % al a no. La generaci on de calor tambi en puede controlarse en funci on de las necesidades de calor de cada cuarto individual (el calor s olo se produce cuando realmente se requiere). Ejemplo 8: El EIB tambi en puede realizar una simulaci on de presencia cuando el usuario est e ausente.
70
VI Est andar Konnex
VI.
Est andar Konnex
Como u ltimo punto, debemos hacer menci on a un hito importante en lo que a la historia de la dom otica europea se reere: la creaci on de la asociaci on 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 est andar europeo y abierto KNX para aplicaciones de dom otica e inm otica y consolidar la marca KNX como s mbolo de calidad e interoperabilidad entre distintos fabricantes.
Figura 49: Konnex Los objetivos de Konnex Asocciation son los siguientes: Denici on 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. Concesi on de la marca KNX en base a las especicaciones mediante certicaci on KNX. Actividades de estandarizaci on a nivel nacional e internacional. Fomento de actividades formativas mediante la certicaci on en Centros de Formaci on. Actividades promocionales: p aginas web, ferias, folletos, etc. Fomento de la creaci on de grupos nacionales. Scientic Partnership o colaboraci on cient ca para centros docentes t ecnicos y universidades. Especicaci on, promoci on y certicaci on de los antiguos sistemas. Proyecto Final de Carrera 71
Dom otica
Actualmente la asociaci on Konnex dispone de las especicaciones del nuevo est andar, el cual es compatible con los productos EIB instalados. Se puede armar que el nuevo est andar 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 tecnolog as. El est andar contempla tres modos de funcionamiento: 1. S-mode (System mode): la conguraci on de Sistema usa la misma losof a que el EIB actual, esto es, los diversos dispositivos o nodos de la nueva instalaci on son instalados y congurados por profesionales con ayuda de la aplicaci on software especialmente dise nada para este prop osito, el ETS. Este m etodo es id oneo para proyectistas e instaladores KNX certicados y, sobre todo, para grandes instalaciones. 2. E-mode (Easy mode): en la conguraci on sencilla los dispositivos son programados en f abrica para realizar una funci on concreta. A un as deben ser congurados algunos detalles en la instalaci on, ya sea con el uso de un controlador central (como una pasarela residencial o similar) o mediante unos microinterruptores alojados en el mismo dispositivo, ruedas de codicaci on o teclas (similar a muchos dispositivos X-10 que hay en el mercado). Los productos compatibles con el E-mode normalmente tienen una funcionalidad limitada y est an concebidos para instalaciones de tama no medio. 3. A-mode(Automatic mode): en la conguraci on autom atica, con una losof a Plug&Play ni el instalador ni el usuario nal tienen que congurar el dispositivo. Este modo est a especialmente indicado para ser usado en electrodom esticos, equipos de entretenimiento (consolas, set-top boxes, HiFi, ...) y proveedores de servicios, y es ideal para el usuario nal y para instalaciones peque nas. La Konnex Association se compon a en un principio de nueve miembros, y a nales de 2003 el n umero de miembros superaba los 100, incluyendo empresas que anteriormente no pertenec an a ninguna de las asociaciones existentes. Dichas empresas reprentan m as del 80 % del mercado europeo de las instalaciones y los electrodom esticos. No s olo empresas desarrolladoras y fabricantes de productos pueden asociarse, sino tambi en prestadoras de servicios (suministros de energ a, etc.) u otras interesadas. A nales de 2003 el est andar KNX fue aprobado por el CENELEC (Comit e Europeo de Normalizaci on Electrot ecnica) como norma europea (EN 50090) para dom otica e inm otica. El exito de Konnex en cifras: M as de 6.500 productos KNX registrados y certicados. M as de 100 miembros KNX. M as de 90 centros de formaci on reconocidos. M as de 6 centros de test europeos. M as de 50.000 proyectos llevados a cabo. M as de 10 millones de productos de KNX instalados.
72
VI Est andar Konnex
VI.1.
Ejemplo Proyecto KNX/EIB
Terminal 5 de Heathrow - Londres El aeropuerto m as innovador del mundo
Figura 50: Terminal 5 de Heathrow La terminal 5 es el proyecto dom otico de construcci on m as grande jam as hecho en el Reino Unido, extendi endose varios kil ometros. Esta nueva expansi on del aeropuerto fue llevada a cabo por la Autoridad de Aeropuertos Brit anica (BAA) y har a que Heathrow sea uno de los m as grandes y probablemente m as innovadores aeropuertos del mundo. El proyecto incluye dos salas principales, un centro de energ a, areas de parking, t uneles de servicio, una red de tren, areas VIP, una torre de control del aeropuerto y varias areas m as.
Caracter sticas novedosas
Control de 64000 luces a trav es de Pasarelas KNX-DALI. Control de m as de 910 l neas KNX mediante 236 Pasarelas KNX-IP y una red de area local. Integraci on de luces de emergencia en la misma red KNX-DALI. Mensajes de error y defectos de luz enviados al sistema de control. Integraci on de sistemas adicionales a KNX, p.ej. mensajes de error de los ascensores. Monitorizaci on y control de todos los subsistemas desde un sistema de administraci on.
73
Dom otica
74
Parte II
Redes de sensores inal ambricas
75

I. Introducci on
El MIT identic o en Febrero de 2003 las diez tecnolog as emergentes que cambiar an el mundo y las redes de sensores inal ambricas aparec an 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 comunicaci on sin cables, interconectados entre s a trav es de una red y a su vez conectados a un sistema central encargado de recopilar la informaci on 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 comunicaci on inal ambrica. 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 reducci on de tr aco a trav es de la red, ya que ser a procesada localmente, y consecuentemente una l ogica descarga de trabajo del computador central.
Figura 1: Red de sensores inal ambrica Las redes de sensores con cables no son nuevas y sus funciones incluyen medir niveles de temperatura, l quido, humedad etc. Muchos sensores en f abricas o coches por ejemplo, tienen su propia red que se conecta con un ordenador o una caja de controles a trav es de un cable y, al detectar una anomal a, env an un aviso a la caja de controles. La diferencia entre los sensores que todos conocemos y la nueva generaci on de redes de sensores inal ambricas es que estos u ltimos son inteligentes, es decir, capaces de poner en marcha una acci on seg un la informaci on que vayan acumulando, y no est an limitados Proyecto Final de Carrera 77
geogr acamente por un cable jo. Los nuevos avances en la fabricaci on de microchips de radio, nuevas formas de routers y nuevos programas inform aticos relacionados con redes est an logrando eliminar los cables de las redes de sensores, multiplicando as su potencial. El ambito de aplicaci on de este tipo de sistemas, como veremos, es muy amplio: monitorizaci on de entornos naturales, aplicaciones para defensa, aplicaciones m edicas en observaci on de pacientes, etc. El motivo del exito de este tipo de redes de sensores se debe a sus especiales caracter sticas f sicas. A los nodos de las redes se les imponen unas restricciones de consumo severas. El motivo de la imposici on 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 alimentaci on son si no inexistentes, de baja potencia. El tama no es otra restricci on que cada vez se hace m as necesaria para la mayor a 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 realizaci on de las aplicaciones para redes de sensores, la Universidad de Berkeley e Intel han desarrollado una plataforma espec ca 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 caracter stica principal reside en que al ser modular resulta ideal para instalarse en sistemas con restricciones de memoria. Se desarroll o tambi en un lenguaje de programaci on, llamado nesC, de sintaxis muy parecida a C, basado en componentes, y a partir del cual se redise n o una primera versi on de TinyOS de modo que actualmente est a ntegramente implementado sobre nesC. Tanto nesC como TinyOS est an basados en componentes e interfaces bidireccionales. Adem as, actualmente, Berkeley e Intel han desarrollado diversas aplicaciones a modo de ejemplo, simuladores de ejecuci on, y varias universidades internacionales est an dedicando esfuerzos al desarrollo de aplicaciones usando esta emergente tecnolog a. Existen otras empresas que son proveedores de esta tecnolog a, el mayor de estos es Crossbow Technology, que ha desarrollado redes de sensores a gran escala para su uso comercial. Las u ltimas investigaciones apuntan hacia una eventual proliferaci on de redes de sensores inteligentes, redes que recoger an enormes cantidades de informaci on hasta ahora no registrada que contribuir a de forma favorable al buen funcionamiento de f abricas, al cuidado de cultivos, a tareas dom esticas, a la organizaci on del trabajo y a la predicci on de desastres naturales como los terremotos. En este sentido, la computaci on que penetra en todas las facetas de la vida diaria de los seres humanos est a a punto de convertirse en realidad. Si los avances tecnol ogicos en este campo siguen a la misma velocidad que han hecho en los u ltimos a nos, las redes de sensores inal ambricas revolucionar an la capacidad de interacci on de los seres humanos con el mundo.
I.1.
Historia
Las redes de sensores nacen, como viene siendo habitual en el ambito tecnol ogico, de aplicaciones de car acter militar. La primera de estas redes fue desarrollada por Estados Unidos durante la guerra fr a y se trataba de una red de sensores ac usticos desplegados en el fondo del mar cuya misi on era desvelar la posici on de los silenciosos submarinos sovi eticos, el nombre de esta red era SOSUS (Sound Surveillance System ). Paralelamente a esta, tambi en EE.UU. despleg o una red de radares a ereos a modo de sensores que han ido evolucionando hasta dar lugar a los famosos aviones AWACS, que no son m as que sensores a ereos. SOSUS ha evolucionado hacia aplicaciones civiles como control s smico y biol ogico, sin embargo AWACS sigue teniendo un Proyecto Final de Carrera 78
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 programaci on (SPLICE) orientados de forma espec ca a las redes de sensores, esto ha dado lugar a nuevos sistemas militares como CEC (Cooperative Engadgement Capability ) consistente en un grupo de radares que comparten toda su informaci on obteniendo nalmente un mapa com un con una mayor exactitud. Estas primeras redes de sensores tan s olo destacaban por sus nes militares, a un no satisfac an algunos requisitos de gran importancia en este tipo de redes tales como la autonom a y el tama no. Entrados en la d ecada de los 90, una vez m as DARPA lanza un nuevo programa enfocado hacia redes de sensores llamado SensIt, su objetivo viene a mejorar aspectos relacionados con la velocidad de adaptaci on de los sensores en ambientes cambiantes y en c omo hacer que la informaci on que recogen los sensores sea able. Ha sido a nales 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 incrementando su autonom a. Compa n as como Crossbow han desarrollado nodos sensores del tama no de una moneda con la tecnolog a necesaria para cumplir su cometido funcionando con bater as que les hacen tener una autonom a razonable y una independencia in edita. El futuro ya ha empezado a ser escrito por otra compa n a 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, podr an ser creadas m ultiples nuevas aplicaciones.
Figura 2: Tama no de los nodos Smart Dust
79
II.
Caracter sticas de las WSN
Los recientes avances en microelectr onica, wireless y electr onica digital han permitido el desarrollo de nodos sensores de bajo coste, reducido tama no, bajo consumo y que se comunican de forma inal ambrica. 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 fen omeno, grandes y muy complejos para distinguir el objetivo del ruido del entorno. Muchos sensores con posici on y topolog a cuidadosamente seleccionada. Transmiten datos de adquisici on a nodos centrales que realizan la computaci on. Como ya hemos comentado, las WSN se componen de miles de dispositivos peque nos, aut onomos, distribuidos geogr acamente, llamados nodos sensores con capacidad de c omputo, almacenamiento y comunicaci on en una red conectada sin cables, e instalados alrededor de un fen omeno objeto para monitorizarlo. Una vez se produzcan eventos, toma de medidas o cualquier actividad programada con el fen omeno en cuesti on los nodos enviar an informaci on a trav es de la red, hasta llegar a un sistema central de control que recoger a los datos y los evaluar a, ejecutando las acciones pertinentes en comunicaci on con otros sistemas o en la propia red de sensores.
Figura 3: Elementos de una WSN Tal y como vemos en esta gura podemos establecer, por tanto, una serie de elementos que componen de forma general una WSN: 1. Sensores. De distinta naturaleza y tecnolog a, toman del medio la informaci on y la convierten en se nales el ectricas. 2. Nodos sensores. Son los procesadores de radio, que toman los datos del sensor a trav es de sus puertas de datos, y env an la informaci on a la estaci on base. Proyecto Final de Carrera 80
II Caracter sticas de las WSN
3. Pasarelas o Gateways. Elementos para la interconexi on 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. T picamente basada en el est andar 802.15.4 - ZigBee. Caracter sticas de una WSN Aunque la naturaleza de los nodos que emplean las redes pueda ser muy distinta y la misi on a realizar pueda variar dependiendo del tipo de aplicaci on, se pueden identicar una serie de caracter sticas comunes a todas ellas y que son las que principalmente las identican: 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 fen omeno y, por lo tanto, muy cerca de el. Topolog a variable. La posici on en que se coloca cada nodo puede ser arbitraria y normalmente es desconocida por los otros nodos. La localizaci on no tiene porqu e 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 deber an ser autoorganizativos. Recursos limitados. Los sensores, a cambio de su bajo consumo de potencia, coste y peque no tama no disponen de recursos limitados. Los dispositivos actuales m as usados, los mica2, cuentan con procesadores a 4 MHz, 4 Kbytes de RAM, 128 Kbytes de memoria de programa y 512 Kbytes de memoria ash 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 comunicaci on por difusi on y debido a que est an densamente desplegados, los vecinos est an muy cerca unos de otros y la comunicaci on multihop (salto m ultiple de uno a otro) consigue un menor consumo de potencia que la comunicaci on single hop (salto simple). Adem as, los niveles de transmisi on de potencia se mantienen muy bajos y existen menos problemas de propagaci on en comunicaciones inal ambricas de larga distancia. Funcionamiento aut onomo. Puede que no se acceda f sicamente 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 bater as se agoten o su funcionamiento deje de ser el esperado. Proyecto Final de Carrera 81
Requisitos para una WSN Para que una red pueda funcionar de acuerdo con las anteriores caracter sticas surgen una serie de retos que la aplicaci on debe resolver. Estos, que se detallan a continuaci on, son los requisitos no funcionales del sistema: Eciencia energ etica. Es uno de los asuntos m as importantes en redes de sensores. Cuanto m as se consiga bajar el consumo de un nodo mayor ser a el tiempo durante el cual pueda operar y, por tanto, mayor tiempo de vida tendr a la red. La aplicaci on tiene la capacidad de bajar este consumo de potencia restringiendo el uso de la CPU y la radio FM. Esto se consigue desactiv andolos 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 topolog a que permita establecer rutas por las que mandar los datos que han obtenido. Los nodos necesitan conocer su lugar en esta topolog a, pero resulta inviable asignarlo manualmente a cada uno, debido al gran n umero de estos. Es fundamental, por tanto, que los nodos sean capaces de formar la topolog a deseada sin ayuda del exterior de la red. Este proceso no s olo 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 soluci on elegida para la red permita su crecimiento. No s olo es necesario que la red funcione correctamente con el n umero de nodos con que inicialmente se contaba, sino que tambi en debe permitir aumentar ese n umero sin que las prestaciones de la red caigan dr asticamente. Tolerancia a fallos. Los sensores son dispositivos propensos a fallar. Los fallos pueden deberse a m ultiples causas, pueden venir a ra z del estado de su bater a, de un error de programaci on, de condiciones ambientales, del estado de la red, etc. Una de las razones de esta probabilidad 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 v alidos, como puede pasar con datos que impliquen una reacci on inmediata del sistema, o se pueden originar problemas serios como ocurrir a si se ignora una alarma cr tica. En caso de que una aplicaci on tenga estas restricciones debe tomar las medidas que garanticen la llegada a tiempo de los datos. Seguridad. Las comunicaciones wireless viajan por un medio f acilmente 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. Proyecto Final de Carrera 82
Seg un la aplicaci on que se dise ne algunos de los anteriores requisitos cobran mayor importancia. Como ejemplo podemos considerar una aplicaci on que controle el comportamiento de animales salvajes dentro de un parque natural. Para determinar su localizaci on, cada uno de estos animales llevar a sujeto un peque no sensor. En esta situaci on la capacidad de autoorganizaci on cobrar a gran importancia. Sin embargo, si pensamos en una red con nodos inm oviles, como los usados en la red dom otica de una ocina, este mismo atributo ser a 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 podr a implicar aumentar la frecuencia con la que se mandan mensajes con datos, lo cual repercutir a en un mayor consumo de potencia y un menor tiempo de vida de los nodos. Esto lleva a buscar, para cada aplicaci on, un compromiso entre los requisitos anteriores que permita lograr un funcionamiento de la red adecuado para la misi on que debe realizar.
II.1.
Arquitecturas de las WSN
Tomando como elementos principales de la red a los nodos sensores, las pasarelas (gateway) 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 fen omeno enviar an sus datos directamente a la pasarela m as cercana, que dirige el tr aco 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 ir a a la pasarela, estaremos creando dos grandes problemas para la red: 1. Cuello de botella en las pasarelas. 2. Mayor consumo de energ a por las comunicaciones. Como resultado, el tiempo de vida de la red ser a relativamente corto.
83
Arquitectura distribuida Dada la naturaleza intr nseca de las redes de sensores, normalmente se tiende a este tipo de arquitectura con una computaci on distribuida. De hecho, como coment abamos en las caracter sticas 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 encargar a de comunicar a la estaci on base a trav es de las pasarelas pertinentes.
Figura 5: Arquitectura WSN distribuida De esta forma se evitan los problemas que surg an en la arquitectura centralizada y, adem as, se mantienen las caracter sticas y ventajas que comentamos al comienzo de este cap tulo.
II.2.
Protocolos de las WSN
Por qu e son diferentes las WSN? A continuaci on vamos a ver por qu e son diferentes las WSN de las redes tradicionales y por qu e 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 comunicaci on inal ambrica y, obviamente, son diferentes de las redes cableadas. Tambi en son diferentes de las tradicionales redes inal ambricas como las redes celulares, Bluetooth o las m oviles ad hoc (MANETS). En estas redes, el objetivo es optimizar el rendimiento y el retardo. Aunque las MANETS comparten las caracter sticas de desarrollo ad hoc y autoconguraci on de los nodos, el consumo de potencia no es una prioridad. Bluetooth tambi en trata los mismos problemas de limitaci on de potencia pero el grado de bajo consumo de potencia que se requiere en las WSN es mucho mayor. Adem as, los nodos sensores son frecuentemente expuestos a extremas condiciones ambientales, haci endolos propensos a frecuentes fallos en los nodos. Esto conlleva unas restricciones estrictas en las WSN, no como en las otras redes. Proyecto Final de Carrera 84
Capa f sica Aunque la transmisi on en las WSN puede ser por infrarrojos, radio o medio optico, la banda industrial, cient ca y medica de los 915MHz (ISM) se ha hecho muy popular en las redes de sensores. La deciencia de usar infrarrojos o medios opticos para la tranmisi on es que requieren que los nodos transmisor y receptor mantengan una l nea de contacto visible. Sin embargo, algunas especicaciones inal ambricas como Bluetooth, HomeRF, y las redes LAN Wireless especicadas 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 able o una infraestructura de red sobre la que los datos puedan ser encaminados. Existen especicaciones como Bluetooth que utilizan la multiplexaci on por divisi on en el tiempo (TDMA) con saltos de frecuencia mientras que las redes LAN inal ambricas especicadas por el 802.11b utilizan un m etodo de acceso al medio con detecci on de portadora y evitando colisiones (CSMA/CA). La necesidad de un nuevo protocolo de capa MAC para WSN radica en que las dicultades de las WSN son muy distintas de los problemas que ten an las especicaciones existentes. Por ejemplo, el alcance de un piconet, que es una colecci on de ocho nodos, en una red Bluetooth es de 32 pies, mientras que el alcance requerido es mucho m as 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 congura la capa de enlace. El algoritmo de escucha y registro (EAR) permite a los nodos sensores m oviles interconectar nodos estacionarios. SMACS act ua al crear la red detectando los nodos vecinos usando transferencia de mensajes. En SMACS, un canal se dene con un par de intervalos de tiempo. La detecci on de vecinos y la asignaci on 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 jerarqu as asumidas en SMACS y por esto se forma una topolog a llana. El algoritmo EAR tiene el problema del control de la movilidad cuando se introducen nodos m oviles 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 denen un piconet. Cuando los piconets est an interconectados para formar redes dispersas, las diferentes topolog as limitan a los nodos que las forman. Para una WSN con la posibilidad de cientos de nodos, esto no ser a suciente. Y no s olo eso, sino que tambi en 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. Adem as, 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 clasicar como aquellos que determinan: 1. Rutas con los nodos de mayor potencia a lo largo de la ruta. 2. Rutas que consuman la m nima energ a. 3. Rutas con el m nimo n umero de saltos. 4. Rutas en las que la m nima potencia disponible es la m axima entre todos los dem as caminos. Proyecto Final de Carrera 85
Capa de transporte La necesidad de una capa de transporte radica en que las WSN necesitan ser conectadas a una red m as 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 podr a ser TCP o UDP, ya existentes. Sin embargo, el protocolo que conecta la pasarela y los nodos sensores tendr a que ser diferente ya que no hay un esquema de direccionamiento global en una red de sensores. La limitaci on de memoria en los nodos sensores conlleva una cuesti on importante en tanto que se preeren protocolos que requieran un bajo almacenamiento de informaci on de estado antes que otros del tipo TCP. Capa de aplicaci on Los nodos sensores tienen muchas aplicaciones distintas. Dise nar un capa de aplicaci on tiene el m erito de que las WSN pueden ser conectadas a grandes redes como Internet. El direccionamiento de nodos es una cuesti on importante aqu ya que, no como en otras redes, los nodos sensores no tienen un identicativo global. Los protocolos de la capa de aplicaci on como el Protocolo de Administraci on de Sensores (SMP) y el Protocolo de Petici on de Sensores y Entrega de Datos (SQDDP) est an actualmente en investigaci on. 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 m as desarrollos en el direccionamiento de varios protocolos en todas las capas. Adem as, se necesita una plataforma com un donde se puedan probar los algoritmos propuestos. Las simulaciones de WSN son dif ciles y normalmente est an vinculadas a una aplicaci on en particular. El area de las WSN es un area en expansi on y en los pr oximos a nos veremos los resultados de los esfuerzos que se est an realizando en estas aplicaciones.
Figura 6: Niveles f sico, red y aplicaci on
86
II.3.
Zigbee, est andar WSN
ZigBee es el est andar de la norma IEEE 802.15.4 que dene el protocolo y la interconexi on de dispositivos con comunicaci on v a radio para redes de area personal inal ambricas (WPAN) patrocinado por la ZigBee Alliance. La tecnolog a est a dise nada con el objetivo de ser m as simple y barata que otras WPANs tales como Bluetooth, y est a apuntanto su uso al de aplicaciones de bajas tasas de datos y bajo consumo de potencia. El est andar usa CSMA/CA como acceso al medio, acceso m ultiple con detecci on de portadora evitando colisiones y soporta topolog as 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 m etodo de transmisi on y se focaliza en las capas inferiores de red (F sica y MAC). La transimisi on 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 transmisi on est a entre los 10 y 75 metros, dependiendo de la potencia de transmisi on y del entorno.
Figura 7: Comparativa est andares inal ambricos En esta tabla comparativa podemos observar c omo cada est andar tiene unas caracter sticas distintas en cuanto a velocidad de transmisi on, memoria necesaria o vida de las bater as, por lo que se enfocan para unas aplicaciones y par ametros 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 tecnolog as inal ambricas. 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 tecnolog a Bluetooth es capaz de llegar a 1 Mbps en distancias de hasta 10 m operando en la misma banda de 2,4 GHz, s olo puede tener 8 nodos por celda y est a dise nado para mantener sesiones de voz de forma continuada, aunque pueden construirse redes que cubran grandes supercies ya que cada ZigBee act ua de repetidor enviando la se nal al siguiente, etc. En la siguiente gr aca se puede ver claramente d onde se ajusta cada est andar, en funci on Proyecto Final de Carrera 87
de su alcance y su tasa de datos, aunque habr a que tener en cuenta factores que diferencian el Bluetooth de Zigbee como es el consumo de potencia que hemos comentado.
Figura 8: Espectro de est andares Se espera que los m odulos ZigBee sean los transmisores inal ambricos m as baratos jam as producidos de forma masiva, con un coste estimado alrededor de los 2 euros. Dispondr an de una antena integrada, control de frecuencia y una peque na bater a. ZigBee Alliance es una alianza, sin animo de lucro, de m as de 100 empresas, la mayor a de ellas fabricantes de semiconductores, con el objetivo de auspiciar el desarrollo e implantaci on de una tecnolog a inal ambrica de bajo coste. La alianza de empresas est a trabajando codo con codo con IEEE para asegurar una integraci on, completa y operativa. Los principales mercados de la ZigBee Alliance son la automatizaci on de viviendas, edicios y la automatizaci on industrial. Adem as de ser el est andar aceptado y utilizado por las WSN, ZigBee es un sistema ideal para redes dom oticas, espec camente dise nado para reemplazar la proliferaci on de sensores y actuadores individuales. ZigBee fue creado para cubrir la necesidad del mercado de un sistema a bajo coste, un est andar para redes Wireless de peque nos paquetes de informaci on, bajo consumo, seguro y able.
Figura 9: Aplicaciones Zigbee
88
II.4.
Problemas de las WSN
Es evidente que las tecnolog as de redes de sensores nos ofrecen multitud de aplicaciones y utilidades, como veremos en el apartado siguiente, pero tambi en conllevan un importante esfuerzo de producci on eciente tanto hardware como software. Las caracter sticas 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 eciente 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 est an en estudio para conseguir posibles soluciones o mejoras, tanto a nivel hardware como de programaci on: 1. Optimizaci on del consumo de energ a en los nodos sensores. Uno de los problemas m as importantes es el consumo de energ a de los nodos. Para lograr que este sea m nimo y, por tanto, conseguir un m aximo tiempo de vida de la red habr a que tener en cuenta: La comunicaci on de mensajes es el primer consumidor de energ a. 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. T ecnicas de software: programaci on eciente de l neas de c odigo. 2. Ancho de banda y cobertura de red limitados. Se debe trabajar teniendo en cuenta que estas redes tienen una cobertura limitada, dadas las caracter sticas de sus componentes, y creando sistemas que se ajusten adecuadamente. 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 tecnol ogicas estas limitaciones se van reduciendo. 4. Soluciones ad-hoc para redes ad-hoc. Como hemos visto en el cap tulo de protocolos, muchas de las soluciones ad-hoc no son v alidas para este tipo de redes, debido a las diferencias existentes tanto en tecnolog a como en objetivos. 5. La topolog a de red es muy din amica. Las WSN tienen como uno de sus objetivos crear redes m oviles cuya topolog a va cambiando continuamente, redes caracterizadas por: Nodos m oviles. Nodos con alta probabilidad de fallo. Nodos que entran en el sistema. Cuanto m as nodos haya en la red mayor ser a el rendimiento. Proyecto Final de Carrera 89
III.
Aplicaciones de las WSN
La WSN puede consistir en muchos tipos diferentes de sensores, como pueden ser s smicos, magn eticos, t ermicos, ac usticos, radar, IR, etc. Los distintos tipos de sensores existentes pueden monitorizar una gran variedad de condiciones ambientales, que incluyen: Temperatura, humedad, presi on. Condiciones de luz, movimiento de veh culos, niveles de ruido. Composici on del suelo. Presencia o ausencia de cierto tipo de objetos. Niveles de estr es mec anico en objetos (maquinaria, estructuras, etc.). Caracter sticas de velocidad, direcci on y tama no de un objeto. Los nodos sensores pueden adoptar diversas formas de trabajo, pueden actuar en modo continuo, por detecci on de eventos, por identicaci on de eventos, toma de datos localizados o como control local de actuadores (id oneo para aplicaciones dom oticas).
Figura 10: Aplicaciones para WSN Si tenemos el tipo de monitorizaci on que van a realizar los sensores, podemos hacer una primera clasicaci on de aplicaciones, en tres tipos distintos que tendr an las siguientes propiedades: Monitorizaci on del entorno. Este tipo de aplicaciones se caracterizan por un gran n umero de nodos sincronizados que estar an midiendo y transmitiendo peri odicamente en entornos puede que inaccesibles, para detectar cambios y tendencias. La topolog a es estable y no se requieren datos en tiempo real, sino para an alisis futuros. Ejemplos: control de agricultura, microclimas, etc. Proyecto Final de Carrera 90
III Aplicaciones de las WSN
Monitorizaci on de seguridad. Son aplicaciones para detectar anomal as o atanques en entornos monitorizados continuamente por sensores. No est an continuamente enviando datos, consumen menos y lo que importa es el estado del nodo y la latencia de la comunicaci on: se debe informar en tiempo real. Como ejemplos tenemos el control de edicios inteligentes, detecci on de incendios, aplicaciones militares, seguridad, etc. Tracking. Aplicaciones para controlar objetos que est an etiquetados con nodos sensores en una regi on determinada. La topolog a aqu va a ser muy din amica debido al continuo movimiento de los nodos: se descubrir an nuevos nodos y se formar an nuevas topolog as.
Figura 11: Tracking de animales Redes h bridas Son aquellas en las que los escenarios de aplicaci on re unen aspectos de las tres categor as anteriores. El concepto de microsensores comunicados de forma inal ambrica promete muchas nuevas reas de aplicaci a on. De momento las vamos a clasicar en: militares, entorno, salud, hogar y otras areas comerciales. Por supuesto es posible ampliar esta clasicaci on.
91
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 r apido y denso despliegue de las redes de sensores, su autoorganizaci on y tolerancia a fallos las hace una buena soluci on para aplicaciones militares. Ofrecen una soluci on de bajo coste y able para estas ya que la p erdida de un nodo no pone en riesgo el exito de las operaciones. Ejemplos de aplicaci on en este area son: Monitorizaci on de fuerzas aliadas, equipamiento y munici on. Cada equipo, tropa, veh culo o arma cr tica lleva integrado un sensor para informar de su estado a l deres o niveles superiores. Se usan nodos recolectores donde se recopila toda la informaci on para luego transmitirla a niveles superiores. Reconocimiento del terreno y fuerzas enemigas. Se pueden desplegar y obtener informaci on valiosa antes de que el enemigo los intercepte sobre rutas de acceso, posibles caminos e incluso movimientos del enemigo.
Figura 12: Reconocimiento del enemigo Adquisici on de blancos. Se pueden incorporar los nodos a sistemas de guiado de armas inteligentes. Valoraci on de da nos, antes o despu es de los ataques. Reconocimiento de ataques nucleares, biol ogicos y qu micos, despleg andolos en la regi on y us andolos como sistema de aviso. Tambi en para reconocimiento despu es de que ocurra sin tener que exponer a equipos de reconocimiento a radiaciones o agentes qu micos.
Figura 13: Desplegue de sensores para reconocimientos
92
III.2.
Aplicaciones medioambientales
En este campo tenemos aplicaciones como el seguimiento de aves, animales e insectos; monitorizaci on de condiciones ambientales que afectan al ganado y las cosechas; irrigaci on; macroinstrumentos para la monitorizaci on planetaria de gran escala; detecci on qu mica o biol ogica; agricultura de precisi on (monitorizaci on de niveles de pesticidas, poluci on y erosi on del terreno); detecci on de incendios; investigaci on meteorol ogica o geof sica; detecci on de inundaciones; mapeado de la biocomplejidad del entorno; y estudios de la poluci on. Podemos destacar cuatro de estas aplicaciones: Detecci on de fuego en bosques. Se podr an desplegar millones de sensores de manera estrat egica, aleatoria y densa en el bosque que informaran del origen exacto de un incendio antes de que se haga incontrolable. Los sensores podr an tener m etodos de obtenci on de energ a como placas solares, ya que ser an abandonados durante meses o a nos sin mantenimiento. Adem as, debido a la densidad de su despliegue ser an capaces de cooperar para realizar una recolecci on de datos cooperativa y evitar obst aculos en las transmisiones, como arboles y rocas que pueden bloquear la l nea de visi on entre sensores.
Figura 14: Detecci on de incendios Mapeado de la biocomplejidad del entorno medioambiental. Requiere enfoques sosticados para integrar informaci on en escalas temporal y espacial. Avances tecnol ogicos en sensorizaci on remota y recolecci on de datos automatizada han permitido una resoluci on espacial, espectral y temporal con un coste por unidad de area que se ha reducido en progresi on geom etrica. Adem as, la conexi on de estos sistemas a Internet permite a usuarios remotos controlar, monitorizar y observar la biocomplejidad del medio ambiente. Aunque los sat elites y sensores a ereos son u tiles en la observaci on a gran escala de la biodiversidad (p.e. complejidad espacial de especies de plantas dominantes), no tienen la precisi on suciente como para observar la biodiversidad a peque na escala, que es la parte m as 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 monitorizaci on, cada una con 25-100 sensores. Detecci on de inundaciones. Ejemplo: sistema ALERT desplegado en EEUU. Hay sensores de lluvia, nivel de agua y meteorol ogicos. Proporcionan informaci on a una estaci on base centralizada. Hay proyectos de investigaci on que investigan enfoques distribuidos en interacci on con los nodos sensores en campo para proporcionar consultas en momentos jos (snapshot ) o en espacios temporales largos (long-running queries ). Proyecto Final de Carrera 93
Agricultura de precisi on. Benecios obtenidos de monitorizar niveles de pesticidas en agua potable, niveles de erosi on del suelo y niveles de poluci on del aire en tiempo real.
III.3.
Aplicaciones sanitarias
Proveer interfaces para los discapacitados; monitorizaci on integral de pacientes; diagn osticos; administraci on de medicamentos en hospitales; monitorizaci on de los movimientos y procesos internos de insectos u otros peque nos animales; telemonitorizaci on de datos siol ogicos humanos; y seguimiento y monitorizaci on de pacientes en un hospital. Telemonitorizaci on de datos siol ogicos humanos. Los datos recolectados se pueden almacenar durante per odos largos de tiempo, usados para exploraci on m edica. La WSN instalada puede monitorizar y detectar el comportamiento de personas mayores, como por ejemplo una ca da. Los sensores, por su reducido tama no, dan al usuario una mayor libertad de movimiento y permiten a los m edicos identicar antes s ntomas predenidos. Adem as, 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 espec ca, por ejemplo monitorizar la presi on arterial y la frecuencia card aca. Los m edicos tambi en llevan sensores, lo que permite a otros m edicos localizarlos en el hospital. Administraci on de medicaci on en hospitales. Si colocamos un sensor en la medicaci on se reduce el riesgo de errores, porque el paciente tambi en llevar a un sensor que identique sus alergias y medicaci on requerida.
III.4.
Aplicaciones del hogar: dom otica
Esta aplicaci on es la que m as nos interesa para nuestro proyecto, puesto que es precisamente uno de los objetivo que andamos buscando: programar y congurar sensores para adaptarlos a entornos del hogar, posibilitando aplicaciones que favorezcan los objetivos de la dom otica.
Figura 15: Aplicaci on dom otica Proyecto Final de Carrera 94
Los nodos sensores pueden ser introducidos en aparatos dom esticos como aspiradoras, microondas, hornos, frigor cos y VCRs. Esto permite que sean manejados remotamente por los usuarios nales mediante una comunicaci on que se realizar a v a sat elite o Internet. A trav es de las redes de sensores pueden crear hogares inteligentes donde los nodos se integran en muebles y electrodom esticos. Los nodos dentro de una habitaci on se comunican entre ellos y con el servidor de la habitaci on. Estos servidores de habitaciones se comunican tambi en 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 nal en t erminos de capacidades de entrada-salida. Desde el punto de vista tecnol ogico: hay que desarrollar nuevas tecnolog as 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 habitaci on, que a su vez se comunican con otros servidores de habitaci on. Todos ellos se integran y organizan con los dispositivos integrados existentes para autoorganizarse, autorregularse y autoadaptarse bas andose en modelos de control.
III.5.
Otras aplicaciones comerciales
Otras aplicaciones comerciales son la monitorizaci on de la fatiga de materiales; teclados virtuales de edicios; gesti on de inventario; monitorizaci on de la calidad de productos; construcci on de ocinas inteligentes; control ambiental en edicios de ocinas; control de robots y guiado en entornos de fabricaci on autom atica; juguetes interactivos; museos interactivos; control y automatizaci on de procesos; monitorizaci on de desastres; estructuras inteligentes; m aquinas de diagn ostico; transporte; instrumentaci on de f abricas; control local de actuadores; detecci on y monitorizado de robo de coches; seguimiento y detecci on de veh culos; e instrumentaci on de c amaras de procesado de semiconductores, maquinar a giratoria, t uneles de viento y c amaras anecoicas. Algunas de estas aplicaciones que m as nos interesan para el proyecto son: Control ambiental en edicios de ocinas. Normalmente la calefacci on o el aire acondicionado se controla desde una central, por lo que la temperatura dentro de la habitaci on puede variar unos pocos grados debido a que la distribuci on de aire no est a uniformemente distribuida y el control es central. Se puede desplegar una WSN para controlar el ujo de aire y la temperatura en diferentes partes de la habitaci on. Con esta tecnolog a se reducir a el consumo ahorrando dos cuatrillones de BTUs (British Termal Unit), que supondr a 55 mill de $ en US, reduciendo en 35 millones de toneladas las emisiones de di oxido de carbono. Museos interactivos. Para que los ni nos interact uen con objetos y experimentos, y reaccionen al toque o al habla. Tambi en permitir a el aviso y localizaci on de personas dentro del recinto. (Ejemplo: exploratorium en museo de San Francisco). Gesti on de inventarios. En el almac en, cada art culo lleva pegado un sensor, de modo que se puede conocer en todo momento su localizaci on y n umero de art culos por categor a. Para dar de alta nuevos art culos se les pega el sensor y se llevan al almac en.
95
IV.
Nodos sensores
Las redes de sensores inal ambricas, 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 tecnolog a inal ambrica, etc. Pero los principales elementos que crean y sobre los que se sustentan 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 caracter sticas y los distintos sensores que est an apareciendo en el mercado, as como los que hemos utilizado en nuestro proyecto para crear las redes de sensores. Un mote, tambi en conocido como nodo sensor, es un elemento que, como ya hemos descrito anteriormente, es un dispositivo capaz de observar y tomar medidas de un fen omeno. Es lo que se denomina en ingl es como sensing. El mote combina capacidades de recolecci on, procesado y transmisi on de datos en un mismo dispositivo, logrando todo esto con un reducido coste econ omico, tama no y consumo de potencia. Los sensores que lleva incorporado el nodo pueden ser de diferentes tipos: presi on, humedad, temperatura, movimiento, etc. dando lugar a las distintas aplicaciones posibles que comentamos en el apartado anterior.
Figura 16: Nodos sensores De esta forma, podemos establecer una serie de caracter sticas generales que se dan para los nodos sensores: 1. Integran sensores para realizar mediciones. Estos pueden ser de luz, temperatura, presi on, humedad, etc. 2. Est an limitados en diferentes aspectos: Energ a. Ya que suelen estar alimentados por medio de bater as y el bajo consumo es una de sus prioridades. Capacidad de c omputo y memoria. A un no disponen de grandes capacidades de procesador y de almacenamiento, aunque este campo est a desarroll andose y ampli andose cada d a. Memoria. La capacidad de alacenamiento tambi en 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 tecnolog a. Proyecto Final de Carrera 96
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 producci on muy bajos y ser desechables. 6. Son aut onomos 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 caracter sticas de los nodos sensores. Estos factores ser an: Energ a, exibilidad, robustez, seguridad, comunicaci on, computaci on, sincronizacion, tama no y coste. Un nodo sensor est a formado por cuatro componentes b asicos: 1. Unidad sensora. Sensores y conversores anal ogico-digitales que convierten las se nales anal ogicas en digitales para el microprocesador. 2. Procesador. Normalmente asociado a una peque na unidad de almacenamiento. Gestiona 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 tranmisi on y recepci on de mensajes. 4. Alimentaci on. Uno de los componentes m as importantes, se obtiene a partir de bater as aunque puede estar ayudado de un generador, como placas solares que obtienen energ a del entorno. Todo esto tiene que caber en un m odulo del tama no de una caja de cerillas y, a veces, en un tama no de un cent metro c ubico para poder suspenderlo en el aire.
Figura 17: Comparaci on plataformas para nodos Aunque cada vez hay procesadores m as peque nos y r apidos, las unidades de procesamiento y almacenamiento en los nodos son recursos escasos. Por ejemplo, Smart Dust mote Proyecto Final de Carrera 97
lleva un Atmel AVR8535 de 4MHz con memoria ash 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 c odigo. 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 modulaci on, ltro pasa banda, ltrado, demodulaci on y circuito multiplexor, lo que los hace complejos y caros. Adem as, las p erdidas en la transmisi on pueden llegar a ser mayores que la distancia a la cuarta, porque est an muy cerca del suelo. A un as , se preeren transceptores RF en la mayor a de proyectos de investigaci on porque los paquetes transportados son peque nos y las tasa de transferencia peque nas (generalmente menores a 1Hz), y la reutilizaci on de frecuencias es alta debido a las cortas distancias de comunicaci on. Por ello se puede usar electr onica de radio de bajo ciclo de trabajo. A un as , el dise no de una electr onica de comunicaciones energ eticamente eciente es todav a un reto. Por ejemplo, Bluetooth consume demasiada energ a s olo en encendidos y apagados. Como muchas veces son inaccesibles, la vida del sensor depende de la fuente de energ a, que adem as es escasa por las limitaciones en el tama no. En una Smart Dust mote se dispone de 1J de capacidad de bater a. En WINS (Wireless Integrated Network Sensors ) el consumo medio es de 30uA para proporcionar tiempos de vida largos. Se puede ampliar la vida con recolecci on de energ a, en muchos casos con c elulas solares. En algunas aplicaciones los nodos pueden llevar componentes adicionales: sistema de localizaci on (GPS), generador de energ a y movilizador. Muchas tareas requieren conocer la posici on porque los sensores se despliegan de manera aleatoria y se dejan desatendidos. Adem as se necesita en muchos protocolos. A menudo, se supone que los nodos tienen GPS con precisi on 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 dem as a determinar su posici on. Optimizaci on del consumo de energ a El consumo de energ a de los nodos sensores, como ya hemos comentado, es uno de las principales limitaciones que tienen estos dispositivos. Por ello, se han realizado ciertas estrategias hardware y software para conseguir un ahorro de energ a, de modo que el tiempo y la duraci on del mote en la red con suciente energ a sea el m aximo posible. Un nodo sensor tiene tres estados de funcionamiento: 1. Sleep. Estado en el que el mote est a durmiendo o inactivo. Se pretende que est e la mayor parte del tiempo posible en este estado y que su consumo sea el m nimo. 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 alg un cambio, est mulo o interrupci on programada dentro de sus funciones de detecci on y an alisis. Uno de los objetivos es que el tiempo de wakeup sea m nimo para pasar r apidamente al estado de trabajo. Proyecto Final de Carrera 98
IV Nodos sensores
3. Active. Es el estado activo del mote, donde est a realizando el trabajo de adquisici on, procesado y tranmisi on de datos. Por supuesto, este tiempo debe ser m nimo para volver cuanto antes al estado sleep, ya que el consumo ser a el mayor de los tres que se dan en cada fase.
Figura 18: Estados de un nodo sensor A continuaci on, podemos ver en una serie de tablas las cantidades de energ a que se consumen tanto para la recepci on como la transmisi on de mensajes. Se puede apreciar c omo adem as de las operaciones de radio, otras como la modulaci on o el manejador radio tambi en consumen su parte de energ a y utilizan parte el procesador. Por supuesto, la recepci on y tranmision radio hacen que los niveles de consumo de energ a puedan llegar hasta los 4uJ en el caso de la transmisi on, por lo que un factor importante para reducir estos consumos ser a reducir el tiempo de estado activo del mote, como sabemos.
Figura 19: Distribuci on del consumo de energ a
99
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 investigaci on en nuestro proyecto. Realizaremos un breve resumen de caracter sticas y aplicaciones posibles de ambos tipos, viendo ventajas de cada uno y la evoluci on que han sufrido con los nuevos avances. En los u ltimos a nos las WSN han evolucionado mucho, principalmente por la creaci on de estos nuevos motes. La Universidad de Berkeley se puede considerar la principal responsable de este avance, ya que fue all donde se desarroll o el primer mote. Varios a nos despues, junto con Intel Research Laboratory Berkeley, han dise nado nuevos motes, los MICA2 y los MICA2DOT, que son los m as usados para investigaci on 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 tambi en puede que lleve adquisici on de datos. En el caso de los Micas son placas que pueden ir por separado y unirlas mediante pines de conexi on, mientras que en el caso de los Telos, est a 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 caracter sticas de los Micaz, Mica2 y Mica2Dot. En la tabla de caracter sticas de la siguiente p agina podemos apreciar c omo ha evolucionado el tipo de procesador o, por otro lado, c omo 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. Proyecto Final de Carrera 100
V Ejemplos de motes: Micas y Telos
Figura 21: Micaz Usa, al igual que el Mica2, 51 pines de conexi on I/O y una memoria ash. Adem as, sus aplicaciones son compatibles. A continuaci on, vemos el diagrama de bloques.
Figura 22: Diagrama de bloques Micaz En esta tabla vemos una comparativa de las caracter sticas de los Micas:
Figura 23: Caracter sticas t ecnicas de Micas
101
Mica2 Los motes Mica2 son los m odulos de tercera generaci on de motes que se usan para redes de sensores inal ambricas de baja potencia. Mejoran bastante las caracter sticas del Mica original: Dise nado espec camente para redes de sensores integradas. Distintas frecuencias de transmisi on con amplio rango. M as de un a no de bater a mediante los modos sleep. Soportan reprogramaci on inal ambrica a distancia. Amplia variedad de placas de sensores compatibles: luz, temperatura, presi on, aceleraci on, ac ustica, detectores magn eticos, etc. Las distintas aplicaciones en las que se utilizan estos motes son, principalmente, las WSN, la seguridad y vigilancia, la monitorizaci on ambiental o las redes inal ambricas 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
102
Mica2Dot Los Mica2Dot son un tipo de motes dise nados especialmente para aplicaciones donde el tama no f sico es fundamental. Al igual que los Mica2 hay tres modelos dependiendo de su frecuencia: MPR500 (915MHz), MPR510 (433MHz), y MPR520 (315MHz). El resto de caracter sticas son similares a las de los Mica2, lo m as importante es la forma f sica y el reducido tama no que poseen, tal y como podemos ver en las im agenes.
Figura 26: Mica2dot Su correspondiente diagrama de bloques lo podemos ver a continuaci on, apreciando que los pines se han colocado de forma perif erica:
Figura 27: Diagrama de bloques Mica2dot
Sensores para Micas Las series de placas de sensores MTS o de aquisici on de datos MDA han sido dise nadas para la familia de los Micas. Hay una gran variedad de sensores que permiten un amplio margen de modalidades diferentes. La tabla de la siguiente p agina 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. Adem as llevan un micr ofono para detectar sonidos, y un resonador piezoel ectrico, lo que se denomina un buzzer, para producir un sonido a una frecuencia determinada. Proyecto Final de Carrera 103
Figura 28: Sensores MTS300 El modelo MTS310CA incluye tambi en aceler ometro y magnet ometro. Con este tipo de sensores la variedad de aplicaciones posibles aumenta, incluyendo detecci on de veh culos, detecci on de se smos de baja intensidad, movimiento, rangos ac usticos, rob otica, etc.
Figura 29: Tipos de sensores para Micas
104
V.2.
Telos
Los TelosB (TPR2400) son los motes que m as 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 re une todo lo esencial para estudios de laboratorio en una plataforma simple, incluyendo la capacidad de programaci on por USB, una antena integrada con sistema 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 caracter sticas generales de los TelosB son: Transmisi on 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. Programaci on y toma de datos v a USB. Proyecto Final de Carrera 105
Conjunto de sensores de luz, temperatura y humedad. Soporta TinyOS para implementaci on y comunicaci on de redes. Esta plataforma consigue un bajo consumo de potencia permitiendo una larga vida a las bater as adem as de tener un tiempo m nimo en el estado de wakeup, otro de los objetivos dentro de las estrategias de bajo consumo. Los TelosB se alimentan de dos bater as AA, aunque si es conectado mediante el puerto USB para programaci on o comunicaci on, la alimentaci on la proporciona el ordenador. Tambi en se proporciona la capacidad de a nadir dispositivos adicionales. Los dos conectores de expansi on de los que dispone pueden ser congurados para controlar sensores anal ogicos, perif ericos digitales y displays LCD. Con todas estas caracter sticas, el mote TelosB no s olo proporciona m as facilidad para programaci on, m as exibilidad y m as prestaciones, sino que es el que menos consumo de potencia ofrece, muy por debajo de los que hab a hasta ahora, permitiendo alargar la vida de los nodos considerablemente y siendo esta su principal baza frente a los otros dispositivos.
106
V.3.
Resumen comparativo
Las diferentes plataformas de motes que hemos visto se diferencian en sus caracter sticas hardware lo que les proporciona distintas cualidades a unas de otras: mayor procesador, frecuencias de transmisi on, velocidad de transmisi on de datos, consumo de energ a, etc. En la siguiente tabla podemos ver la evoluci on que han sufrido los distintos prototipos y, lo que es m as importante para nosotros, la comparaci on con las prestaciones que tienen y ofrecen los TelosB.
Figura 32: Evoluci on de los motes Como ya hemos comentado anteriormente, se puede apreciar que los consumos de potencia del procesador son muy inferiores en comparaci on con los otros motes, la velocidad de transferencia es bastante superior y facilidades como la conexi on USB para la programaci on o el llevar la antena integrada, hacen de este prototipo uno de los mejores. En la gura siguiente, observamos m as concretamente los tiempos de cambio de estado, as como la potencia consumida en cada estado, obteniendo siempre los m nimos resultados para los Telos, y consiguiendo un mayor tiempo de vida del nodo.
Figura 33: Comparativa de tiempos y consumos
107
Conclusiones Los Telos son los motes con el menor consumo de potencia hasta la fecha. Incluyen numerosas mejoras que permiten investigar en las WSN mientras que los dispositivos van siendo m as f aciles de usar y m as baratos en lo que al coste se reere. Otras caracter sticas, como la protecci on hardware contra escritura y la estabilidad de la se nal radio, concretan a un m as las actuales investigaciones. Los investigadores pueden experimentar con el nuevo est andar IEEE 802.15.4 y usar trabajos existentes con TinyOS. Una exibilidad adicional permite que el software pueda congurar o deshabilitar m odulos hardware. Los TelosB son m odulos robustos con unas grandes prestaciones de bajo consumo de potencia que no exist an en dise nos anteriores, ajust andose de forma eciente a los objetivos de este proyecto.
108
VI TinyOS
VI.
TinyOS
Las redes de sensores inal ambricas est an basadas en nodos de peque no tama no que tienen ciertas limitaciones tanto de memoria como de procesador. Adem as, sufren tambi en el importante 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 programaci on de los motes, es el TinyOS. TinyOS (Tiny Micro-Threading Operating System ) se trata de un peque no sistema operativo 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 programaci on, nesC, es un extensi on de C que permite la denici on de componentes y la interconexi on de ellos. No tiene gesti on de procesos, en su lugar tiene dos hilos de ejecuci on, uno destinado a la ejecuci on de eventos y otro a la de tareas, entre los cuales el cambio de contexto es muy r apido. Es muy ligero y puede ser ejecutado en dispositivos con prestaciones limitadas pues, tanto el espacio que ocupa en memoria ash, como la RAM que consume, son muy peque nos. Por tanto, es ideal para el tipo de dispositivos como los motes. La creaci on de nuevos componentes hardware, tanto motes como placas de sensores, es posible. Basta con crear un chero de cabecera en el que se describa el conexionado del hardware y la creaci on de componentes software que, a trav es de llamadas a las librer as C del microcontrolador o a trav es de macros, realicen la comunicaci on con el hardware. La gesti on de potencia corre a cargo de TinyOS, que se encarga de desactivar los recursos hardware que no est an siendo usados. Permite un modo de bajo consumo de potencia mientras no se est an transmitiendo o recibiendo datos as como tambi en establecer periodos en los que, c clicamente, la radio se apaga. Se crean los estados de actividad o de latencia que coment abamos 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 comunicaci on broadcast a todos los nodos como encaminamiento multi-salto. En este segundo caso la aplicaci on 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 dene el sistema operativo para que las aplicaciones puedan f acilmente cambiar el algoritmo que usan por otro. Existen otras caracter sticas dignas de mencionar sobre TinyOS, como son la reprogramaci on en red de todo el c odigo de un mote, o el uso de componentes para cifrado de datos (TinySec). Estas caracter sticas y el hecho de que estuviera disponible bastante antes que otros sistemas operativos, desde principios de 2003, han hecho que sea el sistema operativo m as extendido para redes de sensores. Sin embargo, TinyOS tiene algunos inconvenientes. Puesto que s olo hay un hilo de ejecuci on para tareas y el planicador de estas es una cola FIFO, no se tienen garant as de tiempo real. Este hilo de ejecuci on para tareas no ofrece gesti on 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 programaci on que ofrece puede resultar muy complicado para programadores novatos, que deben tratar con cuestiones de programaci on as ncrona y temporizaci on. Proyecto Final de Carrera 109
Adem as hay algunas caracter sticas de las que este sistema operativo no dispone, como mecanismos ables de sincronizaci on de datos entre nodos o protecci on de memoria, si bien el carecer de esta u ltima le hace requerir menos recursos para su ejecuci on. Tampoco proporciona conectividad con grandes infraestructuras de servicios como Internet. 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 reprogramaci on en red s es posible, pero, como se coment o anteriormente, se debe reprogramar todo el c odigo 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 investigaci on y compa n as est an usando TinyOS en los motes de Berkeley/Crossbow. Numerosos grupos contribuyen activamente con el c odigo en su sitio web sourceforge y trabajan juntos para establecer servicios de red est andar, formados desde una base de experiencia directa y perfeccionados a trav es de an alisis competitivos en un entorno abierto. Proyectos TinyOS Presentamos una serie de ejemplos de proyectos con TinyOS que se est an realizando actualmente en la Universidad de Berkeley: Calamari: Soluciones de localizaci on para redes de sensores. FPS: Un protocolo de red para programaci on 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 sat elite, lo que permite a los investigadores descargar los datos del entorno en tiempo real a trav es de Internet. Mat e: M aquinas virtuales de aplicaci on espec ca para redes TOS. Permiten la programaci on de motes mediante simples scripts. PicoRadio: Redes inal ambricas de muy bajo consumo. SSIS: Sensores de detecci on de integridad estructural. Informan de la localizaci on y da nos durante y despu es de un terremoto. TinyDB: Sistema de procesamiento de peticiones para la extracci on de informaci on de una red de sensores TinyOS. XYZ On A Chip: Redes de sensores inal ambricas integradas para el control de entornos interiores en edicios.
110
VI TinyOS
VI.1.
nesC
nesC es una extensi on del lenguaje de programaci on C dise nado para plasmar los conceptos de estructuraci on y los modelos de ejecuci on de TinyOS. Los conceptos b asicos que hay tras nesC son: Separaci on de construcci on y composici on: los programas se hacen mediante componentes 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 trav es de sus interfaces. Estos hilos pueden ser de ejecuci on de tareas o interrupciones hardware. Las especicaciones 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 componente necesita para hacer su trabajo. Las interfaces son bidireccionales: especican un conjunto de funciones para ser implementadas por el proveedor de la interfaz (los m etodos) y un conjunto para ser implementados por el usuario de la interfaz (los eventos). Esto permite que una interfaz simple represente una interacci on compleja entre componentes (por ejemplo, registrar algo de inter es de un evento, seguido por una llamada cuando el evento ocurre). Esto es importante porque todos los m etodos largos en TinyOS (por ejemplo, enviar paquetes ) son de no-bloqueo; se indica que se han completado a trav es de un evento (env o realizado ). Mediante las especicaciones de las interfaces, un componente no puede llamar al m etodo enviar hasta que proporcione una implementaci on del evento env o realizado. Los componentes est an conectados est aticamente a otros por medio de las interfaces. Esto incrementa la eciencia del tiempo de ejecuci on, fomentando el dise no robusto y permitiendo un mejor an alisis est atico de los programas. nesC est a dise nado bajo la expectaci on de que el c odigo ser a generado por compiladores de programas-completos. Esto deber a tambi en permitir una mejor generaci on de c odigo y an alisis.
Figura 34: Estructura de un componente
111
Estructura de un componente Una aplicaci on nesC consiste en uno o m as componentes unidos para formar un ejecutable. Un componente proporciona y usa interfaces. Estas interfaces son el punto de acceso al componente y son bidireccionales. Una interfaz declara un conjunto de funciones (m etodos) que la proveedora debe implementar y otro conjunto de funciones (eventos) que la usuaria debe implementar. Para llamar a los m etodos de una interfaz, se deben implementar los eventos de esa interfaz. Un componente simple puede usar o proporcionar m ultiples interfaces y m ultiples instancias de la misma interfaz. Hay dos tipos de componentes en nesC: los m odulos y las conguraciones. Los m odulos proporcionan el c odigo de la aplicaci on, implementando una o m as interfaces. Las conguraciones 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 aplicaci on nesC se describe por una conguraci on de alto nivel que conecta todos los componentes que contiene. Los cheros que van a componer una aplicaci on ser an: miaplicacion.nc Ser a el chero conguraci on del componente. En su c odigo contendr a dos apartados: Conguraci on. En general vac a, s olo contendr a algo si se pretende crear un componente no mediante su implementaci on de c odigo directa (en Module) sino ensamblando otros componentes ya creados. Implementaci on. Aqu es donde se denen las conexiones que hay entre los diferentes componentes que utilizan la aplicaci on. miaplicacionM.nc Ser a el m odulo del componente. En el se denen las interfaces que se proporcionan y que se usan y, por supuesto, contiene la implementaci on de la aplicaci on en s . Puede haber m as cheros para una misma aplicaci on, si se incluyen librer as en las que se denen diferentes estructuras necesarias para la aplicaci on, como en el ejemplo:
Figura 35: Ficheros de una aplicaci on
112
VI TinyOS
VI.2.
Herramientas de TinyOS
Las herramientas que a continuaci on se describen ayudan en la tarea del desarrollo de una aplicaci on pero no forman parte de la aplicaci on que nalmente se encargar a de recoger informaci on en los nodos. Estas herramientas pertenecen al entorno de desarrollo de TinyOS. Otros entornos de desarrollo tienen sus propias herramientas de simulaci on y visualizaci on 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 especicada. Gracias a esto se pueden introducir sentencias en el c odigo generado que informen del estado de la simulaci on. Por ejemplo, se puede saber cu ando la simulaci on transmite un paquete, enciende un led, provoca una interrupci on del reloj, etc. Permite una simulaci on bastante completa de una red. Entre sus posibilidades se encuentra la simulaci on de las transmisiones de datos a nivel de bit jando una probabilidad de error de bit. Tambi en 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 gr aca de TOSSIM. Permite ver la topolog a de la red aunque la calidad de la imagen que ofrece no es buena. Soporta la adici on 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 aplicaci on Java que viene incluida con TinyOS. Permite monitorizar una red y analizar el funcionamiento del mallado de la red. Sus caracter sticas incluyen: Descubrimiento y conguraci on autom atica de la red. Visionado de la topolog a de red. Proyecto Final de Carrera 113
Almacenamiento y visualizaci on de estad sticas de la red como rendimiento, calidad de los enlaces, etc. Herramienta gr aca para el visionado de datos.
Figura 37: Surge View
SerialForwarder Esta aplicaci on java permite recibir paquetes por el puerto serie del PC y reenviarlos a trav es de otros puertos del PC. De esta forma otros programas, como por ejemplo Surge View, pueden comunicarse con la red de sensores a trav es de un nodo conectado al PC que hace de pasarela. NesDoc Esta utilidad permite generar documentaci on autom aticamente a partir del c odigo fuente de un programa. Por cada chero fuente genera un chero HTML con un gr aco que describe el conexionado de los componentes del chero a trav es de sus interfaces y una descripci on textual sacada de los comentarios de los cheros fuente. Por esto, para aprovechar todas las caracter sticas de NesDoc es necesario seguir una serie de reglas al comentar los cheros fuente. GRATIS II / GME GRATIIS II (Graphical Development Environment for TinyOS ) es un entorno que ofrece una representaci on gr aca de los componentes implicados en una aplicaci on tinyOS. Ofrece un traductor que permite transformar entre los modelos gr acos que usa y los cheros de conguraci on 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 informaci on 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 extensi on del lenguaje de consultas SQL. Las extensiones realizadas a SQL permiten que al pedir una lectura se puedan especicar Proyecto Final de Carrera 114
VI TinyOS
la frecuencia de muestreo y el periodo de tiempo durante el que se tomar an muestras entre otros par ametros. Incluso es posible que TinyDB ajuste estos par ametros para conseguir un determinado tiempo de vida de los nodos. Estas consultas, que son realizadas por una aplicaci on ejecutada sobre un PC, provocan en los nodos la lectura de datos. Cada vez que un dato consultado sea le do, este se introducir a en un mensaje y se reenviar a por la red de vuelta al PC que solicit o el dato. Para ahorrar energ a, el n umero de mensajes retransmitidos se reduce organizando los nodos en una estructura en arbol en la que cada nodo s olo se comunicar a con su nodo padre y sus nodos hijo. TinyDB est a implementado como un framework extensible. A trav es de esta extensibilidad se pretende que, en un futuro, se a nadan nuevos eventos y atributos de los nodos y se pueda invocar comandos para la realizaci on de tareas de control y actuaci on.
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 Mat e. 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 l neas de c odigo. El c odigo en Bombilla se divide en c apsulas de 24 bytes. Una de estas c apsulas se encarga de la recepci on de mensajes, otra de la transmisi on de mensajes y otra de los eventos del reloj que permiten disparar la adquisici on de datos. Si es necesario el uso de algoritmos puede haber otras cuatro c apsulas adicionales que los contengan. Las instrucciones de Mat e hacen que la programaci on ya no sea as ncrona, ahora se sabe qu e momento van a llegar datos de los sensores, lo cual facilita la tarea de programar la aplicaci on. 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. Mat e es adecuado para aplicaciones simples que necesitan ser reprogramadas a menudo. Para la reprogramaci on basta introducir las nuevas c apsulas en la red y los propios nodos las adoptar an si contienen una versi on m as moderna que la que est an ejecutando. Sin embargo, Mat e no permite realizar operaciones matem aticas que sean m as complejas que una resta, ni tampoco puede ejecutar programas extensos. Proyecto Final de Carrera 115
VII.
Futuro de las WSN
Las caracter sticas de exibilidad, movilidad, alta delidad en sensorizaci on, bajo coste y r apido despliegue de las WSN crean muchas nuevas areas de aplicaci on interesantes para la sensorizaci on remota. En el futuro, este amplio rango de areas de aplicaci on har a de las redes de sensores una parte integral de nuestras vidas. Sin embargo, la realizaci on de las redes de sensores debe satisfacer las restricciones introducidas por factores como la tolerancia a fallos, escalabilidad, coste, hardware, cambios en la topolog a, entorno y consumo energ etico. Puesto que estas restricciones son muy exigentes y espec cas de las redes de sensores, se requieren nuevas t ecnicas para este tipo de redes. En la actualidad hay muchos investigadores involucrados en el desarrollo de tecnolog as necesarias para las diferentes capas de la pila de protocolo de las redes de sensores. Adem as de estos proyectos, se requiere m as trabajo en los problemas descritos y m as desarrollos para solucionar los temas de investigaci on abiertos que hemos estado viendo en este cap tulo. Debemos tener en cuenta que estamos tratando con una tecnolog a bastante reciente en la que hay muchos dise nos pero pocos funcionan, no existe lo que se llama una killer application que cree una nueva forma de mercado (como fue la tecnolog a m ovil) y que el 99 % de las redes son cableadas. Si resumi eramos los factores que est an actualmente impidendo el desarrollo deber amos resaltar: No existen tendencias claras de SO o plataformas harware. Falta de est andares o protocolos comunes. Limitaci on de recursos: energ a, 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 f sico, como de computaci on: sistemas operativos, algoritmos distribuidos, etc. como de comunicaci on: protocolos de enrutamiento, mantenimiento de la topolog a, descubrimiento de vecinos, etc. Cada vez van saliendo nuevas soluciones que permiten mejorar cada uno de estos apartados. Por ejemplo, una posible soluci on distribuida ser a la creaci on de Middleware, que establezca una interoperabilidad entre los sistemas operativos y una aplicaci on, de tal forma que proporcione interfaces de alto nivel para enmascarar la complejidad de las redes y protocolos o que permita a los desarrolladores centrarse en cuestiones espec cas de la aplicaci on. En un futuro no muy lejano veremos c omo las redes de sensores empezar an a verse en todo tipo de aplicaciones como las que hemos visto en este cap tulo y en muchas m as que ir an surgiendo. Problemas como las limitaciones de memoria o procesador ir an desapareciendo con las nuevas nanotecnolog as y MEMs, lo que permitir a bajar mucho m as el consumo de potencia, alargar la vida de los nodos y quiz a cambiar la perspectiva de estas redes hacia nuevos campos de actuaci on.
116
VII Futuro de las WSN
En la pel cula de Hollywood Twister, los meteor ologos persiguen tornados para acoplarles una barril con sensores en su camino que pudieran meterse en el coraz on del tornado. Los cient cos pod an medir as el tornado desde dentro con la informaci on que enviaban los sensores. El laboratorio nacional de tormentas graves (NSSL) inform o de que la pel cula estaba basada en un trabajo del Dr. Al Bedard que desarroll o un instrumento para observar tornados. Era un barril dotado de sensores en su exterior para medir viento, presi on y temperatura, y llevaba unas bater as incorporadas. Lo que no ten a muy en cuenta eran los inconvenientes de seguridad como los objetos que pod an chocar contra el barril.
Figura 39: Twister Aunque la pel cula Twister exageraba la realidad en su momento, ahora ya no es imposible pensar en la utilizaci on 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 transmitirlos a una red donde los usuarios podr an evaluar y analizar los datos. La robustez y el coste de la red de sensores superar a la alta probabilidad de fallo en los nodos para asegurar el exito del proyecto y, adem as, conseguir una informaci on relevante desde el coraz on del tornado, para el bien de los meteor ologos. Otra aplicaci on que podr amos considerar futurista es la que se expone en este v deo.
Figura 40: T unel WSN En el se muestra un escenario de un t unel con bastante tr aco en el que ocurre un accidente y provoca un incendio en su interior. El t unel est a dotado de sensores que transmiten Proyecto Final de Carrera 117
informaci on de todo tipo a las centrales de control de la ciudad: niveles de temperatura, da nos, n umero de coches y sus caracter sticas, 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 comunicaci on y el tiempo de respuesta, evidentemente, es inmediato. El tr aco es desviado hacia otras carreteras y los sistemas de emergencia del t unel hacen su parte hasta que llegan los refuerzos humanos. Los veh culos de emergencia tambi en disponen de sistemas de control con informaci on actualizada de la situaci on en el interior del t unel, e introducen robots de detecci on y rastreo de los distintos niveles de peligro que pudiera haber. Finalmente, los propios bomberos son una PAN (Personal Area Network ) m ovil, y van provistos de varios sensores que indican sus caracter sticas internas y externas, as como su posici on. Los cascos van provistos de c amara y pantallas que informan de cada uno de los par ametros clave para tomar las mejores decisiones. En EEUU est an ya experimentando en un proyecto para bomberos llamado Wireless FireFighter System en el que est an dise nando este tipo de cascos, as que parece que no estamos ante una realidad tan futurista.
118
Parte III
Proyecto de integraci on de WSN y dom otica
119

I. Introducci on
Este proyecto de integraci on de redes de sensores en el ambito de la dom otica consiste, b asicamente, en la programaci on de nodos sensores que formar an redes inal ambricas dedicadas a funciones y aplicaciones dom oticas, como pueden ser el control de iluminaci on, persianas, sistemas de calefacci on, etc. Tal y como se describe en un sistema dom otico, ciertos nodos ser an los sensores, que interact uan con el medio, recibiendo est mulos, tomando datos o midiendo distintos par ametros, dependiendo de para qu e hayan sido programados. Por otra parte, otros nodos ser an congurados como actuadores. Los actuadores recibir an la informaci on de los sensores cuando se produzca un cambio, un evento o cualquier cosa que queramos indicar y estos, en funci on de la informaci on recibida, actuar an de una forma u otra, tomando decisiones, activando aparatos, reenviando la informaci on a otros nodos o incluso a una unidad central de control. En denitiva, esto es lo que se conoce como Redes de Sensores y Actuadores Inal ambricas WSAN (Wireless sensor and actor networks ), redes que, tal y como ocurre en una tecnolog a dom otica, se basan en un grupo de sensores que env an eventos a unos actuadores para que realicen cierto tipo de funciones. Se espera que la introducci on de este novedoso tipo de redes sea la revoluci on en el sector de la dom otica inal ambrica. Iniciativas del est andar IEEE 802.15.4 para WSAN denen la automatizaci on de viviendas como uno de sus principales ambitos de aplicaci on. Por estas razones, adem as de la importancia y relevancia para el futuro que ya poseen las redes inal ambricas de sensores, consideramos muy interesante y con mucho trabajo por hacer el campo de la utilizaci on de tecnolog as de WSN para el dise no de una red de automatizaci on de viviendas y edicios. Estos estudios permitir an la introducci on de la dom otica en viviendas ya construidas o la ampliaci on de instalaciones existentes, proporcionar an las prestaciones de confort, seguridad, ahorro energ etico e interoperabilidad con otras redes, y habilitar an un escenario para la creaci on del ambiente inteligente y la computaci on ubicua. En primer luegar veremos algunas caracter sticas de este tipo de redes que se ajustan elmente a nuestros objetivos.
121
I.1.
WSAN
Las WSAN consisten en un grupo de actuadores y sensores conectados inal ambricamente para realizar medidas de sensores de forma distribuida y tareas de actuadores. La arquitectura f sica de una WSAN es la siguiente:
Figura 1: Arquitectura WSAN En una red de este tipo, los sensores van reuniendo informaci on sobre el medio f sico 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, capacidad de procesamiento y comunicaci on inal ambrica limitados, y el hecho de actuar sobre un fen omeno es m as complicado y consume m as energ a que medir un fen omeno, los actuadores deber an ser nodos de recursos m as caros, con mejor capacidad de proceso, una potencia de transmisi on mayor y unas bater as con mayor tiempo de vida. En las WSAN, dependiendo del tipo de aplicaci on puede que se necesite un tiempo de respuesta r apido ante un evento. Adem as, para ejectuar las acciones correctas, los datos medidos deben ser v alidos en el momento de la ejecuci on. Por lo tanto, la comunicaci on en tiempo real es una cuesti on muy importante en las WSAN. El n umero de nodos sensores dedicado al estudio de un fen omeno puede llegar al orden de cientos de miles. Sin embargo, no es necesaria tal cantidad para nodos actuadores. Para conseguir un trabajo de detecci on y actuaci on efectivo, es necesario un mecanismo local de coordinaci on entre sensores y actuadores. En el caso que nos ata ne, el mundo de la dom otica y automatizaci on de edicios tiene unas caracter sticas concretas que le diferencian de otro tipo de mercados. No ser a lo mismo unos sensores que detecten movimientos s smicos y tengan que advertir posibles terremotos en tiempo real, que unos sensores de una ocina que controlen la temperatura para activar el sistema de aire acondicionado. Por tanto, estas caracter sticas de las redes WSAN se ajustan a las redes que controlar an 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 env o en tiempo real no ser an problema para el control de iluminaci on o persianas, pero s con aplicaciones de seguridad y vigilancia que estar an basadas en esos factores y de los cuales depender a que el sistema sea able y efectivo. Proyecto Final de Carrera 122
I Introducci on
I.2.
Ventajas de la dom otica inal ambrica
Las redes de sensores inal ambricas proporcionan soluciones con baja tasa de transmisi on de datos, bajo consumo, seguridad y abilidad que, como ya hemos comentado, son ideales para los mercados de la automatizaci on de viviendas, edicios e industrial. Veamos algunas ventajas que podremos experimentar para cada uno de estos mercados. Control En el caso de la automatizaci on de viviendas se conseguir an ventajas como una administraci on exible de luz, calefacci on y sistemas de aire acondicionado desde cualquier parte de la vivienda. En un edicio, por ejemplo de ocinas, tendremos una gesti on centralizada e integrada de iluminaci on, calefacci on, AC y seguridad, as como para aplicaciones industriales se podr a ampliar la abilidad de los procesos de control e industriales y mejorar las ventajas de administraci on mediante una monitorizaci on cont nua de equipos importantes. En todos los ambitos podremos tener un control autom atico de m ultiples sistemas que mejoran aspectos como el consumo, la exibilidad, el confort y la seguridad. Consumo En el caso de viviendas con este tipo de redes podremos obtener una captura detallada de datos u tiles de utilizaci on de electricidad, agua y gas, adem as de una inteligencia integrada para optimizar el consumo de recursos naturales. En edicios o sistemas industriales la reducci on de los gastos de energ a vendr a mediante un control optimizado de los sistemas HVAC y con medidas como destinar equitativamente los costes u tiles bas andose en el consumo actual. Tambi en se podr an identicar operaciones inecientes o equipos de bajo rendimiento.
Figura 2: Casa dom otica
Seguridad En una vivienda individual podremos destacar una f acil instalaci on de sensores inal ambricos que monitoricen una amplia variedad de condiciones y se reciban noticaciones autom aticas cuando detecten eventos inusuales dentro del marco de la seguridad. Por otro lado, para edicios habr a redes y datos integrados desde m ultiples puntos de control de acceso as como el desarrollo de redes de monitorizaci on inal ambricas para aumentar la protecci on perimetral. Proyecto Final de Carrera 123
En una f abrica se podr an desarrollar redes de monitorizaci on para aumentar la seguridad p ublica y de los empleados, as como hacer m as eciente la recolecci on de datos para mejorar los informes de resultados. Confort Todas las instalaciones, actualizaciones y sistemas de control de la redes dom oticas son sin cables, tambi en pudiendo congurar y ejecutar m ultiples sistemas a distancia de forma remota. Flexibilidad En el caso de automatizaci on de edicios se podr a efectuar una reconguraci on r apida de sistemas de iluminaci on para crear espacios de trabajo adaptables, adem as de ampliar y actualizar las infraestructuras del edicio con el m nimo esfuerzo. Eciencia Esta ventaja puede verse claramente en sistemas industriales donde se podr a realiar una adquisici on autom atica de datos mediante sensores remotos para reducir la intervenci on humana y proporcionar datos detallados para mejorar los programas de mantenimiento preventivos.
124
I Introducci on
I.3.
Soluciones existentes
Para acabar este cap tulo introductorio, presentaremos un par de soluciones existentes en el campo de la dom otica mediante redes inal ambricas de sensores, llevadas a cabo por la Zigbee Alliance. Control4 Control4, un l der creciente en los sistemas asequibles y de f acil uso para el control dom otico y el entretenimiento, reconoci o que el mejor y m as asequible de los est andares inal ambricos, combinado con la tecnolog a IP, permitir a la automatizaci on 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 construcci on. Control4 crea los primeros productos de control en viviendas basados en el est andar Zigbee, que proporciona la red inal ambrica para la comunicaci on entre los dispositivos de la casa.
Figura 3: Control4
Soluciones TAC TAC es una compa n a l der en automatizaci on de edicios, sistemas de seguridad y soluciones de energ a. La misi on de TAC es proporcionar un valor a nadido mediante servicios de entorno de viviendas como la climatizaci on interior, la seguridad y el uso de la energ a, desarrollados con tecnolog as avanzadas para poder llegar a todos los usuarios y propietarios del mundo. Las soluciones inal ambricas TAC est an basadas en una familia de controladores que se instalan en todo el mundo y que proporcionan una administraci on del sistema con herramientas gr acas en tiempo real para controlar la red inal ambrica.
125
II.
Escenario del proyecto
El prop osito nal de este proyecto es dise nar una red de sensores y actuadores inal ambrica para su aplicaci on en automatizaci on y control de viviendas y edicios que satisfaga los requerimientos propios de las instalaciones dom oticas y facilite la introducci on de t ecnicas para la creaci on de ambientes inteligentes a trav es de las prestaciones que ofrecen este tipo de redes. Una WSAN va a funcionar en escenarios que dependen de la aplicaci on, pero cuyas caracter sticas b asicas ser an comunes. Por ello, vamos a establecer el escenario de aplicaci on sobre el que se desarrollar a nuestro proyecto, que se podr a ampliar o modicar en un futuro, si nuestros resultados se ajustan adecuadamente. El escenario de nuestro proyecto podr a ser el siguiente: Vivienda unifamiliar de tama no medio con sistemas de calefacci on, aire acondicionado, iluminaci on 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 mayor a de las existentes, sin ning un sistema tecnol ogico complejo.
Figura 4: Vivienda escenario Los nodos de la red ser an instalados en la vivienda con una expectativa de funcionamiento a muy largo plazo, como cualquier interruptor habitual de nuestra casa. Los nodos dispondr an de elementos sensores y actuadores, y los datos se enviar an por dos posibles causas: Dirigidos por eventos externos al nodo. Por ejemplo, la pulsaci on de un interruptor para dar una orden de encendido. De manera peri odica para la realizaci on de acciones de control. Por ejemplo, la regulaci on de temperatura en el sistema de climatizaci on. Por tanto, distinguiremos por un lado los nodos sensores, que detectar an los cambios que se produzcan en la magnitud que est en midiendo o los eventos ante los que tengan que efectuar una respuesta. Normalmente, esta respuesta ser a el env o de un mensaje concreto al nodo actuador. Proyecto Final de Carrera 126
II Escenario del proyecto
Por otro lado estar an los nodos actuadores, que ser an los que reciban la informaci on conveniente de los sensores y ejectuar a la acci on en consecuencia, ya sea encender o apagar luces, activar o desactivar un motor de persiana o la calefacci on. Hemos enfocado el proyecto en tres campos dom oticos distintos, en cada uno de los cuales la programaci on de los sensores y actuadores depende la aplicaci on que se quiera realizar: 1. Iluminaci on. Dentro de este apartado incluimos la interacci on de sensores y actuadores para realizar distintas funciones de iluminaci on: conmutaci on On/O de grupos de luces, regulaci on relativa o regulaci on absoluta. 2. Persianas. Aqu las aplicaciones ser an 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 traducir a en los giros de lamas en un sentido u otro. 3. Sensores crepusculares y de temperatura. En este u ltimo apartado incluimos las aplicaciones que incorporan sensores de tipo crepuscular para la activaci on o regulaci on de luces o motores, dependiendo de la iluminaci on solar o, por otra parte, sensores de temperatura que controlar an los sistemas de calefacci on 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 tecnolog a dom otica adaptada para la programaci on de los mismos. Sistema dom otico: Dada su importancia actual y la expansi on que est a teniendo en Europa, elegimos el sistema EIB-KNX. En la primera parte de este proyecto vimos las caracter sticas, ventajas y desventajas de este sistema, as como las t ecnicas de env o de mensajes por medio de datagramas. Utilizaremos los mismos m etodos y campos para la programaci on de nuestros sensores, de manera que sigan este mismo sistema y sean lo m as compatibles posible, con la gran diferencia de que ya no ser a un sistema cableado, sino inal ambrico. Nodos sensores: Despu es de todo lo expuesto en la segunda parte del proyecto, llegamos a la conclusi on de que los motes TelosB eran los que proporcionaban las mejores caracter sticas en cuanto a bajo consumo, haci endolos superiores al resto. Adem as de algunas pruebas que realizamos con Micas, los TelosB han sido los utilizados para las aplicaciones dom oticas.
127
III.
Programaci on de las aplicaciones dom oticas
En este cap tulo expondremos c omo se ha realizado la programaci on de los distintos nodos para que realicen las funciones dom oticas descritas y que, m as adelante, veremos en profundidad. Es obvio que para programar los sensores de los que disponemos, como son los TelosB, deberemos conocer c omo trabaja el sistema TinyOS, y dominar el lenguaje nesC para la programaci on. Ya vimos un resumen de ambas cosas en apartados anteriores. No obstante, realizaremos un estudio de una de las aplicaciones b asicas, para comprender un poco mejor el modo de programaci on. Tambi en realizaremos un breve resumen de otras aplicaciones ya existentes y que han sido de gran utilidad para la realizaci on de c odigos en este proyecto. Adem as, adjuntamos los c odigos completos de las aplicaciones desarrolladas en los ap endices de este proyecto. De esta forma se pretende que, junto con las explicaciones de las partes m as importantes del c odigo, se comprenda perfectamente c omo recibe cada nodo la informaci on, c omo la procesa y qu e hace en consecuencia. Tras estos preliminares, realizaremos un an alisis de las aplicaciones dom oticas programadas, dividi endolas en los tres apartados que comentamos anteriormente: Iluminaci on, persianas y aplicaciones de sensores crepusculares o de temperatura. Aplicaci on Blink La aplicaci on Blink es la t pica que se utiliza para mostrar c omo se implementa un programa en nesC, sus componentes y las conexiones entre las distintas interfaces. Consiste en una aplicaci on que hace parpadear un led del mote a cada interrupci on de reloj y dicha interrupci on est a programada para cada sengundo. La aplicaci on est a compuesta por dos componentes: un m odulo, llamado BlinkM.nc y una conguraci on llamada Blink.nc. Debe recordarse que todas las aplicaciones requieren de un archivo de conguraci on de alto-nivel que suele llamarse como la aplicaci on en s . En este caso Blink.nc es la conguraci on para la aplicaci on Blink y es el archivo fuente que el comilador de nesC utiliza para generar el chero ejecutable. Por otra parte, BlinkM.nc realmente proporciona la implementaci on de la aplicaci on Blink. El archivo de conguraci on dir a a qu e componentes habr a que conectar nuestro m odulo, aquellos que requiera la aplicaci on.
1 2 3 4 5 6 7 8 9
configuration Blink { } implementation { components Main , BlinkM , SingleTimer , LedsC ; Main . StdControl -> SingleTimer . StdControl ; Main . StdControl -> BlinkM . StdControl ; BlinkM . Timer -> SingleTimer . Timer ; BlinkM . Leds -> LedsC ; } C odigo 2.1: Blink.nc El archivo Blink.nc contiene la conguraci on (que no es necesaria para esta sencilla aplicaci on) y la implementaci on, donde se denen las conexiones que hay entre los diferentes componentes que utilizan la aplicaci on. Proyecto Final de Carrera 128
III Programaci on de las aplicaciones dom oticas
La l nea n umero 4 especica el conjunto de componentes que esta conguraci on referencia, en este caso Main, BlinkM, SingleTimer, and LedsC. El resto de la implementaci on consiste en la conexi on de interfaces usadas por los componentes a las interfaces proporcionadas por otros. Main es el componente que se ejecuta primero en una aplicaci oin TinyOS. Siendo precisos Main.StdControl.init() es el primer comando que se ejecuta en TinyOS seguido de Main.StdControl.start(). De esta forma, un aplicaci on TinyOS debe tener siempre un componente Main en su conguraci on. StdControl es la interfaz que se usa para inicializar y arrancar los componentes TinyOS.
1 2 3 4 5
interface command command command }
StdControl { result_t init () ; result_t start () ; result_t stop () ; C odigo 2.2: Interfaz StdControl.nc
Vemos que StdControl dene tres m etodos: init(),start(), y stop(). init() es llamado 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 est a controlando. Estos tres m etodos tienen una sem antica profunda: llamar al m etodo 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() ser an llamadas por Main.StdControl.init(). Y lo mismo pasar a con los m etodos start() y stop(). Con respecto a las interfaces utilizadas, es importante advertir que las funciones de inicializaci on de un subcomponente deben ser expl citamente llamadas por el componente que las use. Por ejemplo, el m odulo BlinkM usa la interfaz Leds, as que Leds.init() es llamado expl citamente por BlinkM.init(). nesC utiliza echas para determinar la relaci on entre interfaces. Para entenderlo, se puede pensar que la echa hacia la derecha signica se vincula a. La parte de la izquierda de la echa vincula una interfaz a una implementaci on de la parte derecha. En otras palabras, el componente que usa la interfaz est a en la izquierda y el componente que proporciona esa interfaz est a 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 m ultiples 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 identicador de timer como par ametro. Proyecto Final de Carrera 129
Los v nculos pueden ser tambi en impl citos. Por ejemplo: BlinkM.Leds ->LedsC; Es en realidad una abreviatura de: BlinkM.Leds ->LedsC.Leds; Si no se pone ning un nombre de interfaz en la parte derecha de la echa, el compilador nesC intenta, por defecto, vincularlo a la misma interfaz que hay en la parte izquierda. Veamos el chero del m odulo.
1 2 3 4 5 6 7
module BlinkM { provides { interface StdControl ;} uses { interface Timer ; interface Leds ; } } C odigo 2.3: BlinkM.nc La primera parte del c odigo declara el nombre del m odulo y las interfaces que proporciona y que usa. El m odulo BlinkM proporciona la interfaz StdControl. Esto signica que la va a implementar en su c odigo. Adem as, BlinkM usa tambi en dos interfaces: Leds y Timer. Quiere decir que BlinkM podr a llamar a cualquier m etodo declarado en las interfaces que usa y deber a implementar tambi en cualquier evento declarado en esas interfaces. La interfaz Leds dene varios m etodos como redOn() o redOff(), que encienden o apagan los diferentes LEDs del mote. Como BlinkM usa esa interfaz, podr a invocar esos m etodos para su aplicaci on. Pero se debe tener en cuenta que Leds es s olo una interfaz: la implementaci on est a especicada en el chero de conguraci on Blink.nc (que la vinculaba con el componente LedsC). Timer.nc es tambi en interesante:
1 2 3 4 5
interface Timer { command result_t start ( char type , uint32_t interval ) ; command result_t stop () ; event result_t fired () ; } C odigo 2.4: Interfaz Timer.nc La interfaz Timer dene los m etodos start(), stop(), donde se especicar a el tipo de timer con el intervalo indicando cu ando expira el timer. Las unidad de tiempo en el argumento del intervalo son los milisegundos. Los tipos v alidos son: TIMER REPEAT Este timer termina despu es de un intervalo especifado. TIMER ONE SHOT Un timer de este tipo se va repitiendo continuamente hasta que se para con el m etodo stop(). Proyecto Final de Carrera 130
Una aplicaci on sabe que su timer ha expirado cuando recibe un evento. Esta interfaz proporciona el evento fired(). Un evento es una funci on que la implementaci on de una interfaz se nalizar a cuando se produzca un evento. En nuestro caso, el evento fired() se se naliza cuando pasa el intervalo de tiempo especicado. Esto es un ejemplo de interfaz bidireccional: una interfaz no s olo proporciona m etodos que pueden ser llamados por los usuarios de la interfaz, sino que tambi en produce eventos que llaman a los manejadores del usuario. Un m odulo que usa una interfaz debe implementar los eventos que usa esa interfaz. El resto del c odigo de BlinkM:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
implementation { command result_t StdControl . init () { call Leds . init () ; return SUCCESS ; } command result_t StdControl . start () { return call Timer . start ( TIMER_REPEAT , 1000) ; } command result_t StdControl . stop () { return call Timer . stop () ; } event result_t Timer . fired () { call Leds . redToggle () ; return SUCCESS ; } } C odigo 2.5: Continuaci on de BlinkM.nc El m odulo implementa los m etodos StdControl.init(), StdControl.start(), y StdControl.stop() y tambi en el evento Timer.fired(), ya que proporciona esa primera interfaz y porque es necesario implementar los eventos de las que use. El m etodo init() simplemente inicializa el subcomponente Leds. El m etodo start() invoca al Timer para crear un temporizador que se repita y expire cada segundo. El m etodo stop() para el timer. Cada vez que el evento Timer.fired() se dispara, el m etodo Leds.redToggle() hace que parpadee el led rojo. nesC proporciona tambi en la posibilidad de ver una representaci on gr aca de la relaci on entre componentes. Para esta aplicaci on es la siguiente:
Figura 5: Relaci on de componentes en Blink
131
Aplicaciones existentes TinyOS A continuaci on, comentaremos brevemente una serie de aplicaciones ya implementadas que nos han servido para realizar la programaci on de nuestras aplicaciones dom oticas, tanto para el env o de mensajes, como la toma de datos, as como la visualizaci on en ordenador de los campos de esos mensajes. CntToLedsAndRfm Esta aplicaci on es la uni on 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 s olo de tres leds el contador va de 0 a 7 y vuelve a empezar). En la primera aplicaci on muestra esa cuenta en los leds. En la segunda, a cada evento de reloj, incrementa el contador y env a un mensaje con ese valor. Esta aplicaci on reun a ambas: incrementa el contador, lo muestra en los leds y lo env a por radio. De aqu es importante ver c omo se consiguen realizar diferentes tareas, como la cuenta del contador, tomar cierta variable para que ejecute algo concreto (encender leds) o, lo que es m as importante, crear un mensaje que contenga dichos datos, funci on b asica de los nodos sensores. RfmToLeds Al programar un mote con esta aplicaci on, se dispondr a en estado de espera hasta que reciba un mensaje. Concretamente, recibir a un mensaje con un valor de un contador, que mostrar a en sus leds. Esta aplicaci on tambi en 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 b asicamente la funci on de un nodo actuador. Sense Esta aplicaci on en concreto programa el mote para que su sensor de luz haga un muestreo peri odico y, a partir de esta lectura, muestre en los leds los tres bits m as signicativos, para poder apreciar los cambios de la intensidad de luz. Por un lado, podemos congurar un sensor del mote, como es el de luz, pero tambi en veremos que, de forma sencilla y gracias a la programaci on por m odulos de nesC, tambi en se podr a llamar a cualquiera de los sensores de que dispone el mote, para medir temperatura o humedad. OscilloscopeRF Estas dos u ltimas aplicaciones podemos englobarlas en lo que es la visualizaci on 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, tomar a estos datos y los mostrar a en pantalla. Con esta aplicaci on pudimos ver los distintos niveles de luz, las medidas que tomaban, as como denir umbrales para ciertas aplicaciones. A modo de ejemplo, podemos ver un gr aco con las medidas de luz de dos motes. TOSBase La aplicaci on TOSBase es la que programa un mote como pasarela para recibir paquetes de datos por radio y transmitirlos por el puerto serie o USB a un ordenador. Proyecto Final de Carrera 132
Figura 6: Aplicaci on Oscilloscope Simplemente retransmite los paquetes que recibe y llegar an a la aplicaci on que corra en el ordenador para mostrar los datos. En el caso anterior pod amos ver un osciloscopio, pero tambi en 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 informaci on, pudimos congurar los mensajes de acuerdo a nuestro sistema y realizar las pruebas pertinentes.
Figura 7: Aplicaci on SerialForwarder y captura de mensajes
133
III.1.
Aplicaciones de iluminaci on
El sistema EIB establece una direcci on f sica para cada uno de sus componentes, de tal forma que puedan ser identicados dentro de una red. Pero debemos tener en cuenta que esta direcci on no es m as que un nombre que se le da al dispositivo, y no inuir a en la funcionalidad nal del mismo. Las direcciones que marcan el funcionamiento de un aparato son las direcciones de grupo. Estas direcciones establecen el comportamiento y los v nculos entre los objetos de comunicaci on de los distintos dispositivos que tendr a la red. En el caso de aplicaciones de iluminaci on, seg un los tipos de punto de datos (DPT) estandarizados de EIB, lo que llam abamos EIS, dispondremos de tres tipos de objetos de comunicaci on: Encender/Apagar (1.001) Este tipo de punto de datos se utiliza para conmutar el estado de un actuador. Anteriormente denominado EIS1, actualmente se le llama DPT 1.001. Consta de un solo bit, donde sus valores podr an ser 1 (Encender/Abrir/Verdadero/Alarma) o 0 (Apagar/Cerrar/Falso/No alarma). En nuestro caso ser a s olo Encender o Apagar luces. Regulaci on relativa (3.007) Este objeto de comunicaci on pertenece al bloque funcional Regular, anteriormente denominado EIS2 y que constaba de, al menos, la regulaci on relativa y el objeto de conmutaci on 1.001. Tambi en pod a incluir la regulaci on absoluta. Mediante este objeto se env a un comando de regulaci on relativo al valor de luz actual. Consta de cuatro bits de los cuales el m as signicativo indica si la regulaci on aumenta o disminuye la luminosidad con respecto a la luminosidad actual. Regulaci on absoluta (5.001) Con la funci on de regulaci on absoluta, de 8 bits, se ja directamente un valor de luminosidad previamente establecido, entre 1 (m nimo) y 255 (m aximo). Este tipo se suele utilizar para crear lo que se denominan escenas en dom otica. Por ejemplo, puede haber una escena-cine en la que ciertas luces que est en cerca de la pantalla pasen a un 20 % de intensidad y otras al 40 % al pulsar un bot on. Los nodos que se conguren como sensores tendr an el comportamiento de pulsadores convencionales. Es decir, estar an conectados a un pulsador y cuando este sea pulsado, recibir an un evento de bot on y enviar an un mensaje concreto, dependiendo del bot on pulsado. Cada bot on tendr a asociado un objeto de comunicaci on, 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 m as intensidad, regular a menos, o incluso lo que se denominan funciones centrales, que conciernen a todos los sistemas de iluminaci on, por ejemplo, apagar todas las luces de una casa. Trasladando todo esto al protocolo EIB, diremos que asociamos una direcci on de grupo a cada uno de estos objetos de comunicaci on. Es decir, el objeto de comunicaci on que enciende una luz se asociar a con una direcci on 1/1/1, por ejemplo. Cada vez que se pulse el bot on vinculado a ese objeto de comunicaci on, se enviar a un mensaje con esa direcci on de grupo. Los mensajes enviados por los nodos pulsadores llegar an a los nodos congurados como actuadores, que llevar an asociadas una serie de direcciones de grupo ante las que tendr an que efectuar ciertas acciones. Proyecto Final de Carrera 134
Si un nodo actuador tiene asociada la direcci on 1/1/1 y le llega un mensaje con esa direcci on, realizar a la acci on consecuente, en este caso, encender una luz. A modo de ejemplo, podemos ver este gr aco:
Figura 8: Ejemplo de telos sensores y actuadores En este caso, tenemos un nodo congurado como pulsador, cuya direcci on f sica es 1.1.1. Observamos que tiene cuatro tipos distintos de objetos de comunicaci on (en realidad son s olo dos, conmutaci on y regulaci on relativa pero congurados para diferentes prop ositos) asociados a cuatro direcciones de grupo. Por ejemplo, la direcci on 1/1/3 ordenar a que haya una regulaci on que disminuya la luminosidad pero no sabe a qu e luces afectar a. Enviar a el mensaje y todos aquellos actuadores que tengan asociada esa misma direcci on 1/1/3 ser an los que ejecuten dicha regulaci on. Por otro lado, tenemos dos actuadores con sus direcciones f sicas. 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 encender a o se apagar a de forma conmutada cuando le lleguen esos eventos de bot on. Y el otro nodo, con las direcciones 1/1/2 y 1/1/3 se regular a hacia m as o menos luz, pero tambi en se apagar a con 1/1/4. Esto es lo que se denomina funci on central: con la pulsaci on del bot on que env a la direcci on 1/1/4 realizaremos un apagado de todos los nodos existentes, ya que todos los actuadores responden ante ese evento, realizando la misma acci on. Teniendo en cuenta esta diferenciaci on entre nodos sensores y actuadores, veamos c omo se ha realizado la programaci on de ambas partes. Examinaremos las partes m as importantes del c odigo que nos ayuden a comprender el proceso que tiene lugar en cada uno de los nodos, pudiendo comprobar el c odigo completo en el ap endice. Para todas las aplicaciones que vamos a ver, tendremos que el archivo principal de conguraci on es eib.nc y el m odulo eibM.nc. Adem as, como ya dijimos, para una aplicaci on pod a incluirse un tipo de archivo que especicara el tipo de mensajes, como es lo que ocurre en nuestro caso de forma com un a todas las aplicaciones. Proyecto Final de Carrera 135
El archivo en cuesti on 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 regulaci on absoluta. Incluye los campos de los mensajes que se env an entre los nodos. Tambi en, para mayor comodidad hemos incluido una enumeraci on de distintas direcciones de grupo posibles y de los valores que pueden tomar los DPT en el campo de datos.
1 2 3 4 5 6 7 8 9 10
typedef struct EIBMsg { uint8_t control ; uint8_t seqno ; uint16_t dfisica ; uint16_t dgrupo ; uint8_t hop_count ; uint8_t length ; uint16_t datos ; uint8_t seguridad ; } EIBMsg ; C odigo 2.6: EIBMsg.h Como vemos, al igual que en un mensaje EIB incluimos los campos: control Conguramos este byte de control para que indique que es un telegrama con prioridad baja para todos los mensajes. Se podr a congurar para otras prioridades, repeticiones o incluso para mensajes de control. En com un para todos, el c odigo ser a 0xBC en hexadecimal. seqno N umero de secuencia del mensaje. Es importante indicar el n umero de secuencia para la sincronizaci on de mensajes entre emisores y receptores. Este campo no estaba descrito para EIB pero lo hemos considerado necesario en este tipo de redes. dsica Direcci on f sica que se le quiera dar al dispositivo, como si fuera la direcci on origen. dgrupo Direcci on de grupo a la que va destinada el mensaje. Es la direcci on destino, puesto que englobar a 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 cu antos nodos ha pasado un mensaje hasta llegar a su destino y puede ser u til para dar informaci on de la red o realizar otras conguraciones. length Longitud del mensaje. En nuestros tipos de mensaje tendr a valor 1 excepto en los de regulaci on absoluta que ser a de 2. datos Conjunto de datos u tiles. Llevar a incluido el comando y los datos. En caso de regulaci on absoluta tambi en incluiremos el valor denido. seguridad Byte de seguridad o comprobaci on como vimos que hab a en el sistema EIB. Permitir a comprobar el correcto env o de tramas para m etodos de comprobaci on de bits.
136
Nodos pulsadores de iluminaci on

Comenzaremos con los nodos pulsadores, cuyo chero es EIB reg bot denominado as porque sigue el protocolo de mensajes EIB, y est a destinado a pulsadores o botones para funciones de regulaci on, incluyendo tambi en la regulaci on absoluta con un valor prejado. eib.nc La parte m as importante del c odigo de conguraci on es la implementaci on, donde veremos qu e componentes utilizamos y los v nculos entre ellos:
1 2 3 4 5 6 7 8 9 10 11 12 13
implementation { components Main , eibM , GenericComm , LedsIntensityC , TimerC ; Main . StdControl -> eibM ; Main . StdControl -> LedsIntensityC ; eibM . CommControl -> GenericComm ; eibM . ReceiveEIBMsg -> GenericComm . ReceiveMsg [ AM_EIBMSG ]; eibM . Send -> GenericComm . SendMsg [ AM_EIBMSG ]; eibM . LedsIntensity -> LedsIntensityC ; eibM . TimerMilli -> TimerC . TimerMilli [ unique (" TimerMilli ") ]; } C odigo 2.7: eib.nc Los componentes que se utilizan en este c odigo los podemos apreciar en la l nea 2 y son: Main, eibM, GenericComm, LedsIntensityC y TimerC. En las dos primeras l neas vemos c omo la interfaz StdControl, que ya vimos que realiza las funciones de inicializaci on, es implemetada en eibM y por el componente LedsIntensityC. En las l neas 7-9 se establece el v nculo con el componente GenericComm, que ser a quien implemente las comunicaciones, tanto los m etodos de env o de mensajes (SendMsg) como la recepci on (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 permitir a regular los leds con distintos valores de intensidad en un rango de 0 a 255. Gracias a esta interfaz, aplicaremos la regulaci on 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 aplicaci on.
Figura 9: Diagrama de eib.nc Proyecto Final de Carrera 137
Por otro lado, analizaremos la sentencia siguiente con un poco m as 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 ejecuci on o de compilaci on. Recordemos que es posible para un componente proveer m ultiples 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 generalizaci on 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 aplicaci on 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 transmisi on 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 especicando que eibM.TimerMilli estar a conectado a la instancia de la interfaz TimerMilli especicada por el valor entre corchetes. Este puede ser cualquier n umero positivo de 8 bits. Si tuvi eramos que especicar un valor particular aqu , como 38 o 42, se podr a dar accidentalmente un conicto con el timer usado por otro componente (si ese componente us o el mismo valor entre corchetes). Por eso, usamos la funci on constante en tiempo de compilaci on unique(), que genera un u nico identicador de 8 bits de la palabra dada como argumento. En este caso, unique("TimerMilli") genera un u nico n umero de 8 bits de un conjunto 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. T engase 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 pr actica usar el nombre de la interfaz parametrizada como argumento de la funci on unique().
138
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 est an conectando los m etodos de env o y recibo de eibM con los proporcionados 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 identicadores IDs del manejador AM (Active Message ) se conectan juntos. En eibM, estamos conectando la interfaz SendMsg correspondiente al ID del manejador AM EIBMSG a GenericComm.SendMsg. (AM EIBMSG es un valor global denido en EIBMsg.h). Cuando el m etodo SendMsg se invoca, se le proporciona el ID del manejador, esencialmente como un argumento extra. Para nuestras aplicaciones hemos elegido TimerMilli porque ofrece m as posibilidades que la interfaz Timer original. Si observamos el c odigo de la interfaz:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
interface TimerMilli { command result_t setPeriodic ( int32_t millis ) ; command result_t setOneShot ( int32_t millis ) ; command result_t stop () ; command command command command bool isSet () ; bool isPeriodic () ; bool isOneShot () ; int32_t getPeriod () ;
event result_t fired () ; } C odigo 2.8: Interfaz TimerMilli.nc Como se puede observar, adem as de los m etodos para establecer un timer de un solo disparo o peri odico, el m etodo stop() y el evento fired(), disponemos de nuevas funciones. Estos nuevos m etodos (l neas 8-11) nos permiten saber: isSet() si el Timer est a activado. isPeriodic() si el Timer es peri odico. isOneShot() si el Timer es de un solo disparo. getPeriod() el per odo que tiene congurado el Timer. Estos m etodos nos han sido de ayuda a la hora de realizar comprobaciones en las aplicaciones, para saber si estaba activado el timer en un determinado momento, por ejemplo.
139
eibM.nc La implementaci on del m odulo eibM.nc est a compuesta de distintas variables, m etodos y eventos. Podemos dividir el c odigo en tres partes fundamentales: 1. Transmisi on de mensajes. 2. Procesado de mensajes. 3. Recepci on de mensajes. Puesto que estamos analizando un nodo sensor, este estar a dedicado a las labores de transmisi on de mensajes cuando se produzca un evento de bot on en el. En cambio, la parte de procesado y recepci on de mensajes es labor fundamental de los nodos actuadores. Sin embargo, debemos tener en cuenta que estamos tratando con redes inal ambricas de sensores, distribuidos geogr acamente en sitios distintos. Esto quiere decir que quiz a un nodo sensor est e situado de tal forma que deba encaminar un mensaje. Si, adem as, tenemos en cuenta que, tal y como describe el sistema EIB, un mensaje es enviado de forma broadcast, todos los nodos recibir an el mensaje pero s olo actuar an los que deben hacerlo, de acuerdo con la pol tica de direcciones de grupo. Normalmente, un nodo sensor no estar a programado para procesar un mensaje, pero s puede congurarse como nodo de enlace o encaminador de mensajes hacia otros nodos actuadores que se encuentren en una ubicaci on que no est a al alcance del emisor. Por esto, un nodo sensor o un nodo actuador podr a establecerse como retransmisor de mensajes, si as lo requiere la topolog a con la que estemos trabajando. En el caso de topolog as est aticas es relativamente sencillo congurar estos nodos, de acuerdo a las distancias y el alcance; en cambio, para topolog a din amicas debe haber un algoritmo que vaya estableciendo continuamente la posici on de los nodos as como las relaciones establecidas entre ellos. Transmisi on de mensajes Inicialmente, como en toda aplicaci on, se ejecutar an los m etodos de inicializaci on Init(), Start() y Stop(), pero estos carecen ahora de importancia para nosotros. Unicamente debemos tener en cuenta que en ellos se inicializar an las distintas variables, el timer, y en el m etodo Init() podremos congurar los las funciones de los botones, como veremos. Los eventos y tareas m as 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 estar a saltando peri odicamente para detectar cualquier evento de bot on. Cuando este ocurra activar a un contador para poder determinar si es una pulsaci on corta o larga. A continuaci on, y dependiendo de esto u ltimo, se invocar a la tarea correspondiente. Si es una pulsaci on corta se enviar a el mensaje que haya sido programado para pulsaci on corta (encender/apagar) y si es una pulsaci on larga se enviar a para que regule hacia m as o menos luminosidad, como se haya denido. Para parar la regulaci on de pulsaci on larga existe la tarea de stop y, nalmente se se nalizar a el evento de que se ha enviado correctamente el mensaje. Proyecto Final de Carrera 140
El c odigo de la funci on Timer sigue el siguiente algoritmo:
Figura 11: Algoritmo de Timer Las variables m as importantes son: tpulsado, que lleva la cuenta del tiempo que est a pulsado el bot on; tfrontera, que es el tiempo frontera establecido para diferenciar una pulsaci on corta de una pulsaci on larga; enviadaLarga, un booleano que indica si se ha enviado o no un mensaje de pulsaci on larga. Las tres opciones que pueden ocurrir son: EnviarLarga: Cuando el bot on sea pulsado y supere la frontera, querr a decir que es una pulsaci on larga y, por tanto, se invocar a a la tarea enviarPulsacionLarga. EnviarCorta: Si, por el contrario, el bot on ha sido pulsado pero deja de estar pulsado antes de pasar el tiempo frontera, determinaremos una pulsaci on corta y se invocar aa la tarea enviarPulsacionCorta. EnviarStop: Por u ltimo, este ser a el caso en que se libere el bot on y, previamente, se hab a enviado una pulsaci on larga, por lo que habr a que detener el proceso. Profundizando en el c odigo podemos ver c omo la variable valorBoton nos va a establecer si hay un evento de bot on (con 0x0000) o no. Una vez se haya detectado la pulsaci on, se pone en marcha la cuenta del tiempo que est a pulsado, mientras sigue dispar andose el timer, realiz andose el algoritmo que acabamos de comentar.
141
El c odigo fuente es el siguiente:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
event result_t TimerMilli . fired () { valorBoton = T O S H _ R E AD _ BO TO N _U N O_ PI N () ; if ( valorBoton == 0 x0000 ) { tpulsado = tpulsado + 100; if (( tpulsado > tfrontera ) && ! enviadaLarga ) { post enviarPulsacionLarga () ; enviadaLarga = TRUE ; } } else { if (( tpulsado < tfrontera ) && ( tpulsado != 0) ) { post e n v i a rPulsacionCorta () ; tpulsado = 0; } else { if ( enviadaLarga ) { post enviarSTOPlarga () ; } tpulsado = 0; enviadaLarga = FALSE ; } } return SUCCESS ; } C odigo 2.9: Funci on de Timer Las tareas que se invocan tanto para una pulsaci on corta, larga o para dejar de ejecutar una regulaci on, consisten en el env o de un mensaje, diferenci andose u nicamente en la direcci on de grupo del mensaje y en el campo de los datos. Para la pulsaci on corta (encender/apagar) enviaremos, por ejemplo, la direcci on de grupo 1/1/1 mientras que para la larga (regulaci on) utilizaremos la 1/1/3. Y en el campo de datos especicaremos el caso que sea: ESCRIBIR ON = 0x0081 ESCRIBIR OFF = 0x0080 ESCRIBIR TOGGLE = 0X0082 REGULAR LUZ = 0x0089 REGULAR OSCURIDAD = 0X0081 REGULAR STOP = 0X0088
142
A modo de ejemplo, veamos el c odigo del env o de mensaje para pulsaci on corta:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
task void e n v i a r P u l s a c i o n C orta () { EIBMsg * message = ( EIBMsg *) data . data ; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; message - > seqno = lastSeqno ; message - > datos = ESCRIBIR_TOGGLE ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_2 ; message - > dgrupo = DIRE_GRUPO_1_1_1 ; message - > hop_count = 0 x00 ; message - > length = 0 x01 ; message - > seguridad = 255; } call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ; pending1 = FALSE ; } } C odigo 2.10: Tarea de env o para pulsaci on 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 recepci on de un mensaje obteniendo: 0E 01 08 03 FF FF FF FF 04 7D | BC 02 ... 00
A destacar los campos de direcci on (address) que establecimos como broadcast (0xFFFF) y el tipo de mensaje (type) que toma el valor de AM EIBMSG. Proyecto Final de Carrera 143
En el resto del c odigo de la pulsaci on corta debemos destacar algunas sentencias como la actualizaci on del n umero de secuencia del mensaje (l neas 6-7), o que en el campo de datos se asigna para que se realice la funci on TOGGLE, (l nea 9) que har a encender la luz si est a apagada y apagarla si est a encendida, aunque esto corre a cargo del actuador. Aqu hemos presentado las principales sentencias del c odigo, aunque si revisamos el c odigo completo veremos que para asignar el valor del campo de datos hemos establecido un switch para elegir la funci on del bot on, tanto para pulsaci on corta, larga, como el valor de regulaci on absoluta, como veremos un poco m as adelante. Para nalizar, tambi en se ve denida la direcci on de grupo claramente (l nea 14) y c omo se env a nalmente el mensaje (l nea 19) mediante la llamada: call Send.send(TOS BCAST ADDR, sizeof(EIBMsg), &data); Si profundizamos en la interfaz SendMsg, el m etodo que proporciona es: command result t send(uint16 t address, uint8 t length, TOS MsgPtr msg); Donde los argumentos son: uint16 t address Direcci on de destino. En nuestro caso, con TOS BCAST ADDR = 0xFFFF, hacemos un env o broadcast. uint8 t length La longitud del buer de datos que enviamos. La obtenemos en nuestro caso con la funci on sizeOf(). TOS MsgPtr msg Mensaje o buer de datos que queremos enviar. Para la regulaci on, con pulsaciones largas, lo u nico que cambiaremos ser a la direcci on de grupo, puesto que se trata de otro objeto de comunicaci on y el valor de los datos podr a ser, por ejemplo, para disminuir la luminosidad, tal y como se ha denido en EIBMsg.h: message->datos = REGULAR OSCURIDAD; Mientras que para detener la regulaci on podemos utilizar la misma direcci on de grupo pero el campo de datos ser a: message->datos = REGULAR STOP; En el caso de regulaci on absoluta, variaremos la longitud e introduciremos el valor en los datos, por ejemplo: message->valor = VALOR 20 %;
144
Conguraci on de funciones para los botones Con el objetivo de que la programaci on de los motes sea m as sencilla, hemos establecido unas variables para congurar la funci on que tendr a cada bot on del dispositivo. Dependiendo del valor que se les d e, el bot on encender a, apagar a, regular a hacia m as luz u oscuridad, o lo que deseemos para sus pulsaciones corta y larga. Las variables pueden modicarse en el m etodo Init() y sus conguraciones posibles son: int8 t funcionCorta: Determina la funci on para una pulsaci on corta. Puede tomar 4 valores (1-4) consistentes en: 1. Funci on On. 2. Funci on O. 3. Funci on Toggle, alternar. 4. Funci on de regulaci on absoluta, con un valor que estableceremos con la variable valorAbs. int8 t funcionLarga: Determina la funci on para una pulsaci on larga de bot on. Puede tomar 2 valores (1-2) que son: 1. Regulaci on hacia m as luz. 2. Regulaci on hacia m as oscuridad. int8 t valorAbs: Indica el valor de regulaci on absoluta, en el caso de que la pulsaci on corta estuviera congurada 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 l neas de c odigo, se traduce de la siguiente forma al crear el mensaje y darle valores a sus campos, por ejemplo, para el caso de pulsaci on larga y elegir el tipo de regulaci on:
1 2 3 4 5 6 7 8 9 10 11
switch ( funcionCorta ) { case 1: message - > datos = ESCRIBIR_ON ; break ; case 2: message - > datos = ESCRIBIR_OFF ; break ; case 3: message - > datos = ESCRIBIR_TOGGLE ; break ; case 4: message - > length = 0 x02 ; message - > datos = REGULACION_ABSOLUTA ; break ; } C odigo 2.11: Ejemplo de conguraci on de funciones de bot on
145
Recepci on y procesado de mensajes Aunque ya hemos comentado que esta parte es la que realizan los nodos actuadores, estableceremos aqu los m etodos generales m as importantes para la conguraci on de un nodo sensor como retransmisor de mensajes. Los principales m etodos 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 m etodo 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 continuaci on se llama al m etodo que procesa los comandos ProcessCmd.execute que actualizar a ciertas variables y llamar a al int erprete de mensajes, que analizaremos m as adelante. De estos m etodos 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 bot on. int8 t pending2 Indica si hay alg un proceso pendiente en la recepci on. El int erprete de mensajes cmdInterpret, es quien realmente decidir a qu e hace un nodo actuador en funci on de los mensajes que reciba. Por lo tanto, este m etodo no estar a denido para un nodo sensor sino que directamente pasaremos al evento de tareas y procesado terminados: ProcessCmd.done. Una vez hecho esto, si el nodo es retransmisior se invocar a a la tarea forwarder que reenviar a el mismo mensaje que se ha recibido, sin realizarle cambio alguno o actualizando los campos que se deseen, como la direcci on f sica o el contador de saltos. El c odigo de este m etodo es:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
task void forwarder () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > seqno = lastSeqno ; message - > dfisica = DIRE_F ISICA_1_1_2 ; if ( retransmite ) { call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , m ) ; } else { pending1 = FALSE ; bcast_pending = 0; } } C odigo 2.12: Tarea de retransmisi on
146
Nodos actuadores de iluminaci on

El chero con el que tratamos en este caso se denomina EIB reg led ya que ahora estamos congurando un actuador de regulaci on, que transmitir a las ordenes a luces o, en nuestro caso, a los leds. La mayor parte del c odigo ya la hemos desarrollado en el apartado anterior, puesto que hemos explicado parte de los m etodos de recepci on y los m etodos de transmisi on, aunque en este caso lo habitual es que el nodo no sea preparado para realizar las funciones t picas de un sensor. La tarea que es la base del funcionamiento de un nodo actuador es el int erprete de mensajes cmdInterpret. En ella se analizar a el contenido de un mensaje, siendo partes fundamentales: Direcci on de grupo. Si el mensaje va destinado a una direcci on de grupo ante la que un nodo actuador no debe responder, no se producir a ninguna acci on. Si el nodo s la tiene registrada, examinar a los datos a continuaci on. Datos u tiles. Dependiendo de la funci on que establezcan los datos, como pueden ser ESCRIBIR TOGGLE o REGULAR LUZ, se ejecutar an los comandos pertinentes. Cuando sean funciones de conmutaci on la ejecuci on ser a m as simple, en cambio, para funciones de regulaci on relativa entrar a en juego el timer. Longitud. Para el caso de regulaci on absoluta, variaremos este campo del mensaje puesto que es diferente de la regulaci on relativa. Si se trata de una absoluta se tratar a de transmitir ese valor determinado a las luces. En la p agina siguiente tenemos la primera parte del c odigo de int erprete de mensajes. En la primera sentencia: struct EIBMsg *message = (struct EIBMsg *)m->data; Se est a 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, direcci on de grupo, etc. Si examinamos c omo contin ua el c odigo, comprobamos que para la direcci on de grupo 1/1/1 el actuador ejecutar a diversas acciones dependiendo del campo de datos: message->datos==ESCRIBIR ON En este caso la funci on LedsIntensity establece la intensidad de luz al m aximo para el led que hayamos designado. message->datos==ESCRIBIR OFF En este caso daremos la orden de apagar el led, o las luces que est en incluidas en este comando y est en bajo el control de este nodo actuador, por supuesto. message->datos==ESCRIBIR TOGGLE Este caso es diferente, puesto que primero hay que saber si est a encendida o no la luz (mediante la variable valorLuz) y actuar en consecuencia para conseguir que se alterne la iluminaci on. message->datos==REGULACION ABSOLUTA Este es el caso de la regulaci on absoluta para la pulsaci on corta. Se jar a una intensidad de luz determinada en los leds, congurada mediante la variable valorAbs.
147
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
task void cmdInterpret () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; switch ( message - > dgrupo ) { case DIRE_GRUPO_1_1_1 : if ( message - > datos == ESCRIBIR_ON ) { call LedsIntensity . set (0 x00 ,255) ; } if ( message - > datos == ESCRIBIR_OFF ) { call LedsIntensity . set (0 x00 ,0) ; } if ( message - > datos == ESCRIBIR_TOGGLE ) { if (! valorLuz ) { call LedsIntensity . set (0 x00 ,255) ; valorLuz = TRUE ; intensidad = 255; } else { call LedsIntensity . set (0 x00 ,0) ; valorLuz = FALSE ; intensidad = 0; } if ( message - > datos == REGULACION_ABSOLUTA ) { valorRecibido = message - > valor ; call LedsIntensity . set ( 0 x00 , valorRecibido ) ; valorLuz = TRUE ; intensidad = valorRecibido ; } break ; C odigo 2.13: Int erprete de mensajes (1) Para el caso de la direcci on de grupo de regulaci on, el c odigo es el similar. Para la regulaci on relativa, se activan dos variables (regular luz y regular sombra) que har an que comience la regulaci on al dispararse el timer. De la misma forma, una vez que termina una pulsaci on larga se enviar a un mensaje de tipo REGULAR STOP que har a que pare la regulaci on del tipo que sea. Dentro de esta opci on, se baraja la posibilidad de que se d e una pulsaci on corta tras una regulaci on de luz, y lo que hacemos es establecer, por convenio, que siempre se apaguen. Esto puede ser denido por el gusto del usuario, puede decidir que siempre se apaguen o se enciendan o que un bot on de regulaci on hacia m as luz siempre encienda o al contrario. Veamos el resto de c odigo del int erprete as como el Timer, que ir a realizando la regulaci on de cada tipo.
148
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
case DIRE_GRUPO_1_1_3 : if ( message - > length == 0 x01 ) { if ( message - > datos == REGULAR_LUZ ) { regular_luz = TRUE ; } if ( message - > datos == REGULAR_OSCURIDAD ) { regular_sombra = TRUE ; } if ( message - > datos == REGULAR_STOP ) { regular_luz = FALSE ; regular_sombra = FALSE ; if (! estadozero ) { valorLuz = TRUE ; } else { valorLuz = FALSE ; estadozero = FALSE ; } }} C odigo 2.14: Int erprete de mensajes (2)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
event result_t TimerMilli . fired () { if ( regular_luz ) { if ( intensidad < 255) { intensidad = intensidad + factor ; call LedsIntensity . set (0 x00 , intensidad ) ; } else { call LedsIntensity . set (0 x00 , 255) ; valorLuz = TRUE ;} } if ( regular_sombra ) { if ( intensidad > 0) { intensidad = intensidad - factor ; call LedsIntensity . set (0 x00 , intensidad ) ; } else { call LedsIntensity . set (0 x00 , 0) ; estadozero = TRUE ;} } return SUCCESS ;} C odigo 2.15: Timer de regulaci on
149
El funcionamiento es sencillo, ya que cada vez que se dispara el timer va comprobando si la variable sigue activada, y si es as , continuar a regulando hacia m as o menos luz. Lo que s que hay que tener en cuenta es marcar claramente cu ando una luz est a encendida o apagada totalmente (estadozero) para que no haya incongruencias al recibir peticiones de pulsaci on corta. Es decir, si se regula hacia oscuridad dejando apagada la luz y despu es se ejecuta una pulsaci on corta pero no se enciende porque a la funci on TOGGLE le tocaba apagar la luz, mostrar a aparentemente que el sistema no funciona bien. En el sistema dom otico EIB hay varias formas de controlar estos casos, una de ellas se realiza mediante el env o de mensajes con unos objetos de comunicaci on 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 qu e estado se encuentra y no se producir an fallos de este tipo. Por otro lado, cuando una luz est a a medio regular y recibe una pulsaci on corta, se suele denir 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 regulaci on, que las luces est an encendidas; de esta forma lo que har a una pulsaci on corta ser a apagarlas. Aunque ya decimos que esto se puede congurar seg un preferencias, un bot on que regula hacia m as luz puede congurarse para que siempre encienda totalmente las luces con una pulsaci on corta, y al contrario con un bot on de regulaci on hacia m as oscuridad.
150
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 m nimo de los objetos de comunicaci on con los siguientes tipos de datos (DPT): Subir/Bajar (1.008) Cuando se escribe este objeto de comunicaci on se pone en marcha un motor en reposo o se cambia de direcci on si ya estaba en movimiento, tras un breve tiempo de espera. Consta de 1 bit y se corresponde con la acci on de subir o bajar totalmente una persiana o toldo: si es 0 indicar a Subiendo/Recogiendo y si es 1 ser a Bajando/Extendiendo. Paso (1.007) Tambi en consta de un solo bit y permitir a, mediante una pulsaci on 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 convencional o un giro breve en una persiana de lamas. El bit indicar a un Stop/Paso abajo si es 1 y un Stop/Paso arriba si es 0. En este caso los nodos pulsadores tambi en deber an distinguir entre pulsaci on corta y larga, asoci andose a un tipo de objeto de comunicaci on o a otro: la pulsaci on corta a un movimiento de paso y la pulsaci on 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 est e encendido indicar a que est a subiendo y si est a apagado es que est a parado.
Nodos pulsadores de persianas

Los pulsadores de persianas, al tener tambi en la diferenciaci on entre pulsaci on corta y larga van a estar programados exactamente igual que los nodos pulsadores de iluminaci on. La u nica diferencia vendr a en el campo de datos, donde habr a que indicar si se env a un objeto para subir o bajar, o si es un paso de subida o bajada, lo que se congurar a tambi en f acilmente modicando una u nica variable. (Podemos ver el c odigo en el anexo correspondiente). Pero incluso esta parte estar a controlada casi en su totalidad por los nodos actuadores, porque en los pulsadores estableceremos una direcci on de grupo para un objeto de comunicaci on y otra direcci on distinta para el otro objeto, sin m as complicaci on. El campo de datos podr a 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 atender a ante este comando subiendo totalmente la persiana, es decir, poniendo en marcha el bot on durante el tiempo predenido para la subida total. En el caso del DPT 1.007 se efectuar a un paso de hacia arriba. 2. message->datos = ESCRIBIR OFF; Cuando se env e este comando, ser a para bajar totalmente una persiana o toldo si es el primer caso. Si es el caso de un movimiento de paso, se producir a un paso hacia abajo.
151
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 bot on congurado para la subida de la persiana, podr a enviar una direcci on de grupo para que suba totalmente la persiana y otra para que s olo realice un paso de subida. Lo mismo ocurrir a con otro bot on congurado de bajada. Adem as, el actuador deber a tener prejados unos tiempos espec cos para el buen funcionamiento. Por ello, creamos las variables: tpaso Tiempo que dura un paso de subida/bajada. ttotal Tiempo establecido para hacer una subida/bajada total, que d e tiempo a toda la carrera de la persiana. twait Tiempo de espera que hay que respetar cuando hay colisi on subida/bajada, es decir, cuando, estando en movimiento, se hace una petici on de movimiento en sentido contrario.
Figura 12: Ejemplo de telos en aplicaci on de persianas En este ejemplo podemos ver c omo un telos nodo sensor est a provisto de dos botones congurados 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 efectuar a la subida o bajada (representada por la luz verde o roja) en funci on de lo que reciba. Por ejemplo, si se hace una pulsaci on corta con el bot on de subida se enviar a la direcci on 1/1/4 y el actuador recibir a ese mensaje, evaluar a los datos que llevar an la acci on ESCRIBIR ON y, por tanto, encender a la luz verde de subida durante el tiempo de un paso. Si, por el contrario, se hace una pulsaci on larga de bajada, se enviar a la 1/1/5 pero con el comando ESCRIBIR OFF, lo que encender a el led rojo durante el tiempo ttotal, a no ser que sea interrumpido con una pulsaci on corta de cualquiera de los botones, que se traduce como un stop del movimiento. Lo m as 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. Proyecto Final de Carrera 152
Algoritmo de movimiento de paso
Figura 13: Algoritmo de movimiento de paso El c odigo ser a:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
case DIRE_GRUPO_1_1_4 : if ( message - > datos == ESCRIBIR_ON ) { if ( total_subir || total_bajar ) { total_subir = FALSE ; total_bajar = FALSE ; call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x02 , 0 ) ; } else { paso_subir = TRUE ; paso_bajar = FALSE ; tcounter = 0; }} C odigo 2.16: Paso de subida en persianas Proyecto Final de Carrera 153
En este algoritmo, cuando se hace una petici on de paso de subida, por ejemplo con la direcci on 1/1/4 del ejemplo anterior, primero se comprueba si ya estaba en movimiento de subida o bajada, por lo que la pulsaci on corta pasa a ser un comando de stop. Si no es as , saltar a el timer y empezar a a correr un contador de tiempo. El motor se pondr a en marcha hasta que se supere el tiempo establecido como el tiempo de paso. Una vez se rebase ese tiempo, el motor se parar a.
1 2 3 4 5 6 7 8 9 10 11 12
event result_t TimerMilli . fired () { if ( paso_subir ) { tcounter = tcounter + 100; call LedsIntensity . set ( 0 x00 , 255 ) ;
// motor ON
if ( tcounter > tpaso ) { call LedsIntensity . set ( 0 x00 , 0 ) ;; // motor OFF paso_subir = FALSE ; tcounter = 0; } C odigo 2.17: Timer - Paso de subida en persianas El algoritmo es similar para un paso de bajada, con la salvedad de que el actuador activar a 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 nal podemos observar el diagrama completo, v alido tambi en para esta aplicaci on.
154
Algoritmo de movimiento total Al realizar una petici on de movimiento total de subida o bajada, es muy importante controlar si ya estaba en movimiento. Si es as , los pasos a seguir ser an: 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 dir a cu ando hemos superado ese tiempo de espera. Una vez superado, podremos poner el motor en marcha hasta que se pase lo que hemos predenido como tiempo total.
Figura 14: Algoritmo de movimiento total
155
El c odigo para la subida total de una persiana ser a:

1 2 3 4 5 6 7 8
case DIRE_GRUPO_1_1_5 : if ( message - > datos == ESCRIBIR_ON ) { total_subir = TRUE ; if ( total_bajar ) { wait = TRUE ;} total_bajar = FALSE ; tcounter = 0; call LedsIntensity . set ( 0 x02 , 0 ) ;} C odigo 2.18: Subida total en persianas Apreciamos c omo, si estaba realizando el movimiento contrario de bajada, se establece el tiempo de espera, adem as de parar dicho movimiento para activar el contrario.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
// SUBIDA TOTAL DE PERSIANA if ( total_subir ) { tcounter = tcounter + 100; if ( wait ) { // Caso de colision if ( tcounter > twait ) { call LedsIntensity . set ( 0 x00 , 255 ) ; if ( tcounter > ttotal ) { call LedsIntensity . set ( 0 x00 , 0 ) ; total_subir = FALSE ; tcounter = 0; wait = FALSE ; }} } else { // Caso normal , sin colisi on call LedsIntensity . set ( 0 x00 , 255 ) ; if ( tcounter > ttotal ) { call LedsIntensity . set ( 0 x00 , 0 ) ; total_subir = FALSE ; tcounter = 0; }}} C odigo 2.19: Timer - Subida total en persianas En el Timer se distinguen los dos casos: 1. Con colisi on: en el que esperar a el tiempo determinado twait y luego pondr a el motor en marcha hasta que pase el tiempo total. 2. Sin colisi on: simplemente pondr a en marcha el motor hasta que el contador determine que se ha superado el tiempo total.
156
III.3.
Aplicaci on de sensor crepuscular
Para congurar un nodo como sensor crepuscular, de temperatura como termostato o de humedad vimos que dispon amos de la aplicaci on Sense, que va tomando medidas del sensor que tenga congurado. A modo de ejemplo, realizaremos la programaci on de un nodo sensor crepuscular, cuyas medidas ser an de luz solar. Los TelosB, adem as del sensor de temperatura y humedad, disponen de dos tipos de sensores de luz Hamamatsu: PAR: Photosynthetically Active Radiation. Radiaci on fotosint etica activa. TSR: Total Solar Radiation. Radiaci on solar total. Activaremos el sensor de radiaci on solar, con el que ir a tomando medidas de luz a cada salto de reloj. Los m etodos m as importantes de este componente Sense son:
1 2 3 4 5 6 7 8
event result_t Timer . fired () { return call ADC . getData () ; } async event result_t ADC . dataReady ( uint16_t data ) { call IntOutput . output (( data > >7) &0 x7 ) ; return SUCCESS ; } C odigo 2.20: Funcionamiento b asico de Sense Cuando se dispara el timer se toman los datos, procesados por el componente ADC mediante el m etodo: call ADC.getData(); Una vez se han tomado los datos (ADC.dataReady) se invoca al m etodo IntOutput.output que pasar a la informaci on a nuestro c odigo. IntOutput.output((data 7) &0x7); Con esa sentencia, los datos son desplazados lo necesario para tomar los bits m as signicativos y que est en, adem as, en una escala de 0-7. El diagrama de conguraci on de esta aplicaci on Sense es el siguiente:
Figura 15: Diagrama Sense.nc Proyecto Final de Carrera 157
En el diagrama podemos apreciar la relaci on entre SenseM y eib, mediante el m etodo que hemos comentado, IntOutput. Adem as, destacamos tambi en la relaci on con el componente DemoSensor2C, que ser a el que congure el sensor como luz, vincul andolo a los sensores de luz Hamamatsu. Podemos ver parte de este c odigo completo que encontraremos en los ap endices nales, a continuaci on:
1 2 3 4 5 6 7 8 9 10 11 12
configuration DemoSensor2C { provides interface ADC ; provides interface StdControl ; } implementation { components HamamatsuC as DemoSensor ; StdControl = DemoSensor ; ADC = DemoSensor ; } C odigo 2.21: Conguraci on de DemoSensor2C Un sensor crepuscular de este tipo puede congurarse para que cuando se sobrepasa cierto umbral de luz u oscuridad, se env e un mensaje a un actuador de conmutaci on para que encienda o apague luces. Ese es el funcionamiento m as sencillo. Sin embargo, ya que podemos programar actuadores de regulaci on que consiguen regulaci on absoluta, nos aprovechamos de esta utilidad para completar esta aplicaci on, creando un sensor crepuscular que enviar a mensajes cuando se sobrepasen ciertos umbrales, produciendo en el sistema de iluminaci on un encendido o apagado gradual. En una vivienda se traducir a en una programaci on de ciertas luces, por ejemplo del jard n, que se ir an encendiendo gradualmente conforme se hace de noche y, por el contrario, se ir an apagando gradualmente cuando se haga de d a.
Figura 16: Sensor crepuscular Para ello, el c odigo va evaluando los niveles de luz que recibe y si se supera alguno y el nivel de luminosidad no es el adecuado, se enviar a un mensaje al actuador para que regule la luz. S olo ocurrir a en ese caso, as evitaremos un mayor consumo de potencia con el env o de mensajes innecesarios. En nuestro caso, dividimos los valores en diez tipos (0-7) y diez grados de iluminaci on (0255 para nuestros leds) de tal forma que, cuando el valor recibido sea m aximo, la intensidad que enviaremos en el mensaje al actuador sea m nima.
158
Valor 7 7 6 5 4 3 2 1 0
Intensidad 0 32 64 96 128 160 192 224 255
Tabla III.1: Valores e intensidades de luz
1 2 3 4 5 6 7 8 9 10 11 12 13
command result_t IntOutput . output ( uint16_t value ) { if ( value == 5) { if ( intensidad != 96) { // ENV I O DE MENSAJE // message - > datos = R EGULACION_ABSOLUTA ; message - > length = 0 x02 ; message - > valor = 96; } C odigo 2.22: Aplicaci on crepuscular Como vemos en esta parte del c odigo, si el valor medido no corresponde con la intensidad que debe haber en las luces, se enviar a un mensaje de regulaci on absoluta. En este caso, hemos destacado los campos m as importantes: el campo de datos donde indicamos que es un mensaje de regulaci on absoluta, el campo de longitud con la correspondiente a este DPT, y el valor de intensidad que marcar a la luminosidad de las luces. En otros casos, por ejemplo un termostato, conguraremos el sensor de tal forma que cuando se sobrepase un umbral se env e un mensaje determinado para encender la calefacci on, el aire acondicionado o lo que queramos controlar.
159
IV.
Ejemplo de aplicaci on: Vivienda con conguraci on est atica
Uno de los objetivos nales de esta uni on entre las redes de sensores y la dom otica, 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 llevar an impl citos las funciones de sensor o actuador, dependiendo de d onde se encuentren situados y de c omo se quieran congurar.
Figura 17: Vivienda con motes distribuidos En este ejemplo el mote del balc on o el de la buhardilla podr an tener conguradas funciones de sensor crepuscular y pulsadores de persianas, el mote de la puerta principal podr a llevar funciones centrales de apagado de luces y bajada de persianas de toda la casa cuando nos marchamos, y el mote central podr a 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 sal on como en la gura de la p agina siguiente, con varios motes congurados como pulsadores, otros como actuadores y uno como sensor, podr amos establecer las siguientes relaciones, tal y como trabaja el sistema EIB: Sensores S1 Luz P1 O P2 Toggle P3 Toggle P4 Pers Up P5 Pers Down P6 Luz Up P7 Luz Down @Grupo 1/1/1 1/1/2 1/1/3 1/1/4 1/1/5 1/1/6 1/1/7 1/1/8 Actuadores AL1 AL2 AP1 @Grupo 1/1/1, 1/1/2, 1/1/3 1/1/1, 1/1/2, 1/1/4, 1/1/7, 1/1/8 1/1/2, 1/1/5, 1/1/6
Tabla III.2: Tabla conguraci on de motes
160
IV Ejemplo de aplicaci on: Vivienda con conguraci on est atica
Si nos jamos en la tabla anterior y en el gr aco podemos ver que el sensor S1 controlar a los actuadores de luces de los dos pisos (AL1 y AL2), encendi endolas 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 funci on central de apagar todas las luces y bajar las persianas del actuador AP1, mediante la direcci on de grupo 1/1/2. La persiana del piso de arriba es controlada tambi en mediante los pulsadores P4 y P5, que est an vinculados al actuador AP1. Y, por u ltimo, las luces de abajo tienen dos pulsadores de regulaci on, que son P6 y P7.
Figura 18: Estancia con motes congurados Este es un simple ejemplo de las m ultiples aplicaciones y conguraciones distintas que permiten este tipo de redes en viviendas domotizadas. Por ahora s olo hemos desarrollado unas pocas aplicaciones, que m as adelante ir an aumentando en prestaciones, abilidad y versatilidad, lo que dar a un gran benecio al mundo de las viviendas y edicios inteligentes.
161
V.
Conguraci on de los puertos de expansi on de TelosB
En este apartado describiremos la parte f sica del proyecto, que ha consistido en aprovechar los puertos de expansi on de que dispone el mote para a nadirle nuevos botones o leds, de tal forma que las prestaciones del dispositivo aumentaran. En esta gura podemos ver c omo la placa dispone de dos unidades de expansi on:
Figura 19: Detalle de componentes TelosB Los conectores de expansi on tienen 10 y 6 pines respectivamente, entre los cuales se encuentran los pines GIO (General Input Output ) que conguraremos como entradas para posibles pulsadores o salidas para posibles leds. Primero realizaremos la conguraci on hardware para soldar y cablear correctamente los puertos de expansi on a las placas que dise nemos con los botones o leds. Una vez montada lo que es la parte f sica de la placa y sus conexiones al mote, conguraremos este para que las se nales de expansi on est en determinadas como entradas o salidas y no haya problemas ni ambig uedades entre ellas, porque, como veremos, algunos puertos comparten distintas se nales.
162
V Conguraci on de los puertos de expansi on de TelosB
V.1.
Conguraci 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 expansi on. Lo resumimos en la siguiente tabla: Se nal GIO0 GIO1 GIO2 GIO3 Puerto MSP430 20 21 23 26 Puerto U2 10 7 Puerto U28
3 4
Tabla III.3: Correspondencia de se nales y puertos Tal y como puede verse en el esquem atico:
Figura 20: Conectores de expansi on TelosB
Lo importante de esta parte es que para habilitar las entradas GIO0 y GIO1 es necesario puentear las resistencias R14 y R16 que, por defecto, est an en circuito abierto. De esta forma ya podremos generar interrupciones externas conectadas a estos pines. Si no, las entradas activadas ser an ADC2 y ADC3. Con GIO2 y GIO3 no encontramos este problema. Por otra parte, para a nadir botones o leds a nuestro mote, realizamos el montaje de unas placas que dispusieran de cuatro pulsadores o leds, siguiendo el mismo esquem atico de los botones existentes en el mote o el de los propios leds:
Figura 21: Esquem atico para botones y leds
163
V.2.
Programaci on de los puertos
Para programar con las nuevas se nales de expansi on, lo primero que se debe hacer es congurar dichas se nales como entradas o salidas, dependiendo de lo que sean: para leds ser an salidas y para pulsadores las tomaremos como entradas. El chero a congurar ser a hardware.h que encontraremos en la plataforma de telosb, en /tinyos-1.x/tos/platform/telosb/hardware.h. , que trataremos de no cambiar su conguraci on lo menos posible y realizar la programaci on pertinente en nuestro c odigo. Lo primero que hay que hacer es realizar la asignaci on de pines. Si se observa el chero detenidamente se puede comprobar c omo los pines ya est an asignados y asociados a sus nombres GIO con las sentencias. As los mantendremos para la programaci on de botones: //GIO pins TOSH ASSIGN TOSH ASSIGN TOSH ASSIGN TOSH ASSIGN
PIN(GIO0, PIN(GIO1, PIN(GIO2, PIN(GIO3,
2, 2, 2, 2,
0); 1); 3); 6);
De todas formas, podemos cambiar dichas asignaciones e introducir los nombres que nos parezcan apropiados. Una vez hechas las asignaciones, debemos congurar la direcci on de los pines. Podemos hacerlo de dos formas, cambiando las direcciones de los pines en este mismo chero, o en nuetra propia aplicaci on. En nuestra aplicaci on deniremos 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 c odigo, pero debemos llevar cuidado de que no haya algunos puertos denidos como entrada y salida, o que puedan inuir.
Programaci on para botones adicionales Para programar las aplicaciones de botones pulsadores hemos dejado las asingaciones de los GIO tal y como ven an por defecto, y utilizaremos los nombres que vienen dados. Para establecer la direcci on de los pines hemos incluido en nuestro c odigo, en el m etodo init(), las sentencias: TOSH TOSH TOSH TOSH MAKE MAKE MAKE MAKE GIO0 GIO1 GIO2 GIO3 INPUT(); INPUT(); INPUT(); INPUT();
Donde se conguran los pines como entradas. El problema que surge ahora es el hecho de que algunos pines GIO comparten entrada con algunas se nales ADC (v ease el ap endice con el esquem atico 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 Proyecto Final de Carrera 164
tambi en como entradas los puertos ADC que comparten se nal con los pines de nuestro inter es. De esta forma no habr a problemas, por tanto, a nadiremos en nuestro c odigo: TOSH MAKE ADC2 INPUT(); TOSH MAKE ADC3 INPUT();
Programaci on para leds adicionales Este caso es diferente al de los botones, puesto que adem as de asignar pines y direcciones, los leds van a estar comandados por una serie de funciones que los encender an y apagar an, y cuyas funciones implementa el componente LedsC. Este componente tiene denidas sus funciones con los nombres que tienen asignados los leds por defecto: RED LED, GREEN LED y YELLOW LED (que, adem as, son s olo tres y no cuatro, como los que podr amos a nadir). Hay dos posibles formas de hacerlo: 1. Creando un nuevo componente en el que se conguraran funciones similares a las de LedsC pero con los nuevos nombres que asign aramos a los pines de los GIO. 2. Aprovechar las funciones ya creadas y cambiar los pines asignados en el chero hardware.h. Hemos programado nuestros motes siguiendo esta u ltima opci on, aprovechando el c odigo ya existente, pero realizando la asignaci on: //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 est an congurados como salidas, por lo que no habr a que asignarles direcciones en nuestro c odigo, pero s a los ADC que intereren. De nuevo, habr a que congurarlos como entradas, para que no se solape una salida con nuestras salidas: TOSH MAKE ADC2 INPUT(); TOSH MAKE ADC3 INPUT(); Si queremos congurar la cuarta entrada para un led m as, entonces deberemos crear una nueva asignaci on en hardware.h : TOSH ASSIGN PIN(LED CUATRO, 2, 6); Y, por supuesto, tendremos que congurar las funciones del c odigo LedsC para que se encienda y apague el nuevo led.
165
Existe otro m etodo de asignar las direcciones de pines, modicando el chero hardware.h. En el, encontraremos el m etodo void TOSH SET PIN DIRECTIONS que mediante unas sentencias en las que asigna un n umero hexadecimal, se establecen como entrada o como salida los pines. El par ametro PxDIR es el que realiza esta funci on, 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 conguraci on ser a: P2DIR 0X7b 27 0 26 1 25 1 24 1 23 1 22 0 21 1 20 1
Tabla III.4: Conguraci on 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 congurar nuestros pines GIO como salidas, deber an estar a 1 los puertos 20, 21, 23 y 26, y para congurarlos como entradas deber an estar a 0. El par ametro P2OUT es el valor inicial en la salida, y que, por defecto, estar a a 0 en los pines que nos ata nen. El problema de la compartici on de se nales con algunas se nales ADC, que corresponden a pines de P6DIR, lo solucionaremos declarando los pines P6DIR=0x00 (como entradas) y cuando sean salidas, los declararemos tambi en como entradas P6DIR=0x00 para que no interera en la salida que estamos generando. Finalmente, en nuestros c odigos podremos conocer el estado de cada uno de estas se nales, mediante los m etodos o macros que se proporcionan, como por ejemplo: valorBoton2 = TOSH READ BOTON DOS PIN(); Habiendo predenido asignado previamente las se nales a los nombres como BOTON DOS, podremos controlar y leer esas se nales. Conguraci on bot on sin expansi on En las c odigos de las aplicaciones en las que no hay botones ni leds adicionales no deber a modicarse el c odigo de hardware.h. Para el caso de la programaci on de actuadores (leds) no habr a ning un problema, pero en el caso de la programaci on de pulsadores (que utilizan el UserButton del mote) deberemos realizar una asignaci on en el c odigo de harware.h puesto que el bot on 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 c odigo compilar a y funcionar a correctamente en el mote.
166
El resultado nal, tras el montaje, soldaduras y acoplo de los motes a las placas puede verse en estas fotograf as.
Figura 22: TelosB con leds y botones
Figura 23: TelosB con expansiones
167
VI.
Perspectivas de futuro
El futuro de la dom otica va a estar muy ligado al mundo de las redes inal ambricas. Actualmente, los frentes de actuaci on est an centrados en asentar los est andares 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 tecnolog as existentes son muy heterog eneas, presentando soluciones cableadas, por corrientes portadoras o inal ambricas, aunque no muy desarrolladas. El principal problema de las soluciones cableadas es la necesidad de previsi on de su instalaci on en la fase de proyecto y construcci on del edicio, lo que limita su ambito de aplicaci on a viviendas de nueva construcci on. Para la implantaci on en viviendas ya construidas, el sistema m as extendido es el de corrientes portadoras pero tambi en presenta grandes inconvenientes de abilidad o funcionamiento. En cambio, las redes inal ambricas de sensores est an creciendo a un ritmo muy alto en cuanto a desarrollo, prestaciones y aplicaciones. Se espera que gracias a las WSAN se produzca una revoluci on en el mundo de la dom otica, permitiendo la introducci on de la dom otica avanzada en viviendas ya construidas, ampliando instalaciones existentes o proporcionando grandes avances en las prestaciones de confort, seguridad, ahorro energ etico, interoperatividad con otras redes, etc. Los prop ositos a solucionar para conseguir la integraci on de las redes inal ambricas y la dom otica son muchos. Por un lado, las carencias que vimos en las WSN y que se deben solucionar, como la falta de est andares, protocolos o arquitecturas que marquen el sistema o las limitaciones de los sensores que deber an ir mejorando con el desarrollo de la tecnolog a. En cuanto al caso concreto de las redes dom oticas, hay una serie de puntos que se deber an trabajar y mejorar para conseguir un buen sistema funcional y able. Interoperatividad con otras redes. La monitorizaci on y el acceso remoto es una de las funcionalidades b asicas de las redes dom oticas, ya que permite la comunicaci on de incidencias de seguridad en la instalaci on, as como algunas funciones de confort. La interoperatividad es necesaria para la conexi on con otras redes inal ambricas o cableadas del hogar, como otros sistemas dom oticos ya existentes, redes multimedia o de datos. Nodos m oviles. La determinaci on de la posici on de nodos m oviles, en los que se identicar a el perl del usuario que lo transporta es uno de los requerimientos para la creaci on de ambientes inteligentes. La localizaci on de ocupantes en una vivienda y su revisi on propone entornos inteligentes con predicci on de rutas de los usuarios para incrementar su confort y realizar usos ecientes de la energ a. Otro campo de inter es es la aplicaci on para viviendas con personas mayores, discapacitadas o con necesidades especiales. Alimentaci on de los nodos. Se debe satisfacer el requerimiento de un consumo energ etico muy bajo para aquellos nodos que deban funcionar con bater as, y las fuentes alternativas de alimentaci on aprovechando el entorno. Se est an estudiando t ecnicas piezoel ectricas mediante las cuales se pueda obtener energ a por procesos mec anicos; este tipo de alimentaci on es id onea para pulsadores o sensores que experimenten est mulos de tipo mec anico. Los sensores de temperatura se podr an alimentar por m etodos de diferencias t ermicas, los de luz con placas solares, etc. Proyecto Final de Carrera 168
VI Perspectivas de futuro
Seguridad. La seguridad es fundamental en estas aplicaciones por varios motivos. El primero es la naturaleza inal ambrica del medio, f acilmente 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 informaci on valiosa de los usuarios de una vivienda. Adem as, entre sus funciones se incluyen la de gesti on de la seguridad, lo que puede comprometer a un m as la integridad en caso de ataques externos y manipulaci on de nodos. Dise no y encapsulado de nodos. La mayor a de nodos se instalar an en interiores por lo que las condiciones ambientales no ser an extremas ni estar an en peligro por los usuarios. Se deber a tener en cuenta aspectos como el aislamiento el ectrico para nodos alojados en proximidades de instalaciones el ectricas y aspectos est eticos, puesto que estar an situados en viviendas o edicios en los que esta cuesti on puede ser importante. Conguraci on de los nodos. La conguraci on deber a 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. Adem as, con la introducci on de la computaci on ubicua, el tama no de las redes y la ubicaci on de los sensores hace necesario disponer tambi en de t ecnicas para recongurar el software de los nodos a trav es de la propia red.
La dom otica tender a, 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 m as sociol ogico, conjuntos de personas interconectadas, quienes, junto con sus ordenadores y otros aparatos, comprar an, vender an e intercambiar an informaci on y servicios, todo dentro del entorno de la vivienda. La creaci on de estos entornos inteligentes se dar a gracias a la expansi on de las redes inal ambricas de sensores, con nodos m oviles cuya posici on estar a determinada y gracias a la computaci on ubicua, creando de un hogar un centro neur algico de computaci on y comunicaci on, pero a la vez perfectamente integrado con los usuarios humanos. El Ambiente Inteligente no se limitar a a ning un lugar f sico determinado sino que comprender a todos ellos: la casa, el coche, el lugar de trabajo, etc. El Ambiente estar a donde nosotros estemos y responder a 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 constituir a como el Ambiente Inteligente por excelencia.
169
170
Conclusiones
Con este proyecto hemos realizado un estudio de dos sectores tecnol ogicos que a un est an en sus comienzos, poniendo nuestro granito de arena en una de las salidas con m as perspectivas de futuro para la dom otica, como son las redes inal ambricas de sensores. Despu es de analizar el estado actual de la automatizaci on de viviendas y edicios, hemos comprobado que desde hace algunos a nos se han puesto esperanzas en proyectos que no han dado los resultados previstos. La integraci on de la dom otica en la sociedad es una asignatura a un pendiente, puesto que est an apareciendo inconvenientes que est an retrasando esta implantaci on. Al igual que pas o con la telefon a m ovil, que experiment o una revoluci on y un auge casi inesperados, a la dom otica le est a faltando ese factor explosivo que permita integrarla en la vida cotidiana de cualquier persona, en cualquier casa y edicio. Ese factor ser an las redes inal ambricas de sensores y actuadores. El MIT considera que estas redes ser an una de las tecnolog as que cambiar an el mundo en los pr oximos a nos y, por supuesto, llevar an 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 tecnolog as emergentes se vayan asentando. Por una parte, la integraci on de tecnolog as inal ambricas en los est andares dom oticos, estableciendo nuevos frentes de actuaci on. Por otro lado, avanzar tecnol ogicamente e ir encontrando nuevas soluciones para las redes de sensores inal ambricas, desarrollando aplicaciones con m as prestaciones, nuevos sensores exclusivos para dom otica, ampliaci on de topolog as para redes m oviles, etc. Muchas aplicaciones para redes de sensores se est an realizando en diversos campos, y el de la dom otica es uno que est a pendiente por desarrollar. Estudios como este proyecto con la programaci on de sensores de acuerdo a un est andar dom otico, la creaci on de nuevas aplicaciones para viviendas o la programaci on de aplicaciones con interfaces gr acas que permitan la conguraci on de sensores de una red WSAN son distintos frentes en los que habr a que ir trabajando para conseguir que estas nuevas tecnolog as sean una realidad.
171
Conclusiones
172
Ap endice A
C odigo fuente - Iluminaci on

A.1.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Nodos pulsadores Iluminaci on
El c odigo de conguraci on es com un a todos los nodos. includes EIBMsg ; configuration eib { } implementation { components Main , eibM , GenericComm , LedsIntensityC , TimerC ; Main . StdControl -> eibM ; Main . StdControl -> LedsIntensityC ; eibM . Send -> GenericComm . SendMsg [ AM_EIBMSG ]; eibM . ReceiveEIBMsg -> GenericComm . ReceiveMsg [ AM_EIBMSG ]; eibM . CommControl -> GenericComm ; eibM . LedsIntensity -> LedsIntensityC ; eibM . TimerMilli -> TimerC . TimerMilli [ unique (" TimerMilli ") ]; } C odigo A.1: eib.nc
173
Ap endice A. C odigo fuente
eibM.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
includes EIBMsg ; module eibM { provides { interface StdControl ; interface ProcessCmd ; } uses { interface ReceiveMsg as ReceiveEIBMsg ; interface StdControl as CommControl ; interface SendMsg as Send ; interface TimerMilli ; interface LedsIntensity ; } } implementation { TOS_MsgPtr m ; int8_t bcast_pending ; TOS_Msg buf ; int8_t pending2 ; int8_t lastSeqno ; bool pending1 ; TOS_Msg data ; bool retransmite ; int16_t valorBoton ; int16_t tpulsado ; int16_t tfrontera ; bool enviadaLarga ; int8_t funcionCorta ; int8_t funcionLarga ; int8_t valorAbs ; /********************************************/
task void cmdInterpret () { signal ProcessCmd . done (m , SUCCESS ) ; }
task void forwarder () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > seqno = lastSeqno ; message - > dfisica = 0 xBB ; if ( retransmite ) { call Send . send ( TOS_BCAST_ADDR , 8 , m ) ; Proyecto Final de Carrera 174
Ap endice A. Aplicaciones de Iluminaci on
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
} else { pending1 = FALSE ; bcast_pending = 0; } } task void e n v i a r P u l s a c i o n C orta () { EIBMsg * message = ( EIBMsg *) data . data ; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; message - > length = 0 x01 ; switch ( funcionCorta ) { case 1: message - > datos = ESCRIBIR_ON ; break ; case 2: message - > datos = ESCRIBIR_OFF ; break ; case 3: message - > datos = ESCRIBIR_TOGGLE ; break ; case 4: message - > length = 0 x02 ; message - > datos = REGULACION_ABSOLUTA ; break ; } switch ( valorAbs ) { case 1: message - > valor = VALOR_10 ; case 2: message - > valor = VALOR_20 ; case 3: message - > valor = VALOR_30 ; case 4: message - > valor = VALOR_40 ; case 5: message - > valor = VALOR_50 ; case 6: message - > valor = VALOR_60 ; case 7: message - > valor = VALOR_70 ; case 8: message - > valor = VALOR_80 ; case 9: message - > valor = VALOR_90 ; } message - > seqno = lastSeqno ; Proyecto Final de Carrera
break ; break ; break ; break ; break ; break ; break ; break ; break ;
175
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_1 ; message - > dgrupo = DIRE_GRUPO_1_1_1 ; message - > hop_count = 0 x00 ; message - > seguridad = 255; } call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ; pending1 = FALSE ; } } task void e n v i a r P u l s a c i o n Larga () { EIBMsg * message = ( EIBMsg *) data . data ; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; switch ( funcionLarga ) { case 1: message - > datos = REGULAR_LUZ ; break ; case 2: message - > datos = REGULAR_OSCURIDAD ; break ; } message - > seqno = lastSeqno ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_1 ; message - > dgrupo = DIRE_GRUPO_1_1_3 ; message - > hop_count = 0 x00 ; message - > length = 0 x01 ; message - > seguridad = 255; } call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ; pending1 = FALSE ; } } task void enviarSTOPlarga () { EIBMsg * message = ( EIBMsg *) data . data ; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; message - > datos = REGULAR_STOP ; message - > seqno = lastSeqno ; Proyecto Final de Carrera 176
150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199
atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_1 ; message - > dgrupo = DIRE_GRUPO_1_1_3 ; message - > hop_count = 0 x00 ; message - > length = 0 x01 ; message - > seguridad = 255; } call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ; pending1 = FALSE ; } } command result_t StdControl . init () { m = & buf ; bcast_pending = 0; pending2 = 0; lastSeqno = 0; pending1 = FALSE ; retransmite = FALSE ; tpulsado = 0; tfrontera = 1500; enviadaLarga = FALSE ;
funcionCorta = 3; funcionLarga = 1; valorAbs = 5; return call CommControl . init () ; } command result_t StdControl . start () { call TimerMilli . setPeriodic ( 100 ) ; return call CommControl . start () ; } command result_t StdControl . stop () { call TimerMilli . stop () ; return call CommControl . stop () ; } inline char is_new_msg ( struct EIBMsg * bmsg ) { if ( bcast_pending ) return 0; return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) < lastSeqno ) ) ; } inline void remember_msg ( struct EIBMsg * bmsg ) { lastSeqno = bmsg - > seqno ; Proyecto Final de Carrera 177
200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249
bcast_pending = 1; } event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) { TOS_MsgPtr ret = m ; result_t retval ; struct EIBMsg * datos = ( struct EIBMsg *) m - > data ; if ( is_new_msg ( datos ) ) { remember_msg ( datos ) ; retval = call ProcessCmd . execute ( pmsg ) ; ret = m ; m = pmsg ; } return ret ; } command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) { pending2 =1; m = pmsg ; post cmdInterpret () ; return SUCCESS ; } event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status ) { if ( pending1 && msg == & data ) { pending1 = FALSE ; } if ( status == SUCCESS ) bcast_pending = 0; return SUCCESS ; } default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg , result_t status ) { m = pmsg ; if ( status ) { post forwarder () ; } else { bcast_pending = 0; } return SUCCESS ; } event result_t TimerMilli . fired () { valorBoton = T O S H_ READ_BOTON_PIN () ; if ( valorBoton == 0 x0000 ) { tpulsado = tpulsado + 100; Proyecto Final de Carrera 178
250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269
if (( tpulsado > tfrontera ) && ! enviadaLarga ) { post enviarPulsacionLarga () ; enviadaLarga = TRUE ; } } else { if (( tpulsado < tfrontera ) && ( tpulsado != 0) ) { post e n v i a rPulsacionCorta () ; tpulsado = 0; } else { if ( enviadaLarga ) { post enviarSTOPlarga () ; } tpulsado = 0; enviadaLarga = FALSE ; } } return SUCCESS ; } } C odigo A.2: Nodo pulsador de iluminaci on eibM.nc
179
A.2.
Nodos actuadores Iluminaci on
eibM.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
includes EIBMsg ; module eibM { provides { interface StdControl ; interface ProcessCmd ; } uses { interface ReceiveMsg as ReceiveEIBMsg ; interface StdControl as CommControl ; interface SendMsg as Send ; interface TimerMilli ; interface LedsIntensity ; } } implementation { TOS_MsgPtr m ; int8_t bcast_pending ; TOS_Msg buf ; int8_t pending2 ; int8_t lastSeqno ; bool pending1 ; TOS_Msg data ; bool retransmite ; bool regular_luz ; bool regular_sombra ; int16_t intensidad ; int16_t factor ; bool valorLuz ; bool estadozero ; int16_t valorRecibido ; task void cmdInterpret () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > hop_count ++; switch ( message - > dgrupo ) { case DIRE_GRUPO_1_1_1 : if ( message - > datos == ESCRIBIR_ON ) { call LedsIntensity . set ( 0 x00 , 255 ) ; } if ( message - > datos == ESCRIBIR_OFF ) { call LedsIntensity . set ( 0 x00 , 0 ) ; } Proyecto Final de Carrera 180
49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
if ( message - > datos == ESCRIBIR_TOGGLE ) { if (! valorLuz ) { call LedsIntensity . set ( 0 x00 , 255 ) ; valorLuz = TRUE ; intensidad = 255; } else { call LedsIntensity . set ( 0 x00 , 0 ) ; valorLuz = FALSE ; intensidad = 0; } } if ( message - > datos == REGULACION_ABSOLUTA ) { valorRecibido = message - > valor ; call LedsIntensity . set ( 0 x00 , valorRecibido ) ; valorLuz = TRUE ; intensidad = valorRecibido ; } break ; case DIRE_GRUPO_1_1_3 : if ( message - > datos == REGULAR_LUZ ) { regular_luz = TRUE ; } if ( message - > datos == RE GULAR_OSCURIDAD ) { regular_sombra = TRUE ; } if ( message - > datos == REGULAR_STOP ) { regular_luz = FALSE ; regular_sombra = FALSE ; if (! estadozero ) { valorLuz = TRUE ; } else { valorLuz = FALSE ; estadozero = FALSE ; } } break ; } pending2 =0; signal ProcessCmd . done (m , SUCCESS ) ; }
task void forwarder () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > seqno = lastSeqno ; message - > dfisica = 0 xBB ; Proyecto Final de Carrera 181
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
if ( retransmite ) { call Send . send ( TOS_BCAST_ADDR , 8 , m ) ; } else { pending1 = FALSE ; bcast_pending = 0; } } command result_t StdControl . init () { m = & buf ; bcast_pending = 0; pending2 = 0; lastSeqno = 0; pending1 = FALSE ; retransmite = FALSE ; regular_luz = FALSE ; regular_sombra = FALSE ; intensidad = 0; factor = 15; valorLuz = FALSE ; estadozero = FALSE ; valorRecibido = 0; return call CommControl . init () ; } command result_t StdControl . start () { call TimerMilli . setPeriodic ( 100 ) ; return call CommControl . start () ; } command result_t StdControl . stop () { call TimerMilli . stop () ; return call CommControl . stop () ; } inline char is_new_msg ( struct EIBMsg * bmsg ) { if ( bcast_pending ) return 0; return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) < lastSeqno ) ) ; } inline void remember_msg ( struct EIBMsg * bmsg ) { lastSeqno = bmsg - > seqno ; bcast_pending = 1; } event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) { TOS_MsgPtr ret = m ; Proyecto Final de Carrera 182
150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199
result_t retval ; struct EIBMsg * datos = ( struct EIBMsg *) m - > data ; if ( is_new_msg ( datos ) ) { remember_msg ( datos ) ; retval = call ProcessCmd . execute ( pmsg ) ; ret = m ; m = pmsg ; } return ret ; } command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) { pending2 =1; m = pmsg ; post cmdInterpret () ; return SUCCESS ; } event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status ) { if ( pending1 && msg == & data ) { pending1 = FALSE ; } if ( status == SUCCESS ) bcast_pending = 0; return SUCCESS ; } default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg , result_t status ) { m = pmsg ; if ( status ) { post forwarder () ; } else { bcast_pending = 0; } return SUCCESS ; } event result_t TimerMilli . fired () { if ( regular_luz ) { if ( intensidad < 255) { intensidad = intensidad + factor ; call LedsIntensity . set ( 0 x00 , intensidad ) ; } else { call LedsIntensity . set ( 0 x00 , 255 ) ; valorLuz = TRUE ; } } Proyecto Final de Carrera 183
200 201 202 203 204 205 206 207 208 209 210 211 212
if ( regular_sombra ) { if ( intensidad > 0) { intensidad = intensidad - factor ; call LedsIntensity . set ( 0 x00 , intensidad ) ; } else { call LedsIntensity . set ( 0 x00 , 0 ) ; estadozero = TRUE ; } } return SUCCESS ; } } C odigo A.3: Nodo actuador de iluminaci on eibM.nc
184
Ap endice B
C odigo fuente - Persianas

B.1. Nodos pulsadores Persianas
eibM.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
includes EIBMsg ; module eibM { provides { interface StdControl ; interface ProcessCmd ; } uses { interface ReceiveMsg as ReceiveEIBMsg ; interface StdControl as CommControl ; interface SendMsg as Send ; interface TimerMilli ; interface LedsIntensity ; } } implementation { TOS_MsgPtr m ; int8_t bcast_pending ; TOS_Msg buf ; int8_t pending2 ; int8_t lastSeqno ; bool pending1 ; TOS_Msg data ; bool retransmite ;
int16_t valorBoton ; int16_t tpulsado ; int16_t tfrontera ; bool enviadaLarga ; int8_t funcionBoton ;
185
Ap endice B. C odigo fuente
35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
/*******************************/ task void cmdInterpret () { signal ProcessCmd . done (m , SUCCESS ) ; } task void forwarder () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > seqno = lastSeqno ; message - > dfisica = 0 xBB ; if ( retransmite ) { call Send . send ( TOS_BCAST_ADDR , 8 , m ) ; } else { pending1 = FALSE ; bcast_pending = 0; } } task void e n v i a r P u l s a c i o n C orta () { EIBMsg * message = ( EIBMsg *) data . data ; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; switch ( funcionBoton ) { case 1: message - > datos = ESCRIBIR_ON ; break ; case 2: message - > datos = ESCRIBIR_OFF ; break ; } message - > seqno = lastSeqno ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_1 ; message - > dgrupo = DIRE_GRUPO_1_1_1 ; message - > hop_count = 0 x00 ; message - > seguridad = 255; } call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ; pending1 = FALSE ; } }
186
Ap endice B. Aplicaciones de Persianas
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134
task void e n v i a r P u l s a c i o n Larga () { EIBMsg * message = ( EIBMsg *) data . data ; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; switch ( funcionBoton ) { case 1: message - > datos = ESCRIBIR_ON ; break ; case 2: message - > datos = ESCRIBIR_OFF ; break ; } message - > seqno = lastSeqno ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_1 ; message - > dgrupo = DIRE_GRUPO_1_1_5 ; message - > hop_count = 0 x00 ; message - > length = 0 x01 ; message - > seguridad = 255; } call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ; // Env o pending1 = FALSE ; } } command result_t StdControl . init () { m = & buf ; bcast_pending = 0; pending2 = 0; lastSeqno = 0; pending1 = FALSE ; retransmite = FALSE ; tpulsado = 0; tfrontera = 1500; enviadaLarga = FALSE ; funcionBoton = 2; return call CommControl . init () ; }
187
135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184
command result_t StdControl . start () { call TimerMilli . setPeriodic ( 100 ) ; return call CommControl . start () ; } command result_t StdControl . stop () { call TimerMilli . stop () ; return call CommControl . stop () ; } inline char is_new_msg ( struct EIBMsg * bmsg ) { if ( bcast_pending ) return 0; return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) < lastSeqno ) ) ; } inline void remember_msg ( struct EIBMsg * bmsg ) { lastSeqno = bmsg - > seqno ; bcast_pending = 1; } event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) { TOS_MsgPtr ret = m ; result_t retval ; struct EIBMsg * datos = ( struct EIBMsg *) m - > data ; if ( is_new_msg ( datos ) ) { remember_msg ( datos ) ; retval = call ProcessCmd . execute ( pmsg ) ; ret = m ; m = pmsg ; } return ret ; } command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) { pending2 =1; m = pmsg ; post cmdInterpret () ; return SUCCESS ; } event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status ) { if ( pending1 && msg == & data ) { pending1 = FALSE ; } if ( status == SUCCESS ) bcast_pending = 0; return SUCCESS ; } Proyecto Final de Carrera 188
185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221
default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg , result_t status ) { m = pmsg ; if ( status ) { post forwarder () ; } else { bcast_pending = 0; } return SUCCESS ; } event result_t TimerMilli . fired () { valorBoton = T O S H_ READ_BOTON_PIN () ; if ( valorBoton == 0 x0000 ) { tpulsado = tpulsado + 100; if (( tpulsado > tfrontera ) && ! enviadaLarga ) { post enviarPulsacionLarga () ; enviadaLarga = TRUE ; } } else { if (( tpulsado < tfrontera ) && ( tpulsado != 0) ) { post e n v i a rPulsacionCorta () ; tpulsado = 0; } else { if ( enviadaLarga ) { post enviarSTOPlarga () ; } tpulsado = 0; enviadaLarga = FALSE ; } } return SUCCESS ; } } C odigo B.1: Nodo pulsador de persianas eibM.nc
189
B.2.
Nodos actuadores Persianas
eibM.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
includes EIBMsg ; module eibM { provides { interface StdControl ; interface ProcessCmd ; } uses { interface ReceiveMsg as ReceiveEIBMsg ; interface StdControl as CommControl ; interface SendMsg as Send ; interface TimerMilli ; interface LedsIntensity ; } } implementation { TOS_MsgPtr m ; int8_t bcast_pending ; TOS_Msg buf ; int8_t pending2 ; int8_t lastSeqno ; bool pending1 ; TOS_Msg data ; bool retransmite ; bool bool bool bool paso_subir ; paso_bajar ; total_subir ; total_bajar ;
int16_t tcounter ; int16_t tpaso ; int16_t ttotal ; int16_t twait ; bool wait ; task void cmdInterpret () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > hop_count ++; switch ( message - > dgrupo ) { case DIRE_GRUPO_1_1_4 : if ( message - > datos == ESCRIBIR_ON ) { if ( total_subir || total_bajar ) { Proyecto Final de Carrera 190
49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
total_subir = FALSE ; total_bajar = FALSE ; call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 0 ) ; } else { paso_subir = TRUE ; paso_bajar = FALSE ; tcounter = 0; } } if ( message - > datos == ESCRIBIR_OFF ) { if ( total_bajar || total_subir ) { total_subir = FALSE ; total_bajar = FALSE ; call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 0 ) ; } else { paso_subir = FALSE ; paso_bajar = TRUE ; tcounter = 0; } } break ; case DIRE_GRUPO_1_1_5 : if ( message - > datos == ESCRIBIR_ON ) { total_subir = TRUE ; if ( total_bajar ) { wait = TRUE ;} total_bajar = FALSE ; tcounter = 0; call LedsIntensity . set ( 0 x01 , 0 ) ; } if ( message - > datos == ESCRIBIR_OFF ) { total_bajar = TRUE ; if ( total_subir ) { wait = TRUE ;} total_subir = FALSE ; tcounter = 0; call LedsIntensity . set ( 0 x00 , 0 ) ; } break ; } pending2 =0; signal ProcessCmd . done (m , SUCCESS ) ; } task void forwarder () { Proyecto Final de Carrera 191
100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > seqno = lastSeqno ; message - > dfisica = 0 xBB ; if ( retransmite ) { call Send . send ( TOS_BCAST_ADDR , 8 , m ) ; } else { pending1 = FALSE ; bcast_pending = 0; } } command result_t StdControl . init () { m = & buf ; bcast_pending = 0; pending2 = 0; lastSeqno = 0; pending1 = FALSE ; retransmite = FALSE ; paso_subir = FALSE ; paso_bajar = FALSE ; total_subir = FALSE ; total_bajar = FALSE ; tcounter =0; tpaso = 1000; ttotal = 5000; twait = 1000; wait = FALSE ; return call CommControl . init () ; } command result_t StdControl . start () { call TimerMilli . setPeriodic ( 100 ) ; return call CommControl . start () ; } command result_t StdControl . stop () { call TimerMilli . stop () ; return call CommControl . stop () ; } inline char is_new_msg ( struct EIBMsg * bmsg ) { if ( bcast_pending ) return 0; return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) < lastSeqno ) ) ; } inline void remember_msg ( struct EIBMsg * bmsg ) { Proyecto Final de Carrera 192
150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199
lastSeqno = bmsg - > seqno ; bcast_pending = 1; } event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) { TOS_MsgPtr ret = m ; result_t retval ; struct EIBMsg * datos = ( struct EIBMsg *) m - > data ; if ( is_new_msg ( datos ) ) { remember_msg ( datos ) ; retval = call ProcessCmd . execute ( pmsg ) ; ret = m ; m = pmsg ; } return ret ; } command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) { pending2 =1; m = pmsg ; post cmdInterpret () ; return SUCCESS ; } event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status ) { if ( pending1 && msg == & data ) { pending1 = FALSE ; } if ( status == SUCCESS ) bcast_pending = 0; return SUCCESS ; } default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg , result_t status ) { m = pmsg ; if ( status ) { post forwarder () ; } else { bcast_pending = 0; } return SUCCESS ; }
event result_t TimerMilli . fired () { if ( paso_subir ) { tcounter = tcounter + 100; Proyecto Final de Carrera 193
200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250
call LedsIntensity . set ( 0 x00 , 255 ) ; if ( tcounter > tpaso ) { call LedsIntensity . set ( 0 x00 , 0 ) ; paso_subir = FALSE ; tcounter = 0; } } if ( paso_bajar ) { tcounter = tcounter + 100; call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 255 ) ; if ( tcounter > tpaso ) { call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 0 ) ; paso_bajar = FALSE ; tcounter = 0; } } if ( total_subir ) { tcounter = tcounter + 100; if ( wait ) { if ( tcounter > twait ) { call LedsIntensity . set ( 0 x00 , 255 ) ; if ( tcounter > ttotal ) { call LedsIntensity . set ( 0 x00 , 0 ) ; total_subir = FALSE ; tcounter = 0; wait = FALSE ; } }} else { call LedsIntensity . set ( 0 x00 , 255 ) ; if ( tcounter > ttotal ) { call LedsIntensity . set ( 0 x00 , 0 ) ; total_subir = FALSE ; tcounter = 0; } } } if ( total_bajar ) { tcounter = tcounter + 100; if ( wait ) { if ( tcounter > twait ) { call LedsIntensity . set ( 0 x00 , 0 ) ; Proyecto Final de Carrera 194
251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273
call LedsIntensity . set ( 0 x01 , 255 ) ; if ( tcounter > ttotal ) { call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 0 ) ; total_bajar = FALSE ; tcounter = 0; wait = FALSE ; } } } else { call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 255 ) ; if ( tcounter > ttotal ) { call LedsIntensity . set ( 0 x00 , 0 ) ; call LedsIntensity . set ( 0 x01 , 0 ) ; total_bajar = FALSE ; tcounter = 0; }} } return SUCCESS ; } } C odigo B.2: Nodo actuador de persianas eibM.nc
195
Ap endice C. C odigo fuente
196
Ap endice C
C odigo fuente - Sensores

C.1. Nodo Sensor Crepuscular
Los c odigos de conguraci on Sense.nc y eib.nc son comunes a todos los nodos. Sense.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
configuration Sense { } implementation { components Main , SenseM , LedsC , TimerC , DemoSensor2C as Sensor , eib ; Main . StdControl Main . StdControl Main . StdControl Main . StdControl -> -> -> -> Sensor ; TimerC ; SenseM ; eib ;
SenseM . ADC -> Sensor ; SenseM . ADCControl -> Sensor ; SenseM . Leds -> LedsC ; SenseM . Timer -> TimerC . Timer [ unique (" Timer ") ]; SenseM . IntOutput -> eib . IntOutput ; } C odigo C.1: Sense.nc
197
eib.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
includes EIBMsg ; configuration eib { provides interface StdControl ; provides interface ProcessCmd ; provides interface IntOutput ; } implementation { components eibM , GenericComm , LedsC ; IntOutput = eibM ; StdControl = eibM ; ProcessCmd = eibM . ProcessCmd ; eibM . ReceiveEIBMsg -> GenericComm . ReceiveMsg [ AM_EIBMSG ]; eibM . CommControl -> GenericComm ; eibM . Leds -> LedsC . Leds ; eibM . Send -> GenericComm . SendMsg [ AM_EIBMSG ]; } C odigo C.2: eib.nc
198
Ap endice C. Aplicaciones de Sensores
SenseM.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
module SenseM { provides { interface StdControl ; } uses { interface Timer ; interface ADC ; interface StdControl as ADCControl ; interface Leds ; interface IntOutput ; } } implementation { result_t display ( uint16_t value ) { if ( value &1) call Leds . yellowOn () ; else call Leds . yellowOff () ; if ( value &2) call Leds . greenOn () ; else call Leds . greenOff () ; if ( value &4) call Leds . redOn () ; else call Leds . redOff () ; return SUCCESS ; } command result_t StdControl . init () { return call Leds . init () ; } command result_t StdControl . start () { return call Timer . start ( TIMER_REPEAT , 2000) ; } command result_t StdControl . stop () { return call Timer . stop () ; } event result_t Timer . fired () { return call ADC . getData () ; } async event result_t ADC . dataReady ( uint16_t data ) { display (7 -(( data > >7) &0 x7 ) ) ; call IntOutput . output (( data > >7) &0 xf ) ; return SUCCESS ; } event result_t IntOutput . outputComplete ( result_t success ) { return SUCCESS ; }} C odigo C.3: SenseM.nc Proyecto Final de Carrera 199
eibM.nc
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
includes EIBMsg ; module eibM { provides { interface IntOutput ; interface StdControl ; interface ProcessCmd ; } uses { interface ReceiveMsg as ReceiveEIBMsg ; interface StdControl as CommControl ; interface Leds ; interface SendMsg as Send ; } } implementation { TOS_MsgPtr m ; int8_t bcast_pending ; TOS_Msg buf ; int8_t pending2 ; int8_t lastSeqno ; bool pending1 ; TOS_Msg data ; bool retransmite ; int16_t intensidad ;
task void cmdInterpret () { signal ProcessCmd . done (m , SUCCESS ) ; } task void forwarder () { struct EIBMsg * message = ( struct EIBMsg *) m - > data ; message - > seqno = lastSeqno ; message - > dfisica = 0 xBB ; if ( retransmite ) { call Send . send ( TOS_BCAST_ADDR , 8 , m ) ; } else { pending1 = FALSE ; bcast_pending = 0; } } command result_t StdControl . init () { m = & buf ; bcast_pending = 0; pending2 = 0; lastSeqno = 0; Proyecto Final de Carrera 200
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
pending1 = FALSE ; retransmite = FALSE ; intensidad = 0; return call CommControl . init () ; } command result_t StdControl . start () { return call CommControl . start () ; } command result_t StdControl . stop () { return call CommControl . stop () ; } inline char is_new_msg ( struct EIBMsg * bmsg ) { if ( bcast_pending ) return 0; return ((( bmsg - > seqno - lastSeqno ) >0) || (( bmsg - > seqno +127) < lastSeqno ) ) ; } inline void remember_msg ( struct EIBMsg * bmsg ) { lastSeqno = bmsg - > seqno ; bcast_pending = 1; } event TOS_MsgPtr ReceiveEIBMsg . receive ( TOS_MsgPtr pmsg ) { TOS_MsgPtr ret = m ; result_t retval ; struct EIBMsg * datos = ( struct EIBMsg *) m - > data ; if ( is_new_msg ( datos ) ) { remember_msg ( datos ) ; retval = call ProcessCmd . execute ( pmsg ) ; ret = m ; m = pmsg ; } return ret ; } command result_t ProcessCmd . execute ( TOS_MsgPtr pmsg ) { pending2 =1; m = pmsg ; post cmdInterpret () ; return SUCCESS ; } command result_t IntOutput . output ( uint16_t value ) { if ( value > 7) { if ( intensidad != 0) { Proyecto Final de Carrera 201
101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
EIBMsg * message = ( EIBMsg *) data . data ; intensidad = 0; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; message - > datos = R EGULACION_ABSOLUTA ; message - > valor = 0; message - > seqno = lastSeqno ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_2 ; message - > dgrupo = DIRE_GRUPO_1_1_1 ; message - > hop_count = 0 x00 ; message - > length = 0 x02 ; message - > seguridad = 255; } if ( call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ) return SUCCESS ; pending1 = FALSE ; } } } else if ( value == 7 ) { if ( intensidad != 32) { EIBMsg * message = ( EIBMsg *) data . data ; intensidad = 32; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; message - > datos = R EGULACION_ABSOLUTA ; message - > valor = 32; message - > seqno = lastSeqno ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_2 ; message - > dgrupo = DIRE_GRUPO_1_1_1 ; message - > hop_count = 0 x00 ; message - > length = 0 x02 ; message - > seguridad = 255; } if ( call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ) return SUCCESS ; pending1 = FALSE ; } } } [...] Proyecto Final de Carrera 202
150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
else if ( value == 0 ) { if ( intensidad != 255) { EIBMsg * message = ( EIBMsg *) data . data ; intensidad = 255; if (! pending1 ) { pending1 = TRUE ; lastSeqno = lastSeqno + 1; message - > datos = R EGULACION_ABSOLUTA ; message - > valor = 255; message - > seqno = lastSeqno ; atomic { message - > control = 0 xBC ; message - > dfisica = DIRE_FISICA_1_1_2 ; message - > dgrupo = DIRE_GRUPO_1_1_1 ; message - > hop_count = 0 x00 ; message - > length = 0 x02 ; message - > seguridad = 255; } if ( call Send . send ( TOS_BCAST_ADDR , sizeof ( EIBMsg ) , & data ) ) return SUCCESS ; pending1 = FALSE ; } } } return FAIL ; }
event result_t Send . sendDone ( TOS_MsgPtr msg , result_t status ) { if ( pending1 && msg == & data ) { pending1 = FALSE ; signal IntOutput . outputComplete ( SUCCESS ) ; } if ( status == SUCCESS ) bcast_pending = 0; return SUCCESS ; } default event result_t ProcessCmd . done ( TOS_MsgPtr pmsg , result_t status ) { m = pmsg ; if ( status ) { post forwarder () ; } else { bcast_pending = 0; } return SUCCESS ; } Proyecto Final de Carrera 203
199 200 201 202 203
default event result_t IntOutput . outputComplete ( result_t success ) { return SUCCESS ; } } C odigo C.4: eibM.nc DemoSensor2C.nc
1 2 3 4 5 6 7 8 9 10 11 12
configuration DemoSensor2C { provides interface ADC ; provides interface StdControl ; } implementation { components HamamatsuC as DemoSensor ; StdControl = DemoSensor ; ADC = DemoSensor ; } C odigo C.5: DemoSensor2C.nc
204
Ap endice D
Diagramas Nesdoc
D.1. Diagrama completo de Iluminaci on y Persianas
A continuaci on, adjutamos el diagrama completo, generado por la herramienta Nesdoc, de las aplicaciones programadas de iluminaci on y persianas. El diagrama es similar para las aplicaciones de iluminaci on y persianas, tanto para los nodos congurados como pulsadores como los nodos congurados como actuadores.
205
Ap endice D. Diagramas Nesdoc
206
D.2.
Diagrama completo de Sensores
Adjuntamos el diagrama completo, generado por la herramienta Nesdoc, de las aplicaciones que conguran un nodo como sensor crepuscular.
207
208
Ap endice E
Hardware Telos rev.B
209
Ap endice E. Hardware Telos
E.1.
Telos
210
E.2.
Telos - CC240 802.15.4 Wireless Radio
211
E.3.
Telos - USB Interface
212
Bibliograf a
[1] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam y E. Cayirci, A Survey on Sensor Networks , 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 Architecture 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 Wireless Networks for Smart Developmental Problem-solving Environments , International Conference on Mobile Computing and Networking, 2001. [8] M. Jim enez, Caso de estudio: Redes de sensores/actuadores WSAN para automatizaci on de viviendas y edicios , Universidad Polit ecnica de Cartagena, Dpto. Tecnolog a Electr onica, 2006. [9] M. Weiser, The computer for the 21st century., Scientic American, vol. 265, no 3, pp. 94-104, September 1991. [10] Telef onica, Libro Blanco del Hogar Digital y las Infraestructuras Comunes de Telecomunicaci on http://www.telefonica.es/indez/libroblancohogardigital.html [11] M. Soledad Escolar D az 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 rst 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. Proyecto Final de Carrera 213
Bibliograf a
[14] F. Losilla, Estado del arte para redes de sensores y perspectivas desde el punto de vista de la ingenieria del software , Universidad Polit ecnica 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 Specication , 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 personal 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 00189162/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 Networking and Computing in Healthcare Industry, 2003. Healthcom 2003 Proceedings. 5th International Workshop on, pp. 118-127, June 2003. [23] European Installation Bus System Specication , European Installation Bus Association Handbook Series. Vol I, versi on 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 edicios: Dom otica , 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 , Est andar Konnex para control de viviendas y edicios, 2007. http://www.konnex.org/ [30] Futurasmus, S.L., Especialistas en KNX/EIB, 2007. http://www.futurasmus.es/ [31] EIB Shop Spain , Distribuci on de productos KNX/EIB, 2007. http://www.eibshop-spain.com/ [32] Casadomo , Portal de la dom otica y el hogar digital, 2007. http://www.casadomo.com Proyecto Final de Carrera 214
Bibliograf a
[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 dom oticos, 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] Situaci on actual de la dom otica y legislaci on, 2007. http://legislaciones.iespana.es/domotica.htm [37] Inmom atica, dom otica y tecnolog a para vivir . Control integral de edicios y viviendas. Tecnolog a para el hogar, 2007. http://www.inmomatica.com/ [38] Royal Philips Electronics - Pronto , 2007. http://www.pronto.philips.com/ [39] CEBus . Distribuidores de la tecnolog a CEBus, 2007. http://www.intellon.com/ [40] Echelon Corporation, embedded control networking technology .Echelon, compa n a l der 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/ Proyecto Final de Carrera 215
Bibliograf a
[49] Matradi, S.L.. Perspectivas 3D de proyectos de arquitectura e ingenier a, 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 Dom otica y Ambientes Inteligentes del Departamento de Tecnolog a Inform atica y Computaci on de la Universidad de Alicante, 2007. http://www.dtic.ua.es/dai/
216

Sensores Inalambricos

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sensores Inalambricos

Hochgeladen von

Copyright:

Verfügbare Formate

ESCUELA TECNICA SUPERIOR DE INGENIER IA DE TELECOMUNICACION UNIVERSIDAD POLITECNICA DE CARTAGENA

Proyecto Fin de Carrera

n de Programacio mbricas para Redes de Sensores Inala moticas aplicaciones do

Titulaci on Intensicaci on Departamento Fecha de Presentaci on

Proyecto Final de Carrera

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 conanza, gracias

Proyecto Final de Carrera

Proyecto Final de Carrera

Parte I. Dom otica Dom otica

Ejemplo Proyecto KNX/EIB . . . . . . . . . . . . . . . . . . . . . . .

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

159 160 163 166

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Figura 1: Casa dom otica Proyecto Final de Carrera 22

Proyecto Final de Carrera

Proyecto Final de Carrera

Figura 4: Anem ometro

Proyecto Final de Carrera

Figura 8: Sistemas cableados o inal ambricos

Proyecto Final de Carrera

III Funcionalidad de la dom otica

Funcionalidad de la dom otica

Control energ etico

Figura 9: Control energ etico

Proyecto Final de Carrera

III Funcionalidad de la dom otica

Figura 11: Control mediante pantalla t actil

Proyecto Final de Carrera

Figura 12: Controlador pronto de Philips

Proyecto Final de Carrera

Figura 14: Normalizaci on de los sistemas dom oticos

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Proyecto Final de Carrera

Figura 20: C odigos de casa y de control para unidad

Figura 23: Dispositivos X-10

Proyecto Final de Carrera

Figura 24: Accesorios X-10

Proyecto Final de Carrera

Proyecto Final de Carrera

Figura 28: Instalaci on LonWork

Proyecto Final de Carrera

Figura 30: Tramas EHS

Proyecto Final de Carrera

Proyecto Final de Carrera