OPC “OLE for Process Control”

Surgimiento de OPC

En cooperación con Microsoft, una fuerza constituida por cinco empresas, Intellution, Opto-22, Fisher-Rosemount, Rockwell Software y Intuitiv Software, nace OPC Foundation en Mayo de 1995.

Este grupo de empresas pretendía definir una serie de especificaciones basadas en COM/DCOM y el primer borrador de las mismas fue completado al final de 1995, gracias a la colaboración de otras 90 compañías a lo largo del mundo, las cuales comprobaron estas especificaciones. El primer conjunto oficial de especificaciones se completó en Agosto de 1996.

El objetivo del comité conformado fue proporcionar una interfaz de programación de aplicaciones estándar para el intercambio de datos que pudiese simplificar el desarrollo de drivers de I/O y mejorar el rendimiento de los sistemas de interfaz; el esquema que reinaba en ese entonces y el cual se pretendía cambiar era el siguiente:

Figura. 1 Modelo de arquitectura de automatización industrial basado en drivers.

Según el documento OPC Overview publicado por OPC Foundation en 1998, esta arquitectura conduce a problemas como:Duplicación de esfuerzoSe deben escribir programas amarrados a un driver para el hardware de un vendedor particular.Inconsistencias entre vendedores de driversLas características de hardware no son soportadas por todos los drivers.

Soporte para cambios en características de hardwareUn cambio en las capacidades del hardware puede ocasionar conflictos en los drivers.

Conflictos de AccesoDos paquetes, generalmente, no pueden acceder simultáneamente al mismo dispositivo, puesto que cada uno contiene drivers independientes. Los fabricantes de hardware procuran resolver estos problemas desarrollando nuevos drivers, pero son obstaculizados por diferencias en los protocolos del cliente. No se puede desarrollar un driver eficiente que pueda ser utilizado por todos los diferentes tipos de clientes.

En estas circunstancias resulta muy complejo realizar aplicaciones industriales, pues no existe una forma estándar de definir las conexiones sin tener que depender del tipo de dispositivo. El OPC eliminó este problema estableciendo una interfase de comunicación común, lo cual ha beneficiado enormemente el desarrollo de aplicaciones HMI y sistemas SCADA. La siguiente figura representa una primera idea sobre un ambiente de monitoreo y control industrial basado en OPC:

Figura. 2 Modelo de arquitectura de automatización industrial basado en OPC

Definición de OPCEl OPC, (OLE para el Control de Procesos) “es una especificación técnica no propietaria definida por la Entidad OPCFoundation y consiste básicamente en un Sistema de Interfaces Estándar basado en OLE/COM de Microsoft” 1; con OPC es posible interoperar dispositivos industriales con sistemas de información o aplicativos de escritorio. En otras palabras, el OPC permite desarrollar de una manera muy práctica y eficiente aplicaciones que pretendan comunicarse con equipos industriales controlados por PLCs.

OPC FoundationOPCFoundation es una entidad sin ánimo de lucro, encargada de administrar la especificación OPC.

Ventajas de OPCEl OPC ofrece varias ventajas las cuales también fueron citadas por OPC Foundation en su OPC Overview; se destacan las siguientes:

Los fabricantes de hardware tienen que hacer solamente un conjunto de componentes de software para que los clientes los utilicen en sus aplicaciones.

Los desarrolladores de software no tienen que reescribir drivers debido a cambios en características o adiciones en un hardware.

Los clientes tendrán más opciones con las cuales puedan desarrollar diversos sistemas de aplicación a nivel industrial.

Con el OPC la integración de un sistema industrial, en un ambiente de computación heterogéneo resulta simple, es decir, se puede obtener como resultado una arquitectura como la que se ilustra en la Figura 3, página 4.

1 CASTILLO, Juan Del. Tendencias en Arquitecturas de Control: OLE for Process Control. p. 4

Figura 3. Ambiente Heterogéneo de Sistemas para la Industria.

Posibilidades con el OPC:

Acceder a datos en línea: La lectura y la escritura eficiente de datos entre una estación central y un dispositivo de control de procesos se puede realizar de forma flexible y eficiente.

Control de alarmas: El OPC provee mecanismos para que sus clientes sean notificados de la ocurrencia de acontecimientos y de condiciones de alarmas especificadas.

Acceso a datos históricos: El OPC permite la lectura, procesamiento y corrección de datos históricos con un eficiente motor de acceso.

Con la arquitectura OPC se aprovechan las ventajas de la interfaz COM para ampliar su funcionalidad.

La especificación OPC incluye lo siguiente:

1. Interfase COM/DCOM para ser usada por clientes Locales o Remotos.

2. Referencias a la Interfase de Automatización OLE.

Requerimientos de FuncionalidadLa siguiente lista de requerimientos de funcionalidad fue tomada del documento Data Access Automation Interface Standard Versión 2.01, publicado por OPC Foundation.

OPC es soportado completamente por VC++, Visual Basic y Delphi. Cualquier cliente con interfaz OLE con ciertas limitaciones. No soporta el uso con VBScript o JavaScript. La especificación OPC requiere como Sistema Operativo Windows 95/98 (con

DCOM), Windows NT 4.0 o Superior. En todos los casos es recomendable instalar la última versión de Services Pack correspondiente.

Funcionamiento de OPCUn cliente OPC puede conectarse a servidores OPC de uno o varios vendedores.

Se puede construir un cliente con una interfase personalizada, para lo cual se puede usar un lenguaje de alto nivel como Visual C++, pero los clientes más comunes se construyen bajo una interfase automatizada que puede ser desarrollada en lenguajes como Visual Basic 6.0, Delphi y recientemente .NET gracias a COM-Interop.

La Figura 4 representa el funcionamiento del OPC con las interfaces personalizada y automatizada.

Figura. 4. Funcionamiento e Interfaces de OPC

Modelo de Objetos de la Especificación OPCEl modelo jerárquico de objetos definido por OPC Foundation se representa en la siguiente figura:

Figura. 5. Modelo de Objetos del Servidor de Automatización OPC

La descripción de cada uno de los objetos del modelo anterior, se presenta en la siguiente tabla:

Tabla 1. Descripción de la colección de objetos de la especificación OPC 2

OBJETO DESCRIPCIÓN

OPCServer Es una instancia de un servidor OPC. Se debe crear un objeto OPCServer antes de poder referenciar los otros objetos. Este contiene la colección OPCGroups y el objeto OPCBrowser.

OPCGroups Es una colección de los objetos OPCGroup que el cliente ha creado.

OPCGroup El propósito de este objeto es mantener la información de estado y proveer el mecanismo para ofrecer los servicios de adquisición de datos por la colección de objetos OPCItem.

OPCItems Es una colección que contiene todos los objetos OPCItem que el cliente ha creado.

OPCIterm Es un objeto que mantiene la definición de los items, sus valores, estados y datos de la última actualización.

OPCBrowser Es un objeto que permite buscar nombres de items en un servidor configurado.

Un servidor de acceso a datos OPC está formado por varios objetos: el servidor, el grupo y el elemento. “El servidor de objetos OPC ofrece información sobre el

2 OPC Foundation. Data Access Automation Interface Standard: OPC Automation Server Object Model. p. 13

servidor y sirve como un contenedor de grupos de objetos OPC. El grupo de objetos OPC mantiene información acerca de sí mismo y proporciona los mecanismos para contener y organizar lógicamente los elementos OPC” 3; los grupos OPC proporcionan una forma para organizar los datos de los clientes, por ejemplo, el grupo podría representar los elementos en un pantalla particular del operador o a través de un informe; los datos pueden ser leídos y escritos, y las conexiones basadas en excepciones, pueden ser creadas entre el cliente y los elementos en el grupo y pueden ser activadas y desactivadas según sea necesario; un cliente OPC puede configurar que porcentaje de los datos deben ser cambiados antes de la actualización.

Hay dos tipos de grupos, públicos y locales (o privados); los públicos se realizan para ser compartidos entre varios clientes, mientras que los locales son privados para el cliente en cuestión. Existen interfaces específicas opcionales para los grupos públicos; dentro de cada grupo, el cliente puede definir uno o más elementos OPC, la siguiente imagen ilustra esta relación:

Figura 6. Relaciones entre Grupos e Items

Los elementos OPC representan conexiones a fuentes de datos dentro del servidor; un elemento OPC, no es accesible por el cliente como un objeto. Así pues, no hay una interfaz externa definida para un elemento OPC; todos los accesos al elemento OPC se realizan a través del objeto grupo OPC que contiene el elemento OPC, o simplemente el grupo en el que el elemento ha sido definido.

Asociado a cada elemento existe un valor, calidad y valor temporal. “Los elementos no son las fuentes de datos, sólo son conexiones a ellas; el elemento OPC debe ser entendido como la dirección de los datos, no como la fuente física actual de los datos a los que la dirección referencia” 4, puesto que la fuente real de los datos es el dispositivo controlador, regularmente un PLC.

Marlon MartínezAnalista de SistemasCENTELSACALI – COLOMBIA

3 OPC Foundation. OPC Overview: OPC DataAccess Overview. p. 114 OPC Foundation. OPC Overview: OPC DataAccess Overview. p. 12

marlonma@centelsa.com.co