Repositorio Institucional de Documentos

Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF verificando el estándar 802.15.4 (II) ÍNDICE GENERAL 2010 Francisco Pérez Pellicena REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 2 HOJA DE IDENTIFICACIÓN DE DATOS DATOS DEL PROYECTO REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 DIRECTORA DEL PROYECTO ARÁNZAZU OTÍN ACÍN RAZÓN SOCIAL: C\MARÍA DE LUNA 1, EDIFICIO ADA BYRON, 50015 ZARAGOZA AUTOR DEL PROYECTO FRANCISCO PÉREZ PELLICENA C\COIMBRA 2 2ºC 50008 ZARAGOZA FECHA Y FIRMA EN ZARAGOZA A 31 DE AGOSTO DE 2010 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 3 MEMORIA 1. OBJETO 6 2. ALCANCE 7 2.1. HARDWARE 7 2.2. SOFTWARE 7 3. ANTECEDENTES 9 3.1. INTRODUCCIÓN 9 3.2. EVOLUCIÓN HISTÓRICA 11 3.3. EVOLUCIÓN EN LA DOMÓTICA 13 3.4. LUZ 14 3.5. TEMPERATURA 15 3.6. HUMEDAD 17 3.7. PRESENCIA 17 3.8. ACTUADOR DIMMER 18 4. NORMAS Y REFERENCIAS 19 4.1. DISPOSICIONES LEGALES Y NORMAS APLICADAS 19 4.2. BIBLIOGRAFÍA 19 4.3. OTRAS REFERENCIAS 20 5. DEFINICIONES Y ABREVIATURAS 21 5.1. DEFINICIONES 21 5.2.-ABREVIATURAS 22 6. REQUISITOS DE DISEÑO 24 6.1. ARQUITECTURA DEL SISTEMA 24 6.2. SISTEMA LOCAL 24 6.3. SISTEMA EMBEBIDO 25 6.4. SISTEMA SERVIDOR 25 7. ANÁLISIS DE SOLUCIONES 27 7.1. ARQUITECTURA DEL SISTEMA 27 7.2. RED DE MOTES 28 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 4 7.2.1. PROTOCOLOS DE COMUNICACIÓN 28 7.2.1.1 WLAN 29 7.2.1.2. BLUETOOTH 29 7.2.1.3. IEEE 802.15.4 31 7.1.2.4. LA SOLUCIÓN A LA RED DE MOTES 33 7.2.2. TRANSCEPTORES 34 7.2.2.1. ST MICROELECTRONICS SN260 34 7.2.2.2. TEXAS INSTRUMENTS CC2420 34 7.2.2.3. DIGI XBEE 35 7.2.2.4. ELECCIÓN DEL TRANSCEPTOR 36 7.2.3. MICROCONTROLADORES 37 7.2.3.1. ATMEL 38 7.2.3.2. MICROCHIP 38 7.2.3.3. FREESCALE 39 7.2.3.4. ELECCIÓN DE MICROCONTROLADOR 40 7.3. SISTEMA LOCAL 41 7.3.1. LA SOLUCIÓN ARQUITECTÓNICA Y SU IMPLEMENTACIÓN 42 7.4. SISTEMA EMBEBIDO 43 7.4.1. SOFTWARE 43 7.4.1.1. LIBRERÍAS 43 7.4.1.2. AUTOGESTIÓN 43 7.4.1.3. PROGRAMA.PRINCIPAL 44 7.4.1.4. MOTE.AMBIENTAL 45 7.4.1.5. MOTE DE DETECCIÓN 46 7.4.1.6. MOTE DIMMER 46 7.4.2. HARDWARE 49 7.4.2.1. COORDINADOR 49 7.4.2.2. MOTE BASE 51 7.5. SISTEMA SERVIDOR 56 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 5 7.5.1. SERVIDOR DE APLICACIONES 56 7.5.2. SERVIDOR DE BASE DE DATOS 57 7.5.3. APLICACIÓN 58 7.5.3.1. REQUISITOS 58 7.5.3.2. MODELO ORIENTADO A OBJETOS 59 7.5.3.3. MODELO RELACIONAL 60 7.5.3.4. CONTROLADOR 60 CONTEXT.XML 62 7.5.3.5. VISTA 66 7.5.3.6. REGLAS 68 8. CONCLUSIONES 70 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 6 ANEXOS 1. DOCUMENTACIÓN DE PARTIDA 5 2. CÁLCULOS 6 2.1. COORDINADOR 6 2.1.1. ALIMENTACIÓN 6 2.1.2. COMUNICACIÓN 8 2.2. MOTE BASE 11 2.2.1. ALIMENTACIÓN 11 2.2.2. CARGA DE BATERÍA 22 2.2.3. PROCESAMIENTO 23 2.2.4. COMUNICACIÓN 25 3. FLUJOGRAMAS DE PROGRAMACIÓN 28 3.1. SISTEMA LOCAL 28 3.1.1. COMUNICACIÓN SERIE CON XBEE 28 3.1.2. GESTIÓN DE TRAMAS DE RED 29 XBEEPACKETLISTENER.JAVA 30 RESPONSEREADER.JAVA 32 RESPONSEREADERFACTORY.JAVA 34 STANDARDRESPONSEREADER.JAVA 35 ASSOCIATIONRESPONSE.JAVA 39 SENSORMEASURERESPONSE.JAVA 39 3.1.3. ARQUITECTURA SERVIDOR REMOTO 40 XBEESTANDARDSERVICE.JAVA 41 XBEESTANDARDSERVICEIMPL.JAVA 42 3.1.4. AUTOCONFIGURACIÓN A ALTO NIVEL 43 3.1.5. REASOCIACIÓN 46 ASSOCIATIONWORKER.JAVA 47 3.1.6. CONEXIÓN A LA BASE DE DATOS 48 DBLOCAL.JAVA 48 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 7 3.2. SISTEMA EMBEBIDO 50 3.2.1. LIBRERÍA XBEE 50 XBEE.H 50 STRUCT XBEEPACKET 51 3.2.2. LIBRERÍA PARA GESTIÓN DE INFORMACIÓN 54 ASSOCIATION.H 54 ASSOCIATION.C 55 SENSING.H 56 SENSING.C 57 3.2.3. AUTOGESTIÓN 58 AVR_PORT.H 63 AVR_PORT.C 63 3.2.4. PROGRAMA PRINCIPAL 64 3.2.5. MOTE AMBIENTAL 65 3.3. SERVIDOR DE APLICACIONES 73 3.3.1. MODELO ORIENTADO A OBJETOS 73 USER.JAVA 73 ROLE.JAVA 74 NETWORK.JAVA 75 MOTE.JAVA 76 COORDINATOR.JAVA 77 SENSORENDDEVICE.JAVA 77 CONTROLLERENDDEVICE.JAVA 78 EVENT.JAVA 79 EVENTTYPE.JAVA 79 EVENTRELEVANCE.JAVA 80 MEASURE.JAVA 81 CONTINUOUSMEASURE.JAVA 81 BINARYMEASURE.JAVA 82 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 8 ALARM.JAVA 83 CONTINUOUSALARM.JAVA 84 ALARMTYPE.JAVA 84 ALARMRULE.JAVA 85 SEASONS.JAVA 85 DAYTIMES.JAVA 85 3.3.2. MODELO RELACIONAL 86 USERS.SQL 87 MOTES.SQL 88 ALARMS.SQL 89 EVENTS.SQL 90 3.3.3. VISTA 91 REALTIMECHARTSERVLET.JAVA 93 HISTORICRANGE.JAVA 94 STATCHARTSERVLET.JAVA 94 REALTIMECONTROLUPDATESERVLET.JAVA 99 3.4. REGLAS 100 ALARMCHECK.JAVA 100 RULES.DRL 102 4. DATOS DE COMPONENTES 105 4.1. ATMEL ATMEGA 168 105 4.2. XBEE 115 4.3. FTDI FT232RL 117 4.4. TPS79333 119 4.5. TPS61131 124 4.6. MAX1555 132 4.7. DIODOS LED SMD 135 4.8. SWITCH ADG719 136 4.9. INTERRUPTORES A6H-1109 139 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 9 4.10. TMP36 141 4.11. HIH5030 144 4.12. LDR 148 4.13. SENSOR PIR PARALLAX 149 4.14. OPTOACOPLADOR 4N25 151 4.15. TRIAC OPTOACOPLADO MOC3021 154 REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 Página 16 MANUAL DE USUARIO 1.- REQUISITOS HARDWARE 4 2.- REQUISITOS SOFTWARE 4 3.- ACCESO A LA APLICACIÓN 4 4.- DATOS DE USUARIO 6 5.- USUARIOS DE LA RED 6 6.- DATOS DE LA RED 8 7.- MOTES INSTALADOS 10 7.1.- DATOS DE UN MOTE 11 7.2.- MONITORIZACIÓN DE UN MOTE SENSOR 11 7.3.- CONTROL DE UN MOTE ACTUADOR 12 7.4.- HISTÓRICO DE MEDICIONES 13 7.5.- GESTIÓN DE ALARMAS 14 7.6.- DESHABILITAR MOTE 15 7.6.- REINICIO DE UN MOTE 15 7.7.- COMPROBACIÓN DE UN MOTE 15 8.- SALIDA DE LA APLICACIÓN 16 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF verificando el estándar 802.15.4 (II) MEMORIA 2010 Autor: Francisco Pérez Pellicena Directora: Aránzazu Otín Acín Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 2 HOJA DE IDENTIFICACIÓN DE DATOS DATOS DEL PROYECTO REALIZACIÓN DE SISTEMA DOMÓTICO CON MICROCONTROLADORES DE BAJO COSTE (AVR) Y MÓDULOS RF, VERIFICANDO EL ESTÁNDAR 802.15.4 DIRECTORA DEL PROYECTO Aránzazu Otín Acín Razón social: C\María de Luna 1, Edificio Ada Byron, 50015 Zaragoza AUTOR DEL PROYECTO Francisco Pérez Pellicena C\Coimbra 2 2ºC 50008 Zaragoza FECHA Y FIRMA En Zaragoza a 31 de Agosto de 2010 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 3 Agradecimientos En primer lugar quiero agradecer a mi familia el apoyo que me ha prestado y la comprensión que han tenido, no sólo estos últimos meses sino desde el primer momento que vi la luz en este mundo. Sin ellos nada habría sido posible. Especialmente a mi madre, porque el presente proyecto me ha robado mucho tiempo de estar a su lado. En segundo lugar, a todas las personas que de una forma u otra, han contribuido a mi desarrollo personal y profesional en la Escuela Universitaria de Ingeniería Técnica Industrial de Zaragoza, porque su labor es de un valor incalculable. Mi especial agradecimiento a Aránzazu Otín Acín como directora de este proyecto, por sus consejos y su paciencia. A mi compañero de proyecto David Pilarcés Collado por su esfuerzo para que esta empresa haya salido adelante. A Diego Antolín Cañada por su apoyo personal y profesional. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 4 ÍNDICE 1.- OBJETO .......................................................................................................................................................................................... 6 2.-ALCANCE ........................................................................................................................................................................................ 7 2.1.- HARDWARE ....................................................................................................................................................................................................7 2.2- SOFTWARE ......................................................................................................................................................................................................7 3.-ANTECEDENTES .......................................................................................................................................................................... 9 3.1.- INTRODUCCIÓN .......................................................................................................................................................................................9 3.2.-EVOLUCIÓN HISTÓRICA ..................................................................................................................................................................... 11 3.3.-EVOLUCIÓN EN LA DOMÓTICA ....................................................................................................................................................... 13 3.4.-LUZ ............................................................................................................................................................................................................... 14 3.5.-TEMPERATURA ...................................................................................................................................................................................... 15 3.6.-HUMEDAD ..................................................................................................................................................................................................... 17 3.7.- PRESENCIA .............................................................................................................................................................................................. 17 3.8.-ACTUADOR DIMMER ........................................................................................................................................................................... 18 4. - NORMAS Y REFERENCIAS ................................................................................................................................................... 19 4.1.-DISPOSICIONES LEGALES Y NORMAS APLICADAS .................................................................................................................................... 19 4.2.-BIBLIOGRAFÍA .............................................................................................................................................................................................. 19 4.3.- OTRAS REFERENCIAS ................................................................................................................................................................................. 20 5. - DEFINICIONES Y ABREVIATURAS .................................................................................................................................... 21 5.1. - DEFINICIONES ............................................................................................................................................................................................ 21 5.2.- ABREVIATURAS........................................................................................................................................................................................... 22 6. - REQUISITOS DE DISEÑO ...................................................................................................................................................... 24 6.1. - ARQUITECTURA DEL SISTEMA ................................................................................................................................................................. 24 6.2. - SISTEMA LOCAL ......................................................................................................................................................................................... 24 6.3.- SISTEMA EMBEBIDO ................................................................................................................................................................................... 25 6.4. - SISTEMA SERVIDOR ................................................................................................................................................................................... 25 7.-ANÁLISIS DE SOLUCIONES .................................................................................................................................................... 27 7.1- ARQUITECTURA DEL SISTEMA ................................................................................................................................................................... 27 7.2.- RED DE MOTES ............................................................................................................................................................................................ 28 7.2.1.- Protocolos de comunicación ..................................................................................................................................................... 28 7.2.1.1- WLAN .................................................................................................................................................................................................................... 29 7.2.1.2.- BLUETOOTH ..................................................................................................................................................................................................... 29 7.2.1.3.- IEEE 802.15.4 ................................................................................................................................................................................................... 31 7.1.2.4.- La solución a la red de motes ................................................................................................................................................................... 33 7.2.2.- Transceptores................................................................................................................................................................................. 34 7.2.2.1.- ST Microelectronics SN260 ....................................................................................................................................................................... 34 7.2.2.2.- Texas instruments CC2420 ....................................................................................................................................................................... 34 7.2.2.3.- Digi XBee ............................................................................................................................................................................................................ 35 7.2.2.4.- Elección del transceptor ............................................................................................................................................................................. 36 7.2.3. - Microcontroladores .................................................................................................................................................................... 37 7.2.3.1.- Atmel .................................................................................................................................................................................................................... 38 7.2.3.2.- Microchip ........................................................................................................................................................................................................... 38 7.2.3.3.- Freescale ............................................................................................................................................................................................................. 39 7.2.3.4.- Elección de microcontrolador .................................................................................................................................................................. 40 7.3. - SISTEMA LOCAL ......................................................................................................................................................................................... 41 7.3.1.- La solución arquitectónica y su implementación............................................................................................................. 42 7.4. - SISTEMA EMBEBIDO .................................................................................................................................................................................. 43 7.4.1.- Software .......................................................................................................................................................................................... 43 7.4.1.1.- Librerías ............................................................................................................................................................................................................. 43 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 5 7.4.1.2.- Autogestión ....................................................................................................................................................................................................... 43 7.4.1.3.- Programa principal ....................................................................................................................................................................................... 44 7.4.1.4.- Mote ambiental ............................................................................................................................................................................................... 45 7.4.1.5.- Mote de detección .......................................................................................................................................................................................... 46 7.4.1.6.- Mote dimmer .................................................................................................................................................................................................... 46 7.4.2. – Hardware ....................................................................................................................................................................................... 49 7.4.2.1.- Coordinador ...................................................................................................................................................................................................... 49 7.4.2.2. - Mote Base .......................................................................................................................................................................................................... 51 7.5. - SISTEMA SERVIDOR ................................................................................................................................................................................... 56 7.5.1.- Servidor de aplicaciones ............................................................................................................................................................ 56 7.5.2.- Servidor de base de datos .......................................................................................................................................................... 57 7.5.3.- Aplicación ........................................................................................................................................................................................ 58 7.5.3.1.- Requisitos .......................................................................................................................................................................................................... 58 7.5.3.2.- Modelo orientado a objetos....................................................................................................................................................................... 59 7.5.3.3- Modelo relacional ............................................................................................................................................................................................ 60 7.5.3.4.- Controlador ....................................................................................................................................................................................................... 60 context.xml .................................................................................................................................................................................................................... 62 7.5.3.5.- Vista ...................................................................................................................................................................................................................... 66 7.5.3.6.- Reglas ................................................................................................................................................................................................................... 68 8.- CONCLUSIONES ........................................................................................................................................................................ 70 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 6 1. - OBJETO El objeto del presente proyecto es la realización de un prototipo funcional sencillo, que permita la medición de ciertos parámetros físicos haciendo uso de los pertinentes transductores o sensores. Las mediciones realizadas de forma aislada, se propagarán a través de una red inalámbrica hasta llegar a un sistema central, el cual procesará las medidas y las almacenará para su posterior tratamiento. La principal idea a aplicar es el hacer accesible esa información, siempre convenientemente tratada, a internet, de tal forma que pueda ser consultada desde cualquier terminal con acceso y en cualquier momen- to. Además de realizar mediciones se ofrece la posibilidad de realizar ciertas tareas de control sencillas, como activar y desactivar dispositivos, regular sistemas de iluminación...etc. , y aunque el prototipo no incluirá todas las opciones posibles, cabe destacar que las tareas de control, también podrán ser llevadas a cabo desde cualquier terminal con acceso a internet, lo que dotará de una alta disponibilidad al conjunto. Las aplicaciones son inmensas, desde la realización de sistemas de monitorización ambiental en ciudades o espacios naturales, hasta sistemas complejos con un gran número de elementos de red y con complejas opciones de control, como podría ser la domotización de un edificio. En este proyecto se va a intentar que la generalidad sea una cuestión primordial, bajo la idea de que el sistema pueda adaptarse tanto a pequeñas como a grandes implementaciones. Esto solo se puede conseguir abstrayendo los elementos comunes a los posibles problemas que queremos resolver e ideando soluciones eficientes a dichos problemas de base. No obstante, se va a pretender desarrollar un prototipo de un sistema reducido, como podría ser una solución para un sistema domótico, más o menos general. Este proyecto se realiza en conjunto con David Pilarcés Collado, quien se encarga principalmente del desarrollo del hardware. El trabajo elaborado por el presente proyectante está centrado en la programación tanto del software de los sistemas hardware (motes) que interactúan con sensores y actuadores, como en el software de aplicación, sin dejar de lado las implicaciones que el diseño del hardware tienen sobre el software y participando activamente en el propio diseño del hardware. Los objetivos concretos de la parte que se presenta son los siguientes:  Programación de los motes de la red inalámbrica que permita la gestión de auto asociación a alto nivel y el envío de información estructurada.  Gestión de la información que circula por la red, almacenando la que es relevante para el funcionamiento y para los usuarios.  Creación de una infraestructura de servidor web, para permitir el acceso a la información almacenada.  En general, establecer las bases para un sistema sensorial que permita la adaptación al cambio con el menor coste. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 7 2.-ALCANCE Una vez marcados los objetivos tal y como se describen en el apartado anterior, y dado el gran abanico de posibilidades, se va a centrar el proyecto en el desarrollo de un prototipo funcional de lo que podría ser un sistema de medición y control de parámetros que se pueden encontrar en una vivienda habitual. 2.1.- HARDWARE Se van a contemplar como parámetros de medición los siguientes: 1. Temperatura ambiental 2. Iluminación 3. Humedad relativa 4. Presencia Para ello se dispondrán los dispositivos pertinentes que más en profundidad se detallan en apartados siguientes. Como se ha mencionado, también aparece el término control, y aunque no se trata de un control estricto, si que va a ser suficiente para el propósito de este proyecto. En este sentido, se va a realizar un control de iluminación de una bombilla típica mediante la realización hardware de un dimmer, controlado por software. Los sistemas autónomos o motes de medición y control, están formados por un núcleo microcontrolador que gestiona la adquisición de medidas y las acciones de control, así como el sistema de comunicación. En cuanto al sistema de comunicación, como ya se ha mencionado se va a disponer un transceptor inalámbrico de coste moderado y consumo reducido, que permita la transmisión y recepción de información desde cada mote a un sistema central, donde se van a almacenar y tratar toda la información que llegue, formando una red con una determinada topología. Uno de los principales objetivos es la flexibilidad del sistema, de tal forma que la red formada por los motes sea capaz de gestionar la configuración de los motes, permitiendo añadir nuevos en lo que podría ser un sistema plug&play de alto nivel. 2.2- SOFTWARE En cuanto al software, cabe diferenciar tres actuaciones. Una primera centrada en el desarrollo de las aplicaciones que van instaladas en los motes, donde se trabaja a bajo nivel con el principal elemento, el microcontrolador, usando el lenguaje de programación C. Los principales objetivos son el desarrollo de un software que sea eficiente energéticamente y que permita la flexibilidad de autogestión de la red. En cuanto al concepto de “software eficiente energéticamente” cabe decir que está basado en el aprovechamiento de los recursos que ofrece el microcontrolador en términos de bajo consumo, como son los modos de sueño y el control de activación de bloques independientes. Ambos recursos se van a tratar de explotar para minimizar el consumo. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 8 Una segunda actuación del desarrollo de software está pensada como aplicación principal que gestiona el sistema autónomo, es decir la red de motes, dentro de lo que sería una instalación física. Esta aplicación debe funcionar de forma autónoma e ininterrumpida, independientemente de que exista o no una conexión a internet, por lo que las dependencias deben minimizarse. Esto puede entrar en contraposición al objetivo de accesibilidad, pero nada más lejos de la realidad, lo que interesa es que el sistema de motes funcione bajo cualquier circunstancia. La gestión de la red implica la capacidad de autogestión de la misma a alto nivel, con la posibilidad de añadir motes en caliente y sin previa configuración en el sistema informático, la detección de tramas específicas de datos, el envío de tramas de control a los motes que realizan acciones y la coordinación de toda esta información con el sistema central, donde se almacenará, lo que implica que debe ser capaz de acceder remotamente a través de internet a un sistema de base de datos externo. De igual forma que es capaz de gestionar las tramas que circulan por la red, debe permitir la ejecución de acciones de control, como puede ser regular la iluminación de una bombilla, desde un terminal externo conectado a internet. Para lograrlo, hay que permitir el acceso al sistema instalado de forma remota, así un cliente remoto podrá realizar las acciones de control, por lo que la instalación puede considerarse conceptualmente como un servidor remoto, que ofrece servicios de control de dispositivos, entre otros. La tercera actuación está centrada en el sistema central donde se recibe la información, se almacena y se pone a disposición de los usuarios. Se va a enfatizar en el concepto de servicio, de tal forma que el conjunto del proyecto es en sí mismo un servicio, el cual es contratado por determinados clientes. Esto afecta directamente al desarrollo del sistema central, donde se van a considerar diferentes perfiles de acceso a la aplicación, permitiendo un perfil de administración para tareas restringidas y al menos un perfil de cliente, con propósitos de monitorización y control de la instalación. Básicamente esto se consigue empleando un servidor de aplicaciones en el cual, se ejecuta una aplicación que es capaz de gestionar la información de cada perfil adecuadamente, así como de delimitar el acceso a las zonas restringidas. Evidentemente es necesario un mecanismo de persistencia para almacenar la información que es relevante tanto para la gestión de usuarios y perfiles como para la configuración de la red, asegurando el correcto funcionamiento de la misma. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 9 3.-ANTECEDENTES 3.1.- INTRODUCCIÓN Etimológicamente, domótica proviene de la unión de domus (del latín: casa) y robota (del checo: esclavo) y se define como “la integración de la tecnología en el diseño inteligente de un recinto” El concepto Domótica, se asocia con un conjunto de sistemas capaces de automatizar una vivienda, aportando así servicios de: gestión energética, seguridad, bienestar y comunicación; e integrados por medio de redes interiores\exteriores de comunicación, cableadas o inalámbricas (wireless). Estos servicios se crean a partir de las nuevas tecnologías de la información (TIC), las cuales han sido aplicadas y utilizadas en las viviendas siempre, contribuyendo a cambiar las relaciones familiares y las estructuras de las ciudades. La penetración e inserción de las TIC en la sociedad y el territorio tiene sus raíces en el reciente proceso de convergencia tecnológica, facilitado en buena medida por la estandarización de una de las unidades básicas con que hoy se mide la información y su flujo: los bits. Las TIC son una especie de disciplina emergente en la que conjuntamente están implicados arquitectos, ingenieros eléctricos, electrónicos y civiles, programadores de sistemas y diseñadores. Esta forma de trabajar implica varias arquitecturas, principalmente existen:  Arquitectura Centralizada: en donde un controlador centralizado recibe información de múltiples sensores y, una vez procesada, genera las órdenes oportunas para los actuadores.  Arquitectura Distribuida: en este caso, no existe la figura del controlador centralizado, sino que toda la inteligencia del sistema está distribuida por todos los módulos sean sensores o actuadores. Suele ser típico de los sistemas de cableado en bus.  Arquitectura Descentralizada: dispone de varios pequeños dispositivos capaces de adquirir y procesar la información de múltiples sensores y transmitiéndolos al resto de dispositivos distribuidos por la vivienda. (Se conoce como Arquitectura Mixta). FIGURA 1: ARQUITECTURAS PARA SISTÉMAS DOMÓTICOS Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 16 al que le ha dado el sol. Para tener una idea más aproximada de la sensación se puede tomar la temperatura de varias formas. TEMPERATURA SECA: Se llama “Temperatura seca del aire de un entorno”, o más sencillamente, temperatura seca, a la del aire, prescindiendo de la radiación calorífica de los objetos que rodean ese ambiente concreto y de los efectos de la humedad relativa y de la velocidad del aire. Se puede obtener con el termómetro de mercurio, cuyo bulbo, reflectante y de color blanco brillante, se supone razonablemente que no absorbe la radiación. TEMPERATURA RADIANTE La temperatura radiante tiene en cuenta el calor emitido por radiación de los elementos del entorno. Se toma con un termómetro de bulbo, que tiene el depósito de mercurio encerrado en una esfera o bulbo metálico de color negro, para asemejarlo lo más posible a un cuerpo negro y absorba la máxima radiación. Para anular en lo posible el efecto de la temperatura del aire, el bulbo negro se aísla mediante otro bulbo en el que se ha hecho al vacío. Las medidas se pueden tomar bajo el sol o a la sombra. En el primer caso tendrá en cuenta la radiación solar y dará una temperatura bastante más elevada. También sirve para dar una idea de la sensación térmica. La temperatura de bulbo negro hace una función parecida, dando la combinación de la temperatura radiante y la ambiental TEMPERATURA HÚMEDA Temperatura de bulbo húmedo o Temperatura húmeda es la temperatura que da un termómetro a la sombra con el bulbo envuelto en una mecha de algodón húmedo bajo una corriente de aire. La corriente de aire se produce mediante un pequeño ventilador o poniendo el termómetro en un molinete y haciéndolo girar. Al evaporarse el agua, absorbe calor, rebajando la temperatura, efecto que reflejará el termómetro. Cuanto menor sea la humedad relativa ambiente, más rápidamente se evapora el agua que empapa el paño. Se utiliza para dar una idea de la sensación térmica o en los psicrómetros para calcular la humedad relativa. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 17 UNIDADES DE TEMPERATURA Kelvin (SI) Grados Celsius (unidades habituales) Grados Fahrenheit (unidades anglosajonas) Grados Rankine (no convencional) Grados Réaumur (no convencional) 3.6.-HUMEDAD Se denomina humedad ambiental a la cantidad de vapor de agua presente en el aire. Se puede expresar de forma absoluta mediante la humedad absoluta, o de forma relativa mediante la humedad relativa o grado de humedad:  La humedad absoluta es la cantidad de vapor de agua presente en el aire, se expresa en gramos de agua por kilogramos de aire seco (g/kg), gramos de agua por unidad de volumen (g/m³) o como presión de vapor (Pa o KPa o mmHg). A mayor temperatura, mayor cantidad de vapor de agua permite acumular el aire.  La humedad relativa es la humedad que contiene una masa de aire, en relación con la máxima humedad absoluta que podría admitir sin producirse condensación, conservando las mismas condiciones de temperatura y presión atmosférica. Esta es la forma más habitual de expresar la humedad ambiental. Se expresa en tanto por ciento. 3.7.- PRESENCIA El sensor de proximidad es un transductor que detecta objetos o señales que se encuentran cerca del elemento sensor. Existen varios tipos de sensores de proximidad según el principio físico que utilizan. Los más comunes son los interruptores de posición, los detectores capacitivos, los inductivos y los fotoeléctricos, como por ejemplo el de infrarrojos. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 18 FIGURA 2: DETECCIÓN DE MOVIMIENTO MEDIANTE SENSORES PIR En este caso se utilizarán sensores PIR (sensores de proximidad de infrarrojos) como se puede observar en la figura. 3.8.-ACTUADOR DIMMER Los dimmer son dispositivos usados para regular el voltaje de una o varias lámparas. Así, es posible variar la intensidad de la luz, siempre y cuando las propiedades de la luminaria lo permitan. Para controlar esa intensidad lumínica, se varía el ángulo de disparo, para ello antes habrá que tener una referencia de ese ángulo, con lo que será necesario detectar el cruce por cero de la red eléctrica. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 19 4. - NORMAS Y REFERENCIAS 4.1.-DISPOSICIONES LEGALES Y NORMAS APLICADAS A continuación se cita la normativa aplicada a la realización de este proyecto en materia eléctrica y de fabricación de las PCB:  Norma UNE 20 524 75(1). Técnica de los circuitos impresos. Parámetros fundamentales.  Norma UNE 20 524 77(2). Técnica de los circuitos impresos. Terminología.  Norma UNE 20 621 80. Circuitos impresos. Métodos de ensayo.  Norma UNE 20 621 84. Circuitos impresos. Diseño y utilización de placas impresas.  Norma UNE 20 621 85. Circuitos impresos. Especificaciones para placas impresas de simple y doble cara con agujeros metalizados.  Norma UNE 20 622 81. Código de símbolos para agujeros de circuito impreso.  MI BT 031. Hace referencia a las condiciones de instalación y hace alusión a que durante el funcionamiento de los aparatos no se deben producir perturbaciones en la red.  Directiva de Baja Tensión (BT 73/23/CEE) relativo a todo aquel material electrotécnico utilizado a una tensión menor de 1000V.  Instrucción técnica complementaria para baja tensión. ITC-BT-36. Instalaciones a muy baja tensión.  Instrucción técnica complementaria para baja tensión ITC-BT-51. Instalaciones de sistemas de automatización, gestión técnica de la energía y seguridad para viviendas y edificios. 4.2.-BIBLIOGRAFÍA  Programación de aplicaciones o Core Java vol.2, Prentice Hall, Cay Horstmann, Gary Cornell o The Java Language Specification Third Edition, Gosling et al., Addison Wesley o Effective Java Second Edition, Josua Bloch, Addison Wesley o Programación concurrente en Java 2ª Edición, Doug Lea, Addison Wesley  Programación en C o C Primer Plus,Stephen Prata, Sams Publishing  Microcontrolador Atmel o C programming for Microcontrollers featuring Atmel Butterfly  Redes 802.15.4 o Wi-Fi, Bluetooth, ZigBee and Wi-Max , H. Labiod, H. Afifi,c. De Santis, Springer o ZigBee wireless networks and transceivers, Shahin Farahani PhD, Newnes o Sensor networks and configuration, Nitaigour P. Mahalik,Springer  Drools o Jboss Drools Business Rules, Paul Browne, Packt Publishing o Drool Jboss Rules 5.0 Developers guide, Michael Bali, Packt Publishing  Electrónica o Circuitos electrónicos. Discretos e integrados. Donald L. Schilling, Charles Belove. McGraw- Hill. o Sensores y acondicionadores de señal, Ramón Pallás Areny, Marcombo Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 20 4.3.- OTRAS REFERENCIAS  Páginas web o www.digikey.com o www.avrfreaks.net o www.oracle.com o www.mysql.com o www.jboss.org o www.developer.yahoo.com o www.w3.org o www.atmel.com o www.arduino.cc o www.digi.com o www.zigbee.org o www.sparkfun.com o www.freescale.com o www.microchip.com o www.maxim-ic.com o www.nxp.com o www.zilog.com o www.humirel.com o www.sensirion.com  Application notes y datasheets o AVR 133: Long delay generation using the AVR microcontroller o XBee/XBee Pro 802.15.4 OEM RF Modules v.1.x.E.x o Atmega 48/88/168/328 datasheet o UM10204 I2C bus specification and user manual o TU0113 Performing signal integrity analises, Altium o Atmel white paper, Innovative techniques for extremely low power consumption with 8 bit microcontroller. o AVR 042: AVR hardware desing considerations o ADG719 datasheet, Analog Devices o FT232R datasheet FTDI Chip o TPS79333 datasheet, Texas Instruments o TPS61131 datasheet, Texas Instruments o MAX 1555 datasheet, Maxim  Referencias y manuals o MySql 5.0 Reference guide Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 21 5. - DEFINICIONES Y ABREVIATURAS 5.1. - DEFINICIONES 5.1.1.- Accesibilidad: Propiedad de una aplicación de facilitar la información que produce a quien la consume. 5.1.2.- Alias: Pseudónimo, palabra que identifica a un elemento. 5.1.3.-Base de datos: Sistema de almacenamiento de información basado en tablas y relaciones entre tablas. 5.1.4.-Clase: Representa una entidad modelada en lenguaje de programación orientado a objetos. 5.1.5.-Clase abstracta: Clase con métodos no implementados cuya funcionalidad depende de quién implemente dicha clase abstracta. 5.1.6.-Coordinador: Elemento de una red de sensores que está encargado de crear la red y gestionar la información que circula por ella. 5.1.7.-Data center: Espacio físico donde se albergan los servidores web, que dispone de mecanismos de control de temperatura y humedad, así como sistemas de seguridad, energía y red redundantes. 5.1.8.-Disponibilidad: Capacidad de una aplicación web de ser accedida en cualquier momento, independientemente de las condiciones. 5.1.9.-Escalabilidad: Capacidad de una aplicación web de incrementar su uso y volumen de datos. 5.1.10.-Interfaz: En programación orientada a objetos, es un contrato, una definición de cabeceras de métodos que quienes hereden de esa interfaz, deberán implementar. 5.1.11.-Listener: En programación orientada a objetos, es una clase especializada en escuchar eventos, como por ejemplo, una pulsación de ratón o de teclado. 5.1.12.-Mote: Elemento de una red inalámbrica de bajo coste, que está formado por un transceptor de red y un microcontrolador que lo gestiona. 5.1.13.-Multiplataforma: Capacidad de una aplicación de funcionar de la misma forma en diferentes sistemas. 5.1.14.-Objeto: Es una instancia de una clase, que ocupa un espacio en memoria y es manejable. 5.1.15.-Plug and Play: Capacidad de un bloque software o hardware de añadirse o eliminarse de un sistema completo, sin afectar al funcionamiento de dicho sistema. 5.1.16.-Proxy: Entidad intermedia entre dos elementos que se comunican y que generalmente se encarga de gestionar funcionalidades de bajo nivel. 5.1.17.-Sistema embebido: Aquel sistema electrónico con recursos limitados, que forma parte de un producto final, cuyo cometido está restringido a una operación en concreto. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 22 5.1.18.-Toolchain: Conjunto de herramientas informáticas que se utilizan para la compilación, programación y depurado de aplicaciones. 5.1.19.-Topología: Disposición física de elementos, con unas determinadas propiedades. 5.1.20.-Trama de datos: Conjunto de información enviada a través de un sistema de comunicación ya sea cableado o inalámbrico, que tiene una determinada estructura, determinada por el protocolo empleado. 5.2.- ABREVIATURAS 5.2.1.- A/D: Conversor analógico a digital 5.2.2.- AES: Advanced encryption standard 5.2.3.- API: Application Programming Interface 5.2.4.-CISC: Complex instruction set computing 5.2.5.-CRC: Comprobación de redundancia cíclica 5.2.6.-CSMA: Carrier sense multiple access 5.2.7.-DIP: Dual in line package 5.2.8.-FFD: Full function device 5.2.9.-IEEE: Institute of Electrical and Electronics engineers 5.2.10.-ISP: Internet service provider 5.2.11.-JNI: Java native interface 5.2.12.-JVM: Java virtual machine 5.2.13.-LQI: Link quality interface 5.2.14.-LR-WPAN: Low rate wireless personal area network 5.2.15.-MAC: Media access control 5.2.16.-OSI: Open system interconection 5.2.17.-P2P: peer to peer 5.2.18.-PAN: Personal area network 5.2.19.-PWM: Pulse width modulation 5.2.20.-QFN: Quad flat no leads package 5.2.21.-QLP: Quad lead package Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 23 5.2.22.-RFD: Reduced function device 5.2.23.-RISC: Reduced instruction set computing 5.2.24.-RSSI: Received signal strength indication 5.2.25.-SH: Serial high 5.2.26.-SL: Serial low 5.2.27.-SMD: Surface mount device 5.2.28.-SPI: Serial peripheral interface 5.2.29.-THD: Through hole device 5.2.30.-TIC: Tecnología de la información y la comunicación 5.2.31.-UART: Universal asynchronous receiver transmitter 5.2.32.-USB: Universal serial bus 5.2.33.-WLAN: Wireless local area network 5.2.34.-XML: Extensible markup language Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 24 6. - REQUISITOS DE DISEÑO 6.1. - ARQUITECTURA DEL SISTEMA Desde un punto de vista general, la arquitectura, es decir, cómo se reparten las funciones principales en bloques y cómo se interconectan estos bloques entre sí, es la parte fundamental del análisis del sistema. Dados los requisitos estructurales enunciados en el apartado 2.-ALCANCE y que a continuación se resumen, se puede plantear un diseño lo suficientemente flexible y escalable:  Gestión de la red de motes (PAN) centralizada y ortogonal frente a comportamientos anómalos del proveedor de ISP.  Acceso desde cualquier terminal con conectividad a internet.  Comunicación bidireccional entre los sistemas locales y el sistema principal.  Persistencia robusta y estructurada de datos 6.2. - SISTEMA LOCAL En cada una de las actuaciones físicas o instalaciones que se pueden realizar, es necesaria la existencia de un sistema central que sea capaz de gestionar la red de dispositivos a alto nivel, es decir, la información que transporta. Y no solo esto, también debe ser capaz de establecer una comunicación bidireccional con el exterior, entendiendo exterior como cualquier usuario del sistema que quiere recibir información de lo que está ocurriendo, como actuar directamente sobre el sistema. Esto establece en principio los criterios para la selección de la tecnología a emplear:  Por un lado, al tener como primer objetivo la gestión de la red, debe acceder a la misma, de tal forma que deberá formar parte de ella y además con una relevancia importante. Este acceso debe ser físico, es decir, en sistema en el cual va a correr el software, debe disponer de un soporte para acceso a la red, lo que se puede conseguir instalando un dispositivo transceptor en dicho sistema.  Una vez que hemos determinado que el sistema debe acceder físicamente a la red, y por lo tanto dispondrá de un transceptor de red, el software que ejecuta debe poder acceder a dicho transceptor, lo que implica que deberá ser posible crear o usar las librerías pertinentes para tal fin.  Por otra parte, una vez sea posible acceder físicamente a la red, y obtener la información que por ella circula, hay que poder estructurar esa información, de tal forma que sea manejable para la programación y para el almacenamiento de la misma. Esto se consigue usando lenguajes de programación que permitan la creación de estructuras de datos adecuadas a la necesidad del problema. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 25  Una vez ya tenemos la información de la red y la hemos estructurado de forma adecuada, hay que hacerla accesible a los interesados en la misma. Para esto el sistema debe permitir acceso a internet para poder enviar dicha información al sistema servidor y de ahí ponerla a disposición de los usuarios. Esta es la primera parte de la comunicación bidireccional, del sistema instalado al sistema servidor.  La segunda parte de la comunicación bidireccional, del sistema central a los sistemas instalados, es un poco más compleja, pues implica la identificación de cada uno de los sistemas instalados, usando una comunicación punto a punto. Para esto, la infraestructura que se utilice debe permitir una comunicación P2P cliente-servidor. 6.3.- SISTEMA EMBEBIDO Siguiendo lo dispuesto hasta el momento en el planteamiento del presente proyecto, para el diseño y programación del sistema embebido que conforma la red de motes surgen necesidades que ya se han planteado con anterioridad y que se han de trasladar y resolver en el mundo embebido. También surgen necesidades específicas como puede ser el tratamiento de los sensores, la gestión de eventos asíncronos…etc. La siguiente lista presenta los requisitos que se plantean en ambos ámbitos con carácter general:  El software embebido debe permitir gestionar las tramas de datos en el mismo sentido que el sistema local, generando tramas de asociación y sensado.  El software embebido debe realizar una gestión eficiente de la energía consumida por los motes, promoviendo modos de bajo consumo.  El diseño de los motes debe ser flexible para permitir múltiples aplicaciones sin tener que modificarlos sustancialmente.  El hardware debe ser eficiente energéticamente, pues pueden darse aplicaciones en las que la alimentación dependa de baterías. 6.4. - SISTEMA SERVIDOR Los requisitos principales que se plantean son los relacionados con aplicaciones web, en los que podemos destacar, seguridad, disponibilidad y escalabilidad. La seguridad se puede plantear a distintos niveles, pero en un nivel básico o inicial, se debe implementar un mecanismo de autenticación para los usuarios. La autenticación consiste en que un usuario introduce unas credenciales, que generalmente son un usuario y una contraseña, que se validan contra un mecanismo de gestión de usuarios, ya sea LDAP, base de datos, fichero de texto…etc. La disponibilidad indica el grado de respuesta que tiene una aplicación web corriendo en un servidor de aplicaciones frente a eventos anómalos. Supongamos que ubicamos nuestro servidor de aplicaciones en una zona donde se producen frecuentes terremotos y como consecuencia cortes en el suministro eléctrico y telefónico. La disponibilidad de nuestro servidor para ser accedido tiene una probabilidad muy baja de ser aceptable. Sin embargo, ubicándolo en un Data Center con unas condiciones ambientales controladas y con Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 32 a punto a todos los nodos de la red. Esta topología es más escalable y ofrece mayores oportunidades para el ahorro energético, pues la comunicación no está centrada en un único nodo.  Agrupación de árboles Un coordinador es nombrado como el coordinador PAN de toda la red. No obstante, cualquier nodo puede actuar como coordinador y proporcionar sincronismo a otros nodos. El estándar no define como construir el árbol, solo indica que es posible y que debe ser inicializado en capas superiores. Para sistemas complejos, es posible formar una red de múltiples árboles vecinos. Desde el punto de vista físico, 802.15.4 ofrece tres bandas operacionales: 2.4Ghz, 915Mhz y 868Mhz. Hay un único canal en la banda de los 868 Mhz, 10 canales en la de 915 Mhz y hasta 16 canales en la banda de 2.4 Ghz. Los baudrates que se manejan para la banda de 2.4 Ghz pueden alcanzar los 250Kbps, 40Kbps para la banda de los 915 Mhz y 20 Kbps para los 868 Mhz. Como características que ofrece la especificación 802.15.4 en capa física se pueden destacar las siguientes:  Activación y desactivación del transceptor de radio El transceptor de radio puede trabajar en tres estados: transmitiendo, recibiendo o durmiendo. Cuando la capa MAC realiza una solicitud, la radio es activada o desactivada según la necesidad.  Detección de energía de recepción Es una estimación de la potencia de la señal recibida.  Indicación de la calidad del enlace Caracteriza la relación fuerza/calidad de la señal recibida en un enlace.  Selección del canal En cuanto al mecanismo de acceso al medio, sin entrar en detalles cuantitativos, podemos decir que emplea una técnica denominada CSMA-CA (carrier sense multiple access collision avoidance) lo que traducido viene a ser, acceso múltiple con detección de portadora, evitando colisiones de paquetes. A grandes rasgos el funcionamiento es el siguiente: un transceptor cuando tiene información para transmitir, lo que hace en primera instancia es escuchar el medio para detectar si alguien está transmitiendo. En caso de que determine que hay alguien transmitiendo, espera un tiempo aleatorio dentro de un rango de valores, y realiza el mismo proceso de detección. Este proceso se repite hasta que encuentra el medio desocupado y realiza una transmisión corta o solicitud de envío, para activar al receptor y ver si está disponible para recibir. De esta forma, las estaciones cercanas detectarán esa transmisión corta y no transmitirán. Si el receptor está disponible para recibir, envía una confirmación al transmisor para que inicie la transmisión efectiva. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 33 7.1.2.4.- LA SOLUCIÓN A LA RED DE MOTES Una vez analizadas las opciones más razonables para implementar la red de dispositivos inalámbricos que confirmarán el sistema de medida y control, parece que lo que más adecuado por sus características, es el empleo de la tecnología IEEE 802.15.4, con la siguiente relación de justificaciones:  El consumo energético es bajo en relación a la tecnología WLAN.  El coste monetario de los transceptores 802.15.4 es menor que los WLAN y bluetooth.  Realiza una gestión de la transmisión que evita colisiones en el mismo sentido que la tecnología WLAN detecta las colisiones.  Permite varias topologías, lo que da una flexibilidad que Bluetooth no permite.  Las distancias que se alcanzan son razonables sin un incremento exagerado del consumo, como ocurre con Bluetooth o WLAN.  Permite un estado de sueño para los transceptores, de forma independiente, en contraposición a Bluetooth, que es el maestro quién establece los criterios de sueño. Habiendo determinado que posiblemente IEEE 802.15.4 sea la mejor solución, ahora queda por elegir alguno de los dispositivos que existen en el mercado. A continuación se describen algunos de los transceptores comerciales que encajarían en nuestro diseño. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 34 7.2.2.- TRANSCEPTORES 7.2.2.1.- ST MICROELECTRONICS SN260 Es un controlador que implementa las capas física y MAC para el estándar 802.15.4, y además es compatible con ZigBee, para la banda de los 2.4 Ghz. Permite el control por un host externo o microcontrolador a través de conexiones SPI o UART y dispone de periféricos y memoria integrados para minimizar el uso de componentes externos. Proporciona tres modos de funcionamiento:  Idle o ausente: Modo de funcionamiento normal donde el transceptor permanece activo a la espera de recibir o enviar información.  Deep sleep: Modo de sueño en el que se desactivan la mayoría de bloques integrados en el transceptor, dejando activas las funciones críticas. El regulador interno se desactiva y todas las salidas se congelan en el estado en el que estaban justo antes de entrar en este modo. Para sacar al dispositivo de este estado a un modo activo, se puede lograr mediante un evento temporizado o una señal externa. El consumo se reduce entorno al microamperio.  Power down: Funciona idénticamente al modo deep sleep pero en este caso el bloque del timer permanece desactivado de tal forma que la única posibilidad de cambiar a un estado activo, es mediante una señal externa. El consumo se reduce entorno al microamperio. Dispone de un bloque acelerador para encriptación AES así como funciones de capa MAC implementadas en hardware para cumplir con requisitos de timing estricto. El transceptor, internamente se alimenta a 1.8 V, y el sistema de alimentación externo recomendado debe proporcionar entre 2.1V y 3.6 V. El consumo en condiciones estándar de 1.8V de alimentación interna, a una temperatura de 25ºC y a potencia máxima, está en 36mA tanto en transmisión como en recepción. El encapsulado es un QFN de 40 pines de 6 x 6 mm. 7.2.2.2.- TEXAS INSTRUMENTS CC2420 Se trata de un transceptor que implementa capa física en la banda de 2.4 Ghz con soporte para capa MAC. Implementa un bloque SPI para el control y comunicación con microcontrolador externo. Dispone de un regulador integrado al que hay que proveerle de una tensión externa entre 2.1 y 3.6 V. Implementa múltiples funciones de capa MAC en hardware tales como, generador de preámbulo automático, generación y comprobación del checksum, RSSI, LQI y encriptación AES. El consumo tanto en transmisión como en recepción está por debajo de los 20 mA. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 35 Dispone de tres modos de operación:  Regulador de tensión off: En este estado se puede considerar que el transceptor está completamente apagado con un consumo de 0.02 uA.  Power down: Con un consumo de 20 uA, donde el oscilador interno está deshabilitado como también las colas de transmisión y recepción y la memoria interna.  Idle: Con un consumo de unos 430 uA. El encapsulado es un QLP de 48 pines de 7 x 7 mm. 7.2.2.3.- DIGI XBEE Se trata de un bundle de componentes que en conjunto implementan la especificación IEEE 802.15.4 con el añadido de un sistema conversor A/D para funcionamiento autónomo. El formato físico es atractivo para prototipos ya que el encapsulado no requiere de soldadura de precisión. En principio se presenta en las tres bandas de funcionamiento: 868 Mhz, 915 Mhz y 2.4 Ghz, con lo que cubre todas las necesidades. Además se presentan en varias potencias de transmisión: 1 mW, 2 mw, 50 mW, 60mW y 100 mW, lo que permite ajustar con precisión el producto a la necesidad. En cuanto a la interfaz con controladores externos, únicamente dispone de una UART para transmisión serie, con un modem interno que permite configurar los parámetros de funcionamiento mediante comandos AT. Dispone de dos formatos de transmisión de información:  Modo transparente: Se envía la información por RF tal y como llega a la UART.  Modo API: Envía la información de forma estructurada en paquetes de datos con comprobación CRC. Dispone de varios modos de bajo consumo configurables bien por hardware o firmware:  Hibernate: Se activa al poner a un nivel alto el terminal Sleep_RQ, así que es activado por hardware. Al activar el terminal, el módulo termina de transmitir y entra en un modo de bajo consumo, en torno a 10 uA y no responde hasta que no se desactiva el terminal.  Doze: Funciona igual que el modo hibernate pero tiene un tiempo de wake up menor y un consumo mayor, sobre los 50 uA.  Cyclic: Se configura únicamente en el firmware y permite que el transceptor duerma periódicamente, con un ciclo de sueño fijado por un parámetro configurable. El rango de alimentación está entre 2.8 V y 3.4 V y el consumo en general está sobre los 45 mA en transmisión y 50 mA en recepción, en condiciones de alimentación de 3.3V y para el caso de transceptor de 1mW. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 36 7.2.2.4.- ELECCIÓN DEL TRANSCEPTOR Una vez vistas las características de algunos modelos comerciales de transceptores IEEE 802.15.4, se ha decidido que para los propósitos de prototipado, la solución más sencilla desde el punto de vista de montaje físico es el empleo de los módulos XBee, ya que no requieren de soldadura de precisión, como en el resto de casos analizados, cuyos encapsulados SMD, dificultarían notablemente el montaje de los prototipos. En cuanto a la interfaz que ofrece es más que suficiente para trabajar con microcontroladores sencillos, ya que la gran mayoría disponen te uno o varios bloques UART. La flexibilidad que ofrecen en cuanto a la gama de potencias de transmisión y la posibilidad de mezclar transceptores de diferentes potencias en una misma red, puede ser útil a la hora de resolver problemas en casos en los que las distancias o las atenuaciones sean mayores de lo previsto. El interfaz de programación es relativamente sencillo y en el caso API, las tramas de datos están bien definidas a alto nivel y únicamente se requiere la elaboración del software necesario para generar y reconocer las tramas especificadas, por lo que no existe la necesidad de trabajar con un stack complejo para IEEE. Los modos de sueño que ofrece son suficientes para la mayoría de aplicaciones y aunque el consumo es sensiblemente mayor que el resto, se compensa con la facilidad de montaje y programación, que en términos de coste de proyecto son ventajosos. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 37 7.2.3. - MICROCONTROLADORES Dentro del desarrollo de los motes, el otro elemento principal, junto al transceptor wireless, es el microcontrolador. Éste ejecuta el programa que hace que un mote funcione y esto incluye generar las tramas de datos para envío, parsear las tramas que se reciben, realizar tareas temporizadas, realizar conversiones A/D o responder ante eventos externos, entre otras posibles tareas. Existen microcontroladores con arquitecturas Von-Neumann y con arquitectura Harvard, con un elevado número de instrucciones (CISC) o con un conjunto pequeño (RISC), con anchos de palabra de 8 bits hasta 32 bits y con una memoria interna de centenas de bytes hasta centenas de Kilobytes, por lo que la gama es amplia, y debemos restringir el conjunto a la necesidad concreta. Para la aplicación en concreto, los aspectos a alto nivel más a tener en cuenta son los siguientes:  Curva de aprendizaje “rápida”.  Disponibilidad de herramientas para desarrollo (compilación, programación y depurado).  Disponibilidad de librerías testadas y posibilidad de crear nuevas. En un nivel inferior, hay que contemplar las necesidades de los motes, que desde un punto de vista genérico pueden ser las siguientes:  Conversor A/D integrado, para minimizar coste, con una resolución adecuada.  Sistemas de temporización o timers, para realizar tareas periódicas.  Bloque de comunicaciones serie, para poder emplear el transceptor 802.15.4 elegido.  Bajo consumo de potencia y alimentación a tensiones adecuadas y concordantes con el transceptor inalámbrico, para evitar usar dos sistemas de alimentación.  Disponibilidad de encapsulados DIP de fácil montaje para prototipado. A todo esto y con carácter personal se van a plantear algunos requisitos que, aunque a priori no están dentro de los requisitos técnicos, se verá que son una valiosa ayuda:  Herramientas de desarrollo open source y open hardware, lo que evita tener que pagar licencias en elementos como compilador, entorno de desarrollo software o dispositivo de programación para el microcontrolador, además de proveer de librerías testadas por comunidades de desarrolladores de todo el mundo con un buen soporte en internet.  Herramientas multiplataforma, para permitir al ingeniero, desarrollador...etc, moverse libremente en el entorno que más cómodo se sienta. Dados los requisitos de interfaz con el transceptor wireless, el microcontrolador debe incluir al menos un bloque UART para la transmisión de información. En cuanto a rangos de alimentación, como ya se ha mencionado, sería bueno que el microcontrolador tuviera un rango similar o que menos incluyera el que ofrece en transceptor, que está en torno a los 3 V. En cuanto a la velocidad del clock no existen requisitos especiales. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 38 7.2.3.1.- ATMEL Atmel fabrica una familia de microcontroladores denominada AVR, que van desde microcontroladores de 8 hasta 32 bits, pasando por los recientes XMEGA de 16 bits. Atmel, al igual que Microchip, basa el diseño de sus dispositivos en una arquitectura Harvard, con memoria y buses separados para instrucciones y datos, para maximizar el paralelismo mediante etapas de pre-fetch. El conjunto de instrucciones, aunque todavía se encaja en RISC, tiene más instrucciones, en torno a 130, que su competidor Microchip. No obstante, la mayoría de ellas solo requieren de un ciclo de reloj para ejecutarse, mientras que el ciclo de ejecución en un microcontrolador PIC típico, es de cuatro ciclos. Una característica importante es que los dispositivos de una misma familia, son intercambiables en el sentido en que el software no cambia si cambia el microcontrolador, siempre que no se cambie de familia. Los periféricos integrados más comunes son los siguientes:  Bloques de comunicaciones I2C, SPI y USART.  Conversor A/D de 10 bits por aproximaciones sucesivas, con varias entradas multiplexadas.  Bloques de contaje (capture), temporización (timers) y PWM.  Entradas de interrupción externa específicas y generales. Disponen de seis modos de bajo consumo, lo que supone una gran flexibilidad a la hora de elegir un modo, en función de la necesidad concreta. En estos modos, el consumo se reduce hasta la décima de microamperio, dependiendo de la tensión de alimentación. En cuanto al entorno de desarrollo, ATMEL ofrece la herramienta AVR Studio para los microcontroladores de 8 bits y AVR32 Studio para la gama de 32 bits. Esta herramienta es gratuita y permite desarrollar aplicaciones tanto en ensamblador como en lenguaje C, programar usando un programador externo e incluso depurar si se dispone de un debugger. Tiene la desventaja de que solo funciona bajo Windows. No obstante existe una buena cantidad de recursos libres que hacen muy fácil el desarrollo para los AVR. Así podemos indicar que existe un toolchain para AVR totalmente libre, con versiones para Windows (winavr) y para Linux (avr-gcc-toolchain), mediante el cual se puede compilar código C y C++, se puede transferir el programa al microcontrolador e incluso permite depurar. Atmel y otros fabricantes independientes, ofrecen placas de evaluación y desarrollo a precios muy competitivos, lo que minimiza todavía más el coste de desarrollo. 7.2.3.2.- MICROCHIP Microchip fabrica una familia de microcontroladores denominada PIC, que dispone de una importante gama de dispositivos con diferentes prestaciones, que pueden ser empleados en muy diversas aplicaciones. Todos los microcontroladores PIC están unidos por un denominador común, la arquitectura Harvard modificada, y el juego de instrucciones RISC. En la arquitectura Harvard del PIC, el ancho de palabra para los datos es de 1 byte mientras que el ancho de palabra para instrucciones es de 14 bits, lo que permite albergar todas las instrucciones en una sola pala- Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 39 bra, al contrario que en la arquitectura Vonn Neuman, donde pueden existir instrucciones que ocupan dos o más palabras. El conjunto de instrucciones es bastante reducido y oscilan entre 35 instrucciones para los PIC de gama baja y 70 instrucciones para los de gama alta, lo que facilita el aprendizaje. Los PIC integran los bloques periféricos más comunes como:  Módulos PWM con resolución de hasta 10 bits.  Bloques contadores y comparadores, con una resolución de hasta 16 bits.  Conversor A/D integrado de 10 bits y varias entradas multiplexadas.  Comunicaciones medianto I2C, SPI y USART.  Comparadores analógicos programables.  Mútiples entradas para interrupciones externas. Por lo general, disponen de varios modos de bajo consumo, en los que un oscilador interno a 32Khz hace de clock del sistema. Mientras se encuentra en alguno de estos modos, el consumo indicado por el fabricante está en torno a la decena de microamperios, dependiendo de varios factores como la tensión de alimentación y la temperatura. En cuanto al entorno de desarrollo, Microchip ofrece MPLAB, que integra un compilador para ensamblador con la posibilidad de programar los binarios y de similar, no en tiempo real, el código escrito. Este entorno funciona bajo Windows y al tratarse de un freeware, dispone de funcionalidad reducida, en tanto en cuan- to, para los microcontroladores de alta gama hay que adquirir una versión completa de pago. Existe una alternativa libre llamada SDCC (Small Device C Compiler), que entre otros, soporta compilación de código C para PIC16 y PIC18. En cuanto a dispositivos programadores o placas de entrenamiento, hay una gran disponibilidad en el mercado y los precios rondan los 100€-200€. 7.2.3.3.- FREESCALE Freescale ofrece tres familias para microcontroladores de 8 bits, HC08, HCS08 y RS08. En cuanto a arquitectura se desmarca del resto usando un sistema Von Neumann, donde los datos y las instrucciones se ubican en el mismo sistema de memoria y comparten el mismo bus. Así mismo usa un juego de instrucciones CISC amplio, que unido a los varios modos de direccionamiento permite realizar complejas operaciones. De la misma forma que los anteriores, ofrece similares características en cuanto a periféricos en modelos equivalentes, aunque se puede destacar que se ofrecen modelos con características especiales, que han sido fabricados bajo demanda y se han incluido en el catálogo como productos habituales. Los encapsulados que ofrecen no son demasiado adecuados para el desarrollo de prototipos cuando los recursos son limitados, ya que todos tienen formato SMD. En cuanto a la herramienta de desarrollo, Freescale ofrece el conocido CodeWarrior en distintas versiones según el microcontrolador sobre el que se va a desarrollar y con distintas licencias. Tiene la ventaja de que Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 40 en una única aplicación integra todo lo necesario para el desarrollo y programación, además de ofrecer una utilidad de depuración muy potente. Están disponibles versiones que funcionan sobre varios sistemas operativos. 7.2.3.4.- ELECCIÓN DE MICROCONTROLADOR A priori elegir un microcontrolador que se ajuste a la perfección, de tal forma que se aprovechen al máximo los recursos que ofrece, para cubrir las necesidades de la aplicación es una tarea casi imposible, pues siempre nos vemos forzados a elegir un dispositivo que exceda en recursos, dando así un margen para cambios de última hora y posibles mejoras a futuro. En el presente proyecto, el objetivo es construir un prototipo sencillo, por lo que se van a descartar todos aquellos dispositivos que no dispongan de encapsulados insertables, pues la complejidad de fabricación es innecesaria para aportar lo mismo que las versiones THD. Tras este razonamiento quedarían automáticamente descartados los microcontroladores de la familia Freescale. En segundo lugar, debemos tener en cuenta las características de los dispositivos en cuanto a periféricos integrados, consumo, facilidad de aprendizaje...etc. En este ámbito las familias de Atmel y Microchip se encuentran bastante equilibradas, ya que ambas ofrecen un conjunto RISC de instrucciones, permiten varios modos de bajo consumo y los periféricos son similares. Se desmarca por delante Microchip en cuanto a la documentación disponible, que es muy abundante en contenido y ejemplos prácticos, mientras que Atmel delega más en foros y personas anónimas para promocionar y ofrecer soporte en webs como www.avrfreaks.net. Otro punto a tener en cuenta y ciertamente importante, es el coste de desarrollo, es decir, que herramientas hardware y software son necesarias para realizar la aplicación completa. Tanto Microchip como Atmel ofrecen herramientas de programación propias de forma gratuita, MPLAB y AVR Studio cuyas características son similares: compilan asm y c, permiten programación y depurado. No obstante ambas funcionan bajo sistemas Windows, lo que obligaría a tener una licencia de sistema operativo. Con el objetivo de minimizar los costes todavía más, se va a usar como estación de desarrollo un PC corriendo un sistema operativo Linux, de tal forma que las herramientas anteriores no nos sirven. Microchip tiene algunas alternativas libres en internet pero no parecen realmente fiables, pues la mayoría no están actualizadas como YaPIDE, un entorno de desarrollo para PIC o GPUtils, un toolchain igualmente para PIC. Sin embargo Atmel tiene un buen soporte de la comunidad de software libre y ello deriva en la existencia de un buen toolchain Avr-gcc-toolchain, que incluye herramientas de compilación (avr-gcc), programación (avr-dude) y librería standard para programación en lenguaje C (avr-libc), actualizado a los nuevos dispositivos y con abundante documentación. Con todo esto, creemos que es motivo suficiente para elegir Atmel como proveedor de microcontroladores para el presente proyecto. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 41 7.3. - SISTEMA LOCAL En la figura 3, en la parte del sistema local se puede apreciar que existe una conexión directa con la red de motes o PAN, lo que permitiría el acceso físico a la red y por lo tanto la gestión a alto nivel del tráfico de datos que por ella circula. Dentro del sistema local, vemos que se está ejecutando un programa que realiza principalmente tres funciones:  Gestiona la red de motes o PAN Desde el punto de vista de la red PAN, se encarga de la gestión de la información que por ella circula, de tal forma que funcionalmente es el router de dicha red ya que toda la información pasa por este punto.  Tiene la capacidad de acceso remoto al mecanismo de persistencia. Toda la información relevante que circula por la red es almacenada, pero este almacenamiento no puede ser local, pues violaría una de las premisas, la accesibilidad de la información desde el exterior. Por ello, cada uno de los sistemas locales, tiene acceso directo al mecanismo de persistencia, que puede y debe estar alojado en una ubicación segura y diferente a la del sistema local. Cabe destacar que es necesaria una conexión activa a internet, pues es la única forma de lograr este requisito a un coste razonable.  Realiza la función de servidor punto a punto, con el servidor de internet. Este es uno de los puntos clave que permite que la red de motes sea controlada desde cualquier terminal, es decir, que los motes con funciones de control, sean accesibles desde el exterior. Analicemos esto con un poco más de detalle. Si por ejemplo, queremos que un usuario en una ubicación A, sea capaz de controlar el sistema de iluminación, situado en una ubicación B, tiene que ser capaz de acceder justo hasta el mote o motes que se encargan de ello. Este es un camino largo y con varios obstáculos. Uno de los principales requisitos para lograr esto es que tanto el usuario como nuestro sistema deben ambos, estar accesibles a internet. Esto es relativamente sencillo. Ahora bien, si pensáramos en acortar el camino, lo más directo sería que el cliente accediera directamente al sistema local, de tal forma que el sistema local sería realmente un servidor de internet en sí mismo. Esto no es aconsejable por los siguientes motivos entre otros: o El sistema local debería entonces disponer de una IP pública fija, lo que implica un coste adicional en el ISP. o El sistema hardware que alberga el sistema local, debe ser capaz de correr un servidor web. o Este servidor web, debe permitir características avanzadas como autenticación, para evitar que un usuario no autorizado acceda al sistema. Únicamente con los motivos anteriores, ya se hace desaconsejable esta solución, que a priori podría parecer interesante. Una verdadera solución sin coste añadido y que permite el acceso desde el exterior para realizar tareas de control, podría pasar por el uso de un servidor remoto. Un servidor remoto actúa como un servidor de internet en cuanto a la accesibilidad, pero no atiende a peticiones web tradicionales, sino que usa un mecanismo de comunicación basado en el paso de objetos desde el cliente al servidor y viceversa. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 48 FIGURA 6 Por lo tanto en los flancos de subida y bajada de dicha señal, se producirán los sincronismos que pueden ser tratados como interrupciones. Esto tiene una ventaja, y es que se consigue una buena precisión en los disparos, pues una interrupción tarda aproximadamente 1 uS en entrar en la rutina asociada. La señal cuadrada se aplicará a un pin dedicado al tratamiento de interrupciones de tal forma que su prioridad sea elevada para no perder el sincronismo cuando acontecen otras interrupciones, retrasando las de menor prioridad. Como se ha analizado, esta interrupción se ha de generar tanto con flancos de subida como de bajada y por lo tanto se ha de configurar para disparar con el cambio (toggle). La implementación de la rutina que gestiona los pasos por cero de la red y la rampa de contaje del ángulo de disparo, se encuentran en el apartado 3.2.7.- Mote dimmer, del documento Anexos. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 49 7.4.2. – HARDWARE 7.4.2.1.- COORDINADOR El elemento principal de la red 802.15.4 es el transceptor que actúa como coordinador, siendo el dispositivo encargado de crear la PAN, seleccionando un PAN ID y un canal libres. Como ya se ha mencionado anteriormente, éste debe ir conectado directamente al sistema local de tal forma que exista una vía de comunicación serie entre ambos. En un compromiso entre coste, sencillez y fiabilidad, se ha empleado el mecanismo más sencillo de conexión directa entre un dispositivo USART y un puerto USB, un cable USB de cinco terminales y un adaptador Serie-USB. Se ha decidido emplear un conector Mini-USB A en la PCB, para minimizar el volumen. FIGURA 7 Inicialmente, la corriente máxima que puede suministrar un puerto USB está limitada sobre los 500mA, aunque esto no es un problema, pues el consumo máximo del transceptor XBee que hará de coordinador está en torno a 50 mA. No obstante a esto habrá que sumar el consumo correspondiente al propio adaptador Serie-USB, así como el de los dispositivos indicadores instalados. Como dispositivo adaptador Serie-USB, se ha empleado el conocido FT232RL fabricado por FTDI Chip, que proporciona una interfaz sencilla y drivers para los sistemas operativos más relevantes. Así mismo dispone de una versión con encapsulado SSOP de 28 pines, lo que facilita el proceso de soldadura manual. VBUS 1 D- 2 D+ 3 NC 4 GND 5 J1 440247-1 F1 500mA PTC GND Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 50 FIGURA 8 Cabe destacar que en esta versión de la PCB para el coordinador, se han añadido indicadores luminosos tal y como se puede apreciar en el fragmento de esquema anterior. Así pues, encontramos diodos led para indicación de alimentación, para transmisión y recepción, indicación de RSSI e indicador de asociación. Información ampliada y cálculos, se encuentra en el apartado 2.1.2.- Comunicación, del documento Anexos. La alimentación del FT232RL es proporcionada por el propio puerto USB a través de uno de los cinco terminales del cable y para la alimentación del transceptor XBee se ha empleado un regulador lineal fijo, con una salida de 3.3 voltios. El dispositivo empleado es el TPS79333 de Texas instruments, que se trata de un regulador lineal de muy bajo drop-out(unos 112mV a 200mA), una corriente de polarización de unos 120 uA y una salida en corriente de 200mA máximo, más que suficiente para alimentar los XBee de la serie PRO. FIGURA 9 Información ampliada y cálculos, se encuentra en el apartado 2.1.1.- Alimentación, del documento Anexos. DIO0 20 VCC 1 DOUT 2 DIN 3 DIO8 4 /RESET 5 RSSI 6 PWM1 7 RESERVED 8 /DTR 9 GND 10 DIO4 11 /CTS 12 /SLEEP 13 VREF 14 DIO5 15 /RTS 16 DIO3 17 DIO2 18 DIO1 19 Xbee XBee serie 1 TX 1 DTR# 2 RTS# 3 VCCIO 4 RXD 5 RI# 6 GND 7 NC 8 DSR# 9 DCD# 10 CTS# 11 CBUS4 12 CBUS2 13 CBUS3 14 USBDP 15 USBDM 16 3V3OUT 17 GND 18 RESET# 19 VCC 20 GND 21 CBUS1 22 CBUS0 23 NC 24 AGNG 25 TEST 26 OSCI 27 OSCO 28 U1 FT232RL VBUS 1 D- 2 D+ 3 NC 4 GND 5 J1 440247-1 F1 500mA PTC DOUT DIN DIO8 RST# RSSI PWM1 RSVD DTR# DIO4 CTS# SLEEP# VREF DIO5 RTS# DIO3 DIO2 DIO1 DIO0 GND DIN DOUT VCC D2 LED RED 330 R1 0.1uF C1 GND GND GND GND RXLED TXLED 0.1uF C2 GND D3 LED YELLOW 330 R2 330 R3 RXLED TXLED D1 LED RED GND VCC GND DTR# RTS# CTS# GND 3V3 3V3 D4 LED YELLOW 330 R4 GND RSSI D5 LED YELLOW 330 R5 GND DIO5 IN 1 GND 2 EN 3 NR 4 OUT 5 U3 TPS79333DBVR GND 0.1uF C3 GND 0.01uF C4 GND GND VCC C5 10uF 3V3 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 51 7.4.2.2. - MOTE BASE El mote base es la estructura electrónica que da el soporte necesario en cuanto a procesamiento y comunicación y además es la estructura mecánica que permite la ubicación de las PCB funcionales. Principalmente consta de los siguientes bloques:  Bloque de potencia: formado por los sistemas de alimentación y por el sistema de carga de las mismas.  Bloque de procesamiento: formado por el microcontrolador y los elementos pasivos necesarios para su funcionamiento.  Bloque de comunicación wireless: formado por el transceptor XBee e indicadores funcionales.  Bloque de comunicación USB: formado por un adaptador Serie-USB, empleado para la programación del microcontrolador. Se ha desarrollado una nueva versión del mote base que mejora el diseño anterior, ofreciendo mejores características y funcionalidades. Los principales puntos de mejora son los siguientes:  Se ha sustituido el regulador lineal que alimentaba a todo el sistema por un sepic/flyback con una eficiencia superior al 90% y que proporciona 3.3V configurados mediante resistencias y 1100 mA.  Se ha añadido indicador de asociación para el transceptor XBee, que indica si el mote se ha asociado correctamente a la red.  Se ha añadido un bloque de cuatro interruptores que permiten configurar el transceptor XBee a través del microcontrolador.  Se ha incorporado un mecanismo para el reset automático del mote, que lo habilita para reprogramar el firmware inalámbricamente, usando el transceptor XBee.  Se ha añadido un interruptor para desconectar la batería sin tener que desenchufarla del mote. BLOQUE DE POTENCIA El sistema de alimentación del mote está formado por un SEPIC/Flyback, el TPS61131 de Texas Instruments. Este dispositivo proporciona dos salidas para alimentación, una a partir de un Buck/Boost y otra a partir de un regulador líneas LDO. Como se ha indicado una de las mejoras ha consistido en mejorar la eficiencia del sistema de alimentación y por ello se ha empleado la configuración Buck/Boost que indica la figura. La tensión necesaria para el sistema son 3.3V, que van tanto al microcontrolador y al transceptor XBee como a los sensores y actuadores que van instalados en las PCB funcionales. Para ello, se ha configurado al TPS61131 con el par de resistencias R8 y R9 con los valores indicados en el esquema, obteniendo una salida en Vout de 3.3V. Información ampliada y cálculos, se encuentra en el apartado 2.2.1.- Alimentación, del documento Anexos. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 52 FIGURA 10 Por otro lado está el sistema encargado de cargar las baterías, formado por el MAX 1555 de Maxim, que se trata de un cargador de baterías de ión-litio (L+) de una celda, que puede realizar el proceso de carga desde un terminal USB o una fuente de alimentación. En la implementación se ha usado un conector de barril para una fuente de alimentación externa. Incorpora un indicador de carga, que se activa cuando la batería está en proceso de carga, indicándose el hecho por medio de un diodo led activo. FIGURA 11 FB 15 SWN 2 SWP 1 LDOOUT 10 VBAT 4 LBI 5 VOUT 16 LDOIN 9 PGND 3 GND 12 LBO 13 LDOSENSE 11 PGOOD 14 EN 7 SKIPEN 6 LDOEN 8 U3 TPS61131 GND 1 3 4 2 L1 DRQ74 220R SWN SWP GND SWN SWP 10uF C11 GND VBAT 10uF C12 GND VBAT 1M R6 390K R7 GND VBAT VBAT VBAT 180K R9 1M R8 1MR10 1MR11 VCC 2.2uF C13 C14 100uF GND VOUT VOUT Cgnd Cgnd USB 1 GND 2 CHG 3 DC 4 BAT 5 U2 MAX1555 D1 LED 330 R2 GND 1uF C2 GND 1uF C3 GND VBAT VBAT 5V 1uF C4 GND 1 2 3 J2 PWR2 GND Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 53 BLOQUE DE PROCESAMIENTO Este bloque está formado por el microcontrolador y los elementos pasivos necesarios para el funcionamiento básico. Los microcontroladores AVR tienen la ventaja de que apenas necesitan componentes externos para funcionar y en este caso se han empleado un cristal de cuarzo que resuena 8Mhz, con dos condensadores para el circuito interno del oscilador, las conexiones de alimentación y masa. FIGURA 12 Adicionalmente y siendo necesario, se ha incluido un sistema de reset manual, formado por el típico circui- to de reset con pulsador, resistencia y condensador. FIGURA 13 Para contemplar la funcionalidad de programación remota del firmware del microcontrolador, es necesario un mecanismo para que el microcontrolador pueda auto resetearse, activando alguno de sus terminales. Para esto se ha empleado un switch CMOS, el ADG719 de Analog Devices, que funcionalmente es un multiplexor de dos entradas y una salida controlado digitalmente. Es usado para seleccionar la fuente de reset, es decir, por defecto o en condiciones normales, el reset viene dado por interruptor manual pero cuando cambia el estado del terminal de control a nivel lógico 1, el reset está conectado a masa, por lo que se resetea automáticamente. Como terminal de control se ha empleado el terminal ICP del microcontrolador. 21 21 S2 O m r o n t y p e B 3 F GND V C C 10K R1 R S T M 100nF C1 D T R PC6 (RESET) 1 PD0 (RXD) 2 PD1 (TXD) 3 PD2 (INT0) 4 PD3 (INT1) 5 PD4 (XCK/T0) 6 VCC 7 GND 8 PB6 (XTAL1/TOSC1) 9 PB7 (XTAL2/TOSC2) 10 PD5 (T1) 11 PD6 (AIN0) 12 PD7 (AIN1) 13 PB0 (ICP) 14 PB1 (OC1A) 15 PB2 (SS/OC1B) 16 PB3 (MOSI/OC2) 17 PB4 (MISO) 18 PB5 (SCK) 19 AVCC 20 AREF 21 GND 22 PC0 (ADC0) 23 PC1 (ADC1) 24 PC2 (ADC2) 25 PC3 (ADC3) 26 PC4 (ADC4/SDA) 27 PC5 (ADC5/SCL) 28 U1 ATmega168 ICP OC1A OC1B MOSI MISO SCK XTAL1 XTAL2 RXD TXD INT0 INT1 T0 T1 AIN0 AIN1 ADC0 ADC1 ADC2 ADC3 ADC4 ADC5 RST VCC GND AREF VCC 100nF C7 GND 20pF C8 GND AREF XTAL1 XTAL2 20pF C9 20pF C10 GND GND 1 2 Y1 XTAL Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 54 FIGURA 14 BLOQUE DE COMUNICACIÓN 802.15.4 Este bloque lo conforma el transceptor XBee con la configuración que muestra la figura. FIGURA 15 Se ha incorporado un led indicador de asociación y un bloque de cuatro interruptores, de los que dos estarán siempre en una posición de paso, RX y TX, pues son los necesarios para realizar la transmisión de datos, los otros dos irán in función de los requisitos del mote concreto. Concretamente se han configurado los terminales SLEEP y SLEEP/RQ para controlar manualmente el estado de activación del transceptor XBee. Habitualmente este dispositivo funcionará en un modo de sueño cíclico, en el que cada cierto tiempo configurado en el firmware, se despertará para ver si tiene información que enviar o recibir, volviendo al estado de sueño posteriormente. Pero puede ocurrir el caso en el que el mote sea totalmente autónomo, es decir, que solo envíe información, no la reciba. En ese caso, se puede realizar un control del consumo del XBee de forma manual, configurando los terminales INT0 y SCK del microcontrolador por medio del software, para hacer que prácticamente consuma la corriente de polarización. Información ampliada y cálculos, se encuentra en el apartado 2.1.1.- Alimentación, del documento Anexos. BLOQUE DE COMUNICACIÓN USB Al igual que el coordinador, el mote base dispone de conectividad USB por medio del adaptador Serie-USB FTDI232RL. En este caso se puede usar para realizar la programación del mote a modo de herramienta de desarrollo, ya que el microcontrolador incorpora un bootloader que hace innecesario el uso de un programador dedicado. 1 2 3 4 5 6 U5 ADG719 ICP RST GND VCC RSTM GND DIO0 20 VCC 1 DOUT 2 DIN 3 DIO8 4 /RESET 5 PWM0 6 PWM1 7 RESERVED 8 Sleep/RQ 9 GND 10 DIO4 11 /CTS 12 /SLEEP 13 VREF 14 DIO5 15 /RTS 16 DIO3 17 DIO2 18 DIO1 19 Xbee XBee 1B2 VCC RXD TXD GND 6 54 3 1 8 2 7 S3 A6H-4101 Sleep Sleep SCK INT0 D3 LED 330 R12 GND RSTM Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 55 FIGURA 16 Información ampliada y cálculos, se encuentra en el apartado 2.1.1.- Alimentación, del documento Anexos TX 1 DTR# 2 RTS# 3 VCCIO 4 RXD 5 RI# 6 GND 7 NC 8 DSR# 9 DCD# 10 CTS# 11 CBUS4 12 CBUS2 13 CBUS3 14 USBDP 15 USBDM 16 3V3OUT 17 GND 18 RESET# 19 VCC 20 GND 21 CBUS1 22 CBUS0 23 NC 24 AGNG 25 TEST 26 OSCI 27 OSCO 28 U4 FT232RL VBUS 1 D- 2 D+ 3 NC 4 GND 5 J1 440247-1 F1 500mA PTC GND RXD TXD 5V 0.1uF C5 GND GND GND GND RXLED TXLED 0.1uF C6 GND DTR# RTS# CTS# RSTM Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 56 7.5. - SISTEMA SERVIDOR Hasta ahora ya tenemos solucionados los problemas de la red de motes y de los sistemas locales pero queda el tercer gran bloque, que permite almacenar la información importante y hacerla accesible a los usuarios. Este bloque se denominará sistema servidor e integra dos elementos, un servidor de aplicaciones y un servidor de base de datos. Por lo general y como norma, estos servidores nunca se van a encontrar físicamente en una instalación local por motivos de seguridad, mantenimiento y accesibilidad. Este sistema en conjunto permite que los usuarios de los sistemas locales instalados, puedan acceder a información sobre el estado de dichos sistemas así como realizar sencillas tareas de control desde una conexión a internet. 7.5.1.- SERVIDOR DE APLICACIONES Uno de los elementos principales del sistema servidor es el servidor de aplicaciones. Un servidor de aplicaciones permite la ejecución de un programa específicamente diseñado para trabajar en entorno de internet y por lo tanto accesible desde un navegador web. La función principal de un servidor de aplicaciones es la de recibir peticiones http en los formatos que establece la norma http://www.w3.org/Protocols/rfc2616/rfc2616.html y responder al solicitante con la información requerida lo más rápidamente posible. Esto que parece sencillo se convierte en un verdadero problema cuando tenemos miles de usuarios haciendo peticiones cada pocos milisegundos y se ha de responder sin perder efectividad. Afortunadamente, en la actualidad existen numerosos servidores de aplicación en los que los aspectos de concurrencia están muy depurados y el rendimiento aumenta conforme aumentan las peticiones. Una de las tareas es pues elegir un servidor de aplicaciones que encaje dentro de los objetivos del presente proyecto en cuanto a coste, filosofía open source..etc. El estándar open source para servidores web es Apache Server, de la Apache Software Foundation, que tiene una larga tradición como servidor HTTP desde pequeños sistemas hasta grandes servidores. Tiene una arquitectura basada en plugins, lo que lo hace muy modular, activando solo las que sean necesarias y así por ejemplo dispone de plugins para SSL,autenticación, cachè, filtros o LDAP. Ahora bien un servidor web está pensado para realizar las tareas de gestión a bajo nivel de las peticiones HTTP y las respuestas asociadas, no para formar un sistema completo por sí mismo. Teniendo en cuenta que la aplicación del lado del servidor va a ser desarrollada usando la tecnología JAVA para aplicaciones web, necesitamos algo más. La especificación JAVA para la web está formada por dos elementos principales, Servlets y JSP. Un servlet puede ser entendido como un elemento de servidor que tiene asociada una dirección web y que está encargado de responder las peticiones HTTP sobre esa dirección. Teniendo en cuenta que un servidor puede recibir miles de peticiones simultáneas sobre una misma dirección, la especificación indica que existirá una instancia de un servlet concreto por cada petición, eliminando los problemas derivados de la concurrencia. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 57 Por otro lado tenemos la tecnología JSP, que básicamente se emplea para la creación de páginas web dinámicas. Una página HTML dinámica es creada a partir de cierta información generada en el momento de recibir la petición, como puede ser un listado de motes en nuestro caso. Dispone de elementos muy útiles para usar objetos Java que son pasados a las JSP como iteradores de listas, utilidades de formateo de datos, bloques de control…etc. Con esto ya tenemos la infraestructura necesaria para generar el contenido dinámicamente, pero queda resolver cómo se trasladan las peticiones HTTP del servidor de aplicaciones hasta un Servlet en concreto. Para esto es necesario y así lo indica la especificación web de JAVA, lo que se conoce como un contenedor de Servlets, es decir, una aplicación que está por encima del servidor HTTP y que es capaz de ejecutar los Servlet cada vez que procesa una petición. Nuevamente la opción más robusta, open source y de los desarrolladores de Apache, se denomina Apache Tomcat, que es el contenedor de Servlet por excelencia. Existen varias aplicaciones privativas similares a Tomcat pero su coste lo hace inviable para nuestro propósito. 7.5.2.- SERVIDOR DE BASE DE DATOS La otra pieza fundamental para que funcione el conjunto, es la que da soporte al almacenamiento de información. Sin un mecanismo para almacenar datos como, qué coordinador está conectado en cada sistema local, que motes pertenecen a una red y qué roles juega cada mote en función de los dispositivos que tiene instalados, sencillamente nada podría funcionar. Por lo tanto se trata de un sistema vital para el conjunto y que además debe ser eficiente y robusto para no provocar cuellos de botella en el almacenamiento de los datos. Existe un conjunto amplio de servidores de base de datos y los podemos catalogar en dos tipos:  Relacionales: La información se estructura como relaciones entre entidades.  Orientados a objetos: La información se guarda en forma de objetos, tal y como se representan en un lenguaje orientado a objetos. Tradicionalmente, los sistemas más usados son las bases de datos relacionales por la flexibilidad y las herramientas que ofrecen. Es muy importante que ofrezca un bueno conjunto de herramientas, sobre todo las relacionadas con la seguridad y la recuperación de datos ante fallos y eso es a día de hoy una lacra de las bases de datos orientadas a objetos. Las bases de datos orientadas a objetos tienen algunas ventajas, precisamente para los programadores orientados a objetos:  No es necesaria una capa objeto-relacional para realizar la persistencia.  Pueden considerarse más rápidas pues las relaciones son punteros, no filas y columnas. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 64 4. Gestión de actuadores Este caso de uso está reservado al Administrador, pues trata de gestionar los actuadores que admite el sistema, de los que depende la instalación física y el buen funcionamiento del sistema de autoconfiguración. Podemos dividir este caso de uso tal y como aparece en el diagrama. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 65 5. Gestión de motes El apartado de gestión de los motes está reservado para el Administrador y el Gestor de red, pues permite realizar operaciones relevantes sobre la red instalada. Por un lado permite la edición de algunos de los datos de los motes, concretamente los que no afectan a su funcionamiento y configuración, pues esto se realiza de forma automática. Se dispone de una opción para resetear la conectividad del mote, sin tener que efectuar un reset manual. También se permite actualizar o modificar el programa que ejecuta el microcontrolador remotamente, sin tener que moverlo de la ubicación final. La gestión de alarmas, permite crear alarmas para los sensores instalados en los motes que disponen de dichos elementos. 6. Monitorización de la red La monitorización de la red es un caso de uso permitido a todos los usuarios de la aplicación, pues no afecta al funcionamiento sino que es una mera consulta del estado de la red. Se puede dividir en dos partes bien diferenciadas. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 66 Por un lado está el caso de uso Históricos, que permite obtener información de los sensores agrupada por espacios temporales, ofreciendo gráficos en formato histograma. Por otro lado está el caso de uso del Monitor en directo, de tal forma que se obtiene información de los sensores en el momento, cada breves intervalos de tiempo. Ambos aspectos se detallan en el apartado 7.5.4.5, monitorización de sensores. 7. Control de actuadores El case de uso Control de actuadores, permite a los usuarios de la aplicación realizar sencillas tareas de control, de acuerdo con la configuración de los motes de la red. Está habilitada para todos los perfiles de usuarios de aplicación. Este aspecto se detalla en el apartado 7.5.4.5, control de actuadores. 7.5.3.5.- VISTA Lo que el usuario ve y con lo que puede interactuar es lo que se denomina vista y en el caso de una aplicación web, son las páginas que se muestran en un navegador. Están directamente relacionadas con los casos de uso antes presentados ya que precisamente esto representa lo que los usuarios pueden hacer. No tiene interés alguno el presentar fragmentos de código JSP y remitimos al lector a visitar las páginas del manual. No obstante cabe destacar dos de las funcionalidades implementadas, la posibilidad de acceder remotamente desde una página web hasta los motes de control instalados en un sistema local, para enviar órdenes y la monitorización de baja latencia para ver el estado de los sensores. Para ver como se ha realizado este apartado, primero hay que ver el camino que recorre la información desde la página web que el usuario ve en el navegador y viceversa, hasta el mote. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 67 1. Monitorización de sensores Este apartado pretende mostrar una serie de gráficas temporales de las medidas de los sensores instalados en un mote concreto. Además se ha pretendido que no sea algo estático, sino que dinámicamente se actualicen los datos mostrados con nuevas medidas, pero sin la interacción constante de usuario, es decir, sin refrescar manualmente la página web. Para conseguir esto inicialmente el usuario accede a una página en la que aparecen una serie de gráficas, cada una relacionada con los sensores del mote que ha seleccionado. Dentro de la página se ha programado un script que periódicamente realiza peticiones automáticas a una dirección web concreta, dentro de nuestra aplicación, de tal forma que le devuelve un conjunto de medidas que son visualizadas en la página. Ciertos detalles relevantes de implementación se encuentran en el apartado 3.3.3.1.- Monitorización de sensores, del documento Anexos. 2. Histórico de datos A parte de la funcionalidad que permite monitorizar en directo a los sensores de la red, se ha implementado una opción para obtener históricos de los datos proporcionados por los sensores. Esto se puede conseguir ya que las medidas de dichos sensores se almacenan en una base de datos. Esta funcionalidad está limitada a la agrupación de datos temporalmente pero se puede extender la funcionalidad para hacer estimaciones de consumo estacional y plantear estrategias de minimización del mismo. Ciertos detalles relevantes de implementación se encuentran en el apartado 3.3.3.2.- Histórico de datos, del documento Anexos. 3. Control de actuadores Para realizar el control de los motes que disponen de actuadores, el flujo de datos va únicamente desde la página web hacia el servidor y finalmente al mote. No por esto es más sencillo que la monitorización, pues desde el servidor web hay que acceder hasta el servidor local y de ahí a la red de motes. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 68 En un primer paso, el usuario interactúa con la página web estableciendo unas nuevas condiciones para el controlador que ha elegido, que pueden ser cambiar el ángulo de disparo de la iluminación de una habitación o subir una persiana. Estos cambios se envían en background hasta el servidor web que genera la información necesaria a partir de los parámetros que llegan, contacta con el servidor remoto y envía los datos de la trama generada. Ciertos detalles relevantes de implementación se encuentran en el apartado 3.3.3.3.- Control de actuadores, del documento Anexos. El caso que se ha implementado en el prototipo es el de control de la iluminación de una bombilla mediante la variación del ángulo de disparo de un tiristor, tal y como se detalla en las secciones 7.4.2.6 y 7.4.3.4. 7.5.3.6.- REGLAS Como se indicó en 7.5.4.4, la aplicación permite la creación de alarmas asociadas a los sensores instalados en los motes, entendiendo por alarma, una condición fuera de lo marcado como normal. En este sentido cabe recordar que cada vez que un mote sensor envía datos al coordinador, se comprueba la existencia de alarmas y si las hay, las ejecuta para comprobar si alguna de ellas se cumple. Hay que distinguir entre lo que es una regla y la ejecución de reglas. Una regla es una condición o conjunto de condiciones a las que se les aplica determinados valores de entrada. La ejecución de una o varias reglas es el proceso por el que a dichas reglas se les aplica un conjunto de valores de entrada, produciendo una salida que determina si se cumplen o no. Desde el punto de vista del usuario de la aplicación, lo que hace es crear las reglas a las que se les aplicarán posteriormente los vectores de entrada con los datos provenientes de los motes sensores, de tal forma que queda por implementar la parte que ejecuta las reglas. En la primera versión del presente proyecto, se creó un motor de ejecución de reglas sencillo, el cual realizaba la comprobación de las reglas creadas con los datos recibidos en una sola pasada de las reglas, es decir si la sensibilización de una regla daba como resultado la sensibilización de una segunda, esta segunda no se llegaba a ejecutar. Como mejora al sistema anteriormente implementado, se ha hecho uso de un auténtico motor de reglas empleando la librería open source, Drools, proporcionada por Jboss. Se trata de un motor de creación, ejecución y gestión de reglas basado en un algoritmo RETE. Un sistema basado en reglas consta de los siguientes elementos:  Motor de inferencia: coordina la información procedente del resto de módulos.  Base de conocimientos: contiene las reglas utilizadas para representar el conocimiento disponible en un determinado dominio.  Base de hechos: contiene los hecho iniciales como los que se van generando.  Interfaz de usuario: a través del cual el usuario puede interaccionar con el sistema. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 69 FIGURA 17: ESTRUCTURA DE UN MOTOR DE INFERENCIA Una regla por lo general consta de dos partes: antecedente o parte izquierda y consecuente o parte derecha. En el antecedente figuran las condiciones que se han de cumplir para que la regla sea sensibilizada. En el consecuente, aparecerán las conclusiones o acciones a desarrollar cuando la regla sea ejecutada. El proceso de inferencia en un sistema basado en reglas consiste en establecer la verdad de determinadas conclusiones a partir de la información que se tiene en la base de conocimiento y en la base de hechos. Es el motor de inferencia el encargado de llevar a cabo dicho proceso, que por lo general puede realizarse de dos formas:  Encadenamiento hacia adelante Se basa en ejecutar aquellas reglas cuyo antecedente es cierto a partir de la base de hechos que hay en el sistema. Por otra parte la introducción de nueva información a partir del consecuente de cada regla ejecutada, permitirá la ejecución de otras reglas.  Encadenamiento hacia atrás Se basa en seleccionar aquellas reglas cuyo consecuente permita demostrar cierta condición, si ésta no puede ser demostrada a partir de la base de afirmaciones. A su vez, las condiciones que figuran en los antecedentes de las reglas seleccionadas volverán a convertirse en nuevos subobjetivos de forma recursiva hasta que se encuentra la información buscada en la base de hechos. Drools emplea un algoritmo mejorado del encadenamiento hacia atrás denominado RETE. La idea que constituye la base de este algoritmo es que , en lugar de buscar qué reglas satisfacen los hechos existentes en cada momento, son los nuevos hechos generados en cada ciclo los que buscan o determinan qué nuevas reglas se seleccionan para una posible ejecución. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 70 8.- CONCLUSIONES El sistema final queda definido por el siguiente esquema en el que se especifica la solución empleada en cada uno de los bloques: FIGURA 18: ARQUITECTURA IMPLEMENTADA  Red domótica La red domótica se ha implementado usando el estándar 802.15.4, que es un protocolo para redes inalámbricas de baja tasa de datos y bajo consumo, de acuerdo con los requerimientos del proyec- to. Como transceptor inalámbrico se ha empleado XBee de Digi, y aunque en la práctica no es el mejor que se puede encontrar, para los propósitos de prototipado es el adecuado.  Motes Los motes o elementos de red a alto nivel, están formados por un microcontrolador Atmel AVR 168P/328P, un transceptor XBee como elementos principales. Disponen de una estructura física modular que permite el acoplamiento de diversos módulos para sensado o control. Su programación está pensada para bajo consumo lo que también los hace adecuados para aplicaciones en redes sensoriales. Además se han implementado opciones importantes como la autoconfiguración de la red o el reseteo de la misma, al nivel de los motes.  Sistema local El sistema local está encargado de gestionar a alto nivel la información que circula por la red de motes. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 71 Esta gestión incluye el manejo de tramas de autoconfiguración, de sensado y control así como la persistencia de forma remota de la información relevante y la detección de alarmas. Se ha implementado mediante un servicio RMI en Java, lo que permite la ejecución de tareas de control desde el exterior.  Sistema servidor El sistema servidor es el clásico Apache Tomcat que engloba las tecnologías de servidor de aplicaciones y contenedor de servlets. Implementa todas las funcionalidades que están accesibles para los usuarios de los sistemas domóticos y para los administradores o gestores de la aplicación global. Tanto Apache Http Server como Apache Tomcat, son tecnologías Open Source y no tienen coste de implantación en cuanto a licencias  Base de datos El sistema de base de datos empleado es el conocido MySQL, que es una solución robusta, probada, con herramientas de administración y soporte de la comunidad open source y que además no tiene coste de licencia. Como conclusiones más personales, podía destacar las siguientes que a continuación se indican. Se ha empleado el transceptor XBee para la realización de la red 802.15.4, principalmente por el encapsulado DIP de fácil prototipado y por la abstracción que ofrece en términos de programación, ya que limita el proceso de comunicación al envío y recepción de tramas estructuradas vía RS232. En ocasiones el comportamiento no es el que parece lógico y la documentación no profundiza en ningún aspecto, ni hardware ni software, lo que dificulta sobremanera el proceso de desarrollo. El coste es elevado respecto a otros transceptores 802.15.4 pero tiene la ventaja de que es intercambiable con los modelos de mayor potencia de transmisión. Para una supuesta producción a gran escala, debería seleccionarse algún otro transceptor de los existentes en el mercado que dan soporte para 802.15.4 y ZigBee, con menor consumo, con un stack de programación que permita controlar los aspectos de bajo nivel y con un encapsulado que permita reducir las dimensiones del mote. El microcontrolador elegido es bastante adecuado a la aplicación, dadas sus características técnicas y la facilidad de programación. No obstante, se debería emplear un modelo con encapsulado TQFP o QFN, que reduce sensiblemente el área ocupada. El proceso de desarrollo se ha hecho sin contar con un depurador de código y aunque no es estrictamente necesario, lo ha ralentizado. Se ha implementado que los motes dispongan de varios mecanismos de alimentación empleando baterías, terminal USB y conector de barril a fuente de alimentación. Esto es innecesario. En el caso de una aplicación domótica como la planteada, una mejor solución teniendo en cuenta el ámbito, habría sido la incorporación de un sistema típico de fuente de alimentación, con mini transformador para PCB en conjunción con un convertidor buck. La mayoría de los motes pueden tomar la alimentación de la red monofásica. En cuanto a los sistemas locales o instalaciones, se ha optado por una implementación de un sistema cliente servidor (RMI) para el control y monitorización de cada una. Esto, para una instalación domótica no es estrictamente necesario, ya que generalmente el usuario va a interactuar con el sistema cuando se encuentre en él. No cabe duda de que es un valor añadido pero quizá la complejidad introducida sea innecesaria. Así mismo el sistema local se ha implementado sobre un ordenador personal, con las ventajas y desventajas que ofrece. En primer lugar la propensión a errores y los reinicios que puede sufrir un PC, influirían no- Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 72 tablemente en el funcionamiento estable del sistema. El PC no se podría parar, ya que el coordinador al está conectado directamente a uno de los puertos USB y si el coordinador desaparece, la red PAN deja de existir. Sería una mejor implementación, y se plantea como mejora, el emplear un Single Board Computer (SBC) o un sistema electrónico que disponga de un microprocesador relativamente potente, de 32 bits y a 500 MHz por ejemplo, que disponga de conectividad Ethernet o WiFi. Si no se desea modificar la programación del sistema local, es necesario el empleo de un microprocesador Intel ya que el sistema de invocación remota RMI, tiene una implementación estable sobre esta arquitectura. Así mismo, sería conveniente incluir un sistema de visualización táctil o un control (mando) avanzado, comunicándose por ejemplo, empleando el propio 802.15.4, con cada uno de los motes. En cuanto al sistema servidor, la solución es bastante correcta aunque la interfaz de usuario se puede mejorar mucho todavía para hacerla realmente usable, principalmente evitando el empleo de palabras técnicas como mote y en lugar de mostrar elementos tabulares, dar la posibilidad de incluir un mapa de la casa, sobre el que se disponen los dispositivos instalados. En líneas generales, la idea de llevar 802.15.4 al campo de la domótica puede suponer grandes ventajas para el desarrollo de una red de dispositivos que interoperan de forma estándar, siempre y cuando se estandaricen capas superiores a las que implementa 802.15.4. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 73 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 7 Dada la tensión proporcionada por el terminal USB, que es de 5 voltios y la salida del regulador de 3.3 voltios, queda un margen de 1.7 voltios, por lo que se ha de emplear un regulador de bajo dropout. Se ha elegido el regulador lineal TPS79333DBVR, que proporciona una tensión de salida no regulable de 3.3V y una corriente máxima de 200mA. La potencia que disipa en el peor de los casos, suponiendo una corriente media de 100mA, aunque ya sabemos que va a ser aproximadamente la mitad: Suponiendo que el módulo del coordinador va a estar generalmente a una temperatura ambiente, en torno a los 25ºC, el fabricante indica en el apartado “Dissipation ratings table” que es capaz de soportar hasta 390 mW sin emplear disipador. Dado que este valor es bastante superior al que se ha calculado, no es necesario el empleo de disipador térmico. Los condensadores externos necesarios son los indicados por el fabricante en el apartado “External capacitor requirements”. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 8 2.1.2. COMUNICACIÓN El segundo bloque está formado por la circuitería necesaria para realizar una transmisión de datos efectiva entre el transceptor XBee y el ordenador al que está conectado. Por lo tanto se hace necesario el empleo de un adaptador Serie-USB. Se ha empleado el conocido FT232R del fabricante FTDI, y la siguiente figura lo ilustra. FIGURA 2: CONFIGURACIÓN DEL ADAPTADOR FT232R Se va a emplear el dispositivo FT232R alimentado desde el mismo puerto USB, por lo que para este propósito no se requiere ningún dispositivo adicional. Se ha incluido un fusible reseteable PTC que abre el circuito de alimentación en caso de que se superen los 500mA que especifica el estándar USB como límite de corriente máxima que puede proporcionar. Se ha seguido el apartado “7.1.- USB to RS232 converter” que recomienda el fabricante, para configurar una interfaz sencilla entre el terminal USB del ordenador, con la USART del transceptor XBee. FIGURA 3: APLICACIÓN TÍPICA USB-SERIAL DEL FT323R TX 1 DTR# 2 RTS# 3 VCCIO 4 RXD 5 RI# 6 GND 7 NC 8 DSR# 9 DCD# 10 CTS# 11 CBUS4 12 CBUS2 13 CBUS3 14 USBDP 15 USBDM 16 3V3OUT 17 GND 18 RESET# 19 VCC 20 GND 21 CBUS1 22 CBUS0 23 NC 24 AGNG 25 TEST 26 OSCI 27 OSCO 28 U1 FT232RL VBUS 1 D- 2 D+ 3 NC 4 GND 5 J1 440247-1 F1 500mA PTC GND DIN DOUT VCC 0.1uF C1 GND GND GND GND RXLED TXLED 0.1uF C2 GND GND DTR# RTS# CTS# Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 9 En este sentido, se han añadido dos diodos led indicadores para transmisión y recepción, con sus respectivas resistencias limitadoras de corriente, según especifica el fabricante en el apartado “7.5.- Led interface”. FIGURA 4: LEDS INDICADORES PARA EMISIÓN Y RECEPCIÓN Se ha aprovechado la salida del regulador de 3.3 voltios y empleando unos diodos led SMD con una tensión umbral de 2 voltios, se ajusta la resistencia limitadora de corriente como sigue: Teniendo en cuenta que el fabricante de los diodos led indica una corriente máxima de 20 mA, la resistencia mínima que hay que colocar: Estableciendo la corriente por el diodo a 4mA para conseguir una luminosidad aceptable sin ocasionar un consumo notable, la resistencia necesaria: De la misma forma, se ha empleado la configuración anterior para indicar que el circuito está alimentado. FIGURA 5: LED DE POWER D2 LED RED D3 LED YELLOW 330 R2 330 R3 RXLED TXLED 3V3 330 R1 D1 LED RED GND VCC Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 10 En este caso es necesario que la alimentación provenga directamente del terminal USB, por lo que la tensión tiene un valor de 5 voltios. Los cálculos para la resistencia limitadora son los siguientes, bajo las mismas condiciones del diodo led: Por otro lado el transceptor XBee también dispone de dos indicadores led, dispuestos de la misma forma que en el caso del FT232R: FIGURA 6: TRANSCEPTOR XBEE Y LEDS INDICADORES DE ASOCIACIÓN Y RSSI Los diodos empleados son los mismos que el caso anterior y la tensión de polarización, proveniente del transceptor XBee es igualmente de 3.3 voltios, por lo que las condiciones son las mismas que las anteriormente calculadas y se emplean resistencias de 330 Ohmios. DIO0 20 VCC 1 DOUT 2 DIN 3 DIO8 4 /RESET 5 RSSI 6 PWM1 7 RESERVED 8 /DTR 9 GND 10 DIO4 11 /CTS 12 /SLEEP 13 VREF 14 DIO5 15 /RTS 16 DIO3 17 DIO2 18 DIO1 19 Xbee XBee serie 1 DOUT DIN DIO8 RST# RSSI PWM1 RSVD DTR# DIO4 CTS# SLEEP# VREF DIO5 RTS# DIO3 DIO2 DIO1 DIO0 GND 3V3 D4 LED YELLOW 330 R4 GND RSSI D5 LED YELLOW 330 R5 GND DIO5 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 11 2.2. MOTE BASE 2.2.1. ALIMENTACIÓN El mote base debe proporcionar un sistema de alimentación para el microcontrolador, el transceptor XBee y las PCB funcionales que se le acoplan, por lo que podemos estimar el consumo en cada caso para determinar la corriente mínima que debe proporcionar. De la misma forma que el coordinador, los rangos de tensión están limitados por los dispositivos a los que alimenta. La siguiente tabla muestra los dispositivos que contiene el diseño y sus posibles valores de tensión de entrada. Dispositivo Rango de tensiones de alimentación Microcontrolador Atmel AVR Atmega 168 Min = 1.8 v, Max = 5v Transceptor XBee Min = 2.8v, Max = 3.4v Por lo tanto, la intersección de ambos conjuntos determina que el rango de valores posibles de alimentación viene determinado por los que marca el transceptor XBee. Un valor standard comercial que se encuentra dentro del rango de posibles valores es 3.3 voltios y es el que se ha seleccionado. El consumo en cada mote es la suma del consumo en el mote base y en cada caso, el de la PCB funcional que tenga acoplada. Teniendo en cuenta que la principal fuente de alimentación se encuentra físicamente en el mote base y es única para todo el mote, hay que dimensionarla para el peor de los casos. Los siguientes cálculos estiman el consumo del mote base, teniendo en cuenta una tensión de alimentación de 3.3 voltios. MICROCOTROLADOR Dispone de un cristal a 8 MHz como primera condición para estimar el consumo. Así mismo se considera un modo de funcionamiento normal, sin la activación de modos de bajo consumo. De acuerdo con el funcionamiento normal, a priori son susceptibles de estar activos los siguientes bloques periféricos internos, que contribuyen al consumo total: Mote Periféricos activos Ambiental  USART  ADC  TIMER 0, TIMER 1 Detección presencia  USART  TIMER 0 Dimmer  Timer 0  Timer 2 Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 12 La siguiente tabla resume el consumo de los bloques periféricos integrados, extraída a partir de la tabla que aparece en el apartado “29.3.3” del Datasheet del Atmega 168: FIGURA 7: CONSUMO DEL ATMEGA168 DEPENDIENTE DE LA FRECUENCIA DEL CRISTAL FIGURA 8: CONSUMO DE LOS PERIFÉRICOS COMO PORCENTAJE DEL AISLADO DEL ATMEGA168 A partir de la tabla 7, se determina que para una tensión de alimentación de 3.3 voltios y una frecuencia de reloj de 8 MHz, el consumo medio del microcontrolador es de 2.2 mA. La siguiente tabla indica los consumos adicionales que se superponen al consumo del microcontrolador en modo activo. Periférico Consumo USART 1.5%*2.2mA = 0.033 mA ADC1 3.4%*2.2mA = 0.0748 mA TIMER 0 0.7%*2.2mA = 0.0154 mA TIMER 1 1.7%*2.2mA = 0.037 mA TIMER 2 2.4%*2.2mA = 0.0528 mA 1 SE TIENE EN CUENTA QUE LA REFERENCIA INTERNA DEL ADC ESTÁ CONECTADA A LA TENSIÓN DE ALIMENTACIÓN DEL ATMEGA. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 13 Con la información anterior podemos estimar los siguientes consumos por mote. Mote Periféricos activos Consumo estimado Ambiental  USART  ADC  TIMER 0, TIMER 1 2.2 mA + 0.033 mA + 0.0748 mA + 0.0154 mA + 0.037 mA = 2.36 mA Detección presencia  USART  TIMER 0 2.2 mA + 0.033 mA + 0.0154 mA = 2.25 mA Dimmer  USART  Timer 0  Timer 2 2.2 mA + 0.033 mA + 0.0154 mA + 0.0528 mA = 2.3 mA El consumo máximo es de 2.36 mA. XBEE Los consumos del transceptor XBee ya se han mencionado en el apartado “2.1.1” y como resultado se indica que el consumo máximo se especifica durante la recepción de datos, tomando un valor en torno a 50 mA. La siguiente tabla extraída del Datasheet, referencia lo anterior. FIGURA 9: ESPECIFICACIONES ELÉCTRICAS DEL TRANSCEPTOR XBEE SWITCH ADG719 El consumo del switch digital es despreciable por dos motivos:  El fabricante indica un consumo para polarización interna de máximo 1 uA.  El consumo asociado al proceso de reset es transitorio, pues únicamente se emplea para el sistema de reseteo automático. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 14 La siguiente figura muestra el consumo del Atmega 168 en el pin de reset. FIGURA 10: CONSUMO DEL ATMEGA 168 AL RESETEAR Para la tensión de alimentación de 3.3 voltios y la frecuencia de 8 MHz, aparece un consumo en reset de 0.35 mA durante los 500nS que dura el reset, como se puede ver en las figuras 10 y 11. FIGURA 11: TIEMPO MÍNIMO DE RESET EN FUNCIÓN DE LA TENSIÓN DE ALIMENTACIÓN Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 15 INDICADORES Existen varios diodos led polarizados de forma permanente o alternativa, que indican el estado del mote. Algunos de ellos se activan cuando está en modo carga de batería, por lo que no los vamos a tener en cuenta para el cálculo del consumo, pues únicamente nos referimos al consumo en funcionamiento con baterías. El transceptor XBee dispone de un indicador de asociación, que parpadea 2 veces por segundo, según indica el Datasheet del componente en el apartado “End-device start up”. Así pues suponiendo que el mote está correctamente asociado, permanecerá de forma permanente parpadeando. Según las características de los diodos led empleados, se requiere una corriente de unos 10 mA para conseguir una luminosidad aceptable, según la siguiente tabla extraída del Datasheet. FIGURA 12: ESPECIFICACIONES ELÉCTRICAS DE LOS DIODOS LED SMD Así, teniendo en cuenta que la salida de los terminales I/O del transceptor XBee no pueden superar la tensión de alimentación, fijada a 3.3 voltios, la resistencia adecuada para el diodo es la siguiente: Con los cálculos anteriores se puede estimar el consumo en general del mote base, sin tener en cuenta las PCB funcionales que se van a acoplar. Este cálculo supone un caso desfavorable, ya que supone la activación de varios periféricos integrados simultáneamente, así como el transceptor XBee recibiendo, lo que es poco probable al mismo tiempo. A esto hay que sumarle la contribución de las PCB funcionales en cada uno de los casos, lo que incrementa el consumo final. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 16 Mote ambiental El mote ambiental dispone de los siguientes sensores:  Sensor de temperatura TMP36 El sensor está alimentado a la tensión establecida inicialmente, 3.3 voltios y el consumo en modo activo viene dado por la siguiente figura extraída del Datasheet: FIGURA 13: CONSUMO DEL SENSOR DE TEMPERATURA TMP36 REFERENTE A LA TENSIÓN DE ALIMENTACIÓN Por lo tanto, para la tensión de 3.3 voltios, el consumo está en torno a 23 uA.  Sensor de humedad HIH 5030 De la misma forma, el Datasheet del sensor de humedad indica que bajo las condiciones de 3.3 voltios y alimentación y 25ºC, el consumo típico es de 200 uA. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 23 y suponemos una corriente de salida máxima de 450 mA y un rizado no superior a 10 mV. Estableciendo un factor de seguridad de aproximadamente 2 por las pérdidas transitorias y la resistencia equivalente serie del condensador, se elige un condensador de 100 uF. Por otro lado, se ha dispuesto un condensador de 2.2 uF tal y como indica el Datasheet en la figura 24, sin cálculo específico. Las resistencias de pull-up R10 y R11, tienen un valor de 1 MOhm tal y como recomienda el fabricante. 2.2.2. CARGA DE BATERÍA El mote base incluye un circuito de carga para la batería de Li+ basado en el integrado MAX1555 de Maxim. FIGURA 22: CONFIGURACIÓN DEL CARGADOR DE BATERÍAS DE LI+, MAX1555 Este dispositivo permite cargar baterías de una celda a partir de dos fuentes distintas, un puerto USB o una fuente de alimentación externa y se han implementado ambas, dado que apenas se requieren componentes externos, como una forma de ofrecer flexibilidad en este aspecto. El conector específico para la fuente de alimentación es un terminal de barril con un diámetro del pincho de 2mm estándar. El diseño, incluye un indicador de carga de batería, de tal forma que está activo mientras dura el proceso de carga y se desactiva una vez la batería alcanza el valor nominal. USB 1 GND 2 CHG 3 DC 4 BAT 5 U2 MAX1555 D1 LED 330 R2 GND 1uF C2 GND 1uF C3 GND VBAT VBAT 5V 1uF C4 GND 1 2 3 J2 PWR2 GND Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 24 Todos los condensadores externos se han elegido de acuerdo con la recomendación del fabricante en el Datasheet: FIGURA 23: APLICACIÓN TÍPICA DEL MAX1555 2.2.3. PROCESAMIENTO El microcontrolador elegido ha sido el Atmel Atmega 168, funcionando a una frecuencia de reloj de 8Mhz y a 3.3 voltios. Los aspectos relacionados con el consumo se han detallado en el apartado 2.2.1. FIGURA 24: MICROCONTROLADOR ATMEGA 168 La mayoría de los terminales de I/O están mapeados a terminales externos conectables, que sirven de base a las PCB funcionales, de tal forma que establecen una conexión robusta entre los módulos. Para establecer el clock del sistema se ha elegido un cristal de cuarzo de 8Mhz, lo que supone un bajo consumo y susceptibilidad a ruido. Dado que el ruido en principio no es un elemento cuya incidencia sea relevante, pues se trata de un diseño de baja frecuencia, prevalece el factor del bajo consumo. PC6 (RESET) 1 PD0 (RXD) 2 PD1 (TXD) 3 PD2 (INT0) 4 PD3 (INT1) 5 PD4 (XCK/T0) 6 VCC 7 GND 8 PB6 (XTAL1/TOSC1) 9 PB7 (XTAL2/TOSC2) 10 PD5 (T1) 11 PD6 (AIN0) 12 PD7 (AIN1) 13 PB0 (ICP) 14 PB1 (OC1A) 15 PB2 (SS/OC1B) 16 PB3 (MOSI/OC2) 17 PB4 (MISO) 18 PB5 (SCK) 19 AVCC 20 AREF 21 GND 22 PC0 (ADC0) 23 PC1 (ADC1) 24 PC2 (ADC2) 25 PC3 (ADC3) 26 PC4 (ADC4/SDA) 27 PC5 (ADC5/SCL) 28 U1 ATmega168 ICP OC1A OC1B MOSI MISO SCK XTAL1 XTAL2 RXD TXD INT0 INT1 T0 T1 AIN0 AIN1 ADC0 ADC1 ADC2 ADC3 ADC4 ADC5 RST VCC GND AREF Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 25 FIGURA 25: CRISTAL DE CUARZO Y CONDENSADORES PARA EL ATMEGA 168 No obstante es necesaria la colocación de dos condensadores en el rango 12 – 22 pF tal y como indica la figura 24, extraída del apartado “8.3 Low power crystal oscillator”, tomando el valor de 20 pF. FIGURA 26: RANGOS PARA LOS CONDENSADORES DEL CRISTAL Dado que se trata de un dispositivo digital de tecnología CMOS, el consumo de corriente se produce en las transiciones entre estados lógicos, y aunque se puede establecer un consumo promedio, lo picos de corriente pueden provocar efectos adversos importantes si no se controlan. Para ello no basta con insertar un elemento capacitivo a la salida del sistema de alimentación, pues la distancia puede ser lejana y crear un bucle de corriente largo que incremente los efectos negativos. Para gestionar los picos de corriente transitoria que suceden durante el normal funcionamiento, cuando se activa un periférico o un puerto I/O, se ha incorporado un condensador de 100 nF, para proporcionar esa corriente instantánea que la línea no es capaz de asumir. También en la entrada de referencia del conversor A/D se ha incluido un condensador de 20pF para evitarla introducción de ruido al conversor. No obstante este terminal también está mapeado en un terminal externo por lo que no queda inhabilitado. FIGURA 27: CONDENSADOR DE DESACOPLO DEL ATMEGA 168 Y CONDENSADOR DE FILTRADO PARA LA REFERENCIA ANALÓGICA XTAL1 XTAL2 20pF C9 20pF C10 GND GND 1 2 Y1 XTAL VCC 100nF C7 GND 20pF C8 GND AREF Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 26 En ambos casos, para minimizar el bucle de corriente, el placement de ambos condensadores se debe realizar lo más cercano posible a los terminales que afecta, como se puede apreciar en la figura 28. FIGURA 28: DETALLE DE RUTEO DEL CRISTAL PRÓXIMO AL MICROCONTROLADOR El circuito de reset está formado por dos partes, un reset manual y un reset automático, para permitir algunas funciones de reprogramación inalámbrica. El circuito de reset manual es el formado por el típico pulsador y el circuito RC que muestra la figura 29, en la que el puerto DTR está conectado a masa: FIGURA 29: PULSADOR DE RESET MANUAL Por otro lado, para el reset automático se ha empleado un switch controlado digitalmente por uno de los terminales del Atmega 168, el dispositivo ADG719 de Analog Devices. FIGURA 30: SWITCH CONTROLADO POR MICROCONTROLADOR PARA RESET AUTOMÁTICO 21 21 S2 Omron type B3F GND VCC 10K R1 RSTM 100nF C1 DTR 1 2 3 4 5 6 U5 A D G 7 1 9 I C P R S T GND VCC R S T M GND Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 27 El terminal 1 es el de control, que está controlado por el terminal ICP del microcontrolador. En estado de reposo, es decir, con ICP en nivel bajo, la salida RST del ADG719 está conectada al terminal 4, que a su vez corresponde a la salida del reset manual. Por defecto, el reset manual está preparado en el switch. Ahora, cuando el terminal ICP pasa a estado alto, el ADG719, cablea a la salida RST directamente a GND, lo que provoca el reset. Como el terminal ICP es controlable por programa, se trata de un reset por software. 2.2.4. COMUNICACIÓN El bloque de comunicación es idéntico al explicado en el apartado 2.1.2, por lo que se remite al lector a dicho apartado. El mote base incluye un bloque de 4 interruptores, empleados para permitir la configuración de modos de bajo consumo del transceptor XBee. De los cuatro interruptores, los conectados a RX y TX, siempre van a estar activos, pues son fundamentales para la comunicación. FIGURA 31: TRANSCEPTOR XBEE Y CONMUTADORES DE CONFIGURACIÓN Para permitir al transceptor XBee los modos Hibernate y Pin Doze, de muy bajo consumo se habilita el terminal Sleep_RQ a través del bloque de interruptores, para que sea controlado por el terminal SCK del Atmega 168. De esta forma, en las aplicaciones en las que se pueda hacer uso de estos modos, el terminal está habilitado. Por otra parte, el microcontrolador, también podría emplear el bloque I2C, por lo que sería necesario el uso del terminal SCK, y deshabilitando este en el bloque de interruptores quedaría disponible. DIO0 20 VCC 1 DOUT 2 DIN 3 DIO8 4 /RESET 5 PWM0 6 PWM1 7 RESERVED 8 Sleep/RQ 9 GND 10 DIO4 11 /CTS 12 /SLEEP 13 VREF 14 DIO5 15 /RTS 16 DIO3 17 DIO2 18 DIO1 19 Xbee XBee 1B2 VCC RXD TXD GND 6 54 3 1 8 2 7 S3 A6H-4101 Sleep Sleep SCK INT0 D3 LED 330 R12 GND RSTM Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 28 3. FLUJOGRAMAS DE PROGRAMACIÓN 3.1. SISTEMA LOCAL 3.1.1. COMUNICACIÓN SERIE CON XBEE Como ya se ha mencionado, una de las principales funciones del sistema local es la coordinación de los motes de la red o PAN. Esto se consigue, desde el punto de vista físico accediendo a la red mediante un transceptor inalámbrico. Para ello se ha construido una PCB que incorpora un transceptor XBee y un adaptador serie-usb FT232RL para poder conectar el XBee con el PC a través de un puerto USB. FIGURA 32: ESQUEMA DE COMUNICACIÓN PC CON XBEE La alimentación del sistema la realiza el puerto USB del PC, por lo que se establece un límite máximo de corriente por la especificación USB de unos 500 mA. Dado el consumo límite del XBee entorno a 50 mA en el peor de los casos y el del FTDI que está en los 15 mA en operación normal, queda un margen muy amplio hasta el límite proporcionado por el terminal USB. El XBee actúa como coordinador de la red de motes usando una topología en estrella centralizada, por lo que todos los paquetes pasan por él. FIGURA 33: TOPOLOGÍA DE LA RED DE MOTES Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 29 De esta forma, toda la información que el XBee envíe a través de su bloque de comunicaciones serie, será recibida en el PC y estará accesible para la aplicación. La aplicación del sistema local, actualmente está implementada en un PC, con un sistema operativo Linux, usando el lenguaje de programación Java. Se hace imprescindible el uso de una librería específica que realice dos funciones esenciales: hacer de interfaz entre el XBee y nuestra aplicación y que permita manejar las tramas estructuradas de datos que maneja el XBee, a nivel de orientación a objetos. Para lograr todo esto se ha utilizado la única librería libre y open source que hasta este momento existe, XBee- API (http://code.google.com/p/XBee-api/), que implementa la mayoría de la funcionalidad del XBee, en lenguaje Java. Internamente se apoya en la librería también libre y open source, RXTX que da soporte de bajo nivel para el acceso a los puertos USB en lenguaje Java, usando código nativo (JNI). Una vez conectado el XBee a través del FTDI al puerto USB, dinámicamente el sistema operativo reconoce el conjunto como un dispositivo con comunicaciones serie y lo monta, asignándole recursos en el área de dispositivos (devices). 3.1.2. GESTIÓN DE TRAMAS DE RED Todas las tramas que llegan al coordinador, son enviadas a través del puerto USB, de tal forma que generan una interrupción en el sistema operativo. Esta interrupción es propagada hasta la JVM, de tal forma que el núcleo de la librería RXTX es notificado del hecho de la interrupción y la atiende, recogiendo los datos sin un formato específico, como una ristra de bytes. Estos bytes son nuevamente recogidos por la librería XBee-api, que los encapsula en las estructuras de tramas que marca la especificación del XBee. Además de encapsular la información de forma estructurada, provee de métodos y funciones para manejar con cierta facilidad a alto nivel dichas tramas. En principio con todo lo anterior ya estaríamos en disposición de manejar desde la aplicación las tramas que circulan por la red. Ahora bien, hay que tener en cuenta los posibles cuellos de botella que existen desde que el XBee recibe la información hasta que esta es procesada y almacenada en su caso. Cada vez que se recibe una trama, se genera una interrupción en el sistema y esta es finalmente atendida por la aplicación. La “atención” a las tramas que llegan implica que la aplicación está dedicada durante cierto tiempo a recibir la trama, a encapsularla y a realizar el procesamiento adecuado y todo esto lleva un tiempo, que no es siempre el mismo para todas las tramas. Aunque en principio el tráfico de datos que circula por la red de motes va a ser bajo, por la propia concepción de la red, puede darse el caso de que se iniciaran múltiples activaciones consecutivas y por lo tanto interrupciones en el sistema, mínimamente espaciadas en el tiempo, lo que puede suponer un problema, pues podrían llegar a perderse cuando el procesamiento individual es largo. A nivel de aplicación este cuello de botella se soluciona o al menos se minimiza en buen grado, usando múltiples hilos de ejecución (threads), incrementando con ello el grado de paralelismo con el que las tareas se ejecutan. Esto se consigue haciendo uso de las utilidades para concurrencia que Java ofrece y en este sentido cabe destacar la magnífica implementación desarrollada por Doug Lea, incorporada a partir de la versión 1.5 de la JDK. En nuestro caso, se hace uso de lo que se conoce como una “pool” de threads (ThreadPoolExecutor), un lugar donde existen instancias ya creadas de threads, listas para ser usadas. Cuando la aplicación recibe una trama, antes de iniciar el procesamiento, recupera un thread de la pool, le asigna una tarea y lanza la ejecución. Cuando la ejecución termina, el thread es liberado y devuelto a la pool. Con esto conseguimos minimizar la latencia o el tiempo de respuesta ante los eventos, por dos motivos, uno, la pool de threads no crea nuevos Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 30 threads a menos que se vacíe, con lo que se elimina el coste de creación de objetos y dos, podemos tener múltiples threads corriendo en pseudo paralelismo. XBEEPACKETLISTENER.JAVA /** * Interceptor de trama recibida. * Identifica la trama y delega el procesamiento en el parser adecuado. * En toda la aplicación solo vamos a tener una instancia de esta clase * y por ello usamos un Singleton * Para mejorar el rendimiento y la respuesta ante los eventos, * usa una Pool de Threads, que lanza un thread por cada petición. */ public class XBeePacketListener implements PacketListener { private static final Logger log = Logger.getLogger(XBeePacketListener.class); private static final XBeePacketListener listener = new XBeePacketListener(); private static ThreadPoolExecutor pool = (ThreadPoolExecutor)Executors.newCachedThreadPool(); private XBeePacketListener() { } public static XBeePacketListener getInstance(){ return listener; } public void processResponse(XBeeResponse response) { log.debug("Paquete recibido...inicia worker thread"); pool.execute(new ResponseReaderFactory().getResponseReader(response)); } } Como se puede apreciar en el fragmento anterior, la llamada a pool.execute(..) tiene como argumento una tarea, es decir algo ejecutable. Esto en Java recibe el nombre de Runnable y es una interfaz con un único método, run(), el cual es llamado por el thread que contiene la tarea. El siguiente esquema de clases, refleja las relaciones y los contratos entre el listener proporcionado por la librería XBee-api y la implementación propia. FIGURA 34: RELACIONES DE HERENCIA PARA EL LISTENER DE PAQUETES Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 31 Para poder atender a los eventos generados por la recepción de tramas en el dispositivo XBee, en la aplicación se ha de crear una instancia de una clase que sea capaz de gestionarlo. Como ya se ha mencionado, haciendo uso de la librería XBee-API, se emplea la clase XBee: ... XBee xbee = new XBee(); ... Esta clase es una capa de abstracción sobre la proporcionada por la librería RXTX, para el manejo de datos por el puerto serie. Ofrece por lo tanto un mecanismo para manejar las interrupciones generadas, que en lenguajes de algo nivel se conoce como Listener. El uso de este método va ligado con todo lo anterior y su uso es como sigue: ... XBee.addPacketListener(XBeePacketListener.getInstance()); ... La secuencia de ejecución desde el punto de vista de la aplicación queda de la siguiente forma:  Creación de una instancia para la clase XBee.  Creación de una instancia para el listener de paquetes.  Añadir el listener a la instancia de la clase XBee. Con esto ya tenemos el mecanismo base para poder trabajar a alto nivel con el transceptor XBee. El siguiente paso consiste en leer y trabajar con las tramas recibidas. Nuevamente se ha pensado en un sistema genérico y compatible con los dispositivos XBee disponibles en el mercado. DIGI fabrica dispositivos XBee para 802.15.4, ZigBee y la variante Znet y aunque no son compatibles, nuestra aplicación ofrece la posibilidad de usar la tecnología que más convenga en cada caso. De esta forma si un problema concreto requiere del uso de ZigBee cuando 802.15.4 no cubre las necesidades, la aplicación está preparada para ello. La problemática de una implementación genérica está en crear un sistema mínimo para procesar las tramas que sea común a todos los casos. Esto en programación orientada a objetos se puede concretar en interfaces. Una interfaz es un contrato para todos aquellos que se adhieran a ella, es decir, deben implementar de forma concreta el comportamiento que la interfaz propone. Se ha creado una clase que proporciona la funcionalidad requerida por ThreadPoolExecutor y que además establece un criterio común para el procesamiento de tramas, en forma de método abstracto, que implementarán los lectores concretos para las tramas que se reciben. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 32 RESPONSEREADER.JAVA /** * Clase base para los lectores especializados en tramas concretas. * * Hace de plantilla para los que extiendan esta clase, que deben * implementar el método read(), para leer la trama recibida. * Implementa la interfaz Runnable, necesaria para el ThreadPoolExecutor. */ public abstract class ResponseReader implements Runnable { private final XBeeResponse response; public ResponseReader(XBeeResponse response) { this.response = response; } public XBeeResponse getResponse() { return response; } protected abstract void read(); public void run() { this.read(); } } Esta hereda la propiedad de ser ejecutable dentro de un thread al implementar Runnable y además proporciona una plantilla en forma de método read(), para las clases que la extienden, es decir, read() es un método que implementará una clase que esté preparada para trabajar con 802.15.4 pero que también implementará una clase que trabaje con Znet, eso sí, cada implementación será particular. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 39 ASSOCIATIONRESPONSE.JAVA /** * Clase que encapsula la información de la trama de asociación. * * El parseador de la trama de asociación {@link XmlStandardAssociationResponseParser} * y el manejador del parser {@link XmlAssociationResponseHandler}, usan esta clase * para almacenar la información. */ public class AssociationResponse implements IResponse { private XBeeAddress64 macAddress; //Se la asignamos por defecto private XBeeAddress16 netAddress = AUTO_ASSOC_NET_ADDRESS; private MoteType type; //Tipo de mote según el parseo del xml private List<Integer> sensors; private List<Integer> controllers; //Métodos set y get } La clase que encapsula la información de asociación, contiene los siguientes atributos, mostrados en el diagrama anterior:  macAddress: cuyo tipo es una dirección de 64 bits encapsulada a su vez en la clase XbeeAddress64.  netAddress: cuyo tipo es una dirección de 16 bits encapsulada a su vez en la clase XbeeAddress16.  cMeasures: Mapa con las medidas contínuas de cada sensor.  bMeasures: Mapa con las medidas binarias de cada sensor.  SENSORMEASURERESPONSE.JAVA /** * Datos enviados por un mote sensor. */ public class SensorMeasureResponse implements IResponse { private XBeeAddress64 macAddress; //Se la asignamos por defecto private XBeeAddress16 netAddress = AUTO_ASSOC_NET_ADDRESS; private Map<Integer, Double> c_measures; private Map<Integer, Boolean> b_measures; //Métodos set y get } Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 40 3.1.3. ARQUITECTURA SERVIDOR REMOTO Cada uno de los sistemas locales es al mismo tiempo un servidor remoto, de tal forma que con una conexión de red, se permite el acceso a ciertas funciones restringidas. El caso más significativo es que se permite acceder a los dispositivos de la red que realizan tareas de control, como pueden ser motes que gestionan la iluminación. Se ha empleado la tecnología cliente-servidor que ofrece Java denominada RMI o Remote Method Invocation. RMI está basada en el paso de objetos entre distintas máquinas, así como la invocación de métodos y la recepción de resultados en el cliente. Para lograr el paso de objetos entre máquinas virtuales diferentes, evidentemente es necesario un servidor, el cual ofrece una interfaz que define un conjunto de métodos con parámetros y resultados, que está accesible para los clientes que conecten con ese servidor. FIGURA 37: ARQUITECTURA RMI SOBRE DOS MÁQUINAS VIRTUALES DIFERENTES Por otro lado, los clientes tienen que ser capaces de contactar con el servidor y cumplir los requisitos de acceso y seguridad, si es que los hay. Hay que hacer la matización de que la comunicación o paso de objetos entre cliente y servidor no es directa, sino que se usan unas entidades intermedias denominadas Proxy, que se ocupan de la problemática de la comunicación a bajo nivel. Estas entidades Proxy, se ubican tanto en el cliente como en el servidor y delegan las peticiones y los resultados a servidor y cliente respectivamente. FIGURA 38: DIAGRAMA DE SECUENCIA DE UNA SOLICITUD REMOTA Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 41 La especificación RMI obliga a que se extienda la interfaz Remote para poder codificar el servidor, ya que esta permite la creación de métodos que se pueden invocar remotamente. Así por ejemplo, para aquellos sistemas que empleen 802.15.4 en su red de motes, podrían tener una especificación del servidor remoto como esta: XBEESTANDARDSERVICE.JAVA /** * Interfaz de servicio remoto pasa sistemas que operan con el estándar * 802.15.4. * * El servicio RMI estará corriendo en la instalación inalámbrica y los * clientes remotos interactuarán con la instalación con esta interfaz. */ public interface XBeeStandardService extends Remote { public static final int networkID = 1; //Id de la red /** * Envía una trama con el formato TxRequest16 * * @param addressLow byte de menor peso de la dirección destino * @param addressHigh byte de mayor pese de la dirección destino * @param payload datos efectivos que contiene la trama * @param options opciones de envío(ver:{@link Option}) * @param frameId identificador para la trama * @throws RemoteException */ void sendTxRequest16(int addressLow, int addressHigh, int[] payload, int options,int frameId) throws RemoteException; /** * Envía una trama con el formato TxRequest64 * * @param macAddress dirección mac del destinatario * @param payload datos efectivos de la trama * @param options opciones de envío(ver:{@link Option}) * @param frameId identificador para la trama * @throws RemoteException */ void sendTxRequest64(String macAddress, int[] payload, int options, int frameId) throws RemoteException; } Esta es una interfaz sencilla para un servidor remoto que opera con 802.15.4 y que ofrece dos métodos para enviar remotamente tramas, empleando bien direcciones de 16 bits o direcciones de 64 bits. La implementación de los métodos remotos es bastante sencilla ya que se hace uso de la librería XBee-api y en concreto de la clase XBee de la que el servidor contiene una instancia. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 42 XBEESTANDARDSERVICEIMPL.JAVA public class XBeeStandardServiceImpl extends UnicastRemoteObject implements XBeeStandardService { private static final long serialVersionUID = 1523090807995267859L; private static final Logger log = Logger.getLogger(XBeeStandardServiceImpl.class); private static final XBee xbee = new XBee(); public void sendTxRequest16(int addressLow, int addressHigh, int[] payload, int options, int frameId) throws RemoteException { XBeeAddress16 xBeeAddress16 = new XBeeAddress16(addressHigh, addressLow); TxRequest16 txRequest16 = new TxRequest16(xBeeAddress16, frameId, Option.get(options), payload); try { XBee.sendAsynchronous(txRequest16); } catch (XBeeException ex) { log.error(ex); } } public void sendTxRequest64(String macAddress, int[] payload, int options, int frameId) throws RemoteException { XBeeAddress64 xBeeAddress64 = new XBeeAddress64(macAddress); TxRequest64 txRequest64 = new TxRequest64(xBeeAddress64, frameId, Option.get(options), payload); try { XBee.sendAsynchronous(txRequest64); } catch (XBeeException ex) { log.error(ex); } } } Ya tenemos la funcionalidad externa mediante la cual, un cliente remoto puede enviar tramas con formatos de 16 o 64 bits a la red de motes que gestiona el sistema local. Aprovechando la implementación de un servidor remoto, ya que es un servicio que está permanentemente activo, podemos añadir el resto de la lógica para la autoconfiguración de los motes. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 43 3.1.4. AUTOCONFIGURACIÓN A ALTO NIVEL Se entenderá el término autoconfiguración a alto nivel como el proceso por el cual el software de aplicación al disponer de la información necesaria, es capaz de identificar cuando un mote se añade a la red y cuál es su configuración de sensores y actuadores. Además se han de tener en cuenta otros casos como el posible reinicio de la red o la sustitución del coordinador por avería. El proceso de autoconfiguración comienza cuando arranca el servidor local, detectando el dispositivo XBee coordinador que está conectado al puerto USB. Básicamente se puede esquematizar en el siguiente diagrama que a posteriormente se explica con fragmentos de código: FIGURA 39: FLUJOGRAMA DEL ARRANQUE DEL SERVICIO REMOTO Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 44 1. Al arrancar el sistema, se detecta el coordinador que está conectado al puerto USB y mediante comandos AT, se obtiene el número de serie. Los comandos AT están especificados en la documentación que aporta DIGI y en concreto son SH, para obtener la parte alta del número de serie y SL para la parte baja. Este número de serie tiene 64 bits y cada parte está formada por 32 bits. log.info("Iniciando el servicio remoto del coordinador XBee"); //Obtiene la información de la red a partir de la existente en la base de datos //de la aplicación global, que está en nuestro servidor Network network = new DbNetworkDAO().load(networkID, null); log.info("XBee inicializado"); //Inicia la red con los datos obtenidos configurados anteriormente XBee.open(network.getPort(), network.getBaudrate().getValue()); log.info("Conexión con el coordinador establecida"); log.info("Comprobando número de serie del coordinador"); AtCommand command = new AtCommand("SH"); AtCommandResponse response = (AtCommandResponse) XBee.sendAtCommand(command); int[] serialHigh = response.getValue(); command = new AtCommand("SL"); response = (AtCommandResponse) XBee.sendAtCommand(command); int[] serialLow = response.getValue(); int[] serial = new int[serialHigh.length + serialLow.length]; for (int i = 0; i < serialLow.length; i++) { serial[i] = serialLow[i]; serial[i + serialLow.length] = serialHigh[i]; } XBeeAddress64 connectedSerial = new XBeeAddress64(serial); log.info("Dirección del coordinador conectado : " + ByteUtils.toBase16(serial)); 2. Una vez se obtiene el número de serie, lo busca en la base de datos. Mote coordinator = new DbMoteDAO().load(connectedSerial); XBeeAddress64 currentSerial = coordinator != null ? coordinator.getSerialNumber() : null; 3. Si no hay coordinador previo, entonces obtiene la dirección de red del mote y guarda el número de serie obtenido y la dirección de red. Finalmente añade el listener de paquetes. if (currentSerial == null) { //Si no hay coordinador previo lo guardaría en la base de datos log.debug("El sistema no tiene coordinador"); log.debug("Obteniendo información del coordinador conectado..."); command = new AtCommand("MY"); response = (AtCommandResponse) XBee.sendAtCommand(command); coordinator = new Coordinator(); coordinator.setSerialNumber(connectedSerial); coordinator.setNetworkAddress(new XBeeAddress16(response.getValue())); coordinator.setNetwork(network); new DbMoteDAO().save(coordinator); log.debug("Nuevo coordinador guardado!"); //y añade el listener porque van a empezar a llegar paquetes de asociación XBee.addPacketListener(XBeePacketListener.getInstance()); log.info("Manejador de paquetes añadido"); } Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 45 4. Si no ha cambiado, simplemente añade el listener de paquetes. //Si no hemos cambiado de coordinador no hace nada, pues los nodos //ya conocen la dirección del coordinador de alguna asociación anterior //o si es la primera vez, se asociarán ahora. if (currentSerial.equals(connectedSerial)) { log.debug("No ha cambiado el coordinador y no hace falta iniciar el proceso de reasociación."); //y añade el listener porque van a empezar a llegar paquetes de sensado XBee.addPacketListener(XBeePacketListener.getInstance()); log.info("Manejador de paquetes añadido"); } 5. Si ha cambiado el coordinador, entonces reconfigura en la base de datos el nuevo coordinador y reinicia el proceso de asociación. if (!currentSerial.equals(connectedSerial)) { //Si ha cambiado el coordinador, actualiza en DB el serial del coordinador //y arranca un worker thread para reasociar los nodos al nuevo coordinador. //Para ello tenemos que recuperar los nodos y en concreto las direcciones //de 64 bits y enviarles uno a uno el comando AT remoto ATDA, que fuerza //la desasociación para que reinicien el proceso de asociación al nuevo //coordinador. log.debug("Se ha cambiado el coordinador!"); log.debug("Obteniendo información del coordinador conectado..."); command = new AtCommand("MY"); response = (AtCommandResponse) XBee.sendAtCommand(command); coordinator = new Coordinator(); coordinator.setSerialNumber(connectedSerial); coordinator.setNetworkAddress(new XBeeAddress16(response.getValue())); coordinator.setNetwork(network); new DbMoteDAO().update(coordinator); log.debug("Actualizado el nuevo coordinador"); log.debug("Iniciando el proceso de reasociacion de nodos"); List<Mote> motes = new DbMoteDAO().loadByNetworkId(networkID); List<XBeeAddress64> endDevicesMacList = new ArrayList<XBeeAddress64>(); for (Mote mote : motes) { log.debug(mote.getSerialNumber()); endDevicesMacList.add(mote.getSerialNumber()); } AssociationWorker associationWorker = new AssociationWorker(endDevicesMacList, XBee); //Usa un singleThread, pero igual se puede mejorar usando una Pool ExecutorService associationService = Executors.newSingleThreadExecutor(); associationService.execute(associationWorker); } Hasta ahora se ha presentado como es el flujo una vez que el sistema arranca pero la parte importante es la de la reasociación que se da en el punto 5. En el fragmento de código presentado aparece una clase, AssociationWorker, que se ha creado concretamente para gestionar este proceso. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 46 3.1.5. REASOCIACIÓN El proceso de reasociación consiste en desasociar a cada uno de los motes que pertenecen a la red individualmente, y dejar que automáticamente se asocien. Quien ordena la disociación de los motes es el coordinador, que envía el comando remoto DA (Dissasociate) a cada uno de los motes. Cuando un XBee se desasocia, automáticamente, por su configuración, vuelve a asociarse en el nivel de red, se une a una PAN y tiene un periodo de handshaking para obtener una dirección. Una vez que se ha asociado, el XBee envía un comando de respuesta al coordinador indicando si la asociación ha sido satisfactoria. Principalmente esta tarea es la que realiza AssociationWorker, que toma todos los motes que conocemos que pertenecen a la red y va uno a uno desasociando y esperando una respuesta. Se trata de una tarea esporádica y por lo tanto se puede encapsular en un hilo de ejecución o thread, que muere cuando finaliza la tarea. Una forma adecuada de crear esta tarea es usar el modelo de Executor de la librería estándar Java para concurrencia, de la siguiente forma: AssociationWorker associationWorker = new AssociationWorker(endDevicesMacList, XBee); ExecutorService associationService = Executors.newSingleThreadExecutor(); associationService.execute(associationWorker); La utilidad AssociationWorker toma un mapa de direcciones estados, associationMap y cada segundo envía el comando AT remoto “DA” a cada una de las direcciones. Si de forma síncrona, recibe una respuesta de asociación “Ok”, entonces lo indica en el mapa de estados como un booleano cierto. Este proceso se realiza hasta que todos los motes están asociados de nuevo, momento en el que inicia el listener de paquetes por defecto XbeePacketListener. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 47 ASSOCIATIONWORKER.JAVA /** * Acción del worker de asociación. * Se ejecuta mientras no están asociados todos los nodos conocidosen el momento de iniciarse. * Una vez que se han asociado todos, añade el manejador de paquetes adecuado al XBee. */ public class AssociationWorker implements Runnable { private final Logger log = Logger.getLogger(this.getClass()); private Map<XBeeAddress64, Boolean> associationMap; private XBee xbee; private static final String DISSASOCIATE_COMMAND = "DA"; private static final int TIMEOUT = 1000; public AssociationWorker(List<XBeeAddress64> endDevicesMac, XBee xbee) { this.xbee = XBee; this.associationMap = new HashMap<XBeeAddress64,Boolean>(endDevicesMac.size()); for (XBeeAddress64 address : endDevicesMac) { this.associationMap.put(address, false); } } private boolean associationCompleted() { for (XBeeAddress64 endDevice : associationMap.keySet()) { if (!associationMap.get(endDevice)) { return false; } } return true; } public void run() { while (!associationCompleted()) { try { for (XBeeAddress64 endDevice : associationMap.keySet()) { if (!associationMap.get(endDevice)) { log.debug("Reiniciando asociación con:"+ endDevice.toString()); ZNetRemoteAtRequest dissasociateCommand = new ZNetRemoteAtRequest(0x01, endDevice, XBeeAddress16.BROADCAST, true, DISSASOCIATE_COMMAND); ZNetRemoteAtResponse response = (ZNetRemoteAtResponse) this.XBee.sendSynchronous(dissasociateCommand, TIMEOUT); log.debug(response); if (response.isOk()) { associationMap.put(endDevice, true); log.debug("Asociado el nodo con dirección:"+endDevice); } } } } catch (XBeeException ex) { log.error(ex); } } log.debug("Finalizado el proceso de reasociación de nodos"); //Una vez realizado el proceso de asociación, iniciamos el manejador de paquetes Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 48 XBee.addPacketListener(XBeePacketListener.getInstance());//Es un Singleton log.info("Manejador de paquetes añadido"); } } 3.1.6. CONEXIÓN A LA BASE DE DATOS Para lograr la gestión de la red a alto nivel, como se ha explicado en los apartados anteriores, es necesario un mecanismo que permita guardar cierta información, como puede ser datos sobre el coordinador, las direcciones de red de los motes y los sensores que tienen instalados, información de los sensores...etc. El mecanismo de persistencia se explica en más detalle en la sección 6 pero diremos que se trata de una base de datos relacional, donde la información se guarda en forma tabular en la que cada fila de una tabla corresponde con un registro de información. Existe una conexión directa entre los sistemas locales y la base de datos, es decir, la base de datos es realmente un servidor que está disponible en internet y es accesible a través de una dirección. Java ofrece un mecanismo estándar para manejo de base de datos denominado JDBC que gestiona la conexión y la ejecución de sentencias de base de datos o SQL. En el prototipo de aplicación, se ha desarrollado una clase que permite gestionar la conexión remota con un servidor de base de datos, que físicamente estaría ubicado en el servidor global de aplicaciones. DBLOCAL.JAVA public class DBLocal { private final Logger log = Logger.getLogger(this.getClass()); /**Proporciona una conexión a la base de datos.*/ public Connection getConnection() { try { String userName = "root"; String password = "admin"; String url = "jdbc:mysql://localhost:3306/homeAutomation"; Class.forName("com.mysql.jdbc.Driver").newInstance(); Connection conn = DriverManager.getConnection(url, userName, password); return conn; } catch (SQLException ex) { log.fatal("Problema con fuente de datos " + ex.toString()); throw new RuntimeException("Error de conexión a la base de datos.", ex); } catch (InstantiationException ex) { log.fatal("Problema con fuente de datos " + ex.toString()); throw new RuntimeException("Error de conexión a la base de datos.", ex); } catch (IllegalAccessException ex) { log.fatal("Problema con fuente de datos " + ex.toString()); throw new RuntimeException("Error de conexión a la base de datos.", ex); } catch (ClassNotFoundException ex) { log.fatal("Problema con fuente de datos " + ex.toString()); throw new RuntimeException("Error de conexión a la base de datos.", ex); } } /** Devuelve una conexión a la base de datos. */ Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 55 /** * Crea el XML adecuado para formar el payload de una trama de asociación * para un end device que únicamente contiene actuadores. * * El formato es el siguiente: * * <mote fmt="1"> * <actuator id="0000"/> * <actuator id="0001"/> * </mote> * * @param sensorList Puntero a la lista de actuadores * */ char* createActuatorAssociationPayload(struct Element actuatorList[],uint8_t length); #endif /* ASSOCIATION_H_ */ Y la implementación que se ha realizado de las funciones anteriores se encuentra en el archivo association.c: ASSOCIATION.C /* * association.c * */ #include "association.h" #include "element.h" #include <string.h> #include <stdlib.h> char* createSensorAssociationPayload(struct Element sensorList[],uint8_t length) { char* xml = calloc(100,sizeof(xml)); strncat(xml, ASSOC_MOTE_START_TAG, strlen(ASSOC_MOTE_START_TAG)); strncat(xml, SENSOR_TYPE_TAG, strlen(SENSOR_TYPE_TAG)); int i; for (i = 0; i < length; i++) { strncat(xml, SENSOR_START_TAG, strlen(SENSOR_START_TAG)); strncat(xml, sensorList[i].id, strlen(sensorList[i].id)); strncat(xml, SHORT_END_TAG, strlen(SHORT_END_TAG)); } strncat(xml, MOTE_END_TAG, strlen(MOTE_END_TAG)); return xml; } char* createActuatorAssociationPayload(struct Element actuatorList[],uint8_t length) { char* xml = calloc(100,sizeof(xml)); strncat(xml, ASSOC_MOTE_START_TAG, strlen(ASSOC_MOTE_START_TAG)); int i; for (i = 0; i < length; i++) { strncat(xml, ACTUATOR_START_TAG, strlen(ACTUATOR_START_TAG)); strncat(xml, actuatorList[i].id, strlen(actuatorList[i].id)); Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 56 strncat(xml, SHORT_END_TAG, strlen(SHORT_END_TAG)); } strncat(xml, MOTE_END_TAG, strlen(MOTE_END_TAG)); return xml; } De la misma forma se han creado los archivos sensing.h y sensing.c para generar el XML de las tramas de sensado, que envían información sobre las medidas. SENSING.H /* sensing.h */ #ifndef SENSING_H_ #define SENSING_H_ #include "association.h" #define SENSING_MOTE_START_TAG "<mote fmt=\"2\">" #define SENSOR_C_MEAS_TAG " c=\"" #define SENSOR_B_MEAS_TAG " b=\"" #define QUOTE "\"" /** * Crea el XML adecuado para formar el payload de una trama de sensado * para un end device que únicamente contiene sensores. * * El formato es el siguiente: * * <mote fmt="2"> * <sensor id="0000" c_meas="-12.234"/> //Sensor analógico * <sensor id="0001" b_meas="1"/> //Sensor binario * </mote> * * @param sensorList Puntero a la lista de sensores con las medidas * */ char* createSensorMeasuresPayload(const struct Element sensorList[],uint8_t length); #endif /* SENSING_H_ */ Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 57 SENSING.C /* sensing.c */ #include "sensing.h" #include "stdlib.h" #include "string.h" char* createSensorMeasuresPayload(const struct Element sensorList[],uint8_t length){ char* xml = (char*)calloc(95,sizeof(char*)); strncat(xml, SENSING_MOTE_START_TAG, strlen(SENSING_MOTE_START_TAG)); int i; //int length = sizeof(actuatorList) / sizeof(struct Element); for (i = 0; i < length; i++) { strncat(xml, SENSOR_START_TAG, strlen(SENSOR_START_TAG)); strncat(xml, sensorList[i].id, strlen(sensorList[i].id)); strncat(xml, QUOTE, strlen(QUOTE)); if(sensorList[i].type == CONTINUOUS){ strncat(xml, SENSOR_C_MEAS_TAG, strlen(SENSOR_C_MEAS_TAG)); strncat(xml, sensorList[i].c_meas, strlen(sensorList[i].c_meas)); }else if(sensorList[i].type == BINARY){ strncat(xml, SENSOR_B_MEAS_TAG, strlen(SENSOR_B_MEAS_TAG)); strncat(xml, sensorList[i].b_meas, strlen(sensorList[i].b_meas)); } strncat(xml, SHORT_END_TAG, strlen(SHORT_END_TAG)); } strncat(xml, MOTE_END_TAG, strlen(MOTE_END_TAG)); return xml; } Como se puede observar, en ambos casos se está usando una tipo de dato denominado Element. Element es una struct que se ha creado para agrupar ciertos datos comunes a los sensores instalados en un mote y que sirven tanto para identificarlos como para asociar medidas concretas. /** Tipo de medidas que proporciona el sensor */ enum elementType{ CONTINUOUS = 1, BINARY = 2 }; /** Estructura para relacionar sensor, medidas y canales del a/d usados */ struct Element{ const char* id; /** Id del sensor en la base de datos */ const enum elementType type;/** Tipo de medida que proporciona */ const char a2d_channel;/** Canal a/d que usa */ char* c_meas;/** Vector con las medidas contínuas */ char* b_meas;/** Vector con las medidas binarias */ }; Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 58 3.2.3. AUTOGESTIÓN En el lado del coordinador se deben configurar los siguientes atributos:  Coordinator enable(CE): Habilita un transceptor como coordinador. 0 - End device 1 - Coordinador  Coordinator association(A2): Establece las opciones de asociación en el lado del coordinador. Las posibles opciones son: bit 0 – Reasignación de identificador PAN 0 – El coordinador no llevará a cabo un escaneo activo para localizar un identificador de PAN disponible, simplemente operará en la pan que tiene configurada. 1 – El coordinador realizará en escaneo activo para determinar un identificador PAN disponible. Si el identificador PAN que tiene configurado ya está siendo usado, lo cambiará por uno que esté libre. bit 1 – Reasignación de canal 0 – El coordinador realizará un escaneo de energía para determinar un canal libre. Operará en el canal que tiene configurado en el registro CH. 1 – El coordinador realizará un escaneo de energía para encontrar un canal libre. bit 2 – Opciones de asociación 0 – El coordinador no permite a ningún dispositivo que se una a la PAN. 1 – El coordinador permite asociación. Por lo tanto habrá que configurar el parámetro CE con valor 0x01 en cualquiera de los casos, para disponer de un coordinador que forme la PAN. Buscando la máxima flexibilidad, el parámetro A2 debe tener un valor 0x07, de tal forma que buscará un identificador PAN libre y un canal libre también, permitiendo asociación de los end device. En el lado de los end device se debe configurar el parámetro A1 de la misma forma que se ha hecho con el A2 del coordinador, al valor 0x07, para que pueda obtener un identificador de PAN y un canal. Para seleccionar un identificador de PAN, realiza un barrido (active scan) de las PAN que alcanzan su ámbito y se queda con la de mejor señal (link quality). Entonces intenta unirse a ella enviando una solicitud de asociación (association request) y si el coordinador acepta esa solicitud, el end device establece su dirección de red de 16 bits al valor 0xFFFE y envía por la UART una trama de estado del modem(Modem status response) que indica que está asociado. Cabe destacar que este valor lo establecen todos los end device que se asocian mediante el proceso anteriormente descrito, de tal forma que son indistinguibles a través de la dirección de red. Esta es una connotación realmente importante, pues deshabilita el uso de tramas con direccionamiento de 16 bits desde el coordinador hacia los end devices, limitando a un único direccionamiento, el de 64 bits o números de serie. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 59 Ahora bien, los XBee disponen de dos registros de 32 bits donde pueden almacenar hasta una dirección completa de 64 bits, DH (Destination high) y DL (Destination low) y en nuestro caso, empleando el proceso de asociación descrito en el párrafo anterior, en DL queda registrada la dirección de 16 bits del coordinador, de tal forma que los end devices emplean tramas con direccionamiento de 16 bits hacia el coordinador. Esta falta de uniformidad entre los direccionamientos derivada del empleo de la autoasociación en los dispositivos XBee es cuanto menos curiosa y requiere de un proceso previo de experimentación para llegar a estas conclusiones, pues la información que proporciona DIGI es realmente escasa. A efectos prácticos lo que interesa para determinar si un end device está asociado es, si se recibe una trama Modem status response indicando una correcta asociación y es esto lo que se emplea en el programa de los motes. Una vez que recibimos dicha trama, obtenemos la dirección de red del coordinador para poder direccionarle una trama con los datos de la asociación que contiene los sensores o actuadores instalados. Al ser el proceso de asociación algo puntual, no tiene sentido el que se trate de una tarea periódica ni de algo que se ejecute en un instante fijo sino que puede tener la consideración de evento asíncrono y modelarse como un manejador de interrupción. Se ha generado por lo tanto el código que completa la interrupción de la UART del microcontrolador de la siguiente manera: /** * Rutina de interrupción para la recepción de tramas del XBee en formato API 2 * * Tipos de trama que puede recibir: * - MODEM_STATUS_RESPONSE * - RX_64_RESPONSE * * La RX_16_RESPONSE no se puede dar por el uso de autoasociación, ya que * todos los end devices tienen como dirección de red 0xFFFE y es imposible * direccionar. * * Se recibirá una trama MODEM_STATUS_RESPONSE en los siguientes casos: * - HARDWARE_RESET >> 0x7E|0x00|0x02|0x00|CHK * - ASSOCIATED >> 0x7E|0x00|0x02|0x02|CHK * - DISASSOCIATED >> 0x7E|0x00|0x03|0x00|CHK * (solo en el caso de que se fuerce la desasociación usando ATDA) * * Si el XBee logra asociarse al coordinador, este mandará por la UART una trama * MODEM_STATUS con la información ASSOCIATED y procederá entonces a enviar al * coordinador la trama de asociación con la información necesaria para configurarse * en el sistema. * Puede ocurrir que el proceso de asociación sea masivo y que todos los nodos intenten * asociarse al sistema de forma simultánea. Para minimizar el impacto de este probable caso, * haremos que espere un breve tiempo aleatorio antes de enviar la trama. * Solo en el momento en que recibe una trama ASSOCIATED, inicia el funcionamiento normal * del mote, lo que implica que arranca los timer */ ISR(USART_RX_vect) { cli(); XBee_ResetPacket(&packet); uint8_t result = XBee_GetPacket(&packet); Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 60 if (result == 1) { if (packet.apiId == XBEE_MODEM_STATUS_RESPONSE) {/ uint8_t status; if (XBee_ReadModemStatusPacket(&packet, &status)) { if (status == ASSOCIATED) {/** Si indica asociación correcta*/ XBee_ResetPacket(&packet); XBee_CreateATCommandPacket(&packet, 0x52, "DL", NULL, 0); _delay_ms(5000); XBee_SendPacket(&packet, 0); } } } else if (packet.apiId == XBEE_ATCOMMANDRESPONSE) { uint8_t frameID; char* command; uint8_t status; int data; if (XBee_ReadAtResponsePacket(&packet, &frameID, &command, &status, &data)) { uartSendByte('C'); if (strcmp(command, "DL") == 0) { mac = data; } XBee_ResetPacket(&packet); char* payload = createSensorAssociationPayload(sensors, 3); XBee_CreateTX16Packet(&packet, 0x52, mac, 0x00, payload, strlen(payload)); XBee_SendPacket(&packet, strlen(payload)); free(payload); free(command); init_normal_mode(); } } sei(); } } El algoritmo funciona básicamente de la siguiente forma: cuando el microcontrolador detecta entrada de datos en el buffer de la USART, lanza la rutina de interrupción asociada que en este caso está identificada por USART_RX_vect. Recordemos que la familia AVR dispone de interrupciones vectorizadas con prioridades estáticas, y por ello han usado el sufijo _vect para identificarlas. Una vez entra en la rutina de interrupción, resetea el paquete XbeePacket, es decir, limpia los valores que pueda tener y libera los punteros. La implementación de esta función es la siguiente: void XBee_ResetPacket(XBeePacket* packet) { packet->dataPtr = (uint8_t*) packet; packet->crc = 0; /** Limpia el Checksum*/ packet->rxState = XBEE_PACKET_RX_START;/** Estado inicial de recepción*/ packet->length = 0;/** Limpia la longitud del paquete */ packet->index = 0;/** Comienzo del paquete */ packet->apiId = 0; memset(packet->payload, 0, 100);/** Reserva 100 bytes con valor 0*/ } Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 61 Una vez limpio el paquete se puede proceder a la lectura de la información que llega a través de la USART. Esto se realiza mediante la llamada a la función XBee_GetPacket que tiene la siguiente implementación: uint8_t XBee_GetPacket(XBeePacket* packet) { uint8_t ret = 0; uint8_t byte; while (serialAvailable()) { byte = uartReadByte(); switch (packet->rxState) { case XBEE_PACKET_RX_START: if (byte == XBEE_PACKET_STARTBYTE) packet->rxState = XBEE_PACKET_RX_LENGTH_1; break; case XBEE_PACKET_RX_LENGTH_1: packet->length = byte; packet->length <<= 8; packet->rxState = XBEE_PACKET_RX_LENGTH_2; break; case XBEE_PACKET_RX_LENGTH_2: packet->length += byte; if (packet->length > XBEE_MAX_PACKET_SIZE) { packet->rxState = XBEE_PACKET_RX_START; ret = -2;//LENGTH Error } else { packet->rxState = XBEE_PACKET_RX_PAYLOAD; } packet->crc = 0; break; case XBEE_PACKET_RX_PAYLOAD: *packet->dataPtr++ = byte; if (++packet->index >= packet->length) packet->rxState = XBEE_PACKET_RX_CRC; packet->crc += byte; break; case XBEE_PACKET_RX_CRC: packet->crc += byte; packet->rxState = XBEE_PACKET_RX_START; if (packet->crc == 0xFF) return 1;//Everything OK! else { XBee_ResetPacket(packet); return -1;//CRC Error } } _delay_ms(20);//Necesita un delay } return ret; } Esta rutina se ejecuta en un bucle mientras haya datos en el buffer de entra da de la USART. La estructura es la de una máquina de estados que es una solución elegante para detectar formatos de datos estructurados, como son las tramas API del transceptor XBee. Por lo tanto, se han definido un conjunto de estados de recepción de tramas y son los siguientes: Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 62 // estados de recepción de paquete #define XBEE_PACKET_RX_START 0 /** Inicio de recepción */ #define XBEE_PACKET_RX_LENGTH_1 1 /**Recepción de la parte alta de la longitud del paquete*/ #define XBEE_PACKET_RX_LENGTH_2 2 /**Recepción de la parte baja de la longitud del paquete*/ #define XBEE_PACKET_RX_PAYLOAD 3 /** Recepción de la información o payload*/ #define XBEE_PACKET_RX_CRC 4 /** Recepción del checksum*/ y se ha implementado el siguiente grafo de estados: FIGURA 41: GRAFO DE ESTADOS DE RECEPCIÓN DE TRAMAS EN EL MICROCONTROLADOR Para determinar si quedan datos en el buffer de entrada de la USART, se ha implementado una pequeña utilidad específica e inspirada en sistemas de mayor tamaño y complejidad, en lo que se conoce como BSP(Board support package), que define una interfaz de funciones de bajo nivel que son necesarias para implementar la aplicación pero cuya implementación cambia, como es normal, dependiendo del microcontrolador elegido. Así pues, hay una interfaz común con funciones útiles y su implementación se adecúa a cada caso. Esto es lo que se ha pretendido, poniendo las miras en que sería posible que cambiara el microcontrolador y por lo tanto las implementaciones de bajo nivel. Se ha creado una cabecera de funciones de utilidad muy sencillas pero que ejemplifican el uso de un BSP. Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 63 AVR_PORT.H #ifndef AVR_PORT_H_ #define AVR_PORT_H_ #include <stdint.h> #include "avrlibtypes.h" #define ADC_V_REF 3.3 //Tensión de referencia del ADC #define ADC_RESOLUTION ADC_V_REF/1024 //Resolución del ADC double getA2dValue(char channel); void uartSendByte(uint8_t byte); uint8_t uartReadByte(); uint8_t serialAvailable(); uint8_t isOverrun(); void toggle(); void on(); void off(); #endif /* AVR_PORT_H_ */ AVR_PORT.C #include "avr_port.h" #include <stdint.h> #include <avr/io.h> #include <util/delay.h> #include "a2d.h" void uartSendByte(uint8_t byte) { UDR0 = byte; while (!(UCSR0A & (1 << UDRE0))) { } } uint8_t uartReadByte() { return UDR0; } uint8_t serialAvailable() { return (UCSR0A & (1 << RXC0)); } double getA2dValue(char channel){ unsigned short raw = a2dConvert10bit(channel); Realización de sistema domótico con microcontroladores de bajo coste (AVR) y módulos RF, verificando el estándar 802.15.4 Página 64 return raw * ADC_RESOLUTION; } uint8_t isOverrun() { return (UCSR0A & (1 << DOR0)); } void toggle() { PORTB ^= _BV(PINB5); } void on() { PORTB |= _BV(PINB5); } void off() { PORTB &= ~_BV(PINB5); } 3.2.4. PROGRAMA PRINCIPAL Básicamente inicializa el sistema de I/O mediante una llamada a la función setup_io, que cada mote implementa según su funcionalidad. Seguidamente configura un modo de bajo consumo en los registros del microcontrolador e inicializa la USART para permitir autogestión y reseteo del mote. Automáticamente entra en un bucle infinito de ejecución en el que duerme y ejecuta código de interrupción. /** * Rutina principal para los motes. * Inicia el I/O y establece un modo de bajo consumo */ int main() { cli(); setup_io(); setup_sleep_mode(); uart_init(); XBee_ResetPacket(&packet); wdt_disable(); for (;;) { sei(); sleep_enable(); sleep_mode(); sleep_disable(); cli(); } return 0; }