Post on 27-Sep-2018
UNIVERSIDAD POLITÉCNICA SALESIANA
SEDE QUITO
CARRERA:
INGENIERÍA ELECTRÓNICA
Trabajo de titulación previo a la obtención del título de:
INGENIERO ELECTRÓNICO
TEMA:
SIMULACIÓN DE UN WCS (WIRELESS CONTROL SYSTEM) PARA SENSORES
Y ACTUADORES INTELIGENTES APLICADO A PROCESOS PRODUCTIVOS
AUTOR:
ALEX JAVIER BONILLA CUADRADO
TUTOR:
CARLOS GERMÁN PILLAJO ANGOS
Quito, marzo del 2017
Cesión de derechos de autor
Yo Alex Javier Bonilla Cuadrado, con documento de identificación N°
1718455825, manifiesto mi voluntad y cedo a la Universidad Politécnica Salesiana
la titularidad sobre los derechos patrimoniales en virtud de que soy autor del trabajo de
titulación intitulado: Simulación de un WCS (Wireless Control System) para sensores y
actuadores inteligentes aplicado a procesos productivos, mismo que ha sido
desarrollado para optar por el título de: Ingeniero Electrónico, en la Universidad
Politécnica Salesiana, quedando la Universidad facultada para ejercer plenamente
los derechos cedidos anteriormente.
En aplicación a lo determinado en la Ley de Propiedad Intelectual, en mi condición de
autor me reservo los derechos morales de la obra antes citada. En concordancia,
suscribo este documento en el momento que hago entrega del trabajo final en
formato impreso y digital a la Biblioteca de la Universidad Politécnica Salesiana.
Alex Javier Bonilla Cuadrado
C.I. 1718455825
Quito, marzo del 2017
Declaratoria de coautoría del docente tutor
Yo, declaro que bajo mi dirección y asesoría fue desarrollado el trabajo de titulación
Simulación de un WCS (Wireless Control System) para sensores y actuadores
inteligentes aplicado a procesos productivos realizado por Alex Javier Bonilla Cuadrado,
obteniendo un producto que cumple con todos los requisitos estipulados por la
Universidad Politécnica Salesiana para ser considerados como trabajo final de titulación.
Quito, marzo del 2017
DEDICATORIA
A mis hijos, mi esposa y mi madre quienes han sido mi motivación y el aliento que me
ha acompañado en los mejores momentos de mi vida.
Dios bendiga mi familia
Javier
AGRADECIMIENTO
A mi madre por hacer un gran esfuerzo y brindarme la oportunidad de estudiar esta
carrera, a la Universidad Politécnica Salesiana por formarme durante estos años y al Ing.
Carlos Pillajo por su guía y apoyo en el desarrollo del presente trabajo.
ÍNDICE DE CONTENIDO
CAPÍTULO 1 .................................................................................................................... 1
ANTECEDENTES ........................................................................................................... 1
1.1 Título del proyecto ................................................................................................. 1
1.2 Planteamiento del problema .................................................................................... 1
1.3. Objetivos ................................................................................................................ 2
1.3.1. Objetivo general ................................................................................................ 2
1.3.2. Objetivos específicos ........................................................................................ 2
1.4. Alcance .................................................................................................................. 3
1.5. Justificación ........................................................................................................... 3
CAPÍTULO 2 .................................................................................................................... 5
MARCO TEÓRICO ........................................................................................................ 5
2.1. Estudio y análisis de las redes convencionales de control ...................................... 5
2.2. Estudio y análisis de las redes control usando un medio compartido (TCP/IP) ..... 6
2.3. Situación actual de WCS y NCS ............................................................................. 8
2.3.1 Costo .................................................................................................................. 8
2.3.2 Aplicaicones....................................................................................................... 9
2.3.3 Problemas y soluciones ...................................................................................... 9
2.4. Ventajas y desventajas .......................................................................................... 10
CAPÍTULO 3 .................................................................................................................. 11
DISEÑO E IMPLEMENTACIÓN ............................................................................... 11
3.1 Funcionamiento de los elementos que conforman un proceso de control dentro de
una red industrial convencional. ................................................................................... 11
3.2 Esquema y modelos de redes para el estudio de los NCS/WCS. ........................... 13
3.2.1 Modelo1: Modelo básico de Red de Control. .................................................. 14
3.2.2 Modelo 2: Modelo de Red Multimedia en la que interactúa un segmento de
red dedicado a realizar acciones de control (NCS/WCS) con parámetros Ethernet. 21
3.2.3 Modelo 3: Modelos de Red Multimedia .......................................................... 32
3.3 Monitoreo de una red real con características de tráfico similares a las simuladas,
mediante el uso del Software PRTG ............................................................................ 42
CAPÍTULO 4 .................................................................................................................. 46
PRUEBAS Y RESULTADOS ....................................................................................... 46
4.1 Análisis del Modelo1: Modelo básico de Red de Control ...................................... 46
4.2 Análisis del Modelo 2: Modelo básico de Red de Control ..................................... 47
4.3 Análisis del Modelo 3 ............................................................................................. 48
4.4 Comparativa de la Simulación con los datos obtenidos en PRTG ......................... 55
CONCLUSIONES .......................................................................................................... 58
RECOMENDACIONES ................................................................................................ 60
REFERENCIAS ............................................................................................................. 61
ANEXOS ......................................................................................................................... 63
ANEXO 1. Software OPNET para la simulación de un entorno de red ......................... i
ANEXO 2. Configuraciones Iniciales del Software OPNET ........................................ ii
ANEXO 3. Software PRTG para el monitoreo de redes. ............................................... v
ANEXO 4. Modulo Arduino y Programación del mismo ............................................. vi
ÍNDICE DE FIGURAS
Figura 2.1. Pirámide de automatización ............................................................................. 5
Figura 2.2. Redes industriales(Simatic) ............................................................................. 6
Figura 2.3. Sistemas de control con medio compartido ..................................................... 7
Figura 3.1. Protocolos de una red de Control Industrial .................................................. 11
Figura 3.2. Tipo de datos en función del servicio ............................................................ 12
Figura 3.3. Esquema redes ASI ........................................................................................ 12
Figura 3.4. Trama de datos ............................................................................................... 13
Figura 3.5. Figura 18: Red del Modelo 1 ......................................................................... 14
Figura 3.6. Paleta de opciones para el Modelo ................................................................ 14
Figura 3.7. Atributos de un nodo ..................................................................................... 15
Figura 3.8. Parámetros configurados en nodo Sensor, modelo 1 ..................................... 17
Figura 3.9. Parámetros configurados en nodos restantes, modelo 1 ................................ 18
Figura 3.10. Selección de Estadísticas en modo Global .................................................. 18
Figura 3.11. Selección de Estadísticas Individuales ........................................................ 19
Figura 3.12. Configuración de los parámetros de la simulación ...................................... 19
Figura 3.13. Ventana del navegador de Resultados ......................................................... 20
Figura 3.14. Ejemplo del tráfico generado en el modelo 1 .............................................. 20
Figura 3.15. Modelo de red multimedia ........................................................................... 21
Figura 3.16. Red del modelo 2 ......................................................................................... 23
Figura 3.17. Ventana de atributos en el bloque Aplication Configuration ..................... 23
Figura 3.18. Ventanas de configuración de aplicaciones. ................................................ 24
Figura 3.19. Ventana de atributos en el bloque Profile Configuration ............................ 25
Figura 3.20. Configuración de las aplicaciones dentro de los perfiles............................. 25
Figura 3.21. Configuración de los atributos del servidor ................................................. 26
Figura 3.22. Configuración de los atributos del servidor, supported services ................. 26
Figura 3.23. Configuración de los atributos del servidor, destination preferences .......... 27
Figura 3.24. Configuración de los atributos del servidor, actual name ........................... 27
Figura 3.25. Configuración de BSS Identifier ................................................................. 28
Figura 3.26. Configuración del router .............................................................................. 28
Figura 3.27. Datos estadístico en modo individual, (Http) .............................................. 29
Figura 3.28. Datos estadístico en modo individual (Datos) ............................................. 29
Figura 3.29. Datos estadístico en modo individual (Video) ............................................ 30
Figura 3.30. Datos estadístico en modo global ................................................................ 30
Figura 3.31. Configuración del tiempo de simulación ..................................................... 31
Figura 3.32. Gráficas del tráfico generado en el modelo 2 .............................................. 31
Figura 3.33. Gráficas de retardos en el modelo 2 ............................................................ 32
Figura 3.34. Ventana del entorno de simulación del modelo 3 ........................................ 33
Figura 3.35. Red del modelo 3a ....................................................................................... 33
Figura 3.36. Segmento de red de ensamblaje ................................................................... 34
Figura 3.37. Segmento de red de Pintura ......................................................................... 35
Figura 3.38. Segmento de red de Test .............................................................................. 35
Figura 3.39. Segmento de red Administrativo ................................................................. 35
Figura 3.40. Aplicaciones del modelo 3a ......................................................................... 36
Figura 3.41. Perfiles del modelo 3a ................................................................................. 36
Figura 3.42. Ejecución de la simulación .......................................................................... 37
Figura 3.43. Gráficas del tráfico generado en el modelo 3a ............................................ 37
Figura 3.44. Red del modelo 3b ....................................................................................... 38
Figura 3.45. Aplicaciones asignadas a los perfiles del modelo 3b................................... 40
Figura 3.46. Intervalos de tiempo en la aplicación de video ............................................ 41
Figura 3.47. Intervalos de tiempo en la aplicaciones ....................................................... 41
Figura 3.48. Gráficas del tráfico generado en el modelo 3b ............................................ 41
Figura 3.49. Gráficas unificadas del tráfico generado en el modelo 3b ........................... 42
Figura 3.50. Ventana de dispositivos en la red monitoreados por PRTG ........................ 43
Figura 3.51. Gráfica del tráfico de http monitoreados por PRTG .................................... 44
Figura 3.52. Gráfica del tráfico de la aplicación datos monitoreados por PRTG ............ 44
Figura 3.53. Gráfica del tráfico de video monitoreados por PRTG ................................. 45
Figura 4.1. Gráfica del trafico enviado y recibido del modelo 1 ..................................... 46
Figura 4.2. Gráfica de retardos en el modelo 2 ................................................................ 47
Figura 4.3. Gráfica de los retardos en cada aplicación del modelo 2............................... 48
Figura 4.4. Gráfica de tráfico generado en cada aplicación del modelo 2 ....................... 48
Figura 4.5. Gráfica de retardos en el modelo 3 ................................................................ 49
Figura 4.6. Gráfica de tráfico generado en cada aplicación del modelo 3 ....................... 49
Figura 4.7. Gráfica de tráfico generado en intervalos de tiempo ..................................... 50
Figura 4.8. Gráfica del throughput en el modelo 3 .......................................................... 50
Figura 4.9. Gráfica de variación de retardo en paquetes en el modelo 3 ......................... 52
Figura 4.10. Variación en la configuración de datos y http ............................................. 52
Figura 4.11. Variación en retardo con tráfico de video más pesado ................................ 53
Figura 4.12. Variación del tráfico de video...................................................................... 53
Figura 4.13. Variación del retardo de paquetes con un tráfico de video más pesado ...... 54
Figura 4.14. Variación del throughput ............................................................................. 54
Figura 4.15. Gráfica del tráfico enviado en las aplicaciones del modelo 3 ..................... 55
Figura 4.16. Comparación de gráficas de http en OPNET y PRTG ................................ 56
Figura 4.17. Comparación de gráficas de datos en OPNET y PRTG .............................. 56
Figura 4.18. Comparación de gráficas de video en OPNET y PRTG .............................. 57
ÍNDICE DE TABLAS
Tabla 2.1. Ventajas y desventajas entre NCS-WCS y Redes Industriales Convencionales ......... 10
Tabla 3.1. Número de nodos de acuerdo a su aplicación ............................................................. 34
Tabla 3.2. Escala de conversión de horas a segundos .................................................................. 39
Tabla 3.3. Intervalos de trabajo en las aplicaciones ..................................................................... 39
Tabla 3.4. Asignación de tiempos en la simulación ..................................................................... 39
RESUMEN
En el presente proyecto se abordan los conceptos de Sistemas de control en red y
Sistemas de control inalámbrico (NCS y WCS, Networked Control System - Wireless
Control System) mediante los cuales se plantea la existencia de una red de control de
procesos productivos que interactúa en un entorno de red con características multimedia.
Se propone simular la integración de aplicaciones de red en un medio compartido, en la
cual un segmento de la red dedicado a procesos de control utiliza tecnología Wireless.
Los Sistemas de control en red y Sistemas de control inalámbrico (NCS y WCS) son una
tecnología en desarrollo, el estudio de su funcionamiento y sus posibles aplicaciones
contribuyen a determinar sus limitantes, por lo que para ser superadas dan paso a idear
nuevas formas de comunicación y nuevos dispositivos tecnológicos.
La red que se Simulará propone el análisis del comportamiento de una red propia de un
entorno industrial que convive con aplicaciones típicas de una red interactiva y
multimedia, determinando si una red de ese tipo es viable.
ABSTRACT
In this project the concepts of Networked Control Systems and Wireless Control
Systems (NCS and WCS) are discussed, through which the existence of a network of
productive process control interacts In a network environment with multimedia features.
It is proposed to simulate the integration of network applications into a shared medium,
in which a segment of the network dedicated to control processes uses Wireless
technology.
Networked control systems and wireless control systems (NCS and WCS) are a
technology in development, so the study of their operation and possible applications
contribute to determine their limitations, so that to be overcome give way to To devise
new forms of communication and new technological devices.
The Simulated Network proposes the analysis of the behavior of a network of an
industrial environment that coexists with typical applications of an interactive and
multimedia network, determining if such a network is viable.
INTRODUCCIÓN
Hoy en día los avances tecnológicos son constantes, prácticamente la tecnología está
inmersa en todas las cosas y actividades cotidianas en un mundo en el que cada vez se
acortan distancias y se cuenta con un mayor control de las cosas. Actualmente la idea de
controlar eventos y procesos de forma remota a distancias relativamente largas ya es
toda una realidad, sin embargo existen procesos que dado su aplicación dedicada
resultan más complejos de integrar a esta nueva tendencia de control.
En los sistemas de control propios de procesos productivos se manejan redes industriales
que si bien cumplen con el mismo propósito que tienen las redes de información que se
utilizan en los últimos niveles de la pirámide de automatización, el cual es comunicar un
dispositivo con otro, hay que destacar el volumen del tráfico que generan.
En las redes industriales el tráfico en la mayoría de las ocasiones está en el rango de los
bits y los tiempos de retardo pueden ser críticos, por lo contrario, en las redes de
información se maneja un gran volumen de datos y dado que sus aplicaciones para la
transmisión de datos no es algo delicado pueden ocasionarse retardos prolongados.
Con el estudio de los WCS/NCS y por medio de una simulación se pretende el análisis
del funcionamiento de una red de control industrial con las características de una red de
información, lo cual generaliza el tipo de comunicaciones que usa la pirámide de
automatización red, creando un solo camino que comunique a todos los elementos de
una red independientemente del tipo de aplicación que realice.
1
CAPÍTULO 1
ANTECEDENTES
1.1 Título del proyecto
Simulación de un WCS (Wireless Control System) para sensores y actuadores
inteligentes aplicado a procesos productivos.
1.2 Planteamiento del problema
Se necesita analizar el tráfico que se genera a través de una red multimedia, en la cual, se
cuente con un segmento de la red dedicado únicamente al control de procesos
productivos, en este segmento se cuenta con nodos que a su vez son sensores y
actuadores inteligentes con la capacidad de adaptarse a los protocolos de una red
multimedia.
Se debe tomar en cuenta que para hacer un análisis del tráfico dentro de una red con las
características antes mencionadas, se debe contar con distintas aplicaciones que generan
distintos tipos de tráfico, cada una permite diferenciar las características que este puede
tener, así se puede distinguir un tipo de tráfico de otro y por ende determinar cuál de
ellos se ve más, o menos afectado a la hora de variar parámetros dentro de las
aplicaciones.
Los Sistemas de Control Inalámbrico (WCS, Wireless Control Systems) pueden
presentar algunas ventajas como: El que no existen cables físicos, pueden ser más
baratos, permiten gran movilidad dentro del alcance de la red, pueden instalarse
fácilmente. Pero si bien la comunicación de estos equipos por un medio inalámbrico
facilita el control de procesos remotamente, y presenta múltiples ventajas en
comparación a una red cableada, también se debe tomar en cuenta los problemas a los
que se debe hacer frente como: El volumen de datos (mayor tamaño, con mayor
velocidad), lo que lleva a situaciones de congestión (llegan más datos de los que el
sistema puede procesar), lo que puede originar una importante pérdida de paquetes y
2
retraso en la entrega de información lo que finalmente deteriora la calidad de servicio
demandado por el usuario.
Por otro lado representa el problema de que se depende absolutamente de la capacidad
de la red y de las configuraciones necesarias de la misma para realizar un control
eficiente; en una red específicamente industrial, donde pueden haber procesos dedicados
que requieren una medición y una respuesta inmediata por lo que se debe garantizar la
eficiencia y operatividad de la red.
Cada avance en la tecnología ha provocado un cambio, en el control automático. Hoy
por hoy es la era de la sociedad en red, la gente experimenta un nuevo estilo de vida
conectado en un mundo donde se puede acceder a información desde cualquier lugar y
cualquier dispositivo con internet.
1.3. Objetivos
1.3.1. Objetivo general
Diseñar y plantear la simulación de un WCS (Wireless Control System) para sensores y
actuadores inteligentes aplicado a procesos productivos.
1.3.2. Objetivos específicos
Estudiar la situación actual de los Sistemas de control en red así como los WCS y NCS
para tratar sistemas de control de procesos.
Estudiar el tráfico de una red en un entorno industrial con procesos de control en
los que se pueda aplicar los conceptos de NCS y WCS, para la transmisión y
recepción de datos mediante el software OPNET.
Simular el funcionamiento de una red mediante el software OPNET, centrándose
en cómo se trata la implementación de una red aplicando WCS y NCS, aportando
a ideas que sirvan como base o referencia para su uso en aplicaciones académicas
o que puedan extender la investigación.
3
Evaluar pruebas de comunicación de los sistemas diseñados en simulación
virtual, mediante su ejecución en software y hardware realizado con OPNET y
PRTG respectivamente.
1.4. Alcance
En el presente proyecto se propone la simulación de una planta que maneja dos tipos de
tráfico específico, el tráfico de procesos de control y el tráfico de aplicaciones
multimedia.
Para la transmisión de esta información se plantea el concepto de un medio compartido,
en el que conviven los dispositivos propios de una red de control industrial y los
usuarios de una red de información, por lo que se analizara el tipo de tráfico que genera
cada aplicación y como interfiere en las aplicaciones de la red.
1.5. Justificación
Llegar a implementar en tecnología Wireless el comportamiento de las redes industriales
de hoy en día y controlarlas remotamente a través de la nube es el desafío a futuro. Por
lo que se hace necesario el estudio y la simulación del comportamiento de los WCS y los
NCS para analizar el tráfico generado en una red industrial y evaluar su funcionamiento
a nivel básico y nivel macro donde se tenga que plantear conceptos de administración de
redes, determinando los problemas que puede presentar la red y las limitantes que
existen hoy en día. (Zheng Lu and Hongji Yang, 2012)
Sin embargo ya que la aparición de nuevos servicios en red realiza un consumo de
recursos muy alto, se pretende realizar el presente trabajo para analizar el
funcionamiento de una red y determinar su eficiencia ya que como se mencionó
anteriormente el uso excesivo de servicios puede provocar funcionamientos defectuosos
debido a la baja capacidad de las redes y de los propios equipos. (Hespanha, 2007)
Ya que la implementación de una red física con estas características aún resulta
compleja por la escases y costos elevados de equipos de control industrial con estas
4
características, se propone la realización de una simulación mediante el Software
OPNET Modeler, que permita el análisis y comportamiento del tráfico de una red con
los componentes antes mencionados. La red simulada debe estar dentro de los
lineamientos y características propias de los equipos convencionales de una red de
Wireless – Ethernet.
La red debe contar con distintas aplicaciones que generen distinto tipos de tráfico como:
tráfico de Video, tráfico de Datos, y un tráfico con características de consumo muy
pequeño que para efectos de esta simulación se determina como tráfico Http.
La red debe contar con un número distinto de nodos o usuarios de las tres aplicaciones,
lo que permitirá diferenciar el consumo de datos que cada aplicación realiza. Esto
permitirá definir el ancho de banda adecuado para que una red de este tipo pueda
trabajar de forma óptima.
Se debe determinar la aplicación más sensible a la interferencia de las otras y analizar el
consumo de datos que produce, este consumo afecta a toda la red, por lo que si se varían
las características de las aplicaciones se puede determinar que tanto afecta a la red
estudiando la aplicación más sensible.
5
CAPÍTULO 2
MARCO TEÓRICO
2.1. Estudio y análisis de las redes convencionales de control
Dependiendo del volumen de información que maneja el sistema de control (bits, bytes,
paquetes, etc.), se establecen diferentes protocolos que se acoplan a la funcionalidad de
su respectivo nivel en la pirámide de automatización.
Figura 2.1. Pirámide de automatización
Elaborado por: (Sistemas_industriales, 2013, pág. 54)
Las redes industriales se caracterizan por ser deterministas a diferencian de las redes de
información que se usan en el último nivel de la pirámide de automatización. En el nivel
de gestión se usa el protocolo TCP/IP por elevado volumen de información que puede
transmitir. Para el resto de niveles de la pirámide, se usan diferentes protocolos:
Industrial Ethernet, Profibus, AS-Interface, cada protocolo posee su software y hardware
dedicado para atender las necesidades de su área de trabajo. (Cáceres, 2013)
Un parámetro de la eficiencia de una red de comunicación es la cantidad de información
con la que se trabaja, cuando los elementos que interactúan en el sistema generan
diferentes volúmenes información es necesario dimensionar el protocolo que presente el
mejor desempeño. En los sistemas de control los retardos son un factor crítico en el
equilibrio del sistema. Es lógico pensar que un protocolo que es capaz de comunicar una
gran cantidad de datos puede trabajar con pequeños volúmenes de información, sin
6
embargo en la trama total resultante se incrementa información innecesaria presentando
retardos en la red, entorpeciendo la acción de control. Por esta razón existen diferentes
protocolos para las redes industriales (Salt, Casanova, & Piza, 2008, pág. 2).
Figura 2.2. Redes industriales(Simatic)
Elaborado por: (Mitsubishi_electronics, 2016)
La configuración de red, cableado dedicado, protocolo, hardware especifico, etc,
convierten a las redes industriales en sistemas de elevada complejidad, costo y
mantenimiento.
2.2. Estudio y análisis de las redes control usando un medio compartido (TCP/IP)
Los sistemas de control en red rompen varios esquemas y conceptos tradicionales de
teoría de control. El uso de un único medio para comunicar varios elementos de un lazo
cerrado de control, presenta múltiples ventajas como: control centralizado, reducción de
costes de cableado y mantenimiento por trabajar con un protocolo general a nivel de
software y hardware. Sin embargo, en una red industrial existen varios bucles de control,
el elevado número de sensores y actuadores que generan información pueden reducir la
eficiencia de la red, presentando retardos en la comunicación (Casanova, Sistemas de
control basados en red. Modelado y Diseño de estructuras de control, 2011, pág. 14).
La información que circula entre los diferentes nodos de la red, no tienen un tiempo fijo
que garantice su actualización. Al trabajar con una red no determinística se integra el
concepto de control asíncrono.
7
Tanto los elementos de red administrativos e industriales se comunicarían con un solo
protocolo, es decir, toda la pirámide de automatización tendría un solo lenguaje
universal.
Figura 2.3. Sistemas de control con medio compartido
Elaborado por: (Casanova, Sistemas de control basados en red.
Modelado y Diseño de estructuras de control, 2011, pág. 14)
Sin embargo, los retardos son un factor crítico para el proceso de control y son
imposibles de eliminar por la naturaleza de la red. Se pueden presentar soluciones desde
el área de control y comunicaciones (Casanova, Sistemas de control basados en red.
Modelado y Diseño de estructuras de control, 2011, pág. 16).
En el área de control se pueden incorporar algoritmos que actúen en el sistema durante la
ausencia de información. Estos algoritmos pueden predecir el comportamiento del
sistema en base a las características físicas. Para poder optimizar el uso del ancho de
banda de la red, se puede programar a los elementos industriales que solo envíen la
información cuando sea necesario (Control por eventos), a diferencia de los sistemas de
control convencionales que están constantemente monitoreando el proceso.
En el área de comunicaciones se puede analizar los límites de funcionamiento de la red,
analizar el tráfico que existe con los múltiples nodos que envían información. Levantar
un estudio que muestra la eficiencia de la red en varios escenarios enfocándose en el
estudio probabilístico de retardos.
8
2.3. Situación actual de WCS y NCS
Un sistema de control en red (NCS, Networked Control System) es un sistema de control
en el que los bucles de control están cerrados a través de una red de comunicación. Su
característica principal es que las señales de control o de retroalimentación se
intercambian entre los componentes del sistema de control en forma de paquetes de
información a través de una red TCP/IP. (Ruiz & Jiménez, 2013)
En la actualidad el funcionamiento de un NCS se realiza mediante el uso de los
elementos básicos en un proceso de control industrial (Hristu-Varsakelis, 2005):
Sensores, para la toma de señales, datos o adquirir información.
Controladores, para determinar decisiones y órdenes.
Actuadores, para ejecutar acciones o comandos y
Red de comunicación, para permitir el intercambio de información.
De los cuatro componentes descritos anteriormente, el que se distingue en los NCS es la
red de comunicación ya que en este caso se maneja bajo el protocolo TCP/IP. La
característica más importante de un NCS es que conecta el ciberespacio con el espacio
físico, esto permite la ejecución de varias tareas desde larga distancia. (Monsalve &
Arias, 2013)
2.3.1 Costo
Actualmente la implementación de una Red para realizar el control de procesos
productivos puede resultar sumamente costosa, esto depende de la magnitud que tenga la
red, el lugar donde se va a implementar y de los equipos necesarios para la misma. Por
lo que la opción de implementar un NCS y un WCS resultan una buena alternativa que
por ejemplo eliminan el cableado innecesario reduciendo la complejidad y el coste total
en el diseño e implementación de los sistemas de control. También se pueden modificar
o actualizar fácilmente añadiendo sensores, actuadores y controladores a un costo
relativamente bajo y sin cambios importantes en su estructura. (Hespanha &
Naghshtabrizi, 2007)
9
2.3.2 Aplicaciones
Sus aplicaciones potenciales son numerosas y abarcan una amplia gama de industrias
tales como: exploración espacial y terrestre, acceso en entornos peligrosos,
automatización de fábricas, diagnóstico y solución de problemas remotos, instalaciones
experimentales, robots domésticos, aviones, automóviles, Tele operaciones. Por otro
lado, mientras que las aplicaciones potenciales de los NCS y WCS son numerosas, las
aplicaciones probadas son pocas, y para explotar la capacidad real de los NCS se deberá
desarrollar aplicaciones optimas que se apliquen de forma real a conceptos de control ya
definidos. Por esta razón, muchos de los proyectos con NCS y WCS para el control de
procesos productivos están en etapa de diseño e investigación. (Hristu-Varsakelis, 2005)
2.3.3 Problemas y soluciones
El desarrollo de Internet combinado con las ventajas proporcionadas por los NCS y
WCS atrae el interés de investigadores de todo el mundo, pero con las ventajas, varios
desafíos también surgen, dando lugar a muchos temas de investigación importantes
como: nuevas estrategias de control, fiabilidad y la seguridad de las comunicaciones, la
asignación de ancho de banda, el desarrollo de protocolos de comunicación de datos, las
correspondientes estrategias de control de fallas y de tolerancia a fallos. (Monsalve &
Arias, 2013)
La inserción de una la red de comunicación TCP/IP en un bucle de control con
realimentación hace que el análisis y diseño de un NCS sea complejo, ya que esto genera
retardos adicionales en los bucles de control o la posibilidad de pérdida de paquetes.
Dependiendo de la aplicación para la que desee utilizar un WCS, los retardos en el
tiempo pueden imponer severos problemas en el rendimiento de la red y por ende del
sistema de control. (Hespanha & Naghshtabrizi, 2007)
Esto genera que se investiguen y propongan soluciones utilizando conceptos de varias
áreas de control tales como control robusto, control estocástico óptimo, control
predictivo, lógica difusa, etc.
10
Además, una de las cuestiones más críticas e importantes que rodean el diseño de NCS
distribuidos con la complejidad cada vez mayor es satisfacer los requisitos de fiabilidad
de la red, garantizando un alto rendimiento del sistema en un amplio rango de
funcionamiento. Esto hace que las redes basadas en la detección de fallos y técnicas de
diagnóstico, reciban cada vez más y más atención. (Hespanha & Naghshtabrizi, 2007)
Con las nuevas velocidades de internet y mejoras en general de la red (Wi-fi ac, Li-fi,
etc.), el mundo del futuro será una red inmensa de información que integrara
dispositivos de varias áreas, desde equipos electrodomésticos hasta sistemas complejos
militares.
2.4. Ventajas y desventajas
En la siguiente tabla se muestran las ventajas y desventajas de los NCS-WCS y las redes
industriales convencionales.
Tabla 2.1. Ventajas y desventajas entre NCS-WCS y Redes Industriales Convencionales
NCS – WCS Redes Industriales
Ventajas Desventaja
Implementación de un Protocolo general para toda la pirámide
automatización
En la pirámide se utilizan diferentes protocolos dependiendo del nivel de
automatización
Instalación de un cableado general para los diferentes nodos de red
Necesitan de un cableado dedicado que requiere de dispositivos adicionales
exclusivos de la marca
Red escalable ya que, tanto dispositivos cableados o inalámbricos, ingresan a la red de forma ágil y dinámica sin mayor
dificultad en la configuración
Dependiendo de la red, se requiere de un elevado conocimiento del protocolo
para incorporar un nuevo elemento
Bajo costo de instalación y mantenimiento
Elevados costos de instalación y mantenimiento
Desventajas Ventajas Requiere de algoritmos de control y
compensación de elevada complejidad Se aplican algoritmos de control
tradicionales
Presenta retardos aleatorios Red determinística
Elaborado por: Alex Bonilla
11
CAPÍTULO 3
DISEÑO E IMPLEMENTACIÓN
3.1 Funcionamiento de los elementos que conforman un proceso de control dentro
de una red industrial convencional.
Dentro de un sistema de control existen varios elementos que interactúan y gestionan
información, básicamente en un lazo de control cerrado existe: sensor, actuador y
controlador. Pero en una empresa existen varios lazos de control, cada elemento o área
genera diferente cantidad de información.
Dependiendo del tamaño o dimensión de la información generada por cada elemento en
la red, existen diferentes plataformas que facilitan la transmisión de datos. Por el bus de
campo pueden circular desde un bit hasta paquetes.
Figura 3.1. Protocolos de una red de Control Industrial
Fuente:http://image.slidesharecdn.com/smartinstrumentsfieldbusethernetandwirelessrev33-
140704022855-phpapp02/95/smart-instruments-fieldbus-ethernet-and-wireless-10-
638.jpg?cb=1410828356
12
Un factor importante en procesos de control es la velocidad de transmisión o la garantía
de que se actualice la información en un intervalo de tiempo definido (redes
determinísticas). Pero la relación entre velocidad y cantidad de datos es inversamente
proporcional, por ello las redes de control fueron diseñadas teniendo como prioridad la
cantidad de información que genera cada elemento.
En el nivel más bajo de la pirámide de automatización sus elementos tienden a enviar
pequeñas cantidades de información, se analiza la red ASI y sus características.
Una red ASI se basa en la técnica de sondeo de un maestro a varios esclavos,
conociendo la información de todos los nodos en 5ms. Los elementos característicos de
la red son: Maestro, Esclavos, Fuente de alimentación, cable de conexión. (Universidad
de Valencia, redes de comunicación, pag 41)
Figura 3.2. Tipo de datos en función del servicio
Elaborado por: Alex Bonilla
Figura 3.3. Esquema redes ASI
Fig. a) Esquema de conexión de red ASI b) cable ASI y método de conexión
Fuente: Universidad de valencia, redes de comunicación, pag 42
13
Si se analiza la trama del maestro y esclavo de la red ASI, el maestro cuenta con 14 bits.
En los bits del maestro de A4 a A0 se posiciona la dirección del esclavo al que se le
solicita información, el esclavo responde con una trama de 7 bits en donde los bits de
datos son desde I3 a I0, es decir, que solo puede enviar 4 bits de información (Fig.
siguiente).
Un esclavo ASI solo puede enviar un nibble de información, 4 entradas o salidas
digitales (on/off) o en su defecto una variable análoga con solo 4 bits de resolución.
Cuando dispongo de elementos que generan una mayor cantidad de información esta red
quedaría obsoleta, basta con que algún elemento de la red envié un entero (16bits) para
buscar una red que este en el próximo nivel de la pirámide de
automatización. (Cáceres, 2013)
3.2 Esquema y modelos de redes para el estudio de los NCS/WCS.
Para el análisis del proyecto se proponen tres escenarios de trabajo para lo cual se
procede a diseñar los distintos modelos que se detallan a continuación:
Figura 3.4. Trama de datos
Fuente: Universidad de valencia, redes de comunicación, pag 57
14
3.2.1 Modelo1: Modelo básico de Red de Control.
En este escenario se plantea un modelo de control simple, en el cual constan un sensor,
un controlador y un actuador; de tal forma que se pueda evaluar los datos que
intercambian entre sí. Una vez que se ha revisado la configuración básica del software
OPNET Modeler, se procede a partir de la creación del escenario para la simulación, en
este escenario se procede con lo siguiente:
Para el primer ejemplo se analiza el tráfico entre 3 terminales antes descritas como
sensor, actuador y controlador.
En la ventana de “Objet palett tree” se despliegan las opciones de dispositivos que se
pueden utilizar, para este ejemplo se seleccionó previamente “Wireless_station_adv” en
modo de “fixed_node” o “nodo fijo.
Figura 3.5. Figura 18: Red del Modelo 1
Elaborado por: Alex Bonilla
Figura 3.6. Paleta de opciones para el Modelo
Elaborado por: Alex Bonilla
15
Se da clic derecho sobre el mismo y se selecciona “Edit Atributes, tras lo cual se
desplegará la siguiente ventana
En esta ventana es donde se pueden configurar las características con las cuales va a
trabajar el equipo. Para este ejemplo en particular la configuración de los tres terminales
(Sensor, controlador y actuador) es la misma, únicamente cambian el destinatario por lo
cual se puede configurar un terminal y luego copiarlo.
Aquí se determinaran los parámetros del tráfico a generar, para lo cual se configura lo
siguiente:
Start time: Es el instante en el que la aplicación empieza a generar tráfico, por
defecto está configurado en never, lo cual se modifica al valor “uniform (0.1,
1.0)”, esto significa que se establece un rango entre 0.1 y 1.0 segundos donde
comienza la simulación, este valor variará cada vez que se realice un nuevo
“run” de la simulación.
ON state time: El tráfico se genera cuando la aplicación está en ON y deja de
hacerlo cuando la aplicación está en OFF, por lo cual se modifica para que
siempre este en ON hasta que se termine el tiempo de la simulación. Esto se
obtiene seteando un valor superior al tiempo de simulación, por ejemplo se
configura en un valor “constant (10000)” segundos.
Figura 3.7. Atributos de un nodo
Elaborado por: Alex Bonilla
16
OFF state Time: Es el parámetro que permite determinar en qué momento se deja
de generar tráfico, como se explicó anteriormente para este ejemplo no se desea
que deje de generar tráfico hasta que termine el tiempo de la simulación, para los
cual se setea un valor “constant (0)”.
Packet Generation Arguments: En esta opción se configuran los parámetros que
va a tener el tráfico a generarse.
- Interarrival time: Es el tiempo entre cada paquete, es decir se envía un
paquete, la aplicación espera un tiempo de llegada y envía un nuevo
paquete, así sucesivamente. Se le asigna un valor exponencial (1) de tal
forma que el tiempo que se espera varíe siempre entre paquete y paquete.
- Packet size: Es el tamaño que va a tener cada paquete. Para la realización
de este proyecto, se ha determinado un tamaño constante de 64 Bytes que
es el valor mínimo que se puede enviar en el protocolo TCP/IP. Este
valor se determina ya que en las redes de control industrial el tamaño de
los datos transmitidos es mínimo (en el rango de los bits).
- Segmentation size: Este parámetro ayuda a hacer una segmentación de
paquetes siempre y cuando el paquete sea demasiado extenso, para este
caso, dado que el tamaño de los paquetes es el menor posible y ya que
este valor va a ser constante, no es necesarios utilizarlo, por lo que se fija
en un valor de “No Segmentation”
Stop time: Finalmente se determina el instante en el que se desea que termine la
aplicación, como no se desea que termine hasta que finalice el tiempo de
simulación se setea el valor “never”.
El siguiente parámetro a configurar es la “Wireless LAN MAC Address”, este parámetro
permite diferenciar a cada nodo para definir los enlaces que se van a crear, es decir
permite direccionar el tráfico. Es importante recalcar que el simulador no necesita que se
determine un protocolo como el TCP/IP, para direccionar los dispositivos, el simulador
evita este proceso de asignar una dirección IP a cada elemento de la red ya que no se
centra en esa configuración, sino que, más importante es el analizar el tráfico que se
genera en la misma. Esto no quiere decir que no se pueda crear una tabla de
17
direccionamiento o que no se pueda configurar direcciones IP en los nodos, todo lo
contrario, el simulador es muy potente y puede configurar parámetros como Dirección
IP, mascara de red, Gw, etc., de forma automática, y para revisarlos basta con
seleccionar la opción de IP en los parámetros a simular como se verá más adelante.
El siguiente parámetro que se debe configurar es la “Destination Address”. Este
parámetro permite especificar hacia que nodo se desea emitir el tráfico, es decir, el nodo
que tiene la “Wireless LAN MAC Address 1” enviará tráfico hacia el nodo que posee la
“Wireless LAN MAC Address 2”
Una vez configurados los parámetros antes descritos la tabla queda de la siguiente
manera:
De la misma forma se configuran los 2 nodos restantes en donde es necesario variar la
“Wireless LAN MAC Address” y la “Destination Address” de acuerdo a lo deseado por
lo que los nodos restantes quedan configurados de la siguiente manera.
Figura 3.8. Parámetros configurados en nodo Sensor, modelo 1
Elaborado por: Alex Bonilla
18
A continuación se selecciona las estadísticas a evaluar en la simulación, estas se
seleccionan de modo global y de modo individual.
Para las estadísticas de modo Global se debe hacer clic derecho en cualquier parte del
escenario y seleccionar la opción “Choose individual DES Statistics” luego de lo cual se
despliega la siguiente ventana de donde se debe seleccionar los siguientes items:
Figura 3.9. Parámetros configurados en nodos restantes, modelo 1
(a) (b)
Fig. (a) Parámetros configurados en nodo Controlador
Fig. (b) Parámetros configurados en nodo Actuador
Elaborado por: Alex Bonilla
Figura 3.10. Selección de Estadísticas en modo Global
Elaborado por: Alex Bonilla
19
Para seleccionar las estadísticas de modo individual se debe dar clic derecho sobre el
nodo a configurar y seleccionar nuevamente la opción “Choose individual DES
Statistics” luego de lo que aparece una ventana en donde se debe seleccionar los
siguientes parámetros.
Lo mismo se aplica para los nodos restantes.
Una vez que se han configurado estos parámetros se configurar el número de eventos y
tiempo de simulación, esto se hace en “DES, Configure/Run Discrete event simulation”
en donde se despliega la siguiente ventana. Para este caso se configura un tiempo de 30
minutos y valores por estadística de 100.
Finalmente una vez que se han configurado todos estos parámetros se procede a iniciar
la simulación mediante el botón de “Run”.
Figura 3.11. Selección de Estadísticas Individuales
Elaborado por: Alex Bonilla
Figura 3.12. Configuración de los parámetros de la simulación
Elaborado por: Alex Bonilla
20
Para revisar las estadísticas generadas se selecciona “Results Browser”
En la ventana de “Results Browser” se puede ir seleccionando uno a uno los parámetros
que se desea revisar, como por ejemplo los retardos, o el tráfico que se envía y recibe, lo
cual es muy práctico a la hora de evaluar la eficiencia de la red o comparar los nodos
entre sí, estos datos se van graficando al lado derecho de la pantalla de acuerdo al orden
en el que han sido seleccionados.
En la primera gráfica se visualiza el retardo “Delay” generado en la Red de modo
Global. En la segunda gráfica del nodo CLIENTE_1_SENSOR se ve el tráfico enviado
en bits/seg, en la gráfica 3 y 4 del nodo CLIENTE_2_CONTROLADOR se ve el tráfico
Figura 3.13. Ventana del navegador de Resultados
Elaborado por: Alex Bonilla
Figura 3.14. Ejemplo del tráfico generado en el modelo 1
Elaborado por: Alex Bonilla
21
recibido y enviado en bits/seg respectivamente y en la gráfica 5 se ve el tráfico recibido
por el CLIENTE_3_ACTUADOR en bits/seg.
3.2.2 Modelo 2: Modelo de Red Multimedia en la que interactúa un segmento de
red dedicado a realizar acciones de control (NCS/WCS) con parámetros Ethernet.
Para continuar con el estudio de los WCS se desarrolló el Modelo 2, que se ve en la
figura X. Para entender mejor lo que se desea simular se debe recalcar que el simulador
riverbed OPNET es netamente un simulador de redes de computadoras y que lo que se
ha hecho en el presente proyecto es asimilar el comportamiento de estos equipos como si
fueran los propios de una red de control industrial, esto dado que el principio de los
WCS es que todos los dispositivos que interactúan en la red de control puedan ser
controlados e identificados por medio de tecnología inalámbrica que al momento se
comunica utilizando tecnología Wi-Fi (802.11 a/b/g/n) que utiliza el protocolo de
comunicación TCP/IP.
El protocolo TCP/IP posee características bajo las cuales se rige este proyecto, una de
ellas por ejemplo es que el tamaño mínimo de los paquetes que se transmiten es de 64
Bytes.
Figura 3.15. Modelo de red multimedia
Elaborado por: Alex Bonilla
22
La opción que se propone para el estudio de un sistema de control es la arquitectura de
red “Cliente – Servidor” que permite el envío y recepción de datos por medio de un
“request”, esto puede ser programado en el receptor de manera que filtre y separe los
datos que necesita para ejercer el control sobre un dispositivo específico. Esto depende
del proceso que se va a controlar ya que el tiempo de respuesta en los actuadores puede
ser delicado, por lo que si son procesos de control de lenta reacción este método resulta
muy eficiente, pero si ya se habla de procesos de rápida respuesta este método no es lo
suficientemente adecuado por lo que se hace necesario plantear opciones adicionales que
complementen este procedimiento. Una vez definido el uso del protocolo HTTP se
procede con la simulación.
3.2.2.1 Modelo 2: Desarrollo
Para el análisis de la carga de tráfico que contiene un WCS se plantea el uso de distintas
aplicaciones que en este caso son HTTP, DATOS (FTP) y VIDEO, de modo que se
estudie una red Multimedia dentro de la cual la aplicación HTTP simule la carga de
trafico de un procesos de control (WCS). Para la realización de este Modelo se procede
de forma similar al Modelo anterior, pero en la ventana de “Select Tecnologies” se
seleccionan las opciones “Wireless_lan_advance” y “Ethernet” ya que hay
componentes de estos dos tipos de tecnología en la red.
En el caso de los servidores, estos son equipos para los que no es necesaria la utilización
de tecnología inalámbrica, por su función y seguridades estos equipos no suelen poseer
esta característica.
Continuando con la simulación se necesitan los siguientes equipos:
Wlan_ethernet_router_adv
Wlan_wkstn_adv
Ethernet_16_switch_int
Ethernet_server_int
Bloque de Aplication_Configuration
Bloque de Profile_Configuration
23
Para los equipos que no son inalámbricos se utiliza un enlace cableado en estándar “100
Base T”, este se selecciona en la paleta de herramientas dentro de la librería de equipos
Ethernet, y con él se crean los enlaces router - switch y switch - servidor.
Lo más importante en este modelo es configurar las aplicaciones que van a generar
tráfico, esto se hace en el “Bloque de Application Configuration”, que permite
configurar una aplicación en común para un grupo de nodos o estaciones.
Dando clic derecho sobre el bloque mencionado se selecciona Edit Atributes y se
modifica el número de filas a 3 definiendo las aplicaciones VIDEO, DATOS y HTTP.
Figura 3.16. Red del modelo 2
Elaborado por: Alex Bonilla
Figura 3.17. Ventana de atributos en el bloque Aplication Configuration
Elaborado por: Alex Bonilla
24
Luego de estos se configuran las aplicaciones. Esto se puede realizar rápidamente
seleccionando alguna de las opciones que se presentan por default que usualmente tiene
características para generar una baja, media o alta carga de tráfico en la red, sin
embargo, existe la opción de configurar manualmente los parámetros de la aplicación;
así se fijan los siguientes parámetros:
Una vez creadas las aplicaciones se procede a crear los perfiles que contendrán esas
aplicaciones en el “Bloque de Profile_Configuration”.
Dando clic derecho sobre el bloque mencionado y seleccionando Editar atributos se
despliega la ventana donde se modifica la pestaña “Profile Configuration” donde se
cambia el número de filas a 3 y se le asigna a cada perfil un nombre fácil de identificar,
generalmente relacionado con la aplicación. En este caso se utilizó VID, DAT y HT.
Figura 3.18. Ventanas de configuración de aplicaciones.
Figura (a): Configuración, aplicación de video
Figura (b): Configuración, aplicación de datos
Figura (c): Configuración, aplicación de http
Elaborado por: Alex Bonilla
25
Para cada perfil en la pestaña de Application se asigna la aplicación correspondiente
previamente creada, y adicional se configura el tiempo en el que se desea que empiece a
trabajar para lo que se setea en “Start time” un valor constante (0) en los 3 perfiles, esto
quiere decir que las aplicaciones iniciaran desde el instante en que arranque la
simulación.
Luego se configura el Servidor, para lo cual se da clic derecho sobre el mismo y se
selecciona Edit Attributes, donde los parámetros principales a configurar son la “Server
Address” a la que se le puede asignar un nombre que posteriormente será usado para que
los terminales sepan hacia donde destinar su tráfico, en este caso se le asignó el nombre
Figura 3.19. Ventana de atributos en el bloque Profile Configuration
Elaborado por: Alex Bonilla
Figura 3.20. Configuración de las aplicaciones dentro de los perfiles
Elaborado por: Alex Bonilla
26
SRVR_GEN. El otro parámetro a configurar está en la pestaña “Applications”, dentro de
ésta se configura la opción “Application: Supported Services”.
En la opción “Application: Supported Services” se debe cambiar el número de filas a
tres y asignar las aplicaciones creadas anteriormente.
Ahora se procede con la configuración de los terminales. Para esto, se debe tomar en
cuenta que aplicación es la que va a utilizar cada uno de ellos, por lo que se procede de
la misma forma dando clic derecho sobre el terminal y seleccionando Edit Attributes.
En la pestaña “Applications” se modifica la opción “Application: Destination
Preferences”, se selecciona la aplicación correspondiente ya sea VIDEO, DATOS o
Figura 3.21. Configuración de los atributos del servidor
Elaborado por: Alex Bonilla
Figura 3.22. Configuración de los atributos del servidor, supported services
Elaborado por: Alex Bonilla
27
HTTP y en la opción “Actual Name” se fija el punto de acceso, en este caso el Servidor
hacia donde se desea que se transmita la información.
Una vez fijados estos valores, se establece que el tráfico generado por el terminal de
VIDEO se destinara hacia el servidor y viceversa. Esto debe realizarse en cada uno de
los terminales de la red, tomando en cuenta que lo que cambia es la aplicación con la
que va a trabajar.
Dado que en la simulación, los terminales y el router son equipos con tecnología
Wireless, hay que configurarlos dentro del mismo segmento de red para que estos
puedan interactuar entre sí. Esto se logra mediante la configuración del BSS Identifier.
Figura 3.23. Configuración de los atributos del servidor, destination preferences
Elaborado por: Alex Bonilla
Figura 3.24. Configuración de los atributos del servidor, actual name
Elaborado por: Alex Bonilla
28
El BSSI (Basic Service Set Identifier), de una red de área local inalámbrica (WLAN), es
un nombre de identificación único de todos los paquetes de una red inalámbrica para
identificarlos como parte de esa red
Este valor se configura de acuerdo al segmento de red en donde se encuentran los
equipos, si hay más de un segmento, tanto router como equipos deben asumir valores
correspondientes a ese segmento.
Lo mismo se debe configurar en los terminales con la aplicación de DATOS y HTTP,
así como también el router que es inalámbrico.
Una vez configurados todos los parámetros para la simulación se procede a establecer
los datos estadísticos a obtener. Para esto se deben seleccionar los eventos deseados
Figura 3.25. Configuración de BSS Identifier
Elaborado por: Alex Bonilla
Figura 3.26. Configuración del router
Elaborado por: Alex Bonilla
29
dando clic derecho en cada uno de los nodos y seleccionar la opción “Choose individual
DES Statistics”
Dentro de cada nodo se debe seleccionar los eventos de acuerdo a la aplicación que
maneja. Para el caso del nodo con la aplicación HTTP se debe seleccionar las opciones
“Client Http” y “Wireless Lan”, adicionalmente se puede seleccionar otras opciones
como IP, UDP, etc.
Se procede de forma similar con los otros nodos
Figura 3.27. Datos estadístico en modo individual, (Http)
Elaborado por: Alex Bonilla
Figura 3.28. Datos estadístico en modo individual (Datos)
Elaborado por: Alex Bonilla
30
Así mismo se deben seleccionar los eventos a simular de forma Global, dando clic
derecho en el escenario de simulación y seleccionando la opción “Choose individual
DES Statistics” donde se deben seleccionar las siguiente opciones:
Figura 3.29. Datos estadístico en modo individual (Video)
Elaborado por: Alex Bonilla
Figura 3.30. Datos estadístico en modo global
Elaborado por: Alex Bonilla
31
Una vez configurados los eventos a simular se procede a hacer “run” en la simulación,
en la ventana previa se configura el tiempo y número de eventos a simular. Para este
caso se selecciona 10 minutos.
Finalmente se puede revisar la simulación, en donde uno de los aspectos más
importantes es el retardo que se genera en los nodos de acuerdo a la aplicación que
utilizan.
Figura 3.31. Configuración del tiempo de simulación
Elaborado por: Alex Bonilla
Figura 3.32. Gráficas del tráfico generado en el modelo 2
Elaborado por: Alex Bonilla
32
En la gráfica se ven los retardos generados por cada aplicación en el segmento de
Wireless Lan, en la cual claramente la aplicación que genera más retardos por el
volumen de datos que transmite es la aplicación de Video.
Si se analiza el tráfico que generan esta aplicaciones se puede ver que el trafico más
elevado es el que corresponde a la aplicación de Video, sin embargo se mantiene
cercano a los parámetros normales de trabajo para una transmisión de datos de Video de
baja resolución que es cercano a los 1000 Kbps.
Esto permite evaluar que tan eficiente es una red multimedia en donde existen
aplicaciones de Control (Http), Video y Datos, así como definir los parámetros idóneos
para que una red de este tipo pueda ser implementada.
3.2.3 Modelo 3: Modelos de Red Multimedia
3.2.3.1 Modelo 3 A: Modelo de Red Multimedia en un entorno de Planta Industrial
Para este modelo de Red se plantea los posibles nodos existentes en el entorno de una
planta industrial. La planta se divide en dos zonas completamente distintas que son la
zona de oficinas y la zona de producción, en las que el número de nodos varía de
acuerdo a las necesidades.
Pare este Modelo la Planta se ubica en la ciudad de Quito – Ecuador
Figura 3.33. Gráficas de retardos en el modelo 2
Elaborado por: Alex Bonilla
33
En la planta la parte de Producción abarca toda el área donde se realizan procesos de
control, y la parte de Oficinas es donde se realizan acciones administrativas.
En el Modelo 3 se plantea la idea de simular una Planta de fabricación de Autos, por lo
que se determinan tres procesos principales: Ensamblaje, Pintura y Test. Adicional en
Oficinas se crea el segmento de red Administrativo.
Para determinar cuántos nodos con sus respectivas aplicaciones se deben utilizar en cada
uno de estos segmentos de la red se crea la Tabla 2.
Figura 3.34. Ventana del entorno de simulación del modelo 3
Elaborado por: Alex Bonilla
Figura 3.35. Red del modelo 3a
Elaborado por: Alex Bonilla
34
Tabla 3.1. Número de nodos de acuerdo a su aplicación
MODELO3 VIDEO DATOS HTTP # TOTAL EN LINEA
ENSAMBLAJE 2 3 18 23
PINTURA 4 3 15 22
TEST 1 4 12 17
ADMIN 3 6 0 9
# TOTAL EN APP 10 16 45 71
Elaborado por: Alex Bonilla
Con los datos de la tabla se arma la red con los elementos que anteriormente se
utilizaron en el Modelo 2:
Wlan_ethernet_router_adv
Wlan_wkstn_adv
Ethernet_16_switch_int
Ethernet_server_int
Bloque de Aplication_Configuration
Bloque de Profile_Configuration
Cada segmento de red queda definido como se ve a continuación:
Ensamblaje
Figura 3.36. Segmento de red de ensamblaje
Elaborado por: Alex Bonilla
35
Pintura
Test
Administrativo
Figura 3.37. Segmento de red de Pintura
Elaborado por: Alex Bonilla
Figura 3.38. Segmento de red de Test
Elaborado por: Alex Bonilla
Figura 3.39. Segmento de red Administrativo
Elaborado por: Alex Bonilla
36
Como se puede observar en cada proceso se cuenta con un número determinado de
nodos y su respectivo router, posteriormente este router se conecta un switch que los
concentra y los enlaza con un Servidor general, que transmite información a toda la red
y que por ende maneja las Aplicaciones de Http, Video y Datos.
Las configuraciones de red del Modelo 3 son idénticas a las configuraciones del Modelo
2, sin embargo el cambio notable es el número de nodos que interactúan en la red, lo que
origina considerables diferencias en el tráfico que se va a generar para cada aplicación.
Figura 3.40. Aplicaciones del modelo 3a
Elaborado por: Alex Bonilla
Figura 3.41. Perfiles del modelo 3a
Elaborado por: Alex Bonilla
37
Una vez realizadas las configuraciones pertinentes de Aplicaciones, Perfiles, Enlaces y
Eventos estadísticos, se puede ejecutar la simulación.
Para el Modelo 3a se configura un tiempo de simulación de 3 minutos, ya que el alto
número de nodos hace que se genere un alto número de eventos, por lo que hacer una
simulación más larga resulta imposible, esto sucede ya que tratándose de la versión
académica del Software OPNET el número de eventos estadísticos se limita a 50
millones.
Una vez configurado esto se da “run” y se espera a que termine la simulación.
Una vez que se obtienen los datos se puede comparar el tráfico en cada una de las
aplicaciones a manera global.
Figura 3.42. Ejecución de la simulación
Elaborado por: Alex Bonilla
Figura 3.43. Gráficas del tráfico generado en el modelo 3a
Elaborado por: Alex Bonilla
38
El análisis de estas graficas permitirá definir la eficiencia de la red y el comportamiento
del tráfico de control de los WCS en una red multimedia.
3.2.3.2 Modelo 3 B: Simulación de un modelo de Red Multimedia en un entorno de
Planta Industrial con variaciones en tráfico de acuerdo a horas laborales.
Dentro de una red se debe tomar en cuenta eventos o situaciones que pueden generar una
mayor carga de tráfico, en un inicio se propone el funcionamiento de la planta durante
las 24 horas del día, sin embargo no todas las áreas de la Planta trabajan continua e
ininterrumpidamente, por ende el consumo de recursos de la red debe variar de acuerdo
a un horario.
Dado que no se puede generar una simulación en un lapso mayor a 3 minutos, (como se
explicó anteriormente en el Modelo 3 a) se plantea realizar una simulación de 2 minutos,
en la cual se asignan 5 segundos para representar cada hora del día, es decir:
5 𝑠𝑒𝑔 = 1 ℎ𝑜𝑟𝑎
24 ℎ𝑜𝑟𝑎𝑠 = 120 𝑠𝑒𝑔 = 2 𝑚𝑖𝑛
Para el análisis de este ejemplo se proponen los datos fijados en la Tabla 3, que indica
los intervalos a configurar en las diferentes aplicaciones.
Figura 3.44. Red del modelo 3b
Elaborado por: Alex Bonilla
39
Tabla 3.2. Escala de conversión de horas a segundos
ESCALA DE CONVERSION DE HORAS A SEGUNDOS DENTRO DE LA SIMULACIÓN
MADRUGADA MAÑANA TARDE NOCHE
INTERVALO 00:00 - 07:00 07:00 - 12:00 12:00 - 18:00 18:00 24:00
# DE HORAS 7 5 6 6
JORNADA (seg) 0 – 35 35 - 60 60 - 90 90 - 120
Elaborado por: Alex Bonilla
En la Tabla 3, se analiza los intervalos de trabajo en la Planta, y se convierte el número
de horas a segundo, es decir los 120 segundos de la simulación equivalen a las 24 horas.
Una vez definidos los espacios de tiempo se procede a analizar en cuál de estos espacios
trabajaran las diferentes aplicaciones, para lo cual se realiza la Tabla 4.
Tabla 3.3. Intervalos de trabajo en las aplicaciones
INTERVALOS DE TRABAJO PARA LAS APLICACIONES
MADRUGADA MAÑANA TARDE NOCHE
INTERVALOS (seg) 0 - 35 35 - 60 60 - 90 90 - 120
# DE HORAS 7 5 6 6
HTTP SI SI SI SI
VIDEO NO SI SI NO
DATOS NO SI NO NO
Elaborado por: Alex Bonilla
En la Tabla 4, de acuerdo a lo analizado se puede diferenciar que aplicaciones trabajaran
durante todo el día o solo en determinadas horas, esto se logra estableciendo el uso de
aplicaciones de acuerdo a necesidades de una planta. Así se obtiene los valores de la
Tabla 5:
Tabla 3.4. Asignación de tiempos en la simulación
ASIGNACION DE TIEMPOS DE SIMULACIÓN
# HORAS INTERVALO (seg) DURACIÓN (seg)
HTTP 24 0 -120 120
VIDEO 11 35 - 90 55
DATOS 5 35 - 60 25 Elaborado por: Alex Bonilla
40
En la Tabla 5 se puede reconocer los intervalos de tiempo a configurar en la simulación
con los cuales trabajarán las respectivas aplicaciones.
Una vez definidos los intervalos de tiempo para las aplicaciones se procede a
configurarlos en la simulación. Esto se lo hace en el “Bloque de Profile_Configuration”
en la pestaña de “Profile Configuration” se cuenta con los perfiles creados para las
aplicaciones de Video, Datos y Http respectivamente.
Desplegando las pestañas para cada aplicación hay que configurar las siguientes
opciones:
- Start time Offset (seconds): Esta opción permite configurar cuando comienza a
generarse tráfico en la aplicación, así que se selecciona un valor “constant (n)”
donde n es el instante (en segundos) en que arranca el flujo de tráfico de acuerdo
a la tabla anterior.
- Duration (seconds): En esta opción se determina cuanto tiempo va a durar ese
flujo de tráfico y también se configura con la opción “constant (t)” donde t es el
tiempo de duración del flujo de tráfico definido en la tabla anterior.
Hay que tomar en cuenta que estos parámetros se pueden configurar tanto en la
aplicación como en el perfil.
Una vez configuradas las aplicaciones, los valores quedan de la siguiente forma:
Figura 3.45. Aplicaciones asignadas a los perfiles del modelo 3b
Elaborado por: Alex Bonilla
41
El resto de parámetros a configurar quedan iguales al Modelo 3 a.
Previo a ejecutar la simulación, se debe verificar que el tiempo de simulación
corresponda a 2 minutos. Una vez terminada la simulación se puede confirmar el flujo
de tráfico de acuerdo a los intervalos configurados anteriormente, como se ve en la
Figura 3.48.
Figura 3.46. Intervalos de tiempo en la aplicación de video
Elaborado por: Alex Bonilla
Figura 3.47. Intervalos de tiempo en la aplicaciones
Figura (a): Intervalos de tiempo en la aplicación de datos
Figura (b): Intervalos de tiempo en la aplicación de http
Elaborado por: Alex Bonilla
Figura 3.48. Gráficas del tráfico generado en el modelo 3b
Elaborado por: Alex Bonilla
42
De la misma forma si se toman las señales anteriores y se las mide en un solo gráfico se
puede ver como el tráfico se genera en los intervalos de tiempo definidos. Figura 3.49.
3.3 Monitoreo de una red real con características de tráfico similares a las
simuladas, mediante el uso del Software PRTG
El Software PRTG permite el monitoreo de una red para evaluar su rendimiento. Es así
que permite revisar el tráfico que genera un nodo, y las características del mismo.
Para realizar la comparativa con el presente proyecto se configuro tres nodos en una red
doméstica que simularan el tráfico de las aplicaciones desarrolladas en el proyecto
mediante OPNET.
Para simular estos nodos se utilizó:
- Tráfico de Video: Un Pc que está descargando videos.
- Tráfico de Datos: Un Pc que navega en internet
- Tráfico de (Control) Http: Un Arduino UNO con módulo Ethernet configurado
para desplegar una página web con un tamaño fijo de 29 Bytes.
PRTG se encarga de monitorear la red mediante el uso de sensores, el utilizado en este
análisis ya que se basa en navegación de internet es el sensor Http avanzado.
Figura 3.49. Gráficas unificadas del tráfico generado en el modelo 3b
Elaborado por: Alex Bonilla
43
“El sensor HTTP avanzado supervisa el código fuente de una página web mediante el
protocolo de transferencia de hipertexto (HTTP).
- El sensor puede mostrar lo siguiente:
- Tiempo de carga
- Bytes recibidos
- Descargar ancho de banda (velocidad)
- Tiempo hasta el primer byte”
(https://prtg.paessler.com/help/http_advanced_sensor.htm)
Así se crean los nodos Arduino HTTP, Video – PC y Datos - PC con sus respectivos
sensores en la plantilla de Dispositivos del Software PRTG.
Una vez configurados y añadidos los sensores respectivos se puede revisar los eventos
monitoreados en los datos históricos de forma gráfica y numérica.
Figura 3.50. Ventana de dispositivos en la red monitoreados por PRTG
Elaborado por: Alex Bonilla
44
Monitoreo del tráfico de Http en el módulo Arduino
Como se puede ver en la gráfica de la Figura 65, el Ancho de Banda de descarga oscila
entre los 15 y los 232 Kbps como se ve en las unidades del lado derecho, esta oscilación
se da ya que están interactuando otros nodos que también consumen ancho de banda,
mientras que en la tabla de datos se puede ver que los bytes recibidos mantienen un
valor constante de 29 Bytes que se configuraron en Arduino para simular el tráfico del
segmento de la red de control.
Monitoreo del tráfico de Datos
Figura 3.51. Gráfica del tráfico de http monitoreados por PRTG
Elaborado por: Alex Bonilla
Figura 3.52. Gráfica del tráfico de la aplicación datos monitoreados por PRTG
Elaborado por: Alex Bonilla
45
Como se puede ver en la gráfica de la aplicación Datos, el Ancho de Banda de descarga
oscila entre los 10 y los 22 Kbps y los Bytes recibidos mantiene un valor constante de
1606 Bytes.
Tráfico de Video
Como se puede ver en la gráfica el Ancho de Banda de descarga para Video oscila entre
los 373 y los 729 Kbps, y en los Bytes recibidos se mantiene un valor de 44.450 Bytes
que varía levemente en cada muestra, debido a que al tratarse de una aplicación de video
el tiempo de carga y descarga varía, dependiendo del tráfico generado por otras
aplicaciones que exista en la red que también consuman recursos de la misma.
Estos datos permiten analizar el tráfico que se genera en cada nodo, adicional se pude
ver el consumo del ancho de banda de cada uno de uno de ellos que en las gráficas es la
línea en color azul.
Figura 3.53. Gráfica del tráfico de video monitoreados por PRTG
Elaborado por: Alex Bonilla
46
CAPÍTULO 4
PRUEBAS Y RESULTADOS
4.1 Análisis del Modelo1: Modelo básico de Red de Control
En este ejemplo se determina el flujo del tráfico que se origina desde un Sensor a un
controlador y que luego se transmite a un Actuador.
En la gráfica se observa el tráfico que envía el Sensor y que a su vez recibe el
Controlador, como es lógico las gráficas son similares, ya que lo que envía el Nodo 1 es
lo que recibe el Nodo 2, así también se puede revisar el siguiente salto en donde el
controlador envía trafico al actuador y la gráfica debe tener las mismas características.
Esto se debe a que al configurar el tipo de tráfico que se desea generar se determinó un
valor específico para todos los elementos de la red, por lo tanto, los datos varían de
forma imperceptible puesto que puede haber pérdidas o retardos que el simulador genera
aleatoriamente. Sin embargo tratándose de un volumen de datos sumamente reducido
estos eventos no se originan con facilidad, por lo que las gráficas del tráfico
prácticamente no cambian para ninguno de los Nodos.
Cabe recalcar que si hay variación en la medición de los bits transmitidos, se debe a que
al configurar el tipo de tráfico se determinó que se genere tráfico de tamaño aleatorio.
Figura 4.1. Gráfica del trafico enviado y recibido del modelo 1
Elaborado por: Alex Bonilla
47
4.2 Análisis del Modelo 2: Modelo básico de Red de Control
En el modelo 2 se configuró un modelo de red sencillo en el que interactúan 3
aplicaciones, video, datos y http que es la aplicación en la red donde se realiza Control
de procesos. La red se compone de elementos Wireless, en este caso los terminales que
manejan las aplicaciones y elementos cableados, estos últimos son precisamente el
servidor, que en la realidad por conceptos de seguridades no puede ser un elemento
Wireless y el switch que usualmente es un dispositivo cableado.
Dados estos parámetros, se tiene un segmento de Wireless Lan y otro Ethernet, por lo
que en ellos se pueden evaluar los retardos (delay).
Como se puede ver en las gráficas y como es lógico suponer, el retardo en el tramo de
Wireless Lan es muy superior al tramo de Ethernet, aun así hay que tomar en cuenta que
el retardo máximo en la red es de 5 ms. Sin embargo el retardo es un factor importante
ya que para las aplicaciones de Datos y Http que son las que tienen un volumen de datos
pequeño y que no manejan procesos de rápida respuesta este tiempo de retardo es
aceptable. Por otra parte la aplicación de Video es más sensible y tiene un parámetro que
es el retardo máximo permitido de 150 ms, por lo que siempre que no se supere este
parámetro la red será eficiente.
Figura 4.2. Gráfica de retardos en el modelo 2
Elaborado por: Alex Bonilla
48
Estos datos corresponden claramente al tráfico generado por las aplicaciones como se ve
a continuación en la Figura 4.4.
4.3 Análisis del Modelo 3
El modelo 3 se planteó de forma que permita describir gradualmente la configuración
que se estableció para el modelo de NCS/WCS en el entorno de una planta industrial.
En la planta se maneja una red multimedia con un número determinado de usuarios para
cada ampliación, definidas anteriormente como Video, Datos y Http. Estas aplicaciones
trabajan en determinados intervalos de tiempo que se definieron con una aproximación a
Figura 4.3. Gráfica de los retardos en cada aplicación del modelo 2
Elaborado por: Alex Bonilla
Figura 4.4. Gráfica de tráfico generado en cada aplicación del modelo 2
Elaborado por: Alex Bonilla
49
las horas laborales que aplican en la realidad con la relación de que 5 segundos
equivalen a 1 hora.
De forma similar al modelo 2 se pueden evaluar los retardos en la red de forma general
en el tramo Wireless Lan y el tramo Ethernet.
Nuevamente es lógico que en Wireless Lan el retardo sea mayor que en Ethernet, sin
embargo hay que destacar que para este modelo el tiempo máximo del retardo es de 13
ms, lo que quiere decir que con los valores configurados se tiene una red de
comportamiento eficiente para las aplicaciones configuradas ya que no sobrepasa el
retardo máximo permitido en video de 150 ms.
Ahora se analiza el tráfico generado en la red.
Figura 4.5. Gráfica de retardos en el modelo 3
Elaborado por: Alex Bonilla
Figura 4.6. Gráfica de tráfico generado en cada aplicación del modelo 3
Elaborado por: Alex Bonilla
50
Lo primero que se puede destacar es que el tráfico enviado que se genera de acuerdo a
los intervalos de tiempo que se configuraron. Si se comparan las gráficas de las tres
aplicaciones resalta el elevado tráfico que genera la aplicación de Video versus el tráfico
de FTP y Http que prácticamente es imperceptible. Por ende se puede decir que el mayor
consumo y retardos se darán en el intervalo de tiempo en el que trabaja la aplicación de
Video.
Estas aplicaciones se configuraron con parámetros de tráfico bajos.
Se puede analizar el Throughput para determinar cuánto ancho de banda consumen estas
aplicaciones.
En la figura se ve que el Throughput varía dependiendo de los intervalos de tiempo en
los cuales trabajan las aplicaciones. Para una medición estimada del ancho de banda que
Figura 4.7. Gráfica de tráfico generado en intervalos de tiempo
Elaborado por: Alex Bonilla
Figura 4.8. Gráfica del throughput en el modelo 3
Elaborado por: Alex Bonilla
51
se consume se utiliza la gráfica del Throughput en valor promedio. El ancho de Banda se
puede calcular utilizando la siguiente formula:
𝐵𝑊 = 𝐺 ∗ 𝐶 (4.1)
Donde:
- BW: Es el ancho de banda teórico del “enlace más lento”
- G: Es el consumo del ancho de banda garantizado por usuario, medido en Kbps
- C: Concurrencia del usuario (el 30% del total aproximadamente) (Acosta, 2016)
Se toman los valores obtenidos de la Figura 73, donde se ve el consumo de las
aplicaciones solo en los datos enviados. Se toma en cuenta que el Throughput recoge los
valores de los datos enviado, recibido, perdidos, etc. Y que se manejan tres aplicaciones
por lo que el consumo del BW garantizado por usuario será diferente dependiendo de la
aplicación.
- Video: 3000 Kbps
- Datos: 300 Kbps
- Http: 40 Kbps
Con los datos de la Tabla 2 se puede determinar el dato de la concurrencia de usuarios,
que como se explico es el 30% del total de usuarios en este caso por aplicación.
- Video: 4 usuarios
- Datos: 6 usuarios
- Http: 15 usuarios
Aplicando la formula antes mencionada se obtienen los siguientes valores
- BW Video: 12000 Kbps
- BW Datos: 1800 Kbps
- BW Http: 600 Kbps
52
Estos datos originan un consumo de ancho de banda total de 14400 Kbps
aproximadamente.
14400 𝐾𝑏𝑝𝑠 = 14.5 𝑀𝑏𝑝𝑠
Y de acuerdo con la gráfica del Throughput se requieren 14 Mbps, por lo que los datos
son aproximados
Otra forma de verificar si la red funciona adecuadamente es utilizando los datos de
“Paquet Delay Variation” que mide la variación del retardo en paquetes consecutivos, es
decir el tiempo que se demora en llegar un paquete tras de otro. Si este valor es
constante a pesar del tráfico generado por otras aplicaciones, la red se mantiene de forma
efectiva proporcionando los servicios para los que fue diseñada sin problemas.
Para comparar como afecta el tráfico generado por las aplicaciones en la red se
configuran ahora las aplicaciones de Ftp y Http con parámetros bajos, esto dado que la
aplicación con el tráfico más sensible a variaciones es la aplicación de Video.
Figura 4.9. Gráfica de variación de retardo en paquetes en el modelo 3
Elaborado por: Alex Bonilla
Figura 4.10. Variación en la configuración de datos y http
Elaborado por: Alex Bonilla
53
Como se puede ver, al cambiar el parámetro de calidad de Video por una de tipo HD, el
retardo que genera este tráfico aumento considerablemente, sin embargo aún se
mantiene bajo los 13 ms.
De la misma forma el tráfico enviado en Video se disparó a los 6.3 MB/seg en
comparación al caso anterior de 2 MB/seg.
Ahora, analizando la gráfica de “Paquet Delay Variation” se puede ver que aunque hay
flujo de tráfico aparentemente normal, la entrega de los paquetes de video sufre retardos
considerables sobre todo en el momento que también hay tráfico de la aplicación de
Datos en la red.
Figura 4.11. Variación en retardo con tráfico de video más pesado
Elaborado por: Alex Bonilla
Figura 4.12. Variación del tráfico de video
Elaborado por: Alex Bonilla
54
Así mismo se revisa el Throughput se nota claramente que el tráfico generado se ha
duplicado en comparación al caso anterior.
De la misma forma al caso anterior para determinar el BW usado se utiliza nuevamente
la gráfica del Throughput en valores promedio. Bastaría con analizar la gráfica y
determinar parámetros sobredimensionando la red, es decir, con sus parámetros más
altos de consumo. Por otro lado se puede calcular un estimado utilizando la tasa de
transferencia.
Así, se toman los valores obtenidos de la figura del Throughput y se obtiene la ecuación:
𝐵𝑊 = 𝐺 ∗ 𝐶 (4.2)
Figura 4.13. Variación del retardo de paquetes con un tráfico de video más pesado
Elaborado por: Alex Bonilla
Figura 4.14. Variación del throughput
Elaborado por: Alex Bonilla
55
El BW que se consume por las aplicaciones configurando de tal manera que los
parámetros de las aplicaciones de Datos y Http generan un tráfico bajo, mientras que la
aplicación de Video está configurada para generar un tráfico pesado de Video en Alta
definición es de 30 Mbps.
4.4 Comparativa de la Simulación con los datos obtenidos en PRTG
Básicamente la simulación en OPNET puede asimilarse a los datos obtenidos en PRTG
de modo que se puedan comparar los datos que transmiten las diferentes aplicaciones en
la simulación de modo virtual y los datos obtenidos del monitoreo en modo real.
Para realizar la comparativa se tomó como referencia la gráfica del tráfico enviado del
Modelo 2 que tiene configurado un solo nodo (usuario) por aplicación ya que en la
implementación que se realizó para monitorear una red de características similares con
PRTG se configuraron el mismo número de nodos.
Obteniendo los siguientes datos:
Figura 4.15. Gráfica del tráfico enviado en las aplicaciones del modelo 3
Elaborado por: Alex Bonilla
56
Comparación de las gráficas del tráfico de la aplicación Http.
Comparando las gráficas de la simulación y de la implementación para la aplicación de
Http, se puede ver como el tráfico que fluye a través de la red es bajo, por el orden de los
5 a 10 Kbps en la simulación, y por los 50 a 230 Kbps en la implementación con
Arduino.
Comparación de las gráficas del tráfico de la aplicación Datos
Figura 4.16. Comparación de gráficas de http en OPNET y PRTG
Elaborado por: Alex Bonilla
Figura 4.17. Comparación de gráficas de datos en OPNET y PRTG
Elaborado por: Alex Bonilla
57
Comparando las gráficas de la simulación y de la implementación para la aplicación de
Datos, se puede ver como el tráfico que fluye a través de la red es bajo, por el orden de
los 15 Kbps en la simulación, y por los 8 a 20 Kbps en la implementación con un
computador
Comparación de las gráficas del tráfico de la aplicación de video
Comparando las gráficas de la simulación y de la implementación para la aplicación de
Video, se puede ver como el tráfico que fluye a través de la red es el más alto y por ende
el que más consume, está en el orden de los 170 Kbps en la simulación ya que se
configuro como un terminal con una calidad de video baja; y por los 420 a 700 Kbps en
la implementación con un computador dado que navega en internet usando la plataforma
YouTube, en donde los videos se configuran a un tipo de descarga de video con calidad
estándar.
Figura 4.18. Comparación de gráficas de video en OPNET y PRTG
Elaborado por: Alex Bonilla
58
CONCLUSIONES
En la actualidad los NCS y los WCS se encuentran parcialmente desarrollados, ya que
los estudios teóricos de tráfico demuestran que las redes de este tipo son viables
dependiendo del proceso para el cual sean aplicadas, esto sucede ya que aún no se
cuenta con dispositivos tecnológicos lo suficientemente eficientes en relación a retardos
y conectividad, de tal manera que dificultan los procesos de control de rápida respuesta.
El tráfico que se genera en una red de Control Industrial difiere mucho del tráfico de una
red de información habitual, de ahí que existen varios protocolos tanto para las redes de
control como para las convencionales, sin embargo la tendencia y el desarrollo del
internet y de nuevas tecnologías apunta a una conexión global en donde todos los
dispositivos que usan redes se puedan conectar entre sí, la idea es crear un camino
común para todos los dispositivos electrónicos y permitir que estos interactúen entre sí
de tal manera que para el usuario sea sencillo acceder a cualquier tipo de información y
desde cualquier lugar.
Mediante el uso del simulador de redes OPNET se simulo el comportamiento de una red
que contiene un segmento dedicado al control de procesos productivos (red industrial)
bajo los parámetros que rigen a las redes típicas de información (protocolos TCP/IP),
analizando el tráfico que fluye a través de la red con un consumo de ancho de banda
equivalente a 14 Mbps que encaja dentro de los parámetros de mercado aunque con
costos elevados, se concluye que es factible implementar la red contando con los
dispositivos de control adecuados, actualmente esta es una limitante ya que la tecnología
para trabajar en este tipo de aplicaciones se encuentran en desarrollo y son pocos
equipos los que se comercializan, por ese motivo los WCS y NCS se usan para
aplicaciones de lenta respuesta como monitoreos en donde las variables cambian en
tiempos prolongados.
Una forma de comparar los datos obtenidos en la simulación con OPNET, es mediante el
uso del Software PRTG que permite monitorear el tráfico de redes. Para esto, se
implementó una red configurada con parámetros similares a los de la simulación y
59
aunque los datos obtenidos de ambos programas no son idénticos, si son muy similares.
Por medio de la comparativa se puede determinar valores referentes de BW y por medio
de aproximaciones definir la capacidad que debe tener la red. Cabe mencionar que una
simulación nunca va a ser exacta a la realidad, pero sí muy semejantes.
60
RECOMENDACIONES
En la actualidad la implementación de los WCS y NCS tienen que realizarse
conjuntamente con métodos de control que ayuden a evitar complicaciones en la
transición de información. Métodos como lógica difusa, algoritmos predictivos,
estrategias de control de fallas y de tolerancia a fallos ya que el control de procesos
productivo necesita que se garantice la fiabilidad de la red, sobre todo si los procesos de
que se desean controlar son de rápida respuesta.
En el simulador Riverbed OPNET resultar imposible configurar todos los parámetros
propios de los dispositivos de una red de control industrial como PLC’s, sensores y
actuadores, ya que son equipos muy distintos a los de las redes de información y emiten
información de tamaños muy bajos, por lo que se debe buscar la forma de emular el
comportamiento del tráfico que pueden generar estos equipos.
61
REFERENCIAS
Casanova, V. (2005). Sistemas de control basados en red. Modelado y diseño de
estructuras de control. Valencia: Universidad Politécnica de Valencia.
Clariant. (2 de diciembre de 2015). A NEW SERIES OF ORGANIC PIGMENTS.
Obtenido de http://www.clariant.com/en/Innovation/Innovation-Spotlight-
Videos/EDW-Pigments
Custodio, A. (1999). Sensores Inteligentes: La revolución de la instrumentación.
Madrid: Departamento de electrónica UNEXPO.
Dormido, S., Sánchez, J., & Kofman, E. (2008). Muestreo, control y comunicación
basada en eventos. España: Comite Español de Automática(C.E.A.).
Ian F. Akyildiz I. A., Weilian Su W. S., Yogesh Sankarasubramaniam Y. S., and Erdal
Cayirci E. C. (2002) A Survey on Sensor Networks. Georgia Institute of
Technology. IEEE Communications Magazine • August 2002
Joao Hespanha, J.E. & Payam Naghshtabrizi P.N. & Yonggang Xu Y.X. (2007). A
Survey of Recent Results in Networked Control Systems. Proceedings of the
IEEE.
Klaus Wehrle K.W, Mesut Günes M. G., James Gross J. G. (2010). Modeling and Tools
for Network Simulation. Springer.
Mo-Yuen Chow M.CH. (2010). Overview of Agent-based Control and Management for
NCS. The University of Arizona, Tucson, AZ, USA
Rachana Gupta R.G. & Mo-Yuen Chow M.CH. (2010). Overview of Networked Control
Systems. North Carolina State University, Raleigh, NC 27695, USA
Salt, J., Casanova, A., & Piza, R. (2008). Sistema de control basados en Red Modelado
y Diseño de Estructuras de Control. España: Revista Iberoamericana de
Automatica.
62
Sistemas_industriales. (25 de 9 de 2013). SlideShare. Obtenido de
http://es.slideshare.net/marceloolycaceres/aplicaciones-neumaticas-para-la-
automatizacion-de-la-industria-1
Th. Arampatzis T.A., J. Lygeros, J.L. (2005). A Survey of Applications of Wireless
Sensors and Wireless Sensor Networks. Mediterranean Conference on Control
and Automation Limassol, Cyprus, June 27-29, 2005
Universidad Pública de Navarra (s.f.) Arquitectura de Redes, Sistemas y Servicios.
Recuperado el 20 Agosto de 2015 en http://www.tlm.unavarra.es
Walter Romero Kanashiro. W.R. (2013). Redes inalámbricas y simulación de WLAN
mediante OPNET. Recuperado el 25 de Septiembre del 2015 en
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/18261/8/wromeroPFC01
13memoria.pdf
W. P. M. H. Heemels W.H. & J. H. Sandee J.S. & P. P. J. Van Den Bosch P.V. (2008).
Analysis of event-driven controllers for linear systems. Dept. of Mechanical
Engineering, Technische Universiteit Eindhoven, Control System Technology
Group, P.O. Box 513, 5600 MB Eindhoven, The Netherlands
Zheng, L., & Yang., H. (2012). Unlocking the Power of OPNET Modeler. Cambridge:
Cambridge University Press.
63
ANEXOS
i
Figura A1. Pantalla de inicio de OPNET Modeler
Elaborado por: Alex Bonilla
ANEXO 1. Software OPNET para la simulación de un entorno de red
El software OPNET Modeler “Academic Edition” de la empresa Riverbed es un
simulador híbrido, que se basa en la simulación de eventos discretos combinados con un
modelos analíticos (modelos matemáticos). Posee gran cantidad de librerías que le
permiten modelar protocolos, componentes (equipos – marcas) y comportamiento de
redes.
La versión de Software que se utilizó para la realización del presente proyecto es la
versión académica, que se puede obtener de forma gratuita en la página oficial de
Riverbed. Como característica adicional en la versión completa que se utiliza a nivel
empresarial o profesional, se permite el acceso al código fuente de las librerías y
modelos, lo que permite desarrollar nuevos protocolos o aplicaciones.
Sin embargo al tratarse de la simulación de una red multimedia en la que interactúa un
segmento de control industrial no se abordan temas tan profundos en la configuración de
la red y más bien se resaltan aspectos básicos pero esenciales.
ii
ANEXO 2. Configuraciones Iniciales del Software OPNET
Una vez instalado el Software se procede a explorar su ambiente de trabajo. Ya en la
ventana principal como se ve en la Fig. A1 se procede a seleccionar File/New/Project,
luego de lo cual se desplegará la siguiente ventana:
Donde se configura el nombre del proyecto y el nombre del escenario sobre el que se va
a trabajar.
Se continua con la ayuda del asistente de creación de proyectos para más facilidad y se
selecciona la opción “Create empty scenario”, se selecciona next y se pasa a la ventana
de “Choose Network Scale” donde se determina el tamaño o espacio físico que va a
tener la red. Ya que el simulador permite diseñar redes a gran escala así como ejemplos
de redes básicas, para este trabajo de simulación se utiliza la opción “Office”, que es
para un entorno de oficina.
Figura A2. Pantalla de Nuevo proyecto
Elaborado por: Alex Bonilla
Figura A3. Pantalla de Choose Network Scale
Elaborado por: Alex Bonilla
iii
Se da clic en siguiente y se despliega la ventana de “Specify Size”, donde se determina
que tamaño va a tener el espacio del entorno de simulación, esto es importante ya que de
ello depende la cuadricula o grilla que se genera en la ventana de la simulación.
Para este caso se deja los valores por default de 100x100 m.
En la siguiente ventana de “Select Tecnologies” se procede a seleccionar el tipo de
tecnología con la que se va a trabajar en la simulación, como se puede revisar la gama de
equipos que se pueden utilizar es amplia y están clasificados de acuerdo a la aplicación
que se desee realizar. Siendo el caso de la simulación de una red Wireless se selecciona
la opción “Wireless_lan_advance” que es la que contiene gran cantidad de dispositivos
Wi-Fi como se verá más adelante.
Figura A4. Ventana de Specify Size
Elaborado por: Alex Bonilla
Figura A5. Ventana de Select Tecnologies
Elaborado por: Alex Bonilla
iv
La siguiente ventana que se despliega es la ventana de “Review” donde se despliegan
los datos de todas las opciones seleccionadas para la simulación, si estos son correctos se
puede finalizar el asistente y se genera el entorno del proyecto.
Al cabo de unos minutos se despliega la venta con el “escenario” del proyecto y
adicional la paleta con los elementos propios del grupo de “Wireless_lan_adv” que se
utilizaran para el diseño de la red.
Figura A6. Ventana de Review
Elaborado por: Alex Bonilla
Figura A7. Select Tecnologies
Elaborado por: Alex Bonilla
v
ANEXO 3. Software PRTG para el monitoreo de redes.
PRTG Network Monitor es un Software desarrollado por la empresa PAESSLER que
permite el monitoreo de redes con una gran cantidad de herramientas que detectan
problemas y ayudan a mejoras la calidad de servicio. Permite monitorear el consumo de
ancho de banda, lo que ayuda a determinar nodos específicos que pueden generar
problemas a toda la red.
En el presente proyecto se pretende utilizar el Software PRTG de Monitoreo de Red para
analizar el consumo de los recursos de una red en la transmisión de información con
diferentes características, como video, datos o http.
El software de fácil instalación en cualquier PC, permite añadir los dispositivos que
estén conectados a la misma red y monitorearlos por medio de sensores como por
ejemplo un “ping” o “http”, lo que permite determinar las características de la
Figura A8. PRTG
Elaborado por: Alex Bonilla
Figura A9. Pantalla inicial de PRTG
Elaborado por: Alex Bonilla
vi
aplicación que está ejecutando ese nodo en ese momento. Así también cuenta con un
historial ubicado al lado derecho de la pantalla en donde se determina el tráfico que está
generando ese dispositivo desde que se comenzó a sensar.
ANEXO 4. Modulo Arduino y Programación del mismo
“Arduino es una plataforma electrónica de código abierto basada en hardware y
software fáciles de usar. Está pensado para cualquier persona que haga proyectos
interactivos.” (Arduino, 2011).
Programación:
#include <SPI.h>
#include <Ethernet.h>
// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = {
0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED
};
IPAddress ip(192, 168, 0, 180);
// Initialize the Ethernet server library
// with the IP address and port you want to use
// (port 80 is default for HTTP):
EthernetServer server(80);
void setup() {
// Open serial communications and wait for port to open:
Serial.begin(9600);
// start the Ethernet connection and the server:
Ethernet.begin(mac, ip);
server.begin();
}
void loop() {
// listen for incoming clients
EthernetClient client = server.available();
if (client) {
// an http request ends with a blank line
boolean currentLineIsBlank = true;
while (client.connected()) {
if (client.available()) {
char c = client.read();
// if you've gotten to the end of the line (received a newline
// character) and the line is blank, the http request has ended,
// so you can send a reply
vii
if (c == '\n' && currentLineIsBlank) {
// send a standard http response header
client.println("HTTP/1.1 200 OK");
client.println("Content-Type: text/html");
client.println("Connection: close"); // the connection will be closed after completion of the response
//client.println("Refresh: 5"); // refresh the page automatically every 5 sec
client.println();
client.println("<html>");
// output the value of each analog input pin
client.println("hola mundo");
client.println("</html>");
break;
}
if (c == '\n') {
// you're starting a new line
currentLineIsBlank = true;
}
else if (c != '\r') {
// you've gotten a character on the current line
currentLineIsBlank = false;
} } }
// give the web browser time to receive the data
delay(1);
// close the connection:
client.stop();
} }