Índice

OPC server.................................................................................................................................2

Historia de OPC.........................................................................................................................4

Tipos de OPC.............................................................................................................................6
OPC DA (Data Access)............................................................................................................6
OPC A&E (Alarm and Events)................................................................................................8
OPC HDA (Historical Data Access)........................................................................................9
OPC UA (Unified architecture).............................................................................................10
Otras interfaces estándares OPC............................................................................................11

Partes que integran un OPC server.......................................................................................12

Proveedores en el mercado de servidores OPC....................................................................14

Caso de estudio.........................................................................................................................17

Referencias...............................................................................................................................19
 OPC server
OPC es una tecnología de comunicación con una arquitectura de cliente y servidor. Una
aplicación actúa de servidor proporcionando datos y otra actúa como cliente leyéndolos o
manipulándolos o dicho de otra forma es una interfaz de programación de aplicaciones
estándar para el intercambio de datos que puede simplificar el desarrollo de Drivers de I/O
(Dispositivos de entrada y salida u/o Banco de Datos) y mejorar el rendimiento de los sistemas
de interfaz.

OPC es con mucha diferencia, la tecnología de comunicación industrial estándar. Ello permite
el intercambio de información entre múltiples dispositivos y aplicaciones de control sin
restricciones o límites impuestos por los fabricantes. Los softwares que tienen la capacidad de
adquirir datos de los dispositivos de campo y servirlos en OPC son los llamados Servidores
OPC u OPC Servers.

Un servidor OPC es una aplicación de software (driver) que cumple con una o más
especificaciones definidas por la OPC Foundation. El Servidor OPC hace de interfaz
comunicando por un lado con una o más fuentes de datos utilizando sus protocolo nativos
(típicamente PLCs, DCSs, básculas, Modulos I/O, controladores, etc.) y por el otro lado con
Clientes OPC (típicamente SCADAs, HMIs, generadores de informes, generadores de
gráficos, aplicaciones de cálculos, etc.). En una arquitectura Cliente OPC/ Servidor OPC, el
Servidor OPC es el esclavo mientras que el Cliente OPC es el maestro. Las comunicaciones
entre el Cliente OPC y el Servidor OPC son bidireccionales, lo que significa que los Clientes
pueden leer y escribir en los dispositivos a través del Servidor OPC.

Un servidor OPC puede estar comunicándose continuamente con los PLCs de campo, RTUs,
estaciones HMI u otras aplicaciones. Aunque el hardware y el software provengan de
diferentes marcas comerciales, el cumplimiento del estándar OPC posibilita la comunicación
continua en tiempo real.

Por ello, OPC ha permitido una mejor cooperación entre proveedores y usuarios, ayudando a
construir soluciones completamente transversales, dando a los consumidores más poder de
elección entre diferentes aplicaciones industriales.
Un Cliente OPC puede conectarse, por medio de una red a Servidores OPC proporcionados
por uno o más fabricantes. De esta forma no existe restricción por cuanto a tener un Software
Cliente para un Software Servidor, lo que es un problema de interoperabilidad que hoy en día
se aprecia con sistemas del tipo propietario. Como se muestra a continuación:

Los fabricantes, a su vez, proporcionan el código que identifica: Dispositivos, Tipos de Datos
a los que cada servidor tiene acceso, Valor de los Datos, y detalles sobre cómo el Servidor
físicamente acceda a los datos. Sin estos códigos Servidores y Clientes no podrían
comunicarse y reconocerse como sistemas compatibles.

La siguiente imagen muestra la interoperabilidad de diversos Sistemas interconectados dentro

un una misma Red si solo si estos trabajan bajo un estándar OPC.
También es posible que otros sistemas como lo son SCADA o DCS puedan comunicarse con
un Servidor OPC y llevar su información recopilada desde un banco de datos o dispositivos
físicos como lo son del tipo SMART y PLC’s. Así de esta forma aplicaciones cliente OPC de
otros fabricantes tendrán acceso a estos datos por medio del Servidor. Lo anterior se observa
en la siguiente imagen.

Historia de OPC
El estándar OPC (inicialmente OLE for Proccess Control, pero renombrado Open Platform
Communications) surgió a mediados de los años 90 como una tecnología para la
comunicación del software SCADA y otros HMI con los dispositivos de control en el ámbito
de la industria. El principal acicate para su desarrollo fue la superación de las insuficiencias
que presentaban los sistemas basados en DDE, en particular su escaso rendimiento y la
incompatibilidad de las distintas extensiones que los fabricantes habían introducido para
solventarlo.

OPC se basaba originalmente en la tecnología OLE/DCOM de Microsoft. Las especificaciones

iniciales fueron desarrolladas por la OPC Task Force, una institución promovida por varias de
las principales compañías del sector: Fisher-Rosemount, Intellution, Intuitive Technology,
Opto22, Rockwell y Siemens AG.

En agosto de 1996 se liberó una primera versión de las especificaciones (OPC Specification
Version 1.0), basadas en las tecnologías COM (Component Object Model), OLE (Object
Linking and Embedding) y DCOM (Distributed Component Model). La primera definía un
sistema de comunicación entre procesos y de creación dinámica de objetos de forma neutral;
es decir, éstos podían ser utilizados posteriormente en entornos de desarrollos distintos al de
creación original. La segunda, OLE, establecía mecanismos de mantenimiento y gestión de
datos y archivos de forma que pudiesen tratarse por distintas aplicaciones. La última, DCOM
permitía la creación de componentes distribuidos de software en diferentes sistemas
intercomunicados.

Uno de sus mayores retos del estándar OPC ha sido adaptarse a un dominio en continuo
cambio, para lo que se optó desde sus orígenes por una estrategia que permitiese enriquecerlo
de forma constante por medio de adiciones básicas. Esto se vino llevando a cabo inicialmente
mediante distintos documentos Data Access Specification, que recogían las incorporaciones a
los mecanismos y funcionalidad de lectura y escritura de datos de proceso. Paralelamente,
OPC se veía enriquecido por la adición de servicios de interés en el ámbito industrial.

A la primera versión del protocolo, que pasó a denominarse OPC DA (Data Access) y
establecía cómo debía realizarse el intercambio de datos de tiempo real entre servidores y
clientes, se le incorporó en 1999 la posibilidad de gestionar el tráfico de alarmas y eventos
entre servidores y clientes, OPC AE (Alarms and Events Specification), y en el año 2000 se le
agregó una capacidad semejante de manejo de datos históricos, OPC HDA (Historical Data
Access Specification). También en dicho año se definieron e implementaron políticas de
seguridad, OPC S (Security Specification). Otras adiciones posteriores fueron las recogidas en
la OPC Batch Specification, para la gestión de tareas, la OPC XML-DA Specification para
servicios web a través de XML y SOAP, o la OPC DX Specification, que define la
comunicación de servidor a servidor sin uso de clientes. La comunicación entre servidores,
que requieren mensajes con tipos de datos más complejos, se efectúa gracias a OPC CD
(Complex Data). Entre los últimos protocolos incorporados al estándar se encuentra OPC C
(Commands), que dota a clientes y servidores de un conjunto de interfaces para indentificar,
enviar y moonitorizar comandos de control.

Actualmente, el rápido crecimiento en el número de productos que incorporan OPC, así como
sus capacidades, han hecho de éste el estándar industrial con más aceptación. La OPC
Foundation es la organización encargada de crear y mantener las especificaciones de forma
abierta.

Conforme DCOM fue reemplazándose por la tecnología .NET, que permitía un desarrollo ágil
en redes y entornos Web, OPC debió adaptar sus interfaces a dicha plataforma. La última API
liberada del OPC clásico, conocida formalmente como OPC Express Interface (Xi), se basa en
el modelo .NET 4.0 WCF (Windows Communication Foundation). Provee de una envoltura a
las interfaces clásicas, y permite un uso más seguro a través de redes por medio de
mecanismos de autentificación, autorización y encriptación de datos. También simplifica el
acceso a través de cortafuegos, al requerir sólo la apertura de dos puertos.

Desde el año 2006, la OPC Foundation, en conjunción con el MTConnect Institute, viene
trabajando en una versión unificada de los estándares (OPC UA, o Unified Architecture), con
miras a avanzar hacia una arquitectura orientada a servicios de tipo multiplataforma. Gracias a
esto se elimina la tradicional dependencia de Microsoft Windows de los protocolos de control
industrial. OPC UA se beneficia de las características que proporcionan el conjunto de
estándares descrito, a las que se une la ventaja de ser portable a otros sistemas operativos. Para
ello, OPC abandona definitivamente el modelo DCOM y se constituye en una arquitectura
orientada a servicios (SOA, Service Oriented Architecture). Existen interfaces de
programación (API) implementadas para C, C++, .NET, Java, NodeJS y Python. Otras
ventajas que aporta son la seguridad revisada, el modelo de información, redundancia,
buffering de datos o monitorización de los enlaces.

Tipos de OPC
Existen cuatro tipos de servidores OPC definidos por la OPC Foundation, y son los siguientes:

OPC DA (Data Access)

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.

A un alto nivel, un Servidor de Acceso a Datos OPC, se compone de varios objetos: Servidor,
Grupo, e Item. La función del servidor OPC, es mantener la información sobre sí mismo y
hacer las veces de un "Recipiente" unificando los datos en un Grupo. La función del Grupo
OPC es mantener la información y proporcionar un mecanismo por contener y organizar
lógicamente los Items.
Los Grupos OPC proveen a los clientes OPC, quienes ejecutan aplicaciones, una forma de
organizar sus datos. Por ejemplo, el grupo podría representar los Items de un dispositivo en
particular para que despliegue o informe sobre sus datos. Pueden leerse datos y pueden
escribirse.

Hay dos tipos de grupos, Público y Local, que se describen tal como sigue:

a) Público: Es compartido por múltiples clientes. Hay también interfaces optativas específicas
para grupos públicos en plataforma Linux o Unix

b) Local: Trabaja en torno a un cliente o grupo con prioridad.

Dentro de cada Grupo el cliente puede definir uno o más Artículos de OPC

Los Items OPC representan conexiones a las fuentes de datos dentro del servidor. Un Item
OPC, bajo la perspectiva de interface, no es accesible como un objeto por un Cliente OPC. Por
consiguiente, ninguna interface externa se encuentra definida para un Item OPC. Todos
accedena los Items OPC vía Grupo OPC, objeto o ícono que “contiene” el (los) Item(es) OPC,
o simplemente donde el ítem OPC se define. Asociando, un Item es un valor, una condición y
permanece o varía en el tiempo. El valor está en la forma de una variable, y la condición es
similar a lo especificado por Fieldbus (Estándar de Buses de Campo).
OPC A&E (Alarm and Events)
Estas interfaces proveen de mecanismos a los Clientes OPC, con los cuales pueden ser
notificados de la ocurrencia de eventos y condiciones de alarmas específicas. Estas también
proporcionan servicios que les permiten a los Clientes OPC determinar eventos y condiciones
necesarias para alarmas, eventos, y para obtener su estado actual, todo ello apoyado por un
Servidor OPC. Dentro de OPC se puede definir que:

a) Alarma: Es una condición anormal del sistema y por lo que es un caso especial de esta.
b) Condición: Es un estado nombrado Evento en el Servidor OPC. Por ejemplo, la
etiqueta FC101 puede tener las condiciones siguientes asociadas con ella:
 HighAlarm, HighHighAlarm,
 Normal, LowAlarm,
 LowLowAlarm.
c) Evento: Es una ocurrencia perceptible que es de importancia al Servidor OPC, de los
dispositivos que representa o sus Clientes OPC.

Un evento puede o no ser asociado con una condición. Por ejemplo, la transición de
HighAlarm a condiciones normales es un evento. Sin embargo, una acción del operador
permite cambiar la configuración del sistema, y los errores son ejemplos de eventos que no se
relacionan a las condiciones específicas del sistema. Los Clientes de OPC pueden subscribirse
al sistema para ser notificados de las ocurrencias de eventos específicos.

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.

La interface de IOPCEventServer, proporciona los métodos que habilitan al Cliente OPC a:

a) Determinar los tipos de eventos que los Servidores OPC soportan.

b) Subscribirse a eventos específicos, para que puedan recibir notificaciones de sus
intervalos de ocurrencias. Pueden usarse filtros para definir un subconjunto de eventos
deseados.
c) Acceder y manipular las condiciones asignadas al Servidor OPC.
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.
OPC UA (Unified architecture)
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 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.

OPC-UA se construye en varias capas, como se muestra en la imagen a continuación. 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.
Se 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 interfaces estándares OPC

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 siguiente imagen 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 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.

Partes que integran un OPC server

Las características técnicas de OPC contienen siempre dos juegos de interfaces; Interface
diseñada para un propósito (Aplicación) y una Interface de Automatización.
OPC especifica la interface COM (Component Object Model), lo que la interface es y su
aplicación y no su implementación. Especifica el comportamiento esperado que proporciona la
interface ante el uso y/o aplicaciones del cliente. Comprende tener las descripciones de
arquitecturas e interfaces. Como todas las aplicaciones COM, la arquitectura OPC es un
modelo Cliente-Servidor donde el componente Servidor OPC, proporciona una interface con
el objeto y lo controla.

Hay varias consideraciones, que son únicas, para llevar a cabo la implementación de un
servidor OPC. Una de ellas, la principal, es la frecuencia de traslado e intercambio de datos a
través de redes comunicacionales, hacia dispositivos físicos u otras bases de datos las cuales
son incompatibles entre sí. De esta manera, se espera que Servidores OPC sean ejecutables ya
sean en forma Local o Remota, los cuales incluyan un código que los identifique y los
respalde en la recolección de datos en forma eficaz entre un dispositivo físico o una base de
datos.

Una aplicación Cliente OPC se comunica con un Servidor OPC a través de un cliente
específico e interfaces de automatización. Los servidores OPC deben llevar a cabo la interface
del cliente, y opcionalmente puede llevar a cabo la interface de automatización, tal como lo
describe la arquitectura típica OPC.
En algunos casos la Fundación OPC proporciona una interface estándar de automatización.
Esta interface, denominada wrapperDLL, puede usarse para cualquier Cliente-Servidor o
fabricante específico.

Una Arquitectura OPC se refiere a la infraestructura de comunicaciones que incluye uno o

varios Clientes OPC y Servidores OPC comunicándose entre sí. Para mantener una
Arquitectura Cliente / Servidor OPC fácil de leer se utiliza la convención de dibujar el
diagrama de flujo con los Datos fluyendo desde abajo hacia arriba. Los Datos deben fluir
desde las Fuentes de Datos (PLC, DCS, RTU, Básculas, Protocolos, Bases de Datos, Hojas de
Cálculo, etc.) hacia la Aplicación que utilizará los Datos (SCADAs, Bases de Datos
Relacionales, HMIs, Historiadores, Servidores Web, Hojas de Cálculo, etc.).

Proveedores en el mercado de servidores OPC

Actualmente son todos los OPC Server que existen en el mercado, anexando la marca como
ABB, Siemens Yokogawa, MBS, Panasonic, Matrikon, etc. y un hipervínculo que lo lleva a
una breve explicación de cada uno.

• @aGlance OPC Server

• ABB Advant IMS OPC Server
• Allen Bradley OPC Server
• APACS OPC Server (API)
• APACS OPC Server (Direct)
• Applikon OPC Server from MatrikonOPC
• AspenTech InfoPlus.21 OPC Server
• BACnet OPC Server for BACnet Devices
• Bailey OPC Server (Direct)
• Bailey OPC Server (SemAPI)
• Bristol Babcock OpenBSI OPC Server
• Citect OPC Server
• Direct Data Exchange (DDE) OPC Server
• DNP3 OPC Server
• EDAS (HOSE) OPC Server
• eDNA OPC Server
• Eurotherm 800 Series OPC Server
• Fisher ROC OPC Server (ROC & ROC Plus)
• Foxboro I/A (Object Manager) OPC Server
• Foxboro OPC Server
• GCOM ABB OPC Server
• GE CIMPLICITY OPC Server
• GE Fanuc PLC OPC Server
• GE Harris OPC Server
• GE Speedtronic Mark V & VI OPC Server (GSM)
• GE Speedtronic Mark V OPC Server (Direct)
• Honeywell Measurex OPC Server
• Husky Host OPC Server
• IEC 60870-5 OPC Server
• IEC 61400-25 OPC Server
• IEC 61850 OPC Server
• Intellution Fix/iFix OPC Server
• JC N1 (Johnson Controls) OPC Server
• JC N2 (Johnson Controls) OPC Server
• Kaye Digilink OPC Server
• Kaye Netpac OPC Server
• KNX OPC Server
• LonWorks OPC Server
• Lufkin Modbus OPC Server
• Mettler Toledo OPC Server
• Microsoft Task Manager OPC Server
• Mitsubishi PLC OPC Server for Mitsubishi PLCs
• Mitsubishi Turbine Controllers OPC Server
• Modbus OPC Server for Modbus Devices
• Moore MYCRO OPC Server
• Motorola IP Gateway OPC Server (MOSCAD)
• NEG Micon OPC Server
• Nova Biomedical OPC Server
• Nova BioProfile FLEX Analyzer OPC Server
• OMNI Flow Computers OPC Server
• OMRON OPC Server for OMRON PLCs
• OPC Genie
• OPC Server for Databases (ODBC, MySQL, MSSQL, and Oracle)
• OPC Server for Mark VI (Direct) - MatrikonOPC OPC Servers
• Proficy (iHistorian) OPC Server
• Provox OPC Server (Direct)
• RM-80 OPC Server for Radiation Monitoring Systems
• Sartorius OPC Server
• SCADA Modbus OPC Server (Telemetry / OPC DA)
• Schneider Electric PowerLogic SMS OPC Server
• SCI OPC Server
• Siemens PLC data access with OPC UA or OPC Classic
• Siemens Wind Turbines OPC Server
• SNMP - OPC Client
• SNMP Agent for OPC
• SNMP OPC Server
• Triconex OPC Server
• TVA DatAWare OPC Server
• Unitrol 5000 OPC Server
• Vestas Wind Turbine Controllers OPC Server
• WITS OPC Server
• Wonderware Historian OPC Server (InSQL)
• Wonderware InTouch OPC Server
• Yokogawa OPC Server

Caso de estudio
Este caso de estudio es sacado de una revista la cual trata de la Integración Vertical en plantas
industriales utilizando OPC UA e IEC-61499 en dicha reviste muestra caso de estudio
propuesto que describe un sistema de industrial a escala con el objetivo de mostrar una
aplicación de automatización industrial. En particular, la planta de producción es una línea de
montaje con tres estaciones FESTO® como se representa en la imagen. La Estación de
Manipulación recoge desde una posición de entrada las piezas de trabajo que deben procesarse
y las deja sobre una rampa que alimenta siguiente estación; la Estación de Transporte traslada
y selecciona las piezas; mientras que la Estación de Almacenamiento completa el
procesamiento de la línea de montaje.

La arquitectura de hardware y software de bajo coste comprende: una tarjeta Raspberry Pi 2

modelo B como controlador del proceso y que integra un servidor OPC UA, una BeagleBone
Black como sistema de supervisión y monitorización, y dos tarjetas Arduino UNO como
dispositivos entrada/salida de periferia distribuida trabajando como esclavos Modbus/TCP.

Como se puede observar en la imagen, la Estación de Almacenamiento y la Estación de

Transporte se asocian a la red industrial mediante el uso de esclavos que utilizan el protocolo
Modbus/TCP integrado en tarjetas Arduino UNO. La tarjeta RPi2 tiene acceso directo a las
E/S de la Estación de Manipulación y, como a su vez es maestro Modbus/TCP, puede acceder
a las E/S de las otras estaciones del proceso. En la imagen también se puede observar el
archivo de configuración XML del servidor OPC UA con el cual se consigue el acceso a las
variables locales en la RPi2 y las variables remotas de los esclavos como maestro
Modbus/TCP.

La RPi2 controla las tres estaciones e integra el servidor OPC UA. Para ello se ejecuta una
instancia del runtime FORTE, el cual permite a los SIFBs anteriormente presentados llevar a
cabo el control de todo el proceso y la gestión del servidor OPC UA.

Los clientes OPC UA remotos, así como la aplicación de supervisión que se ejecuta en la
tarjeta BBB, pueden leer/escribir o suscribirse a los datos de proceso mediante el conjunto
SIFB anteriormente descrito. Por ejemplo, la imagen muestra la aplicación de supervisión de
la Estación de Transporte bajo la norma IEC 61499.

El servidor OPC UA y todas las características de los clientes se integran en una librería
propia implementada utilizando una pila OPC UA en C ++. La librería OPC UA incluye el
acceso a los esclavos Modbus/TCP y al GPIO del RPi2. Al mismo tiempo, esta librería OPC
UA se ha integrado en el runtime FORTE, de esta manera las características del servidor y
cliente están incrustadas en el runtime.
Además, en la página que se muestra a continuación existen muchos de los casos de estudios
que se han realizado según Matrikonopc.com.

https://www.matrikonopc.com/downloads/types/casestudies/index.aspx

Referencias
Casares J. (2015). Recuperado el 23 de Abril de 2020, de https://josecasares.com/historia-de-
opc/

García M., Irisarri E., & Pérez F. (2017). Integración Vertical en plantas industriales
utilizando OPC UA e IEC-61499. Recuperado el 23 de Abril de 2020, de
http://ingenieria.ute.edu.ec/enfoqueute/public/journals/1/html_v8n1/art021.html

OPC: Desde el clásico al nuevo OPC-UA. (2016). Recuperado el 23 de Abril de 2020, de

https://larraioz.com/articulos/opc-desde-el-clasico-al-nuevo-opc-ua

OPC UA (Arquitectura Unificada). (2020). Recuperado el 23 de Abril de 2020, de

https://www.matrikonopc.es/opc-ua/index.aspx

Plant and Factory Data Connectivity. (2020). Recuperado el 23 de Abril de 2020, de

https://www.matrikonopc.com/drivers/driver-types.aspx

Que es OPC y que es un OPC Server. (2019). Recuperado el 23 de Abril de 2020, de

https://www.kepserverexopc.com/que-es-opc-y-que-es-un-opc-server/

Que es un Servidor OPC. (2020). Recuperado el 23 de Abril de 2020, de

https://www.matrikonopc.es/opc-servidor/index.aspx
Vidal P. (2004). OPC: UN ESTANDAR EN LAS REDES INDUSTRIALES Y BUSES DE
CAMPO. Recuperado el 23 de Abril de 2020, de
http://www.etitudela.com/entrenadorcomunicaciones/downloads/labviewintroducciono
pcserver.pdf