Devices Profile for

Web Services
DPWS en la automatización industrial

5/2/2011
Asier Aranbarri Beldarrain
 1. Introducción

Las siglas DPWS hacen referencia al término Devices Profile for Web Services,
una tecnología que permite que determinados dispositivos con recursos de
procesamiento limitados sean capaces de implementar y trabajar con servicios
web.

Devices Profile for Web Services fue introducido por Microsoft en el año 2004,
siendo desarrollado a partir de ahí por diferentes profesionales de la industria.
Uno de los grandes avances para la tecnología fue la estandarización de la
misma por OASIS, en 2009. Actualmente, la versión DPWS 1.1 es la más
extendida y estable [1].

El toolkit DPWS utiliza los siguientes estándares de Servicios Web: WSDL 1.1,
XML Schema, SOAP 1.2, WS-Adressing, WS-MetaDataExchange, WS-Transfer,
WS-Policy, WS-Security,WS-Discovery y WS-Eventing.(SOA middl+automation).

DPWS se centra en los dispositivos capaces de implementar el protocolo IP,

cada vez más avanzados tecnológicamente. Aunque muchos de estos
dispositivos no dispongan de un nivel de procesamiento de datos alto, deberían
estar preparados para contribuir como partícipes de otros mecanismos en el
mundo de los servicios web que están siendo implantados en el ámbito del
hogar, empresa, oficina, o internet, por citar algunos.

El principal objetivo de DPWS es llevar los servicios web a los dispositivos

“pequeños” [2]. Para ello, permite que estos puedan realizar estas funciones
básicas:

• Enviar de manera segura mensajes a servicios web, y recibirlos.

• Descubrir dinámicamente servicios web.
• Describir un servicio web.
• Suscribirse y recibir eventos de un servicio web.

1
Para conseguir comprender mejor lo que se va a exponer en este documento, es
recomendable conocer los términos más importantes:

• Servicio: Una función que acepta unas llamadas y devuelve unas

respuestas mediante una interfaz bien definida. Ejemplos: devolver
temperatura, imprimir fotografía,…
• Dispositivo: La representación lógica de un dispositivo físico (torre de luz,
brazo móvil, cinta transportadora,…). Un dispositivo DPWS aloja sus
propios servicios, que pueden ser invocados desde fuera.
• Servicios alojados: Los Servicios propios de cada Dispositivo. Cada
Dispositivo puede alojar uno o varios de estos servicios.
• Mensaje: Modo en el que los Dispositivos se comunican entre sí.

En la siguiente figura se muestran la arquitectura DPWS de un dispositivo

(izquierda) y el conjunto de protocolos utilizados (derecha):

Figura 1. Arquitectura DPWS

2
 2. Funcionamiento

El término importante para comprender el funcionamiento de DPWS es el del

descubrimiento, o Discovery.

Cada Dispositivo anuncia su presencia a los demás Dispositivos dentro de una

red mediante un mensaje de bienvenida (Hello Message), y anuncia su salida
mediante otro mensaje de despedida (Bye Message).

Estos mensajes se envían vía multicast por la red, de manera que todos los
Dispositivos conocen las llegadas y salidas de otros Dispositivos.

Por otro lado, un Dispositivo es capaz de hacer una búsqueda por la red para
encontrar otros Dispositivos disponibles [2]. Existen dos técnicas para ello, el
Probing y el Resolving:

• Probing: En este caso, no buscamos un Dispositivo concreto, sino alguno

que disponga de algún tipo de Servicio que queramos encontrar.
• Resolving: Muy utilizado en los WS, funciona de manera parecida, pero
en este caso conocemos el destino (endpoint) del Dispositivo que
queremos encontrar.

Para evitar una saturación de la red, solamente los Dispositivos toman parte de
este proceso de Discovery, dejando fuera a los Servicios presentados.

Todos los Dispositivos son capaces de describirse a sí mismos. De esta manera,

cuando uno de ellos recibe un Get Message, un tipo de mensaje WS-Transfer
que solicita una descripción, los Dispositivos responden con:

− Modelo de dispositivo (Nombre, Fabricante, …)

− Descripción de sí mismos (Firmware, Serial, Version,…)
− Servicios presentados que dispone (enumera sus destinos, los tipos, sus
funciones,…)

3
Cuando el solicitante conozca esta información, también tiene la posibilidad de
conseguir más datos sobre los Servicios presentados de cada Dispositivo. Esto se
hace mediante el envío de un mensaje parecido al anterior, esta vez, un
GetMetadata Message.

La respuesta a esta solicitud contiene esta información:

− La funcionalidad específica de ese servicio: Contiene todas las acciones

que se pueden invocar y el tipo de respuesta que se recibe.
− Información adicional: Políticas de uso, referencias, …

Los Servicios presentados pueden generar eventos a los que los clientes se
pueden suscribir. Aunque el cliente se suscriba a todos los eventos, puede
especificar qué clase de información desea recibir, mediante el uso de una
especie de filtros.

El cliente se suscribe a los eventos por un determinado tiempo, y la suscripción

puede ser renovada en cualquier momento.

Siempre que se habla de redes y compartición de datos, tenemos que tener en

cuenta un punto vital, el de la seguridad. Actualmente, DPWS solamente
recomienda usar algún método de seguridad, pero no lo incluye como
obligatorio en la especificación. La aplicación o no de estos métodos debe ser
considerada específicamente para cada caso.

En entornos pequeños en los que no se corren peligros, usar estos métodos

puede provocar malos resultados, ya que reducen la interoperabilidad; En
entornos mayores, su aplicación debería ser, al menos, estudiada.

Esto es lo que recomienda la especificación:

− Firma: como prueba de autenticidad a la gira de enviar mensajes.

− Canal Seguro: como vía de comunicación entre Dispositivos (TLS/SSL).
− Certificados: que verifican la autenticidad de cada Dispositivo.

Para ver más claramente el funcionamiento de DPWS, a continuación se va a

mostrar un ejemplo en el que todos los puntos antes descritos se observan de
manera práctica y más fácil de comprender.

4
 Se trata de una oficina, con decenas de computadoras conectadas a la misma
red. Un trabajador quiere imprimir una fotografía, por lo cual debe buscar una
impresora en su red que tenga capacidad de imprimir fotografías a color.

En este caso, tenemos que:

• Cliente
Trabajador que quiere imprimir.

• Dispositivo
La impresora.
• Servicio alojado
Servicio que imprime una fotografía a color.

Por ello, el trabajador necesita encontrar una impresora que disponga del
servicio que permite imprimir una fotografía.

Imprimir fotos

Trabajador Impresora

“Probe”

“Probe Match”

“Get”

Metadata

“GetMetadata”

Metadata

Comenzar operación

Operación inicializada

Suscribirse

Respuesta a suscripción

Imprimir fotografía

Imprimir fotografía aceptado

Impresión finalizada

Figura 2. Fases de la operación

5
Pasos:

1. “Probe”: Para encontrar una impresora, el cliente envía un mensaje de

Probing a través de Multicast vía UDP. En el probe se muestra que el
cliente busca un servicio que le permita imprimir una fotografía.

2. “Probe Match”: El Dispositivo recibe el mensaje “Probe” enviado por

Multicast. Como este Dispositivo contiene un servicio que permite
imprimir fotografías, responde a la petición con un mensaje “Probe
Match” que incluye información sobre su ubicación, seguridad,…

3. “Get”: Para saber más sobre el Dispositivo que le ha respondido y sus

Servicios presentados, el cliente envía un mensaje “Get” directamente al
Dispositivo.

4. Metadata: El Dispositivo responde con su metadata, incluyendo

información sobre el fabricante, versión, nombre, Servicios presentados,

5. “GetMetadata”: Para conocer más sobre el propio servicio de impresión

de fotografías, el cliente decide enviar este mensaje, en este caso,
directamente al Servicio presentado.

6. Metadata: El Servicio responde con información sobre el tipo de acciones

que soporta (imprimir a color, imprimir en alta resolución,…).

7. Comenzar operación: El cliente avisa al servicio de que la operación de

imprimir la foto va a dar comienzo.

8. Operación inicializada: El Dispositivo responde con un mensaje indicando

que la operación ha dado comienzo.

9. Suscribirse: El cliente se suscribe a los eventos (notificaciones) que pueda

enviar el servicio, como por ejemplo, final de impresión, impresión
errónea, etc.

6
 10. Respuesta a suscripción: El servicio de impresión comunica al cliente que
la suscripción se ha realizado.

11. Imprimir fotografía: El cliente envía la orden de imprimir la fotografía,

enviada como un fichero adjunto en el mensaje.

12. Imprimir fotografía aceptado: El servicio comunica al cliente que la

acción ha sido aceptada y que el proceso ya ha dado comienzo.

13. Impresión finalizada: Se trata de un evento enviado por el servicio al

suscriptor, el cliente, una vez finalizado el trabajo de impresión.

Como se puede observar, una operación tan sencilla como imprimir una
fotografía requiere una gran cantidad de mensajes entre una y otra parte; En
total, se necesitan 13 mensajes que, a su vez, representan 5 fases:

I. Descubrimiento
Los pasos 1 y 2 corresponden a la fase de “descubrimiento” (discovery)
por parte del cliente de los Dispositivos que pueden serle útiles.

II. Descripción
Los mensajes del 3 al 6 corresponden a la fase de descripción del
Dispositivo y los Servicios presentados de éste. No es una fase
obligatoria, sino opcional.

III. Control
Los mensajes 7 y 8 forman parte de la fase de control, donde el cliente y
el servicio se comunican entre ellos para asegurarse que el trabajo se
lleve a cabo.

IV. Envío de datos

En el mensaje 11 el cliente envía un mensaje adjuntando una fotografía a
color, siendo aceptada por el servicio al responder afirmativamente en el
siguiente mensaje.

V. Envío de eventos
En los mensajes 9 y 10 se realiza la suscripción por parte del cliente. El
servicio, en este caso, solamente envía un evento o notificación al

7
 cliente, el último mensaje. El módulo encargado de gestionar los eventos
dentro de DPWS es el WS-Eventing.

Por naturaleza, DPWS adopta un patrón de mensajería de tipo

Publicador/Suscriptor.

En este patrón, cada vez que el elemento “publicador” experimente algún

cambio de estado, lo notificará a través de eventos a todos los suscriptores.

Los suscriptores, por su parte, pueden decidir qué tipo de notificaciones desean
recibir y qué tipo de notificaciones prefieren pasar por alto.

8
 3. Estado del arte
Motivación

DPWS fue desarrollado para que los dispositivos y elementos de recursos

reducidos fuesen capaces de implementar funcionalidades de servicios web.
El proyecto DPWS lo comenzó Microsoft junto con algunas compañías
fabricantes de impresoras.

Devices Profile for Web Services es, por naturaleza, una arquitectura SOA. Estas
siglas corresponden a Service Oriented Architecture, un concepto de
arquitectura software que define la utilización de servicios para dar soporte a
los requisitos de negocio [3].

DPWS no es el primer SOA que tiene como objetivo la comunicación entre

dispositivos. Tecnologías como Open Service Gateway Initiative (OSGi), Home
Audio/Video Interoperability (HAVi), Java Intelligent Network Infrastructure
(JINI) y Universal Plug and Play (UPnP) son de similar naturaleza.

La especificación OSGi propone una arquitectura montada sobre una JVM (Java
Virtual Machine) que permita la instalación, actualización y eliminación de
módulos. OSGi es en esencia un SOA montado en una JVM, y supone la
respuesta en plataforma Java a la programación modular [4].

HAVi es una iniciativa de algunos de los fabricantes más importantes de equipos

de entretenimiento, que busca crear un estándar que consiga la
interoperabilidad entre diferentes elementos de diferentes marcas.
Casadomo.com

JINI es una tecnología desarrollada por SUN para comunicación espontánea

entre servicios y recursos basados en tecnología JAVA.

Por último, UPnP es una arquitectura software abierta y distribuida que de

forma independiente al fabricante, sistema operativo,… permite el intercambio
de datos entre dispositivos conectados a una red [5].

9
La gran ventaja de DPWS comparada con estas otras tecnologías también
basadas en SOA es la estrecha relación con los servicios web; Esto implica una
gran aceptación por parte los desarrolladores, además de independencia del
lenguaje de programación [6].

Hasta la fecha, las principales demostraciones del uso de DPWS se han dado en
el ámbito de los aparatos electrónicos utilizados en el hogar.
[msnbc.msn.com…] La iniciativa Windows Rally está enfocada en conectar los
electrodomésticos con el ordenador personal, por ejemplo [7].

La utilización de DPWS en otros ámbitos, sobre todo en el ámbito de la

automatización industrial, ha seguido un ritmo mucho más pausado. La
aplicación de DPWS en este campo es muy diferente a la aplicación en los
electrodomésticos y envuelve a diferentes grupos de usuarios y servicios.

Mientras que en el ámbito del hogar la mayoría de comunicaciones se realizan

de manera simple, horizontal, entre dispositivo y dispositivo, dentro del mundo
industrial las comunicaciones entre dispositivos son más complejas y críticas.

En el ámbito industrial, los consumidores de dispositivos que implantan DPWS

serán, en su mayoría, sistemas distribuidos que son parte de una aplicación
basada en SOA de mayor nivel que ellos. Esta ramificación de los dispositivos
conlleva una mayor complejidad a la hora de interactuar unos con otros, de
comunicarse. Por ello, la arquitectura DPWS será más compleja que en el caso
de los electrodomésticos [8].

Para comprender mejor el uso de estas tecnologías en el mundo de la industria

es necesario entender el contexto actual. Las empresas de manufactura se están
centrando en aumentar la variedad y calidad de sus productos, lo que conlleva
una mayor complejidad en el proceso de creación de los mismos.

La agilidad y flexibilidad se convierten en dos términos vitales en el proceso de

manufactura: las empresas deben ser capaces de gestionar de manera eficiente
y efectiva cualquier cambio o modificación que se puedan encontrar en la
fabricación de sus productos.

Por ello, la implantación de SOA en el mundo de la empresa ha resultado vital,

ya que gracias a esta tecnología es posible la compartición de información entre
todos los elementos de la empresa: desde los elementos más simples de la
fábrica hasta los niveles superiores de gestión de la empresa, por ejemplo, los
Enterprise Resource Planning, o ERP.

10
DPWS en la empresa

La utilización de SOA en la fabricación automatizada está siendo actualmente

estudiada a través de varios proyectos, entre ellos, SOCRATES y SODA.

Estos estudios buscan diseñar, ejecutar y gestionar una plataforma para la

nueva generación de fábricas automatizadas, intentando comprender la
repercusión que puede tener SOA a niveles bajos (dispositivos) y altos (ERP,…)
de la empresa.

Los estudios se centran en la creación de un modelo de fabricación en el que los

dispositivos anteriormente “ciegos” puedan disponer de tecnología DPWS para
comunicarse de manera tanto horizontal como vertical unos con otros.

El desarrollo de los servicios web a nivel de factoría contiene el potencial de

poder conseguir todas las ventajas de la computación distribuida.
Un sistema distribuido es aquel cuyos componentes hardware y software, que
están conectados a la red, se comunican mediante el paso de mensajes para el
logro de un objetivo.

Se deja a un lado la visión centralizada y se logran las siguientes ventajas [9]:

• Menores costes.
• Posibilidad de trabajar conjuntamente.
• Mayor confiabilidad, al estar distribuida la carga.
• Capacidad de crecimiento incremental.

En la industria de la automoción, una cadena de montaje está compuesta por un

número no demasiado alto de elementos de control comunes. Se calcula que el
80% del equipo encargado del control contienen tecnología común o muy
parecida, y se podría ahorrar mucho esfuerzo si la funcionalidad de control
pudiese ser encapsulada a nivel de dispositivo, a más bajo nivel.

Como se ha comentado antes, el sector de la automoción también busca nuevas

metas a la hora de fabricar sus productos, lo que conlleva una mayor
especialización en su ejercicio de automatización: mayor variedad y calidad,
menores costes de dinero y tiempo.

A parte de la fabricación en sí, el ciclo de vida de este tipo de productos

requiere una compleja interacción entre socios geográficamente alejados que

11
forman parte del proceso de ingeniería: proveedores de herramientas
automatizadas, proveedores de herramientas de control, fabricantes de
herramientas mecánicas, ingenieros de control, y un largo etcétera.

Para todo esto debe existir una manera de compartir la información de una
manera sencilla, no sólo entre los miembros de diferentes lugares del mundo,
sino también entre los propios dispositivos embebidos.

Estos últimos deben poder reconfigurarse, conseguir adaptarse a los cambios

para poder ser reutilizados; Además, son clave a la hora de ofrecer un
diagnostico objetivo del proceso de producción: gracias a DPWS, son capaces de
enviar información sobre su funcionamiento, una información que un sistema
más complejo recoge y estudia, consiguiendo un diagnóstico preciso sobre el
rendimiento del sistema completo. Gracias a esto, se pueden observar errores
en el proceso de fabricación, observar los puntos críticos o mejorables, y ofrecer
un mantenimiento más adecuado.

Hasta el momento, los sistemas de control de una empresa han sido siempre
fragmentados, complicados de manejar y muy difíciles de cambiar o
simplemente actualizar.

Los clientes solicitan poder conectar todos sus subsistemas y equipamiento de

control en el mismo sistema de información. Se necesita un sistema distribuido
capaz de integrar una gran variedad de dispositivos diferentes dentro de una
red en la que pueden comunicarse entre ellos, y es ahí donde nacen soluciones
como DPWS.

Un ejemplo del uso de los servicios web en el sector de la fabricación es una

plataforma instalada por Ford para la fabricación de sus coches.

Los mecanismos de esta plataforma presentan problemas de control típicos de

este tipo de maquinaria (pequeños dispositivos, elementos sin recursos para
informar, funcionalidades básicas,…). La máquina está separada en cuatro
secciones, cada una de las cuales está gestionada por un FTB (Field Terminal
Block), que controla las operaciones de entrada/salida de la sección.

Para el control de las entradas y salidas, se implementó un interfaz de servicios

web en cada FTB, conectados mediante Ethernet.

Para gestionar esta arquitectura se implementó otro FTB. Este gestor es el

punto por el que los servicios son invocados (en un determinado orden), de
12
manera que se asegura un control específico en todos los elementos de la
plataforma.

En la siguiente figura [10] se muestran todos los dispositivos que conforman la

plataforma:

Figura 3. Plataforma de Ford y sus controladores

La plataforma se compone de una serie de dispositivos mecánicos y

automatizados, cada uno con su función. En el mundo de los servicios web, cada
uno de estos dispositivos pasa a ser un Servicio.

De esta manera, una cinta transportadora, un elevador o un brazo móvil, pasan

a ser a ojos de los ordenadores unos Dispositivos a los que se les puede invocar
unas acciones: elevar una pieza, moverla, etc.

13
La jerarquía presentada en este ejemplo, con un gestor encargado de gestionar
los servicios, es un ejemplo valido de arquitectura SOA para la automatización
industrial. Una de sus mayores ventajas es que toda la gestión de los servicios se
encuentra encapsulada en una sola máquina, por lo que cualquier cambio o
actualización no requerirá mucho esfuerzo. Además, las máquinas no se
comunican directamente entre sí, por lo que fuera de tiempo de ejecución
todos los trabajos relacionados con una máquina serían invisibles a las demás;
El cambio de una máquina, por ejemplo, requeriría menor tiempo y esfuerzo en
operaciones software.

Sin embargo, se consume más tiempo en el intercambio de mensajes al no

disponer de una comunicación dispositivo-dispositivo; Todos los mensajes
tienen que pasar primero por el gestor, que, por otra parte, puede estar
sometido a demasiada sobrecarga en determinados momentos.

La arquitectura de comunicación directa entre dispositivos debe ser considerada

y estudiada, ya que no siempre es necesaria; Por ejemplo, en entornos críticos
donde la información debe transmitirse en tiempo real (sensores, maquinaria de
precisión,…) este tipo de comunicaciones adquieren un mayor sentido; en
entornos donde el tiempo de retardo no se considera tan importante, una
solución más económica como una gestión de servicios centralizada es una
solución más adecuada.

Desde el punto de vista que ofrece DPWS, la arquitectura presentada en la

plataforma de la figura 3 puede ser mejorada mediante un sistema distribuido.
Para poder conseguir un modelo de servicios distribuido sin la participación de
un gestor central, los Servicios (cinta transportadora,..) deben ser capaces de
usar su propia lógica embebida para configurar y ejecutar las operaciones de la
máquina que representan.

A este planteamiento se le denomina coreografía de servicios [11]. Para

optimizar el tiempo de ejecución usando la coreografía, se definen tres fases en
la ejecución de la máquina:

• Tiempo de configuración
• Tiempo de ejecución
• Tiempo de evaluación

14
 Figura 4. Fases de la coreografía

En el tiempo de configuración se despliegan los servicios y se configura la lógica

de ejecución de los mismos.

El tiempo de ejecución es el tiempo que se da para que las máquinas y sus

servicios ejecuten las operaciones.

Por último, en el tiempo de evaluación se realiza un diagnóstico de la operación

para comprobar errores y reconfigurar la máquina (si fuese necesario) para un
nuevo ciclo.

Esta arquitectura de tres fases asegura que se consigue el máximo potencial de

ejecución del conjunto de máquinas en la plataforma. Gracias a la
implementación de DPWS, los servicios pueden comunicarse entre sí en tiempo
de ejecución, pudiendo reaccionar a cambios que se den en el proceso (cambios
en valores de sensores, ...) sin necesitar un gestor que actúe como
intermediario, reduciendo los tiempos de retardo.

El modelo DPWS convierte a las máquinas en servicios que pueden ser

agrupados de manera eficiente en base a su tipo de coreografía.

El objetivo de este nuevo planteamiento es el conseguir que la maquinaria y los

dispositivos que la componen puedan incluirse en una gestión de mayor nivel,
pasando a formar parte de un SOA que engloba una visión general de la
empresa.

15
Proyectos

Entre los proyectos de investigación que se están desarrollando sobre DPWS, los
proyectos SOCRADES, SODA y SIRENA son los más relevantes.

El proyecto SOCRADES busca diseñar, desarrollar y gestionar una plataforma

para el control de sistemas de automatización industrial. El objetivo es poder
utilizar los servicios web como medio de comunicación entre los dispositivos de
una cadena de trabajo [11].

SOCRADES presentó sus resultados finales en el simposio de Itea en Madrid, en

octubre de 2009.

Figura 5. Ejemplo aplicación SOCRADES

El proyecto SODA (Service Oriented Device & Delivery Architecture) tiene como
objetivo crear una infraestructura construida como un ecosistema completo,
escalable para comunicaciones de alto nivel entre dispositivos. Esta
infraestructura se basa en la arquitectura SOA.

SODA mantiene una línea similar al proyecto SOCRADES, pero en su caso abarca
unos ámbitos más extensos que el de simplemente la automatización industrial,
como la domótica, telecomunicaciones, etcétera.

16
 Figura 6. Arquitectura SODA [12]

El proyecto SIRENA fue un trabajo de investigación europeo desarrollado entre

2003 y 2005 que tenía como objetivo implementar una infraestructura de
servicios para aplicaciones embebidas en tiempo real (Service Infrastructure for
Real Time Embedded Network Applications).

Este proyecto fue el pionero en estudiar el empleo del paradigma SOA para las
comunicaciones entre dispositivos de recursos reducidos, o de bajo nivel.

Como curiosidad, el proyecto SIRENA consiguió el galardón ‘ITEA Achievement

Awards’ en el año 2006, por su contribución al programa ITEA [13] de
investigación.

Los resultados obtenidos al finalizar el proyecto sirvieron para comenzar los

proyectos SODA y SOCRADES, siento estos dos ramificaciones de SIRENA.

17
Aplicaciones e Implementaciones

Entre las aplicaciones relacionadas a DPWS, una de las más populares y

extendidas es la de Windows Rally.

Se trata de un conjunto de tecnologías que integran DPWS y cuyo objetivo es el

de simplificar la instalación y el mantenimiento de dispositivos de bajos recursos
conectados a una red.

Windows Rally [14] se compone de los siguientes elementos:

• LLTD: Siglas del protocolo Link Layer Topology Discovery, encargado de

que las aplicaciones puedan ser capaces de buscar dispositivos y
determinar la topología de red.

• qWAVE: Un API preconfigurado para datos multimedia dependientes del

tiempo, como pueden ser los streamings.

• Windows Connect Now: Conjunto de tecnologías orientadas a simplificar

la configuración de dispositivos inalámbricos.

• DPWS

• Function Discovery: API cuya función es servir como una capa abstracta
entre las aplicaciones y los dispositivos, permitiendo que las primeras
puedan encontrar dispositivos utilizando como parámetro de búsqueda
la función del dispositivo.

• Plug and Play: Protocolo basado en IP que permite a un dispositivo

unirse a una red, obtener una IP y descubrir la presencia y características
de otros dispositivos de la misma red.

18
 Figura 7.Arquitectura Windows Rally

DPWS es una tecnología cada vez más extendida y por ello se comienza a utilizar
en un mayor número de implementaciones.

Existen toolkits que permiten el desarrollo de software orientado a servicios,

como por ejemplo, SOA4D (Service Oriented Architecture for Devices) o WS4D
(Web Services for Devices).

En referencia a WS4D, éste contiene un framework llamado JMEDS [15]. Basado

en Java, permite implementar y ejecutar Servicios, Dispositivos y Clientes DPWS.
Se trata de un producto con licencia open Source, y su versión más actual es la
JMEDS v2.0.

19
Conclusiones

DPWS constituye la mayor promesa en el marco de comunicaciones entre

dispositivos o componentes de bajo nivel. Mantiene la filosofía de los SOA y la
conjuga con la practicidad de los servicios web. Esta es precisamente la gran
ventaja de DPWS comparado con demás especificaciones similares.

Gracias su relación con los servicios web, DPWS es independiente de lenguaje

de programación y de plataforma. Los dispositivos implementados con DPWS
proveen servicios a cualquier aplicación corriendo en cualquier plataforma y
escrita en cualquier lenguaje de programación.

Tras los ensayos en diferentes plataformas, DPWS ha demostrado ser capaz de

cambiar o añadir componentes de manera rápida y efectiva, gracias a su diseño
modular basado en la arquitectura web.

Aun así, la tecnología debe mejorar en ciertos aspectos antes de convertirse en

un estándar.

Uno de sus desventajas es que la descripción de los dispositivos sólo es

accesible en tiempo de ejecución, y no en las otras dos fases. Por otro lado,
necesitaría un template para creación de dispositivos; Esto facilitaría el trabajo
de los desarrolladores a la hora de definir los servicios, por un lado, y se lograría
que las búsquedas de dispositivos fuesen mucho más rápidas y eficaces, por
otro.

En resumen, se trata de una tecnología en alza, interesante sobre todo para el

campo de la automatización industrial, y que gracias a su potencial está
consiguiendo el apoyo de una gran cantidad de profesionales.

Por ello, una vez se consigan limar sus defectos y demuestre ser una tecnología
práctica, eficiente y rentable, DPWS tendrá muchas posibilidades de
convertirse en un estándar para el ámbito de la automatización industrial.

20
 4. Anexos

a. Tamaño de mensajes DPWS

Figura 8 .Tamaño de mensajes DPWS para los formatos XML, EXI, FI y HTML
[17]

21
b. Ejemplo de simulación y validación: Milagaia

La simulación es uno de los campos en los que DPWS ha sido utilizado con el fin
de validar nuevos sistemas de producción.

En un proyecto llevado a cabo por el ingeniero Rui Milagaia [18] en 2008, se

desarrolló una capa intermedia basada en DPWS para comunicar los agentes
software con dispositivos de menor nivel (Hardware, bases de datos,…).

La demo consiste en una cinta transportadora que enlaza cuatro diferentes

estaciones de trabajo, cada una de las cuales con una función específica dentro
del plan de producción.

Este sistema “inteligente” es capaz de adaptarse dinámicamente a las posibles

eventualidades (embotellamientos, fallos puntuales en estaciones,…), además
de poder modificar el proceso de producción en tiempo de ejecución.

Para demostrar la validez del concepto se desarrolló una demo consistente en

un modelo 3D de una planta de producción, una serie de agentes controladores
del sistema, herramientas de configuración, producción y comunicación y una
base de datos, comunicados todos entre sí mediante una interfaz DPWS. [19]

Figura 9 Esquema DPWS de Milagaia

22
Este organigrama demuestra la validez de DPWS a la hora de simular sistemas
de producción: cada elemento que forma parte del sistema, al estar modelados
por una interfaz DPWS, el cambio de un dispositivo real por uno virtual se
podría realizar de manera automática.

Esto permitiría la simulación de un sistema que contiene dispositivos reales y

virtuales. Por ejemplo, si se quiere comprobar el funcionamiento de un nuevo
dispositivo (un brazo mecánico, una cinta,…) dentro de un sistema ya creado, se
podría simular la implantación del dispositivo de manera virtual, sin tener que
“montarlo” de manera física. Esto supondría un cuantioso ahorro de tiempo y
de posibles errores en la producción, o lo que es lo mismo, un ahorro de costes.

23
c. Aplicación JAVA para control de un tanque de agua

La aplicación desarrollada es un ejemplo muy simple del funcionamiento de

DPWS. El programa simula un tanque provisto de un sensor de temperatura que
oferta un servicio en el cual envía notificaciones periódicas (cada 5 segundos)
sobre la temperatura del agua alojada en el tanque.

Por otro lado, devuelve el tiempo local y el remoto. El tiempo local se

corresponde al momento en el que el cliente recibe la información del servidor.
El tiempo remoto es el momento en el que el servidor envía la notificación. De
esta manera se conoce el retardo del mensaje, algo imprescindible en entornos
críticos.

El programa consta de los siguientes elementos:

Figura 10. Ficheros de la aplicación Java

• Cliente.java
La clase Cliente es la encargada de buscar el servicio que le devuelve la
temperatura del agua. Esta clase simboliza al operador/máquina que desea
conocer el estado del tanque.
Cuando encuentra el servicio, se suscribe a él y recibe las notificaciones.
• Reloj.java
Una clase sencilla que devuelve el tiempo actual en milisegundos.
• Servidor.java
La clase servidora es la encargada de publicar el evento (temperatura del
agua) cada 5 segundos, haya suscriptores o no. La clase servidor simboliza al
controlador del tanque de agua, que recoge los datos de un sensor
introducido en el agua y lo envía.

24
• Ventana.java
Código SWING y AWT para mostrar una ventana. No relacionado con DPWS.

• DPWS.properties
Este documento define las propiedades de todos los elementos que toman
parte en la operación: dispositivos, servicios, direccionamiento, metadata,…

Existen dos maneras de ejecutar la aplicación:

− Ejecutando el código fuente desde un IDE Java (Eclipse, NetBeans,…).

− Lanzando el JAR ejecutable.

Figura 11. Vista de la aplicación y la consola; Ejecución del código fuente desde Eclipse

25
 5. Referencias

[1] Estándar DPWS 1.1, OASIS http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdd-dpws-1.1-

spec-os.pdf

[2] Blog de Ondrej Piálek, “Introduction to DPWS”, noviembre de 2009.

[3] Artículo de Jeffrey Schlimmer, “A Technical Introduction to the Devices Profile for Web
Services”, mayo de 2004.

[4]Wikipedia
es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios#Dise.C3.B1o_y_desarrollo_de_SOA

[5] Blog de Justo Aguilar, “Qué es DPWS y para qué sirve”, agosto de 2009

[6] Wikipedia, es.wikipedia.org/wiki/Universal_Plug_and_Play

[7] Conferencia , Elmar Zeeb, Andreas Bobek, Hendrik Bohn, Frank Golatowski, “Lessons
learned from implementing Devices Profile for Web Services”, Cairns, febrero de 2007.

[8] Microsoft, msdn.microsoft.com/en-us/windows/hardware/gg463018

[9] Artículo, Thomas Kirkham, Robert Harrison, “SOA MIDDLEWARE AND AUTOMATION:
Services, Applications and Architectures”.

[10]Página web, monografías, www.monografias.com/trabajos16/sistemas-distribuidos/

[11] Congreso, Navjot Kaur, Robert Harrison, “Web Services-Based Control Devices for Future
Generation Distributed Automation Systems”, World Congress of Engineering, 30 Junio-2 Julio
2010, Londres.

[12] Página web, SOCRADES, www.socrades.com

[13] SODA, www.ims.es/pdf/eng/downloads/publications/SODA_profile_oct-06.pdf

[14] Página web, ITEA, www.itea2.org

[15] Página web, Windows Rally, msdn.microsoft.com/en-us/windows/hardware/gg463018

[16] Página web, JMEDS,ws4d.e-technik.uni-rostock.de/jmeds/

[17]Artículo, Guido Moritz, Dirk Timmermann, “Encoding and Compression for the Devices
Profile for Web Services”, 2010.

[18] Rui Milagaia: http://pt.linkedin.com/in/milagaia

[19] Artículo, Gonçalo Candido, José Barata, “SOA in reconfigurable supply chains: A research
roadmap”, Octubre de 2008.

26