UNIVERSIDAD
VERACRUZANA
FACULTAD DE INSTRUMENTACI ´
ON
ELECTR ´
ONICA
DISE ˜
NO DE SISTEMA DE
MONITOREO PARA
L´INEAS DE ALTA
TENSI ´
ON, EN ´
AREAS DE
DIF´ICIL ACCESO
TESIS
Que para obtener el t´ıtulo de
Maestro en Ingenier´ıa Electr´
onica y
Computaci´
on
Presenta
Edy Alfonso Ram´
on Fern´
andez
Director de la tesis:
Dr. Jes´
us Garc´ıa Guzm´
an
Co-Director de la tesis:
Dr. Agust´ın Gallardo del ´
Angel
Dedicado a Dios: Por proporcionar, salud, perseverancia, sabidur´ıa y fortaleza.
Agradecimientos
A mis padres: Sabiendo que jam´as existir´a una forma de agradecerles una vida de lucha, sacrificio y esfuerzos constantes; solo deseo que comprendan que el logro m´ıo es suyo, que mi esfuerzo es inspirado en ustedes y que son mi ´unico ideal. Con respeto y admiraci´on . . .
A mis hermanos: En reconocimiento a todo el apoyo brindado a trav´es de mis estudios y con la promesa de seguir siempre adelante. . .
A t´ı: Esa persona especial que es parte de esta historia: con la fe en m´ı; la adversidad no podr´a quitarme el triunfo, ni mi Gloria. . .
Agradecimiento especial
Quiero agradecer a aquellas personas que compartieron sus conocimientos y tiem-po para hacer tiem-posible la conclusi´on de esta tesis. Especialmente agradezco al Dr. Jes´us Garc´ıa Guzm´an por su asesor´ıa siempre dispuesta. Gracias a los Drs. Agust´ın Gallardo del ´Angel y Roberto Casta˜neda Sheissa por sus ideas y recomendacio-nes. . .
A mis maestros que en este andar por la vida, influyeron con sus lecciones y experiencias en formarme como una persona de bien y preparada para los retos que pone la vida, a todos y cada uno de ellos les dedico cada una de est´as paginas. . .
A la Direcci´on de Extensi´on de Servicios Tecnol´ogicos (DEST) y al Departa-mento Operativo de Telefon´ıa (DOT) de la Universidad Veracruzana por su apoyo y comprensi´on. . .
A la Facultad de Instrumentaci´on Electr´onica y Universidad Veracruzana por la oportunidad brindada. . .
Resumen
La nueva generaci´on de sistemas de potencia el´ectrica, conocida como Redes Inteligentes, est´a siendo estudiada intensamente como la soluci´on m´as viable para el manejo de la demanda energ´etica actual. Una de las caracter´ısticas de estos sistemas es la integraci´on de redes de comunicaci´on con alta velocidad de trans-ferencia de informaci´on, fiables y seguras para la compleja administraci´on de los mismos, y que adem´as les proporcione inteligencia y efectividad, en caso de fallas. En paralelo con el desarrollo de las nuevas tecnolog´ıas de comunicaciones, las re-des inal´ambricas de sensores han venido evolucionando para venir a complementar estos requerimientos de procesamiento inteligente de la informaci´on.
En el presente trabajo se presenta la propuesta e implementaci´on de una red inal´ambrica de sensores orientada al monitoreo de l´ıneas de transmisi´on en siste-mas el´ectricos de alta tensi´on. Se parte del an´alisis del medio en que la red se ha de implementar, se proyecta la infraestructura requerida, se realiza la configura-ci´on adecuada y se desarrolla el software para el sistema propuesto. Por ´ultimo, se presenta un an´alisis y observaciones de los resultados experimentales del modelo implementado para la red inal´ambrica de sensores.
Abstract
The new generation of electrical power systems, known as Smart Grid, is being intensively studied as the most viable solution for the management of the current energetic demand. One of the features of these systems is the integration of com-munication networks capable of transferring information at high-speed, reliable and secure, for their complex administration and, also, providing intelligence and effectiveness in cases of failures. In parallel with the development of the recent com-munication technologies, wireless sensor networks have been evolving to match the requirements for smart processing of information.
In this work, the proposal and implementation of a wireless sensor network for the monitoring of transmission lines in high-voltage electrical systems is presented. Starting from the analysis of the environment in which the network is going to be implemented the required infrastructure is projected; the proper configuration is setup and the software for the proposed system is developed. Finally, an analysis and remarks about the experimental results of the implemented model for the wi-reless sensor network is presented.
´Indice general
Agradecimientos III
Resumen V
Abstract VII
1. Introducci´on 1
1.1. Antecedentes . . . 1
1.2. Objetivos . . . 3
1.3. Alcance . . . 3
1.4. Metodolog´ıa . . . 4
1.5. Contribuci´on a la investigaci´on . . . 4
1.6. Estructura de la tesis . . . 5
2. Bases te´oricas 7 2.1. Redes inal´ambricas de sensores . . . 7
2.2. El est´andar IEEE 802.15.4 y ZigBee . . . 8
2.2.1. Tipos de dispositivos . . . 9
2.2.2. Definici´on de nodos . . . 10
2.3. Redes Inal´ambricas de sensores en sistemas lineales . . . 11
2.4. Mecanismo de direccionamiento . . . 11
2.4.1. Direccionamiento ZigBee . . . 12
3. Descripci´on general del sistema 15 3.1. Presentaci´on del sistema . . . 15
3.1.1. Prop´osito del sistema . . . 15
3.2. Interfaz de adquisici´on de datos . . . 16
3.3. Red Inal´ambrica. . . 16
3.3.1. Conexi´on inal´ambrica entre los nodos . . . 16
3.4. Interfaz de presentaci´on de datos . . . 17
x ´INDICE GENERAL
4. Plataforma y herramientas de desarrollo 19
4.1. Hardware y subsistemas . . . 19
4.1.1. Dispositivos de monitoreo remoto . . . 19
4.1.2. Comunicaci´on inal´ambrica . . . 20
4.1.3. Estaci´on base . . . 22
4.2. Software del sistema . . . 23
4.2.1. Dispositivos de monitoreo . . . 23
4.2.2. Comunicaci´on inal´ambrica . . . 24
4.2.3. Estaci´on base . . . 24
5. Arquitectura e implementaci´on 27 5.1. Escenario de dise˜no sobre el c´alculo de la red . . . 27
5.1.1. Dise˜no de la red . . . 27
5.2. Propuesta de la WSN . . . 29
5.3. Programaci´on principal . . . 30
5.3.1. Env´ıo-recepci´on de informaci´on . . . 30
5.4. Programaci´on de nodos remotos . . . 32
5.4.1. Programaci´on de env´ıo de informaci´on API. . . 32
5.4.2. Transferencia de informaci´on de nodos remotos . . . 32
5.4.3. Env´ıo de informaci´on de los puertos digitales . . . 33
5.5. Estaci´on base . . . 34
6. Pruebas y conclusiones 37 6.1. Pruebas de funcionalidad . . . 37
6.1.1. Distancia entre nodos e intensidad de la se˜nal . . . 37
6.1.2. Solicitud de variables de estado . . . 39
6.1.3. Variables digitales. . . 39
6.2. Conclusiones. . . 40
6.2.1. Propuestas para trabajo futuro . . . 41
A. C´odigo de desarrollo 43 A.1. Env´ıo de dato . . . 43
A.2. Lectura de puertos digitales . . . 44
A.3. C´odigo en estaci´on base . . . 45
B. Im´agenes de pruebas 49 B.1. Enlace sin l´ınea de vista . . . 50
B.2. Enlace con l´ınea de vista . . . 52
´Indice de tablas
4.1. Propiedades de tarjeta BL4S150. . . 21
4.2. Especificaciones Xbee-PRO (S2B) . . . 21
4.3. Caracter´ısticas de las Antenas omnidireccionales. . . 22
4.4. Propiedades del servidor central . . . 23
5.1. Estructura de Frame API. . . 31
5.2. Visualizaci´on de la informaci´on recibida en shell de Python. . . 35
´Indice de figuras
2.1. Pila del protocolo IEEE 802.15.4/ZigBee. . . 9
3.1. Esquema del sistema propuesto. . . 15
3.2. Esquema LT-WSNs. . . 17
4.1. Diagrama a bloque de nodos sensores. . . 20
4.2. Diagrama a bloques de la estaci´on base . . . 22
5.1. Esquema del sistema . . . 29
5.2. Nodo remoto con bater´ıa de 9 V. . . 33
5.3. Secuencia del modo de transmisi´on. . . 34
5.4. Diagrama a bloque de la informaci´on procesada en la Estaci´on Base. 36 6.1. Gr´afica de distancia e intensidad de se˜nal. . . 38
6.2. Diagrama esquem´atico de la transferencia de informaci´on de los nodos remotos a la estaci´on base. . . 39
B.1. Topograf´ıa del enlace sin l´ınea de vista . . . 50
B.2. Diagn´ostico de enlace sin l´ınea de vista . . . 51
B.3. Topograf´ıa del enlace con l´ınea de vista . . . 52
B.4. Diagn´ostico de enlace con l´ınea de vista. . . 53
Cap´ıtulo 1
Introducci´
on
1.1.
Antecedentes
Uno de los grandes problemas en los sistemas el´ectricos consiste en el moni-toreo en tiempo real de los equipos encargados de la transmisi´on de la energ´ıa. En particular, las l´ıneas de transmisi´on son uno de los componentes cr´ıticos y su correcta operaci´on es fundamental para la distribuci´on y suministro de la energ´ıa. Las l´ıneas constan de cables de alta tensi´on colocados en torres o postes y est´an, en general, expuestas a la intemperie y por ello a todos los riesgos que esto implica, como pueden ser rayos, ca´ıda o crecimiento de arboles, robo de conductores, rotura de cables, entre otros. La mayor parte de estas l´ıneas se encuentran en sitios des-poblados, de dif´ıcil acceso y a grandes distancias de los centros urbanos. Cuando una falla ocurre, es necesario, en primer lugar, localizar el sitio de la misma y, en segundo lugar, reparar la falla en tiempos reducidos.
En condiciones convencionales, la localizaci´on y atenci´on de las fallas lleva mu-cho tiempo ya que no hay forma segura de saber el punto de la aver´ıa sin recurrir a la inspecci´on f´ısica y son pocos los datos que se obtienen de los sistemas de protecci´on tradicionales de los sistemas el´ectricos.
Recientemente, se habla de ”redes el´ectricas inteligentes” (Smart Grids [1]), refiri´endose al uso de tecnolog´ıas electr´onicas, de informaci´on y de comunicaciones integradas a las redes convencionales. Bajo este nuevo concepto, se integr´an a las redes el´ectricas componentes para el monitoreo, supervisi´on y control de los equi-pos el´ectricos, y es dentro de este tema que se ubica el presente trabajo.
2 CAP´ITULO 1. INTRODUCCI ´ON
Al respecto, se han realizado investigaciones y desarrollos basados en nuevas tecnolog´ıas con el objetivo de monitorear y supervisar algunas de las fallas m´as comunes en las l´ıneas de transmisi´on [2].
En reportes recientes [3, 4, 5] se describen algunos de los est´andares de las tecnolog´ıas de la comunicaci´on actualmente en desarrollo para aplicaciones en sis-temas ”Smart Grid”, los autores describen las ventajas y desventajas de cada uno de ellos en los diversos campos de aplicaciones en las redes el´ectricas inteligentes. De igual forma, existen ya revisiones [6] que resumen los est´andares que se est´an adoptando para el uso de las nuevas tecnolog´ıas de comunicaci´on en las redes el´ectricas inteligentes, y se han descrito tamb´ıen [7], las caracter´ısticas y variables que influyen en el entorno de las l´ıneas de transmisi´on. Otros trabajos recientes [8, 9] han sido enfocados al uso de tecnolog´ıas inal´ambrica aplicadas a obtener informaci´on de forma local en las l´ıneas de ultra alta tensi´on (UHV 1
).
En este trabajo se propone, dise˜na y desarrolla la primera etapa de una red inal´ambrica de sensores orientada al monitoreo y supervisi´on de l´ıneas de transmi-si´on de energ´ıa el´ectrica. El sistema desarrollado se basa en la tecnolog´ıa ZigBee [10] para la comunicaci´on entre nodos sensores, los cuales son capaces de captu-rar se˜nales sobre el estatus de variables importantes en la operaci´on de las l´ıneas de transmisi´on el´ectrica. La red permite transmitir en tiempo real la informaci´on obtenida a trav´es de un sistema de comunicaci´on inal´ambrica que concentra los datos a una central en la que pueden ser analizados en forma continua, para la eventual determinaci´on de detalles como: localizaci´on de las fallas en tiempo m´ıni-mo, ubicaci´on de las mismas dentro de un rango reducido, diagn´ostico inicial de las posibles causas de la falla y generaci´on de avisos preventivos.
La disponibilidad de esta informaci´on puede significar grandes ahorros en el mantenimiento de las l´ıneas, ya que se evitan desplazamientos innecesarios del personal t´ecnico y se reducen considerablemente los tiempos de atenci´on a las fallas. Adem´as, se reducen las p´erdidas y otros inconvenientes causados por las interrupciones del servicio el´ectrico.
1
1.2. OBJETIVOS 3
1.2.
Objetivos
El objetivo principal de este proyecto es el dise˜no, implementaci´on y evalua-ci´on de un sistema escalable para el monitoreo remoto de variables f´ısicas y, en base a ello, determinar condiciones de fallas en las l´ıneas de transmisi´on el´ectri-ca mediante una red inal´ambriel´ectri-ca de sensores WSN2
basada en el protocolo IEEE 802.15.4/ZigBee.
A continuaci´on se describen los objetivos particulares en el desarrollo de la fase inicial de los componentes que integran el sistema:
Estaci´on base. Se proyecta su adecuaci´on, configuraci´on y programaci´on para la visualizaci´on de la informaci´on proveniente de los nodos sensores.
Nodos sensores. Se proyecta la configuraci´on y programaci´on de las entrada-s/salidas anal´ogicas y digitales, para hacer llegar la informaci´on a la estaci´on base.
Red inal´ambrica ZigBee. Se propone realizar la comunicaci´on entre los nodos sensores mediante los radios Xbee, analizar su comportamiento, caracterizar los par´ametros de alcance e intensidad de se˜nal y estatus de la red inal´ambri-ca de sensores.
En lo referente a la evaluaci´on, se deben realizar diversas pruebas del com-portamiento documentando los resultados obtenidos, con el fin de garantizar la funcionalidad de la tecnolog´ıa implementada. El sistema propuesto act´ua como c´elulas de recolecci´on de datos, los cuales son concentrados en la estaci´on base realizando el almacenamiento de la informaci´on en una base de datos.
1.3.
Alcance
La relevancia de este sistema como primera etapa de un proyecto m´as am-bicioso, consiste en la implementaci´on de la plataforma de comunicaci´on de una red inal´ambrica de sensores (WSN) aplicando tecnolog´ıa basada en el protocolo
2
4 CAP´ITULO 1. INTRODUCCI ´ON
ZigBee/IEEE 802.15.4. Se realiza la configuraci´on de los nodos sensores, as´ı co-mo la programaci´on y desarrollo de la interfaz de co-monitoreo y visualizaci´on de la informaci´on recabada de la red de sensores. Esta fase es importante debido a que la informaci´on remota se presenta en tiempo real, lo cual permite un an´alisis minucioso del comportamiento de las variables de cada nodo sensor y, por ende, la ubicaci´on y atenci´on oportuna de fallas.
1.4.
Metodolog´ıa
La metodolog´ıa aplicada al desarrollo de este proyecto se divide en las siguientes etapas:
1. Investigaci´on - En esta etapa se realiza una revisi´on documental con base a los fundamentos te´oricos necesarios para el dise˜no, desarrollo e implemen-taci´on de la WSN en un entorno lineal, mediante el protocolo ZigBee/IEEE 802.15.4.
2. Dise˜no e implementaci´on - En esta etapa se elige y configura el hardwa-re m´as adecuado para el desarrollo del proyecto. En esta parte tambi´en se describe el c´odigo que se ha desarrollado para el funcionamiento de la WSNs.
3. Pruebas, resultados y conclusionesEn esta parte se detallan las pruebas de campo, resultados obtenidos y concluyendo con los alcances obtenidos. Se realizan recomendaciones para trabajos futuros.
1.5.
Contribuci´
on a la investigaci´
on
1.6. ESTRUCTURA DE LA TESIS 5
1.6.
Estructura de la tesis
Cap´ıtulo 2
Bases te´
oricas
En este cap´ıtulo se hace una breve descripci´on de los principales conceptos tecnol´ogicos que son usados en este trabajo de tesis enfocados principalmente a las redes inal´ambricas de sensores y al y protocolo ZigBee.
2.1.
Redes inal´
ambricas de sensores
Las redes inal´ambricas de sensores (WSN) generalmente se componen de cien-tos e incluso miles de sensores aut´onomos y actuadores, organizados y distribuidos en los llamados nodos-sensores. Estos nodos son capaces de intercambiar informa-ci´on entre ellos a trav´es de la red inal´ambrica. En conjunto, son aplicados en la supervision y monitoreo de fen´omenos f´ısicos. Las aplicaciones de las WSNs pue-den cubrir una amplia gama de dominios [14,15].
Las WSNs en la industria son regidas por el est´andar IEEE 1451 [16], cuyo prop´osito fundamental es crear la normatividad de la interfaz transductora inteli-gente para los sensores y actuadores, es decir, define en conjunto la interfaz com´un de comunicaci´on para la conexi´on de transductores inteligentes a sistemas basados en microprocesadores, instrumentos y redes. Adem´as proporciona un conjunto de protocolos para sistemas tanto cableados como inal´ambricos, subdivididos en siete grupos, siendo los encargados de definir la estandarizaci´on de hardware y softwa-re, para el soporte de sensores inteligentes de la conectividad de la red [17]. Las especificaciones desarrolladas no establecen restricciones sobre el uso del acondi-cionamiento de se˜nales y esquemas de procesamiento, de convertidores anal´ogico a digital, microprocesadores, protocolos de red y el medio de comunicaci´on de la red [18].
8 CAP´ITULO 2. BASES TE ´ORICAS
En los sistemas de distribuci´on de energ´ıa, existen diversas tecnolog´ıas en evo-luci´on, Ahmad Usman y Sajjad Haider Shami [3] describen las tecnolog´ıas de la comunicaci´on al´ambrica e inal´ambrica, comentando las aplicaciones y desarrollos de estas tecnolog´ıas estandarizadas por la IEEE1
, como son: ZigBee, WiMAX [19], Wi-Fi [20], GSM3G/4G Celular [21], DASH7 [22] y PLC [23] enfocadas a aplica-ciones en redes el´ectricas inteligentes [24].
El Electric Power Research Institute (EPRI) [25] analiza el futuro sobre la ins-pecci´on y monitoreo de las l´ıneas subterr´aneas de alta tension, haciendo ´enfasis en el medio de transmisi´on a las redes inal´ambricas, en conjunto con las redes de fibra ´optica.
En este proyecto se realiza la implementaci´on de una WSN, siendo la base del desarrollo el protocolo ZigBee. Mediante los conceptos antes mencionados, se justi-fica la viabilidad de implementaci´on de una red inal´ambrica de sensores, teniendo como objetivo principal del monitoreo y supervisi´on de las l´ıneas el´ectricas de alta tensi´on.
2.2.
El est´
andar IEEE 802.15.4 y ZigBee
Los est´andares IEEE 802.15.4 [26] y ZigBee act´uan en conjunto, dependiendo uno del otro. Ambos rigen la estructura de las redes inal´ambricas de ´area personal a baja tasa de transferencia de datos LR-WPAN2
[26]. La tecnolog´ıa ZigBee fue desarrollada por ZigBee Allience basado en la capa f´ısica y de control de acceso al medio del est´andar IEEE 802.15.4. Operando sobre la bandas ISM [27], soporta tres bandas de frecuencias: banda de 2450 MHz (con 16 canales de 5 MHz rango de 2.405 a 2.480 GHz), banda a 915 MHz (con 10 canales) y banda a 868 MHz(un canal), usando el m´etodo de codificaci´on de canal de espectro ensanchado de secuencia directa DSSS [28]. La banda 2450 MHz emplea O-QPSK [29] para la modulaci´on, con una tasa de transferencia de 250 kbps [30]. La relaci´on que existe entre el protocolo IEEE 802.15.4 y ZigBee, se define por las capas del modelo OSI [31]. Mientras el prop´osito principal de la norma IEEE 802.15.4 es la comunicaci´on entre dos dispositivos, determinada por la capa f´ısica PHY y de control de acceso al medio MAC, la norma ZigBee define la comunicaci´on en la capa nivel tres o superior del modelo OSI.
1
IEEE 1451.5 : Wireless Transducer Interface 2
2.2. EL EST ´ANDAR IEEE 802.15.4 Y ZIGBEE 9
Su prop´osito principal es establecer una topolog´ıa de red (jerarqu´ıa) que permi-te que un n´umero indefinido de dispositivo se comuniquen entre ellos y, al mismo tiempo, establecer funciones de comunicaci´on adicionales tales como: autentica-ci´on, encriptaautentica-ci´on, asociaci´on y servicios de aplicaci´on en las capas superiores. Esta estructura se muestra en la Figura 2.1.
Figura 2.1: Pila del protocolo IEEE 802.15.4/ZigBee.
2.2.1.
Tipos de dispositivos
10 CAP´ITULO 2. BASES TE ´ORICAS
2.2.2.
Definici´
on de nodos
La red comprende tres tipos de nodos: coordinador, ruteadores y dispositivos finales. Los FFDs pueden ser tanto ruteadores como coordinador de la red, mien-tras que los RFDs solo pueden ser los dispositivos terminales. Los FFD tienen la capacidad de ser un dispositivo final, normalmente, no son usados como tal. La tarea de creaci´on y gesti´on de la red la toma el coordinador. Los ruteadores, como su nombre lo indica, son los encargados de rutear o encaminar el tr´afico desde los dispositivos finales hasta el coordinador. Los ruteadores y coordinadores son capa-ces de comunicarse con todos los dispositivos de la red, por lo que ninguno de ellos puede entrar en modo ”Sleep”. Los dispositivos terminales solo pueden comunicar-se con el coordinador o ruteador adjunto, ya que no comunicar-se les permite comunicarcomunicar-se con m´as de un dispositivo y son los ´unicos que pueden entrar en modo ”Sleep” en la red.
Coordinador de la PAN (Personal Area Network)
En las redes ZigBee siempre existe un solo dispositivo coordinador (ZC3), cuyas funciones principalmente son: encargarse de controlar la red, formaci´on de la red (los caminos que deben seguir los dispositivos para conectarse entre ellos), entre-ga de direcciones y la gesti´on de las funciones que definen la red, como la seguridad.
Ruteador
Un ruteador (ZR4
) es un nodo ZigBee con todas las funciones. Puede unirse a las redes existentes, enviar informaci´on, recibir informaci´on y rutear o dirigir informaci´on. El enrutamiento significa que act´ua como un mensajero entre las co-municaciones de otros dispositivos que est´an demasiado separados para transmitir informaci´on sobre la propia red. Una red puede tener m´ultiples nodos ”ruteador”.
Dispositivo finales
Los dispositivos finales (ZED5
), tienen la funcionalidad suficiente para comuni-carse con los nodos padres (ya sea el coordinador o un ruteador), pero no pueden transmitir los datos de otros dispositivos.
3
ZigBee Coordinator 4
ZigBee Router 5
2.3. REDES INAL ´AMBRICAS DE SENSORES EN SISTEMAS LINEALES 11
En el Cap´ıtulo 5se realiza la definici´on y configuraci´on de los nodos usados en este trabajo. Todos los nodos son definidos como Full Function Device (F F D), to-mando en cuenta las funcionalidades que debe tener cada uno de ellos. As´ı mismo en la implementaci´on (ver Secci´on 5.1) los nodos son definidos como: coordinador ZC y ruteadores ZR, respectivamente.
2.3.
Redes Inal´
ambricas de sensores en sistemas
lineales
Las topolog´ıas de red soportada por IEEE.802.156.4/ZigBee dentro de la capa f´ısica (PHY) se pueden clasificar en tres grandes grupos: ´arbol, basado en grupo y malla (tree, cluster y mesh networks), respectivamente. Sin embargo, debido a las caracter´ısticas topogr´aficas de la distribuci´on de los nodos sensores en las l´ıneas de transmisi´on de alta tensi´on, la topolog´ıa que mejor se adapta a este proyecto es de tipo lineal, ya sea LWSN 6
o LT WSN7
. Estas topolog´ıas est´an ya definidas [11,12,13] sus caracter´ısticas como: implementaci´on, formaci´on de nodos y direc-cionamiento, as´ı como los an´alisis que se pueden efectuar y los resultados que se pueden obtener. Hay diversos trabajos en los cuales se ha discutido la asignaci´on de direccionamiento en las WSN [34, 35], en los cuales propone un esquema de asignaci´on de direccionamiento jer´arquico, cuando los sensores son divididos en ”clusters” y los ”clusters” son divididos l´ogicamente en capas.
Tomando en cuenta estas definiciones, en el Cap´ıtulo5 se realiza el dise˜no con base a la topograf´ıa en las l´ıneas de transmisi´on de energ´ıa el´ectrica de alta tensi´on.
2.4.
Mecanismo de direccionamiento
El dise˜no e implementaci´on de esquemas de enrutamiento en las WSN es una tarea compleja, estos deben ser capaces de manejar de manera eficaz y eficiente el intercambio y procesamiento de informaci´on, para ello se deben considerar una serie de cuestiones te´oricas. En primer lugar, con el fin de garantizar el m´aximo tiempo de vida de la red, en los mecanismos adoptados para el descubrimiento de rutas e intercambio de informaci´on es necesario tener alta eficiencia de energ´ıa [36]. En segundo lugar, ya que los nodos suelen operar en forma desatendida, los protocolos usados deben ser autoorganizados, robustos ante fallas y p´erdida de
6
Linear Wireless Sensor Networks 7
12 CAP´ITULO 2. BASES TE ´ORICAS
informaci´on. El ´ultimo y m´as importante requisito es que el protocolo de enruta-miento; este deber´a ser capaz de manejar la extensi´on de la red para garantizar la transferencia de informaci´on, superando los retos derivados de interferencias en los radios y manteniendo los m´ultiples saltos en el camino [37].
2.4.1.
Direccionamiento ZigBee
En ZigBee, las direcciones de red se asignan a los dispositivos mediante un esquema de asignaci´on de direcciones distribu´ıdo [38]. Antes de la formaci´on de la red, el coordinador determina el n´umero m´aximo de nodos hijos de un ruteador comoCmy el n´umero m´aximo de nodos hijos ruteadores del ruteadorRm, as´ı como
la extension Lm de la red [39]. Hay que tener en cuenta que los nodos hijos de un
ruteador puede ser ruteadores o dispositivos terminales, entonces Cm ≥ Rm. El
coordinador y los ruteadores pueden tener como nodo hijo m´as de un ruteadorRm
y al menosCm -Rmcomo nodos hijosCm. El direccionamiento de los dispositivos es
asignado jer´arquicamente de forma superior a inferior por el coordinador. Todo el espacio de direcciones es particionado l´ogicamente en bloquesRm+ 1. Los primeros
bloques Rm deben ser asignados a los nodos hijos ruteadores del coordinador,
siendo el ´ultimo bloque reservado para los propios dispositivos terminales hijos del coordinador. En el direccionamiento para Cm, Rm y Lm cada router calcula un
par´ametro llamado Cskip para obtener el direccionamiento de inicio del grupo de
direcciones de los nodos hijos. El c´alculo de Cskip para el coordinador o ruteador
con profundidad ”depth” d se determina de acuerdo a la Ecuaci´on 2.1 y define el n´umero m´aximo de direcciones que pueden ser asignadas dentro de los l´ımites de 216
= 65536 [38, 40]:
Cskip(d) =
1 +Cm×(Lm−d−1), Si Rm= 1.
1 +Cm−Rm−CmRmLm−d−1, Si Rm6= 1.
1−Rm
(2.1)
Direccionamiento Zigbee en LWSN
Los mecanismos de direccionamiento en LWSN m´as comunes son:
Mecanismo de asignaci´on de direccionamiento estoc´astico (SAAM8
): atribuye un direccionamiento aleatorio a trav´es de la red mediante el protocolo de ruteo AODV (RFC 3651) [41].
8
2.4. MECANISMO DE DIRECCIONAMIENTO 13
Mecanismo de asignaci´on de direccionamiento distribuido (DAAM) 9 : El ”cluster−tree” propone una estructura direccionamiento jer´arquico y un mecanismo de ruteo basado en el m´aximo n´umero de hijos (Cm) por nodo el
n´umero m´aximo de routers (Rm) hijos por nodo, y la profundidad ”depth”
m´axima del ´arbol Lm. Este mecanismo prev´e la asignaci´on de un f´acil y
r´apido enrutamiento [42].
LT WSN10
: todos los nodos son FFDs y son divididos en ”clusters” y en cada ”cluster” dos nuevas reglas son definidas un ”clustercabeza” y uno puente, estos nodos deber´an ser seleccionados de forma manual en cada puente de entre todos los nodos [11].
La eficacia de los mecanismos de direccionamiento depender´a del tama˜no de la red, en el desarrollo de este proyecto, con base al dimensionamiento son usados los tres mecanismos de direccionamiento. Considerando las observaciones realizadas por Moussa Dethie Sarr, Francois Delobel, Michel Misson y Ibrahima Niang [38], quienes han realizado un an´alisis sobre el alcance y limitaciones de estos algoritmos de direccionamiento en las redes ZigBee.
9
Distributed Address Assignment Mechanism 10
Cap´ıtulo 3
Descripci´
on general del sistema
3.1.
Presentaci´
on del sistema
En este trabajo de tesis, se desarrolla una red inal´ambrica de sensores basada en el protocolo Zigbee, con el objetivo de monitorear diversas variables f´ısicas en las l´ıneas el´ectricas de alta tensi´on(ver Figura-3.1).
Estación base INTERNET
ZigBee
ZigBee
ZigBee
ZigBee ZigBee
ZigBee
ZigBee
ZigBee
ZigBee
GSM/GPRS
Nodo n Nodo(n+1)
Nodo(n+2) Nodo(n+3)
Nodo(n+...)
RS-232
Figura 3.1: Esquema del sistema propuesto.
3.1.1.
Prop´
osito del sistema
El sistema propuesto (3.1) se encargar´a de recolectar informaci´on del medio a trav´es de nodos remotos; para hacerla llegar de forma inal´ambrica mediante el
16 CAP´ITULO 3. DESCRIPCI ´ON GENERAL DEL SISTEMA
protocolo ZigBee siguiendo la topolog´ıa LT-WSN1
a una estaci´on base. La infor-maci´on es procesada y almacenada en la estaci´on base, en la cual se tiene acceso del monitoreo de la informaci´on recibida de los nodos remotos, a trav´es de una in-terfaz web para la visualizaci´on gr´afica mediante el puerto de conexi´on de internet.
3.2.
Interfaz de adquisici´
on de datos
La interfaz de adquisici´on de datos es la encargada de recopilar la informaci´on del medio a trav´es de las entradas/salidas de sensores; los datos obtenidos son pro-cesados para posteriormente ser enviados en la WSN mediante el protocolo ZigBee a la estaci´on base, estos nodos son definidos como nodos ruteadores.
En este caso particular, el sistema consta de la tarjeta de desarrollo marca DIGI modelo BL4S150 y un m´odulo Xbee DIGI modelo XBee-PRO ZB S2B. Me-diante programaci´on se procesan los datos de entrada del medio para ser enviados al coordinador central y presentar la informaci´on.
3.3.
Red Inal´
ambrica
La red inal´ambrica est´a definida partiendo como base fundamental de los est´andares IEEE 802.15.4 y ZigBee. La transferencia de informaci´on de la red inal´ambrica de sensores sigue las especificaciones establecidas en estos protocolos.
3.3.1.
Conexi´
on inal´
ambrica entre los nodos
Los principales factores a considerar para el env´ıo ´optimo de la informaci´on son:
Rango de distancia entre nodos: superior a 400 metros.
Ancho de banda: a 250 kb/s.
L´ınea de vista.
El sistema est´a dise˜nado de tal forma que los dispositivos de control tienen que establecer una conexi´on con el nodo vecino (n + 2) ruteador de tal forma que
1
3.4. INTERFAZ DE PRESENTACI ´ON DE DATOS 17
LAN-GSM/GPRS
LT-WSNs
Nodo Router
Nodo Coordinador ZigBee
802.15.4
Figura 3.2: Esquema LT-WSNs.
mediante el protocolo ZigBee, partiendo de la base de distribuci´on de nodos en topolog´ıa lineal, se hace llegar la informaci´on obtenida de los nodos remotos a una estaci´on base/servidor definida como nodo coordinador, tal como se muestra en la Figura3.2.
3.4.
Interfaz de presentaci´
on de datos
Cap´ıtulo 4
Plataforma y herramientas de
desarrollo
4.1.
Hardware y subsistemas
En este cap´ıtulo se describe cada uno de los m´odulos (hardware) que integran el sistema propuesto, as´ı como el software de programaci´on y control con el que se implementa la red inal´ambrica de sensores.
4.1.1.
Dispositivos de monitoreo remoto
Los dispositivos de monitoreo generalmente, est´an constituidos por un micro-controlador para el procesamiento de la informaci´on, una interfaz de conexi´on de entradas/salidas para la interconexi´on de sensores anal´ogicos y digitales para la adquisici´on de informaci´on, memoria para el almacenamiento de datos, interfaz de conexi´on de modulo ZigBee para la comunicaci´on inal´ambrica en la red, adem´as de contar con bater´ıas para el soporte energ´ıa.
En los siguientes subsecciones se describen las caracter´ısticas esenciales de los nodos sensores. Las arquitectura de hardware se describe en el diagrama a bloques de la Figura4.1.
Tarjeta para desarrollo BL4S150
Las caracter´ısticas de la tarjeta de desarrollo BL4S150 de Rabbit [43], basadas en los requerimientos b´asicos de los dispositivos de monitoreo remoto como son: procesamiento de informaci´on, memoria, perif´ericos. Se muestran en la Tabla 4.1.
20 CAP´ITULO 4. PLATAFORMA Y HERRAMIENTAS DE DESARROLLO
Sistema de energ´ıa
Debido al hecho de que los m´odulos inal´ambricos consumen la mayor´ıa de la energ´ıa en el sistema, el consumo de corriente el´ectrica es otro aspecto importante a tener en cuenta [44]. Adem´as de considerar la ubicaci´on de los nodos de monito-reo en zonas distantes, ser´ıa necesario contar con un sistema que capte la energ´ıa a partir de las l´ıneas mismas para la recarga autom´atica de las bater´ıas de los nodos sensores. El dise˜no de este sistema de captura de energ´ıa y recarga de bater´ıas queda fuera del alcance de este proyecto. Por lo tanto, en la fase experimental el suministro de energ´ıa se realiza mediante bater´ıas recargable de 12V en los nodos remotos (como se observa la parte sombreada de color amarillo del diagrama a bloques en la Figura4.1).
4.1.2.
Comunicaci´
on inal´
ambrica
El m´odulo de comunicaci´on inal´ambrica proporciona una interfaz para el in-tercambio de datos con otras unidades del mismo tipo y con la estaci´on base. Las consideraciones importantes a tener cuenta son: la fiabilidad en las comuni-caciones, rango, velocidad de transferencia de datos y la asignaci´on de frecuencias permitidas por el pa´ıs1
.
1
Para el caso de M´exico la frecuencia usada es la banda de 2.4 GHz
4.1. HARDWARE Y SUBSISTEMAS 21
Propiedades de la tarjeta Requerimiento correspondiente
Microprocesador Rabbit 4000 ope-rando a 40.00 MHz.
Procesamiento de informaci´on a par-tir de m´ultiples entradas y salidas de sensores.
Multiple terminales de conexi´on En-trada/Salida.
Interconexi´on de sensores Anal´ogico-s/Digitales.
1MB de SRAM, 2MB de memoria Flash.
Almacenamiento y procesamiento de informaci´on
Interfaz para m´odulo ZigBee PRO Transmisi´on de la informaci´on.
Interfaz UART, USB. Interfaces para programaci´on y
desa-rrollo.
Tabla 4.1: Propiedades de tarjeta BL4S150.
M´odulo XBee-PRO ZB S2B
Tomando en cuenta requerimientos esenciales para la comunicaci´on entre no-dos, como son: protocolo, distancia, potencia de transmisi´on, consumo de energ´ıa, sensibilidad de recepci´on de los radios, entre otros. El m´odulo en la implementaci´on del proyecto es el Xbee-PRO (S2B) con conector RPSMA [45], cuya especificacio-nes de operaci´on, se describen en la Tabla 4.2(para m´as informaci´on ver p´agina 5 de [46]).
Propiedades del m´odulo Requerimiento correspondiente
Rango de alcance externo con l´ınea de vista.
Hasta 1500 mts. variante internacio-nal.
Potencia de transmisi´on de salida. 10mW (+10dBm) Variante interna-cional.
Tasa de transferencia RF. 250,000bps.
Sensibilidad recibida. -102 dBm.
Voltaje de Operaci´on. 2.7-3.6V.
Corriente de Operaci´on. Tx(117mA a 132mA) Rx(47mA a
62mA)
Frecuencia de Operaci´on. ISM 2.4 GHz
Temperatura de Operaci´on. -40 a 85◦C
22 CAP´ITULO 4. PLATAFORMA Y HERRAMIENTAS DE DESARROLLO
Antenas
En la amplificaci´on de la se˜nal se emplean antenas de tipo omnidireccional, con las caracter´ısticas descritas en la Tabla 4.3.
Propiedades del m´odulo Requerimiento correspondiente
Banda de frecuencia. 2400-2500MHz.
Ganancia de Antena. 8dBi.
Polarizaci´on. Vertical lineal.
HPBW2
/Plano-H. 360◦.
HPBW/Plano-E. 15◦.
Impedancia. 50 Ω
Tabla 4.3: Caracter´ısticas de las Antenas omnidireccionales.
4.1.3.
Estaci´
on base
La estaci´on base (tambi´en conocida comopuerta de enlace) es la unidad recep-tor/transmisor, su funci´on es ser el punto de conexi´on entre la red inal´ambrica y la red LAN IP. As´ı mismo, almacenar la informaci´on obtenida. En otras palabras, la estaci´on base es la encargada de recolectar la informaci´on de los dispositivos de monitoreo, la cual es procesada y almacenada en una base de datos, con el objetivo de llevar un control centralizado de la red de sensores. Adem´as, realiza la funci´on degateway de comunicaci´on para la visualizaci´on y control remoto, como se observa en la Figura 4.2.
4.2. SOFTWARE DEL SISTEMA 23
La estaci´on base se enfoca en coordinar la comunicaci´on con los dispositivos de monitoreo mediante el protocolo ZigBee, recopilar la informaci´on de los nodos sensores, almacenar la informaci´on recolectada y procesarla para que sea accesible desde cualquier lugar v´ıa web. La estaci´on de base est´a compuesta por un m´odulo de comunicaci´on inal´ambrica en conjunto con una tarjeta de interfaz a cargo de la recopilaci´on de datos y la programaci´on a distancia.
Hardware de la plataforma
Para realizar las funciones se˜naladas en el Secci´on 4.1.3. La implementaci´on se realiza en una computadora personal como servidor central, con las caracter´ısticas descritas en la Tabla-4.4.
Especificaci´on Requerimiento
Procesador Pentium 4 a 2.4GHz.
Memoria RAM 512 MBs.
DDR 20 GB.
Interfaz RS-232.
Tabla 4.4: Propiedades del servidor central
Adaptador XBee-PRO 802.15.4 a RS-232
´
Este es un perif´erico de comunicaci´on entre el m´odulo Xbee-PRO y la estaci´on base, el cual cuenta con una interfaz serial (RS-232) y un ”socket” para montar el m´odulo XBee-PRO. Mediante la UART [47] el emisor y el receptor est´an de acuer-do con anticipaci´on en los par´ametros de tiempo de transmisi´on; los bit especiales de delimitaci´on son agregados a cada bits de dato, con el fin de garantizar tanto el env´ıo como la recepci´on entre los dispositivos.
4.2.
Software del sistema
4.2.1.
Dispositivos de monitoreo
La programaci´on de los dispositivos de monitoreo se realiza mediante el softwa-re para sistemas embebidos Dynamic C y el compilador Dynamic C version 10.72 [48], desarrollado por Rabbit Semiconductor 3
para implementaciones de disposi-tivos embebidos que cuenten con microprocesadores Rabbit los cuales comparten
3
24 CAP´ITULO 4. PLATAFORMA Y HERRAMIENTAS DE DESARROLLO
caracter´ısticas similares al procesador Z80/Z180 [49], basado en arquitectura CISC [50]. Dynamic C cuenta adem´as con bibliotecas para el desarrollo de redes basadas en el protocolo ZigBee [51].
4.2.2.
Comunicaci´
on inal´
ambrica
Para la programaci´on de los radios ZigBee, siguiendo los conceptos descritos en la Secci´on2.2.2, los nodos son definidos como: coordinador PAN en la estaci´on base y como nodos ruteadores en los dispositivos de monitoreo. Para ello, lo que define el tipo de nodo es el firmware, instalado en la configuraci´on de cada uno de los nodo inal´ambricos.
Programaci´on del Coordinador
La programaci´on del radio coordinador, se realiza mediante el software de pro-gramaci´on XCTU version 5.2.8.6 de DIGI [52].
Programaci´on de los nodos Ruteadores
Los ruteadores son programados a trav´es del compilador Dynamic C, descrito en la Secci´on4.2.1, seleccionando el firmware ruteador que definir´a a los nodos de monitoreo.
4.2.3.
Estaci´
on base
Para procesar la informaci´on recibida de los nodos sensores se emplea como plataforma el Sistema Operativo Debian 7 [53], as´ı como los siguientes paquetes de software para desarrollo:
Python-xbee
4.2. SOFTWARE DEL SISTEMA 25
MySQL
Realiza la gesti´on de la base de datos, en el ordenamiento de la informaci´on recolectada de los nodos sensores [56].
Php
Lenguaje de programaci´on para desarrollo web [57]. Es usado para desarro-llo de la interfaz web en conjunto con Apache [58] y los Frameworks [59]: Codeigniter [60] y Jquery [61].
Plugins
Highcharts [62] gr´aficas para la visualizaci´on de la informaci´on en la interfaz Web.
Cap´ıtulo 5
Arquitectura e implementaci´
on
5.1.
Escenario de dise˜
no sobre el c´
alculo de la
red
En la distribuci´on de los nodos sensores hay que considerar la topograf´ıa de distribuci´on de las torres en las l´ıneas el´ectricas de alta tensi´on, en las cuales se pretende ubicar cada uno de los nodos. Por lo tanto, se analizan las caracter´ısticas del entorno, en los cuales de acuerdo aArgonne National Laboratory [63] referente a una encuesta realizada por EPRI1
, el espacio L entre las torres en las l´ıneas el´ectricas de alta tensi´on para 500 KV, com´unmente se expresa como un n´umero medio de torres por milla. Este valor oscila de cuatro a seis torres por milla, va-riaci´on que depende de factores como: material de la torre, n´umero de circuitos, geometr´ıa de las torres, topograf´ıa (tramo recto, en esquina, cruce de r´ıos), entre otros. En lo que respecta a las caracter´ısticas de dimensionamiento de las torres, de acuerdo a la tabla de EPRI [64] var´ıa de 18 a 33 metros aproximadamente.
Con base a lo anterior se puede concluir que la distancia en la distribuci´on de nodos-sensores sobre las torres en las l´ıneas el´ectricas de alta tensi´on, oscilar´ıa en un rango de 402.25 metros como m´axima y 268 metros como longitud m´ınima. Teniendo una variaci´on ∆ de 132.25 metros entre la distancia m´ınima y m´axima de separaci´on por milla.
5.1.1.
Dise˜
no de la red
La topolog´ıa de red que se adapta a las caracter´ısticas antes mencionadas es de tipo lineal (ver Secci´on 2.3), tomando en cuenta la formaci´on de nodos en un
1
Electric Power Research Institute
28 CAP´ITULO 5. ARQUITECTURA E IMPLEMENTACI ´ON
sistema lineal, la cual se puede describir como una gran estructura en forma de rejilla establecida secuencialmente. En est´a, se pueden establecer grupos de nodos-sensores tal como se aprecia en la Figura 5.1.
Hay que considerar la distribuci´on en serie de los nodos sensores S = { s1,
s2, s3, s4, . . . ,sn }, encadenados en forma lineal cubriendo un ´area bidimensional
β, donde cada sensor si, i = 1. . .n, est´a situado en las coordenadas (xi,yi). La
cobertura total de los n sensores se denota como Φ, donde cada sensor i cubre una subregi´on Φi, dentro de la cual puede alcanzar a otros nodos. El rango de
sensibilidad de cada nodo sensor es Rs, siendo el rango de comunicaci´on βi la
re-gi´on o ´area cubierta por el encadenamiento entre el nodoiy los nodos vecinos que ´este alcanza,αes la m´axima distancia longitudinal entre nodos, por lo tantoβ≫α.
Definiciones:
Definici´on 1Considerar el ´area de coberturaβ connnodos sensores, donde cada nodo cubre un rangoβi, tal que βi ⊂ β. El ´area de la regi´on β se dice
que es Φ cubierta si cada nodosi en la regi´onβ cubre por lo menos los nodos
de subregi´on Φi. Es decir, β =β1 ∪ β2 ∪ β3 . . . ∪ βn.
Definici´on 2Considerar cualquier nodo sensor si. Se dice que las
subregio-nes de Φi a Φn est´an enlazadas, si todos losn nodos comparten al menos un
si distinto en cada subregi´on de β.
Definici´on 3Toda la regi´on Φ es cubierta, si y solo si losnnodos comparten por lo menos un si+2 en cada subregi´on desde Φi hasta Φn, para lograr un
encadenamiento ´optimo [65].
Definici´on 4 Para una Φ regi´on cubierta convexa del ´area global de cober-tura β con n nodos sensores de rango de detecci´on o sensibilidad Rs, y con
rango de comunicaci´on β, se dice que β≥2Rs [66].
En resumen, dado el conjunto S de la distribuci´on de nodos si, se puede
de-terminar que una regi´on β es Φi cubierta por al menos si+2 nodos sensores, es
decir que los nodos se encuentran organizados en cadena, con alcance de β2 yβi ≥
2Rs. Por lo tanto, aunque se pierda comunicaci´on con el nodo vecino se establece
5.2. PROPUESTA DE LA WSN 29
Rs
(xi,yi)
s1 s3
βi α
β
. . . sn
Φi . . .Φn
s1 s2 s3 s4
Figura 5.1: Esquema del sistema
El objetivo de lograr una cobertura integral y una configuraci´on ´optima de conectividad es maximizar el encadenamiento entre nodos para lograr una mayor robustez en la red, ante posibles fallas detectadas.
5.2.
Propuesta de la WSN
Con base al dimensionamiento y caracter´ısticas topol´ogicas de la red descrita en la Secci´on 5.1.1, para la implementaci´on de la red inal´ambrica de sensores, se requiere definir los nodos de la siguiente manera:
Un nodo Coordinador principal ZC el cual llevara el control de la in-formaci´on procesada por los nodos remotos de forma centralizada, definido tambi´en como Estaci´on Base.
30 CAP´ITULO 5. ARQUITECTURA E IMPLEMENTACI ´ON
En lo que respecta al direccionamiento, se realiza mediante ”grupos”. Hay que tomar en cuenta que el n´umero de ”saltos” m´aximos entre los nodos ZigBee en DIGI es de diez saltos. El ruteo se lleva a cabo mediante el Algoritmo AODV (ver Secci´on 2.4), con el cual el dimensionamiento de la red no deber´a ser mayor a 40 dispositivos [46]. Sin embargo, si la WSN es mayor a 40 elementos, en el ruteo AODV se requiere realizar un descubrimiento de ruta por cada dispositivo de des-tino para establecer la comunicaci´on entre los nodos de la red.
5.3.
Programaci´
on principal
De acuerdo al dimensionamiento, caracter´ısticas de la red y propuesta definida, se determina la programaci´on y configuraci´on de los radios XBee-PRO ZB S2B, y con base en lo descrito en la Secci´on 4.2.2, se realiza la selecci´on de firmware de acuerdo a las caracter´ısticas de operaci´on de la red.
5.3.1.
Env´ıo-recepci´
on de informaci´
on
Para el env´ıo-recepci´on e intercambio de informaci´on, hay dos modos de opera-ci´on, en la funcionalidad de los radios ZigBee. Uno es en modo AT (transparente), y el otro en modo API2
. Por las caracter´ısticas y funcionalidades de la red que se usa en este proyecto, la configuraci´on se lleva a cabo mediante el modo API. En es-te modo de operaci´on la comunicaci´on del m´odulo ZigBee se realiza medianes-te una interfaz estructurada (los datos son comunicados en tramas en un orden definido) como se aprecia en la Tabla5.1. Mediante el modo API se realiza el env´ıo-respuesta de informaci´on, as´ı como el env´ıo-respuesta de mensajes de estado entre los m´odu-los estructurando la ”frame” de informaci´on, para el env´ıo-recepci´on a trav´es de la UART. Entre las ventajas operacional del modo API al modo transparente son:
Muestras de E/S. Puede recibir E/S de datos de m´as de un dispositivo re-moto.
Acuse de recibo (ACK3
) y reintentos. Al enviar un paquete, la transmisi´on de radio recibe un ACK, lo que indica que el paquete fue entregado con ´exito. La transmisi´on por radio volver´a a enviar el paquete si no recibe un ACK.
2
Application Programming Interface 3
5.3. PROGRAMACI ´ON PRINCIPAL 31
Recibir paquetes (RX). El contenido de la direcci´on de origen en la trans-misi´on de radio remoto.
El env´ıo de paquetes de difusi´on (broadcast) en T X.
Obtener RSSI (intensidad de se˜nal) de un paquete de RX.
Los paquetes incluyen una suma de comprobaci´on (checksum) de integridad de los datos mediante CRC [67].
Cluster ID y perfil ID de los nodos remotos.
Delimitador de inicio longitud Frame de dato Checksum
(Byte = 1) (Bytes = 2-3) (Bytes = 4-n) (Byte = n+1)
0x7E MSB4
LSB5
API-Estructura 1 Byte
Tabla 5.1: Estructura de Frame API.
Definici´on de dispositivos
De acuerdo a la Secci´on2.2.1, con base en las funciones que realizan los dispo-sitivos, todos los nodos deben ser definidos del tipo Full Function Device (F F D). Mientras que, en lo correspondiente al tipo de nodo (ver Secci´on 2.2.2) se definen de la siguiente forma:
Coordinador
Mediante el software XCTU se instala el firmware en el m´odulo XBee-PRO ZB (S2B). La version correspondiente que define al radio es: 2xA07 ZIG-BEE COORDINATOR API6
.
Ruteadores
En la actualizaci´on de firmware, para definir los nodos remotos como Router, se instala la versionXBP24-ZB_23A7.ebl por medio del compilador Dynamic C. Se edita la plantilla en lenguaje C xbee_update_ebl.c, en la cual habr´a que definir los par´ametros de comunicaci´onRouter como velocidad de trans-misi´on en la interfaz serial BD (115,200 Baud) y el modo API entre otros.
6
32 CAP´ITULO 5. ARQUITECTURA E IMPLEMENTACI ´ON
Una vez realizada la instalaci´on del firmware (definiendo el modo de opera-ci´on) y configuraci´on de los radios, se realizan pruebas de comunicaci´on mediante el env´ıo de tramas (datagramas), tomando en cuenta la direcci´on SH y SL del m´odulo remoto, formando la estructura del paquete [46] se construyen las tramas de transferencia en la interfaz XCTU de prueba.
5.4.
Programaci´
on de nodos remotos
En la programaci´on de los nodos remotos (Ver Figura 5.2), hay que tomar en cuenta las variables a enviar, as´ı como los diversos par´ametros de mensaje de estados entre los m´odulos remotos a la estaci´on base. Estos mensaje de estatus se env´ıan o solicitan mediante comandos AT dentro de una estructura API [68], sitio del autor Tom Collins [69], las librer´ıas de desarrollo del compilador se localizan en el directorio de Windows
C:\DCRABBIT_10.72\Lib\Rabbit4000, mientras que los archivos de encabezado se encuentran en C:\DCRABBIT_10.72\include.
5.4.1.
Programaci´
on de env´ıo de informaci´
on API
El env´ıo de informaci´on se realiza siguiendo la capa XBee/ZigBee hasta llegar a la estructura API, definida como Simple XBee API (SXA) [68]. Se programa el env´ıo de informaci´on a la direcci´on del nodo destino, la cual fue previamente programada y agregada a la tabla que se autogenera en_sxa_select.c agregando a la estructura el dato a enviar y la longitud del mismo (Ver Ap´endice- A.1).
5.4.2.
Transferencia de informaci´
on de nodos remotos
La transferencia de informaci´on se realiza cuando un dato serial es recibido y esta listo para ser empaquetado, el m´odulo RF deber´a salir del modo libre (ver Figura5.3) e intentar la transmisi´on del dato. La direcci´on destino determina que nodo deber´a recibir el dato .5.4. PROGRAMACI ´ON DE NODOS REMOTOS 33
Figura 5.2: Nodo remoto con bater´ıa de 9 V.
5.4.3.
Env´ıo de informaci´
on de los puertos digitales
34 CAP´ITULO 5. ARQUITECTURA E IMPLEMENTACI ´ON
Figura 5.3: Secuencia del modo de transmisi´on.
5.5.
Estaci´
on base
Componentes para adquisici´on de datos
La comunicaci´on entre el radio Xbee nodoCoordinadory el servidor se realiza mediante PySerial [70]. Una vez recibida la informaci´on, esta es procesada por la API python-XBee 2.1.0 (ver ap´endiceA.3); con esta API se puede enviar y recibir informaci´on de la red. La sintaxis de la informaci´on en la shell [71] de Python se muestra en la Tabla 5.2.
Recepci´on de informaci´on
5.5. ESTACI ´ON BASE 35
##−−−NODO1
{’ s t a t u s ’ : ’\x00 ’ , ’ s o u r c e a d d r ’ : ’ I\x16 ’ , ’ s o u r c e a d d r l o n g ’ : ’\x00\x13\xa2\x00@\xa5\x84\x91 ’ , ’ f r a m e i d ’ : ’A ’ , ’command ’ :
’TP ’ , ’ pa r a meter ’ : ’\x00\x1d ’ , ’ i d ’ : ’ r e m o t e a t r e s p o n s e ’}
{’ p r o f i l e ’ : ’\xc1\x05 ’ , ’ s o u r c e a d d r ’ : ’ I\x16 ’ , ’ d e s t e n d p o i n t ’ : ’\xe8 ’ , ’ r f d a t a ’ : ’ 1 1 1 1 1 1 1 11 111 ’ , ’ s o u r c e e n d p o i n t ’ : ’\xe8 ’ , ’ o p t i o n s ’ : ’\x01 ’ ,
’ s o u r c e a d d r l o n g ’ : ’\x00\x13\xa2\x00@\xa5\x84\x91 ’ , ’ c l u s t e r ’ : ’\x00\x11 ’ , ’ i d ’ : ’ r x e x p l i c i t ’}
##−−−NODO2
{’ s t a t u s ’ : ’\x00 ’ , ’ s o u r c e a d d r ’ : ’ %\xb0 ’ , ’ s o u r c e a d d r l o n g ’ : ’\x00\x13\xa2\x00@\xa9 ˆ\x06 ’ , ’ f r a m e i d ’ : ’A ’ , ’ command ’ :
’DB ’ , ’ pa r a meter ’ : ’# ’ , ’ i d ’ : ’ r e m o t e a t r e s p o n s e ’}
{’ p r o f i l e ’ : ’\xc1\x05 ’ , ’ s o u r c e a d d r ’ : ’ I\x16 ’ , ’ d e s t e n d p o i n t ’ : ’\xe8 ’ , ’ r f d a t a ’ : ’ 1 0 1 1 1 0 1 11 111 ’ , ’ s o u r c e e n d p o i n t ’ : ’\xe8 ’ , ’ o p t i o n s ’ : ’\x01 ’ ,
’ s o u r c e a d d r l o n g ’ : ’\x00\x13\xa2\x00@\xa9 ˆ\x06 ’ , ’ c l u s t e r ’ : ’\x00\x11 ’ , ’ i d ’ : ’ r x e x p l i c i t ’}
Tabla 5.2: Visualizaci´on de la informaci´on recibida en shell de Python.
la API ZigBee_Transmit_Request de los dos nodos sensores remotos, es el ID de API 0x10, cuya respuesta de los nodos remotos se identificada como status. En ella se solicita la informaci´on de temperatura T P en nodo 1 y RSSI7
DB en el nodo 2. El valor de T P, parameter: \x00\x1d se expresa en c´odigo hexadecimal, mientras que DB parameter:\#, se expresa en forma de car´acter.
El par´ametroprof ile en ambos nodos corresponde a la llegada de informaci´on de las variables de estado en los nodos remotos, el\xc1\x05 corresponde al grupo cluster, rf_data muestra la informaci´on del valor de la variables de entrada en el m´odulo remoto y source_addr_long la direcci´on del nodo de donde proviene la informaci´on.
Env´ıo de informaci´on
Para solicitar informaci´on de estado o de mando a los nodos remotos, se env´ıa la solicitud mediante comando AT en conjunto con la direcci´on SH+SL de m´odulo remoto, mediante la API python-XBee 2.1.0 (Ver Ap´endice-A.3) La programaci´on
7
36 CAP´ITULO 5. ARQUITECTURA E IMPLEMENTACI ´ON
de tiempo de solicitudes de informaci´on de los nodos remotos se realiza por medio
deapscheduler [72], asignando el tiempo de solicitud a cada petici´on.
Componentes interfaz de usuario
En la interfaz de usuario se visualiza la informaci´on en tiempo real, mediante una interfaz Web donde se aprecia de forma gr´afica el estado de las variables en los nodos remotos (ver Ap´endice-C.1).
Flujo de informaci´on en la estaci´on base
El diagrama a bloque de la Figura5.4se muestra la secuencia del procesamien-to de la informaci´on en la estaci´on base. Esta llega de los nodos sensores remoprocesamien-tos al coordinador y ´este se comunica a trav´es de la interfaz RS-232 (Pyserial) la in-formaci´on es procesada por la APIP ython−Xbee. En esta act´ua Apscheduler, el cual es el encargado de programar las solicitudes de estado de los nodos remotos mediante comandos AT en API. Esta informaci´on de estado en conjunto con la informaci´on de eventos recibida de los nodos remotos, es enviada a la base de datos (PHP/MySQL). Una vez almacenada en la base de datos, ´esta es procesada (Codeignaiter, Jquery, plugins) para ser presentada en la interfaz de visualizaci´on web, de forma c´ıclica. Cada vez que un dato pasa de la interfaz RS-232 a la base de datos ´este es actualizado para ser presentado casi en tiempo real con un m´ınimo retardo de tiempo de 150 milisegundos.
Cap´ıtulo 6
Pruebas y conclusiones
En este cap´ıtulo se describe el comportamiento de la WSNs, con base en las pruebas de simulaci´on realizadas. Tomando como par´ametro la distancia entre nodos, analizando la transferencia de informaci´on de estatus y transferencia de informaci´on en las entradas digitales y anal´ogicas de los nodos sensores remotos a la estaci´on base. Se concluye con una propuesta de continuidad de este trabajo.
6.1.
Pruebas de funcionalidad
La funcionalidad del sistema en la transferencia de informaci´on depende de la conexi´on inal´ambrica de la red, por ello es necesario asegurar que se pueda garan-tizar una conexi´on estable y una transmisi´on fiable de datos, a trav´es de la WSN, mientras el sistema en conjunto sea capaz de realizar una transmisi´on de informa-ci´on a una tasa de transferencia razonable y con p´erdida m´ınima de informainforma-ci´on. Para ello, con base en los conceptos de dise˜no realizados en la Secci´on5.1 sobre las l´ıneas el´ectricas de alta tensi´on, habr´a que realizar pruebas de enlaces basados en la distancia y ubicaci´on de los nodos sensores. Estas pruebas deber´an de garantizar una transferencia de informaci´on e intensidad de se˜nal ´optima.
6.1.1.
Distancia entre nodos e intensidad de la se˜
nal
De acuerdo al an´alisis descrito en el Secci´on 5.1, para garantizar la comunica-ci´on inal´ambrica entre nodos. Las pruebas de comunicacomunica-ci´on del enlace en distancia se realizan de dos formas: a trav´es de l´ınea de vista y sin l´ınea de vista de enlace entre los nodos sensores.
38 CAP´ITULO 6. PRUEBAS Y CONCLUSIONES
200 400 600 800 1,000
30 40 50 60 70 80 90 100 Distancia (metros) In te n sid ad d e S e˜n al ( d B )
S1=258
V1=454
S2=384
V2=702
Figura 6.1: Gr´afica de distancia e intensidad de se˜nal.
En las pruebas realizadas con l´ınea de vista se obtuvo un alcance de 702 metros de distancia, con 88 dB de intensidad de se˜nal (ver l´ınea caf´e de la Figura 6.1), mientras que sin l´ınea de vista se obtuvo un alcance de 384 metros a 89 dB de intensidad de se˜nal (ver l´ınea verde de la Figura 6.1), en la gr´afica tambi´en se pueden apreciar los par´ametros iniciales de intensidad de se˜nal contra la distancia entre nodos.
6.1. PRUEBAS DE FUNCIONALIDAD 39
Msj. estado: ATDB, ATTP...AT
Ncoord NR1 estatus-E/S
Salto(n+1)
NR2 estatus-E/S
ACK
Figura 6.2: Diagrama esquem´atico de la transferencia de informaci´on de los nodos remotos a la estaci´on base.
6.1.2.
Solicitud de variables de estado
Mediante la estaci´on base se realiza la solicitud de informaci´on de variables de estado de los nodos remotos. Este tiempo de solicitud se realiza cada 12 segundos y 14 segundos, respectivamente, de cada nodo NR. Las variables solicitadas son: temperatura, voltaje e intensidad de la se˜nal.
En la figura del Ap´endice A.3 se muestra la programaci´on de solicitud de las variables de estado, as´ı mismo en la Figura 6.2 se muestra de forma descriptiva el flujo y solicitud de informaci´on las variables de estados de los nodos NR sensores al nodo coordinador o estaci´on base.
6.1.3.
Variables digitales
La transferencia de informaci´on digital se realiza mediante un evento secuencial [74] de los nodosNR1 yNR2 al nodoNcoord en la estaci´on base para ser presentada
en la interfaz web. En esta interfaz web se muestra parte de la informaci´on recibida deNR1yNR2, en la figura del Ap´endiceC.1se aprecia la interfaz de visualizaci´on
de estado de los nodos NR1 y NR2. En la cual, se muestran los cambios de color
verde a color rojo cuando ocurre un evento en las interfaces de entrada digitales de los nodosNR1,NR2 e indicando el estado de las variables en los nodos remotos. A
40 CAP´ITULO 6. PRUEBAS Y CONCLUSIONES
La transferencia de informaci´on se realiza de la siguiente forma (ver Figura6.2).
NR2 ⇐⇒ NR1 ⇐⇒ Ncoord
NR2 ⇐⇒ Ncoord
NR1 ⇐⇒ Ncoord
6.2.
Conclusiones
1. Se ha desarrollado un sistema de red inal´ambrica de sensores orientado al manejo de informaci´on relacionada con la operaci´on de l´ıneas el´ectricas de alta tensi´on. El sistema incluye la programaci´on, comunicaci´on y desarrollo de un prototipo capaz de capturar informaci´on a partir de sensores est´andar como de sensores de aplicaci´on espec´ıfica.
2. Las se˜nales obtenidas por un grado de n nodos son concentradas en una estaci´on base para el procesamiento digital de las diferentes condiciones de falla, habilitando a los ingenieros responsables del sistema para proporcio-nar una respuesta r´apida y b´ıen fundamentada de atenci´on a los problemas detectados.
3. Con base en las pruebas f´ısicas realizadas del enlace, flujo y transferencia de informaci´on en el sistema, se ha podido comprobar la factibilidad de imple-mentar esta tecnolog´ıa en el entorno real, para analizar mediante la misma el comportamiento de las variables que intervienen en el monitoreo de las l´ıneas el´ectricas de alta tensi´on.
6.2. CONCLUSIONES 41
6.2.1.
Propuestas para trabajo futuro
Con base en los conceptos descritos en esta tesis se pueden considerar las alter-nativas para extender la red y realizar pruebas en el entorno. Cabe se˜nalar que el trabajo aqu´ı reportado es la primera etapa de un proyecto m´as ambicioso y com-plejo, pero la solidez de su desarrollo proporciona la plataforma de comunicaci´on de una red inal´ambrica de sensores capaz de capturar, recopilar y concentrar la informaci´on requerida para el monitoreo eficaz de fallas en l´ıneas de alta tensi´on. A continuaci´on se mencionan algunas de las posibles l´ıneas de investigaci´on.
Escalabilidad del sistema.La red se puede extender mediante la incor-poraci´on de m´as nodos remotos, y contando tambi´en con la evoluci´on del protocolo ZigBee, ser´a posible aumentar el alcance entre nodos de la red inal´ambrica y por ende tener un mayor encadenamiento entre ellos, robuste-ciendo la misma.
Sensores y actuadores.Una vez establecida la plataforma de comunica-ci´on de la red, se puede proceder al desarrollo e incorporacomunica-ci´on de elementos sensores en el entorno real de las l´ıneas el´ectricas de alta tensi´on, para so-meterlos a pruebas y caracterizaci´on.
Interfaz web. Es necesario el desarrollo de la interfaz de administraci´on web de acuerdo a la escalabilidad de la red. No solo se podr´a monitorear y solicitar informaci´on de estado en los nodos remotos, sino tambi´en tener el control de los mismos.
Sistema de captura de energ´ıa. Uno de los aspectos m´as importantes en la operaci´on de las redes de sensores es el del suministro de energ´ıa a los nodos remotos. Se requiere desarrollar e implementar s´ıstemas que capturen energ´ıa a partir del medio en que operan, en este caso de las mismas lineas que son monitoreadas, para garantizar la autonom´ıa del sistema y hacerlo sustentable.
42 CAP´ITULO 6. PRUEBAS Y CONCLUSIONES
Ap´
endice A
C´
odigo de desarrollo
A.1.
Env´ıo de dato
i n t s e n d d a t a ( const s x a n o d e t FAR ∗sxa , void FAR ∗data , u i n t 1 6 t l e n g t h )
{
i n t s t a t u s ;
w p a n e n v e l o p e t env ;
w p a n e n v e l o p e c r e a t e ( &env , &my xbee . wpan dev , &sxa−>i d .
i e e e a d d r b e ,
sxa−>i d . netwo r k a ddr ) ;
env . pa ylo a d = da ta ; env . l e n g t h = l e n g t h ;
do {
s t a t u s = x b e e t r a n s p a r e n t s e r i a l ( &env ) ;
i f ( s t a t u s == −EBUSY) {
s x a t i c k ( ) ;
// Permit e e l p r o c e s a m i e n t o de r e s p u e s t a s de e n t r a d a o s o l i c i t u d e s .
// Espera un b i t y hace e l r e i n t e n t o . }
} while ( s t a t u s == −EBUSY) ;
return s t a t u s ; }
44 AP ´ENDICE A. C ´ODIGO DE DESARROLLO
A.2.
Lectura de puertos digitales
i n t P o r t D i g i t a l e s ( void) {
char cmdstr [ 8 0 ] ; i n t s t a t u s ; i n t c h a n n e l ; i n t r e a d p o r t D i g ; i n t PortDig ;
char Da to sAenvia r [ 1 3 ] ; char Send Dig da to [ 1 3 ] ;
b r d I n i t ( ) ; // I n i c i a l i z a E/S d i g i t a l e s y c o n v e r t i d o r A/D
f o r( c h a n n e l = 0 ; c h a n n e l < BL DIGITAL IN ; ++c h a n n e l )
// L e c t u r a de l o s 12 p u e r t o s D i g i t a l e s {
s e t D i g I n ( c h a n n e l ) ; }
f o r( c h a n n e l = 0 ; c h a n n e l < BL DIGITAL IN ; ++c h a n n e l ){
r e a d p o r t D i g = d i g I n ( c h a n n e l ) ; i f( r e a d p o r t D i g )
Send Dig da to [ c h a n n e l ] = 4 9 ; e l s e
Send Dig da to [ c h a n n e l ] = 4 8 ; p r i n t f ( ” %d ” , r e a d p o r t D i g ) ;
}
// Envio de e s t a d o i n i c i a l
s t a t u s = s e n d d a t a ( sxa , Send Digdato , BL DIGITAL IN ) ;
p r i n t f ( ”\n” ) ;
while( 1 ) {
f o r( c h a n n e l = 0 ; c h a n n e l < BL DIGITAL IN ; ++
c h a n n e l ) {
r e a d p o r t D i g = d i g I n ( c h a n n e l ) ; i f( r e a d p o r t D i g )
Da to sAenvia r [ c h a n n e l ] = 4 9 ; // Est ado de v a r i a b l e 1
e l s e
Da to sAenvia r [ c h a n n e l ] = 4 8 ; // Est ado de v a r i a b l e 0
p r i n t f ( ” %d ” , r e a d p o r t D i g ) ;
i f( Da to sAenvia r [ c h a n n e l ] != Send Dig da to [ c h a n n e l ] )
A.3. C ´ODIGO EN ESTACI ´ON BASE 45
s t a t u s = s e n d d a t a ( sxa , DatosAenviar , BL DIGITAL IN ) ;
// Comparacion de d a t o a n t e r i o r con d a t o a c t u a l
Send Dig da to [ c h a n n e l ] = Da to sAenvia r [ c h a n n e l ] ;
}
p r i n t f ( ”\n” ) ; }
}
A.3.
C´
odigo en estaci´
on base
#! / u s r / b i n / p y t h o n #! / u s r / b i n / p y t h o n
import MySQLdb # Base de d a t o s MySQL s o c k e t
import serial # p y s e r i a l c o n e x i o n s e r i a l
from xbee import ZigBee # API Xbee ZigBee ( Greg Rapp )
# I n s p i r e d by c o d e w r i t t e n by Amit Synderman and Marco S a n g a l l i
from xbee import base # API Xbee ZigBee ( By Paul
Malmsten )
from apscheduler . scheduler import Scheduler
import Queue
packets = Queue . Queue () # El p a q u e t e e s p u e s t o en c o l a
PORT = ’/ dev / ttyS0 ’
BAUD RATE = 115200
NODO REM1 = ’\x00\x13\xa2\x00\x40\xa5\x84\x91 ’
NODO REM2 = ’\x00\x13\xa2\x00\x40\xa9\x5e\x06 ’ # A b r i r p u e r t o S e r i a l , a 115200 b a u d i o s .
ser = serial . Serial ( PORT , BAUD RATE )
# Crea e l O b j e t o API=1 s i n c a r a c t e r de e s c a p e
xbee = ZigBee ( ser , escaped = False )
def hextobin ( cadena ):
str= cadena . encode (’ string escape ’)
return str. replace (’x ’,’’). replace (’^ ’,’5e ’).
replace (’@’,’’). replace (’\\’,’’). replace (" ’",""
). strip ()
46 AP ´ENDICE A. C ´ODIGO DE DESARROLLO
#Envio de d i f u s i o n
sendPacket ( BROADCAST , ’\xff\fe\r ’)
# S o l i c i t u d de i n f o r m a c i o n remota d e l nodo 1 , m e d i a n te de SH y SL a d d r=64 b i t s
def at commands () :
print " INFORMACION NODO1 "
#S o l i c i t u d de RSSI ( R e c e i v e d S i g n a l S t r e n g t h I n d i c a t i o n )
xbee . remote at ( d e s t a d d r l o n g = NODO REM1 , command =" DB ", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM1 , command =" %V", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM1 , command =" ID ", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM1 , command =" CH ", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM1 , command =" SL ", frame id ="A")
#S o l i c i t u d de t e m p e r a t u r a d e l s i s t e m a remoto 1
xbee . remote at ( d e s t a d d r l o n g = NODO REM1 , command =" TP ", frame id ="A")
# S o l i c i t u d de i n f o r m a c i o n remota d e l nodo 2 , m e d i a n te SH y SL a d d r=64 b i t s
def at commands2 () :
print " INFORMACION NODO2 "
#S o l i c i t u d de RSSI ( R e c e i v e d S i g n a l S t r e n g t h I n d i c a t i o n )
xbee . remote at ( d e s t a d d r l o n g = NODO REM2 , command =" DB ", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM2 , command =" %V", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM2 , command =" ID ", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM2 , command =" CH ", frame id ="A")
xbee . remote at ( d e s t a d d r l o n g = NODO REM2 , command =" SL ", frame id ="A")
