TRABAJO FIN DE MÁSTER Máster en Ingeniería en Informática

Integración de procesos industriales mediante patrones SOA y tecnología RESTful

Autor: José Vicente Espí Beltrán

Director:

Virgilio Gilart Iglesias Daniel Ruiz Fernández

Septiembre de 2013

2

Tabla de contenido

1. Introducción. .......................................................................................................... 3

2. Evaluación de arquitecturas, tecnologías y lenguajes. ........................................... 4

2.1. SOA. ............................................................................................................... 4

2.2. Protocolos de comunicaciones. ...................................................................... 5

2.3. Servidores BPMS. .......................................................................................... 6

2.4. Lenguajes de orquestación. ............................................................................ 8

2.5. Lenguaje para el desarrollo del middleware. ................................................... 9

2.6. Alternativas para la integración de servicios RESTful en BPMS. .................. 11

2.7. Trabajos científicos relacionados. ................................................................. 12

3. Especificación. ..................................................................................................... 13

3.1. Descripción de los procesos industriales a modelar. ..................................... 13

3.2. Especificación de requisitos funcionales del middleware. ............................. 13

3.3. Requisitos del software de composición de servicios (BPMS). ..................... 14

4. Arquitectura. ........................................................................................................ 15

5. Diseño. ................................................................................................................ 18

5.1. Metodología. ................................................................................................. 18

5.2. Diseño del simulador de dispositivos. ........................................................... 20

5.3. Middleware: diseño del programa. ................................................................ 20

5.4. Middleware: configuración. ........................................................................... 21

5.5. Middleware: estructuras de datos. ................................................................ 25

5.6. Middleware: análisis funcional. ..................................................................... 26

5.7. Middleware: protocolo de comunicaciones.................................................... 28

5.8. Diseño del BPMS.......................................................................................... 31

6. Implementación y pruebas. .................................................................................. 36

6.1. Entorno de pruebas. ......................................................................................... 36

6.2. Resultados obtenidos. ...................................................................................... 37

6.3. Análisis de los resultados. ................................................................................ 41

7. Recursos necesarios. .......................................................................................... 43

8. Plan de implantación/costes. ............................................................................... 44

9. Conclusiones y trabajos futuros. .......................................................................... 46

10. Referencias. ..................................................................................................... 47

3

1. Introducción.

Los patrones de diseño basados en SOA (Service Oriented Architecture) que encontramos habitualmente son aplicados generalmente a Sistemas de Información clásicos, esto es, donde los elementos que los componen son los propios de las TI. Es el ámbito más común de las tecnologías de la información, y suele habitar en las organizaciones empresariales de cierto tamaño. En este escenario, se modelan procesos de negocio donde intervienen aplicaciones informáticas y personas en base a una lógica alineada con el negocio. El enfoque BPM (Business Process Management) surge ante la necesidad de las organizaciones de poder reaccionar ante los cambios que se producen en sus objetivos estratégicos. Mediante el empleo de patrones SOA, permite modelar los procesos de negocio alineando las tecnologías de información a estos, y de esta manera dar respuesta a las necesidades de los objetivos operacionales. El problema surge cuando una organización de base manufacturera pretende modelar sus procesos industriales junto al resto de procesos de la empresa; en ese caso se topará con dificultades al no ser la tecnología industrial fácilmente integrable dentro de un patrón SOA. Partiendo de esta experiencia en integración TI, se plantea realizar la integración de procesos industriales a través de la arquitectura SOA. De esta manera se abordará un patrón de diseño SOA, mediante el empleo de tecnologías TI con el propósito de incorporar e integrar sistemas de información industriales. Se pretende pues, mostrar la viabilidad y eficiencia de SOA en entornos para los que inicialmente no estaba concebido, en base a unos requisitos diferentes. Para ello se desarrollará previamente un middleware que permitirá acoplar los elementos industriales a SOA, para a continuación diseñar varios procesos industriales mediante una herramienta BPMS (BPM Server o BPM Suite).

El dominio industrial de aplicación que se aborda en el proyecto tiene unos requisitos de tiempos de respuesta muy cortos, en muchos casos próximos al tiempo real. Además, el equipamiento a utilizar para el middleware suele ser robusto y simple, con una capacidad de cómputo reducida, por lo que para lograr los tiempos de respuesta necesarios se ha elegido para las comunicaciones el empleo de servicios RESTful en lugar de los tradicionales SOAP.

4

2. Evaluación de arquitecturas, tecnologías y lenguajes.

En este apartado se pretende describir las arquitecturas, tecnologías y lenguajes actuales relacionados con el proyecto. A consecuencia de su análisis se justificará su empleo en cada caso. Este apartado debe ser leído como un análisis del arte de los componentes implicados en el proyecto. Los trabajos existentes relacionados o similares se expondrán más adelante en el epígrafe 9.

2.1. SOA.

SOA es un patrón de diseño del software donde los componentes del sistema se modularizan en servicios. Estos servicios son unidades autocontenidas de lógica de negocio, que, mediante la interacción con otros servicios componen el conjunto de la lógica del sistema.

Para llevar a cabo un diseño basado en SOA se debe aplicar una metodología orientada al servicio. Este método requiere que cada pieza del sistema sea creada conforme una serie de principios, que según Thomas Erl [1] son:

• Contrato de servicio estándar. Los servicios implementados serán conformes con el diseño estándar establecido.

• Servicios débilmente acoplados. Los servicios mantienen una relación de mínima o nula dependencia. Solo se requiere que tengan conocimiento el uno del otro.

• Abstracción. Se ocultan los detalles de la lógica interna del servicio, conociéndose solamente la información esencial de los contratos de servicio.

• Reusabilidad. Los servicios contienen y expresan lógica agnóstica, siempre tendentes a la creación de recursos reutilizables.

• Autonomía. Los servicios deben tener control absoluto sobre la lógica que encapsulan.

• Servicios sin estado. Reducen el consumo de recursos posponiendo la gestión de la información de estado.

• Descubrimiento. Los servicios contienen metadatos adicionales que permiten su descubrimiento e interpretación.

• Composición. Los servicios pueden ser combinados independientemente de la complejidad y del tamaño.

Mediante la aplicación de estos ocho puntos, y escogiendo una tecnología que se adapte correctamente a estos principios podremos crear una solución que se considere orientada al servicio.

Destacamos a continuación las cuatro características o puntos fuertes de SOA:

• Orientación al negocio. Consiste en alinear la arquitectura tecnológica con la arquitectura del negocio. De esta forma la tecnología se adapta rápidamente a los cambios que puede sufrir el negocio.

5

• Independiente del proveedor. Esta eliminación de dependencias facilita la integración entre sistemas.

• Núcleo de la empresa. El ámbito de la arquitectura debe ser los principales espacios de los sistemas de empresa para evitar las aplicaciones aisladas.

• Orientación a la composición. Esta arquitectura favorece la agregación y combinación de servicios, permitiendo un rápido ensamblado de composición de servicios, acorde con las necesidades de la empresa.

2.2. Protocolos de comunicaciones.

2.2.1. SOAP.

SOAP (Simple Object Access Protocol) es el protocolo de comunicaciones utilizado en los servicios web y el más utilizado en la arquitectura SOA. Define cómo dos objetos pueden comunicarse mediante el intercambio de datos XML. Es independiente de la plataforma o lenguaje de programación, lo que permite interconectar objetos completamente diferentes. Está compuesto de múltiples especificaciones y extensiones que facilitan su procesamiento como son la seguridad, formato de entrega, procesamiento del mensaje, enrutamiento, etc. Asociado a SOAP suele presentarse WSDL (Web Services Description Language), que es un lenguaje de definición de servicios web disponibles. Es el equivalente a un directorio de servicios que describe la sintaxis de los mismos expresados en formato XML. SOAP tiene la gran ventaja de ser el estándar dominante junto a WSDL en la mayoría de BPMS, lo que lo convierte en el protocolo ideal en orquestación de procesos TI. Además se integra perfectamente con el lenguaje de orquestación BPEL, que se verá más adelante. También permite elegir el protocolo de transporte más adecuado, aunque en la práctica se emplea siempre HTTP. Como desventajas se plantean:

● Es totalmente dependiente del formato XML, lo que supone una sobrecarga de trabajo que supone su procesado.

● A XML se le debe añadir el procesado e interpretación de las especificaciones indicadas por el propio SOAP.

Por último indicar que SOAP está especialmente indicado para diseñar las comunicaciones bajo el esquema RPC, es decir, invocando la ejecución de funciones remotas.

2.2.2. REST.

A pesar de presentarse REST (Representational State Transfer) como alternativa a SOAP, no es exactamente un protocolo de comunicaciones, sino más bien una técnica de diseño de las comunicaciones en sistemas hypermedia distribuidos [2].

6

Habitualmente encontramos REST asociado al protocolo HTTP ampliamente utilizado en la World Wide Web. Como características fundamentales tiene:

● Empleo de las operaciones básicas de HTTP (GET, POST, PUT, DELETE,...) sobre recursos bien definidos en la URL.

● Como consecuencia de lo anterior se deduce que REST está orientado al acceso y manipulación de recursos, en contraposición del paradigma RPC de SOAP.

● Permite cualquier formato de mensaje en la transferencia de información. Aunque en sus inicios se utilizaba XML, en la actualidad está ganando terreno el empleo de JSON como formato más ligero y ágil a la hora de ser procesado.

Estas características descritas hacen de REST un método para comunicar servicios más eficiente y rápido que SOAP [3]. Visto de forma práctica, SOAP es en realidad REST + una capa de abstracción más que añadir en el envío y recepción de datos. Además, REST es mucho más sencillo de implementar, siendo más escalable que SOAP. La orientación hacia la manipulación de recursos lo hace también más atractivo frente a SOAP, ya que cuando accedemos a un dispositivo industrial en realidad estamos leyendo o escribiendo valores sobre una variable de un autómata. La lógica compleja en realidad se traslada al motor de orquestación, y este diseño permite obtener tiempos de respuesta bastante buenos, como se verá más adelante. Como desventaja se presenta el hecho de que no está debidamente soportado por la mayoría de las herramientas BPMS de manera estándar. Se acaba acudiendo a extensiones particulares de los motores de orquestación o encapsulados propios de REST sobre WSDL.

2.3. Servidores BPMS. Se describe a continuación las herramientas BPMS analizadas para el desarrollo del proyecto. Solamente se han tenido en consideración aquellas que son de código abierto o gratuitas.

2.3.1. Apache ODE / BPEL Designer.

El primer servidor BPMS que se analiza es Apache ODE. Se trata de un servidor J2EE que implementa un motor de orquestación de procesos basado en lenguaje BPEL. Este lenguaje es un estándar para escribir código BPMS, y desde el principio se planteó mantener como requisito del proyecto. Se puede emplear la herramienta BPEL Designer para realizar el modelado del proceso y generar código BPEL. Para el soporte para REST, ODE plantea dos posibilidades:

7

● Utilizar extensiones específicas de ODE para WSDL 1.1, que permiten encapsular los recursos dentro de la definición WSDL. Esta opción se probó pero no funcionó correctamente a la hora instanciar un proceso. Sí funcionaba para la invocación de servicios RESTful externos, mientras que la recepción fallaba.

● Emplear dos extensiones BPEL propuestas por ODE para invocar y exponer recursos vía REST. Esta solución parece más interesante, ya que simplifica la configuración de los servicios al prescindir del empleo de WSDL. Todavía no se encuentra disponible y no existe una fecha concreta de desarrollo de estas extensiones a BPEL.

Estos motivos expuestos provocaron que se descartara Apache ODE como motor de orquestación.

2.3.2. Intalio BPMS.

La Suite de Intalio para BPMS consta de un motor de orquestación, derivado del desarrollo de ODE y un IDE para el diseño y modelado. Está orientado a BPEL, con la característica fundamental de que permite modelar mediante la notación BPMN y traducir a BPEL. Tiene multiples endpoints que permiten conectar con otros sistemas como bases de datos, que lo aproximan a un ESB, aunque en esencia es un BPMS. Es una opción muy interesante a la hora de modela en BPM porque emplea los dos estándares principales para el modelado, BPMN y BPEL. Al igual que ocurría con ODE, el servidor corre sobre Apache Tomcat, lo que en principio podría ser un inconveniente al no ser la solución más eficiente. Acarrea los inconvenientes de integración con REST explicados para ODE, lo que lo imposibilita para el proyecto.

2.3.3. BonitaBPM.

BonitaBPM es un producto que proporciona un motor BPMS y un IDE para el diseño y modelado de los procesos de negocio. Implementa la notación BPMN, y es una buena opción cuando queremos orquestar servicios SOAP. Dispone además de multitud de conectores a otros sistemas, como bases de datos, CRM, ERP, etc. lo que lo acerca al mundo ESB. A la hora de evaluar el principal requisito, es decir, la posibilidad de recibir y enviar mensajes RESTful, no se aprecia un conector que directamente lo implemente fácilmente. Esto lo invalida como herramienta para el proyecto.

2.3.4. jBPM.

jBPM es la herramienta BPMS de la comunidad jBOSS. Corre por tanto en un servidor jBOSS, y como característica fundamental tiene la implementación de BPMN 2.0. El manejo del IDE de modelado no es muy intuitivo, y está bastante orientado al desarrollador Java, ya que requiere el empleo de bastante código (Java) para que se ejecute la orquestación de procesos.

8

En un primer estudio no se apreció ninguna integración fácil con REST, lo que lo descartaba como servidor de proceso para el proyecto.

2.3.5. JOpera.

El último BPMS probado se llama JOpera1, y ha sido desarrollada por la Universidad de Lugano (Suiza). Se trata de un herramienta de composición de servicios que ofrece una plataforma de ejecución y un IDE de diseño y composición. Tiene un lenguaje visual propio para el modelado, de manera que sin escribir código, y simplemente diseñando y configurando las actividades se puede orquestar servicios y modelar así procesos. Una de sus características clave es la integración con servicios RESTful [4] de manera directa, tanto a la hora de enviar como de recibir. Se añade un completo conjunto de interfaces de integración con otros sistemas y lenguajes habituales en un ESB, pudiendo vincular la ejecución de scripts Java, Javascript, Groovy, BPEL, XPath y conectividad con otros sistemas vía SMTP, SSH, SOAP, etc. Además el motor de ejecución tiene una interfaz de consola RESTful para monitorizar el estado y controlar la ejecución de instancias de proceso. Por la facilidad con la que se podía realizar la integración de servicios RESTful se optó finalmente por esta herramienta. Destacar además que el motor de ejecución corre sobre Jetty, lo que produce un rendimiento muy bueno [5] con un consumo de recursos (memoria, CPU) bastante contenidos.

2.4. Lenguajes de orquestación.

2.4.1. BPMN.

Business Process Modeling Notation no es estrictamente un lenguaje de orquestación, pero se menciona porque es bastante común encontrarlo en los BPMS. Se trata de un intento de estandarizar el proceso de modelado de los procesos de negocio en torno a una notación común que sea legible para desarrolladores y directivos no TI. Se definen un conjunto no muy extenso de elementos gráficos para representar el flujo que define el proceso. Consta de eventos, actividades, control de flujo, flujo de secuencia, flujo de mensaje, y otros elementos que permiten definir el modelado del proceso y hacerlo comprensible para cualquier persona involucrada en la gestión de la organización. BPMN no se limita a orquestar servicios web, sino que al ser genérico no se limita a ningún tipo de comunicación con componentes de otros sistemas. Esto lo hace también utilizable en herramientas ESB. Como inconveniente tiene que esta notación no es exportable a un formato de fichero que permite portarse entre herramientas BPMS diferentes. Esto plantea un problema de mantenimiento de una instalación, ya que el modelado realizado de un proceso vale 1 http://www.jopera.org

9

solo para la herramienta donde se haya realizado. Algunas herramientas de diseño como el IDE de Intalio permiten exportar a un lenguaje de orquestación como es BPEL.

2.4.2. BPEL.

Business Process Execution Language es uno de los lenguajes de composición de servicios web más utilizados hasta la fecha. Está basado en XML y pensado para el control centralizado de la invocación de servicios web, aportando además cierta lógica de negocio. Es por tanto un lenguaje de orquestación. Anteriormente se denominaba BPEL4WS y actualmente podemos encontrarlo como WS-BPEL. BPEL se apoya en XML para la sintaxis del lenguaje, pero también para el tratamiento de la información. Es compatible con XPath para la extracción de datos, y utiliza WSDL 1.1 para la definición de servicios web publicados e invocados. Esto es importante porque al no soportar la versión 2.0, dificulta en gran medida la adopción de REST como protocolo de comunicaciones. Al igual que ocurría con BPMN, cada herramienta BPMS compila el modelado realizado en BPEL a código de ejecución específico, generalmente Java, y de esta forma incrementa el rendimiento del servidor de orquestación. No es por tanto un lenguaje interpretado. Al tratarse de un lenguaje con sintaxis basada en XML es completamente portable entre herramientas. Como limitación podemos señalar que solo permite la orquestación de servicios web, lo que en algunos casos puede ser demasiado limitante a la hora de componer servicios en un proceso de negocio.

2.4.3. Otros lenguajes específicos de cada herramienta.

Existen multitud de herramientas BPMS, aunque la mayoría de ellas quedan fuera del alcance este proyecto. No todas utilizan BPMN o BPEL como lenguaje de modelado, otras emplean otros lenguajes no siempre estándar. Por ejemplo, la herramienta JOpera analizada plantea el uso de un lenguaje visual propio para realizar el modelado de los procesos. De manera similar a BPMN, pero sin seguir ningún estándar reúne características deseables como:

● Composición de servicios Botton-up y Top-Down ● Posibilidad de invocar servicios SOAP, RESTful, Java, Javascript, etc. ● Definición del flujo de control y el flujo de datos ● Monitorización y depuración de las composiciones de servicio

2.5. Lenguaje para el desarrollo del middleware. Una parte importante de este proyecto consiste en el desarrollo del middleware que permita la composición de servicios web asociados al proceso industrial. Para hacer esto posible el middleware, también denominado pasarela, debe satisfacer algunos

10

requisitos para los que el lenguaje elegido para su codificación juega un papel fundamental. Se analizan a continuación los tres lenguajes evaluados para la codificación del middleware. El abanico de posibilidades en este caso era bastante amplio, pero se ha limitado a aquellos conocidos por el autor.

2.5.1. Java.

El primer lenguaje que se suele tener en cuenta hoy en día a la hora de abordar un desarrollo mínimamente complejo es Java. En el caso que nos ocupa, analizó su empleo, encontrándose ventajas como:

● Amplio conocimiento por la comunidad académica ● Gran productividad por la facilidad de escritura de código y existencia de

numerosas librerías y frameworks Sin embargo se descartó su uso porque para la implementación de la pasarela se buscaba primar el rendimiento. Java puede ser un lenguaje ágil para la mayoría de aplicaciones empresariales, pero cuando se opera en el ámbito industrial es casi indispensable incrementar el rendimiento del software hasta niveles de tiempo real. Además, en este ámbito no siempre se dispone de dispositivos potentes, y uno de los aspectos más negativos de Java es el consumo desmedido que realiza de memoria RAM.

2.5.2. C.

El siguiente lenguaje analizado, y dadas las necesidades de rendimiento anteriormente expuestas, fue C. Es de sobra conocido su utilización tanto en ámbitos académicos como profesionales, siendo uno de los preferidos en la industria. Su rendimiento está fuera de toda duda, y solo se le podrían achacar dos inconvenientes:

● la portabilidad entre plataformas no siempre es fácil, ya que según las librerías empleadas no basta con recompilar simplemente. El ejemplo más recurrente es el uso de la librería Pthreads, aunque valdría cualquier implementación del API de POSIX.

● Al ser un lenguaje creado hace bastantes décadas, adolece de ser menos productivo que otros lenguajes de alto nivel más recientes, como podría ser Java. Este punto puede estar sujeto a debate, porque es difícil de medir la productividad de un lenguaje, y muchas veces es más importante la maestría que se tiene con su uso que las bondades aparentes.

A pesar de ello, C se ha mantenido como un posible candidato para el desarrollo de la pasarela.

2.5.3. Go.

El tercer lenguaje analizado es Go. Se trata de un lenguaje de propósito general, lanzado por Google en 2009. Entre los autores se encuentran Rob Pike (desarrollo UNIX, UTF8) y Ken Thompson (cocreador de UNIX, UTF8).

11

El lenguaje es compilado con una sintaxis parecida a C. El binario obtenido es código máquina nativo de la plataforma, es decir, no genera ningún tipo de bytecode ni realiza compilación JIT. Incorpora la concurrencia desde el propio lenguaje, y no está orientado a objetos porque no dispone de una jerarquía de tipos ni del mecanismo de herencia. Sin embargo sobre esto último hay debate porque sí que existen mecanismos de orientación a objetos, como la posibilidad de asociar métodos a tipos de datos. Otra característica que aporta es que dispone de un recolector de basura. Cuando se compila un programa, se añade código que permite la ejecución del recolector, así como otras funciones como el manejo de la concurrencia [6]. Go tiene unas características que lo hacen bastante atractivo para el proyecto:

● Tiene un gran rendimiento, muy próximo a C. ● A pesar de ser bastante reciente, existen numerosas librerías que facilitan la

escritura de aplicaciones. ● Gestiona la concurrencia muy eficientemente, siendo incluso superior en

algunas comparativas a C. ● Su sintaxis lo hace muy productivo. ● Al no permitir la aritmética de punteros y disponer de un recolector de basura

se obtienen programas más seguros. ● Está soportado por las principales sistemas operativos y plataformas (Linux,

Mac, Windows, AMD64, x86, ARM) y su portabilidad es sencilla. Todas estas características hacen de Go una buena elección para el desarrollo de la pasarela. Ahora bien, también se podría haber empleado C para el proyecto, aunque por razones didácticas finalmente se prefirió el primero como lenguaje de implementación. El gran futuro que se le abre a Go, junto a la gran acogida que está teniendo (en 2009 fue declarado lenguaje del año por TIOBE2) motiva a profundizar en su uso para futuros proyectos. Un hecho destacable es que Google soporta Go en su PaaS AppEngine junto a Java y Python, lo que lo convierte en un firme lenguaje para trasladar futuros desarrollos a la nube de Google.

2.6. Alternativas para la integración de servicios RESTful en BPMS.

Una vez evaluadas las herramientas BPMS disponibles y el estado del arte acerca de REST en SOA, podemos resumir que:

● BPEL2.0 no soporta WSDL 2.0, que es la versión que permite definir servicios RESTful. Esto nos obligó a buscar otra solución.

● Apache ODE: dispone de extensiones de WSDL 1.1 para REST. Si bien esto podría funcionar, añade una complejidad en la programación y no acaba de funcionar para exponer servicios RESTful.

● Cesare Pautasso propone una extensión de BPEL para soportar REST [7]. Esto está bien sobre el papel, pero no es un estándar y hasta ahora no se adoptado en ningún BPMS.

2 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

12

● WADL: similar a WSDL pero específico para REST. No es estándar, y en los BPMS analizados ninguno lo soporta.

Llegados a este punto, con el análisis del arte realizado acerca de las alternativas para modelar utilizando REST, se valora como mejor y única opción la utilización de JOpera como BPMS para el proyecto.

2.7. Trabajos científicos relacionados.

El objetivo del proyecto es realizar un desarrollo práctico a partir de la aplicación de una serie de conceptos teóricos y tecnologías ya existentes. Está directamente relacionado con los contenidos de algunas asignaturas del Máster de Ingeniería Informática de la Universidad de Alicante, que ha sido diseñado con un carácter eminentemente profesional. El tema elegido para el desarrollo del proyecto no es completamente original, sino que se apoya en otros trabajos científicos en los que se ha inspirado. Podemos mencionar en primer lugar, los trabajos [8], [9], [10] de Gilart-Iglesias et al., de donde se ha apoyado principalmente para la selección del tema del proyecto. En estos artículos, los autores proponen una modelización de los procesos industriales y manufactureros mediante la arquitectura SOA, basándose en tecnología SOAP y apoyándose en dispositivos middleware para la integración de los dispositivos de campo. De forma análoga, encontramos en el trabajo de Mathes [11] una modelización basada en SOA similar a la anterior, pero eliminando la capa de middleware y empotrando directamente en el autómata el software que implementa los servicios web. Esta solución plantea el inconveniente del fuerte dependencia en el lenguaje de programación del autómata y por tanto en la tecnología de señalización de los dispositivos de campo. Con un enfoque diferente, prescindiendo del modelado de procesos, nos encontramos abundante producción científica en el área de Internet de las Cosas. En [12] Ruppen plantea la conectividad de dispositivos a lo largo de Internet mediante tecnología RESTful. El autor aboga por “RESTify” todo elemento conectable a la red como paso previa para componer servicios. Esta apuesta por el estilo REST para publicar como servicios los dispositivos industriales será uno de los pilares principales en que se fundamente el proyecto.

13

3. Especificación.

3.1. Descripción de los procesos industriales a modelar.

Se define la descripción del proceso industrial como las transformaciones realizadas a un conjunto de entradas introducidas que producen unos resultados. Tanto las entradas, como las salidas, así como las transformaciones realizadas entre medias pueden tener alguna interfaz de comunicación con un elemento industrial. Específicamente se plantea el siguiente escenario industrial. En un CPD inteligente se han montado diferentes elementos que permiten operar la sala de servidores con total seguridad y confianza. Se pretende implementar un sistema que gobierne de forma autónoma todas las instalaciones que se contienen en la sala. La lógica de control establecida es la siguiente:

● Cuando la temperatura exterior sea inferior a 23ºC, se parará la climatización y se activarán los impulsores y aspiradores. Se mantendrá este estado mientras la temperatura interior esté por debajo de los 25ºC.

● Cuando la temperatura interior supere los 25ºC, independientemente de la temperatura exterior, se activará la climatización y se cerrarán los impulsores y aspiradores.

● Cuando se dispare la alarma de extinción de incendios se apagarán las climatizadoras, se desactivarán los impulsores y aspiradores y se activará la grabación CCTV.

3.2. Especificación de requisitos funcionales del middleware.

El middleware está planteado para ser la pasarela de comunicaciones entre los dispositivos industriales y el BPMS. Las características principales que debe tener son:

● Debe ser capaz de comunicarse vía Modbus/TCP [13] con uno o varios autómatas.

● Funciones reactivas (servidor RESTful). Implementará funciones de lectura/escritura de variables sobre dispositivo . Éstas podrán ser tanto individuales como colectivas.

● Funciones proactivas (cliente RESTful). Revisará mediante sondeo configurable conjuntos de variables en los dispositivos. Permitirá definir eventos y alarmas configurables en función de valores alcanzados. Estas alarmas y eventos permitirán ejecutar servicios web hacia el BPMS definido.

● Caché de datos. Los datos servidos desde petición RESTful (reactiva) serán suministrados a partir de la recopilación más reciente realizada mediante lectura del dispositivo (proactiva).

● Existirá un API con las funciones de comunicación con el dispositivo.

14

● Cada tipo de dispositivo tendrá una implementación del driver de comunicaciones, utilizando el API. Se abre de esta manera la posibilidad de integrar otros autómatas que utilicen protocolos diferentes, como PROFINET, o bien cablear directamente los sensores y actuadores a la pasarela.

● Fichero de configuración general con parámetros del sistema. ● Fichero de configuración con las variables (tags) definidas y el tipo (r/w). ● Fichero de configuración con las variables y su direccionamiento en el

dispositivo. Este fichero será específico de cada implementación del driver del dispositivo.

● Existirá un log con la actividad general de la pasarela. Otras características opcionales que se plantean para el futuro, aunque fuera del alcance de este proyecto son:

● Para transferencias masivas de datos opcionalmente será posible la compresión de los mismos.

● Establecer algún mecanismo de autenticación para el servidor web: OAuth, LDAP y cuentas locales.

● Se implementará https. ● Se implementará el protocolo de comunicaciones PROFINET.

3.3. Requisitos del software de composición de servicios (BPMS).

El software de composición de servicios debe soportar nativamente la arquitectura de comunicaciones basada en REST. Esto quiere decir que, sin realizar ningún gran esfuerzo de integración, con las opciones de configuración del BPMS, y sin recurrir a ESB terceros, debe ser capaz de publicar servicios RESTful y conectar con servicios RESTful externos. La características esenciales que debe contemplar serían:

● La instanciación de cada proceso de negocio debe realizarse bajo petición RESTful

● La huella de memoria y carga de CPU debe ser contenida para poder soportar las exigencias de un entorno industrial

● Debe ser software libre o al menos software gratuito.

4. Arquitectura.

El sistema completo está constituido por tres

● Autómata industrial. La parte de campo industrial está reproducida a través de un simulador de PLC capaz de comunicarse vía Modbus/TCP. El software elegido en este caso es

● Middleware. Como parte del proyecto se ha desde publicar las señales de dispositivos como servicios RESTful.

● Servidor BPMS. Derivado del análisis del estado del arte en cuanto a software BPMS, y en función de los requisitos, se ha optado por emplear el software JOpera4 para el modelado de los procesos. Este modelado se realizará mediante la composición de los servicios RESTful publicados por el middleware.

Los tres componentes conforman un sistema distribuido con posibilidadesToda la actividad de proceso comienza en el middleware, ya que por un lado está sondeando periódicamente al autómata leyendo las variables y guardándolas en memoria caché. Las variables son publicadas como servicios, que son atendidos por procesos que implementan un servidor web empotrado. Este modo de funcionamiento se denomina reactivo, porque opera reaccionando a las peticiones externas, en este

3 http://modbuspal.sourceforge.net/4 http://www.jopera.org/

El sistema completo está constituido por tres componentes principales:

Autómata industrial. La parte de campo industrial está reproducida a través de un simulador de PLC capaz de comunicarse vía Modbus/TCP. El software elegido en este caso es ModBusPal 3. Middleware. Como parte del proyecto se ha desarrollado el software encargado de publicar las señales de dispositivos como servicios RESTful. Servidor BPMS. Derivado del análisis del estado del arte en cuanto a software BPMS, y en función de los requisitos, se ha optado por emplear el software

para el modelado de los procesos. Este modelado se realizará mediante la composición de los servicios RESTful publicados por el

Fig.1. Arquitectura general del sistema

Los tres componentes conforman un sistema distribuido con posibilidadesToda la actividad de proceso comienza en el middleware, ya que por un lado está sondeando periódicamente al autómata leyendo las variables y guardándolas en memoria caché. Las variables son publicadas como servicios, que son atendidos por

os que implementan un servidor web empotrado. Este modo de funcionamiento se denomina reactivo, porque opera reaccionando a las peticiones externas, en este

http://modbuspal.sourceforge.net/

15

componentes principales:

Autómata industrial. La parte de campo industrial está reproducida a través de un simulador de PLC capaz de comunicarse vía Modbus/TCP. El software

arrollado el software encargado de publicar las señales de dispositivos como servicios RESTful. Servidor BPMS. Derivado del análisis del estado del arte en cuanto a software BPMS, y en función de los requisitos, se ha optado por emplear el software

para el modelado de los procesos. Este modelado se realizará mediante la composición de los servicios RESTful publicados por el

Los tres componentes conforman un sistema distribuido con posibilidades escalado. Toda la actividad de proceso comienza en el middleware, ya que por un lado está sondeando periódicamente al autómata leyendo las variables y guardándolas en memoria caché. Las variables son publicadas como servicios, que son atendidos por

os que implementan un servidor web empotrado. Este modo de funcionamiento se denomina reactivo, porque opera reaccionando a las peticiones externas, en este

caso el BPMS. Las peticiones de lectura no generan a su vez una lectura en el autómata, sino en la cache de datos. Las peticiones de escritura sí producen escritura en el autómata y la cache, mediante el mecanismo

Por otro lado, como consecuencia de esta lectura, analiza los valores obtenidos y ecaso de cumplir alguna condición de evento o alarma generará una petición que provocará el arranque de un proceso en el BPMS. Es el modo de funcionamiento proactivo, y el evento es generado a través de un cliente web RESTful.

caso el BPMS. Las peticiones de lectura no generan a su vez una lectura en el cache de datos. Las peticiones de escritura sí producen escritura

en el autómata y la cache, mediante el mecanismo write-through.

Fig. 2. Esquema reactivo del middleware

Por otro lado, como consecuencia de esta lectura, analiza los valores obtenidos y ecaso de cumplir alguna condición de evento o alarma generará una petición que provocará el arranque de un proceso en el BPMS. Es el modo de funcionamiento proactivo, y el evento es generado a través de un cliente web RESTful.

16

caso el BPMS. Las peticiones de lectura no generan a su vez una lectura en el cache de datos. Las peticiones de escritura sí producen escritura

Por otro lado, como consecuencia de esta lectura, analiza los valores obtenidos y en el caso de cumplir alguna condición de evento o alarma generará una petición que provocará el arranque de un proceso en el BPMS. Es el modo de funcionamiento proactivo, y el evento es generado a través de un cliente web RESTful.

Fig. 3. Esquema proactivo del middleware.

17

18

5. Diseño.

5.1. Metodología.

En arquitecturas SOA existen varias metodologías disponibles para llevar a cabo la modelización de los procesos [14]. Las principales son:

● Top-down: se parte del análisis del proceso de negocio y de él se deriva la composición de servicios. Posteriormente se desarrollan estos servicios y son desplegados. Se trata de una metodología deductiva.

● Bottom-up: la tecnología juega en este caso un papel principal, y determina cómo se construyen los servicios para diseñar el proceso de negocio. A diferencia de top-down, se fundamenta en una metodología inductiva.

Existen otras metodologías derivadas de la combinación de ambas, como Meet-in-the-

middle y Middle-out [15], pero que no aplican a nuestro caso y se descartan por ser menos relevantes. Para la modelización de procesos industriales nos vemos empujados a utilizar la metodología bottom-up para construir el proceso. Esto es así porque se debe contar siempre con los dispositivos de campo disponibles y la forma de señalizar los datos y estados de los elementos a componer. A diferencia de otros ámbitos de las TI, por ejemplo en BPM empresariales, donde el desarrollo final del servicio se implementa vía software, en el caso manufacturero disponemos de la restricción impuesta por el conjunto de sensores y actuadores. Esto nos obliga a construir inicialmente los servicios disponibles partiendo del conjunto de señales publicadas por el middleware que conecta con campo. De esta manera, en una primera fase es necesario construir los servicios a partir de una señal o conjunto de señales de un dispositivo industrial (fig. 4).

Fig

A continuación componemos los servicios (orquestación) una lógica y la interacción entre ellos industriales (fig. 5). Hay que destacar que esta composición de servicios suele incluir otros servicios no industriales, como los clásicos

Fig. 5. Composición de servicios para implementar un proceso industrial.

Fig 4. Modelización de dispositivos como servicios.

A continuación componemos los servicios (orquestación) mediante la aplicación de una lógica y la interacción entre ellos y se crean así los procesos de negocio industriales (fig. 5). Hay que destacar que esta composición de servicios suele incluir otros servicios no industriales, como los clásicos empresariales (ERP, CRM, etc).

Composición de servicios para implementar un proceso industrial.

19

mediante la aplicación de rocesos de negocio

industriales (fig. 5). Hay que destacar que esta composición de servicios suele incluir empresariales (ERP, CRM, etc).

20

5.2. Diseño del simulador de dispositivos. Para reproducir los dispositivos de entrada y salida industriales, se buscó un simulador de autómata que fuera capaz de simular el protocolo industrial Modbus/TCP. La solución seleccionada fue ModbusPal 1.6b, que se trataba de un software que arrancaba un proceso con interfaz gráfica incluida y donde se podían definir los registros de variables donde representar los estados de cada uno de los dispositivos. Se empleó el segmento de memoria comprendido a partir de la posición 40001 (holding registers), por ser los registros (16 bit) reservados para operaciones de lectura (entradas) y escritura (salida). Se indica a continuación los dispositivos identificados por su posición en memoria:

Dirección de memoria Dispositivo

40001 Sonda de temperatura exterior 40002 Sonda de temperatura interior 40003 Climatizadora 1 40004 Climatizadora 2 40005 Impulsor 1 40006 Impulsor 2 40007 Aspirador 1 40008 Aspirador 2 40010 Centralita contraincendios 40011 Cámara CCTV 1 40012 Cámara CCTV 2

Todos ellos estaban preparados para soportar lecturas y escrituras, aunque para las pruebas solo desempeñaban roles de lectura o escritura según su naturaleza. Para conseguir una simulación lo más fiel a la realidad, se configuró el software de manera que cada acceso al autómata tuviera una latencia constante de 10 ms.

5.3. Middleware: diseño del programa. El middleware está desarrollado completamente en lenguaje Go, estructurándose los ficheros de código fuente de la siguiente manera:

● devicews.go: código de programa principal, contiene la función main. ● soaserver.go: proceso de servidor web que atiende las peticiones de servicio

en funcionamiento reactivo. ● soaclient.go: proceso encargado de comunicar de eventos y alarmas hacia el

BPMS, siendo éste el comportamiento proactivo. ● worker.go: proceso encargado de comunicar con dispositivos ModBus.

Contiene la interfaz (API) a implementar por cada driver desarrollado. ● workerMB.go: implementación del API worker.go para Modbus/TCP ● protocolMB.go: contiene los detalles del protocolo modbus, como las

estructuras de los paquetes de comunicaciones.

21

● config.go: se incluye la definición de estructuras tanto de ficheros de configuración (JSON) como de datos.

Todos los ficheros están agrupados dentro de un mismo paquete llamado main y estarán ubicados sobre el directorio devicews. Como resultado de la compilación se obtiene un único ejecutable binario de la plataforma nativa (en nuestro caso Linux x86_64).

5.4. Middleware: configuración. Tres ficheros permiten configurar el middleware, lo que nos aporta suficiente flexibilidad para manejar cualquier escenario de implantación en un entorno industrial. Se ha empleado el formato JSON debido a que inicialmente se diseñó el programa enteramente en este formato, incluidas las comunicaciones, y se ha decidido mantener hasta la actualidad. Configuración general (config.json).

El fichero de configuración config.json permite definir los parámetros generales de funcionamiento del middleware.

Todos los parámetros son autoexplicativos por el nombre adoptado. Destacamos como más importantes RESTTCP, que define el puerto TCP por el que va a escuchar el middleware las peticiones REST, y EventSubscriber como la URL completa donde se enviarán los eventos y alarmas, en este caso el servidor BPMS. A esta URL se deberá añadir el directorio /event. Hay que indicar también que no todos los parámetros se han implementado (RESTTLS, RESTMaxRequests, RESTTimeout) quedando pendiente para futuras versiones. Configuración de tags (tags.json).

Las variables que se transmiten hacia y desde los dispositivos industriales se denominan tags y se organizan mediante agrupaciones llamadas áreas. Estas áreas cumplen la función de ser la unidad mínima de lectura en el sondeo periódico realizado

{ "config":{ "RESTTCP":8787, "RESTTLS":false, "RESTMaxRequests": 100, "RESTTimeout": 30000, "RESTXML": true, "LogFile": "devicews.log", "LogLevel":"DEBUG", "EventSubscriber":"http://bpmserver:8080" } }

22

al dispositivo, optimizándose de esta manera los tiempos de comunicación. También cada área será la unidad mínima configurable en los workers o procesos, que veremos en la siguiente sección. Los tipos de datos admitidos son:

● I: entero con signo de 16 bits ● F: coma flotante de 32 bits ● B: booleano (16 bits) ● L: entero largo con signo de 32 bits

Una configuración típica podría ser:

A cada tag se le puede asociar un evento/alarma que permita generar una acción a partir de una condición dada:

[...] {"name":"texterior","address":"40001","datatype":"I",

"events":[{"expression":"LT","valuestring":"23","priority":1,"descripti

on":"Aviso temp. exterior<23"},

{"expression":"GE","valuestring":"23","priority":2,"description":"Alarm

a temp. exterior >=23"}]}, [...]

{ "areas":[ { "name":"area1", "tags":[ {"name":"tag1","address":"30001","datatype":"I"}, {"name":"tag2","address":"30002","datatype":"I"}

] }, { "name":"area2", "tags":[ {"name":"tag11","address":"30011","datatype":"I"}, {"name":"tag12","address":"30012","datatype":"I"} ] }, { "name":"area3", "tags":[ {"name":"tag21","address":"30021","datatype":"I"}, {"name":"tag22","address":"30022","datatype":"I"} ] } ] }

23

En este ejemplo se asocian dos alarmas que se dispararán cuando el valor sea menor a 23 (LT, less than) con prioridad 1, o cuando el valor sea mayor o igual que 23 (GE, greater or equal) con prioridad 2. Conviene especificar las restricciones que existen a la hora de configurar las áreas y tags, dependientes del protocolo modbus:

● Cada tag pertenecerá a un único área ● Cada tag puede tener un tamaño de 2 o 4 bytes. Se almacenan en formato en

bruto como array de dos o 4 bytes, y solo al procesar por parte del servidor web se formateará al tipo correspondiente.

● Los tags deben tener direcciones correlativas y estar organizados por áreas. Cada área se lee secuencialmente y no deben más de 125 variables (de 2 bytes), ya que con cada secuencia de lectura solo se pueden leer un máximo de 250 bytes.

● En el caso de Modbus, cada posición de memoria ocupa 2 bytes, por lo que si queremos direccionar tipos de 4 bytes correlativos, hay que tener en cuenta este dato. Por ejemplo, dos tags de 16 bits pueden direccionarse como 40001 y 40002, mientras que si fueran de 32 bits debería ubicarse en 40001 y 40003.

Configuración de workers (workers.json).

Por último queda definir la unidad de proceso que permite acceder a los dispositivos. Cada worker corresponde con un proceso encargado de leer o escribir datos a un único dispositivo. Los workers se especializan en lectura o escritura, pero nunca ambos roles simultáneamente, y tienen un ciclo de ejecución constante configurable. Como ejemplo de configuración mostramos el siguiente:

24

A cada worker asociamos un nombre, protocolo de comunicación, período de ejecución (en ms), rol de lectura o escritura, dirección del dispositivo, puerto de comunicación, y áreas de tags que gestionará. Los worker de escritura tienen como algunas particularidades como:

● Solo puede existir uno en el middleware. ● Al ser las escrituras solo bajo demanda, el parámetro period no tiene sentido. ● Tienen un parámetro adicional, threads, que permite paralelizar en múltiples

hilos el proceso para escalar las peticiones de escritura y evitar cuellos de botella.

{ "workers":[ { "name":"MotorW1", "protocol":"modbus", "period":-1, "writer": true, "address":"plc", "port":502, "threads":10 }, { "name":"Motor1", "protocol":"modbus", "period":900000, "writer": false, "address":"plc", "port":502, "areas":[ {"area":"area1"} ] }, { "name":"Motor2", "protocol":"modbus", "period":1000000, "writer": false, "address":"plc", "port":502, "areas":[ {"area":"area2"}, {"area":"area3"} ] } ] }

25

5.5. Middleware: estructuras de datos. En esta sección se describen las estructuras creadas para el almacenamiento de los datos en el programa. Por simplificar se ha descartado describir las estructuras auxiliares necesarias para la lectura y parsing automático de los ficheros json. Cache de datos.

Está definida por dos estructuras de datos tipo hash, que permiten un rápido acceso a cualquier área o tag.

● Mapa de Áreas. Como clave se define un string con el nombre, devolviendo un valor del tipo AreaType.

areasMap := make(map[string]AreaType)

● Mapa de Tags. Como clave se define un string con el nombre (nombre de área

+ nombre de tag), devolviendo un valor del tipo TagType.

tagsMap := make(map[string]TagType) Estructuras de datos principales.

type AreaType struct { Name string Tags []TagType } type TagType struct { Name string Address string Area string Kind byte //r=read only, w=write only, a=read/write Size int Value interface{} } type EventType struct { Expression string //see expressions constants section above ValueString string Value []byte Priority int Description string }

26

5.6. Middleware: análisis funcional. Según hemos visto anteriormente, el middleware es capaz de funcionar de manera reactiva y proactiva, lo que permite mejorar los tiempos de respuesta de los dispositivos industriales al reducir la necesidad de polling. Modo reactivo: lectura de variable

Fig. 6. Diagrama de secuencia del middleware en lectura de una variable.

Modo reactivo: escritura de variable

27

Fig. 7. Diagrama de secuencia del middleware en escritura de variable.

Modo proactivo.

Fig. 8. Diagrama de secuencia del middleware generando evento (modo proactivo).

28

5.7. Middleware: protocolo de comunicaciones. El formato de los mensajes se realizará en XML. Los tipos de datos para las tags disponibles (tagType) serán:

Código Tipo B Booleano I Entero 16 bits L Entero 32 bits F Flotante 32 bits

Modo reactivo.

Se utilizará la siguiente estructura de datos para almacenar las variables:

type RESTTag struct{ Name string Area string DataType string Value string }

29

Y las operaciones definidas se indican a continuación:

Reactivo: Lectura de una variable tag

Método GET

Path /tag/{area}/{tag}

Salida TagType

Ejemplo http://localhost:8787/tag/area1/tag1

Dato devuelto <Tag> <Name>tag2</Name> <Area></Area> <DataType>I</DataType> <Value>1021</Value>

</Tag>

Código correcto 200 OK

Códigos error 404 variable no encontrada

503 error de conexión con dispositivo

Reactivo: Lectura de todas las variables tag de un área

Método GET

Path /tag/{area}

Salida Vector de TagType

Ejemplo http://localhost:8787/tag/area1

Dato devuelto <Area> <Name>area1</Name> <Tags>

<Tag> <Name>tag1</Name> <Area>area2</Area> <DataType>I</DataType> <Value>501</Value>

</Tag> <Tag>

<Name>tag2</Name> <Area>area2</Area> <DataType>I</DataType> <Value>1021</Value>

</Tag> </Tags>

30

</Area>

Código correcto 200 OK

Códigos error 404 variable no encontrada

503 error de conexión con dispositivo

Reactivo: Escritura de una variable tag

Método POST

Path /tag

Body

<Tag> <Name>nombreTag</Name> <Area>NombreArea</Area> <DataType>tipoDato</DataType> <Value>valorDato</Value>

</Tag>

Salida <nada>

Ejemplo http://localhost:8787/tag

Dato devuelto

<Tag> <Name>tag2</Name> <Area>area1</Area> <DataType>I</DataType> <Value>1021</Value>

</Tag>

Código correcto 202 OK

Códigos error 404 variable no existe

500 error general de escritura

Proactivo: envío de evento o alarma.

Generará eventos, que según su criticidad podrán ser simples eventos o alarmas. La estructura del evento será:

y por tanto el formato del mensaje en XML:

type RESTEvent struct{ Priority int Description string Tag RESTTag }

31

Proactivo: Envío de una evento/alarma

Método POST

Path /event

Body

<Event> <Priority>prioridad</Priority> <Description>Descripción</Description> <Tag>

<Name>nombreTag</Name> <Area>NombreArea</Area> <DataType>tipoDato</DataType> <Value>valorDato</Value>

</Tag> </Event>

Salida <nada>

Ejemplo http://bpmserver:8080/event

Dato

devuelto

<Event> <Priority>2</Priority> <Description>Alarma de

temperatura</Description> <Tag>

<Name>texterior</Name> <Area>area1</Area> <TagType>I</TagType> <Value>27</Value>

</Tag> </Event>

La prioridad variará entre 0 y 9, siendo:

● 0-7: alarma, cuanto menor número, mayor prioridad. ● 8: evento informativo. ● 9: evento historizador, empleado para expresar un cambio de valor en una

variable y así poder registrarlo en la BD histórica. Esta forma de codificar es una propuesta, ya que es dependiente del servidor que reciba estos mensajes y cómo realice el tratamiento de estos mensajes.

5.8. Diseño del BPMS.

El software para la modelización de los procesos industriales es JOpera, que incluye un lenguaje visual muy apto diseñar el modelo de proceso. Se basa en definir dos tipos de modelización:

● Flujo de control. Se definen las actividades conectadas con flechas para indicar

el flujo de control que seguirá la ejecución del proceso.● Flujo de datos. En este caso se definen las actividades conectadas con flechas

indicando el flujo de datos. La conexión sde una actividad que enlazan con las variables de entrada de la siguiente.

Los procesos industriales se han modelizado de la siguiente manera. Existe un proceso principal, llamado derivarlas al subproceso que aplique.

Fig. 9. (a) Flujo de control del proceso Listener. (b) Flujo de datos del proceso Listener.

Subproceso ClimaExterior. Se activa cuando llega un evento que contiene la variable texterior. Este proceso primero obtiene la temperatura interior (tinterior) y el estado de la centralita contraincendios (centralitapci). En función de los valores obtenidos accionará la climatización o la ventilación activándola o desactivándola.

● Accionar la climatización consiste en enviar 0 o 1 a los servicios AccionarClima1 y AccionarClima2.

● Accionar la ventilación supone enviar 0 o 1 a los servicios AccionarImpulsor[12] y AccionarVentilador[1

o de control. Se definen las actividades conectadas con flechas para indicar el flujo de control que seguirá la ejecución del proceso. Flujo de datos. En este caso se definen las actividades conectadas con flechas indicando el flujo de datos. La conexión se realiza mediante variables de salida de una actividad que enlazan con las variables de entrada de la siguiente.

Los procesos industriales se han modelizado de la siguiente manera. Existe un proceso principal, llamado Listener, que se encarga de recibir las peticiones y derivarlas al subproceso que aplique.

(a) Flujo de control del proceso Listener. (b) Flujo de datos del proceso Listener.

. Se activa cuando llega un evento que contiene la variable . Este proceso primero obtiene la temperatura interior (tinterior) y el estado de

la centralita contraincendios (centralitapci). En función de los valores obtenidos accionará la climatización o la ventilación activándola o desactivándola.

climatización consiste en enviar 0 o 1 a los servicios AccionarClima1 y AccionarClima2. Accionar la ventilación supone enviar 0 o 1 a los servicios AccionarImpulsor[12] y AccionarVentilador[1-2].

32

o de control. Se definen las actividades conectadas con flechas para indicar

Flujo de datos. En este caso se definen las actividades conectadas con flechas e realiza mediante variables de salida

de una actividad que enlazan con las variables de entrada de la siguiente. Los procesos industriales se han modelizado de la siguiente manera. Existe un

as peticiones y

(a) Flujo de control del proceso Listener. (b) Flujo de datos del proceso Listener.

. Se activa cuando llega un evento que contiene la variable . Este proceso primero obtiene la temperatura interior (tinterior) y el estado de

la centralita contraincendios (centralitapci). En función de los valores obtenidos accionará la climatización o la ventilación activándola o desactivándola.

climatización consiste en enviar 0 o 1 a los servicios

Accionar la ventilación supone enviar 0 o 1 a los servicios AccionarImpulsor[1-

Fig. 10. (a) Flujo de control del subproceso ClimaExt

Subproceso ClimaInterior. Se activa cuando llega un evento que contiene la variable tinterior. Este proceso primero obtiene la temperatura exterior (texterior) y el estado de la centralita contraincendios (centralitapci). En función de los valores obtenidos accionará la climatización o la ventilación activándola o desactivándola.

(a) Flujo de control del subproceso ClimaExterior. (b) Flujo de datos del subproceso ClimaExterior.

. Se activa cuando llega un evento que contiene la variable . Este proceso primero obtiene la temperatura exterior (texterior) y el estado de

endios (centralitapci). En función de los valores obtenidos accionará la climatización o la ventilación activándola o desactivándola.

33

erior. (b) Flujo de datos del subproceso ClimaExterior.

. Se activa cuando llega un evento que contiene la variable . Este proceso primero obtiene la temperatura exterior (texterior) y el estado de

endios (centralitapci). En función de los valores obtenidos accionará la climatización o la ventilación activándola o desactivándola.

Fig. 11. (a) Flujo de control del subproceso ClimaInterior. (b) Flujo de datos del subproceso ClimaInterior.

Subproceso PCI. Se activa cuando llega un evento que contiene la variable centralitapci. Si se activa la alarma apagará la climatización y ventilación, además de iniciar la grabación de las cámaras CCTV. Si se desactiva la alarma, finalizará la grabación de CCTV, y leerá a continuación la temperatura interior; en función de los valores obtenidos accionará la climatización o la ventilación.

(a) Flujo de control del subproceso ClimaInterior. (b) Flujo de datos del subproceso ClimaInterior.

. Se activa cuando llega un evento que contiene la variable Si se activa la alarma apagará la climatización y ventilación, además de

iniciar la grabación de las cámaras CCTV. Si se desactiva la alarma, finalizará la V, y leerá a continuación la temperatura interior; en función de los

valores obtenidos accionará la climatización o la ventilación.

34

(a) Flujo de control del subproceso ClimaInterior. (b) Flujo de datos del subproceso ClimaInterior.

. Se activa cuando llega un evento que contiene la variable Si se activa la alarma apagará la climatización y ventilación, además de

iniciar la grabación de las cámaras CCTV. Si se desactiva la alarma, finalizará la V, y leerá a continuación la temperatura interior; en función de los

Fig. 12. (a) Flujo de control del subproceso PCI. (b) Flujo de datos del subproceso PCI.

(a) Flujo de control del subproceso PCI. (b) Flujo de datos del subproceso PCI.

35

(a) Flujo de control del subproceso PCI. (b) Flujo de datos del subproceso PCI.

36

6. Implementación y pruebas.

La implementación del middleware ha sido realizada mediante el uso del lenguaje de programación general Go. Se ha desarrollado íntegramente sobre plataforma Linux v.3.9.9 x86_64, obteniéndose código nativo, lo que nos ha permitido obtener unos tiempos de ejecución óptimos. No obstante, para las pruebas de rendimiento se recompiló el código fuente para el procesador ARM11. Se han utilizado varias librerías nativas del lenguaje Go:

● GoRest: servidor web que es capaz encapsular peticiones RESTful. ● log4go: librería para la generación de logs, similar a log4j.

La implementación del protocolo ModBus/TCP [16] ha sido totalmente artesanal al no disponerse de librerías. No obstante la sencillez de este protocolo no ha supuesto un gran esfuerzo en el desarrollo. Finalmente, como resultado de la compilación del código fuente y librerías, se ha obtenido un único ejecutable binario con un tamaño aproximado de 4,5 MB. Esto nos permite facilitar su distribución, ya que su instalación solo requiere:

El nombre que inicialmente se ha dado al middleware es devicews.

6.1. Entorno de pruebas. Para la ejecución de las pruebas de rendimiento se ha dispuesto el siguiente entorno:

● Autómata. El simulador de Modbus/TCP ha corrido en un equipo Windows7/64 Intel i3 2GHz. con 4 GB de RAM. Este equipo no precisaba de mucho rendimiento ya que el simulador se iba a configurar con un retardo artificial de 10ms.

● Middleware. Para el componente que hace las funciones de pasarela se buscó una plataforma que fuera sencilla y económica, incluso pudiéndose empotrar en otros dispositivos, para acercarla lo más posible al mundo industrial. De esta forma se probaría también la eficiencia y viabilidad de la implementación. Para ello se contó con el microordenador Raspberry Pi, que es una tarjeta con varios circuitos integrados y chips, pero que contiene todo lo necesario para correr la aplicación: CPU ARM11, 512 MB de memoria y un puerto de red de 100Mbps. Este dispositivo ejecutaba una distribución de Linux basada en Debian llamada Raspbian, lo que lo convertía en una solución flexible, económica y versátil.

● Servidor BPMS. Por último para la ejecución del servidor JOpera se contó con un servidor Linux Fedora 19 x86_64 con CPU Intel i3 3,2GHz y 8 GB de RAM.

[jvespi@localhost devicews]$ ll *.json devicews -rw-r-----. 1 jvespi jvespi 286 jul 20 08:54 config.json -rwxr-x---. 1 jvespi jvespi 4644457 jul 20 08:54 devicews -rw-r-----. 1 jvespi jvespi 1522 jul 20 08:54 tags.json -rw-r-----. 1 jvespi jvespi 506 jul 20 08:54 workers.json

37

● Red de comunicaciones. Los tres dispositivos anteriores se conectaron mediante un switch de 100 Mbps, siendo el cableado UTP categoría 5e.

Fig. 13. Microordenador RaspBerry Pi.

6.2. Resultados obtenidos. Para la realización de las pruebas se desarrolló un sencillo cliente REST que nos indicaba los errores recibidos y los tiempos de respuesta. Admitía además generar n peticiones paralelas, y es por tanto ideal para la medición del rendimiento del entorno. Las condiciones generales en que se realizaron las pruebas fueron las siguientes:

● Latencia de respuesta en lectura/escritura del PLC: 10ms ● Número máximo permitido de escrituras paralelas al middleware: 10 ● Número máximo permitido de accesos paralelos al PLC: 12

38

Funcionamiento reactivo del middleware.

Atendiendo al rendimiento exclusivo del middleware, se diseñó una primera prueba consistente en medir secuencialmente y paralelo el tiempo de respuesta para lecturas y escrituras en el autómata. Se realizaron hasta 10 mediciones de tiempos en lecturas secuenciales, y 10 mediciones de cargas paralelas de 100 y 400 peticiones.

Prueba Secuencial

(ms)

Paralelo (100 procs, ms) Paralelo (400 procs, ms)

T total T por

proceso T total T por proceso

1 6 481 4,81 2230 5,575

2 6 492 4,92 2248 5,62

3 6 491 4,91 1951 4,8775

4 6 455 4,55 2292 5,73

5 5 483 4,83 2276 5,69

6 6 487 4,87 2309 5,7725

7 5 514 5,14 2294 5,735

8 6 457 4,57 2126 5,315

9 6 518 5,18 2311 5,7775

10 5 458 4,58 2323 5,8075

Media 5,7 483,6 4,836 2236 5,59

Tabla 1. Pruebas de lectura de variable.

A la vista de los resultados, se concluye que los tiempos de respuesta en secuencial son muy buenos, por debajo de la latencia del PLC. Esto es debido a la existencia de la cache, que evita tener que contactar con el autómata en cada lectura. Si comparamos los tiempos con la media en paralelo de 100 peticiones, vemos una mejora de en torno 1 ms. por petición. Esta ligera diferencia, de alrededor de un 20% encuentra su explicación en que el mayor consumo de tiempo se produce en el procesamiento de la petición y no tanto en los tiempos de comunicación. Además, hay que recordar que la CPU del dispositivo donde corría el middleware era un monoprocesador, lo que no permitía explotar plenamente el paralelismo. Para cargas de 400 peticiones simultáneas, se obtienen tiempos ligeramente peores pero mejores que en secuencial. Esto nos da una medida de los límites reales de este middleware para obtener tiempos de respuesta aceptables. Si analizamos los tiempos en pruebas de escritura, se observa un aumento de los tiempos de respuesta. En secuencial obtenemos una media de 25,3ms, lógico por otro lado si tenemos en cuenta que el middleware ya no puede aprovechar su cache y

39

debe necesariamente comunicarse con el autómata. Si comparamos con las versiones paralelas, tanto en 100 como en 400 peticiones se observa una media de 10,8 ms por proceso, tiempos muy buenos. Se encuentra la explicación en el aprovechamiento de los tiempos muertos de espera de la respuesta del autómata.

Prueba Secuencial

(ms)

Paralelo (100 procs, ms) Paralelo (400 procs, ms)

T total T por proceso T total T por proceso

1 22 1080 10,8 4418 11,045

2 28 1071 10,71 4352 10,88

3 29 1090 10,9 4251 10,6275

4 25 1084 10,84 4340 10,85

5 28 1087 10,87 4262 10,655

6 20 1083 10,83 4370 10,925

7 29 1079 10,79 4374 10,935

8 26 1073 10,73 4225 10,5625

9 23 1097 10,97 4398 10,995

10 23 1084 10,84 4230 10,575

Media 25,3 1082,8 10,828 4322 10,805

Tabla 2. Pruebas de escritura de variable.

40

Orquestación de procesos: carga secuencial.

La siguiente prueba mide el rendimiento del sistema completo, desde el autómata hasta el servidor BPMS. La prueba se realiza mediante el cliente REST, pero simulando un evento producido en el entorno para invocar cada uno de los tres procesos industriales. Se plantean estos tres escenarios partiendo de dos condiciones de entorno diferentes cada uno.

Prueba

ClimaExterior (tInterior=25, ms)

ClimaInterior (texterior=25, ms) PCI

tExterior=22 tExterior=27 tInterior

=22 tInterior

=27 centralitapci=1 centralitapci=0

1 110 37 36 150 136 111

2 126 36 37 117 144 102

3 121 32 29 106 168 129

4 125 46 34 131 120 106

5 138 37 28 108 141 124

6 129 39 38 118 121 117

7 112 39 33 116 155 100

8 139 38 29 116 137 110

9 117 48 23 115 145 110

10 110 46 36 117 144 125

Media 122,7 39,8 32,3 119,4 141,1 113,4

Tabla 3. Pruebas del sistema orquestado completo en secuencial (en milisegundos).

A la vista de los resultados, observamos tiempos diferentes en función de las lecturas y escrituras que debía hacer cada flujo de proceso. Para el proceso ClimaExterior, los tiempos oscilan entre 122ms y 39ms. Para el proceso ClimaInterior tenemos diferencia parecidas (32ms, 119ms) y en el proceso PCI tiempos similares (141ms, 113ms).

41

Orquestación de procesos: carga en paralelo.

Si comparamos los tiempos anteriores con pruebas realizadas con cargas en paralelo, encontramos los siguientes resultados:

Prueba

ClimaExterior (tInterior=25, ms) ClimaInterior (texterior=25, ms) PCI (ms)

tExterior=22 tExterior=27 tInterior =22 tInterior =27 centralitapci=1 centralitapci=0

T total Errores T total Errores T

total Errores T

total Errores T

total Errores T

total Errores

1 594 2 201 1 284 3 545 2 752 1 497 3

2 738 2 201 1 208 3 619 1 771 1 577 2

3 586 2 201 0 237 2 618 1 703 1 532 2

4 550 3 200 0 252 2 585 1 642 1 519 2

5 636 1 212 0 217 2 654 0 667 2 462 2

6 585 2 222 0 217 2 659 1 672 2 634 0

7 602 1 200 0 245 1 551 1 750 1 513 2

8 606 1 200 0 212 1 542 2 828 0 667 2

9 585 1 200 0 221 0 575 2 782 0 641 0

10 520 1 201 0 206 1 652 0 833 1 515 2

Media 600,2 1,6 203,8 0,2 229,9 1,7 600 1,1 740 1 555,7 1,7

Tabla 4. Pruebas del sistema orquestado completo en paralelo (en milisegundos).

Cada prueba constaba de una batería de 10 peticiones. Las pruebas en paralelo se han diseñado de manera que entre una petición y la siguiente se dejaba un desfase de 20 ms. La razón radica en que el BPMS requería un tiempo para poder instanciar un nuevo proceso cada vez que iniciara su ejecución el que atendió la última petición. Aún así, se ha registrado los errores producidos debido a que en ocasiones el BPMS no fue suficientemente rápido para instancia un nuevo proceso y por tanto no pudo atenderse la petición. Los resultados arrojan una mejora de los tiempos sustancial, del orden de más del 50%; esto es, por otro lado esperable, debido al alto consumo de tiempo de comunicación, lo que permite explotar las capacidades de paralelización.

6.3. Análisis de los resultados.

42

Los resultados obtenidos son bastante buenos teniendo en cuenta las condiciones del laboratorio de pruebas empleado. El rendimiento obtenido por el middleware es bueno, ya que nos proporciona tiempos inferiores a 10ms en lectura, que es la mayoría de los casos para un sistema en tiempo real. Para las escrituras nos vamos a tiempos superiores a los 20 ms, que sin ser malos, están por encima de los esperables para un sistema crítico. Teniendo en cuenta que en cada escritura se producen dos comunicaciones ethernet, junto a una latencia fija de 10ms del PLC, se pueden fácilmente mejorar estos tiempos modificando la implementación:

● Utilizando conexiones GigaEthernet de 1Gbps ● Cableando los dispositivos directamente al middleware en lugar de emplear

Modbus/TCP ● Utilizando autómatas más rápidos

Cuando componemos el sistema completo, incluyendo el BPMS, se aprecian unos tiempos algo mayores según cada caso. Por ejemplo, para el proceso ClimaExterior, podemos obtener unos tiempos muy buenos en el caso de no tener que ejecutar ninguna escritura en campo (30ms); pero cuando la evaluación de las condiciones obliga a modificar el estado de los dispositivos, obtenemos respuestas que se elevan a 130ms. Esto es debido a las 6 escrituras que debe realizar en campo, que vienen a suponer unos 100ms. El BPMS parece que no tiene gran capacidad de procesamiento paralelo, a la vista de los resultados. Esto es por otro lado lógico si tenemos en cuenta que se trata de un BPMS más orientado a procesos empresariales de oficina, desarrollado en Java.

43

7. Recursos necesarios.

Para la elaboración del proyecto se ha utilizado exclusivamente recursos TIC. Esto incluye que para la parte de campo industrial, se ha empleado un simulador que evitara la necesidad de adquirir tal equipamiento. El detalle de los equipos empleados para la implantación y pruebas ha sido descrito en el punto 6.1. Para el desarrollo del software, configuración del BPMS y elaboración de la memoria se ha recurrido a un ordenador personal doméstico.

44

8. Plan de implantación/costes.

Este proyecto se ha diseñado pensando en la simulación del entorno con el objetivo de un análisis de viabilidad teórico de cara a una aplicación práctica. Esto quiere decir que el equipamiento utilizado para la implantación y pruebas no necesariamente es el más apto para su puesta en producción en un entorno real. Para calcular convenientemente el coste que supone su implatación, se abren dos posibles escenarios en función de la infraestructura previamente existente en el CPD. En común tienen el requerimiento de adquirir:

● Pareja de servidores en cluster para la ejecución del BPMS ● Microcomputadora donde empotrar el middleware de comunicación

Escenario A. El Centro de Proceso de Datos no contiene equipamiento TIC ni autómatas de control de dispositivos. Esta circunstancia nos obliga a dotar adicionalmente de:

● Autómata industrial sobre el que cablear los dispositivos a gobernar. Debe ser capaz de comunicarse vía Modbus/TCP.

● Electrónica de red redundante capaz de conectar el middleware con los servidores a través del firewall. Consistirá en al menos dos switches con capacidad de gestión de vlan y enrutamiento entre ellas.

● Firewall en cluster que aisle la red de acceso a los autómatas respecto a la red corporativa.

Escenario B. El Centro de Proceso de Datos ya está operativo con otros sistemas de información. Además contiene uno o varios autómatas que gobiernan los dispositivos industriales y son capaces de comunicar vía Modbus/TCP.

Elemento Escenario A Escenario B

Servidores BPMS 2 x 3000 € 2 x 3000 €

Microcomputadora ( +1 repuesto)

(1 + 1) x 50 € (1 + 1) x 50 €

Autómata industrial Modbus/TCP (+1 repuesto)

(1 +1) x 900 €

Switches de red 2 x 2000 €

Firewall en cluster 2 x 1500 €

Cableado de red UTP cat. 6

2000 € 1000 €

45

Horas de Ingeniería de Procesos

200 x 50 € 200 x 50 €

Horas de Ingeniería de Sistemas

40 x 50 € 40 x 50 €

Horas de Montaje 40 x 25 € 20 x 25 €

Total coste 29900 € 19600 €

Tabla 5. Relación de costes de implantación.

El cálculo de los costes ha sido realizado basándose en la experiencia en el sector, con equipamiento de gama media. En los costes no se incluyen:

● los costes asociados a contratos de soporte ampliados ● el coste del software implantado, no aplica por tratarse software libre.

46

9. Conclusiones y trabajos futuros.

Los procesos industriales están mayoritariamente implementados, hasta la fecha, mediante herramientas y aplicaciones software propietarias del mundo industrial. Los sistemas SCADA representan el tipo de software orientado al control de los procesos en la industria manufacturera más utilizado. Con este trabajo se ha presentado una alternativa abierta basada en los estándares de diseño de procesos empresariales. Mediante el empleo de SOA como arquitectura de diseño de procesos, pero orientándolo a un caso de uso industrial, se ha construido un sistema que puede ser eficaz en su ejecución. Se ha complementado con el uso de tecnologías propias de las TIC, como es REST en las comunicaciones, XML en el formato de los mensajes y un servidor BPMS para la ejecución de la lógica de negocio. No obstante, los resultados no son plenamente útiles para todos los casos de uso industriales y manufactureros. Se han obtenido tiempos de respuesta que pueden ser satisfactorios para muchos entornos, pero algo escasos cuando los pretendemos trasladar a un sistema en tiempo real. Además, el ejemplo de instalación empleado para las pruebas es demasiado sencillo para establecer conclusiones suficientemente rigurosas. Estas circunstancias, lejos de desanimar, plantean un desafío, dado que abren todo un área de investigación futura. El alcance, naturaleza y duración de este proyecto limitan la continuación de la búsqueda de soluciones plenamente satisfactorias para los sistemas industriales, y emplazan a continuar investigando en el área de la informática industrial. El propósito de este proyecto era el de demostrar la viabilidad de la modelización SOA aplicada a la industria mediante la implementación de varios procesos. Y se han logrado estos objetivos señalados, aunque a sabiendas de que existen soluciones a desarrollar más apropiadas. El servidor BPMS empleado no está lo suficientemente maduro para ser implantado en producción, además de no utilizar un lenguaje de modelización estándar. Esta carencia se plantea como una línea de investigación y desarrollo futura. El estudio de lenguajes como BPEL y su adaptación a los requerimientos industriales ofrece un objeto de investigación para los próximos años.

47

10. Referencias.

[1] Erl, T. (2008). SOA design patterns. Pearson Education.

[2] Fielding, R. T. (2000). Architectural styles and the design of network-based software

architectures (Doctoral dissertation, University of California). [3] Pautasso, C., Zimmermann, O., & Leymann, F. (2008, April). Restful web services vs. big'web services: making the right architectural decision. InProceedings of the 17th

international conference on World Wide Web (pp. 805-814). ACM. [4] Pautasso, C. (2009, January). Composing restful services with jopera. In Software

Composition (pp. 142-159). Springer Berlin Heidelberg. [5] Peternier, A., Pautasso, C., Binder, W., & Bonetta, D. (2012). High performance execution of service compositions: a multicore aware engine design. Concurrency and

Computation: Practice and Experience. [6] Deshpande, N., Sponsler, E., & Weiss, N. Analysis of the Go runtime scheduler. [7] Pautasso, C. (2008). Bpel for rest. In Business Process Management (pp. 278-293). Springer Berlin Heidelberg. [8] Gilart-Iglesias, V., Maciá-Pérez, F., Mora-Gimeno, F. J., & Berná-Martínez, J. V. (2006, September). Normalization of industrial machinery with embedded devices and SOA. In Emerging Technologies and Factory Automation, 2006. ETFA'06. IEEE

Conference on (pp. 173-180). IEEE. [9] Gilart-Iglesias, V., Maciá-Pérez, F., Marcos-Jorquera, D., & Mora-Gimeno, F. J. (2007, June). Industrial Machines as a Service: Modelling industrial machinery processes. In Industrial Informatics, 2007 5th IEEE International Conference on(Vol. 2, pp. 737-742). IEEE. [10] Gilart-Iglesias, V., Maciá-Pérez, F., Capella-D'alton, A., & Gil-Martínez-Abarca, J. A. (2006, August). Industrial Machines as a Service: A model based on embedded devices and Web Services. In Industrial Informatics, 2006 IEEE International

Conference on (pp. 630-635). IEEE. [11] Mathes, M., Stoidner, C., Heinzl, S., & Freisleben, B. (2009, February). SOAP4PLC: web services for programmable logic controllers. In Parallel, Distributed

and Network-based Processing, 2009 17th Euromicro International Conference on (pp. 210-219). IEEE.

48

[12] Ruppen, A., Pasquier, J., & Hürlimann, T. (2011). A RESTful architecture for integrating decomposable delayed services within the web of things. International Journal of Internet Protocol Technology, 6(4), 247-259. [13] Modbus, I. D. A. (2004). Modbus application protocol specification v1. 1a. North

Grafton, Massachusetts (www. modbus. org/specs. php). [14] Erl T. Service-Oriented Architecture (SOA): Concepts, Technology, and Design (The Prentice Hall Service-Oriented Computing Series from Thomas Erl). Prentice Hall PTR, 2005. [15] Jeori Terlouw et al. An Assessment Method for Selecting an SOA Delivery Strategy: Determining Influencing Factors and Their Value Weights. Proceedings of the Busital workshop, 2009. [16] Modbus, I. D. A. (2004). Modbus Messaging on TCP/IP Implementation Guide v1. 0a. North Grafton, Massachusetts (www. modbus. org/specs. php).