Protocolos de Comunicacion

INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA

MECANICA Y ELÉCTRICA
DISEÑO DE SOFTWARE EN VISUAL BASIC PARA

MONITOREO DE CONTROLADORES DIGITALES POR
OPC
T E S I S
QUE PARA OBTENER EL TITULO DE
INGENIERO EN CONTROL Y
AUTOMATIZACIÓN.
P R E S E N T A N :
ANGELES TANIA JUÁREZ SÁNCHEZ
FERNANDO OLIVERA CAUDILLO
LUIS ALFREDO MUÑOZ SALAS.
JAJASJ
OOOO
ASESOR: ING. RICARDO HURTADO RANGEL
MÉXICO, DISTRITO FEDERAL 2010

INGENIERÍA EN CONTROL Y AUTOMATIZACIÓN
“DISEÑO DE SOFTWARE EN VISUAL BASIC PARA MONITOREO DE CONTROLADORES DIGITALES POR OPC”
1
Al Ingeniero Ricardo Hurtado Rangel nuestro asesor de tesis, por confiar en nosotros darnos su
apoyo y conocimiento y por su compromiso desinteresado a lo largo de este proyecto.
Al Ingeniero José Luis Arias Ortiz por todas las oportunidades, facilidades, consejos y experiencia
gracias a las cuales he concluido de manera exitosa una etapa más en mi vida.
Son muchas las personas a las que me gustaría agradecer su cariño, apoyo,
ánimo y compañía en las diferentes etapas de mi vida. Algunas están aquí
conmigo y otras en mis recuerdos y en mi corazón. Sin importar en donde
estén quiero darle las gracias por formar parte de mí, por todo lo que han
brindado y por todas sus bendiciones.
A mi MADRE por mostrarme el valor de la familia, porque gracias a sus cuidados, atenciones y
consejos me han permitido culminar un ciclo más en mi vida, Mami tu esfuerzo, se convirtió en tu
triunfo y el mío, TE AMO.
A mi PADRE por su ejemplo, apoyo económico y emocional, por las noches de desvelo y los
consejos en todos mis proyectos porque me has mostrado que nos podemos levantar de las
adversidades por más fuertes que sean, porque gracias a tu esfuerzo nos permitiste tener a mi
madre tan cerca de nosotros.
A mi HERMANO por la compañía y apoyo que me has brindado en momentos difíciles, por las risas,
consejos, por ser partícipe de mi vida gracias Enano porque sé que siempre contaré contigo.
A mi ABUELITA IRENE por brindarme su cariño y dejarme conocer un cariño diferente.
A ALE por su apoyo y comprensión por compartir mis alegrías y tristezas y enseñarme un cariño
sincero, desinteresado por su tolerancia y por persistir y no dejar que el cariño que nos tenemos se
acabe.
A todos, mis tíos, primos y sobrinos que han estado en este gran recorrido de mi crecimiento como
persona y en la culminación de mis estudios.
Mi admiración, gratitud y reconocimiento a mis compañeros de tesis Fernando y Luis quienes

estuvieron conmigo durante toda la carrera y a lo largo del desarrollo de este proyecto que ahora
culminamos, brindándome su amistad y apoyo.
Ángeles Tania Juárez Sánchez
2
A mis padres como un humilde homenaje por el apoyo y comprensión que siempre me
han brindado, que con su sacrificio guiaron mi camino e hicieron posible llegar a esta
meta.
A mis hermanos que una vez que he seguido sus consejos y apoyo moral he podido llevar
conmigo siempre su ejemplo de superación en la vida y crear un camino lleno de
oportunidades.
A mis amigos que con su gran apoyo y comprensión me han podido sacar de apuros y he
tenido una gran convivencia agradable.
Al Instituto Politécnico Nacional, en particular a la Escuela Superior de Ingeniería

Mecánica y Eléctrica Unidad Zacatenco, que ha sido una gran escuela que me ha
proporcionado los conocimientos necesarios para ser útil en la sociedad y los maestros
agradeciéndoles las atenciones que me presentaron y sus desinteresados consejos.
Fernando Olivera Caudillo
3
Al término de esta etapa de mi vida, quiero expresar un profundo agradecimiento a

quienes con su ayuda y comprensión me alentaron a terminar mi carrera profesional. A
mis padres, quienes sin escatimar esfuerzo alguno, han sacrificado gran parte de su vida
para formarme y educarme. Por esto y más… Gracias.
Así mismo agradezco a los maestros y compañeros que me ayudaron a entender las
bases de teoría fundamentales que permiten la solución de problemas y al mismo tiempo
son la respuesta a preguntas planteadas a lo largo de la historia.
Luis Alfredo Muñoz Salas
4
CONTENIDO
Glosario ........................................................................................................................... 10
Objetivo General. ............................................................................................................. 13
Objetivos Específicos ...................................................................................................... 13
Resumen ......................................................................................................................... 14
Introducción. .................................................................................................................... 15
Problema ......................................................................................................................... 16
Alcance. ........................................................................................................................... 17
Justificación. .................................................................................................................... 18
Aportaciones.................................................................................................................... 20
Estructura De La Tesis. ................................................................................................... 21
I. “TECNOLOGÍA DE COMUNICACIÓN ENTRE APLICACIONES EMPLEADAS EN LA
SUPERVISIÓN DE PROCESOS” .................................................................................... 22
1.1 Activex. .............................................................................................................. 23
1.1.1 En El Cliente. ................................................................................................... 23
1.1.2 En El Servidor. ................................................................................................. 23
1.1.3 Guiones ActiveX. ............................................................................................. 23
1.1.4 Ventajas, Desventajas Y Riesgos .................................................................... 24
1.2 Dynamic Data Exchange (DDE) (Intercambio Dinámico de Datos). ........................ 25
1.2.1 Utilización DDE ................................................................................................ 25
1.2.2 Windows, Cliente, Servidor. ............................................................................. 26
1.2.3 Protocolo. ........................................................................................................ 26
1.2.4 Elementos De Conversación. ........................................................................... 26
1.3 Open Data Base Conectivity (ODBC) (Conectividad De Base De Datos Abierta). .. 27
1.3.1 La Interfaz. ....................................................................................................... 29
1.3.2 ODBC define dos tipos de drivers. ................................................................... 30
1.3.3 Estructura Del ODBC. ..................................................................................... 31
1.4 Protocolos De Comunicación. ................................................................................ 31
1.4.1 Componentes de las Redes Industriales .......................................................... 32
1.4.2 RS-232. ........................................................................................................... 33
1.4.3 Ethernet. .......................................................................................................... 35
1.5 Tecnología OPC. .................................................................................................... 37
1.5.1 Historia del OPC .............................................................................................. 37
5
1.5.2 OLE FOR PROCESS CONTROL (OPC) ......................................................... 38

1.5.3 Problemática y solución en la comunicación driver / aplicación........................ 42
1.5.4 Arquitectura. ................................................................................................... 43
1.5.5 Tipos de datos y características en OPC. ....................................................... 45
1.5.6 Funcionamiento de OPC. ................................................................................ 46
II. “HARDWARE Y SOFTWARE PARA SISTEMAS DE CONTROL DIGITAL” ................. 47
2. Evolucion de los sistemas de control .......................................................................... 48
2.1. Controlador lógico programable “PLC” .................................................................. 49
2.1.1. Antecedentes. ................................................................................................. 49
2.1.2. ¿Qué es un controlador lógico programable? ................................................. 50
2.1.3. Arquitectura de un plc convencional ............................................................... 50
2.1.4. Ciclo de trabajo del PLC ................................................................................. 51
2.1.5 Ventajas del PLC ............................................................................................. 52
2.2 Sistema de Control Distribuido (SCD). ................................................................... 54
2.2.1. Antecedentes Históricos. ................................................................................ 54
2.2.2. Arquitectura típica del DCS. ............................................................................ 54
2.2.3. Componentes de hardware (equipos). ............................................................ 57
2.3. SCADA (supervisory control and data acquisition) ................................................ 59
2.3.1. Origen y evolución. ......................................................................................... 59
2.3.2. El sistema SCADA. ......................................................................................... 61
2.3.3 Objetivos de un SCADA. .................................................................................. 62
2.3.5. El control a distancia. ...................................................................................... 63
2.4 Visual Basic 6.0. .................................................................................................... 64
2.4.1 El entorno de Programación Visual Basic 6.0 .................................................. 64
2.4.2 Ventajas........................................................................................................... 66
2.5 RSLOGIX 5000 ...................................................................................................... 66
III. “DISEÑO Y PUESTA EN MARCHA DEL SOFTWARE DE SUPERVISIÓN
COMUNICADO MEDIANTE TECNOLOGÍA OPC”........................................................... 67
3.1 Herramientas a utilizar ........................................................................................... 68
3.2 Descripción del Proceso a conrolar ........................................................................ 69
3.2.1 Diagrama de Tuberias y Instrumentación ......................................................... 71
3.3 Estrategia de Control.............................................................................................. 72
3.3.1 Control Autómatico .......................................................................................... 72
3.4 Lógica demostrativa para el control de Proceso ..................................................... 73
3.4.1 Consideraciones para el desarrollo de la lógica. .............................................. 73
6
3.4.2 Diagrama de escalera en RSlinks 5000. .......................................................... 77

3.5 Diseño de la interfaz Gráfica para el monitoreo y control de nivel. ......................... 78
3.5.1 Estructura ........................................................................................................ 79
3.5.2 Código programado ......................................................................................... 85
3.5.3 Algoritmo integrado a la ihm para la conectividad por opc ............................... 87
3.6 Puesta en marcha del sistema ............................................................................... 92
3.6.1 Funcionamiento en modo manual .................................................................... 92
3.6.1 Funcionamiento en modo automático .................................................................. 99
IV. “ANÁLISIS COSTO BENEFICIO DEL PROYECTO”................................................. 106
4. Análisis Costo – Beneficio.......................................................................................... 107
4.1 Tiempos En la Realización Del Proyecto ............................................................. 108
4.2 Comparación con un Sistema SCADA Comercial................................................. 109
Conclusiones Y Recomendaciones................................................................................ 111
Bibliografia ..................................................................................................................... 112
Apéndice A. Diagrama Escalera Rslogix5000. ............................................................... 114
Apéndice B. Código Fuente De La Interfaces Y Enlace Opc (Visual Basic). .................. 118
Apéndice C. Diagrama De Tuberías E Instrumentación. (Dti). ...................................... 126
Apéndice D. Especificaciones Tecnicas Del PLC Compaclogix L32E .......................... 127
7
Contenido de Figuras
Figura 1. Tecnologías de software _______________________________________________________ 22
Figura 2. Aplicación ODBC. _____________________________________________________________ 29
Figura 3. Ejemplos de RED. ____________________________________________________________ 30
Figura 4. Transmisión de datos. _________________________________________________________ 33
Figura 5.Integración de datos en OPC. ___________________________________________________ 39
Figura 6. Sistema abierto con servidores OPC. ____________________________________________ 40
Figura 7. Diagrama cliente-servidor OPC. ________________________________________________ 40
Figura 8. Organización de los datos en un servidor OPC. ___________________________________ 41
Figura 9. Problema OPC _______________________________________________________________ 43
Figura 10. Solución OPC. _______________________________________________________________ 43
Figura 11. Arquitectura Cliente / Servidor. ________________________________________________ 44
Figura 12. “n” de grupos. _______________________________________________________________ 44
Figura 13. Diseño de un servidor OPC. ___________________________________________________ 45
Figura 14. Arquitectura de un PLC convencional. __________________________________________ 51
Figura 15. Ciclo de Trabajo del PLC. _____________________________________________________ 52
Figura 16. Dimensiones del PLC CompactLogix LE32E ____________________________________ 53
Figura 17. División de los sistemas de control avanzado ___________________________________ 54
Figura 18. Principales componentes de un SCD __________________________________________ 56
Figura 19. Medida a distancia. ___________________________________________________________ 63
Figura 20. Entorno de programación de visual Basic _______________________________________ 65
Figura 21. Ejemplo de control en una caldera _____________________________________________ 70
Figura 22. DTI para el control de nivel en la caldera _______________________________________ 71
Figura 23. Ventana principal ____________________________________________________________ 82
Figura 24.Ventana para selección de modo de control _____________________________________ 83
Figura 25.Ventana de válvula de llenado _________________________________________________ 84
Figura 26.Ventana de medidor de flujo ___________________________________________________ 85
Figura 27. Configuración del driver ______________________________________________________ 88
Figura 28. Configuración de un OPC Topic _______________________________________________ 89
Figura 29. Vínculos DDE/OPC de las variables en de control _______________________________ 90
Figura 30. Estado inicial de la interfaz ____________________________________________________ 93
Figura 31. Estado inicial del controlador de proceso _______________________________________ 94
Figura 32. Ventana de selección de modo de control. ______________________________________ 95
Figura 33. Estado inicial Del mando de la válvula __________________________________________ 95
Figura 34. Válvula FV-16 abierta manualmente____________________________________________ 96
Figura 35. Demanda de vapor ___________________________________________________________ 96
Figura 36. Forzado de cierre de la válvula ________________________________________________ 97
Figura 37. Exportación de las variables de proceso a Excel _________________________________ 98
Figura 38. Forzado del apagado de los quemadores _______________________________________ 99
Figura 39. Activación del modo automático de control _____________________________________ 100
Figura 40. Aplicación de la nueva histérisis ______________________________________________ 100
Figura 41. Nivel bajo en la caldera ______________________________________________________ 101
Figura 42. Límite superior establecido ___________________________________________________ 102
Figura 43. Nivel disminuyendo en modo automático ______________________________________ 102
Figura 44. Límite inferior establecido ____________________________________________________ 103
Figura 45. Vapor de salida en modo automático __________________________________________ 103
Figura 46. Mando de la válvula durante modo automático _________________________________ 104
Figura 47. Habilitación de envío de datos a Excel ________________________________________ 105
Figura 48. Exportación de datos durante la prueba _______________________________________ 105
8
Contenido de Tablas
Tabla 1 Conexiones del pin _______________________________________________________ 34

Tabla 2. Conexiones cable Ethernet. ________________________________________________ 36
Tabla 3.Objetos de Modelos. ______________________________________________________ 42
Tabla 4. Tipos de Fabricante y Software. ____________________________________________ 60
Tabla 5. Elementos utilizados en en desarrollo del proyecto. _____________________________ 69
Tabla 6. Tipos de variables utilizadas durante la programación. ___________________________ 85
Tabla 7 Costo de Material y Equipo. _______________________________________________ 107
Tabla 8. Relación de tiempo y costo del proyecto _____________________________________ 108
Tabla 9. Costo Total de proyecto _________________________________________________ 108
9
GLOSARIO
ASP: Active Server Pages es una tecnología de Microsoft del tipo "lado del servidor"
para páginas web generadas dinámicamente.
Choque térmico: un colapso térmico o choque térmico se refiere al rompimiento de algún

material al sufrir un cambio drástico de temperatura, es cuando un material sólido se
quiebra al someterse a un brusco aumento o descenso de la temperatura.
COM: Modelo de objetos componentes.
CPU: Unidad de control de Procesos.
DBMS: Sistemas de Gestión de Bases de Datos.
DCOM: Modelos de objetos componentes Distribuido.
DDE: Intercambio Dinámico de Datos.
DLL: Librerías de unión dinámico.
DTI: Diagrama de Tuberías e Instrumentación.
Golpe de ariete: El golpe de ariete es una gran fuerza destructiva que puede presentarse
en cualquier sistema de bombeo, cuando en este el caudal (gasto) cambia
repentinamente de un momento a otro cualquiera que sea la causa.
Histerisis: La diferencia, en términos porcentuales (%), de la distancia de detección

nominal entre la operación (encendido) y el punto de liberación (apagado) cuando el
objeto se aleja de la cara activa de los sensores.
10
Inteligible: Que puede ser comprendido.
LAN: Red de Área Local.
NEMA: Asociación Nacional de Fabricantes de Normas Eléctricas.
ODBC: Conectividad de Base de Datos Abierta.
Ofimático: Todo lo relacionado a oficina.
OLE: Vinculación e Inserción de Objetos.
OPC: OLE para control de procesos.
PLC: Controlador Lógico Programable.
Polimorfismo: Propiedad de ciertos cuerpos que pueden cambiar de forma sin variar su
naturaleza.
SCADA: Sistema de Registro de datos y control de supervisión.
SCAP: Sistema de Control Avanzado de Procesos.
SCD: Sistema de Control Distribuido.
Sistema Operativo Multipuesto: Un sistema operativo es multipuesto o multiusuario

cuando permite la conexión de varios puestos de trabajo desde los que operar
concurrentemente, utilizando una única C.P.U. y un único sistema operativo. Un sistema
operativo es multipuesto o multiusuario cuando permite la conexión de varios puestos de
trabajo desde los que operar concurrentemente, utilizando una única C.P.U. y un único
sistema operativo.
11
Sistema Operativo Monopuesto: Decimos que es monopuesto o monousuario cuando

estamos ante un modo de ejecución que solo admite un usuario en el ordenador, o lo que
es lo mismo un usuario por cada sistema operativo instalado.
SQL: Lenguaje de consulta estructurado.
TCP/IP: Transmisión Control Protocol / Internet Protocol.
Telemetría: Sistema de medida de magnitudes físicas en lugares difícilmente accesibles,

que permite transmitir el resultado de la medición a un observador lejano
VB: Visual Basic.
12
OBJETIVO GENERAL.
Diseñar software de aplicación en Visual Basic para adquisición de datos de

controladores digitales utilizando tecnología OPC.
OBJETIVOS ESPECÍFICOS
- Explicar las diferentes tecnología de comunicación entre aplicaciones empleadas en

la supervisión de procesos, como son: Active x, DDE (Dynamic Data Exchange),
ODBC (Open Database Conectivity), OPC (OLE for process control), para la
obtención de adquisición de datos mediante estas tecnologías.
- Presentar el hardware y software para sistemas de control digital abordando
conceptos de Controlador Lógico Programable (PLC), Sistema de control distribuido
(SCD), Sistemas de Adquisición de Datos (SCADA), y el lenguaje de programación
Visual Basic. Herramientas que serán útiles para la realización de esta tesis.
- Diseñar el desarrollo de un software capaz de adquirir datos desde un controlador
digital Compactlogix Allen-Bradley por medio de OPC, así como la muestra de una
interfaz gráfica en Visual Basic a través de imágenes dinámicas que permiten la
visualización de los parámetros en el controlador encargado de mantener el
adecuado nivel de agua una caldera.
- Realizar el análisis costo beneficio del proyecto, haciendo una cotización, para
obtener la utilidad de dicha aplicación en la industria y su beneficio.
13
RESUMEN
En esta tesis se muestra el diseño de un software para adquirir datos desde un

controlador digital CompactLogix Allen Bradley utilizando tecnología OPC (OLE para
control de procesos), así como el diseño de una interfaz gráfica en Visual Basic, que
permite a través de imágenes dinámicas la visualización de los parámetros del
controlador para el control, adquisición y supervisión de datos, encargado de tener el
nivel apropiado de una caldera.
La comunicación se realiza a través de Ethernet ya que brinda una gran velocidad en

comparación con la RS-232, al utilizarla se logro un monitoreo más exacto y con mayor
claridad de animación haciéndolo más eficiente.
Se realiza un análisis costo-beneficio del proyecto, donde se identifica las estimaciones

económicas reales atribuibles al proyecto proporcionando información valiosa para la
toma de decisiones resaltando las ventajas que éste otorga
14
INTRODUCCIÓN.
ANTECEDENTES
El intercambio de información entre aplicaciones y computadoras comienza con Microsoft

Windows y con otro nombre: DDE. La tecnología de intercambio Dinámico de Datos
(DDE. Dynamic Data Exchange ) permite que cualquier aplicación, basada en Windows,
pueda intercambiar información con otra aplicación diferente (por ejemplo, un sistema de
visualización y una hoja de Cálculo). [14]
Wonderware Corporation, el primer proveedor de un sistema Scada basado en Windows,

ya utilizó entonces DDE como estándar de intercambio de datos de control de
aplicaciones. Lo mejoró con FastDDE, que ya permitía el intercambio de bloques de
Información, manteniéndose en el ranking de las comunicaciones por muchos años.
Rockwell Software hizo algo parecido con AdvanceDDE. Estas dos posibilidades son
accesibles mediante paquetes de herramientas proporcionados por los proveedores, pero
las especificaciones de funcionamiento son propietarias y no son del dominio público.
OLE 1.0 aparece con las versiones 2 y 3 de Microsoft Windows. Por aquel entonces los
ordenadores aún tenían que superar la barrera de los 640Kb de memoria RAM, y lo de
hacer funcionar más de una cosa al mismo tiempo aún daba dolores de cabeza.
OLE 2.0 mantenía la idea del documento tipo Cajón de Sastre; formatos diferentes de
datos dentro de un mismo contenedor. Aquí apareció por primera vez el concepto de
Objetos Comunes (COM, Common Object Model), creándose un estándar para los
objetos OLE y otros conceptos. OLE 2.0 presentó un estándar para el tratamiento de
objetos. De esta manera, los integradores de software no necesitan conocer las
aplicaciones destinatarias de sus objetos. Por lo tanto este trabajo nace, con la idea de
generar un software de aplicación que pueda integrar diferentes tecnologías de hardware
y software. Para que en un futuro cercano se pueda vender y explotar para el beneficio
técnico y económico. Propio como desarrollo de ingeniería.[9]
15
PROBLEMA
¿Para qué realizar un software de adquisición de datos mediante OPC?
En un sistema de automatización hay múltiples elementos de control y monitorización,

cada uno con su protocolo de comunicaciones específico (modbus, AS-i, Ethernet,
RS232, etc.) y con un sistema operativo propio tal como DOS, UNIX, Linux o Windows,
con sus propias características. Cada conexión significa un programa exclusivo dedicado
al diálogo entre el controlador y la interfaz.
Cada fabricante proporciona este programa controlador de comunicaciones o driver que

comunica su producto con un equipo determinado. El acceso a los datos se hace de
forma oscura, sin acceso por parte del usuario. La interfaz se ocupa de convertir los datos
del equipo en datos útiles para el sistema de control o captación.
El problema implícito en este método es que, para cualquier ampliación o modificación del
sistema, debemos dirigimos al fabricante del equipo para que realice las modificaciones
necesarias en el driver o desarrolle uno nuevo. Todo ello implica una duplicación de
esfuerzos, debido a los cambios obligados de hardware o software, de la misma forma
presenta conflictos de acceso ya que generalmente, dos programas no pueden acceder
simultáneamente al mismo dispositivo puesto que poseen drivers independientes.
16
ALCANCE.
El software desarrollado en Visual Basic para integrar y gestionar datos como se hace en
un SCADA, tiene los siguientes alcances.
 Se programo en el controlador digital la lógica necesaria para la simulación de

control de nivel de una caldera.
 Se desarrollaron los componentes de la interfaz con características como
animación mediante componentes active-x, posibilidad de transferir información a
Excel.
 Dentro de la interfaz se integro el código de programación necesario para la
comunicación, esto mediante el desarrollo de la estructura OPC.
 La interoperabilidad que brinda OPC permite hablar sobre la casi total reutilización
del software desarrollado, ya que los cambios necesarios al migrar de un sistema
de control de una marca a otra son mínimos. El cambio de código en la forma de
acceso a las variables del controlador es el cambio más significativo que sufriría el
código de programación.
17
JUSTIFICACIÓN.
En los últimos años se han producido una serie de cambios significativos en tecnologías
claves en el campo del control. Estas se refieren sobre todo a la disponibilidad directa de
las mediciones de campo a través de buses de campo y sistemas de control distribuido,
algoritmos de control, hardware avanzado, etc.
Todo esto hace necesario que el intercambio de datos de los dispositivos de campo sea
cada día indispensable, hasta ahora cuando una aplicación requería el acceso a un
elemento de control, se necesitaba el desarrollo de controladores o drivers de forma
independiente o específica lo que implicaba:
 Duplicación de esfuerzos: todos los programas necesitan un driver para un
determinado hardware.
 Falta de consistencia entre drivers: hay características del hardware no soportadas
por todos los drivers.
 Cambios en el hardware: hacen que los drivers queden obsoletos.
 Conflictos de acceso: generalmente, dos programas no pueden acceder
simultáneamente al mismo dispositivo puesto que poseen drivers independientes.
Los fabricantes de hardware no pueden desarrollar un driver eficiente utilizable por todos
los clientes debido a las diferencias de protocolos entre clientes.
La tecnología OPC (Object Linking and Embedding (OLE) for process control) permite
facilitar un mecanismo para extraer datos de una fuente y comunicarlos a cualquier
aplicación cliente de manera estándar, además los servidores OPC tiene una fácil
integración en aplicaciones en Visual Basic, Excel, Access, etc. No necesitan
herramientas especiales para su desarrollo. Por todo ello la tecnología OPC nos ofrece
las siguientes ventajas:
 Reducción de tiempo y costos de integración de sistemas más bajos
 Facilidad de integración (conectividad simplificada)
 Facilidad de conexión e interoperabilidad de aplicaciones
 Eliminación de bloqueos propietarios
 Acceso a los datos por cualquiera en la jerarquía de automatización
18
 Facilidad de uso
 Menores costos de mantenimiento
 No obsolescencia
El objetivo de desarrollar un software en Visual Basic usando la tecnología OPC es crear
una interfazs, de modo que sea un programa cliente que se pueda conectar con cualquier
OPC-server. Visual Basic es actualmente el lenguaje de programación utilizado en todo el
mundo debido a las ventajas que éste ofrece tales como economía, fácil aprendizaje
facilitando una interfaz visual al mismo tiempo puede ser capaz de crear potentes
aplicaciones a través de su lenguaje.
Desarrollar una aplicación OPC por medio de Visual Basic permitirá crear infinidad de
aplicaciones con una única licencia sin limitaciones en el número de variables.
La intención de su desarrollo no es por ningún motivo competir con un software SCADA
sino crear otra alternativa que permita establecer comunicación a cualquier aplicación
cliente de manera sencilla y mucho menos costosa ya que comúnmente los sistemas
SCADA son demasiado grandes, soliendo utilizar miles de etiquetas (entradas /salidas),
haciéndolo un software costoso, además de ser sobrado para algunos procesos que solo
requieren de escasas aplicaciones.
Teniendo en cuenta que la solución brindada a través de la generación de un software
OPC deberá reducir el período de desarrollo y costos de entrenamiento asociados con el
tiempo que toma aprender diferentes paquetes para cubrir las especificaciones finales del
sistema.
19
APORTACIONES.
Este trabajo presenta una aplicación de un sistema como lo es OPC, se presenta el

diseño de un programa cliente mediante el lenguaje de programación Visual Basic, la
aplicación obtendrá información de los dispositivos de control, al ser capaz de interrogar a
los servidores para obtener los datos solicitados por el usuario mediante la interfaz gráfica
(PC).
Al tener en nuestro sistema de control una interfazs estándar gracias a los servidores
OPC, se podrá obtener información de cualquier controlador digital (Siemens, Moller,
Allen Bradley, Mitsubishi, etc.) que cuente con un servidor.
El diseño de este software está orientado a mostrar de manera práctica una solución al
problema de la falta de interoperabilidad entre dispositivos de control, aunque el grado de
estandarización actual no permite hablar de sistemas totalmente abiertos ya que un
sistema abierto debe permitir al usuario unir en una misma aplicación los componentes de
hardware y software de distintos fabricantes que más se ajusten a sus necesidades
particulares.
20
ESTRUCTURA DE LA TESIS.
El presente trabajo escrito está estructurado en 4 capítulos, logrando así una mejor
organización de la información. Una breve descripción del contenido de los mismos se
detalla a continuación.
Capítulo I. Trata sobre las diferentes tecnologías basadas en la plataforma Microsoft

Windows, mostrando la teoría necesaria para el entendimiento del trabajo aquí
desarrollado.
Capítulo II. Se dan los diferentes hardware y software que se encuentran en la aplicación
de sistemas de control, mostrando las herramientas que se pueden utilizar en el proyecto
desplegado.
Capítulo III. Se desarrolla de una forma muy completa cada uno de los pasos que se
llevaron a cabo para la realización de la Interfaz Hombre Máquina y su descripción de
funcionamiento, mostrando los elementos constitutivos de cada pantalla y cada variable
que se conjunta.
Capítulo IV. Trata sobre los costos del proyecto. Aquí se desglosan todas las partidas
necesarias para la elaboración del costo total del proyecto, además de una comparación
de un sistema completo con respecto a un sistema desarrollado para una aplicación de un
solo proceso.
Y finalmente se encuentran los Apéndices, en donde se tiene el código de la

programación de los diferentes algoritmos de control y de la recepción y envío de datos de
la comunicación por medio de Ethernet.
21
I. “TECNOLOGÍA DE COMUNICACIÓN ENTRE APLICACIONES EMPLEADAS EN LA

SUPERVISIÓN DE PROCESOS”
En este capítulo se hablara sobre las diferentes tecnologías de software que existen para
la supervisión de procesos tales como lo son: ACTIVEX, DDE (DYNAMIC DATA
EXCHANGE), ODBC (OPEN DATABASE CONECTIVITY), LOS PROTOCOLOS DE
COMUNICACIÓN, OPC (OLE FOR PROCESS CONTROL), como se muestra en la figura
No.1.
Figura 1. Tecnologías de software
22
A continuación se desarrollan los conceptos de cada uno de estos dando un panorama

generalizado. Posteriormente se profundiza en la tecnología OPC dando sus
complementos y funcionamientos.
1.1 ACTIVEX.
ActiveX es un marco para definir los componentes de software reutilizables (conocidos

como controles) que realizan una función en particular o un sistema de funciones en
Microsoft Windows de una manera que sea independiente del lenguaje de programación
usado para ejecutarlos.
ActiveX es una tecnología de Microsoft para el desarrollo de páginas dinámicas. Tiene

presencia en la programación del lado del servidor y del lado del cliente, aunque existan
diferencias en el uso en cada uno de esos dos casos.
1.1.1 EN EL CLIENTE.
Son pequeños programas que se pueden incluir dentro de páginas web y sirven para
realizar acciones de diversa índole. Por ejemplo hay controles ActiveX para mostrar un
calendario, para implementar un sistema de FTP, etc.´
Los controles ActiveX son particulares de Internet Explorer.
1.1.2 EN EL SERVIDOR.
También existen controles ActiveX del servidor y la gente que conozca ASP seguro que
los utiliza ya, aunque sea sin darse cuenta.
Por ejemplo, cuando realizamos una conexión con una base de datos, estamos utilizando
un control ActiveX del servidor.
1.1.3 GUIONES ACTIVEX.

Un guión es una secuencia de instrucciones que se van ejecutando secuencialmente. Si
adaptamos esta definición para los guiones ActiveX, se entiende como un mecanismo
para enlazar rápidamente un conjunto diverso de componentes.
ActiveX se basa en dos componentes: un host de guiones y un motor de guiones. [11]
23
 El host es la aplicación que crea el motor. Ejemplos de hosts son Internet Explorer
y FrontPage.
 El motor procesa y ejecuta los comandos de guión. Ejemplos de motores son el
conjunto de lenguajes como VBScript, JSCript, Perl, Tcl/Tk, etc.
 Los guiones los encontramos embebidos dentro de código HTML.
1.1.4 VENTAJAS, DESVENTAJAS Y RIESGOS
1.1.4.1 VENTAJAS
Fácil de utilizar. Siempre que visite una página Web que utiliza un control ActiveX, Internet
Explorer comprobará automáticamente si dispone del control necesario instalado en el
sistema.
Si no es así, lo instalará. Además, a diferencia de otras aplicaciones de tipo
“complemento”, los controles ActiveX están ahí sólo cuando los necesita y no ocupan
valiosos recursos cuando no los necesita.
Mayor acceso a sitios mejores. Los controles ActiveX abren infinitas posibilidades de
agregar nuevo contenido al Web.
Cada control ActiveX contiene una firma digital, que permite comprobar la procedencia del
código recibido, para reducir la posibilidad de ser afectado por un virus informático.
1.1.4.2 DESVENTAJAS
El uso de ActiveX tiene su máxima aplicación en entornos homogéneos, basados en los
diferentes sistemas operativos y aplicaciones de Microsoft, en los que se puede
aprovechar la capacidad de los controles para obtener y presentar información de fuentes
muy diversas: bases de datos SQL o Access, hojas de cálculo Excel, etc.
A pesar de las numerosas similitudes entre el uso de Applets Java y controles ActiveX,
existen diferencias importantes, que condicionan en gran medida su aplicación. Los
controles ActiveX están totalmente enfocados a los entornos basados en los sistemas
operativos de Microsoft (Windows 3.11, 95 y NT).
De hecho, el único cliente Web capacitado para utilizar estos controles es el Internet
Explorer. Además, los módulos ActiveX se distribuyen en el formato binario característico
de los procesadores de Intel, mientras que los Applets Java tienen un espectro de
aplicación mucho más amplio, gracias a su distribución en un formato independiente de la
arquitectura hardware de cada tipo de ordenador. [11]
24
1.1.4.3 RIESGOS
Riesgos de los controles: Cuando los descargamos, los controles se ejecutan como
cualquier otro programa, teniendo acceso total al sistema. Pueden leer y escribir ficheros,
abrir conexiones de red, ejecutar comandos del sistema, es decir, realizar cualquier tarea
permitida por el sistema operativo.
Observando esto, corremos grandes riesgos si ejecutamos código de dudosa
procedencia.
Riesgos de los contenedores: Un contenedor es una aplicación que puede contener
controles y documentos. El peligro radica en la posibilidad de ejecución interactiva de
múltiples controles contenidos dentro de un contenedor, como por ejemplo una página
web.
Riesgos de los guiones: Permiten enviar comandos interactivamente a controles ActiveX
usando Java Script o VBScript. Los comandos proceden del contenedor o del servidor.
Pueden aceptar comandos de cualquier página web. [11]
1.2 DYNAMIC DATA EXCHANGE (DDE) (INTERCAMBIO DINÁMICO DE DATOS).

DDE es un protocolo integrado en Microsoft Windows que permite a los usuarios
compartir datos entre aplicaciones, ya sea en una máquina local o a través de una
conexión de red de Windows.
Como el nombre sugiere, DDE es un método para aplicaciones de Windows para
comunicarse entre sí y compartir información de manera dinámica. Puede ser pensado
como una conversación entre los dos programas. El primer programa se iniciará la
conversación por hacer una pregunta y la segunda va a obligar mediante el envío de la
respuesta. La conversación continúa hasta que una de las solicitudes se cierra la
conexión.
1.2.1 UTILIZACIÓN DE DDE.

DDE es generalmente utilizado para compartir datos entre dos aplicaciones, pero también
puede ser usado para enviar comandos a otra aplicación.
Algunas de las aplicaciones que soportan DDE en Windows de Microsoft son de Word,
Excel, Visual Basic, y Gerente de Programa, así como otros programas tales como el
ACC MultiView.[14]
25
1.2.2 WINDOWS, CLIENTE, SERVIDOR.

Cuando una aplicación se inicia el proceso de DDE, la solicitud se dice que es porque el
cliente solicita información a otra aplicación. La otra aplicación se llama el servidor, ya
que presta sus servicios a un cliente DDE. A pesar de lo que el nombre implica, un cliente
y servidor a través de la comunicación DDE nunca hablar directamente el uno al otro. Por
el contrario, enviar mensajes a Windows, que pasa la información en el destino correcto.
Debido a esto, el mundo de las redes de DDE abarca todo y no se limita a una sola
estación de trabajo. Con DDE es posible que una aplicación de Windows en una máquina
para enviar datos a una aplicación que se está ejecutando en otro lugar de trabajo,
siempre que estén en la misma red. Además, es posible que una única solicitud para
participar en múltiples conversaciones DDE simultáneamente.
1.2.3 PROTOCOLO.
Como con la mayoría de las comunicaciones, un conjunto de normas que aplican para
determinar cómo y cuándo se envían los datos. Estas normas determinan el protocolo
que se utiliza para regular el intercambio de datos. DDE requiere su propio protocolo para
supervisar la comunicación entre aplicaciones.
Este protocolo describe los procedimientos utilizados para iniciar y finalizar una sesión de
DDE, enviar datos a otra aplicación, recibir los datos de otra aplicación, y dar
instrucciones a otra aplicación para ejecutar una macro o comando. Hay relativamente
pocos parámetros que constituyen el presente protocolo, haciendo las comunicaciones
DDE bastante elemental.
1.2.4 ELEMENTOS DE CONVERSACIÓN.

Antes de intentar realizar una conversación DDE entre y otra aplicación, hay algunos
elementos esenciales de comunicación que debe determinarse.
Estos componentes especificar la aplicación que desea conversar con él, así como el
tema, o datos, que usted está interesado en compartir.
26
1.2.4.1 SOLICITUD.
Este es el programa con el que se quiere conversar. Con el fin de iniciar una
conversación con otra aplicación, usted tiene que saber el nombre del otro programa.
Este es el nombre del ejecutable de los demás, menos los .exe. [14]
Como un ejemplo, si se abre una conexión DDE con el Administrador de Programas de
Windows, el nombre de la aplicación sería PROGMAN. Si la otra aplicación no está en
ejecución, usted no podrá conectarse a él y lo más probable es que obtener un ERROR =
70. Es el programador tiene la responsabilidad de garantizar que la otra aplicación se
está ejecutando. Si no es así, usted debe invocar utilizando los SCALL () función.
1.2.4.2 TEMA
Este es el tema de datos que se designa para el acceso DDE, DDE de la aplicación del
servidor. Este campo está predeterminado por la aplicación de servidor como un objeto
que le gustaría compartir. Por ejemplo, si se va a comunicar con una hoja de cálculo de
Excel a través de DDE, el tema de la conversación sería el nombre del archivo de hoja de
cálculo con el que desea intercambiar datos.
1.2.4.3 ARTÍCULO
Esta es la pieza de información que usted está tratando de leer. Usando el ejemplo de
Excel, el tema sería el de células específicas en la hoja de trabajo. Si usted quiere saber
qué programas se han definido en el grupo Accesorios de Windows en el Administrador
de programas, deberá utilizar el nombre del grupo de “accesorios” para el tema.
Para poder utilizar DDE con éxito, el programador debe tener toda la información relativa
a la aplicación remota de antelación. En otras palabras, usted no puede llevar a cabo una
conversación DDE a menos que sepa los temas que se comparten y la naturaleza de los
temas.
Esto puede limitar la utilidad y la capacidad que ofrece DDE. Por ejemplo, es posible que
desee obtener información de su hoja de cálculo de Excel, pero sin saber lo que espera
para Excel DDE temas y artículos que no pueden comunicarse con ella en absoluto. [14]
1.3 OPEN DATA BASE CONECTIVITY (ODBC) (CONECTIVIDAD DE BASE DE DATOS

ABIERTA).
La interfaz ODBC, permite el acceso a las aplicaciones de datos en sistemas
manejadores de bases de datos (DBMS, Data Base Management System) utilizando para
ello SQL (Standard Query Lenguaje) como un estándar para el acceso a los datos.
27
La interfaz permite máxima interoperabilidad. Una sencilla aplicación puede accesar a

diferentes DBMS. Esto permite al diseñador de las aplicaciones, desarrollar, compilar y
enviar una aplicación sin especificar el manejador de base de datos utilizado. Los
usuarios pueden entonces agregar módulos llamando a drivers de bases de datos para
lograr una unión entre las aplicaciones y su opción de DBMS.[13]
En el mundo tradicional de las bases de datos. Las aplicaciones usualmente significaban

hacer una tarea específica de una base de datos con un específico DBMS en mente, tales
como operaciones financieras, pagos, o un manejador de inventario. Estas aplicaciones
típicamente estaban escritas utilizando SQL inmerso. Mientras el SQL inmerso es
eficiente y portable entre diferentes tipos de hardware y sistemas operativos, el código
fuente necesitaba ser compilado en cada nuevo ambiente.
SQL inmerso no fue óptimo para aplicaciones que necesitaban analizar guardados en
bases de datos, tales como DB2 y Oracle, y preferiblemente lo hacían a través de
interfaces familiares tales como Microsoft Excel. Bajo el acercamiento tradicional de
accesar la base de datos, una versión de Microsoft Excel debería poseer un pre-
compilador con código de DB2 o de Oracle.
ODBC ofrece un nuevo acercamiento: provee programas separados para extraer la
información de la base de datos, y luego tiene una forma de importar los datos. Siempre
existirá métodos viables de comunicación; protocolos de datos, y capacidades de DBMS,
la solución ODBC permite utilizar tecnologías para ser definidos como interfaces
estándares.
Esta solución lleva a la idea de drivers de bases de datos – librerías de unión dinámico
(dynamic-link libraries, DLL) que una aplicación puede invocar cuando sea requerido para
beneficiarse del acceso a una fuente de datos particular, a través de un método particular
de comunicaciones, muy parecidos a un driver de impresora bajo ambiente Windows.
ODBC provee una interfaz estándar que permite tanto a los escritores de aplicaciones y a
los proveedores de librerías manejar datos entre aplicaciones y las fuentes de datos. [13]
28
Figura 2. Aplicación ODBC.
En la Fig. 2 puede observarse que el ODBC permanece en el centro de un sinnúmero de

aplicaciones y de la misma forma de los DBMS, haciendo la aplicación independiente de
DBMS.
1.3.1 LA INTERFAZ.
La interfaz ODBC define lo siguiente:
La librería que contiene las funciones ODBC permite a la aplicación conectarse a un
DBMS, ejecutar sentencias SQL, y obtener los resultados.
La sintaxis SQL está basada en las especificaciones de 1992 de X/Open, y SQL Access
Group (SAG).
 Códigos de errores estándares.

 Una forma de conectarse y darse ingreso al manejador que utilice.
 Una representación estándar de los tipos de datos.
 La interfaz es flexible.
Las cadenas de caracteres que contienen las sentencias SQL pueden ser explicitas,
incluyendo el código fuente o bien pueden ser construidas en tiempo de corrida.
Una aplicación puede ignorar los protocolos de comunicaciones fundamentales entre ella
y el producto DBMS.
Los valores de datos, pueden ser enviados y obtenidos en un formato conveniente para la
aplicación. [13]
29
1.3.2 ODBC DEFINE DOS TIPOS DE DRIVERS.

 De simple paso
 De múltiples pasos.
Este tipo de drivers procesan las llamadas de ODBC y las sentencias (En este caso el
driver ejecuta parte de la funcionalidad de las fuentes de datos).
El driver procesa las llamadas de ODBC y pasa las sentencias SQL a la fuente de los
datos.
Un sistema puede contener ambos tipos de configuraciones.
Figura 3. Ejemplos de RED.
La figura. 3 muestra como cada uno de las configuraciones antes mencionadas pueden
parecer en una red simple. El diagrama incluye ejemplos de los tipos de DBMS que
pueden residir en la red.
30
1.3.3 ESTRUCTURA DEL ODBC.

La arquitectura ODBC contiene cuatro principales componentes: la aplicación, el
administrador de drivers, el driver, y la fuente o fuentes de datos. Una aplicación utilizando
la interfaz ODBC generalmente proveerá al usuario herramientas, incluyendo:
 Conectarse y desconectarse de DBMS.
 Ejecutar consultas y proveer áreas de trabajo y dar el formato a los datos que del
los resultados.
 Permitir el proceso de transacciones en línea (OLTP)
 Rasgos externos a la interfaz ODBC. [13]
1.4 PROTOCOLOS DE COMUNICACIÓN.

Muchas veces escuchamos en la industria la palabra protocolos de comunicación sin
tener claro de que estamos hablando. Con el objeto de familiarizar, sus principales
características y fundamentos de los más utilizados. En principio un protocolo de
comunicación es un conjunto de reglas que permiten la transferencia e intercambio de
datos entre los distintos dispositivos que conforman una red. Estos han tenido un proceso
de evolución gradual a medida que la tecnología electrónica ha avanzado y muy en
especial en lo que se refiere a los microprocesadores.
Un importante número de empresas en nuestro país presentan la existencia de islas

automatizadas (células de trabajo sin comunicación entre sí), siendo en estos casos las
redes y los protocolos de comunicación Industrial indispensables para realizar un enlace
entre las distintas etapas que conforman el proceso.
La irrupción de los microprocesadores en la industria ha posibilitado su integración a

redes de comunicación con importantes ventajas, entre las cuales figuran:
 Mayor precisión derivada de la integración de tecnología digital en las mediciones.

 Mayor y mejor disponibilidad de información de los dispositivos de campo.
 Diagnóstico remoto de componentes.
La integración de las mencionadas islas automatizadas suele hacerse dividiendo las

tareas entre grupos de procesadores jerárquicamente anidados. Esto da lugar a una
estructura de redes Industriales, las cuales es posible agrupar en tres categorías:
31
 Buses de campo.
 Redes LAN.
 Redes LAN-WAN.
En esta oportunidad nos referiremos a los protocolos de comunicación más usados en la

industria.
Los buses de datos que permiten la integración de equipos para la medición y control de
variables de proceso, reciben la denominación genérica de buses de campo.
Un bus de campo es un sistema de transmisión de información (datos) que simplifica
enormemente la instalación y operación de máquinas y equipamientos industriales
utilizados en procesos de producción.
El objetivo de un bus de campo es sustituir las conexiones punto a punto entre los
elementos de campo y el equipo de control a través del tradicional lazo de corriente de 4 -
20mA o 0 a 10V DC, según corresponda. Generalmente son redes digitales,
bidireccionales, multipunto, montadas sobre un bus serie, que conectan dispositivos de
campo como PLC‟s, transductores, actuadores, sensores y equipos de supervisión.
1.4.1 COMPONENTES DE LAS REDES INDUSTRIALES

En grandes redes industriales un simple cable no es suficiente para conectar el conjunto
de todos los nodos de la red. Deben definirse topologías y diseños de redes para proveer
un aislamiento y conocer los requerimientos de funcionamiento.
 Bridge
Con un puente la conexión entre dos diferentes secciones de red, puede tener diferentes
características eléctricas y protocolos; además puede enlazar dos redes diferentes.
 Repetidor
El repetidor o amplificador es un dispositivo que intensifica las señales eléctricas para que
puedan viajar grandes distancias entre nodos. Con este dispositivo se pueden conectar un
gran número de nodos a la red; además se pueden adaptar a diferentes medios físicos
como cable coaxial o fibra óptica.
32
 Gateway
Un gateway es similar a un puente ya que suministra interoperabilidad entre buses y
diferentes tipos de protocolos y además las aplicaciones pueden comunicarse a través de
él.
 Enrutadores
Es un switch "Enrutador" de paquetes de comunicación entre diferentes segmentos de red
que definen la ruta hacia donde se transmite la información.
1.4.2 RS-232.
El driver RS232 realiza la comunicación full-dúplex. Consta de dos partes totalmente
diferenciadas: el circuito transmisor y el circuito receptor. El circuito receptor es el
responsable de la recepción de los datos que se envían desde la computadora al
periférico: la línea TxD de salida de la computadora se conecta al pin RxD del periférico.
De forma similar, el circuito transmisor es el responsable del envío de datos a la
computadora: la línea de salida TxD del periférico se conecta al nodo de entrada RxD del
computador.
El protocolo de comunicación serie full-dúplex RS232 asíncrona establece una
comunicación fácil entre computador y periférico.
El protocolo de comunicación RS232 la transmisión de datos puede ser estudiado como
lo muestra la figura 4.
Figura 4. Transmisión de datos.
 El estado de reposo implica un 1 lógico.

 Un bit de start a 0 lógico.
 7 u 8 bits de datos.
 Posibilidad de bit de paridad.
 Uno, uno y medio o dos bits de stop, a 1 lógico.
33
Durante la transmisión (recepción) la duración de cada bit es de 16 ciclos de reloj base.

Por consiguiente, en la realización de los drivers (transmisor y receptor) se tendrá que
contemplar la sincronización de la transmisión / recepción de datos con el reloj base.
Aunque computador y periférico se programen para transmitir datos a una frecuencia
determinada, es difícil asegurar que las frecuencias base de los relojes estén
perfectamente sincronizadas. Por ello la emisión y recepción de datos se realiza tomando
como base una frecuencia 16 veces superior a la frecuencia de transmisión de datos. Por
otra parte, durante la recepción de datos pueden producirse en la transmisión daños que,
debido a interferencias, pueden introducir errores de recepción. Para minimizar este
efecto suelen tomarse distintas muestras de la recepción del bit, tomando como resultado
bueno, el valor que más se sucede dentro de la recepción del bit. Es por ello, que durante
la recepción se deberá considerar circuitería adicional para asegurar un comportamiento
más fiable de la transmisión.
En una comunicación simple mediante protocolo RS232 (sin control de recepción) tan sólo
son necesarias tres líneas de conexión entre el PC y el periférico: RxD o recepción, TxD o
transmisión, y tierra.
Puerto serie.
Aunque el puerto serie puede tener un tamaño de 25 pines, el formato más utilizado es el
de 9 pines. La tabla 1 de conexiones del pin-out para ambos conectores es:
Tabla 1 Conexiones del pin
34
1.4.3 ETHERNET.
Ethernet es una tecnología de redes ampliamente aceptada con conexiones disponibles
para PCs, estaciones de trabajo científicas y de alto desempeño, mini computadoras y
sistemas mainframe.
La arquitectura Ethernet provee detección de errores pero no corrección de los mismos.

Tampoco posee una unidad de control central, todos los mensajes son transmitidos a
través de la red a cada dispositivo conectado. Cada dispositivo es responsable de
reconocer su propia dirección y aceptar los mensajes dirigidos a ella. El acceso al canal
de comunicación es controlado individualmente por cada dispositivo utilizando un método
de acceso probabilístico conocido como disputa.
Ethernet continúa ganando aceptación en aplicaciones de medición y control distribuido

debido a su bajo costo, operación entre dispositivos, comunicación con la empresa y un
mayor ancho de banda. Viendo al futuro, la tendencia que más afecta el futuro Ethernet es
el Ethernet determinístico para aplicaciones que requieren de gran sincronización y
transferencia de datos entre nodos. En las redes Ethernet estándar, las colisiones en las
redes de los concentradores introducen variaciones, los conmutadores de red introducen
retraso de propagación, y nodos individuales introducen retrasos. Éstos causan
problemas para cualquier sistema basado en tiempo incluyendo las aplicaciones de
control.
Existe un gran número de estándares en Ethernet introducidos para proporcionar

diferentes niveles de determinismo incluyendo EtherNET/IP (ODVA), PROFINET
(Siemens), EtherCAT (Grupo Tecnológico EtherCAT), ETHERNET Powerlink, y SERCOS-
III (IGS). Cada protocolo ofrece diferentes niveles de desempeño y costo pero
generalmente requieren que todos los nodos en el segmento Ethernet soporten el
protocolo.
Cable Ethernet. (Par Trenzado)

Los cables de trenza no tienen escudo (unshielded) son comúnmente utilizados con
sistemas telefónicos y redes de área local (LAN), consisten en pares de cables aislados y
entrelazados mutuamente. Las ventajas de un (unshielded) cable de trenza es que no son
35
muy costosos relativamente, son fáciles de instalar y proveen una transmisión bastante
rápida de hasta 100Mpbs.El número de entrelazamientos en el cable es importante
porque más vueltas ayudan a prevenir que el campo magnético que se genera por la
señal eléctrica de uno de los cables ocasione un fallo en el voltaje del otro cable.
Tabla 2. Conexiones cable Ethernet.

Posición de los pines
Pin Función 568A 568B
Conector RJ-45
TX+
1
Transceive data + Blanco - Verde Blanco – Naranja
2 Transceive data -
Verde Naranja
RX+
3 Blanco -
Receive data + Blanco – Verde
Naranja
BDD+
4 Bi-directional data
Azul Azul
+
BDD-
Blanco - Azul Blanco – Azul
-
RX-
6
Receive data - Naranja Verde
BDD+
Blanco - Marrón Blanco – Marrón
+
BDD-
Marrón Marrón
-
36
El conector RJ-45 encontrado al final de los cables de trenzas es similar a aquellos

usados en los cables telefónicos y se necesitan conectar del cable de la red al hub y luego
a la computadora y su conexión como se muestra en la Tabla 2.
1.5 TECNOLOGÍA OPC.
1.5.1 HISTORIA DEL OPC

Este es el camino que se ha llevado hasta llegar al OPC:
1982 DOS: Desde los “viejos” tiempos del DOS se ha intentado conectar los equipos de
campo a computadoras personales. En aquella época oscura, los PC sólo podían hacer
una cosa a la vez y se necesitaban drivers específicos para cada dispositivo externo que
se quería conectar.
1990 Windows 3.0 y Dynamic Data Exchange (DDE Intercambio Dinámico de Datos): Con
él apareció la posibilidad (a bajo precio) de ejecutar varias tareas simultáneamente en un
ordenador y un mecanismo estándar para que se intercambiaran información entre ellas.
Se podía ya, por ejemplo, ver datos de proceso de instrumentos de campo en una hoja de
Excel. Desafortunadamente, DDE tenía limitaciones: no era excesivamente robusto, el
ancho de banda era limitado (la información se transfiere en formato de caracteres) y no
se podía enviar información a través de redes.
1992 Windows 3.1 & Object Linking & Embedding 1.0 (OLE): En cuanto apareció, ya se
intuía que OLE iba a desplazar al DDE para intercambio de datos, ya que era más flexible,
robusto y usaba mecanismos de transporte más eficientes.
1993 OLE 2.0 Comité WinSEM: Este grupo de desarrolladores de software técnico se
reunía regularmente en las instalaciones de Microsoft y estaban interesados en aplicar el
PC a control industrial y adquisición de datos. Se centraron en técnicas OLE para
intercambiar datos entre aplicaciones en (cuasi) real-time. En particular, los fabricantes de
SCADA se mostraron muy interesados en estandarizar la interfaz entre el “núcleo” del
SCADA y los drivers de los dispositivos de campo. Eso podía beneficiar tanto al fabricante
del SCADA como al del dispositivo de campo.
1994 OLE 2.1 (32 bit).
1995 OPC Task Force: La OPC Task Force se hace pública en la presentación de ISA de
1995, donde se anuncian los objetivos del grupo. Los primeros miembros son: Fisher-
Rosemount, Intellution, Intuitive Technology, OPTO 22, Rockwell Software y Microsoft. El
primer borrador de la especificación aparece en diciembre.
37
1995 Windows 95: Hacia el final de 1995 aparece Windows 95, se generaliza el Windows
(a secas) como sistema operativo.
1996 Especificación OPC V 1.0 (A): En agosto 1996 aparece la versión 1.0.
1996 Windows NT 4.0: Aparece en 1996, combina la fiabilidad del NT 3.5 con el interfas
de usuario del W 95. Incluye soporte de DCOM (Distributed Common Object Model), que
permite a las aplicaciones crear y trabajar con objetos residentes en otros ordenadores a
través de la red.
1996 Fundación OPC: En agosto de 1996 se crea la fundación como organización sin
interés económico con la tarea de gestionar el estándar OPC. Su “misión” es: Desarrollar
un estándar abierto, basado en los requerimientos funcionales de la tecnología OLE/COM
y DCOM, que fomente mayor interoperabilidad entre aplicaciones de
control/automatización, sistemas/dispositivos de campo y aplicaciones de gestión.
1997 Comités Técnicos OPC: Para poder gestionar el amplio rango de asuntos
relacionados con los datos del control de los procesos la fundación OPC forma una serie
de “comités” para investigar y diseñar mejoras a la especificación original.
1998 Windows 98: Se espera para la segunda mitad de 1998, W98 es una mejora
incremental sobre W95 y su importancia para la industria del control de procesos por ser
un sistema operativo multitarea con soporte para DCOM integrado y por lo tanto para
tecnología de servidor de OPC barato y probado.
1998 Windows NT 5.0: También aparecerá en la segunda mitad de 1998, ofrece mejoras
significativas sobre NT 4.0.[8]
1.5.2 OLE FOR PROCESS CONTROL (OPC)

El OLE para control de procesos (OPC) es un estándar abierto para compartir datos entre
dispositivos de campo y aplicaciones de ordenador basado en OLE de Microsoft.
Permite a las aplicaciones leer y escribir valores de proceso y que los datos sean
compartidos fácilmente en una red de computadoras.
El estándar, gobernado por la Fundación OPC, es de dominio público y disponible para

cualquiera que quiera usarlo (ver apartado final de este texto donde conseguirlo).
Tradicionalmente, los fabricantes de software para acceso de datos de proceso tenían
que desarrollar drivers específicos para cada tipo de hardware al que querían acceder.[9]
38
Cada software requería un driver distinto para cada hardware, implicando un esfuerzo
enorme, al que hay que añadir el de las actualizaciones continuas.
Con OPC, los fabricantes de hardware sólo tendrán que preparar un conjunto de
componentes de software para que los clientes los utilicen en sus aplicaciones. Los
desarrolladores de software no tendrán que reescribir los drivers debido a nuevas
versiones de hardware.
Los usuarios finales tendrán muchas más alternativas de integrar distintos sistemas.
Una aplicación OPC, como cualquier otra aplicación OLE (o DDE), constará de servidores
y clientes OPC. (Fig. 5.).
Sistema
I/O fisicas
SCADA
OPC
APLICACION
server
I/O fisicas
Figura 5.Integración de datos en OPC.
Cada cliente, es decir, cada aplicación de usuario, SCADA, módulo histórico, o aplicación
de usuario en C++ o Visual Basic interroga al servidor que contiene los datos que necesita
(Fig. 6 y 7).
39
Figura 6. Sistema abierto con servidores OPC.
Los servidores están organizados en grupos y cada grupo puede contener distintos items.
DIAGRAMA CLIENTE – SERVIDOR OPC
Servidor OPC
Fabr. A
Servidor OPC
Cliente OPC #1 Cliente OPC #2
Fabr. B
Servidor OPC
Fabr. C
Cliente OPC #3
Figura 7. Diagrama cliente-servidor OPC.
40
Las diferentes partes de la aplicación (displays de operador, informes, etc.) pueden usar
distintos grupos, los cuales pueden tener distinta frecuencia de refresco y pueden ser de
acceso secuencial o basado en excepciones (eventos). Los ítems representan conexiones
a fuentes de datos dentro del servidor (variables de proceso) a grandes ragos en la Tabla
1.3 los modelos de objetos. A cada item se asocia un valor (valor de la variable de
proceso), un cualificador (estado de la variable, OK, bajo rango, etc.) y una marca de
tiempo (Fig. 9). [9]
ORGANIZACIÓN DE UN SERVIDOR OPC
Servidor OPC
GRUPO 1
ITEM 1
ITEM 2
ITEM 3
GRUPO 2 ITEM...
VALOR : 150 °C
QUALIFICADOR : O.K.
Marca Temporal : 22:15:00
GRUPO...
GRUPO 3
Figura 8. Organización de los datos en un servidor OPC.
A continuación se muestra en la tabla 3 las jerarquías de OPC
41
Tabla 3.Objetos de Modelos.
OBJETO DESCRIPCIÓN
OPCServer Es una instancia (referencia o solicitud) a un servidor OPC. Mantiene

información sobre el servidor escogido y los servicios que ofrece. Se debe
crear un objeto OPCServer antes de poder referenciar los otros objetos.
Este contiene la colección OPCGroups y el objeto OPCBrowser.
OPCGroups Es una colección de los objetos OPCGroup que el cliente ha creado.
OPCGroup El propósito de este objeto es mantener la información de estado y proveer

el mecanismo para ofrecer los servicios de adquisición de datos por la
colección de objetos OPCItem.
OPCItems Es una colección que contiene todos los objetos OPCItem que el cliente ha
creado.
OPCItem Es un objeto que mantiene la definición de los items, sus valores, estados
y datos de la última actualización. Los Item representan conexiones a las
fuentes de datos requeridas del servidor OPC instalado.(NO son fuentes
de datos)
OPCBrowser Es un objeto que permite (hojear) buscar nombres de items en un servidor

configurado.
1.5.3 PROBLEMÁTICA Y SOLUCIÓN EN LA COMUNICACIÓN DRIVER / APLICACIÓN.

Problema (Figura 9).
 Problemas que compatibilidad.
 Duplicacion del esfuerzo.
 Inconsistencias entre los fabricantes.
 Conflictos de acceso.
42
Figura 9. Problema OPC
Solución.
Establece un Estándar (Figura 10):
 Disminuye inversion en Drivers
 Intergracion entre varios fabricantes.
 Menor dependencia del Hardware.
Figura 10. Solución OPC.
1.5.4 ARQUITECTURA.
Arquitectura cliente / servidor (Figura 11).
 El servidor ofrece datos.
 El cliente accede a esos datos.
Un servidor OPC es un objeto COM.

El interfaz de acceso a datos ofrece una ventana a datos existentes.
43
Figura 11. Arquitectura Cliente / Servidor.
Los datos se identifican con una cadena.

 OPC ofrece un acceso simbólico a los datos para las capas superiores.
Cada dato físico es un ´item´ (= tag, variable).

El cliente puede leer y escribir ítems (Figura 12).
 Las lecturas pueden ser sincronas o asincronas.
 Se puede crear suscripciones a ítems.
Figura 12. “n” de grupos.
Acceso a datos históricos.

Distintos tipos de servidores históricos y diseño de servidor OPC (Figura 13).
 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. [9]
44
Figura 13. Diseño de un servidor OPC.
1.5.5 TIPOS DE DATOS Y CARACTERÍSTICAS EN OPC.

En general tipos simples:
 bool, byte, word, dword, float, double
 (Singned y Unsigned)
También permite (menos común).

 Arrays de los tipos anteriores
 Manejo de cadenas.
 Datos estructurados.
 No es lo habitual.
 El estandar lo contempla de forma optativa.
 Mas complejo.
Características.
 Basado en COM.
 Flexible.
 Eficiente.
 Puede empotrarse en las aplicaciones.
 Altamente escalable.
45
 Debido a que la tecnología COM se basa en interfazss.

 Esto permite desarrollar grandes aplicaciones.
 Diseñado para comportarse eficientemente en red.
 Aceptado y adoptado por el entorno industrial.
Otra gran ventaja de las especificaciones “abiertas” OPC, es la utilización de lenguajes de

programación como C++ o Visual Basic como clientes OPC, para la realización de
aplicaciones a medida.
1.5.6 FUNCIONAMIENTO DE OPC.
La opción más sencilla y habitual, es utilizar OPC Automation Wrapper. Se trata de un

interfazs de automatización usado para conectarse desde un cliente (Visual Basic, Excel y
otros lenguajes de programación) a servidores OPC.
 Se llama wrapper (envoltura) porque enmascara o envuelve el interfazs de
programación original “OPC Custom Interfazs Server”, que sirve los datos en C++.
 Así, las llamadas desde el programa cliente al OPC Automation Wrapper, son
convertidas automáticamente al interfazs de comunicación original OPC.
 La ventaja de OPC Automation Wrapper, es que proporciona una comunicación
con los servidores OPC usando un lenguaje más sencillo.
 Muchos programadores están familiarizados con los servidores y los clientes de
OPC creados por los miembros de la fundación de OPC. Por ejemplo, un SCADA
es un cliente OPC de fácil programación, que intercambia datos con un servidor
OPC (alojado en un PC) el cual a su vez se comunica con los equipos físicos
(PLC, etc.). Para el programador, la comunicación en el estándar OPC es
transparente, y solamente utiliza las herramientas que proporciona el Scada. [9]
46
II. “HARDWARE Y SOFTWARE PARA SISTEMAS DE CONTROL DIGITAL”
En este capítulo se abordan los conceptos de Controlador Lógico Programable (PLC),

Sistema de control distribuido (SCD), Sistemas de Adquisición de Datos (SCADA), y un
lenguaje de programación como lo es Visual Basic en su versión 6.0 dando una
explicación breve de éstos para resaltar las características de cada una de ellos
asimismo mostrar información de las herramientas de software y hardware que serán
útiles en el desarrollo del proyecto.
47
2. EVOLUCION DE LOS SISTEMAS DE CONTROL
La aparición de los sistemas de control tal y como se conocen en la actualidad es el

resultado de un proceso largo de evolución tecnológica.
Los primeros sistemas de control que conocemos son las trampas de caza. Estaban
dotadas de un elemento, a modo de trinquete primitivo, que sujetaba la trampa abierta.
Cuando algún animal pisaba encima, el trinquete dejaba de sujetar la trampa, cerrándola y
atrapando al animal.
Uno de los ejemplos más antiguos de sistemas automáticos son los mecanismos
reguladores con flotador, desarrollados en Grecia durante el siglo III a.C., como el reloj de
agua de Ktesibios o la lámpara de Filón, que permitía mantener un nivel constante de
aceite. En el siglo I d.C. Herón publicó su obra Pneumatica, en la que describía varios
automatismos hidráulicos y neumáticos.
En la Revolución Industrial, la invención de la máquina de vapor supuso un avance
enorme en la automatización de los sistemas. Se aplicó principalmente a la tracción de
locomotoras y vehículos, y posteriormente derivó en la invención de los motores de
combustión interna. Todas estas invenciones tienen en común el aporte de un medio
energético a una máquina para que funcione de forma autónoma.
El nacimiento de la automatización industrial surgió con la invención del regulador
centrífugo de Watt, que permitía controlar la velocidad de las máquinas de vapor.
A partir del siglo XIX comenzaron a aparecer multitud de aparatos que realizaban
funciones automáticas, como máquinas mecánicas de multiplicar o una máquina para
resolver ecuaciones de segundo grado inventada por Charles Babbage
La Segunda Guerra Mundial marcó un hito en el desarrollo de los sistemas de control

automáticos, coincidiendo con el desarrollo de la electrónica. Así, se avanzó
enormemente en los medios de control con fines militares, como el radar, el piloto
automático en los aviones, los sistemas de cálculo de tiro o las comunicaciones a través
de la radio y la telefonía.
A partir de los años cincuenta comenzó la incorporación de los ordenadores para el

control de procesos, naciendo los plc y los robots. En 1954, el norteamericano G. Devol
48
desarrolló un brazo mecánico programable capaz de realizar tareas específicas, y durante

la misma década una empresa norteamericana instaló el primer plc en sus cadenas de
montaje.
En definitiva, se puede decir que el desarrollo de los sistemas de control automáticos ha

supuesto que los objetos de consumo posean una autonomía tal que funcionan
prácticamente sin intervención de las personas, no solo en la industria, sino también, en
el hogar.
El control automático de procesos se utiliza debido a que reduce el costo de os procesos
industriales, lo que compensa con creces la inversión en equipo de control. Además de
las ganancias intangibles que se obtienen tales como la eliminación de mano de obra
pasiva y la supresión de errores. [15]
2.1. CONTROLADOR LÓGICO PROGRAMABLE “PLC”
2.1.1. ANTECEDENTES.
Su historia se remonta a finales de la década de 1960 cuando la industria buscó en las
nuevas tecnologías electrónicas una solución más eficiente para reemplazar los sistemas
de control basados en circuitos eléctricos con relés, interruptores y otros componentes
comúnmente utilizados para el control de los sistemas de lógica combinacional.
En 1969 la División Hydramatic de la General Motors instaló el primer PLC para
reemplazar los sistemas inflexibles alambrados usados entonces en sus líneas de
producción.
Ya en 1971, los PLCs se extendían a otras industrias y, en los ochentas, ya los
componentes electrónicos permitieron un conjunto de operaciones en 16 bits, comparados
con los 4 de los 70s, en un pequeño volumen, lo que los popularizó en todo el mundo.
En los primeros años de los noventas, aparecieron los microprocesadores de 32 bits con
posibilidad de operaciones matemáticas complejas, y de comunicaciones entre PLC‟s de
diferentes marcas y PCs, los que abrieron la posibilidad de fábricas completamente
automatizadas y con comunicación a la gerencia en "tiempo real". [15]
49
2.1.2. ¿QUÉ ES UN CONTROLADOR LÓGICO PROGRAMABLE?
De acuerdo con la definición de la "Nema" (National Electrical Manufacturers Association)

un controlador programable es: "Un aparato electrónico operado digitalmente, que usa
una memoria programable para el almacenamiento interno de instrucciones para
implementar funciones específicas, tales como lógica, secuenciación, registro y control de
tiempos, conteo y operaciones aritméticas para controlar, a través de módulos de
entrada/salida digitales (ON/OFF) o analógicos (1 5 VDC, 4 20 mA, etc.), varios tipos de
máquinas o procesos.[16]
2.1.3. ARQUITECTURA DE UN PLC CONVENCIONAL

En su forma más básica el PLC costa de los siguientes elementos
1. Fuente de Alimentación. Suministra el voltaje requerido para el funcionamiento de
los componentes electrónicos del PLC.
2. Memoria. Se almacenan las instrucciones (lógica de control) que definirá la
secuencia de control y las variables internas y externas
3. Unidad de control de Procesos (CPU). Se encarga de procesar las instrucciones
almacenadas en la memoria, para ordenar a las tarjetas de salida.
4. Tarjetas de Salidas. Se encargan de transformar los estados de las señales de
control, generadas por la CPU en señales de campo
5. El Bus de Datos. Medio por el que transitan los datos de distintos componentes del
PLC.
La figura 14 muestra de manera gráfica los componentes de un PLC convencional
50
Memoria CPU Tarjetas de Entrada
Fuente de
Bus de Datos
Alimentación
Tarjetas de Salida
Figura 14. Arquitectura de un PLC convencional.
2.1.4. CICLO DE TRABAJO DEL PLC

El PLC está siempre repitiendo un ciclo, llamado ciclo de SCAN, como se observa en la
figura 14 y consiste en lo siguiente:
a) En primer lugar lee todas las entradas y almacena el estado de cada una de
ellas
b) En segundo lugar ejecuta las operaciones del programa siguiendo el orden en
que se han grabado.
c) En tercer lugar escribe el resultado de las operaciones en las salidas.
d) Una vez escritas todas las salidas (activando o desactivando las que el
resultado de las operaciones así lo requieran) vuelve al paso a.
51
Este ciclo de Scan se realiza indefinidamente hasta que pasemos el conmutador de la

CPU a la posición STOP. Como se observa en la figura 15.
Lee las
entradas
Almacena CICLO Almacena

estado de las estado de las
entradas SCAN entradas
Ejecución del
programa
Figura 15. Ciclo de Trabajo del PLC.
Comunicación del PLC

El PLC tiene tres niveles de comunicación, éstos son:
 Nivel de control. Comprende el intercambio entre controladores
 Nivel Instrumentos. Incluye el protocolo de comunicación de toda la
instrumentación de campo con el controlador
 Nivel Supervisión. Abarca la comunicación entre controladores con la finalidad de
supervisar las condiciones del controlador y las variables de campo.
2.1.5 VENTAJAS DEL PLC

Los PLC pueden realizar un amplio rango de tareas de automatización. Estos son típicos
en procesos industriales en la manufactura donde el costo de desarrollo y mantenimiento
de un sistema de automatización es relativamente bajo. Los PLC contienen todo lo
necesario para manejar altas cargas de potencia; se requiere poco diseño eléctrico y el
problema de diseño se centra en expresar las operaciones y secuencias en la lógica de
escalera (o diagramas de funciones).
52
Gracias a ellos, es posible ahorrar tiempo en la elaboración de proyectos, pudiendo

realizar modificaciones sin costos adicionales. Por otra parte, son de tamaño reducido y
mantenimiento de bajo costo, además permiten ahorrar dinero en mano de obra y la
posibilidad de controlar más de una máquina con el mismo equipo. Sin embargo, y como
sucede en todos los casos, los controladores lógicos programables, o PLCs, presentan
ciertas desventajas como es la necesidad de contar con técnicos calificados y adiestrados
específicamente para ocuparse de su buen funcionamientos.
Para el desarrollo del proyecto se utiliza un PLC marca Allen Bradley, Compactlogix
modelo L32E debido a que éste fue proporcionado para la realización de esta tesis, cuya
construcción física y características se indican en la figura 16 y tabla 4 respectivamente.
Figura 16. Dimensiones del PLC CompactLogix LE32E
53
2.2 SISTEMA DE CONTROL DISTRIBUIDO (SCD).
2.2.1. ANTECEDENTES HISTÓRICOS.

En 1975, fue presentado por primera vez al público el sistema basado en
microprocesadores, completamente digital. Este novedoso concepto de control agrupa en
un solo conjunto de equipos electrónicos, todo lo necesario para manejar desde una
consola en pantallas y teclados, en contraste con los grandes tableros de control, todo un
proceso industrial. Este moderno sistema se dio a conocer como “Sistemas de Control
Distribuido” ya que el concepto básico en el que su fundamentó fue la distribución
geográfica de los controladores, que además de estar en un lugar más cercano
físicamente al proceso, tendría la facilidad de enviar toda la información hasta el cuarto de
control donde el operador de la planta tendría acceso a ella, de manera irrestricta.
2.2.2. ARQUITECTURA TÍPICA DEL DCS.
2.2.2.1. SISTEMAS DE CONTROL DISTRIBUIDO (ARQUITECTURA).

Hablando de manera general de los sistemas de control moderno que representan
características de control avanzado, en el sentido de que sean capaces de manejar no
solo los lazos de control con una ley de control especifica, sino de utilizar modelos
matemáticos de los procesos, dando una ley de control no conocida o preestablecida,
combinando funciones matemáticas y lógicas; con flexibilidad y maniobrabilidad, ya que
todas éstas se generan en base a un programa o configuración, entonces se habla de los
sistemas de control avanzados, los cuales pueden ser divididos la siguiente manera:
SISTEMAS AVANZADOS DE
CONTROL DE PROCESOS
SISTEMAS DE SISTEMAS DE
CONTROL DISTRIBUIDO CONTROL CENTRALIZADO
Figura 17. División de los sistemas de control avanzado
54
Figura.17 Se puede apreciar que en el control distribuido las funciones de control residen
en las unidades de control local, mientras que en los sistemas centralizados, estas
residen en la unidad central, estando remotas solo en las entradas y salidas que se
ubican en gabinetes locales, cuyos cables se llevan hasta la instrumentación de campo y,
por medio de otros cables que contribuyen a la pista de datos, se envían al cuarto de
control central.
2.2.2.2. ARQUITECTURA TÍPICAS DE CONTROL DISTRIBUIDO.

Actualmente existen sistemas en la industria del control que presentan diversas
arquitecturas entre las que destacan tres:
 Arquitectura tipo lineal o Bus.
 Arquitectura tipo anillo.
 Arquitectura tipo mixto.
En forma funcional la Figura 16. Presenta los componentes principales de cualquier
sistema de control de procesos avanzados o modernos, donde se puede observar que los
dispositivos de entrada miden las condiciones del proceso. Estos dispositivos pueden ser
analógicos tal como los transmisores de flujo, presión o analizadores, o pueden ser
discretos como interruptores de la presión e interruptores de límite, las válvulas de control.
Estos dispositivos alimentan sus señales vía módulos de entrada a las funciones de
control. La función de estos módulos de entrada es acondicionar las señales para darles
la forma que sea aceptable para los circuitos y dispositivos internos de un Sistema de
Control Avanzado de Procesos (SCAP).
Los cuatro componentes principales son de un DCS son (figura 18):
 Modulo de comunicaciones de E/S.

 El Procesador.
 La Memoria.
 La Fuente de Poder.
55
PROCESO
Dispositivos de Dispositivos de Salida

Entrada Analógicos y Discretos
Analógicos y Discretos
MODULOS DE MODULOS DE
Funciones de
control
Lógicos
PID
Interfaz con el
Operador
Pantalla/Teclado
Figura 18. Principales componentes de un SCD
La interfaz de operador, como su nombre indica proporciona los medios para que el
operador observe la información que existe en el SCAP, en varias presentaciones, tal
como gráficos, alarmas, y tendencias históricas de los registros del comportamiento del
proceso.
Los módulos de salida realizan funciones inversas a los de entrada, ellos transforman las
señales del SCAP hacia el proceso, para que los elementos finales de control manejen las
variables manipuladas y ajusten las condiciones del proceso llevándolas al punto de
ajuste deseado que determina el modulo de control del SCAP.
Como se vio en la Figura 17 los SCAP pueden dividirse en 2 grandes filosofías o
categorías:
56
 Control Distribuido
 Control Centralizado
En el primer caso los módulos de E/S y de control están contenidos en un gabinete
localizado cerca del proceso que controla (a veces se usan cuartos satélites), que se
enlazan vía una pista de datos a través del modulo de comunicaciones, mientras que la
interface con el operador se encuentra en una cuarto de control remoto.
2.2.3. COMPONENTES DE HARDWARE (EQUIPOS).

2.2.3.1. EQUIPOS.
En los sistemas de control distribuido se requiere tener un tipo de equipos mínimo que no
dependan de la arquitectura, sino de las funciones, y otro tipo que permita hacer la
arquitectura deseada en el sistema.
En general, podemos establecer los siguientes equipos:
 Procesador de datos.
 Módulos de Entrada Analógicas (EA).
 Módulos de Entrada Digitales (ED).
 Módulos de Salida Analógicas (SA).
 Módulos de Salida Digitales (SD).
 Redes de Comunicaciones.
 Interfaz de Comunicación.
 Fuentes de Poder.
 Módulos de Entrada de Bajo Nivel
 Interface de Operador.
Además de los equipos antes mencionados, un sistema de Control Distribuido puede

tener equipos y subsistemas de respaldo en redundancia, así como equipos y
subsistemas para conectarse a otros sistemas superiores, que le permitan desarrollar
funciones de optimización y control avanzado, y aun mas, tener una red de manejo
administrativo gerencial donde la empresa, programando la producción y factibilidad de
realización de lotes de producto, con pronóstico de costos, tiempos, financiamientos,
utilidades y proyección de mercados nacionales e internacionales. Estos equipos se alzan
vía sistema de cómputo con programas especializados. [4]
57
2.2.3.2. CARACTERÍSTICAS NECESARIAS PARA LOS EQUIPOS.

Los sistemas de Control Distribuido están integrados en equipos cuyos componentes se
alojan en gabinetes que se construyen según las normas aplicables generalmente NEMA.
Los que se instalan en el campo a la intemperie, deben ser NEMA 4X, que su ambiente
G-X y que se construyen con materiales resistentes a la lluvia, corrosión, sol, etc., y que
son gabinetes herméticos con un sistema de inyección de aire limpio para enfriamiento
local.
Generalmente, los equipos de Control Distribuido tienen limitaciones ambientales que en
general serian las siguientes:
 Temperatura Máxima: 50°C
 Humedad Relativa: 95% res. condensable
 Alimentación Eléctrica: 125 VAC. libre de ruido por lo que
require acondicionamiento
 Respaldo en Falla de Energía: UPS con banco de baterías para un
Tiempo específico típicamente 30min.
 Libre de Vibración.
 Piso Falso: Tipo antiestético
 Sistema de Tierras: Separado con resistencias menor de 5Ω
 Sistema de Protección: Contra incendio, detección y extinción con
CO2 preferentemente
 Entradas/Salidas: Compatibles con la instrumentación de

Campo, y sean transmisores o elementos de
control que tengan polaridades compatibles
en tipo y nivel de voltaje
 Equipos Auxiliares: Configuradores, Diagnosticadores de

fallas, PC´s y algunas interfazss para
transmitir datos a otros equipos de marcas
distintas y características eléctricas y
protocolos diferentes
58
 Puertos de Comunicación: Universales y particulares según sea el

caso (RS-232, 422, 485) puertos seriales,
puertos paralelos también.
 E/S Digitales: Tipo estado sólido o tipo relevador
 E/S Analógicas: Alto Nivel 4-20mA dc (1-5 Vdc)
2.2.3.3. DESVENTAJAS DE UN SISTEMA DE CONTROL DISTRIBUIDO.

 Falla del Sistema. No es predecible ya que son sistemas basados en
microprocesadores.
 La falla de los módulos de entrada, introducen señales falsas al sistema que lo
llevan a responder en forma correspondiente.
 Los módulos de salida pueden fallar cortocircuitándose los equipos de estado
sólido llevando a las salidas a un estado de energización permanente.
 Los subsistemas de control que se componen de tarjetas de CPU y memoria, a
veces se ven afectados por interferencias electromagnéticas o electrostáticas, que
pueden causar paros totales repentinos en el proceso.
 Cuando hay fallas de energía, se pueden tener acciones erráticas al entrar y
funcionar el sistema de respaldo UPS, o al regresar la fuente principal de energía.
 Peligro de corto circuito con cables y posible interferencia electroestática con ellos.
Estos problemas se deben diagnosticar.
 Los módulos de comunicación pueden fallar, causando una interrupción en la
comunicación y el aislamiento de los componentes en el Sistema de Control. Se
recomienda usar redundancia por vías distintas.
 Se recomienda no usar walkie-talkies en las cercanías de los Sistemas de Control
Distribuido debido a que ocasionan interferencias.
2.3. SCADA (SUPERVISORY CONTROL AND DATA ACQUISITION)
2.3.1. ORIGEN Y EVOLUCIÓN.

Cada vez que se ha realizado el control de un sistema, grande o pequeño, ha sido
necesario tener información visual de cómo está funcionando. Así, a medida que los
sistemas de control han ido evolucionando y se han hecho cada vez más complejos, ha
aumentado también la complejidad de los elementos que proporcionan la información al
usuario.
59
Las necesidades de ver y controlar a distancia una máquina aparecían en los primeros
cuadros de control, donde multitud de luces indicaban las diferentes situaciones previstas
de la máquina. Cualquier situación imprevista, o pasada por alto, significaba varias horas
de trabajo de electricista para llevar la señal olvidada al panel de control y podía ser que
no hubiera espacio para colocar el indicador.
La aparición de la informática permitió realizar este tipo de control de manera más sen-
cilla, sin la necesidad de tener a verdaderos expertos en sistemas de automatización cada
vez que hiciera falta cambiar el ajuste de un temporizador en un sistema de control.
Los grandes cuadros de control empezaron a convertirse en monitores que podían
mostrar la misma información. Pero cualquier cambio en la presentación era más sencillo
de realizar. Bastaban unas modificaciones en el código de la aplicación para que en la
pantalla apareciera.
Vista la necesidad, varios fabricantes desarrollaron entonces paquetes de software
capaces de comunicarse con los sistemas de control existentes y permitieron así una
flexibilidad de uso no imaginada hasta el momento. Esta tendencia ha ido en aumento, de
tal manera que hoy día las opciones existentes son numerosas. Algunos de los más
conocidos se muestran en la tabla 4:
Tabla 4. Tipos de Fabricante y Software.
SOFTWARE
FABRICANTE
DISEÑADO
Intellution IF1X
Omron SCS
Siemens WinCC
Rockwell RS-View
Automation
Wonderware InTouch
GE-Fanuc Cimplicity
La evolución de los sistemas operativos ha incrementado y sus posibilidades son más

amplias, permitiendo las estructuras multipuesto gracias a los sistemas de red
informáticos.
60
Con la entrada de Internet en el mundo de las comunicaciones industriales ahora es

posible conectarse con un sistema de control situado en cualquier lugar del mundo gra-
cias a la tecnología Web-Serven un ordenador dotado de un explorador y la dirección IP
del sistema que queremos visualizar serán suficientes.
Fue entonces cuando Wonderware pudo demostrar ante los organismos competentes en
el caso que los procesos supervisados mediante su software eran seguros. Al estar
basado en Windows era sencillo de documentar y los procesos se podían representar de
manera gráfica, más fácil y segura de interpretar, mucho más que obtener una serie de
líneas de texto (DOS). Esta compañía fue la primera en cumplir las exigencias de las
agencias estatales estadounidenses. Incluso hoy día hay compañías de seguros y
empresas de Estados Unidos que recomiendan el uso de este paquete de software.
Debemos de tener en cuenta que actualmente los grandes fabricantes de sistemas HMI
ofrecen prestaciones similares.
Con la entrada de técnicas de intercambio de información entre aplicaciones, como DDE
(Dynamic Data Exchange, Intercambio dinámico de datos), se simplificó en gran medida el
desarrollo de software. En los años ochenta todo el mundo tenía sus propios desarrollos
de software, por supuesto incompatibles con el resto.
Con el auge de Windows también recibió un impulso el desarrollo de utilidades para
comunicarse con aplicaciones que funcionaban con este sistema operativo (drivers o
controladores). A partir de entonces todos los fabricantes empezaron a tomar a Windows
y a DDE como el medio para unir todas las piezas.
A mediados de los noventa aparece una versión de Visual BASIC que permite crear, con
gran facilidad, controles gráficos e interfazss de usuario gracias a utilidades ya definidas.
Colocar un botón en pantalla es simplemente eso, picar y arrastrar el botón, ya
confeccionado, hasta el lugar deseado.
2.3.2. EL SISTEMA SCADA.

Damos el nombre de SCADA (Supervisory Control And Data Acquisition) a cualquier
software que permita el acceso a datos remotos de un proceso y permita, utilizando las
herramientas de comunicación necesarias en cada caso, el control del mismo.
No se trata de un sistema de control, sino de una utilidad software de monitorización o
supervisión, que realiza la tarea de interfaz entre los niveles de control (PLC) y los de
gestión, a un nivel superior.
61
Los objetivos para que su instalación sea perfectamente aprovechada son los siguientes:
Funcionalidad completa de manejo y visualización en sistema operativo Windows sobre
cualquier PC estándar. La arquitectura abierta que permita combinaciones con
aplicaciones estándar y de usuario, que consientan a los integradores crear soluciones de
mando y supervisión optimizadas (Active X para ampliación de prestaciones, OPC para
comunicaciones con terceros, OLE-DB para comunicación con bases de datos, lenguaje
estándar integrado como VB o C, acceso a funciones y datos mediante API).
Sencillez de instalación, sin exigencias de hardware elevadas, fáciles de utilizar, y con
interfaces amigables con el usuario.
Permitir la integración con las herramientas ofimáticas y de producción.
Fácilmente configurable y escalable, debe ser capaz de crecer o adaptarse según las
necesidades cambiantes de la empresa.
Ser independiente del sector y la tecnología.
Funciones de mando y supervisión integradas.
La topología de un sistema SCADA variará adecuándose a las características de cada
aplicación. Unos sistemas funcionarán bien en configuraciones de bus, otros en
configuraciones de anillo. Unos necesitarán equipos redundantes debido a las
características del proceso, etc.
2.3.3 OBJETIVOS DE UN SCADA.

Proporciona que un sistema sea más económico ya que facilita ver qué ocurre en la
instalación desde la oficina que enviar a un operario a realizar la tarea. Ciertas revisiones
se convierten innecesarias.
A través del fácil acceso será posible modificar los parámetros de funcionamiento de cada
elemento del sistema, poniendo fuera de servicio los que den indicios de anomalías;
consultar el estado de las estaciones, detener los actuadores que no sean necesarios, la
adquisición de datos materializa la posibilidad de obtener datos de un proceso,
almacenarlos y presentarlos de manera inteligible para un usuario no especializado. La
misma aplicación se puede programar de manera que nos avise cuando se aproximen las
fechas de revisión o cuando una máquina tenga más fallos de los considerados normales
proporcionando de esta manera un fácil mantenimiento en cualquier proceso.[1]
El SCADA proporciona ergonomía que procura hacer que la relación entre el usuario y el
proceso sea lo menos rígido posible. Los modernos ordenadores, con sus prestaciones
62
gráficas, intentan sustituir a los grandes paneles, repletos de cables, pilotos y demás
paralaje informativo. Pero hay un problema que aún persiste: cómo presentar toda esa
información sin aburrir ni fatigar al usuario. Todos los datos recopilados pueden ser
valorados de múltiples maneras mediante herramientas estadísticas, gráficas, valores
tabulados, etc., que permitan explotar el sistema con el mejor rendimiento posible.
Buscando sistemas abiertos, es decir, sin secretos ni sorpresas para el integrador. La
documentación de los protocolos de comunicación actuales permite la interconexión de
sistemas de diferentes proveedores y evita la existencia de lagunas informativas que
puedan causar fallos en el funcionamiento o en la seguridad.
2.3.5. EL CONTROL A DISTANCIA.

La forma en la cual las señales se intercambian entre el sistema a controlar y el sistema
que controla. Aparece el concepto de telemetría (medida a distancia), entendido como la
transmisión a distancia de información sobre algún tipo de magnitud. Si además la
presentación de los datos se realiza de forma inteligible ya nos proporciona la base para
el desarrollo de un sistema de control y monitorización a distancia. La figura 19 ejemplifica
un control a distancia.
Figura 19. Medida a distancia.
Un ejemplo de telemetría es el control de llenado de un tanque industrial. Unos sensores

se ocupan de vigilar el nivel de agua, informando a la bomba de cuándo debe ponerse en
marcha para bombear agua al tanque, si hay nivel insuficiente en éste o cuando debe
detenerse, si el depósito está lleno o el nivel del tanque no es suficiente.
63
2.4 VISUAL BASIC 6.0.
Visual Basic es un lenguaje de programación orientado a objetos con propiedades y

métodos, pero carece de los mecanismos de herencia y polimorfismo propios de los
verdaderos lenguajes orientados a objetos como Java y C++ creado por Microsoft. La
programación en Visual Basic se basa en un ambiente de desarrollo totalmente gráfico,
que facilita la creación de interfaces gráficas, y en cierta medida, también la programación
misma incorpora todas las herramientas necesarias para la creación de cualquier
aplicación para Windows pudiendo incorporar todos los elementos de este entorno
informático: ventanas, botones, cajas de diálogo y de texto, botones de opción y de
selección, barras de desplazamiento, gráficos, menús, etc.
Eventos: Son Acciones del usuario sobre el programa tales como clicar sobre un botón,
arrastrar un icono, el elegir una opción de un menú, o simplemente mover el ratón. Cada
vez que se produce un evento sobre un determinado tipo de control, Visual Basic 6.0
comienza una determinada función o procedimiento que realiza la acción programada por
el usuario para ese evento concreto. Estos procedimientos se llaman con un nombre que
se forma a partir del nombre del objeto y el nombre del evento, separados por el carácter
(_), como por ejemplo txtBox_click.
Métodos: Son funciones que del mismo modo son llamadas desde programa, pero a
diferencia de los procedimientos no son programadas por el usuario, sino que vienen ya
pre-programadas con el lenguaje. Los métodos realizan tareas típicas, previsibles y
comunes para todas las aplicaciones. De ahí que vengan con el lenguaje y que se libere
al usuario de la tarea de programarlos. Cada tipo de objeto o de control tiene sus propios
métodos.
Proyecto: Cada aplicación que se empieza a desarrollar en Visual Basic 6.0 es un nuevo
proyecto, éste comprende otras componentes más sencillas, como por los formularios y
métodos.
Formularios: Son las ventanas de la interfaz de usuario de la nueva aplicación
2.4.1 EL ENTORNO DE PROGRAMACIÓN VISUAL BASIC 6.0
Cuando se arranca Visual Basic 6.0 aparece en la pantalla una configuración similar a la
mostrada en la Figura 20. En ella se pueden distinguir los siguientes elementos:
64
1. La barra de títulos, la barra de menús y la barra de herramientas de Visual Basic

6.0 en modo Diseño (parte superior de la pantalla).
2. Caja de herramientas (toolbox) con los controles disponibles (a la izquierda de la
ventana).
3. Formulario (form) en gris, en que se pueden ir situando los controles (en el
centro). Está dotado de una rejilla (grid) para facilitar la alineación de los
controles.
4. Ventana de proyecto, que muestra los formularios y otros módulos de programas
que forman parte de la aplicación (arriba a la derecha).
5. Ventana de Propiedades, en la que se pueden ver las propiedades del objeto
seleccionado o del propio formulario (en el centro a la derecha). Si esta ventana no
aparece, se puede hacer visible con la tecla <F4>.
6. Ventana FormLayout, que permite determinar la forma en que se abrirá la
aplicación cuando comience a ejecutarse (abajo a la derecha).
Figura 20. Entorno de programación de visual Basic
65
2.4.2 VENTAJAS
En Visual Basic se pueden realizar aplicaciones orientadas a objetos (POO), con lo que
su código será más robusto y fácilmente transferible a otros lenguajes, más sencillo de
depurar y de reutilizar en nuevas aplicaciones. Debido a que es un lenguaje muy
extendido resulta simple acceder a una gran cantidad de ayuda a través de tutoriales,
listas de correo, foros, páginas web o en forma de material impreso (libros). Además de
poder encontrar infinidad de recursos tanto gratuitos como de terceras empresas
(utilidades, controles ActiveX, código, etc.). Por todo lo anterior la creación de la interfazs
hombre maquina del proyecto es realizada a través de éste lenguaje de programación ya
que se adapta a las necesidades de un programador de aplicaciones SCADA, diseñando
su propia aplicación no estará limitado por las características de un SCADA cerrado y
suministrando al cliente aquello que éste solicite.
2.5 RSLOGIX 5000

Para la programación del PLC es necesario el uso del software de programación RSLogix
5000 compatible con la familia escalable de controladores programables de
automatización (PAC) Logix, es una plataforma que puede utilizarse para aplicaciones de
base discreta, de proceso, de lote, de movimiento, de seguridad y de variadores, permite
fragmentar la aplicación en programas más pequeños que pueden volver a utilizarse,
rutinas e instrucciones que pueden crearse al utilizar distintos lenguajes de programación:
diagrama de lógica de escalera, diagrama de bloque de funciones, texto estructurado y
diagrama de funciones secuenciales. Con el software RSLogix 5000 se puede configurar
de forma fácil y rápida la mayoría de los módulos E/S mediante los perfiles de módulo
dedicados. Además, estos perfiles permiten obtener acceso fácilmente a la información de
estado y de diagnóstico. La integración y la documentación de los datos E/S en la
aplicación es muy simple porque la configuración y el estado de los módulos E/S están
disponibles como estructuras de datos descriptivas, definidas previamente. Por tanto, no
es necesario buscar en manuales para averiguar dónde se han asignado los datos E/S en
la memoria del controlador y crear y administrar símbolos para cada ubicación de
memoria en un esfuerzo por documentar su código. Puesto que los datos de módulo E/S
se representan en el controlador también como tags, es posible hacer referencia de forma
fácil y rápida a los datos E/S en las visualizaciones de la interface operador-máquina, sin
tener que administrar otra base de datos en el software de la interfaz operador-máquina.
66
III. “DISEÑO Y PUESTA EN MARCHA DEL SOFTWARE DE

SUPERVISIÓN COMUNICADO MEDIANTE TECNOLOGÍA OPC”
Este capítulo explica la realización del software y se ahonda en su capacidad para adquirir
datos desde un controlador digital Compactlogix Allen-Bradley. Como se señalo
anteriormente la tecnología de comunicación tiene el nombre de OPC. De igual manera
dentro de este apartado se integra una aplicación práctica al diseñarse una interfaz
gráfica en Visual Basic a través de imágenes dinámicas que permiten la visualización de
los parámetros para el control de nivel de una caldera de tubos de humo. La aplicación
incluye el desarrollo de la lógica de control necesaria, programada en el controlador
digital. Así mismo se exponen todas las consideraciones de proceso necesarias para el
desarrollo óptimo del proyecto
67
3.1 HERRAMIENTAS A UTILIZAR

OPC se ha convertido en un estándar industrial ampliamente utilizado para la
comunicación entre aplicaciones. La base fundamental para OPC es DCOM, esta
enormemente probada en campo, es estable y está diseñada bajo la plataforma de
Microsoft, que es la plataforma predominante en control de procesos para la capa LAN y
superiores [17].
Como se reviso en el capítulo 1, el software que permite la lectura y escritura de datos en

un PLC por OPC se conoce como software cliente. De igual forma se requiere de un
software servidor que funcione como interfaz hacia los clientes, al convertir el formato de
intercambio de datos en uno estandarizado lo cual se logra con la tecnología DDE de
Microsoft.
En primer lugar se opto por realizar toda la programación con el lenguaje Visual Basic,
desde algoritmos de prueba hasta la presentación final del software, esto gracias a su
confiabilidad, estabilidad y facilidad de programación.
Dado que el proyecto está orientado a mostrar la interoperabilidad lograda mediante OPC,
es necesario emplear esta herramienta dentro de una aplicación industrial, además de
que sin ella el código de programación se vuelve inteligible para toda aquella persona que
no tenga conocimiento amplio en programación. En lo que a las herramientas de
hardware respecta, el uso de un controlador digital Allen-Bradley que posea un puerto de
comunicación RS-232 o Ethernet es suficiente para la ejecución de la lógica necesaria
para mantener controlado el proceso o problema planteado. Se opto por la utilización de
un PLC Allen-Bradley debido a su facilidad de adquisición.
Así mismo resulta necesaria una computadora personal con sistema operativo Windows
XP profesional, donde se instalen los paquetes de software necesarios tanto para el
enlace del PLC con la computadora así como la programación de la lógica de control.
Los elementos tanto de hardware como de software seleccionados para la realización del
proyecto se muestran en la tabla 5.
68
Tabla 5. Elementos utilizados en el desarrollo del proyecto.
Computadora Personal con Microsoft

Windows XP Professional
Software Visual Basic 6.0
Software RSLinks Classic v 2.52.00
Software RSLogix 5000 v 13.0
PLC Compactlogix L32E (Fuente y CPU)
3.2 DESCRIPCIÓN DEL PROCESO A CONTROLAR

Con el fin de demostrar la eficiencia de OPC, se presenta su aplicación para el monitoreo
y control de nivel en una caldera de tubos de humo.
Las calderas de vapor se utilizan en la mayoría de industrias debido a que muchos

procesos emplean grandes cantidades de vapor. La caldera se caracteriza por una
capacidad nominal de producción de vapor en Kg/h a una presión especificada, por lo cual
se deben cumplir los siguientes puntos durante su operación:
a) aportar una energía calorífica suficiente en la combustión del fuel-oil o del gas
con el aire.
b) desde el punto de vista de seguridad, el nivel de agua debe estar controlado y
mantenido dentro de unos límites.
c) es necesario garantizar una llama segura en la combustión.
d) el sistema de control debe ser seguro en la puesta en marcha, en la operación
y en el paro de la caldera.
La caldera que se utiliza para ejemplificar debe entregar vapor saturado a la salida, para
que esto sea posible deberá existir un suministro de agua hacia la caldera con la mínima
cantidad de oxigeno disuelto, así como alimentación de combustible que nos proporcione
la energía necesaria para calentar el agua y además un flujo de aire proporcional al poder
calórico del combustible.
69
En la figura 21 se explica de manera sencilla como se podría controlar la cantidad de

vapor que se produce al calentar agua contenida en un recipiente, a partir de su
calentamiento por la combustión de gas.
Figura 21. Ejemplo de control en una caldera
Considerando lo anterior, la caldera cuenta con dos lazos principales de control:
- Control de Combustión
- Control de Nivel
Sin embargo, dado que la finalidad es demostrar la eficiencia e interoperabilidad que OPC
brinda a las comunicaciones, bastara con enfocar solo el lazo de control de nivel.
Control de Nivel
• Objetivos:
– Controlar el nivel del agua en la caldera al modular la válvula de control del

agua de alimentación.
– Evitar daños térmicos que se presentarían si el nivel bajo de agua

descubre los tubos verticales, y no existe enfriador en los tubos del horno.
70
- Evitar choque térmico y golpe de ariete ya que el nivel alto de agua inunda
los separadores de vapor, y el agua entra en los tubos de vapor de alta
velocidad pudiendo provocar dichos fenómenos.
La capacidad de producción de vapor está vinculada a la potencia de diseño de la

caldera, y en el proyecto se planteo una caldera de mediana potencia (6,000 a 15000
Kg/h), la demanda exacta de proceso se propuso como constante 12480 Kg/h lo cual
equivale a 208 Kg/s, esto por fines prácticos que nos permitirán enfocarnos en los
objetivos del proyecto.
3.2.1 DIAGRAMA DE TUBERÍAS E INSTRUMENTACIÓN
El tipo de sistema de control recomendada para calderas de mediana capacidad tiene el

nombre de regulación de nivel de dos elementos y como lo ilustra la figura 22 se logra
con un controlador de caudal de vapor y un controlador de nivel cuyas señales de salida
se comparan en un relé de relación que actúa directamente sobre la válvula de control del
agua de alimentación. El Diagrama de Tuberías e Instrumentación para el lazo de control
de nivel de la caldera.
Figura 22. DTI para el control de nivel en la caldera
71
Un control de nivel óptimo se puede obtener mediante un medidor de presión diferencial,

la primera toma censa la presión del vapor mientras que la toma inferior mide la presión
de salida del vapor más la presión ejercida por el líquido que está siendo calentado, de
esta forma la diferencia de presiones resulta ser la presión que el liquido contenido en el
tanque ejerce por la fuerza de gravedad. Además con el fin conocer la demanda de vapor
se coloca un medidor de flujo, normalmente placa de orificio, que podría ser necesario si
se presentan variaciones moderadas en la demanda, lo cual no aplica para este proceso,
en este caso el medidor de caudal se utiliza con el objetivo último de simular el monitoreo
de caudal en la estación de control.
3.3 ESTRATEGIA DE CONTROL

El algoritmo de control propuesto para ejemplificar el monitoreo está dividido en dos
modos principales, control automático y control manual.
3.3.1 CONTROL AUTOMÁTICO

Cuando el permisivo automático se encuentre activado, el nivel de la caldera deberá
mantenerse dentro de los límites seguros, estos se calculan a partir del valor ideal de nivel
que es la mitad de la escala, el rango que queda comprendido dentro de los límites se
nombro histérisis la cual es indicada por el operador. La válvula FV-16 que regula el
caudal de alimentación de agua se cerrara automáticamente en el momento que se
alcance el límite superior de nivel y se abrirá cuando disminuya al límite inferior. Durante
el modo automático el control manual de la válvula se encuentra desactivado.
3.3.2 CONTROL MANUAL

Si el permisivo automático se encuentra desactivado, la apertura o cierre de la válvula
FV-16 deberá ser manipulable por el operador y al igual que en el control automático, el
nivel de la caldera dependerá de la cantidad de agua a presión que la válvula permita
pasar en función del tiempo. Sin embargo por seguridad los límites de nivel no se deben
descuidar y es por esta razón que una vez alcanzado el límite superior de nivel el
controlador forzara el cerrado de la válvula, por otra parte, si el nivel alcanza el límite
inferior, el controlador de nivel deberá forzar el apagado de los quemadores de la caldera
y mantener la válvula cerrada.
72
3.4 LÓGICA DEMOSTRATIVA PARA EL CONTROL DE PROCESO

Diagrama ladder (escalera) es un lenguaje de programación que permite representar
gráficamente el circuito de control de un proceso dado mediante el uso simbólico de
contactos N.A. y N.C., temporizadores, contadores, registros de desplazamiento, relés,
etc. este tipo de lenguaje debe su nombre a su similitud con los diagramas eléctricos de
escalera, es decir, el circuito eléctrico se pasa a diagrama de escalera.
Se debe recordar que mientras que en el diagrama eléctrico todas las acciones ocurren
simultáneamente, en el programa se realizan en forma secuencial, siguiendo el orden en
el que los rungs (escalones) fueron escritos, y que a diferencia de los relés y contactos
reales (cuyo número está determinado por la implementación física de estos elementos),
en el PLC podemos considerar que existen infinitos contactos auxiliares para cada
entrada, salida, relé auxiliar o interno, etc.
3.4.1 CONSIDERACIONES PARA EL DESARROLLO DE LA LÓGICA.
Cerrado (XIC). La instrucción XIC examina el bit de datos para considerar si se cierra.
Abierto (XIO). La instrucción de XIO examina el bit de datos para considerar si se abre.
La salida se energiza (OTE). Cuando se permite la instrucción de OTE, el regulador fija el

bit de datos. Cuando la instrucción de OTE es interrumpida, el regulador despeja el bit de
datos.
Cierre de la salida (OTL).Cuando está permitido, los sistemas de instrucción de OTL da

un bit de datos. Da un bit de datos fijados hasta que se despeje, típicamente por una
instrucción OTU. Cuando está inhabilitada, la instrucción de OTL no cambia el estado del
bit de datos.
73
La salida abre (OTU).Cuando está permitida, la instrucción OTU despeja el bit de datos.
Cuando está inhabilitada, la instrucción OTU no cambia el estado del bit de datos.
Límite (LIM). La instrucción de LIM prueba si el valor de la prueba está dentro del rango,
del límite bajo al límite alto.
Igual a (EQU). La instrucción de EQU prueba si la variable A es igual a la variable B.
Menos que (LES). La instrucción de LES prueba si la variable A es menos que la variable
B.
Mayor que (GRT).La instrucción de las GRT prueba si la variable A es mayor que la
variable B.
74
Menos que o igual (LEQ). La instrucción de LEQ prueba si la variable A es menor que o
igual a la variable B.
Mayor que o igual (GEQ).La instrucción de GEQ prueba si la variable A es mayor que o
igual a la variable B.
Mover (MOV). La instrucción MOV copia la variable a un destino. Sigue existiendo la

variable sin cambiar.
Contador de tiempo a retardo (TON). La instrucción de TON es un contador de tiempo que

acumula el tiempo en que se permite la instrucción (escalón - condición - es verdad).
Contador ascendente (CTU). Cuando está contando y se acciona el .CU, la instrucción de

CTU incrementa el contador por uno. Cuando está inhabilitado, la instrucción de CTU
conserva su valor de .ACC.
75
Contador Descendente (CTD). La instrucción de CTD se utiliza típicamente con una

instrucción de CTU que se refiera a la misma estructura contraria. Cuando está contando
y se acciona el .CU, la instrucción de CTU decrementa el contador por uno. Cuando está
inhabilitado, la instrucción de CTU conserva su valor de .ACC.
Reset (RES).La instrucción del RES reajusta una estructura del contador de tiempo o del
contador.
Una vez establecidas las instrucciones a utilizar, se explica la programación. En esta se

crean variables compartidas con la programación de Visual Basic y su misma magnitud la
que se transmite de la interfaz al controlador o viceversa. Como ejemplo tenemos la
variable de encendido que se considera una variable de entrada ya que su valor es
cambiado por el usuario desde la interfaz, por otro lado tenemos la variable nivel que es
una variable de salida ya que su valor es generado por el controlador y enviado hacia la
interfaz. Estas variables deben tener una buena coordinación para que la comunicación
sea correcta. La lista de variables se enuncia a continuación:
 Encendido.
Variable de salida booleana (0 Apagado ó 1 Encendido).
 Automático.
Variable de salida booleana (0 Manual ó 1 Automático).
 Nivel.
Variable de entrada (100 a 900)
 Histerisis LL.
Variable de salida analógica (Creada y controlada por el usuario).
 Histerisis HH.
Variable de salida analógica (Creada y controlada por el usuario).
 Flujo.
Variable de entrada constante (208).
 Mando Válvula.
76
Variable de salida booleana (Tiempo de apertura de la válvula (1min.)).

 Válvula Abierta.
Variable de entrada booleana.
 Válvula Cerrada.
Variable de entrada booleana.
 Quemador.
Variable de entrada booleana constante.
3.4.2 DIAGRAMA DE ESCALERA EN RSLINKS 5000.

A continuación se explica la programación realizada a través del RSlinks5000 respecto al
diagrama ladder dando referencia a las variables establecidas que se relacionan tanto en
RsLinx5000 con Visual Basic.
En el programa es utilizado un contacto de Encendido (XIC) para controlar todo el

proceso, seguido de un contacto de Automático (XIC y XIO) el cual será activado cuando
se establezca un estado verdadero, es decir, uno lógico, por el contrario cuando haya un
estado falso o un cero lógico dará pie al modo Manual.
Una vez establecido estas variables se utiliza un contador de tiempo “Timer Auto” (TON)
utilizando una instrucción .DN para accionar un contador ascendente y descendente
“Contador Auto (CTU y CTD), teniendo en cuenta un RES para el “Timer Auto”.
Con el “Contador Auto” es utilizada la instrucción .ACC esta acción es movida mediante
MOV en donde se crea una nueva variable Nivel. Con esta nueva variable da el
accionamiento a un par de instrucciones (LEQ y GEQ) que hacen la comparación de Nivel
con dos nuevas variables Histerisis HH (LEQ) y Histerisis LL (GEQ) que energizan una
salida (OTE) correspondientes, dichas salidas son Alarma HH y Alarma LL.
Con respecto al modo Automático y el modo Manual se establecen condiciones para que
trabajen por separado pero energizando las mismas salidas tanto a Alarma HH y Alarma
LL sin afectar el uno del otro.
Una vez establecido lo anterior, se procede a accionar dos alarmas más Alarma H y
Alarma L, ambas utilizadas en mando Automático y Manual.
77
En modo Manual está condicionado a trabajar en cualquier momento esto es que una vez
abierta la válvula el nivel sube y en cualquier momento se puede interrumpir y cerrar la
válvula y el nivel descenderá y viceversa, esta acción es para demostrar el control que
conlleva el tanque, esta mas que mencionar que tanto en el mando Manual como en el
mando Automático cualquiera puede entrar sin perturbar al otro.
A continuación se crea una nueva variable llamada Flujo que no es más que una
constante para mostrar el Flujo de salida del proceso de nivel de la caldera.
En seguida se establece tanto para el modo Automático y el modo Manual, el cierre o

apertura de la válvula para controlar la variable Nivel conjunto a una nueva variable
llamada Mando Válvula. Se utilizan 2 contadores de tiempo (TON) “Timer Válvula Auto” y
“Timer Válvula Manual”, para llevar a un contador (CTU y CTD) “Contador V” con un
tiempo de 1min., se vuelve a utilizar la instrucción del contador .ACC que se mueve
mediante un MOV a una variable llamada Posición que mediante un EQU hace una
comparación con respecto a Posición para accionar las variables faltantes Válvula Abierta
y Válvula Cerrada que hacen el control de nivel para saber en qué momento se debe de
llenar el tanque o en qué momento se vacía esté con ciertas condiciones. Se estableció
una variable mas llamada Válvula Intermedia para poder manipular o tener el
accionamiento en modo Automático cuando se desee cambiar la Hiterísis en cualquier
momento sin afectar dicho funcionamiento.
Por último se implanta una última variable Quemador que en modo Automático siempre
estará en verdadero y en modo Manual estará en condición de la Alarma LL.
El código de control programado en el
3.5 DISEÑO DE LA INTERFAZS GRÁFICA PARA EL MONITOREO Y CONTROL DE

NIVEL.
Una vez que se conocen con precisión tanto las especificaciones del proceso así como la
lógica de control programada en el controlador digital se puede diseñar la interfaz gráfica
capaz de cubrir por completo las necesidades de monitoreo y control supervisorio. El
seguimiento de este orden de diseño es imprescindible ya que el diseño de la Interface
Hombre Maquina (IHM) depende totalmente de la estrategia final de control además de
78
todos los aspectos que se creen necesarios para el optimo monitoreo y control del
proceso.
Los requerimientos de comunicación entre IHM y el controlador son definidos por el tipo y
cantidad de información, es decir los valores de las variables de interés que en un
momento dado son leídos o escritos en el mapa de memoria del PLC. Las variables de
entrada y salida se seleccionan a su vez al analizar la estrategia y la lógica de control,
tomando siempre como punto de partida la seguridad del sistema a la hora de definir la
información necesaria en el IHM.
3.5.1 ESTRUCTURA
El primer paso en el desarrollo de la interface es el diseño de la apariencia gráfica de la
misma, para ello se integran todas las imágenes y componentes Active-x que mejor
representen el proceso, tomando el diagrama de tuberías e instrumentación y agregando
además elementos para visualización de valores numéricos, interruptores y botones
necesarios para que el usuario tome acción en el control del proceso y en el manejo de la
información.
En total la interfaz gráfica está conformada por cuatro ventanas: una página principal y
tres ventanas auxiliares que contienen componentes adicionales de información y mando.
a) Ventana principal: Es el soporte para todas las funciones que la interfaz en su

totalidad permitirá al usuario realizar, por esta razón su diseño debe poseer
flexibilidad en el acceso y claridad en la información desplegada. Contiene la
animación del proceso así como información más importante para el operador.
b) Selección de Modo de Control: La ventana para selección de modo de control
se diseño con dos botones, correspondientes a la selección de modo
automático o modo manual, además cuando el sistema se encuentra
trabajando en modo manual se integra un cuadro de texto que permite el
cambio para el valor de la histérisis con respecto al punto de ajuste.
c) FV-16 válvula de llenado: Esta ventana contiene información sobre la posición
en tiempo real de la válvula y durante el funcionamiento en modo manual
aparecen los botones de mando para la apertura o cierre de la misma.
79
d) FT-16 medidor de vapor de salida: Debido a que la demanda de vapor es

constante, esta ventana únicamente muestra el valor del flujo de vapor de
salida.
Cada una de las ventanas y sus componentes se encuentra siempre en constante

comunicación con el controlador con la finalidad de tener en pantalla información actual
de lo que sucede en el proceso.
a) Ventana Principal – BL-10 Pagina de Control

En la figura 23 se presenta la estructura final de diseño para esta ventana, a continuación
se explica la función de cada uno de sus componentes:
1. Botón para envió de datos a Microsoft Excel: Esta parte opcional de la interfaz
permite el envió de información a una hoja de cálculo de Excel con un solo click
izquierdo.
2. Marco para presentación del valor de nivel: Este marco contiene dos cuadros de
texto que muestran la magnitud del nivel en milímetros y el porcentaje de llenado
para un instante dado.
3. Alarmas: Cuatro indicadores de alarma en el nivel, la señalización low (L) se
activara cuando el nivel sea menor o igual al 20% de la escala total, la alarma
low-low (LL) lo hará cando el nivel sea menor al 10%, la indicación high (H)
encenderá cuando el nivel sobrepase el 80% de la escala, mientras que la
señalización high-high (HH) lo hará cuando sobrepase un 90%.
4. Medidor de Flujo (FT-16): Esta imagen representa el medidor de presión
diferencial que obtiene la magnitud de flujo en un momento dado, además se
programo para que al hacer click sobre él se despliegué la ventana FT-16 medidor
de vapor de salida.
5. Válvula de llenado (FV-16): Esta imagen permite el acceso a la ventana FV-16
Válvula de llenado al colocar el cursor sobre ella y pulsar el botón izquierdo del
mouse. Este componente active-x se programo con tres colores diferentes que
permitirán conocer el estado de la misma; rojo indica que la válvula se encuentra
80
cerrada, el amarillo significa que la válvula está en movimiento, y el azul que la

válvula se encuentra abierta.
6. Medidor de Nivel (LT-16): La imagen representa un sensor-transmisor de presión
diferencial para la toma de nivel.
7. Caldera (BL-10): Se trata del equipo industrial principal ya que es a este al que se
controla el nivel de agua, la imagen active-x cuenta con animación para cambiar
de color, dependiendo de que el estado del interruptor de arranque de simulación
este encendido y del estado del permisivo LL en modo manual, este ultimo envía
una señal al controlador de los quemadores para cesar el flujo de combustible y
aire. Cuenta además con una mira hacia el interior del tanque.
8. Selección de modo de control: Se trata de un botón que funciona como vinculo con
la ventana de selección de modo de control, además cuenta en la parte inferior
con dos indicadores que son accionados en concordancia con el modo de control
actual del sistema ya sea manual o automático.
9. Botón para encendido o apagado de la simulación: Son imágenes que con ayuda
del código de programación se animaron para su alternancia en caso de hacer
click izquierdo sobre una u otra. Esta condición marca el encendió o interrupción
de la simulación únicamente ya que la comunicación entre el IHM existe todo el
tiempo.
81
Figura 23. Ventana principal
b) Ventana para selección del modo de control

En la figura 24 se presenta la estructura final de diseño para esta ventana, a continuación
se explica la función de cada uno de sus componentes:
1. Indicador de modo de actual de operación: Mediante texto alternado por código de

animación, este marco presenta el modo de trabajo en un instante dado.
2. Botón de selección automático: Al presionar el botón izquierdo con el cursor sobre
él, pasa del sistema a modo de control automático.
3. Botón de selección manual: Al hacer click izquierdo con el cursor sobre este botón
permitirá el cambio a modo de control manual.
4. Histérisis actual: Está compuesto por un cuadro de texto que permite el cambio de
la magnitud de la histérisis siempre y cuando se encuentre dentro del rango 2-
800mm, que es el rango seguro de operación y únicamente aparecerá cuando se
encuentre en modo automático.
82
Figura 24.Ventana para selección de modo de control
c) FV-16 – Válvula de llenado
Los componentes para la ventana de válvula de llenado se muestran en la figura 25 y se

describen en seguida:
1. Indicadores en modo automático: El marco contiene dos indicadores que trabajan
únicamente durante modo automático, el primero será de color verde si el nivel
del agua se encuentra dentro de los limites seguros, es decir en el rango 100 a
900 mm, si se encuentra fuera de estos límites se presentara como luz amarilla
intermitente. La segunda lámpara indica si el sistema se encuentra trabajando en
modo automático.
2. Indicadores en modo manual: al igual que el anterior este marco contiene dos
indicadores que trabajan cuando el modo automático esta deshabilitado, la primer
lámpara será verde si el nivel en la caldera se encuentra dentro de los limites
seguros, de no ser así será una luz intermitente amarilla. La segunda lámpara
indica si el sistema se encuentra trabajando en forma manual.
83
3. Posición actual de la válvula: El marco muestra la posición de la válvula en un

instante determinado, existen tres posibilidades, que se encuentre abierta,
desplazándose o cerrada. Lo anterior se logra mediante la programación de texto
alternado.
4. Botón para apertura de la válvula: Cambia la variable de mando a verdadero al
hacer click izquierdo sobre ella, este botón al igual que el cierre únicamente
aparecen durante el modo manual.
5. Botón para cierre de la válvula: Cambia la variable de mando a falso, es decir
cierre, al presionar el botón izquierdo con el cursor sobre este botón.
Figura 25.Ventana de válvula de llenado
d) FT-16 – Medidor del vapor de salida

La figura 26 muestra la apariencia de la ventana, esta contiene la magnitud de la
demanda de vapor, que como se indicó es una constante de 208 Kg/s.
84
Figura 26.Ventana de medidor de flujo
3.5.2 CÓDIGO PROGRAMADO

A partir de la estructura gráfica diseñada se comienzan a establecer las variables a utilizar
para el manejo de la información dentro del programa, definiendo su tipo de variable y
nombre apropiados. Visual Basic permite el uso de 11 tipos de variables diferentes. El
código programado para esta aplicación únicamente requirió del uso los siguientes tipos
mostrados en la tabla 6:
Tabla 6. Tipos de variables utilizadas durante la programación.
Las variables son de entrada o salida con respecto al sistema de control y dependiendo
de si su valor es leído o escrito por el cliente OPC integrado en el software de supervisión.
Las variables que deberán encontrarse en comunicación constante con el controlador se
clasifican enseguida.
85
Datos de entrada:
1. nivel: Definido como entero largo, representa la magnitud de nivel medido por el
instrumento LT-16, montado en la caldera.
2. flujo: Definido como entero largo, representa los Kg/s de flujo de vapor que salen
de la caldera y que son censados por el medidor FT-16.
3. zso: Definido como booleano, representa el interruptor de completa apertura de la
válvula FV-16, abierto (0) o cerrado (1).
4. zsc: Definido como booleano, representa el interruptor de cierre completo de la
válvula FV-16, abierto (0) o cerrado (1).
5. qmador: Definido como booleano, representa el estado encendido (1) a apagado
(0) del quemador de la caldera BL-16.
Datos de salida:
1. hh: Definido como entero largo, representa el rango de límite superior a partir del
punto de ajuste, este valor es definido al dividir el valor de la histérisis entre dos.
2. ll: Definido como entero largo, representa el rango de límite inferior a partir del
punto de ajuste, este valor es definido al dividir el valor de la histérisis entre dos.
3. autom: Definido como booleano, representa el modo de trabajo del sistema,
manual (0) o automático (1).
4. mandov: Definido como booleano, representa la orden del operador hacia la
válvula, ya sea abrir (1) o cerrar (0)
5. encendido: Definido como booleano, representa el la orden de encendido (1) o
apagado (0).
El código para la definición de las variables comunes es el siguiente:
El código programado para la aplicación se divide, por subrutinas, en cuatro principales.
1. Private Sub Timer1_Timer(): Ejecuta el código para la comunicación con el

servidor OPC además de la actualización constante de los ítems de entrada y
salida que son asociados a su variable correspondiente. Puede ejecutarse en
86
un intervalo de hasta 1 milisegundo lo que proporciona una visualización en

tiempo real.
2. Private Sub Timer3_Timer(): Una vez asociadas las magnitudes de los Items a
cada una de las variables este Timer se encarga de ejecutar el código que
actualiza los componentes que dependen de estas variables, como por ejemplo
la visualización del nivel dentro de la caldera. Así actualiza todos los
componentes gráficos de la interfaz para permitirle al usuario tomar decisiones
basadas en información actualizada.
3. Private Sub Timer2_Timer(): Subrutina que se encarga de el envio a Microsoft
Excel de las variables hora, flujo, nivel, porcentaje de llenado, esto se efectúa
cada determinado intervalo de tiempo marcado por la función timer, que Visual
Basic ofrece.
4. Private Sub Form_Load(): Cada una de las tres subrutina anteriores es
soportada gracias a la subrutina de inicio o form_load(), que se encarga de
proporcionar los valores iníciales de variables, establece la comunicación con
RSLinx para comunicación OPC, inicia Microsoft Excel y proporciona las
condiciones para el arranque del programa.
El código completo se puede consultar en el Apéndice B de este trabajo.
3.5.3 ALGORITMO INTEGRADO A LA IHM PARA LA CONECTIVIDAD POR OPC

Durante la programación se integró en la interfaz el algoritmo que hace posible la
comunicación con el controlador, con la ayuda también del software RS Linx, esta
comunicación se consigue mediante un conjunto de instrucciones en Visual Basic que
generan un servidor, el cual es enlazado dentro de la misma aplicación al cliente para el
acceso a los datos. El servidor está conformado por uno o más grupos y cada uno de
ellos posee a su vez uno o más ítems, estas son las bases de conexión por OPC. En el
capítulo uno se explica el método de acceso a la información por parte de los clientes y
servidores OPC.
Primeramente antes de iniciar el desarrollo del código es necesario establecer un nodo de

comunicación entre la computadora y el controlador digital. Específicamente en este
87
proyecto, para que exista comunicación entre la computadora y el PLC Compact Logix es
necesario establecer la red en este caso Ethernet y su medio físico para transmisión de
datos el cable UTP. Esto componentes fueron elegidos debido a la eficiencia y velocidad
de comunicación además de su rentabilidad.
Una vez establecido el medio de comunicación RS-Linx permite enlazar el controlador

digital con la computadora, para ello se deberá configurar el driver para Ethernet/IP. La
primera información que resulta necesaria es la dirección IP que tiene asignada el
controlador, así como la máscara de subred que se establece al asignar la dirección IP de
la computadora. Esto deberá ser introducido en la ventana de configuración del driver
como se muestra en la figura 27.
Figura 27. Configuración del driver
RS Linx permite una sencilla configuración de un OPC topic, el cual funciona como enlace
hacia el mapa de memoria del controlador y así conocer la dirección de acceso que
permitirá al software diseñado el acceso al controlador con el fin de leer o escribir valores
88
en dichas direcciones. En la figura 28 se muestra la forma de crear un OPC topic desde

RS Linx Classic.
Figura 28. Configuración de un OPC Topic
La dirección en el mapa de memoria del controlador para accesar a las variables de

interés se obtiene al ingresar a la opción copy DDE/OPC link en el menu Edit, la figura 29
explica el contenido de interés en esta ventana.
89
Figura 29. Vínculos DDE/OPC de las variables en de control
Las funciones de programación de Rs linx OPC Automation es una versión simplificada de

OPC Data Access. Esta interfaz facilita a las aplicaciones clientes de automatización el
comunicarse con numerosas fuentes de datos. Además permite al cliente de Visual Basic
escribir la mínima cantidad de código para leer o escribir los cambios de datos.
El código para definición de la estructura básica de OPC necesaria para la aplicación se

enuncia a continuación:
Dim servidor As RsiOPCAuto.OPCServer

Dim WithEvents grupos As RsiOPCAuto.OPCGroups
Dim Item1, Item2 As RsiOPCAuto.OPCItem
Dim WithEvents grupo As RsiOPCAuto.OPCGroup
Dim arItemIDs() As String
Dim arClientHandles() As Long
Dim arServerHandles() As Long
Dim arErrors() As Long
Dim i As Long
Dim lIndex As Long
90
Dentro de la rutina inicial de la aplicación se deberá inicializar la conexión la conexión del

servidor, en este caso el objeto tiene el mismo nombre como se observa enseguida:
Set servidor = New OPCServer

servidor.Connect "RSLinx OPC Server" “Conexión con el servidor OPC
Set grupo = servidor.OPCGroups.Add("g1")
grupo.UpdateRate = 10 „„tiempo de actualización del grupo en milisegundos
grupo.IsActive = True
grupo.IsSubscribed = True
grupo.ClientHandle = 1
Se redimensionan los arreglos para leer las etiquetas, en la aplicación desarrollada son 10
las variables, por lo que de igual manera se agregaron 10 arreglos:
ReDim arItemIDs(1 To 10)

ReDim arClientHandles(1 To 10)
Se direccionan los arreglos para la sincronización de la información entre la aplicación y el

controlador. El link consiste en la combinación del Topic con la dirección de los ítems, en
este caso las variables:
'ENTRADAS'
arItemIDs(1) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Nivel,L1,C1" 'NIVEL
arClientHandles(1) = 1
arItemIDs(2) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Flujo,L1,C1" 'FLUJO
arItemIDs(3) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Valvula_Abierta,L1,C1" 'SWITCH
ZSO
arItemIDs(4) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Valvula_Cerrada,L1,C1" 'SWITCH
ZSC
arItemIDs(5) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Quemador,L1,C1" 'QUEMADORES
'SALIDAS'
arItemIDs(6) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Histerisis_HH,L1,C1" 'LIMITE
SUPERIOR
91
arItemIDs(7) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Histerisis_LL,L1,C1" 'LIMITE

INFERIOR
arItemIDs(8) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Encendido,L1,C1" 'ENCENDIDO
arItemIDs(9) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Automatico,L1,C1" 'SELECTOR
AUTO-
MANUAL
arItemIDs(10) = "[Control_de_Nivel_de_Caldera]Program:MainProgram.Mando_Valvula,L1,C1" 'MANDO
DE VALVULA
3.6 PUESTA EN MARCHA DEL SISTEMA

Para correr la aplicación se pulsa el botón start en el menú run esto iniciara en un
principio la compilación del programa y aparecerá la ventana principal de la interfaz. Al
iniciar la aplicación es necesario que la comunicación entre el controlador y la
computadora se encuentre habilitada, de ser así el software creado comenzara a
intercambiar la información de las variables con el controlador. El software para
adquisición de datos y control supervisorio diseñado es sencillo y funcional, ya que
muestra en todo momento y de manera clara el estado del proceso, no importando la
cantidad de ventanas que se encuentren abiertas, Porque cada ventana proporciona
información básica, además de la información sobre la función específica que cubre.
3.6.1 FUNCIONAMIENTO EN MODO MANUAL

En primer lugar se realizo la prueba de control en modo manual, el cual se estableció
predeterminadamente para el inicio de la aplicación (fig. 30).
92
Figura 30. Estado inicial de la interfaz
El estado inicial del nivel depende de la señal recibida desde el controlador y se puede
verificar en el software de programación del PLC que es RSLogix 5000 (fig. 31). Teniendo
lo anterior en cuenta, si la magnitud de la variable nivel es 100 mm el software
programador debe tener el mismo valor en la interfaz grafica diseñada, lo cual se puede
verificar en la figura 30.
93
Figura 31. Estado inicial del controlador de proceso
Una vez iniciada la simulación mediante el interruptor ON/OFF que aparece en la interfazs
son habilitados los botones y vínculos para su uso. En la ventana de selección de modo
que se muestra en la figura 32, se observa que no aparece el cuadro de texto para el
cambio en el valor de la histérisis, debido a que solamente se es posible su uso durante el
modo automático.
94
Figura 32. Ventana de selección de modo de control.
Como se explico previamente durante el funcionamiento en modo manual es posible

manipular el estado de la válvula en sus dos posiciones mediante la ventana que se
despliega al hacer click izquierdo sobre la válvula.
Figura 33. Estado inicial Del mando de la válvula
95
Con el fin de probar el correcto funcionamiento del mando se abrió la válvula desde la
estación de control como se muestra en la figura 34. El color azul de la válvula indica que
se encuentra completamente abierta, para llegar a este estado ha sido necesario un
periodo de transición que se expondría con el color amarillo de la válvula.
Figura 34. Válvula FV-16 abierta manualmente
En el momento en que el nivel en la caldera llega a un punto seguro, es decir superior a

100 mm se inicia la simulación de encendido en los quemadores, así como la demanda de
vapor saturado. Para conocer el flujo de vapor que registra el sensor en un momento dado
se pulsa el medidor de flujo apareciendo la ventana mostrada en la figura 35.
Figura 35. Demanda de vapor
96
Una vez que el nivel ha alcanzado un valor elevado, es decir igual o superior a 900 mm el
controlador forza el cierre de la válvula, la cual se vuelve de color amarillo indicando su
transición (fig. 36) y en cuanto se esté completamente cerrada el nivel comenzara a
descender debido a que la demanda de vapor sigue existiendo y es constante.
Figura 36. Forzado de cierre de la válvula
Otra función opcional que ofrece el software es el envió de datos a una hoja de cálculo de
Microsoft Excel, presionando un solo botón, la aplicación se encargara de enviar los
valores de las variables de interés repetitivamente sobre una misma columna. El intervalo
de intermitencia entre envió de información se programa dentro del código de la interfazs.
El valor seleccionado para la intermitencia de datos es 2 seg, debido a que los cambios
de la variable nivel son lentos y no requieren de un monitoreo más minucioso.
Los datos exportados a Excel para este ejercicio se muestrearon cuando el nivel se
comportaba de forma descendente desde 700 hasta 100 mm que es el nivel mínimo. Esta
información se muestra en la figura 37.
97
Figura 37. Exportación de las variables de proceso a Excel
Con la válvula cerrada y el nivel decreciendo, llega el momento en que el mismo alcanza
el límite inferior seguro de 100 mm, lo que conlleva a que la caldera se apague
volviéndose color gris en la animación (fig. 38). De esta forma el sistema queda en espera
de alguna orden más del usuario enviado a través de la interfaz grafica.
98
Figura 38. Forzado del apagado de los quemadores
3.6.1 FUNCIONAMIENTO EN MODO AUTOMÁTICO
Con el proceso encendido, la prueba de control en modo automático comienza con el

paso del sistema a este modo. En la Figura 39 se aprecia que una vez que se ha pulsado
el botón de automático aparece el cuadro de texto que permite el cambio de valor de la
histérisis, el valor inicial para esta misma es 800mm y no habrá forma de excederse de
este valor ya que el software corrige inmediatamente cualquier valor superior a este. Así
mismo en caso de la presencia de un valor inferior a 2 mm el sistema lo convertirá en 2
mm con el fin de evitarla indeterminación de los limites.
99
Figura 39. Activación del modo automático de control
Con la finalidad de demostrar el correcto funcionamiento en un rango diferente del

preestablecido, se propone una histérisis de 100, el valor se captura y se pulsa el botón
aplicar para que entre en función (Fig. 40).
Figura 40. Aplicación de la nueva histérisis
100
Desde el momento en que se activa el modo automático se comienza a abrir la válvula

para alimentación de agua y el nivel dentro de la caldera comienza a incrementar, esto se
puede observar en la Figura 41.
Figura 41. Nivel bajo en la caldera
Debido a que el punto de ajuste para el control de nivel es 500 mm y después de haber
aplicado una histérisis de 100 mm, el cálculo de los límites superior e inferior resulta ser
de 550 y 450 respectivamente. Por esta razón al alcanzarse este valor la válvula
comienza a cerrarse (Fig. 42).
De la misma forma que en modo manual, una vez cerrada completamente la válvula, el
nivel de agua comenzara a tener un decremento por lo que pasara únicamente por el
punto de ajuste. Esto puede apreciarse en la Figura 43.
101
Figura 42. Límite superior establecido
Figura 43. Nivel disminuyendo en modo automático
102
Una observación importante es que la alarmas se activan únicamente cuando se alcancen

niveles riesgosos dentro de la caldera, por esta razón para el control con la histérisis de
esta prueba no deberán activarse. La figura 44 muestra como el nivel alcanza el límite
inferior, es en este momento cuando la válvula comienza cerrarse.
Figura 44. Límite inferior establecido
En cualquier momento se puede consultar de igual manera la demanda de vapor en la

caldera apareciendo la ventana correspondiente como se muestra en la Figura 45.
Figura 45. Vapor de salida en modo automático
103
Consultando la ventana de mando de la válvula (Fig. 46), se puede observar que no

aparecen los botones de mando de la válvula debido a que los interlocks de apertura
automática están activados y por tanto no resultan necesarios.
Figura 46. Mando de la válvula durante modo automático
Con la finalidad de realizar una completa prueba de todos los elementos, con este fin se
activo el envío de las variables de proceso a Excel. El estado de esta unción se mostrara
en el texto del botón de activación como se muestra en la Figura 47.
104
Figura 47. Habilitación de envío de datos a Excel
.
De esta forma los datos exportados de muestran en la Figura 48. Con ello concluyen las
pruebas de funcionamiento del software y como se ha demostrado, resultan por completo
satisfactorias.
Figura 48. Exportación de datos durante la prueba
105
IV. “ANÁLISIS COSTO BENEFICIO DEL PROYECTO”
El presente capítulo detalla la cuantificación económica total del proyecto proporcionando

información valiosa para la toma de decisiones procurando determinar las ventajas de un
proyecto mediante la enumeración y valoración en términos monetarios de todos los
costos y beneficios.
106
4. ANÁLISIS COSTO – BENEFICIO.
Uno de los principales factores para cualquier diseño es la cuestión económica, de tal
modo que podemos estimar los costos del proyecto de acuerdo a la parte física y laboral
que demande a lo largo del mismo
El análisis de costo es el proceso mediante el cual se ordenan, sistematizan e identifican

las estimaciones económicas reales atribuibles al proyecto. Este análisis es de ayuda en
la toma de decisiones destacando los beneficios que el proyecto proporciona en términos
financieros expresados en moneda de un mismo momento. [18]
El monto total del proyecto es determinado por varios factores como lo son el desarrollo
tablas que proporcionan la información. La siguiente tabla 7 muestra los costos del
equipo necesario para la realización del proyecto.
Tabla 7 Costo de Material y Equipo.
CONCEPTO COSTO (Moneda Nacional)

Computadora Personal con Microsoft
$10000.00
Windows XP Professional
Software Visual Basic $12150.00
Software RSLinks Classic v 2.52.00 $5000.00
Software RSLogix 5000 v 13.0 $37905.00
PLC Compactlogix L32E $36064.00
TOTAL $ 101,119.00
107
4.1 TIEMPOS EN LA REALIZACIÓN DEL PROYECTO
A través de la tabla 8 se muestran el tiempo invertido para la realización de las diferentes

etapas del proyecto así como del costo por día.
Tabla 8. Relación de tiempo y costo del proyecto
Concepto Días Empleados Costo total (MX)

Diseño Interfaz Gráfica 5 $4000
Programación en Visual Basic 10 $8000
Programación RSLogix5000 10 $8000
Enlace por OPC 3 $2400
Puesta en Marcha 5 $4000
TOTAL 33 $26, 400
El costo total del proyecto se muestra en la tabla 9.
Tabla 9. Coste Total de proyecto
CONCEPTO COSTO (Moneda Nacional)

Coste Material y Equipo $101,119.00
Coste tiempo Empleado $26,400.00
TOTAL $127,519.00
Entonces el costo total del proyecto es de $127,519.00, aún cuando el objetivo del
desarrollo de este proyecto no es competir con un sistema SCADA cabe mencionar que
éste puede ser utilizado con los mismos fines pudiendo cubrir las necesidades esenciales
del cliente sin obligar a este a comprar un software más costoso que en ocasiones suele
ser sobrado para la aplicación que se desea proporcionar.
108
4.2 COMPARACIÓN CON UN SISTEMA SCADA COMERCIAL.
Existen diferentes tipos de HMI que se desarrollan en un entorno de programación gráfica

como C++, Visual Basic, Delphi, etc. Los paquetes enlatados HMI, son paquetes que
contemplan la mayoría de las funciones estándares de los sistemas SCADA, ejemplo de
ellos son FIX, WinCC, Wonderware, etc.
Las funciones básicas de un Software HMI son:

Monitoreo: Es la habilidad de obtener y mostrar datos de la planta en tiempo real. Estos
datos se pueden mostrar como numeros, texto o gráficos que peritan una lectura más
fácil de interpretar.
Supervisión: Esta función permite junto con el monitoreo la posibilidad de ajustar las
condiciones de trabajo del proceso directamente desde la computadora.
Alarmas: Es la capacidad de reconocer eventos excepcionales dentro del proceso y
reportar estos eventos. Dichas alarmas son reportadas basadas en límites de control
preestablecidos.
Control: Es la facultad de aplicar algoritmos que ajustan los valores del proceso y así
mantener estos valores dentro de ciertos límites.
Históricos: Es conseguir muestrear y almacenar en archivos, datos del proceso a una
determinada frecuencia. Este almacenamiento de datos es una p herramienta para la
optimización y corrección de procesos.
Una vez analizado lo anterior podemos concluir que el desarrollo del proyecto mostrado
en el capitulo anterior es un pequeño sistema IMH que cuenta con todas las
características mínimas para conformar una Interfaz Hombre Máquina a continuación se
mostrara un sistema IMH/SCADA como lo es HMI SIMATIC WinCC con el fin de mostrar
los alcances, limitantes y ventajas económicas del proyecto realizado.
Software de Sistema WinCC

SIMATIC WinCC es un sistema de visualización de procesos escalable y dotado de
potentes funciones para la supervisión de procesos automatizados. WinCC aporta
funcionalidad SCADA completa en Windows para todos los sectores, desde sistemas
109
monopuesto hasta sistemas multipuesto distribuidos con servidores redundantes y

soluciones para todos los lugares de instalación con clientes web.
Entre las ventajas que este ofrece se enlistan las siguientes:

Visualización totalmente gráfica de las secuencias y el estado de los procesos
• Manejo de la máquina o instalación desde una interfaz de usuario que se puede
personalizar, con menús y barras de herramientas propios
• Señalización y confirmación de eventos
• Archivo de valores medidos y avisos en una base de datos del proceso
• Protocolización de los datos actuales del proceso y de datos de archivo registrados
• Administración de usuarios y sus permisos de acceso [12]
El costo de un software como el descrito anteriormente dependiendo de las funciones que
este tenga es alrededor de $763140.00 sin incluir el costo del equipo en el que será
instalado, ni la puesta en marcha si comparamos este con el precio que se obtuvo en la
realización del proyecto hay una diferencia de más de $500,000.00 la solución ofrecida a
lo largo del proyecto no compite con este software que trae características más
sofisticadas pretende dar solución a un sistema de control que no necesita de todas las
herramientas y puede trabajar con un software menos costoso y que cumpla con los
requerimientos del cliente
110
CONCLUSIONES Y RECOMENDACIONES.
El objetivo general de este proyecto se cumplió al haberse diseñado un software de

aplicación en Visual Basic para adquisición de datos y supervisión de controladores
digitales utilizando tecnología OPC. Este trabajo muestra la comunicación del software
con el PLC Compact Logix Allen-Bradley, que cubrió las necesidades de procesamiento
para el control de nivel de una caldera. Como bien señalamos anteriormente cada
fabricante de controladores presenta un método de acceso diferente a la información
interna de los mismos, es por esta razón que el software diseñado deberá adaptarse en
estos rubros que el fabricante del controlador señale, sufriendo ligeros cambios en el
direccionamiento de los ítems (variables) localizadas dentro de la memoria del
controlador.
La interfaz gráfica diseñada es una clara muestra del amplio alcance que posee Visual
Basic para el diseño de tecnologías de automatización y por ello su amplio uso por parte
de los diseñadores internacionales.
Por otra parte se puede apreciar que la comunicación por Ethernet brinda una mayor
velocidad en comparación con la RS-232, al utilizarla se logro un monitoreo más confiable
ya que se tiene la certeza de que la información presente en pantalla es actualizada
logrando así un control supervisorio más eficiente.
Por otra parte se recomienda observar que la interfaz grafica se puede modificar en
cualquier momento con el software adecuado teniendo este en su librería un OPC que es
la tecnología abierta para que todo funcione adecuadamente.
La interfaz se convierte en una herramienta que hace eficiente el control de un proceso
dentro de cualquier industria al proporcionar al operador información actualizada y más
ordenada, cabe mencionar que la base de este programa se puede utilizar para realizar el
control de distintas variables ya sea de temperatura, flujo, presión, etc., así vemos que la
tecnología OPC ofrece una gran variedad de herramientas para el enlace cliente-servidor,
demostrando su gran amplitud en el manejo de datos.
Se recomienda actualizar este trabajo aplicando la tecnología OPC a través de la
adquisición de datos y desarrollo de interfazs graficas de tal modo que se pueda visualizar
el alcance de ésta por medio del uso de diferentes tipos y marcas de controladores así
como software de aplicación optimizando el control, monitoreo y supervisión de cualquier
proceso industrial.
111
BIBLIOGRAFIA
1. Aquilino Rodríguez Penin, SISTEMAS SCADA, 3° Edición MARCOMBO, S.A.,

México, México 2006.
2. Michael D. Whitt, Successful Instrumentation and control system designs, ISA, USA
2004.
3. Creus Solé Antonio, INSTRUMENTACIÓN INDUSTRIAL, 7° edición MARCOMBO.

S.A., México, México 2005.
4. Antonio Miranda Toledo, José Luis Pérez Navarro, Sistema de control distribuido
(DCS), ISA, México, México 2000.
5. Taylor, Ed. TCP/IP Complete, 1ª ed. Ed. Mc Graw-Hill. New York, EUA. 1998.
6. Baca Urbina, Gabriel. Evaluación de Proyectos, 4a ed. Ed. Mc Graw-Hill. México,

México 2001.
7. Carlos M. Rodríguez Bucarelly, 2° Edición, Bucarelly, México 2005-2008.
8. www.opc.org.com.
Historia OPC, generalidades de la tecnología.
9. http://www.opcsystems.com.
Teoría, aplicación, generalidades OPC
10. www.dauelectronica.com.
Diseño, Proyectos, Software etc., todo sobre Automatización.
11. http://www.desarrolloweb.com/articulos/993.php.
Que es ActiveX, Funciones, Aplicación.
112
12. www.automation.siemens.com/salesmaterial-
as/brochure/es/brochure_simatic-wincc_es.pdf.
Software SIMATIC.
13. http://office.microsoft.com/es-mx/access/HA102755503082.aspx
Administrar orígenes de Datos ODBC.
14. http://www.angelfire.com/biz/rhaminisys/ddeinfo.html.
Teoría y Funcionamiento DDE.
15. http://wwwlhc.cern.ch/IndCtrl/PLC/Recomm.html
INTRODUCCIÓN A LA PROGRAMACIÓN DE PLC'S
16. http://www.control-systems-
principles.co.uk/whitepapers/spanishwp/14ProgLogicSP.pdf
Concepto dePLC referencia y funcionalidad.
17. Dixon, P. y Velarde, M. (2009). “The mith and magic of OPC”. InTech ISA (Agosto):
20-23
18. Anthony E. Boardman - Análisis de costos y beneficios: Conceptos y práctica

(2da edición)
113
APÉNDICE A. DIAGRAMA ESCALERA RSLOGIX5000.

A continuación se da el programa en lenguaje ladder, realizado y almacenado en la
memoria del PLC (sólo en ciertos tipos de PLC´s que están preparados para ello) a través
del programador. El PLC hace un scan, es decir, lee de forma secuencial, siguiendo el
orden en que los renglones que fueron escritos, comenzando por el renglón superior y
terminando con el inferior. En este tipo de programa cada símbolo representa una variable
lógica cuyo estado puede ser verdadero o falso, o en estado binario (0 o 1).
114
115
116
117
APÉNDICE B. CÓDIGO FUENTE DE LA INTERFAZS Y ENLACE OPC (VISUAL

BASIC).
A continuación se dará el código de Visual Basic a partir de la estructura gráfica diseñada

estableciendo las variables a utilizar para el manejo de la información dentro del
programa, definiendo su tipo de variable y nombre apropiados. Visual Basic permite el
uso de 11 tipos diferentes de variables.
B1. PAGINA PRINCIPAL
118
119
120
121
VENTANA FTRANS16FRAME
122
B.2 MEDIDOR DE VAPOR DE SALIDA FT-16.
B.3 VALVULA DE LLENADO FV-16.
123
B.3 VENTANA DE MODO DE CONTROL
124
125
APÉNDICE C. DIAGRAMA DE TUBERÍAS E INSTRUMENTACIÓN. (DTI).

A continuación se ilustra el DTI que se logra con un controlador de caudal de vapor y un
controlador de nivel cuyas señales de salida se comparan en un relé de relación que
actúa directamente sobre la válvula de control del agua de alimentación.
126
APÉNDICE D. ESPECIFICACIONES TECNICAS DEL PLC COMPACLOGIX L32E
127

Protocolos de Comunicacion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Protocolos de Comunicacion

Cargado por

Copyright:

Formatos disponibles

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA

DISEÑO DE SOFTWARE EN VISUAL BASIC PARA

ASESOR: ING. RICARDO HURTADO RANGEL

MÉXICO, DISTRITO FEDERAL 2010

A mi ABUELITA IRENE por brindarme su cariño y dejarme conocer un cariño diferente.

Mi admiración, gratitud y reconocimiento a mis compañeros de tesis Fernando y Luis quienes

Ángeles Tania Juárez Sánchez

Al Instituto Politécnico Nacional, en particular a la Escuela Superior de Ingeniería

Fernando Olivera Caudillo

Al término de esta etapa de mi vida, quiero expresar un profundo agradecimiento a

Luis Alfredo Muñoz Salas

1.5.2 OLE FOR PROCESS CONTROL (OPC) ......................................................... 38

3.4.2 Diagrama de escalera en RSlinks 5000. .......................................................... 77

Tabla 1 Conexiones del pin _______________________________________________________ 34

Choque térmico: un colapso térmico o choque térmico se refiere al rompimiento de algún

COM: Modelo de objetos componentes.

CPU: Unidad de control de Procesos.

DBMS: Sistemas de Gestión de Bases de Datos.

DCOM: Modelos de objetos componentes Distribuido.

DDE: Intercambio Dinámico de Datos.

DLL: Librerías de unión dinámico.

DTI: Diagrama de Tuberías e Instrumentación.

Histerisis: La diferencia, en términos porcentuales (%), de la distancia de detección

Inteligible: Que puede ser comprendido.

LAN: Red de Área Local.

NEMA: Asociación Nacional de Fabricantes de Normas Eléctricas.

ODBC: Conectividad de Base de Datos Abierta.

Ofimático: Todo lo relacionado a oficina.

OLE: Vinculación e Inserción de Objetos.

OPC: OLE para control de procesos.

PLC: Controlador Lógico Programable.

SCADA: Sistema de Registro de datos y control de supervisión.

SCAP: Sistema de Control Avanzado de Procesos.

SCD: Sistema de Control Distribuido.

Sistema Operativo Multipuesto: Un sistema operativo es multipuesto o multiusuario

Sistema Operativo Monopuesto: Decimos que es monopuesto o monousuario cuando

SQL: Lenguaje de consulta estructurado.

TCP/IP: Transmisión Control Protocol / Internet Protocol.

Telemetría: Sistema de medida de magnitudes físicas en lugares difícilmente accesibles,

VB: Visual Basic.

Diseñar software de aplicación en Visual Basic para adquisición de datos de

- Explicar las diferentes tecnología de comunicación entre aplicaciones empleadas en

En esta tesis se muestra el diseño de un software para adquirir datos desde un

La comunicación se realiza a través de Ethernet ya que brinda una gran velocidad en

Se realiza un análisis costo-beneficio del proyecto, donde se identifica las estimaciones

El intercambio de información entre aplicaciones y computadoras comienza con Microsoft

Wonderware Corporation, el primer proveedor de un sistema Scada basado en Windows,

¿Para qué realizar un software de adquisición de datos mediante OPC?

En un sistema de automatización hay múltiples elementos de control y monitorización,

Cada fabricante proporciona este programa controlador de comunicaciones o driver que

 Se programo en el controlador digital la lógica necesaria para la simulación de

Este trabajo presenta una aplicación de un sistema como lo es OPC, se presenta el

Capítulo I. Trata sobre las diferentes tecnologías basadas en la plataforma Microsoft

Y finalmente se encuentran los Apéndices, en donde se tiene el código de la

I. “TECNOLOGÍA DE COMUNICACIÓN ENTRE APLICACIONES EMPLEADAS EN LA

Figura 1. Tecnologías de software

A continuación se desarrollan los conceptos de cada uno de estos dando un panorama

ActiveX es un marco para definir los componentes de software reutilizables (conocidos

ActiveX es una tecnología de Microsoft para el desarrollo de páginas dinámicas. Tiene

1.1.3 GUIONES ACTIVEX.

1.1.4 VENTAJAS, DESVENTAJAS Y RIESGOS

1.2 DYNAMIC DATA EXCHANGE (DDE) (INTERCAMBIO DINÁMICO DE DATOS).