Estándares de Comunicación OPC para la Industria de Procesos: Acceso y Gestión de Datos

OPC para el Control de Procesos

Motivos para el desarrollo de la especificación OPC

La arquitectura informática para la industria de proceso incluye los siguientes niveles:

• Gestión de Campo: Información sobre los dispositivos de instrumentación (estado, constitución, configuración, etc.).
• Gestión de Proceso: Datos sobre el proceso productivo adquiridos y procesados por sistemas SCADA y DCS.
• Gestión de Negocio: Integración de la información de planta en los sistemas que gestionan los aspectos financieros de la fabricación.

El objetivo es que en la industria se puedan utilizar herramientas estándar (paquetes SCADA, bases de datos, hojas de cálculo) para construir un sistema que responda a sus necesidades de mejora de la productividad. Para ello, es necesario desarrollar una arquitectura de comunicaciones abierta y efectiva que se centre en el acceso a los datos, no en los tipos de datos.

Actualmente, existen muchas aplicaciones cliente que requieren datos de dispositivos y acceden a ellos desarrollando controladores o drivers de forma independiente. Esto implica:

• Duplicación de esfuerzos: Todos los programas necesitan un driver para un determinado hardware.
• Falta de consistencia entre drivers: Hay características del hardware no soportadas por todos los drivers.
• Cambios en el hardware: Hacen que los drivers queden obsoletos.
• Conflictos de acceso: Generalmente, dos programas no pueden acceder simultáneamente al mismo dispositivo, ya que poseen drivers independientes.

Los fabricantes de hardware no pueden desarrollar un driver eficiente utilizable por todos los clientes debido a las diferencias de protocolos entre clientes.

OPC proporciona un mecanismo para extraer datos de una fuente y comunicarlos a cualquier aplicación cliente de manera estándar.

Origen de la especificación OPC

OPC se basa en la tecnología OLE/COM (Object Linking and Embedding / Component Object Model) de Microsoft. Esta es la tecnología que permite que componentes de software (escritos en C y C++ por expertos en un sector) sean utilizados por una aplicación (escrita en Delphi o Visual Basic para otro sector).

De esta forma, se desarrollarán componentes en C y C++ que encapsulen los detalles de acceder a los datos de un dispositivo.

El diseño de las interfaces OPC soporta arquitecturas distribuidas en red. El acceso a servidores OPC remotos se hace empleando la tecnología DCOM (Distributed COM) de Microsoft.

Arquitectura de un Servidor OPC

Un servidor OPC se compone de varios objetos que se ajustan a la norma COM:

• El objeto servidor: Contiene información sobre la configuración del servidor OPC y sirve de contenedor para los objetos tipo grupo.
• El objeto grupo: Sirve para organizar los datos que leen y escriben los clientes (ej.: valores en una pantalla MMI o en un informe de producción). Se pueden establecer conexiones por excepción entre los clientes y los elementos de un grupo. Un grupo puede ser público, es decir, compartido por varios clientes OPC.
• El objeto item: Representa conexiones a fuentes de datos en el servidor (no son las fuentes de datos en sí). Tiene asociados los atributos Value, Quality y Time Stamp. Los accesos a los items OPC se hacen a través de los grupos OPC y los clientes pueden definir el ritmo al cual el servidor les informa sobre cambios en los datos.

El acceso a los objetos COM se hace a través de interfaces, que son lo único que ven los clientes OPC. Los objetos descritos son representaciones lógicas que no tienen porqué coincidir con la implementación que se haga del servidor OPC.