Informática III 2010 Presentación Paper Integración de Sistemas Embebidos Utilizando Servicios Web

Integrantes: • Kenny, Juan Francisco • Patriarca, Rodrigo • Santa Cruz, Santiago

Resumen

 Las aplicaciones embebidas en la actualidad requieren una integración cada vez mayor.

 Los Servicios Web proporcionan una arquitectura distribuida orientada a los servicios (SOA) para la interconexión de sistemas a través de redes TCP / IP.

 Los Servicios Web permiten una integración que aún no es proporcionada por las aplicaciones embebidas.

 El presente trabajo tiene por objeto demostrar la viabilidad del uso de Servicios Web para la integración de aplicaciones embebidas que se ejecutan en arquitecturas heterogéneas.

Definiciones

Sistema embebido:

Es un sistema de computación diseñado para realizar una o algunas pocas funciones dedicadas frecuentemente en un sistema de computación en tiempo real. Los sistemas embebidos se utilizan para usos muy diferentes a los usos generales a los que se suelen someter a las computadoras personales.

Diagrama de bloques de un sistema embebido típico

Definiciones

Servicios Web:

En inglés,

Web services,

es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.

Definiciones



Computación Ubicua:

Es la integración de la informática en el entorno de la persona, de forma que los ordenadores no se perciban como objetos diferenciados. Tiene como objetivo insertar dispositivos inteligentes tanto en el entorno como en aparatos de uso diario para que las personas puedan interactuar con ellos de una manera natural y desinhibida en todo tipo de situaciones y circunstancias.

Algunas plataformas existentes para Servicios Web

  Plataformas embebidas: NetBurner, RabbitCore (familia RCM) y SHIP entre otras.

Herramientas de desarrollo para plataformas embebidas: J2ME, ETTK, eSOAP y gSOAP.

Limitaciones para la elección de herramientas:  Aspectos de hardware (procesamiento, memoria, sistemas operativos más complejos, etc.).

  Entorno de desarrollo (requiere herramientas comerciales o un conjunto de otros programas como compiladores específicos).

Documentación incompleta, insuficiente o inexistente.

Capas de los Servicios Web

Descripción de las capas

 El núcleo de la arquitectura de servicios Web se compone de un protocolo de Internet (HTTP en la mayoría de los casos), que envía mensajes encapsulados XML utilizando el Protocolo SOAP. Como capas superiores tenemos el lenguaje de descripción de los servicios web WSDL y el repositorio que puede ser empleado para publicar y localizar todos los servicios web UDDI (Universal Description, Discovery and Integration).

Interacciones entre proveedores, consumidores y brokers de Servicios Web

Interacciones entre proveedores, consumidores y brokers de Servicios

Web

Un corredor de servicio se comporta como un repositorio para la publicación de los prestadores de servicios y para la ubicación de estos por los solicitantes de servicios.

Después de ser localizado, un proveedor de servicios puede brindarlos a un solicitante.

Principales características de los Servicios Web

  Basados en XML.

Articulación flexible entre proveedores de servicios y los solicitantes.

  Granularidad gruesa.

El cliente y la comunicación de servicios pueden ser sincrónicos o asincrónicos.

 Soportan RPC (Llamada a Procedimiento Remoto).

 Soportan el intercambio de documentos.

Principales características de los Servicios Web

  Emplean los mismos protocolos de comunicación adoptados por la Web, permitiendo el intercambio de datos a través de firewalls corporativos.

Son capaces de proveer interacción entre aplicaciones y programas sin intermediación del hombre.

 Pueden comunicarse con otros servicios web y luego ser capaces de suministrar nuevas aplicaciones fusionando todos sus servicios.

Arquitectura propuesta para integrar dispositivos embebidos usando Servicios Web

Arquitectura propuesta para integrar dispositivos embebidos usando Servicios Web

   Un cliente envía sus mensajes XML / SOAP según el tipo de servicio requerido a través del protocolo HTTP.

En el servicio web se produce la planificación eficaz de las solicitudes en función de sus prioridades (oro, plata, bronce y mejor esfuerzo). A continuación, estos mensajes serán procesados por el microcontrolador.

Después de la ejecución, una respuesta generada por el servicio puede devolverse al cliente.

Escenario hipotético de integración

Escenario hipotético de integración

   Supervisión y control de señales vitales de pacientes hospitalarios.

Los dispositivos remotos conectados a la plataforma SHIP envían señales al equipo de adquisición y luego estos valores se envían como información XML / SOAP a un servidor de aplicaciones.

El servidor de aplicaciones almacena y distribuye las diversas informaciones procedentes de diferentes conjuntos de plataformas SHIP y los dispositivos remotos conectados dentro del ambiente del hospital a los clientes respectivos (base de datos del hospital, personal médico en el hogar o en el hospital, y familiares del paciente, usando ordenadores, PDA's, teléfonos móviles, etc).

Gestión de prioridades

 Podemos ver claramente la diferenciación de servicios: oro para el control en tiempo real, plata para las alarmas enviadas a personal médico, bronce para la actualización de base de datos y mejor esfuerzo para otros servicios.

Ventajas con respecto a otras topologías

    La gran ventaja de esta propuesta es que, ya que se está usando servicios Web, el resto del entorno distribuido sólo tiene que ser capaz de manejar los mensajes SOAP. Las preocupaciones sobre la integración con sistemas heredados, estructura de base de datos, tipo de software que utiliza el cliente, etc. son irrelevantes.

El uso de esta estructura se puede aplicar en la mayoría de los diversos escenarios, tales como: Supervisión, control y difusión de los datos en las líneas de transmisión (electricidad, televisión por cable, etc) y los sistemas y aplicaciones más diversos involucrados.

Entornos de fábrica con los sistemas embebidos más diversos con interfaces específicas de comunicación.

Plataforma adoptada

 Plataforma SHIP

Características SHIP

       Microcontrolador ARM7TDMI, familia AT91X40 con procesador RISC.

512 K Bytes de memoria flash, con 448K bytes libres para las aplicaciones.

Sistema operativo compatible con conexiones Ethernet y comunicaciones TCP / IP.

μBoot para la carga del sistema y programa depurador μMonitor para la configuración y la carga de las aplicaciones en la plataforma.

Servidor de páginas Web compacto.

Diversos dispositivos externos se pueden conectar a la plataforma tales como equipos de automatización de fábricas, sensores y actuadores, equipos médicos, etc.

Bajo consumo de energía, amplia gama de bibliotecas de soporte y softwares incorporados.

¿Por qué la plataforma SHIP?

 No sólo el software de desarrollo, sino también el sistema operativo de la plataforma embebida y las bibliotecas de tiempo de ejecución son de código abierto y tienen buena documentación y soporte total.

Herramienta de Desarrollo (Toolkit)

  gSOAP.

Ha demostrado ser el más compatible con la plataforma elegida (SHIP, sólo trabaja con rutinas de C y todas las otras herramientas de desarrollo no tienen esta característica).

 Fue necesario hacer algunos cambios en el código fuente con el fin de hacer compatible gSOAP con el sistema operativo del SHIP.

Características gSOAP

    Permite la composición (vinculante) de los mensajes SOAP con C / C + +, crear stubs y esqueletos.

Clientes C / C + + a través de analizador de WSDL (convertidor WSDL a archivos de cabecera gSOAP).

Independiente de la plataforma (hay ejemplos de aplicación desarrollados en Windows, Linux, Unix, Mac OS X, Pocket PC, Palm OS, Symbian y Linux embebido).

Las aplicaciones pueden realizarse con menos de 100K bytes, con consumo total de sólo 150K bytes de memoria.

Ensayos de comportamiento

 Pocas muestras y threads con el objetivo de ver cómo la plataforma SHIP, especialmente su controlador Ethernet, reacciona en una demanda similar a la que se experimenta en el escenario propuesto.

Ensayos de comportamiento

 Servicio de calculadora que tiene un tamaño total de 65KBytes, incluyendo el sistema operativo, el servidor de aplicaciones y las bibliotecas gSOAP.

Así, cuando un cliente solicita uno de los servicios disponibles (es decir, las cuatro operaciones matemáticas básicas), un mensaje SOAP se envía a la plataforma SHIP, que realiza la operación y responde con un mensaje SOAP con el resultado.

Después de esto, el servidor comienza a esperar otra solicitud de servicio.

Respuesta temporal de la plataforma SHIP con un único cliente

Respuesta temporal de la plataforma SHIP con dos clientes

Respuesta temporal de la plataforma SHIP con dos clientes

 El comportamiento observado muestra que algunas solicitudes tienen que esperar más tiempo mientras que otras son procesadas inmediatamente. Esto refuerza la necesidad de un mecanismo de planificación de solicitudes como el descrito anteriormente.

Conclusiones

 Los Servicios Web presentan una forma para interconectar aplicaciones a través de Internet entre sistemas de cómputo. Por otra parte, su eminentemente abierta y estandarizada arquitectura proporciona a los Servicios Web de un gran uso potencial en la computación distribuida.

 Es posible desplegar servicio web en un sistema embebido para proporcionar la integración de aplicaciones que se ejecutan en la plataforma embebida con otro sistema en un entorno distribuido.

 Esta investigación tiene la intención de añadir soporte QoS en servicios web, porque los requisitos y las políticas de uso de QoS aún no están muy consolidados en esta tecnología.