PROTOCOLOS DE COMUNICACIÓN ORIENTADOS A SERVICIOS EN TIEMPO REAL EN DISPOSITIVOS CON RECURSOS

LIMITADOS

Autores: Guido Moritz, Steffen Pruter, Dirk Timmermann, Frank Golatowski

Las Arquitecturas Orientadas a Servicios de cliente (SOA), son cada vez más importantes para la conexión entre dispositivos.

Las principales ventajas de las SOA son:

•Alto nivel de abstracción

•Capacidad de interoperabilidad entre dispositivos

•En diseño web es frecuentemente utilizado (pero no únicamente)

• Sin embargo, esta tecnología solo está disponible para dispositivos con suficientes recursos.

• Por eso, los dispositivos embebidos comúnmente son excluidos de la implementación de servicios web debido a falta de poder de cómputo y memoria.

• Aquí se presenta un nuevo enfoque para manejar servicios de comunicación web en tiempo real, a través de hardware embebido.

• Una manera posible de cumplir con los requisitos de interoperabilidad en redes de sistemas embebidos, es utilizar a SOA como un concepto de arquiterctura de software para este propósito.

• Para esto, se propone utilizar el método SODA (Service oriented device architectures), junto con DPWS (Device Profile for Web Services) como estándar.

• Pero para implementar SODA, se necesitan una cantidad de recursos adicionales.

• Para la interacción cliente/servidor se utilizará el protocolo SOAP (Simple Object Access Protocol)

• Para utilizar DPWS en SODA con recursos limitados, existen herramientas disponibles (ejemplo WS4D, SOA4D). Estas resultan útiles para sistemas embebidos.

SERVICIOS WEB EN SISTEMAS DE SERVICIOS WEB EN SISTEMAS DE CONTROL DE DISPOSITIVOSCONTROL DE DISPOSITIVOS

• Si bien UPnP es un estándar popular, pero debe quedar limitado a redes pequeñas debido a la falta de mecanismos de seguridad y de servicios proxy.

• DPWS es capaz de descubrir dispositivos en tiempo de ejecución de forma dinámica, sin un registro global de servicios (UDDI).

• También se utiliza WS-Eventing, que permite a los clientes una suscripción para ver los eventos en un dispositivo.

• En situaciones específicas, los proxies de comunicación son necesarios debido a la poca memoria y potencia de cálculo de los dispositivos embebidos.

• Con el nuevo enfoque aplicado, ambos dispositivos los embebidos y los dispositivos que son más potentes serán capaces de comunicarse e interactuar entre sí. Estos son sustitutos de la comunicación por proxies.

REQUERIMIENTOS PARA UN S.O.D.A. REDUCIDOREQUERIMIENTOS PARA UN S.O.D.A. REDUCIDO• En primer lugar, debe existir un sistema operativo en tiempo real actuando,

lo que garantiza la programación de las diferentes tareas en el orden correcto y en intervalos de tiempo específicos.

• En segundo lugar, la red física tiene que proporcionar características de tiempo real.

• HTTP está ligado con el Protocolo de Control de Transmisión (TCP). Este tiene partes no deterministas, lo cual entra en conflicto con el dispositivo embebido de tiempo real, al no especificar un tiempo para la finalización de la ejecución.

• Es posible la comunicación SOAP sobre UDP. Pero de acuerdo a la especificación DPWS, el dispositivo debe ser compatible con por lo menos una interfaz HTTP.

• Para los dispositivos embebidos, existen varios sistemas operativos en tiempo real. FreeRTOS es un mini kernel de tiempo real para diversos plataformas como ARM7, ARM9, etc.

• Un sistema operativo en tiempo real permite el acceso a los periféricos en tiempos predecibles, y la ejecución de las tareas en el orden correcto.

• El sistema operativo se encarga de la gestión correcta del hilo y la programación correcta de las tareas de tiempo real y tiempo no real. Las tareas en el controlador, que compiten con la comunicación, son priorizadas por el sistema operativo.

• Desafortunadamente, no hay uso de una pila de red TCP/IP en tiempo real junto con este sistema operativo, para sistemas embebidos. Por lo tanto, nos concentramos en la posibilidad de ofrecer características de tiempo real mediante TCP/IP.

PILA DE REDPILA DE RED

• La pila de red, es la responsable del correcto direccionamiento y el modo de intercambio de datos, es el primer módulo que debe ser realizado.

• Se han desarrollado dos estándares compatibles con la pila TCP/IP para las arquitecturas de controladores de 8 bits: uIP y lwIP.

• Ambas implementaciones están diseñadas para funcionar en arquitecturas de 8 bits con y sin un sistema operativo.

• Las diferencias entre ambas pilas se mostrará en la siguiente figura.

uIP vs lwIPuIP vs lwIP

*Rexmit = retransmisión

*RTT: tiempo que tarda un paquete enviado desde un emisor en volver a este mismo emisor habiendo pasado por el receptor de destino.

• DPWS utiliza WS-Discovery para encontrar automáticamente dispositivos y se basa en multidifusión IP.

• Las aplicaciones de multidifusión utilizan la conexión no fiable UDP.

• uIP puede enviar mensajes de multidifusión con UDP, pero no los puede recibir.

• FreeRTOS puede utilizar la pila lwIP para redes. Este combina las ventajas de una pila de red compatible y liviana, y el uso de un sistema operativo embebido en tiempo real.

SOAP (Simple Objects Access Protocol)SOAP (Simple Objects Access Protocol)

• Después de diseñar la pila de red, sigue el protocolo de comunicación HTTP.

• La carga está incrustada en las estructuras XML y se envía a través de HTTP.

• el procesamiento y análisis de XML se debe analizar. En los dispositivos embebidos, con sólo unos pocos kB de memoria, el tamaño del código y el uso de la RAM tienen que ser reducidos.

• WS-Discovery y los mensajes de obtención de metadatos superan la unidad de transmisión máxima (MTU) de las tecnologías de la mayorías de la redes, incluyendo Ethernet.

NUEVO ENFOQUE BASADO EN TABLASNUEVO ENFOQUE BASADO EN TABLAS• Una implementación completa de SODA para sistemas embebidos

con memoria y poder de procesamiento limitados, es un reto importante.

• Analizando diferentes equipos que cumplen con la implementación DPWS, se observó que en la mayoría de los casos, solo unos pocos tipos de mensajes tienen que ser procesados y sólo unas pocas partes varían entre los mensajes intercambiados.

• Con todos los mensajes intercambiados y a partir del análisis de los diferentes casos, se generan TABLAS. Éstas contienen todos los mensajes apropiados de entrada y de salida. El nuevo enfoque basado en tablas implementado es capaz de responder cada solicitud con la respuesta adecuada, refiriéndose a dichas tablas.

• Este nuevo enfoque basado en tablas no está basado ni en SOAP ni en HTTP. En cambio, se utiliza un enfoque basado en la sencilla comparación de strings (cadenas de texto) de los mensajes de entrada.

• Los dispositivos de éste tipo son capaces de enviar respuestas específicas con secciones dinámicamente variables.

• El consumo de analizar y generar siempre el mismo mensaje se reduce en gran medida con este enfoque.

• Por lo tanto, el uso de memoria y de tiempo de cómputo disminuyen en comparación con una implementación tradicional.

• El tiempo necesario para analizar el mensaje como un string es predecible. El esquema XML que requiere el DPWS no puede cumplir este requerimiento.

• Verificamos nuestra solución en un caso del mundo real:Una PC externa y una cámara aérea están encargados de controlar un

equipo de cinco robots autónomos. Estos reciben comandos de un servidor central, los cuales deben ser ejecutados en intervalos de tiempo concretos para prevenir colisiones y asegurar movimientos precisos por parte de los robots. En la siguiente imagen se muestra la configuración del ensayo:

PRUEBA CON ROBOTS MÓVILESPRUEBA CON ROBOTS MÓVILES

• Para controlar los robots se utilizaron dos placas controladoras alternadamente: una placa con Linux embebido y una placa con controlador ARM7 corriendo FreeRTOS. Las implementaciones son evaluadas mediante una PC estándar y éstas placas. Se resume en la siguiente tabla las especificaciones de hardware:

HARDWARE DEL ENSAYOHARDWARE DEL ENSAYO

• En el primer ensayo, se crea un servicio con el conjunto de herramientas WS4D que provee todos los comandos necesarios para los robots. La PC llama al servicio alojado en los robots. El servicio contesta con una respuesta adecuada.

• En el segundo ensayo, las estructuras y contenidos de los posibles mensajes son depositados en el nuevo dispositivo en forma de strings. Cada mensaje recibido es analizado con un string elemental de comparación. Así se averigua el tipo de mensaje.

• Si el tipo de mensaje se conoce, el dispositivo contesta con el mensaje correcto. En la respuesta, solo las partes requeridas por la especificación DPWS son cambiadas.

IMPLEMENTACIÓNIMPLEMENTACIÓN

La siguiente imagenmuestra los mensajesintercambiados porlos robos móviles:

INTERCAMBIO DE MENSAJESINTERCAMBIO DE MENSAJES

• La implementación del dispositivo mediante el conjunto de herramientas WS4D necesitó de 794 KB de espacio en disco cuando fue compilado para Linux en una arquitectura x86.

• El dispositivo basado en tablas requirió 16 kB cuando fue compilado para una PC x86 estándar corriendo Linux (sin contar el servicio de manejo de IPs).

• Esta misma implementación portada a la placa SAM7 con FreeRTOS tiene un requerimiento de 13 KB (sin contar el servicio de manejo de IPs)

Tamaño total de la implementación SAM7:

Tamaño total: 146 kB

TAMAÑO DE LOS DISPOSITIVOSTAMAÑO DE LOS DISPOSITIVOS

• Se midió el tiempo promedio transcurrido entre el envío de un mensaje y la recepción de la respuesta del lado del cliente.

• Todas las mediciones fueron hechas con una PC estándar y una placa SAM7 con FreeRTOS embebido. En la placa SAM7 también se utilizó un hilo independiente para simular una carga adicional para el CPU.

TIEMPOS DE RESPUESTATIEMPOS DE RESPUESTA

• El nuevo enfoque basado en tablas permite el uso de servicios Web en sistemas embebidos. Más aún, los servicios implementados pueden garantizar capacidades de tiempo real. Así, el dispositivo embebido puede ser integrado en estructuras corporativas de servicios.

• La interfaz de servicios creada puede reutilizarse en diferentes aplicaciones. La conectividad entre una cantidad grande de dispositivos embebidos ya no requiere de proxies, ya que se puede acceder a los mismos mediante una lógica de procesamiento de alto nivel. La validación y certificación se hacen más baratas debido a la simplicidad de la implementación y la reusabilidad de las interfaces.

• Las mediciones muestran que se puede reducir el tamaño de los dispositivos hasta hacerlos aproximadamente 50 veces mas pequeños, al mismo tiempo que los tiempos de respuesta mejoran. Esto siempre que se tenga un sistema operativo de tiempo real subyacente.

CONCLUSIONESCONCLUSIONES