OPC

De Wikipedia, la enciclopedia libre

El OPC (OLE for Process Control) es un estándar de comunicación en el campo del

control y supervisión de procesos. Este estándar permite que diferentes fuentes de datos
envíen datos a un mismo servidor OPC, al que a su vez podrán conectarse diferentes
programas compatibles con dicho estándar. De este modo se elimina la necesidad de que
todos los programas cuenten con drivers para dialogar con múltiples fuentes de datos,
basta que tengan un driver OPC.

En realidad OPC es un conjunto de protocolos entre los que podemos destacar los
siguientes:

OPC-DA (Data Access).- El original, sirve para el intercambio de datos a tiempo real
entre servidores y clientes.

OPC-AE (Alarms & Events).- Proporciona alarmas y notificaciones de eventos.

OPC B (Batch).- Útil en procesos discontinuos.

OPC DX (Data eXchange).- Proporciona interoperabilidad entre varios servidores.

OPC HDA (Historical Data Access).- Acceso histórico a datos OPC.

OPC S (Security).- Especifica cómo controlar el acceso de los clientes a los servidores.

OPC XML-DA (XML Data Access).- Sirve para el intercambio de datos entre
servidores y clientes como OPC-DA pero en vez de utilizar tecnología COM/DCOM
utiliza mensajes SOAP (sobre HTTP) con documentos en XML.

OPC CD (Complex Data).- Permite a los servidores exponer y describir tipos de datos
más complicados en forma de estructuras binarias y documentos XML.

Este estandar está siendo mantenido por la Fundación OPC.

Entre las desventajas de este estándar podemos mencionar el problema de la seguridad,

que aún no está resuelto y su dependencia del Sistema Operativo Windows(con la
especificación OPC XML-DA se empieza a eliminar esta dependencia).
OLE for process control

From Wikipedia, the free encyclopedia

OLE for Process Control (OPC) which stands for Object-Linking and Embedding
(OLE) for Process Control, is the original name for an open standards specification
developed in 1996 by an industrial automation industry task force. The standard
specifies the communication of real-time plant data between control devices from
different manufacturers.

After the initial release, the OPC Foundation was created to maintain the standard.
Since then, standards have been added and names have been changed. Currently (June,
2006), "OPC is a series of standards specifications". (Seven current standards and two
emerging standards.) "The first standard (originally called simply the OPC
Specification"), is "now called the Data Access Specification", or (later on the same
page) "OPC Data Access", or OPC Data Access Specification.

While OPC originally stood for "OLE for Process Control", the official stance of the
OPC Foundation is that OPC is no longer an acronym and the technology is simply
known as "OPC". One of the reasons behind this is while OPC is heavily used within
the process industries, it can be, and is, widely used in discrete manufacturing as well.
Hence, OPC is known for more than just its applications within process control.

Origin and Uses

The OPC Specification was based on the OLE, COM, and DCOM technologies
developed by Microsoft for the Microsoft Windows operating system family. The
specification defined a standard set of objects, interfaces and methods for use in process
control and manufacturing automation applications to facilitate interoperability.

OPC was designed to bridge Windows based applications and process control hardware
and software applications. It is an open standard that permits a consistent method of
accessing field data from plant floor devices. This method remains the same regardless
of the type and source of data.

OPC servers provide a method for many different software packages to access data from
a process control device, such as a PLC or DCS. Traditionally, any time a package
needed access to data from a device, a custom interface, or driver, had to be written. The
purpose of OPC is to define a common interface that is written once and then reused by
any business, SCADA, HMI, or custom software packages.

Once an OPC server is written for a particular device, it can be reused by any
application that is able to act as an OPC client. OPC servers use Microsoft’s OLE
technology (also known as the Component Object Model, or COM) to communicate
with clients. COM technology permits a standard for real-time information exchange
between software applications and process hardware to be defined.
Future

The OPC Unified Architecture (UA) has been specified and is being tested and
implemented through its Early Adopters program. It can be implemented with Java,
Microsoft .NET, or C, eliminating the need to use a Microsoft Windows based platform
of earlier OPC versions. UA combines the functionality of the existing OPC interfaces
with new technologies such as XML and Web Services to deliver higher level MES and
ERP support. It looks to become the standard for exchanging industrial data, replacing
FactoryTalk, Archestra, some Modbus applications, and OPCDA.
OPC
OLE for Process Control

From http://www.automatas.org/redes/opc.htm

Motivos para el desarrollo de la especificación OPC - 1

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.

Se trata de 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.

Motivos para el desarrollo de la especificación OPC - 2

Hay 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 puesto 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. Los fabricantes de hardware pueden
desarrollar servidores optimizados para recoger datos de sus dispositivos. Dando al
servidor un interfase OPC permite a cualquier cliente acceder a dichos dispositivos.
Motivos para el desarrollo de la especificación OPC - 3

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
VisualBasic 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, de manera que quienes desarrollen aplicaciones
empresariales puedan escribir código en VisualBasic que recoja y utilice datos de
planta.

El diseño de los interfases OPC soporta arquitecturas distribuídas en red. El acceso a

servidores OPC remotos se hace empleando la tecnología DCOM (Distributed COM) de
Microsoft.
Integración de sitemas heterogéneos con OPC

Arquitectura general y componentes OPC

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 interfases, 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.