opc server

Comunicación OPC:

2/22

Ingeniería Producción Industrial

Temario Cap IIConceptos VILabview: Conceptos BásicosLabView: Paneles y Diagrama de BloquesLabView: Tipos VisLabView: PaletasLabView: HerramientasLabView: HelloWorldLabView: ClusterLabView: Decisiones en VILabView: Otras EstructurasLabView: StringLabView: I/O FilesLabview: DAQ 6009Comunicación OPC

¿Qué es OPC?

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 el 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.

Comunicación OPC:

2/22



¿Por qué triunfa OPC donde los protocolos propietarios fallan?

La clave del éxito de OPC en crear comunicaciones auténticamente independientes del fabricante estriba en que OPC abstrae de los detalles de la implementación de Fuentes de Datos (i.e. PLC) y Clientes de Datos (i.e. HMI/ SCADA), con lo que los datos se pueden intercambiar entre ellos sin que tengan que saber nada de sus respectivos protocolos de comunicación nativos y de la organización interna de sus datos. Esto, en clara oposición a la aproximación basada en crear aplicaciones basadas en protocolos propietarios que, por definición, son requeridos para comunicar, de forma nativa, la Fuente de Datos con el Cliente de Datos.Un poco de HistoriaOPC corresponde a un conjunto de especificaciones basadas en los estándares de Microsoft (COM, DCOM, OLE Automation y Active X) que cubren los requerimientos de comunicación industrial entre aplicaciones y dispositivos, no es comunicación en tiempo real. Los fabricantes de software de estos niveles (scadas, etc.), tenían el problema de mantener y actualizar la gran variedad de drivers que comunicaban los distintos equipos de planta con sus productos. En cooperación con Microsoft, un grupo constituido por cinco empresas, Intellution, Opto-22, Fisher-Rosemount, Rockwell Software e Intuitiv Software, colaboraron para solucionar este problema y dieron origen a la especificación técnica no propietaria definida por la OPC Foundation en Mayo de 1995.

Comunicación OPC:

2/22



Con la introducción de Windows 3.0 en 1990 se hizo posible OPC, sobre una plataforma barata, para ejecutar aplicaciones múltiples simultáneamente. Aún mejor, Windows proporcionó un mecanismo estándar para aquellas aplicaciones que intercambian datos en tiempo de ejecución. Este mecanismo era el Intercambio de datos Dinámico, o DDE, y no mucho antes, los usuarios vieron los beneficios de tener sus procesos o datos de planta dentro de aplicaciones de propósito general como Microsoft Excel.

Pronto sin embargo, las limitaciones de DDE se hicieron claras. No era muy robusto, no había ningún apoyo para DDE a través de una red, y, el peor de todos, su ancho de banda era muy limitado.DDE (Dynamic Data Exchange): Es un protocolo de intercambio de información desarrollado por Microsoft. El protocolo DDE es un conjunto de mensajes e instrucciones. Se ocupa de enviar mensajes entre distintas aplicaciones que comparten memoria. Ha sido reemplazado por su mucho más poderoso sucesor "Object Linking and Embedding", "COM" y "OLE Automation". Sin embargo, todavía se usa en varios sitios dentro de Windows, por ejemplo en la asociación de archivos.

Comunicación OPC:

2/22



OLEMicrosoft estaba trabajando en el desarrollo del OLE 2.0 (Object linking and Embedding) (objetos enlazados e incrustados). Aparentemente esta nueva tecnología podría reemplazar al DDE (Dynamic Data Exchange) (Intercambio dinámico de datos) que hasta ese momento había sido usada extensivamente para el intercambio de datos en sistemas SCADA diseñados para Windows. La nueva tecnología de OLE era más flexible, robusta y eficiente para el entorno industrial que la proporcionada por DDE.

El Objeto OLE de algún modo actualiza la tecnología DDE. Un objeto OLE permite vincular o incrustar una aplicación dentro de otra, de modo que el intercambio de datos entre ambas aplicaciones es inmediata. Por ejemplo podríamos incrustar una hoja de cálculo dentro de un informe en word, de este modo podemos tener un gráfico incrustado en nuestro informe creado en word. Por lo tanto cuando cambiamos los datos, el gráfico cambia automáticamente, no es necesario copiarle nuevamente y pegarle como una imagen estática dentro de nuestro documento. De este modo se simplifica el trabajo y no es necesario estar abriendo y cerrando aplicaciones constantemente, evitando así mismo errores en el proceso

Comunicación OPC:

2/22



OPC (OLE for Process Control)

OPC Task Force publica en 1995 ISA Show en Nueva Orleans con una nueva versión. Sus miembros eran Fisher-Rosemount (ahora Emerson Process Managment), Intellution, Intuitive Technology, OPTO 22, y Rockwell Software. Microsoft actúa como apoyo.

De este modo surge un estándar basado en tecnología OLE/COM, comunicación tipo servidor-cliente, que permite ligar de una forma abierta el hardware de diversos fabricantes sin necesidad de crear un driver específico para cada equipo.

La primera versión preliminar de la especificación OPC fue lanzada en diciembre 1995. A pesar del resentimiento de que un grupo de élite asumiera el esfuerzo de estandarización, en conjunto la respuesta era favorable y muy constructiva.

Una segunda especificación se publica en marzo 1996, y seminarios 'JumpStart' serealizan en Dallas, Texas (abril 1996), Londres, Inglaterra (julio 1996), y Japón (agosto 1996) para ofrecer una introducción a los interesados en el estándar propuesto. En cada ocasión la respuesta era positiva.

Comunicación OPC:

2/22



• El método definido por OPC, facilita el intercambio de datos en forma estandarizada y simple en aplicaciones de control y automatización, entre los dispositivos y sistemas de campo y las aplicaciones de supervisión, administrativas y de oficina. Es decir, OPC simplifica la interfaz entre componentes de automatización de distintos fabricantes, con programas y aplicaciones tales como sistemas administrativos y de visualización.

• Con estas especificaciones, el diseño de un paquete SCADA, cuya comunicación se realizará con servidores OPC, no necesita disponer de drivers para los numerosos equipos industriales posibles.

• El software se ha estandarizado y para una aplicación concreta solamente será necesario disponer en el servidor OPC, de los drivers que conviertan los elementos de campo al formato OPC. El cliente OPC, como puede ser un SCADA, Visual Basic,.., siempre se comunica en el mismo formato.

• Otra gran ventaja de las especificaciones “abiertas” OPC, es la utilización de lenguajes de programación como C++ o Visual Basic como clientes OPC, para la realización de aplicaciones a medida. Las próximas unidades didácticas tratarán sobre ello. El condicionante es que hay que hacerlo bajo Windows.

Comunicación OPC:

2/22



NI OPC SERVER

LABVIEW

Comunicación OPC:

2/22



¿Qué tipos de datos soporta OPC? Los tipos de datos más comunes transferidos entre dispositivos, controladores y aplicaciones en automatización se pueden encuadrar en tres categorías:7

• Datos de tiempo real • Datos históricos• 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 arrays, 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.

Comunicación OPC:

2/22



Las tres especificaciones OPC que se corresponden con las tres categorías de datos son:

1. OPC Data Access Specification (OPC DA) – utilizada para trasmitir datos de tiempo real. Es la función más usada. Permite leer, modificar y monitorizar variables del proceso. La Fundación OPC ofrece una herramienta con la que se puede probar la conformidad de los servidores DA. OPC DA se basa en la tecnología COM/DCOM de Microsoft y sólo está disponible para PC ´s con un sistema operativo de Microsoft; la comunicación está limitada a las estaciones de una LAN.

2. OPC Historical Data Access Specification (OPC HDA) – utilizada para transmitir datos históricos. Provee de una interfaz Cliente OPC de Acceso a Datos Históricos, que facilita el uso de aplicaciones de acceso a datos.

3. OPC Alarms & Events Specification (OPC A&E) – utilizada para transmitir información de alarmas y eventos. Se utiliza para transmitir de forma imediata, alarmas o eventos programados a cualquier cliente OPC. Por una parte estará el servidor OPCDA comunicando datos normales del proceso, y por otra el OPC-AE para la comunicación de datos críticos. Esto permite que sistemas de información remotos puedan reaccionar y lanzar rutinas de evaluación.

Comunicación OPC:

2/22



¿Todos los Servidores OPC incluyen todas las especificaciones OPC? No. No es obligatorio que todos los Servidores OPC incluyan todas las especificaciones OPC. Históricamente, la mayoría de los Servidores OPC sólo soportan datos de tiempo real (OPC DA). Es aconsejable investigar que especificaciones OPC incluye un Servidor OPC antes de elegirlo para un proyecto.

¿Es importante saber qué especificaciones OPC incluye un Cliente OPC o un Servidor OPC? Sí, es crucial. Mientras que las tres especificaciones OPC (OPC DA, OPC HDA, OPC A&E) utilizan la misma arquitectura OPC cliente/servidor subyacente para transmitir las distintos categorías de datos, tanto Cliente OPC como Servidor OPC deben incluir la misma especificación OPC para coordinar de forma correcta el flujo de datos entre ellos y para trabajar correctamente con la Fuente de Datos y el Cliente de Datos respectivamente.

Comunicación OPC: Servidor

2/22



SERVIDORES OPC

¿Qué es 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.

¿Qué hacen los servidores 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/22



¿Puede comunicar un Cliente OPC de un determinado fabricante con Servidores OPC de otros fabricantes?

Sí, siempre que tanto el Cliente OPC como el Servidor OPC cumplan con las mismas especificaciones OPC, deben ser capaces de comunicar entre sí, independientemente de qué suministrador vengan.

¿Los Servidores OPC pueden compartir datos con otros Servidores OPC?

Los Servidores OPC no se comunican directamente unos con otros; sólo están diseñados para comunicar con Clientes OPC. Sin embargo, existen utilidades OPC diseñadas específicamente para que ésta comunicación entre Servidores OPC sea posible (y fácil). Ver MatrikonOPC Data Manager (http://www. matrikonopc.com/products/opc-data-management/opc-data-manager.aspx)


2/22



Configuración Canal Servidor (Ejemplo S7-1200)

Primero añadimos un nuevo canal, y una vez creado el canal añadimos los dispositivos(PLCs), siguiendo el asistente es fácil de configurar, damos el nombre que nos interese al canal, en este caso TCP-IP


2/22




Lo próximo que debemos de hacer es seleccionar el driver para el tipo de PLC que vayamos a configurar, vamos a utilizar el Siemens TCP/IP y le asignamos la tarjeta de red de nuestro PC, donde deberá estar en el mismo rango que la dirección del PLC


2/22




Para terminar de configurar el canal, dejamos por defecto escribir los últimos valores para todos los tags y podemos finalizar el asistente para el canal


2/22



Configuración Dispositivo (PLCs) Servidor (Ejemplo S7-1200)

Lo próximo que vamos a hacer es configurar un nuevo dispositivo, asignando el nombre que nos interese y seleccionando el modelo


2/22




Al configurar un dispositivo por ethernet, el ID del dispositivo es la direccion IP que le hayamos asignado a nuestro PLC y debe ser única en toda la red, los próximos valores se pueden dejar por defecto o asignar según las necesidades


2/22




Por defecto el puerto para comunicaciones TCP/IP es el 102 que ya viene por defecto, y en la siguiente pantalla configuramos el tipo de link con el PLC si es desde PC/PG/OP y el número de Slot del PLC, el rack por defecto es el 0


2/22




El último paso antes de finalizar la configuración de nuestro dispositivo es el orden del byte de mayor peso dentro de una palabra o doble palabra, lo que viene siendo 16 y 32 bits, por defecto ya viene seleccionado el radio button de Big Endian para S7, con lo cual ya hemos finalizado


2/22




Ya solo nos queda crear los tags que nos interese visualizar en nuestro HMI y listo


2/22




Para comprobar el correcto funcionamiento de la configuración del servidor OPC se puede lanzar el cliente del NI OPC server, y aquí podremos verificar si cambian las variables seleccionadas en nuestro proyecto

Comunicación OPC: Cliente

2/22



¿Pueden comunicar un Cliente OPC con múltiples dispositivos (Servidores OPC) de forma simultánea? La respuesta tiene dos partes:

Primero, semánticamente: Es importante recordar que los Clientes OPC, por su diseño, sólo son capaces de comunicar con Servidores OPC, no con los dispositivos finales. Esta aclaración es necesaria porque los Clientes OPC deben ser independientes de protocolos, puesto que de otra forma caerían en la trampa dispositivo-driver del pasado.

Segundo: Sí, efectivamente los Clientes OPC pueden comunicar de forma simultánea con múltiples Servidores OPC. Esto significa que un Cliente OPC puede leer y escribir datos desde y hacia múltiples dispositivos (Fuentes de Datos) a través de sus respectivos Servidores OPC.

Comunicación OPC: Cliente

2/22



¿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.

Comunicación OPC

2/22



FUNCIONALIDAD OPC

El objetivo principal de OPC es entregar las especificaciones a la industria tan rápidocomo sea posible. Por lo tanto, OPC se enfoca en:• Acceso de Datos en línea, en otras palabras, la lectura y escritura

eficiente de datos entre una aplicación y un dispositivo de control de proceso

• El Manejo de Alarma y el Acontecimiento, en otras palabras, los mecanismos para Clientes de OPC para ser notificados de las condiciones especificadas y alarma,

• Acceso a Datos Históricos, en otras palabras, la lectura, procesamiento y redacción de datos históricos

Otras metas para el diseño de OPC son:• Sencillo de aplicar.• Flexible de acomodar a múltiples necesidades• Proporcionar un nivel alto de funcionalidad• Ser eficiente.

opc server

Documents