Soporte técnico para una instalación de arte...

Parte VIII.

Cálculos

379

16. Cálculos

16.1. Cobertura inalámbrica y diseño de red

Esta sección realiza un repaso de las características técnicas de ZigBee que sirvencomo base teórica para la configuración del sistema desarrollado. Se estudian sóla-mente aquellos aspectos del estándar que interesan para la realización del SoporteTécnico; en particular, aquéllos que sirven parapueden garantizar la movilidad ylocalización de nodos, la robustez del sistema y la implementación de mecanismosde racionalización del consumo. Partimos aquí de la descripción técnica realizadaen la Memoria y de las referencias técnicas que allí se presentan. Un estudio máscompleto de la tecnología puede encontrarse en otros trabajos académicos, como elproyecto fin de carrera de Marín Díaz.

Características de 802.15.4. Banda de transmisión

En el cuadro siguiente, se resumen las características de transmisión propias delestándar 802.15.4, con indicación de las técnicas y capacidades de la transmisiónsegún el canal de comunicación.

Figura 16.1.: Resumen de características técnicas del estándar 802.15.4

Para el desarrollo del Soporte Técnico, se ha adoptado el canal de 2,4 GHz por sumayor capacidad y la disponibilidad de mercado de componentes que trabajan enesta banda. Es cierto que las bandas de frecuencia a 868 - 915 MHz ofrecen algunasventajas, por su menor saturación y niveles de interferencia y absorción de señal,pero no compensa con ello la capacidad de ancho de banda 6 veces superior de labanda 2450.El estandar 802.15.4 incorpora funcionalidades que permiten compensar los factoresadversos del medio de transmisión; tal es el caso de la detección de energía, que puede

381

Capítulo 16 Cálculos

ser utilizada por la capa superior de software para medir y evitar la interferenciade canales de radio en un entorno cambiante, o para seleccionar el mejor canal defrecuencia en la etapa de despliegue de la red[?, ?].La selección de un canal de comuncación para nuestro sistema no obedece, en todocaso, sólo a razones de capacidad. La necesidad de una red de sensores surge cuandoqueremos captar información del entorno de la instalación artística de forma capi-lar, transparente y adaptativa. El estudio de los posibles usos de la WSN, con laenumeración de los servicios incorporados a sus nodos, apunta a una necesidad deancho de banda que la configuración de red debe garantizar. A partir de este pun-to, no obstante, la comunicación debe cumplir un segundo nivel de especificación,garantizando una calidad en la comunicación adecuada a las exigencias dinámicasdel Soporte Técnico, para conseguir una respuesta temporal acotada y adecuada alfenómeno dinámico que estamos observado, que no es otro que el movimiento de losespectadores.Algunos investigadores (por ejemplo,[15]) han estudiado la influencia de los paráme-tros de comunicación en la eficacia de distintas aplicaciones de localización, apun-tando a una menor eficiencia del canal de 800 MHz para la localización basada enmedidas de potencia (que es la técnica de base aplicada aquí), presentando peoresprestaciones en cuanto a rendimiento y estabilidad del enlace que los demás. Comoquiera que la banda de 915 MHz no es de dominio público en Europa, esto conviertea la banda de 2 GHz en la candidata ideal para el despliegue del bloque inalámbricode sensores / actuadores del Soporte.

Cobertura inalámbrica de la instalación. Topología WSN

Las características del espacio de referencia ya se han comentado en Subsección 15.2.1y nos sirven como punto de partida para establecer una estrategia de coberturainalámbrica de la instalación, necesaria para garantizar que cualquier visitante por-tando un dispositivo de localización sea rastreado por el sistema. En general, unainstalación interactiva va a ubicarse en un radio inferior a los 100 metros y en unespacio abierto, por lo que, aunque se trate de un espacio interior, podemos ignorarla presencia de obstáculos a la propagación y la ubicación de los equipos dentrode la instalación. Asumiendo estas condiciones, los aspectos que preocupan en laplanificación de la red son la colocación de los equipos y el establecimiento de lacomunicación entre ellos.El rango de la transmisión ZigBee depende fundamentalmente de las característicasde potencia del equipo y del entorno de trabajo. Con un dispositivo común (conuna potencia de transmisión de 0 dBm), puede obtenerse un rango de transmisiónde unos 200 metros (con los equipos de prueba, el fabricante garantiza una distan-cia máxima de 450. Dentro de un edificio, sin embargo, los efectos de absorción,reflexión y onda estacionaria reducen la propagación de la señal, limitándola a unalcance promedio de unos 30 metros. Varias medidas son factibles para aumentar

382

16.1 Cobertura inalámbrica y diseño de red

esta distancia: mayor potencia de transmisión (la distancia puede triplicarse contransmisores de 15 dBm) y una adecuada configuración de la topología. Efectiva-mente, 802.15.4 puede extender el alcance de la red al permitir una topología enárbol con nodos intermedios, de tal forma que la distancia máxima del árbol no lafije el alcance del nodo Coordinador, sino la cantidad de saltos que la señal puedellegar a dar sin degradar la calidad de la conexión del dispositivo más alejado delcentro de la red.Considerando las reducidas dimensiones de una instalación y el hecho de que, dentrodel escenario de una obra, podemos asumir un medio de propagación homogéneo, laadopción de una topología de red no debería afectar a la cobertura del movimientode un visitante. El criterio para la elección de una configuración de red debería ver,en todo caso, por su impacto en el tráfico de la red.IEEE 802.15.4 permite varias topologías (estrella, malla o árbol), con la única con-dición de que una red siempre debe contener un PAN Coordinator. Las topologíasen sí no son parte del estándar, sino que la propagación es manejada por las capaspor encima de 802.15.4, como la capa de red ZigBee.Una red en árbol mantiene una estructura que facilita el encaminamiento. Los men-sajes no siempre tienen que atravesar el Coordinador, empezando por un paso directodel emisor original a su nodo padre, que decidirá el camino:

Si el nodo destino es también un “hijo” suyo, el mensaje pasará directamentea él.Si el nodo destino no es un “hijo” de este “padre”, el mensaje pasará al no-do padre directamente por encima en la topología. Este nodo podrá entoncesdeterminar si el mensaje tiene que bajar a alguno de sus hijos o seguir as-cendiendo en la red. Si el mensaje llega a la raíz de la red, el Coordinadoractua como el último padre y envía el mensaje hacia su destinatario en sentidodescendente.

El enrutamiento en árbol se apoya en tablas configuradas en los nodos padre obien en mecanismos de direccionamiento especiales, en los que la dirección del nododepende de su posición en la red.Por su parte, en una red en malla, hay al menos un grupo de nodos con capacidadpara comunicarse unos con otros, pero no se mantiene una estructura lógica de redpara ayudar al encaminamiento de mensajes. A pesar de esto, son factibles algunosmétodos de encaminamiento; uno de ellos es difundir el mensaje a todos los nodos dela red, aunque es poco efectivo. Otro incluye el uso de tablas de enrutamiento, conla peculiaridad de que éstas se van actualizando con la información intercambiadaentre nodos[?].A la luz de las características del Soporte Técnico, parece evidente que una topologíaen malla aporta más ventajas que una configuración en estrella o en árbol. La WSNdel Soporte consta de nodos fijos, además del Coordinador, que siempre van a par-ticipar en la red y que desempeñan un papel protagonista en las tareas de conexión

383


del visitante y en la generación de efectos interactivos. El tráfico entre estos nodoses muy específico y totalmente ajeno al Coordinador y, para muchas funciones, tam-bién al Visitante; por lo tanto, estas balizas conforman una capa dorsal dentro dela WSN, a la que corresponde una comunicación todos con todos para minimizar elnúmero de saltos de los mensajes. Por otra parte, la movilidad de los nodos Visitanteva paralela a la función de localización, por lo que parece más eficaz dirigir todala comunicación de los Visitantes hacia los nodos que van a ayudarle en esta tarea;como quiera que los Visitantes obtienen respuesta de las balizas, el acceso de losVisitantes se restringe a las balizas, que se configuran para actuar como padres enla topología y mediar en la comunicación de su hijo móvil con las entidades de fuerade la WSN (el Servidor), de forma transparente a la aplicación.

La red WSN, en definitiva, va a estar dividida en una zona dorsal, donde se conectantodos los nodos Router (balizas, LightCube / ZoneGuard) y una zona de acceso, dondese conectan los Visitantes en estrella a los Routers. Habría que considerar dos zonasmás, correspondientes al núcleo en torno al Coordinador y la conexión Pasarela haciael Servidor. Todos los servicios y funciones complementarias del Soporte Técnico seubican en alguna de estas delimitaciones. Será la configuración del nivel de red, juntocon el correcto encabezado de las transacciones propias a cada objeto de aplicación,la que determine el camino de propagación, el ámbito y la duración de cada mensaje.

Plan de frecuencias

La elección de las frecuencias de despliegue es importante, dado que la instalaciónde referencia dispone de una red UPnP que presumiblemente va a utilizar 802.11como soporte físico y una red 802.15.4 para el despliegue WSN. Como vemos en lailustración, ambas redes deben convivir en la misma banda, en un ambiente que pre-sumiblemente va a estar ocupado por toda clase de dispositivos que pueden afectara las comunicaciones y las funciones del sistema que dependen de las característicasdel canal.

A priori, el despliegue de la red AV resulta menos comprometedor, ya que UPnP vaa operar sobre una red WiFi convencional. Por tanto, nos centramos en la configu-ración del canal para la red ZigBee.

384


En la ilustración anterior, vemos que un canal ZigBee ocupa un ancho de espectromenor que un canal 802.11, teniendo su frecuencia central desplazada 2 MHz conrespecto a las centrales de los canales WiFi. En un ambiente libre de redes 802.15.4,la elección del canal 11 garantiza una mayor protección frente al ruido de redes WiFicolindantes, ya que la señal de una WiFi en el canal 1 sólo se superpone al canal11 en una franja de 4 MHz, pero no podemos garantizar que en el entorno de lainstalación no se encuentren desplegados otras redes similares, ni que el entorno estélibre de fuentes de ruido que afecten a la comunicación PAN de forma impredecible,haciendo de la elección del canal de transmisión un detalle que sólo puede resolversesobre la planta real de control.Afortunadamente, 802.15.4 dispone de mecanismos de escaneo de frecuencia, dele-gando en las capas superiores la elección del canal más apropiado para la comuni-cación. Estos mecanismos pueden aplicarse en distintos escenarios de conexión:

En el momento de la conformación, debe escogerse una frecuencia para elestablecimiento de la red. Esta tarea es realizada por el Coordinador, queaprovecha la capacidad de escaneo y detección de energía para escoger el canalmás adecuado (normalmente, el que se encuentre menos ocupado o afectadopor el ruido).También, cuando un nodo quiere conectar con la red, debe encontrar primeroel canal de comunicación donde está desplegada su red. El nuevo dispositivodebe contar de antemano con la PAN ID de la red para realizar cualquiera delas pruebas siguientes:

• Sondeo Activo de Canal, por el que el nodo envía una serie de tramasde solicitud para que pueda ser detectado por los Coordinadores de suentorno; aquél que maneje la red con la PAN ID específica será el queresponda a la solicitud.

• Sondeo Pasivo de Canal (sólo en modo de envío síncrono), en el que elnodo puede escuchar las marcas periódicas de sincronismo enviadas porel Coordinador para detectar la actividad dentro de una banda.

Cuando un nodo de la red queda “huérfano” (ha perdido la conexión con suCoordinador), debe realizar un sondeo de canal para volver a conectarse. Estesonde especial supone el envío de tramas de información de estado por canalesconcretos, con la esperanza de que el Coordinador detecte el mensaje difundidoy responda con un comando de reconexión.

Estas funciones son realizadas por la subcapa MAC de 802.15.4 como respusa a unasolicitud de una capa superior[?]. En el caso de nuestro sistema de prueba, la versiónde desarrollo del Stack ZigBee no incorpora las primitivas para invocar las funcionesde sondeo MAC, pero otras versiones de Stack sí cuentan con una implementacióncompleta de las especificaciones 802.15.4, pudiendo utilizarse como base para eldesarrollo de herramientas de diagnóstico y ajuste sobre terreno de ayuda en lasprimeras etapas de diseño de una instalación interactiva.

385


En la siguiente fotografía, por ejemplo, tenemos el aspecto del panel LCD de undispositivo programado con la herramienta Site-Survey Tool de Jennic, que sirveprecisamente para detectar el nivel de ruido de los canales 802.15.4 ([?]).

Figura 16.2.: Mote Jennic con la aplicación Site Survey

Con una red ZigBee establecida en 2405 MHz, podemos calcular el alcance de la redpara unas condiciones adversas de comunicación y una especificación de dispositivoque corresponda al peor de los equipos disponibles, con una antena de baja potenciay sensibilidad. Estos cálculos se han realizado siguiendo la guía del libro ZigbeeWireless Networks and Transceivers y la herramienta de cálculo que lo acompaña1.Estos datos justifican la topología de la red, al permitir un rango máximo de 32metros entre el Coordinador y el Visitante más alejado del centro, gracias a la con-figuración de las balizas como Routers padre para los nodos finales. A partir de estemodelo y las condiciones calculadas, vamos a considerar cualquier factor atenuantecomo una pérdida de ancho de banda, limitando el tráfico máximo circulante haciay desde el Servidor y, con ello, la velocidad de respuesta del Soporte.

Aspectos de gestión energética

La instalación de un Soporte Técnico basado en medios inalámbricos debe contarcon la necesidad de instalar y mantener las fuentes de alimentación en los propiosequipos. En términos sistémicos, la autonomía del sistema es equivalente a la delequipo que consume más rápidamente su batería, por lo que una parte fundamentalen el diseño es la identificación de estas fuentes y la caracterización del consumo decada equipo, tratando además de incorporar a nivel software la gestión de los nivelesde autonomía para que éstos no afecten a la estabilidad de la aplicación.

1http://www.learnzigbee.com/Calculators.html

386

http://www.learnzigbee.com/Calculators.html


Estimación del rango entre dos nodos

Potencia de trasnmisión nodo A =P0(dBm)

-3

Sensibilidad de recepción nodo B =Sr(dBm)

-85

Expontente de pérdida del trayecto =n

2,5

Margen de desvanecimiento = Fm(dB) 10

Frecuencia de señal = f (MHz) 2405

Rango estimado en metros 16Cuadro 16.1.: Estimación de la distancia para un transmisor ZigBee genérico

Nos centraremos en los aspectos de consumo de los equipos WSN, ya que éstos suelenalimentarse por medio de pilas de baja capacidad y, por tanto, son críticos para eldimensionamiento del sistema. A pesar de que el Soporte considera la necesidadde un mantenimiento de los equipos, una de las especificaciones del Proyecto es elcontrol del consumo y la maximización de la autonomía de los equipos, por lo quevamos a estudiar los mecanismos que facilitan los protocolos 802.15. 4 y ZigBee parael cumplimiento de este objetivo.A nivel físico, las características de la transmisión y el diseño de los componenteselectrónicos de comunicación afectan directamente al consumo del equipo. Es porello que los equipos 802.15.4 se caracterizan por las siguientes propiedades:

Una baja latencia: El tiempo medio de transmisión de un nodo 802.15.4 estáestimado en 0,55 ms. Considerando el tiempo de activación, procesamiento dedatos de los sensores integrados, conversión CAD, envío y espera de asenti-mientos, el ciclo de actividad de un nodo ronda los 14 ms.Bajo consumo: Para estos tiempos de actividad, las operaciones de transmisión/ recepción consumen una media de 6,60E-06 mAH, debido, entre otros fac-tores, a la eficiencia energética del esquema de modulación OQPSK empleadopara la transmisión en el canal de 2,4 GHz ([?]).

A nivel ZigBee, el estándar facilita varios mecanismos para maximizar la autonomíade la red. En redes suficientemente pobladas, una técnica muy común es poneralgunos nodos en modo de hibernación2 y emplear sólo un grupo de nodos activospara las funciones de captación y comunicación. Esta técnica se denomina SleepScheduling o control de densidad. El objetivo de esta gestión es doble: por una parte,garantizar la funcionalidad de la red durante el mayor tiempo posible, pero además,

2Denominado en ZigBee Sleep Mode

387


también, reducir el tráfico redundante, minimizando el retraso en el reenvío y lacolisión entre paquetes.Los parámetros fundamentales para la programación del modo de actividad o sue-ño de cada nodo son la cobertura y la conectividad dentro de la red. Una red desensores permanece conectada mientras todos los nodos pueden enviar sus mensa-jes a cualquier destinatario, ya sea por un enlace directo o en varios saltos. Por suparte, la cobertura es el área que puede ser monitorizada por el conjunto de losnodos activos. Como podemos imaginar, el algoritmo de gestión debe evaluar deforma colectiva el estado de la red para establecer el estado de cada nodo, ya quedebe quedar garantizada en todo momento la cobertura de la planta de control y lacomunicación de todos los nodos dentro de la red ([5]).

En nuestro escenario de trabajo, no podemos garantizar la cobertura de la instalaciónsi se desactiva alguno de los nodos de la zona dorsal de la WSN (los LightCube), notanto por la pérdida de conectividad de los nodos Visitante (que, por las dimensionesde la instalación, siempre podrán conectarse a otro Router más alejado), sino por laconfiguración de los Dispositivos de Servicio instalados en cada nodo. Efectivamente,cada dispositivo de la red dorsal desempeña un papel estructural en el desarrollode los servicios del Soporte, tanto en la localización como en la sincronización y lagestión escénica, por lo que la desconexión de uno de ellos equivale a la desapariciónde una parte del Soporte. Esta circunstancia podría suplirse sólo si la red WSNestuviera compuesta por un número suficiente de equipos que puedan sustituirseen las labores de coordinación de los servicios, pero, dada la limitada cantidad deequipos de prueba utilizados en el Proyecto y la complejidad añadida que supondríael sistema de identificación de dispositivos, no se ha desarrollado esta opción y, enconsecuencia, ni el Coordinador ni los Routers pueden ejecutar ciclos de sueño. Noasí los nodos móviles, que, de hecho, van a pasar la mayor parte del tiempo ensilencio; auque no forma parte de la aplicación desarrollada, la implementación deestos modos de hibernación en los nodos finales es perfectamente compatible con la

388


gestión de su movilidad dentro de la red y la estructura de actividad general de losdispositivos Visitante, por lo que podrían configurarse para aumentar su autonomíapor medio de ciclos de sueño.En la siguiente tabla, se describe en términos de consumo energético la estructurade actividad de un nodo WSN del Soporte Técnico:

Paso Acción Duración(ms)

Corrientepromedio (uA)

Energía(nAH)

1 Activación del equipo 50 50 0,69442 Captación de

información desensores,

procesamiento yalmacenamiento

0,2 5.000 0,28

3 Recepción de paquetes 6 25.000 41,674 Transmisión de

paquetes0,55 25.000 3,82

5 Espera deasentimientos

0,25 25.000 1,74

6 Hilo de ejecución dela aplicación (main)

33 35.000 320,83

TOTAL 96,8 416,25Cuadro 16.2.: Consumo energético del escenario de aplicación WSN del Soporte

A partir de estos datos, podemos estimar la duración de una batería genérica de1000 mAH con una rendimiento del 45% y un factor de descarga del 0,5% mensual.Podemos ver los resultados en la Tabla 16.3.En el Soporte Técnico, el perfil de consumo de los nodos Lightcube corresponderíaal A+, con una actividad frecuente e ininterrumpida, lo que nos obliga a considerarfuentes alternativas de energía para estos nodos, ya que la vida media estimada deuna batería en estos equipos es de 4,2 días (algo mayor en realidad, si consideramosque la instalación no va a permanecer abierta 24 horas al día). Por su parte, losnodos Visitante se moverán entre los perfiles B- y A-, ya que pueden permanecergrandes periodos de tiempo sin realizar ningún intercambio con el Servidor (porquese encuentran demasiado alejados del Coordinador como para conectarse a la red),pero, una vez entran en su estado activo, mantienen varios diálogos en paralelocon los nodos WSN y el nodo central del sistema; en suma, la autonomía estimadapara estos equipos, con las características de consumo y la fuente indicadas, esde 1 mes aproximadamente. Para mejorar esta característica, el Soporte deberíaincluir un protocolo de gestión del sueño y, consecuentemente, un mayor número dedispositivos.

389


Perfil Pausa entreciclos (s)

Energía totalconsumida enun mes (mAH)

Vida de labatería(meses)

A+ 0,25 3114,40 0,14A- 1,23 825,89 0,6B+ 6,06 178,53 2,5B- 29,85 39,36 11,4C+ 146,97 10,67 42,2C- 723,68 4,82 93,3D+ 3.563,45 3,633 123,9D- 17.546,56 3,391 132,7

Cuadro 16.3.: Estimación de la autonomía de los equipos WSN por su tiempo deinactividad

16.2. Secuencia de arranque

La secuencia de arranque del Soporte Técnico corresponde a la realización del casode uso Arrancar el Sistema y del caso Habilitar el Soporte Técnico. Con elprimer caso, se garantizan las condiciones para la ejecución de la aplicación, en con-diciones generales, comunes a cualquier modo operativo o uso que se quiera hacerdel Soporte. A estas condiciones se las denomina servicio y al tramo de la secuenciade arranque que garantiza el servicio al sistema se le denomina “Puesta en Servicio”.La puesta en servicio es el primer estado de automatización del ciclo de vida de laexposición, como queda recogido en la Subsección 15.1.1. En el mismo esquema dela Figura 15.2, vemos que a la puesta en servicio le sigue un estado de “Puesta enMarcha”, que supone la creación de los hilos principales de ejecución de la aplicación,una vez que ya se han desplegado todos los componentes de infraestructura y debeconfigurarse la plataforma de servicios para adecuarse al modo de ejecución escogi-do por el administrador del sistema. Todos los modos operativos siguen la mismasecuencia, presentando sólo variaciones en los elementos invocados en cada paso dela puesta en marcha - como veremos en el siguiente apartado -, conduciendo al buclede ejecución del Soporte, donde se desarrollan todos los demás casos de uso.

La secuencia de arranque se divide, por tanto, en Puesta en Servicio y Puesta enMarcha. En la siguiente imagen, se detalla la secuencia interna de estas etapas delarranque:

390

16.2 Secuencia de arranque

Figura 16.3.: Puesta en Servicio y Puesta en Marcha del Soporte Técnico

Puesta en Servicio

La Puesta en Servicio se define como la secuencia de acciones sobre los equipos delsistema previas a la aplicación que garantizan las condiciones para su ejecución.Dentro de la secuencia de arranque, corresponde a la realización del caso Iniciarel Sistema, quedando organizada en tres etapas y dos transiciones. Si recordamoslos pasos internos del caso (ver Tabla 13.1), podemos comprender esta división:

1. Arranque de equipos: corresponde a los siguientes puntos de la secuencia dearranque:

1. Alimentación. Tensión.2. Arranque PC Servidor.3. Encendido Coordinador WSN.4. Encendido Router - Hostpot Wifi.

2. La primera transición corresponde a la espera de arranque del sistema opera-tivo de todos los equipos anteriores.

3. Entorno de ejecución: corresponde a un punto único:

5. Aplicación - servidor. El Soporte no se presenta como un productosoftware terminado, por lo que este punto requiere la ejecucióndel entorno Eclipse Equinox con el target de compilación de laaplicación Soporte, junto con todas sus dependencias.

391


4. La segunda transición aguarda la primera señal de actividad del runtime Equi-nox, indicando que todos los bundles del servidor se encuentran registrados, loscomponentes del núcleo OSGi están activos y todo está listo para el desplieguedel sistema.

5. Habilitación del Núcleo: con el núcleo activo, la habilitación supone el procesode conexión del Servidor con los coordinadores de los bloques remotos. Entérminos del arranque del sistema, esto incluye el siguiente punto:

6. Pasarela WSN.

La entrada en servicio del equipo Pasarela no se completa hasta que se ha regis-trado en el coordinador como nodo WSN. A partir de este momento, el sistematiene lista su infraestructura para el despliegue de la plataforma de servicios. Elsiguiente paso en el arranque es el establecimiento de conexión entre los bloques delsistema, comenzando por la presentación al Servidor de la pasarela y el coordinadorWSN. Con la conexión establecida, se dan todas las condiciones para la realizaciónde Habilitar el Soporte Técnico, en el que se recoge la siguiente secuencia deeventos (ver Tabla 13.2):

1. Servidor

a) Núcleo: Librerías (target de compilación).

b) Resolución de dependencias entre bundles.

c) Activación de componentes de la infraestructura.

d) Capa de Participación: registro de servicios.

e) Capa de Presentación: habilitación de contexto e interfaz de usuario (shelly logger).

2. WSN

a) Núcleo:

1) Establecimiento de red (coordinador).

2) Pasarela. Conexión con el servidor.

b) Ajuste de reloj. Sincronización.

c) Despliegue de Routers.

1) Consistencia de red (tablas de enrutamiento).

2) Establecimiento de vecindades (zonas).

3) Calibrado LQi y aprendizaje de escenas.

3. Navegador UPnP: GUI.

392


Al tratarse de una aplicación distribuida, estos eventos se suceden de forma des-acoplada. Si analizamos esta secuencia no desde el punto de vista de los equipos ybloques, sino estableciendo las condiciones transversales que van marcando el des-pliegue colectivo, podemos comprender los estados en los que se reparte la puestaen marcha.

Figura 16.4.: Fin de la Puesta en Servicio WSN - Núcleo

El arranque WSN corresponde a la etapa de Núcleo de la Puesta en Servicio. Duranteel arranque, se establece la red y se registra la Pasarela en el Servidor. Como vemos enla secuencia, el Coordinador y la Pasarela registran sus dispositivos (sus componentesde servicio) una vez que forman parte de la red. Esto garantiza que los dispositivos deservicio críticos (encargados de la configuración, topología, sincronización y conexiónremota) estén presentes y hayan refrescado su estado cuando sea necesario másadelante en la Puesta en Marcha. La disponibilidad de los servicios “primitivos”permite que los equipos arranquen sus tareas básicas: en el caso del coordinador,tiene que registrar todos los nodos de la red WSN; en el caso de la pasarela, realizarsu función de mediación entre la red WSN y el Servidor. El arranque de la WSN nose completa hasta que el Coordinador ha encontrado a la Pasarela, garantizando asíla disponibilidad del canal de comunicación remoto para la Puesta en Marcha (aúnsín garantías de conexión con el extremo Servidor).

Los puntos de frontera indicados son los siguientes:

393


1 Paso al procedimiento de conexión del Coordinador en el Servidor - Tran-sición a la etapa de Red Dorsal.

2 Activación de la tarea de conexión de la Pasarela. Servicio IO / Data(Z2O) activo.

3 Comunicación inicial RS232 con el servidor. Ajuste y presentación.

Figura 16.5.: Fin de la Puesta en Servicio Servidor - Núcleo

Paralelamente al arranque WSN, tiene lugar en el Servidor la secuencia de desplieguede infraestructura detallada en la figura anterior. Este despliegue corresponde a laejecución de la aplicación del Soporte Técnico instalada en el Servidor, por lo quetiene lugar completamente dentro del entorno Equinox OSGi.El verdadero punto de inicio está en el momento de activación de los componen-tes registrados. El orden de activación de los componentes no está controlado porconfiguración (sólo se garantiza la disponibilidad de los componentes del runtimeantes de llamar a los bundles propiamente del Soporte), quedando garantizada laconsistencia del arranque por la topología de dependencias entre bundles, en la quese han evitado bucles y condiciones de bloqueo. Así, las ramas de la aplicación van

394


activándose de forma paralela, comenzando por los elementos centrales de librería,las clases primitivas y los componentes de bajo nivel, conformándose el bloque deconexión WSN - apoyado en un driver de comunicación por puerto USB - y el bloqueUPnP - tomando el control de la API Cling -.Esta secuencia desemboca en las transiciones indicadas:3’ Evento puerto serie, Log de eventos, intérprete Z2O y activación del

ZigBeePort (Bridge). Canal ascendente listo = capas de acceso y abs-tracción WSN.

4 Invocación a la capa de integración ZigBee.5 Arranque autónomo del núcleo UPnP y respuesta paralela a los disposi-

tivos de la red. Invocación a la capa de integración UPnP.

Puesta en Marcha

Figura 16.6.: Puesta en Marcha WSN

Con la conexión de la Pasarela al Coordinador, tiene lugar el fin de la Puesta enServicio WSN y la transición a la Puesta en Marcha. Hasta aquí, la aplicación sóloha establecido dos rutinas básicas de conexión, necesarias para garantizar la infra-estructura. Con la Puesta en Marcha, aparecen los servicios propios de la capa SOAdel Soporte.Siguiende por los puntos de entrada, tenemos:

395


1 Coordinador: Registro remoto en el Servidor y señal de bienvenida (ca-nal descendente listo): activación de los servicios del Coordinador - Sin-cronización (0x0b), Configuración de Servicios (0x41) y Sesión Remota(0x72).

2 Pasarela: Bucle de puente Z2O. Flujo de entrada hacia la WSN por (6)y de salida hacia el Servidor por los mecanismos afmeDataRequest conel encabezamiento Z2O (ver Sección 13.1.3.2).

La realización de estas tareas se produce en la transición entre la llamada a la Puestaen Servicio y el estado de Red Dorsal. Con la activación de las tareas de servicio enlos nodos de la red, se dan las condiciones para la conexión ordenadas de los demásequipos (routers y dispositivos finales), que, siguiendo siempre la misma secuenciaRed Dorsal - Red de Acceso - Listo para Apertura, puede variar en función del modode operación de la aplicación.

Figura 16.7.: Puesta en Marcha Servidor

Por su parte, la Puesta en Marcha de Servidor supone la activación de las tres capasque completan la arquitectura de la aplicación presentada. Siguiendo por los puntosde entrada de la secuencia, tenemos:3 & 4 Capa de integración WSN: Se registran los EndPoints del Servidor, con-

virtiendo al equipo en un nodo “remoto” de la red WSN al que puedendirigirse los mensajes Z2O. Con la activación de la capa de integración, segarantizan los recursos que utilizaran los dispositivos de servicio alojadosen el Servidor.

396


5 Capa de integración UPnP: ControlPoint del Servidor. Sobre las ca-pas de acceso UPnP, se registra la capa de integración que convierte alServidor en un dispositivo ControlPoint de la red UPnP.

4 O 5 Núcleo del Servidor: Lógica de servicios - ServiceBus. La activación delos EndPoints del Servidor debe conectarse de algún modo con los com-ponentes de servicio que implementan la capacidad de control y decisiónreal del sistema. En ZigBee, esta función queda resuelta por medio delos Zigbee Device Objects, que asocian un Descriptor Simple con unEndPoint para activar un servicio dentro de la red WSN. Dentro delServidor, la construcción de la plataforma de servicios comienza por laactivación del ServiceBus, que sirve como canal de intercambio entretodos los dispositivos internos y los emisores / receptores que conectancon las redes del sistema.

6 Canal de comunicación Z2O con los dispositivos WSN.

La Puesta en Marcha finaliza con el establecimiento de la Tareas de Gestión de Ser-vicios y Contenidos, que sólo pueden comenzar cuando están garantizados todos losrecursos de la capa de Participación. Siguiendo con la secuencia de activación, vemosque son necesarios, además de los mecanismos de conexión garantizados por el Nú-cleo, los puntos de conexión remota manejados por la Capa de Integración, el modelológico de datos gobernado por el BoxProfile y la base de información necesaria pararecuperar el contexto de la aplicación, entendido como la configuración que cadadispositivo debe tener cuando el sistema se encuentre Listo para Apertura.

Estos fragmentos pertenecen a la misma secuencia de activación y se enmarcan, comohemos dicho, entre los estados de Habilitación del Núcleo y la Puesta en Marcha.Observar que, hasta este punto, se han mencionado sólo dos casos de uso y sehan iniciado tres servicios localizados en la red WSN. Podemos imaginar que, enparalelo, se habrán activado los dispositivos del servicio MmBox implantados enla red AV, pero no se ha hablado nada de la zonificación, el control de escenas ola localización. La secuencia de puesta en marcha no finaliza hasta que el SoporteTécnico alcanza las condiciones de apertura, que se definen de acuerdo con el modooperativo seleccionado por el usuario.

Etapas de despliegue de la red

El Coordinador WSN es responsable de monitorizar (y, en algunos modos, de contro-lar) las transiciones entre etapas de la Puesta en Marcha. Como reflejo los estadospresentados en la Figura 16.3, se definen los siguientes valores, que correspondena un grado de despliegue del sistema por los nodos conectados y el estado de losservicios.

NO_NWK (0x00) Corresponde al estado de pausa con puesta en servicio y sinorden de puesta en marcha. El sistema puede permanecer estático en estas

397


condiciones hasta que el Coordinador encuentre un canal para establecer la redo el servidor haya obtenido el puerto serie para conectar con la pasarela.

LOAD (0x01) Corresponde al estado de arranque de la puesta en marcha, conla secuencia que hemos detallado anteriormente. A efectos de supervisión, latransición del estado 0x01 al siguiente tiene lugar cuando se ha establecido lared, hay conexión serie con el Servidor y el Coordinador ha iniciado su sesiónremota.

BACKBONE (0x02) También etapa Dorsal, es la etapa de validación de la Habilitacióndel Soporte. En cuanto a la red, a partir de este punto el Coordinador ad-mite la conexión de los nodos FFD, conformándose la red en malla entre losRouters que deben acoger después a los Visitantes. En esta etapa, todavía nose han registrado los dispositivos de servicio del bloque WSN.

ACCESS (0x03) O fase de Acceso, corresponde a la etapa de registro de serviciosy recuperación de contexto. Se admite la conexión a la red de los nodos RFD(Visitantes), sin establecer todavía ninguna conexión entre los dispositivos delVisitante y el resto del sistema. En la fase de Acceso, se desarrollan íntegra-mente los casos de uso Definir modos de control (Tabla 13.5) y Habilitarinterfaz remota (Tabla 13.10).

RUNTIME (0x04) Estado de ejecución. Se habilitan los dispositivos de Visitantey se desarrollan los casos relacionados o dirigidos a la configuración y ejecu-ción de la interacción de la obra. Según el modo de explotación, apareceránlos casos de Control de artefactos (Tabla 13.7), Localizar al visitante(Tabla 13.3), Control de contenido (Tabla 13.4) y Reproducir el Mensaje(Tabla 13.6) o bien Definir reglas de medida (Tabla 13.9), Habilitar APIde aplicación (Tabla 13.11) y Definir Reacciones (Tabla 13.8).

16.3. BoxProfile

En esta sección, presentamos la colección completa de entidades clasificadas dentrodel Profile de aplicación, denominado comúnmente a lo largo del Proyecto “Box-Profile”. Como queda recogido en la Subsubsección 13.1.2.2, el Profile representaal dominio lógico del Soporte Técnico, estableciendo el diccionario compartido portodos los dominios del sistema e, implícitamente, las reglas de comunicación entrelos componentes que respetan el modelo de servicio, que son los escenciales paracomprender el diseño y el funcionamiento del Soporte Técnico como aplicación degestión y control sobre una instalación de arte interactivo.La sección está dividida en una primera parte descriptiva, en la que se enumerany describen todos los elementos del Profile, seguida de una segunda parte donde sedesarrolla la implantación de estos elementos en la topología del sistema, tratandode explicar los mecanismos que permiten la traducción de dominio por medio deeste documento de referencia.

398

16.3 BoxProfile

Profile de aplicación

El Profile de aplicación es la clasificación global de los elementos de intercambioentre componentes dentro de la lógica de dispositivo. La organización interna delProfile viene heredada del Profile de aplicación de “The BOX”, que detallamos enel Capítulo 14, adaptado al mayor grado de interoperabilidad que exige el SoporteTécnico entre los dominios UPnP y ZigBee.

Como refleja el esquema de la Figura 13.6, las tres clases principales recogidas en elProfile son EndPoint, Cluster y Attribute. Un Cluster sólo es un contenedor de Atribu-tos, por lo que existe una relación de contigencia entre ambas clases; sin embargo,la lógica de dispositivo no limita a priori las posibles asociaciones entre EndPointsy Clusters, permitiendo cierta flexibilidad para diseñar los perfiles de Dispositivos(a través de sus Descriptores Simples) como más convenga a la topología delsistema.

EndPoints / Clusters

La aplicación Soporte se organiza en tres EndPoints, denominados ZHOI, ARTIE eIO. Los Clusters contenidos en el BoxProfile se asocian de forma unívoca a cadaEndPoint, de tal forma que la asociación de un Cluster con un EndPoint viene fijadapor diseño. A nivel de arquitectura, como se apunta en la Subsubsección 13.1.2.4,las necesidades de comunicación entre entre roles servirán para determinar la confi-guración de entrada / salida de los Clusters, pero en todo momento hablaremos dela misma lista de Clusters para cada EndPoint.

ZHOI (0x10) Herencia del Profile de “The BOX”. Ya se presentó a su antecesoren la Sección 9.3. ZHOI establece un canal uniforme para la configuración y elcontrol de los equipos en red. Como podemos imaginar, las funciones primariasdel EndPoint son la sincronización, la localización y la verificación de la cohe-sión de red. ZHOI deviene de “ZigBee Hand Over Implementation” ya que, sinimplementar un protocolo de traspaso, resuelve todos los detalles relacionadoscon la autonomía y movilidad dentro del dominio WSN. El EndPoint ZHOIestá prescrito y diseñado para la red ZigBee, que requiere de una mayor aten-ción en la tareas de configuración y cohesión que la red UPnP; sin embargo,algunas funciones recogidas en ZHOI son igualmente importantes para la redAV, como es el caso de la sincronización. Los Clusters reunidos en ZHOI sonlos siguientes:

Config (0x41) Incorporado del profile de “The BOX”. Canaliza todas lasoperaciones de control y configuración de red, incluidos los modos deahorro energético, movilidad de terminales de visitante y señales del ciclode vida de los servicios. Las funciones del cluster Config se situan a nivelde la infraestructura, por debajo del modelo de servicio.

399


Time (0x0B) Basado en el cluster homónimo de la ZigBee Cluster Library(ZCL). Canaliza las tareas de sincronización y ajuste temporal entre no-dos. Time se desarrolla como un Servicio de alcance global a todo elSoporte.

Lqi (0x0C) Reemplaza en el Profile del Soporte al cluster RSSI de la ZCL. Seaplica a las tareas de localización de nodos móviles y monitorización delcanal, utilizando el único medio que habilita el fabricante del equipo deprueba para ello, que es el índice LQi (ver Sección 11).

Groups (0x05) Incorporado de la ZCL como medio de definición de dominiosde difusión dentro de la WSN, finalmente no se ha empleado en el Soporte,al no ser compatible con la versión del Stack ZigBee del fabricante.

ARTIE (0x20) Es una evolución del EndPoint SCENE de “The BOX”. Deriva de“Artistic Interaction EndPoint”, ARTIE sirve como puerto de configuración yejecución escénica, concentrando los servicios más relevantes para el propósitodel Soporte Técnico. Las aplicaciones reunidas en ARTIE se han diseñado bajolos principios de subsidiariedad, reactividad y personalización, tal y como sepreconiza en la Sección 9.1. Los Clusters ARTIE son los siguientes:

Set (0x61) Establece un mapa de zonas sobre la instalación, donde quedanasociados todos los dispositivos con alguna capacidad expresiva que puedaser controlada por ARTIE. Dada la limitada capacidad de los equipos deprueba, el servicio Set se haya fuertemente desacoplado, siendo quizás elejemplo más significativo de la aplicación de SOA en el Soporte Técnicopor su papel en la construcción de los grupos de interactividad y en lainteracción con el Visitante.

Scene (0x06) Reemplaza al cluster Scene de la ZCL. Facilita un mecanismopara configurar y ejecutar escenas dentro de un dominio de difusión. Es-tos conceptos se aplican en el Soporte Técnico circunscritos al endpointARTIE, por lo que Scene se apoya en el mapa de instalación gestionadopor Set para definir escenas a partir de elementos de los clusters de inter-acción, que son Thrill (ambiente por regulación luz) y MmBox (secuenciade película).

Director (0x62) Añade un nivel de gestión a las capacidades escénicas, per-mitiendo la gestión de listas o secuencias de escenas dentro de un crono-grama. Por medio de Director, el Artista puede establecer reglas sencillaspara disparar una secuencia cuando se cumplan unas condiciones dentrode una zona. El propio servio se encarga de difundir la configuración a losmiembros de la zona, desencadenando con ello una secuencia completade programación de escenas y comportamientos.

Thrill (0x51) El Cluster Thrill canaliza todas las funciones de control deluminosidad, extendiendo las aplicaciones tradicionales de encendido /regulación / verificación para permitir también una función de regulación

400

16.3 BoxProfile

por la distancia con el visitante conectado a la luz. La versión desarrolladadel cluster maneja una regla lineal definida por tres atributos, que puedenajustarse según el perfil de regulación establecido.

MmBox (0x52) El Cluster MmBox desarrolla un servicio de control remotode reproducción vídeo. Es el equivalente a Thrill para los dispositivosactuadores del extremo AV del sistema, de forma que un determinadoperfil se corresponde aquí con una secuencia de vídeo almacenada en eldisco duro del equipo proyector o bien en un stream multimedia inyectadodesde el servidor. Es una adaptación de las capacidades del EndPointMmBox de “The BOX” a la arquitectura UPnP del Soporte Técnico,utilizando en la conversión los referentes de integración presentados en laSección 9.3 y la Sección 15.5.

IO (0x30) Sirve como canal de entrada / salida de propósito general, habilitandoun mecanismo de comunicación punto a punto. Por medio de este EndPoint,puede construirse el mecanismo de intercambio Z2O entre un nodo WSN yel Servidor. Cada Cluster dentro del EndPoint incorpora una cabecera dentrodel payload de la trama, por lo que cada servicio utilitario puede establecersu propia señalización de servicio al margen de los servicios de configuraciónde red y gestión escénica. Las aplicaciones de este EndPoint son fundamen-talmente dos: log de eventos y túneles Z2O. Los clusters habilitados para elloson dos:

Data (0x71) Gestiona cualquier envío con cabecera propio entre el Servidory un nodo de la red WSN. En la red AV no tiene aplicación, ya que losdispositivos UPnP son rastreados automáticamente con los métodos deCling. Dos de los usos de este Cluster son el establecimiento de túnelesZ2O para el envío indirecto a / desde el Servidor y el envío de mensajesen texto plano para logging, tanto en sentido Servidor (volcados al loggergeneral de la aplicación) como hacia los nodos (por ejemplo, se utilizanel Coordinador para la indicación por pantalla LCD).

Remote (0x72) Es un Cluster para la realización de pruebas. Sirve para si-mular cualquier paso de mensajes, reproducir cualquier señalización ocomando entre un nodo de red y el Servidor. Tiene aplicación, por ejem-plo, para comprobar el estado de los reguladores de luz, o para identificara un equipo por su dirección de Red o su Uid en el Servidor.

Atributos

ZHOI / Config

Status (0x0001) Estado del nodo: chequeo general, latencia de la rutina prin-cipal y modo de operación (ver Sección 16.4).

401


Figura 16.8.: Árbol de Endpoints / Clusters / Atributos del BoxProfile

Service (0x0002) Estado de conexión y ciclo de vida de los servicios del nodo(ver Sección 16.2).

Session (0x0003) Tiempo de conexión del nodo a la red, en milisegundos.Max_Session (0x0004) Tiempo máximo de conexión habilitado. Al agotar el tiem-

po de sesión, un dispositivo debe deshabilitar sus servicios y reconectarse.Rount_trip_time (0x0005) Tiempo promedio de ida y vuelta, en milisegundos, de

un saludo de verificación enviado al padre. Sirve como tiempo base paracomprobar el estado del enlace de conexión.

Indirect_poll_rate (0x0030) (Sólo dispositivos finales) Tiempo de sondeo de recu-peración de mensajes. Si el valor es mayor que 0, sirve como base de tiempo paraconfigurar el modo de ahorro de energía del nodo (será igual al tiempo de sondeomenos el round_trip_time).Lqi_retry_threshold (0x0031) (Sólo dispositivos finales) Nivel Lqi de los mensajesZHOI recibidos a partir del cual el nodo debe ejecutar la secuencia de traspaso dentrode la red. Esto supone la monitorización del estado del enlace con su padre actual y

402

16.3 BoxProfile

la evaluación de los posibles candidatos; si uno de los nodos candidato tiene un nivelde señal sostenido mejor que el padre actual, el dispositivo procede a desconectarsede la red (volviendo a conectarse por el nodo más cercano, que corresponderá almejor candidato).

ZHOI / TimeTime (0x0001) Contador en milisegundos de la actividad del equipo.Status (0x0002) Registro de configuración del servicio de sincronización.Standard (0x0003) Fecha y hora del sistema en segundos desde 00:00:00 01/01/2000.Shift (0x0005) Registro en milisegundos de la deriva del dispositivo. Es un

parámetro predefinido o ajustado por el Servidor.

ZHOI / LQiLocation_Type (0x0001) Enumeración de tipos establecida por la ZCL. Se usa

para identificar el cálculo estimativo del nodo.Location_Method (0x0002) Enumeración de métodos establecida por la ZCL. Se

usa para identificar el método aplicado en el servidor.Location_Age (0x0003) Milisegundos desde la última estimación de posición.Number_of_devices (0x0004) Número de nodos baliza (Beacon) que participan en

la localización.Coord_1 (0x0010) Coordenada X en LQi (entero de 8 bits sin signo) estimada

respecto a la posición del Coordinador {127, 127}.Coord_2 (0x0011) Coordenada Y en LQi (entero de 8 bits sin signo) estimada

respecto al Coordinador en {127, 127}.Reporting_period (0x0012) Marca de tiempo en milisegundos para informar al

servidor de la última posición estimada.Calculation_period (0x0013)Marca de tiempo en milisegundos para lanzar un nue-

vo ciclo de localización.Number_of_measures (0x0014) Número de medidas consecutivas que se solicitan

a cada baliza.Calculation_feedback (0x0015) Número de iteraciones que se realimentan en la

estimación de posición (filtro pasobajo).

ARTIE / SetTag (0x0001) Etiqueta pública de zona. Es conocida por los Visitantes (por

indicación del Servidor) y el Guarda de zona.

403


Zone (0x0002) ID privada de zona. Es compartida por el Guarda de zona conlos LightCube y los Proyectores de su zona.

Stage (0x0003) Estado de zona. De cara a la red de acceso, sirve como umbralde acceso para confrontar los privilegios del nodo Visitante; de cara ala parte dorsal de red, sirve para indicar la prioridad de la zona conrespecto a las demás zonas en las que participe un nodo (en caso deconflicto, sólo participará en la secuencia con mayor prioridad).

Leader (0x0005) UID del Guarda de zona. En el extremo WSN, se traduce porla dirección ZigBee.

ARTIE / Scene

Count (0x0001) Número de escenas configuradas en un dispositivo.

Current (0x0002) ID de la última escena invocada (configurada / ejecutada).

Zone (0x0003) ID de la zona activa en la última invocación (configuración /ejecución).

Valid (0x0004) Indicación de resultado de la última invocación (configuración/ ejecución).

Last_Conf_By (0x0005) UID del dispositivo que ha configurado la última escenainvocada.

ARTIE / Director

Current (0x0001) ID de zona asociada a la secuencia.Time_Stamp (0x0003) Referencia de tiempo para sincronización entre miembros

de escena.Active_Seq (0x0004) Registro de la última secuencia invocada.

Valid_Seq (0x0005) Indicación de resultado de la operación sobre la última secuen-cia (configuración o ejecución).

ARTIE / Thrill

Tone (0x0001) Controla la pendiente de la recta de regulación por la distanciaPulse (0x0002) Frencuencia de la portadora para la generación del pulso de

regulación por PWM (ver Sección 11).

Loud (0x0003) Nivel máximo de intensidad regulable.

ARTIE / MmBox No desarrollado.

404

16.3 BoxProfile

IO / DataBin (0x0001) Recipiente genérico de datos. Transporte Z2O (ver Sección 13.1.3.2).Log (0x0002) Transporte para datos de logging y depuración. En primera

instancia, se emplea en la presentación al Servidor de todos los nodosWSN por paso de su MAC.

Dispositivos y Roles

Ya se han presentado los perfiles de dispositivo en la Memoria en la Subsubsección 13.1.2.4.El Profile necesita tan sólo cuatro roles para cubrir todos los perfiles de los equiposparticipantes en la arquitectura WSN. El Soporte queda completo con los roles delbloque AV, pero éstos responden a perfiles estándar recogidos en la UPnP AVArchitecture v.2 y que ya han sido definidas en el Capítulo 11.MASTERBOX (0x3000) Se refiere como norma general al Coordinador de la red o

al Servidor, cuando actúa como proveedor de servicio.LIGHTCUBE (0x3001) Es el rol de los equipos RFD de la red WSN que ejercen un

papel en el control escénico y permanecen estáticos. A los nodos de la red queimplementan dispositivos LightCube se les denomina Routers en el SoporteTécnico, porque sirven como punto de acceso para los nodos móviles. Losnodos Router / Lightcube registran todos el mismo dispositivo en el servicio delocalización, por lo que generalmente reciben la misma denominación, aunquesu denominación oficial es baliza o Beacon.

VISITOR (0x3002) Los equipos finales de la red, libres para desplazarse y cambiarde nodo padre en la red. Desempeñan un papel cliente en la mayoría de losservicios que registran, tomando la iniciativa en las tareas de localización ymovilidad de red y actuando como disparadores de las secuencias escénicascon sus movimientos de entrada y salida de las zonas.

GATEWAY (0x300A) Es un rol específico para el equipo Pasarela y sus dispositivos.Identifica a todos los puntos de entrada y salida de datos del bloque WSN.

La aplicación de estos roles a cada uno de los agentes de servicio instalados en losdistintos nodos del sistema da lugar a la aparición de los Dispositivos, que quedanrecogidos en el siguiente esquema por su servicio y ubicación.Muchos dispositivos carecen de un nombre característico, siendo tan sólo agentesconsumidores o proveedores de servicio con un rol asignado. Dentro de la red, todoslos dispositivos de un mismo servicio instalados en nodos iguales son indistinguibles,salvo por la dirección de red de su nodo, salvo si un mismo nodo puede albergarun dispositivo consumidor y uno proveedor. Los dispositivos adquieren su singulari-dad cuando son reconocidos por el Servidor, donde son tratados como una entidadúnica que debe mantener su identidad aunque cambie la dirección de red de suhuésped. Para poder diferenciar entre dispositivos de un mismo nodo, el propio ser-vicio debe habilitar los atributos para completar la información de la cabecera de

405


Figura 16.9.: Clasificación de dispositivos recogidos en el BoxProfile

las transacciones o bien el propio contexto de ejecución se asocia a un destinatariode forma inequívoca. Por ejemplo, en el servicio Set, un mismo nodo puede actuarcomo Guarda de una zona y como LightCube para otra zona. Determinados mensajesde configuración o de ejecución sólo pueden ser enviados por el Guarda de zona,por lo que la comunicación se apoya en el conocimiento de la dirección de red delGuarda. La propia secuencia de diálogo de los servicios simplifica el tratamiento delos mensajes.

16.4. Modos operativos

Se han establecido cuatro modos operativos para los Dispositivos y otros cuatromodos para los Servicios. El modo de operación por Dispositivo afecta a sólo a unperfil de dispositivo específico, a todos los nodos que implementan dicho perfil. Porsu parte, el modo de operación por Servicio es común para todos los Dispositivosdel mismo y, por tanto, afecta a la ejecución de todo el Servicio. La secuencia dePuesta en Marcha, que forma parte del arranque del sistema, varía según el modooperativo seleccionado para cada Dispositivo y Servicio.

Modos por Dispositivo

Forman parte del atributo de configuración de dispositivo, dentro del servicio generalde configuración (ZHOI / Config). Se definen:STANDALONE (0x00) Modo de funcionamiento autónomo. En este modo, el dis-

positivo cuenta con su propia configuración de servicios y la proteje de cual-quier modificación externa. Un nodo autónomo no esperará a las señales de la

406

16.4 Modos operativos

puesta en marcha para ir desplegando sus servicios, sino que lo hará tan pron-to como cuente con los recursos imprescindibles. A efectos de programación,supone una inhabilitación de todos los comandos de escritura de parámetrosy de todas las solicitudes de recuperación de contexto, dirigiendo todo el es-fuerzo a recuperar ese contexto de la memoria local. Este modo puede resultarútil en instalaciones con equipos con almacenamiento no volátil que ya hansido configurados, probados y validados y se disponen a un uso continuado sincambiar su entorno de trabajo.

COORDINATED (0x02) Modo coordinado. En este modo, el Coordinador de la redpuede cambiar la configuración del dispositivo. Los nodos de la red puedenrecibir órdenes de reconfiguración del Servidor rebotadas por el Coordinador osolicitudes de verificación de estado para mostrar por el display el estado delos servicios del nodo, la consistencia de red o cualquier aspecto que afecte aldespliegue de los servicios. En el modo coordinado, la señal de etapa de red (latransición de un estado al siguiente en el arranque) debe venir validada por elCoordinador, de modo que puede controlarse la puesta en marcha paso a pasode forma cómoda. También puede utilizarse como un modo intermedio entreel funcionamiento autónomo y el funcionamiento supervisado (los siguientes),permitiendo a algunos dispositivos mantener un perfil propio, monitorizan-do los elementos críticos y actuando como proxy de recuperación en caso depérdida o corrupción de la configuración de algun nodo local.

SERVER_BASED (0x04) Modo centralizado. Es el modo más común de trabajode una aplicación manejada por el Soporte Técnico. En este modo, los nodosperiféricos se descargan de todo almacenamiento y recuperan su configuraciónde la memoria del servidor, estableciendo un diálogo sin intermediarios parapresentarse, obtener una configuración válida y así poder establecer las cone-xiones locales que sean necesarias para el despliegue de servicios.En el modo centralizado, la intervención del Coordinador como supervisor deldespliegue se limita a la monitorización de la etapa de despliegue, la difusióndel reloj y la visualización de eventos o mensajes para asistir a la puesta enmarcha. La principal diferencia entre el modo coordinado y el centralizado ra-dica en el número de saltos de comunicación para el control del despliegue:Mientras que el modo coordinado carga todo el proceso en un nodo de la red,el modo basado en Servidor abre una vía de comunicación por cada nodo conun equipo fuera de la misma. Así visto, el modo coordinado bien podría servirpara acelerar la puesta en marcha con sólo disponer del contexto de todos losdispositivos esperados en la red, pero, como condición indispensable, es nece-sario un equipo alimentado de forma ininterrumpida y con gran capacidad deprocesamiento, ya que acarrea una inflación del control de contexto frente alas demás tareas críticas que debe realizar el coordinador de red.

USER_BASED (0x06) Modo asistido. La puesta en marcha debe conducir al siste-ma a un estado de disponibilidad para la ejecución de los servicios que definenla instalación interactiva: reactividad al visitante y efectos escénicos coordi-

407


nados. Se define el Contexto como la configuración de todos los dispositivosesperados de la ejecución del Soporte, conteniendo por ello no sólo una relaciónde los nodos - con sus identidades y configuraciones generales - sino también laconfiguración específica de los servicios propios de cada dispositivo. No debe-mos pensar en el Contexto como una base centralizada de información (comotampoco el Profile es un modelo unificado de datos y servicios); más bien, setrata de una colección de recursos de los que se puede extraer la informaciónnecesaria para completar la puesta en marcha.Los recursos que pueden soportar o mantener el Contexto pueden ser muyvariados. Podemos clasificarlos por su capacidad para aceptar cambios en tiem-po de ejecución como contenedores estáticos o dinámicos; Según su ubicaciónen el sistema, puede ser recursos internos (de la aplicación Servidor) o exter-nos. Cada modo de operación está preparado para manejar contenedores deContexto de una naturaleza específica. En el modo centralizado de operación,por ejemplo, se maneja un Contexto interno y estático. En los modos coordi-nado o autónomo, el contexto está repartido por los nodos, pero también puedeexistir una parte del contexto alojada en el Servidor / Coordinador. En el modoasistido por usuario, sin embargo, una parte del Contexto puede venir de fuerade la aplicación, suministrado a través de las interfaces de la aplicación.El modo asistido es indispensable para habilitar el Soporte en las etapas deMontaje y Mantenimiento del ciclo de vida de la obra interactiva, yaque permite trabajar con un sistema en el que todavía no contamos con unContexto completo sin abortar la puesta en marcha. Al mismo tiempo, la in-formación de Contexto y el control de los dispositivos conectan con la interfazde usuario, permitiendo así una labor de ajuste o configuración supervisada.

Modos por Servicio

De forma complementaria, se definen los modos por servicio en el atributo de estadode servicios del dispositivo general de configuración (ZHOI / Config), quedandoestablecidos los siguientes:

MAQUETA (0x04) Habilita un modo especial de servicio en el cual el dispositivoactúa como si incorporara un componente de servicio que maneje el EndPointregistrado, aunque se trate tan sólo de una maqueta software que “reproduz-ca” algunos aspectos de su comportamiento. Este modo permite relajar losmecanismos de control y seguridad, cortando cualquier secuencia de órdenesque pueda afectar al resto del sistema por parte de este servicio para estudiarsimplemente la comunicación entre dispositivos o los cambios de rendimientoen los demás dispositivos.

AJUSTE (0x05) En este modo, se exige la disponibilidad de todos los dispositivosdel Servicio y, por tanto, hablamos de un despliegue real en el Soporte. Enel modo de ajuste, se permite al Servidor (o al Coordinador, según el modo de

408


dispositivo), modificar la configuración del servicio, lo que a efectos de pro-gramación significa un tratamiento de los comandos SET / GET del protocolo.Como quiera que un cambio en la configuración de ciertos servicios puede afec-tar al estado de despliegue del sistema, este modo sólo puede ejecutarse en lasetapas de la puesta en marcha, nunca en fase de apertura.

ENSAYO (0x06) En el modo de ensayo, los dispositivos de servicio deben contarcon una configuración propia (un Contexto ). El propósito del modo es va-lidar la implantación de dicho contexto en los dispositivos, habilitando paraello los mecanismos de control paso - a - paso y de visualización y aviso parainformar al operario del resultado de la prueba. Este modo permite la supervi-sión de un servicio sin necesidad de cambiar el estado operativo del sistema nitirar la puesta en marcha, ya que sólo introduce una capa de monitorizacióncomplementaria al tráfico de servicio general.

MADURO (0x07) Se trata del modo de operación autónomo para un servicio, enel que debe operar sólo en base al Contexto y las directrices del Contratode Servicio. En este modo, todos los dispositivos se dirigirán a su proveedorde Contexto para ejecutar su puesta en marcha y seguirán con la secuenciade arranque hasta haber establecido todas las conexiones para garantizar laapertura del sistema. Es el modo más general en el que puede ejecutarse unservicio y en el que - presumiblemente - deberían ejecutarse en una instalacióndesarrollada con éxito sobre el Soporte Técnico.

Modos de explotación del Servicio Técnico

La habilitación de distintos modos a nivel de Dispositivo y Servicio permite la ejecu-ción del Soporte en distintos momentos del ciclo de vida de la obra de arte, pudiendoutilizarse en cada etapa para el máximo provecho del actor implicado en el desarrollode la obra. En la siguiente tabla, se han recogido distintos modos de explotación delservicio, entendidos como una consigna de modo común a todos los Dispositivos yServicios.

Ciclo de Vida Actor Modo de dispositivo Modo de servicio

Creación Integrador CUALQUIERA MAQUETAMontaje Creativo USER_BASED AJUSTEMontaje Integrador USER_BASED ENSAYOExposición Guía (Visitante) SERVER_BASED MADURO

Mantenimiento Mantenimiento COORDINATED MADUROCuadro 16.4.: Modos de explotación del Servicio Técnico

409


Modos operativos y estados de despliegue de red

Como hemos visto en la secuencia de arranque, la Puesta en Marcha sigue siemprela misma sucesión de estados. Si no se cumplen las condiciones para saltar a lasiguiente etapa en un tiempo controlado o se producen situaciones que afectan alarranque, se puede abortar la puesta en marcha, volviendo al estado original deausencia de red. Imaginemos que la Pasarela se queda colgada, que las condicionesde comunicación por el canal se hacen imposibles o que se pierde la sincronizaciónentre el Coordinador y el Servidor; ante estas circunstancias, el sistema sólo puedeentrar en suspensión y comenzar de nuevo la puesta en marcha, necesitando paraello que todos los equipos permanezcan inactivos el tiempo justo para no entorpecerla secuencia natural de activación y entrar a participar en ella en el momento queles corresponda.

Los modos operativos afectan claramente al contenido de la Puesta en Marcha,pero no a su secuencialidad. Podemos decir que, por lo general, la aplicación sólo estábajo control del usuario cuando alcanza la fase de Apertura. La única excepción aesta norma sería la configuración en modo supervisado por Coordinador con serviciosno maduros, necesitando el avance de la puesta en marcha la generación de señalesexternas al sistema, por medio de alguna interfaz de usuario (como pulsadores odisplays) o depuración en línea del programa.

410


Figura 16.10.: Detalle de la secuencia de puesta en marcha

Consignación de modos

Los modos de marcha pertenecen a la estructura misma de la aplicación y, portanto, son anteriores a la Plataforma de Servicios . Para su implementación enel programa del Soporte Técnico, se han considerado dos técnicas antagonistas, quemodifican el desarrollo y el rendimiento del sistema.

Directivas de preproceso / Condiciones de compilación: permiten incluir en elprograma sólo las estructuras de código que correspondan al modo de ejecuciónque vaya a explotarse, lo que implica que el modo debe quedar establecido porprogramación de los equipos, no puede cambiarse y debe ser coherente en todoel sistema. Tiene sentido para aquellos modos de explotación utilizados antesde la etapa de exposición, en los que el equipo de desarrollo tiene acceso atodos los recursos de la instalación y todavía no intervienen terceros en sumantenimiento.Secuencias de control: permiten una mayor flexibilidad y aprovechamiento delentorno OSGi, ya que el sistema puede cambiar de modo y reconfigurarse sinnecesidad de repetir la puesta en marcha completa, pero exigen más capacidadde almacenamiento en los nodos remotos y complican el desarrollo, obligando

411


a un análisis en profundidad para crear métodos específicos que sean ligerosy seguridos y entroncar adecuadamente todos los modos en una misma se-cuencia de ejecución. A priori, es la estrategia más adecuada para los modosde explotación propios de la etapa de exposición y mantenimiento, ya que enellos deben minimizarse las intervenciones sobre el programa que impliquenuna sobreescritura del código. Cobra especial protagonismo aquí la interfaz dedesarrollo y la potencia de la plataforma OSGi, permitiendo una sustitución decomponentes de servicio en tiempo de ejecución sin desestabilizar al programa.

16.5. Parámetros de comunicación

16.5.1. Formato de mensajes

EP: ZHOI (Configuración de red y mobilidad)

ZHOI / ConfigGET_ACK (1) De: Master <–> A: CualquieraSET (2) De: Master <–> A: Gateway, LightCubeSET (3) De: Master <–> A: VisitorSET_ACK De: Master <–> A: Gateway, LightCube

Cuadro 16.5.: Mensajes ZHOI / Config

ZHOI / TimeGET_ACK (1) De: Master (S) <–> A: Gateway, Master (C)GET_ACK (2) De: Master (C) <–> A: Cualquiera (WSN)SET_ACK (1) De: Master (S) <–> A: Master (C)SET_ACK (2) De: Master (C) <–> A: Cualquiera (WSN)EVENT_ACK (I) De: Master (S) <–> A: CualquieraEVENT (O) De: Master (C) <–> A: Master (S)

412

16.5 Parámetros de comunicación

Cuadro 16.6.: Mensajes ZHOI / Time

ZHOI / LQiGET_ACK (1) De: Master (S) <–> A: Visitor. CMD_LQI_GET_DEVICE_CONFGET_ACK (2) De: Master (S) <–> A: LightCubeGET_ACK (3) De: Cualquiera <–> A: Cualquiera. CMD_LQI_GET_POSITIONSET_ACK (1) De: Master (S) <–> A: Cualquiera. CMD_LQI_SET_POSITIONSET_ACK (2) De: Master (S) <–> A: LightCube, Visitor. CMD_LQI_SET_DEVICE_CONF

EVENT_ACK (I/O) De: Visitor <–> A: LightCube. CMD_LQI_HELLOEVENT (I) De: Master (S) <–> A: LightCube, Visitor. CMD_LQI_GET_LOCATION_DATAEVENT (O) De: Visitor <–> A: Master (S). CMD_LQI_LOCATION_BURSTEVENT (O) De: LightCube <–> A: Master (S)

Cuadro 16.7.: Mensajes ZHOI / LQi

413


Cuadro 16.8.: Formato de las respuestas del EP ZHOI

414


EP: ARTIE (Control de efectos)

ARTIE / SetSET_ACK (1) De: Master (S) <–> A: Visitor. CMD_SET_CONFIGURE

SET (1) De: Master (S) <–> A: Visitor. CMD_SET_MOVEGET_ACK (1) De: LightCube <–> A: Visitor. CMD_SET_GET_PROFILEEVENT (O) De: Visitor <–> A: Master (S). CMD_SET_INTRODUCEEVENT (I/O) De: Visitor <–> A: LightCube. CMD_SET_STEPPED_INTO_ZONEEVENT (I/O) De: Master (S), Visitor <–> A: LightCube. CMD_SET_VISITOR_CARDEVENT_ACK (I) De: Master (S) <–> A: LightCube. CMD_SET_STAGE

Cuadro 16.9.: Mensajes ARTIE / Set

ARTIE / SceneGET_ACK (1) De: Master (S) <–> A: Lightcube. CMD_SIMPLESCENE_REMOVESET (1) De: Master (S), LightCube <–> A: LightCube. CMD_SIMPLESCENE_ADDEVENT (I) De: Master (S), LightCube <–> A: LightCube. CMD_SIMPLESCENE_VIEW

Cuadro 16.10.: Mensajes ARTIE / Scene

ARTIE / DirectorGET_ACK (1) De: Master (S) <–> A: LightCube. CMD_SEQUENCE_REMOVESET (1) De: Master (S), LightCube <–> A: LightCube. CMD_SEQUENCE_ADDEVENT (I/O) De: Master (S), LightCube <–> A: LightCube. CMD_SEQUENCE_RUN

415


Cuadro 16.11.: Mensajes ARTIE / Director

ARTIE / ThrillSET_ACK (1) De: Master (S) <–> A: LightCubeGET_ACK (1) De: Master (S) <–> A: LightCube

Cuadro 16.12.: Mensajes ARTIE / Thrill

416


Cuadro 16.13.: Formato de las respuestas del EP ARTIE

417


EP: IO (Datos remotos)

IO / Data (Log)EVENT (O) De: Cualquiera <–> A: Master (S, C). CMD_DEBUG

Cuadro 16.14.: Mensaje IO / Data

IO / Data (Bin) Transporte de tramas Z2O. Ver Sección 13.1.3.2.

IO / RemoteEVENT_ACK (O) De: Cualquiera <–> A: Master (S). CMD_NODE_LOGIN

Cuadro 16.15.: Mensaje IO / Remote

Cuadro 16.16.: Formato de las respuestas del EP IO

418


16.5.2. Requerimientos de tráfico

En esta sección, trataremos de justificar la elección de la ZigBee como tecnologíade comunicación para implementar el bloque WSN del Soporte y como patrón pa-ra el dimensionamiento del resto del sistema. Los siguientes cálculos de tráfico sehan realizado en base a los formatos de mensaje definidos en el apartado anteriory de acuerdo con la secuencia de arranque, para una red modelo formada por 1Coordinador, 3 LightCube, 1 Pasarela y 4 nodos Visitante, más el equipo Servidor.El tráfico se ha dividido por Clusters, considerando el número total de envíos quese producen en cada fase de despliegue. No se ha discriminiado por equipos, alresultar muy difícil una estimación del tiempo de ocupación del canal de cada unade las transacciones (dependerá del ciclo de ejecución, de la concurrencia de tráficoentre servicios y de las condiciones del canal). A nivel individual, la arquitecturade comunicación está justificada no por la capacidad libre del canal, sino por losmecanismos de la secuencia de arranque y los sistemas de control del hilo de ejecuciónde los nodos de red, que permiten tratar el flujo de datos en base a la memoriadisponible y la ocupación del canal.Los datos resumen de cada tabla muestran la ocupación máxima del canal en lapeor situación posible de cada fase de despliegue. Para obtenerlo, se ha estudiadocada Cluster por separado, considerando la duración de la etapa, el número y pesode las transacciones y cómo pueden ocupar la capacidad del ciclo de ejecución delnodo receptor. Por columnas, tenemos primero el consumo máximo, entendido comoel ancho de banda total que demandan las transacciones del Cluster (incluyendolas taras de cada mensaje), la frecuencia máxima de transacción (en transaccionespor segundo) y el impacto en el hilo de ejecución, expresado como el promedio depaquetes que llegan en cada ciclo de trabajo que, inversamente, es el número deciclos disponibles para tratar un mensaje de servicio.La etapa dorsal, como vemos en el Tabla 16.17, está dominada por el tráfico decontrol y la señalización. Se ha considerado aquí la utilización del canal de Datospara la asistencia a la puesta en marcha, registrando mensajes tanto en el Servidorcomo en el Coordinador. Aunque suponen una carga importante durante esta etapa,se trata de mensajes de baja prioridad que no tienen por qué afectar al rendimientoreal del sistema. Los datos más relevantes aquí son el ancho de banda requerido parala conexión de nodos con el Servidor y la tasa de actualización del reloj (2 veces porsegundo), que debe mantenerse en toda la ejecución para garantizar la consistenciay sincronización de todos los demás servicios.

419


Cluster Consumomáximo

Frecuenciamáxima

Nodo másocupado

Mensajemás pesado

CONFIG 107 bps 0,17 Hz Pasarela (0,025ppc)

56 B

LQI 0 bps 0 Hz - 0 B

TIME 2,008 kbps 2 Hz Coordinador (0,15ppc)

60 B

SET 0 bps 0 Hz - 0 B

DIRECTOR 0 bps 0 Hz - 0 B

SCENE 0 bps 0 Hz - 0 B

THRILL 0 bps 0 Hz - 0 B

REMOTE 6,096 kbps 6 Hz Pasarela (0,025ppc)

127 B

DATA 2,032 kbps 2 Hz Pasarela (0,65 ppc) 127 B

Tráfico TOTAL = 10,5 kbpsCuadro 16.17.: Estimación de ancho de banda en fase de conformación (dorsal)

420



Frecuenciamáxima

Nodo másocupado

Mensajemás pesado

CONFIG 432 bps 0,5 Hz Pasarela (0,1 ppc) 56 B

LQI 664 bps 0,5 Hz Pasarela (0,15 ppc) 58 B


60 B

SET 940 bps 1 Hz Pasarela (0,075ppc)

127 B

DIRECTOR 30,768 kbps 24 Hz Pasarela (0,05 ppc) 127 B

SCENE 30,176 kbps 24 Hz Pasarela (0,05 ppc) 127 B

THRILL 0 bps 0 Hz - 0 B

REMOTE 762 bps 0,75 Hz Pasarela (0,075ppc)

127 B


Tráfico TOTAL = 80,558 kbpsCuadro 16.18.: Estimación de ancho de banda en fase de acceso

La fase de acceso está marcada por la configuración de la escena interactiva, carac-terizada por la cantidad y el peso de los mensajes. Este volumen de tráfico puedellegar a saturar la capacidad de procesamiento de la pasarela al tratarse, fundamen-talmente, de tráfico del servidor a los nodos de red. Efectivamente, en un momentocrítico del despliegue, el tráfico por la pasarela alcanza un pico de tres paquetes porciclo; considerando que el limitado buffer de llegada y el peso de los mensajes (127octetos), podrían perderse mensajes el control de los flujos de entrada y la salida serealizara en el mismo hilo de ejecución. Para evitar la saturación, el servidor puedeincorporar mecanismos de control de flujo, aumentando los temporizadores de ven-cimiento o incluyendo asentimiento y envío ordenado; al mismo tiempo, la pasarelapuede ajustar sus recursos a las características del tráfico esperado en cada etapa,dando más prioridad al tráfico descendente (del Servidor a la red) durante la fasede acceso o asignándole más cuota de buffering.

421



Frecuenciamáxima

Nodo másocupado

Mensajemás pesado

CONFIG 872 bps 1 Hz Pasarela (0,2 ppc) 57 B

LQI 20,752 kbps 8Hz LightCube (0,55ppc)

127 B


60 B

SET 6,568 kbps 2 Hz Pasarela (0,35 ppc) 127 B

DIRECTOR 1,584 kbps 3 Hz Lightcube (0,3 ppc) 54 B

SCENE 1,696 kbps 4 Hz Lightcube (0,025ppc)

53 B

THRILL 0,848 kbps 8 Hz LightCube (0,2 ppc) 53 B

REMOTE 2,54 kbps 1 Hz Pasarela (0,3 ppc) 127 B


Tráfico TOTAL = 64,884 kbpsCuadro 16.19.: Estimación de ancho de banda en fase de apertura

La fase de apertura ocurre un instante antes de entrar en ejecución. En esta etapade transición, ya se han configurado las zonas y dispositivos escénicos y se procedea registrar a los visitantes. Vemos cómo el servicio de localización adquiere un pesosignificativo en el ancho de banda ocupado, sin llegar a comprometer ni la capacidaddel canal ni el tiempo de cálculo de los nodos, ya que hablamos de una primerafase de calibrado de las balizas y de ajuste de los parámetros de servicio. Con laapertura, todos los servicios se encuentran activos y transmitiendo información,cobrando protagonismo los dispositivos LightCube en su faceta de proveedores. Laarquitectura basada en servicios de la aplicación y el dimensionamiento del protocologarantizan que, a pesar del número de dispositivos que están comunicándose porla red, el canal ocupado por nodo sea de 3,16 kbps, con una tasa media de 1,6paquetes por ciclo. Con estos requerimientos, la capacidad del canal 802.15.4 es másque suficiente.

422

16.6 Localización de dispositivos WSN


Frecuenciamáxima

Nodo másocupado

Mensajemás pesado

CONFIG 225,5 bps 0,28 Hz Pasarela (0,053ppc)

54 B

LQI 19,747 kbps 12,5 Hz Visitante (1,78 ppc) 127 B


60 B

SET 30,208 kbps 12,5 Hz LightCube (2,91ppc)

127 B

DIRECTOR 15,36 kbps 32 Hz LightCube (1 ppc) 48 B

SCENE 12,032 kbps 32 Hz LightCube (0,2 ppc) 47 B

THRILL 3,008 kbps 8 Hz LightCube (0,8 ppc) 47 B

REMOTE 6,35 kbps 6,25 Hz Pasarela (0,625ppc)

127 B


Tráfico TOTAL = 93,6085 kbpsCuadro 16.20.: Estimación de ancho de banda en fase de ejecución

La fase de ejecución corresponde al estado estacionario de la aplicación, donde todoslos servicios están realizando su función dentro del Soporte. El tráfico de esta fase esmayoritariamente información de servicio proveniente de la red. Vemos en la tablael peso del servicio de localización, el control de zonas y también el control escénico.Mientras que la tasa del servicio de localización crece de forma lineal con el númerode visitantes, el tráfico de zonas (movilidad de visitantes y reproducción de escenas)crece de forma geométrica con el número de zonas. Proyectando estos datos, seestima una capacidad máxima del sistema de 20 LightCubes y 10 Visitantes, con unainstalación dividida en 10 zonas. Con estos parámetros, alcanzamos una ocupaciónmáxima del canal de 245 Kbps en tiempo de ejecución.

16.6. Localización de dispositivos WSN

La localización en WSN es un campo muy vasto de investigación, que afecta alplanteamiento del Soporte Técnico en tanto que los efectos programados dependende la presencia y de la posición del espectador. Actualmente, se desarrollan treslíneas de publicación paralelas sobre la materia:

423


1. Analizar el coste computacional de una aplicación distribuida.2. Determinar la precisión y validez de un determinado algoritmo.3. Resolver el compromiso entre resolución y coste energético del sistema.

La labor de documentación realizada nos lleva a pensar que, a pesar del gran volumende datos técnicos existente, resulta difícil trasladar las propuestas a un sistema fuerade las condiciones de estudio. Pocas son las investigaciones académicas en las quese ha analizado globalmente el impacto de un sistema de localización, desde sudefinición matemática hasta su validación experimental. Cada publicación exponesólo los aspectos novedosos de su trabajo, no existiendo un modelo de referencia delque deriven. Y lo mismo sucede en los proyectos de referencia: que no entroncancon ninguna teoría, ni presentan un diseño que pueda servir de guía interpretativay de escala para su evaluación. Al no existir puentes entre la investigación y losantecedentes del Proyecto, una parte importante del trabajo pasa por la justificacióny la definición del sistema de localizacion que debería implementar una aplicaciónpara una instalación interactiva.La localización es un imperativo del Soporte, ya que dota de contexto al visitante.Se debe a los requisitos del Proyecto, donde ya establecíamos que el Soporte buscaun sistema más rápido que preciso, pero en todo caso fiable y escalable. Tambiénse ha impuesto por diseño que la localización forma parte de la arquitectura deservicios, lo que implica que todo el sistema debe estar adaptado y dimensionadopara rastrear a los visitantes, lo que tiene fuertes implicaciones en el ciclo de trabajode la aplicación.

Motivación3

El problema del movimiento

There are two basic operations that are elemental to tracking mobile users - uptadeand find. Associated with each one of these operations there is a certain cost. Forinstance, frequent uptades cause high power consumption at the mobile units andload the wireless network. Network - wide searches load both the backbone and thewireless networks. Intuitively, increasing one cost leads to a decrease in the otherone.The idea is that mobile users will transmit update messages only upon entering areporting cell, and a search for any user will always be restricted to the vicinity of areporting cell - the one to which the user lastly reported. This strategy is static in thesense that the location of the reporting centers is fixed. Also, the strategy is globalin the sense that all mobile users transmit their update messages in the same set ofcells. Note that it might happen that a mobile user will transmit frequent updatemessages, even if it does not move far since it can move in and out a reporting

3[2, 1]

424


center frequently. It czn also happen that a mobile user will not transmit updatemessages for long periods of time, even if it moves a lot, since it does not enter areporting center. The question of where to place the reporting centers so that somecost function is optimized is answered in for various cell topologies.

We focus on dynamic strategies in which the mobile users transmit update messagesaccording to their movements and not in predetermined cells. These strategies arelocal in the sense that the location update may differ from user to user and the usersthemselves decide when and where to transmit their update messages.

To model the movement of the users we assume that time is slotted, and a usercan make at most one move during a slot. The movements will be assumed to bestochastic and independent from one user to another. For each user, we analyze twotypes of movements - the i.i. d. (independent and identically distributed) movementand the Markovian movement. In the i.i.d. model, if a user is in cell i at the beginningof a slot, then during the slot it moves to cell is1 with probability p, moves to celli - 1 with probability p, or remains in cell i with probability 1 - 2p (0 < p < 1/2),independently of its movements in other slots. In the Markovian model, during eachslot a user can be in one of the following three states: (i) The stationary state (S)(ii) The right-move state (R) (iii) The leftmove state (L). Assume that a user is incell i at the beginning of a slot. The movement of the user during that slot dependson the state as follows. If the user is in state S then it remains in cell i, if the useris in state R then it moves to cell i + 1, and if the user is in state L then it movesto cell i - 1. Let X ( t ) be the state during slot t. We assume that {X(t), t = 0 , 1 ,2 , . . .} is a Markov chain with transition probabilities pk,l = P ~ o b [ X (+t 1 )= Z/X(t) = k] as follows: pR,R = pL,L = q, pL,R = pR,L = v, PS,R = PS,L = P,PL,S = PR,S = 1 - q - v and p s , =~ 1 - 2 p (see Figure 1).

Figura 16.11.: Diagrama de estados de paseo modelado como una cadena deMarkov

Para el caso de movimiento independiente e idénticamente distribuido (I.I.D.), te-nemos:

De donde sigue que:

UD = pQD−1 = 2pD2

425


Algoritmo 16.1

Qd = lım inf (Prob [Y (t) = d]) , d = 0, 1, ..., D − 1

2pQ0 = pQ1 + pQD−12pQ1 = 2pQ0 + pQ22pQd = pQd−1 + pQd+1, 2 ≤ d ≤ D − 2pQD−1 = pQD−2Resolviendo y normalizando, tenemos,

Q0 = 1D

;Qi = 2 (D − i)D2 , 1 ≤ i ≤ D − 1

SD = 1 +D−1∑d=1

dQd = 1 + D

3 −1

3D

Una comparativa de estas métricas con las que obtendríamos al aplicar una estra-tegia basada en el movimiento o una tasa de muestreo temporal, demuestra que laactualización basada en la distancia es mucho más eficiente (hasta dos veces mejor),justificando su elección.En el caso del movimiento markoviano, las ecuaciones que desarrollan los posiblesmovimientos son las siguientes:El usuario envía su información en el slot i si y sólo si tanto Y(t-1) = D-1 y X(t-1)= R, o Y(t-1) = -(D-1) y X(t-1) = L. En este caso:

UD = 2QD−1,R

El número de búsquedas necesarias para localizar a un usuario es:

SD = 1 + 2D−1∑i=1

i (Qi,S +Qi,R +Qi,L)

Resolviendo las ecuaciones de balance anteriormente presentadas, tenemos que:

UD = 2p (1 + q − v)D (1 + 2p− q − v) [D (1− q − v) + 2 (q − v)]

426


Algoritmo 16.2Q0,R = pQ0,S + qQD − 1, R + vQ−(D−1),L + qQ−1,R + vQ1,L

2pQ0,S = (1− q − v)×(QD−1,R +Q−(D−1),L +Q−1,R +Q1,L

)2pQd,S = (1− q − v) (Qd−1,R +Qd+1,L) , 1 ≤ d ≤ D − 2Qd,R = pQd,S + qQd−1,R + vQd+1,L, 1 ≤ d ≤ D − 2Qd,L = pQd,S + vQd−1,R + qQd+1,L, 1 ≤ d ≤ D − 22pQD−1,S = (1− q − v)QD−2,R

QD−1,R = pQD−1,S + qQD−2,R

QD−1,L = pQD−1,S + vQD−2,R

por simetría, se asume que:

Qd,R = Q−d,L,− (D − 1) ≤ d ≤ (D − 1)

Qd,S = Q−d,S, 1 ≤ d ≤ (D − 1)

SD = 1 + (D − 1) [D + 1− (q − v) (D − 2)]3 [D − (q − v) (D − 2)]

Figura 16.12.: Coste de la tasa buscar vs. actualizar con un modelo markoviano(izquierda: q = 0.8, v = 0.1, p = 0.1 / derecha: q = 0.1, u = 0.8, p = 0.1)

Los resultados anteriores nos permiten concluir que, en el caso en el que, con muchaprobabilidad, el móbil vaya a cambiar de posición, lo más adecuado es manteneruna tasa fija de actualización. Si el caso en el que el nodo se encuentra lejos de unafrontera, lo más óptimo es ajustar la actualización por la distancia, como, por otra

427


parte, indica el sentido común. En el Soporte, no se puede implementar el mecanismopor movimiento porque el nodo móvil no conoce el número de desplazamientos hastahaber actualizado su posición (ya que la topología de red y la topología de losdispositivos no coinciden, ya que hay más fronteras entre zonas que fronteras entrecélulas). Por otra parte, el mecanismo de búsqueda podría ser interesante comoprotección, pero no como desencadenante, porque sería forzar un comportamientoen la WSN contra la lógica de diseño, que obliga a distribuir las funciones hasta elpunto más bajo de abstracción que pueda resolverlas dentro de las especificacionesde trabajo: En definitiva, si la red no está mandando posiciones, debe haber otromotivo por el que el servidor se preocupe antes de solicitar la posición de un nodo.

Localización basada en la potencia recibida (RSS)

La localización WSN es el proceso de obtención sistemática de la ubicación física deun nodo por medios inalámbricos. El conocimiento de la posición de los dispositivoses fundamental para la realización de muchas tareas: la localización facilita un con-texto para la medición de datos y provee un soporte para los servicios de red. Muchasde estas aplicaciones se basan en medidas de la potencia de señal recibida (RSS),aunque también se aplican otras técnicas como la estimación del retraso de llegada(TDOA), tiempo de vuelo (TOF), ángulo de llegada (AOA), etc. En general, estastécnicas son más precisas que las basadas en RSS, pero necesitan un equipamientoespecífico y mayor capacidad de procesamiento y comunicación, por lo que acarreanun mayor consumo.La propagación de señales radio se ve afectada por múltiples factores, que contri-buyen a la degradación de su calidad. Estos efectos son aún más significativos en lapropagación de señales inalámbricas con poca potencia de transmisión. Consecuen-temente, los enlaces WSN suelen tener un comportamiento impredecible. Se sabeque hay tres factores que afectan a la calidad del enlace: (i.) el entorno, que produceefectos de propagación multi-camino y contribuye al ruido de fondo, (ii.) las fuentesde interferencia, que surgen de transmisiones de la propia red inalámbrica, de redesvecinas o de fuentes electromagnéticas concurrentes; por último, (iii.) el hardwarede transmisión, que limita las características de rango dinámico y potencia de señal.En los motes WSN, debemos considerar, además, la característica de transmisiónno isotrópica de las antenas, que, en conjunción con la baja potencia de transmisióny la cohabitación con múltiples fuentes de interferencia en la banda de 2.4 GHz.,suponen un factor crítico para la calidad de la comunicación.El rango de transmisión puede dividirse en tres regiones, con una forma irregulary límites cambiantes, pero características específicas en cuanto a la comunicación.En la región de conexión (i.), los enlaces son estables, simétricos y de una calidadsostenida; en la región de transición (ii.), los enlaces mantienen una calidad promedioen el largo plazo, pero son inestables, no tienen un comportamiento correlado conla distancia y son generalmente asimétricos; finalmente, en la región de desconexión(iii.) los enlaces mantienen una pésima calidad y no són hábiles para la comunicación.

428


Las técnicas de localización basadas en medidas del enlace explotan distintos esti-madores o métricas para su evaluación. Se han definido, entre otras, las siguientes:PRR (Packet Reception Ratio). Se computa como la razon entre el número de pa-

quetes recibidos correctamente frente al número de paquetes enviados. Unamétrica complementaria es el PER (Packet Error Ratio).

RSSI (Received Signal Stregth Indicator). La mayoría de los transceptores radio802.15.4 incluyen un registro RSSI. Este registro facilia una lectura del nivelde señal para cada paquete recibido. En ausencia de transmisiones, este registromarca el nivel de ruido base.

SNR (Signal to Noise Ratio). Se obtiene generalmente a partir de la diferencia endecibelios entre el nivel de señal de información recibido (señal sin ruido) y elnivel de ruido ambiente.

LQI (Link Quality Estimator). Se propone en el IEEE 802.15.4, pero su implemen-tación depende del fabricante. Para el chip CC2420 instalado en los equiposde Jennic, la LQI se calcula a partir de los ocho primeros símbolos del paque-te recibido, asignando una puntuación entre 50 y 110 (donde un valor mayorsignifica una mejor calidad).

Distintas publicaciones han contribuido a caracterizar el canal de transmisión WSN,del que caben destacar los siguientes aspectos:

La calidad del enlace es anisótropa.Los nodos que están físicamente más próximos tienen una mayor correlaciónespacial en su PRR.La variabilidad espacial de la calidad del enlace se debe a la interferenciaconstructiva / destructiva.La variabilidad temporal en la calidad del enlace se debe a cambios en el medio(humedad, temperatura, obstáculos). La zona de transición se extiende entredos umbrales en la curva PRR/SNR, entre el 25% y el 90%.Principales fuentes de interferencia:

• Redes 802.11b (WiFi), excepto si la WSN se despliega en el canal 26.• 802.15.1 (Bluetooth), en menor medida que las redes WiFi.• Electrodomésticos (hornos microondas).• Cross - channel.

Métodos de localización en WSN basados en RSSI4

Los métodos RSS hacen uso de distintos modelos de propagación para ponderarla influencia del entorno en el rendimiento de la calidad del enlace. En general, la

4[9]

429


literatura técnica ha dado en clasificar los métodos de localización basados en RSSIdentro de las siguientes categorías:

Fingerprinting

La técnica, también denominada mapeado, se basa en la identificación de patrones.La implementación pasa por una primera etapa de calibración, en la que se realizanmapas con medidas de las balizas desde posiciones estratégicas de la planta WSN;en una segunda etapa, la localización supone encontrar el patrón más próximo a lasmedidas en tiempo real.

El fingerprinting es muy eficaz en entornos de interior relativamente estáticos, ya quepuede compensar fuentes estáticas de ruido, tales como paredes y objetos inmóviles.

Localización basada en rangos

Estos métodos parten de la asunción de que el nivel de señal decae con la distanciasiguiendo una distribución conocida. Esta distribución se utiliza para convertir lasmedidas de señal en estimaciones de distancia. Como podemos imaginar, el modelode propagación incluye distintos parámetros, que deben ser correctamente ajustadospara que el método sea eficaz en la planta WSN.

La localización basada en rangos se apoya en la multilateración para cuadrar laposición a partir de las distancias y posiciones de las balizas de la red. En estecaso, las balizas deben cumplir con unos requisitos más exigentes que en los demásmétodos en cuanto a potencia de emisión e isometría de radiación para garantizarla eficacia del sistema.

Dentro de esta categoría, uno de los métodos más aplicados es el uso del MaximumLikelihood Estimator , basado en el modelo de propagación Log - Normal, que vere-mos en el siguiente apartado.

Localización independiente del rango

Este método ofrece una alternativa menos exigente pero también menos precisaque la localización basada en rangos. En ella, los nodos calculan su posición por elcentroide de las coordinadas de las balizas de las que recibe señal.

Como podemos imaginar, el rendimiento de este método depende del ajuste entrelos valores reales y esperados de los rangos de transmisión y el despliegue de unamayor cantidad de balizas.

430


Localización basada en la proximidad

Al igual que los métodos basados en rango, en los métodos de proximidad se asumeque la intensidad de señal es inversamente proporcional a la distancia, pero en estecaso se emplean únicamente los órdenes de magnitud RSS, en vez de convertir lamedida de señal en distancia. La principal ventaja de este método es que no necesitaun calibrado previo. Uno de los métodos más destacados dentro de esta categoría esla denominada ecolocación.Veremos algunas consideraciones sobre el coste computacional de los distintos mé-todos, pero antes, vamos a introducir los aspectos teóricos que definen los límites derendimiento de la localización basada en RSS y las métricas que caracterizan cadamétodo.

Consideraciones teóricas5

Para el problema de la localización, la red se modela como un grafo conectado yno direccional, G = (V,E), donde V es el conjunto de nodos del sensor y E es elconjunto de enlaces entre nodos vecinos. Cada enlace e(u,v) lleva asociado un valorzεZ (por ejemplo, un valor RSSI). Sean (x,y) las coordenadas desconocidas de uεV .Sea A ⊂ V el conjunto de balizas, cuyas coordenadas son conocidas. La localizaciónsupone encontrar las coordenadas (x,y) de cada nodo uεV \ A.El problema de localización se resuelve asignado a los pesos z de los enlaces o bienuna medida de distancia, o bien una unidad significativa para la topología física dela red (radius, distancia compensada en saltos...). En la aproximación discreta RSSI,z puede tener uno de los pεP valores de RSSI cuantizados, donde la relación entreP y la distancia real es una relación biyectiva desconocida and its usually set usinga RSSI quantization scheme.Tracing back the lateration technique we come across the concept of Cramer-RaoBound applied to the localization problem. CRB defines the lower bound on theprecision of a localization estimator. Solve the localization problem step-wise asfollows:

1. Basic concept: known noise distributions are applied to distance measure-ments.

2. Theoretical step: determine CRB to obtain an idea of the achievable accuracyof unbiased position estimators.

3. Algorithm: from the formulation of CRB determine the metric to be minimizedin order to obtain a position (e.g. using the lateration procedure).

4. Post processing: use coefficients such as Geometric Dilution of Precision (GDOP)to correct issues not captured by the estimation theory (such as the geometry

5[11, 6]

431


of anchor deployment). It is assumed that minimizing the sums in the latera-tion equation leads to better position estimates.

En una WSN con K nodos móviles y B balizas - con posiciones conocidas -, seaX = {Xkl}el conjunto de todas las medidas RSSI, donde Xkles el valor RSSI medidopor un nodo k de la señal recibida desde l. Sabemos que la medida no es totalmenteprecisa, debido a la sensibilidad de equipo y a la influencia del entorno. Si la posicióndesconocida de cada nodo móvil es rk = (xk, yk) , k = 1, 2, ..., K y la posición decada baliza rk = (xk, yk) , k = −B+1,−B+2, ..., 0, la localización puede formularsecomo el problema de estimación de rk, k = 1, 2, ..., K a partir de las medidas Xkl

y las posiciones conocidas de las balizas rk, k = −B + 1, ..., 0. En definitiva, puedeasimilarse a un problema de estimación de parámetros.A partir de la formulación del problema como una estimación de parámetros, puedeser analizado aplicando la teoría de la estimación.

Algoritmo 16.3 Definición de la matriz de información de FisherSi R = [r1, r2, ..., rK ]son los parámetros a ser estimados y R (X) =[r1 (X) , r2 (X) , ..., rK (X)]son estimadores insesgados de cada parámetro para unaobservación X y si p (X|R)son las probabilidades que relacionan las medidas obser-vadas con los parámetros buscados, la teoría establece que el límite inferior de lavarianza de dicho estimador puede calcularse como:

σ2k = var (rk (X)− rk) ≥ J−1

kk (16.1)

Donde Jkkes la información de Fisher del parámetro k.Los elementos de la Matriz de Información de Fisher (FIM) J se computan como:

Jkl = −E(∂2 ln p (X|R)

∂rk∂rl

)

Como estamos buscando las coordenadas de cada nodo móvil, la matriz J del pro-blema de localización puede organizarse como sigue:

J =(Jxx Jxy

JTxy Jyy

)

Los nodos de una WSN se comunican por enlaces punto a punto. El nivel RSSI quealcanza a cada nodo se ve afectado por los efectos perjudiciales de desvanecimientodel canal, atenuación por la distancia y pérdidas en obstáculos. De acuerdo con elmodelo Log - Normal, la potencia recibida por un nodo k transmitida desde un nodoj (expresada en dBm) puede expresarse como:

432


Pkj = Π0 − 10np log dkj

∆0(16.2)

donde Π0(dBm) es la potencia recibida a una distancia de referencia ∆0. General-mente, la distancia de referencia es 1 metro y la potencia se calcula a partir dela fórmula de propagación en espacio libre. El exponente de pérdida de trayectonpdepende del entorno y suele variar entre 2 y 4 y puede modelarse como una va-riable gaussiana:

np ∼ N (α, σ)

A partir de aquí, la probabilidad condicionada de recibir una potencia P en un dis-positivo k con una localización rk transmitida desde un dispositivo j con localizaciónrj será

pkj (P ) = 1√

2π(10log dkj

∆0

)σe

−

[P−(

Π0−10αlogdkj∆0

)]2

2[(

10logdkj∆0

)σ

]2

(16.3)

Plugging the probabilistic mapping, we can derive the Cramer-Rao lower bound onthe localization error variance for localization using quantized RSSI.Several network parameters affect the Cramer-Rao bound (CRB) of localizationerror variance Let σ2

xk and σ2yk be the CRB of error variance of estimating xk and

yk, respectively.We compute the root-meansquared location error variance of eachnetwork, RMS (σ), by

RMS (σ) =

√√√√ 1A

A∑k=1

(σ2

xk + σ2yk

)

The value RMS (σ) gives the average lower-bound variance in errors of estimatedsensor node locations. The smaller RMS (σ), the higher confidence we have on thelocalization result generated by a localization algorithm.

RSSI quantization level, S, is the parameter used to set thresholds for RSSIvalue intervals. Shows that RMS (σ) decreases as S increases until S reachesa certain value. After that, RMS (σ) cannot be improved by increasing thequantization level. This is due to the noise in the RSSI readings. When thequantized RSSI value interval is comparable to the noise, increasing the quan-tization level becomes less useful.

433


RMS increases when the network size increases, which indicates that networksize is a negative factor in localization accuracy. However, moving the anchorsfrom the outermost layer to some inner layer can improve RMS significantlyfor larger networks. This suggests that if the anchors are positioned in a layerso that the number of outer nodes and the number of inner nodes are balanced,RMS (σ) can be kept from increasing too fast as the network size increases.

The simulation shows that RMS (σ) decreases when density increases. Refe-rring to the result about the network size effect, to maintain a lower RMS, alarge number of nodes are needed to counteract the effect of increasing networksize.

We showed that the one-hop distance-based localization mechanism has geometryas its foundation and not measurement noise as CRB assumes. The localizationboundaries should thus be explored first from a geometrical perspective and thencomplemented by knowledge of the noise characteristics.

Consideraciones técnicas

La siguiente tabla, recoge un análisis pormenorizado del coste computacional dedistintas técnicas de localización.

434


Cri

teri

oLP

Cen

-tr

aliz

ado

Inte

rsec

ción

rect

angu

-la

r

Mul

tila

tera

ción

(Kal

man

)A

pren

diza

je(K

erne

l)D

V-H

opC

uadr

ícul

aD

espl

iegu

ey

ajus

te

Esc

alab

ilida

dNo

SíSí

Mod

erada

SíSí

Sí

Con

sum

oen

com

uni-

caci

ones

( D·

N2)( D

·N 3

+c)

3·N

·D

·c

N·

O

[ (A+

s·c)

D2

+D

3 3

]O( A

3k

2+

R2A

k2) N

·O

[ (A)D

2+D

3 3

] D·

c·N

N·

O

[ (A+

s·c)

D2

+D

3 3

]

Con

sum

oen

cálc

ulo

pa

thle

n·

c·N

N·

cA

·N

+

c·N

·s

A·

NA

·N

N·

cA

·N

+

c·N

·s

Pre

cisi

ón++

++

con

mucho

sno

dos

cono

cidos

++

++

++

con

mucho

sno

dos

cono

cidos

++

Tol

eran

cia

aler

ror

+++

++

++

++

++

Vel

ocid

adde

conv

er-

genc

ia

Prop

orcio

nal

alcuadrado

delá

rea

Rápida

Prop

orcio

nal

altamañoy

lasite

racio

nes

delfi

ltro

Prop

orcio

nal

altamaño

Prop

orcio

nal

altamaño

Rápida

Prop

orcio

nal

altamañoyel

númerode

iteracio

nes

Con

sist

enci

aen

tre

rede

s

No

No

SíNo

SíNo

Sí

Est

imac

ión

del

erro

r

No

No

No

SíNo

No

No

Cos

tede

red

Alto

Alto

Bajo

Depende

del

tamaño

Bajo

Alto

Bajo

Cuadro 16.21.: Evaluación del coste computacional de distintos métodos delocalización

435


De acuerdo con estos datos, tanto el esquema basado en la multilateración como elfingerprinting (despliegue y ajuste) producen buenos resultados con un coste bajode red y capacidad de expansión. A cambio, deben mantener un tráfico constante yson más lentas en cuanto a cálculo que otras técnicas como el conteo de saltos o elfiltro LP centralizado.El Soporte Técnico puede compensar este coste añadido aprovechando la doble ar-quitectura del sistema: por una parte, puede compaginar una localización rápida anivel de red con un esquema más exacto en el servidor que compense la menor preci-sión del esquema distribuido, aprovechando las mismas medidas de señal obtenidaspara la localización local. Este modelo de servicio en dos partes permite aligerar elpeso de cálculo y las necesidades de almacenamiento de datos de los nodos, perotambién permite combinar dos sistemas de localización, de forma que el servidor nose centre en corregir los resultados, sino en ajustar los parámetros del esquema delocalización implementado en los motes. La única condición para hacerlo posible esque toda la cadena de operaciones se ejecute dentro de la ventana de tiempo delsistema, determinada por el movimiento del visitante.

Conclusiones prácticas6

El servicio de localización implementado puede soportar distintos métodos delocalización basados en muestras de la calidad del enlace tomadas por un nodoen movimiento con respecto a un sistema de balizas fijas.La estimación de la localización en el nodo se realiza a partir de las muestraspromediadas. Los referentes incluyen distintas técnicas: trilateración, mínimoscuadrados y centroide ponderado (WCL).El número mínimo de balizas para la implementación de cualquier esquema es3. El mínimo recomendado es 4.La utilización de esquemas de localización WSN tiene una resolución acotadapor la geometría de la red y las características de los equipos y el medio.Distintos estudios fijan la cota de Cramer - Rao para un sistema basado enmultilateración en 0,4m rms.El rendimiento real de los sistemas de localización RSS se sitúa en el entorno de1 a 3m rms. Para conseguir una precisión mayor, deben recurrirse a algoritmosmás refinados o un equipamiento de calidad.Cada fabricante incorpora sus propias funciones y métricas. No todos los SDKincorporan funciones para acceder al RSSI de cada paquete (como es el casode Jennic), obligando a recurrir a esquemas alternativos.La capacidad del sistema (en cuanto a número de nodos) se ve limitada porla frecuencia de actualización. Para una tasa en torno a los 2 segundos, el

6[16]

436

16.7 Tiempo ciclo

número máximo de nodos es 24, sin contar con el tráfico consumido por losdemás servicios activos en la red.

16.7. Tiempo ciclo

El tiempo al que deben ajustarse los ciclos de ejecución de la aplicación WSN vie-nen determinados por el movimiento del visitante y el servicio de localización. Eneste apartado, vamos a estimar la frecuencia mínima de trabajo del sistema paragarantizar la capacidad de localización del espectador, en la base de todo el sistemadesplegado.

Figura 16.13.: Modelo de referencia para la localización del visitante

Como se deduce del apartado anterior, el proceso de localización no genera una in-formación exacta acerca de la posición del nodo en movimiento, sino precisa, dentrode la resolución de los equipos y el esquema utilizado. Aunque estemos determi-nando unas coordenadas {x,y} asociadas al visitante, sabemos que en realidad elproceso supone una asociación a una zona acotada del espacio. Esta celda básicade localizacion puede definirse a partir del límite teórico de resolución del esquemaaplicado o, siendo menos exigentes, considerando el límite práctico, más cercano alas capacidades reales del servicio implementado. Se define una celda básica comoun cuadrado de 1,2m de lado.

437


Asumiendo una velocidad máxima de desplazamiento de un visitante de 1,8 m/s,se define un mapa cartesiano de coordenadas en torno al origen del sistema o nodoCoordinador- (representadas como un valor entero con signo) en el que el serviciode localización debe actualizar la posición del visitante con una velocidad suficientecomo para no perderlo en un área equivalente a una celda básica. Si la velocidadse mantiene constante, significa que el visitante puede cambiar de coordenadas 1,5veces por segundo, lo que implica una frecuencia mínima de estimación de 330ms.A partir de esta tasa, deben dimensionarse todos los temporizadores del sistemapara asegurar que toda la secuencia de comunicación entre el nodo Visitante, la redWSN y el servidor se completa dentro de la ventana temporal de 330ms exigida.Para ello, se considera el peor caso posible, reflejado en el siguiente diagrama depaso de mensajes:

Figura 16.14.: Camino crítico del sistema

438

Soporte técnico para una instalación de arte...

Documents

Transcript of Soporte técnico para una instalación de arte...