A fines de la década de 1990 y principios de la década de 2000, la OPC se extendió como una

maleza. Los servidores OPC estaban en todas partes. Kepware, Matrikon y otros implementaron

millones (bueno, miles) de servidores OPC en todos los rincones de la industria de la
automatización. Todo tipo de industria. Cada tipo de aplicación.

Pero no todo estaba bien con OPC, o OPC Classic como lo llamo ahora. Problemas de seguridad,
dependencia de las plataformas de Microsoft, formas costosas e ineficientes para mover datos,
además de dificultades de mantenimiento, todas plagadas de OPC Classic.

Entonces, a pesar de que OPC Classic ha tenido un gran éxito y funcionó bien cuando se manejó
correctamente, hubo suficiente insatisfacción con sus problemas que se planificó un sucesor para
ello.

¿Qué es OPC UA?

Esa es una pregunta muy simple. La respuesta cuando se habla
de una tecnología compleja como OPC UA no es tan simple.

OPC UA es la próxima generación de tecnología OPC. OPC UA es un mecanismo más seguro,

abierto y confiable para transferir información entre servidores y clientes. Proporciona más
transportes abiertos, mejor seguridad y un modelo de información más completo que el OPC
original, «OPC Classic». OPC UA proporciona un mecanismo muy flexible y adaptable para
mover datos entre sistemas de tipo empresarial y los tipos de controles, dispositivos de monitoreo
y Sensores que interactúan con datos del mundo real.
 ¿Por qué una arquitectura de la comunicación totalmente nueva? OPC Classic es limitado y no se
adapta bien a los requisitos actuales para mover datos entre los sistemas empresariales / de
Internet y los sistemas que controlan procesos reales que generan y monitorean datos en
vivo. Estas limitaciones incluyen:

 Dependencia de la plataforma en Microsoft : OPC Classic se basa en DCOM (Distribution COM),

una tecnología de comunicación más antigua que Microsoft está desestimando.
 Modelos de datos insuficientes : OPC Classic carece de la capacidad de representar
adecuadamente los tipos de datos, información y relaciones entre elementos de datos y sistemas que son
importantes en el mundo conectado de hoy.
 Seguridad inadecuada : muchos usuarios perciben que Microsoft y DCOM carecen del tipo de
seguridad necesaria en un mundo conectado con amenazas sofisticadas de virus y malware.

OPC UA es la primera tecnología de comunicación construida específicamente para vivir en esa

«tierra de nadie» donde los datos deben atravesar firewalls, plataformas especializadas y
barreras de seguridad para llegar a un lugar donde esos datos puedan convertirse en
información. OPC UA está diseñado para conectar bases de datos, herramientas analíticas,
sistemas de planificación de recursos empresariales (ERP) y otros sistemas empresariales con
datos reales de controladores de gama baja, sensores, actuadores y dispositivos de monitoreo
que interactúan con procesos reales que controlan y generan datos reales. datos mundiales

OPC UA utiliza plataformas escalables, múltiples modelos de seguridad, múltiples capas de

transporte y un sofisticado modelo de información para permitir que el controlador dedicado más
pequeño interactúe libremente con aplicaciones complejas de servidor de alto nivel. OPC UA
puede comunicar cualquier cosa, desde un simple estado de inactividad hasta cantidades
masivas de información altamente compleja en toda la planta.

OPC UA es un mecanismo sofisticado, escalable y flexible para establecer conexiones seguras

entre clientes y servidores. Las características de esta tecnología única incluyen:

Escalabilidad: OPC UA es escalable e independiente de la plataforma. Se puede admitir en

servidores de gama alta y en sensores de gama baja. OPC UA utiliza perfiles detectables para
incluir pequeñas plataformas integradas como servidores en un sistema OPC UA.

Un espacio de direcciones flexible: el espacio de direcciones OPC UA se organiza en torno

al concepto de un objeto. Los objetos son entidades que constan de variables y métodos y
proporcionan una forma estándar para que los servidores transfieran información a los clientes.
Codificaciones y transportes comunes: OPC UA utiliza transportes y codificaciones estándar
para garantizar que la conectividad se pueda lograr fácilmente tanto en el entorno integrado como
en el empresarial.

Seguridad: OPC UA implementa un sofisticado modelo de seguridad que garantiza la

autenticación de clientes y servidores, la autenticación de usuarios y la integridad de su
comunicación.

Capacidad de Internet: OPC UA es totalmente capaz de mover datos a través de Internet.

Un conjunto robusto de servicios: OPC UA proporciona un conjunto completo de servicios para

eventos, alarmas, lectura, escritura, descubrimiento y más.

Interoperabilidad certificada: OPC UA certifica los perfiles de modo que se pueda garantizar la

conectividad entre un cliente y un servidor utilizando un perfil definido.

Un modelo de información sofisticado: OPC UA perfila más que solo un modelo de

objeto. OPC UA está diseñado para conectar objetos de tal manera que la verdadera información
pueda ser compartida entre clientes y servidores.

Sofisticada gestión de alarmas y eventos : OPC UA proporciona un mecanismo altamente

configurable para proporcionar alarmas y notificaciones de eventos a los clientes interesados. Los
mecanismos de eventos y alarmas van mucho más allá de las alarmas de tipo de cambio en el
valor estándar encontradas en la mayoría de los protocolos.

Integración con modelos estándar de datos específicos de la industria: la Fundación OPC

está trabajando con varios grupos comerciales de la industria para definir modelos de información
específicos para sus industrias y para respaldar esos modelos de información dentro de OPC UA.
Cómo OPC UA se diferencia de los
sistemas de piso de planta
He estudiado esta tecnología desde hace mucho tiempo. Y sin embargo, hay una pregunta de la
que casi me encojo. De hecho, a veces odio responderla.

No es porque no entiendo lo que es. No es que no entiendo cómo funciona. Y no es que no crea
que sea una herramienta muy valiosa para casi todos los sistemas de pisos de plantas.

Es difícil ponerlo en contexto cuando no hay nada con qué compararlo. Por ejemplo, cuando salió
Profinet IO, pude decirle a la gente que era el equivalente de EtherNet / IP para los controladores
de Siemens. El mismo tipo de tecnología. Básicamente el mismo tipo de funcionalidad. Fácil de
explicar

Pero, ¿cómo explico OPC UA cuando no tiene un equivalente? Se podría decir que se trata de
servicios web para sistemas de automatización. O que es SOA para sistemas de automatización,
un término aún más arcano. SOA es «Arquitectura Orientada a Servicios», básicamente lo mismo
que los servicios web. Eso está bien si eres un chico de TI (o una chica) y entiendes esos
términos. Tienes algún contexto.

Pero si usted es un empleado de la planta, es probable que a pesar de que utilice los servicios
web (es decir, la plomería para Internet), no sepa qué significa ese término.

Entonces, la razón por la que me enojo por responder esta pregunta es porque siempre hacen
otra pregunta que me hace temblar: «¿Por qué necesitamos otro protocolo? Modbus TCP,
EtherNet / IP y Profinet IO funcionan bien «.

Así que debo comenzar con el hecho de que no es como EtherNet / IP, Profinet IO o Modbus
TCP. Es un paradigma completamente nuevo para las comunicaciones de planta. Es como
intentar explicar EtherNet / IP a un programador de PLC en 1982. Sin nada con qué compararlo,
es imposible de entender.

Ahí es donde estoy tratando de explicar OPC UA.

Las personas a las que trato de llegar han vivido con el paradigma de redes de PLC por tanto
tiempo que es una segunda naturaleza. Usted tiene un PLC, es un tipo de dispositivo maestro y
mueve datos dentro y fuera de los dispositivos esclavos. Utiliza una mensajería de tipo
transacción muy simple o algún tipo de mensajería conectada.

En cualquier caso, existe este búfer de datos de salida en una cosa llamada controlador
programable. Hay un búfer de datos de entrada en un grupo de dispositivos llamados servidores,
esclavos o nodos. El búfer de datos de entrada se mueve al controlador programable. Los buffers
de datos de salida se mueven desde el controlador programable a los
dispositivos. Repetir. Siempre. Hecho.

Eso es muy fácil de envolver tu mente. Realmente fácil de ver cómo encaja en su entorno de
fabricación y realmente fácil de diseñar.
OPC UA vive fuera de ese paradigma. Bueno, en serio, eso no es cierto. OPC UA vive en paralelo
con ese paradigma. No lo reemplaza. Lo extiende. Se suma a ello. Le brinda una nueva
funcionalidad, crea nuevos casos de uso e impulsa nuevas aplicaciones. Al final, aumenta la
productividad, mejora la calidad y reduce los costos al proporcionar no solo más datos, sino
también información, y el tipo correcto de información para la producción, el mantenimiento y los
sistemas de TI que necesitan esa información cuando la necesitan.

Bastante poderoso, ¿eh?

Nuestros mecanismos actuales para mover datos de planta (pocos o ningún sistema mueven
información) son frágiles. Se requieren enormes cantidades de recursos humanos y de
computación para hacer cualquier cosa. Y en el proceso perdemos muchos metadatos
importantes, perdemos resolución y creamos sistemas frágiles que son una pesadilla para apoyar.

Y ni siquiera preguntes sobre los agujeros de seguridad que crean. Porque cuando hay
problemas, y siempre los hay, lo primero que hacen todos es eliminar la seguridad y reiniciar.

Estos sistemas son una frágil casa de naipes. Necesitan ser derribados.

Y debido a todo esto, se pierden las oportunidades para extraer datos de calidad de la fábrica,
interrogar y crear bases de datos de mantenimiento, sistemas de informes de paneles de
alimentación, recopilar datos históricos y sistemas analíticos empresariales de
alimentación. Todas las oportunidades para mejorar los procedimientos de mantenimiento, reducir
el tiempo de inactividad, comparar el rendimiento en varias plantas, líneas y células en toda la
empresa se pierden.

Esta es la brecha que llena OPC UA. No es algo que pueda hacer Profinet IO, aunque los acólitos
devotos impugnen esa afirmación. No es algo que EtherNet/IP pueda hacer. Y sería una broma
hablar de Modbus TCP en este contexto.

Así que vuelvo a la pregunta original: «¿Qué es exactamente OPC UA»?

OPC UA se trata de modelar «objetos» de manera confiable, segura y, sobre todo, de manera
sencilla, y hacer que esos objetos estén disponibles en la planta, en las aplicaciones
empresariales y en toda la corporación. La idea detrás de esto es infinitamente más amplia de lo
que la mayoría de nosotros hemos pensado antes.

Todo comienza con un objeto. Un objeto que podría ser tan

simple como una sola pieza de datos o tan sofisticado como un
proceso, un sistema o una planta completa.

Puede ser una combinación de valores de datos, metadatos y relaciones. Tome un controlador de

doble bucle. El objeto controlador de bucle dual relacionaría las variables para los puntos de
ajuste y los valores reales para cada bucle. Esas variables harían referencia a otras variables que
contienen metadatos como las unidades de temperatura, los puntos de referencia altos y bajos y
las descripciones de texto. El objeto también puede hacer suscripciones disponibles para recibir
notificaciones sobre cambios en los valores de datos o los metadatos para ese valor de datos.  Un
cliente que accede a ese objeto puede obtener la menor cantidad de datos que desee (valor de
datos único) o un conjunto extremadamente rico de información que describe ese controlador y su
funcionamiento con gran detalle.

OPC UA es, como sus primos de fábrica, compuesto de un cliente y un servidor.  El dispositivo
cliente solicita información. El dispositivo servidor lo proporciona. Pero como podemos ver en el
ejemplo del controlador de bucle, lo que hace el servidor OPC UA es mucho más sofisticado que
lo que hace un servidor EtherNet / IP, Modbus TCP o Profinet IO.

Un servidor OPC UA modela datos, información, procesos y sistemas como objetos y presenta
esos objetos a los clientes de maneras que son útiles para diferentes tipos de aplicaciones
cliente. Mejor aún, el servidor OPC UA proporciona servicios sofisticados que el cliente puede
usar, que incluyen:

Servicios de descubrimiento: servicios que los clientes pueden usar para saber qué objetos
están disponibles, cómo están vinculados a otros objetos, qué tipo de datos y qué tipo están
disponibles, y qué metadatos están disponibles que se pueden usar para organizar, clasificar y
describir esos objetos y valores

Servicios de suscripción: servicios que los clientes pueden usar para identificar qué tipo de
datos están disponibles para las notificaciones. Servicios que los clientes pueden usar para
decidir qué tan pequeños, cuánto y cuándo desean recibir notificaciones sobre los cambios, no
solo a los valores de los datos, sino a los metadatos y la estructura de los objetos.

Servicios de consulta: servicios que entregan datos masivos a un cliente, como datos históricos
para un valor de datos

Servicios de nodo: servicios que los clientes pueden usar para crear, eliminar y modificar la
estructura de los datos mantenidos por el servidor

Method Services: servicios que los clientes pueden usar para realizar llamadas a funciones
asociadas con objetos.

A diferencia de los protocolos industriales estándar, un servidor OPC UA es un motor de datos

que recopila información y la presenta en formas que son útiles para varios tipos de dispositivos
cliente OPC UA, dispositivos que podrían ubicarse en la fábrica como un HMI, un control
patentado. Programa como un gestor de recetas, o una base de datos, un panel de control o un
programa de análisis sofisticado que podría estar ubicado en un servidor empresarial.

Aún más interesante, estos datos no están necesariamente limitados a un solo nodo físico. Los
objetos pueden hacer referencia a otros objetos, variables de datos, tipos de datos y más que
existen en nodos fuera de otro lugar en la subred o en otro lugar en la arquitectura o incluso en
otro lugar en Internet.

OPC UA organiza procesos, sistemas, datos e información de una manera que es absolutamente
única para la experiencia de la industria de la automatización industrial. Es una herramienta única
que ataca un problema completamente diferente al resuelto por los protocolos EtherNet / IP,
Modbus TCP y Profinet IO Ethernet. OPC UA es una herramienta de entrega y modelado de
información que brinda acceso a esa información a los clientes en toda la empresa.
Terminología OPC UA
Una de las cosas que debe saber sobre OPC UA es que la terminología es un poco diferente de
lo que está acostumbrado a ver. Los términos utilizados en muchos documentos OPC UA son
similares a lo que podría esperar, pero los diseñadores distorsionaron ligeramente los
significados. Probablemente sea porque OPC UA es el primer protocolo que realmente cruza la
línea entre la empresa y la fábrica. Debido a que tiene un pie en ambos mundos, los términos
pueden ser confusos para personas bien versadas tanto en el mundo de TI como en el de fábrica.

Otra razón por la que los términos a primera vista parecen ser un poco confusos es el alcance de
una discusión OPC UA. En IA (automatización industrial), generalmente hablamos de interfaces
entre componentes de software que cohabitan en un procesador. O hablamos de dispositivos en
la misma subred que se comunican a través de interfaces muy bien definidas y muy restrictivas
(EtherNet / IP, Modbus TCP o Profinet IO). En el mundo de Internet, las personas hablan de
servicios genéricos con mucha más flexibilidad y capacidad que las interfaces entre los
dispositivos de fábrica.

Aquí hay un diccionario de los términos más importantes de OPC UA.

APLICACIÓN OPC UA: en redes industriales, generalmente hacemos una distinción entre la
aplicación del usuario final y la pila de protocolos. La aplicación del usuario final implementa algún
conjunto de funcionalidades definidas. La pila de protocolos mueve datos bien definidos entre la
aplicación y algún dispositivo externo mediante una interfaz muy restrictiva. No es exactamente lo
mismo en OPC UA. En OPC UA, he encontrado que la aplicación OPC UA hace referencia a la
aplicación del usuario final, al modelo de objetos OPC UA y al conjunto de servicios OPC UA
implementados por el dispositivo OPC UA. Este es un uso mucho más abarcador del término.

OPC UA CLIENT: un punto final de OPC UA cliente es el lado de una comunicación OPC UA que
inicia una sesión de comunicación. Los clientes en OPC UA son mucho más flexibles que otros
clientes de red. Los clientes OPC UA tienen la capacidad de buscar y descubrir servidores OPC
UA, descubrir cómo comunicarse con el servidor OPC UA, descubrir qué capacidades tienen los
servidores OPC UA y configurar el servidor OPC UA para entregar datos específicos cuando y
cómo lo quiero. Los clientes OPC UA generalmente admitirán diferentes asignaciones de
protocolos para que puedan comunicarse con todos los diferentes tipos de servidores.

OPC UA SERVER: un punto final del servidor OPC UA es el lado de una comunicación OPC UA
que proporciona datos a un cliente OPC UA. No existe un servidor OPC UA estándar en
funcionalidad, rendimiento o tipo de dispositivo. Los dispositivos desde sensores pequeños hasta
enfriadores masivos pueden ser servidores OPC UA. Algunos servidores pueden alojar solo un
par de puntos de datos. Otros pueden tener miles. Algunos servidores OPC UA pueden usar
mapeos con alta seguridad y menor rendimiento XML, mientras que otros pueden comunicarse
sin seguridad utilizando la codificación binaria OPC UA de alto rendimiento. Algunos servidores
pueden ser completamente configurables y ofrecer al cliente la opción de configurar vistas de
modelo de datos, alarmas y eventos. Otros pueden ser completamente fijos.

BLOB (Bloque de objetos grandes binarios): los «BLOB» proporcionan una forma de transferir

datos que no tienen definición de datos OPC UA. Normalmente, todos los datos de OPC UA están
referenciados por algún tipo de definición de datos que explica el formato de los datos. Los datos
BLOB se utilizan cuando la aplicación desea transferir datos que no tienen una definición de OPC
UA. Los datos BLOB son definidos por el usuario y pueden ser cualquier cosa: video, audio,
archivos de datos o cualquier otra cosa.

PILA O PILA DE PROTOCOLO: una pila de protocolos como EtherNet / IP o Profinet IO en redes

industriales generalmente implementa el modelo de datos y los servicios de ese protocolo. Una
API conecta ese modelo de datos y el modelo de servicio a los datos de la aplicación del usuario
final. Aunque los proveedores de la pila de protocolos pueden implementar esto de muchas
maneras diferentes, en general, una pila de protocolos OPC UA consta de tres componentes:
codificación de datos, seguridad y transporte de red. Tenga en cuenta que, a diferencia de las
pilas de protocolos IA (automatización industrial), el modelo de datos y el modelo de servicio para
el dispositivo no se incluyen necesariamente en la pila de protocolos.

CODIFICACIONES: una codificación de datos es una forma específica de convertir una solicitud

o respuesta OPC en un flujo de bytes para la transmisión. Actualmente se admiten dos
codificaciones en OPC UA: OPC UA Binary y XML. OPC UA Binary es una codificación mucho
más compacta con mensajes más pequeños, menos espacio de búfer y mejor rendimiento. XML
es una codificación más genérica que se utiliza en muchos sistemas empresariales. XML es más
fácil de procesar para los servidores empresariales, pero requiere más capacidad de
procesamiento, mensajes más grandes y más espacio en el búfer.

PROTOCOLO DE SEGURIDAD: un protocolo de seguridad es la forma de garantizar la

integridad y privacidad de los mensajes que se transfieren a través de una conexión.  OPC UA
utiliza el mismo tipo de seguridad que se usa en Internet para la privacidad y la seguridad: los
certificados.

TRANSPORTES: un transporte es el mecanismo que mueve un mensaje OPC UA entre un

cliente y un servidor. Este es otro término que a primera vista puede resultar confuso. Todos los
mensajes OPC UA se entregan a través de una conexión TCP / IP. Dentro de TCP, hay lo que yo
llamaría una sesión, aunque la palabra «sesión» no se usa específicamente en ningún lugar que
haya encontrado en mi estudio de la tecnología. Hay dos tipos de estas sesiones que envían
mensajes a través de TCP, y se denominan transportes cuando se usa OPC UA. Son OPC UA
TCP y SOAP / HTTP.
MAPPINGS – Este es un término interesante. Las especificaciones OPC UA son muy abstractas,
a diferencia de, por ejemplo, una especificación Modbus RTU. Modbus RTU se ejecuta sobre
RS485 multipunto y ese hecho es inherente a las especificaciones. No es así con OPC UA. Las
especificaciones para la operación OPC UA son muy abstractas y se realizan de esa manera para
mantener la capacidad de aprovechar las tecnologías futuras. Una asignación se refiere a cómo
esas especificaciones abstractas se asignan a una tecnología específica. Por ejemplo, una
asignación de seguridad describe cómo se implementa la capa de canal segura OPC UA
utilizando WS Secure Conversation. Una asignación de codificación binaria OPC UA describe una
forma en que las estructuras de datos OPC UA se asignan a un flujo de bytes.

API (interfaz de programa de aplicación) –Una API es el conjunto de interfaces de software que
permiten que una aplicación de software utilice los servicios de otra aplicación de software.  En el
mundo industrial, esto normalmente se refiere a la interfaz entre dos piezas de software que
cohabitan en el mismo procesador. En el mundo de Ethernet, la API puede referirse a las
interfaces que necesita un dispositivo cliente para acceder a los servicios disponibles de algún
servicio web remoto. En OPC UA, la API generalmente se refiere al conjunto de interfaces que un
proveedor de kit de herramientas OPC UA proporciona a un desarrollador de dispositivos. Debido
a que los diferentes kits de herramientas están diseñados de manera diferente, las API funcionan
de manera diferente. La API puede incluir interfaces para el modelo de datos. En otros casos, la
API solo puede conectar los tres componentes principales de OPC UA: la capa de codificación, la
capa de seguridad y la capa de transporte.

SERVICIOS WEB: servicios web es un término genérico para unir de forma estructurada los
servicios de Internet (aplicaciones). La mayoría de las aplicaciones de Internet hoy en día se
construyen utilizando servicios web. Con los servicios web, puede encontrar servicios fácilmente,
obtener las interfaces y las características de las interfaces y luego vincularlas. HTTP, SOAP,
XML son las tecnologías básicas de las aplicaciones de servicios web y son algunas de las
tecnologías que pueden ser utilizadas por los clientes y servidores OPC UA.

SERIALIZACIÓN – Este es un término fácil de comprender. Este es el proceso de tomar un

servicio como el servicio de atributo de lectura y crear la serie de bytes que un servidor OPC UA
puede procesar y devolver el valor de un atributo. La serialización determina cómo los elementos
de datos como un valor de punto flotante se transforman en una serie de bytes que se pueden
enviar en serie a través de un cable. OPC UA admite actualmente dos tipos de codificación en
serie: OPC UA Binary y OPC UA XML.

CODIFICACIÓN XML OPC UA: la codificación XML es una forma de serializar datos mediante el
lenguaje de marcado extensible (XML). Una codificación es una forma específica de asignar un
tipo de datos a los datos reales que aparecen en el cable. En la codificación XML, los datos se
asignan a la representación de caracteres ASCII altamente estructurada utilizada por XML. XML
puede ser engorroso, grande e inhibir el rendimiento, pero la codificación se utiliza porque una
gran cantidad de programas de aplicaciones empresariales admiten XML de forma
predeterminada.

CODIFICACIÓN BINARIA OPC UA – La codificación binaria OPC UA es una forma de serializar

datos utilizando un estándar de codificación binaria IEEE. Una codificación es una forma
específica de asignar un tipo de datos a los datos reales que aparecen en el cable. En la
codificación binaria, los datos se asignan a una representación de datos binarios muy compacta
que utiliza menos bytes y es más eficiente de transferir y procesar mediante sistemas
integrados. La codificación binaria es ampliamente utilizada por los sistemas de automatización
industrial, pero es menos común entre las aplicaciones empresariales.
PROTOCOLO DE SEGURIDAD: un protocolo de seguridad protege la privacidad y la integridad
de los mensajes. OPC UA aprovecha varios protocolos de seguridad estándar y bien
conocidos. El protocolo de seguridad seleccionado para una aplicación específica es una
combinación de los requisitos de seguridad para la instalación y la codificación y los transportes
seleccionados para la implementación de OPC UA.

PROTOCOLO DE TRANSPORTE: un protocolo de transporte (también denominado

«transporte») proporciona la transferencia de extremo a extremo de los mensajes OPC UA entre
los clientes y servidores OPC UA. Una vez que un mensaje de servicio OPC UA se codifica y
pasa a través de la titulización, está listo para el transporte. Actualmente se definen dos
transportes para OPC UA: OPC UA TCP y SOAP / HTTP. La tecnología subyacente para ambos
transportes es TCP estándar. TCP proporciona la comunicación a nivel de socket entre clientes y
servidores.

TRANSPORTE OPC UA TCP: el transporte OPC UA TCP es esencialmente un pequeño

protocolo que establece un canal de comunicación de bajo nivel entre un cliente y un servidor. La
mayor parte de lo que hace el transporte OPC UA TCP es negociar los tamaños máximos de
búfer para que ambas partes entiendan los límites de la otra. La ventaja de OPC UA TCP es su
tamaño y su impacto insignificante en el rendimiento.

HTTP (Protocolo de transferencia de hipertexto): HTTP es parte de la tubería básica de

Internet. Es el protocolo de bajo nivel que permite que una aplicación cliente como su navegador
solicite una página web desde un servidor web. Los mensajes HTTP solicitan datos o los envían
en un formato muy estándar compatible con todas las aplicaciones con acceso a Internet.

XML (Extensible Markup Language): XML es una forma altamente estructurada de especificar

datos para que las aplicaciones puedan comunicarse fácilmente. XML transfiere todos los datos
como ASCII, el único formato de datos comúnmente comprendido para todos los sistemas
informáticos. XML utiliza una gramática para definir las etiquetas de datos específicas que utiliza
una aplicación para pasar datos.

SOAP (Protocolo simple de acceso a objetos): SOAP extiende XML y proporciona un mayor

nivel de funcionalidad. Entre otras cosas, SOAP agrega la capacidad de realizar llamadas a
procedimientos remotos dentro de una estructura XML.

TRANSPORTE OPC UA DE HTTP / SOAP: el transporte HTTP / SOAP es el segundo transporte

actualmente compatible con OPC UA. Este transporte requiere mensajes más grandes, búferes
más grandes y más procesamiento, pero se usa porque HTTP y SOAP son compatibles con casi
todas las aplicaciones empresariales (si no todas). Es una forma estándar de mover mensajes
OPC UA serializados entre un cliente y un servidor.
También puede visita nuestra tienda virtual de  Logicbus o llámanos al +52 33 3854 5975.

Estandarización y seguridad en el protocolo OPC UA

Publicado el 15/11/2018, por INCIBE
Introducción del protocolo OPC
El protocolo OPC (Object Linking and Embedding for Process Control) nació de la necesidad de una interfaz
común para la comunicación de procesos industriales. Basado inicialmente en la tecnología COM/DCOM de
Microsoft, esta tecnología permite de una manera abstracta la comunicación de diferentes elementos de la red
de procesos.

-Estado inicial sin OPC-

OPC utiliza un planteamiento cliente-servidor para la comunicación. El servidor OPC es el encargado de la
encapsulación de la información y de la disponibilidad de esta a través de su interfaz, mientras que el cliente
OPC se conecta al servidor OPC y accede a la información disponible. En el OPC clásico las interfaces están
basadas en la tecnología COM y DCOM de Microsoft, mientras que en OPC UA en la última versión del
estándar, se utilizan dos protocolos, un protocolo TCP binario de alto rendimiento (OPC-TCP) y un segundo
basado en web services (HTTP).
 -Estado inicial con OPC-

Evolución del protocolo OPC

La primera versión del protocolo OPC, conocida como OPC clásico, se adaptó a las necesidades del momento
y planteaba tres especificaciones distintas:

 OPC DA (Data Access): utilizado para el acceso a datos actuales de los procesos.
 OPC A&E (Alarm and Events): utilizado para información de eventos y alarmas.
 OPC HDA (Historical Data Access): acceso a datos históricos ya almacenados.

La interfaz OPC DA es actualmente la más importante de OPC y la utilizada en la mayoría de los dispositivos
que implementan el protocolo. Las interfaces OPC A&E y OPC HDA son menos relevantes y se utilizan a modo
de complemento de OPC DA.
Después del lanzamiento de la primera versión de OPC, nace OPC XML DA, que es el primer intento de OPC
de crear una especificación OPC independiente de la plataforma, reemplazando la tecnología propietaria de
Microsoft COM/DCOM por HTTP/SOA y tecnologías web, manteniendo la funcionalidad de OPC-DA. El
problema de OPC XML DA fue su bajo rendimiento y consumo elevado de recursos.
Es por estos problemas por lo que nace OPC UA, es decir, por la necesidad real de una herramienta
independiente de la plataforma (del sistema operativo subyacente), pero manteniendo el rendimiento y las
características del OPC clásico.
La aparición de OPC UA supone un cambio total de paradigma en las infraestructuras OPC. Windows deja de
ser un requisito obligatorio al pasar el protocolo a ser independiente de la plataforma. Es tanto el cambio que
supone OPC UA, que hasta cambia el significado de las siglas OPC, de OLE for Procces Control a Open
Platform Communication.
El objetivo principal de OPC UA es unificar toda la arquitectura OPC clásica en una infraestructura
independiente de la plataforma, manteniendo toda la funcionalidad, evitando así la dependencia de los sistemas
de Microsoft y de su tecnología COM/DCOM. Para ello, define los mecanismos de transporte y modelo de
datos.
En cuanto al transporte define dos mecanismos, como ya se han mencionado anteriormente. Por un lado, un
protocolo TCP binario de alto rendimiento para comunicaciones intranet y acceso a los estándares de Internet
aceptados como HTTP.
En cuanto al modelo de datos define las reglas y bloques necesarios para el acceso al espacio de direcciones.
Los servicios en OPC UA se definen de manera abstracta y se utilizan los mecanismos de transporte para
intercambiar datos entre cliente y servidor. Gracias a esta abstracción, un cliente puede acceder a los datos sin
entender el modelo de datos subyacente.
 -Flujo de comunicación de una aplicación OPC UA-

Medidas de seguridad OPC clásico vs OPC UA

En el estándar OPC se implementan varias medidas de seguridad a la hora de garantizar los principios de
confidencialidad, integridad y disponibilidad. Para ello, plantea los siguientes objetivos:

Autenticación de la aplicación
Mediante el mecanismo de autenticación, se permite a las aplicaciones que corren bajo OPC UA identificarse
las unas a las otras. Para ello, poseerán un certificado digital que comparte en la fase de conexión.
En cambio, en OPC clásico, no todos los clientes y servidores OPC soportan este tipo de restricciones, por lo
que normalmente no se encuentra configurado. Además, configurar la autenticación de las aplicaciones
requiere mucho trabajo, ya que requiere configurar todos los elementos DCOM.
Por lo tanto, OPC UA aporta mayor facilidad a la hora de implementar mecanismos de autenticación de la
aplicación en comparación con la versión clásica.

Autenticación del usuario

En OPC UA la autenticación del usuario es de obligado cumplimiento, y son soportados varios mecanismos de
autenticación, en comparación con la versión clásica en la cual la autenticación no se encuentra habilitada por
defecto pudiendo llegar a ser costosa su habilitación.
Para la autenticación del usuario en OPC UA se pueden utilizar varios mecanismos; uno de ellos es mediante la
combinación de usuario y contraseña, otro sería mediante el uso de certificado digital, por último, también
permite la autenticación mediante ticket Kerberos. Todas las aplicaciones que utilicen OPC UA deben soportar
la combinación usuario y contraseña, que es la más sencilla de implementar, pero puede ser la más difícil de
configurar, ya que ha de hacerse en cada aplicación. La selección de la manera de identificar al usuario es
específica de la aplicación. La identificación de usuario de OPC UA funciona de manera similar entre máquinas
(p. ej. cliente OPC, servidor OPC) dentro de un mismo grupo de trabajo, de un mismo dominio, entre dominios
distintos, o incluso cuando la plataforma (sistema operativo) de estas es distinta.
En cuanto a OPC clásico el acceso no se encuentra restringido por defecto. En un entorno de dominio, el
dominio debería identificar todos los servidores OPC clásico y asignar los derechos de acceso adecuados a los
grupos de usuarios (roles) de los clientes que se conectarán. Dado que todas las cuentas de un dominio se
administran desde un controlador central, es sencillo habilitar la autenticación de los usuarios, pero al no estar
habilitada por defecto ha de ser configurada manualmente en el controlador central del dominio. En un entorno
que no sea de dominio, se puede configurar, pero requiere trabajo adicional para identificar a los usuarios
(cuentas comunes en todas las máquinas, grupo de usuarios común (roles), etc.).

Autorización del usuario

En OPC UA, una vez que el usuario es identificado y autenticado, es la aplicación la encargada de restringir los
derechos de acceso para un usuario determinado con respecto a la navegación de lectura / escritura, etc.
Lo mismo ocurre en OPC clásico, donde las aplicaciones del mismo, pueden proporcionar restricciones de
acceso individual para un elemento determinado frente al acceso DCOM general de lectura o escritura, pero
pocas o ninguna aplicación incluyen este tipo de restricción.

Disponibilidad del servidor

Otro punto importante que contempla OPC UA es la disponibilidad de los servidores de la aplicación. No es algo
que dependa del protocolo, sino que se recomienda que los servidores OPC implementen mecanismos para la
disponibilidad de su sistema, como puede ser la disponibilidad de servidores de respaldo o el soporte para
configuración de redundancia.

Auditabilidad del sistema

En OPC UA también se contempla la capacidad del sistema para ser auditado. Para ello, OPC UA define los
mecanismos necesarios para que un servidor pueda almacenar en los ficheros de log todos los eventos
relevantes.

Confidencialidad e integridad
La confidencialidad e integridad de los datos se contempla en la capa de transporte de OPC UA mediante el
cifrado de las comunicaciones. Si se utilizan los servicios web para la comunicación, se usa el protocolo  WS
Secure Conversation. En caso de la versión TCP binaria se utiliza una adaptación de WS Secure Conversation.
Por último, existe una versión mixta en la cual se utiliza TLS.
En cuanto al cifrado de los datos en OPC clásico, DCOM puede configurarse para proporcionar tanto el firmado
de los datos como el cifrado. El problema de DCOM es que no tiene el cifrado habilitado por defecto y por lo
tanto, debe ser configurado.
Tanto en el estándar OPC clásico como en OPC UA es posible el cifrado de las comunicaciones, la principal
diferencia reside en que en OPC UA el cifrado se encuentra habilitado por defecto, mientras que en el estándar
clásico ha de ser implementado manualmente.

Conclusiones
Algunos incidentes de seguridad como CrashOverride ponen de manifiesto las debilidades que posee el
estándar OPC clásico y es por ello que la OPC Foundation define en su último estándar, OPC UA, nuevos
mecanismos de seguridad que son obligatorios y que aportan un nivel superior respecto a la versión OPC
clásico.
Etiquetas: 
Sistema de Control Industrial