U4 t9 opc eai

1. Universidad de Oriente
Núcleo Monagas
Escuela de Ingeniería y Ciencias Aplicadas
Departamento de Ingeniería de Sistemas
Cursos Especiales de Grado
Área: Automatización y Control de Procesos Industriales
Estrategias para Automatización Industrial (EAI)
OPC (OLE for Process Control)
OLE para el Control de Procesos
Unidad IV – SISTEMAS DE SUPERVISIÓN Y CONTROL
Tutor de Seminario: Integrantes:
Ing. Judith Devia Marcano Spréa, Estefani Carolina
C.I.: 20 646 564
Paris Acuña, Iliana Gabriela
C.I.: 22 968 567
Equipo OPC
Maturín, Marzo de 2016

2. ÍNDICE
INTRODUCCIÓN..................................................................................................................3
MARCO TEÓRICO ...............................................................................................................4
1. ¿Qué es OPC?..............................................................................................................4
2. ¿Cómo funciona OPC? ................................................................................................4
3. ¿Qué tipos de datos soporta OPC?...............................................................................4
4. OPC Clásico.................................................................................................................5
5. ¿Qué es y qué hace un Servidor OPC? .......................................................................5
6. ¿Con qué tipos de Fuentes de Datos puede comunicar un Servidor OPC? .................5
7. ¿Cómo trabaja un Servidor OPC?................................................................................6
8. ¿Qué es y qué hace un Cliente OPC? ..........................................................................6
9. ¿Dónde está instalado el Cliente OPC? .......................................................................7
10. ¿Cómo trabaja un Cliente OPC?.................................................................................7
11. OPC UA......................................................................................................................7
12. Beneficios de utilizar conectividad OPC ...................................................................8
DISCUSIÓN ...........................................................................................................................9
CONCLUSIONES................................................................................................................11
REFERENCIAS BIBLIOGRÁFICAS .................................................................................12

3. INTRODUCCIÓN
Tener una conectividad de datos dentro de los procesos debe ser esencial, ya que estos
son los que nos muestran como se está realizando el proceso actual. OPC nace de esta
necesidad pero más que como un protocolo como un estándar que permita la interconexión
de los elementos que conforman el proceso. Desarrollado en 1996 por OPC Foundation y
basado en tecnología utilizado por Microsoft, OLE para el Control de Procesos brinda una
forma de conectar los componentes de manera abierta e independiente del fabricante de los
dispositivos tanto lógicos como físicos.
El OPC es una tecnología que ha venido utilizando una cantidad considerable de
empresas, e incluso proyectos se han diseñado y desarrollado mediante ésta. Se caracteriza
por poseer dos componentes fundamentales el Servidor OPC y el Cliente OPC, cada uno
realiza una función específica dentro de la conectividad de todos los elementos, igualmente
la OPC Foundation muestra dos tipos de OPC uno denominado clásico y otro UA. Es por
ello que dentro de ésta investigación se abarcaran dichos puntos a fin de entender cómo
opera OPC dentro de la comunicación de los componentes conformadores del proceso.

4. 4
MARCO TEÓRICO
1. ¿Qué es OPC?
OPC significa OLE (Object Linking and Embeding, enlace e incrustación de objetos)
para Control de Procesos (Process Control) y está basado en la tecnología COM
(Component Object Model) de Microsoft. En agosto de 1996, se crea la fundación OPC
para gestionar el estándar OPC, que es un estándar abierto para comparar datos entre
dispositivos de campo y aplicaciones de ordenador. [1]
OPC es el método de conectividad de datos basado en los estándares más populares del
mundo. Es utilizado para responder a uno de los mayores retos de la industria de la
automatización: cómo comunicar dispositivos, controladores y/o aplicaciones sin caer en
los problemas habituales de las conexiones basadas en protocolos propietarios. OPC no es
un protocolo, sino más bien un estándar para la conectividad de datos que se basa en una
serie de especificaciones OPC gestionadas por la OPC Foundation. Cualquier software que
sea compatible con estas especificaciones OPC proporciona a usuarios e integradores
conectividad abierta e independiente tanto del fabricante del dispositivo como del
desarrollador de la aplicación Cliente. [2]
2. ¿Cómo funciona OPC?
Se puede representar como una capa de “abstracción” intermedia que se sitúa entre la
Fuente de Datos y el Cliente de Datos, permitiéndoles intercambiar datos sin saber nada el
uno del otro. La “abstracción de dispositivo” OPC se consigue utilizando dos componentes
OPC especializados llamados Cliente OPC y Servidor OPC. Es importante resaltar que el
hecho de que la Fuente de Datos y el Cliente de Datos puedan comunicar entre sí mediante
OPC no significa que sus respectivos protocolos nativos dejen de ser necesarios o hayan
sido reemplazados por OPC. Al contrario, estos protocolos y/o interfaces nativos siguen
existiendo, pero sólo comunican con uno de los dos componentes del software OPC. Y son
los componentes OPC los que intercambian información entre sí, cerrando así el círculo. La
información puede viajar de la aplicación al dispositivo sin que estos tengan que hablar
directamente entre sí. [2]
3. ¿Qué tipos de datos soporta OPC?
Los tipos de datos más comunes transferidos entre dispositivos, controladores y
aplicaciones en automatización se pueden desglosar en tres categorías [2]:
 Datos de tiempo real
 Datos históricos

5. 5
 Alarmas y Eventos
A su vez, cada una de las categorías anteriores soporta una amplia gama de tipos de
datos. Estos tipos de datos pueden ser enteros, coma flotante, cadenas, fechas y distintos
tipos de arreglos, por mencionar algunos. OPC asume el reto de trabajar con estas distintas
categorías de datos especificando de forma independiente cómo se va a transmitir cada uno
de ellos a través de la arquitectura Cliente OPC - Servidor OPC. [2]
4. OPC Clásico
Las especificaciones del OPC Clásico están basadas en las tecnologías de Microsoft
Windows usando COM/DCOM (Modelo Distribuido de Los Componentes de Objeto) para
el intercambio de datos entre los componentes del software. Las especificaciones proveen
diferentes definiciones para el acceso de procesos de datos, datos históricos y alarmas. [3]
Las tres especificaciones OPC que se corresponden con las tres categorías de datos son:
 OPC Data Access Specification (OPC DA): utilizada para trasmitir datos de tiempo
real.
 OPC Historical Data Access Specification (OPC HDA): utilizada para transmitir
datos históricos.
 OPC Alarms & Events Specification (OPC A&E): utilizada para transmitir
información de alarmas y eventos. [3]
5. ¿Qué es y qué hace un Servidor OPC?
Un Servidor OPC es una aplicación de software. Un driver “estandarizado” desarrollado
específicamente para cumplir con una o más especificaciones OPC. La palabra “Server” en
“OPC Server” no hace referencia en absoluto al ordenador donde este software se estará
ejecutando. Hace referencia a la relación con el Cliente OPC. Los Servidores OPC son
conectores que se pueden asimilar a traductores entre el mundo OPC y los protocolos
nativos de una Fuente de Datos. OPC es bidireccional, esto es, los Servidores OPC pueden
leer de y escribir en una Fuente de Datos. La relación Servidor OPC/Cliente OPC es de tipo
maestro/esclavo, lo que significa que un Servidor OPC sólo transferirá datos de/a una
Fuente de Datos si un Cliente OPC así se lo pide. [2]
6. ¿Con qué tipos de Fuentes de Datos puede comunicar un Servidor OPC?
Los Servidores OPC pueden comunicar prácticamente con cualquier Fuente de Datos
cuyos datos puedan ser leídos o escritos por medios electrónicos. Una breve lista de
posibles Fuentes de Datos incluye: dispositivos, PLCs, DCSs, RTUs, instrumentos de
medición, bases de datos, historiadores, software de cualquier tipo (ejemplo Excel), páginas
web e incluso archivos CSV (texto separado por comas) de actualización automática. Para

6. 6
comunicar con cualquiera de estos dispositivos se requiere únicamente el uso de un
Servidor OPC que utilice el protocolo o interfaz nativo apropiado. Una vez que se ha
configurado dicho Servidor OPC, cualquier aplicación Cliente que utilice OPC (y tenga los
permisos adecuados) puede empezar a comunicar con la Fuente de Datos sin que importe la
forma en que esta comunica de forma nativa. [2]
7. ¿Cómo trabaja un Servidor OPC?
Conceptualmente el funcionamiento del Servidor OPC se puede desglosar de la siguiente
manera:
 Módulo de comunicaciones OPC: Esta es la parte del Servidor OPC responsable
de comunicar adecuadamente con un Cliente OPC. Los Servidores OPC bien
diseñados deben ser plenamente compatibles con las especificaciones OPC que
implementen, para asegurar que comunican correctamente con cualquier Cliente
OPC. [2]
 Módulo de comunicaciones nativas: El Servidor OPC debe emplear el método de
comunicación más eficiente con la Fuente de Datos. En algunos casos, esto implica
comunicar con la Fuente mediante su protocolo propietario de datos, mientras que
en otros casos, esto significa comunicar a través de una Interfaz de Programación de
la Aplicación (API). Típicamente, cuanta más experiencia tenga el desarrollador del
Servidor OPC con el dispositivo, mejor utilizará las posibilidades de comunicación
que ofrece el dispositivo. [2]
 Módulo de traducción/mapeado: La función de este módulo es interpretar de
forma adecuada las peticiones OPC entrantes de un Cliente OPC, convirtiéndolas en
peticiones nativas que se envían a la Fuente de Datos y viceversa. Si esto se hace
eficientemente, se puede mantener al mínimo la carga sobre la Fuente de Datos
mientras se maximiza la capacidad de transmisión de datos. [2]
8. ¿Qué es y qué hace un Cliente OPC?
Un Cliente OPC es una pieza de software creada para comunicar con Servidores OPC.
Utiliza mensajería definida por una especificación concreta de la OPC Foundation.
Representa un destino de datos. Inician y controlan la comunicación con Servidores OPC
basados en las peticiones recibidas desde la aplicación en la que están embebidos. Los
Clientes OPC traducen las peticiones de comunicación provenientes de una aplicación dada
en la petición OPC equivalente y la envían al Servidor OPC adecuado para que la procese.
A cambio, cuando los datos OPC vuelven del Servidor OPC, el Cliente OPC los traduce al
formato nativo de la aplicación para que ésta pueda trabajar de forma adecuada con los
datos. [2]

7. 7
Los Clientes OPC son módulos de software utilizados por una aplicación para permitirla
comunicarse con cualquier Servidor OPC compatible visible en la red. Típicamente, los
Clientes OPC están embebidos en aplicaciones como HMIs, SCADAs, graficadores,
Historiadores o generadores de informes, convirtiéndolos en aplicaciones compatibles
OPC. [2]
9. ¿Dónde está instalado el Cliente OPC?
Los Clientes OPC, típicamente, están embebidos en la aplicación que los utiliza, como
por ejemplo HMIs o Historiadores. Si por alguna razón la aplicación que tenemos que
utilizar no dispone de un Cliente OPC embebido, es posible que se pueda obtener uno
externo del fabricante de la aplicación o de un tercero. Un Cliente OPC externo a la
aplicación típicamente comunicara con ella a través de uno de sus protocolos nativos. En
este caso, el Cliente OPC podría incluso no residir en el mismo ordenador que la
aplicación. [2]
10. ¿Cómo trabaja un Cliente OPC?
Un Cliente OPC se puede dividir conceptualmente en tres módulos [2]:
 Módulo de comunicaciones OPC: Aunque no tan involucrado como en el Servidor
OPC (en los Servidores OPC esta parte es más compleja) es crucial para que el
Cliente OPC se comporte como debe al conectarse a un Servidor OPC, intercambiar
datos con él y desconectarse sin desestabilizar al Servidor OPC. [2]
 Módulo de comunicaciones con la aplicación: El Cliente OPC típicamente está
diseñado para trabajar en una aplicación específica, por lo que, para permitir que la
información pase de la aplicación al Servidor OPC pasando por el Cliente OPC,
realiza una serie de llamadas al interfaz para la programación de la aplicación (API).
También es posible que un Cliente OPC genérico comunique con una aplicación
mediante un protocolo en lugar de con llamadas al API siempre que la aplicación
soporte ese protocolo. [2]
 Módulo de traducción/mapeado: Una de las funciones clave del Cliente OPC es la
de traducir de forma bidireccional la información que su aplicación necesita leer de
o escribir al dispositivo o Fuente de Datos. [2]
11. OPC UA
Mientras que OPC convencional resuelve los problemas de interoperabilidad a nivel de
sistemas de control de procesos, la demanda por el mismo nivel de estandarización ha sido
requerida por el área de análisis de la información. El standard OPC clásico está basado en
Microsoft DCOM el cual introduce vulnerabilidad a todas ésas áreas. La necesidad de
encontrar simplicidad, máxima interoperabilidad y seguridad ha llevado a la OPC

8. 8
Foundation a la creación de un método de comunicación unificado para las actuales
especificaciones OPC DA, HDA, A&E, y Seguridad. OPC UA (Arquitectura Unificada)
extiende el gran éxito del protocolo de comunicación OPC, para la adquisición de datos, el
modelado de la información y la comunicación entre planta y aplicaciones de una forma
fiable y segura. [4]
Las principales características y beneficios de los OPC UA son:
 Plataforma neutral que funciona en cualquier sistema operativo
 Preparada para el futuro y para comunicar con sistemas antiguos
 Fácil configuración y mantenimiento
 Tecnología orientada a servicios
 Aumento de la visibilidad
 Mayor alcance de la conectividad
 Alto rendimiento [4]
12. Beneficios de utilizar conectividad OPC
A primera vista, crear un driver propietario para dos componentes OPC (Cliente OPC y
Servidor OPC) puede parecer que no sea una gran mejora, pero la experiencia ha
demostrado que sí lo es. A continuación se enumeran algunos de los beneficios clave de
utilizar OPC [2]:
1. Una aplicación Cliente OPC puede comunicar libremente con cualquier Servidor OPC
visible en la red sin la necesidad de utilizar ningún driver específico para la Fuente de
Datos.
2. Las aplicaciones Cliente OPC pueden comunicar con tantos Servidores OPC como
necesiten. No hay ninguna limitación inherente a OPC en el número de conexiones que se
pueden establecer.
3. Hoy en día OPC está tan extendido que hay un Servidor OPC disponible para
prácticamente todos los dispositivos nuevos o antiguos que existen en el mercado.
4. Las Fuentes de Datos (hardware o software) que utilizan OPC pueden ser
intercambiadas o actualizadas sin la necesidad de actualizar los drivers utilizados por cada
aplicación que comunique con ellas mediante OPC. Sólo hay que mantener actualizado el
Servidor OPC para esa Fuente de Datos.
5. Los usuarios pueden elegir libremente los dispositivos, controladores y aplicaciones
que mejor se ajusten a sus proyectos sin preocuparse del fabricante del que provienen o de
si comunicarán entre sí la intercomunicación se da por sentado. [2]

9. 9
DISCUSIÓN
Dentro de cualquier proceso, los datos de información siempre van a surgir. Un proceso
donde se requiera la supervisión y el control del mismo requiere de ciertos componentes
que permitan que la información que surja pueda ser recibida e interpretada no solo por las
unidades controladoras sino también por el recurso humano que debe estar al tanto de todo
lo que vaya sucediendo. OPC es un estándar de comunicación que permite precisamente
realizar una conectividad entre los datos que van surgiendo dentro del proceso a través de
su conexión OPC Servidor y OPC Cliente.
En un sistema de supervisión y control automatizado para la unidad de ahumado de
carnes animal, OPC permitiría que los datos que van surgiendo en el proceso puedan ser
interpretados para saber si en cada una de las etapas se van realizando los mismos de
manera deseada. Uno de los factores a tomar en cuenta es que el proceso de ahumado de
carnes puede tener una cantidad de variables amplia y que cada una de estas deben tener un
historial de datos, pues no se realiza una sola vez el proceso, sino múltiples ocasiones.
Como todo proceso, el diseño de un sistema de supervisión y control automatizado para
la unidad de ahumado de carnes animal debe estar compuesto por varios componentes,
OPC puede significar entonces un intermediario entre la comunicación de datos que va a
surgir con ello. Ya que una de sus ventajas es precisamente esa facilidad de conexión entre
los distintos componentes sin importar su fabricante e igualmente puede funcionar de
manera efectiva. La implementación de OPC en muchas industrias, incluso proyectos, ha
resultado de manera exitosa, tal es el punto que existen varias empresas que distribuyen
OPC dentro del mercado, incluyendo claro la certificación de OPC Foundation, un ejemplo
de ello es MatrikonOPC, cuyos productos dentro del mercado cumplen con las
especificaciones mencionadas anteriormente (conectar dispositivos sin importar tipo de
fabricantes).
Entonces dentro del diseño de tal magnitud puede ser de gran ayuda ya que debe existir
un ente que permita la conectividad no solo de los elementos que conforman el proceso
sino también de la información que se puede generar a través del mismo. De igual forma se
debe tomar en consideración de tipo de estandarización OPC se puede utilizar, si uno
Clásico (Arriesgándose un poco respecto a las fallas que este presenta) o el UA, que es
relativamente nuevo pero que con respecto a su predecesor puede significar un avance.
Dentro de la propuesta se plantearía la implementación del OPC UA mayormente por su
nivel de seguridad y flexibilidad, incluso tomando en cuenta el precio del producto que
puede variar dependiendo del desarrollador y de los dispositivos a implementar.

10. 10
Independientemente de cualquiera de las especificaciones o estándares presentados por
OPC, se tendría definida la conexión del Servidor OPC con la unidad controladora que se
desee instalar (si se decide usar PLC o incluso un micro-controlador como Arduino) y el
Cliente será entonces la aplicación desarrollada (que puede ser en Visual Basic, o en un
entorno LabView).
Formando entonces una comunicación que permita la visualización de los datos
arrojados dentro del proceso de ahumado de carnes en todas sus etapas, a fin de tener una
supervisión de los mismos para efectivamente cerciorase de que el mismo fluye de la
manera indicada, aprovechando la facilidad que brinda el mismo, ya que la conectividad de
estos elementos a veces resulta complicada.
Definitivamente OPC brinda una aplicabilidad dentro del sistema, brindando una opción
a considerar dentro del diseño, necesitando ser evaluada detalladamente a fin de ver si
efectivamente sea la indicada para brindar la conectividad que se necesita entre la unidad
controladora y la aplicación de interfaz gráfica para observar todos los datos que arroja el
proceso.

11. 11
CONCLUSIONES
 Las necesidades de conectar cada uno de los elementos que conforman el proceso,
han llevado a las industrias a desarrollar protocolos y estándares que permitan dicho
cometido.
 OLE para el Proceso de Control ha sido desarrollado a fin de que las industrias
tengan una opción de conectividad que no dependa de protocolos privatizados a fin
de poder implementar los componentes que sean necesarios sin la obligación de que
todos deban ser del mismo fabricante.
 OPC Foundation ofrece dos opciones de conectividad OPC, la clásica y la UA,
donde se puede considerar que la última es la evolución de la primera, mayormente
por UA ha disminuido las fallas que se pueden considerar en la clásica, no por ello
OPC Classic no se siga implementando.

12. 12
REFERENCIAS BIBLIOGRÁFICAS
[1] CREUS, A. (2008). Instrumentación Industrial. Instrumentación Industrial, 8° edición,
México: Editorial Alfaomega
[2] KOMINEK, D., (2009). OPC: ¿De qué trata y cómo funciona? [Documento en línea]
Disponible en:
http://www.infoplc.net/files/documentacion/comunicaciones/infoplc_net_guia_para_entend
er_la_tecnologia_opc.pdf. [Consulta: 2016, Febrero 25]
[3] OPC Foundation. OPC Classic. [Página web en línea]. Disponible en:
https://opcfoundation.org/about/opc-technologies/opc-classic/. [Consulta: 2016, Febrero
26]
[4] MatrikonOPC. OPC UA. [Página web en línea] Disponible en:
http://matrikonopc.es/opc-ua/index.aspx. [Consulta: 2016, Febrero 26]