OPC UA es un estándar de comunicación que permite intercambiar datos entre PLC, HMI, SCADA y aplicaciones de otros fabricantes. Frente a OPC clásico, incorpora independencia de plataforma, un modelo de información y mecanismos de seguridad configurables. Para conectar un equipo, hay que comprobar qué funciones admite su implementación.
OPC clásico y OPC UA: diferencias prácticas
| Aspecto | OPC clásico | OPC UA |
|---|---|---|
| Plataforma | Basado en COM/DCOM de Windows | Independiente del sistema operativo |
| Datos | Especificaciones separadas para datos, alarmas e históricos | Servicios y modelo de información integrados |
| Conexión | La configuración DCOM condiciona el acceso remoto | Endpoints y políticas de seguridad anunciados por el servidor |
| Equipos existentes | Puede seguir siendo necesario para sistemas heredados | La conexión con OPC clásico requiere un adaptador o pasarela |
Fuente: descripción de OPC UA de OPC Foundation. No confundas «admite OPC UA» con «todas sus funciones están habilitadas»: revisa CPU, firmware, licencia y software cliente.
Si ya conoces la diferencia y quieres configurarlo, ve directamente al tutorial del servidor OPC UA en TIA Portal. A continuación puedes leer cómo se llegó a este estándar.
¿Qué había antes de los OPC?
Antes de que existiera OPC no existía ningún tipo de estándar de comunicación entre los diferentes PLC (u otras fuentes de datos) y las aplicaciones que recogían los datos (montandos en un PC por ejemplo). Esto hacía que las compañías hicieran cada una la guerra por su cuenta y las herramientas fueran desarrolladas de forma propietaria por cada una de ellas, haciendo muy complicada la relación entre los diferentes tipos de equipos (hardware) con las diferentes herramientas ofimáticas (software). Ni que decir que la potencia de comunicación estaba muy limitada y combinar diferentes fabricantes, casi imposible.Llega el OPC
El grupo de trabajo precursor de OPC comenzó en 1995 y la OPC Foundation se constituyó en 1996. La fundación mantiene las especificaciones y coordina su evolución. Su cronología oficial distingue ambos hitos.Pero ¿ qué es OPC?
OPC es un estándar de comunicaciones cuya misión es poner en contacto los equipos industriales y las aplicaciones HMI y Scada. Esto permite, por ser un estándar común, que la integración entre el software y el hardware se haga de una manera más sencilla. Según la propia fundación su misión es la siguiente:La misión de la Fundación OPC es gestionar una organización global en la que los usuarios, proveedores y consorcios colaboren para crear estándares de transferencia de datos para la interoperabilidad multiplataforma, segura y confiable en la automatización industrial. Para apoyar esta misión, la Fundación OPC:Pero claro, el tema de la multi plataforma, no siempre estuvo ahí. En un principio, OPC no era OPC, sino más bien OLE. Se trataba de un desarrollo de Microsoft para permitir la incrustación de documentos y objetos, derivado del intercambio de datos dinámicos (DDE). Con el tiempo, Microsoft OLE deriva en OLE for Process Control... u OPC. Posteriormente este acrónimo se transforma en Open Platform Communication Y así, va avanzando poco a poco hasta lo que conocemos hoy en día. Puedes chequear toda su evolución en la web de OPC Foundation si tienes más curiosidad: https://opcfoundation.org/about/opc-foundation/history/Fuente: https://opcfoundation.org/about/opc-foundation/mission-statement/
- Crea y mantiene especificaciones.
- Asegura el cumplimiento de las especificaciones OPC a través de pruebas de certificación.
- Colabora con organizaciones de estándares líderes en la industria
¿Cómo funciona la arquitectura OPC?
En el modelo cliente/servidor, el servidor expone datos y servicios y el cliente los utiliza según sus permisos. Además de lecturas y escrituras, OPC UA admite suscripciones para recibir notificaciones de cambios. Es el cliente quien pide la información al servidor, a qué velocidad, y este a su vez, lo obtiene del PLC, en nuestro caso.OPC Clásico
El OPC clásico (OPC DA) depende de Microsoft. Concretamente del componente DCOM (https://es.wikipedia.org/wiki/Modelo_de_Objetos_de_Componentes_Distribuidos) Hay varios sabores de OPC, si bien el más habitual es OPC DA cuyas características son:- Intercambio de datos entre cliente y servidor en tiempo real en forma de valor, calidad y tiempo (VQT)
- Permite navegar y acceder a la información del servidor
- La velocidad de recolección de datos puede ir hasta los 10ms.
- Permite lectura y escritura
- Solo soporta Microsoft windows
- La configuración de acceso remoto debe considerar DCOM y la red utilizada.
- Es necesario configurar los permisos y puertos del firewall.
- La autenticación se realiza a través de los servicios de componentes de Windows
¿Qué es OPC UA?
Las siglas UA ya nos dice bastante sobre él ya que significa Arquitectura Unificada (Unified Architecture) y tiene unas características bien definidas:- No depende del sistema operativo. Puedes encontrarlo en Windows, Linux, Mac..
- No depende por tanto del DCOM de Windows haciendo que sea más amigable con los Firewall.
- Incluye todas las características clásicas, en una sola interfaz.
OPC UA en Siemens
Los equipos 1500 de siemens, así como los HMI Comfort disponen de este tipo de protocolo para realizar comunicaciones de forma segura. Tienes información suministrada por Siemens siguiendo este enlace. La idea es poder comunicar los PLC o los HMI con dispositivos fuera de la red que montas con los PLC de una forma segura y razonablemente sencilla.Cómo plantear una primera conexión con un PLC Siemens
Un ejercicio útil consiste en leer desde un cliente una variable de prueba del PLC. Antes de escribir sobre una variable del proceso, comprueba la lectura, su tipo y el estado de calidad. La configuración concreta depende del equipo y de su firmware: utiliza el ejemplo de configuración en TIA Portal y contrástalo con la documentación de tu CPU.
- Identifica la referencia completa del PLC y su firmware. Comprueba que incorpora el servidor y qué licencia necesita.
- Define las variables que quieres exponer y los permisos que necesita el cliente.
- Configura el endpoint y una política de seguridad compatible en ambos extremos.
- Establece la confianza entre los certificados y configura la autenticación de usuario cuando proceda.
- Comprueba la lectura y el estado de calidad; después, verifica una suscripción para observar cambios.
Qué revisar cuando el cliente no conecta
Separa el diagnóstico en tres partes: acceso al endpoint, confianza de certificados y permisos. Que el equipo responda a ping no confirma que el servicio OPC UA esté accesible. Que la sesión se abra tampoco implica permiso de escritura sobre todos los nodos.
OPC UA ofrece autenticación, integridad y confidencialidad, pero hay que seleccionar y configurar sus mecanismos según la instalación. Fuente: modelo de seguridad de OPC Foundation.
Para continuar, tienes el servidor OPC UA en TIA Portal y un enfoque con Node-RED. Si buscas otra forma de intercambiar datos con un S7, revisa el ejemplo de Python y Snap7; utiliza otro mecanismo de comunicación y no sustituye automáticamente a OPC UA.
Qué anotar en tu primera prueba
Al seguir el tutorial, prepara una variable que puedas cambiar sin actuar sobre la máquina. Anota el endpoint utilizado, el tipo de dato, el valor leído y su estado de calidad; después cambia el valor y observa si llega la notificación. Así distingues «la sesión conecta» de «estoy recibiendo el dato esperado». No empieces por escribir órdenes sobre salidas del proceso.
Si antes necesitas afianzar cómo organizar las variables del PLC y diagnosticar la conexión, consulta cómo se estructura un proyecto en TIA Portal. El curso completo de TIA Portal para S7-1200 desarrolla hardware, bloques, diagnóstico y comunicaciones S7, PROFINET y TCP/UDP; el tutorial de OPC UA enlazado arriba es la práctica específica de este artículo.
¿Ya has practicado?
¿Qué PLC y cliente estás utilizando? Cuéntalo en los comentarios: la referencia, el firmware y el mensaje de error ayudan mucho más que decir solamente «no conecta».
