COMMS - Protocolo IO-Link

El protocolo IO-Link es un estándar de comunicaciones (IEC61131-9) utilizado para la conexión de sensores y actuadores.

La sensórica tradicional se basa en el envío de señales digitales/analógicas, sin proporcionar ninguna otra información. No obstante, la tecnología IO-Link permite la conexión de sensores y actuadores capaces de producir y consumir datos adicionales de interés para el sistema.

Por ejemplo, un sensor fotoeléctrico estándar solo tiene dos estados lógicos (encendido o apagado/desconectado).
En cambio, una fotocélula IO-Link también podría informarnos de, por ejemplo:
- Calidad de detección
- Detección analógica (distancia, color...)
- Modo de operación
- Tiempo de funcionamiento
- Detección de desconexión
  etc.

Estas características hacen del IO-Link una tecnología ideal para la integración en soluciones IT. Pues, en ciertas máquinas, los datos que puedan proveer estos sensores y actuadores permiten la toma de decisiones a nivel de producción (mantenimiento preventivo, análisis y estadísticas, etc).
Se trata de una solución para la digitalización (IoT) en la capa de "Edge computing", dado que los datos recopilados son utilizados onsite (en la programación de la máquina).

En el presente artículo se presentará este protocolo, detallando como funciona y como se debe implementar dentro de un sistema automatizado.

¿ESPECIFICACIONES?

El IO-Link es un protocolo de comunicación serie con una arquitectura maestro-esclavo, donde los eslcavos (sensores/actuadores) se conectan a un único maestro con el que intercambian los datos 
La unidad maestra IO-Link se conecta como unidad subordinada al PLC. Normalmente en el rack del mismo o a través de buses de campo (p.e. Profinet, EtherCAT, EtherNet/IP, etc). Por lo que podemos encontrar más de un maestro en una misma arquitectura de máquina.

En esta tecnología, la conexión entre maestro y esclavo se realiza punto a punto (aunque existe la versión inalámbrica). Y se requiere de un cable estándar para sensor, de 3 hilos.
El maestro incorpora varios puertos para la conexión de los dispositivos. Lo común es trabajar con conectores estandarizados M5, M8 y M12.
Pero hay unidades que admiten el cableado simple a bloque de terminales.

Se debe tener en cuenta que este protocolo solo admite distancias de hasta 20 metros.

La comunicación entre maestro y esclavo es bidireccional y opera a 24Vdc.
La transmisión IO-Link suele tomar 400us, a una velocidad de 230kbaud.

¿CÓMO FUNCIONA?

Los puertos en el maestro IO-Link admiten distintos modos funcionamiento. Estos son:
- Modo IO-Link: El puerto se utiliza para comunicaciones con protocolo IO-Link.
- Modo DI: El puerto trabaja como una entrada digital convencional.  
- Modo DQ: El puerto actúa como una salida digital convencional.
- Modo inactivo: El puerto no se va a utilizar, por lo que se desactiva.
Entonces, en un mismo maestro se pueden configurar los puertos con distintos propósitos. No es estrictamente necesario utilizar el protocolo IO-Link, lo que permite trabajar también con sensores estándares (en modo DI y DQ).

Cuando un puerto trabaja en modo IO-Link, es cuando se utiliza el protocolo en cuestión. En el autómata se debe configurar el intercambio de datos entre el maestro y el dispositivo.
En ocasiones, para compatibilizar el uso de dispositivos de terceros con un maestro IO-Link, es necesario utilizar un archivo de descripción IODD (Input Output Data Description) con extensión xml.
Define el componente y permite configurar los datos a los que tendrá acceso el maestro.

¿DATOS INTERCAMBIADOS?

La diferencia clave entre los sensores/actuadores estándares reside en que los IO-Link pueden transmitir 4 clases de datos con el maestro. Estas son:

- Datos del proceso: Intercambio cíclico
Estos datos se intercambian automáticamente en intervalos regulares predefinidos. Incluyen los valores analógicos y estados de conmutación, es decir, el grueso de los datos requeridos para el proceso.

- Estado de valor: Intercambio cíclico
Se transmiten junto a los datos del proceso e indican al maestro si estos son validos o no. Esta información también se conoce esta como "Port Qualifier". 

- Datos del dispositivo: Intercambio acíclico
Son datos que se intercambian a petición del maestro, normalmente desde el programa del autómata. Suelen incluir información de identificación, diagnóstico o parámetros del sensor/actuador.

- Eventos: Intercambio acíclico
Se transmiten cuando se dispara algún error o advertencia en el dispositivo esclavo. Normalmente, para avisar de alguna malfunción (p.e. desconexión, cortocircuito, suciedad, sobrecalentamiento, etc). 

La transmisión de los datos intercambiados cíclicamente y acíclicamente son independientes. No se ven afectadas entre ellas, por lo que las tramas críticas no tienen que esperar hasta que se envíen los datos almacenados en el buffer. .

¿CONCLUSIONES?

Con la rápida adopción del IoT en la industria, los desarrolladores necesitan un medio para la implementación de sensores y actuadores inteligentes.
El IO-Link es un protocolo robusto y estandarizado, con una interfaz fácil de usar, por lo que se presenta como una alternativa muy potente.

La integración del protocolo IO-Link en un sistema ya existente resulta muy directa. Es una tecnología muy flexible.
Hemos visto que los maestros IO-Link pueden trabajar como subordinados en distintos buses de campo. Además, admiten el uso de sensores convencionales en sus puertos, lo que hace más sencillo el poder actualizar una instalación ya existente.

Antes de pensar en una solución IO-Link, es imprescindible comprender como y porque se quiere utilizar, y evaluar como implementar el protocolo de una forma eficiente.
Es importante saber en que dispositivos nos sería útil este protocolo y que datos son imprescindibles para la máquina o sistema... Pues, en ocasiones, la recolección de datos en exceso puede ser contraproducente.
Nos debemos centrar en una producción más eficiente, segura y con tiempos de inactividad mínimos. 

COMMS - Protocolo PROFINET

El protocolo de comunicaciones PROFINET (Process Field Network) es un estándar abierto de Ethernet Industrial basado en TCP/IP e IT.
Es el sucesor del PROFIBUS DP (protocolo serie), con el que comparten propiedades al tener un mismo origen. Pues ambos son mantenidos por una misma organización. 

Esta tecnología permite el intercambio de datos entre los dispositivos de control y de campo en tiempo real. Siendo así, resulta ideal para la automatización de máquinas e incluso como enlace con el mundo IT.
Es uno de los estándares líder en Europa, en todas las áreas de automatización (tanto a nivel de proceso como de planta). Respaldado y utilizado por innumerables fabricantes.

Este artículo pretende exponer en detalle este protocolo tan comunmente utilizado, con el objetivo de presentar las nociones básicas respecto a como trabaja y su implementación. 

¿CÓMO FUNCIONA?

PROFINET, a diferencia de muchos otros protocolos basados en Ethernet Industrial, trabaja con un modelo consumidor-proveedor para el intercambio de datos. 
En una arquitectura maestro-esclavo, el maestro tiene control unidireccional sobre todos los esclavos... Pero el modelo proveedor-consumidor permite al maesto trabajar como proveedor de datos hacia los elementos de campo y, a su misma vez, como consumidor de aquellos datos que le son devueltos.

Entonces, los roles que encontramos en una tipología PROFINET, son los siguientes:
    - Controlador: Maestro (comúnmente un único PLC) que comunica con los demás
    equipos de la red y almacenan toda la información de la misma.
    - Dispositivo: Cualquier esclavo de campo que puede ser monitorizado por el controlador
    y, puntualmente, puede enviar información de diagnóstico al supervisor.
    Los dispositivos se definen mediante un nombre PROFINET único e irrepetible. Y
    requieren una dirección IP (en rango con la del controlador).
    - Supervisor: Típicamente es el rol de un software de programación... Este rol sirve para
    monitorizar el estado de los dispositivos, asignar direcciones IP y/o nombres PROFINET,
    hacer tareas de diagnóstico en la red, etc.

El controlador puede intercambiar los datos de forma cíclica y acíclica con los dispositivos y aprovecha la naturaleza full-duplex del medio físico Ethernet.
La comunicación entre controlador y dispositivos es simultánea en ambos sentidos, lo que lo hace un protocolo muy flexible.

Según con que equipo comunique el controlador y los requerimientos de dicha comunicación, este protocolo utiliza los llamados perfiles PROFINET. Básicamente son telegramas estándares dentro del protocolo diseñados para funcionalidades específicas.
PROFIsafe para la seguridad funcional (safety integrated), PROFIdrive para accionamientos (motion control) y PROFIenergy para aplicaciones de gestión de energía en sistemas de producción.

¿PASOS EN LA COMUNICACIÓN?

En la línea de lo comentado, la función básica del PROFINET es el intercambio de datos entre controlador y dispositivos a controlar (con la filosofía consumidor-proveedor).
Los pasos al establecer dicha comunicación son los siguientes:

1) Resolución de nombre y direcciones: 
    Los dispositivos se identifican al controlador PROFINET mediante un nombre. Entonces, el
    controlador les asigna la dirección IP.

2) Establecimiento de conexión:
    El controlador envía la solicitud de conexión al dispositivo. Esta solicitud ya determina
    ítems críticos como los datos a intercambiar, la velocidad y el tiempo de vigilancia
    (watchdog) para asegurar que no ha habido desconexión.

3) Intercambio de datos: 
    En este punto, una vez conectados controlador y dispositivo, ya empiezan a intercambiar
    datos cíclicamente (según lo preestablecido).
    El controlador procesa las entradas, controla las salidas y notifica las alarmas del
    dispositivo.

4) Desconexión de equipos:
    Normalmente esta situación solo se da cuando se supera el tiempo de vigilancia de
    comunicaciones establecido entre controlador y dispositivo (watchdog). Lo que indica un
    fallo al actuar los datos de E/S en el proceso cíclico...
    No obstante, el controlador también podría desconectarse intencionadamente de algún
    dispositivo.

¿INTERCAMBIO DE DATOS?

Con PROFINET, se suelen diferenciar dos canales de comunicación según el "modo" en el que queramos comunicar un controlador con un dispositivo.
Con el uso de uno u otro, cambia la velocidad y el determinismo del intercambio de datos, por lo que se escogen según los requerimientos del proceso... 
No obstante, las dos variantes suelen coexistir en la misma red. Estas son:  

- PROFINET RT: Real Time

Posibilita la comunicación con dispositivos en tiempo real, con retardos de hasta 1 a 10 ms.
Para su implementación no se precisan requisitos de hardware adicionales o topologías específicas.
Suele ser el más utilizado... Por ejemplo, al comunicar con unidades de E/S distribuidas, controlar comandos de variadores de frecuencia y demás funcionalidades básicas.

- PROFINET IRT: Isochronous Real Time
Este canal se utiliza en aquellas comunicaciones donde se exige una alta precisión y determinismo. Pues garantiza una comunicación isócrona entre el controlador y los dispositivos de campo, con tiempos inferiores a 1 ms.
En este caso, el hardware involucrado debe soportar implícitamente dicha variante y solo es aplicable a unas topologías de red específicas.
Generalmente, se usa en aplicaciones de motion. Donde los servomotores que deban realizar posicionados precisos y/o tareas de sincronismo. 

A parte, PROFINET dispone de un canal de comunicación NRT (Non Real Time). Este utiliza todas las capas del modelo OSI y solo trabaja mediante el direccionamiento por IPs.

Presenta una mayor latencia que los anteriores (entre 30 y 100 ms), pero permite acceder a los dispositivos a través de enrutamientos e internet.
Solo se utiliza con fines de supervisión (software), visualización (HMIs), entre otros intercambios de datos que no requieren altas velocidades. 

¿CONFIGURACIÓN?

Solo nos queda ver, a nivel práctico, como se debe hacer la puesta en marcha de una red PROFINET para poder establecer las comunicaciones expuestas anteriormente... 

1) Importar archivo GSDML de dispositivo
En el software del controlador, incluir este archivo de descripción del dispositivo (.xml).
El fabricante del equipo es quien debe subministrar este archivo. Contiene toda la información PROFINET del equipo i es imprescindible para poderlo enlazar con el controlador.

2) Configuración de dispositivo
Como se ha indicado anteriormente, es necesario dar IP y nombre PROFINET al dispositivo importado. 
En este punto, el equipo ya es visible en la red para el controlador.

3) Asignar dispositivo al controlador
Se enlaza el dispositivo previamente configurado con el controlador que se va a intercambiar los datos.
En este punto se define el canal de comunicación RT, IRT o NRT, lo que define la velocidad (tiempo de reloj del controlador) y determinismo de las comunicaciones.

4) Configurar el intercambio de datos cíclico
Por último, solo queda detallar que mapeado de variables del dispositivo en el controlador.
Es aquí donde se puede definir el uso de un perfil PROFINET concreto (tramas predefinidas).

COMMS - Protocolo Modbus

El protocolo de comunicaciones Modbus fue desarrollado y publicado por la empresa Modicon en 1979 (posteriormente absorbida por Schneider Electric).

Se trata de un estándar abierto respaldado por muchos fabricantes del mundo de la automatización, lo que permite integrar distintos dispositivos de terceros en una misma red.

Este protocolo se utiliza sobre distintos medios físicos, tanto serie (Modbus RTU) como Ethernet (Modbus TCP). 
Vía serie, el interface RS-422/485 es el más común, puesto que admite conexiones multipunto a mayores distancias y más velocidad (que, por ejemplo RS-232).
En la actualidad, el Modbus TCP es el más utilizado. Pues una red Ethernet resulta mucho más flexible, eficiente y fiable. 

Este artículo pretende presentar este protocolo tan comunmente utilizado, con el objetivo de exponer las nociones básicas para saber como funciona y poder utilizarlo. 

¿CÓMO FUNCIONA?

Es una tecnología con una arquitectura maestro-esclavo o cliente-servidor. 
Este protocolo no admite más de un maestro y, por regla general, permite la conexión de hasta 255 esclavos.

Cada uno de los esclavos se identifica mediante una dirección de esclavo (número). 
El ID de esclavo debe ser único para cada uno de los dispositivos de la red.

Dichos esclavos, tienen un mapeado de objetos Modbus.
Esos objetos pueden ser tanto a nivel de bit (Output Coils e Input Contacts), como de canal (Holding Registers e Inlput Registers). 

El maestro hace las peticiones de lectura y escritura de esos datos mediante distintas funciones Modbus como las que se muestran en la siguiente tabla:

¿PASOS EN LA COMUNICACIÓN?

Una vez se han configurado el maestro (cliente) y esclavo (servidor), este es el procedimiento que se sigue para establecer comunicaciones:

1) El maestro envía la petición de lectura/escritura al esclavo. Tiene el siguiente formato:
    - Dirección de esclavo: Indica que esclavo recibe la petición.
    - Código de función: Confirma que acción se llevará a cabo.
    - Datos a leer/escribir: Referente a los objetos Modbus del esclavo.
    - Comprobación de errores: Verifica la trama.

2) El esclavo envía una respuesta acorde a la petición del cliente.
El formato de trama es muy similar al del envío. 

3) El cliente verifica que el contenido de la respuesta es correcto. 
La detección de error se hace mediante un código CRC.

Dejo aquí un enlace donde, a parte de profundizar en el funcionamiento de este protocolo, detalla ejemplos de tramas (envíos y respuestas) de las funciones Modbus más comunes.

No obstante, se debe precisar que el Modbus TCP (por Ethernet) presenta ciertas peculiaridades...

- Se debe establecer conexión con la IP del esclavo. También se puede cerrar.
Normalmente, los equipos utilizan el puerto 502 (TCP) para este protocolo.

- El formato de trama es similar y tiene la misma filosofía, pero guarda diferencias.
Los mensajes Modbus se integran en paquetes Ethernet con el formato prescrito para este medio físico.

¿PRECAUCIONES?

Muchas veces se requiere programar los maestros y esclavos para usar el protocolo Modbus. Si son PLCs, normalmente se hace mediante FBs desarrollados por el fabricante.
Aún así, ciertos equipos ya incorporan Modbus de forma inherente.

Es un protocolo poco eficiente... No se suele recomendar para el intercambio de grandes cantidades de datos o altas velocidades de comunicación.
El maestro se limita a enviar peticiones y recibir la respuesta. 

El Modbus no es un protocolo seguro.
No soporta ningún tipo de seguridad, por lo que cualquiera que tenga acceso a la red podría interceptar los datos transmitidos.

Hay variantes de Modbus no estándares (adaptadas para productos/fabricantes concretos). No todas ellas son compatibles con el estándar abierto de Modbus.
Entre ellas, se puede destacar el Modbus UDP, Modbus Plus, Pemex Modbus o Enron Modbus. 

¿CONCLUSIONES?

El Modbus es un protocolo muy útil para comunicaciones simples. Y suele ser una de las pocas alternativas viables cuando hay que interconectar equipos de distintos fabricantes.

Dada su sencillez, los errores de comunicaciones con este protocolo suelen ser de fácil diagnóstico. 

Además, es un protocolo fácil de entender y que todo el mundo (quien más, quien menos) conoce. Esto hace que sea muy utilizado y demandado en el mercado, pese a sus carencias.

COMMS - Protocolo EtherCAT

El protocolo de comunicaciones EtherCAT (Ethernet for Control Automation Technology) es un bus de campo desarrollado originalmente por Beckhoff Automation. Está diseñado para un control de máquina en tiempo real (incluida en el estándar IEC 61158).

Actualmente, muchos fabricantes de automatización integran este protocolo de alto rendimiento como estándar para sus dispositivos... Por lo que es una red para toda la máquina.

El presente artículo nos introducirá al funcionamiento de EtherCAT. Veremos también cuales son sus principales características, así como las ventajas que ofrece.

¿CÓMO FUNCIONA?

Es una tecnología basada en Ethernet industrial, con una arquitectura maestro-esclavo. 
A los esclavos también se les suele llamar nodos. Se les define por un número de nodo individual. Normalmente estos disponen de dos puertos, uno de entrada y otro de salida.

El maestro envía una trama (única para toda la red) que pasa por cada esclavo. Los nodos leen/escriben en el telegrama los datos a compartir. Lo hacen "al vuelo", en nanosegundos.
El ultimo esclavo detecta un puerto abierto y devuelve el mensaje al maestro directamente.
                                                                    vídeo de interés

Cada uno de los nodos dispone de un reloj distribuido, cuyo tiempo queda también impreso en la trama.
Así pues, el maestro conoce el retraso de comunicaciones que hay entre esclavos, realizando las compensaciones necesarias (jitter inferior a 1us). 

¿INTERCAMBIO DE DATOS?

Hay dos métodos para intercambiar datos del mapeado EtherCAT de los esclavos con el maestro:

- Comunicaciones PDO: Process Data Objects
Listado predefinido de datos que se intercambian cíclicamente entre maestro y esclavo. 
Se utiliza para transferir información en tiempo real con el esclavo (automáticamente y con un período fijo). Pero, si se utilizan en exceso, pueden cargar la red...

- Comunicaciones SDO: Service Data Objects
Este método, consiste en el intercambio de un objeto EtherCAT en un solo ciclo de comunicaciones.
Se utiliza para los datos no críticos, pues permite al maestro leerlos a petición, según lo requiera.
Normalmente se necesita programación en el maestro para ello. 

¿CONFIGURACIÓN?

Para establecer comunicaciones entre maestro y esclavo, comunmente se deben seguir los pasos básicos que se detallan a continuación. 

1) Preparación de hardware
Se debe alimentar el circuito de control de los equipos y conectarlos a la red (cable Ethernet paralelo). 
Confirmar, en los esclavos, que se utilizan los puertos adecuados para la conexión del conector RJ45 (entrada/salida).

2) Importar archivo ESI
En el software del maestro, incluir este archivo de descripción del nodo (.xml).
El fabricante del esclavo es quien debe subministrar este archivo. Contiene toda la información EtherCAT del equipo (nombre del dispositivo, reloj distribuido, etc). Es imprescindible para poderlo enlazar con el maestro.

3) Configurar el esclavo
Dar número de nodo a los equipos para que el maestro pueda reconocerlos.
En EtherCAT se utiliza este número en vez de una dirección IP. Comunmente, puede establecerse por hardware (mediante algún switch físico en el equipo) o desde el software del maestro (utilizando el archivo ESI).

4) Editar mapeado de PDOs
Normalmente los esclavos EtherCAT ya vienen con un mapeado de PDOs predefinidos para intercambiar cíclicamente con el maestro (en el archivo ESI). Pero muchas veces es editable.
Antes de comunicar, confirmar que disponemos de todos los datos que nos interesan en el mapeado del esclavo... También podemos eliminar PDOs que no consideremos necesarias, para no cargar la red.

5) Programar el intercambio de datos
Por último, deben declararse las PDOs de los nodos en el programa del maestro para las lea y escriba automáticamente.
En el caso de requerirse, programar la lectura/escritura de SDOs.
Este punto varia mucho en función del software utilizado.

¿PRECAUCIONES?

Como en la mayoría de buses de campo con medio físico Ethernet, la distancia máxima admisible entre equipos es de 100m.
Aún así, este máximo puede verse afectado por varios factores como el entorno, categoría del cable,etc.

Por especificaciones, el numero máximo de esclavos en la red es de 65535 nodos.
Normalmente, el fabricante del maestro ya da un máximo mucho más restrictivo...

Comunmente, los esclavos, tienen un límite de PDOs que pueden mapearse simultáneamente... 
Esto evita saturar la red, para ello se dispone también de las SDOs.

En algunos fabricantes, la red EtherCAT no admite todas las topologías. Solo pueden conectarse los equipos en cadena.
No obstante, por especificaciones, este bus si que puede admitir trabajar con otros tipos de conexión (p.e. anillo). Pero hay que confirmarlo antes con el proveedor... 

Se pueden utilizar switches EtherCAT específicos para ramificar la red. 
Aunque no comuniquen explícitamente con el esclavo (son elementos pasivos), trabajan como cualquier otro esclavo. Requieren un número de nodo para definirlos y deben constar en la configuración de red del maestro. 

¿PUNTOS FUERTES?

Hay distintos motivos que pueden convencernos para escoger la red EtherCAT al automatizar nuestras máquinas. En la línea de lo que ya se ha comentado...

El rendimiento excepcional, la robustez y la tipología flexible, son las características más destacables.  

También es una tecnología asequible. No se requiere mucho hardware específico respecto a otros buses de campo clásico, por lo que no supone costes adicionales.

Además es sencilla de implementar, pues requiere una configuración muy directa y prácticamente sin programación. Es fácilmente modificable y suele presentar un fácil diagnóstico en el caso de fallos.

Otra principal ventaja es que dispone de seguridad integrada en el bus.
La tecnología es llamada Safety over EtherCAT (FSoE).

Por último, cabe destacar que puede encajar en infinidad de aplicaciones industriales, permitiendo controlar todo el sistema con un único protocolo.

COMMS - Protocolo OPC UA

El protocolo de comunicaciones OPC Unified Architecture, conocido como OPC UA, es una evolución del OPC clásico adaptado para cumplir con los requisitos esenciales en la industria. Lo ha desarrollado la fundación OPC (click aquí para más información al respecto).

vídeo de interés

Este protocolo es abierto y, actualmente, muchos fabricantes de autómatas lo integran en sus equipos de forma predeterminada (medio físico Ethernet).

OPC UA está diseñado para la comunicación entre dispositivos (como PLC/HMI) y máquina a máquina (M2M), así como para el control y recopilación de datos a nivel operacional o de producción (p.e. en una base de datos en la nube).  

Es flexible, seguro y totalmente independiente. Esto lo hace ideal para la implementación del IoT y la Industria 4.0, cerrando la brecha entre OT/IT. 

¿CÓMO FUNCIONA?

Está basado en protocolos IP estándar y utiliza una arquitectura de cliente-servidor.
El cliente (consumidor) es el que hace las peticiones de lectura/escritura, mientras que el servidor únicamente se encarga de exponer los datos a los que se podrá acceder.  
Cada vez que un cliente se conecta a un servidor, se abre una sesión en este. Es importante controlar el límite de sesiones abiertas simultáneamente (establecido por cada equipo). 

Se debe tener presente que todos los dispositivos que admiten protocolo OPC UA (p.e. PLC) no tienen porque poder trabajar como clientes y servidores. Es necesario saber que rol puede desempeñar según las especificaciones del fabricante.

El OPC UA es un protocolo orientado a objetos. Cada objeto es llamado nodo y puede tener atributos, métodos y eventos asociados.

Esta es una característica destacable, pues nos permite definir y organizar la información. Mejora la eficiencia y el diseño de las comunicaciones, para que cualquier aplicación del cliente pueda consumir los datos requeridos fácilmente. 

¿PASOS EN LA COMUNICACIÓN?

Seguidamente se detalla el procedimiento que siguen un cliente y servidor OPC UA (previamente configurados) para establecer comunicaciones.

1) Se habilita el servidor.
Es necesario declarar las variables que se van a exponer vía OPC UA.

2) El cliente descubre el servidor y recoge los "endpoints".
La conexión con el servidor se hace mediante una URL "opc.tcp: // [IP address] : [Port No] /".
Por ejemplo, "opc.tcp: // 192.168.251.1 : 4840 /".
En este punto también se evalúan las políticas de seguridad/encriptación soportadas y la autentificación de usuario si se requiere.

3) Se crea un canal seguro de comunicaciones.
Podría ser prescindible, pero lo común es utilizar certificados digitales para la autentificación.

4) Se abre la sesión.
Es importante que, al cortar comunicaciones, se cierre (manualmente o mediante un timeout predefinido). Como decíamos, los equipos suelen presentan un límite de sesiones.

5) El cliente establece comunicaciones.
Hay dos métodos para el consumo de datos del servidor:
- Polling Read/Write: Se envían las peticiones de lectura y escritura a los atributos de los nodos.
- Subscriptions: El cliente se subscribe a una selección de nodos de su interés y deja que el servidor monitorice esos ítems. Solo se transmiten cuando el valor cambia.

¿SEGURIDAD Y AUTENTIFICACIÓN? 

Como se comenta en el apartado anterior, hay funciones específicas para que la comunicación OPC UA sea segura, aunque ninguna es estrictamente necesaria de implementar...

Una de ellas es la autentificación de usuario. Solo se lleva a cabo en el cliente para verificar las credenciales de quien opere en él.  

La otra, más solicitada, es la autentificación de aplicación. Sirve para validar la seguridad entre el servidor y el cliente.
Este método se implementa mediante el intercambio de certificados digitales para que servidor y cliente autentifiquen la identidad de cada uno de ellos.

Dichos certificados (formato X.59 estándar) contienen lo conocido como llave, un algoritmo que se utiliza para encriptar datos.

¿CONCLUSIONES? 

Los protocolos más comunes para redes de campo (EtherNet/IP, Profinet, etc), por su naturaleza, resultan menos adecuados en niveles superiores de la jerarquía de red. En cambio, OPC UA presenta mayor flexibilidad y capacidad para poder interaccionar con muchos sistemas de diferente naturaleza.
Un servidor puede centralizar la información de distintos equipos en una planta. Luego, puede entregar esta información a distintos clientes para que la utilicen en aplicaciones de monitorización, análisis, etc. Cada cliente solo tiene que apuntar al nodo que engloba toda la información necesaria.

Es una solución abierta pero segura. Los interfaces, las puertas de enlace y la consiguiente pérdida de información son cosa del pasado.
Entonces, este protocolo cumple con todas las necesidades emergentes en el mundo de la automatización industrial.
Trabaja con cualquier sistema operativo, incluyendo Linux, Windows, Android o iOS. Y, al basarse en un arquitectura orientada a los servicios e interfaces de programación, es más fácil de integrar en cualquier tipo de aplicación o dispositivo.