1. Introducción
En el contexto tradicional de la automatización industrial, el control a nivel de planta se realiza de forma autónoma tomando las decisiones en función de datos locales. Convencionalmente, este tipo de sistemas trabajan de manera centralizada y no emplean tecnologías como protocolos de red basados en mensajes, sensores y actuadores inteligentes o nuevas tecnologías de producción (Takahashi, Yokoyama, & Morikawa, n.d.). Por otro lado, recientes tecnologías de comunicación e información como la computación en la nube (Cloud Computing), Internet de las cosas (IoT) o el procesamiento inteligente de datos (Big Data), requieren nuevos servicios de los sistemas de control de planta para lograr un rendimiento óptimo y eficiente (Windt, Böse, & Philipp, 2008).
Actualmente, con el fin de alcanzar los objetivos que propone el concepto de la Industria 4.0, es necesaria la cooperación de todos los participantes a través de las empresas que participan en el ciclo de vida del producto y, para ello, es de vital importancia la existencia de enlaces de comunicación seguros. En este contexto, la norma OPC UA (IEC 62541) es una alternativa prometedora ya que cuenta con una arquitectura orientada a servicios, que ofrece seguridad de datos y modelos de información fiables. Por desgracia, y quizás debido a la falta de disponibilidad de plataformas adecuadas, esta tecnología aún no se encuentra ampliamente utilizada a nivel industrial (Jazdi, 2014).
Adicionalmente, entre el conjunto de iniciativas que componen la Industria 4.0, una de las tecnologías de mayor proyección es la que se basa en la integración de sistemas ciber-físicos (CPPS). Los CPPS están compuestos por dispositivos de control con amplias capacidades de computación y comunicación, tanto local como remota. El IoT Industrial (IIoT) define un conjunto de tecnologías para el acceso remoto al sistema productivo. Englobada en este contexto, la comunicación “Máquina a Máquina” (M2M) define el intercambio de datos entre dos equipos remotos. Una de las ventajas de emplear comunicaciones M2M es que permite implementar máquinas sensibles al contexto (Scheuermann, Verclas, & Bruegge, 2015).
A nivel industrial, la norma IEC 61499 proporciona un marco para el desarrollo de aplicaciones basado en modelos para sistemas de control distribuido. El uso de esta norma en la Industria 4.0 permitirá modelar y desarrollar componentes software y hardware para sistemas de control distribuido (Kleanthis Thramboulidis, 2009), esto, posibilitará desarrollar CPPS para implementar los objetivos de la Industria 4.0
Con lo anteriormente expuesto, este trabajo presenta una plataforma CPPS de bajo coste y una arquitectura OPC UA fácilmente configurable, con servidores y clientes gestionados desde aplicaciones IEC 61499. Por lo tanto, la propuesta presentada permite una plataforma de software fácilmente desplegable destinada a recoger datos de proceso que posibilita la integración de dispositivos empleando comunicaciones M2M. El enfoque se centra en la integración de protocolos de redes industriales tradicionales como Modbus/TCP para acceso a datos de proceso desde servidores OPC UA. Con el fin de unir la brecha entre la tecnología y las fábricas reales, se propone una plataforma de bajo coste en el que es posible crear prototipos de CPPS que emplean comunicaciones OPC UA.
La estructura del artículo es la siguiente: la sección 2 se presenta los trabajos relacionados con este campo de estudio; la sección 3 exhibe la fundamentación teórica referente a la normativa IEC-61499 y OPC-UA, la sección 4 indica la solución propuesta la cual abarca el diseño de un conjunto de SIFB para IEC 61499 y se describe en detalle el archivo XML de configuración para servidores OPC UA, en la sección 5 se muestra el caso de estudio en el que el conjunto anterior de SIFBs se emplean para el gobierno de una planta; finalmente, en la sección 6 se presentan algunas conclusiones y trabajos a futuro
2. Trabajos Relacionados
El objetivo de esta sección es presentar la manera en otros autores que abordan la interpretación del CPPS. En este sentido, se presenta un conjunto de trabajos relacionados, paradigmas y tecnologías de desarrollo, que proporcionan arquitecturas orientadas a servicios y sistemas M2M, empleando el estándar IEC 61499.
Kang et al. (Kang, Kapitanova, & Son, 2012) proponen un middleware llamado Servicio de Distribución de Datos en Tiempo Real (RDDS) para CPPSs; este servicio facilita el intercambio de variables de una manera segura en este tipo de sistemas. El mecanismo de publicación/suscripción que se diseña e integra en el middleware tiene como fin el mejorar la fiabilidad y eficiencia en el tiempo de recogida de datos de los sensores a nivel de planta. La exactitud del modelo diseñado para sensores se mejora mediante una realimentación de los datos proporcionados por los controladores en tiempo real. Sin embargo, no se evalúa el uso de este middleware con redes que se utilizan actualmente en la industria, por lo que su aplicabilidad en comunicaciones industriales a corto plazo no sería factible.
Otro artículo interesante es el propuesto por Vicaire et al (Vicaire, Hoque, Member, Xie, & Stankovic, 2012), en el cual se proponen metodologías de programación para CPPSs basadas en modelos. El modelo de programación dado en este artículo es llamado “Bundle” y es adecuado para modelar tanto dispositivos de nivel de planta como sensores y actuadores. Sin embargo, no se atiende su integración con normas de automatización como IEC 61499 o IEC 61131.
Lee et al. (Lee, Bagheri, & Kao, 2014), (Lee, Lapira, Bagheri, & Kao, 2013) presentan trabajos relacionados con la aplicación de CPPSs en la automatización industrial en donde proporciona una revisión del Estado de Arte de los CPPSs, y valoran el impacto en la informática industrial de nuevas tecnologías como procesamiento inteligente de datos (Big Data), computación en la nube (Cloud Computing), etc. Como conclusión, la aplicación del CPPS y el análisis inteligente de grandes volúmenes de datos es una solución factible para proporcionar predicción y eficiencia en la personalización de productos, y mejorar la producción en una planta industrial. Sin embargo, no se abordan problemáticas como la reutilización de software, comunicaciones de planta o su uso en plataformas hardware para CPPS.
Actualmente, existen aplicaciones CPPS en empresas industriales reales. Uno de los principales retos es diseñar diferentes metodologías de modelado que permitan manejar sistemas de producción industrial complejos y donde se presume que su complejidad aumentará a futuro. En este sentido, para sistemas de automatización distribuida con procesos físicos integrados son necesarias metodologías de diseño basadas en técnicas de modelado como las que se pueden soportar bajo la norma IEC 61499. Desde la perspectiva del diseño, se debe tener modelos de software para las diversas plataformas existentes, modelos para la semántica de ejecución y modelos para las comunicaciones usando redes de comunicaciones industriales. Lo anteriormente expuesto se indica en el trabajo realizado por Dai et al (Dai & Chen, 2015) en donde el principal objetivo es presentar modelos integrados de control y software de comunicación para diseños de sistemas distribuidos en aplicaciones Ciber-físicas usando la norma IEC 61499. Sin embargo, el diseño para nuevas normas de comunicación como OPC UA no se encuentra cubierto en dicha investigación.
Ferrarini et al. (Ferrarini, Veber, & Milano, 2005), (Ferrarini, Veber, & Fogliazza, n.d.) promueve un modelado de procesos industriales bajo la norma IEC 61499 basado en la utilización de componentes de automatización industrial con una distribución similar a la estructura de planta o de la maquinaria de la división de procesos dentro de las fábricas. En esta misma línea, Thramboulidis (K. Thramboulidis, 2005) aplica técnicas de modelado usando la norma IEC 61499 y presenta la arquitectura denominada MIM la cual está basada y adapta conceptos de MDA (Model Driven Architecture) planteando un entorno para modelar componentes mecatrónicos que intervienen en procesos industriales.
Christensen (J.H.Christensen, 2000) propone patrones de modelado para diseño de sistemas industriales distribuidos como apoyo a la norma IEC 61499. De la manera similar, Serna et al. (Kleanthis Thramboulidis, 2009) proponen dos patrones de diseño para el manejo de los estados en FBs cuando existen errores en aplicaciones dentro de la norma IEC 61499.
Stojmenovic (Stojmenovic, 2014) considera a M2M como una tecnología clave para CPPS. El autor identifica el problema de que todas las investigaciones existentes en el ámbito de la comunicación M2M se basan en modelos a pequeña escala y soluciones centralizadas. En este sentido, propone un cambio de paradigma y sugiere que los nodos también deben tomar decisiones basadas en el conocimiento local, en lugar de sólo el reenvío de mensajes al sistema central. Usando este enfoque en sistemas de producción permitiría una fácil vinculación de los datos de planta, a partir de un conjunto de variables que se transmiten de una manera segura y en donde el control industrial se realiza también localmente. Sin embargo, en este artículo no se menciona cuáles serían las ventajas de aplicar esta arquitectura con normas creadas para la su aplicación en sistemas distribuidos como IEC 61499, o, desde el punto de vista de las comunicaciones, la utilización de normas como OPC UA que podrían brindar comunicaciones seguras.
En resumen, estas investigaciones se basan en la coincidencia de las técnicas de búsqueda de nuevas metodologías para producir sistemas distribuidos bajo la norma IEC 61499, pero no se centran en la integración con un protocolo de comunicación útil en fábricas inteligentes, tal como OPC-UA podría ser.
3.- Fundamentación Teórica
A continuación, se dará una breve explicación de la norma IEC 61499 y la arquitectura cliente/servidor OPC UA, las cuales son la pare medular del presente trabajo de investigación
3.1. OPC-UA
OPC UA representa la evolución de normas anteriores como OPC-DA, OPC-A&E y OPC HDA con el fin de proporcionar una arquitectura abierta e independiente de proveedor (GmbH, 2010). Con el fin de solucionar los problemas de portabilidad de las normas anteriores, el servidor OPC UA emplea una pila de comunicación que puede ser utilizada directamente en los sistemas de automatización. OPC UA proporciona un medio adecuado para una comunicación fiable, robusta y de alto rendimiento para aplicaciones industriales de automatización. Además, OPC UA puede ser integrado en dispositivos empotrados como, por ejemplo, los que implementan CPPSs.
OPC UA va más allá de ser un medio de transporte, ya que incluye un mecanismo de modelado capaz de soportar los posibles modelos para una planta industrial. OPC UA ofrece acceso a la información a través de modelos de planta. El uso de la arquitectura propuesta por OPC UA permite una descripción completa de los datos del sistema, independientemente de su complejidad. Este enfoque introduce el concepto de modelo de proceso para una mejor adaptación a las necesidades de las aplicaciones industriales modernas.
Con los servidores OPC UA es posible una representación basada en el modelo del proceso de planta que consiste en un conjunto de objetos que el servidor pone a disposición de los clientes. Estos objetos representan los datos de proceso subyacentes en tiempo real (Van Der Linden et al., 2011).
3.2. IEC-61499
4DIAC es un entorno de desarrollo compatible con la norma IEC 61499 para el diseño y ejecución de aplicaciones y que se ejecuta en plataformas heterogéneas (Claassen, Rohjans, & Lehnhoff Member, 2011). En particular, en este trabajo se ha utilizado 4DIAC-IDE como entorno de desarrollo para aplicaciones de control distribuido. Este entorno proporciona portabilidad, interoperabilidad, así como capacidades de configuración. El runtime utilizado es FORTE (4DIAC-RTE), que permite la ejecución de aplicaciones IEC 61499 dentro de dispositivos empotrados de bajo coste. FORTE proporciona portabilidad a una amplia variedad de sistemas operativos, entre ellos Windows y Linux. Mientras que 4DIAC-IDE sólo puede ser ejecutado en la plataforma de desarrollo, el runtime FORTE se puede ejecutar en cualquier dispositivo del sistema de automatización distribuida.
La entidad clave en la norma IEC 61499 es el Bloque de Función (FB). El FB encapsula en un mismo elemento los algoritmos de control y comunicación haciéndolos transparentes al usuario. Para el desarrollo de los FBs prácticamente se pueden emplear cualquier lenguaje de programación, incluyendo IEC 61131, Java, C/C++. El Bloque de Función de Interfaz de Servicio (SIFB) es uno tipo de FB que permite abstraer el acceso a recursos hardware, comunicaciones, así como a recursos empleados por la Interfaz de Programación de Aplicaciones (API).
4.- Solución Propuesta
Se procede a detallar el hardware seleccionado para implementar CPPS de bajo costo, así como también, la arquitectura software desarrollada e implementada en IEC-61499 para comunicaciones M2M a nivel industrial
4.1 Arquitectura Hardware
La tarjeta Raspberry Pi 2 modelo B (RPi2) es Ordenador de Placa reducida (Single Board Computer - SBC), que permite ejecutar diferentes distribuciones de Linux. En nuestro caso de estudio se utiliza Raspbian que es una versión de Debian Jessie. Desde el punto de vista hardware, esta plataforma integra un procesador ARM Cortex-A7 de cuatro núcleos de 900 MHz con 1 GB de RAM. La tarjeta RPi2 también proporciona una GPIO con 40 pines para la interacción con el mundo físico. Además incluye 4 puertos USB, puerto Ethernet y una ranura de expansión para tarjeta micro SD.
La tarjeta BeagleBone Black (BBB) es otro SBC que ejecuta otra distribución Linux Debian Jessie. La BBB se basa en un microprocesador AM3358 de 1 GHz, con 512 MB de RAM de tipo DDR3. Posee un puerto de propósito general de E/S (GPIO) de 69 pines para la interacción con el mundo físico. Además, entre otras características cuenta con un puerto USB y un puerto Ethernet.
La placa Arduino UNO se utiliza para recoger las variables a nivel de la planta del proceso industrial. Arduino UNO dispone de 14 E/S digitales y 4 entradas analógicas; de esta manera es posible recoger entradas analógicas o digitales de una amplia variedad de sensores, y controlar diferentes actuadores.
Sin embargo, con el fin de hacer posible que estas tarjetas trabajen con señales industriales, es necesario emplear una tarjeta de expansión que adapten las señales de los puertos I/O. En este caso en particular, se ha diseñado, implementado y usado una tarjeta de diseño propio (Figura 1) que proporciona 8 entradas digitales y 8 salidas digitales de 24V por cada dispositivo
Fig. 1:
Plataforma Hardware
4.2 Arquitectura software: Conjunto de SIFBs para OPC-UA
Para la creación de los SIFBs se ha empleado la infraestructura proporcionada por el software 4DIAC-IDE para IEC 61499. Este conjunto de SIFBs encapsula las operaciones que ofrecen servicios de OPC UA.
4.2.1. SIFB OPCUA_SERVER
Mediante la utilización de este SIFB es posible gestionar la configuración y el funcionamiento de un servidor OPC UA. El servidor OPC UA se configura empleando un archivo en formato XML. Este archivo incluye todos los parámetros esenciales para el servidor OPC UA como la dirección URL, el identificador URI, nombre del proveedor, el nombre del servidor, la versión, etc. Además, este archivo de configuración declara el Espacio de Direccionamiento (Adress Space) con sus Tipos de Nodo (NodeTypes) e Instancias de Nodo (NodeInstances). En el espacio de direccionamiento se definen las variables de datos suministardas por el servidor OPC UA (DataVariables). Además, dentro de la configuración se definen otras dos secciones:
Field Devices: En esta sección se agrupan las definiciones de los dispositivos de campo a los que tiene acceso el servidor. También se definen los datos de proceso (FieldData) suministrados por cada dispositivo. Los dispositivos de campo se caracterizan por el protocolo de comunicación o el mecanismo de acceso a los datos de proceso, y la información relacionada con el mismo (Figura 2).
Data Mapping: En esta sección se definen las relaciones existentes entre las variables de datos (DataVariables) ya declaradas la sección del Espacio de Direccionamiento (Address Space) y sus correspondientes datos de proceso (FieldData) de los dispositivos de campo (FieldDevice).
Fig. 2:
Configuración de Dispositivos de Campo
Además de eventos comunes a otros SIFBs como INIT, REQ, INITO y CNF (Figura 3), también presenta los parámetros de entrada y salida siguientes:
QI (BOOL): Este dato de entrada trabaja conjuntamente con el evento INIT para conectar o desconectar el servidor OPC UA. Si se solicita el evento INIT, y si QI es VERDADERO (TRUE), el servidor OPC UA conecta; si QI es FALSO (FALSE), el servidor OPC UA finaliza su ejecución.
CONFIGFILE (WSTRING): Contienen el nombre completo del archivo XML de configuración.
QO (BOOL): Informa sobre cómo ha finalizado de último procedimiento ejecutado.
STATUS (STRING): Ofrece información del estado del servidor.
Fig. 3:
SIFB OPCUA_SERVER
4.2.2. SIFB OPCUA_CLIENT_READ
Este SIFB permite implementar un cliente OPC UA capaz de consultar de manera síncrona variables de un servidor OPC UA.
Fig. 4:
SIFB OPCUA_CLIENT_READ
Además de los eventos comunes, este SIFB presenta los siguientes parámetros de entrada y salida (Figura 4):
URLSERVER (WSTRING): Indica la URL del servidor OPC UA.
DATANAME (WSTRING): Nombre de la variable a acceder en el servidor OPC UA.
RD (ANY): Valor del dato que devuelve el servidor OPC UA al cual el cliente está conectado. El tipo de este parámetro es ANY para mejorar su reutilización en cualquier tipo de aplicación.
SOURCETIMESTAMP (DATE AND TIME): Indica la información de tiempo asociada al elemento en el recurso de origen.
SERVERTIMESTAMP (DATE AND TIME): Indica la información de tiempo asociada al elemento en el servidor OPC UA.
4.2.3. SIFB OPCUA_CLIENT_WRITE
Mediante este SIFB (Figura 5) se crea un cliente para la escritura síncrona de variables en su servidor OPC UA. Presenta los siguientes parámetros:
TYPE (WSTRING): Expresa el tipo del dato para el valor que se va a escribir en el servidor OPC UA.
SD (ANY): Indica el valor del dato a escribir. Como en el SIFB anterior, el tipo de este parámetro es ANY con el fin de aumentar la generalidad.
Figura 5:
SIFB OPCUA_CLIENT_WRITE
4.2.4. SIFB OPCUA_CLIENT_SUBSCRIBE
Además de los servicios de lectura y escritura síncrona, OPC UA permite el mecanismo de subscripción. La suscripción mantiene una copia local de los parámetros del elemento a ser supervisado. Estas copias locales pueden ser alteradas mediante la actualización de sus propiedades sin afectar el estado en el servidor. Para implementar este mecanismo se ha creado un SIFB (Figura. 6) que permite crear clientes que realizan suscripción para monitorizar variables de servidores OPC UA.
Fig. 6:
SIFB OPCUA_CLIENT_SUBSCRIBE
Los parámetros de entrada y salida de este SIFB son:
MODE (WSTRING): Se permiten dos modos para monitorizar las variables del servidor OPC UA: “Reporting” y “Sampling”.
PERIOD (ULINT): Fija el período de muestreo en milisegundos para los elementos en modo de muestreo.
RD (ANY): Proporciona el valor de los elementos monitorizados suministrados por el servidor OPC UA.
SOURCETIMESTAMP (DATE AND TIME): Indica el Timestamp asociado al elemento del recurso de origen.
SERVERTIMESTAMP (DATE AND TIME): Muestra el Timestamp asociado al elemento del servidor OPC UA.
5. Caso de Estudio
El caso de estudio propuesto describe un sistema de industrial a escala con el objetivo de mostrar una aplicación de automatización industrial. En particular, la planta de producción es una línea de montaje con tres estaciones FESTO® como se representa en la Figura 7. La Estación de Manipulación recoge desde una posición de entrada las piezas de trabajo que deben procesarse y las deja sobre una rampa que alimenta siguiente estación; la Estación de Transporte traslada y selecciona las piezas; mientras que la Estación de Almacenamiento completa el procesamiento de la línea de montaje.
La arquitectura de hardware y software de bajo coste comprende: una tarjeta Raspberry Pi 2 modelo B como controlador del proceso y que integra un servidor OPC UA, una BeagleBone Black como sistema de supervisión y monitorización, y dos tarjetas Arduino UNO como dispositivos entrada/salida de periferia distribuida trabajando como esclavos Modbus/TCP.
Como se puede observar en la Figura 7, la Estación de Almacenamiento y la Estación de Transporte se asocian a la red industrial mediante el uso de esclavos que utilizan el protocolo Modbus/TCP integrado en tarjetas Arduino UNO. La tarjeta RPi2 tiene acceso directo a las E/S de la Estación de Manipulación y, como a su vez es maestro Modbus/TCP, puede acceder a las E/S de las otras estaciones del proceso. En la Figura 7 también se puede observar el archivo de configuración XML del servidor OPC UA con el cual se consigue el acceso a las variables locales en la RPi2 y las variables remotas de los esclavos como maestro Modbus/TCP.
La RPi2 controla las tres estaciones e integra el servidor OPC UA. Para ello se ejecuta una instancia del runtime FORTE, el cual permite a los SIFBs anteriormente presentados llevar a cabo el control de todo el proceso y la gestión del servidor OPC UA.
Fig. 7:
Caso de estudio IEC 61499 y fichero de configuración del servidor OPC UA en formato XML
Los clientes OPC UA remotos, así como la aplicación de supervisión que se ejecuta en la tarjeta BBB, pueden leer/escribir o suscribirse a los datos de proceso mediante el conjunto SIFB anteriormente descrito. Por ejemplo, la Figura 7 muestra la aplicación de supervisión de la Estación de Transporte bajo la norma IEC 61499.
El servidor OPC UA y todas las características de los clientes se integran en una librería propia implementada utilizando una pila OPC UA en C ++. La librería OPC UA incluye el acceso a los esclavos Modbus/TCP y al GPIO del RPi2. Al mismo tiempo, esta librería OPC UA se ha integrado en el runtime FORTE, de esta manera las características del servidor y cliente están incrustadas en el runtime.
6. Conclusiones
Este trabajo presenta un enfoque para acceder a los datos de campo en sistemas de automatización industrial en una arquitectura CPPS de bajo coste empleando comunicaciones OPC UA y bajo la norma IEC 61499. La utilización de este tipo de sistemas ayuda a introducir nuevos conceptos de arquitecturas CPPS dentro del paradigma de la Industria 4.0. La arquitectura propuesta proporciona una infraestructura que permite comunicaciones M2M a nivel de planta y la integración en el proceso productivo de dispositivos de niveles superiores.
Se propone un conjunto de SIFBs para implementar servidores y clientes OPC UA, incluidos los mecanismos de suscripción. Estos bloques de función permiten, de una manera rápida y sencilla, la construcción de nuevas aplicaciones distribuidas basadas en componentes mediante entornos de programación bajo la norma IEC 61499.
Futuros trabajos se centran en el desarrollo de nuevas funcionalidades para la mejora de la integración de CPPSs en plantas industriales, adecuando modelos compatibles OPC UA a otros estándares industriales como ISA 95 o AML.
