Redes inalámbricas de sensores : sistema integral de monitorización de estructuras metálicas

UNIVERSIDAD POLIT´ ECNICA DE VALENCIA ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA INFORM´ ATICA Redes Inal´ambricas de Sensores: Sistema Integral de monitorizaci´on de estructuras met´alicas Autor:JOSE VICENTE ESCAMILLA LOPEZ Autor:ALBERT ESTEVE GARCIA Director:DR. ALBERTO MIGUEL BONASTRE PINA Codir.:DR. JOSE VICENTE CAPELLA HERN´ ANDEZ Valencia, Diciembre de 2010 Agradecimientos El proyecto que presentamos aqu´ı es tan solo el final de un ciclo que comenz´o hace m´as tiempo del que pudiera parecer. Y durante todo ese tiempo he acumulado tantos conocidos a los que me gustar´ıa y deber´ıa agradecer que espero que no se enfaden si olvido a alguien. Pero creo que el primero de mis agradecimientos debe ir a mi padre, Ram´on. Me consigui´o inculcar muchas cosas, una de ellas el ansia por aprender y poder superarme cada d´ıa. Sin ´el no estar´ıa seguramente donde estoy y a ´el le debo gran parte de mis ´exitos, ahora y siempre. Tambi´en le debo mucho, por supuesto, a mi madre Lola. Ella me ha animado a seguir siempre adelante y me ha ayudado lo indecible para que consiguiera llegar a donde estoy. Le debo m´as de lo que puedo escribir en un p´arrafo as´ı que ni siquiera lo voy a intentar. Por supuesto a mi hermano Victor, que ha sido mi modelo a seguir durante mucho tiempo, y espero que lo siga siendo durante mucho tiempo m´as. A mi novia, Carla, que me ha empujado a seguir adelante incontables veces y ha cre´ıdo en m´ı siempre. Le quiero con toda mi alma y espero que no deje de creer en m´ı nunca. Prometo no fallarte. Por supuesto a mi compa˜nero de proyecto, a Vicente. He pasado m´as horas con ´el en estos ´ultimos tiempos que con ning´un otro, para lo bueno y para lo malo. Durante la carrera, de principio a fin, ha sido mi compa˜nero de estudios, de sue˜nos y de frustaciones. Sin ´el seguramente el camino entero hubiera sido mucho m´as cuesta arriba. Al resto de mis compa˜neros durante la carrera: Salva, Nuria, H´ector, Eduardo. A ellos les debo las partidas de cartas, las fiesta, las siestas entre clases y de vez en cuando, las jornadas de estudio en grupo. De ellos me llevo varios de los mejores recuerdos y compa˜neros que uno se puede encontrar. Y por ´ultimo a mis amigos: Manolo, Edu y Samuel. Por muchos motivos ellos han sido mi v´alvula de escape y me han apoyado en muchas de las etapas de mi vida. Sin ellos seguramente tampoco estar´ıa donde estoy ahora y les debo mucho m´as de lo que les puedo devolver. Albert Esteve ii En primer lugar quiero darle las gracias a mis padres. Ellos me han educado, me han apoyado siempre en todas las decisiones que he tomado en la vida. Sin ellos obviamente no estar´ıa donde estoy. A mis compa˜neros de carrera H´ector, Nuria, Eduardo y Salva. Ellos han sido mis c´omplices de estudio, mis compa˜neros en las horas muertas y mis amigos fuera de las aulas. Sin ellos la carrera sin duda habr´ıa sido mucho menos llevadera. A Raul por echarme una mano con la parte de la electr´onica del proyecto. A mis amigos Samuel, Estibaliz, Natalia, Rafa, David, H´ector, Manuel, Eduardo. Les debo todas las tardes y noches de fiesta y las carcajadas que consegu´ıan hacer que desconectara del estr´es y los problemas. A mis compa˜neros de club de tiro con arco de la UPV: Vicente (todos los del club), Maite, Maria, Api, Cristobal, Mery, Juan Ram´on, Ram´on. Junto al deporte en s´ı han sido mi v´alvula de escape del d´ıa a d´ıa. A mi compa˜nero de proyecto Albert. Gracias a ´el el desarrollo de ´este proyecto ha sido mucho m´as llevadero. Por supuesto una menci´on especial a Ana por su inmenso apoyo. Por estar siempre ah´ı para ayudarme en lo que hiciera falta y para escucharme cuando necesitaba hablar. Sin duda le debo buena parte de lo que soy. Jos´e Vicente Escamilla iii En el apartado t´ecnico ambos tenemos que agradecer a aquellos profesores y personal del GSTF que prest´o su ayuda desinteresadamente en mayor o menos medida y sin los que seguramente el proyecto hubiese sido si cabe m´as costoso. Entre esas personas se encuentran: Pascual P´erez Blasco, Andres Lapuebla, Juan Jos´e Serrano y en general a todos los que se han interesado y ayudado en el transcurso del largo camino que nos ha llevado a la finalizaci´on con ´exito del presente proyecto. Albert Esteve y Jos´e Vicente Escamilla ´ Indice general 1. Introducci´on 1 1.1. Pre´ambulo ............................. 1 1.2. Justificaci´on ............................ 1 1.3. Descripci´on ............................ 2 1.4. Distribuci´on de tareas ...................... 5 2. Fundamentos Te´oricos 7 2.1. Redes Inal´ambricas de Sensores ................. 7 2.1.1. Caracter´ısticas de una red sensora ............ 8 2.1.2. Est´andares y especificaciones .............. 9 2.1.3. Aplicaciones ........................ 12 2.1.4. Tendencias de Procesador ................ 14 2.1.5. Sistemas Operativos ................... 14 2.1.6. Implementaciones ..................... 15 2.1.7. Algoritmos ......................... 15 2.2. Galgas extensiom´etricas ..................... 16 2.2.1. Fundamentos f´ısicos de funcionamiento ......... 16 2.2.2. Efectos adversos ...................... 17 2.2.3. Factor de galga ...................... 18 2.2.4. Elecci´on de la galga extensiom´etrica ........... 19 2.3. Fundamentos del protocolo de comunicaci´on inal´ambrica . . . 23 2.3.1. Formaci´on de la red .................... 24 2.3.2. Funci´on est´andar ..................... 25 2.4. Aplicaci´on puente USB-IGU ................... 27 2.4.1. WebSocket ......................... 30 3. Protocolo de Comunicaci´on Propuesto 43 3.1. Supuestos B´asicos ......................... 43 3.2. Fundamentos ........................... 44 3.2.1. Formato de trama de N´ıvel F´ısico ............ 44 3.2.2. Formato de paquetes del protocolo ........... 46 3.2.3. Desarrollo por fases .................... 52 3.2.4. Formaci´on del grafo .................... 56 3.2.5. C´alculo de los caminos m´ınimos ............. 57 v vi ´ INDICE GENERAL 3.2.6. Establecimiento de la programaci´on de macro-frames . 58 3.2.7. Toma de medidas ..................... 62 3.2.8. Solucionando errores en la red .............. 62 4. Entorno de trabajo 65 4.1. Microcontrolador ......................... 65 4.1.1. CPU y Memoria ..................... 67 4.1.2. Interfaz de depuraci´on .................. 68 4.1.3. Control de Potencia .................... 68 4.1.4. Temporizadores ...................... 70 4.1.5. Radio ........................... 71 4.1.6. USART .......................... 73 4.2. Tarjeta de adaptaci´on de sensores ................ 73 4.3. Entorno IAR Embedded Workbench .............. 74 4.3.1. Interfaz Gr´afica ...................... 75 4.3.2. Depuraci´on ........................ 76 4.3.3. Perfiles de ejecuci´on ................... 78 4.4. SimpliciTI ............................. 81 4.4.1. Componentes modulares ................. 81 4.4.2. Resumen de la arquitectura ............... 83 4.4.3. Estructura del paquete .................. 84 4.5. SmartRF Packet Sniffer ..................... 86 4.5.1. Flujo de datos ....................... 87 4.5.2. Detalles de la aplicaci´on ................. 87 5. Implementaci´on 95 5.1. Tarjeta de adaptaci´on de sensores ................ 95 5.1.1. Galgas extensiom´etricas ................. 95 5.1.2. Puente Wheatstone .................... 95 5.1.3. C´alculo de la variaci´on de resistencia de las galgas extensiom´etricas ....................... 99 5.1.4. C´alculo de la salida del puente ..............102 5.1.5. Amplificador .......................103 5.1.6. CAD ............................109 5.1.7. Tensiones de alimentaci´on ................114 5.2. Protocolo de comunicaci´on de la red de sensores ........116 5.2.1. Implementaci´on de la comunicaci´on en los nodos . . . . 116 5.2.2. Algoritmos representativos ................117 5.2.3. Estrategias de programaci´on ...............119 5.3. Aplicaci´on puente USB-IGU ...................120 5.3.1. Descripci´on del funcionamiento .............120 5.3.2. Comunicaci´on USB-puente ................124 5.3.3. Comunicaci´on puente-IGU ................132 5.4. Interfaz Gr´afica de Usuario ....................135 ´ INDICE GENERAL vii 5.4.1. Conexi´on WebSocket ...................136 5.4.2. Interacci´on con el script PHP ..............138 5.4.3. ´ Ordenes sobre la red de sensores .............139 5.4.4. Gesti´on de los par´ametros de configuraci´on .......140 5.4.5. Listado de nodos .....................141 5.4.6. Posicionamiento de los nodos en el mapa de nodos . . . 143 5.4.7. Cambio de la imagen del mapa de nodos ........144 6. Resultados 147 6.1. Red de sensores ..........................147 6.1.1. Captura del funcionamiento de la Red de Sensores . . . 150 6.2. Tarjeta de adaptaci´on ......................154 6.3. Interfaz gr´afica de usuario ....................156 7. Conclusiones y futuras ampliaciones 165 7.1. Conclusiones ............................165 7.1.1. Red de sensores ......................165 7.1.2. Tarjeta de adaptaci´on de sensores ............166 7.1.3. Aplicaci´on puente y la IGU ...............166 7.2. Futuras ampliaciones .......................167 7.2.1. Red de sensores ......................167 7.2.2. Tarjeta de adaptaci´on de sensores ............168 7.2.3. Aplicaci´on puente USB-IGU ...............169 7.2.4. Interfaz gr´afica de usuario ................169 Ap´endices 171 A. Manual de Usuario 173 A.1. Instalaci´on de los nodos .....................173 A.1.1. Adhesi´on de los sensores a la pieza ...........173 A.1.2. Preparando la BBDD ...................180 A.2. Preparaci´on del terminal base ..................182 A.3. Instalando la interfaz gr´afica ...................182 A.4. Accediendo a la interfaz gr´afica .................184 A.4.1. Elementos de la IGU ...................185 A.4.2. Par´ametros de la red ...................185 A.4.3. Iniciar la red .......................186 A.4.4. Reiniciar la red ......................187 A.4.5. Forzar medici´on bajo demanda .............187 A.4.6. Mapa de nodos ......................187 A.4.7. Cambiar la imagen del mapa de nodos .........189 A.4.8. Recibiendo medidas de la red ..............189 xiv LISTA DE TABLAS Cap´ıtulo 1 Introducci´on 1.1. Pre´ambulo Este proyecto se engloba dentro de la inform´atica dedicada a las Redes Inal´ambricas de Sensores (RIS). Se pretende dise˜nar un sistema integral de monitorizaci´on para estructuras met´alicas que supervisa la deformaci´on que sufren las estructuras met´alicas de una construcci´on. 1.2. Justificaci´on En el sector de la construcci´on llevan a cabo proyectos cada vez de mas envergadura, m´as arriesgados. Las necesidades destinadas a cubrir por ´estas construcciones, la necesidad de reducir el coste de ´esta, o la simple busca de originalidad y/o notoriedad de la construcci´on empuja a los arquitectos a dise˜nar estructuras que muchas veces desaf´ıan los limites de los materiales empleados. Estos factores provocan que en ciertas ocasiones (por errores de c´alculo, factores ambientales, etc´etera) los materiales utilizados en la construcci´on de la estructura superen el l´ımite para el que fueron concebidos y ´estos reaccionen de forma que comprometan la integridad de la construcci´on. Igualmente, en construcciones considerablemente antiguas sucede algo similar. Sin embargo, en ´este caso el factor que pone en peligro la estructura es la propia antig¨ uedad de ´esta. Los materiales con el tiempo ven mermadas sus capacidades debido al desgaste, el ´oxido, la fatiga, etc. Debido a ´esto las construcciones de cierta edad tambi´en son un conjunto de riesgo a tener en cuenta. Dada la potencialmente peligrosa situaci´on de ´estas estructuras, una de las soluciones que suelen tomarse es monitorizar ciertos par´ametros que de1 2CAP´ ITULO 1. INTRODUCCI´ ON finen la consistencia de la estructura. De ´esta forma, en el momento en el que se registren valores anormales, se pueden tomar medidas que eviten da˜nos mayores o incluso p´erdidas personales. Uno de los par´ametros m´as interesantes que reflejan la estabilidad de una estructura es la deformaci´on que ´esta sufre. Una estructura inestable o d´ebil tender´a a deformar m´as de lo debido los materiales con los que est´a fabricada. Por ejemplo, en el caso de un rascacielos, los pilares sobre los que est´a asentado tienden a torcerse por el viento que impacta sobre ´el, inclinando as´ı la totalidad de la estructura, ´esto fen´omeno pone en peligro la integridad estructural del rascacielos cuando ´este llega a un punto de inclinaci´on cr´ıtico que seg´un la climatolog´ıa de la zona donde resida y la altura del mismo (entre otros factores), puede llegar a ocurrir con relativa facilidad. Tal es la problem´atica en ´este tipo de edificios que algunos de los m´as importantes rascacielos (como el Taipei 101, Taiw´an) del mundo incorporan un contrapeso de varios cientos de toneladas en la parte m´as alta de ´estos. ´ Este contrapeso se mueve accionado por cilindros hidr´aulicos en la direcci´on opuesta a la que es empujado el rascacielos. De ´esta forma se evita que el edificio se incline en exceso y los materiales cedan ante la excesiva deformaci´on a la que est´an sometidos. 1.3. Descripci´on El presente proyecto trata sobre la creaci´on de un sistema integral de monitorizaci´on de estructuras met´alicas de construcciones. A pesar de que el sistema est´a orientado a la monitorizaci´on de dichas estructuras, puede ser usado para monitorizar otro tipo de metales sin modificaciones considerables dependiendo de las necesidades de dicha aplicaci´on. Dicho sistema de monitorizaci´on medir´a las deformaciones en distintos puntos de la estructura y mostrar´a los resultados a trav´es de un terminal con el que el usuario podr´a interactuar. El sistema de monitorizaci´on constar´a de una red inal´ambrica de sensores instalados en los puntos en donde sea necesario medir. Dicha red inal´ambrica transmitir´a los datos un ordenador en donde el usuario podr´a visualizarlos e interactuar con la red de sensores. La red de sensores estar´a formada por nodos inal´ambricos modelos NK01 y SUM-USB fabricados por WSNVAL. Los nodos NK01 (en adelante nodo convencional o sensor) son los dispositivos que ser´an utilizados para realizar las mediciones. ´ Estos constan de un microcontrolador compatible con la serie 80511y una etapa de radio que le permite enviar datos por radiofrecuencia. 1Microcontrolador desarrollado por Intel ampliamente extendido en sistemas embebidos 1.3. DESCRIPCI´ ON 3 Dichos nodos no est´an provistos de sensores para medir deformaciones en metales, por lo que se emplear´an sensores externos al nodo con ´este fin. Dichos sensores constar´an de cuatro galgas extensiom´etricas2que ser´an adheridas al metal del cual se quiere obtener la lectura de su deformaci´on. ´ Estas cuatro galgas estar´an conectadas a su vez a un circuito que amplificar´a y adaptar´a la se˜nal para adecuarla a la entrada del microcontrolador. El dise˜no del protocolo de comunicaci´on esta espec´ıficamente desarrollado para la aplicaci´on. El objetivo es que el protocolo permita la comunicaci´on de un n´umero a priori ilimitado de sensores y que se mantenga una base de datos hist´orica de las medidas, los sensores que conforman la red y otra informaci´on relevante y adem´as que todo el proceso se complete de la forma m´as eficiente posible teniendo en cuenta las necesidades propias del supuesto para el que se dise˜na dicho protocolo. El dise˜no se ha realizado teniendo en mente un entorno en el que el tiempo no es una necesidad cr´ıtica y s´ı lo es, sin embargo, el ahorro de energ´ıa y el tiempo de vida de los sensores. Y bajo estos dos objetivos se propuso el protocolo que se describe en este proyecto. Para conseguirlo el protocolo se basa en divisiones de tiempo que se agrupan en macro-frames3. Cada divisi´on o marco supone una comunicaci´on punto a punto entre dos sensores adyacentes. As´ı se descartan las colisiones y se aumenta la eficiencia de las emisiones. Un macro-frame completo implica la recepci´on total o parcial de datos desde los sensores al nodo sumidero. La red inal´ambrica de nodos se conformar´a como una red multisalto con topolog´ıa en ´arbol con enlaces ponderados. Los enlaces se ponderan seg´un el RSSI4para conseguir que las emisiones se produzcan encaminando los paquetes punto a punto y permitiendo emisiones de menor potencia. Se conoce por nodo recolector o sumidero (sink node en ingl´es) al nodo no sensor que act´ua como puerta de enlace entre la red y la estaci´on de monitorizaci´on. El sumidero arbitra la comunicaci´on del resto de nodos, forma los enlaces entre nodos y debe conocer a todos los componentes de la red. Este nodo esta conectado a la red el´ectrica y env´ıa los datos por puerto USB a un ordenador desde el que se monitoriza toda la informaci´on. En el terminal ´estos datos ser´an recogidos por una aplicaci´on dise˜nada ex profeso para ´este fin. Dicha aplicaci´on (en adelante  puente USB-IGU  ) volcar´a los datos en una base de datos para que un interfaz gr´afico haga uso de los mismos. El puente USB-IGU adem´as se encargar´a de transmitir a la red inal´ambrica las ordenes provenientes del IGU5am´en de implementar algunos mecan2Sensor basado en el efecto piezo-resistivo que reacciona ante una deformaci´on 3Agrupaciones de divisiones o marcos temporales 4Received Signal Strength Indicator. Es un par´ametro que caracteriza el nivel de potencia de una se˜nal recibida en redes inal´ambricas. 5Interfaz Gr´afico de Usuario 4CAP´ ITULO 1. INTRODUCCI´ ON ismos de sincronizaci´on con el mismo que se explicaran con mas detalle m´as adelante. El sumidero adem´as carece de las restricciones energ´eticas a las que est´an sujetos el resto de nodos de la red, con lo que podemos aumentar su carga computacional y comunicacional para permitir al resto de nodos ahorrar tiempo de c´omputo. Tenemos pues un protocolo centralizado y basado en divisiones de tiempo en el que los sensores pasar´an la mayor parte del tiempo ociosos y solo utilizar´an unos pocos frames (marcos temporales) para comunicarse. El tiempo que pasan ociosos lo har´an en un estado de ahorro de energ´ıa o sleep-time del que se pueden despertar ellos mismo mediante un temporizador (sleep-timer) o mediante una se˜nal de radio emitida desde el sumidero mediante un circuito de RF externo al microcontrolador que provoca que los nodos se despierten6 (se˜nal conocida como  bocinazo  ). Esto permite aumentar significativamente el tiempo de vida de los sensores y mantener un control de la red a trav´es del nodo sumidero. Figura 1.1: Detalle de un env´ıo a trav´es del nodo sumidero Valga como introducci´on, veamos la descripci´on de los cap´ıtulos del proyecto: en el cap´ıtulo 2 se describir´an los fundamentos te´oricos de las RIS, las galgas y del protocolo, para pasar, en el cap´ıtulo 3 a describir los fundamentos del protocolo con m´as detalle y detenimiento. El cap´ıtulo 4 estar´a dedicado al entorno de trabajo utilizado para el desarrollo del proyecto y las caracter´ısticas que motivaron su utilizaci´on. Los cap´ıtulos 5 y 6 estar´an dedicados a la descripci´on de distintos detalles de la implementaci´on del protocolo y los resultados obtenidos del mismo respectivamente. Por ´ultimo en el cap´ıtulo 7 se indicar´an las conclusiones extra´ıdas y se propondr´an posibles futuras ampliaciones que se pudieran implementar al protocolo. 6El circuito no se ha dise˜nado en el proyecto, pero se propone como ampliaci´on 1.4. DISTRIBUCI´ ON DE TAREAS 5 1.4. Distribuci´on de tareas El proyecto engloba el proceso entero de dise˜no e implementaci´on de la aplicaci´on de redes de sensores presentada. El proceso completo se puede dividir a su vez en varias partes diferenciadas y dependientes entre s´ı que son: adaptaci´on de las galgas extensiom´etricas a la electr´onica de los nodos de WSNVAL, dise˜no e implementaci´on del protocolo de comunicaci´on de la red de sensores, implementaci´on del puente de comunicaci´on del nodo sumidero con la estaci´on base, dise˜no e implementaci´on de la IGU. En lo que a distribuci´on de tareas la de dise˜no e implementaci´on del protocolo de comunicaci´on de la red de sensores recay´o en Albert Esteve, mientras que el resto de partes del proyecto fueron desarrolladas por Jos´e Vicente Escamilla. 6CAP´ ITULO 1. INTRODUCCI´ ON Cap´ıtulo 2 Fundamentos Te´oricos 2.1. Redes Inal´ambricas de Sensores Una Red Inal´ambrica de Sensores (RIS o Wireless Sensor Networks WSN en ingl´es) consiste en sensores aut´onomos espacialmente distribuidos para monitorizar de forma cooperativa condiciones f´ısicas o medioambientales, tales como la temperatura, el sonido, la vibraci´on, presi´on, movimiento, voltaje e incluso ox´ıgeno disuelto. El desarrollo de las RIS fue motivado, como en muchos otros caso, por el inter´es en aplicaciones militares. Hoy en d´ıa, sin embargo, tiene numerosas aplicaciones en ´areas industriales y civiles, como la monitorizaci´on de procesos industriales, monitorizaci´on en ´areas de salud o en entornos dom´esticos (dom´otica), control de tr´afico, etc. Como predecesor de las RIS se tiene la Sound Surveillance System (SOSUS), una red de boyas sumergidas instaladas en los Estados Unidos durante la Guerra Fr´ıa para detectar submarinos usando sensores de sonido. Adem´as de uno o dos sensores, cada nodo en una RIS est´a t´ıpicamente equipado con un trasceptor de radio u otro sistema de transmisi´on inal´ambrico, un peque˜no microcontrolador (en el caso que nos ocupa los nodos funcionan con el 8051), un circuito anal´ogico, y una fuente de energ´ıa, generalmente una bater´ıa. Un nodo sensor puede variar en tama˜no desde el equivalente a una caja de zapatos hasta un grano de ma´ız. El coste es igualmente variable, dependiendo de las capacidades sensoras de los nodos adem´as de su tama˜no. Las limitaciones en tama˜no y precio en nodos sensores corresponden con limitaciones en otro recursos, tales como la energ´ıa, la memoria, la velocidad de computaci´on o el ancho de banda. Las redes de sensores forman t´ıpicamente redes ad-hoc sin infraestructura f´ısica preestablecida ni administraci´on central. As´ı cada nodo soporta algoritmos en los que la informaci´on se encamina mediante saltos punto a punto entre distintos nodos cercanos f´ısicamente hasta la estaci´on base. 7 8CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS Figura 2.1: Esquema de componentes de un nodo sensor t´ıpico Este tipo de redes se caracterizan por su facilidad de despliegue y por ser autoconfigurables, pudiendo actuar indistintamente como emisor o receptor y ofrecer servicios de encaminamiento entre nodos sin visi´on directa, registrando datos de cada uno de los sensores locales. Otra de sus caracter´ısticas es su gesti´on eficiente de la energ´ıa lo que les permite ser altamente aut´onomos y plenamente operativos. La idea es repartir aleatoriamente estos nodos en un territorio grande, en el cual los nodos  observan  hasta que sus recursos energ´eticos se agoten. Actualmente, las redes de sensores es un tema muy activo de investigaci´on en varias universidades, aunque ya empiezan a existir aplicaciones comerciales basadas en este tipo de redes. La red de sensores hasta la fecha m´as grande consisti´o de 800 nodos y fue puesta en servicio el 27 de agosto de 2001 para una duraci´on breve en la universidad de Berkeley con el fin de demostrar la potencia de esa t´ecnica en una presentaci´on. 2.1.1. Caracter´ısticas de una red sensora Las RIS tienen una serie de caracter´ısticas propias, mientras que otras vienen heredadas como caracter´ısticas de las redes ad-hoc: Topolog´ıa Din´amica: en una red de sensores la topolog´ıa es altamente variable y los nodos sensores deben ser capaces de adaptarse a los cambios para seguir comunic´andose. Variabilidad del canal: el canal de radio en el que transmiten los nodos es variable y puede ser objeto de atenuaciones, de svanecimientos o interferencias que resulten en errores en la recepci´on de los datos. No se utiliza infraestructura de red: no es necesaria infraestructura en una RIS ya que los nodos son capaces de actuar tanto como emisores, 2.1. REDES INAL´ AMBRICAS DE SENSORES 9 como receptores o como enrutadores indistintamente. Sin embargo cabe destacar la figura del nodo recolector o sumidero que es el encargado de recoger informaci´on y medidas del resto de nodos en tiempo discreto generalmente. Esta informaci´on es transmitida a un ordenador que ser´a el encargado de transmitir esa informaci´on por redes cableadas o inal´ambricas seg´un el caso. Tolerancia a errores: un nodo sensor en una RIS debe ser capaz de seguir funcionando a´un pese a la existencia de errores en el sistema propio. Comunicaciones multisalto o bradcast: en aplicaciones sensores es com´un la utilizaci´on de protocolos que permitan el multi-hop (v´ease AODV, DSDV, EWMA u otras), aunque tambi´en es com´un encontrarse con protocolos basados en emisiones broadcast. Consumo energ´etico: es un factor altamente sensible en general, como lo es para el caso de estudio en concreto. En general los sensores vienen equipados con un microcontrolador de consumo ultra bajo as´ı como un trasceptor de radio con la misma caracter´ıstica. El consumo es restrictivo incluso con el software, que se debe crear conjugando la misma caracter´ıstica. Limitaciones hardware: debido a la limitaci´on del consumo energ´etico, tenemos como resultado un hardware sencillo que limita la capacidad de proceso del nodo. Costes de producci´on: puesto que las RIS suelen estar pensadas para ser compuestas por gran n´umero de nodos, ´estos, una vez definida su aplicaci´on, pueden ser baratos de producir si se hacen en grandes cantidades. 2.1.2. Est´andares y especificaciones En las aplicaciones RIS con frecuencia tres a˜nos de duraci´on de las bater´ıas es un requisito de las mismas. Por este motivo hoy en d´ıa varios de los sistemas RIS est´an basados en protocolos ZigBee o IEEE 802.15.4. Pero hay muchas estandarizaciones que siguen en desarrollo para RIS. Mientras IEEE se centra en las capas f´ısica y de acceso al medio, la IETF (Internet Engineering Task Force) trabaja a partir de la capa 3 y superiores. Adem´as de las mentadas, otras iniciativas como ISA (International Society for Automation) y la fundaci´on HART proveen soluciones verticales que incluyen todas las capas de protocolos. Por ´ultimo encontramos tambi´en cierto n´umero de especificaciones o mecanismos no est´andares y propietarios. 16 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS RIS el recurso m´as escaso es la energ´ıa, siendo una de las operaciones que consumen m´as energ´ıa las de transmisi´on de datos y la escucha ociosa. Por esto, la investigaci´on de algoritmos en las RIS se centran en su mayor´ıa en el estudio y dise˜no de algoritmos dedicados al ahorro de energ´ıa, disminuyendo la cantidad de datos siendo transmitidos (usando t´ecnicas como la agregaci´on de datos), cambiando la potencia de transmisi´on de los nodos sensores o apag´andolos preservando conectividad y cobertura. Otra caracter´ıstica a tener en cuenta es que debido al rango de transmisi´on de radio limitado y el crecimiento polinomial en el coste energ´etico de la transmisi´on de radio respecto a la distancia de transmisi´on, es improbable que todos los nodos alcancen la estaci´on base, as´ı que habitualmente la transmisi´on de datos salta de nodo a nodo hasta el sumidero. 2.2. Galgas extensiom´etricas Para medir las deformaciones que sufre el metal se van a usar unos sensores llamados galgas extensiom´etricas. ´ Estos sensores est´an formados por una lamina de un material no conductor con ciertas propiedades el´asticas sobre el que se adhiere una pista de una aleaci´on conductora con un patr´on determinado en funci´on del tipo de tensiones a los que va a estar sometido el material. ´ Esta pista conductora suele dibujarse siguiendo un patr´on zigzag formando un conjunto de lineas largas y paralelas de forma que la mayor parte del conductor est´a distribuido paralelamente en una ´unica direcci´on tal y como se muestra en la figura 2.3. Figura 2.3: Detalle de una galga extensiom´etrica 2.2.1. Fundamentos f´ısicos de funcionamiento La galga extensiom´etrica basa su funcionamiento en el efecto piezo-resistivo1 sobre el material conductor del que est´a formado la misma. Al aplicar una fuerza de tracci´on de forma longitudinal sobre la galga (de forma paralela a 1Cambio en la resistencia de un material al aplicarle un estr´es mec´anico. 2.2. GALGAS EXTENSIOM´ ETRICAS 17 la las pistas de mayor longitud), el material conductor se deformar´a aumentando significativamente la longitud del mismo. ´ Este aumento de longitud debido a la tracci´on se traduce adem´as en una disminuci´on de secci´on en el mismo debido al efecto de Poisson. Tanto el factor de longitud como el de la secci´on del conductor determinan la resistencia de un material conductor como se deduce de la ecuaci´on: R=P∗L S Dado que la resistencia es directamente proporcional a la longitud L del conductor e inversamente proporcional a la secci´on S del mismo y siendo P la constante de resistividad del material, resulta ahora evidente que al someter un conductor a tracci´on (aumenta su longitud y disminuye su secci´on) la resistencia el´ectrica del mismo aumentar´a proporcionalmente. Figura 2.4: Galga sometida a tracci´on El efecto contrario sucede cuando se somete el conductor a compresi´on. Un conductor sometido a compresi´on disminuye su longitud L y aumenta su secci´on S, por lo que, como se deduce de la ecuaci´on anterior, su resistencia disminuir´a de forma proporcional. Gracias a ´este efecto piezo-resistivo es posible medir la deformaci´on que sufre un material adhiriendo cuidadosamente y de forma precisa la galga extensiom´etrica al material del cual se desea medir su deformaci´on. 2.2.2. Efectos adversos Dado que la mayor parte del conductor se distribuye en lineas paralelas la mayor variaci´on de resistencia se registra cuando la deformaci´on (ya sea tracci´on o compresi´on) se produce en direcci´on paralela a las mismas. Sin embargo, al aplicar una fuerza a ´estas, los tramos de conductor que conforman 18 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS Figura 2.5: Galga sometida a compresi´on los cambios de sentido de las pistas est´an dispuestos de forma perpendicular a la fuerza de deformaci´on, por lo que f´ısicamente experimentan el efecto contrario a las lineas paralelas (Figuras 2.6 y 2.7). ´ Esto, a su vez, produce el efecto contrario en la resistencia al producido en las lineas paralelas. No obstante, dada la gran anchura y la poca longitud de ´estos tramos en comparaci´on con los tramos paralelos, la variaci´on de resistencia en ´estos tramos minoritarios de conductor se considera despreciable. Figura 2.6: Galga sometida a tracci´on Figura 2.7: Galga sometida a compresi´on ´ Este tipo de galgas extensiom´etricas est´an dise˜nadas para cuantificar el elongamiento producido en sentido paralelo a las pistas de conductor. En el caso de que el elongamiento se produzca de forma perpendicular a ´estas (Figura 6), las galgas experimentan una variaci´on de resistencia. Sin embargo, ´este caso no ser´a contemplado en nuestro sistema ya que ´este tipo de sensores no est´an dise˜nados para medir deformaciones en direcci´on perpendicular a ´estos y estas fuerzas de deformaci´on no deber´ıan registrarse si se ha llevado a cabo una correcta instalaci´on de los mismos. 2.2.3. Factor de galga Como se ha explicado anteriormente, las galgas extensiom´etrica var´ıan su resistencia el´ectrica en funci´on de la deformaci´on que sufren. ´ Esta variaci´on 2.2. GALGAS EXTENSIOM´ ETRICAS 19 Figura 2.8: Galga sometida a tracci´on de resistencia proporcional a la deformaci´on se cuantifica mediante el factor de galga y se define con la siguiente f´ormula: K=dR/R dL/L El factor de galga (K) es una constante definida por diversos par´ametros referentes a la fabricaci´on del conductor. Es por ello que ´esta constante viene dada por el fabricante para cada tipo de galga, e incluso ´esta suele venir especificada en el embalaje al adquirirlas ya que suele ser calculada por el fabricante en cada lote que ´este pone a la venta con el fin de proporcionar al usuario la constante K exacta del lote que ha adquirido. 2.2.4. Elecci´on de la galga extensiom´etrica A la hora de elegir una galga extensiom´etrica que se ajuste a nuestras necesidades tenemos que tener en cuenta diversos factores que afectar´an a la precisi´on y vida ´util de la misma. Diferentes factores concernientes al entorno en el que se encontrar´a la galga y al tipo de estr´es al que estar´a sometida la misma condicionar´a el tipo de conductor a usar as´ı como la base sobre la que deber´a estar impreso. Con ´este prop´osito los fabricantes ofrecen una gran variedad de tipos de galgas, cada una orientada a unas necesidades concretas de temperaturas, precisi´on y tipo de estr´es. B´asicamente existen dos grandes conjuntos de galgas extensiom´etricas: las met´alicas y las semiconductoras. Fundamentalmente la gran diferencia entre las galgas met´alicas y las semiconductoras es el factor de galga. Mientras las galgas met´alicas ofrecen factores de galga que oscilan entre 1,5 y 3.2, las galgas semiconductoras presentan factores de galga entre 50 y 200. Las galgas extensiom´etricas semiconductoras tienen pues una sensibilidad notablemente mayor, lo cual las hace atractivas ya que simplifican la electr´onica de amplificaci´on. Sin embargo ´estas galgas sufren ciertos problemas que las hacen inadecuadas para algunas aplicaciones: alta sensibilidad a la temperatura, muy fr´agiles y dif´ıcil instalaci´on. Es por ello que para nuestra aplicaci´on 20 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS hemos elegido galgas de tipo met´alicas ya que son mucho mas inmunes a la temperatura y su instalaci´on no es tan cr´ıtica. Antes de valorar distintas caracter´ısticas de las galgas extensiom´etrica con el fin de acotarlas a nuestras necesidades, es conveniente repasar algunos de los par´ametros f´ısicos de ´estas con la ayuda de la siguiente figura: Figura 2.9: Detalle de las partes de una galga extensiom´etrica Tipo de conductor El tipo de conductor de la galga extensiom´etrica va a determinar el factor de galga, la precisi´on, la resistencia a la fatiga y la temperatura de trabajo entre otros par´ametros. A continuaci´on se muestra un listado de las caracter´ısticas m´as importantes de cada material disponible. Constant´an2 Buen factor de galga Relativamente insensible a las variaciones de temperatura Buena resistencia a la fatiga Alta capacidad de deformaci´on (5 %) Auto-compensado de temperatura Constant´an templado Mismas caracter´ısticas que el Constant´an a excepci´on de: Muy alta capacidad de deformaci´on (>20 %) Baja resistencia a la fatiga 2Aleaci´on formada por un 55 % de cobre y un 45 % de n´ıquel 2.2. GALGAS EXTENSIOM´ ETRICAS 21 Aleaci´on Isoel´astica Muy buena resistencia a la fatiga Alto factor de galga (3.2) No adecuado para deformaciones est´aticas No lineal Aleaci´on Karma Buena resistencia a la fatiga Excelente estabilidad Id´oneo para deformaciones est´aticas Rangos de temperatura: R´egimen normal: -269oC a 260oC R´egimen puntual: hasta 400oC Auto-compensado de temperatura (m´as preciso que el Constant´an) Nuestra aplicaci´on no requiere grandes exigencias de temperatura, y las deformaciones van a ser est´aticas, no muy pronunciadas y durante largos periodos de tiempo. Adem´as, se requiere que la galga sea lo m´as lineal posible y tenga cierta compensaci´on de temperatura. Por ´esta raz´on optaremos por el Constant´an como conductor ya que ofrece una combinaci´on de caracter´ısticas ´optimas para nuestra aplicaci´on. Tipo de base El tipo de base que se escoja para la galga extensiom´etrica condicionar´a, al igual que el tipo de conductor, el rango de temperatura que soportar´a la misma, la m´axima elongaci´on del sensor, as´ı como la precisi´on de la medida que nos proporcione el mismo. Fundamentalmente tenemos a nuestra disposici´on dos tipos de base: poliamida, fibra de vidrio reforzada y epoxy-fen´olico. A continuaci´on se muestra un listado de las caracter´ısticas m´as importantes de cada tipo de base: Poliamida Rango de temperatura de -195oC a 175oC Ideal para estr´es din´amico y est´atico Permite elongaciones <20 % 22 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS Fibra de vidrio reforzada y epoxy-fen´olico Rango de temperatura: R´egimen normal: -269oC a 290oC R´egimen puntual: hasta 400oC Permite estr´es din´amico y est´atico Permite elongaciones de 1 % a 2 % Valor de la resistencia Cada modelo de galga extensiom´etrica est´a disponible en distintos valores de resistencia nominal. ´ Esta resistencia nominal es la que sufrir´a las variaciones en su valor en funci´on de la elongaci´on producida por las fuerzas de tracci´on y compresi´on a las que se va a ver sometida. La elecci´on de ´este valor representa un punto importante en nuestro proceso de elecci´on de la galga id´onea para nuestra aplicaci´on ya que cuanto mayor sea el valor de la resistencia mayor ser´a la variaci´on de la misma en valor absoluto para una misma elongaci´on. Adem´as, un mayor valor de resistencia disminuye el calor disipado por la galga a causa del voltaje aplicado a la misma. Longitud de la galga La longitud de la galga es una caracter´ıstica muy importante en tanto en cuanto puede condicionar seriamente la precisi´on de la medida que realice. Los materiales sometidos a una fuerte deformaci´on tienden a concentrar la m´axima deformaci´on en regiones muy concentradas creando un alto gradiente de deformaci´on en la zona sometida a estr´es. Las galga extensiom´etricas tienden a promediar la deformaci´on que sufre la regi´on del material cubierta por la zona sensible de la galga (la rejilla). Dado que el promedio de una deformaci´on no uniforme siempre ser´a menor que la deformaci´on m´axima, una galga que sea m´as grande que la regi´on sometida a la m´axima deformaci´on indicar´a una medida inferior a la deformaci´on m´axima que est´a sufriendo el material, lo cual ser´ıa err´oneo. Sin embargo, escoger galgas de menos de 3mm implica ciertas problem´aticas ya que ´estas galgas permiten una menor elongaci´on, son inestables para deformaciones est´aticas, gozan de menor vida ´util ante deformaciones alternadas c´ıclicas y disipan peor el calor. Para nuestra aplicaci´on necesitaremos una galga estable y precisa para deformaciones est´aticas, no requeriremos que la galga soporte altas temperaturas ya que supuestamente estar´an instaladas en entornos a temperatura 2.3. FUNDAMENTOS DEL PROTOCOLO DE COMUNICACI´ ON INAL´ AMBRICA 23 Figura 2.10: Gr´afica de la deformaci´on de galga a lo largo del material ambiente y dado que las piezas ser´an relativamente voluminosas (vigas, pilares, etc), la regi´on de deformaci´on m´axima ser´a relativamente amplia, por lo que no podremos permitirnos galgas de un tama˜no medio-alto ganando as´ı estabilidad en las medidas entre otras ventajas a˜nadidas. Adem´as se valorar´a el factor de galga para simplificar en la medida de lo posible la electr´onica a˜nadida. Teniendo en cuenta todas las necesidades y las caracter´ısticas de cada tipo de galga vamos a decantarnos por una galga extensiom´etrica met´alica de Constant´an con base de Poliamida de 6.35mm de larga y 350 Ohmios ya que es la que mejor se ajusta a nuestras necesidades. 2.3. Fundamentos del protocolo de comunicaci´on inal´ambrica El protocolo de comunicaci´on dise˜nado para la interacci´on de los nodos hereda multitud de conceptos e ideas de las RIS. Pero se busca, a su vez, introducir cierto grado de innovaci´on a la idea de red de sensores partiendo de los mismos principios. Se pretende pues darle una vuelta de tuerca m´as al objetivo de ahorro de energ´ıa combin´andolo con la idea de un protocolo basado en divisiones de tiempo. Uno de los recursos m´as importantes de las RIS en general y de la aplicaci´on para la que esta dise˜nado el protocolo en particular es la energ´ıa. En este caso, adem´as, debido a la dificultad a˜nadida al sustituir alguno de los sensores, alargar la vida ´util de cada nodo es una de las metas m´as vitales. 24 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS Es f´acil darse cuenta de que las etapas de radio son una de las operaciones que m´as coste energ´etico suponen para un nodo. De este modo el protocolo de comunicaci´on ejecuta varias estrategias de ahorro energ´etico que lo fundamentan. El protocolo esta basado en conjuntos de divisiones o marcos de tiempo cuya finalidad es hacer llegar las lecturas de los sensores de la red a la estaci´on base a trav´es del nodo sumidero. En cada ranura temporal se utiliza un enlace que une virtualmente a dos nodos sensores y se pretende que tan solo dichos sensores participen en la comunicaci´on durante dicha ranura temporal. De este modo se eliminan las colisiones y se evitan reenv´ıos innecesarios. Adem´as los enlaces que se utilizan vienen determinados por la programaci´on enviada por el nodo sumidero, que debe utilizar para ello un grafo ponderado con rutas de caminos m´ınimos que una cada sensor en la red. El grafo se ponderar´a seg´un la intensidad (RSSI) con la que los nodos perciben a los sensores que le rodean. As´ı las comunicaciones siempre se realizan al nodo que requiera menor consumo energ´etico o lo que es lo mismo, el enlace del grafo de menor coste. Es por esto que la formaci´on del grafo, que es lo mismo que hablar del establecimiento de los enlaces de la red y el censo de todos los nodos que la componen es algo tan vital. Pero tan importante como la formaci´on de la red es el mantenerla actualizada para evitar consumos desiguales de los nodos que la componen o para reencaminar los paquetes en caso de que un nodo falle. Por esto en el env´ıo de las mediciones incluye, adem´as del nivel de intensidad del enlace el nivel de bater´ıa, siempre que alguno de estos valores var´ıe significativamente superando un umbral configurable. Tener el grafo y los caminos m´ınimos actualizados ante cambios en el mismo permite que el desgaste de la red sea uniforme. Adem´as se incluye la capacidad de poder recuperar parte de la red reencaminando sus mensajes a otros nodos del grafo y recalculando los caminos m´ınimos despu´es de haber eliminado el enlace que produjo el fallo. 2.3.1. Formaci´on de la red La formaci´on de la red es una etapa fundamental, ya que determina los enlaces de la red y el funcionamiento del protocolo en su totalidad. La formaci´on de la red debe por tanto ser fiable y es, de hecho, definitiva: si se forma mal la red est´a destinada a funcionar mal. El objetivo es conseguir que se registren todos los enlaces, que se env´ıe toda la informaci´on de los mismos al sumidero y que el nodo sumidero forme el grafo con toda la informaci´on en el menor tiempo posible. En este periodo de formaci´on tambi´en se siguen ciertos protocolos de 2.3. FUNDAMENTOS DEL PROTOCOLO DE COMUNICACI´ ON INAL´ AMBRICA 25 ahorro de energ´ıa. Durante esta fase el nodo sumidero no conoce a ning´un nodo sensor, por lo tanto no puede arbitrar las comunicaciones. Se arbitran por s´ı mismas para conseguir el mismo objetivo que se persigue durante todo el protocolo, evitar reenv´ıos innecesarios y el ahorro del uso de etapas de radiofrecuencia. La etapa consiste en una serie de env´ıos por difusi´on de un paquete de descubrimiento que genera respuestas en los nodos circundantes. ´ Esta emisi´on se genera inicialmente en el nodo sumidero para posteriormente ser enviada ordenadamente por todos los nodos que formar´an la red. Cuando un nodo recibe respuestas anotan las direcciones que reciben de ellas en tablas que env´ıan al sumidero junto con los niveles de intensidad con las que los perciben y su propio nivel de bater´ıa. Los env´ıos se generan desde el sumidero y se alejan progresivamente como una ola hasta cubrir todos los nodos de la red. Cuando esto suceda el sumidero poseer´a todas las tablas con nodos e intensidades de se˜nal de recepci´on para crear el grafo ponderado y posteriormente calcular los caminos m´ınimos sobre ´el. Otra de las caracter´ısticas que permiten un ahorro energ´etico por parte de los nodos sensores es la regulaci´on del nivel de emisi´on a bajos niveles de potencia. Esto hace que las emisiones de los nodos sensores no alcancen al nodo sumidero, lo que obliga a encaminar los mensajes de los nodos sensores al nodo sumidero durante esta fase. Sin embargo la topolog´ıa entera de la red esta destinada a que las emisiones atraviesen distintos nodos para amortizar el coste de una emisi´on entre distintos nodos sensores. En la fase de formaci´on de la red, que el ´arbol no esta a´un formado es el propio sumidero el que le debe indicar al nodo sensor qu´e ruta debe seguir para enviar las tablas de intensidades y que el sumidero pueda registrar sus enlaces. 2.3.2. Funci´on est´andar Esta fase engloba todo lo dem´as. Depende estrechamente de las estructuras de datos creadas y de su correcta actualizaci´on para que su funcionamiento sea fiable. En esta fase se realizan las lecturas de los sensores de los nodos y se env´ıan las mediciones tomadas al nodo sumidero para que las reciba la estaci´on de monitorizaci´on correspondiente. Para ello hace uso de los macro-frames para dividir los env´ıos en espacios de tiempo a fin de evitar las colisiones. Cada macro-frame empieza con un  bocinazo  . Los env´ıos son programados por el nodo sumidero, ya que es quien posee el ´arbol de caminos m´ınimos. Se producen desde las hojas al sumidero para que se acumulen las medidas 32 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS momento en el que el cliente recibe las cabeceras por parte del servidor y comprueba su v´alidez la conexi´on queda establecida y ambos pueden enviarse mutuamente flujos de datos de forma bidireccional. En la figura 2.12 se muestra un diagrama que muestra de forma simple ´este proceso. Figura 2.12: Diagrama de una comunicaci´on WebSocket Antes de pasar a describir el protocolo WebSocket cabe aclarar que la aplicaci´on puente implementa la versi´on 76 del borrador de RFC correspondiente a WebSocket del 7 de Noviembre de 2010. ´ Esta especificaci´on del protoclo WebSocket ofrece distintas posibilidades de conexi´on, sin embargo nuestro servidor WebSocket no implementa todas las posibilidades dado que no son de utilidad para nuestra aplicaci´on. Por ello en el presente texto tan s´olo explicaremos las funcionalidades implementadas en nuestro servidor. ´ Estas funcionalidades cumplen con la especificaci´on WebSocket a pesar de que los mecanismos que no son de utilidad de la especificaci´on no est´an contemplados. WebSocket ofrece dos tipos de conexi´on, la conexi´on segura y la no segura. Nuestro servidor tan s´olo implementa el tipo de conexi´on segura, por lo que si el cliente intenta conectar en modo no seguro la negociaci´on de la conexi´on no tendr´a ´exito y la conexi´on ser´a abortada. Por otro lado WebSocket en el momento de transmitir los datos soporta dos modos de transmisi´on: ASCII y binario. La aplicaci´on puente tan s´olo soporta el modo ASCII por lo que 2.4. APLICACI´ ON PUENTE USB-IGU 33 si un cliente intenta enviar datos en modo binario el comportamiento de la aplicaci´on puente puede ser imprevisible. En la versi´on actual del borrador de RFC citada ´antes se advierte que el modo binario actualmente no se puede usar, por lo que a dia de hoy es innecesario implementar dicha funcionalidad. Hay que destacar que WebSocket actualmente es un borrador por lo que todavia se est´an realizando cambios en la especificaci´on del protocolo y no todos los navegadores implementan la misma versi´on del borrador de WebSocket y algunos ni siquiera lo implementan en absoluto. Realizadas las pertinentes aclaraciones pasaremos a explicar el proceso de conexi´on, transmisi´on y desconexi´on de una conexi´on WebSocket teniendo en cuenta las restricciones de la implementaci´on. Protocolo del lado del cliente Establecimiento de conexi´on En primer lugar el cliente establece una conexi´on con el servidor WebSocket. Cuando el servidor acepta la petici´on de conexi´on TCP el cliente env´ıa env´ıa las cabeceras. ´ Estas cabeceras se transmiten como texto plano en formato UTF-8 de forma muy similar a como lo hace HTTP. Las cabeceras se dividen en lineas separadas por los caracteres CR (0x0D) LF (0x0A) correspondiendo cada una a un campo de las cabeceras de la petici´on de conexi´on. Cabe destacar que la aplicaci´on puente tan s´olo reconoce las cabeceras obligatorias de la especificaci´on WebSocket, por lo que tan s´olo se describir´an dichas cabeceras o campos. Cabeceras enviadas por el cliente La primera cabecera o campo siempre tiene el formato de una petici´on GET HTTP contra el servidor. Ejemplo: GET / HTTP/1.1 El resto de cabeceras que le siguen pueden tener un orden aleatorio. Por lo que el servidor no puede asumir un orden concreto a la hora de procesarlas. Dichas cabeceras se describen a continuaci´on. ´ Estas cabeceras tendr´an un formato clave-valor separando la clave del valor con los caracteres 0x3A (:) 0x00 (espacio). Cada par clave-valor terminar´a con 0x0D 0x0A (CR LF). La cabecera Host contiene el nombre y puerto del servidor al que va dirigida la petici´on de conexi´on. ´ Este campo se usa para evitar el ataque de 34 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS DNS Rebinding5. Ejemplo: Host: localhost:9321 La cabecera Origin contiene la URL del cliente que solicit´o la conexi´on. ´ Este campo es usado para evitar ataques de origen cruzado no autorizado. Ejemplo: Origin: http://localhost Las cabeceras Upgrade yConnection son cabeceras propias de HTML. Dado que WebSocket es un protocolo pensado para que sea implementado por servidores HTTP se incluyen ´estas cabeceras con el fin de que las peticiones WebSocket sean compatibles con HTTP y sean entendidas por el servidor HTTP adem´as de identificar la petici´on como una petici´on de conexi´on WebSocket. ´ Estas cabeceras siempre tienen el mismo contenido. Ejemplo: Upgrade: WebSocket Connection: Upgrade Las cabeceras anteriormente descritas son las cabeceras obligatorias que debe enviar el cliente WebSocket para ajustarse a la especificaci´on WebSocket. Sin embargo, como se explic´o anteriormente WebSocket contempla dos tipos de conexi´on: segura y no segura. Si se desea establecer una conexi´on no segura ser´ıa suficiente con enviar las cabeceras descritas hasta ahora. No obstante, en nuestra aplicaci´on haremos uso del modo de conexi´on seguro. ´ Este modo exige enviar tres campos adicionales que detallaremos a continuaci´on. Los campos Sec-WebSocket-Key1 ySec-WebSocket-Key2 contienen cada uno un entero aleatorio generado conforme al algoritmo que se describe a continuaci´on. Generaci´on de claves desafio-respuesta de Secure WebSocket En primer lugar generamos dos enteros aleatorios no mayores a 4,294,967,295 a los que llamaremos max1 ymax2 respectivamente. Ejemplo: 858,993,459 y 477,218,588 Generamos un entero aleatorio comprendido entre 0 y max1 al que llamaremos num1. Ejemplo: 777,007,543 5Es un ataque basado en DNS de c´odigo embebido en p´aginas web aprovech´andose de la pol´ıtica del mismo origen de los navegadores. 2.4. APLICACI´ ON PUENTE USB-IGU 35 Generamos otro entero aleatorio comprendido entre 0 y max2 al que llamaremos num2. Ejemplo: 114,997,259 Luego generamos otro par de enteros aleatorios comprendidos entre 1 y 12 ambos inclusive a los que llamaremos spc1 yspc2. Ejemplo: 5 y 9 Multiplicamos num1 y lo multiplicamos por spc1. Al resultado lo llamaremos producto1. En nuestro ejemplo obtendremos 3,885,037,715. Multiplicamos num2 y lo multiplicamos por spc2. Al resultado lo llamaremos producto2. En nuestro ejemplo obtendremos 1,034,975,331. Convertimos los enteros num1 ynum2 en sendas cadenas de caracteres que contengan dichos n´umeros expresados con los caracteres UTF-8 desde el 0x0x30 al 0x39. En nuestro ejemplo obtendr´ıamos ”3885037715 2 ”1034975331 2 los llamaremos clave1 yclave2 respectivamente. Insertamos en la clave1 un n´umero aleatorio comprendido entre 1 y 12 de caracteres UTF-8 contenidos en los rangos 0x21-0x2F y 0x3A-0x7E en posiciones aleatorias de clave1. Obtenemos:  P388O503D&ul7{K %gX( %715  Insertamos en la clave2 otro n´umero aleatorio comprendido entre 1 y 12 de caracteres UTF-8 contenidos en los rangos 0x21-0x2F y 0x3A-0x7E en posiciones aleatorias de clave2. Obtenemos:  1N?|kUT0or3o4I97N5-S3O31  Insertamos spc1 espacios en posiciones aleatorias de clave1. Obtendremos:  P388 O503D&ul7 {K %gX( %7 15  Insertamos spc2 espacios en posiciones aleatorias de clave2. Obtendremos:  1 N ?|k UT0or 3o 4 I97N 5-S3O 31  clave1 yclave2 ser´an las claves que se enviar´an en los campos SecWebSocket-Key1 ySec-WebSocket-Key2 respectivamente. Seguidamente a ´estas cabeceras se insertar´a una linea en blanco a˜nadiendo los caracteres 0x0D y 0x0A, y una tercera clave que no tendr´a nombre de campo. Es decir, la clave ocupar´a la linea entera. ´ Esta 36 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS clave estar´a formada por 8 bytes aleatorios (codificados en orden BigEndian6). ´ Esta clave no terminar´a con 0x0D y 0x0A como el resto de cabeceras.Por ejemplo: 0x47 0x30 0x22 0x2D 0x5A 0x3F 0x47 0x58 Y con ´esto acabar´ıan las cabeceras adicionales que el cliente enviar´a en el caso de que desee establecer una conexi´on en modo seguro de WebSocket. Al enviar al servidor el paquete con la petici´on de conexi´on el servidor responder´a a la petici´on con otro paquete con sus cabeceras. Si todo ´esta correcto en el paquete de respuesta del servidor, el proceso de negociaci´on de la conexi´on se da por finalizada. En ´este punto tanto el cliente como el servidor ya estar´an en posici´on de enviar datos a trav´es de la conexi´on. Transmisi´on de datos El protocolo de transmisi´on de datos mediante una conexi´on WebSocket es muy simple. Los datos que se deseen enviar deben ir precedidos por el valor 0x00 y deben finalizar con 0xFF. Entre ´estos dos valores deben ir los valores de los caracteres codificados en UTF-8. Cierre de conexi´on Si el cliente desea cerrar la conexi´on enviar´a los caracteres 0xFF 0x00. El servidor responder´a 0xFF confirmando la desconexi´on. Protocolo del lado del servidor El servidor siempre estar´a escuchando el puerto correspondiente a WebSocket. Cuando el servidor reciba una conexi´on en el puerto WebSocket recibir´a autom´aticamente las cabeceras enviadas por el cliente que pretende establecer una conexi´on WebSocket. Establecimiento de conexi´on Al recibir las cabeceras del cliente el servidor deber´a procesarlas y devolver otro conjunto de cabeceras, algunas de las cuales depender´an de las cabeceras recibidas por parte del cliente. El conjunto de cabeceras de respuesta del servidor tiene exactamente el mismo formato que las enviadas por el cliente, s´olo que el servidor enviar´a 6El orden Big-Endian establece el orden de los pesos de bits de forma que el bit m´as significativo de cada byte es el que est´a situado m´as a la derecha 2.4. APLICACI´ ON PUENTE USB-IGU 37 otras cabeceras distintas a las enviadas por el cliente. Al igual que sucede con el cliente todas las cabeceras estar´an separadas por los caracteres 0x0D 0x0A (CR LF). La primera cabecera ser´a la respuesta a la petici´on del cliente. Estar´a formada siempre por la cadena de caracteres  HTTP/1.1 101 WebSocket Protocol Handshake  terminada con 0x0D 0x0A. El resto de cabeceras ser´an una serie de pares clave-valor separando la clave del valor con los caracteres 0x3A (:) 0x20 (espacio). Cada cabecera terminar´a con 0x0D 0x0A (CR LF). A su vez se deber´an a˜nadir un par de caracteres 0x0D 0x0A adicionales para delimitar el final de la lista de cabeceras y el comienzo de una cadena de 16 bytes que ser´an generados en funci´on de los valores de los campos Sec-WebSocket-Key1,Sec-WebSocketKey2 y los ´ultimos 8 bytes aleatorios enviados por el cliente en el paquete de negociaci´on de la conexi´on. El orden de ´estas cabeceras debe ser aleatorio. Definiremos host como el valor obtenido de la cabecera Host enviada por el cliente. Si nuestro servidor no implementa VirtualHosts7´este campo puede ser fijo y se corresponde con la URL del servidor WebSocket. Enviamos la cabecera Upgrade cuyo contenido debe ser WebSocket. Enviamos la cabecera Connection cuyo contenido debe ser Upgrade Definimos wsURL como la concatenaci´on de  wss://  con host. Si nuestro servidor implementara la conexi´on no segura se contemplaria la posibilidad de concatenar  ws://  en lugar de  wss://  . Adem´as, si nuestro servidor soportara VirtualHosts habr´ıa que tener en cuenta que despu´es de host deberiamos concatenar el nombre del recurso proporcionado en la primera cabecera de la petici´on del cliente (el contenido existente entre el segundo y tercer caracter 0x20). Sin embargo, dado que no es nuestro caso podemos permitirnos ´esta simplificaci´on de la cabecera. Enviamos la cabecera Sec-WebSocket-Location con wsURL como valor. Definimos origen como el valor contenido en la cabecera Origin enviada en la petici´on del cliente. Enviamos la cabecera Sec-WebSocket-Origin con origen como valor. Finalmente enviamos los caracteres 0x0D 0x0A para marcar el fin del conjunto de cabeceras. No obstante, dado que estamos manejando una conexi´on WebSocket en modo seguro debemos calcular una cadena de 16 bytes en base a ciertos datos contenidos en la petici´on del cliente y devolver ´estos 16 bytes en la respuesta a la petici´on. ´ Estos 16 bytes se concatenan justo despu´es de los dos ´ultimos 7Virtual hosting es un mecanismo para hospedar distintos nombres de dominio en un servidor HTTP usando una sola IP 38 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS caracteres 0x0D 0x0A. C´alculo de la soluci´on al desafio-respuesta Definimos clave1 como el contenido del campo Sec-WebSocket-Key1 enviado por el cliente. Definimos clave2 como el contenido del campo Sec-WebSocket-Key2 enviado por el cliente. Definimos numerosClave1 como los caracteres comprendidos entre 0x30 y 0x39 que contiene clave1 ordenados por orden de aparici´on. Ejemplo: Sec-WebSocket-Key1: 3e6b263 4 17 80 →3,626,341,780 Definimos numerosClave2 como los caracteres comprendidos entre 0x30 y 0x39 que contiene clave2 ordenados por orden de aparici´on. Ejemplo: Sec-WebSocket-Key2: 17 9 G‘ZD9 2 2b 7X 3 /r90 4 17 80 →1,799,227,390 Definimos clave3 como la cadena de 8 bytes aleatorios enviada por el cliente. ´ Esta cadena est´a formada por los 8 bytes siguientes a la ´unica aparici´on de los caracteres 0x0D 0x0A 0x0D 0x0A de forma consecutiva. Ejemplo: Cabeceras enviadas por el cliente: GET / HTTP/1.1 Connection: Upgrade Host: example.com Upgrade: WebSocket Sec-WebSocket-Key1: 3e6b263 4 17 80 Origin: http://example.com Sec-WebSocket-Key2: 17 9 G‘ZD9 2 2b 7X 3 /r90 WjN}|M(6 clave3 = WjN}|M(6 Definimos spc1 como el n´umero de caracteres 0x20 que aparecen en clave1. En nuestro ejemplo ´este valor ser´ıa 4. Definimos spc2 como el n´umero de caracteres 0x20 que aparecen en clave2. En nuestro ejemplo ´este valor ser´ıa 10. Definimos como parte1 el resultado de dividir numerosClave1 entre spc1. En el ejemplo el resultado ser´ıa 906,585,445. 2.4. APLICACI´ ON PUENTE USB-IGU 39 Definimos como parte2 el resultado de dividir numerosClave2 entre spc2. En el ejemplo el resultado ser´ıa 179,922,739. Definimos como desafio la concatenaci´on de parte1, expresado como un entero de 32 bits Big-Endian, parte2, expresado igualmente como un entero de 32 bits Big-Endian, y clave3. El orden de la concatenaci´on debe ser el mismo orden en el que se enviaron dentro del conjunto de las cabeceras de la petici´on. En nuestro ejemplo desafio contendr´ıa los siguientes 16 bytes: 0x36 0x09 0x65 0x65 0x0A 0xB9 0x67 0x33 0x57 0x6A 0x4E 0x7D 0x7C 0x4D 0x28 0x36. Finalmente definimos como respuesta la huella generada al calcular el algoritmo MD5 sobre desafio como una cadena de caracteres de 128 bits Big-Endian. En nuestro ejemplo la huella MD5 de desafio se corresponderia con los bytes: 0x6E 0x60 0x39 0x65 0x42 0x6B 0x39 0x7A 0x24 0x52 0x38 0x70 0x4F 0x74 0x56 0x62. ´ Esta huella de 16 bytes ser´a la que finalmente se inserte al final de la respuesta a la petici´on WebSocket. El cliente la analizar´a y si coincide con la que ´el mismo calcul´o y el resto de cabeceras son correctas, se establecer´a la conexi´on y tanto el servidor como el cliente podr´an enviar datos de forma bidireccional a trav´es de la conexi´on WebSocket. Transmisi´on de datos Al igual que se explic´o en el apartado dedicado al algoritmo del lado del cliente, que se desee enviar el servidor deben ir precedidos por el valor 0x00 y deben finalizar con 0xFF. Entre ´estos dos valores deben ir los valores de los caracteres codificados en UTF-8. Cierre de conexi´on Al igual que sucede en el caso de que el cliente desee iniciar el proceso de desconexi´on, si es el servidor el que desea cerrar la conexi´on enviar´a los caracteres 0xFF 0x00. El servidor responder´a 0xFF confirmando la desconexi´on. Ejemplo de captura del intercambio de cabeceras Aqui se muestra un ejemplo de la petici´on de conexi´on WebSocket de un cliente (Firefox 4.0 Beta 7) y la respuesta por parte del servidor. ´ Estas capturas est´an extraidas con WireShark de una comunicaci´on real de nuestro servidor implementado. 40 CAP´ ITULO 2. FUNDAMENTOS TE´ ORICOS Petici´on por parte del cliente GET / HTTP/1.1 Sec-WebSocket-Key1: & 3 ’91 4 k 423 g.450 Upgrade: WebSocket Sec-WebSocket-Key2: # 1 4 5 04 7066 0 Host: localhost:9321 Connection: Upgrade Origin: http://localhost C>}m 0000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HTTP/1.1.. 0010 53 65 63 2d 57 65 62 53 6f 63 6b 65 74 2d 4b 65 Sec-WebSocket-Ke 0020 79 31 3a 20 26 20 33 20 20 27 39 31 20 20 34 20 y1: & 3 ’91 4 0030 6b 20 20 34 32 33 20 20 67 2e 34 35 30 0d 0a 55 k 423 g.450..U 0040 70 67 72 61 64 65 3a 20 57 65 62 53 6f 63 6b 65 pgrade: WebSocke 0050 74 0d 0a 53 65 63 2d 57 65 62 53 6f 63 6b 65 74 t..Sec-WebSocket 0060 2d 4b 65 79 32 3a 20 23 20 31 20 34 20 20 20 20 -Key2: # 1 4 0070 35 20 20 20 30 34 20 20 37 30 36 36 20 30 0d 0a 5 04 7066 0.. 0080 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f 73 74 3a Host: localhost: 0090 39 33 32 31 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 9321..Connection 00a0 3a 20 55 70 67 72 61 64 65 0d 0a 4f 72 69 67 69 : Upgrade..Origi 00b0 6e 3a 20 68 74 74 70 3a 2f 2f 6c 6f 63 61 6c 68 n: http://localh 00c0 6f 73 74 0d 0a 0d 0a b6 b8 43 3e 7d 6d 1f d3 ost......C>}m.. Respuesta por parte del servidor HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Origin: http://localhost Sec-WebSocket-Location: ws://localhost:9321/ o7s! 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 f1 d2 15 40 00 40 06 69 ef 7f 00 00 01 7f 00 ....@[email protected]....... 0020 00 01 24 69 c7 65 9d f1 02 e9 9e 88 84 9d 80 18 ..$i.e.......... 0030 02 11 fe e5 00 00 01 01 08 0a 00 20 d0 fd 00 20 ........... ... 0040 d0 fd 48 54 54 50 2f 31 2e 31 20 31 30 31 20 57 ..HTTP/1.1 101 W 0050 65 62 20 53 6f 63 6b 65 74 20 50 72 6f 74 6f 63 eb Socket Protoc 2.4. APLICACI´ ON PUENTE USB-IGU 41 0060 6f 6c 20 48 61 6e 64 73 68 61 6b 65 0d 0a 55 70 ol Handshake..Up 0070 67 72 61 64 65 3a 20 57 65 62 53 6f 63 6b 65 74 grade: WebSocket 0080 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 ..Connection: Up 0090 67 72 61 64 65 0d 0a 53 65 63 2d 57 65 62 53 6f grade..Sec-WebSo 00a0 63 6b 65 74 2d 4f 72 69 67 69 6e 3a 20 68 74 74 cket-Origin: htt 00b0 70 3a 2f 2f 6c 6f 63 61 6c 68 6f 73 74 0d 0a 53 p://localhost..S 00c0 65 63 2d 57 65 62 53 6f 63 6b 65 74 2d 4c 6f 63 ec-WebSocket-Loc 00d0 61 74 69 6f 6e 3a 20 77 73 3a 2f 2f 6c 6f 63 61 ation: ws://loca 00e0 6c 68 6f 73 74 3a 39 33 32 31 2f 0d 0a 0d 0a 6f lhost:9321/....o 00f0 e1 ac 97 37 04 df 73 9d c8 9e db da cc d2 21 ...7..s.......! 48 CAP´ ITULO 3. PROTOCOLO DE COMUNICACI´ ON PROPUESTO El emisor de este paquete esperar´a un ACK4del receptor para salvar posibles colisiones. Paquete de Orden de descubrimiento La Orden de descubrimiento (ID: 3) es un paquete que env´ıa el nodo sumidero a los nodos que tenga registrados, ya sea directamente a trav´es de otros nodos. En este segundo caso al paquete se le adjuntar´a la ruta a trav´es de la cual ha sido descubierto para que pueda encaminar la contestaci´on hacia el sumidero. La ruta incluye la direcci´on del sumidero, de forma que cuando un nodo intermedio tenga que encaminar eliminar´a al nodo receptor de la ruta y adjuntar´a de nuevo al resto de direcciones hasta que llegue al sumidero (que al ser el ´ultimo nodo la ruta estar´a vac´ıa). Este mecanismo se basa en la premisa de que el nodo sumidero alcanza a todos los nodos de la red. Figura 3.4: Formato del paquete de Orden de descubrimiento Este paquete motiva que un nodo sensor env´ıe el paquete de descubrimiento para registrar a los nodos cercanos tal como hemos visto en los paquetes anteriores. Una vez vencido el timeout del descubrimiento el nodo receptor de la orden contestar´a con las tablas de intensidades y su nivel de bater´ıa al siguiente nodo en la ruta adjuntando el resto de direcciones f´ısicas de la misma. El formato incluye 4 bits de relleno entre el ID y la ruta. Paquete de Contestaci´on de Tablas de intensidades Despu´es de anotar las intensidades de se˜nal con las que recibe las contestaciones al descubrimiento, un nodo sensor env´ıa su bater´ıa y dichas intensidades al nodo sumidero en un paquete (ID: 4) de este tipo. Este paquete es el m´as importante de la fase de formaci´on de la red, ya que es la que recoge la informaci´on de intensidades de se˜nal y bater´ıas que permitir´a al nodo sumidero formar el grafo ponderado y calcular los caminos m´ınimos, clave del protocolo propuesto. 4Acuse de recibo, explicado m´as adelante. 3.2. FUNDAMENTOS 49 Figura 3.5: Formato del paquete de Contestaci´on de Tablas de intensidades En dicho paquete se deber´a adjuntar la ruta que recibi´o del sumidero en la orden de descubrimiento, utilizando los 4 bits de relleno entre la ID y la ruta para indicar el n´umero de direcciones que la compone. Posteriormente se adjuntar´a el nivel de bater´ıa del nodo en los 8 siguientes bits seguido de la tabla de intensidades. La tabla de intensidades consta de todas las direcciones f´ısicas de todos los nodos circundantes (4 bytes) del nodo emisor junto con la intensidad de se˜nal (dBm) con que ´este los percibe (1 byte). Por lo tanto cada nodo circundante supone 5 bytes m´as en la longitud del paquete, que se corresponde con una fila de la tabla de intensidades. Esto adem´as permite que el nodo sumidero registre aquellos nodos que est´en alejados de ´el y que no los hubiera descubierto ´este directamente. As´ı seguir´a la fase de formaci´on de la red hasta que no se registren nuevos nodos y a todos les haya enviado el sumidero una orden de descubrimiento y recibido ´este a su vez un paquete de tablas de intensidades. La ruta para estos nodos nuevos pasar´a a trav´es de aquellos nodos sensores que los hayan descubierto. El env´ıo de este paquete se resuelve con un acuse de recibo que se enviar´a punto a punto entre los nodos que conforman la ruta hasta el sumidero. Paquete de Programaci´on del macro-frame Una vez terminada la etapa de formaci´on de la red, formado el grafo y calculados los caminos m´ınimos se pasa a la etapa est´andar. El nodo sumidero enviar´a peri´odicamente una se˜nal de wake-up para sacar a los nodos sensores del estado de reposo y para sincronizarlos. Posteriormente se enviar´a un paquete de Programaci´on del macro-frame (ID: 5) que se compone de marcos de dos direcciones f´ısicas (emisor y receptor) que indican los nodos que participar´an en cada frame. El orden en que se utilizan los enlaces para cada marco temporal del macro-frame es algo que se abordar´a m´as adelante. Pero cabe decir que puesto que los paquetes de env´ıo de mediciones son variables, debemos ponernos en el peor de los casos para calcular el m´aximo de mediciones que un nodo puede acumular por cada env´ıo (frente al m´aximo de 255 bytes de longitud 50 CAP´ ITULO 3. PROTOCOLO DE COMUNICACI´ ON PROPUESTO Figura 3.6: Formato del paquete de Programaci´on del macro-frame de paquete impuesto por las librer´ıas del SimpliciTI para el CC1110). Ya que la programaci´on del macro-frame se realiza desde los nodos de niveles inferiores hacia el sumidero, acumulando medidas de hijos a padres en el ´arbol. Esto quiere decir que un nodo puede que no sea capaz de enviar todas las mediciones de los nodos que cuelgan de ´el directa o indirectamente en un solo paquete, por lo que habr´a que utilizar varios marcos temporales para emitir repetidamente hasta que pueda enviar todas las mediciones que ha acumulado. Por tanto habr´an casos en los que haya m´as marcos temporales que nodos, porque alguno tendr´a que ocupar m´as de uno para enviar sus medidas. La duraci´on de cada marco temporal es invariable y viene fijado por el equivalente a tres emisiones (que suponen el vencimiento de sus respectivos timeouts, y que a su vez depende de la velocidad de transmisi´on) de paquetes de medidas. Como ya hemos indicado el tiempo no es importante y el objetivo es que un error en una transmisi´on suponga la ca´ıda de un nodo y no un error puntual de comunicaci´on. Paquete de Env´ıo de mediciones Cada marco temporal programado por el sumidero supone el env´ıo de uno de estos paquetes (ID: 6) entre dos nodos sensores utilizando un enlace ascendente del ´arbol. El env´ıo del paquete se realiza siempre en cada marco, pero no siempre se enviar´a ninguna medici´on. Las mediciones, tanto la lectura de las galgas como las lecturas de control del RSSI o de la bater´ıa se enviar´an siempre que se supere un umbral configurable. Por ello se hacen necesarios los flags que indicar´an qu´e mediciones se adjuntan en el paquete. El receptor acumular´a el paquete, comprobar´a si es necesario actualizar el nivel de intensidad de la se˜nal respecto al umbral (y adjuntarlo si se diera el caso) y le responder´a con un acuse de recibo para el control de errores punto a punto. El campo de flags de 4 bits se estructura como sigue: 3.2. FUNDAMENTOS 51 Figura 3.7: Formato del paquete de Env´ıo de mediciones Bit Descripci´on 1 Flag de Error 2 Flag de medici´on (lectura de galgas) 3 Flag de nivel RSSI 4 Flag de nivel de bater´ıa Tabla 3.2: Tabla de Flags de mediciones En caso de que un nodo, durante uno de los marcos temporales del macroframe no recibiera un paquete de mediciones que tuviera programado, anotar´ıa la direcci´on f´ısica del nodo que no ha emitido su paquete y lo marcar´ıa con el flag de error. Los flags de medici´on y bater´ıa los marca el emisor y el de nivel de RSSI lo marca el receptor si procediera. Por este motivo los nodos guardan las tablas de intensidades de la etapa de formaci´on de la red donde tienen anotado el RSSI de todos los nodos adyacentes y lo actualizan si procediera. Paquete de Actualizaci´on de configuraci´on La etapa est´andar debe comenzar con este paquete (ID: 7) si desde la aplicaci´on de monitorizaci´on se especifican alguno de los valores de umbral (en caso contrario se toman valores por defecto). A su vez, si durante el desarrollo de la etapa est´andar se desea cambiar alguno de los umbrales que los nodos toman como referencia para enviar sus mediciones, se deber´a enviar un paquete de este tipo. Figura 3.8: Formato del paquete de Actualizaci´on de configuraci´on Consta de tres campos opcionales dependiendo de qu´e par´ametros se quiera modificar. Para indicar qu´e campos son los que contiene el paquete se incluye un campo de flags de 4 bits entre el id y los umbrales de estructura equivalente a los flags del paquete de env´ıo de mediciones. 52 CAP´ ITULO 3. PROTOCOLO DE COMUNICACI´ ON PROPUESTO Bit Descripci´on 1 Sin uso 2 Flag de umbral de medici´on 3 Flag de umbral de nivel RSSI 4 Flag de umbral de nivel de bater´ıa Tabla 3.3: Tabla de Flags de umbrales Los umbrales son en valor absoluto y representan la variaci´on de la susodicha medici´on que se considera suficientemente relevante para enviar el dato al sumidero. El umbral de medici´on se toma en µ (microdeformaciones5), el de la intensidad de se˜nal es en dBm (decibelios por miliWatio) y el umbral de bater´ıa en mAh6(miliamperios hora). Este paquete, como el de programaci´on del macro-frame, viene precedido por una se˜nal de wake-up para levantar a los nodos del modo reposo y prepararlos para la recepci´on del mensaje (excepto si el env´ıo del paquete se produce antes del primer macro-frame). Una vez procesado los nodos volver´an al estado de reposo. Paquete de Acuse de Recibo Tambi´en conocido como Acknoledgement en ingl´es o abreviado como ACK, este mensaje se utiliza en muchos protocolos para confirmar que un mensaje ha llegado correctamente. En este caso se utiliza en varios mensajes durante las fases del protocolo en los enlaces punto a punto como se ha indicado en los paquetes anteriores. El paquete de acuse de recibo consiste en un solo byte con todos sus bits a cero (ID: 0 + relleno). 3.2.3. Desarrollo por fases Fase de formaci´on de la red El objetivo final de esta fase es la formaci´on de un grafo que contenga todos los nodos de la red y sus respectivos enlaces entre ellos que indiquen la 5La deformaci´on es el cambio en el tama˜no o forma de un cuerpo debido a esfuerzos internos producidos por una o m´as fuerzas aplicadas sobre el mismo o la ocurrencia de dilataci´on t´ermica. 6Un amperio hora es una unidad de carga el´ectrica y se abrevia como Ah. Indica la cantidad de carga el´ectrica que pasa por los terminales de una bater´ıa, si esta proporciona una corriente el´ectrica de 1 amperio durante 1 hora. 3.2. FUNDAMENTOS 53 conectividad de la red. Sobre estos enlaces se calcular´an los caminos m´ınimos que formar´an el ´arbol sobre el que se programar´an los macro-frames. El nodo sumidero poseer´a una estructura de datos que le permitir´an alojar a los nodos sensores que descubra durante el desarrollo de la fase. Esta estructura no es m´as que una lista enlazada que contiene la direcci´on f´ısica del nodo y un puntero al nodo que descubri´o al actual. Este puntero se utiliza para poder encaminar los paquetes hasta el sumidero mientras el ´arbol no este formado. La lista se inicia conteniendo al propio nodo sumidero con el puntero a su descubridor a nulo. A medida que descubra nuevos nodos los a˜nadir´a a la lista y la recorrer´a demandando tablas de intensidades de las que a su vez podr´a descubrir e insertar nuevos nodos en la lista. As´ı la fase termina cuando haya recorrido la lista entera sin descubrir nuevos nodos, lo que querr´a decir que posee las tablas de intensidades de todos los nodos de la red y podr´a formar el grafo. Las tablas de intensidades son una estructura de datos que contiene las direcciones e intensidades de se˜nal de todos los nodos adyacentes que un nodo haya percibido. Contiene la direcci´on del nodo que cre´o la tabla, su nivel de bater´ıa actual (que enviar´a al nodo sumidero) y la lista de filas de intensidades, que no son m´as que las direcciones de los nodos adyacentes con sus respectivas intensidades de se˜nal. Se dar´an m´as detalles de implementaci´on m´as adelante en los anexos, pero sirva este adelanto para entender c´omo registra el sumidero los nodos y las rutas durante la fase de formaci´on de la red y qu´e son las tablas de intensidades que se env´ıan al sumidero por parte de los nodos sensores. Intercambio de paquetes durante la formaci´on de la red El registro de nuevos nodos se realiza por medio de los paquetes de descubrimiento. Un nodo que ya est´e registrado en la lista (empezando por el propio sumidero) env´ıa un paquete de descubrimiento. Este paquete es contestado por todos los nodos cercanos con el paquete de contestaci´on al descubrimiento como explicamos en el desarrollo de los paquetes (retroceso exponencial binario y detecci´on de portadora antes de enviar). Con cada contestaci´on que reciba el nodo emisor renovar´a el temporizador para que puedan registrarse nuevos nodos. ´ Este a su vez anota todos los nodos en su tabla local y la env´ıa al sumidero encaminando el mensaje en caso necesario a trav´es de la ruta que indicara la orden. Los nodos realizan esta acci´on a instancias del propio sumidero al recibir una orden de descubrimiento y deber´an contestar con sus tablas de intensidades. Como vemos durante esta fase los nodos sensores deber´an estar perpetuamente en escucha ociosa del medio y contestando a todos los paquetes que 54 CAP´ ITULO 3. PROTOCOLO DE COMUNICACI´ ON PROPUESTO escuchen y que fueran dirigidos a ellos o sean de difusi´on. Los nodos se ir´an descubriendo desde los m´as cercanos al sumidero hasta los m´as alejados a medida que que se vayan registrando. Figura 3.9: Esquema de comunicaciones de un nodo sensor durante la formaci´on de la red El nodo sumidero en primera instancia tantear´a ´el mismo la red para registrar los primeros nodos cercanos para, posteriormente recorrer su lista buscando nuevos nodos mientras les env´ıa ordenes de descubrimiento. Cuando posea las tablas de intensidades de todos los nodos registrados pasar´a a formar el grafo con todas las tablas de intensidades que ha recibido. Fase de funcionamiento est´andar Una vez finalizada la formaci´on de la red los nodos pueden empezar el modo normal de operaci´on, que consiste en este caso en la programaci´on peri´odica de los macro-frames para que las lecturas de las galgas de los nodos sensores lleguen a trav´es del nodo sumidero a la estaci´on de monitorizaci´on. El tiempo transcurrido entre un macro-frame y el siguiente ser´a configurable para permitir que la aplicaci´on se adapte a las necesidades de monitorizaci´on del entorno actual. Durante un macro-frame, el primero de los marcos temporales se reserva para la toma de lecturas de las galgas por parte de todos los nodos de la red. Las lecturas por otra parte, como ya se ha indicado anteriormente, solo se enviar´an si se ha superado un umbral absoluto tambi´en configurable. Los nodos sensores dejan la escucha ociosa del medio propia de la fase anterior en el momento en el que reciben alguno de los dos tipo de paquete 3.2. FUNDAMENTOS 55 Figura 3.10: Esquema de comunicaciones del sumidero durante la formaci´on de la red pertenecientes a esta fase del protocolo. ´ Estos ser´an enviados por el sumidero inmediatamente despu´es de haber formado el ´arbol de caminos m´ınimos. Intercambio de paquetes durante el funcionamiento est´andar En esta fase solo participan dos paquetes, el de programaci´on del macroframe y el de env´ıo de mediciones. En este caso el nodo sumidero tan solo env´ıa peri´odicamente la programaci´on y espera un tiempo proporcional al n´umero de marcos programados7(contando con el reservado para la toma de medidas de los sensores), y cercion´andose de que ha recibido todos los paquetes. El resto de nodos recibir´an un  bocinazo  por cada macro-frame que se vaya a programar. Recibir´an la programaci´on que es enviada por difusi´on a todos los nodos de la red y procesar´an los marcos en los que participan, recibiendo o enviando. Cuando tengan que recibir escucharan el medio durante el espacio de tiempo de un marco temporal completo y si lo reciben lo guardaran y contestar´an con un acuse de recibo. Si no recibieran ning´un paquete durante todo el marco temporal, anotar´ıan la direcci´on f´ısica del nodo del que deb´ıan 7Tespera = (2 + nmarcos)∗Tmarco 56 CAP´ ITULO 3. PROTOCOLO DE COMUNICACI´ ON PROPUESTO haber recibido el paquete de medidas y marcan para ´el el flag de error. Al contrario, al enviar adjuntan sus medidas a las que hubiera podido recibir y las env´ıan en un paquete al nodo que tengan programado como receptor. Cada marco temporal esta programado para tres reenv´ıos en caso de que venciera el timeout sin recibir su respectivo acuse de recibo. El nodo sumidero enviar´a tambi´en los acuses de recibo correspondientes. Una vez recibidos todos los paquetes de medidas el sumidero las recorrer´a en busca de nuevas medidas o paquetes con el flag de error, actuando en cada caso de forma adecuada al problema si debiera. 3.2.4. Formaci´on del grafo Una vez recogidas todas las tablas de intensidades el nodo sumidero pasa a formar el grafo con los datos que contienen. El grafo es otra de las estructuras que poseer´a el sumidero en la que cada v´ertice representar´a un nodo terminal y los arcos o aristas representan las conexiones inal´ambricas presentes. El grafo ser´a ponderado y dirigido (con un par de aristas por enlace). El grafo lo formar´a utilizando las tablas de intensidades de todos los nodos que debe haber recibido tras la etapa anterior. ´ Estas tablas, como se ha indicado, contienen el nivel de bater´ıa de todos los nodos en el momento del env´ıo de sus tablas y las intensidades de se˜nal con que perciben a los nodos cercanos asociadas a sus respectivas direcciones f´ısicas. Datos necesarios todos ellos para formar el grafo y ponderar sus v´ertices. Los nodos se distinguen en el grafo por unos identificadores ascendentes que empiezan en el 1, que corresponder´a al v´ertice que representa al sumidero. Este identificador se utilizar´a entre otras cosas para evitar que se dupliquen v´ertices. Al crear un enlace debe crearse a su vez el v´ertice al que apunta en caso de que este no existiera. Los enlaces se ponderan al crearse y un enlace entre dos nodos supone dos aristas uniendo a ambos nodos en ambos sentidos. Es importante procesar los dos v´ertices al crear un enlace ya que al ponderarlo se tiene en cuenta la bater´ıa de ambos nodos y las respectivas intensidades con que se perciben respectivamente. La f´ormula utilizada para ponderar un enlace es la siguiente: IndiceP =α+β Siendo α=Bateria1·Bateria2− |Bateria1−Bateria2| β=RSSI1·RSSI2− |RSSI1−RSSI2| Al final ambos arcos del enlace deben ponderarse igual (el resultado en ambos sentidos es el mismo ya que la resta es en valor absoluto) aunque en 3.2. FUNDAMENTOS 57 instantes del recorrido distintos. Tanto los operandos como el resultado de la operaci´on se consideran sin signo (el de la bater´ıa y el del RSSI) ya que el RSSI suele verse con valores negativos de dBm y se almacena como un entero con signo. Se busca una concordancia entre los ´ındices αyβ. El c´alculo se formula para penalizar los valores desiguales en los niveles de bater´ıa y RSSI, considerando por igual ambas medidas (αyβ). Como podemos ver si los valores son similares la resta tender´a a cero y entonces la ponderaci´on depender´a del resultado de la multiplicaci´on. Tambi´en es f´acil de observar en este caso que ante niveles que resulten en un mismo valor al multiplicarlos, se ponderar´a m´as positivamente aquella combinaci´on que presente n´umeros m´as similares. Por ejemplo, si RSSI11=2 y RSSI12=4 por un lado, y RSSI21=1 y RSSI22=8 por otro (valores v´alidos para ilustrar el ejemplo solamente y que no se ajustan en ning´un caso a la realidad), tenemos: β1= 2 ·4− |2−4|= 8 −2=6 β2= 1 ·8− |1−8|= 8 −7=1 Con lo que queda claramente ilustrada la penalizaci´on ante valores desiguales que era el objetivo de la f´ormula para la ponderaci´on de arcos presentada. 3.2.5. C´alculo de los caminos m´ınimos El c´alculo de caminos m´ınimos una vez formado el grafo se realiza aplicando el algoritmo de Dijkstra8y formando un ´arbol de expansi´on9sobre el mismo grafo. Como v´ertice origen se toma al nodo sumidero y se calculan los caminos de todos lo v´ertices a ´este usando un puntero al nodo al que deben realizan el env´ıo. El c´alculo determina la forma del ´arbol y los niveles de los que constar´a. Cada v´ertice posee su nivel en el grafo como atributo y el nodo sumidero se guarda el nivel m´aximo del ´arbol para poder recorrerlo desde las hojas de los niveles inferiores. Adem´as cada nodo, una vez terminado el proceso poseer´a un puntero al siguiente nodo del mismo nivel10 en el ´arbol. 8Algoritmo para la determinaci´on del camino m´as corto dado un v´ertice origen al resto de v´ertices en un grafo dirigido y con pesos en cada arista. Su nombre se refiere a Edsger Dijkstra, quien lo describi´o por primera vez en 1959. 9Un ´arbol de expansi´on de un grafo G es una selecci´on de aristas de G que forman un ´arbol que cubre todos los v´ertices. Esto es, cada v´ertice est´a en el ´arbol, pero no hay ciclos. 10Corresponde a detalles del algoritmo utilizado para la programaci´on del macro-frame que se explicar´an a continuaci´on 64 CAP´ ITULO 3. PROTOCOLO DE COMUNICACI´ ON PROPUESTO de sus enlaces y se programa un nuevo macro-frame completo para intentar hacer llegar sus medidas al sumidero. Si alguno de los nodos sensores deja de poder alcanzar al sumidero, es decir que se queda sin enlaces utilizables que le unan al resto de la red, la estaci´on de monitorizaci´on avisar´a al usuario de la existencia del nodo hu´erfano. El sumidero en este caso desmontar´a la red para formar nuevos enlaces y permitir que el nuevo nodo se registre a trav´es de alguno de ellos. En caso de que ni siquiera esta soluci´on sirva y el nodo hu´erfano no se registre en la nueva red simplemente se asumir´a la p´erdida del nodo hu´erfano, debiendo recaer en el usuario la responsabilidad de reemplazar alg´un nodo sensor para que deje de estar hu´erfano. Por otro lado cabe a˜nadir una posible fuente de errores en la formaci´on del ´arbol. En principio no se ha establecido un l´ımite al n´umero de reenv´ıos en ning´un paquete de la formaci´on de la red. Esto requerir´ıa un estudio m´as a fondo de qu´e paquetes pueden resultar en un bucle infinito de env´ıos a un nodo que ha dejado de escuchar. No es una situaci´on habitual y por eso no se ha contemplado excepto en el caso de la contestaci´on al descubrimiento. Un nodo se puede quedar atascado en el env´ıo de contestaciones al descubrimiento a un nodo si en alg´un error puntual su recepci´on no ha sido posible y el nodo receptor ya ha enviado sus tablas de intensidades. Es por esto que se ha a˜nadido una guarda por la que si un nodo recibe un paquete de contestaci´on al descubrimiento y no esta ya formando su tabla de intensidades simplemente enviar´a un acuse de recibo para sacar al nodo del bucle de env´ıos (contemplado en la figura 3.9). A continuaci´on podemos ver la imagen 3.16 que intenta aclarar la situaci´on relatada anteriormente: Figura 3.16: Ilustraci´on de error durante la formaci´on de la red El resto de posibles errores en la red se asumen y solucionan en su caso con los timeouts, los acuses de recibo y los CRCs13 que ofrecen las librer´ıas del SimpliciTI (y el propio microcontrolador), es decir, las t´ecnicas t´ıpicas de control de errores y de flujo de la capa de acceso al medio. 13Comprobaci´on de redundancia c´ıclica, pueden ser usados como suma de verificaci´on para detectar la alteraci´on de datos durante su transmisi´on o almacenamiento Cap´ıtulo 4 Entorno de trabajo 4.1. Microcontrolador El nodo WSNVAL utilizado para el desarrollo y las pruebas del proyecto cuenta con un Microcontrolador CC1110. Entre las caracter´ısticas principales podemos destacar: N´ucleo 8051 que ofrece un elevado rendimiento a cambio de un bajo consumo Funcionamiento en las bandas de frecuencia de: 300-348 MHz, 400-464 MHz u 800-928 MHz. Tasa de env´ıo de datos programable de hasta 500 kbps. 32KB de memoria flash programable. 4KB de memoria SRAM. Dos interfacez USART (Universal Synchronous/Asynchronous Receiver/Transmitter) para la comunicaci´on con dispositivos serie. Un temporizador de 16 bits, tres de 8 bits y uno de 31 bits que funciona en varios modo de bajo consumo (sleep timer). Bajo consumo energ´etico (22 mA en la recepci´on y 31mA en la transmisi´on con el MCU funcionando a 26 MHz). Potencia de emisi´on programable de hasta 10 dBm para todas las frecuencias soportadas. Hasta 0,6 µA de consumo en su modo de m´ınimo consumo (PM3). 65 66 CAP´ ITULO 4. ENTORNO DE TRABAJO Figura 4.1: Arquitectura y asignaci´on del patillaje del CC1110 4.1. MICROCONTROLADOR 67 De entre estas destacan las que recibieron un trato m´as de cerca en el ´ambito del proyecto. En la fase de desarrollo del protocolo algunas caracter´ısticas se mostraron de gran utilidad para ajustar el funcionamiento al descrito en la etapa de dise˜no te´orico del mismo. Algunas incluso son indispensables, como los temporizadores o los modos de bajo consumo para permitir reducir el gasto energ´etico en los periodos que el nodo sensor pasa ocioso. 4.1.1. CPU y Memoria El n´ucleo de la CPU es una versi´on mejorada del est´andar 8051, con el mismo juego de instrucciones que el est´andar, pero se ejecutan m´as velozmente debido entre otros al decremento de los ciclos por instrucci´on de ´esta versi´on del n´ucleo. Adem´as de las mejoras en velocidad tambi´en posee algunas mejoras arquitectales, sin perder compatibilidad con el est´andar industrial del 8051, excepto en los casos en los que en el c´odigo existan bucles de temporizaci´on que pueden requerir cierta modificaci´on. Con lo que respecta a la memoria, la CPU del 8051 posee cuatro espacios bien diferenciados: C´odigo: un espacio de memoria de solo lectura de 16 bits para memoria de programa. Datos: un espacio de memoria de lectura y escritura de 8 bits, que puede ser directamente o indirectamente accesible por una instrucci´on de CPU. Los 128 bytes de menor peso del espacio de memoria pueden ser direccionados de ambas formas, mientras que los restantes 128 bytes solo puede ser direccionados indirectamente. XDATA: un espacio de memoria de lectura y escritura de 16 bits a la cual acceder requiere de 4 a 5 ciclos de instrucci´on de la CPU. El acceso a este espacio de la memoria es m´as lento que al espacio de datos. Registros de Funciones Especiales (SFR - Special Function Registers): un espacio de memoria de lectura y escritura de 7 bits que puede ser direccionada por medio de una simple instrucci´on de la CPU. Para los registro cuya direcci´on sea m´ultiplo de ocho, cada bit es direccionable tambi´en individualmente. 68 CAP´ ITULO 4. ENTORNO DE TRABAJO Figura 4.2: Espacio de memoria XDATA del CC1110 4.1.2. Interfaz de depuraci´on La interfaz de depuraci´on ofrece dicha depuraci´on por medio de un sistema propietario consistente en dos cables de transmisi´on serie. A trav´es de esta interfaz es posible realizar un borrado completo de la memoria flash, controlar qu´e osciladores est´an habilitados, iniciar y detener la ejecuci´on del programa que carga el usuario, ejecutar instrucciones suministradas por el n´ucleo del 8051, establecer puntos de interrupci´on y ejecuci´on paso a paso de las instrucciones. Mediante el uso de ´estas t´ecnicas resulta posible llevar a cabo la depuraci´on del c´odigo que se cargue sobre el dispositivo. 4.1.3. Control de Potencia El CC1110 posee cuantro modos de potencia con distintas caracter´ısticas que permiten asegurar un m´ınimo consumo adaptado a las exigencias de cada situaci´on. Los modos son: PM0, PM1, PM2 y PM3. PM0 es el modo activo mientras que el resto son modos de bajo consumo, siendo PM3 el de menor consumo de potencia. Los modos de operaci´on a (ultra) bajo consumo se consiguen cortando el suministro de energ´ıa a los m´odulos para evitar consumo est´atico y bloqueando los relojes para reducir el consumo din´amico. 4.1. MICROCONTROLADOR 69 PM0 Este modo es el modo activo, en el que todas las funciones de operaci´on y los perif´ericos del MCU est´an activos. El consumo en este modo con la etapa de radio activa puede llegar a los 31 mA cuando la radio est´a en modo de transmisi´on. PM1 En este modo los osciladores de alta velocidad est´an apagados, deteniendo a su vez la CPU y los perif´ericos. El regulador de voltaje permanece encendido, asi como el oscilador activo es el de 32,768/34 kHz, las interrupciones externas o los perif´ericos del sleep timer. Cuando el dispositivo pasa de PM1 a PM0 los osciladores de alta velocidad se inician. Este modo de ahorro de energ´ıa es indicado cuando el tiempo hasta la se˜nal que lo despierte sea supuesto corto ya que se usa una secuencia de entrada y salida del modo r´apida. El consumo ronda tipicamente los 300 µA en este modo. PM2 PM2 es el segundo modo con la menor consumici´on energ´etica de las disponibles. Se usa el mismo oscilador que el PM1 y los perif´ericos del sleep timer siguen activos. El resto de circuitos internos se apagan, incluido el regulador de voltaje. Este modo es indicado cuando se espera un tiempo relativamente largo hasta el momento en que se espere la se˜nal de despertado, ya que la secuencia de entrada y salida del modo, a diferencia del PM1, es costosa y lleva un tiempo relativamente elevado. Este modo se usa t´ıpicamente con el sleep timer como evento de despertado. El consumo ronda tipicamente los 0,8 µA en este modo. PM3 PM3 es indicado cuando se busca el modo con el menor consumo energ´etico. Este modo detiene todos los circuitos internos junto con el regulador de voltaje y todos los osciladores. El encendido al reiniciar y las interrupciones externas son las unicas funciones operativas. As´ı que solo una interrupci´on externa puede despertar a un 70 CAP´ ITULO 4. ENTORNO DE TRABAJO nodo de este modo. Los contenidos de la RAM y los registros son preservados. Se usa la misma secuencia de entrada y salida que en el PM2. El consumo ronda tipicamente los 0,6 µA en este modo. 4.1.4. Temporizadores Sleep Timer Este temporizador funciona a baja potencia usando el oscilador de cristal de 32,768 kHz o el orcilador RC de la misma frecuencia como periodo. Este temporizador funciona de forma continuada en todos los modos de potencia excepto en PM3. Se puede configurar dentro de una amplia gama de resoluciones para llegar a un compromiso ajustado entre la resoluci´on y el periodo. Su uso t´ıpico es como se˜nal de despertado en ciertos modos de ahorro de energ´ıa. Temporizador 1 Este temporizador posee un contador de 16 bits con tres canales con un valor de comparaci´on de 16 bits. Se puede usar para capturar la cadencia de los flancos del reloj como contador. El prescalar permite dividir el periodo entre 1, 8, 32 o 128. Los modos de funcionamiento son: Free-running En este modo de operaci´on el contador empeiza en 0x0000 y se incrementa en cada flanco de subida. Cuando el contado alcanza 0xFFFF el contador se carga de nuevo con el valor 0x0000 y contin´ua incrementando su valor. Cada vez que esto ocurre se activa el flag de interrupci´on. Figura 4.3: Modo Free-running del temporizador 1 4.1. MICROCONTROLADOR 71 M´odulo Este modo es similar al modo free-running, pero la interrupci´on y la vuelta del contador a 0x0000 no se producen en 0xFFFF sino cuando el valor coincide con el contenido en un registro del microcontrolador. Up/Down Este modo empieza con el contador a 0x0000 y se incrementa hasta su valor coincide, como en el caso anterior, con un registro del microcontrolador, y entonces se decrementa de nuevo hasta 0x0000. Figura 4.4: Modo Up/down del temporizador 1 Temporizador 2 Tambi´en conocido como temporizador MAC, dise˜nado especialmente para soportar protocolos software temporizados. El periodo es configurable y posee un rango de prescalar de 18 bits. Temporizadores 3 y 4 Estos temporizadores son de 8 bits de periodo, con prescalares configurables y un canal configurable con un comparador de 8 bits. Su uso es similar al del temporizador 1, incluidos los modos de funcionamiento. Los prescalares dividen la frecuencia entre 1, 2, 4, 8, 16, 32, 64 o 128 (permitiendo ajusta el periodo deseado). 4.1.5. Radio En la figura 4.5 vemos el diagrama del m´odulo de radio del microcontrolador. 72 CAP´ ITULO 4. ENTORNO DE TRABAJO Figura 4.5: M´odulo de Radio del CC1110 El microcontrolador cuenta con un receptor de frecuencias intermedias y bajas. La se˜nal de radio-frecuencia es amplificada y convertida en cuadratura a frecuencia intermedia. En dicha frecuencia, las se˜nales son digitalizadas por el convertidor anal´ogico-digital. El resto del proceso de filtrado y demodulaci´on es realizado digitalmente. La parte transmisora del CC1110 se basa en la s´ıntesis directa de la radio frecuencia. El sintetizador de frecuencia incluye un integrado en chip que realiza la modulaci´on (en fase o cuadratura). Los par´ametros de la radio son ampliamente configurables, en frecuencia, canal, incluso el m´etodo de modulaci´on. La configuraci´on se realiza a trav´es de ciertos registros del propio microcontrolador. Las interrupciones tambi´en se manejan a trav´es de registros del microcontrolador. Permite establecer una m´ascara y capturar distintos tipos de interrupciones para ajustar al m´aximo el comportamiento del dispositivo ante acciones espec´ıficas de la radio. El c´alculo del CRC, la estimaci´on del RSSI o la detecci´on de portadora son funciones que las realiza el m´odulo de radio y se comprueban a trav´es de registros del CC1110. El formato del paquete del CC1110 ya se detall´o en el Cap´ıtulo 3, Secci´on 2.1.1. 4.2. TARJETA DE ADAPTACI´ ON DE SENSORES 73 4.1.6. USART El microcontrolador cuenta de dos USART para la transmisi´on de datos serie mediante los puerto de E/S de prop´osito general. Las USART permiten transmitir en modo UART o SPI. En el modo UART permiten transmitir datos en serie de forma as´ıncrona mientras que en el modo SPI permiten hacer uso del estandar SPI para la transmisi´on de datos. Las USART permiten configurar diversos par´ametros de transmisi´on como la paridad par o impar, el orden de los bits (MSB o LSB), la velocidad de transmision, los bits de parada e inicio, etc. Para configurar y manejar las USART se utilizan los registros UxGCR, UxUCR y UxCSR, donde xpuede ser 0 o 1 dependiendo de la USART que se desee utilizar, mientras que para transmitir y recibir datos se utiliza el registro U0DBUF. Las USART permiten dos alternativas para el conjunto de puertos de E/S usados para el modo UART y otros dos para el modo SPI de forma que se usa un juego distinto de puertos dependiendo de la USART utilizada, el modo en el que funciones y la alternativa de puertos elegida. Las alternativas de puertos elegida se configura en el registro PERCFG. Las USART adem´as incorporan mecanismos de interrupciones de forma que ´estas se pueden usar para activar rutinas ante la recepci´on de datos. 4.2. Tarjeta de adaptaci´on de sensores Como hemos dicho anteriormente, nuestra red de sensores tiene como objetivo medir las deformaciones que sufre el material sobre el que se situar´a el nodo. Para medir ´estas deformaciones nos hemos decantado por el uso de galgas extensiom´etricas. La se˜nal de ´estos sensores debemos llevarla al microcontrolador para que ´este la procese y la env´ıe posteriormente al nodo sumidero a trav´es de la red de nodos. Sin embargo, ´estos sensores son unas simples resistencias que varian su valor en funci´on de la deformaci´on que sufren, por lo que hay que dise˜nar la electr´onica necesaria para generar una se˜nal a partir de la variaci´on de resistencias de las galgas que sea adecuada para aplicarla en las entradas de E/S del microcontrolador Para realizar todo ´ese proceso de adaptaci´on que transformar´a la escasa variaci´on de resistencia de las galgas en una se˜nal digital apta para los puertos de E/S del microcontrolador se dise˜nar´a un circuito electr´onico de adaptaci´on. Dicho proceso queda resumido en la figura 4.6. En primer lugar emplearemos un puente Wheatstone (explicado en el capitulo 5) que convertir´a la variaci´on de resistencia en una peque˜na tensi´on 80 CAP´ ITULO 4. ENTORNO DE TRABAJO realizamos la misma acci´on pero con la funci´on main que no fue deshabilitada en el primer perfil, conseguimos que con el perfil actual podamos compilar la funci´on main. De ´esta forma, ya tenemos dos perfiles de ejecuci´on que compilan correctamente cada una de las dos funciones main, por lo que, a efectos pr´acticos, es como tener dos proyectos en uno ya que seg´un que perfil de ejecuci´on tengamos activo IEW compilar´a una funci´on main u otra. Figura 4.13: Desactivar la compilaci´on de un archivo Extrapolando ´esto a nuestra casu´ıstica particular tendremos dos perfiles de ejecuci´on,  Node  y  Sink  , el primero compilar´a el c´odigo principal de los nodos convencionales y el segundo el c´odigo correspondiente al nodo sumidero. En el perfil de ejecuci´on  Node  deshabilitaremos la compilaci´on del archivo que contiene la funci´on main del nodo sumidero y con el perfil  Sink  activo desactivaremos la compilaci´on para el archivo que contiene la funci´on main que corresponde a los nodos convencionales. Ambos perfiles de ejecuci´on compilar´an a partir de su funci´on main correspondiente y nosotros activaremos el perfil de ejecuci´on correspondiente dependiendo de si queremos compilar y programar un nodo convencional o un nodo sumidero. Los perfiles de ejecuci´on adem´as pueden ser usado para otros prop´ositos 4.4. SIMPLICITI 81 como generar diferentes versiones de los binarios del mismo c´odigo fuente para distintas arquitecturas de microcontrolador simplemente cambiando el perfil de ejecuci´on. En general es un mecanismo que permite tener guardades y a mano diferentes configuraciones del mismo proyecto. 4.4. SimpliciTI SimpliciTIT M es un protocolo dirigido a peque˜nas redes de bajo consumo de energ´ıa y uso de radiofrecuencia3de baja potencia. ´ Este fue desarrollado por Texas Instruments (en adelante TI) con la finalidad de facilitar la implementaci´on y el despliegue de aplicaciones usando algunas de las plataformas de TI basadas en radiofrecuencia, entre las que se encuentra por supuesto la familia de sistemas en chip4(System-on-Chip - SoC) del CC1XXX. Esencialmente el protocolo esta dirigido para aquellos que buscan una soluci´on inal´ambrica para redes de baja potencia, bajo coste y baja velocidad de transmisi´on como un gran caja negra que les permita enviar mensajes por dicha red inal´ambrica de la forma m´as simple posible (por ejemplo sistemas de alarma y seguridad, redes de detectores de humo o sistemas dom´oticos entre otros). El protocolo esta orientado principalmente para aplicaciones en los que la comunicaci´on se realiza punto a punto entre nodos que est´an enlazados explicitamente. Sin embargo SimpliciTI soporta otro tipo de arquitecturas. Desde el punto de vista del desarrollo, el API de SimpliciTI provee de medios para inicializar la red, enlazar dispositivos y enviar mensajes por la red de forma transparente. De entre las funciones de las librer´ıas del SimpliciTI se hace uso en el proyecto sobretodo del manejo transparente de tramas y de las opciones de configuraci´on de la radio y los registros del microcontrolador y no del protocolo propuesto por SimpliciTI espec´ıficamente. 4.4.1. Componentes modulares La pila b´asica del SimpliciTI soporta comunicaci´on inal´ambrica sin ninguna caractesristica adicional. Como vemos en la figura 4.14, hay algunos m´odulos cuyas funcionalidades pueden ser a˜nadidas a la pila b´asica combin´andolas para conseguir un entorno adaptado a la aplicaci´on del consumidor. En el ´ambito del desarrollo del proyecto solo se ha utilizado el m´odulo b´asico del SimpliciTI, aunque el uso de alguno de los m´odulos presentes 3Porci´on menos energ´etica del espectro electromagn´etico 4Sistemas en los que se integran los componentes de un computador o cualquier otro sistema electr´onico en un ´unico circuito integrado (chip) 82 CAP´ ITULO 4. ENTORNO DE TRABAJO Figura 4.14: Componentes modulares de SimpliciTI podr´ıa ser una opci´on de ampliaci´on de las funcionalidades de los nodos de la red propuesta. Por ello se ofrece a continuaci´on una breve descripci´on de algunos de ellos que podr´ıan resultar interesantes. Encriptaci´on Cuando se habilita este m´odulo todos los campos excepto el de direcci´on se encriptan. Funcionalidad que aumenta la seguridad aun con el contra de que las estaciones puente deben desencriptar el mensaje para saber a qu´e direcci´on deben reenviarlo. Frecuency agility Este m´odulo representa la capacidad de la red para migrar de una frecuencia a otra si detecta que la red presenta ruido o se ha visto comprometida la comunicaci´on. La frecuencia se centraliza a todos los nodos de la red a trav´es de una tabla de frecuencias. Los nodos detectan los cambios si no reciben acuse de recibo ante dos reenv´ıos. El emisor cambia de frecuencia recorriendo la tabla hasta que recibe el acuse de recibo. Depende de la arquitectura el cambio de frecuencia puede ser impuesto por un nodo actuando como punto de acceso. Por otro lado los dispositivos que ´unicamente transmitan sin escuchar el medio (Tx-only devices) deber´an enviar dos veces en todas las frecuencias de la tabla (transmiten bien en una sola o bien en una secuencia de frecuencias o canales). 4.4. SIMPLICITI 83 Extensores de Rango ´ Estos nodos reenviar´an todos los paquetes excepto si son los destinatarios de los mismos (como un ping). El n´umero de saltos se decrementa al atravesar un nodo extensor de rango. 4.4.2. Resumen de la arquitectura El software del SimpliciTI soporta conceptualmente tres capas de la pila de protocolos: nivel f´ısico, nivel de red y nivel de aplicaci´on. De estas tres el nivel de aplicaci´on es el ´unico que el cliente necesita desarrollar. La comunicaci´on se realiza a trav´es de algunas funciones propias del API5para inicializar la red y enviar o recibir los mensajes inal´ambricos. La arquitectura no sigue estrictamente el modelo de referencia OSI, de modo que si se necesita funcionalidad extra de alguna de las capas del modelo OSI ´esta debe ser asumida por alguna de las capas presentes. La capa f´ısica por otra parte no posee las funcionalidades t´ıpicas de una capa f´ısica ya que los datos se reciben directamente de la radio que es qui´en realiza dichas funcionalidades (el nivel f´ısico del CC1110). Figura 4.15: Arquitectura de SimpliciTI Capa de Aplicaci´on El usuario desarrolla la aplicaci´on y las interacciones del sensor con el entorno. El uso del API de SimpliciTI aporta a la aplicaci´on la posibilidad de enviar o recibir mensajes hacia o desde otro dispositivo. 5Interfaz de programaci´on de aplicaciones, un conjunto de funciones y procedimientos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracci´on 84 CAP´ ITULO 4. ENTORNO DE TRABAJO Capa de Red La capa de red del SimpliciTI extiende la funcionalidad t´ıpica del est´andar OSI. La configuraci´on de la red se da en tiempo de ejecuci´on por medio de una interfaz del tipo ioctl(). De esta forma se pueden configurar diversos par´ametros, desde la frecuencia base, n´umero de frecuencias soportadas, m´etodo de modulaci´on, velocidad de transmisi´on, entre otros. El espacio de nombres del SimpliciTI consiste en direcciones de cuatro octetos, excluyendo los direcciones 0x00000000 y 0xFFFFFFFF que se reservan para difusiones. MRFI MRFI (del ingl´es Minimal RF Interface) es una capa del SimpliciTI que ofrece un nivel de abstracci´on ante env´ıo y recepci´on de paquetes a trav´es del interfaz de radio. Es decir, se sit´ua en el nivel f´ısico del est´andar OSI. BSP Este paquete (BSP, del ingl´es Board Support Package) ofrece a su vez un nivel de abstracci´on para distintas funciones del microcontrolador, como son el interfaz SPI con la radio y el manejo de interrupciones o LEDs por medio de las conexiones GPIO6. 4.4.3. Estructura del paquete Los paquetes de SimpliciTI se separan en tres secciones l´ogicas: Una parte que se procesa por los niveles f´ısico y de acceso al medio, consistente en los bits de pre´ambulo y de sincronizaci´on. Una parte que soporta la gesti´on de la red, utilizados para su control y especificar distintos par´ametros, como el tipo de paquete (a nivel del SimpliciTI), el n´umero de secuencia, contador de saltos, etc. Una parte que representa la carga ´util de la capa de aplicaci´on creada por el usuario, en nuestro caso los paquetes del protocolo de comunicaci´on dise˜nado que se procesa como parte de la trama recibida. 6Entrada/Salida de prop´osito general (General Purpose Input/Output), una interfaz de comunicaci´on presente en el microcontrolador que ofrece interconexi´on con distintos perif´ericos 4.4. SIMPLICITI 85 Figura 4.16: Detalle de las secciones l´ogicas de un paquete del SimpliciTI Campo Descripci´on Comentarios Pre´ambulo y Sync Sincronizaci´on de la radio Dependiente y manejado por la radio del CC1110 Longitud Longitud del paquete en bytes Cuenta a partir del campo siguiente DSTADDR y SRCADDR Campos reservados para las direcciones de fuente y destino Parcialmente dependiente de la radio, pero manejados por SimpliciTI Puerto Solo los seis bits de menor peso se refieren al puerto de la aplicaci´on, el resto se refieren al nivel de seguridad El espacio de nombres para los puertos reservan las direcciones de la 0x20 a la 0x3F para aplicaciones del cliente TRACTID Identificador de transacci´on Identificador secuencial para a˜nadir robustez en la comunicaci´on APP PAYLOAD Datos de la aplicaci´on Espacio en el que se encapsula el protocolo propuesto, el n´umero m´aximo de bytes es entre 50 o 111 dependiendo del tipo de radio FCS Frame Check Sequence Corresponde al CRC calculado por el hardware de la radio Tabla 4.1: Sumario de Campos relevantes del paquete del SimpliciTI 86 CAP´ ITULO 4. ENTORNO DE TRABAJO Puertos Los puertos son abstracciones conceptuales que especifican la aplicaci´on objetivo que manejar´a el paquete. Los puertos del 0x00 al 0x1F son reservados como puertos bien conocidos con servicios destinados a la gesti´on de la red. Los puertos del 0x20 al 0x3F se mapean a manejadores del usuario. En concreto el puerto 0x3F se reserva para emisiones por difusi´on en nodos que no han sido enlazados7entre s´ı. Los puertos se mapean a nivel de red respecto a los identificadores de los enlaces. Se asocian a manejadores que se lanzan cuando se env´ıan o reciben paquetes. Campos omitidos En la tabla 4.1 se han omitido intencionadamente los campos MISC y DEVICE INFO, que no se usan en el protocolo propuesto y cuya finalidad esta relacionada con cuestiones del protocolo definido por SimpliciTI del cual no se hace uso. 4.5. SmartRF Packet Sniffer Packet Sniffer es una aplicaci´on desarrollada por SmartRFT M que se usa para mostrar por pantalla en tiempo real (y con posibilidad de almacenar) los paquete capturados por un nodo esuchando en el espectro de radiofrecuencia. La aplicaci´on da opci´on de filtrar la captura y decodifica el paquete mostrando cada campo de forma visual y clarificadora. Packet Sniffer soporta una amplia gama de protocolos que se seleccionan desde una ventana que se lanza antes de acceder al interfaz principal de la aplicaci´on. Entre los protocolos soportados se encuentran Bluetooth (especificaci´on 4.0), ZigBee, RF4CE 8y SimpliciTI, adem´as de un modo de captura gen´erica. El uso de esta aplicaci´on ha sido de una utilidad decisiba para las pruebas del protocolo de comunicaci´on, ya que permit´ıa observar y detectar en tiempo real errores en el intercambio de mensajes entres los nodos de los que se dispon´ıa sin la necesidad de depurar los dispositivos. Adem´as ofrece muchas posibilidades de filtrado e informaci´on adicional interesante que facilitaba el desarrollo de las comunicaciones inal´ambricas entre nodos. 7El enlazado de nodos forma parte del protocolo del SimpliciTI, parte que no se usa en el protocolo propuesto y que por tanto obliga a usar el puerto 0x3F de difusi´on en todas las emisiones 8Protocolo que forma parte de la ZigBee Alliance 4.5. SMARTRF PACKET SNIFFER 87 4.5.1. Flujo de datos Desde el punto de vista del PC los paquetes se almacenan en un b´uffer, y pasan por una cach´e en la RAM para mejorar el tiempo de acceso cuando un paquete debe ser mostrado en el entorno gr´afico de usuario. Figura 4.17: Flujo de datos del Packet Sniffer 4.5.2. Detalles de la aplicaci´on El firmware se descarga autom´aticamente sobre el dispositivo que actuar´a de sniffer si se requiere al inicializar la captura. Se comprueba desde la interfaz gr´afica. La aplicaci´on es compatible ´unicamente con Windows. Interfaz gr´afica de usuario Ventana de Lanzamiento Cuando se ejecuta la aplicaci´on se da la opci´on de elegir entre distintos protocolos y configuraciones desde una ventana lunar (o ventana de lanzamiento) que se muestra al incio. Para iniciar una sesi´on del programa se selecciona el protocolo, que en nuestro caso es el SimpliciTI, y seleccionamos el bot´on start. La ventana abre la sesi´on y cerrar o no la ventana de lanzamiento no afecta la ejecuci´on 88 CAP´ ITULO 4. ENTORNO DE TRABAJO Figura 4.18: Ventana de lanzamiento del Packet Sniffer de la aplicaci´on. En la ventana de lanzamiento adem´as se especifican algunos de los dispositivos compatibles con los distintos protocolos y con la aplicaci´on. Ventana de sesi´on del Packet Sniffer Una vez lanzada la aplicaci´on se ve la ventana principal dividida en dos secciones, una en la que aparecen los paquetes capturados y otra en la que se selecciona y configuran distintos par´ametros de los dispositivos conectados y de los filtros. En la captura de la ventana principal mostrada podemos ver un ejemplo con el protocolo SimpliciTI y los datos del protocolo de comunicaci´on desarrollado en medio de la etapa de formaci´on de la red. En la barra de estado (parte inferior izquierda de la ventana) se encuentra un contador de paquetes capturados, otro para el numero de paquetes con errores (por desbordamiento del b´uffer o por errores de CRC) y el estado actual del filtro. Menus y barra de tareas En la siguiente figura (figura 4.20) mostramos los botones de la barra de la parte superior de la ventana principal: Los botones y sus funciones son, de izquierda a derecha: 1. Vac´ıa el buffer y la lista de paquetes (tambi´en accesible desde el men´u File→Reset) 4.5. SMARTRF PACKET SNIFFER 89 Figura 4.19: Ventana principal del Packet Sniffer Figura 4.20: Barra de tareas del Packet Sniffer 96 CAP´ ITULO 5. IMPLEMENTACI´ ON Figura 5.1: Esquema de conexiones de un puente Wheatstone puente son exactamente iguales la salida Vs ser´a 0V. Sin embargo, si cualquiera de las resistencias var´ıa m´ınimamente Vs pasar´a a ser distinto de 0V. ´ Este comportamiento se modela con la siguiente ecuaci´on: V s =R4 R2+R4 −R3 R1R3 ∗V Donde se puede ver claramente que si todas las R son iguales la ecuaci´on se resolver´a: V s = ( R 2R−R 2R)∗V= 0 ∗V= 0V Sin embargo, si R1 y R4 aumentan de forma solidaria al doble del valor de R2 y R3 la ecuaci´on se despeja: V s = ( 2R23 R23 + 2R23 ∗2R23 R23 + 2R23 )∗V=R23 3R23 ∗V= 2R23 ∗V Obviamente, el resultado ser´ıa el mismo si en lugar de aumentar R1 y R4, fueran R2 y R3 las que disminuyeran. Se ve claramente que en ´esta situaci´on, Vs aumentar´a a valor positivos. De forma an´aloga, si R2 y R3 aumentan (o R1 y R4 disminuyen) Vs se obtiene de la siguiente forma: 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 97 V s = ( R14 2R14 +R14 −2R14 R14 + 2R14 )∗V=R14 3R14 ∗V= 2R14 ∗V Por lo que claramente se deduce que para valores de R2 y R3 superiores a R1 y R4 en la salida obtendremos tensiones negativas. El puente puede ser usado de distintos modos. Usando tres resistencias fijas y una activa (cuarto de puente) que ser´a la que var´ıe su valor en funci´on de alg´un factor externo (en nuestro caso ser´a la galga que variar´a su resistencia en funci´on de la deformaci´on), usando dos resistencias fijas y dos activas (medio puente), o usando las cuatro resistencias como elementos activos (puente completo). Cuarto de puente Con una configuraci´on en cuarto de puente obtenemos la m´ınima sensibilidad ya que s´olo disponemos de un elemento activo que var´ıa su resistencia, las otras tres resistencia son fijas. ´ Esta configuraci´on es la m´as econ´omica ya que los elementos activos son notablemente m´as caros que una simple resistencia, pero no ofrecen una gran sensibilidad como demostraremos a continuaci´on. Figura 5.2: Esquema de conexiones de un cuarto de puente Wheatstone Suponiendo que R1 es el elemento activo y R2=R3=R4=Rf, y que el valor m´aximo que adquiere R1= 2Rf, se deduce: 98 CAP´ ITULO 5. IMPLEMENTACI´ ON V s = ( Rf Rf+Rf −Rf 2Rf+Rf )∗V=1 6∗V= 0,166666 . . . ∗V Medio puente En ´este caso disponemos de dos elementos activos y dos resistencias fijas. Figura 5.3: Esquema de conexiones de medio puente Wheatstone Los elementos activos var´ıan sus resistencias de forma solidaria, es decir, R1 siempre es igual a R4, R2 y R3 son resistencias fijas de igual valor. V s = ( 2Rf Rf+ 2Rf −Rf 2Rf+Rf )∗V=1 3∗V= 0,33333 . . . ∗V Puente completo Para obtener el m´aximo valor de salida del puente para ´este caso hay que tener en cuenta que las galgas tienen un valor nominal en reposo y que pueden variar para aumentar respecto de ese valor nominal o disminuir. As´ı pues, el caso m´as extremo en ´esta configuraci´on es que R1 y R4 aumenten al m´aximo su valor respecto al nominal y R2 y R3 a su vez disminuyan al m´ınimo su valor respecto del nominal. De ´este modo suponiendo que R1, R2, R3 y R4 son los elementos activos, R2=R3=Rnom/2, y que R1=R4=2Rnom, se deduce: 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 99 V s = ( 2Rnom Rnom/2+2Rnom −Rnom/2 2Rnom +Rnom/2)∗V=3 5∗V= 0,6∗V Al observar todas las configuraciones resulta ya evidente que el puente completo ofrece una sensibilidad mucho mayor que las otras configuraciones a cambio de usar cuatro elementos activos, que, obviamente, encarecen el sensor. Figura 5.4: Esquema de conexiones de puente Wheatstone completo Adem´as, el puente completo ofrece una ventaja a˜nadida, y es que al ser las cuatro resistencias activas e id´enticas, todas ellas son influenciadas del mismo modo por el calor, de ´este modo ´esta configuraci´on se auto-compensa por temperatura. Por ´estas razones, para nuestra aplicaci´on vamos a optar por conectar cuatro galgas en un puente Wheatstone completo. 5.1.3. C´alculo de la variaci´on de resistencia de las galgas extensiom´etricas Para dise˜nar el circuito amplificador primero hay que conocer de antemano entre qu´e valores oscilar´a su entrada. Para conocer ´estos valores antes debemos saber cu´anto se deformaran las galgas como m´aximo, ya que la elongaci´on de ´estas es directamente proporcional a la variaci´on de resistencia de las mismas. Dado que las galgas se deforman solidarias al material sobre el 100 CAP´ ITULO 5. IMPLEMENTACI´ ON que est´an adheridas, la deformaci´on m´axima que sufrir´an ´estas ser´a la deformaci´on m´axima del material sobre el que est´an midiendo. Sin embargo, la deformaci´on m´axima que sufrir´a el material no es algo trivial de hallar, ya que cada material tiene unas caracter´ısticas distintas, y ´estas a su vez cambian cuando se alea con otro material, y var´ıan adem´as seg´un las proporciones de la aleaci´on. Dado que nuestra aplicaci´on est´a orientada a medir deformaciones en estructuras met´alicas empleadas en la construcci´on podemos acotar considerablemente la variedad de metales a tener en cuenta dado que en la construcci´on se emplean determinados tipos de aleaciones de acero est´andar. Es por ello que para simplificar el dise˜no de la electr´onica entre otras cosas, asumiremos que mediremos deformaciones sobre acero de tipo S275JR ya que es el tipo de acero mas com´un en la construcci´on. Fundamentos b´asicos de mec´anica de materiales Todos los materiales lineales sometidos a una deformaci´on se caracterizan por presentar dos comportamientos distintos ante la misma. Para tensiones hasta un limite σ, los materiales se deforman, pero una vez desaparece la tensi´on el material vuelve a su forma inicial. Para tensiones mayores a σ, una vez desaparece la tensi´on, el material queda deformado de forma permanente. A ´estos dos comportamientos se les denomina comportamiento el´astico y comportamiento pl´astico respectivamente, y a la tensi´on l´ımite σque separa la zona el´astica de la zona pl´astica se le denomina l´ımite el´astico del material. Dicho l´ımite el´astico es una caracter´ıstica propia de cada tipo de material. En la figura 5.5 podemos ver ambas zonas bien diferenciadas. Figura 5.5: Gr´afica tensi´on/deformaci´on del acero 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 101 Obviamente, para nuestra aplicaci´on nos interesa medir los materiales en la zona el´astica de los mismos. Si una viga o pilar sufriera una tensi´on suficiente y ´este entrara en su zona pl´astica, dicho material sufrir´ıa deformaciones importantes y permanentes por lo que probablemente la estructura de la que dependa la integridad del pilar o viga deformados se ver´ıa gravemente comprometida de forma inmediata e irreversible. Dado que en ´este caso extremo, medir la deformaci´on carecer´ıa de sentido en una aplicaci´on real por razones obvias, nos centraremos en medir las deformaciones de la zona el´astica del material ya que ´estas son las m´as comunes y las que conviene vigilar dado su peligro potencial y la capacidad de reacci´on ante una situaci´on en la que se presente dicho peligro. Para caracterizar el comportamiento de los materiales el´astico sometido a una fuerza se usa el modulo de Young. Dicha constante es distinta para cada material y es la misma para tracci´on y para compresi´on para materiales el´astico lineales is´otropos1como el acero. Adem´as puede ser calculada mediante la siguiente ecuaci´on: E= σ Donde E = Modulo de Young, σ= Tensi´on aplicada al material (N/mm2) y = deformaciones2. Conociendo dichos datos ya podemos calcular la deformaci´on m´axima del material. La deformaci´on que consideraremos como m´axima para nuestra aplicaci´on ser´a la deformaci´on sufrida por el material en el l´ımite el´astico por las razones antes citadas. Dado que el acero tiene una constante de Young de 210000 N/mm2y el l´ımite el´astico de dicho material en el rango de temperatura 16 <t<= 40 es de 265 N/mm2, calculamos: =σ E=265 210000 = 10261904762µ Anteriormente definimos el factor de galga como: K=∆R/R ∆L/L Dado que ∆L L=, siendo el valor antes calculado para el material ya que la galga se deformar´a de forma solidaria al material, redefinimos el factor de galga como: 1Es la caracter´ıstica de los cuerpos cuyas propiedades f´ısicas no dependen de la direcci´on 2Unidad de medida adimensional que representa la variaci´on de elongaci´on respecto a la longitud inicial 102 CAP´ ITULO 5. IMPLEMENTACI´ ON K=∆R/R  Siendo K el factor de galga que nos proporciona el fabricante en cada lote, la deformaci´on calculada y R el valor nominal de resistencia de la galga que tambi´en es conocido, ya podemos saber cual ser´a la variaci´on de R que sufrir´a la galga ante la deformaci´on sufrida en el l´ımite el´astico del material. K=∆R/R →∆R R=K∗→∆R 350 = 20105 ∗10262 ∗10−3→ ∆R 350 = 20656 ∗10−3→∆R= 20656 ∗10−3∗350 = 0092971Ω Tenemos que, para la deformaci´on en el l´ımite el´astico, cada galga variar´a ±+−0092971Ω ≈0093Ω, ya que la deformaci´on puede ser positiva (a tracci´on) o negativa (a compresi´on). 5.1.4. C´alculo de la salida del puente Una vez tenemos el rango de valores entre los que oscila la variaci´on de resistencia de las galgas respecto del valor nominal, es trivial calcular los valores entre los que oscilar´a la salida del puente Wheatstone. As´ı pues, solo tenemos que aplicar la ecuaci´on del puente Wheatstone. V s = ( R4 R2+R4 −R3 R1+R3 )∗V Valor m´ınimo de salida (m´aximo negativo) El valor m´aximo negativo se dar´a cuando R2 y R3 alcancen su m´aximo valor mientras que R1 y R4 alcancen su m´ınimo valor. Sabiendo que el valor nominal de las galgas en reposo es de 350 Ohm y la tensi´on de alimentaci´on del puente ser´a de 5V, calculamos: V s = ( 350 −0,93 350 + 0,93 + 340 −0,93−350 + 0,93 350 −0,93 + 350 + 0,93)∗5 = −0,01328571428V Valor m´aximo de salida (m´aximo positivo) El valor m´aximo positivo del puente se dar´a cuando R1 y R4 lleguen a su m´aximo valor de resistencia al tiempo que R2 y R3 llegan a su valor m´ınimo. As´ı pues, con los mismos valores que en el punto anterior calculamos: 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 103 V s = ( 350 + 0,93 350 −0,93 + 340 + 0,93−350 −0,93 350 + 0,93 + 350 −0,93)∗5 = 0,01328571428V 5.1.5. Amplificador Una vez tenemos el valor m´ınimo y m´aximo que nos entregar´a el puente Wheatstone ante la m´axima deformaci´on que puede sufrir el material sobre el que vamos a medir, ya podemos realizar los c´alculos oportunos concernientes al amplificador que nos proporcionar´a unos valores de tensi´on adecuados para trabajar en las posteriores etapas de tratamiento de la se˜nal. El amplificador va a jugar un papel esencial en nuestro circuito de adaptaci´on de la se˜nal proveniente de las galgas extensiom´etricas. La salida del puente Wheatstone ir´a directamente conectada a la entrada de nuestro amplificador, ´este amplificar´a dicha se˜nal y la salida se la aplicaremos a un conversor anal´ogico-digital para que convierta la se˜nal amplificada a una se˜nal digital. Sin embargo, el puente Wheatstone nos puede entregar tanto tensiones positivas como negativas en funci´on de si las galgas son deformadas a tracci´on o a compresi´on (el perfil flexa en un sentido o en otro). Si conectaramos el puente de galgas directamente al amplificador, cuando el puente entregara tensiones positivas el amplificador entregar´ıa a su salida tensiones positivas. Figura 5.6: Amplificador con tensi´on de entrada positiva Sin embargo, dado que el amplificador en reposo nos entrega 0V, si a su entrada le inyect´aramos una se˜nal negativa, a la salida seguir´ıamos teniendo 0V ya que el amplificador no es capaz de entregar tensiones negativas estando alimentado a una tensi´on de Vcc.´ Esto supone un problema ya que s´olo ser´ıamos capaces de medir deformaciones en un sentido. Es decir, no podriamos las deformaciones que se produjeran en el sentido para el cual el puente Wheatstone entregara tensiones negativas. Una forma de solucionar dicho problema ser´ıa alimentando el amplificador con una tensi´on sim´etrica en el rango de ±Vcc. De ´este modo el amplificador ser´ıa capaz de entregar tensiones negativas amplificadas en la salida. 104 CAP´ ITULO 5. IMPLEMENTACI´ ON Figura 5.7: Amplificador con tensi´on de entrada negativa Sin embargo, ´esta soluci´on plantea otros problemas, y es que para generar una tensi´on sim´etrica a partir de bater´ıas ser´ıa necesario el montaje de dos bater´ıas independientes como muestra la siguiente figura. Figura 5.8: Esquema de una fuente sim´etrica fabricada con dos bater´ıas id´enticas ´ Esto plantea serios problemas en tanto en cuanto las bater´ıas nunca ser´an exactamente iguales ni se desgastaran por igual, lo que provocar´ıa una asimetr´ıa en la alimentaci´on que afectar´ıa a las mediciones y ser´ıa dif´ıcil de corregir. Adem´as implicar´ıa el tener que montar dos bater´ıas en cada nodos, lo cual aumentar´ıa de volumen cada uno de los mismos as´ı como los costes. La soluci´on que se ha adoptado consiste en desplazar el valor de salida del amplificador en reposo de 0V a Vcc/2. De ´este modo, la salida del amplificador en reposo ser´a la mitad de la alimentaci´on. Cuando se le inyecte una tensi´on 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 105 positiva a la entrada del amplificador ´este amplificar´a hasta un valor m´aximo de Vccy, an´alogamente, cuando se le inyecte una tensi´on negativa a la entrada ´este amplificar´a pero en t´erminos negativos hasta 0V. ´ Esta soluci´on tiene la desventaja de que perdemos la mitad del rango de valores en la salida del amplificador y, por lo tanto perdemos tambi´en resoluci´on, pero es una perdida asumible a cambio de ganar enormemente en simplicidad. Para obtener el comportamiento descrito anteriormente se aprovecha uno de los terminales del CI3del amplificador llamado Vref .´ Este terminal tiene la finalidad de fijar la tensi´on de salida en reposo del amplificador. Es decir, la tensi´on que se le suministre a ´este terminal ser´a la tensi´on que usara como punto de partida para amplificar. Figura 5.9: Amplificador con tensi´on de entrada 0V y Vref Si fijamos la tensi´on de alimentaci´on a Vcc, Vref a Vcc/2 y le suministramos a la entrada tensiones positivas, amplificara la tensi´on de entrada en un factor G(configurable), a ´esta le sumar´a Vref y la tensi´on resultante la entregar´a a la salida. An´alogamente, si le suministramos a la entrada tensiones negativas llevar´a a cabo la misma operaci´on, con la diferencia de que, al ser una tensi´on negativa, una vez amplificada Gveces la restar´a a Vref , por lo que obtenemos el comportamiento deseado sin necesidad de tensiones de alimentaci´on sim´etricas. De ´esta forma obtenemos un amplificador que, de forma simple y precisa amplifica la d´ebil se˜nal del puente Wheatstone en el rango de ≈0V hasta <Vcc/2 para tensiones positivas, es decir, cuando el material se deforma en un sentido dado, y en el rango de tensiones desde >Vcc/2 hasta ≈Vcc cuando 3Circuito Integrado 112 CAP´ ITULO 5. IMPLEMENTACI´ ON SPI. Sin embargo, el registro empleado para almacenar los datos le´ıdos tiene una longitud de 8 bits. ´ Esto plantea muchos problemas ya que nuestro CAD nos entrega se˜nales de 16 bits, por lo que, para leer los datos del CAD mediante una USART nos ver´ıamos obligados a realizar dos lecturas de 8 bits para obtener la palabra de 16 bits que nos proporciona el CAD. En lugar de ´esto, por simplicidad se ha optado por no emplear las USART del microcontrolador. En lugar de ello se ha optado por conectar las se˜nales de SPI a los puertos de E/S de prop´osito general del microcontrolador e implementar el protocolo SPI mediante software. De ´este modo, podremos controlar totalmente la comunicaci´on y hacer posible la lectura de 16 bits que requiere la comunicaci´on con el CAD. Implementaci´on de la comunicaci´on SPI Para que la comunicaci´on SPI se lleve a cabo con ´exito hay que seguir un protocolo determinado entre el dispositivo maestro y el esclavo. En nuestro caso particular el microcontrolador asumir´a el papel de maestro y el CAD asumir´a el papel de esclavo. El protocolo a emplear se divide en tres fases que llamaremos: muestreo, conversi´on y apagado. En la fase de muestreo en primer lugar hay que deshabilitar la se˜nal de CS (es activa a nivel bajo), a partir de ese instante la se˜nal de reloj debe ser 0 y no puede pasar a nivel alto hasta que pase un tiempo m´ınimo tsucs. Pasado ese intervalo de tiempo se deben generar entre 4,5 y 5 ciclos de reloj durante los cuales el CAD realiza el muestreo de la se˜nal. Aqu´ı terminar´ıa la etapa de muestreo del CAD y dar´ıa paso a la etapa de conversi´on. En la etapa de conversi´on se deben generar 16 ciclos de reloj durante los cuales el CAD env´ıa los 16 bits correspondientes a la se˜nal digital codificada. Para leer ´estos 16 bits hay que tener en cuenta que el CAD enviar´a un bit por cada flanco de subida que genere el reloj y que ´este lo har´a empezando por el bit m´as significativo. Una vez finalizados los 16 ciclos de reloj, si seguimos generando el reloj sin poner la se˜nal CS a nivel alto el CAD volver´a a enviar la misma secuencia de bits pero en orden inverso, es decir empezando por el bit menos significativo. Tanto si obtenemos solo la se˜nal MSB como si esperamos a que genere tambi´en la se˜nal LSB, al terminar de enviarnos los datos debemos proceder con la etapa de apagado. En la etapa de apagado seguiremos generando 3 ciclos m´as de reloj al tiempo que ponemos a 1 la se˜nal CS. Finalizados ´estos 3 ciclos, el CAD estar´a en disposici´on de volver a convertir otra se˜nal. La figura 5.14 muestra con detalle como quedar´ıan las se˜nales de CS, reloj y salida digital en ´ese mismo orden. Para llevar a cabo todo ´este proceso se han usado los puertos de E/S de prop´osito general del microcontrolador tal y como se describe en la tabla 5.1. Para implementar el protocolo SPI en el microcontrolador se hizo uso del timer 1 que proporciona el microcontrolador. Dicho timer se programa para 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 113 Figura 5.14: Cronograma de las se˜nales del CAD Puerto E/S Prop´osito P0 2 Se˜nal de reloj P1 0 CS P2 0 Datos digitales Tabla 5.1: Relaci´on de los puertos de E/S usados para el CAD que genere aproximadamente una interrupci´on cada 1 25 milisegundos (25kHz). Se ha elegido ´este periodo porque ´esta interrupci´on ser´a la encargada de generar la se˜nal de reloj para el CAD y ´este admite una frecuencia m´ınima de reloj de 24kHz (se deja 1kHz de margen para no trabajar sobre el m´ınimo). Para programar el timer 1 para que genere esa frecuencia de llamadas a interrupci´on se asignan los siguientes valores a los registros correspondientes. De ´este modo, cuando se desee leer el valor del CAD tan s´olo habr´a que habilitar el timer 1 con ´estos valores. La rutina de la interrupci´on se ha programado de forma que en cada llamada invierta el valor de P0 2 y al mismo tiempo act´ue en consecuencia dependiendo del n´umero de ciclo en el que se encuentre. Si est´a en los ciclos correspondientes a la etapa de muestreo no har´a nada mas que generar la se˜nal de reloj, si por el contrario est´a en alg´un ciclo correspondiente a la etapa de conversi´on y el valor de la se˜nal de reloj antes de invertirla era 0 (flanco de subida), acumular´a el bit de P2 0 en una variable (desplazando a la izquierda el resto de bits existentes en la variable), y por ´ultimo, si se encuentra en alguno de los ciclos de apagado no har´a nada (excepto activar CS en el primero de ´estos ciclos). Una vez se cumplen los 24 ciclos de reloj necesarios para el protocolo SPI el timer se desactiva y la variable que acumula los 16 bits transmitidos por el CAD ya est´a lista para ser le´ıda. 114 CAP´ ITULO 5. IMPLEMENTACI´ ON 5.1.7. Tensiones de alimentaci´on En ´este tipo de dispositivos en los que se usan se˜nales del orden de milivoltios se hace imperativo la precisi´on de todos los componentes que vayan a intervenir de alguna forma en dichas se˜nales. Adem´as, en ´estas situaciones es extremadamente importante la precisi´on de las alimentaciones de todos los componentes, ya que cualquier variaci´on en las alimentaciones puede repercutir muy seriamente en el funcionamiento de ´estos. En nuestro caso cobra aun m´as importancia si cabe la alimentaci´on en el puente Wheatstone ya que cualquier variaci´on en su alimentaci´on provocar´a una variaci´on proporcional en la salida de ´este, y dada la amplitud m´axima de la se˜nal del puente (≈ ±13,28mV ) no nos podemos permitir variaciones del mismo orden de magnitud o superior. Dado que los nodos est´an dise˜nados para ser alimentados con bater´ıas nos alivia un poco la problem´atica ya que las baterias carecen del rizado t´ıpico de las fuentes de alimentaci´on que transforman la se˜nal senoidal de la red de suministro el´ectrico en una se˜nal continua. Sin embargo, las baterias no son perfectas y requieren igualmente alguna etapa de estabilizaci´on de tensi´on. Para ello usaremos tensiones de referencia fijas proporcionadas por unos circuitos integrados dise˜nados ex profeso por Texas Instruments. ´ Estos circuitos integrados est´an dise˜nados para proporcionar una tensi´on de alimentaci´on fija y extremadamente estable. Cada modelo de integrado proporciona un valor de tensi´on determinado y fijo, es decir, es un valor prefijado de f´abrica, por lo que existen un n´umero limitado de valores de tensi´on de salida entre los que elegir. ´ Estos circuitos funcionan de forma muy sencilla, tan s´olo hay que alimentarlos con una tensi´on de alimentaci´on de como m´ınimo 0.2V superior a la tensi´on de salida para la que est´an dise˜nados y en la salida nos entregar´an exactamente la tensi´on de referencia. Es decir, si el circuito est´a dise˜nado para entregar 5V en la salida, como m´ınimo deber´ıamos de alimentarlo con 5.2V para que funcione correctamente. En concreto usaremos las tensiones de referencia de Texas Instruments modelos REF50xx. Para elegir las tensiones de alimentaci´on primero debemos tener en cuenta la restricciones que nos impone nuestro circuito por su dise˜no. A priori el puente Wheatstone no nos impone restricci´on en cuanto a tensiones m´ınimas ya que su salida ir´a al amplificador y al ser ´esta salida una tensi´on diferencial no importa en exceso el valor de la tensi´on a la que est´e alimentado el puente ya que su salida ser´a much´ısimo menor. En todo caso nos interesa que ´esta sea lo m´as alta posible ya que cuanto m´as alta sea, mas alta ser´a la tensi´on de salida, lo cual har´a ´esta d´ebil se˜nal m´as inmune al ruido y el no deberemos amplificarla tanto en la siguiente etapa, por lo que ganaremos en precisi´on. Sin embargo, cuanto mas alta sea ´esta tensi´on de alimentaci´on m´as potencia consumir´a el puente, y el consumo es cr´ıtico en nodos aut´onomos como los nuestros. Por esta raz´on, hemos elegido una tensi´on de 5V ya que, como 5.1. TARJETA DE ADAPTACI´ ON DE SENSORES 115 veremos m´as adelante, es la tensi´on m´as alta de entre las que necesitar´an el resto de etapas para alimentarse. Podr´ıamos haber elegido una mayor, pero ´esto nos habr´ıa obligado a incluir en la tarjeta de adaptaci´on otro circuito integrado para proporcionar ´esa tensi´on de referencia exclusivamente para el puente Wheatstone, adem´as de aumentar el consumo como se ha dicho anteriormente. El amplificador INA333 puede operar con tesiones de alimentaci´on en el rango de 1,8V y 5,5V. ´ Este es un dato a tener en cuenta, no obstante, el condicionante es que, por el dise˜no que hemos hecho, ´este amplificador necesita que su entrada Vref sea exactamente la mitad de su tensi´on de alimentaci´on para que funcione correctamente (para tener el mismo rango de salida para tensiones de entrada negativas como positivas). Como ya hemos dicho anteriormente Texas Instrumentas proporciona un n´umero muy limitado de tensiones de referencia distintas (es l´ogico ya que son tensiones elegidas en f´abrica) y el ´unico par de tensiones de referencia que cumplen Vref1=Vref2/2 son 2,048V y 4,096V respectivamente, por lo que estamos obligados a usar una tensi´on de alimentaci´on para el amplificador de 4,096V (por suerte entra dentro del rango de alimentaciones en las que puede operar el amplificador) y 2,048V para la entrada Vref del amplificador. As´ı cumplimos las restricciones que ten´ıamos impuestas para el amplificador. Para el CAD tenemos que puede operar en el rango de 2V hasta 5,25V. Adem´as tenemos otra restricci´on proveniente de la tensi´on de salida del amplificador. Dado que el amplificador estar´a alimentado a 4,096V sabemos que como m´aximo su salida ser´a muy cercana a ´ese valor, pero nunca se llegar´a a dar. El CAD necesita dos tensiones estables: la de alimentaci´on, y la de referencia. La tensiones de referencia es la que usar´a el CAD para definir como valor m´aximo de entrada, es decir, se corresponde con el valor de tensi´on de entrada para el que la salida digital ser´a todo 1. En nuestro caso ´esta tensi´on de referencia deber´a corresponderse con el valor m´aximo que nos puede entregar el amplificador. Aunque, como hemos dicho anteriormente, el amplificador te´oricamente no llegar´a nunca a entregar la tensi´on de alimentaci´on de 4,096V, asumiremos que puede llegar a estar tan cerca que esa ser´a la tensi´on m´axima que le puede llegar a la entrada del CAD, por lo que la entrada Vref del CAD la fijaremos a 4,096V. Dado que la tensi´on de alimentaci´on del CAD debe estar por encima de la tensi´on de referencia alimentaremos a ´este con 5V ya que es la tensi´on inmediatamente superior a 4,096V que nos proporciona Texas Instruments. Y con ´esto tenemos todas las tensiones estables cubiertas por lo que el dise˜no de nuestro circuito ya se puede dar por terminado. 116 CAP´ ITULO 5. IMPLEMENTACI´ ON 5.2. Protocolo de comunicaci´on de la red de sensores En el Manual del programador del Anexo B.1 se presentan principalmente bibliotecas implementadas para el manejo de las estructuras de datos creadas para el protocolo de comunicaci´on. No en vano el desarrollo de esas estructuras y las bibliotecas han ocupado gran parte del tiempo de desarrollo del proyecto. La otra parcela l´ogica que se ha llevado gran parte del peso temporal dedicado a la implementaci´on ha sido la comunicaci´on de los nodos, cuya descripci´on se presenta a lo largo del Tema 3. En esta secci´on, por otra parte, se pretende ver de cerca algunos de los algoritmos m´as representativos que se han desarrollado as´ı como una visi´on detallada de algunas de las estrategias tomadas en la programaci´on de los nodos. 5.2.1. Implementaci´on de la comunicaci´on en los nodos M´as all´a de las estructuras usadas y de las bibliotecas, la clase principal de los nodos que componen la red implementa la comunicaci´on en una serie de bucles que comprueban peri´odicamente los flags de recepci´on e ID para situarse en el diagrama de comunicaci´on. Estos flags conforman una parte importante de la implementaci´on del protocolo de red y por ende, de los nodos. Los bucles iteran con uno de los temporizadores como guarda (adem´as de otras condiciones dependiendo del punto de ejecuci´on en el que se encuentren) del mismo y comprobar´an el flag de recepci´on para ver si se ha recibido alg´un paquete. El flag de recepci´on es un byte que cambia de valor cuando se ejecuta una interrupci´on de la radio. Durante dicha interrupci´on tambi´en se procesa el paquete almacen´andolo en la estructura que facilita el SimpliciTI llamada ioctlRawReceive t y se extrae el valor del ID (los primeros cuatro bits del primer byte recibido) para almacenarlo en otro flag. Finalmente se vac´ıa el buffer de recepci´on ya que podemos considerar que se ha terminado el procesamiento del paquete. Cuando se termina la interrupci´on y se vuelve al programa principal se comprobar´a de nuevo el flag de recepci´on, se encontrar´a el flag de recepci´on activo y se proceder´a a desactivarlo y a ejecutar la acci´on que corresponda seg´un el diagrama de comunicaci´on presentado en el tema 3. El flag ID se utiliza en caso de que se est´e en un estado susceptible de recibir distintos tipos de paquetes, utiliz´andolo por ejemplo como condici´on de una clausula case. 5.2. PROTOCOLO DE COMUNICACI´ ON DE LA RED DE SENSORES 117 5.2.2. Algoritmos representativos Formaci´on del grafo a partir de las Tablas de Intensidades Este proceso se ejecuta siempre que termina la etapa de formaci´on de la red y no se repite hasta que se reinicie la red por alg´un motivo. Formar el grafo, por tanto, solo se produce una vez. El resto de operaciones son de alteraci´on de los atributos, el c´alculo de los caminos m´ınimos sobre el grafo construido o la eliminaci´on de alguno de los v´ertices si ´este ha producido alg´un error. Algoritmo 1 Formaci´on del grafo Entrada: Grafo inicializado (grafo) y las Tablas de Intensidades formadas (iTable) Salida: Grafo formado con la informaci´on de las Tablas de Intesidades 1: para i= 0 hasta iTable.length (n´umero de tablas almacenadas) hacer 2: idO ←0 3: si (idO = indice de del nodo iTable[i]) >grafo.length entonces 4: idO = inserta un nuevo v´ertice con la direcci´on de iTable[i] y devuelve su ID 5: fin si 6: para j= 0 hasta iTable.iTable[i].length (n´umero de filas en la tabla) hacer 7: A= nodo A (tabla  i  ) respecto al nodo B (fila  j  ) 8: B.RSSI = nivel RSSI con que el nodo B ha registrado al nodo A 9: B.batera = nivel de bater´ıa del nodo B 10: pond =A.RSSI ∗B.RSSI − |A.RSSI −B.RSSI|+A.batera ∗ B.batera − |A.batera −B.batera| 11: Inserta un nuevo arco de A (idO) a B con valor pond (inserta el v´ertice B si no existe) 12: fin para 13: fin para Para ponderar un arco se debe tener en cuenta tanto el nivel de bater´ıa de ambos nodos, como la intensidad de se˜nal con la que ambos nodos se registraron entre s´ı. Es por este motivo por el que, aunque quiz´a queda algo ambiguo en el pseudoc´odigo mostrado en el algoritmo 1, se hace una b´usqueda para extraer los datos del nodo  B  antes de ponderar el arco. En la formaci´on del grafo se utilizan las funciones de la biblioteca de nodeGprah.h descrita en la secci´on B.1.2. Por medio de su uso se intenta facilitar precisamente la formaci´on del grafo seg´un el algoritmo descrito, por esto algunas de las b´usquedas incluyen la inserci´on del nodo si este no se encuentra a´un en el grafo. Y de ah´ı a su vez que antes de insertar un nuevo 118 CAP´ ITULO 5. IMPLEMENTACI´ ON v´ertice se compruebe si ya existe o no en la l´ınea 3del algoritmo anterior. Esto se traduce en un varios bucles anidados m´as en cada b´usqueda, cortocircuitados para intentar optimizar el recorrido de b´usqueda. De modo que el coste temporal resultante del algoritmo es relativamente elevado. Esto sin embargo no supone ning´un problema en la aplicaci´on de la red de sensores. El algoritmo se ejecuta en un punto entre la formaci´on de la red y la etapa est´andar en la que la criticidad del tiempo es nula, y m´as teniendo en cuenta que las limitaciones energ´eticas no est´an presentes en el caso del nodo sumidero. Una vez formado del grafo se calculan los caminos m´ınimos y se env´ıa toda la informaci´on a la estaci´on base a trav´es de la UART. Programaci´on del macro-frame Este es el algoritmo recursivo que programa el macro-frame por ramas seg´un lo explicado en el punto 3.2.6. El caso base de dicho algoritmo es encontrar un v´ertice sin enlaces por procesar. La ejecuci´on se produce exactamente como se ha relatado en el punto 3.2.6, bajando de la ra´ız a las hojas y luego subiendo por la rama del ´arbol programando marcos temporales. Algoritmo 2 Programaci´on del macro-frame Entrada: V´ertice ra´ız Salida: Array de direcciones con la programaci´on y n´umero total de frames nodesInRoute ←1 2: para i= 0 hasta i < longitud de la lista de arcos del nodo ra´ız hacer nodeAct ←nodo  i  de la lista de arcos 4: si El punto de inter´es de nodoAct apunta a r´aiz entonces countSubTree = llamada recursiva a la funci´on con nodoAct como ra´ız 6: A˜nadir el enlace en el array de programaci´on nodesInRoute =nodesInRoute +countSubTree 8: fin si fin para 10: devolver nodesInRoute Una de las ventajas del algoritmo es que el par´ametro de entrada de nodo ra´ız no tiene necesariamente que coincidir con el nodo ra´ız del ´arbol (que ser´ıa el sumidero por definici´on). As´ı, si se produce alg´un error y se programa un macro-frame de emergencia, como ya se ha indicado con anterioridad, solo se programa para el sub´arbol que cuelga del nodo que ha producido el error. 5.2. PROTOCOLO DE COMUNICACI´ ON DE LA RED DE SENSORES 119 De modo que si la llamada a la funci´on desde el c´odigo principal se hace con el nodo que produjo el error se obtendr´a la programaci´on por ramas del sub´arbol que cuelga de dicho nodo. Posteriormente tan solo har´ıa falta completar la ruta de puntos de inter´es desde el nodo que produjo el fallo hasta el nodo sumidero. 5.2.3. Estrategias de programaci´on Retroceso Exponencial Binario Como ya hemos indicado en el punto 3.2.2 el paquete de contestaci´on al descubrimiento introduce un retardo mediante un algoritmo similar al de Retroceso Exponencial Binario de Ethernet y precisa de la detecci´on de portadora para hacer efectivo el env´ıo. El retardo se determina mediante una cantidad aleatoria de medidas temporales, que viene a su vez determinada en m´odulo por el algoritmo de retroceso exponencial binario mediante la f´ormula: R=Random Number m´od (2k−1) Donde kes el n´umero de reintentos y Random Number es el n´umero aleatorio generado. En el microcontrolador del CC1110 presenten en los nodos WSNVAL existen registros para la generaci´on del n´umero aleatorios que se utilizan en este caso concreto. La entrop´ıa necesaria para la generaci´on de n´umeros aleatorios se obtiene por defecto de los registros del CAD. Esta opci´on sin embargo resulta tan solo en n´umero pseudo-aleatorios. La otra opci´on para la obtenci´on de la entrop´ıa es la de escribir manualmente un registro del microcontrolador dos veces para determinar una semilla. En la generaci´on de n´umeros aleatorios participan dos registros: RNDH y RNDL. Cada vez que se escribe en RNDL se copia su valor a RNDH. As´ı, al escribir dos veces establecemos primero la parte de mayor peso de la semilla y posteriormente la de menor peso. Para establecer la semilla que se escribir´a en los registro del microcontrolador se utiliza una lectura de las galgas extensiom´etricas como fuente entr´opica. Posteriormente para obtener un n´umero aleatorio partiendo de la semilla establecida se hace uso de la funci´on MRFI RandomByte() del SimpliciTI. Este proceso, junto con la detecci´on de portadora, se repite por completo en cada intento de env´ıo. 120 CAP´ ITULO 5. IMPLEMENTACI´ ON 5.3. Aplicaci´on puente USB-IGU La aplicaci´on puente es una aplicaci´on que reside en el terminal al que est´a conectado el nodo sumidero. ´ Esta aplicaci´on se encarga de recoger los datos que provienen de la red de sensores a trav´es del sumidero y volcarlos en una base de datos para que la IGU posteriomente pueda consultarlos con el fin de mostrarlos al usuario. Adem´as, la aplicaci´on puente actua de intermediario entre la IGU y la red de sensores, transmitiendo las se˜nales de control de la red con el fin de que el usuario pueda interactuar con la misma. En definitiva la aplicaci´on puente actua como nexo de uni´on entre la red de sensores, la base de datos y la IGU para que ´estos tres elementos funcionen de forma coordinada. A nivel de implementaci´on cabe destacar que la aplicaci´on puente tan s´olo necesita residir en el mismo terminal en el que se encuentra conectado el nodo sumidero. La base de datos puede residir fisicamente en otra maquina siempre y cuando desde el terminal donde se encuentra el puente se pueda acceder a la base de datos a trav´es de cualquier tipo de red, incluyendo el acceso a trav´es de Internet. Dado que la IGU se implementa como una p´agina HTML+PHP que extrae los datos a trav´es de la base de datos y se comunica con la aplicaci´on puente mediante WebSocket, el servidor HTTP que sirve la p´agina correspondiente a la IGU puede de igual forma residir en otra m´aquina distinta a la de la aplicaci´on puente y a la de la base de datos, con la misma condici´on respecto de la conectividad citada para la base de datos. A su vez, la IGU puede ser consultada desde cualquier terminal que tenga un navegador con soporte para CSS+JavaScript+WebSocket. En definitiva, gracias al dise˜no de la arquitectura Puente+BBDD+HTTP, obtenemos un sistema altamente distribuido que nos permite una gran flexibilidad. 5.3.1. Descripci´on del funcionamiento En primer lugar la aplicaci´on puente trata de abrir el puerto USB para establecer el canal de comunicaci´on con el sumidero. Obviamente si no lo consigue la ejecuci´on falla y devuelve el control a la consola del SO10. En el caso de establecer con ´exito el canal de comunicaci´on con el nodo sumidero lanza el hilo de ejecuci´on conexionIGU que se encarga de escuchar las peticiones de conexi´on WebSocket en el puerto 9321. Posteriormente se lanza otro hilo de ejecuci´on llamado consolaUsuario que ser´a el encargado de gestionar las ordenes que el usuario introduce desde la consola de comandos. Una vez lanzados ´estos dos hilos el hilo principal de ejecuci´on llama a la funci´on initListadoNodos que pone a 0 el campo estado de todas las tuplas de la tabla nodos de la BBDD y queda bloqueado en el sem´aforo mutexInicioRed. 10Sistemas Operativos 5.3. APLICACI´ ON PUENTE USB-IGU 121 ´ Este sem´aforo s´olo se libera cuando desde la consola de usuario o desde alguna IGU se ordena inicializar la red. Cuando ´esto sucede el hilo principal vuelve a la ejecuci´on y queda a la espera de datos desde el puerto USB. A partir de ´este momento comienza el procesamiento de paquetes provenientes del sumidero. Cuando llega un trama desde el puerto USB en primer lugar se analiza para determinar el tipo de trama recibida. Si la trama corresponde a la recepci´on del listado de nodos se llama a la funci´on getDatosNodos para que desensamble el paquete y organice los datos un vector de estructuras de tipo Nodo. Luego para cada nodo de la estructura comprueba si existe en la BBDD, si no existe lo inserta en la tabla nodos con el campo estado fijado a 2, de lo contrario lo activa mediante la funci´on activarNodo. La funci´on activarNodo pone a 1 el campo estado del nodo que est´a procesando en ´esa iteraci´on, dado que inicialmente todos los nodos de la tabla nodos tenian el campo estado a 0, los nodos que ya existian se han activado poniendo a 1 dicho campo y los nodos nuevos se han insertado con el mismo campo a 2 ´esta metodolog´ıa permite saber qu´e nodos existieron en alg´un momento en la red y ya no est´an disponibles (estado=0), los nodos que ya exist´ıan y siguen estando disponibles (estado=1) y los nodos nuevos (estado=2). Si la trama recibida es una trama de listado de nodos pero con longitud 1 (trama vac´ıa, solo contiene el campo identificador) significa que ha terminado el listado de nodos, por lo que se llama a la funci´on notifyIGU para notificar a las IGU del suceso. Si la trama que recibe la aplicaci´on puente es una trama de recepci´on de medidas se llama a la funci´on getDatosMedidasNodos, la cual desensambla el paquete y organiza la informaci´on de los nodos en un vector de estructuras de tipo Nodo para posteriormente insertar dichas medidas en la BBDD mediante la funci´on updateMedidas. Posteriormente se invoca a la funci´on notifyIGU que notifica a las IGU la recepci´on de medidas para que ´estas invoquen al script PHP con el fin de obtener los datos de las medidas de la BBDD. typedef struct { unsigned char addr[4]; unsigned char flags; unsigned short medida; unsigned char addrPadre[4]; char nivelRSSI; unsigned char battery; } Nodo; 128 CAP´ ITULO 5. IMPLEMENTACI´ ON Figura 5.15: Trama enviada por la UART Envio de datos en el lado de la aplicaci´on puente Para enviar datos desde la aplicaci´on puente el proceso es similar al seguido en el lado del microcontrolador. Primero se env´ıa un byte que contiene el tama˜no de los datos que se van a enviar inmediatamente despu´es, y luego se envian los datos ´utiles tal y como se muestra en la figura 5.16. Figura 5.16: Trama enviada por la aplicaci´on puente Protocolo de comunicaci´on Cuando la aplicaci´on puente se ejecuta ´esta abre el puerto USB donde est´a conectado el sumidero y se queda a la espera de la orden de inicializaci´on desde la consola o bien desde la IGU. En ´este momento tanto el sumdiero como la aplicaci´on puente quedan a la espera. Cuando se recibe la orden de inicializaci´on de la red el sumidero env´ıa una trama al sumidero notificando la inicializaci´on de la red e inmediatamente env´ıa una trama que contiene los par´ametros de configuraci´on que deben adoptar todos los nodos de la red. Es necesario enviar ´estos par´ametros de configuraci´on en el momento de inicializar la red ya que los nodos no conocen ´esta configuraci´on que est´a guardada en la base de datos o bien que ha sido modificada por el usuario en la IGU antes de ordenar la inicializaci´on de la red. Cuando el nodo sumidero recibe ´este par de tramas comienza la etapa de formaci´on de la red. Mientras tanto la aplicaci´on puente queda a la espera de recibir por el puerto USB el listado de nodos que tendr´a en posesi´on el sumidero cuando termine la etapa de formaci´on de la red. Cuando ´esta etapa de la red termina el nodo sumidero enviar´a las tramas que contienen la informaci´on sobre los nodos. ´ Estas tramas forman un listado de los nodos activos que existen en la red. ´ Este listado es necesario ya que durante la etapa est´andar de la red es posible que algunos nodos no emitan ninguna trama por lo que el ´unico momento en el que todos los nodos transmiten sus datos necesariamente es durante la etapa de formaci´on de la red, y la aplicaci´on 5.3. APLICACI´ ON PUENTE USB-IGU 129 puente debe recoger un listado de nodos para que pueda ser mostrado en la IGU ya que el usuario debe saber en todo momento de la existencia de la totalidad de los nodos, no s´olo los que transmitan datos en un determinado instante de tiempo. La aplicaci´on puente debe saber el momento en el que termina la etapa de formaci´on de la red para env´ıar una notificaci´on a la IGU. No obstante, dado que el sumidero puede enviar el listado de nodos mediante multiples tramas, ´este debe notificar a la aplicaci´on puente de alguna forma que el listado de nodos ha terminado y que, por lo tanto, la etapa de formaci´on de la red tambi´en lo ha hecho. Para ello el sumidero env´ıa un paquete con el mismo identificador que los paquetes que corresponden al listado de nodos pero con la diferencia de que ´este estar´a vacio. Con ´esto el sumidero informa de que la etapa de formaci´on de la red ha finalizado y se procede a iniciar la etapa est´andar. Una vez la apl´ıcaci´on puente detecta que la etapa de formaci´on de la red ha finalizado se queda a la espera de tramas que contengan informaci´on sobre las mediciones de deformaciones que est´an realizando los nodos. ´ Estas tramas pueden contener un n´umero arbitrario de nodos, sin embargo, por razones de consumo de memoria en el nodo sumidero ´este n´umero se ha limitado a un nodo por trama. Cuando la aplicaci´on puente llega a ´este punto se queda indefinidamente esperando tramas que contienen datos de medidas de los nodos y procesandolas para que la IGU las pueda mostrar por pantalla. Sin embargo, en ´este punto de la ejecuci´on puede darse el caso de que la IGU solicite realizar acciones sobre la red de nodos. ´ Estas acciones pueden ser: enviar nuevos par´ametros de configuraci´on a la red, solicitar una medici´on bajo demanda o reiniciar la red. En cualquiera de ´estos tres casos la aplicaci´on puente env´ıa un paquete especial que contiene un identificador distinto para cada acci´on a realizar. Cabe destacar que la aplicaci´on puente a nivel de implementaci´on no distingue las etapas en las que se encuentra la red, es decir, la aplicaci´on se limita a esuchar el puerto USB y realiza una acci´on u otra en funci´on del identificador de la trama que recibe, por lo que si recibiera una trama con un identificador que se correpondiera con una trama de listado de nodos, cuando supuestamente la red se encuentra en la etapa est´andar, la aplicaci´on procesaria sin problemas dicho paquete y no causar´ıa un mal funcionamiento de la aplicaci´on ni ninguna inconsistencia en la BBDD. ´ Esta caracter´ıstica permite a la aplicaci´on puente reaccionar ante un reinicio de la red sin tener que realizar ninguna acci´on especial. 130 CAP´ ITULO 5. IMPLEMENTACI´ ON Recepci´on del listado de nodos Las tramas correspondientes al listado de nodos las transmite el nodo sumidero al terminar la etapa de formaci´on de la red. La trama se divide en dos partes, la cabecera que contiene ´unicamente el identificador del paquete y la carga ´util que se compone de los datos un n´umero arbitrario de nodos. Como se puede observar el protocolo ofrece la posiblidad de enviar los datos de varios nodos en una misma trama, sin embargo, debido a la limitaci´on de memoria del nodo sumidero se ha restringido a un nodo por trama. La red soporta hasta 232 nodos, lo que supone que para que el nodo sumidero envie los datos de todos los nodos en una trama en el peor de los casos necesitaria primero almacenar en memoria la trama a enviar para posteriormente llevar a cabo el env´ıo. Por cada nodo se necesita almacenar en memoria 4 bytes de la direcci´on MAC del nodo, 4 bytes de la direcci´on MAC del nodo padre, 1 byte del nivel de RSSI y otro byte para el nivel de bateria. ´ Esto implica que para cada nodo que se env´ıe en la trama se necesitan 10 bytes de memoria, por lo que en el peor de los casos (con 232 nodos en la red) el nodo sumidero deber´ıa guardar en memoria 10 ∗232 bytes, o lo que es lo mismo 40GB de memoria. Ser´ıa absudo pues guardar en memor´ıa tal cantidad de datos para luego env´ıarla por lo que se ha decidido limitar a un nodo por trama. El formato de la trama de ´este tipo es el que se muestra en la figura 5.17. Figura 5.17: Formato de un paquete de listado de nodos Recepci´on de medidas ´ Este tipo de trama es la enviada por el sumidero cuando ´este recoge los datos de las mediciones de los nodos durante la etapa est´andar. Cabe notar que la trama es similar a la del listado de nodos. Sin embargo ´esta no necesita incluir la MAC del padre ya que se supone que si el padre de un nodo cambia el nodo sumidero enviar´a una trama de listado de nodos para actualizar dicho dato. No obstante, al contrario que la trama de listado de nodos, en ´esta trama s´ı que es necesario enviar el campo medici´on y el campo flags. El campo flags ahora se hace necesario ya que es posible que un nodo no env´ıe alguno de sus datos y la aplicaci´on puente debe saber qu´e datos contiene la trama y qu´e datos no. El formato de ´esta trama se puede ver en la figura 5.18. 5.3. APLICACI´ ON PUENTE USB-IGU 131 Figura 5.18: Formato de un paquete de recepci´on de medidas Env´ıo de la configuraci´on El env´ıo de los par´ametros de configuraci´on se realiza al inicio de la red y en cualquier momento siempre y cuando la red se encuentre en la etapa est´andar de la misma. Los par´ametros que se deben enviar para que la red pueda funcionar corresponden con el valor del periodo entre mediciones y los valores de los umbrales de medida, nivel de RSSI y nivel de bater´ıa. El formato del la trama correspondiente a los par´ametros de configuraci´on es el que se muestra en la figura 5.19. Figura 5.19: Formato de un paquete de envio de par´ametros de configuraci´on Medici´on bajo demanda El env´ıo de ´esta trama est´a limitado a realizarse ´unicamente durante el transcurso de la etapa est´andar de la red ya que no tendr´ıa sentido en otro momento. ´ Esta trama, al ser una orden sin necesidad de ning´un tipo de par´ametro, no necesita m´as que un identificador para que el sumidero sepa la orden que se le ha ordenado ejecutar. El formato de ´esta trama se puede observar en la figura 5.20. Figura 5.20: Formato de un paquete de envio solicitud de medici´on bajo demanda 132 CAP´ ITULO 5. IMPLEMENTACI´ ON Reinicio de la red El env´ıo de ´esta trama est´a limitado a realizarse ´unicamente durante el transcurso de la etapa est´andar de la red ya que no tendr´ıa sentido en otro momento. ´ Esta orden est´a concebida para reiniciar la red en el caso de un mal funcionamiento de ´esta o la necesidad de una reorganizaci´on de los enlaces, o por la necesidad de a˜nadir nuevos nodos a la red. ´ Esta trama, al ser una orden sin necesidad de ning´un tipo de par´ametro, no necesita m´as que un identificador para que el sumidero sepa la orden que se le ha ordenado ejecutar. El formato de ´esta trama se puede observar en la figura ??. Figura 5.21: Formato de un paquete de envio solicitud de reinicio de la red 5.3.3. Comunicaci´on puente-IGU Desde el punto de vista de la aplicaci´on puente, la comunicaci´on con el IGU comienza en el hilo conexionIGU, cuando ´este recibe una conexi´on de tipo WebSocket al puerto 9321. En ´ese instante se recogen las cabeceras que env´ıa el cliente y se invoca a la funci´on createHeaderForSend pas´andole dichas cabeceras como par´ametro. Dicha funci´on se encarga de generar las cabeceras de respuesta que deber´a env´ıar la aplicaci´on puente de vuelta al cliente WebSocket. ´ Esta funci´on genera las campos fijos de las cabeceras: string header("HTTP/1.1 101 Web Socket Protocol Handshake\r\n" "Upgrade: WebSocket\r\n" "Connection: Upgrade\r\n"); y las cabeceras que se pueden generar directamente de los valores de las cabeceras de la petici´on WebSocket. Para extraer datos de las cabeceras del cliente se utiliza la funci´on getHeader a la que se le proporciona las cabeceras originales y el nombre de la cabecera de la cual se quiere extraer su valor. header += string("Sec-WebSocket-Origin: ") + string(getHeader(cabeceras, "Origin", NULL, NULL, NULL)) + string("\r\n"); 5.3. APLICACI´ ON PUENTE USB-IGU 133 No obstante para generar la key que debe devolver la aplicaci´on puente calculada a partir de las tres keys que env´ıa el cliente se delega en la funci´on solveChallenge. A dicha funci´on se le proporcionan las tres keys enviadas por el cliente y retorna la key que debe devolver la aplicaci´on puente al final de sus cabeceras. Una vez generadas y enviadas todas las cabeceras que debe retornar la aplaci´on puente hacia el cliente WebSocket, un hilo de tipo listenClient toma el control de la comunicaci´on. Dicho hilo recoge los datos enviados por el cliente y realiza las acciones oportunas. Protocolo de comunicaci´on Una vez se establece la conexi´on WebSocket la aplicaci´on puente espera que el cliente envie tres bytes. ´ Esta secuencia de caracteres debe corresponderse con los caracteres 0x00, 0x76, 0xFF. El primer y ´ultimo caracter se corresponden con los delimitadores de las tramas WebSocket, y 0x76 es el caracter que desde el c´odigo JavaScript de la p´agina se envia nada m´as iniciarse la conexi´on. Si ´esta secuencia de caracteres es correcta significa que el cliente se corresponde con una IGU v´alida, de lo contrario se rechaza la conexi´on. Si los caracteres son correctos se procede a enviar un byte que representa el estado de la red de sensores. ´ Este byte es de utilidad para la IGU ya que de ´esta forma conoce en qu´e estado se encuentra la red y puede actuar en consecuencia. El byte de estado de la red se puede corresponder con los valores que se muestran en la tabla 5.3.3. Constante Valor RED PARADA 1 RED INICIANDO 2 RED INICIADA 3 Una vez enviado el estado de la red el hilo queda a la escucha de datos por parte de la IGU. Cuando llega una trama tan s´olo lee los dos primeros caracteres que envia la IGU ya que el primero siempre es 0x00 que corresponde con el inicio de la trama WebSocket, y el segundo se corresponde con el identificador de la trama, que es el que realmente interesa para discriminar las tramas. Seg´un el valor del segundo byte de la trama se tomar´a una acci´on u otra. Inicio de la red El hilo listenClient lee el identificador de trama 0x49. En ´ese caso ordena al sumidero que inicie la red y descarta el ´ultimo byte de la trama (ser´a 0xFF 134 CAP´ ITULO 5. IMPLEMENTACI´ ON marcando el final de la trama WebSocket). La figura 5.22 muestra el formato de dicho paquete. Figura 5.22: Formato de un paquete WebSocket de inicio de la red Env´ıo de la configuraci´on El hilo listenClient lee el identificador de trama 0x43. En ´ese caso lee los siguientes 5 bytes que se corresponder´an con los flags, periodo de medici´on, y los umbrales de la medida, nivel de RSSI y nivel de bater´ıa en ´ese orden, tal y como muestra la figura 5.23. Modifica la trama para que sea compatible con la comunicaci´on Puente-USB y la env´ıa hacia el sumidero. Descarta el ´ultimo byte de la trama (ser´a 0xFF marcando el final de la trama WebSocket) Figura 5.23: Formato de un paquete WebSocket de env´ıo de par´ametros de configuraci´on Medici´on bajo demanda El hilo listenClient lee el identificador de trama 0x4D. En ´ese caso ordena al sumidero que realice una medici´on bajo demanda y descarta el ´ultimo byte de la trama (ser´a 0xFF marcando el final de la trama WebSocket). La figura 5.24 muestra el formato de dicho paquete. Figura 5.24: Formato de un paquete WebSocket de solicitud de medici´on bajo demanda 5.4. INTERFAZ GR´ AFICA DE USUARIO 135 Reinicio de la red El hilo listenClient lee el identificador de trama 0x52. En ´ese caso ordena al sumidero que reinicie la red y descarta el ´ultimo byte de la trama (ser´a 0xFF marcando el final de la trama WebSocket). La figura 5.25 muestra el formato de dicho paquete. Figura 5.25: Formato de un paquete WebSocket de reinicio de la red Env´ıo de la notificaci´on del listado de nodos Desde el hilo principal (main), cuando se recibe desde el sumidero un paquete de listado de nodos vac´ıo significa que la etapa de la formaci´on de la red ha terminado. Para notificar ´este suceso a las IGU se env´ıa una trama WebSocket con el caracter 0x50 como contenido como se muestra en la figura 5.26. Figura 5.26: Formato de un paquete WebSocket de notificaci´on de listado de nodos Env´ıo de la notificaci´on de actualizaci´on de medidas Desde el hilo principal (main), cuando se recibe desde el sumidero un paquete de recepci´on de medidas se notifica a las IGU enviando una trama WebSocket con el caracter 0x51 como contenido como se muestra en la figura 5.27. 5.4. Interfaz Gr´afica de Usuario La interfaz gr´afica de usuario se implementa como una p´agina HTML dotada de fragmentos de c´odigo JavaScript para otorgar un comportamiento 136 CAP´ ITULO 5. IMPLEMENTACI´ ON Figura 5.27: Formato de un paquete WebSocket de notificaci´on de actualizaci´on de medidas din´amico al contenido de la p´agina empleando para ello la tecnolog´ıa AJAX que nos permite realizar peticiones GET (HTTP) sobre un script PHP que nos servir´a de intermediario entre la BBDD y la p´agina propiamente dicha con el fin de obtener los datos a presentar en la p´agina. Adem´as, haremos uso de la tecnolog´ıa WebSocket para establecer una comunicaci´on con la aplicaci´on puente que notificar´a sobre los eventos acontecidos en la red de sensores y adem´as nos servir´a de intermediario entre la red de sensores y la IGU permitiendonos de ´esta forma controlar dicha red. La IGU y el script PHP est´an estrechamente unidos, es por ello que, dado que PHP permite la inserci´on de c´odigo HTML en el mismo archivo donde reside el c´odigo PHP, ambos se implementan sobre el archivo index.php. Cuando se accede al archivo index.php desde un navegador, en primer lugar se comprueba mediante PHP si el script ha sido llamado mediante un formulario (m´etodo POST) o si se le proporciona alg´un par´ametro mediante el m´etodo GET. De ser falsas ambas condiciones significa que el usuario ha solicitado visualizar la IGU, en caso contrario significa que la propia IGU ha invocado una llamada a s´ı misma (a index.php) mediante AJAX para realizar alguna acci´on sobre la BBDD (en el caso de que la petici´on sea de tipo GET) o bien que se est´a invocando al c´odigo PHP para cambiar la imagen de la estructura de nodos (en el caso de que la petici´on sea de tipo POST). 5.4.1. Conexi´on WebSocket Para implementar la conexi´on WebSocket se hace uso de la API que proporciona JavaScript a tal efecto. Para realizar la conexi´on con la aplicaci´on puente tan s´olo hay que instanciar un objeto de tipo WebSocket proporcionandole como par´ametros la URL del servidor y el puerto en el que atiende. ws = new WebSocket("ws://localhost:9321"); Autom´aticamente se env´ıa una petici´on WebSocket a la aplicaci´on puente y, despues de intercambiarse las cabeceras del protocolo, JavaScript llamar´a a la funci´on a la que apunta el atributo onopen de la instancia del objeto WebSocket. 5.4. INTERFAZ GR´ AFICA DE USUARIO 137 ws.onopen = function() { iconoEstado.src = ’img/icono_conectado.png’; ... } De igual forma se implementa una funci´on con el atributo onmessage para cuando se recibe una trama WebSocket y con el atributo onclose para cuando se cierra la conexi´on. Una vez abierta la conexi´on se env´ıa el caracter de validaci´on para identificarse como una IGU v´alida mediante la funci´on send de la instancia de WebSocket. ws.send("L"); Una vez validada la IGU la aplicaci´on puente enviar´a una trama identificando el estado en el que se encuentra la red de sensores. En funci´on del estado en el que se encuentre la red la IGU habilitar´a o deshabilitar´a los botones que permiten realizar acciones sobre la red ya que en ciertos estados de la red no es l´ogico que el usuario pueda realizar algunas acciones, e incluso podr´ıa causar un mal funcionamiento en la misma. Los estados posibles en los que se puede encontrar la red y las acciones que se tomar´an se detallan en la siguiente tabla 5.2. Trama Descripci´on Acciones 1 Red parada Iniciar red →habilitado Forzar medici´on →deshabilitado Aplicar configuraci´on →deshabilitado Reiniciar la red →deshabilitado 2 Red iniciando Iniciar red →deshabilitado Forzar medici´on →deshabilitado Aplicar configuraci´on →deshabilitado Reiniciar la red →deshabilitado 3 Red iniciada Iniciar red →deshabilitado Forzar medici´on →habilitado Aplicar configuraci´on →habilitado Reiniciar la red →habilitado; Tabla 5.2: Tramas recibidas por la IGU Una vez se recibe el estado de la red pueden recibirse dos tipos de tramas. Una trama que contenga el valor 0x50 (’P’) indica que la red ha finalizado el listado de nodos, en ´este caso la IGU no debe realizar ninguna acci´on. Si, por el contrario, la trama recibia es el valor 0x51 (’Q’) significa que se han