Un lector: «¿OPC?»
El autor: «OLE for Process Control»
Un lector: «Pues estoy igual.»
El autor: «Un lenguaje común para que se hablen PLCs y PCs»

DxpSERVER takebishi larraioz elektronika software de servidor opc
Takebishi OPC Server – OPC UA Server

Un lector: «Lo estás arreglando. ¿Los peces hablan?»

El autor: «Una tecnología basada en COM que…»

Un lector: «¿Como los puntocom esos de marcapuntocom, y comprar las chismas por el internetes?

«

El autor: «Un momento que aclaro mis ideas en un documento…»

 

 

 

OPC Foundation

 

 

El uso de sistemas de automatización basados en PC aumentó rápidamente en la automatización industrial al inicio de los 90; especialmente PCs basados en Windows para visualización y control. Uno de los mayores esfuerzos en el desarrollo de software estandarizado se ha dirigido al acceso a datos en un número incontable de dispositivos, redes, protocolos e interfaces.

 

Existía un problema similar para las aplicaciones software y el acceso a impresoras en los días del viejo MS-DOS: cada aplicación debía escribir su propio driver de impresora para todas las impresoras que fuera a soportar. Windows resolvió el problema de drivers de impresora incorporando el soporte a impresoras en el propio sistema operativo. De forma que las aplicaciones sólo debían incorporar la interfaz al driver de impresora del sistema operativo. Y los fabricantes de impresoras ofrecían los drivers de impresora.

 

Como los fabricantes de Interfaces-Hombre-Máquina (Human-Machine-Intefaces – HMI) y software de Supervisión y Control (Supervisory Control and Data Acquisition – SCADA) tenían problemas similares, en 1995 se creó un grupo de trabajo formado por las compañías Fischer-Rosemount, Rockwell Software, Opto 22, Intellution e Intuitive Technology. El objetivo de este grupo de trabajo fue el de definir un estándar Plug & Play para drivers de dispositivos proporcionando un acceso estandarizado a datos de automatización en sistemas basados en Windows. El resultado fue la especificación OPC Data Access (OPC-DA) en agosto de 1996. Esta especificación está soportada por una organización sin ánimo de lucro OPC Foundation y casi todos los proveedores de sistemas para automatización industrial son miembros de ella. La OPC Foundation era capaz de definir y adoptar estándares mucho más rápido que otras organizaciones utilizando APIs basados en tecnologías Microsoft Windows como (Component Object Model – COM) y (Distributed COM – DCOM) En 1998 se presentó la versión 2 de OPC-DA y es aún la interfaz más importante para productos OPC.

 

Hoy día los sistemas SCADA y HMI, gestión de procesos y Sistemas de Control Distribuidos (Distributed Control Systems – DCS) y Sistemas de Ejecución Manufacturera (Manufacturing Execution System – MES) deben soportar interfaces OPC. OPC es el estándar (universalmente aceptado) que ofrece la habilidad de intercambiar datos entre sistemas de automatización industrial.

 

Existen dos niveles de Programas de Conformidad OPC (OPC Compliance Program) para asegurar la interoperabilidad de todos los productos OPC. El primer nivel contempla la certificación propia. La OPC Foundation ofrece tests de conformidad cuyos resultados encriptados se envían a la OPC Foundation, y esta permite el uso del logo ‘Self-Tested’. El segundo nivel se realiza en laboratorios de certificación independientes en los que se realizan tests funcionales, de carga y de stress. Aquellos productos que pasan estos tests pueden utilizar el logo ‘OPC Certified’ que indica un alto nivel de calidad y conformidad con OPC. Se recomienda a los usuarios finales la compra sólo de productos conforme a ‘OPC Certified’ para minimizar problemas de interoperabilidad y asegurar la fiabilidad y rendimiento de su solución basada en OPC.

 

 

OPC Clásico

 

De acuerdo con las diferentes necesidades de las aplicaciones industriales, se han desarrollados tres principales especificaciones OPC:

  • Acceso a Datos (OPC-DA): Acceso a datos de proceso actuales
  • Alarmas y Eventos (OPC-A&E): Información basada en eventos, incluyendo reconocimiento de alarmas
  • Acceso a Datos Históricos (OPC-HDA): Acceso a datos archivados

 

Caso de uso típico en clientes y servidores OPC
Figura 1: Caso de uso típico en Clientes y Servidores OPC.

OPC utiliza un planteamiento cliente-servidor para el intercambio de información: un servidor OPC encapsula la fuente de información de proceso como un dispositivo y hace la información disponible a través de su interfaz. Un cliente OPC se conecta al servidor OPC y puede acceder y consumir la información ofrecida.

 

Las aplicaciones que consumen y ofrecen datos pueden ser, a la vez, cliente y servidor OPC. Las interfaces clásicas de OPC están basadas en la tecnología COM y DCOM de Microsoft. La ventaja de este planteamiento era la reducción del trabajo en la especificación de la definición de diferentes APIs para diferentes necesidades especializadas sin tener que definir un protocolo de red o un mecanismo para comunicaciones entre procesos. COM y DCOM ofrecen a un cliente un mecanismo transparente para llamar a métodos en un objeto COM en un servidor que se está ejecutando, en el mismo proceso, en otro proceso o en otro nodo de red. Esta ventaja fue importante para el éxito de OPC.

 

Las dos desventajas principales son:

  • La dependencia de OPC a la plataforma Windows, y
  • Los problemas de DCOM al utilizar comunicaciones remotas con OPC. DCOM es difícil de configurar, tiene tiempos de espera (timeout) largos y no-configurables y no puede ser utilizado para comunicarse a través de internet.

 

 

OPC DA (Data Access)

 

Objetos creados por un cliente OPC para acceder a datos
Figura 2: Objetos creados por un cliente OPC
para acceder a datos.

La interfaz OPC-DA permite leer, escribir y monitorizar variables que contienen datos de proceso actuales. Su principal uso es el de transmitir datos de tiempo-real de PLCs, y otros dispositivos de control a HMIs y otras pantallas clientes. OPC-DA es el interfaz más importante de OPC y está implementado en el 99% de productos que utilizan la tecnología OPC. El resto de interfaces OPC se implementan principalmente como complemento a OPC-DA.

 

Los clientes OPC-DA seleccionan explícitamente las variables (elementos OPC) que quieren leer, escribir o monitorizar en el servidor. El cliente OPC establece una conexión al servidor creando un objeto OPCServer. El objeto OPCServer ofrece métodos para navegar por el espacio de direcciones para buscar elementos OPC y sus propiedades, como el tipo de datos, o los permisos de acceso. Para acceder a los datos, el cliente agrupa los elementos OPC que tengan idénticas propiedades entre las que se encuentra el tiempo de actualización. Una vez añadidos a un grupo, el cliente puede leer o escribir los elementos. Aunque la forma preferida para la lectura cíclica de los datos por el cliente es la de monitorizar cambios de valores en el servidor: El cliente define un tiempo de actualización para el grupo que contiene los elementos de interés. El tiempo de actualización es utilizado en el servidor para comprobar los valores cíclicamente en busca de cambios. A cada ciclo, el servidor envía sólo los valores cambiados al cliente.

 

OPC ofrece datos de tiempo-real que pudieran no ser accesibles permanentemente, por ejemplo, cuando se interrumpe temporalmente la comunicación con un dispositivo. La tecnología clásica OPC gestiona este problema ofreciendo el instante de muestreo (timestamp) y la calidad a los datos enviados. La calidad especifica si el dato es correcto (bueno), no disponible (malo) o desconocido (dudoso).

 

 

OPC A&E (Alarm and Events)

 

Objetos creados por un cliente OPC para recibir eventos
Figura 3: Objetos creados por un cliente OPC
para recibir eventos.

La interfaz OPC-A&E permite la recepción de notificaciones de eventos y notificaciones de alarmas. Los eventos son notificaciones singulares informando al cliente sobre la ocurrencia de algún evento. Las alarmas son notificaciones que informan al cliente sobre el cambio de alguna condición en el proceso. La condición puede ser el nivel de algún depósito, y un ejemplo podría ser el que este nivel supere el máximo permitido. Muchas alarmas requieren el reconocimiento de la alarma. Este reconocimiento es también posible a través de la interfaz OPC-A&E. Por tanto OPC-A&E ofrece una interfaz flexible para transmitir alarmas y eventos de proceso. Para recibir notificaciones, el cliente OPC-A&E se conecta al servidor, se subscribe a las notificaciones, y entonces recibe todas las notificaciones lanzadas por el servidor. Para limitar el número de notificaciones, el cliente OPC puede especificar algún criterio de filtro.

 

El cliente OPC se conecta, en el primer paso, creando un objeto OPCEventServer en el servidor OPC-A&E, y en el segundo paso, generando un OPCEventSubscription que es utilizado para recibir los mensajes de eventos. Los filtros para los mensajes de eventos pueden ser configurados de manera separada para cada subscripción. La Figura 3 muestra los diferentes objetos que crea el cliente OPC en el servidor. A diferencia de OPC-DA, no se pueden realizar peticiones explícitas de información explícita como en la lectura de valores; en su lugar, se tiene acceso a todos los eventos de proceso, y el cliente puede limitar la cantidad de eventos estableciendo algún criterio de filtro, por ejemplo, filtro por tipos de eventos, por prioridades o por origen de eventos.

 

 

OPC HDA (Historical Data Access)

 

Mientras OPC-DA permite el acceso a datos en tiempo-real que cambian continuamente, OPC-HDA permite el acceso a datos ya almacenados. Los archivos históricos se recuperan de manera uniforme, desde un simple sistema de registro de datos serie a un complejo sistema SCADA.

 

El cliente OPC se conecta creando un objeto OPCHDAServer en el servidor HDA. Este objeto ofrece todas las interfaces y métodos para leer y actualizar datos históricos. Un segundo objeto OPCHDABrowser está definido para navegar el espacio de direcciones del servidor HDA.

 

La principal funcionalidad es la de leer datos históricos en tres formas diferentes:

  • El primer mecanismo lee datos ‘crudos’ del archivo, donde el cliente define las variables y la ventana temporal que quiere leer. El servidor devuelve todos los valores archivados en la ventana temporal especificada hasta el número máximo de valores especificado por el cliente.
  • El segundo mecanismo lee los valores de las variables especificadas para los instantes de muestreo especificados.
  • El tercer mecanismo calcula valores agregados (operaciones entre variables) de datos en la base de datos de históricos para los valores especificados en la ventana temporal.

 

Los valores incluyen siempre la calidad e instante de muestreo. Además de los métodos de lectura, OPC-HDA define también métodos para insertar, reemplazar y borrar datos de la base de datos de históricos.

 

 

Otras interfaces estándares OPC

 

Interfaces estándar de OPC Clásico.
Figura 4: Interfaces estándar de OPC Clásico.

OPC especifica muchos estándares adicionales más como especificaciones básicas o para necesidades específicas. Especificaciones básicas son las definiciones de las intefaces OPC Overview y OPC Common que son comunes a todas las especificaciones OPC basadas en COM. La Figura 4 muestra un resumen de todas las especificaciones OPC clásicas:

 

OPC Security especifica cómo controlar el acceso de los clientes para proteger información sensible y protegerse contra modificaciones de parámetros de proceso sin autorización. OPC Complex Data, OPC Batch y OPC Data eXchange (OPC-DX) son extensiones a OPC-DA. Complex Data define cómo describir y transportar valores con tipos de datos estructurados complejos. OPC-DX especifica el intercambio de datos entre servidores OPC-DA definiendo el comportamiento cliente y las interfaces de configuración para el cliente interno al servidor. OPC Batch extiende OPC-DA para las necesidades específicas de procesos por lotes.

 

 

OPC XML-DA

 

OPC XML-DA fue la primera especificación OPC independiente-de-plataforma que reemplazaba COM/DCOM con HTTP/SOAP y tecnologías de Servicio Web. Por tanto se presentó una infraestructura de comunicaciones neutra en cuanto a plataforma y a fabricante, aceptado ampliamente y que mantenía la funcionalidad de OPC-DA.

 

Como los Servicios Web no tienen estados, la funcionalidad se redujo al conjunto mínimo de métodos para intercambiar información OPC-DA, sin la necesidad de métodos para crear y modificar un contexto para la comunicación. Sólo ocho métodos fueron necesarios para cumplir con las características principales de OPC-DA:

  • GetStatus: para verificar el estado del servidor
  • Read: para leer uno o más valores
  • Write: para escribir uno o más valores
  • Browse y GetProperties: para obtener información sobre los elementos disponibles
  • Subscribe: para crear una subscripción para una lista de elementos
  • SubscriptionPolledRefresh: para intercambiar los valores modificados de una subscripción
  • SubscriptionCancel: para eliminar una subscripción

 

OPC XML-DA se diseñó para el acceso por internet y para la integración en la empresa, aunque en base a la independencia-de-plataforma, se implementó principalmente en sistemas embebidos y plataformas no-Microsoft. Sin embargo, debido a su consumo elevado de recursos y rendimiento limitado, no tuvo tanto éxito como el que se esperaba para este tipo de aplicaciones.

 

 

Motivos para OPC UA

 

El primer estándar OPC Clásico, y aún el de más éxito, OPC-DA, fue diseñado como interfaz a drivers de comunicación, permitiendo un acceso estandarizado de lectura y escritura a datos actuales en dispositivos de automatización. El caso principal era acceso a sistemas HMI y SCADA accediendo a datos de diferentes dispositivos de automatización de diferentes fabricantes, utilizando una interfaz software ofrecida por el fabricante. Con el éxito de la adopción de OPC en miles de productos, OPC se utiliza hoy en día como interfaz estándar entre sistemas de automatización en diferentes niveles de la pirámide de automatización. Se emplea incluso en ámbitos para los que no fue diseñado, y también hay más áreas donde los productores querrían utilizar un estándar como OPC pero que no son capaces de utilizarlo debido a la dependencia de COM de OPC o por las limitaciones de acceso remoto utilizando DCOM.

 

OPC XML-DA fue el primer intento de la OPC Foundation para mantener las características exitosas de OPC pero utilizar una infraestructura neutra en cuanto a plataforma y fabricante. Entre otras razones, el bajo rendimiento de los Servicios Web XML comparado con la versión original basada en COM y los problemas de interoperabilidad al utilizar capas diferentes de Servicios Web XML, hicieron que no cumplieran con los requisitos de la nueva generación de OPC. Pero además de la independencia de plataforma, las compañías miembro de OPC Foundation adelantaron los requisitos para exponer datos complejos y sistemas complejos eliminando las limitaciones del OPC Clásico.

 

La OPC Unified Architecture (OPC-UA) nace de este deseo de crear un recambio real para todas las especificaciones basadas en COM sin perder ninguna de sus características ni rendimiento. Además, debe cubrir todos los requisitos de sistemas independientes de plataforma con capacidades ricas y extensibles de modelado siendo capaces de describir sistemas complejos. La gran variedad de aplicaciones en las que se utiliza OPC requiere una escalabilidad que va desde sistemas embebidos, pasando por sistemas SCADA, hasta sistemas MES y ERP. Los requisitos más importantes para OPC-UA se muestran en siguiente tabla:

 

Comunicación entre sistemas distribuidos Modelo de datos
Fiabilidad Modelo común para todos los datos OPC
Robustez y tolerancia a fallos Orientado a objetos
Redundancia Sistema de tipos ampliable
Independencia de plataforma Meta-información
Escalabilidad Datos y métodos complejos
Alto rendimiento Escalabilidad de modelos desde simples a complejos
Internet y cortafuegos Modelo básico abstracto
Seguridad y control de acceso Base para otro modelo de datos estándar
Interoperabilidad

Los requisitos pueden agruparse entre aquellos para la comunicación entre sistemas distribuidos capaces de intercambiar información y aquellos para el modelo de los datos que describen un sistema y la información disponible.

 

El OPC clásico fue diseñado como una interfaz a drivers de dispositivos. OPC se emplea como interfaz a sistemas; por tanto, la fiabilidad de la comunicación entre sistemas distribuidos es muy importante. Como la comunicación en red no es fiable por definición, los requisitos importantes son la robustez y la tolerancia a fallos, incluyendo la redundancia y la alta disponibilidad. La independencia de plataforma y la escalabilidad son necesarias para poder integrar interfaces OPC directamente en sistemas funcionando en diversas plataformas diferentes. Para reemplazar la comunicación propietaria de los fabricantes, un requisito importante es siempre un alto rendimiento en ambientes de intranet. Pero también debe ser posible la comunicación de internet a través de corta-fuegos, lo que hace la seguridad y control de accesos otro requisito importante. Y como primer y principal requisito, la interoperabilidad entre sistemas de fabricantes diferentes.

 

El modelado de datos era muy limitado en el OPC Clásico y necesitaba una mejora ofreciendo un modelo común, orientado a objetos para todos los datos OPC. Este modelo debe incluir un sistema de tipos ampliable para ser capaz de ofrecer meta-información y describir también sistemas complejos.

 

Figura 6: Los fundamentos de OPC-UA
Figura 6: Los fundamentos de OPC-UA

Los datos complejos son necesarios para soportar la descripción y transporte consistente de estructuras de datos complejas. Era un requisito importante para mejorar las capacidades de modelado, pero era igualmente importante para soportar modelos simples con conceptos simples. Por esta razón, es necesario disponer de un modelo básico simple y abstracto pero ampliable para poder escalar de modelos simples a complejos.

 

Además de los requisitos funcionales para una nueva generación de OPC, el grupo inicial de más de 40 representantes definiendo los requisitos y los casos de uso para la OPC-UA no estaba compuesto sólo por miembros de la OPC Foundation. Otras organizaciones como la IEC e ISA se interesaron en utilizar OPC como mecanismo de transporte de su información en el proceso de diseño inicial. En este grupo, la OPC Foundation define CÓMO describir y transportar los datos, y las organizaciones colaboradoras definen QUÉ datos quieren describir y transportar dependiendo de su modelo de información.

 

Otro objetivo de diseño importante era el de permitir una migración sencilla a OPC-UA para proteger la inversión realizada en los OPC Clásicos tan exitosos.

 

 

Visión general de OPC-UA

 

Para cumplir los objetivos definidos, OPC-UA se construye en varias capas, como se muestra en la Figura 6. Los componentes fundamentales de OPC-UA son los mecanismos de transporte y el modelo de datos. El transporte define diferentes mecanismos optimizados para diversos casos de uso. La primera versión de OPC-UA define un protocolo TCP binario optimizado de alto rendimiento en comunicaciones intranet así como un acceso a estándares de internet aceptados como Servicios Web, XML y HTTP para comunicaciones por internet a través de cortafuegos. Los dos transportes utilizan el mismo modelo de seguridad basado en mensajes bien conocido en los Servicios Web. El modelo de comunicaciones abstracto no depende de un protocolo específico y permite añadir más protocolos en el futuro.

 

El modelo de datos define las reglas y bloques constructivos necesarios para exponer un modelo de información con OPC-UA. Define también los puntos de entrada al espacio de direcciones y los tipos básicos utilizados para construir una jerarquía de tipos. Los Servicios UA son la interfaz entre servidores, como proveedores de modelos de información, y clientes, como consumidores de ese modelo de información. Los Servicios se definen de manera abstracta. Utilizan los mecanismos de transporte para intercambiar datos entre cliente y servidor.

 

El concepto básico de OPC-UA permite a un cliente OPC-UA acceder a la pieza más pequeña de datos sin la necesidad de entender el modelo completo expuesto por un sistema complejo. Los clientes OPC-UA que, además, entiendan modelos específicos, pueden utilizar características mejoradas definidas para dominios específicos y casos de uso.

 

Caso de uso típico de en clientes y servidores OPC
Figura 7: Capas de la arquitectura OPC-UA

La Figura 7 muestra las diferentes capas del modelo de información definidos por OPC, otras organizaciones o por fabricantes.

 

Para cubrir todas las características conocidas del OPC Clásico, los modelos de información para el ámbito de información de proceso se definen sobre las especificaciones base de OPC-UA.

 

  • Data Access (DA) define extensiones específicas de datos de automatización, como el modelado de datos discretos o analógicos y cómo exponer la calidad de servicio. El resto de características DA están ya cubiertos por la base.
  • Alarm & Conditions (A&C) especifica un modelo avanzado para gestión de alarmas de proceso y monitorización de condiciones.
  • Historical Access (HA) define los mecanismos para acceder a datos históricos y eventos históricos.
  • Programs (Prog) especifica un mecanismo para iniciar, manipular y monitorizar la ejecución de programas.

 

 

Otras organizaciones pueden construir sus modelos sobre la base UA, o sobre el modelo de información OPC-UA, exponiendo su información específica vía OPC-UA. Field Device Integration (FDI), Electronic Device Description Language (EDDL), Field Device Tool (FDT) Y PLCopen podrían ser algunos ejemplos de estándares trabajando ya sobre OPC-UA.

 

Pueden definirse modelos de información adicionales específicos a fabricantes utilizando directamente la base UA, los modelos OPC, u otros modelos de información basados en OPC-UA.

 

 

Especificaciones OPC-UA

 

Las especificaciones OPC-UA están divididas en diferentes partes como requisito también de la estandarización IEC. OPC-UA será conocido también como estándar IEC 62541. La Figura 8 muestra una vista general de todas las partes de la especificación divididas entre especificaciones de núcleo (Core) – donde se define la base para OPC-UA – y especificaciones de tipo de acceso – en el que se tratan principalmente modelos de información de OPC-UA.

 

Figura 8: Especificaciones OPC-UA
Figura 8: Especificaciones OPC-UA

Las primeras dos partes no son normativas. La Parte de conceptos da un vistazo general sobre OPC-UA, y la Parte 2 describe los requisitos de seguridad y el modelo de seguridad para OPC-UA.

 

Las partes más importante para comprender cómo modelar y acceder la información son la 3ª y 4ª. Estas dos especificaciones son los documentos clave para el diseño y desarrollo de aplicaciones OPC-UA.

 

El Modelo de Espacio de Direcciones especifica los bloques constructivos para exponer una instancia y el tipo de información – y por tanto el meta-modelo OPC-UA utilizado para describir y exponer modelos de información – y para construir un espacio de direcciones en el servidor OPC-UA.

 

 

 

Figura 9: Capas de la arquitectura de comunicación OPC-UA
Figura 9: Capas de la arquitectura de
comunicación OPC-UA

Los Servicios UA abstractos definidos en la Parte 4 representan las posibles interacciones entre aplicaciones UA-Clientes y UA-Servidores. El cliente utiliza los Servicios para buscar y acceder a la información proporcionada por el servidor. Los servicios son abstractos porque están definiendo la información a intercambiar entre aplicaciones UA, pero no la representación concreta en el cable y tampoco la representación concreta en un API utilizado por las aplicaciones. Lo muestra las capas de la arquitectura de comunicación OPC-UA

 

La asociación de Servicios UA a mensajes, los mecanismos de seguridad aplicados a los mensajes, y el cable de transporte concreto de los mensajes están definidos en la Parte 6. Sólo aquellos implementadores de la capa UA necesitan comprender completamente esta especificación. Como la OPC Foundation ofrece capas UA apropiadas, normalmente los programadores no necesitan leer esta especificación.

 

El modelo de información básico especificado en la Parte 5 ofrece la infraestructura para todos los modelos de información que utilicen OPC-UA. Define lo siguiente:

  • Los puntos de entrada al espacio de direcciones utilizado por clientes para navegar por instancias y tipos de un servidor OPC-UA
  • Los tipos básicos que construyen la raíz para las diferentes jerarquías de tipos
  • Los tipos incorporados pero extensibles como tipos de objetos y tipos de datos
  • El Objeto Server que ofrece información sobre capacidades y diagnóstico

 

Los perfiles son subconjuntos que definen características útiles en la Parte 7. Dichos subconjuntos deben ser implementados completamente por una aplicación UA para asegurar su interoperabilidad. La especificación define los subconjuntos en dos niveles.

 

El primer nivel son las Unidades de Conformidad que definen un pequeño conjunto de funcionalidades que se emplean siempre juntas y pueden ser comprobadas con las Herramientas de Conformidad y verificadas como unidades.

 

El segundo nivel son los Perfiles, compuestos por una lista de Unidades de Conformidad. Un Perfil debe ser implementado completamente y será comprobado como un conjunto completo en la certificación de productos OPC-UA.

 

La lista de Perfiles admitidos y utilizados se intercambia al establecer la conexión entre cliente y servidor y permite a las aplicaciones determinar si la pareja de comunicaciones admite las características necesarias.

 

El modelo de información DA define cómo representar y utilizar los datos de automatización y características específicas como unidades ingenieriles en la Parte 8.

El modelo de información AC especifica la monitorización de alarmas y condiciones de proceso, máquinas de estado específicas y tipos de eventos en la Parte 9.

El modelo de información de Programas define una máquina de estados básica para la ejecución, manipulación y monitorización de programas en la Parte 10.

El modelo de información HA especifica el uso de los Servicios de acceso a históricos y cómo presentar la información sobre la configuración de los datos y eventos históricos en la Parte 11

Los agregados empleados para calcular datos agregados a partir de muestras ‘crudas’ se especifican en la Parte 13. Los agregados se utilizan en el acceso a históricos así como en la monitorización de valores actuales.

La Parte 12 define cómo buscar servidores en la red y cómo puede obtener un cliente la necesaria información para ser capaz de establecer una conexión con un determinado servidor.

 

 

Capas Software en OPC UA

 

Figura 10: Capas software de OPC-UA
Figura 10: Capas software de OPC-UA

OPC-UA utiliza un concepto cliente-servidor similar al que se utiliza en OPC Clásico. Una aplicación que quiera exponer su propia información a otras aplicaciones se llama servidor UA, y una aplicación que quiera consumir información de otras aplicaciones se llama cliente UA.

 

Se espera que vaya a haber muchas más aplicaciones que sean a la vez servidor UA y cliente UA en una misma aplicación que en el OPC Clásico. Una razón es que habrá más servidores UA que vayan a ser integrados directamente en los dispositivos. Otra razón es el uso de OPC UA como interfaz de configuración, donde los clientes UA son a la vez servidores UA para ser configurados vía OPC UA.

 

Una aplicación típica OPC UA está compuesta por tres capas de software, como se muestra en Figura 10. La pila completa de software se puede implementar con C/C++, .NET o JAVA. OPC-UA no está limitado a estos lenguajes de programación y plataformas de desarrollo, aunque actualmente sólo se están utilizando estos entornos para implementar los módulos de pila UA que ofrece la OPC Foundation.

 

Una aplicación OPC-UA es un sistema que quiere exponer o consumir datos vía OPC-UA. Contiene la funcionalidad específica para la aplicación y la asociación de esta funcionalidad a OPC-UA empleando una pila OPC-UA y un Software Development Kit (SDK) de OPC-UA. Una pila OPC-UA implementa las diferentes asociaciones de transporte OPC-UA definidas en la Parte 6. La pila se utiliza para invocar Servicios UA a través de procesos o redes. OPC-UA define tres capas de pila y perfiles diferentes para cada capa.

 

La capa de codificación de mensaje define la serialización de parámetros de servicio en formato binario y XML.

 

Figura 11: Capas de la pila de comunicación UA definida en la Parte 6
Figura 11: Capas de la pila de comunicación UA
definida en la Parte 6

La capa de seguridad de mensaje especifica cómo deben asegurarse los mensajes utilizando estándares de seguridad de Servicios Web o una versión binaria UA de los Servicios Web estándares. La capa de transporte de mensaje define el protocolo de red utilizado, que podría ser UA-TCP o HTTP y SOAP para Servicios Web.

 

La Figura 11 muestra las diferentes capas que contiene la pila de comunicaciones UA. La implementación de las capas en la Pila UA y los APIs resultantes para la aplicación no son parte de la especificación OPC-UA. La Pila UA ofrece APIs dependientes del lenguaje de programación para aplicaciones cliente UA y servidor UA, pero los Servicios y sus parámetros son similares y se basan las definiciones de Servicios abstractos en la Parte 4.

 

Con implementaciones en ANSI C/C++, .NET y JAVA, las Pilas UA cubren los principales entornos de desarrollo y lenguajes de programación, desarrollados y mantenidos por la OPC Foundation.

 

 

Evolución, No Revolución

 

OPC-UA es mucho más flexible y tiene muchas más características que todas las especificaciones OPC clásicas juntas, y además, incorpora todos los conceptos exitosos de la especificación OPC existente, arregla problemas conocidos en los estándares existentes, y añade estandarización para muchos casos adicionales.

 

Uno de los objetivos importantes de diseño era el de permitir una migración sencilla del OPC Clásico al OPC-UA. Por ello la mayoría de características conocidas en OPC Clásico se pueden encontrar en OPC-UA empleando a veces terminologías algo diferentes. No es posible exponer todas las características de OPC-UA con interfaces OPC Clásicos, pero no hay ningún problema para asociar características de OPC Clásico con OPC-UA.

 

OPC-UA permite una asociación simple y ofrece estrategias de migración para integrar productos OPC basados en estándares previos. Una parte de la estrategia de migración ni siquiera requiere un cambio en los productos existentes.

 

La OPC Foundation ofrece ‘proxies’ y ‘wrappers’ capaces de traducir las diferentes interfaces OPC Clásicas a OPC-UA y viceversa. Los fabricantes pueden utilizar esta estrategia como primer nivel en la migración de los productos clásicos a OPC-UA.

 

El segundo nivel de migración a OPC-UA es la integración de OPC-UA directamente en los productos existentes sin añadir características específicas de OPC-UA.

 

El tercer nivel podría requerir la modificación de interfaces internas del producto para soportar todas las características de OPC-UA interesantes para el producto.

 

Para los usuarios finales, es importante que disponga de los ‘wrappers’ y ‘proxies’ disponibles para migrar la gran base de productos OPC Clásicos a OPC-UA. Pueden instalar ‘wrappers’ y ‘proxies’ para hacer de túnel al OPC Clásico a través de cortafuegos, incluyendo transmisiones seguras por internet y acceso autentificado, de forma que simplemente añaden valor a las soluciones industriales ya probadas.

 

Estos componentes son sólo el primer paso. Para los fabricantes es mucho más importante que OPC-UA ofrece conceptos básicos abstractos, modulares y simples en todas las áreas del estándar, permitiendo una migración sencilla de funcionalidades OPC existentes a OPC-UA. La potencia de estos conceptos permite a los fabricantes la extensión de esta base para exponer más características de sus sistemas vía OPC-UA.

 

 

Resumen

 

La OPC Foundation ofrece estándares para intercambio de datos en automatización industrial. Esto incluye la especificación OPC-DA para datos actuales, así como OPC-A&E, para alarmas y eventos y OPC-HDA para datos históricos. Todas estas especificaciones están basadas en la tecnología COM/DCOM venida a menos. Un primer paso hacia las tecnologías punta fue OPC XML-DA, que utilizaba XML sólo como formato de transporte de datos y por tanto no cumplía con los requisitos típicos de rendimiento en aplicaciones OPC.

 

Con la lección aprendida de OPC XML-DA, la OPC Foundation creó un nuevo estándar llamado Unified Architecture (OPC-UA). Aquí, el transporte puede realizarse utilizando Servicios Web que se manejan bien a través de corta-fuegos con estándares como SOAP y HTTP, o un protocolo binario TCP optimizado para comunicaciones de altas prestaciones. OPC-UA ofrece comunicaciones entre aplicaciones interoperativas, independientes-de-plataforma, de alto rendimiento, escalables, seguras y fiables.

 

El cambio de tecnología entre COM/DCOM de Microsoft a protocolos de transporte punteros e independientes-de-plataforma permiten a las aplicaciones OPC-UA ejecutarse en dispositivos inteligentes y controladores a la vez que en sistemas DCS o SCADA, hasta a niveles empresariales con sistemas MES y ERP. Esto aumenta inmensamente su rango de uso en comparación con aplicaciones clásicas de OPC.

 

Además del transporte, el segundo gran logro de OPC-UA es el modelo de información. OPC-UA unifica la funcionalidad de las diferentes especificaciones del OPC-Clásico exponiendo datos actuales, notificación de eventos y el historial todos en un solo espacio de direcciones. Además ofrece modelos de información ricos y extensibles empleando conceptos orientados a objetos, permitiendo meta-datos así como datos complejos.

 

Los mecanismos extensibles permiten definir modelos de información estándares a otras organizaciones que pueden utilizar la infraestructura de comunicación OPC-UA y enfocarse en estandarizar la información que será expuesta.

 

De hecho ya hay iniciativas para definir modelos de información estándares como FDI o PLCopen.

 

Las capacidades de modelado de OPC-UA pueden ser escaladas como las capacidades de transporte. Se puede mantener la oferta de información simple, similar al OPC Clásico, pero también es posible enriquecer la información con un sistema de tipo y por tanto ofreciendo más información útil en una multitud de escenarios de aplicación.

 

 

Larraioz Elektronika, servicio técnico, consultoría, training, y canal de venta oficial de Takebishi, aporta la solución DxpServer, también conocido como DeviceXPlorer OPC Server, el software OPC Server de Takebishi para sistema operativo MS Windows. Este aporta la conectividad industrial con los controladores que operan en los sistemas de producción industrial, tales como PLC, CNC y Robots.DxpSERVER comunica con dichos controladores a través de diferentes redes, Ethernet y Serie entre otros.

 

Por AGM – Larraioz Elektronika

Un comentario en «OPC: Desde el clásico al nuevo OPC-UA»

  • Según lo expuesto en el articulo, tenemos mucho camino por recorrer.
    Citando lo expuexto, en el proceso de migración » La OPC Foundation ofrece ‘proxies’ y ‘wrappers’ capaces de traducir las diferentes interfaces OPC Clásicas a OPC-UA y viceversa. Los fabricantes pueden utilizar esta estrategia como primer nivel en la migración de los productos clásicos a OPC-UA.
    El segundo nivel de migración a OPC-UA es la integración de OPC-UA directamente en los productos existentes sin añadir características específicas de OPC-UA.
    El tercer nivel podría requerir la modificación de interfaces internas del producto para soportar todas las características de OPC-UA interesantes para el producto», debemos adicionalmente a lo propuesto por la la OPC Forum implementar dispositivos y/o consentradores que manejen directo UA?.

    Gracias

Deja una respuesta

Tu dirección de correo electrónico no será publicada.