desarrollo de una pasarela zigbee/802.15.4
Anuncio
!∀#∃%%&∋%∋()∀∗∋∋!∋#+, %#∀#∃% ∋ %∗+∋!(− %∀!∋.∀,%∀∗+(∋%∋!∗)∀∗∋!∀/∋#0∀#+%1 ∗+2+( 344444444444444444444444444444444444444444444444444444444444444 344444444444444444444444444444444444444444444444444444444444444 344444444444444444444444444444444444444444444444444444444444444 2∀(∀5 6&∀(∋!(+7∋#+%∗∋∀((∋(∀ !∀∗+ ∗∋!∀! ,%+3∀8∗∋(%9%∗∋6)∋6 ∗(&∗+2+(3∗ ∀(∗+∀1!∀(:(∋6 4444444444444444 44444444444444444444444444444444444444444444444444444444444444 72∀(∀; ∋#+%1∋1∋∋.∋%∗∋/(,∀∗∀2+(!+1#+,2+%∋%∋1∗∋!(− %∀!!∀2(∋1∋%∋ ∗!&∋%#∀3 9!∀&∀∀4444∗∋44444444444444∗∋ !<∀(∋1∗∋%∋<∀ !<∀∋#(∋∀(+<∀ ∗+3444444444444444 ∗+3444444444444444 !<∀+#∀! ∗+3444444444444444 ∀8∗∋(%9%∗∋6)∋6 ∗ ∀(∗+∀1!∀(:(∋6 ∋#%+!+&)∀!∋#(∃%#∀3 %&∋%∋()∀∗∋∋!∋#+, %#∀#∃% =2∀1∀(∋!∀&=∋∋>?≅≅>≅Α %∋1∋2(+7∋#+1∋(∋∀!6∀ %∋1 ∗+∗∋!∀1#∀(∀#∋()1#∀1∗∋! #+%5 %+∗∋1+! #+%∋1∋1∀%∗∀(6∀∗∀1&=∋∋<>3?3≅71∋∗∋1∀((+!!∀ %∀ 2∀1∀(∋!∀; ∋2+1−!∀!∀(∀%1/∋(∋%#∀∗∋∗∀+1∗∋1∗∋!∀(∋∗#+,2 ∋1∀2+(!+1 1∋%1+(∋1&=∋∋<>3?3≅0∀1∀ %∀1∋(∋∗∋∗(∋##+%∋1∋12∋#/#∀∗∀12+(∋! 1 ∀(+3 9!∀&∀%∋(+∗∋ !∀#∀ ∃%&∋ Acrónimos AES Advanced Encryption Standard ANSI American National Standards Institute ASCII American Standard Code for Information Interchange ASH A Shell API Application Programming Interface APS Application Support Sub-layer CCA Clear Channel Assessment CGI Common Gateway Interface CSMA-CA Carrier Sense Multiple Access-Collision Avoidance DIN Deutsches Institut für Normung DSSS Direct Sequence Spread Spectrum ED Energy Detection FCS Frame Check Sequence GPL General Public License HTML HyperText Markup Language IEEE Institute of Electrical and Electronics Engineers i ii IP Internet Protocol ISM Industrial, Scientic and Medical ISO International Organization for Standardization Joint Test Action Group JTAG Link Quality Indication LQI LR-WPAN Low Rate Wireless Personal Area Network MAC Medium Access Control MIPS Microprocessor without Interlocked Pipeline Stages MCU MicroController Unit Open Systems Interconnection OSI SAP Service Access Point SCP Secure Copy Protocol SSH File Transfer Protocol SFTP Start Of Frame SOF SPI Serial Peripheral Interface SSH Secure SHell SSP Secure Services Provider PAN Personal Area Network PPDU RISC Reduced Instruction Set Computer UART UDP Physical layer conversion Protocol Data Unit Universal Asynchronous Receiver-Transmitter User Datagram Protocol iii URL Uniform Resource Locator USB Universal Serial Bus W3C World Wide Web Consortium WAN Wide Area Network WHATWG Web Hypertext Application Technology Working Group WLAN Wireless Local Area Network WPAN Wireless Personal Area Network ZASA ZDO ZigBee Accelerator Sample Application ZigBee Device Object iv Índice general 1. Introducción 1.1. 1.2. 1.3. 1.4. 1.5. 1 Ubicación tecnológica . . . . . . . . . . . . . . . . . . . . . . . Tecnologías inalámbricas de corto alcance: ZigBee o Bluetooth El papel de ZigBee/802.15.4 en el futuro de las comunicaciones Motivación y objetivos del proyecto . . . . . . . . . . . . . . . Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. ZigBee/802.15.4 1 2 5 6 6 9 2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Evolución de las redes inalámbricas de área personal . . . . 2.1.2. IEEE 802.15.4 y ZigBee . . . . . . . . . . . . . . . . . . . . 2.1.3. Certicación de un dispositivo ZigBee . . . . . . . . . . . . . 2.1.4. Arquitectura de ZigBee . . . . . . . . . . . . . . . . . . . . . 2.1.5. Versiones de ZigBee . . . . . . . . . . . . . . . . . . . . . . . 2.1.6. Empaquetamiento, direccionamiento y acceso al canal . . . . 2.2. IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Tipos de dispositivos . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Topología de red . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3. Capa física IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . 2.2.3.1. Detección de energía recibida (ED) . . . . . . . . . 2.2.3.2. Indicador de calidad de enlace (LQI) . . . . . . . . 2.2.3.3. Evaluación de canal libre (CCA) . . . . . . . . . . 2.2.3.4. Formato de PPDU . . . . . . . . . . . . . . . . . . 2.2.3.5. Características que reducen el consumo energético capa física . . . . . . . . . . . . . . . . . . . . . . . v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . la . . 9 9 10 12 12 14 15 18 19 20 24 25 25 26 26 26 ÍNDICE GENERAL vi 2.2.4. Capa MAC IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . 2.2.4.1. Estructura de supertrama (Modo balizado) . . . . 2.2.4.2. Modelo de transferencia de datos . . . . . . . . . . 2.2.4.3. Inicialización y mantenimiento de una PAN . . . . 2.2.4.4. Unión a una red ZigBee . . . . . . . . . . . . . . . 2.2.4.5. Sincronización . . . . . . . . . . . . . . . . . . . . 2.2.4.6. Formato de la trama MAC . . . . . . . . . . . . . 2.2.4.7. Características que reducen el consumo energético capa MAC . . . . . . . . . . . . . . . . . . . . . . 2.3. ZigBee Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Capa de Red ZigBee . . . . . . . . . . . . . . . . . . . . . . 2.3.1.1. Reincorporación a la red . . . . . . . . . . . . . . . 2.3.1.2. Enrutamiento ZigBee . . . . . . . . . . . . . . . . . 2.3.1.3. Características que reducen el consumo energético capa de red . . . . . . . . . . . . . . . . . . . . . . 2.3.2. Capa de Aplicación ZigBee . . . . . . . . . . . . . . . . . . . 2.3.2.1. Perles de aplicación, grupos y endpoints . . . . . 2.4. Seguridad en ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en . . . . . . . . . . en . . . . . . . . . . . . . . . . . . . . . . la . . . . . . . . . . la . . . . . . . . 3. Componentes y tecnologías utilizadas 3.1. Elementos hardware . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Equipo de desarrollo eZ430-RF2480 de Texas Instruments 3.1.2. Conversor TTL-232R-3V3 de FTDI . . . . . . . . . . . . . 3.1.3. Router ASUS WL-500G Premium . . . . . . . . . . . . . . 3.2. Elementos software . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1. DD-WRT . . . . . . . . . . . . . . . . . . . . . . 3.2.1.2. Entorno de desarrollo Eclipse . . . . . . . . . . . 3.2.1.3. MSP430 IAR Embedded Workbench . . . . . . . 3.2.1.4. WinSCP . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.5. Putty . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1.6. XVI32 . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Programación . . . . . . . . . . . . . . . . . . . . . . . . . 27 28 29 30 31 31 32 32 33 33 33 34 36 36 37 38 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 41 46 48 51 51 51 55 56 58 59 60 61 ÍNDICE GENERAL vii 3.2.2.1. C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.2. CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.3. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Desarrollo del sistema 69 4.1. Descripción de objetivos . . . . . . . . . . . . . . . . . 4.1.1. Requisitos del sistema . . . . . . . . . . . . . . 4.2. Conectividad entre dispositivos . . . . . . . . . . . . . 4.3. Desarrollo de la aplicación pasarela . . . . . . . . . . . 4.3.1. Funciones que componen la aplicación pasarela . 4.3.2. Diagramas de ujo . . . . . . . . . . . . . . . . 4.4. Desarrollo de la interfaz . . . . . . . . . . . . . . . . . 4.4.1. Interacción a traves de la interfaz web . . . . . 4.4.2. Interacción a través de comandos . . . . . . . . 4.5. Conguración inicial automatizada . . . . . . . . . . . 4.6. Integración en el sistema operativo DD-WRT . . . . . 4.6.1. Extracción del rmware DD-WRT . . . . . . . . 4.6.2. Modicación del rmware DD-WRT . . . . . . 4.6.3. Reconstrucción del rmware DD-WRT . . . . . 4.7. Aplicación cargada en los sensores ZigBee/802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Fase de pruebas 5.1. Descripción del entorno de pruebas 5.2. Procesos de vericación . . . . . . . 5.2.1. Pruebas unitarias . . . . . . 5.2.2. Pruebas de integración . . . 5.2.3. Pruebas de sistema . . . . . 61 63 67 . . . . . . . . . . . . . . . 69 69 71 74 74 80 82 83 84 85 86 87 88 89 90 93 . . . . . . . . . . . . . . . 6. Conclusiones y líneas futuras de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 . 94 . 94 . 100 . 101 103 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.2. Líneas futuras de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 A. Manual de usuario 107 A.1. Instalación del sistema operativo en el router . . . . . . . . . . . . . . . . . 107 ÍNDICE GENERAL viii A.1.1. Actualización desde otra versión de DD-WRT A.1.2. Instalación en otros casos . . . . . . . . . . . A.2. Conguración inicial . . . . . . . . . . . . . . . . . . A.3. Manejo de la interfaz . . . . . . . . . . . . . . . . . . Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 107 107 107 109 Índice de guras 1.1. Ámbitos de aplicación de distintas tecnologías [30] . . . . . . . . . . . . . . 2.1. Logotipo ZigBee [21] 2.2. Arquitectura de la pila ZigBee/802.15.4 [20] . . . . . . . . . . . . . . . . . 13 2.3. Tramas y empaquetamiento ZigBee [30] . . . . . . . . . . . . . . . . . . . . 15 2.4. Topología en estrella [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5. Topología en árbol o jerárquica [8] . . . . . . . . . . . . . . . . . . . . . . . 22 2.6. Topología en árbol agrupado [8] . . . . . . . . . . . . . . . . . . . . . . . . 22 2.7. Topología Mallada [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8. Canales IEEE 802.15.4 [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.9. Estructura supertrama [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10. Descubrimiento de ruta [20] 3 12 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.11. Encaminamiento jeráquico [20] . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1. Contenido eZ430-RF2480 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2. Conexión CC2480-MSP430 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3. Distribución de protocolos CC2480-MSP430 [26] . . . . . . . . . . . . . . . 44 3.4. Formato de trama intercambiada entre CC2480 y MSP430 . . . . . . . . . 44 3.5. Campo de Comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.6. FTDI TTL-232R-3V3 [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.7. Asus WL 500G Frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.8. Asus WL 500G Trasera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.9. ASUS WL-500G Premium Interior . . . . . . . . . . . . . . . . . . . . . . 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.11. Eclipse: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.10. DD-WRT: Interfaz Web ix ÍNDICE DE FIGURAS x 3.12. MSP430 IAR Embedded Workbench: Estructura [24] . . . . . . . . . . . . 58 3.13. Putty: Pantalla Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.14. XVI32: Ejemplo de cambio de formato 61 . . . . . . . . . . . . . . . . . . . . 3.15. Lenguages de Programación: Distribución de uso [29] . . . . . . . . . . . . 63 4.1. FTDI TTL-232R-3V3: Pin out [18] . . . . . . . . . . . . . . . . . . . . . . 72 4.2. Esquemático de conexión entre MSP430 y CC2480 . . . . . . . . . . . . . . 73 4.3. Pasarela: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4. Lectura y envío: Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . 81 Índice de tablas 1.1. Comparativa de tecnologías inalámbricas [17] . . . . . . . . . . . . . . . . . 4 2.1. ZigBee 2006 y PRO: Características destacadas [20] . . . . . . . . . . . . . 16 3.1. Características Asus WL-500G Premium [2] . . . . . . . . . . . . . . . . . 48 3.2. DD-WRT: Utilidades principales [1] . . . . . . . . . . . . . . . . . . . . . . 53 4.1. Interconexión entre conversor y sensor 72 xi . . . . . . . . . . . . . . . . . . . . xii ÍNDICE DE TABLAS Capítulo 1 Introducción 1.1. Ubicación tecnológica Los consumidores descubren día a día que la interconexión de sistemas empotrados permite un mayor y más exible control sobre su entorno personal y profesional. Esto tiene como resultado que se esté produciendo una mayor demanda de estos dispositivos. Las comunicaciones entre distintos tipos de dispositivos comunes en la vida diaria como cámaras, teléfonos móviles y un largo etcétera son ya una realidad. Por todo ello, el próximo requisito en estos dispositivos será la posibilidad de comunicarse con objetos que hasta ahora no poseían esas capacidades de comunicación, como electrodomésticos o automóviles. Tanto ZigBee, basado en el estándar 802.15.4 del IEEE (Institute of Electrical and Electronics Engineers ), como Bluetooth, basado en el estándar 802.15.1 del IEEE, dan respuesta a ésto. Cada estándar IEEE dene una capa física y una pila de protocolos distinta, operando ambos dentro de la banda ISM (Industrial, Scientic and Medical ). A pesar de sus similitudes, ZigBee y Bluetooth no son intercambiables como soluciones tecnológicas y para decidir cual de los dos se ha de elegir, deben tenerse claras las ventajes y desventajas de cada uno de ellos. 1 2 1.2. CAPÍTULO 1. INTRODUCCIÓN Tecnologías inalámbricas de corto alcance: ZigBee o Bluetooth Bluetooth sobrepasa a ZigBee en velocidad de transferencia, posibilidades de interconexión, capacidad para evitar las interferencias en frecuencia y estandarización de perles de aplicación. Bluetooth es ideal para transferencia de archivos e intercambio de datos, y más adecuado para la comunicación de ordenadores con periféricos. En resumen, se puede determinar que si la aplicación necesita de forma predominante alguna de las siguientes características, se debe elegir un dispositivo Bluetooth: Imprescindible si se necesita: • Intercambio de datos en tiempo real (audio o vídeo streaming ) • Calidad de servicio garantizada Opción más adecuada si se necesita: • Identicación de compatibilidad entre dispositivos o disponibilidad de servicios por parte de los sensores. • Interoperabilidad garantizada entre dispositivos similares de distintos fabrican- tes. Por otro lado, ZigBee aventaja a Bluetooth en cuanto a duración de la batería de los dispositivos y es más robusto en caso de fallos de sensores en la red. ZigBee es la mejor alternativa para aplicaciones que necesiten la trasferencia de pequeños paquetes sin una periodicidad denida a través de redes malladas. En resumen, se puede determinar que si la aplicación necesita de forma predominante alguna de las siguientes características, se debe elegir un dispositivo ZigBee: Imprescindible si se necesita: 1.2. TECNOLOGÍAS INALÁMBRICAS DE CORTO ALCANCE: ZIGBEE O BLUETOOTH • Capacidad para la interconexión simultánea de cientos de dispositivos. • Enrutamiento multisalto de mensajes hacia un dispositivo localizado más allá del rango de trasmisión directa del dispositivo transmisor. Opción más adecuada si se necesita: • Monitorización de múltiples dispositivos. El mercado de ambos estándares está creciendo de forma signicativa en los últimos años, presentando ambas opciones diferentes, pero en parte solapados, dominios de aplicación. A pesar de haberse descritos solo estas dos opciones, se deben mencionar otras tecnologías que también pueden coincidir parcialmente en cuanto a su dominio de aplicación, tales como Ultra Wide Band, Wi-Fi1 o la red de telefonía móvil. En la gura 1.1 podemos ver reprentado dicho solape entre las tecnologías anteriormente mencionadas. Figura 1.1: Ámbitos de aplicación de distintas tecnologías [30] 1 Aunque se pensaba que el término viene de Wireless Fidelity como equivalente a Hi-Fi, High Fidelity, que se usa en la grabación de sonido, realmente la Wireless Ethernet Compatibility Alliance contrató a una empresa de publicidad para que le diera un nombre a su estándar, de tal manera que fuera fácil de identicar y recordar. 3 4 CAPÍTULO 1. INTRODUCCIÓN Se muestra a continuación en la tabla 1.1 una comparación entre las tecnologías anteriomente mencionadas: Estándar ZigBee Bluetooth Ultra Wide 3.0 Band 802.15.4 802.15.1 802.15.3a 802.11a/b/g Banda de 868/915 MHz; 2.4 GHz 3.1-10.6 GHz 2.4 GHz;5 GHz Frecuencias 2.4 GHz Tasa de 250 Kb/s 1 - 24 Mb/s 110 Mb/s 54 Mb/s Alcance 70m 100m 10m 100m Número de 1/10; 16 79 (1-15) 14 Ancho de Banda 0.3/0.6 MHz; 2 1 MHz 500MHz-7.5 GHz 22MHz de Canal MHz Tipo de BPSK GFSK BPSK, QPSK BPSK, QPSK, Modulación (+ASK), COFDM, O-QPSK CCK, M-QAM Especificación Wi-Fi IEEE Transferencia Máxima canales Ensanchamiento DSSS FHSS DS-UWB, DSS, CCK, OFDM MB-OFDM Mecanismo de Selección Salto de Salto de Selección Dinámica de Coexistencia Dinámica de Frecuencia Frecuencia Frecuencia Frecuencia Adaptativo Adaptativo Control de Potencia Transmitida (802.11h) Número Máximo de sensores > 65000 8 8 (para una piconet ) Tabla 1.1: Comparativa de tecnologías inalámbricas [17] 5 1.3. EL PAPEL DE ZIGBEE/802.15.4 EN EL FUTURO DE LAS COMUNICACIONES 1.3. El papel de ZigBee/802.15.4 en el futuro de las comunicaciones En los próximos años es muy probable que ZigBee vea incrementado su uso ya que sus características se adaptan a los requerimientos necesarios para un amplio rango de soluciones, destacándose las siguientes: Automatización de tareas en el hogar Aplicaciones para el ahorro de energía Aplicaciones destinadas a las telecomunicaciones Si se toma como referencia el tamaño de la pila de protocolos, el de ZigBee, en torno a 32KB, es aproximadamente una tercera parte del tamaño de la pila de otros protocolos de comunicaciones inalámbricos. Además, para dispositivos nales, este tamaño puede verse reducido hasta los 4KB. Esto redunda en un menor coste, tanto por la memoria necesaria para su almacenamiento como por su mayor simplicidad de funcionamiento y, por lo tanto, el ahorro en otros componentes hardware. Igualmente, la sencillez antes mencionada posibilita un rápido desarrollo de aplicaciones y, por lo tanto, una mayor capacidad de adaptación al rápido cambio al que se ven sometidos los productos tecnológicos. Por todo lo anterior, junto a otras razones que se detallarán en sucesivos capítulos, ZigBee/802.15.4 ha sido adoptado ya por multitud de empresas y se prevé que en los próximos años pueda aprovecharse todo su potencial. 6 1.4. CAPÍTULO 1. INTRODUCCIÓN Motivación y ob jetivos del proyecto En el contexto de una sociedad en continuo movimiento y con capacidad de conexión a internet allá donde se encuentre, la posibilidad de poder acceder a información o noticación de eventos concretos en ambientes personales (como puede ser el residencial) se hace cada vez más útil, necesario e incluso demandado por los consumidores. Por ello, considerando el tipo de información a noticar como de periodicidad no determinada y con amplios intervalos de tiempo entre comunicaciones sucesivas, la elección de ZigBee para la red de control se convierte en una elección acertada. Una vez decidido esto, y teniendo en cuenta la exibilidad, expansión y cobertura de las redes basadas en IP (Internet Protocol ) en todo el mundo, la combinación de redes de sensores ZigBee con la red IP se vislumbra como una solución de un gran atractivo con unas posibilidades interesantes. Por ello, el objetivo de este proyecto es la creación de una pasarela entre una red ZigBee/802.15.4 e IP, usando un router comercial a modo de ejemplo de aplicación. Se elige como información a transmitir la temperatura en el lugar de colocación del sensor ZigBee. La nalidad será conseguir que dicha información pueda llegar hasta una o varias direcciones IP, congurables mediante una interfaz web. 1.5. Estructura del documento El documento que a continuación se presenta está dividido en siete capítulos, quedando organizado como a continuación se detalla: Capítulo 1: Introducción Breve presentación de ZigBee/802.15.4 y comparativa con otras posibilidades para las comunicaciones inalámbricas. Justicación de la utilidad de este Proyecto Fin de Carrera Capítulo 2: ZigBee/802.15.4 1.5. ESTRUCTURA DEL DOCUMENTO 7 Descripción detallada de ZigBee/802.15.4 por ser considerado el estándar más novedoso y quizás desconocido de los que se usan para este Proyecto Fin de Carrera. Capítulo 3: Componentes y tecnologías utilizadas Recopilación de las herramientas hardware y software que se hicieron imprescindibles para llevar a cabo este desarrollo. Capítulo 4: Desarrollo del sistema Detalle de las decisiones adoptadas y desarrolladas así como descripción de todos los elementos que la integran. Capítulo 5: Fase de pruebas Descripción del proceso a través del cual se ha conseguido asegurar el correcto funcionamiento de la solución desarrollada. Capítulo 6: Conclusiones y líneas futuras de traba jo Presentación de las conclusiones obtenidas tras la elaboración de este Proyecto Fin de Carrera, así de como posibles mejoras o líneas distintas de trabajo que pueden seguirse tomando este desarrollo como punto de partida. Capítulo 7: Manual de usuario Breve guía que detalla los pasos a seguir para lograr el correcto funcionamiento de la pasarela, partiendo de la instalación en el router y terminando en la puesta en marcha y posterior recepción de paquetes de datos en un dispositivo remoto con acceso a internet. 8 CAPÍTULO 1. INTRODUCCIÓN Capítulo 2 ZigBee/802.15.4 Como primer paso, y antes de entrar en la materia principal sobre la que versa este Proyecto Fin de Carrera, se hará un breve recorrido a través del conjunto de soluciones estandarizadas ZigBee/802.15.4 para poder entender tanto sus fundamentos básicos, como las causas que lo han hecho tan prometedor en los últimos años con la llegada de la domótica. 2.1. 2.1.1. Introducción Evolución de las redes inalámbricas de área personal Las redes celulares pueden ser consideradas la extensión lógica y natural de las redes telefónicas por cable. Conforme fueron aumentando tanto las necesidades de movilidad como el coste de instalación de las redes cableadas, la idea de lograr conexiones personales independientemente de la localización del usuario también progresó. Durante la década de los 80, se pasó de la búsqueda de células capaces de proporcionar áreas de cobertura de hasta decenas de kilómetros, al interés por células con menor área de cobertura a cambio de una mayor capacidad para grandes densidades de usuarios. Es en 9 10 CAPÍTULO 2. ZIGBEE/802.15.4 este último punto donde se enmarca el grupo de trabajo IEEE 802.11, en la investigación y estandarización de redes WLAN (Wireless Local Area Network ). Sin embargo, mientras IEEE 802.11 se centra en proporcionar altas tasas de datos a distancias típicas de decenas de metros, las WPAN (Wireless Personal Area Network ) tienen como principal objetivo dar servicio en el entorno próximo a una persona u objeto, buscando ante todo lograr dispositivos de bajo coste, bajo consumo y pequeño tamaño. El grupo de trabajo IEEE 802.15 surge como respuesta a estos requisitos. Este grupo ha denido tres clases de WPAN diferenciadas por sus tasas de transferencias de datos, consumo energético y calidad de servicio. Las WPAN de alta tasa de transferencia de datos, IEEE 802.15.3, son adecuadas para aplicaciones multimedia que requieren de una calidad de servicio alta. Las WPAN de tasa de transferencia media, IEEE 802.15.1/Bluetooth, están destinadas al manejo de un amplio rango de aplicaciones, como las destinadas a teléfonos móviles, y permiten una calidad de servicio adecuada para comunicaciones por voz. Por último, se encuentran las WPAN de baja tasa de transferencia de datos, IEEE 802.15.4/LR-WPAN (Low Rate WPAN), indicadas para satisfacer las necesidades de un amplio rango de aplicaciones en el ámbito industrial, médico o residencial de bajo consumo de energía y bajo coste. 2.1.2. IEEE 802.15.4 y ZigBee ZigBee es un protocolo de interconexión inalámbrico de baja tasa de transferencia de datos, bajo coste y reducido consumo energético orientado hacia la automatización y control remoto de aplicaciones. No se trata de una tecnología, sino de un conjunto estandarizado de soluciones que pueden ser implementadas por cualquier fabricante. ZigBee está promovido por la ZigBee Alliance, asociación creada en 1998 y que, según un informe reciente de ON World [12], ha sido adoptada por más de 350 fabricantes globales, que trabajan de forma conjunta para lograr un estándar global y abierto, contando ingresos anuales que sobrepasan el billon de dólares estadounidenses. La especicación 1.0 de ZigBee se aprobó el 14 de Diciembre de 2004, estando disponible para miembros de ZigBee Alliance. Dicha especicación se divide en distintos niveles, 2.1. INTRODUCCIÓN 11 accesibles según la categoria adoptada por el suscriptor. Mientras, y en paralelo, el grupo IEEE 802.15.4 había continuado con su trabajo centrado en las WPAN de baja tasa de transferencia de datos el cual comenzó poco tiempo después de la formación de ZigBee Alliance. Más tarde, ZigBee Alliance e IEEE decidieron unicar esfuerzos y criterios, optándose por ZigBee como nombre comercial para la solución tecnológica. Como ya se apuntó anteriormente, ZigBee está indicado como solución de bajo coste y bajo consumo de energía para la interconexión inalámbrica de dispositivos que necesiten un largo ciclo de duración de la batería, pudiendo ir de varios meses a varios años. Además, ZigBee puede ser implementado en redes malladas de un tamaño mayor que las permitidas por Bluetooth. Los dispositivos ZigBee pueden transmitir en rangos de entre 10 y 70 metros, dependiendo de las condiciones radio y del consumo deseado para una determinada aplicación, y opera en las bandas ISM1 , que son bandas reservadas internacionalmente para su uso en campos relacionados con la industria, la ciencia y la medicina, y cuyo acceso es libre sin necesidad de solicitar licencia. El rango de transferencia de datos va de los 250 kbps a los 20 kbps, dependiendo de la banda ISM usada. Desde su unión, IEEE y ZigBee Alliance han trabajado en colaboración para especicar la pila de protocolos. IEEE 802.15.4 se centró en la especicación de las dos capas inferiores del protocolo, las capas física y MAC (Medium Access Contro l), mientras que ZigBee Alliance tuvo como objetivo la denición de las capas superiores, desde la capa de red hasta la capa de aplicación, ambas inclusive. Esta arquitectura puede verse en la gura 2.2. Además, ZigBee Alliance se ocupó de denir una serie de aplicaciones de control destinadas al ámbito residencial y de la construcción, así como de establecer los requisitos para determinar la interoperabilidad de los dispositivos, ocuparse de la parte comercial y determinar las directrices principales en la evolución de ZigBee. 1 2.4 Ghz en todo el mundo, 915 MHz en América y 868 MHz en Europa 12 CAPÍTULO 2. ZIGBEE/802.15.4 2.1.3. Certicación de un dispositivo ZigBee Para que un producto pueda llevar el logotipo de ZigBee Alliance (gura 2.1) debe pasar exitosamente el Programa de Certicación ZigBee. Esto asegura que dicho producto cumple con el estándar descrito en la especicación ZigBee. Se distinguen dos tipos de certicaciones: ZigBee Compliant Platform : se aplica a módulos destinados a ser usados como bloques para la construcción de productos nales. ZigBee Certied Products : aplicado a productos nales construidos en base a bloques con certicación ZigBee Compliant Platform. Figura 2.1: Logotipo ZigBee [21] Aquellos productos que usan perles de aplicación públicos son probados para asegurar la interoperabilidad con otros productos nales ZigBee. Los productos que usan perles de aplicación especícos de un fabricante, y que funcionaran como 'sistemas cerrados', son probados para asegurar que pueden coexistir con otros sistemas ZigBee, esto es, que no intereren en el buen funcionamiento de otros productos ZigBee certicados. 2.1.4. Arquitectura de ZigBee Se presentan a continuación los conceptos esenciales acerca de la arquitectura de la pila ZigBee, la cual se muestra en la gura 2.2. Ninguna de las capas de la pila conoce nada de la capa superior. La capa superior puede ser considerada la 'maestra' que ordena a la capa inferior 'esclava' que realice el 2.1. INTRODUCCIÓN 13 trabajo. Cada capa añade una mayor complejidad basada en el soporte que prestan las capas inferiores. Figura 2.2: Arquitectura de la pila ZigBee/802.15.4 [20] La arquitectura ZigBee/802.15.4 no cumple de manera exacta con el modelo OSI (Open Systems Interconnection ) de siete capas, pero coincide en algunos de sus elementos tales como las capas física, MAC y de red. Las funciones de las capas 4-72 están incluidas en las capas APS (Application Support Sub-layer ) y ZDO (ZigBee Device Object ) del modelo ZigBee. Entre cada capa se denen SAP (Service Access Point ). Los SAP proveen los API (Application Programming Interface ), que permite aislar el trabajo que lleva a cabo una capa respecto a las capas superior e inferior de ésta. ZigBee incluye dos accesos SAP por capa, uno de ellos para datos y otro para gestión. Las dos capas inferiores, física y MAC, están denidas por la especicación IEEE 802.15.4. La capa física simplemente traduce los bits al interfaz aire o viceversa. La capa MAC provee el concepto de red, incluyendo el identicador de PAN (Personal Area Network ), el descubrimiento y unión a otras redes, y comandos para unirse o formar una red. 2 Transporte, Sesión Presentación y Aplicación 14 CAPÍTULO 2. ZIGBEE/802.15.4 La capa MAC no soporta encaminamiento multi salto ni mallado. Las capas de red y aplicación quedarón denidas por la ZigBee Alliance. La capa de red es responsable de la administración de redes malladas, lo cual incluye el envío de paquetes a través de la red, la determinación de rutas para envíos unicast y, de manera general, el control del envío correcto de los paquetes entre sensores. Esta capa incluye también una serie de comandos para la administración de la seguridad en la red. Las redes ZigBee proveen seguridad en la capa de red, tal y como se explicará mas adelante. La capa de aplicación actúa como ltro para las aplicaciones ejecutadas sobre ella, simplicando sus interacciones con otros módulos como Applicastion Prole. Se ocupa también de ltrar mensajes duplicados. Dentro de esta capa se incluye el módulo ZDO, responsable de la gestión de medio radio, del descubrimiento de otros sensores y servicios al alcance y del estado del sensor en la red. Es importante resaltar que no se contempla en la arquitectura ninguna descripción de interacciones entre dispositivos que no se lleven a cabo a través del interfaz aire. ZigBee solo dene el protocolo de red y el comportamiento a través de dicho interfaz. Este hecho permite que todos los mensajes transmitidos a través del interfaz aire por un sensor ZigBee puedan ser interpretados correctamente por cualquier otro sensor ZigBee, consiguiéndose así que los fabricantes innoven a la vez que se mantiene la compatibilidad entre ellos. Todas estas capas serán descritas de manera más detallada en siguientes secciones. 2.1.5. Versiones de ZigBee Hasta el día de hoy existen tres versiones de la pila ZigBee/802.15.4: la primera se denomina ZigBee 2004, la siguiente apareció en Junio de 2006 y se denominó ZigBee 2006 y la última es la versión ZigBee PRO o 2007. El nivel de red de ZigBee 2007 no es compatible con el de ZigBee 2004-2006, aunque un sensor de funcionalidad reducida puede unirse a una red 2007 y viceversa. No pueden combinarse dispositivos enrutadores de las versiones antiguas con un dispositivo coordinador 2007. 2.1. INTRODUCCIÓN 15 Se muestra en la tabla 2.1 un resumen con las características más destacadas incluidas en las versiones 2006 y PRO. 2.1.6. Empaquetamiento, direccionamiento y acceso al canal El empaquetamiento en ZigBee/802.15.4 se realiza a través cuatro tipos de tramas básicas: trama de datos, trama ACK o de acuse de recibo, trama MAC y trama baliza. Podemos ver los campos de estas tramas en la gura 2.3. Figura 2.3: Tramas y empaquetamiento ZigBee [30] La trama de datos presenta una zona de carga de hasta 104 bytes y está numerada para asegurar que todos llegan a su destino. Un campo nos asegura que la trama se ha recibido sin errores. Con esta estructura se aumenta la abilidad en condiciones complicadas de transmisión. La estructura de las tramas ACK permite la realimentación desde el receptor al emisor, conrmándose que fue recibida sin errores. La trama MAC se utiliza para el control remoto y la conguración de los distintos dispositivos. 16 CAPÍTULO 2. El coordinador selecciona el mejor canal disponible para evitar interferencias al inicio Permite el cambio de canal durante la operación para evitar interferencias Asignación distribuida de direcciones Asignación estocástica de direcciones Los dispositivos pueden ser asignados a grupos para direccionarlos de forma común Soporte para dispositivos con función de agregador Encriptado AES de 128 bits con código de integridad de mensaje de 32 bits Contador de tramas para asegurar la no duplicidad Seguridad en la capa de red por defecto y soportada en capas superiores Rotación de la clave de red Centro de seguridad soportado en el coordinador Modo de alta seguridad Centro de seguridad soportado en cualquier dispositivo de la red Tamaño del mensaje de hasta 100 bytes dependiendo del servicio empleado Soporte para mensajes mayores de 100 bytes, teniendo como límite los buers de envío y recepción Algoritmo de enrutamiento tolerante a fallos con capacidad de respuesta a cambios en la red y en el interfaz radio Cada dispositivo mantiene información de sus vecinos, mejorando la abilidad y robustez ZIGBEE/802.15.4 2006 PRO NO SI SI NO SI NO SI SI NO SI SI SI SI SI SI SI SI SI NO NO SI SI SI SI SI SI NO SI SI NO NO SI SI Tabla 2.1: ZigBee 2006 y PRO: Características destacadas [20] SI 2.1. INTRODUCCIÓN 17 La trama baliza se ocupa de activar a los dispositivos, que escanean el canal y luego vuelven a pasar a estado inactivo si no reciben nada más. Estas tramas son importantes para permitir el ahorro de energía de los dispositivos, que esperan el momento adecuado para mantener a los dispositivos sincronizados sin necesidad de estar permanentemente en funcionamiento, permitiendo ahorrar energía. En cuanto al mecanismo de direccionamiento, tanto la capa MAC como la capa de aplicación forman parte de él. Un dispositivo ZigBee está formado por un transceptor radio compatible con el estándar 802.15.4, en el que se implementan dos mecanismos de acceso al canal y una o más descripciones de dispositivos. El transceptor es la base del direccionamiento mientras que las aplicaciones asociadas a un dispositivo se identican por medio de un endpoint numerado entre 1 y 240. Los dispositivos se direccionan empleando 64 bits o un direccionamiento corto de 16 bits que puede asignarse usando dos posibles mecanismos: Mecanismo distribuido: se basa en la generación de subgrupos de direcciones. El coordinador asigna un subgrupo de direcciones a cada uno de sus hijos con capacidad de enrutador. Este proceso de asignación de subgrupos se repite de nuevo en los dispositivos enrutadores de manera iterativa hasta que se llega a los dispositivos nales. Para calcular el tamaño de estos subgrupos de direcciones se tienen en cuenta ciertos parámetros de la red denidos por el coordinador: máximo número de hijos que un padre puede tener, máxima profundidad de la red (es decir, número máximo de saltos hacía arriba o abajo) y máximo número de dispositivos enrutadores que un padre puede tener como hijo. Mecanismo estocástico (solo disponible para ZigBee PRO): basado en la asignación aleatoria. Los dos mecanismos de acceso al canal que se implementan en ZigBee corresponden a redes con funcionamiento balizado y sin funcionamiento balizado. Para una red sin funcionamiento balizado, el mecanismo CSMA-CA (Carrier Sense Multiple Access-Collision Avoidance ) ranurado envía, de manera opcional, tramas ACK para los paquetes recibidos correctamente. En este mecanismo, cada dispositivo es autónomo, pudiendo iniciar una 18 CAPÍTULO 2. ZIGBEE/802.15.4 conversación, en la que otros pueden interferir. Así, el canal puede estar ocupado o el dispositivo destino puede no recibir la petición. Este sistema se usa en sistemas en los que los dispositivos pasan la mayor parte del tiempo inactivos. Para que los demás elementos de la red sigan teniéndolos en cuenta, cada cierto tiempo se activan para anunciar que siguen en la red. Se debe destacar que los dispositivos que actuan como coordinadores no pueden pasar a estado inactivo en ningún momento, debiendo permanecer en modo escucha en todo momento. Por otro lado, en una red con funcionamiento balizado se usa una estructura de supertrama que se estudiará con detalle en 2.2.4.1. 2.2. IEEE 802.15.4 A continuación se describirá de forma detallada la parte de ZigBee responsabilidad del IEEE, sin embargo, se deben tener claras una serie de ideas: IEEE 802.15.4 es: • Un estándar WPAN optimizado para aplicaciones con una baja tasa de trans- ferencia de datos (entre 0.01 y 250 kbit/s) y requisitos mínimos o inexistentes de calidad de servicio. • El tipo de WPAN de menor coste y menor consumo. • Un estándar desarrollado por el IEEE que delega en ZigBee Alliance la parte referente a la mercadotecnia y la conformidad de los dispositivos. • La parte de ZigBee perteneciente a las capas física y MAC. En cuanto a los requisitos hardware de la MCU (MicroController los siguientes: 8 bits Unit ), se denen 2.2. IEEE 802.15.4 19 4 MHz 32 kB ROM 8 kB RAM 2.2.1. Tipos de dispositivos Las redes ZigBee incluyen los siguientes tipos de dispositivos según el papel que desempeñen en la red: Coordinador ZigBee: es el dispositivo más completo, solo puede haber uno en cada red y se encarga de la inicialización y control de la misma. Puede actuar también como centro de seguridad, siendo el encargado de guardar y distribuir las claves de cifrado. Enrutador ZigBee: este dispositivo extiende el área de cobertura, encamina dinámicamente alrededor de obstáculos y proporciona rutas alternativas en caso de congestión o de fallos de dispositivos. Pueden conectarse tanto al coordinador como a otros enrutadores y soporta también dispositivos hijos. Cabe destacar que ofrece un nivel de aplicación para la ejecución de código de usuario. Dispositivo nal ZigBee: debe estar conectado a un coordinador ZigBee o a un enrutador ZigBee y no admite hijos. Posee la funcionalidad necesaria para comunicarse con su sensor padre pero no puede transmitir información destinada a otros dispositivos ni llevar a cabo ninguna operación de enrutamiento. De esta forma, puede permanecer inactivo la mayor parte del tiempo, aumentando la vida de sus baterías. Además, y no menos importante, el hecho de no tener que almacenar tablas de encaminamiento hace que su necesidad de memoria disminuya considerablemente, haciéndolo signicativamente más barato. Por otro lado, atendiendo a la capacidad para actuar según qué tipo de los dispositivos vistos anteriormente, podemos realizar una segunda clasicación: 20 CAPÍTULO 2. ZIGBEE/802.15.4 Dispositivo de funcionalidad completa (FFD: Full Functionality Device ): es capaz de recibir mensajes en formato del estándar 802.15.4 y gracias a su memoria adicional puede actuar como coordinador, enrutador o dispositivo nal ZigBee. Cualquier red ZigBee debe incluir, al menos, un dispositivo ZigBee FFD. Dispositivo de funcionalidad reducida (RFD: Reduced Functionality Device ): presenta capacidad y funcionalidad limitadas (especicadas en el estándar) con el propósito de conseguir bajo coste y simplicidad. Son los sensores/actuadores de la red y, por lo tanto, solo pueden actuar como dispositivos nales ZigBee. 2.2.2. Topología de red En las redes ZigBee pueden encontrarse tres tipos de topologías que se describen a continuación: Estrella: se compone de un dispositivo coordinador y varios dispositivos nales, tal y como se muestra en gura 2.4. En esta topología, el dispositivo nal se comunica solo con el coordinador. Cualquier intercambio de paquetes entre dispositivos nales ha de pasar por el coordinador, siendo ésta su principal desventaja ya que la red depende del buen funcionamiento del coordinador y es fácil la formación de cuellos de botella. Además no presenta rutas alternativas desde la fuente al destino. Como ventajas aporta su simplicidad y el hecho de alcanzar cualquier destino con solo dos saltos. Posibles aplicaciones beneciarias de esta topología son la automatización residencial, periféricos de ordenadores y juguetes. 2.2. 21 IEEE 802.15.4 Figura 2.4: Topología en estrella [8] Árbol o jerárquica: en esta topología la red esta compuesta por un sensor central que actúa como coordinador y varios enrutadores y/o dispositivos nales, tal y como se muestra en la gura 2.5. La misión de los enrutadores es extender la cobertura de la red (aunque también tienen capacidad para ejecutar aplicaciones). Los dispositivos nales conectados a los enrutadores o al coordinador son llamados sensores hijos. Solo los enrutadores y los coordinadores admiten sensores hijo. Cada dispositivo nal solo puede comunicarse con su padre (enrutador o coordinador). El coordinador y los enrutadores pueden tener hijos y, además, son los únicos dispositivos que pueden ser padres. Un dispositivo nal no puede tener hijos por lo que, consecuentemente, no puede actuar como padre. 22 CAPÍTULO 2. ZIGBEE/802.15.4 Figura 2.5: Topología en árbol o jerárquica [8] Árbol agrupado: este es un caso especial de topología en árbol en la que un padre con sus hijos es denominado grupo, tal y como se muestra en la gura 2.6. Cada grupo presenta una identicación única en la red. Esta topología forma parte de la especicación del IEEE 802.15.4 pero no se incluye dentro de ZigBee por lo que no se entrará en más detalles. Figura 2.6: Topología en árbol agrupado [8] 2.2. 23 IEEE 802.15.4 Mallada: consiste en una malla de enrutadores y dispositivos nales interconectados. Cada enrutador está tipicamente conectado a través de, al menos, dos caminos de salida y puede transmitir mensajes a sus vecinos. Tal y como se muestra en la gura 2.7, una red mallada esta compuesta por un único coordinador y múltiples enrutadores y dispositivos nales. En este escenario, añadir o eliminar dispositivos es sencillo, pudiénsose evitar zonas 'muertas', o con señal recibida débil sin más que añadir enrutadores a la red. Como inconvenientes presenta la necesidad de una cabecera de mayor tamaño y que el protocolo de enrutamiento es más complejo que en los otros casos, haciendo los requisitos de memoria y proceso más elevados. Este concepto de red, conocido también como red nodal, es la aportación de ZigBee que mayor interés está despertando entre las empresas desarrolladoras de productos ya que su aplicación hará viable muchas soluciones de domótica vía radio en viviendas construidas, allí donde las tecnologías radio de anteriores generaciones estaban limitadas en cuanto a la cobertura o alcance entre dispositivos. Figura 2.7: Topología Mallada [8] 24 CAPÍTULO 2. ZIGBEE/802.15.4 Sea cual sea la topología elegida, después de que un dispositivo FFD se activa por primera vez, puede establecer su propia red y convertirse en el coordinador. Cada vez que un dispositivo FFD establece una nueva red, elige un identicador PAN que no esté siendo actualmente utilizado por ninguna otra red ZigBee dentro del alcance de cobertura del coordinador. Esto permite a cada red trabajar de forma independiente. 2.2.3. Capa física IEEE 802.15.4 La capa física realiza las funciones de activación/desactivación del transceptor radio, detección de energía, indicador de calidad del enlace, selección de canal y evaluación de canal libre, además de ocuparse de la recepción y transmisión de paquetes a través del interfaz aire. El estándar proporciona dos opciones determinadas por la banda de frecuencia elegida. Ambas están basadas en la técnica DSSS (Direct Sequence Spread Spectrum ). La tasa de transferencia de datos es de 250 kbps en la banda de 2.4 GHz, 40 kbps en la de 915 MHz y 20 kbps en la de 868 MHz. La tasa de 250 kbps se consigue usando un orden mayor de modulación. Por otro lado, frecuencias menores proporcionan un mayor alcance en la cobertura ya que las pérdidas por propagación son menores. Entre 868 y 868.6 MHz hay un único canal, 10 canales entre 902 y 928 MHz y 16 canales entre 2.4 y 2.4835 GHz, tal y como se muestra en la gura 2.8. El hecho de tener canales en diferentes bandas permite el realojo dentro del espectro disponible. El estándar permite también la selección dinámica de canal. En cuanto a la parte hardware, la sensibilidad mínima del receptor ha de ser de -85 dBm para 2.4 GHz3 y de -95 dBm para 868/915 MHz. Por otro lado, la máxima potencia de transmisión ha de estar regulada según la regulación local. Un dispositivo certicado como ZigBee debe indicar su potencia nominal de transmisión indicada en el parámetro de la capa física phyTransmitPower. 3 Aunque los dispositivos comerciales alcanzan a menudo sensibilidades muy inferiores, siendo -100 dBm un valor habitual. 2.2. 25 IEEE 802.15.4 Figura 2.8: Canales IEEE 802.15.4 [20] 2.2.3.1. Detección de energía recibida (ED) La medida de la energía recibida es usada por la capa de red en el algoritmo de selección de canal. Se trata de una estimación de la potencia recibida en el ancho de banda de un canal IEEE 802.15.4 y no decodica la señal recibida. El tiempo requerido para llevar a cabo la estimación debe ser igual al de 8 periodos de símbolo (128 ms en la banda de 2.4 GHz). El resultado de la función ED (Energy Detection ) es noticado como un entero de 8 bits. El valor mínimo indica potencia recibida menor de 10 dB sobre la sensibilidad especicada para el receptor. La amplitud de los posibles valores indicados debe ser de, al menos, 40 dB. 2.2.3.2. Indicador de calidad de enlace (LQI) LQI (Link Quality Indication ) es una medida de la calidad y/o fuerza de la trama recibida. Puede ser implementado por medio de un receptor con capacidad ED, una estimación de la relación señal a ruido o una combinación de ambos métodos. El resultado de LQI será usado por la capa de red o por la de aplicación. LQI se indica mediante un entero de 8 bits, asociándose el mayor y el menor valor 26 CAPÍTULO 2. ZIGBEE/802.15.4 posible con la mayor o menor calidad detectable por el receptor, distribuyéndose los valores de manera uniforme entre estos límites. 2.2.3.3. Evaluación de canal libre (CCA) La operación de CCA (Clear de los siguientes métodos: Channel Assessment ) se lleva a cabo de acuerdo a uno Energía por encima del umbral: CCA informará de canal ocupado si detecta cualquier energía sobre el umbral de ED. Detección de portadora: CCA informará de canal ocupado solo cuando detecte una señal con la modulación y ensanchamiento de las características de IEEE 802.15.4. No tiene en cuenta si la señal esta por encima o por debajo del umbral ED. Detección de portadora con energía por encima del umbral: se trata de una combinación de los dos métodos anteriores. 2.2.3.4. Formato de PPDU La estructura de la PPDU (Physical layer conversion Protocol en la gura 2.3. Esta fomada por los siguientes componentes: Data Unit ) se muestra Cabecera de sincronización: permite al dispositivo receptor sincronizarse. PHY CAB: contiene información acerca de la longitud de la trama. Zona de carga variable (SDU física) que incluirá la trama MAC. 2.2.3.5. Características que reducen el consumo energético en la capa física Se presentan a continuación las características que posibilitan el bajo consumo energético en la capa física: 2.2. IEEE 802.15.4 27 Señalización ortogonal multinivel La baja potencia media usada es lograda gracias a tiempos de funcionamiento reducidos, acompañados de bajos picos de corriente. En la capa física esto fomenta el uso de una tasa de transferencia de datos elevada pero con una baja tasa de símbolos ya que los picos de corriente suelen ir en consonancia con la tasa de símbolos usada más que con la tasa de datos. Esto implica el uso de señalización multinivel. Sin embargo, la señalización multinivel produce una pérdida de sensibilidad que lleva aparejada un aumento del consumo. La solución es el uso de la señalización ortogonal, intercambiando ancho de banda para mejorar la sensibilidad por medio de la ganancia de código. Reducción de la energía usada al activarse Al ser los periodos activos de los sensores IEEE 802.15.4 muy cortos, una parte signicativa de la potencia puede perderse si el transceptor tarda mucho en ponerse a funcionar. El uso de técnicas como DSSS aporta la ventaja de que sus ltros de canal de gran anchura llevan de forma implícita aparejados una baja latencia. No se contempla funcionamiento en modo dúplex para así reducir los picos de corriente. Elección adecuada de la frecuencia de la portadora: por ahora no se contempla el uso de la banda ISM de 60 GHz. 2.2.4. Capa MAC IEEE 802.15.4 La Capa MAC realiza las funciones de administración de la baliza, acceso al canal, administración de las ranuras temporales garantizadas, validación de la trama, acuse de recibo de trama, asociación y disasociación. 28 2.2.4.1. CAPÍTULO 2. ZIGBEE/802.15.4 Estructura de supertrama (Modo balizado) IEEE 802.15.4 permite el uso de la estructura de supertrama. El formato de esta supertrama es denido por el coordinador, quedando localizada entre las balizas y dividida en 16 slots de igual duración. La baliza es enviada en el primer slot de cada supertrama. Si el coordinador no quiere usar la estructura de supertrama puede desactivar la transmisión de balizas, que son usadas para sincronizar los dispositivos adheridos a él, identicar la PAN y describir la estructura de las supertramas. La supertrama esta compuesta de una parte activa y otra inactiva. Durante la parte inactiva, el coordinador no tiene que interactuar con su PAN y entra en modo de bajo consumo. La parte activa consiste en un periodo de acceso contenido (CAP) y otro periodo libre de contención (CFP). Cualquier dispositivo que desee comunicarse durante CAP competirá con otros dispositivos haciendo uso del mecanismo CSMA-CA ranurado. Por otro lado, CFP contiene ranuras temporales reservadas y queda localizado al nal de la parte activa de la supertrama. El coordinador puede asignar hasta siete de estos time slots reservados. Además, una ranura temporal garantizada puede ocupar más de un periodo de ranura. Esta estructura puede verse en la gura 2.9. Figura 2.9: Estructura supertrama [11] Esta estructura garantiza el ancho de banda dedicado y el bajo consumo, siendo especialmente adecuado para aquellos casos en los que el coordinador está alimentado mediante baterías. Los dispositivos que componen la red, escuchan dicho coordinador durante el 2.2. IEEE 802.15.4 29 envío de la baliza4 . Un dispositivo que quiera intervenir, deberá registrarse para el coordinador y luego comprobar si hay paquetes para él. Posteriormente, si no hay paquetes con él como destinatario, pasará a estado inactivo y se activará de nuevo de acuerdo a un horario que habrá establecido previamente el coordinador. 2.2.4.2. Modelo de transferencia de datos Existen tres tipos de transacciones de datos: entre dos dispositivos iguales, de un coordinador a un dispositivo de otro tipo y viceversa. El mecanismo de transferencia varía dependiendo de si la red soporta o no funcionamiento en modo balizado. Cuando un dispositivo desea transmitir al coordinador datos en modo no balizado, simplemente transmite su trama, usando CSMA-CA no ranurado. Cuando la transmisión hacia el coordinador se realiza mediante modo balizado, primero espera a detectar la baliza y, cuando lo hace, se sincroniza con la estructura de supertrama y transmite su trama de datos en el momento adecuado, usando CSMA-CA ranurado. Puede activarse de manera opcional el acuse de recibo tanto en modo balizado como en modo no balizado. Si es el coordinador el que desea transferir datos a un dispositivo dentro de una red con funcionamiento balizado activado, indica en la baliza que tiene un mensaje esperando a ser enviado. El dispositivo escuchará periodicamente la baliza y, si hay un mensaje con él como destinatario, lo solicitará mediante el envío de un comando MAC haciendo uso de CSMA-CA ranurado. El mensaje será enviado entonces usando tambien CSMA-CA ranurado y, una vez que lo reciba, el dispostivo enviará un acuse de recibo y el mensaje será eliminado de la lista de mensajes pendientes en la baliza. Por otro lado, cuando el mensaje a transmitir por el coordinador se hace en una red sin funcionamiento balizado activado, el coordinador almacena el mensaje hasta que el dispositivo entre en contacto con él y solicite el mensaje, mediante la trasmisión de un comando MAC hacia el coordinador. Este comando MAC de sondeo será enviado usando CSMA-CA no ranurado y especicando una tasa de datos requerida. Si no 4 El envío se produce en modo broadcast de forma periódica. Este periodo puede variar, dependiendo de la conguración, entre 0.015 y 252 segundos 30 CAPÍTULO 2. ZIGBEE/802.15.4 hay datos pendientes de ser enviados en el coordinador, el coordinador transmitirá una trama de datos con una zona de carga de longitud cero y el dispositivo conrmará el recibo de esta trama. En el caso de la transmisión de datos entre dispositivos del mismo tipo, se presentan dos opciones. En el primer caso, el sensor escuchará de manera constante y transmitirá sus datos usando CSMA-CA no ranurado. En el segundo caso, los sensores se sincronizan para poder ahorrar energía. 2.2.4.3. Inicialización y mantenimiento de una PAN Una PAN solo puede ser iniciada por dispositivos FFD y una vez que ha llevado a cabo un escaneo de canal activo y que se ha seleccionado un identicador PAN adecuado. El escaneo activo de canal permite al dispositivo FFD localizar coordinadores que estén transmitiendo tramas baliza dentro de su espacio de operación personal. El escaneo activo de canal se lleva a cabo sobre un conjunto de canales lógicos. Para cada canal, el dispositivo debe conmutar la trasmisión a dicho canal y y enviar un comando de solicitud de baliza. Después de esto, el dispositivo activa su receptor durante un tiempo congurable y almacena la información de todas las balizas PAN distintas que se han recibido (rechazando en este periodo de tiempo aquellas tramas que no correspondan a balizas). Si el comando de solicitud de baliza es recibido por un dispositivo coordinador de una red con funcionamiento balizado activado, debe ignorar dicho comando y continuar transmitiendo sus balizas normalmente ya que asume que sus balizas periódicas le acabarán llegando. Si el comando de solicitud de baliza es recibido por un dispositivo coordinador de una red no balizada, trasmitirá una única trama de baliza usando CSMA-CA no ranurado. El escaneo activo de un determinado canal acabará una vez expirado el tiempo especicado o cuando se hayan almacenado el número máximo de identicadores PAN indicados en la implementación. El escaneo completo nalizará cuando todos los canales del conjunto de canales lógicos disponibles hayan sido escaneados (o cuando se hayan almacenado 2.2. IEEE 802.15.4 31 el número máximo de identicadores PAN indicados en la implementación si esto ocurre antes). La elección del identicador de PAN se hará teniendo en cuenta el resultado de las PAN detectadas durante el escaneo y será responsabilidad exclusiva de la aplicación. En conjunto con lo visto hasta ahora, para la selección del identicador también se tendrá en cuenta el resultado de ED en la capa física, pudiéndo ser descartadas ciertas tramas por parte de la capa MAC. Además de todo lo anterior, cabe destacar que ZigBee dispone de una serie de procedimientos para solucionar conictos relacionados con la duplicidad de identicadores PAN dentro de su espacio de operación personal. 2.2.4.4. Unión a una red ZigBee Hay dos procedimientos para unirse a una red ZigBee: asociación MAC y reasociación de red (que se describirá más adelante). La asociación MAC es el procedimiento que todo dispositivo ZigBee debe soportar. En este caso, un coordinador o un ennrutador que desee permitir a otro dispositivo asociarse a la red deberá indicarlo mediante la trasmisión del comando correspondiente. Posteriormente, el dispositivo que desee unirse a la red deberá indicarlo mediante otro comando. Esta última petición causará el inicio de un protocolo de la capa MAC en el que se intercambiarán mensajes entre el dispositivo que desea unirse a la red y el coordinador o el enrutador, indicándose entre otros detalles la dirección asignada al dispositivo dentro de la red. Debe destacarse que la asociación MAC es un protocolo inseguro ya que todas las tramas que se intercambian son enviadas sin tomar medidas de seguridad. 2.2.4.5. Sincronización En aquellas redes con funcionamietnto balizado, la sincronización se consigue a través de la recepción y decodicación de las tramas baliza. En redes sin funcionamiento balizado, la sincronización es llevada a cabo mediante el sondeo del coordinador solicitando transmitir datos. 32 CAPÍTULO 2. ZIGBEE/802.15.4 Existen también procedimientos para la recuperación de dispositivos que han perdido la comunicación con la red, denominados dispositivos huérfanos. 2.2.4.6. Formato de la trama MAC El formato general de la trama MAC varía según el tipo de trama que se envíe, las diferentes opciones se muestra en la gura 2.3 e incluyen los siguientes componentes básicos: MHR: comprende control de trama, número de secuencia e información de direccionamiento. Zona de carga MAC: de longitud variable, contiene información especíca del tipo de trama. Las tramas ACK no contienen zona de carga. MFR: contiene FCS (Frame 2.2.4.7. Check Sequence ). Características que reducen el consumo energético en la capa MAC Se presentan a continuación las características que posibilitan el bajo consumo energético en la capa MAC: Supertrama MAC: permite el funcionamiento en modo balizado que a su vez deriva en un menor tiempo de actividad (duty cycle ) de los dispositivos. CSMA-CA: su uso en lugar del sondeo disminuye signicativamente el consumo. Efecto de recuperación de las baterías: todos los tipos de baterías presentan un efecto de recuperación por el cual su duración se extiende si la corriente es extraída de ellas en ráfagas en lugar de hacerse con el equivalente en corriente constante. 2.3. ZIGBEE ALLIANCE 2.3. 33 ZigBee Alliance A continuación se describirá de forma detallada la parte de ZigBee responsabilidad de ZigBee Alliance, sin embargo, se deben tener claras una serie de ideas: ZigBee Alliance es: • Una asociación de empresas que buscan promover IEEE 802.15.4. • Una asociación de empresas que llevan a cabo la comercialización y certicación de ZigBee. • Una asociación de empresas que se ocupan de la denición de las capas supe- riores de ZigBee. 2.3.1. Capa de Red ZigBee La capa de red ZigBee se ocupa del enrutamiento mediante la invocación de acciones en la capa MAC. Sus tareas incluyen iniciar la red5 , asignar direcciones de red, añadir o eliminar dispositivos en la red, enrutar mensajes, aplicar medidas de seguridad e implementar el descubrimiento de rutas. 2.3.1.1. Reincorporación a la red El procedimiento de reincorporación a la red puede ser, a pesar de su nombre, usado para unirse a la red por primera vez. Se trata de un protocolo de la capa de red, lo que quiere decir, por un lado, que no es responsabilidad obligada de la capa MAC permitir la unión de dispositivos a la red y que, si se hace a nivel de red, la unión de un dispositivo a la red puede hacerse de forma segura. Esto último es cierto si el dispositivo está reincorporándose a a red o si el dispositivo esta uniéndose por primera vez pero ha obtenido la clave de red por medio de algún mecanismo externo. 5 Si se trata de un dispositivo actuando como coordinador 34 2.3.1.2. CAPÍTULO 2. ZIGBEE/802.15.4 Enrutamiento ZigBee El algoritmo de enrutamiento ZigBee está basado en el concepto de enrutamiento por vector distancia, en el cual cada enrutador que participa en la transmisión de tramas desde una fuente a un destino mantiene un registro en su tabla de enrutamiento asociada a esta comunicación. Este registro, como mínimo, debe almacenar tanto la distancia lógica hasta el destino como la dirección del siguiente enrutador en el camino hacia dicho destino. Las rutas son determinadas según van siendo solicitadas usando un proceso de descubrimiento de rutas en el que el dispositivo que desea trasmitir envía un comando de solicitud de ruta a todos los dispositivos a su alcance, posteriormente, cuando dicho mensaje llegue al destinatario, tras sucesivas retransmisiones por parte de los enrutadores intermedios, éste contestará enviando un comando con el dispositivo origen de la petición ahora como destino. Conforme dicha contestación vaya pasando a través de los distintos enrutadores que actuarán como intermediadores en la trasmisión, se irá creando en cada uno de ellos el registro dentro de la tabla de enrutamiento indicado anteriormente. Este procedimiento se muestra en la gura 2.10. Existen un gran número de optimizaciones al algoritmo básico descrito que sirven para reducir la memoria RAM dedicada a las tablas de enrutamiento. Figura 2.10: Descubrimiento de ruta [20] Una de estas alternativas para reducir las necesidades de memoria es usar el mecanismo de distribución de direcciones, en el que las direcciones son asignadas siguiendo una cierta jerarquía, comenzando por el coordinador. Así, los dispositivos con poca o ninguna capacidad de enrutamiento, o dispositivos cuya capacidad haya sido agotada, tienen la opción de usar el encaminamiento jerárquico para proporcionar un enrutamiento posiblemente menos eciente pero más sencillo (ya que el paquete es siempre enrutado hacia un padre 2.3. ZIGBEE ALLIANCE 35 o un hijo, según el rango de la dirección de destino). Este procedimiento se muestra en la gura 2.11. Figura 2.11: Encaminamiento jeráquico [20] Por otro lado, en la mayoría de las aplicaciones empotradas para redes inalámbricas suele existir un dispositivo denominado sumidero, al que todos los demás dispositivos pertenecientes a la red deben enviar datos de forma regular. Para evitar que cada dispositivo de la red deba descubrir al sumidero de forma individual, se establece un caso especial de descubrimiento de ruta en el que una única petición en modo broadcast realizada por el sumidero establece un registro con él como destino en las tablas de encaminamiento de cada enrutador de la red. En grandes redes, los problemas pueden darse cuando el sumidero necesita alcanzar a cada dispositvo de la red de forma separada. El caso de una red en la que el sumidero tiene pocos vecinos pero mediante los cuales pueden alcanzarse muchos dispositvos ejemplica este problema. Las tablas de enrutamiento de estos pocos vecinos se verán sobrecargadas simplemente por su proximidad al sumidero. La especicación ZigBee PRO introduce otro estilo de enrutamiento, conocido como enrutamiento fuente, que solventa este problema. Mientras que en el enrutamiento basado en el algoritmo de vector distancia la información de enrutamiento es almacenada en las tablas de los dispositivos que participan en la retransmisión de una trama, el enrutamiento fuente añade la información de enrutado en la propia trama que se transmite. Ahora solo el origen de la trama necesita almacenar la información para la ruta, pero a costa de que 36 CAPÍTULO 2. ZIGBEE/802.15.4 el registro sea mayor ya que debe almacenar la ruta completa y no solo el siguiente salto. 2.3.1.3. Características que reducen el consumo energético en la capa de red Se presentan a continuación las características que posibilitan el bajo consumo energético en la Capa de Red: El algoritmo de enrutamiento usado en ZigBee 1.0 emplea como parámetros tanto la calidad del enlace como el número de saltos, de esta manera disminuye el consumo de energía al minimizar las retransmisiones de mensajes y evitar la repetición de las rutinas para el descubrimiento de rutas. Las implementaciones futuras de ZigBee probablemente incluirán dentro de su función de costes para la eleccion de la ruta adecuada parámetros relacionados con el consumo energético, tales como energía restante del sensor o fuente de energía usada por el sensor. 2.3.2. Capa de Aplicación ZigBee La capa superior de la pila de protocolos ZigBee esta compuesta por los siguientes elementos: Marco de aplicación: proporciona una descripción acerca de cómo denir un perl en la pila ZigBee. También especica un conjunto de tipos de datos para perles, descriptores para la asistencia en el servicio de descubrimiento, formatos de trama para el transporte de datos y un constructor para desarrollar perles básicos. Dentro del marco de aplicación quedan denidos los objetos de aplicación, que es un software que actua como endpoint y que sirve para el control del dispositivo ZigBee. Un dispositivo ZigBee soporta hasta 240 objetos de aplicación, estando el 0 reservado para ZDO. 2.3. ZIGBEE ALLIANCE 37 ZDO: dene el papel a desempeñar por un dispositivo dentro de la red (coordinador, enrutador o dispositivo nal), inicia y/o responde a peticiones de conexión y de descubrimiento, y establece una relación segura entre los dispositivos de la red. También provee un amplio conjunto de comandos para la administración de la red y el dispositivo. ZDO es siempre el endpoint 0. En colaboración con ZDO se encuentra el Plano de Administración ZDO, cuya labor es facilitar la comunicación entre el APS y la capa de red con ZDO. Permite al ZDO negociar peticiones relacionadas con el acceso a la red o la seguridad. APS: responsable de proveer el servicio de datos a la aplicación. Se ocupa también de almacenar la tabla de conexiones. SSP (Secure Services Provider ): actúa entre APS y la capa de red para proveer los mecanismos necesarios para el uso de encriptación a ambas. Queda congurado a través de ZDO. 2.3.2.1. Perles de aplicación, grupos y endpoints Un perl de aplicación describe una colección de dispositivos empleados para una aplicación especíca e, implicitamente, el esquema de intercambio de mensajes entre estos dispositivos. Un identicador de perl es asignado para cada aplicación de manera que quede identicado de forma unívoca. Existen dos tipos de perles de aplicación: Perl de aplicación público: aplicación desarrollada por ZigBee Alliance que realiza una tarea determinada y puede ser usada en cualquier dispositivo ZigBee. Perl de aplicación especíco de un fabricante: aplicación privada desarrollada por una compañía para funcionar en un derteminado dispositivo ZigBee. Los dispostivos con un perl de aplicación común se comunican entre ellos usando el concepto de grupos, en el que se describen las posibles entradas o salidas de datos que se 38 CAPÍTULO 2. ZIGBEE/802.15.4 pueden registrar desde o hasta otros dispositivos. Un identicador de grupo diferencia de forma unívoca los grupos dentro del rango de un perl determinado. Un endpoint dene una entidad dentro de un dispositivo a través de la que se realiza la comunicación con una aplicación especíca, como ya se indicó, pueden existir hasta 240 endpoint s, estando el 0 reservado para ZDO, que proporciona comandos de control y administración. 2.4. Seguridad en ZigBee La seguridad en ZigBee esta basada en el algoritmo 128-bit AES (Advanced Encryption Standard ) y se añade al modelo de seguridad que provee IEEE 802.15.4. Incluye métodos para el establecimiento y el transporte de manera cifrada, administración de dispositivos y protección de la trama. La especicación de ZigBee dene la seguridad para las capas MAC, de red y de aplicación. La seguridad para las aplicaciones es proporcionada típicamente a través de los perles de aplicación. Veamos los elementos más importantes en lo referente a la seguridad: Centro de Conanza: decide si se permiten o no nuevos dispositivos en la red y puede actualizar y cambiar de forma periódica la clave de red. Para ello, transmite la nueva clave encriptada con la anterior. Posteriormente comunicará a los dispositivos que pasen a utilizar la nueva clave. El Centro de Conanza es normalmente el coordinador, pero tambien puede ser un dispositivo dedicado a esta labor. Es responsable de las siguientes tareas de seguridad: • Autenticación de dispositivos que soliciten unirse a la red. • Mantenimiento y distribución de las claves de red. • Habilitar seguridad end-to-end entre dispositivos. Claves de seguridad: ZigBee usa tres tipos de claves, la Clave Maestra, la Clave de Red y la Clave de Enlace. 2.4. SEGURIDAD EN ZIGBEE 39 • Clave Maestra: esta clave no es usada para la encriptación de tramas sino como un secreto inicial compartido entre dos dispositivos cuando se lleva a cabo el Procedimiento de Establecimiento de Clave para determinar la clave de enlace. Las claves que se originan en el Centro de Conanza se denominan Claves Maestras del Centro de Conanza mientras que las demás se denominan Claves Maestras de la Capa de Aplicación. • Clave de Red: proporciona la seguridad para la Capa de Red. Todos los dispo- sitivos en la red ZigBee comparten la misma clave. Las claves de red de alta seguridad siempre deben ser transmitidas encriptadas mientras que las claves de red de seguridad estándar pueden ser enviadas con o sin encriptación. La opción de alta seguridad es solo soportada por ZigBee PRO. • Clave de Enlace: se trata de una clave opcional, usada para el envio unicast de mensajes entre dos sipositivos a nivel de la capa de aplicación. Las claves de red proporcionadas por el Centro de Conanza son denominadas Claves de Enlace del Centro de Conanza, las demás son denominadas Claves de Enlace de la Capa de Aplicación. 40 CAPÍTULO 2. ZIGBEE/802.15.4 Capítulo 3 Componentes y tecnologías utilizadas En este capítulo se hará una descripción de las herramientas tanto software como hardware que han sido necesarias para la realización y prueba de este Proyecto Fin de Carrera. 3.1. 3.1.1. Elementos hardware Equipo de desarrollo eZ430-RF2480 de Texas Instruments El equipo de desarrollo eZ430-RF2480 de Texas Instruments proporciona la red de sensores ZigBee/802.15.4 que permiten vericar el correcto funcionamiento de la pasarela a desarrollar en este proyecto. A continuación se hará una descripción de sus elementos centrándonos principalmente en la pastilla contenedora de la pila de protocolos ZigBee/802.15.4 pero sin entrar en grandes detalles ya que no es el objetivo de este proyecto su estudio. Para conocer más acerca de su funcionamiento se recomienda consultar la guía para desarrolladores del CC24801 . 1 Disponible en http://focus.ti.com/lit/an/swra176/swra176.pdf 41 42 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS El equipo de desarrollo que nos ocupa está compuesto de tres motas/sensores ZigBee, un conector USB (Universal Serial Bus ) y dos suministradores de energía mediante baterías. Todos ellos pueden verse en la gura 3.1. Figura 3.1: Contenido eZ430-RF2480 El conector USB permite la comunicación de las motas con un ordenador, de esta manera se pueden recibir datos procedentes de la red y programar las motas haciendo uso del software IAR Embedded Workbench2 . Por otro lado, el conector también proporciona la energía necesaría para el correcto funcionamiento de la mota conectada al conversor. En cuanto a los suministradores de energía mediante baterías, se ha de destacar que permiten mantener en funcionamiento a las motas conectadas a ellos sin necesidad de depender de la red eléctrica, funcionando con baterías de tipo AAA. 2 Descrito en el apartado 3.2.1.3 3.1. ELEMENTOS HARDWARE 43 Descripción de las motas Las motas ZigBee contenidas en el equipo de desarrollo eZ430-RF2480 presentan una arquitectura basada en un procesador que se ocupa de las capas física, MAC y de red y un microcontrolador que se encarga únicamente de la capa de aplicación. En concreto, el procesador es un CC2480 y el microcontrolador es un MSP430F2274, comunicándose ambos mediante interfaz SPI (Serial Peripheral Interface ) o UART (Universal Asynchronous Receiver-Transmitter ) según puede verse en la gura 3.2. La antena se encuentra integrada en el mismo CC2480. Figura 3.2: Conexión CC2480-MSP430 La solución incluida en estas motas por Texas Instruments de cara a la implementación de la pila de protocolos es denominada Z-Accel. Dicha solución consiste en la ejecución de la versión de la pila de protocolos ZigBee desarrollada por Texas Instruments, denominada Z-Stack, en el procesador CC2480 y la ejecución de la aplicación en el microcontrolador MSP430F2274. El CC2480 se ocupa de manejar todas las tareas críticas en tiempo así como todo aquello relacionado con el protocolo ZigBee/802.15.4 mientras que el microcontrolador está liberado para ocuparse tan solo de la ejecución de la aplicación almacenada. Esta distribución de capas, y por lo tanto de tareas, entre el procesador y el microcontrolador queda representada en la gura 3.3. Todo lo anteriormente descrito funciona cumpliendo el estándar ZigBee-2006. Se debe reseñar que el procesador CC2480 trabaja sólo en modo no balizado. 44 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Figura 3.3: Distribución de protocolos CC2480-MSP430 [26] Trama intercambiada entre procesador y microcontrolador Un punto importante a la hora de llevar a cabo este proyecto es determinar cúal es el formato de trama intercambiado entre el microcontrolador MSP430F2274 y el procesador CC2480 ya que será esta trama la que se tome y posteriormente envíe a través de la red IP. Dicho formato se muestra en la gura 3.4. Figura 3.4: Formato de trama intercambiada entre CC2480 y MSP430 El primer campo que nos encontramos en el formato descrito es el byte SOF (Start Of Frame ) que avisa del comienzo de la trama. El siguiente campo indica la longitud en bytes del campo de datos. A continuación se encuentran los bytes de datos. Como último campo encontramos el FCS, que es una función XOR de todos los campos anteriormente 3.1. ELEMENTOS HARDWARE 45 descritos exceptuando el SOF. El byte de comando presenta el formato que se muestra en la gura 3.5. Figura 3.5: Campo de Comando Los comandos que se intercambian el microcontrolador y el procesador pueden ser de los siguientes tipos: Petición Asíncrona: enviada desde el microcontrolador al procesador. No se espera respuesta. Petición Síncrona: enviada desde el microcontrolador al procesador. Se espera respuesta. Respuesta Síncrona: respuesta por parte de procesador a la petición síncrona hecha por el microcontrolador. Sondeo: al estar toda comunicación iniciada por el microcontrolador, el sondeo sirve para preguntar al procesador si tiene alguna petición que realizarle al microcontrolador. Por otra parte, como ya se mostró anteriormente, la capa de aplicación se compone de distintas subcapas, indicándose esto mediante el campo subsistema. Finalmente, los 8 bits nales del campo comando identican a cada uno de los comandos disponibles. 46 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Interfaz de aplicación En cuanto a la interfaz con la capa de aplicación, aparte de la interfaz API propia de la solución Z-Stack, y las interfaces de sistema y con ZDO, el procesador CC2480 aporta la interfaz Simple API o SAPI. La interfaz SAPI ofrece únicamente diez llamadas a funciones API, esto facilita enormemente el desarrollo de aplicaciones ZigBee. Esta versión simplicada está pensada para aquellos dispositivos el los que la pila de protocolos está cargada en el procesador y, por lo tanto, no se permite un nivel de conguración tan alto como el que API Z-Stack proporciona por lo que no son necesarias gran parte de las llamadas que contiene. SAPI contiene lo necesario para formar una red ZigBee, vincular dispositivos y enviar/recibir datos. Para conocer con mayor profundidad estos aspectos se recomienda la consulta del documento 'CC2480 Interface Specication'3 . Microprocesador MSP 430 Como se ha descrito a lo largo de esta sección, el procesador CC2480 se combina con un microcontrolador MSP430F2274 que gestiona la parte de aplicación. Este microcontrolador tiene como principal característica el bajo consumo energético, lo cual lo hace ideal para lograr uno de los principales propósitos de ZigBee, la duración de las baterías. Esto se logra gracias a su arquitectura y a cinco modos de funcionamiento optimizados para lograr un bajo consumo energético. Presenta una unidad de proceso RISC (Reduced Instruction Set Computer ) de 16 bits con 16 registros, una memoria ash de 32 Kbytes y una memoria RAM de 1 Kbyte. 3.1.2. Conversor TTL-232R-3V3 de FTDI Los conectores TTL-232R de FTDI son una familia de conversores de UART-TTL a USB que permiten la gestión de toda la señalización y protocolos asociados al estándar USB. Cada uno de estos conversores contiene un pequeño circuito impreso interno encapsulado en el propio conector USB incluido al nal del cable. El modelo concreto usado en 3 Disponible en http://focus.ti.com/lit/er/swra175a/swra175a.pdf 3.1. ELEMENTOS HARDWARE 47 este proyecto es el TTL-232R-3V3 y puede verse en la gura 3.6. Figura 3.6: FTDI TTL-232R-3V3 [18] La parte USB del conversor presenta funcionalidad USB de tipo 2.0. El cable mide 1.8m de longitud y permite hasta 3 Mbaud de tasa de transferencia de datos. Además, cada cable incorpora la identicación única desarrollada por FTDI y denominada FTDIChip-ID que permite proporcionar seguridad a la hora del acceso para la transferencia de archivos a través del conversor. El conversor TTL-232R requiere una serie de controladores que le permiten aparecer en el sistema operativo correspondiente como un puerto virtual, permitiendo de esta manera la comunicación con este dispositivo mediante los puertos de emulación serie disponibles en el sistema operativo (como por ejemplo TTY en el caso de Linux). Para el desarrollo de este proyecto, la existencia de controladores para este conversor destinados a sistemas operativos basados en el kernel 2.4 de Linux fue esencial para su elección frente a otras alternativas, como podría haber sido el conversor proporcionado en el equipo de desarrollo eZ430-RF2480 de Texas Instruments. 48 3.1.3. CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Router ASUS WL-500G Premium La programación de nuestra pasarela Zigbee/802.15.4-IP se llevará a cabo sobre un router ASUS WL-500G Premium. Esta elección se debe a la facilidad para poder instalar en él un sistema operativo basado en Linux y al hecho de disponer de conexiones USB a través de las cuales llegará la información procedente de nuestra red de sensores ZigBee. Se muestra una breve descripción de sus principales características en la tabla 3.1. Parámetro Estándar Inalámbrico Cifrado Antena Modulación Frecuencia de operación Tasa de transferencia de datos nominal Potencia de salida Sensibilidad Canales WAN LAN Otras conexiones Descripción IEEE 802.11 b/g WEP, WAP, WPA2 Antena IF interna y antena externa de dipolo OFDM, CCK, DQPSK, DBPSK 2.4 - 2.5 GHz 802.11g: 6, 9, 12, 18, 24, 36, 48, 54 Mbps; 802.11b: 1, 2, 5.5, 11Mbps 802.11g: 14~16dBm; 802.11b: 16~18dBm -74~-75dBm a 54Mbps; -87~-88dBm a 11Mbps; -95~-97dBm a 1Mbps 13 para Europa (ETSI), 11 para Norte America y 14 para Japón 1 puerto RJ-45 (10/100 BaseT) Fast Ethernet (10/100 Mb/s) 4 puertos RJ-45 (10/100 BaseT) Fast Ethernet (10/100 Mb/s) 2 puertos USB2.0 Tabla 3.1: Características Asus WL-500G Premium [2] El enrutador presenta una serie de indicadores de tipo LED en el frontal que indican su estado según actuen de una u otra manera. En la gura 3.7 podemos apreciar dichos indicadores. Como ya se indicó, una de las grandes ventajas del enrutador elegido es la gran capacidad de conectividad que presenta gracias a sus dos puertos USB 2.0. Además de esto, presenta 4 puertos para conexiones LAN y otro puerto para conexión WAN, sin olvidar 3.1. ELEMENTOS HARDWARE 49 Figura 3.7: Asus WL 500G Frontal las conexiones para la antena (a la derecha) y la alimentación (a la izquierda) tal y como puede apreciarse en la gura 3.8. Debe destacarse el interruptor restore, imprescindible para la instalación del sistema operativo deseado como veremos más adelante. Figura 3.8: Asus WL 500G Trasera En lo referente a la arquitectura interna, el enrutador está compuesto de dos placas, la principal y un módulo Wi-Fi. Esta última es una pequeña placa conectada a la principal a través de una ranura miniPCI. Esta estructura puede apreciarse en la gura 3.9. En la placa principal destacan dos chips, uno fabricado por Broadcom y denominado BCM4318E y otro denominado SiGe 2521A60. El chip BCM4318E es un controlador inalámbrico altamente integrado que, entre otras tareas, es capaz de dar soporte a la tecnología propietaria de Broadcom denominada AfterBurner que permite un incremento de 50 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Figura 3.9: ASUS WL-500G Premium Interior la tasa de transferencia de datos para 802.11g de hasta un 35 % mediante la compresión de tramas. Por su parte, el chip SiGe 2521A60 es un módulo de radiofrecuencia para la gestion de los estándares 802.11b y 802.11g. Los principales componentes del enrutador, procesador y memoria, se encuentran en la placa impresa principal bajo la carcasa metálica. El ASUS WL 500g Premium está equipado con un procesador BCM4704 fabricado por Broadcom. Se trata de un procesador MIPS4 (Microprocessor without Interlocked Pipeline Stages ) de 32 bits que puede funcionar a una frecuencia de 300 MHz a pesar de que en este enrutador la frecuencia quede limitada a 264 MHz. El sistema operativo se almacena en una memoria ash de 8Mbytes fabricada por Spansion. Además, cuenta con 32 Mbytes de memoria RAM5 para la ejecución de software. Otros dos controladores a los que se debe hacer mención son el chip VT6212L fabricado por VIA y el chip BCM5325E fabricado por Broadcom. El primero es un controlador para 4 Familia de microprocesadores de arquitectura RISC desarrollados por MIPS Technologies. 5 Concretamente DDR SDRAM 3.2. ELEMENTOS SOFTWARE 51 los puertos USB 2.0 y el segundo es un conmutador Fast Ethernet con un buer para tramas de 128 Mbytes y la capacidad de detectar el tipo de cable conectado al puerto (ordinario o cruzado). Para la resolución de problemas, se puede conectar al enrutador ASUS WL-500G Premium a través de un bus de tipo UART. El conector correspondiente se encuentra localizado en el borde derecho de la placa principal. 3.2. 3.2.1. 3.2.1.1. Elementos software Herramientas DD-WRT El software DD-WRT es un rmware libre con licencia GPL (General Public License) versión 2. Está destinado a una gran variedad de enrutadores inalámbricos IEEE 802.11a/b/g/h/n con arquitectura basada en chips Atheros o Broadcom. Las versiones hasta la número 22 estaban basadas en el rmware Alchemy de Sveasoft, que a su vez estaba basado en el rmware original de Linksys con licencia GPL. Desde la versión 23 en adelante está basado en OpenWrt, que empezó siendo un rmware basado en el de Linksys pero más tarde cambió a su propio entorno. La idea inicial de crear DD-WRT surgió debido a la decisión de Sveasoft de comenzar a cobrar por su producto, cerrando de esta manera la puerta al código abierto. Actualmente DD-WRT puede conseguirse de manera gratuita en su web pero existen una serie de versiones solo accesibles previo pago. Para determinar qué versión es adecuada instalar en nuestro enrutador, basta con acceder a la página ocial del rmware DD-WRT6 , una vez ahí acudir a la sección Support y entrar a Router Database. Especicando nuestro modelo de router en el espacio correspondiente se mostrarán las versiones recomendadas para ser instaladas en nuestro dispositivo, 6 http://www.dd-wrt.com 52 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS en este caso la elección es la versión 24 (build 12188). Es importante asegurarse de que la versión es la adecuada ya que existen versiones con núcleo 2.6 y otras con núcleo 2.4 de Linux, la instalación en el dispositivo inadecuado de cualquiera de ellas puede dar como resultado la inutilización permanente del enrutador. Además de existir distintas versiones disponibles, también es posible elegir entre varias tipos de rmware dentro de cada versión, diferenciandose entre ellos por las utilidades que incluyen instaladas por defecto. Esto último es importante ya que de esta elección dependerán los requisitos, principalmente de memoria, de los que necesitaremos disponer en nuestro enrutador. En la tabla 3.2 se describen algunas características que pueden ser incluidas en DDWRT: 3.2. 53 ELEMENTOS SOFTWARE Utilidad Asterisk Monitorización del ancho de banda Chillispot Afterburner IPv6 JFFS2 Soporte de expansión de memoria MMC/SD Samba Wake On LAN RFlow Collector Descripción Aplicación que emula una PBX mediante software. Permite el manejo de telefonía sobre IP sin necesidad de añadir hardware adicional, facilitando la interoperabilidad con la mayoría de dispositivos estándares de telefonía. Monitorización de ancho de banda consumido por cada usuario, media temporal... Aplicación para la autenticación de usuarios. Permite el ingreso via web que es el estándar actual para HotSpots públicos. Incrementa el throughput WiFi a través de procesos software. Versión de IP denida en el RFC 2460 y diseñada para reemplazar a la versión 4 denida en el RFC 79 Área dentro de un dispositivo equipado con DD-WRT para la re-escritura habitual de datos. Permite añadir memoria externa al enrutador para el almacenamieto de datos y/o aplicaciones. Implementación libre del protocolo de archivos compartidos de Microsoft Windows (antiguamente llamado SMB, renombrado recientemente a CIFS) para sistemas de tipo UNIX. Permite encender remotamente ordenadores en estado de hibernación o apagados. Permite el envío y almacenamiento de información relacionada con el tráco de la red para su posterior estudio. Tabla 3.2: DD-WRT: Utilidades principales [1] 54 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS La elección de DD-WRT para la realización de este Proyecto Fin de Carrera se basó en la existencia de controladores para el conversor TTL-232R-3V3 de FTDI, la facilidad de conguración a través de su interfaz web, cuya pantalla principal puede verse en la gura 3.10, y la posibilidad de incluir el desarrollo software realizado para el funcionamiento de la pasarela dentro de la estructura del rmware a instalar en el router. Figura 3.10: DD-WRT: Interfaz Web El lenguage de programación bajo el que está desarrollado el núcleo de DD-WRT es C++, existiendo además compiladores cruzados para la creación de aplicaciones dirigidas a routers con arquitectura MIPS tal y como es el caso del ASUS WL-500G Premium. En sucesivos capítulos se describirá de una manera detallada el proceso de compilación, instalación y conguración del rmware para lograr la completa adaptación de éste a los requerimientos deseados. 3.2. ELEMENTOS SOFTWARE 3.2.1.2. 55 Entorno de desarrollo Eclipse Eclipse es una comunidad cuyos objetivos están centrados en la realización de una plataforma de código abierto para el desarrollo de aplicaciones. Se puede mantener el mismo entorno de desarrollo pero variar el lenguage de programación usado para la aplicación a desarrollar sin más que añadir distintos módulos. La Fundación Eclipse7 es una asociación sin ánimo de lucro que busca tanto el mantenimiento del entorno de desarrollo Eclipse como el crecimiento de una serie de productos y servicios complementarios a éste a la vez que promueve la comunidad de código abierto surgida entorno a este proyecto. El Proyecto Eclipse fue creado por IBM en Noviembre de 2001 y apoyado por una agrupación de desarrolladores de software. La Fundación Eclipse fue creada en Enero de 2004 como medio que permitiese a cualquier empresa neutral y abierta establecerse en alrededor de todo lo relacionado con Eclipse. Puede apreciarse la estructura de la pantalla principal de Eclipse en la gura 3.11. Figura 3.11: Eclipse: Pantalla Principal Existe la extendida idea de que Eclipse es simplemente una extensión dedicada al 7 http://www.eclipse.org/org/foundation/ 56 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS desarrollo de software Java, pero nada más lejos de la realidad ya que Eclipse permite la adición de módulos para el desarrollo de aplicaciones en lenguages de programación tan diversos como pueden ser C/C++, PHP, Perl, Ruby y JavaScript. Cada una de estos módulos se denominan Kits de Desarrollo Software (SDK) y permiten desde la corrección de la sintaxis utilizada, hasta la depuración y compilación del código, pasando por la información acerca de las API que pueden utilizarse y como deben ser utilizadas. Otra interesante característica de Eclipse es su capacidad para ocultar bloques de código que hacen más fácil la comprensión y manejo del mismo cuando éste crece. En cuanto a su rendimiento, Eclipse se muestra muy estable, presentando como único inconveniente su consumo de memoría, que lo hace especialmente lento en aquellas máquinas con pocos recursos de memoria RAM. En el caso de este Proyecto Fin de Carrera se hace uso de Eclipse en combinación con el SDK de C++, todo ello ejecutado bajo un sistema operativo Ubuntu 10.04. 3.2.1.3. MSP430 IAR Embedded Workbench La aplicación MSP430 IAR Embedded Workbench es un entorno de desarrollo de C/C++ que integra las funciones necesarias para la realización de aplicaciones empotradas destinadas a la familia de microcontroladores MSP430. Se muestran a continuación los elementos más destacados de los que está compuesto: Editor de textos Permite la edición de varios archivos en paralelo, además de todas las características básicas exigidas en un editor de textos moderno, como la posibilidad de hacer/rehacer de forma ilimitada acciones. Provee también características destinadas a facilitar el desarrollo de software como puede ser el resaltado de palabras clave del lenguage C/C++. 3.2. ELEMENTOS SOFTWARE 57 Compilador IAR C/C++ Incluye las características básicas de un compilador C/C++ además de extensiones que permiten aprovechar las facilidades que los microcontroladores de la familia MSP430 ofrecen. Depurador IAR C-SPY Se trata de un depurador de código de alto nivel destinado a aplicaciones empotradas. Está especialmente diseñado para su uso junto a ensambladores y compiladores de IAR System. Entre sus características incluye la posibilidad de editar el código fuente mientras se está depurando éste. El depurador está compuesto de dos módulos, uno que aporta un conjunto de acciones para la depuración y otro que actúa como un controlador, permitiendo la comunicación y control del dispositivo destino de la aplicación desarrollada. Simulador IAR C-SPY Este módulo permite simular las funciones del procesador destino mediante software. Así, mediante IAR C-SPY, la aplicación puede ser depurada antes de que sea portado al dispositivo destino, facilitando la tarea y ahorrando tiempo de forma considerable. Depurador C-SPY FET Se trata de una emulador a través de conexión JTAG (Joint Test Action Group ), incluida en todas las placas de desarrollo de Texas Instruments. Este módulo permite la descarga de la memoria ash y aprovecha las facilidades de la depuración sobre el chip. Podemos ver la estructura de MSP430 IAR Embedded Workbench en la gura 3.12: 58 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Figura 3.12: MSP430 IAR Embedded Workbench: Estructura [24] Para la ejecución de este Proyecto Fin de Carrera, MSP430 IAR Embedded Workbench fue utilizado para la modicación del software residente en las motas proporcionadas por el equipo de desarrollo eZ430-RF2480 de Texas Instruments, usándose la versión de prueba disponible en su web8 . 3.2.1.4. WinSCP WinSCP es una aplicación libre y descargable desde su web9 que se ejecuta bajo sistemas operativos Windows y permite conectarse a un servidor SSH (Secure Shell ) empleando el protocolo SFTP (SSH File Transfer Protocol ) o el servicio SCP (Secure Copy Protocol ). WinSCP permite efectuar las operaciones básicas con archivos, tales como descargas y subidas. Tambien es posible renombrar archivos y directorios, crear nuevos directorios, modicar las propiedades de archivos y carpetas, y crear enlaces simbólicos y accesos directos. WinSCP permite la elección entre dos tipos de interfaces, uno denominado 'commander' que consta de dos paneles (el izquierdo dedicado al directorio local y el derecho al 8 http://www.iar.com/website1/1.0.1.0/220/1/ 9 http://winscp.net/eng/docs/lang:es 3.2. ELEMENTOS SOFTWARE 59 directorio remoto) y otro denominado 'explorer' en el que solo se muestra un panel (con la información referida al directorio remoto). En la gura puede observarse el interfaz 'commander ' de WinSCP. Esta aplicación fue usada para la transferencia de archivos al router equipado con DD-WRT para facilitar y agilizar el proceso de prueba de los mismos. 3.2.1.5. Putty PuTTY es un cliente SSH, Telnet, rlogin, y TCP raw con licencia MIT. Disponible originalmente sólo para Windows, ahora también está disponible para varias plataformas Unix en su web10 . Su característica más importante de cara a su uso en este Proyecto Fin de Carrera es su soporte para conexiones de puerto serie local, que fue imprescindible para la comprobación del buen funcionamiento del conversor TTL-232R-3V3 de FTDI conectado a las motas ZigBee proporcionadas por el equipo de desarrollo eZ430-RF2480 de Texas Instruments, así como para la visualización del formato de trama enviado por éstas. La conguración adecuada para una correcta recepción de los datos es: 9600 baudios, 8 bits de datos, 1 bit de parada y ningún control de ujo ni de paridad. Los datos se reciben en formato ASCII (American Standard Code for Information Interchange ). Se puede ver la pantalla principal de putty en la gura 3.13. 10 http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html 60 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Figura 3.13: Putty: Pantalla Principal 3.2.1.6. XVI32 XVI32 es un editor hexadecimal freeware 11 . Su utilidad viene del hecho de que los valores recibidos mediante Putty se encuentran en formato ASCII y a través de esta utilidad podremos pasar del formato ASCII proporcionado a un formato hexadecimal al que se está más habituado y suele ser más cómodo leer. Para ello, los datos recibidos por Putty deben ser almacenados en un archivo de texto. Posteriormente bastará ejecutar la utilidad XVI32 y arrastrar sobre su ventana principal el archivo de texto con los datos en formato ASCII, mostrándose en pantalla el equivalente en hexadecimal. Se puede ver un ejemplo de conversión a hexadecimal hecho por XVI32 en la gura 3.14, en ella pueden apreciarse a la derecha los valores en formato ASCII y a la izquierda su equivalente en formato hexadecimal. 11 Puede obternerse en http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm 3.2. ELEMENTOS SOFTWARE 61 Figura 3.14: XVI32: Ejemplo de cambio de formato 3.2.2. Programación 3.2.2.1. C++ C++ fue una evolución de C, el cual surgió a partir de dos lenguajes de programación previos, BCPL y B. BCPL fue desarrollado en 1967 por Martin Richards como medio para escribir software de sistemas operativos y compiladores. Posteriormente, Ken Thompson creó muchas características de su lenguaje B según sus equivalentes en BCPL, valiéndose de B para crear las primeras versiones del sistema operativo UNIX. BCPL y B tenían también en común que eran lenguages sin tipos denidos. El lenguaje C fue una evolución de B llevada a cabo por Dennis Ritchie en los Laboratorios Bell. C se basa en muchos conceptos básicos de BCPL y de B, añadiendo como gran novedad los tipos de datos. C se hizo muy popular en sus comienzos por el ser el lenguaje de desarrollo del sistema operativo UNIX. 62 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS La gran difusión vivida por C tuvo también aspectos negativos, el más destacado fue que, al estar disponible para muchos tipos de ordenadores, surgieron demasiadas variantes, siendo parecidas entre ellas pero a menudo incompatibles. Surgia de esta manera un gran roblema para aquellos desarrolladores con necesidades de crear software portable a distintas plataformas. Como respuesta a este problema, en 1983 se creó el comité técnico X3J11 bajo el ANSI (American National Standards Institute ), con el objetivo de denir el lenguaje de manera independiente del equipo. Finalmente, en 1989 se aprobó el estándar y el ANSI trabajó junto a ISO (International Organization for Standardization ) en su estandarización a nivel mundial, publicándose el documento conjunto del estándar en 1990 bajo el nombre 'ANSI/ISO 9899: 1990'. Por otro lado, a principios de los 80, Bjarne Stroustrup creó C++, una extensión de C. C++ añade una serie de características que mejoran el lenguaje C, pero sobre todas ellas, la más importante fue la inclusión de la capacidad de programación orientada a objetos. El concepto de objeto surgía novedoso pero traería con él la puerta de acceso denitiva para la construcción de software de forma rápida y económica. Los objetos son componentes de software reutilizables capaces de simular elementos reales, permitiendo a los programadores una mayor facilidad a la hora de entender, corregir y modicar su software que con la anterior visión de programación estructurada. C++ era y es un lenguage híbrido ya que es posible programar tanto en estilo C como en estilo orientado a objetos o en ambos. En 1983 el nombre C++ fue propuesto y aceptado. La primera implementación comercial de C++, cfront 1.0, fue lanzada en 1985, se trataba de un traductor de C++ a C. C++ está denido y mantenido por el comité ISO, compuesto por delegados de asociaciones nacionales de estandarización como ANSI, DIN (Deutsches Institut für Normung ) y muchas otras. El primer estándar de C++ fue aprobado en 1998 bajo el nombre ISO/IEC 14882, habiendose publicado hasta hoy dos revisiones de éste. El estándar ISO de C++ dene el lenguaje del núcleo, las librerías incluídas de manera estándar y los requisitos de implementación. Se espera para próximas fechas el lanzamiento del nuevo estándar de C++, siendo el nombre no ocial de éste C++0x. La implantación del uso de C y C++ es mayoritaría entre la comunidad desarrolladora de software pero su inuencia es aún mayor al ser la base de otros lenguajes de programación ampliamente usados en la actualidad como es Java, de Sun Microsystems. En la 3.2. ELEMENTOS SOFTWARE 63 gura 3.15 se muestra la distribución de uso de los principales lenguaes de programación en los últimos díez años. Figura 3.15: Lenguages de Programación: Distribución de uso [29] La gura 3.15 muestra como los tres lenguages de programación más usados en la actualidad y en los últimos años son C, C++ y Java, estando éste último basado en C++. Podemos de esta manera calibrar la importancia de C++ al tratarse de un lenguage híbrido y permitir programar tanto en estilo C como en estilo orientado a objetos o en ambos. En el caso de este Proyecto Fin de Carrera, el uso de C++ viene determinado por ser el lenguaje bajo el que está desarrollado el sistema operativo DD-WRT. 3.2.2.2. CGI CGI (Common Gateway Interface ) es un estándar que permite la comunicación de aplicaciones externas con servidores. Un programa CGI se ejecuta en tiempo real, por lo que permite la generación de información de manera dinámica. 64 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Un ejemplo clásico de uso de CGI es la comunicación de una base de datos con Internet para permitir su consulta a través de un servidor. Para llevar esto a cabo se necesitará un programa CGI, al que la página web del servidor llamará cuando el usuario así lo decida, que permitirá extraer resultados de la base de datos y mostrárselos posteriormente al usuario. A la hora de usar CGI no hay límites respecto a lo que se puede realizar pero deberá tenerse siempre presente que el tiempo de cómputo deberá presentar una baja latencia para no sobrecargar el servidor en caso de recibir varias peticiones. Como un programa CGI es un ejecutable, es equivalente a dejar a cualquier usuario ejecutar un programa en el sistema, decisión que no es la más segura. Por ello existen una serie de precauciones de seguridad que deben implementarse cuando se usan programas CGI de las cuales la más importante es que los programas CGI necesitan residir en un directorio especial. Así el servidor sabe que tiene que ejecutarlo, en vez de simplemente mostrarlo por pantalla. Este directorio está bajo el control del administrador del servidor, prohibiendo de esta manera al usuario crear programas CGI. El directorio anteriormente mencionado suele denominarse /cgi-bin y estar dentro del directorio destinado a almacenar las páginas web alojadas en el servidor, normalmente /www. El servidor conoce que el directorio /cgi-bin contiene ejecutables que deberán ser ejecutados y su salida deberá ser enviada al navegador del cliente. Un programa CGI puede ser escrito en cualquier lenguage de programación que pueda ser ejecutado en el sistema, en el caso de este Proyecto Fin de Carrera os programas se han desarrollado haciendo uso de C++. Se debe hacer mención al hecho de que CGI permite la ejecución de programas tanto de tipo interpretado como compilado, lo que permite también el uso de scripts. Para el paso de datos del servidor al programa CGI, el servidor puede usar tanto líneas de comando como variables de entorno que se activan cuando se ejecuta el programa CGI. Se describen a continuación de forma breve estas variables de entorno: 3.2. ELEMENTOS SOFTWARE 65 SERVER_SOFTWARE Devuelve el nombre y la versión del software del servidor de información que contesta la petición de usuario. SERVER_NAME Devuelve nombre de host del servidor, el alias DNS, o la dirección IP como aparecería en las URL autoreferenciadas. GATEWAY_INTERFACE Devuelve la revisión de la especicación CGI con que el servidor puede trabajar. Las variables anteriormente mencionadas son activadas en todos los casos por el servidor, con independencia de la información enviada, por otro lado, las que se muestran a continuación son especícas de la petición hecha por el usuario. SERVER_PROTOCOL Devuelve el nombre y revisión del protocolo de información bajo el que se realizó la petición. SERVER_PORT Devuelve el número de puerto por el cual fue enviada la peti- ción. REQUEST_METHOD QUERY_STRING Devuelve el método por el cual la petición fue enviada. Hace referencia a la parte de la URL con la que se llama al programa CGI que viene inmediatamente después del símbolo ' ?'. Esta variable de entorno es usada para pasar una lista de pares variable-valor usando el símbolo '&' como delimitador de cada uno de los pares y el símbolo '=' como separador entre la variable y su valor. Para evitar confusiones, algunos caracteres son codicados. Esta variable es usada principalmente para pasar a los programas CGI información asociada a formularios. 66 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS REMOTE_HOST y REMOTE_ADDR Devuelven el nombre del host que realiza la petición y la dirección IP del host remoto que realiza la petición respectivamente. AUTH_TYPE Si el servidor soporta autenticación de usuario , y el programa CGI está protegido, este es el método de autenticación especíco del protocolo para validar el usuario. REMOTE_USER Si el servidor soporta autenticación de usuario , y el script está protegido, este será el nombre de usuario con el que se ha autenticado. REMOTE_IDENT Si el servidor HTTP soporta autenticación RFC 931 , entonces está variable se activará con el nombre del usuario remoto obtenido por el servidor. Esta varible solo se utilizará durante el login. CONTENT_TYPE Para peticiones que tienen información añadida, como HTTP POST y PUT, este será el tipo de datos contenido. CONTENT_LENGTH Devuelve la longitud del contenido tal como es dado por el cliente. Para devolver como respuesta una página web, bastará con imprimir ésta en pantalla usando una función destinada a ello dentro del lenguaje de programación elegido para la creación del programa CGI, respetando el estándar usado por el servidor para la presentación de webs. En los programas CGI usados en este Proyecto Fin de Carrera se hace uso de la función printf en combinación con HTML. Un ejemplo de esta combinación podría ser: printf("<HTML>\n"); printf("<HEAD>\n"); printf("<TITLE>Ejemplo de página impresa mediante CGI usando HTML\n"); 3.2. 67 ELEMENTOS SOFTWARE printf("</TITLE>\n"); printf("</HEAD>\n"); printf("</HTML>\n"); Lo anterior, al ejecutarse dentro de un programa CGI escrito en C++, daría como resultado la impresión por pantalla de una página web en blanco con la cabecera Ejemplo de página impresa mediante CGI usando HTML. Por último, se debe mencionar también que el código CGI, una vez compilado, deberá ser guardado en la carpeta cgi-bin anteriormente indicada, con permisos de ejecución y extensión 'cgi'. 3.2.2.3. HTML HTML ( HyperText Markup Language ) es el lenguage de programación básico usado en la web. El código de HTML hace uso del concepto de etiquetas para permitir a los navegadores la correcta representación de las páginas web. Para comprender la forma en la que se estructura un código HTML se puede hacer una similitud con el cuerpo humano, ya que las etiquetas aparecen según un orden lógico, limitándose qué puede aparecer o no antes o después de cada una de ellas, si hacemos la similitud con el cuerpo humano, si se observa éste de arriba abajo y consideramos sus distintas partes como etiquetas, nunca aparecerá antes la etiqueta 'piernas' que la etiqueta 'cabeza'. El lenguaje HTML es un estándar, compuesto por recomendaciones publicadas por World Wide Web Consortium ). Las especicaciones un consorcio internacional: el W3C ( ociales de HTML describen las "instrucciones" del lenguaje, pero no cómo seguirlas, es decir, cómo las interpretan los programas informáticos. Esto permite visualizar páginas Web independientemente del sistema operativo o la arquitectura del equipo del usuario. Sin embargo, pese a lo detallado de las especicaciones, existe margen para la interpretación por parte del navegador y esta es la razón por la que la misma página puede aparecer de modo diferente en un navegador u otro. Es más, algunos editores de software agregan instrucciones HTML exclusivas que no se hallan en las especicaciones de W3C. 68 CAPÍTULO 3. COMPONENTES Y TECNOLOGÍAS UTILIZADAS Por este motivo, las páginas Web que contienen dichas instrucciones pueden ser vistas en un navegador, y ser completa o parcialmente ilegibles en otros. Debido a lo anteriormente expuesto, las páginas Web deben seguir las recomendaciones de W3C, de forma que lleguen al público más amplio posible. Para un aprendizaje detallado acerca de HTML se recomienda consultar la especicación ocial de HTML 4.0112 . 12 Disponible en http://www.w3.org/TR/html401/ Capítulo 4 Desarrollo del sistema 4.1. Descripción de ob jetivos El sistema a desarrollar debe permitir, de manera general, transferir información desde una red de motas ZigBee/802.15.4 hasta una o varias direcciones IP, usando como elemento intermedio un dispositivo con capacidad de enrutamiento. En las siguientes secciones se describirá con detalle las distintas tareas llevadas a cabo para llevar a buen término lo anteriormente descrito, comenzando por las necesidades puramente hardware necesarias para la comunicación entre las motas/sensores y el enrutador, pasando por los distintos elementos software desarrollados y acabando por la integración del software con el sistema operativo elegido para el enrutador, proporcionandose de esta manera un paquete software completo con todo lo necesario para su funcionamiento en el enrutador desde el mismo momento de su instalación sin más que disponer de los elementos hardware necesarios. 4.1.1. Requisitos del sistema Para mostrar una visión más clara del sistema desarrollado se enumeran a continuación los requisitos, tanto funcionales como operacionales, que ejercieron de guía a la hora de 69 70 CAPÍTULO 4. DESARROLLO DEL SISTEMA tomar las distintas decisiones que se fueron llevando a cabo en cada una de las fases del proyecto. Requisitos operacionales • Permitir la transferencia de datos procedentes de una red de motas ZigBee/802.15.4, siendo transparente la información transportada en dichos datos, hacia una serie de direcciones IP especicadas por el usuario. • Conseguir la integración del desarrollo en el sistema operativo alojado en el enrutador, de manera que se facilite la instalación y uso por parte del usuario. Requisitos funcionales • La base sobre la que se desarrollará el sistema deberá ser un sistema operativo Linux. • Se usará el protocolo UDP. • La aplicación destinada a ejecutarse en el enrutador para ejercer las tareas de recogida de datos de la red ZigBee/802.15.4 y, posteriormente, el envío a las direcciones IP indicadas, deberá funcionar en segundo plano. • Las direcciones IP que podrán ser introducidas como destinatarias deberán cumplir con el protocolo IPv4. • El usuario podrá añadir o eliminar direcciones IP destino en cualquier momento, independientemente de si el sistema se encuentra en funcionamiento o no. • El usuario deberá ser capaz de visualizar las direcciones IP que se encuentren actualmente almacenadas como destinatarias de los datos procedentes de la red ZigBee/802.15.4. • Las direcciones IP introducidas por el usuario deberán pasar a través de una aplicación que las valide, evitándose de esta manera errores en el funcionamiento derivados de la introducción de direcciones IP incorrectas según el protocolo IPv4. • El usuario podrá elegir el puerto a través del cual se enviarán los datos proce- dentes de la red de sensores y visualizarlo desde la interfaz web. 4.2. 71 CONECTIVIDAD ENTRE DISPOSITIVOS • Los cheros, carpetas y módulos necesarios para el correcto funcionamiento del sistema deberán crearse o cargarse al encenderse el enrutador, de manera que la aplicación pueda ser ejecutada en cualquier momento desde su puesta en marcha. • El usuario deberá tener a su disposición una interfaz que le permita conocer el estado actual de la aplicación en cuanto a su funcionamiento o no. 4.2. Conectividad entre dispositivos Como primer paso en el desarrollo de la pasarela ZigBee/802.15.4 - IP se debe conseguir la comunicación entre la red formada por las motas ZigBee/802.15.4 y el router especicados1 . Para lograr esta comunicación se hace uso, por un lado, de la capacidad de conexiones vía USB del router y, por otro, de la posibilidad de replicación de los datos intercambiados entre el microcontrolador MSP430 y el procesador CC2480 a través de la conexión UART. Gracias a ésto, todos aquellos datos procedentes de los distintos sensores ZigBee/802.15.4 que llegan hasta el dispositivo coordinador pueden ser leídos usando esta interfaz UART. Usando un conversor que permita la comunicación entre la conexión UART y la entrada USB del router se conseguirá la transmisión de los datos procedentes de la red de sensores hacia el mismo. La característica necesaria para la elección del conversor fué la existencia de controladores adecuados al sistema operativo basado en un kernel 2.4 elegido para funcionar en el router. La primera opción fué la utilización del conector USB proporcionado por el equipo de desarrollo eZ420-RF2480 de Texas Instruments, sin embargo, su uso debió ser rechazado debido a la imposibilidad de compilar adecuadamente los controladores disponibles, pensados para su funcionamiento en un kernel 2.6 o superior. Consultando distintas alternativas con módulos controladores para un kernel 2.4, nalmente se eligió el coversor TTL-232R-3V3 de FTDI descrito en la subsección 3.1.2. En la gura 4.1 se muestra el detalle referente a los distintos pines existentes en el conversor. 1 Tal y como se indicó en la sección 3.1, se usarán las motas incluidas en el equipo de desarrollo eZ430- RF2480 de Texas Instruments para la formación de la red ZigBee/802.15.4 y el Premium como elemento intermedio entre ésta y la red IP. router ASUS WL-500G 72 CAPÍTULO 4. DESARROLLO DEL SISTEMA Figura 4.1: FTDI TTL-232R-3V3: Pin out [18] Una vez elegido el conversor se ha de determinar la manera en la que éste ha de ser interconectado al sensor que actuará como dispositivo coordinador de la red. Para ello se hace uso del esquemático de conexión entre MSP430 y CC2480 mostrado en la gura 4.2 en el que se especica el signicado de cada uno de los pines de salida del sensor. Una vez estudiado el esquemático, se determina que los terminales del conversor y del sensor han de ser interconectados según se indica en la tabla 4.1. Se debe tener en cuenta que todo aquel terminal o pin no usado debe ser convenientemente conectado para evitar posibles malos funcionamientos. Terminal del conversor Pin del sensor Amarillo Orange Black Red 6 1 5 2 Tabla 4.1: Interconexión entre conversor y sensor 4.2. CONECTIVIDAD ENTRE DISPOSITIVOS Figura 4.2: Esquemático de conexión entre MSP430 y CC2480 73 74 4.3. CAPÍTULO 4. DESARROLLO DEL SISTEMA Desarrollo de la aplicación pasarela En esta sección se presentan los detalles más importantes referidos a la aplicación principal de este Proyecto Fin de Carrera. Se trata del programa que toma los datos que llegan al puerto USB y los reenvía a las direcciones IP especicadas en el archivo correspondiente. Dicho reenvío estará siempre supeditado a que la trama de datos recibida por el puerto USB cumpla con el formato de trama asociado a nuestra pasarela. Si esta condición se cumple, los datos serán leídos y pasarán a formar parte de un paquete UDP (User Datagram Protocol ) que será encaminado a través de la interfaz o de las interfaces correspondiente del router para así poder alcanzar todos los destinos indicados por el usuario de la aplicación. El usuario deberá especicar el puerto a través del cual desea que sean enviados los datos procedentes de la red de sensores, así como las direcciones IP que actuarán como destinatarias. Se debe tener en cuenta que, a la hora de compilar la aplicación pasarela se usaron dos compiladores distintos, según se desease ejecutarla en un ordenador o en el router. Así, para su ejecución sobre un ordenador, cualquiera de los compiladores de C++ existentes para Linux es válido, mientras que para su ejecución en el router se hizo uso del compilador cruzado 'mipsel-linux-uclibc-c++'. 4.3.1. Funciones que componen la aplicación pasarela A continuación se muestran las distintas funciones que componen la aplicación pasarela, además de una breve descripción de su funcionamiento y sus aspectos más destacados referentes a la composición del código fuente. 4.3. DESARROLLO DE LA APLICACIÓN PASARELA 75 void AdecuacionRouter() Se encarga de la carga de los módulos necesarios para el correcto funcionamiento del conversor, de la creación de la estructura de carpetas en el sistema operativo y de la creación e inicialización de los archivos que indican el estado, las direcciones IP destinatarias y la página web que permite la visualización de estas direcciones. int AbrirPuertoSerie (char *dispositivo) Establece el vínculo con el puerto USB al que se conectará el conversor TTL-232R3V3 de FTDI, determinándose además su modo de apertura, en este caso de entrada y en modo binario. Todo lo anterior se establece a través de: open(dispositivo,std::ios::in | std::ios::binary) Por último indicar que devuelve un entero con el descriptor de chero asociado a la apertura previamente realizada. void CerrarPuertoSerie (int fd, struct termios cong) Finaliza el vínculo con el puerto USB previamente establecido a través de la función 'AbrirPuertoSerie'. Para ello se le debe pasar como parámetro el descriptor de chero devuelto por ésta última función. Como actuación complementaria, congura el puerto USB con los mismos parámetros existentes antes de la ejecución de la aplicación 'pasarela' mediante el paso del parámetro 'cong'. Este parámetro será obtenido al comienzo de la ejecución de la pasarela, previamente al cambio de conguración del puerto USB para lograr el funcionamiento necesario para el correcto desempeño de la aplicación 'pasarela'. Lo anteriormente explicado se ejecuta mediante el siguiente código: tcsetattr(fd, TCSANOW, &config); close(fd); 76 CAPÍTULO 4. DESARROLLO DEL SISTEMA La función 'tcsetattr' congura el puerto USB asociado al indicador de chero 'fd' según lo indicado a través del parámetro 'cong'. Por último, 'TCSANOW' es una constante simbólica denida en la librería <termios.h> que indica que el cambio de conguración se lleve a cabo de manera inmediata. struct termios CongurarPuertoSerie (int fd, int baudios, int datos, int parada, int paridad, int tipo_paridad, int modo, int tamano, int temporizador) Haciendo uso de esta función se establece la conguración del puerto USB desde el que se leerán los datos procedentes del conversor. Tal y como se desprende de los nombres de los parámetros, la conguración queda determinada mediante el número de símbolos transmitidos por segundo, los bits de parada, la existencia o no de paridad así como su tipo, el modo de operación (canónico o no canónico), el número de caracteres adquiridos en cada lectura y un temporizador entre lecturas sucesivas que para este caso será establecido a cero y por lo tanto quedará desactivado. Todos los datos anteriormente descritos para lograr la conguración del puerto USB han de ser introducidos en una estructura especíca para tal n, esta estructura es del tipo struct termios. Este tipo de estructura aporta una interfaz para la conguración de los parámetros de comunicación con dispositivos asíncronos. La forma de completar dicha estructura es la siguiente: nuevaconfig.c_cflag = baudios|datos|parada|paridad|tipo_paridad|CLOCAL|CREAD; nuevaconfig.c_lflag = modo; nuevaconfig.c_cc[VMIN] = tamano; nuevaconfig.c_cc[VTIME] = temporizador; Previamente a la ejecución del cambio de conguración del puerto USB de obtendrá la conguración actual del puerto para después ser devuelto a su estado original una vez terminada la ejecución de la aplicación pasarela. Esta conguración actual es proporcionada por la función 'CongurarPuertoSerie' para luego ser usada por la 'CerrarPuertoSerie'. 4.3. DESARROLLO DE LA APLICACIÓN PASARELA 77 La obtención y el cambio de conguración son llevados a cabo por las funciones 'tcgetattr' y 'tcsetattr' respectivamente. static void Demonizar (void) Mediante esta función se consigue que la aplicación pasarela sea ejecutada en background, es decir, como un demonio o servicio. Para ello debe ser invocada al comienzo de la función main. Su funcionamiento consiste en crear un proceso hijo que tiene su propia copia de datos y código del padre. Además, redirigirá la salida y entrada estándar hacia '/dev/null'. Gracias a esto, la ejecución de la pasarela continuará sigamos o no conectados al router, sin perjuicio para la ejecución de otras aplicaciones residentes en él. void Lectura_y_Envio (int puerto_serie) En esta función se realiza la lectura de la trama recibida en el puerto USB y posterior reenvío. Cuando se reciben datos en el puerto USB, se leen los bytes uno a uno. Si el byte recibido contiene 'FE' se habrá detectado el SOF, de esta manera se puede determinar que el byte que vendrá tras SOF será la longitud del campo de datos. Sabiendo que además de los bytes pertenecientes al campo de datos, existen otros tres bytes más enviados por los sensores, correspondientes a los campos de comando y FCS, se podrá indicar cuantos bytes deberán leerse a continuación hasta esperar de nuevo a la recepción de un byte con el contenido del SOF. El formato de la trama se mostró en la gura 3.4. Para la lectura de los datos llegados al puerto USB se hará uso de la función 'RecibirPorPuertoSerie', que será explicada a continuación. Una vez que se tiene almacenada la trama completa, se procede al envío de la misma a todos los destinatarios especicados por el usuario. Para ello se sigue un proceso iterativo en el que se lee el chero en el que se almacenan las direcciones IP, hasta llegar al nal 78 CAPÍTULO 4. DESARROLLO DEL SISTEMA del mismo. Cada vez que se lea una dirección IP se creará un socket UDP en el que se incluirá la trama procedente del conversor anteriromente leída y que llevará como destino la dirección IP recien leída. El proceso anteriormente descrito de recepción de trama y posterior envío de la misma a todas las direcciones IP almacenadas como destino será repetido de manera continuada mientras no se indique la detención de la pasarela u ocurra algún error en su ejecución. En cuanto al proceso de creación y envío del socket, se aprecian distintas acciones necesarias para su correcta ejecución. En primer lugar deben reservarse recursos para el socket mediante: socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) Esta función devuelve un indicador de socket que será utilizado para hacer referencia a él una vez creado. Como parámetros se le pasan tres constantes simbólicas. La primera de ellas, AF_INET, indica que el socket está destinado a su envío a través de Internet. La segunda, SOCK_DGRAM, especica el uso de datagramas en lugar del establecimiento de un circuito virtual para su envío. La tercera y última constante simbólica pasada como parámetro, IPPROTO_UDP, indica que se debe usar el protocolo de nivel de transporte UDP. UDP es el protocolo estándar para el nivel de transporte cuando enviamos datagramas a través de redes IP por lo que también podría haberse pasado como parámetro cero, de manera que sería el propio sistema operativo el que elegiría el protocolo para el envío de datagramas más apropiado, que hubiera sido UDP de igual manera. Una vez que se está seguro de disponer de recursos necesarios para procesar el socket, se procede a completar la estructura de tipo 'sockaddr_in', especicando en ella la familia de direcciones a las que podrá ser enviado, en este caso direcciones IP, y el puerto a través del cual se enviará. Para este propósito se rellena la estructura como sigue: descr_socket.sin_family = AF_INET; descr_socket.sin_port = htons(PORT); 4.3. DESARROLLO DE LA APLICACIÓN PASARELA 79 Como último paso, y si todo lo anterior ha sido realizado de manera correcta y sin errores, se procede al envio del socket descrito, indicando el descriptor de socket para el que se reservaron recursos, la dirección IP a la que se envía y la descripción del socket. Todo se lleva a cabo gracias a: inet_aton(linea, &descr_socket.sin_addr); sendto(s, buf, BUFLEN, 0, (struct sockaddr *)&descr_socket, slen); Siendo la variable 'linea' la dirección IP, 'buf ' la variable donde se almacena el dato recibido procedente del conversor y 'BUFLEN' su tamaño. int RecibirPorPuertoSerie (int fd, char *buer, int buer_tamano, int num_car, int reintentos) Se ocupa de la lectura y almacenamiento de los datos que llegan al puerto USB. Es llamada desde la función 'Lectura_y_Envio'. Lee tantos caracteres como se le indique a través del parámetro, en este caso uno. Devuelve el número de bytes leídos de forma correcta. 80 CAPÍTULO 4. DESARROLLO DEL SISTEMA 4.3.2. Diagramas de ujo El diagrama de ujo asociado a la ejecución completa de la aplicación pasarela se muestra en la gura 4.3. Figura 4.3: Pasarela: Diagrama de Flujo 4.3. DESARROLLO DE LA APLICACIÓN PASARELA 81 En cuanto a la función más importante incluída en la aplicación pasarela, la que realiza la tarea de lectura y envío de los datos procedentes de la red de sensores, su diagrama de ujo se muestra en la gura 4.4. Figura 4.4: Lectura y envío: Diagrama de Flujo 82 4.4. CAPÍTULO 4. DESARROLLO DEL SISTEMA Desarrollo de la interfaz Para la conguración, puesta en marcha y detención de la aplicación 'pasarela' se dispone de varios elementos. Por un lado pueden distinguirse aquellos destinados a la vericación del estado y conguración actual de la aplicación y por otro aquellos orientados a la modicación de lo anterior. Para ello, las opciones disponibles a través de la interfaz desarrollada permiten el inicio y detención de la aplicación, la adición y eliminación de direcciones IP destinatarias de los datos procedentes de la red de sensores, la vericación del estado de funcionamiento de la pasarela, la visualización de las direcciones IP actualmente almacenadas y la introducción y visualización del puerto a través del cual se realiza la comunicación. En un principio se desarrolló toda la estructura de interacción con la aplicación 'pasarela' a través de una interfaz web haciendo uso de CGI, sin embargo, una vez se pasó a la fase de portabilidad para su funcionamiento en el router, surgieron problemas que imposibilitaron su funcionamiento completo a través de dicha interfaz web. Estos problemas están originados por la limitación, en las versiones actuales disponibles del sistema operativo DD-WRT, a la hora de usar las variables de entorno asociadas a CGI. En concreto, para la utilidad que permitía la introducción de direcciones IP destinatarias desde la propia interfaz web, se hacía uso del metodo POST de CGI para el paso de parámetros. De esta manera, mediante la lectura de STDIN, así como de la lectura de la variable de entorno CONTENT_LENGTH, que informa del número exacto de bytes a leer, y el procesado de los datos con la función de descifrado adecuada que también se desarrolló, se conseguía la adición de la dirección IP al sistema de reenvío de los datos. Todo lo anteriormente descrito debió ser sustituido por otra solución debido a que la variable de entorno mencionada se encuentra deshabilitada, como muchas otras de CGI, por motivos de seguridad. Tan solo están disponibles para la interfaz web incluída en el sistema operativo. Por este motivo, la interacción se realiza a través de dos sistemas distintos. Por un lado se encuentran una serie de acciones accesibles a través de la interfaz web y por otro aquellas acciones llevadas a cabo mediante la ejecución a modo de comando de distintos programas de tipo shell script. 4.4. DESARROLLO DE LA INTERFAZ 4.4.1. 83 Interacción a traves de la interfaz web La interfaz web puede ser accedida a través de internet mediante la introducción de la URL (Uniform Resource Locator ) correspondiente asociada al router seguida de 'pasarelazb.html'. A modo de ejemplo, y suponiendo que la URL asignada al router sea la dirección IP 192.168.2.1, el acceso a la página principal se consigue introduciendo en el navegador: http://192.168.2.1/pasarelazb.html Una vez se muestre, la primera página que aparece da la posibilidad de comprobar si la pasarela se encuentra en funcionamiento o no, esta primera página puede verse en la FIGURA. Tras pulsar sobre el enlace que determina el estado de la pasarela, se pasa a la siguiente página asociada a la interfaz. En ella se presentan las siguientes opciones: Si la pasarela se encuentra en funcionamiento permite detener su ejecución. Si por el contrario se encuentra detenida, se nos presenta el enlace y las instrucciones a seguir para iniciar su ejecución. Visualización de las direcciones IP que actualmente estan almacenadas como destinatarias de los paquetes procedentes de la red de sensores ZigBee. Visualización del puerto a través del cual se envían los datos. En la FIGURA puede apreciarse el aspecto de esta última página para el caso en el que la aplicación se encuentre en funcionamiento. Para la realización de esta interfaz se hizo uso de HTML y CGI,de manera que gracias a las características de CGI se leen y modican los cheros correspondientes para después, dependiendo de los valores que hayan sido leídos en dichos cheros, mostrar la página web correspondiente. Por ejemplo, en el caso de la primera pantalla que se muestra, al pinchar 84 CAPÍTULO 4. DESARROLLO DEL SISTEMA sobre el enlace que verica el estado de la pasarela, la aplicación CGI se encargará de leer el archivo 'estado' y, una vez leído su contenido, si almacenaba un uno mostrará la página que permite detener la pasarela o, en el caso de que al archivo leído almacenara un cero, mostrará la página con las indicaciones que permiten iniciar la pasarela. Conviene recordar que, a la hora de compilar los archivos cgi se usaron dos compiladores distintos, según se desease ejecutarlos en un ordenador o en el router. Así, para su ejecución sobre un ordenador con un sistema operativo Linux, cualquiera de los compiladores de C++ existentes para Linux es válido, mientras que para su ejecución en el router se hizo uso del compilador cruzado 'mipsel-linux-uclibc-c++'. 4.4.2. Interacción a través de comandos Como ya fué comentado en anteriores secciones, la limitación en el uso de las variables de estado asociadas a CGI obligó a buscar alternativas que permitieran la interacción deseada con la aplicación 'pasarela'. Para ello fue muy útil la utilidad integrada en la interfaz web proporcionada por el sistema operativo DD-WRT que permite la ejecución de comandos y que se muestra en la FIGURA. Estas mismas acciones podrían llevarse a cabo accediendo al router a través de Telnet, sin embargo, la posibilidad de realizarlo todo sin necesidad de usar más que un navegador web resulta más adecuada para permitir un uso sencillo a todo tipo de usuarios, independientemente de sus conocimientos informáticos. Para ello se ponen a disposición del usuario una serie de pequeñas soluciones que complementan aquello mostrado o ejecutado a través del interfaz web asociado a la aplicación 'pasarela'. Se describen estas soluciones a continuación: Pasarelazb: permite el inicio de la ejecución del programa principal. Está desarrollado en lenguaje C++. AnadirIPzb: permite la introducción de una IP destinataria de paquetes de la red de sensores. Previamente a su almacenamiento se chequeará que la IP introducida cumple con el estándar IP versión 4. Se trata de un script ejecutado haciendo uso del intérprete de comandos ASH (A Shell ) contenido en DD-WRT. 'AnadirIPzb' hace 4.5. CONFIGURACIÓN INICIAL AUTOMATIZADA 85 uso del script 'creacion_web_destinatarios', que actualiza la página a mostrar en caso de querer visualizar, a través de la interfaz web, las direcciones IP almacenadas. EliminarIPzb: permite la eliminación de la IP situada en la posición pasada como parámetro. Dichas posiciones quedan determinadas al visualizar, a través de la interfaz web, las IP destinatarias. Se tratá de un script ejecutado haciendo uso del intérprete de comandos ASH contenido en DD-WRT. 'EliminarIPzb' hace uso del ejecutable 'creacion_web_destinatarios', que actualiza la página a mostrar en caso de querer visualizar, a través de la interfaz web, las direcciones IP almacenadas. SeleccionPuerto: permite la modicación del puerto a través del cual se envían los datos procedentes de la red de sensores y con destino a las distintas direcciones IP almacenadas. 'SeleccionPuerto' hace uso del ejecutable 'creacion_web_puerto', que actualiza la página a mostrar en caso de querer visualizar, a través de la interfaz web, el puerto que está siendo usado. 4.5. Conguración inicial automatizada Para lograr que en cada inicialización del router todo se encuentre congurado de manera adecuada para usar la aplicación pasarela, es imprescindible la creación de un script que se ejecute tras cada encendido del router. Hay varias opciones para llevarlo a cabo, pero en este caso concreto se optó por la creación de un shell script. El otro método que podía haberse elegido consiste en almacenar los comandos que se desean ejecutar en la memoria nvram, sin embargo, dicha opcion no es la más adecuada por el uso de memoria ash que requiere. Además de esta razón, que en este caso no era crítica pues el script es de pequeño tamaño, se debe tener en cuenta la facilidad para futuras modicaciones, mucho más accesibles a través de la opción nalmente elegida. Para que el shell script sea ejecutado en cada inicialización del router, debe elegirse un nombre seguido de '.startup', en este caso 'pasarelazb.startup', y ser almacenado en el directorio adecuado, tal y como se detallará en la subsección 4.6.2. 86 CAPÍTULO 4. DESARROLLO DEL SISTEMA El shell script desarrollado presenta la estructura que se muestra a continuación: #! /bin/ash touch /tmp/destinatarios.txt touch /tmp/estado.txt echo 0 >> /tmp/estado.txt mkdir /tmp/www /bin/creacion_web_destinatarios De esta manera se crearán e inicializarán todos los directorios y archivos necesarios para poder ejecutar la aplicación pasarela una vez se ponga en funcionamiento el router. Se debe aclarar que para su prueba en el entorno compuesto por un ordenador funcionando bajo un sistema operativo Ubuntu 10.04 el intérprete de comando utilizado fué bash. 4.6. Integración en el sistema operativo DD-WRT Los distintos componentes destinados para funcionar en el router, y que posibilitan el funcionamiento de la pasarela, han sido compilados junto al sistema operativo DDWRT, de esta manera, bastará instalar en el router el paquete proporcionado y, a falta de la conexión del conversor al puerto USB, se dispondrá del software necesario para el funcionamiento de la pasarela. Este paquete compilado, como ya se ha mencionado, está formado por DD-WRT y todos los componentes necesarios para el correcto funcionamiento de la pasarela, lo que incluye: Aplicación principal Interfaz web Ejecutables para la interacción con la aplicación pasarela a través de comandos Módulos necesarios para la correcta detección del conversor 4.6. INTEGRACIÓN EN EL SISTEMA OPERATIVO DD-WRT 87 Para compilar todos estos componentes junto al sistema operativo y obtener así una solución global y agrupada fueron necesarios tres pasos. En el primero de ellos se llevó a cabo la extracción del rmware DD-WRT, en el segundo se realizaron las modicaciones deseadas y en el tercero y último se compiló todo de nuevo obteniéndose una única solución. Veamos estos pasos con más detalle. 4.6.1. Extracción del rmware DD-WRT Antes de proceder a la extracción del rmware se debe disponer de una serie de requisitos mínimos para que sea realizada con exito. Estos requisitos son: Llevarla a cabo sobre uno de los sistemas operativos soportados por la herramienta de extracción, a saber: Linux o OS-X. En el caso concreto de este Proyecto Fin de Carrera, se utilizó como sistema operativo Ubuntu 10.04 ejecutándose sobre un ordenador portatil DELL Inspiron 1545. GNU C GNU C++ Librerías de desarrollo estándar para C y C++ GNU make Disponiendo de todo lo anterior, se puede pasar a utilizar la herramienta para la extracción del rmware. Dicha herramienta puede conseguirse desde los repositorios ociales proporcionados por DD-WRT2 . En el paquete que se obtendrá también se encontrarán las herramientas necesarias para la instalación de paquetes y la posterior reconstrucción del sistema operativo. Una vez obtenida la herramienta, se lleva a cabo la extracción mediante el uso del comando: 2 Mediante el comando 'svn checkout http://rmware-mod-kit.googlecode.com/svn/trunk/ rmwaremod-kit-read-only' 88 CAPÍTULO 4. DESARROLLO DEL SISTEMA ./extract_firmware.sh firmware.bin directorio_de_extracción Debe indicarse que 'rmware.bin' es el sistema operativo DD-WRT que se pretende extraer3 y 'directorio_de_extracción' hace referencia al lugar donde se almacenarán los archivos resultantes de la extracción. Por útimo, indicar que para ejecución del comando 'extract_rmware.sh' se debe estar dentro del directorio en el que se encuentre la herramienta. 4.6.2. Modicación del rmware DD-WRT Una vez extraido el rmware, el sistema de archivos resultante se encontrará almacenado en el directorio indicado anteriormente. Dicho sistema de archivos se compone de los siguientes directorios principales: image_parts: aquí se almacenan archivos intermedios necesarios para futuras reconstrucciones. rootfs: aquí se encuentra el sistema de archivos que compone DD-WRT, con los directorios habituales que se encuentran en los sistemas operativos Linux (bin, dev, etc...). Las modicaciones que se introducirán serán llevadas a cabo todas en este directorio. installed_packages: destinado a los paquetes que el usuario desea instalar en el sistema operativo DD-WRT para su uso desde el mismo momento de su instalación en el router y que no se encuentran a su disposición en la versión disponible por defecto. Para llevar a cabo esto se hace uso de la herramienta 'ipkg_install.sh', obtenida junto a la herramienta de extracción en el paquete obtenido desde los repositorios de DD-WRT. A continuación se detallan las modicaciones llevadas a cabo dentro del sistema de archivos contenido en la carpeta 'rootfs', indicando aquellos directorios en los que se han añadido elementos y de qué elementos se tratan para cada caso: 3 En este caso DD-WRT versión 24 (build 12188) 4.6. INTEGRACIÓN EN EL SISTEMA OPERATIVO DD-WRT 89 bin: se añade el ejecutable destinado a la creación de la página web, los ejecutables para la interacción con la aplicqación mediante el uso de comandos y la aplicación principal de la pasarela. etc/cong: se añade el archivo que se ejecutará en cada encendido del router para su lograr la adecuada conguración permitiendo así el correcto funcionamiento de la aplicación pasarela una vez que el router se encuentra inicializado. lib: añadidos los módulos 'usbserial.o' y 'ftdi_sio.o' para permitir la detección y posterior manejo del conversor conectado al puerto USB usado en este Proyecto Fin de Carrera. www: añadida la pagina html que servirá como inicio del interfaz web de la aplicación pasarela. Además, se crea dentro la carpeta 'cgi-bin' en la que se almacenarán los archivos cgi necesarios para la interacción con los archivos que indican el estado actual de la pasarela en cuanto a funcionamiento y conguración. 4.6.3. Reconstrucción del rmware DD-WRT Por último, una vez extraido el rmware y realizados los cambios que se desean, se debe volver a crear un paquete único de manera que pueda ser instalado como un único elemento en el router. Para esta accción se hará uso de otra de las herramientas obtenidas desde los repositorios de DD-WRT, en este caso 'build_rmware.sh'. Para su correcto uso deberá ejecutarse el siguiente comando desde el directorio en el que esté almacenada la herramienta: ./build_firmware.sh directorio_de_salida/ directorio_de_extracción/ Siendo 'directorio_de_salida' el lugar donde se almacenarán las reconstrucciones del rmware y 'directorio_de_extracción' el lugar donde está el sistema de archivos extraído y posteriormente modicado. 90 CAPÍTULO 4. DESARROLLO DEL SISTEMA Por último, indicar que la herramienta reconstruirá el rmware y presentará diversas versiones, diferenciadas entre ellas por el hecho de estar optimizadas para su instalación en routers de distintos fabricantes. También se incluye una versión reconstruida del rmware genérica. 4.7. Aplicación cargada en los sensores ZigBee/802.15.4 Para poder determinar el correcto funcionamiento de la aplicación pasarela desarrollada para el router, se hace imprescindible la carga en los sensores contenidos en el equipo de desarrollo eZ430-RF2480 de Texas Instruments de una aplicación que haga uso de la capacidad de monitorización y posterior envío de los datos monitorizados a través de la red ZigBee. Dado que la capacidad de los sensores incluidos se basa en la medida de la temperatura del lugar en el que se encuentren colocados, la aplicación ZASA (ZigBee Accelerator Sample Application ), aportada por Texas Instruments a modo de ejemplo de uso, es ideal para el propósito deseado. La aplicación ZASA puede hacer que los sensores actúen de dos maneras distintas, como sumideros o como fuentes de infomación. Si indicamos esto desde el punto de vista de su papel en la red, los sensores pueden actuar como los tipos de dispositivos habituales descritos por la especicación ZigBee/802.15.4: coordinador, enrutador o dispositivo nal. De esta manera, los datos recolectados y enviados por aquellos sensores que actúen como fuente de información serán el voltaje del bus y la temperatura ambiente. La conguración del papel dentro de la red será determinada en base a la actuación sobre el botón incluido en el CC2480 e informada a través de un código de colores mediante dos indicadores luminosos. Los sensores se conguran con dos posibles acciones, pulsando el botón incluido en CC2480 una o dos veces. Se muestran a continuación las distintas posibilidades: Si se pulsa el botón una vez en dos segundos intentará congurarse como enrutador dentro de una red ya existente, actuando además como fuente de datos, si no existe tal red, pasará a crear una nueva y se establecerá como coordinador, actuando como sumidero de datos. Lo anteriormente descrito se indicará mostrando el LED rojo encendido de forma continua en caso de actuar como coordinador o mostrando el 4.7. APLICACIÓN CARGADA EN LOS SENSORES ZIGBEE/802.15.4 91 LED verde encendido en caso de actuar como enrutador. Si se pulsa el botón dos veces en dos segundos, el sensor quedará congurado como un dispositivo nal y, por lo tanto, actuará como fuente de datos. Esto quedará indicado a través del parpadeo del LED de color verde a una frecuencia de 1Hz. Para completar el código usado a traves de los LED incluidos, caben destacarse los siguientes casos: Ambos LED parpadeando indican que el sensor aún no ha sido congurado. En el caso de que los sensores actúen como enrutador o dispositivo nal, una vez que envían un paquete de datos el LED rojo parpadeará. En el caso de actuar el sensor como coordinador, un parpadeo del LED verde indicará la correcta recepción de un paquete de datos. Para adecuar la aplicación ZASA a ciertas características propias del desarrollo llevado a cabo en este Proyecto Fin de Carrera, se han incluido modicaciones en su código que a continuación se describen: El sensor que se conecta al conversor TTL-232R-3V3 de FTDI, y que por lo tanto se comunica con el router, presenta como única posibilidad de actuación dentro de la red la de dispositivo coordinador. Esto es así porque dicha función va directamente ligada a su conexión con el router y por lo tanto no tiene ningún sentido que se deba determinar, a través de la pulsación del botón, su papel en la red. Además, de esta manera se prevén posibles fallos derivados de cortes de luz y reinicios del router puesto que al estar pensado para su funcionamiento autónomo, el hecho de tener que estar sicamente presente para la conguración de este sensor podría hacerle perder al conjunto la facilidad y comodidad de uso que se pretende. Para conseguir esta conguración automática como coordinador anteriormente descrita se modicó el código incluido en 'sample_app.c', suprimiéndose el funcionamiento de la función 'appBtnPress' para de esta manera deshabilitar la interacción a través del botón e 92 CAPÍTULO 4. DESARROLLO DEL SISTEMA incluyéndose la variable 'timerboton' en combinación con otras llamadas a funciones para conseguir la conguración como coordinador que se desea. Para los sensores que actúan como fuentes de datos (ya sean enrutadores o dispositivos nales), se añade un campo en la trama enviada que los identica de manera física, no a través de la dirección de red que asigna el protocolo basada en la asignación distribuida de direcciones. De esta manera, se puede identicar a que sensor corresponde cada paquete recibido sin necesidad de saber cual se conectó a la red en primer lugar, proporcionando un método de identicación más claro. Para lograr este propósito se realizaron los siguientes cambios en 'sample_app.c': • La constante SRCE_REPORT_SZ fue establecida a un valor de tres • Se crea la constante SRCE_REPORT_ZBID con un valor de dos • Por último, estableciendo srceReport[SRCE_REPORT_ZBID] dentro de la función 'appSrceData', se determina el número que identicará a cada sensor. Por ejemplo, para establecer el número identicativo del sensor a uno, se debería intoducir en el código: srceReport[SRCE_REPORT_ZBID] = 1; Capítulo 5 Fase de pruebas 5.1. Descripción del entorno de pruebas Con el objetivo de detectar defectos que causen un funcionamiento no deseado del desarrollo llevado a cabo en este Proyecto Fin de Carrera se determinaron una serie de pruebas que los distintos componentes debían ir vericando para de esta manera construir cada nuevo paso sobre una base sólida en lo referente a su funcionamiento. Como entorno de prueba se usarón dos elementos para la vericación, variando este entorno según la fase del proyecto en la que se ejecutaron las pruebas, como se mostrará más adelante. Se pueden diferenciar dos entornos de pruebas: Ordenador DELL Inspiron 1545, equipado con 4 Gb de memoria RAM y un procesador Intel Core 2 Duo T6400 y funcionando con un sistema operativo Ubuntu 10.04. Router ASUS WL-500G Premium, funcionando con un sistema operativo DD-WRT. Haciendo uso de los dos entornos anteriormente descritos se realizarán una serie de vericaciones que determinarán si el desarrollo cumple con los requisitos operacionales y 93 94 CAPÍTULO 5. FASE DE PRUEBAS funcionales que fueron denidos para el proyecto. 5.2. Procesos de vericación El objetivo de los procesos de vericación es la búsqueda de defectos en el sistema debidos a errores en el proceso de desarrollo para así evitar la posterior aparicición de fallos. Estas actividades de vericación se llevan a cabo mediantte un conjunto de pruebas, pudiéndose utilizar distintos métodos, para este caso concreto el método usado para la vericación ha sido el método a través de experimentos, esto es, la prueba del sistema desarrollado mediante la simulación de las condiciones reales en las que debe desempeñar su función, observando y analizando su funcionamiento. Para llevar a cabo el proceso de vericación se determina una secuanciación bottomtop, partiendo del correcto funcionamiento de los elementos unitarios y acabando en la vericación de la combinación de todos estos elementos unitarios para dar lugar al sistema global que se desea. 5.2.1. Pruebas unitarias Para el caso de las pruebas unitarias se usó el entorno de pruebas constituido por el ordenador DELL Inspiron 1545, de esta manera, una vez conseguido el correcto funcionamiento de los distintos elementos en este entorno, éstos quedaban validados para su posterior integración en el sistema mediante la portabiliddad al router ASUS WL-500G Premium. Igualmente cabe destacar que en este proceso se llevaron a cabo tres tipos de pruebas: Pruebas de progresión: la primera prueba que se realiza al elemento. Pruebas de corrección: repetición de una prueba tras haber sido detectado un error y haberse realizado un cambio. 5.2. PROCESOS DE VERIFICACIÓN 95 Pruebas de regresión: volver a ejecutar una prueba que ya se había pasado satisfactoriamente tras realizar un cambio. Siguiendo la secuenciación temporal llevada a cabo en el desarrollo se exponen a continuación las pruebas unitarias de cada elemento: Pasarelazb Para la vericación de este elemento se hizo uso del ordenador DELL Inspiron 1545 en combinación con el conversor TTL-232R-3V3 de FTDI y los sensores incluidos en el equipo de desarrollo eZ430-RF2480 de Texas Instruments. La vericación se llevó a cabo de forma progresiva, añadiendo las distintas funciones de las que se compone de manera escalonada según el siguiente orden: 1. Funciones para el manejo, conguración y lectura del puerto USB. 2. Función destinada al envío de los datos leídos del puerto USB a una dirección IP y un puerto jos. 3. Adición de lectura de archivo para indicar la interrupción de la aplicación. 4. Adición de lectura de cheros para permitir la modicación de las direcciones IP de destino y del puerto a usar. 5. Función que permite la ejecución 'pasarelazb' en background. Para llevar a cabo la prueba se conectó el conversor al sensor que actua como coordinador por un lado y por el otro se conectó a un puerto USB de los disponibles en el ordenador. Una vez comprobado el puerto que el sistema operativo Ubuntu le asignaba1 y hecha la correspondiente modicación del mismo en el código fuente se procedía a la ejecución del programa habiendo previamente congurado los demás sensores para su funcionamiento como enrutadores o dispositivos nales. 1 De tipo ttyUSB# 96 CAPÍTULO 5. FASE DE PRUEBAS Una vez se encontraba el programa en funcionamiento y los dispositivos correctamente congurados se procedía a la comparación de los datos obtenidos a través de la aplicación 'pasarelazb' con los obtenidos gracias a la herramienta Putty (descrita en 3.2.1.5). Para ver los datos obtenidos por Putty de una manera más clara se hacía uso de un postprocesado mediante XVI32 (descrito en 3.2.1.6). De esta manera, se fueron ajustando los parámetros de conguración asociados al puerto USB hasta conseguir la lectura de los datos tal y como eran obtenidos a través de Putty. Así, para poder visualizar los datos leídos a través del conversor se introdujo en el código fuente del programa 'pasarelazb' las líneas necesarias para la impresión por pantalla de todos los caracteres que iban siendo leídos del conversor, de manera que pudiera realizarse la comparación anteriormente mencionada. Estas líneas permitían la lectura y correcta impresión de los datos en formato hexadecimal. Se muestra a continuación como ejemplo el código que posibilita la impresión por pantalla del preámbulo del paquete enviado desde el conversor procedente del sensor que actua como coordinador: cout<<"PREAMBULO: "<<hex<<int(buf[0])<<endl; Una vez asegurada la correcta recepción de los datos, se pasó al envío de éstos a una dirección ja. Para facilitar la vericación de los envíos se decidió que esta dirección de destino fuese el localhost. Además se desarrollaró una sencilla aplicación que actuara recepcionando estos datos. Así, haciendo uso de la visualización introducida en 'pasarelazb' y de esta aplicación de recepción se pudo constatar el correcto envío a la dirección IP indicada. Se muestra a continuación la parte del código de la aplicación de recepción que permite visualizar lo enviado por la aplicación 'pasarelazb': cout<<"Datos procedente de la mota "<<dec<<int(buf[12])<<endl; cout<<"Temperatura: "<<dec<<int(buf[10])<<" Grados"<<endl; cout<<"Voltaje: "<<dec<<int(buf[11])<<" V"<<endl; cout<<"Network address: "<<hex<<int(buf[5])<<hex<<int(buf[4])<<endl; En este punto se añadió la lectura de un archivo a través del cual se especica si la aplicación debe seguir ejecutándose o no, su chequeo consistió en la modicación manual 5.2. PROCESOS DE VERIFICACIÓN 97 de dicho chero para determinar la interrupción de 'pasarelazb' en el momento debido. Tras lograr la correcta recepción y posterior envío de los paquetes se añadió la posibilidad de lectura de puerto y dirección IP desde un archivo que podía ser modicado. Con el objetivo de probar esta adición se creó el chero de destinatarios con la dirección IP 127.0.0.1 (localhost ) y se usó la aplicación de recepción anteriormente mencionada de manera que quedara comprobaa la correcta interpretación de la dirección IP introducida en el chero. De igual manera y siguiendo el mismo proceso se comprobó la correcta lectura e interpretación del archivo destinado a indicar el puerto a usar para el envío de los datos. Por último, se añadió la función que permitía la ejecución de todo lo anterior en background. Comprobando que a pesar de ejecutarse como un demonio seguía cumpliendo todo lo anteriormente vericado. Shell scripts Para la vericación de los shell scripts en el entorno de pruebas indicado se usó bash, incluido por defecto en la instalación de Ubuntu 10.04, como intérprete de comandos. Una vez indicado esto, su prueba se basó en comprobar que modicaban, borraban y creaban los directorios y archivos de la manera en la que debian según los distintos requisitos. Se detallan a continuación las distintas vericaciones realizadas en cada shell script : AnadirIPzb: la vericación de este script se llevo a cabo comprobando por separado cada una de las tareas de las que se compone y vericando después su funcionamiento conjunto, de esta manera, el orden seguido a la hora de vericar e integrar funciones dentro del script fué el siguiente: 1. Vericación de que la dirección IP introducida se compone de cuatro partes. Para llevar esto a cabo se introducjeron direcciones IP formadas por una, dos, tres y cinco partes, separadas todas por puntos, comprobándose que todas ellas eran detectadas como no válidas. Una vez hecho esto, y tras comprobar que las direcciones IP formadas por cuatro partes eran clasicadas como válidas, 98 CAPÍTULO 5. FASE DE PRUEBAS se procedió a comrpobar que también eran descartadas todas aquellas direcciones formadas por cuatro partes pero no separadas por un punto, vericándose también este extremo. 2. Vericación de que todas y cada una de las cuatro partes de las que se compone la dirección IP introducida están compuestas tan solo de valores numéricos. Para la vericación completa de este punto se introdujeron direcciones IP formadas por cuatro partes y separadas por puntos. De esta manera se comprobaron las distintas combinaciones en las que alguna o varias de las partes constituyentes de la dirección IP contenían un valor no numérico. En todos los casos fué detectado dicho valor y, por lo tanto, clasicadas como direcciones IP no válidas. 3. Vericación de que todas y cada una de los cuatro valores numéricos de los que se compone la dirección IP introducida se encuentran dentro del rango permitido. Para la vericación completa de este punto se introdujeron direcciones IP formadas por cuatro partes y separadas por puntos. De esta manera se comprobaron las distintas combinaciones en las que alguna o varias de las partes constituyentes de la dirección IP contenían un valor numérico por encima de 255. En todos los casos fué detectado dicho valor y, por lo tanto, clasicadas como direcciones IP no válidas. 4. Si todo lo anterior se cumple, almacenamiento en el chero correspondiente de la dirección IP introducida. La vericación de este punto consistió en introducir una dirección IP válida y comprobar su correcto almacenamiento en el chero indicado. 5. Por último, eliminación de posibles direcciones IP repetidas dentro del chero. La vericación de este punto consistió en introducir de manera consecutiva dos direcciones IP válidas iguales y la posterior comprobación de que solo se almacenaba una vez en el chero. Siguiendo este orden, a medida que un objetivo cumplía con los requisitos de uno de los puntos anteriores se añadía el siguiente, partiendo de la base de lo que ya se había desarrollado y vericado. 5.2. PROCESOS DE VERIFICACIÓN 99 EliminarIPzb: para vericar este script se hizo uso de 'AnadirIPzb', mediante el cual se almacenaron varias direcciones IP para, posteriormente y tras seleccionar el número de línea correspondiente a la dirección IP que se deseaba eliminar, hacer uso de 'EliminarIPzb' y comprobar que se había eliminado la dirección IP que ocupaba el número de línea seleccionado y que, además, aquellas que ocupaban posiciones inferiores habían sido desplazadas convenientemente. SeleccionPuerto: la vericación de este script se llevó a cabo en dos fases que a continuación se detallan 1. Vericación de detección de valores no permitidos. Para la comprobación de este requisito se desarrolló el código necesario para detectar,y en tal caso desechar, toda aquella introducción de puerto que no se trate de un número dentro de un rango determinado. Con el objetivo de probar su funcionamiento se introdujeron valores no numericos además de valores fuera del rango permitido, habiéndose dettectado en todos los casos y posibles combinaciones la no validez del valor introducido. 2. Eliminación del anterior valor almacenado y almacenamiento del valor introducido en caso de ser detectado como válido. En este caso se introducía un valor válido y se comprobaba su correcto almacenamiento. Posteriormente se introducía otro valor también válido, comprobándose que éste último había sustituído de manera adecuada al anteriormente almacenado. Ejecutables destinados a la creación de un HTML Aquí se incluye tanto 'creacion_web_destinatarios' como 'creacion_web_puerto'. El funcionamiento de los dos es completamente análogo por lo que el proceso de vericación seguido con los dos fué el mismo, consistiendo en la vericación de la correcta generación de un archivo con extensión HTML partiendo de los datos almacenados en el chero correspondiente (aquel que almacena las direcciones IP destinatarias o aquel que almacena el puerto actualmente seleccionado). La vericación consistió en introducir en los cheros una serie de datos haciendo uso de 'AnadirIPzb' o 'SeleccionPuerto' y abrir 100 CAPÍTULO 5. FASE DE PRUEBAS con el explorador Firefox incluido en Ubuntu 10.04 la página creada, determinando si lo visualizado se corresponde con lo almacenado en cada uno de estos archivos. Interfaz web Bajo este punto quedan englobadas tanto la página 'pasarelazb.html' de inicio de la interfaz como los ejecutables 'Estado.cgi' y 'Detener.cgi'. Veamos el proceso de vericación de cada uno de ellos: Pasarelazb.html: la vericación consistió en su visualización haciendo uso del explorador Firefox. Estado.cgi: dado que este ejecutable debe leer un archivo y según su cobtenido mostrar una página u otra, su prueba consistió en la modicación manual de dicho archivo y en la vericación de que semostraba por pantalla la página HTML adecuada. Detener.cgi: este ejecutable debe modicar un archivo y posteriormente mostrar una página HTML. Para su vericación se comprobó la modicación adecuada del correspondiente archivo y la visualización correcta de la página HTML. 5.2.2. Pruebas de integración A la hora de llevar a cabo la integración de distintos elementos unitarios ya vericados, se siguió una secuenciación que permitía la detección de posibles fallos en dicha integración de manera rápida. Las pruebas de integración y su correcta secuenciación están enfocadas a encontrar problemas de interacción entre los distintos elementos que van integrándose. Se detalla a continuación el plan seguido para la integración: 1. Lectura por parte de la aplicación 'pasarelazb' de los archivos modicados por 'AnadirIPzb' y 'SeleccionPuerto'. 2. Posterior adición de 'EliminarIPzb', siendo el archivo modicado por este script aquel modicado por 'AnadirIPzb'. 5.2. PROCESOS DE VERIFICACIÓN 101 3. Creación de los enlaces entre distintas páginas HTML de la interfaz web. 4. Enlace de los ejecutables 'Estado.cgi' y 'Detener.cgi' con los archivos modicados y/o leídos por 'pasarelazb'. 5.2.3. Pruebas de sistema Una vez integrado el sistema, es decir, construido el último nivel de integración y realizadas las pruebas de funcionalidad capaces de detectar problemas en los interfaces entre los distintos elementos unitarios, se pasa a la fase de pruebas del sistema, para asegurar el cumplimiento de todos los requisitos en el entorno bajo el que debe funcionar. Una vez hecha la portabilidad de todo lo anteriormente descrito y vericado al router gracias a la compilación cruzada y a la construcción del rmware DD-WRT con las adiciones desarrolladas en este Proyecto Fin de Carrera, se pasó a la vericación global del sistema en el entorno bajo el que debe cumplir con los requisitos. Se detallan a continuación los requisitos funcionales que implicaron pruebas de sistema: Se usará el protocolo UDP. Una vez ejecutada la aplicación 'pasarelazb' se hacía uso de la aplicación de recepción también desarrollada para comprbar el correcto uso del protocolo de transporte UDP. La aplicación destinada a ejecutarse en el enrutador para ejercer las tareas de recogida de datos de la red ZigBee/802.15.4 y, posteriormente, el envío a las direcciones IP indicadas, deberá funcionar en segundo plano. Su vericación consistió en la ejecución del ejecutable 'pasarelazb' y, posteriormente, accediendo a través Telnet comprobación de que se encontraba en ejecución mediante el comando 'ps'. El usuario podrá añadir o eliminar direcciones IP destino en cualquier momento, independientemente de si el sistema se encuentra en funcionamiento o no. 102 CAPÍTULO 5. FASE DE PRUEBAS Una vez encontrándose el ejecutable 'pasarelazb' en funcionamiento se añadían y eliminaban direcciones IP, funcionando en todo momento de manera correcta y variando adecuadamente su funcionamiento en función de lo introducido. El usuario deberá ser capaz de visualizar las direcciones IP que se encuentran actualmente almacenadas como destinatarias de los datos procedentes de la red ZigBee/802.15.4. Su vericación consistió en la visualización de la página correspondiente a través del acceso remoto al router. El usuario podrá elegir el puerto a través del cual se enviarán los datos procedentes de la red de sensores y visualizar el puerto usado desde la interfaz web. La modicación del puerto quedó vericada haciendo uso de 'SeleccionPuerto' en combinación con la aplicación de recepción desarrollada, que era programada para usar el puerto que se introducía y, de esta manera, constatar el correcto uso del mismo. Posteriormente se procedió a la visualización a través de la interfaz web del puerto previamente introducido. Los cheros, carpetas y módulos necesarios para el correcto funcionamiento del sistema deberán crearse o cargarse al encenderse el enrutador, de manera que la aplicación pueda ser ejecutada en cualquier momento desde su puesta en marcha. La aplicación WinSCP (descrita en 3.2.1.4) permitió vericar que los archivos y carpetas eran creados en el router tal y como el shell script 'pasarelazb.startup' indicaba. El usuario deberá tener a su disposición una interfaz que le permita conocer el estado actual de la aplicación en cuanto a su funcionamiento o no. Esto fue vericado iniciando y deteniendo el ejecutable 'pasarelazb' y conrmando que era mostrado el mensaje correcto según se encontrará o no en funcionamiento. Capítulo 6 Conclusiones y líneas futuras de trabajo En el presente capítulo se expondrán las conclusiones deducidas del desarrollo de este Proyecto Fin de Carrera. Además se mencionarán posibles líneas de investigación y estudio que permitirían la continuación del mismo, permitiendo a otros proyectandos su uso como base para futuros desarrollos. 6.1. Conclusiones Una vez alcanzado el nal en el desarrollo del presente Proyecto Fin de Carrera, pueden considerarse como superados los objetivos que en el principio del mismo se marcaron y que a continuación se detallan: Realización de una pasarela Zigbee/802.15.4-IP sobre un router comercial. Posibilidad de seleccionar distintas IP destinatarias así como el puerto a través del cual se desean enviar los datos procedentes de la red de sensores ZigBee. Utilización, en el router sobre el cual funcionará el desarrollo, de un sistema operativo de código abierto. 103 104 CAPÍTULO 6. CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO Permitir al usuario la interacción con la pasarela a través de una interfaz web, de manera que no se necesiten conocimientos añadidos a la ya habitual y comunmente utilizada navegación en Internet. Integración del desarrollo completo en el sistema operativo elegido, quedando todo congurado e instalado de la manera más cómoda posible para el usuario. Además de los objetivos anteriormente expuestos y exigidos, a título personal se deben mencionar distintos campos en los que se ha adquirido un conocimiento mayor al haber sido directamente tratados a lo largo de la realización de este Proyecto Fin de Carrera, estos son: Estudio del conjunto de soluciones estandarizadas ZigBee/802.15.4. Manejo y conguración, a través del lenguaje C++, de los puertos disponibles en un dispositivo equipado con un sistema operativo basado en Linux. Conocimientos básicos de HTML y scripting. Aprendizaje de la estructura y de las posibilidades de conguración y modicación del sistema operativo de código abierto DD-WRT. Conocimientos acerca de los distintos pasos a seguir a la hora de realizar un proyecto desde cero, desde la fase de documentación y estudio hasta la realización del plan de pruebas, pasando por el estudio de distintas alternativas y acabando con este documento. 6.2. Líneas futuras de traba jo Como consecuencia del continuo aumento de necesidades relacionadas con la monitorización tato en el ámbito de la industria, como en el ámbito médico o residencial, ZigBee/802.15.4, en combinación con el desarrollo llevado a cabo en este Proyecto Fin 6.2. LÍNEAS FUTURAS DE TRABAJO 105 de Carrera, puede cubrir una amplia variedad de estas necesidades. Se detallan a continuación algunas variantes que, partiendo de este desarrollo, podrían aportar soluciones interesantes: Añadir comunicación desde el usuario hacia la red de sensores ZigBee para permitir cambios en su conguración. Esta posibilidad implicaría casi con total seguridad un cambio en la elección de los sensores, ya que los usados en este desarrollo admiten una limitada capacidad de conguración. Adición de soporte para direcciones IPv6 ya que el agotamiento de las direcciones IPv4 hará imprescindible su uso en pocos años. Integración total del interfaz web en la misma estructura añadiendo módulos y utilizando otras opciones de comunicación entre HTML y los ejecutables como podría ser PHP. 106 CAPÍTULO 6. CONCLUSIONES Y LÍNEAS FUTURAS DE TRABAJO Apéndice A Manual de usuario A.1. Instalación del sistema operativo en el router A.1.1. Actualización desde otra versión de DD-WRT A.1.2. Instalación en otros casos A.2. Conguración inicial A.3. Manejo de la interfaz 107 108 APÉNDICE A. MANUAL DE USUARIO Bibliografía [1] DD-WRT Ocial Web Page. Disponible en http://www.dd-wrt.com/site/index. [2] ASUS. WL-500g Premium Features. Disponible http://www.asus.es/product.aspx?P _ID=8el2DcrRjLoHNdQ8&templete=2. [3] BlackCode Magazine. A brief programming en http://mixter.void.ru/rawip.html. en tutorial in C for raw sockets. Disponible [4] Per Bothner. Sockets Tutorial. http://www.linuxhowtos.org/C_C++/socket.htm. Disponible en Estudio de la tecnología Zigbee y la implementación en la aplicación de sensores remotos, 2010. Disponible en [5] Dora Castañeda, Diana Bacca, and Gustavo Higuera. http://www.iiis.org/cds2010/cd2010csc/cisci_2010/PapersPdf/ca371me.pdf. [6] Cristian Castiblanco. Programación Shell en Linux. Disponible en http://casidiablohost.googlepages.com/ProgramacinenshellLinux.pdf. [7] H.M. Deitel and P.J. Deitel. [8] Ata Elahi and Adam C++ Cómo Programar. Prentice Hall, 1999. Gschwender. Bee Wireless Sensor and Control Network, Introduction to the Zig- 2009. Disponible http://www.informit.com/articles/article.aspx?p=1409785&seqNum=4. en [9] José Tomás Entrambasaguas Muñoz. Ingeniería de desarrollo de Sistemas de Telecomunicación. Servicio de Publicaciones e Intercambio Cientíco de la Universidad de Málaga, 2008. 109 BIBLIOGRAFÍA 110 [10] Shahin Farahani. [11] Drew Gislason. . Elsevier, 2008. ZigBee Wireless Networks and Transceivers . Elsevier, 2008. ZigBee Wireless Networking [12] Mareca Hatler, Darryl Gurganious, Charley Chi, and Mike Ritter. A Market Dyna- . ON World, 2010. mics report on IEEE802.15.4 and ZigBee [13] Janell Armstron. C. Richard Helps. Comparative Evaluation of ZigBee and Blue- , 2007. tooth: Embedded Wireless Network Technologies for Students and Designers. Disponible en http://icee.usm.edu/icee/conferences/asee2007/papers/ 1242_comparative_evaluation_of_zigbee_and_blu.pdf. [14] Texas Instruments. CC2480 , Developer Guide 2008. Disponible en http://focus.ti.com/lit/an/swra176/swra176.pdf. [15] Jukka Korpela. , 2010. Disponible en Getting Started with CGI Programming in C http://www.cs.tut./jkorpela/forms/cgic.html. [16] Ed Callaway. Florida Communication Research Lab & Motorola Labs. Low Power , November Consumption Features of the IEEE 802.15.4/ZigBee LR-WPAN Standard. 2003. Disponible en http://www.cens.ucla.edu/sensys03/sensys03-callaway.pdf. [17] Jin-Shyan Lee, Yu-Wei Su, and Chung-Chou Shen. Wireless Protocols: Bluetooth, UWB, ZigBee, and A Comparative , 2007. Wi-Fi Study of Disponible en http://eee.guc.edu.eg/Announcements/Comparaitive_Wireless_Standards.pdf. [18] Future Technology Devices International Ltd. TTL-232R-3V3 USB to TTL Serial , 2006. Disponible en http://eris.liralab.it/viki/images/c/c1/FTDI_- Converter Cable _serial_converter_cable_TTL232R.pdf. [19] Jordi Mayné. , 2009. Dis- Estado actual de las Comunicaciones por Radio Frecuencia ponible en http://www.bairesrobotics.com.ar/data/estado_actual_de_las _comunicaciones_por_radiofrecuencia.pdf. [20] Daintree Networks. , 2008. Disponible Getting Started with ZigBee and IEEE 802.15.4 en http://www.daintree.net/downloads/whitepapers/zigbee_primer.pdf. [21] Patrice Oehen. ZigBee: An Overview of the Upcoming Standard., October 2005. Disponible en http://www.dcg.ethz.ch/lectures/ws0506/seminar/materials/zb_slides.pdf. BIBLIOGRAFÍA [22] Juan R. 111 Pozo. Tutorial de , 2003. HTML Disponible en http://html.conclase.net/tutorial/html/. [23] Michael R. Sweet. , 2005. Serial Programming Guide for POSIX Operating Systems Disponible en http://www.easysw.com/mike/serial/serial.html. [24] IAR Systems. , 2006. MSP430 IAR Embedded Workbench ID [25] Iñigo Tejedor and Pello Altadill. . Disponible Taller Shell, comandos y programación en http://4party.cuatrovientos.org/les/2007/shell_linux.pdf. [26] Texas Instruments. Z-Accel 2.4 GHz ZigBee . Disponible en Processor http://focus.ti.com/lit/er/swra175a/swra175a.pdf. [27] Texas Instruments. , 2008. Disponi- eZ430-RF2480 Demonstration Kit: User's Guide ble en http://focus.ti.com/lit/ug/swru151a/swru151a.pdf. [28] Texas Instruments. , 2009. Disponible en CC2480 Target Board Reference Design 1.4 http://www.ti.com/litv/zip/swru156a. [29] TIOBE Software. . Dis- TIOBE Programming Community Index for December 2010 ponible en http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html. [30] Jorge Carlos Valverde Rebaza. , 2007. Disponible en El Estándar inalámbrico ZigBee http://www.seccperu.org/les/ZigBee.pdf.
