Los sistemas de automatización basados en OPC aumentaron con mucha frecuencia en los años en que se producía la automatización industrial. Uno de los esfuerzos más grandes para el desarrollo de software se dirigió en la parte del acceso a datos realizado por un gran número de dispositivos, interfaces, redes y protocolos.
Esto nos hace tener mucho interés en querer explicar cómo se produjo el paso del protocolo OPC a la tecnología OPC UA.
El problema del driver compatible
Partimos de la idea de que el problema principal que existía en todos ellos tenía su base en el MS-DOS y se trataba de que cada aplicación precisaba un driver personalizado para la impresora que, a su vez, todas ellas pudieran soportar. Windows quiso enfrentarse al problema añadiendo un soporte para las impresoras que partiera desde el propio sistema operativo, de manera que fueran los propios fabricantes de cada impresora los que ofrecieran los drivers de la misma.
Como este problema se daba en otros sectores, se creó un grupo de trabajo formado por varias compañías, cuyo objetivo sería el de definir un estándar de tipo Plug & Play que proporcionara un acceso estándar para los datos de automatización en sistemas que utilizaran Windows.
De todo esto, salió una especificación OPC-DA en 1966. Esta estuvo soportada por casi todos los proveedores de sistemas de automatización de tipo industrial y es la interfaz más importante para todos los productos de tipo OPC. Se trata de un estándar que permite intercambiar datos entre sistemas de automatización industrial.
Existen dos niveles de actuación y a continuación, voy a explicar cada uno de ellos de manera particular.
Protocolo OPC clásico
Existen dentro de ésta, tres especificaciones diferentes:
- OPC-DA: Acceso a los datos de proceso que existen actualmente.
- OPC-A&E: Información que se basa en reconocimiento de alarmas y de eventos.
- OPC-HDA: Acceso a datos guardados en un histórico.
Como OPC, utiliza el sistema de cliente-servidor se puede decir que el servidor OPC guarda toda la fuente de información y la mantiene disponible mediante una interfaz concreta. Por otro lado, la parte relativa al cliente se conecta al servidor OPC y puede consumir la información que este ofrece.
La ventaja principal de este planteamiento es que se produce una alta reducción del trabajo en la especificación de la definición de las API’s para las necesidades sin que haya que definir un protocolo mediante el que se comuniquen los diferentes procesos.
OPC-DA permite que se puedan leer, escribir y controlar las variables que contienen los datos del proceso; aunque su principal función sea la de transmitir datos en tiempo real en las PLC’s.
OPC-A&E recibe notificaciones acerca de eventos y alarmas, lo que permite informar al cliente acerca de algún cambio en el proceso o de alguna práctica errónea realizada dentro del mismo.
OPC-HDA permite que se acceda directamente a datos que ya se han almacenado de manera uniforme para poder leer datos que cambian constantemente dentro de un histórico.
OPC posee múltiples especificaciones básicas comunes a todas las especificaciones de OPC basadas en COM. Así que lo interesante es tener una idea parcial acerca de las mismas para poder comprender cómo se ha llegado a pasar del protocolo OPC a la tecnología OPC UA.
¿Quieres saber más? Continuaremos muy pronto con la parte 2 de este artículo.
¡Gracias! Te contactaremos pronto