RTP – significa “Real Time Transport Protocol” (Protocolo de transporte en

tiempo real), y define un formato de paquete estándar para el envío de audio y

video sobre Internet. Es definido en el RFC1889. Fue desarrollado por el grupo de
trabajo de transporte de audio y video y fue publicado por primera vez en
1996. RTP se utiliza ampliamente en los sistemas de comunicación y
entretenimiento que involucran medios de transmisión, tales como la telefonía,
aplicaciones de videoconferencias, servicios de televisión y web basado en
funcionalidades push-to-talk.

RTP se utiliza junto con el protocolo de control de RTP (RTCP). Mientras

que RTP transporta los flujos de medios (por ejemplo, audio y vídeo), RTCP se
usa para supervisar las estadísticas de transmisión y calidad de servicio (QoS) y
ayuda a la sincronización de múltiples flujos. RTP es originado y recibido en
número de puerto par y la comunicación asociadas a RTCP utilizan el próximo
número de puerto impar superior. RTP es uno de los fundamentos de VoIP y se
utiliza conjuntamente con SIP el cual ayuda a establecer las conexiones a través
de la red.

Modbus

Ir a la navegación Ir a la búsqueda

Modbus es un protocolo de comunicaciones situado en los niveles 1, 2 y 7

del Modelo OSI, basado en la arquitectura maestro/esclavo (RTU) o
cliente/servidor (TCP/IP), diseñado en 1979 por Modicon para su gama de
controladores lógicos programables (PLCs). Convertido en un protocolo de
comunicaciones estándar de facto en la industria, es el que goza de mayor
disponibilidad para la conexión de dispositivos electrónicos industriales.1

Las principales razones por las cuales el uso de Modbus en el entorno industrial
se ha impuesto a otros protocolos de comunicaciones son:

 Se diseñó teniendo en cuenta su uso para aplicaciones industriales

 Es público y gratuito
 Es fácil de implementar y requiere poco desarrollo
 Maneja bloques de datos sin suponer restricciones
 Modbus permite el control de una red de dispositivos, por ejemplo un sistema
de medida de temperatura y humedad, y comunicar los resultados a un ordenador.
Modbus también se usa para la conexión de un ordenador de supervisión con una
unidad remota (RTU) en sistemas de supervisión adquisición de datos (SCADA).
Existen versiones del protocolo Modbus para puerto serie y Ethernet
(Modbus/TCP).

Cada dispositivo de la red Modbus posee una dirección única. Cualquier

dispositivo puede enviar órdenes Modbus, aunque lo habitual es permitirlo sólo a
un dispositivo maestro. Cada comando Modbus contiene la dirección del
dispositivo destinatario de la orden. Todos los dispositivos reciben la trama pero
sólo el destinatario la ejecuta (salvo un modo especial denominado "Broadcast").
Cada uno de los mensajes incluye información redundante que asegura su
integridad en la recepción. Los comandos básicos Modbus permiten controlar un
dispositivo RTU para modificar el valor de alguno de sus registros o bien solicitar
el contenido de dichos registros.

Existe gran cantidad de modems que aceptan el protocolo Modbus. Algunos

están específicamente diseñados para funcionar con este protocolo. Existen
implementaciones para conexión por cable, wireless, SMS o GPRS. La mayoría de
problemas presentados hacen referencia a la latencia y a la sincronización.

Índice

 1 Versiones del protocolo

 2 Modelo de Datos Modbus
 3 Formato de la trama
 4 Implementaciones
 5 Limitaciones
 6 Enlaces externos
 7 Referencias

Versiones del protocolo

Hay muchas variantes de protocolos Modbus, existen versiones del protocolo

Modbus para el puerto serie, para Ethernet, y otros protocolos que soportan el
conjunto de protocolos TCP/IP de Internet:

 Modbus RTU — Es la implementación más común disponible para Modbus.

Se utiliza en la comunicación serie y hace uso de una representación
binaria compacta de los datos para el protocolo de comunicación. El
formato RTU sigue a los comandos/datos con una suma de comprobación
de redundancia cíclica (CRC) como un mecanismo de comprobación de
errores para garantizar la fiabilidad de los datos. Un mensaje Modbus RTU
 debe transmitirse continuamente sin vacilaciones entre caracteres. Los
mensajes Modbus son entramados (separados) por períodos inactivos
(silenciosos).
 Modbus ASCII — Se utiliza en la comunicación serie y hace uso de
caracteres ASCII para el protocolo de comunicación. El formato ASCII
utiliza un checksum de control de redundancia longitudinal (LRC). Los
mensajes Modbus ASCII están entramados por los dos puntos principales
(":") y la nueva línea (CR/LF).
 Modbus TCP/IP o Modbus TCP — Se trata de una variante Modbus
utilizada para comunicaciones a través de redes TCP/IP, conectándose a
través del puerto 502.2 No requiere un cálculo de suma de verificación
(checksum), ya que las capas inferiores ya proporcionan protección de
checksum.
 Modbus sobre TCP/IP o Modbus sobre TCP o Modbus RTU/IP — Esta es
una variante de Modbus que difiere del Modbus TCP en que se incluye una
suma de comprobación en la carga útil como en Modbus RTU.
 Modbus sobre UDP — Algunos han experimentado con el uso de Modbus
sobre UDP en redes IP, lo que elimina los gastos generales necesarios
para TCP.3
 Modbus Plus (Modbus+, MB+ o MBP) — Es una versión extendida del
protocolo y privativa de Schneider Electric y a diferencia de las otras
variantes, soporta comunicaciones peer-to-peer entre múltiples masters.4
Requiere un co-procesador dedicado para manejar HDLC. Utiliza par
trenzado a 1 Mbit/s y sus especificaciones son muy semejantes al estándar
EIA/RS-485 aunque no guarda compatibilidad con este, e incluye
transformador de aislamiento en cada nodo. Se requiere hardware especial
para conectar Modbus Plus a un ordenador, normalmente una tarjeta
diseñada para bus ISA, PCI o PCMCIA.
 Pemex Modbus — Esta es una extensión de Modbus estándar con soporte
para datos históricos y de flujo. Fue diseñado para la compañía petrolera
Pemex para su uso en el control de procesos y nunca alcanzó un uso
generalizado.
 Enron Modbus — Esta es otra extensión del estándar Modbus desarrollada
por Enron Corporation con soporte para variables enteras de 32 bits y de
punto flotante y datos históricos y de flujo. Los tipos de datos se asignan
utilizando direcciones estándar.5 Los datos históricos cumplen con un
estándar de la industria del American Petroleum Institute (API, por sus
siglas en inglés) según la forma en que deben almacenarse los datos.

El modelo de datos y las llamadas de función son idénticas para las primeras 4
variantes de protocolos; Sólo la encapsulación es diferente. Sin embargo, las
variantes no son interoperables, ni sus formatos de trama tampoco.
Modelo de Datos Modbus

El modelo de datos en Modbus distingue entre entradas digitales (discrete

input), salidas digitales (coils), registros de entrada (input register) y registros de
retención (holding registers). Las entradas y salidas digitales ocupan,
evidentemente, un bit; mientras que los registros, tanto de entrada como de
retención, ocupan dos Bytes

La siguiente es una tabla de tipos de objetos proporcionados por un

dispositivo esclavo Modbus a un dispositivo maestro Modbus:

Tipo de objeto Acceso Tamaño

Discrete input Solo leer 1 bit
Coil Leer/escribir 1 bit
Input register Solo leer 16 bits
Holding register Leer/escribir 16 bits

Formato de la trama

Una trama Modbus está compuesta por una Unidad de Datos de Aplicación (ADU),
que incluye una Unidad de Datos de Protocolo (PDU):6

 ADU = Dirección + PDU + Comprobación de errores,

 PDU = Código de función + Datos.

Todas las variantes de Modbus usan uno de los siguientes formatos de trama. 1

Formato de trama Modbus RTU (utilizado principalmente en líneas asíncronas

de 8 bits como RS-485)

Longitud
Nombre Función
(bits)

Inicio 28 Al menos 3 1⁄2 Tiempos de silencio

Dirección 8 Station address

Indica el código de función; Por ejemplo, leer los registros

Función 8
de bobinas/retención

Datos + La longitud se rellenará dependiendo del tipo de

Datos n×8
mensaje

CRC 16 Verificación de redundancia cíclica (CRC)

 Fin 28 Al menos 3 1⁄2 Tiempos de silencio entre tramas

Nota sobre el CRC:

 Polinomial: x16 + x15 + x2 + 1 (CRC-16-ANSI también conocido como CRC-

16-IBM, Polinomio algebraico hexadecimal normal siendo 8005 e inverso
A001).
 Valor inicial: 65.535
 Ejemplo de trama en hexadecimal: 01 04 02 FF FF B8 80 (Cálculo CRC-16-
ANSI desde 01 a FF da 80B8, que se transmite el byte menos significativo
primero).

Formato de trama Modbus ASCII (utilizado principalmente en líneas serie

asíncronas de 7 u 8 bits)

Longitud
Nombre Función
(Bytes)

Inicio 1 Comienza con dos puntos : (El valor hex ASCII es 3A)

Dirección 2 Dirección de la estación

Indica los códigos de función como leer bobinas /

Función 2
entradas

Datos + La longitud se rellenará dependiendo del tipo

Datos n×2
de mensaje

LRC 2 Verificación de redundancia longitudinal (LCR)

Par retorno de carro/avance de línea (CR/LF) (Valores

Fin 2
ASCII de 0D, 0A)

Dirección, función, datos y LRC son todos pares legibles de caracteres

hexadecimales que representan valores de 8 bits (0-255). Por ejemplo, 122 (7 x 16
+ 10) se representará como 7A.

LRC se calcula como la suma de valores de 8 bits, negados (complemento

de dos) y codificado como un valor de 8 bits. Ejemplo: si la dirección, la función y
los datos codifican como 247, 3, 19, 137, 0 y 10, su suma es 416. El complemento
de dos (-416) recortado a 8 bits es 96 (por ejemplo 256 × 2 - 416) Que se
representará como 60 en hexadecimal. Por lo tanto el siguiente trama:
:F7031389000A60<CR><LF>.
 Formato de trama Modbus TCP (utilizado principalmente en redes Ethernet)

Longitud
Nombre Función
(Bytes)

Identificador de la Para la sincronización entre mensajes de

2
transacción servidor y cliente

Identificador del
2 0 para Modbus/TCP
protocolo

Campo de longitud 2 Número de bytes en esta trama

Identificador de unidad 1 Dirección del esclavo (255 si no se usa)

Códigos de función como en otras

Código de función 1
variantes

Bytes de datos n Datos como respuesta o comandos

El identificador de unidad se utiliza con dispositivos Modbus/TCP que son

compuestos de varios dispositivos Modbus en las pasarelas Modbus/TCP a
Modbus RTU. En tal caso, el identificador de unidad indica la dirección de esclavo
del dispositivo detrás de la pasarela. Normalmente, los dispositivos compatibles
con Modbus/TCP ignoran el identificador de unidad.

El orden de bytes para valores en tramas de datos Modbus es big-endian

(MSB, byte más significativo de un valor recibido primero).

Implementaciones

Todas las implementaciones presentan variaciones respecto al estándar oficial.

Algunas de las variaciones más habituales son:

 Tipos de Datos
o Coma Flotante IEEE
o Entero 32 bits
o Datos 8 bits
o Tipos de datos mixtos
o Campos de bits en enteros
o Multiplicadores para cambio de datos a/de entero. 10, 100, 1000,
256...
 Extensiones del Protocolo
o Direcciones de esclavo de 16 bits
 o Tamaño de datos de 32 bits (1 dirección = 32 bits de datos
devueltos.)

Limitaciones

 Dado que Modbus fue diseñado a finales de los setenta para comunicarse
con controladores lógicos programables, el número de tipos de datos se
limita a aquellos entendidos por los PLC en ese momento. Los objetos
binarios grandes no son compatibles
 No existe una forma estándar para que un nodo encuentre la descripción de
un objeto de datos, por ejemplo, para determinar si un valor de registro
representa una temperatura entre 30 y 175 grados.
 Dado que Modbus es un protocolo maestro / esclavo, no es posible que un
dispositivo de campo "informe por excepción" (excepto a través de Ethernet
TCP / IP, llamado open-mbus) - el nodo maestro debe rutinariamente
encuestar cada dispositivo de campo y buscar cambios en los datos. Esto
consume ancho de banda y tiempo de red en aplicaciones en las que el
ancho de banda puede ser costoso, como por ejemplo un enlace de radio
de baja velocidad binaria.
 Modbus está restringido al direccionamiento de 254 dispositivos en un
enlace de datos, lo que limita el número de dispositivos de campo que
pueden conectarse a una estación maestra (una vez más, Ethernet TCP/IP
es una excepción).
 Las transmisiones Modbus deben ser contiguas, lo que limita los tipos de
dispositivos de comunicaciones remotas a aquellos que pueden almacenar
datos para evitar lagunas en la transmisión.
 El protocolo Modbus no ofrece seguridad contra órdenes no autorizadas o
interceptación de datos.7

RTU

Una Unidad Terminal Remota (UTR o, mas conocida por sus siglas en
inglés, RTU) es un dispositivo basado en microprocesadores, el cual permite
obtener señales independientes de los procesos y enviar la información a un sitio
remoto donde se procese.1 Generalmente este sitio remoto es una sala de control
donde se encuentra un sistema central SCADA el cual permite visualizar las
variables enviadas por la UTR. Dentro del universo de las UTR existen los
controladores lógicos programables (PLCs) quienes han complementado sus
facilidades de comunicación. En el mundo PLC surgieron los protocolos de
comunicaciones para pequeños sistemas de control (RS-485, SINEC L1, Modbus,
DNP3, CAN bus, IEC-101, IEC-105, etc..) En forma paralela en el mundo RTU ha
evolucionado en la industria eléctrica, y otras ramas, donde grandes sistemas
SCADA, requieren la gestión de gran número de señales con precisión de
milisegundos, cosa que es imposible realizar con los PLCs. En las RTUs se ha
desarrollado y expandido a otros equipamientos (medidores de energía, relés de
protecciones, reguladores automáticos), el protocolo de comunicaciones IEC o CEI
60870-4. Para las comunicaciones internas de los equipos, o entre ellos, las RTU
han adoptado el protocolo Modbus, en la forma de Modbus RTU, que puede
implementarse sobre una red RS-485 o sobre una red TCP/IP.23

¿Qué es el protocolo Modbus RTU?

Modbus es un protocolo de comunicaciones, basado en la arquitectura

maestro/esclavo o cliente/servidor, diseñado en 1979 por Modicon para su gama
de controladores lógicos programables (PLCs).
Debido a que este protocolo fue público, de fácil uso y que requiere poco
desarrollo (maneja bloques de datos sin suponer restricciones) se convirtió en un
protocolo de comunicaciones estándar en la industria. Es el protocolo de mayor
disponibilidad para la conexión de dispositivos electrónicos industriales.
El protocolo Modbus permite el control de una red de dispositivos, por ejemplo un
equipo de medición temperatura y humedad puede comunicar los resultados a una
PC. Modbus también se usa para la conexión de un PC de supervisión con una
unidad remota (RTU) en sistemas de supervisión de adquisición de datos
(SCADA). Existen versiones del protocolo Modbus para puerto serial y Ethernet
(Modbus/TCP).

¿Qué es el protocolo Modbus TCP?

Modbus/TCP es un protocolo de comunicación diseñado que permite a

equipos industriales tales como PLCs, PC, drivers para motores y otros tipos de
dispositivos físicos de entrada/salida, comunicarse sobre una red Ethernet. Fue
introducido por Schneider Automation como una variante de la familia de
protocolos MODBUS, ampliamente usada para la supervisión y el control de
equipo de automatización. Específicamente el protocolo define el uso de mensajes
MODBUS en un entorno intranet o internet usando los protocolos
TCP/IP.

La especificación Modbus/TCP define un estándar interoperable en el

campo de la automatización industrial, el cual es simple de implementar para
cualquier dispositivo que soporte sockets TCP/IP. Todas las solicitudes son
enviadas vía TCP sobre el puerto registrado 502 y normalmente usando
comunicación half-duplex sobre una conexión dada. Es decir, no hay beneficio en
enviar solicitudes adicionales sobre una conexión única mientras una respuesta
está pendiente.

Modbus/TCP básicamente encapsula una trama MODBUS dentro de una

trama TCP en una manera simple como se muestra en la figura a continuación.

¿Ques softwares soportan los protocolos Modbus RTU o TCO?

La mayoría de los softwares SCADA (Supervisor Control And Data

Acuisition) soportan Modbus por ejemplo: Citect, ICONICS, iFIX, InduSoft, Intouch,
Entivity Studio, Entivity Live, Entivity VLC, Trace Mode, Wizcon, Wonderware...
etc.

¿Cuales son los beneficios de utilizar el protocolo Modbus RTU/TCP?

 De codigo abierto, no se requiere pagar por licencia.

 Ampliamente soportado por HMIs o softwares SCADA
 Facil de usar
 Se pueden integrar varios equipos facilmente
 Bajo costo de desarrollo
 Conocido apliamente en la industria
Productos Modbus

tGW-715
Módulo Modbus / TCP a RTU / ASCII gateway, 1
puerto RS 485/422, puerto Ethernet (10/100 Base-
TX) con PoE.

tGW-718
Tiny Modbus / TCP a RTU / ASCII gateway con
PoE y 1 puerto RS-232/422/485 (RoHS).

tGW-722
Tiny Modbus / TCP a RTU / ASCII gateway con
PoE y 2 puertos RS-232 (RoHS).

tGW-725
Tiny Modbus / TCP a RTU / ASCII gateway con
PoE y 2 puertos RS-485 (RoHS).
 GW-7473
Modbus esclavo a la puerta de enlace Ethernet / IP.

GW-7662
Convertidor (Gateway) de PROFINET a Modbus
RTU/ASCII. Proteccion electrostatica de 1. 4 kV en
cualquier terminal. CPU de 32-bit 32MB de RAM /
4MB Flash / 8 KB EEPROM. Rango de operación -
25°C~75°C (13°F ~167°F).

OPC
Ir a la navegación Ir a la búsqueda

Para otros usos de este término, véase OPC (desambiguación).

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

control y supervisión de procesos industriales, basado en una tecnología Microsoft, que
ofrece una interfaz común para comunicación que permite que componentes de software
individuales interactúen y compartan datos. La comunicación OPC se realiza a través de
una arquitectura Cliente-servidor. El servidor OPC es la fuente de datos (como un
dispositivo hardware a nivel de planta) y cualquier aplicación basada en OPC puede
acceder a dicho servidor para leer/escribir cualquier variable que ofrezca el servidor. Es una
solución abierta y flexible al clásico problema de los drivers propietarios. Prácticamente
todos los mayores fabricantes de sistemas de control, instrumentación y de procesos han
incluido OPC en sus productos.

Las aplicaciones necesitan una manera común de acceder a los datos de cualquier fuente,
como un dispositivo o una base de datos.
Índice
 1 Ventajas
 2 Problema y solución OPC
 3 Situación
 4 Arquitectura
o 4.1 Arquitectura OPC cliente/servidor
 5 Bases de OPC
o 5.1 Objetos e interfaces
o 5.2 Acceso de Datos OPC
o 5.3 Gestión de Alarmas y Eventos
o 5.4 Acceso a Datos Históricos
 6 Aplicaciones OPC
 7 Arquitectura General y Componentes
o 7.1 Servidores locales y remotos
 7.1.1 Servidor de Acceso a Datos OPC (OPC DA)
 7.1.2 Servidor de Alarmas, Condiciones y Eventos OPC (OPC AE)
 7.1.3 Servidor de Acceso a Datos Históricos OPC (OPC HDA)
o 7.2 Intercambio de Datos OPC (OPC DX)
o 7.3 Acceso de Datos XML (OPC XML DA)
o 7.4 Arquitectura Unificada OPC (OPC UA)
o 7.5 Seguridad
 8 Estándares OPC
o 8.1 OPC common
 9 Enlaces externos

Ventajas
  Los fabricantes de hardware sólo tienen que hacer un conjunto de componentes de
programa para que los clientes los utilicen en sus aplicaciones.
 Los fabricantes de software no tienen que adaptar los drivers ante cambios de hardware.

Problema y solución OPC

El problema sin tecnología OPC.

La solución al problema al contar con tecnología OPC.

Situación
Con OPC, la integración de sistemas en un entorno heterogéneo se tornará simple.

Arquitectura
Arquitectura OPC cliente/servidor

Bases de OPC
Objetos e interfaces

Un cliente OPC se puede conectar a servidores OPC proporcionados por más de un

"proveedor".

Esto le puede ser útil para conectarse a más de dos OPC sin necesidad de seguir el mismo
protocolo.
Acceso de Datos OPC

Acceso de datos OPC.

Compuesto por varios elementos:

El servidor (server)

Mantiene información sobre el servidor

Sirve como container para objetos del grupo OPC

El grupo (group)

Mantiene información sobre sí mismo

Provee mecanismos para contener/organizar lógicamente items

El elemento (item)

Representan conexiones a fuentes de datos dentro de un servidor

Gestión de Alarmas y Eventos

Alarma

Es una condición anormal; caso especial de condición.

 Una condición es un estado concreto del Servidor de Eventos OPC o de uno de los objetos
contenidos por dicho servidor, que puede resultar de interés para sus clientes.

Evento

Es un suceso detectable que es significativo para un servidor OPC, para el aparato al que
representa y para sus Clientes OPC

Puede estar o no asociado a una condición

Acceso a Datos Históricos

Distintos tipos de servidores históricos:

Servidores de datos simples

ofrecen solo capacidad de almacenar datos

Servidores de análisis y compresión de datos complejos

ofrecen capacidad de compresión y almacenaje de datos

ofrecen funciones de análisis de datos

pueden actualizar datos y tener un resumen de actualizaciones

Aplicaciones OPC
 Diseñado principalmente para acceder a datos de un servidor en red.

 Distintas aplicaciones:

- nivel más bajo pueden coger datos de aparatos físicos y llevarlo a SCADA o DCS, o de un
servidor SCADA o DCS a una aplicación.
Arquitectura General y Componentes
 Dos tipos de interfaces

 Interfaces Custom (obligatorio, C/C++)

 Interfaces de Automatización (opcional, VB)

OPC especifica la interfaz COM, como: “Lo que la interfaz es y su aplicación y no su

implementación”. Especifica el comportamiento esperado que proporciona la interfaz ante
el uso y/o aplicaciones del cliente.

 Implementación de funciones de interfaces

 Obligatorio: Funcionalidades indispensables

 Opcional : Funcionalidades añadidas

La arquitectura OPC es un modelo Cliente-Servidor donde el Servidor OPC proporciona

una interfaz al objeto OPC y lo controla. Una aplicación cliente OPC se comunica a un
servidor OPC a través de un cliente OPC específico por medio de una interfaz de
automatización. El servidor OPC lleva a cabo la interfaz cliente, y opcionalmente lleva a
cabo la interfaz de automatización

Servidores locales y remotos

 Dos alternativas:

 Los clientes se deben conectar siempre a un servidor local que hará uso de un
esquema de red existente.
 El cliente se puede conectar al servidor local/remoto que desee.

Una aplicación cliente OPC, puede conectarse por medio de una red, a varios 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. Sistemas de
control supervisorio como lo son SCADA o DCS pueden comunicarse con un Servidor
OPC y proveer a este, información de los dispositivos de campo asociados. De esta forma,
aplicaciones cliente OPC de otros fabricantes tendrán acceso a estos datos por medio del
servidor.

Servidor de Acceso a Datos OPC (OPC DA)

 A un alto nivel, está compuesto por los objetos:

 Servidor: Mantiene la información sobre sí mismo, y unifica los Datos dentro de un

Grupo.
 Grupo: Dota de un mecanismo que contiene en forma lógica los ítemes. Se
clasifican en público o Local.
 Ítem: Es un valor, una condición y permanece o varía en el tiempo. Es una
dirección específica de los datos y no la fuente de datos.

Servidor de Alarmas, Condiciones y Eventos OPC (OPC AE)

 Provee de Interfaces, donde Clientes OPC son notificados de Sucesos. Estos mecanismos
se definen como:

 Alarma: Condición anormal de un sistema, por lo que es un caso especial de esta.

 Condición: Estado nombrado evento por contener condiciones asociadas a una
etiqueta como HighAlarm, Normal, LowAlarm.
 Evento: Ocurrencia perceptible, de importancia al servidor OPC, de los dispositivos
que representa o de sus dispositivos OPC.

Transmisión de paso a paso.

Servidor de Acceso a Datos Históricos OPC (OPC HDA)

Provee de una interfaz Cliente OPC de Acceso a Datos Históricos, que facilita el uso de
aplicaciones de acceso a datos. Características: Arquitectura de comunicación abierta y
eficaz, concentrada en el acceso a datos y no en los tipos de datos. Propósito: Permite que
aplicaciones (MS Office, Objetos WWW) accedan a datos de un dispositivo o un banco de
datos “In process”. Facilita el desarrollo de aplicaciones sin sacrificar la funcionalidad de la
Interfaz Cliente.

Intercambio de Datos OPC (OPC DX)

Define un conjunto de interfaces que permiten el intercambio de datos, así como la

comunicación "server to server" entre dispositivos y controladores conectados a Ethernet,
que utilizan distintos protocolos. OPC-DX permite a los servidores OPC-DA intercambiar
directamente datos sin la exigencia de un cliente OPC intermedio. La mejor manera de
pensar en un servidor OPC-DX es como un servidor OPC-DA que se puede configurar para
intercambiar datos con otros servidores OPC-DA. Como es el caso de otros servidores
OPC, el cliente aún se utiliza para configurar, controlar y vigilar este intercambio de datos.

Acceso de Datos XML (OPC XML DA)

Se está convirtiendo en el método estándar para el intercambio de datos entre las

aplicaciones de empresa y son cada vez más un proceso de control de entornos. OPC XML-
DA salió a la luz en 2003 tras varios años de desarrollo, y ofrece una interfaz Simple Object
Application Protocol (SOAP) para los objetos OPC DA 2.0/3.0. Esto permite a las
aplicaciones cliente ser escritas en Java, Perl, Python, y otros idiomas que soporta SOAP.
SOAP y XML Web Services utiliza Protocolo de transferencia de hipertexto (HTTP) y los
mecanismos de transporte y, además, proporciona una plataforma neutral más adecuado
para el tráfico con base en Internet, en comparación con tecnologías como DCOM. Sin
embargo, debido a las limitaciones de rendimiento posible, OPC XML-DA es poco
probable que se utilice para aplicaciones en tiempo real, a pesar de que normalmente se usa
de puente entre la empresa y la red de control.

Arquitectura Unificada OPC (OPC UA)

Refleja el objetivo de Microsoft de retirar DCOM en favor de .NET y arquitecturas

orientadas a servicio. OPC UA integra la funcionalidad de las anteriores especificaciones
(OPC DA, OPC-HDA, OPC A & E, OPC-DX, etc). OPC UA abandona COM / DCOM en
favor de dos transportes: SOAP / HTTP (S) y un mensaje binario codificado en la parte
superior de TCP. Es prematuro evaluar la seguridad de OPC UA en relación con DCOM,
ya que la API OPC UA de seguridad aún está en desarrollo. Sin embargo, dado que ahora
existe una mayor conciencia en la OPC Foundation, proveedores OPC, y Microsoft para la
necesidad de seguridad, hay poca duda de que .NET proporcionará una base más segura
que COM / DCOM. También hacen mucho más sencillo el desarrollo de clientes y
servidores OPC en plataformas que no sean de Microsoft.
Seguridad

 Existen tres niveles de seguridad OPC:

 Seguridad Inválida: Libre acceso entre Cliente/Servidor.

 Seguridad DCOM: Clientes seleccionados tienen acceso limitado a servidores OPC.
No hay un control total sobre sistemas operativos como Linux, Unix.
 Seguridad OPC: El Servidor OPC sirve como un regulador de control de acceso a
fabricantes de sistemas operativos como Linux y Unix sobre objetos específicos de
acceso restringido que son expuestos por el Servidor OPC.

Estándares OPC
OPC common

Definición de interfaces:

 IOPCShutdown: Desconexión de los clientes. Punto de conexión a través de la

interfaz IOPCShutdown.
 IConnectionPointContainer: Acceso al punto de conexión para la interfaz
IOPCShutdown.
 IOPCCommon:

 Usado por todos los servidores OPC independientemente de que pertenezcan a

una especificación u otra.
 Interfaz independiente con cada servidor.

 IOPCServerList: Determina el tipo de servidores disponibles en una máquina.