-Automatización de edificios

-Sostenibilidad
-Consultoría tecnológica
-Consultoría energética
-Tendencia de sistemas SCADAS bajo DSA
-Bases de datos
-Sistemas BMS
-Gestion de herramientos IoT
-DH+ y DF1 -> MINIDIN8
-DH 485 -> DB9
-ETHERNETH -> RJ-485 ESTANDAR RS-232
-Domótica, Urbotica e Inmotica
-Ciudades inteligentes (smartcites)
-Big Data
-Protocolos de comunicación abiertos
-Wireshark
-Redes integrales de automatización
-ISO/IEC 14908
-Sistema de Adquisición de Datos
-ISO50001
-Proyecto elétrico, ilumincación, cñimatización, ventilación forzada,
aguas sanitarias, suministro de ascensores, telecomunicación, CCTV
-Diagramas generales de red
-Memoria descriptiva
-Listado de control y matriz de responsabilidades

Estandares
-BACNET
-LONWORKS
-MODBUS

Sus aptitudes
-Gestión de proyectos
-Control de acceso
-Electronica
-Seguridad
-Building Automation
-IP CCTV
-Diseño e implementación de redes
-Instrumentación y control
-Programación en C
-RS 485, 232
-FieldServer Project Implementation
-LULOWIN
-RTU
-P2000

Modbus
Modbus es un protocolo de comunicaciones situado en el nivel 7 del Modelo OSI, basado en
la arquitectura maestro/esclavo (RTU) o cliente/servidor (TCP/IP), diseñado
en 1979por 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
[ocultar]

 1Versiones del protocolo

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

Versiones del protocolo[editar]

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[editar]

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[editar]
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 de

Función 8
bobinas/retención

Datos n×8 Datos + La longitud se rellenará dependiendo del tipo de 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

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

Datos n×2 Datos + La longitud se rellenará dependiendo del tipo de mensaje

LRC 2 Verificación de redundancia longitudinal (LCR)

 Par retorno de carro/avance de línea (CR/LF)
Fin 2
(Valores 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
(bits)

Identificador de la Para la sincronización entre mensajes de servidor

2
transacción y cliente

Identificador del protocolo 2 0 para Modbus/TCP

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ódigo de función 1 Códigos de función como en otras 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, p. 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[editar]
Todas las implementaciones presentan variaciones respecto al estándar oficial. Algunas de las
variaciones más habituales son:

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

Limitaciones[editar]
 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

KNX
Este artículo o sección necesita referencias que aparezcan en una publicación
acreditada.
Este aviso fue puesto el 6 de noviembre de 2013.

KNX-Logo
 KNX-Transceiver-Board de Elmos

KNX es un estándar (ISO/IEC 14543) de protocolo de comunicaciones de red, basado en OSI,

para edificios inteligentes (domótica e inmótica). KNX es el sucesor y la convergencia de tres
estándares previos: el European Home Systems Protocol (EHS), el European Installation Bus
(EIB o Instabus) y el BatiBUS pertenecientes, respectivamente, a la EHSA (European Home
Systems Association), la EIBA (European Installation Bus Association) y el BCI (BatiBUS Club
International).1 El estándar KNX está gestionado por la Asociación KNX.
Hasta enero de 2016, el texto de la especificación KNX debía ser adquirido previo pago de
una tarifa.2 Desde entonces, la especificación puede ser adquirida sin ningún tipo de cargo
asumiendo que el usuario tiene una cuenta gratuíta registrada en la web de la KNX
Association.3

Índice
[ocultar]

 1Historia
 2Protocolo
o 2.1Nivel Físico
 3Hardware
 4Presente y Futuro
 5Formación
 6Véase también
 7Enlaces externos
 8Referencias

Historia[editar]
Las especificaciones anteriores a KNX aparecieron a principios de los 90 de la mano de
Batibus, EIB y EHS. Estas tres soluciones para el control de viviendas y edificios en Europa,
intentaron al principio desarrollar sus mercados separadamente, tratando de hacerse un lugar
en la normalización europea. Batibus lo hizo especialmente bien en Francia, Italia y España,
mientras que EIB lo hizo en los países de habla alemana y norte de Europa. Por su parte, EHS
fue la solución preferida para fabricantes de productos de línea blanca y marrón.
En 1997 estos tres consorcios decidieron unir fuerzas con el declarado objetivo de desarrollar
conjuntamente el mercado del hogar inteligente, acordando crear una norma industrial común
que también podría ser propuesta como norma internacional. La especificación KNX fue
publicada en primavera de 2002 por la recién establecida KNX Association, logrando penetrar
lentamente en un mercado reticente como es la construcción a pesar de que es un sistema
muy robusto y fiable.4

Protocolo[editar]
La especificación está basada en la pila de comunicación de EIB completada con los
mecanismos de configuración, medios físicos y experiencia de aplicación originalmente
desarrollados por Batibus y EHS.5
KNX define varios medios de comunicación física:6

 Cableado de par trenzado (heredado de BatiBUS y EIB Instabus)

 Red eléctrica (heredado de EIB y EHS - similar al utilizado por X10)
 Radio (KNX-RF)
 Ethernet (también conocido como EIBnet/IP o KNXnet/IP)
Nivel Físico[editar]
TP: sobre par trenzado a 9600 bps. Además por estos dos hilos se suministra 30 Vdc para la
telealimentación de los dispositivos KNX. Usa la técnica CSMA/CA con arbitraje positivo del
bus que evita las colisiones evitando así los reintentos y maximizando el ancho de banda
disponible.
PL: en la red eléctrica, con corrientes portadoras sobre 230 Vac/50 Hz (powerline) a
1200/2400 bps. Usa la modulación SFSK (Spread Frequency Shift Keying) similar a
la FSK pero con las portadoras más separadas. La distancia máxima que se puede lograr sin
repetidor es de 600 metros. Este sistema actualmente ya no pertenece a los temas de
certificación y es muy importante recalcar que no es compatible con sistemas de alimentación
eléctrica a 110V/60Hz.
IP: usando el estándar Ethernet generalmente se utiliza como backbone entre segmentos,
líneas y áreas KNX además de permitir la transferencia de telegramas a través del protocolo
IP a ubicaciones remotas.
RF (Radiofrecuencia): usando varias portadoras, se consigue comunicación inalámbrica
utilizando el aire como medio de transmisión, esta tecnología logra comunicar distancias de
hasta 300 metros en campo abierto (condiciones ideales). Para mayores distancias o edificios
con múltiples estancias se pueden usar repetidores pero es recomendable para
comunicaciones de baja prioridad.

Hardware[editar]
KNX consta de básicamente 4 grupos de elementos:
ACTUADORES: Los actuadores son los elementos del sistema que se conectan físicamente
sobre los elementos a controlar en el edificio, por ejemplo las luces, electroválvulas, motores,
contactos secos, etc. y hacen la traducción de las instrucciones que viajan del mundo KNX al
mundo físico conmutado, regulando o accionando los dispositivos que son controlados.
SENSORES: Los sensores son los elementos del sistema que recogen datos o interpretan
órdenes del usuario, por ejemplo pulsador, botonera, detector de movimiento, termostato,
anemómetro, sensor crepuscular; muchos sensores incorporan visualizadores o pantallas
donde se controla y monitoriza el sistema, como las botoneras o pantallas táctiles.
PASARELAS: Las pasarelas (gateways o routers) enlazan otros sistemas con otros
protocolos de comunicación con KNX, por ejemplo de DALI, BACnet, LONWORKS, RS485, IP,
RS232, X10 etc. a KNX. Estos equipos permiten interaccionar con proyectores, otros sistemas
inteligentes o incluso comunicarse en remoto con el sistema.
ACOPLADORES: Estos elementos realizan una separación física dentro del bus consiguiendo
agrupar los dispositivos en un segmento de características determinadas para la cantidad de
equipos, ubicaciones físicas o funciones determinadas y conectarlo con otro segmento para
una mayor eficacia en el envío de datagramas a través del bus, alcanzar mayores distancias
(repetidores), además de darle un direccionamiento físico muy entendible utilizando la división
de Áreas, grupos y líneas.
SOFTWARE Distinguiremos el software en 2 tipos:
a) Software de gestión: El software de gestión, es decir el que usaremos para configurar los
dispositivos y ponerlos en marcha es el ETS (actualmente versión 5). Es un programa bajo
plataforma Windows que nos permite relacionar actuadores con sensores y traducir las
comunicaciones a través de las pasarelas. Esta herramienta es la única forma de configurar
los dispositivos KNX y es creada, suministrada y regulada únicamente por la KNX Association.
b) Software de control: Es el programa de cómputo que sirve para tener acceso a la
instalación para dotarnos de control y visualización desde un equipo de cómputo que puede
tener varias funciones. • Visualizar el estado de los elementos. • Controlar la instalación. •
Registrar los eventos. • Generar reportes y eventos. • Crear funciones lógicas. • Servir y dotar
información a otros sistemas (interfaz o pasarela). • Ejecutar funciones de diagnóstico,
escenas y rutinas de comprobación. • Otorgar acceso a otras plataformas o métodos de
acceso a los sistemas KNX.

Presente y Futuro[editar]
PRESENTE: En la actualidad este tipo de instalaciones se realizan principalmente en edificios
de oficinas e industriales para una gestión de energías y automatización de sistemas y en las
viviendas para el confort y como tecnología asistiva para ancianos y discapacitados. A pesar
que en los últimos años ha bajado de precio de sus elementos, el sistema encarece el precio
final de la instalación, aunque a la larga puede otorgar una reducción de consumo eléctrico si
la configuración del sistema es eficiente.
FUTURO: Se están diseñando las bases para posiblemente cambiar el bus o encapsularlo
dentro del protocolo TCP/IP esto es: KNX/IP. Esto es debido a que el citado protocolo ha ido
estandarizándose y absorbiendo buses y protocolos de otros sistemas (CCTV, VOZ
ANALÓGICA, etc.). También el crecimiento, implantación y estandarización de TCP/IP hace
que esta opción se pueda convertir en el diseño final de KNX, siendo un elemento más cada
equipo de este sistema dentro de las redes IP, es decir, conectaríamos los equipos
directamente a ethernet y a través del enrutador típico de conexión a Internet podríamos
gestionar y monitorizar externamente los sistemas, también nuestros equipos WiFi instalados
en el edificio nos darían acceso al sistema de una manera cómoda y con dispositivos estándar
(móviles, tabletas, ordenadores, etc.). A diferencia del sistema actual que necesita
pasarelas IP, los propios equipos "hablarían" directamente en IP, simplificando las
instalaciones pues el cableado más usado hoy es el cableado UTP dado a la implantación ya
estandarizada de TCP/IP desde hogares pequeños hasta grandes empresas.

Formación[editar]
Existe una formación estandarizada en todo el mundo que concede la certificación KNX
Partner. Desde la página de la Asociación KNX http://www.knx.org/knx-partners/training-
 centres/list/ puede accederse a un listado de todos los centros de formación que imparten
dicha formación en el mundo.

BACnet
BACnet (de Building Automation and Control Networks) es un protocolo de comunicación de
datos diseñado para comunicar entre sí a los diferentes aparatos electrónicos presentes en los
edificios actuales (alarmas, sensores de paso, Aire Acondicionado, Calefactores...)
Originalmente diseñado por la ASHRAE actualmente es también un estándar de
la ISO y ANSI.
El protocolo BACnet define una serie de servicios usados para intercomunicar dispositivos de
un edificio. El protocolo incluye los servicios Who-Is, I-am, Who-Has y I-Have, utilizados para
la detección de Objetos y Dispositivos. Otros servicios como Read-Property y Write-Property
son usados para la lectura o escritura de datos.
Permite el control desde una central de todos los dispositivos de un edificio de grandes
dimensiones.
Es el ISO 16484-5:2007(E).

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

Índice
[ocultar]

 1Propósito
 2Ventajas
 3Problema y solución OPC
 4Situación
 5Arquitectura
o 5.1Arquitectura OPC cliente/servidor
 6Bases de OPC
 o 6.1Objetos e interfaces
o 6.2Acceso de Datos OPC
o 6.3Gestión de Alarmas y Eventos
o 6.4Acceso a Datos Históricos
 7Aplicaciones OPC
 8Arquitectura General y Componentes
o 8.1Servidores locales y remotos
 8.1.1Servidor de Acceso a Datos OPC (OPC DA)
 8.1.2Servidor de Alarmas, Condiciones y Eventos OPC (OPC AE)
 8.1.3Servidor de Acceso a Datos Históricos OPC (OPC HDA)
o 8.2Intercambio de Datos OPC (OPC DX)
o 8.3Acceso de Datos XML (OPC XML DA)
o 8.4Arquitectura Unificada OPC (OPC UA)
o 8.5Seguridad
 9Estándares OPC
o 9.1OPC common
 10Enlaces externos

Propósito[editar]
Las aplicaciones necesitan una manera común de acceder a los datos de cualquier fuente,
como un dispositivo o una base de datos.

Ventajas[editar]
 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[editar]

El problema sin tecnología OPC.

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

Situación[editar]
Con OPC, la integración de sistemas en un entorno heterogéneo se tornará simple.
Arquitectura[editar]
Arquitectura OPC cliente/servidor[editar]
Bases de OPC[editar]
Objetos e interfaces[editar]
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[editar]

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[editar]
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[editar]
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[editar]
 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[editar]
 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[editar]

 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)[editar]

 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)[editar]

 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)[editar]
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)[editar]
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)[editar]
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)[editar]
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[ed
itar]

 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ánda
res
OPC[edit
ar]
OPC
common[
editar]
Definición
de
interfaces:

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

del interfaz IOPCShutdown.
 IConnectionPointContainer: Acceso al punto de conexión para la interfaz
IOPCShutdow.
 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.

V