Arquitectura unificada OPC

OPC Unified Architecture ( OPC UA ) es un estándar IEC62541 multiplataforma y de código abierto para el intercambio de datos desde sensores a aplicaciones en la nube desarrollado por la Fundación OPC . Las características distintivas son: ^[1]

• Modelos de datos estandarizados disponibles gratuitamente para más de 60 tipos de equipos industriales, publicados por la Fundación OPC a través de Especificaciones complementarias
• Perfiles de seguridad extensibles, que incluyen autenticación, autorización, cifrado y sumas de comprobación
• Gestión de claves de seguridad extensible, incluidos X.509, token y contraseña
• Compatibilidad con patrones de comunicación cliente-servidor y publicación-suscripción
• Independiente del protocolo de comunicación. Se especifican asignaciones a varios protocolos de comunicación como TCP/IP, UDP/IP, WebSockets, AMQP y MQTT.
• Inicialmente tuvo éxito en el intercambio estandarizado de datos con equipos industriales (fabricación discreta, fabricación de procesos, energía) y sistemas para recopilación y control de datos, pero ahora también se aprovecha en la automatización de edificios, equipos de pesaje y de cocina y aplicaciones en la nube.
• Abierto : implementaciones de referencia de código abierto disponibles gratuitamente para miembros de la Fundación OPC, no miembros bajo licencia GPL 2.0 ^[2]
• Multiplataforma : no está vinculado a un solo sistema operativo o lenguaje de programación
• Arquitectura orientada a servicios (SOA)
• La especificación está disponible de forma gratuita en el sitio web de OPC Foundation y está dividida en varias partes para facilitar la implementación, pero solo los proveedores de pilas OPC UA necesitan leerlas; los usuarios finales simplemente aprovechan las pilas comerciales y/o de código abierto existentes disponibles en todos los lenguajes de programación populares.

Aunque fue desarrollado por la misma organización, OPC UA difiere significativamente de su predecesor, Open Platform Communications (OPC). El objetivo de la Fundación para OPC UA era proporcionar un camino a seguir a partir del modelo de comunicaciones OPC original (es decir, el intercambio de procesos COM/ DCOM exclusivo de Microsoft Windows ) que satisficiera mejor las necesidades emergentes de la automatización industrial . ^[3]

Después de más de tres años de trabajo de especificación y otro año para la implementación de un prototipo, la primera versión de la Arquitectura Unificada se lanzó en 2006. ^[4]

La versión actual de la especificación es la 1.04 (22 de noviembre de 2017 ^[5] ). La nueva versión de OPC UA ahora ha agregado la publicación/suscripción además de la infraestructura de comunicaciones cliente/servidor.

Aunque la vinculación original a COM/ DCOM ayudó a que OPC se distribuyera bien, tenía varios inconvenientes:

• Problemas frecuentes de configuración con DCOM;
• No hay tiempos de espera configurables;
• Sólo Microsoft Windows ;
• Menor seguridad;
• No hay control sobre DCOM (COM/DCOM es una especie de caja negra, los desarrolladores no tienen acceso a las fuentes y, por lo tanto, tienen que lidiar con errores o implementaciones insuficientes).

Estos inconvenientes, junto con una serie de otras consideraciones, impulsaron la decisión de desarrollar una pila nueva e independiente para OPC UA, que sustituye a COM/DCOM. Las principales características de esta pila de comunicación eran:

• Implementación multiplataforma, incluyendo implementaciones portátiles ANSI C , Java y .NET ;
• Escalabilidad: desde sensores inteligentes y actuadores inteligentes hasta mainframes;
• Operación multiproceso, así como de un solo subproceso/tarea única, necesaria para trasladar la pila a dispositivos integrados;
• Seguridad, basada en nuevos estándares;
• Tiempos de espera configurables para cada servicio;
• Fragmentación de datagramas grandes.

Esta pila de comunicación refleja el comienzo de varias innovaciones. La arquitectura OPC UA es una arquitectura orientada a servicios (SOA) y se basa en diferentes niveles lógicos.

Los servicios básicos de OPC son descripciones abstractas de métodos, que son independientes del protocolo y proporcionan la base para la funcionalidad de OPC UA. La capa de transporte coloca estos métodos en un protocolo, lo que significa que serializa/deserializa los datos y los transmite a través de la red. Se especifican dos protocolos para este propósito. Uno es un protocolo TCP binario , optimizado para un alto rendimiento y el segundo está orientado a servicios web .

El modelo de información OPC es una red en malla basada en nodos . Estos nodos pueden incluir cualquier tipo de metainformación y son similares a los objetos de la programación orientada a objetos (OOP). Un nodo puede tener atributos para acceso de lectura (DA, HDA), métodos que se pueden llamar (comandos) y eventos desencadenados que se pueden transmitir (AE, DataAccess, DataChange). Los nodos contienen datos de proceso, así como otros tipos de metadatos . El espacio de nombres OPC contiene el modelo de tipo.

El software cliente puede verificar qué perfiles admite un servidor. Esto es necesario para obtener información sobre si un servidor solo admite la funcionalidad DA o también AE, HDA, etc. Además, se puede obtener información sobre si un servidor admite un perfil determinado. Las características nuevas e importantes de OPC UA son:

• Soporte de redundancia
• Latido de las conexiones en ambas direcciones (para indicar si el otro extremo está "activo"). Esto significa que tanto el servidor como el cliente reconocen las interrupciones.
• Almacenamiento en búfer de datos y confirmación de la transmisión de datos. Las conexiones perdidas ya no provocan la pérdida de datos. Los datagramas perdidos se pueden recuperar.

En octubre de 2006, en la OPC UA DevCon de Múnich, se presentaron en directo los primeros prototipos. Se mostraron varios servidores UA en un controlador lógico programable de Beckhoff y una placa de pruebas integrada de Euros. El PLC de Beckhoff se basa en Windows XP Embedded y el controlador integrado se basa en el sistema operativo en tiempo real Euros. La empresa Embedded Labs Ltd. presentó un servidor OPC UA basado en su propia pila C++ UA que se ejecuta en un microcontrolador ARM de un solo chip con 64 kB de RAM . En octubre de 2012, el centro de aplicaciones alemán Fraunhofer IOSB-INA y el Instituto de Tecnologías de la Información Industrial (inIT) demostraron que un servidor OPC UA se puede escalar hasta 15 kB de RAM y 10 kB de ROM y, por lo tanto, se puede utilizar a nivel de chip. ^[6]

La especificación OPC UA es una especificación de varias partes y consta de las siguientes partes:

1. Conceptos
2. Modelo de seguridad
3. Modelo de espacio de direcciones
4. Servicios
5. Modelo de información
6. Mapeos
7. Perfiles
8. Acceso a datos
9. Alarmas y condiciones
10. Programas
11. Acceso histórico
12. Descubrimiento y servicios globales
13. Agregados
14. PubSub
15. Seguridad
16. Máquinas de estados
17. Nombres de alias
18. Seguridad basada en roles
19. Referencia del diccionario
20. Transferencia de archivos
21. Incorporación de dispositivos
22. Modelo de red base
23. Tipos de referencia comunes
24. Programador

Además, también están disponibles la parte 100, Dispositivos, y la parte 200, Automatización industrial. Estas se basan en el conjunto básico de especificaciones y añaden nuevas definiciones comunes que luego se utilizan en diferentes especificaciones complementarias. Por ejemplo, tanto OPC UA para dispositivos analizadores como OPC UA para maquinaria se basan directamente en la parte 100.

A diferencia de las especificaciones basadas en COM, las especificaciones UA no son especificaciones de aplicación puras. Describen mecanismos internos de UA, que se gestionan a través de la pila de comunicación y normalmente solo son de interés para aquellos que trasladan una pila a un objetivo específico o aquellos que desean implementar su propia pila UA.

Los desarrolladores de aplicaciones OPC UA codifican en función de la API OPC UA y, por lo tanto, utilizan principalmente la documentación de la API. No obstante, las partes 3, 4 y 5 pueden resultar de interés para los desarrolladores de aplicaciones. ^[7]

La arquitectura de una aplicación UA, independientemente de si es la parte servidor o cliente, está estructurada en niveles.

Algunas partes son iguales a las del antiguo COM Proxy/Stubs y las proporciona la OPC Foundation. El nivel de portabilidad es nuevo; simplifica la portabilidad de la pila UA ANSI C a otras plataformas de destino. La OPC Foundation también proporciona una capa de puerto para Windows y Linux .

La seguridad UA consiste en autenticación y autorización, cifrado e integridad de datos mediante firmas. Para los servicios web se utiliza WS-SecureConversation y, por lo tanto, es compatible con .NET y otras implementaciones SOAP . Para la variante binaria, se han seguido los algoritmos de WS-SecureConversation y también se han convertido a un equivalente binario. Esto se denomina UA Secure Conversation.

También existe una versión mixta en la que el código es binario, pero la capa de transporte es SOAP. Se trata de un compromiso entre la codificación binaria eficiente y la transmisión compatible con el cortafuegos. La codificación binaria siempre requiere UA Secure Conversation. La autenticación utiliza exclusivamente certificados X.509 . Depende del desarrollador de la aplicación elegir a qué almacén de certificados se vincula la aplicación UA. Por ejemplo, es posible utilizar la infraestructura de clave pública (PKI) de un Active Directory .

El estándar OPC UA define 25 tipos de datos integrados:

Las API de UA están disponibles en varios lenguajes de programación. Hay SDK comerciales disponibles para C, C++, Java y .NET. Hay pilas de código abierto disponibles al menos para C, C++, Java, Javascript(node), Tcl y Python.

La implementación de .NET utiliza ANSI C para los niveles inferiores e implementa el resto de forma nativa en .NET. Esto significa que solo el manejo del socket y la fragmentación de mensajes se integran desde la pila ANSI C. La deserialización se realiza directamente en .NET y, por lo tanto, se convierte directamente en estructuras y objetos .NET. Esto proporciona un mejor rendimiento que deserializar primero en una estructura C y luego copiar los datos a una estructura .NET.

Se estaban desarrollando varias pilas para Java. ^{[¿ Cuándo? ]} Al igual que .NET, existen principalmente tres variantes:

1. Encapsular la pila ANSI C completa a través de JNI , lo que complica la portabilidad. Aunque la pila se puede trasladar a diferentes sistemas operativos, es necesario compilarla para cada uno de ellos individualmente. Además, los datos deben copiarse en el límite de JNI, pero se benefician del rendimiento de C durante la deserialización.
2. Codifique directamente en la capa de red (similar a la implementación actual de .Net) y deserialice en Java. Esto ahorra la ejecución de una copia de datos, pero aún depende de la pila C.
3. Escribir una pila OPC UA nativa de Java. Se observó que esta era la más portátil, pero se estimó que su implementación requeriría un mayor esfuerzo de ingeniería. El proyecto Eclipse Milo proporciona una implementación de código abierto y en Java puro de la especificación de cliente y servidor UA 1.03. ^[8]
4. El proyecto Apache PLC4X proporciona una implementación de código abierto en Java puro del cliente UA, así como descripciones de marcos a nivel de red que se pueden utilizar para implementaciones en varios lenguajes. ^[9]

Otra opción es la variante sencilla que solo admite el protocolo WebService. Para ello, se necesita un kit de herramientas SOAP que admita WS-Security .

IEC 62541 ^[10] es un estándar para la arquitectura unificada OPC.

• Acceso a datos OPC
• OLE para control de procesos
• Fundación OPC

• Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: Arquitectura unificada OPC. Springer Verlag 2009; ISBN 978-3-540-68898-3 
• Lange, J., Iwanitz, F., Burke, T. OPC Del acceso a los datos a la arquitectura unificada 2010; ISBN 978-3-8007-3242-5