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 esfuerzo
Se deben escribir programas amarrados a un driver para el hardware de un
vendedor particular.
Inconsistencias entre vendedores de drivers
Las características de hardware no son soportadas por todos los drivers.

Soporte para cambios en características de hardware

Un cambio en las capacidades del hardware puede ocasionar conflictos en los
drivers.

Conflictos de Acceso
Dos 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 OPC
El 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 Foundation
OPCFoundation es una entidad sin ánimo de lucro, encargada de administrar la
especificación OPC.

Ventajas de OPC
El 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 Funcionalidad
La 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 OPC
Un 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 OPC
El 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:
2
Tabla 1. Descripción de la colección de objetos de la especificación OPC

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
servidor y sirve como un contenedor de grupos de objetos OPC. El grupo de

2
OPC Foundation. Data Access Automation Interface Standard: OPC Automation Server Object
Model. p. 13
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ínez
Analista de Sistemas
CENTELSA
CALI – COLOMBIA
marlonma@centelsa.com.co
3
OPC Foundation. OPC Overview: OPC DataAccess Overview. p. 11
4
OPC Foundation. OPC Overview: OPC DataAccess Overview. p. 12