Pero, ¿cómo y, sobre todo, porqué se desarrolló OPC UA? OPC Foundation la desarrolló y la especificación inicial se introdujo en 2008, existiendo después varias versiones y revisiones del estándar para mejorar su funcionalidad y adaptarse a las cambiantes necesidades de la industria.

El objetivo era abordar las limitaciones y desafíos del OPC original, que hoy llamamos habitualmente OPC Classic, y que buscaba ser más seguro, escalable, interoperable y adecuado para las necesidades actuales y futuras de la industria.

Por lo tanto, esto nos lleva a más años hacia atrás a través de la siguiente pregunta: ¿por qué se desarrolló OPC? Se originó en la década de los 90 del siglo pasado y fue necesario debido a la, cada vez más, necesidad de automatización y de un software que la pudiera gestionar.

En ese momento, en temas relacionados con la visualización de variables o del estado de la planta se utilizaban mayormente plataformas basados en Windows. Por lo tanto, si se quería comunicar con los diferentes PLCs (Programmable Logic Controller) se necesitaba un driver específico para cada uno de ellos, con todas las posibles diferencias en los protocolos o conexiones entre ellos.

Por lo tanto, el desarrollo de OPC (OLE for Process Control) se originó debido a la necesidad de establecer una forma estándar de comunicación entre dispositivos y sistemas en la industria de automatización y control. Mencionamos algunas razones para su desarrollo:

• Automatización Industrial: Con el crecimiento de la automatización industrial, había una creciente demanda de una forma eficiente y estandarizada de intercambiar datos en tiempo real entre dispositivos, sensores, controladores y sistemas de supervisión.
• Heterogeneidad de Sistemas y Protocolos: Antes de OPC Classic, había una falta de estándares para la comunicación entre dispositivos y sistemas en la automatización industrial. Los sistemas utilizaban diferentes protocolos y enfoques de comunicación, lo que dificultaba la interoperabilidad entre dispositivos de diferentes fabricantes.
• Necesidad de Integración: Los datos no eran fácilmente accesibles por lo que su envío a diferentes aplicaciones no era sencillo y las empresas buscaban integrar sistemas de control y adquisición de datos en una sola plataforma. Por lo tanto, se necesitaba una comunicación eficiente entre diferentes sistemas y equipos, independientemente de su origen. OPC proporcionó una interfaz estandarizada que permitía a los sistemas interactuar y compartir datos de manera más fluida.
• Aprovechamiento de tecnologías existentes en Windows: En el momento en que se desarrolló OPC Classic, las tecnologías como COM (Component Object Model) y DCOM (Distributed Component Object Model) eran prominentes en el desarrollo de software de Windows, así que OPC Classic aprovechó estas tecnologías para habilitar la comunicación entre dispositivos y sistemas.

Lo que se propuso fue el desarrollo de una capa que haría de puente entre el propio HMI (Human Machine Interface) y los drivers de cada PLC. De este modo, los diferentes programas existentes para generar un HMI no tendrían que conocer todos los drivers necesarios.

Esta capa sería por lo tanto el llamado “Servidor OPC”, mientras que los diferentes elementos que se conectaran (como podría ser un SCADA) pasarían a ser los “Clientes OPC”. Para realizar la comunicación entre el servidor y los diferentes clientes se usaron las tecnologías COM (Component Object Model) y DCOM (Distributed Component Object Model) comentadas, las cuales ya existían en Windows.

Estas tecnologías fueron desarrolladas por Microsoft y se utilizaron para facilitar la creación de software modular, reutilizable y distribuido en entornos de sistemas operativos Windows. Estas tecnologías proporcionaron un marco para el desarrollo de componentes de software independientes que podrían interactuar entre sí de manera eficiente y coherente. Vamos a definirlas:

Component Object Model (COM): COM es un modelo de programación de software que permite a los desarrolladores crear componentes de software independientes y reutilizables. Un componente COM es un objeto de software autónomo que encapsula una funcionalidad específica. Estos componentes pueden ser llamados por otras aplicaciones o componentes para realizar diferentes tareas. Se basa en interfaces y define cómo los componentes se comunican entre sí a través de llamadas a funciones.

Las principales características de COM incluyen la encapsulación de datos y funcionalidad, la reutilización de componentes, la interoperabilidad entre lenguajes de programación y la facilidad de mantenimiento y actualización del software.

Hay que decir que COM es un modelo para la comunicación dentro del mismo PC, lo que nos lleva al DCOM.

Distributed Component Object Model (DCOM): DCOM es una extensión de COM que permite la comunicación entre componentes a través de una red, lo que facilita la creación de aplicaciones distribuidas y cliente-servidor, soportando la comunicación remota entre componentes en diferentes computadoras.

Esto es especialmente útil en entornos de red empresarial donde las aplicaciones necesitan acceder a recursos en diferentes sistemas. DCOM utiliza tecnologías de protocolo de red para lograr la comunicación entre componentes distribuidos.

Ambas tecnologías, COM y DCOM, jugaron un papel importante en el desarrollo de aplicaciones Windows, permitiendo a los desarrolladores crear sistemas más flexibles, modulares y distribuidos.