OPC UA es un o de los protocolos IoT por excelencia. Sus grandes ventajas son que se trata de un protocolo abierto y multiplataforma. Esto nos permite conectar dispositivos de cualquier fabricante a nuestra red de IoT.

Si trabajas en un entorno industrial o en el ámbito de la automatización seguro que te has enfrentado a este problema. En tu instalación dispones de máquinas de Honeywell, de Siemens, de ABB, de Schneider… y cada una es diferente a la anterior, hablan su propio «idioma». Esto se debe a que usan protocolos propietarios específicos de ese fabricante.

Afortunadamente, hace muchos años alguien se dio cuenta de que lo habitual en las plantas industriales es que los sistemas de todos los fabricantes convivan y, para algunas tareas, necesiten comunicarse entre sí. Es por ello que aparecieron los protocolos abiertos, con unas especificaciones conocidas por todos, y que permitían, por ejemplo , conectar un PLC de Siemens a un SCADA de Honeywell.

OPC UA es uno de los más populares. Es la implementación actual de OPC, una especificación ideada por un consorcio industrial denominado OPC Foundation. No obstante ese OPC clásico (así se le llama ahora tenía el gran inconveniente de su dependencia de DCOM, una característica de Microsoft Windows, lo que hacía que OPC no fuese tan libre como demandaba ese espíritu de «entendimiento» entre dispositivos. OPC UA (Unified Architecture) elimina esa dependencia y permite emplear la tecnología OPC en todos los sistemas operativos, lo cual permite una enorme libertad en el diseño de sistemas y reducir enormemente los costes de integración.

¿Qué papel juega OPC UA?

Como he dicho anteriormente , OPC UA es uno de los «lenguajes» que pueden hablar nuestras máquinas y es un lenguaje que conocen todas las máquinas, por lo que es una opción a considerar si queremos intercambiar información entre ellas.

¿Qué necesitaremos entonces? Un «traductor», esto es, un gateway IoT.

OPC UA se basa en la arquitectura cliente–servidor. Si recuerdas el artículo que dediqué al protocolo MQTT, en aquella ocasión habla de publisher y subscriber. En OPC UA, hablaremos de cliente y servidor, y, como en todos los sistemas que se basan en esta arquitectura, tendremos un servidor, que ofrecerá los datos a la red y varios clientes, que se conectarán a este servidor para obtener los datos deseados.

Integración en un sistema IoT

Si sólo tenemos dos elementos en nuestra red, la arquitectura se simplifica enormemente, pues uno de ellos será el servidor y el otro, el cliente. Pero lo habitual en un sistema de complejidad media-alta, es que convivan múltiples dispositivos y múltiples protocolos, de ahí la mención que hacía al gateway IoT. Lo ideal es que dispongamos en nuestra red de ese elemento que pueda «escuchar» y «hablar» a la vez en múltiples idiomas y con múltiples interlocutores Si retomamos la terminología de MQTT, ese broker que media entre todos los nodos de la red.

Ese gateway puede tratarse de un software instalado en alguna de las máquinas del ecosistema, o de un software embebido en algún dispositivo hardware. Aquí entra en juego la gran ventaja que comentaba de OPC UA frente a OPC clásico. Gracias a OPC UA, hoy en día el hardware para montar una arquitectura OPC UA no tiene por qué ser Windows. Esto nos va a permitir disponer de gateways muy muy económicos, dispositivos diseñados exprofeso para esta función y con una gran funcionalidad exenta en muchos casos de pago de licencias, de mantenimiento etc. Esto supone una gran revolución en el mundo de la integración de sistemas y una base excelente para tareas ulteriores, como las tecnologías big data.

Elección del servidor OPC UA

Para el artículo de hoy, voy a usar la plataforma vNode. En Instalando Node-RED usé Node-RED y, si investigas un poco, también descubrirás cómo usar OPC UA con ella,.

vNode es una herramienta muy sencilla de utilizar, pues se compone, como Node-RED, de módulos con una funcionalidad específica, de modo que para ponerlos en marcha tan sólo necesitaremos activar el módulo deseado y realizar la configuración adecuada.

Cabe decir quevNode es un software comercial y, como tal, tiene un coste. Por lo que si vas a emplearlo a gran escala en tu planta, tendrás que pagar las correspondientes licencias. La ventaja es que estas licencias son modulares, pagas únicamente por los módulos que vas a emplear, y cuentas con un soporte técnico y unos recursos de documentación y formación muy completos.

Despliegue del proyecto

En este artículo vamos a simular un sencillo sistema en el que vamos a extraer información de un servidor modbus (otro de los protocolos ampliamente empleados en industria), que podría ser cualquiera de las máquinas que aparecen a la izquierda en el gráfico que puse arriba y vamos a configurar un servidor OPC UA en vNode.

Para ello, en vNode deberemos usar un módulo cliente modbus, un módulo servidor OPC UA y hacer las configuraciones oportunas. Una vez hecho esto, podremos leer los datos generados en el servidor modbus en un cliente OPC UA, de forma opaca a los extremos de la cadena, gracias al uso de este gateway/»traductor» en nuestro sistema. ¿Magia?… No, es IoT 😊🙌.

Como servidor MODBUS emplearemos el simulador ModRSsim2 (o el 1, yo tengo la primera versión). Al abrir este simulador veréis una sencilla matriz de direcciones modbus a partir de la 40001, que es donde se encuentran los analog output holding registers (es decir, las salidas analógicas en las que podremos escribir el valor que queramos).

Como cliente OPC UA usaremos Matrikon OPC UA explorer. Matrikon es uno de los referentes en lo que a OPC UA se refiere. De la misma manera que vNode, ofrece algunas herramientas y funcionalidades de manera gratuita o en versión demo, pero si queremos montar un ecosistema profesional, tendremos que licenciar aquellas partes del software que nos sean de interés.

Y ahora viene lo divertido… ¿Cómo pasamos los datos de uno a otro? Aquí es donde entra en juego vNode.

Para descargar su software debemos registrarnos en su página web y nos enviarán un enlace. El proceso de instalación es sumamente sencillo y, si mantenemos la configuración por defecto, finalmente tendremos acceso a la plataforma a través del puerto 8003 de nuestro PC (recordad, por ejemplo, que Node-RED usaba el 1880).

Pasos a seguir

Hecho esto, la filosofía para desplegar cualquier funcionalidad será siempre la misma:

• Si vamos a System > Config aparecerá un menú (Explorer) con los componentes del nodo.
• Si pulsamos en el apartado Modules, podemos crear un Model. Esto es el tipo de módulo que queremos instalar. En nuestro caso necesitaremos un módulo ModbusClient y un módulo OpcUaServer. Por lo general, en este punto no tenemos que tocar mucho la configuración.
• Creado el módulo ModbusClient, tenemos que ir a él y bajo el apartado Model, crear un nuevo Channel. En este Channel tenemos que indicar la dirección y el puerto del Host (nótese que estamos usando MODBUS TCP/IP).
• Y dentro del Channel crearemos un Device. Importante habilitar la recolección de datos (no es extraño olvidarse de esto).
• Para el OpcUAServer, basta configurar la dirección y el puerto del Host.
• Finalmente tenemos que crear un tag que «beba» del servidor modbus. Esto lo haremos en el apartado Tags, y ahí, en Source, marcaremos el tipo de módulo que vamos a usar y las configuraciones concretas. En este caso, Device y Modbus address.

Vídeo demo

Para clarificar el apartado anterior, te dejo un vídeo demo con el proceso de configuración. Si aún así tienes dudas, recuerda que puedes hablar conmigo por los medios de la sección CONTACTO.