PaperInfo3.ppt

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.