Proyecto de Título Gabriel Rubilar PDF

FACULTAD DE INGENIERÍA
DEPTO. INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
“INTEGRACIÓN DE UNA MAQUETA DE CONTROL DE NIVEL EN

TANQUES INTERACTUANTES A UN SISTEMA DE LABORATORIOS
REMOTOS”
AUTOR
GABRIEL ALONSO RUBILAR FIGUEROA
PROYECTO DE TÍTULO PARA OPTAR AL TÍTULO DE

INGENIERO CIVIL EN AUTOMATIZACIÓN
CONCEPCIÓN – CHILE
AÑO 2017
FACULTAD DE INGENIERÍA
DEPTO. INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
“INTEGRACIÓN DE UNA MAQUETA DE CONTROL DE NIVEL EN TANQUES INTERACTUANTES A

UN SISTEMA DE LABORATORIOS REMOTOS”
AUTOR
GABRIEL ALONSO RUBILAR FIGUEROA
DOCENTE PATROCINANTE: D. Sc. ANGEL ERNESTO RUBIO RODRÍGUEZ

DOCENTE ADJUNTO O CORRECTOR: JUAN BAUTISTA ANTIPIL IBAÑEZ
Agradecimientos.
AGRADECIMIENTOS
El haber llegado al momento culmine de mi carrera de pregrado y este trabajo de título es el

resultado del apoyo y colaboración de muchas personas muy importantes tanto en el ámbito
estudiantil como personal.
En primer lugar quiero agradecer a mis padres Carlos y Gabriela por todo el esfuerzo y
los sacrificios a lo largo de la vida para permitir que logremos nuestras metas y anhelos, por
nunca acotar nuestras mentes y apoyarnos en lo que nos propusiéramos. A mis hermanos Carlos y
Cristian por el apoyo entregado. A Anita por su constante motivación, cariño e incondicional
compañia durante estos largos años. También agradezco a Gabriel, Gerardo, Diego, Rodrigo,
Matías, Patricio, Ricardo, Mauricio con los cuales formamos un gran núcleo de inseparables
amigos ayudándonos en momentos difíciles, con los que aprendí lo que no se enseña en libros y
adquirí valores que sin duda me ayudaron a crecer como persona. Quiero agradecer también a
don Pedro quien se transformo en un amigo y gran apoyo en mi estadia en la universidad.
Por supuesto debo agradecer a mi profesor guía, Sr Angel Rubio y al profesor Iván
Santana por toda la ayuda brindada y hacer posible la realización de estre trabajo de título.
Gabriel Rubilar Figueroa

Resumen.
RESUMEN
El presente proyecto de título está orientado a la implementación de un sistema de

laboratorios a distancia (SLD) en el laboratorio de control del departamento de Ingeniería
Eléctrica y Electrónica (DIEE) de la Universidad del Bío-Bío. Este sistema de laboratorios fue
desarrollado por el Grupo de Automatización Robótica y Percepción (GARP) de la Universidad
Central “Marta Abreu” de Las Villas, en colaboración con el Departamento de Automática,
Ingeniería Electrónica e Informática Industrial de la Universidad Politécnica de Madrid, y ahora,
en colaboración con el DIEE de la Universidad Del Bío-Bío, se integra a una maqueta de control
de nivel en tanques interactuantes para ejecutar experiencias de control de nivel vía Internet. El
SLD permite ejecutar las prácticas en cualquier momento y desde cualquier lugar con acceso a
Internet, ampliando así la disponibilidad de las maquetas de laboratorio. Este sistema en
particular, tiene como ventajas fundamentales la independencia entre las estaciones de trabajo y
el servidor, lo que permite que se puedan compartir recursos entre lugares distantes, a través de
Internet. Además, la posibilidad de tener más de una estación de trabajo, con la misma práctica,
controladas por el mismo servidor, lo que le brinda un mayor paralelismo. Por último, mencionar
el hecho de permitir la realización de prácticas en tiempo real. La maqueta que ha sido integrada
al SLD, consiste en cuatro tanques interactuantes a los que se suministra agua a través de dos
bombas de agua inmersas en un tanque de agua en su parte inferior. Esta se manipula desde un
computador conectado a la maqueta utilizando Matlab y Simulink.
Este trabajo de título está organizado en cinco capítulos de acuerdo a la siguiente
distribución. En el Capítulo 1, se hace una introducción al tema y se describen objetivos
generales y específicos, con el fin de contextualizar el proyecto abordado. En el Capítulo 2, se
realiza un análisis de varias de las plataformas de laboratorios virtuales y remotos existentes en la
actualidad. Este estudio sirve de base para la selección del SLD. En el Capítulo 3, se detalla a
cabalidad el funcionamiento de cada una de las partes que conforman el sistema de laboratorio a
distancia y se describe paso a paso las instrucciones para la instalación y puesta en marcha del
sistema en un servidor. En el Capítulo 4, se realiza una caracterización y modelado de la planta a
controlar para posteriormente determinar algunas estrategias de control sobre esta. Finalmente se
comentan las principales conclusiones de este trabajo y se mencionan posibles trabajos futuros.
Índice de contenidos.
ÍNDICE DE CONTENIDOS
ABREVIATURAS ......................................................................................................................... v
CAPÍTULO 1. INTRODUCCIÓN ............................................................................................... 1
1.1 Introducción ...................................................................................................................... 1
1.2 Objetivos ........................................................................................................................... 2
1.2.1 Objetivo General........................................................................................................ 2
1.2.2 Objetivos Específicos ................................................................................................ 2
CAPÍTULO 2. SISTEMAS DE LABORATORIOS REMOTOS ............................................. 3
2.1 Introducción ...................................................................................................................... 3
2.2 Laboratorios virtuales y remotos aplicados a la ingeniería de control automático ........... 3
2.3 Arquitecturas de hardware y software empleadas en los laboratorios remotos ................ 6
2.4 Partes que componen un SLD en general ....................................................................... 19
2.4.1 Interfaz de usuario ................................................................................................... 19
2.4.2 Gestión de las prácticas ........................................................................................... 22
2.4.3 Procesamiento de las prácticas ................................................................................ 24
2.5 Conclusiones y comentarios ........................................................................................... 25
CAPÍTULO 3. EL SISTEMA DE LABORATORIOS A DISTANCIA ................................. 26
3.1 Introducción .................................................................................................................... 26
3.2 Características generales del SLD .................................................................................. 26
3.3 Arquitectura del sistema de laboratorios a distancia ...................................................... 29
3.3.1 Integración con MATLAB/simulink ....................................................................... 31
3.3.2 Interfaz gráfica del cliente ....................................................................................... 34
3.4 Estructura de la base de datos ......................................................................................... 39
3.5 Estructura de las funciones de MATLAB....................................................................... 41
3.5.1 Ejecución de prácticas de forma real con control predefinido ................................ 41
3.5.2 Ejecución de prácticas de forma simulada con control predefinido ........................ 47
3.6 Seguridad informática del SLD ...................................................................................... 50
3.7 Instalación del SLD ........................................................................................................ 52
3.8 Puesta en marcha del SLD .............................................................................................. 59
3.9 Añadir prácticas al SLD .................................................................................................. 59
CAPÍTULO 4. APLICACIÓN DEL SLD ................................................................................. 66
4.1 Introducción .................................................................................................................... 66
4.2 Sistema de tanques interactuantes del feedback ............................................................. 66
4.3 Modelado de tanques en cascada .................................................................................... 68
4.4 Identificación experimental del sistema.......................................................................... 72
4.5 Control de nivel con PID ................................................................................................ 73
4.6 Control de nivel con otra estrategia de control ............................................................... 77
CONCLUSIONES ....................................................................................................................... 79
Conclusiones.............................................................................................................................. 79
Trabajo a futuro ......................................................................................................................... 80
i
Índice de contenidos.
BIBLIOGRAFÍA ......................................................................................................................... 81
ANEXOS 88
Anexo 1 Análisis de vulnerabilidad en servidor con XAMPP v1.6.5 .................................... 88
Anexo 2 Análisis de vulnerabilidad en servidor con XAMPP v1.6.8 .................................. 107
ii
Índice de tablas y figuras
_____________________________________________________________________________________________
ÍNDICE DE TABLAS
Tabla 3.1 Partes e implementación de la plataforma. Software utilizado [33] .............................. 29
ÍNDICE DE FIGURAS
Figura 2.1 Arquitectura del sistema ACT [20, 21]. ......................................................................... 6

Figura 2.2 Arquitectura de referencia para la construcción de laboratorios remotos presentada por
Calvo y colaboradores [22].............................................................................................................. 7
Figura 2.3 Arquitectura del sistema LABNET [23]. ....................................................................... 7
Figura 2.4 Cliente LABNET [23] .................................................................................................... 8
Figura 2.5 Interface de usuario de RECOLAB [24] ........................................................................ 9
Figura 2.6 Arquitectura de RECOLAB [24]. ................................................................................ 10
Figura 2.7 Interface del laboratorio virtual sobre una máquina de fundición continua [25]. ........ 11
Figura 2.8 Arquitectura del NCSLab [26]. .................................................................................... 12
Figura 2.9 Arquitectura del laboratorio remoto implementado en la Universidad de Maribor [27].
....................................................................................................................................................... 13
Figura 2.10 Arquitectura del sistema RoboLab (RobUALab) [28]. .............................................. 14
Figura 2.11 Arquitectura del Laboratorio de Automatización Remoto (RAL) [31]. .................... 15
Figura 2.12 Equipos disponibles en el laboratorio de la UPM [33]. ............................................. 17
Figura 2.13 Equipos disponibles en el laboratorio de la UCLV. ................................................... 17
Figura 2.14 Arquitectura del sistema SLD [33]. ........................................................................... 18
Figura 2.15 Esquema general de un sistema que utiliza MATLAB Web Server para la
comunicación entre las aplicaciones web y MATLAB a través de un servidor TCP/IP. .............. 23
Figura 3.1 Funcionamiento general del sistema de laboratorio a distancia. .................................. 30
Figura 3.2 Vista general de la infraestructura del SLD [33]. ........................................................ 33
Figura 3.3 Esquema de la interfaz de usuarios del SLD [56]. ....................................................... 35
Figura 3.4 Ventana de práctica con control predefinido [56]. ....................................................... 37
Figura 3.5 Ventana de práctica con control definido por usuario [56]. ......................................... 38
Figura 3.6 Modelo Lógico de la Base de Datos [33]. .................................................................... 40
Figura 3.7 Código del archivo m_CT_T1_PIDFr.m ..................................................................... 42
Figura 3.8 Archivo simulink de práctica en modo real con controlador predefinido. ................... 44
Figura 3.9 Cambiar parámetros al bloque controler desde simulink. ............................................ 44
Figura 3.10 Configuración de StopFcn* del archivo.mdl. ............................................................ 45
Figura 3.11 Código del archivo salida.m ....................................................................................... 46
Figura 3.12 Código del archivo CT_T1_PIDFs.m ........................................................................ 48
Figura 3.13 Evaluación de seguridad informática del SLD........................................................... 51
Figura 3.14 Ruta de instalación XAMPP por defecto ................................................................... 53
Figura 3.15 Selección de servicios a instalar. ................................................................................ 54
Figura 3.16 Panel de control de XXAMP...................................................................................... 55
Figura 3.17 Menú principal XAMPP. ........................................................................................... 55
Figura 3.18 Creación de base de datos. ......................................................................................... 56
Figura 3.19 Edición de privilegios de usuario root. ...................................................................... 57
Figura 3.20 Asignación de password a la BD. .............................................................................. 57
Figura 3.21 Agregar carpeta de práctica CT_T1_PIDFr al sistema. ............................................. 60
iii
Índice de figuras.
Figura 3.22 Ventana principal de base de datos. ........................................................................... 61

Figura 3.23 Tablas que conforman la base de datos. ..................................................................... 61
Figura 3.24 Contenido de tabla sld_practices_data. ...................................................................... 62
Figura 3.25 Datos ingresados para añadir práctica “Control de nivel de un tanque con PID”
Simulada. ....................................................................................................................................... 62
Figura 3.26 Datos ingresados para añadir práctica “Control de nivel de un tanque con PID” Real.
....................................................................................................................................................... 64
Figura 3.27 Práctica agregada al SLD. ......................................................................................... 64
Figura 4.1 Maqueta tanques acoplados o interactuantes. .............................................................. 66
Figura 4.2 Identificación de componentes de la maqueta. ............................................................ 67
Figura 4.3 Modelo físico tanques en cascada. ............................................................................... 68
Figura 4.4 Diagrama de bloques de tanques en cascada................................................................ 72
Figura 4.5 Respuesta temporal del sistema en lazo abierto. .......................................................... 72
Figura 4.6 Sistema de control simple – Lazo cerrado. .................................................................. 73
Figura 4.7 Esquema para el control de nivel de un tanque con regulador PID y filtro. ................ 76
Figura 4.8 Esquema para control de nivel de un tanque con cambio de regulador. ...................... 77
iv
Abreviaciones.
ABREVIATURAS
Mayúsculas
SLD : Sistema de Laboratorio a Distancia.
SLR : Sistema de Laboratorio Remoto.
BD : Base de Datos.
SAP : Servidor de Administración de Prácticas.
CAP : Cliente de Administración de Prácticas.
SQL : Structured Query Language (Lenguaje de Consulta Estructurada)
HTML : HyperText Markup Language (lenguaje de marcas de hipertexto)
PHP : Hypertext Preprocessor (Preprocesador de hipertexto)
v
CAPÍTULO 1. Introducción
CAPÍTULO 1. INTRODUCCIÓN
1.1 Introducción
En la actualidad, el uso de Internet y de las tecnologías Web ha presentado un cambio
radical en la educación. La enseñanza basada en Web, los cursos a distancia, los libros digitales y
las plataformas interactivas de educación a distancia juegan un papel cada vez más importante en
el proceso de aprendizaje. Los sistemas de laboratorio remoto (SLR), son sistemas donde los
usuarios pueden interactuar con dispositivos reales a través de Internet.
Un sistema de laboratorio remoto (SLR) o también llamado sistema de laboratorio a
distancia (SLD), es un sistema que permite operar y controlar remotamente uno o más equipos
físicos, utilizando una interfaz determinada. Estos equipos pueden ser didácticos como las
maquetas de laboratorio o equipos industriales. Estos laboratorios requieren de servidores
específicos que gestionan tanto a los usuarios del sistema como los equipos integrados en los
mismos. Normalmente los usuarios a través de una interfaz Web pueden cambiar algunos
parámetros de control, realizar experimentos, ver los resultados y descargar los datos del
experimento. El SLR implementado, además, permite a los usuarios cambiar las referencias y
diseñar sus propios controladores de una forma sencilla utilizando herramientas ampliamente
conocidas en el área del control automático como son Matlab y Simulink.
En el Laboratorio de Control Automático del Departamento de Ingeniería Eléctrica y
Electrónica (DIEE) de la Universidad del Bío-Bío, se cuenta con una maqueta para realizar
prácticas de control de nivel. Esta consiste en cuatro tanques interactuantes a los que se
suministra agua mediante dos bombas inmersas en un tanque ubicado en la parte inferior de la
maqueta. Las prácticas con esta maqueta se realizan de forma presencial implementando la
estrategia de control en Matlab/Simulink, según la interconexión que se haga en los tanques y los
índices de desempeño deseados en el sistema. Esta modalidad de prácticas limita el uso de los
recursos al tiempo que se dispone en un turno de clases y por ser un recurso único, no todos los
alumnos pueden realmente interactuar con él. Es por ello que se propone incorporar dicha
maqueta a un Sistema de Laboratorios Remotos (SLR) que permita controlarla vía Internet y
permitir así desarrollar sobre ella la modalidad de Prácticas Remotas en los ramos de control
automático. De esta manera el acceso a la maqueta no quedaría restringido solamente a la
duración de las clases, si no que los alumnos pueden acceder a ella en cualquier momento y lugar
siempre que no haya otro accediendo ya a ella.
1
Para implementar el software necesario se analiza las diversas arquitecturas de hardware y

software empleadas en los laboratorios remotos reportados en la literatura especializada. Además,
se implementa el software necesario, tanto en Matlab como en Simulink, para realizar
experiencias de control sobre la maqueta y devolver los resultados vía web.
La viabilidad del sistema se demuestra con el desarrollo de un conjunto de experiencias
didácticas relativas al control de nivel en tanques interactuantes, sobre la plataforma integrada.
Se espera como resultado entregar a la Universidad del Bío-Bío un sistema de laboratorio

remoto valido y confiable para ser utilizado en cursos orientados al control, el cual entregará a los
alumnos el conocimiento y experiencia en tecnologías vanguardistas en control de procesos.
1.2 Objetivos
1.2.1 Objetivo General
Implementar el software necesario para integrar la maqueta de tanques interactuantes a un

Sistema de Laboratorios Remotos de modo que se permita la realización de prácticas de control
del nivel en los tanques.
1.2.2 Objetivos Específicos
Analizar críticamente las diversas arquitecturas de hardware y software empleadas en los

laboratorios remotos reportados en la literatura especializada.
Implementar el software necesario, tanto en Matlab como en Simulink, para realizar

experiencias de control sobre la maqueta y devolver los resultados vía web.
Desarrollar un conjunto de experiencias didácticas relativas al control de nivel en tanques

interactuantes, sobre la plataforma integrada (Maqueta-SLR).
Validar el funcionamiento del sistema integrado Maqueta-SLR.
2
CAPÍTULO 2. SISTEMAS DE LABORATORIOS REMOTOS
2.1 Introducción
En este capítulo, se realiza un estudio detallado de una amplia muestra de sistemas de

laboratorios virtuales y remotos, y se definen las principales partes que los componen: interacción
de la plataforma con el usuario, gestión de los pedidos de prácticas y procesamiento de las
prácticas.
2.2 Laboratorios virtuales y remotos aplicados a la ingeniería de control automático
Los laboratorios remotos se encuentran en evolución constante y no se restringen a una sola

temática, aunque los de Automática y Robótica son los más utilizados. En trabajos sobre este
tema los autores hacen una valoración de cuáles son las características que deben tener los
laboratorios remotos futuros, haciendo especial hincapié en la reutilización, la interoperabilidad y
la integración con herramientas de aprendizaje colaborativo [1, 2, 3, 4].
Otra tendencia actual es el uso de la computación grid1, el cual es un sistema de computación
distribuido. Estos sistemas permiten compartir recursos no centrados geográficamente para
resolver problemas de gran escala, en este caso los recursos serían las maquetas de laboratorio.
La aplicación de esta técnica admite la creación de redes de laboratorios [5].
Un ejemplo de creación de redes de laboratorios virtuales y remotos para la enseñanza de
la automática es el proyecto AutomatL@bs coordinado por el Profesor Sebastián Dormido, en el
que se encuentran colaborando varias universidades españolas [6, 7, 8, 9, 10]. AutomatL@bs es
una red de laboratorios virtuales/remotos para la enseñanza de la automática, formada por la
integración de los recursos que aportan los grupos que participan en el proyecto. Proporciona un
sistema de reserva de tiempos para la realización de los experimentos y un entorno de trabajo
común que facilita su aprendizaje por parte del alumno. Para esto AutomatL@bs utiliza eMersion
que es un entorno de experimentación basado en web. El sistema eMersion ha sido desarrollado
para la gestión y publicación centralizada de laboratorios virtuales y remotos con propósitos
educacionales.
___________________________________
1
La computación grid es una tecnología que permite utilizar de forma coordinada todo tipo de recursos (sistemas de
cómputo, almacenamiento y aplicaciones específicas) que no están sujetos a un control centralizado.
3
A través de eMersion es posible obtener toda la documentación necesaria para completar una
sesión de experimentación en línea, incluyendo los guiones de práctica, protocolo de tareas,
sistema de reservas y el sistema eJournal. El eJournal ofrece un espacio compartido para los
alumnos en el cual pueden depositar los “Fragmentos de datos” que se van obteniendo durante
una sesión de trabajo.
Recientemente se ha creado el Consorcio Global de Laboratorios en línea (Global Online
Laboratory Consortium, GOLC) cuyo objetivo fundamental es promover el desarrollo y
compartir las investigaciones sobre los laboratorios remotos usados con fines educativos. En tal
sentido se trabaja para lograr una arquitectura estándar, unificada e interoperable que comparta
los laboratorios remotos a todo el mundo [11].
El proyecto iLabs, liderado por los profesores del MIT Jesús del Alamo y Steve Lerman,
pone a disposición de los estudiantes el acceso a dispositivos reales de forma remota a través de
la web. iLabs comenzó con el WebLab de microelectrónica, donde los estudiantes podían probar
los dispositivos microelectrónicos frágiles. Este concepto de experimentación en línea se ha
extendido a otras disciplinas, creando hasta la fecha siete laboratorios en línea del MIT, entre los
que se incluye un reactor químico [12], estructuras mecánicas, un intercambiador de calor, etc. El
laboratorio de microelectrónica es usado por estudiantes de China y África para realizar
experimentos con transistores [13].
El proyecto Labshare, financiado por el Departamento de Educación de la Universidad
Curtin en Australia, tiene como objetivo principal desarrollar tanto la infraestructura técnica y
como una estrategia de apoyo al intercambio permanente de las instalaciones de laboratorio y
recursos remotos. Labshare trata de establecer una comunidad compartida de laboratorios de
control remoto y fomentar el desarrollo de laboratorios de alta calidad y rentables para la
educación [14]. Son varios los ejemplos de laboratorios virtuales y remotos que se muestran en la
actualidad. El grupo de educación en Automática del Comité Español de Automática (CEA-
IFAC) ha desarrollado una página web en la que se recopilan los recursos actuales en el área de
los laboratorios virtuales y/o remotos, además de mostrar las clasificaciones de los mismos [15].
El WebLab-DEUSTO es un laboratorio remoto diseñado e implementado por la Facultad
de Ingeniería de la Universidad de Deusto. Desde el punto de vista tecnológico el laboratorio
4
ha sido implementado en su última versión como un Web Services2 (servicio web) usando
SOAP3, AJAX4 y Python5 [16].
El Ciclope Robot es un laboratorio remoto que tiene como objetivo enseñar cómo realizar
la programación de sistemas de tiempo real embebidos en equipos reales, tales como un robot.
Este escenario está compuesto por un laboratorio real situado en la Facultad de Informática de la
Universidad Politécnica de Madrid y por un cliente web. En la interfaz del cliente se utiliza el
lenguaje HTML, JavaScript y applets6 de Java. En el servidor web se utiliza Apache, PHP,
MySQL y software programado en C++ para la comunicación con el robot [17].
En Chile, el proyecto Ingeniería 2030 considera a la Universidad del BíoBío, Universidad
de Talca y Universidad de la Frontera, para que las tres facultades de ingeniería de estas
universidades actúen como una sola gran MacroFacultad de formación conjunta para Sistemas de
Control Automático. Actualmente, se encuentra en desarrollo el proyecto FDE ING 2030
“Macrolaboratorio de formación conjunta” liderado por el profesor Mario Fernández de la
Universidad de Talca, para integrar los laboratorios de las tres universidades [18].
Particularmente, en la Universidad del Bío-Bío, se desarrolla el proyecto IenDU “Sistema de
prácticas remotas de control automático en tiempo real para la formación de estudiantes de
Ingeniería Civil en Automatización”, liderado por el profesor Ernesto Rubio, del cual es parte
este trabajo de titulo.
Con este proyecto se pretende desarrollar un sistema que permita la implementación de
prácticas remotas de control automático en tiempo real a través de las plataformas de enseñanza a
distancia utilizadas en la UBB, para integrarlo a la docencia de la carrera de Ingeniería Civil en
Automatización y desarrollar con él una innovación metodológica que impacte positivamente
sobre el interés, la motivación y el rendimiento académico de los estudiantes de la carrera de
Ingeniería Civil en Automatización [19].
__________________________________________
2
Web service es una pieza de software que utiliza un conjunto de protocolos y estándares que sirven para
intercambiar datos entre aplicaciones.
3
SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en
diferentes procesos pueden comunicarse por medio de intercambio de datos XML.
4
AJAX, acrónimo de Asynchronous JavaScript And XML, es una técnica de desarrollo Web para crear aplicaciones
interactivas.
5
Python es un lenguaje de programación de alto nivel cuya filosofía hace hincapié en una sintaxis muy limpia y que
favorezca un código legible.
6
Applet es un componente de una aplicación que se ejecuta en el contexto de otro programa, por ejemplo un
navegador Web.
5
2.3 Arquitecturas de hardware y software empleadas en los laboratorios remotos
A continuación se analizan las arquitecturas utilizadas en distintos laboratorios remotos aplicados

a la ingeniería de control automático.
 El Automatic Control Telelab (ACT) es un laboratorio que permite realizar experimentos
remotos sobre diferentes plantas (motor CC, levitador magnético, helicóptero, robot LEGO,
tanques). El sistema admite que se realicen tanto prácticas con controladores predefinidos como
con controladores definidos por el usuario, tema este de gran interés en las investigaciones [20,
21]. En la Figura 2.1 se muestra la arquitectura del ACT.
Figura 2.1 Arquitectura del sistema ACT [20, 21].
Este sistema de la Universidad de Siena en Italia se ha ampliado a Robotics & Automatic Control
Telelab (RACT) el cual permite, además, ejecutar experimentos con un robot manipulador.
 Una metodología para construir laboratorios remotos es presentada por Calvo et al. [22].
En dicho trabajo se presenta un enfoque basado en tecnologías estándar (WWW, lenguaje Java,
tecnologías orientadas a objetos distribuidas, etc.) con la intención de proporcionar un marco
genérico que se adapte a un gran número de situaciones. Esta metodología proporciona una
arquitectura de referencia, mostrada en la Figura 2.2, así como pautas a seguir para completar los
diferentes componentes involucrados en los laboratorios remotos (Servidor de Aplicaciones,
Aplicaciones Remotas, etc.).
6
Figura 2.2 Arquitectura de referencia para la construcción de laboratorios remotos

presentada por Calvo y colaboradores [22].
 El sistema LABNET: Laboratorio remoto para control de procesos es un laboratorio

remoto que permite la realización de experimentos sobre las maquetas de laboratorio a través de
internet [22]. La arquitectura de LABNET sigue el modelo de cliente-servidor tal y como se
muestra en la Figura 2.3.
Figura 2.3 Arquitectura del sistema LABNET [23].
El servidor de LABNET es una aplicación que se encarga de la gestión de los usuarios, de

las maquetas y de la administración los experimentos. Por otra parte, el cliente de LABNET es la
aplicación que permite el acceso remoto al laboratorio y, a través de su interfaz gráfica, los
7
usuarios pueden ejecutar sus experimentos de forma rápida y transparente. En la Figura 2.4 se
muestra el cliente LABNET.
Figura 2.4 Cliente LABNET [23]
El entorno de LABNET ofrece la posibilidad de realizar experimentos de control en lazo

abierto o en lazo cerrado con controladores predefinidos que se pueden ejecutar de forma local o
remota. En el modo local, el controlador está ubicado en el servidor. Por su parte, en la
modalidad de control remoto, el controlador se ejecuta en el cliente, por lo que la realimentación
se hace a través de la red. Los controladores predefinidos de LABNET son las tres variantes más
comunes del controlador PID: el PID teórico, el PID con filtrado de la derivada y el PID con
Anti-Windup [23]
 El sistema RECOLAB: Laboratorio de Prácticas de Control de Procesos vía Internet está

orientado al control a distancia y en tiempo real de un sistema físico a través de Internet. Hace
uso de MATLAB/Simulink como plataforma de desarrollo. El mismo permite al alumno, simular
primeramente, a través de Internet, el funcionamiento de un regulador dado para un proceso
físico determinado, y más tarde ejecutar en tiempo real sobre dicho proceso el regulador ajustado
8
en la simulación. La aplicación devuelve al usuario toda la información referente a la ejecución

realizada, además de gráficas y otros datos de interés [24]. En la Figura 2.5 se muestra la
interface de usuario de RECOLAB.
Figura 2.5 Interface de usuario de RECOLAB [24]
En la Figura 2.6 se muestra la arquitectura general de RECOLAB. Se destacan los bloques que
conforman esta arquitectura y su interrelación.
9
Figura 2.6 Arquitectura de RECOLAB [24].
La comunicación cliente-servidor se realiza a través del protocolo HTTP (HyperText Transfer

Protocol, Protocolo de transferencia de hipertexto) mediante un servidor web y el paquete de
herramientas MATLAB Web Server, el cual permite de forma flexible recopilar datos generados
por un núcleo de MATLAB y enviarlos a una página web. En cuanto a la ejecución en tiempo
real se utilizan las aplicaciones y paquete de herramientas: MATLAB, Simulink, Real – Time
Workshop y Real – Time Windows Target. Estos dos últimos permiten realizar la ejecución en
tiempo real de un esquema Simulink con un determinado sistema de adquisición de datos.
 El sistema Laboratorios Virtuales para el Diseño de Sistemas de Control (Virtual

Laboratories for Control Systems Design, VL-CSD) es un sistema de laboratorios virtuales que
provee una solución on-line a los tradicionales laboratorios experimentales. Este producto es
comercializado por la Universidad de Newcastle en Australia y se basa en ejemplos de un libro
escrito por uno de sus autores y promotor, el profesor Graham Goodwin [25]. En la Figura 2.7 se
muestra la interface de la máquina de fundición continua.
10
Figura 2.7 Interface del laboratorio virtual sobre una máquina de fundición continua [25].
La simulación del sistema está basada en applets de Java que permiten en algunos casos
realizar interacciones con las distintas simulaciones. Presenta varios casos de estudio disponibles
como fundición continua, péndulo invertido, control de nivel en un tanque, columna de
destilación, control de pH, etc.
 El Laboratorio de Sistemas de Control en Red (Networked Control System Laboratory,
NCSLab) es un interesante sistema que permite a los usuarios realizar experimentos en
dispositivos reales localizados en diferentes lugares [26]. Se propone una arquitectura escalable
compuesta por navegadores web, servidor web central, servidores de MATLAB, servidores
regionales de experimentos, unidades de control y los dispositivos sobre los que se realizan los
experimentos (Figura 2.8).
11
Figura 2.8 Arquitectura del NCSLab [26].
El NCSLab adoptó MATLAB como sistema de modelado y simulación por la amplia

utilización de este software en la industria y en el entorno académico, lo cual permite que los
usuarios se familiaricen rápidamente con el sistema. Para evitar las posibles colisiones al acceder
al mismo experimento se implementó un mecanismo de reserva. Se definen tres tipos de
privilegios: sin privilegio, privilegio de observar y privilegio de control total. Solamente el
usuario que gane el privilegio de control total podrá hacer cambios en los experimentos y
ejecutarlos. Actualmente presenta dos servidores regionales, uno en China y otro en Reino Unido,
incluyendo 12 dispositivos para los experimentos [26].
12
 El Laboratorio Remoto de Mecatrónica (Remote Laboratory of Mechatronics) de la

Universidad de Maribor en Eslovenia, utiliza para el control de los dispositivos un hardware
desarrollado por ellos y dos software comerciales muy conocidos en el área: MATLAB y
LabVIEW. MATLAB/Simulink es utilizado para el desarrollo de los algoritmos de control,
mientras que LabVIEW es utilizado para la interface de usuario, el control remoto y la
comunicación [27]. En la Figura 2.9 se muestra la arquitectura del laboratorio remoto
implementado.
Figura 2.9 Arquitectura del laboratorio remoto implementado en la Universidad de

Maribor [27].
 ROBOLAB: Laboratorio Virtual remoto para la enseñanza de robótica, es un laboratorio

remoto que permite la simulación de un brazo robot Scorbot ER-IX de Eshed Robotec Ltd, así
como la tele-operación del brazo real equivalente por parte de varios estudiantes de forma
simultánea (Figura 2.10) [28,29].
13
Figura 2.10 Arquitectura del sistema RoboLab (RobUALab) [28].
El alumno puede acceder a todas las funciones del laboratorio a través de una página web con un
applet de Java el cual maneja la simulación local del robot. Además posee una ventana VRML
con el estado simulado del mismo, obteniendo la información necesaria de una base de datos, la
cual es suministrada por el servidor que atiende al robot.
Este sistema ha estado en evolución desde 1999, y ha pasado por diferentes versiones. La
primera versión de RoboLab (RoboLab I) ofrece una interfaz creada con Java y VRML.
Posteriormente se ha desarrollado una segunda versión (RoboLab II) basada en Java y Java 3D.
Las últimas versiones de RoboLab utilizan el software Easy Java Simulations (EJS)
(simulaciones sencillas en Java) y también están basadas en Java y Java 3D. La versión más
reciente, iniciada en 2007 y denominada RobUALab [30], incluye muchas funciones nuevas con
respecto a las anteriores y forma parte del proyecto AutomatL@bs.
 El Laboratorio de Automatización Remoto (RAL) de la Universidad de Alcalá permite el

acceso remoto a PLC (Programmable Logic Controller, Controladores Lógicos Programables) de
diferentes fabricantes. Hace uso de una estructura de máquinas virtuales para permitir el acceso a
cada uno de los tipos de PLC. Este sistema utiliza Moodle y scripts en PHP para el manejo de los
usuarios y la autentificación [31]. En la Figura 2.11 se muestra la arquitectura diseñada.
14
Figura 2.11 Arquitectura del Laboratorio de Automatización Remoto (RAL) [31].
En el sistema laboratorio virtual y remoto del Departamento de Informática y Automática

de la Universidad Nacional de Educación a Distancia (UNED) que forma parte del proyecto
AutomatL@bs se hace uso de EJS para crear una simulación interactiva. El sistema permite
realizar tanto la simulación de un sistema como la ejecución de forma remota del experimento
sobre los dispositivos reales. Este sistema dispone tres plantas didácticas: el sistema heatflow, el
sistema de tres tanques y un motor de corriente continua. Son varios los estudios realizados sobre
el uso del EJS en los laboratorios virtuales y remotos. En versiones recientes el EJS permite la
comunicación con MATLAB/Simulink ampliando su utilización.
En los laboratorios remotos se experimenta con recursos críticos, donde solo un usuario
puede acceder a la vez, por lo que se implementan diferentes herramientas administrativas para el
control del acceso.
15
 En el sistema de laboratorios a distancia Implementado en la Universidad Politécnica de

Madrid (UPM) y en la Universidad Central “Marta Abreu” de las Villas (UCLV) el alumno
puede diseñar sus propios experimentos y llevarlos a cabo, así como analizar e interpretar los
resultados obtenidos. También desarrollar sus habilidades en la interacción con equipos reales.
Además las actividades prácticas permiten que el alumno adquiera competencias en
Conocimiento y capacidad para el modelado y simulación de sistemas pues se realizan prácticas
de laboratorio sobre modelado físico de un proceso e identificación de un sistema lineal. También
se realizan prácticas relacionadas con la sintonía y diseño de reguladores [33].
El SLD permite implementar dos tipos prácticas:
 Prácticas paramétricas: el usuario solo puede modificar ciertos parámetros, como pueden
ser las ganancias de un regulador PID, la amplitud de un escalón, etc.
 Prácticas con cambio de estrategia: el usuario tiene la posibilidad de realizar cambios en
algunos bloques del modelo del sistema, como puede ser el regulador, las referencias, etc.
Tras descargarse el modelo de Simulink correspondiente, el usuario realiza las
modificaciones pertinentes haciendo uso de los bloques de Simulink. Se pueden realizar
igualmente cambios en otros parámetros avanzados, como el tiempo de ejecución, el
tiempo de muestreo, etc.
Además, el SLD posee características únicas como: Interfaz de usuario rápida y fácil,
administración de múltiples pedidos en forma paralela, desarrollo de controladores de forma
remota usando Matlab y Simulink, Cambio del periodo de muestreo y cambio de referencias de
los experimentos. [34]
El laboratorio de automática de la UPM está formado por 8 puestos equipados con un ordenador
con tarjeta de adquisición y dos sistemas físicos, un sistema térmico y un motor de corriente
continua (Figura 2.12).
16
Figura 2.12 Equipos disponibles en el laboratorio de la UPM [33].
El laboratorio de automática de la UCLV tiene a disposición un motor DC y un Robot IRb-6

(Figura 2.13)
Figura 2.13 Equipos disponibles en el laboratorio de la UCLV.
El sistema está desarrollado en lenguaje de programación PHP ejecutado en el servidor. En el

caso del servidor de base datos se utiliza MySQL y las consultas se realizaron utilizando el
lenguaje SQL19. Se utiliza igualmente para algunas aplicaciones del cliente códigos programados
en JavaScript, el cual es un lenguaje interpretado orientado a las páginas web. Otra de las
tecnologías utilizadas es AJAX, que es una técnica de desarrollo web para crear aplicaciones
interactivas. Estas se ejecutan en el cliente y mantiene comunicación con el servidor en segundo
17
plano. El otro software utilizado en el sistema fue Matlab/Simulink, el cual fue usado para la
programación de las prácticas, ficheros .m y .mdl asociados a cada práctica.
Matlab, se instala en las estaciones de trabajo, es decir, las que se conectan directamente
al proceso real. En caso de realizar prácticas con cambio de estrategia es necesario el uso de
MATLAB/Simulink para modificar la plantilla base descargada del servidor [33]. En la figura
2.14 se muestra la arquitectura del SLD.
Figura 2.14 Arquitectura del sistema SLD [33].
18
2.4 Partes que componen un SLD en general
De forma general, un laboratorio virtual y remoto debe tener al menos tres partes o niveles,
la interfaz de usuario, el nivel de gestión de prácticas y el procesamiento de las prácticas [32].
2.4.1 Interfaz de usuario

La interfaz de usuario es una de las partes de mayor importancia dentro de un sistema de
laboratorios virtual y remoto pues es la cara para el usuario. Debe ser flexible, amigable y
permitir un fácil uso del sistema. Además debe ser implementada de forma tal que se pueda
mantener y ampliar sin dificultad. La principal función de la interfaz de usuario consiste en
mostrar las prácticas disponibles en el sistema, conformar el pedido de las prácticas con todos sus
datos y enviarlo a la parte encargada de gestionarlos y, por último, presentar los resultados. En
este nivel se encuentra la administración y gestión del sistema que, a su vez, se interrelaciona con
los demás niveles. Para realizar esta parte tan importante de la plataforma existen varias
alternativas como son las aplicaciones específicas, las aplicaciones compiladas y las aplicaciones
interpretadas [33].
Aplicaciones específicas
En las aplicaciones específicas se desarrolla una aplicación por parte del desarrollador del
sistema la cual, generalmente, se realiza en un lenguaje de alto nivel como puede ser el C, C++,
Delphi, Visual Basic, Java, entre otros. Dentro de esta clasificación se encuentra el trabajo A
Web-Based Laboratory for Control Engineering Education (Un laboratorio basada en Web para
la Educación de la Ingeniería de Control). Este método tiene como ventaja fundamental que la
aplicación es descargada la primera vez y luego se puede usar mientras no ocurran cambios en el
servidor. Permite realizar aplicaciones más interactivas.
El uso de aplicaciones específicas tiene como desventaja fundamental el hecho de tener

que descargar la aplicación por parte del usuario lo que produce, en varios casos, que el usuario
se arrepienta de usar la herramienta, pues trae problemas de seguridad, retardo en descargar la
aplicación y posible incompatibilidad entre sistemas operativos, es decir, generalmente el
desarrollador impone requisitos para la utilización. Otra desventaja importante lo constituye el no
tener un mecanismo de actualización de la aplicación, esto solo se podría realizar volviendo a
19
descargar la nueva aplicación o plug-in7 (complemento) que permita esto. Todo esto hace que
esta opción sea poco ventajosa para ser usada como única herramienta de interfaz de usuario de
los laboratorios virtuales y remotos, de hecho, los sistemas la implementan como una elección
adicional. En las últimas fechas prácticamente es una variante que no se utiliza [33].
Aplicaciones compiladas
Existen varios tipos de aplicaciones compiladas tanto del lado del servidor como del
cliente. Una de las más utilizadas son las aplicaciones CGI8 clásicas (Common Gateway
Interface, Interfaz de entrada común) en las cuales se realiza la programación según APIs9
(Application Programming Interface, Interfaz de programación de aplicaciones) en lenguajes
como C, C++, Delphi, etc. Aquí el módulo CGI recibe información a través de variables de
entorno del servidor, realiza un procesamiento y escribe una respuesta para el cliente. Esto, por
supuesto, se vincula con páginas HTML para lograr el objetivo deseado. En RECOLAB, el CGI
se encarga del acceso a los recursos y la comunicación entre el servidor web y las aplicaciones
MATLAB [24]. Otra metodología a la que se recurre para la interfaz de usuario de los
laboratorios remotos es VRML por lo amigable e interactivo que es. VRML es un lenguaje para
la descripción de objetos y mundos virtuales 3-D con los que el usuario puede interactuar. Entre
sus principales características destaca la de ser un lenguaje estándar y, por consiguiente,
universalmente utilizado en Internet como el lenguaje para simulaciones interactivas dentro de la
web. VRML fue desarrollado para que millones de personas pudieran interactuar y cualquier
usuario pueda acceder a sitios producidos en VRML. Fue diseñado precisamente para ser usado a
través de Internet, usando el menor ancho de banda posible y aprovechando al máximo los
recursos del equipo cliente. Un ejemplo de utilización de esta tecnología es el VCLab: The
Virtual Control Laboratory for Education on the Web (El Laboratorio de Control Virtual para la
Educación en la Web) [21] y también una de las versiones del Robolab [35].
___________________________________
7
Un plug-in (complemento) es una aplicación que se relaciona con otra para aportarle una función nueva y
generalmente muy específica. Esta aplicación adicional es ejecutada por la aplicación principal e interactúan por
medio de la API.
8
CGI es una tecnología web que permite a un cliente (navegador web) solicitar datos de un programa ejecutado en
un servidor web. CGI especifica un estándar para transferir datos entre el cliente y el programa.
9
API es el conjunto de funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece
cierta biblioteca para ser utilizado por otro software como una capa de abstracción.
20
Los applets de Java permiten el desarrollo de aplicaciones con interfaz gráfica. Esta
variante es muy utilizada [36, 37, 38, 26], porque aunque hay que descargar el applet, y esto lleva
su demora, tiene la ventaja de brindar una interfaz más amigable e interactiva con el usuario. A
diferencia de los CGI los applet se pueden actualizar de forma fácil y automática, completamente
transparente para el usuario. Sin embargo los applets tienen como dificultad un elevado consumo
de recursos conforme aumenta la complejidad y contenido gráfico de la aplicación. Además le
exige al usuario tener instalado los plug-ins necesarios por el navegador. Otro problema bien
importante es cuando se usan sockets para la comunicación entre los clientes y el servidor, pues
se asigna un puerto por cada cliente que se conecte al servidor, lo cual trae problemas con los
firewalls que por cuestiones de seguridad tienen los puertos no estándares cerrados.
Otra variante utilizada en la creación de laboratorios virtuales y remotos, y que se incluye
dentro de los applets de Java, es Easy Java Simulations (EJS) [37, 39, 40, 41, 42, 30]. Jara et al.,
realizan un exhaustivo estudio sobre la factibilidad de uso de esta tecnología [43, 44]. El EjsRL
es una biblioteca de alto nivel de Java diseñada específicamente para EJS que proporciona un
marco completo y funcional para el modelado y la simulación de manipuladores, algoritmos de
visión artificial y operación remota [43].
El API Java 3D es una interfaz para escribir programas que muestran e interactúan con
gráficos tridimensionales. Es una extensión estándar del JDK10 de Java y proporciona una
colección de constructores de alto-nivel para crear y manipular geometrías 3D y estructuras para
dibujar esta geometría. Este tipo de tecnología está ganando terreno en el mundo de los
laboratorios remotos para la implementación de la interfaz de usuario debido a la forma amigable
y realista en que se muestra al usuario. Ejemplo de esto se puede apreciar en el hecho de que el
Robolab haya realizado una versión en Java 3D de su laboratorio [33].
____________________________________
10
Java Development Kit (JDK), es un software que provee herramientas de desarrollo para la creación de programas
en Java.
21
Aplicaciones interpretadas
Las aplicaciones interpretadas son aplicaciones cuyos códigos son interpretados por el
servidor web. El ASP/ ASP.NET es un lenguaje de secuencia de comandos (script) del lado del
servidor desarrollado por Microsoft. Es utilizado para la programación de páginas web dinámicas
y para la comunicación con bases de datos. En [45, 46] se utiliza esta tecnología para validar el
acceso de los usuarios y comunicarse con las bases de datos del sistema.
El lenguaje PHP es un lenguaje del lado del servidor que es muy flexible y con potentes APIs
para el manejo de bases de datos, mail, comercio electrónico, etc. Varios sistemas de laboratorios
remotos y virtuales hacen uso de este lenguaje con el objetivo de autenticar usuarios, la
verificación de las entradas de los mismos, el acceso a las bases de datos y la presentación y
actualización de la interfaz de usuario [47, 17, 48, 49, 38, 50].
El Java Server Pages (JSP) es un lenguaje de secuencia de comandos del lado del servidor que
permiten manejar clases de Java, por lo que se presentan como una solución híbrida entre
JavaScript y Java con una gran flexibilidad.
En la mayoría de las aplicaciones web se hace uso de la combinación de estas herramientas
aprovechando las ventajas que cada una ofrecen. Las variantes Java son muy utilizadas por la
gran portabilidad que presenta este lenguaje.
Otras tecnologías actuales han comenzado a utilizarse ampliamente como son los Adobe Flash y
AJAX (Asynchronous JavaScript and XML). Según el estudio realizado en [55], AJAX
constituye por sus funcionalidades la mejor tecnología a utilizar en los laboratorios remotos. Esta
tecnología brinda una excelente compatibilidad con los exploradores web, seguridad,
compatibilidad con diferentes sistemas operativos y dispositivos móviles, potencia en funciones
de video y audio, eficiencia en la utilización del ancho de banda, bajos costos en el desarrollo y
una gran flexibilidad [33].
2.4.2 Gestión de las prácticas

En la capa de gestión de prácticas el sistema se encarga de enviar los pedidos de prácticas
realizados a través de la interfaz de usuario al nivel de procesamiento de prácticas para luego
devolver al usuario la respuesta de la ejecución, es decir, funciona como enlace entre la interfaz
de usuario y la capa de procesamiento de prácticas. En la actualidad se utilizan tres variantes
principalmente, MATLAB Web Server, LabVIEW Internet Tool-kit y en otros trabajos se
22
implementan mecanismos propios de comunicación ya sea con MATLAB o con otro software de
procesamiento de prácticas [33].
Gestión de prácticas mediante MATLAB Web Server

El paquete de herramientas MATLAB Web Server tiene como función principal la
comunicación entre las aplicaciones web y MATLAB, para esto hace uso de un servidor TCP/IP
(Transmission Control Protocol / Internet Protocol) multi-hilo que ejecuta los programas de
MATLAB que les solicita el CGI. Estos programas están especificados en el documento HTML y
para ello hace uso de un fichero de configuración llamado ―mathweb.conf‖. En este fichero de
configuración se especifica el número de puertos que se van a utilizar en la comunicación y el
número máximo de simulaciones (Figura 2.12).
Figura 2.15 Esquema general de un sistema que utiliza MATLAB Web Server para la
comunicación entre las aplicaciones web y MATLAB a través de un servidor TCP/IP.
MATLAB Web Server, a pesar de tener la ventaja de permitir la comunicación entre el CGI
y MATLAB, tiene la desventaja de que una misma práctica sólo se puede ejecutar en una
máquina, la especificada por el fichero de configuración. Además no permite validar los
parámetros de las prácticas introducidos por el usuario antes de ser pasadas a ejecutar con
MATLAB ni permite enviar ficheros del cliente al servidor, lo que imposibilita el desarrollo de
23
prácticas con cambio de estrategias de control. El sistema RECOLAB hace uso de MATLAB
Web Server para enlazar los datos del cliente con MATLAB [51, 24].
Gestión de prácticas mediante LabVIEW Internet Tool-kit
LabVIEW tiene la particularidad de que se puede unir el nivel de interfaz de usuario y el

de gestión de prácticas pues el VI (Virtual Instrument, archivo de LabVIEW) que conforma el
pedido de la práctica a ejecutar puede utilizar a otros que le permitan comunicarse con LabVIEW
y pasarle directamente los parámetros. Para poder utilizar esta variante hay que instalar
LabVIEW en el servidor web.
Gestión de prácticas mediante mecanismos propios de comunicación
Algunos sistemas desarrollados hacen uso de software específico para llevar a cabo el
procesamiento de las prácticas, implementando sus mecanismos propios para comunicar la
interfaz de usuario con este nivel. Por otra parte otros utilizan MATLAB o LabVIEW, pero no
usan ni MATLAB Web Server ni LabVIEW Internet Tool-kit para la comunicación, sino que
realizan su mecanismo de comunicación propio tratando de eliminar las limitaciones impuestas
por aquellos.
2.4.3 Procesamiento de las prácticas

Este nivel se encarga de ejecutar las prácticas seleccionadas por el usuario, cuyos datos y
parámetros fueron establecidos en la interfaz del usuario. La forma en que se procesan las
prácticas depende del software utilizado. Las variantes más recurridas son software específico,
LabVIEW y MATLAB/Simulink. Ambos, a pesar de ser software propietario, son los más
utilizados.
Procesamiento de las prácticas mediante software específico
Para la implementación de este nivel se utilizan lenguajes como C, C++, Java, Python
entre otros. Esta variante se desarrolla generalmente para aplicaciones muy específicas y tiene el
inconveniente de ser difícil de mantener y, a la larga, su costo efectivo es mucho más alto que
implementarlo mediante un software profesional.
24
Procesamiento de las prácticas mediante LabVIEW
LabVIEW constituye un software muy utilizado para el procesamiento de prácticas

debido a su fácil uso [6]. James Trevelyan plantea que LabVIEW es un potente software con un
amplio rango de conexiones de hardware y plataformas de apoyo que permiten la realización de
aplicaciones para Internet. LabVIEW provee todas las facilidades básicas requeridas para
implementar laboratorios online [52]. Otra ventaja que presenta LabVIEW es que, al ser
desarrollado por la compañía National Instruments, tiene una amplia compatibilidad con tarjetas
de adquisición de datos y otros dispositivos físicos.
Procesamiento de las prácticas mediante MATLAB/Simulink

MATLAB/Simulink como herramienta de procesamiento de prácticas es muy potente debido
a la gran variedad de paquetes de herramientas relacionados con el control que contiene, por lo
que tiene un amplio uso en el área de control automático. Además, se desarrolla una gran
cantidad de software para interactuar con MATLAB, entre ellos los necesarios para lograr la
ejecución de las prácticas en tiempo real, independientemente de que MATLAB tenga su paquete
de herramientas de tiempo real (Toolbox Real-Time Workshop y Real-Time Windows Target)
[33].
2.5 Conclusiones y comentarios
Sobre la base de este estudio se selecciona para ser implementado el Sistema de Laboratorios a
Distancia desarrollado por la UCLV, que tiene la mayoría de las facilidades reportadas en la
literatura e incluye aspectos novedosos como disponer de múltiples estaciones en las cuales se
puede ejecutar las mismas prácticas. De esta forma se puede lograr un mayor paralelismo y, por
ende, mayor velocidad de respuesta ante accesos simultáneos. Además permite la ejecución de
experimentos con cambio de estrategia de control brindando amplias posibilidades para el
desarrollo de actividades prácticas docentes y de investigación.
25
CAPÍTULO 3. El sistema de laboratorios a distancia
CAPÍTULO 3. EL SISTEMA DE LABORATORIOS A DISTANCIA
3.1 Introducción
De acuerdo al estudio realizado en el capítulo anterior de los sistemas existentes se

selecciona el SLD desarrollado por la UCLV para implementarlo en la UBB. En este capítulo se
aborda todos los aspectos relacionados con la instalación y puesta en marcha del mismo,
detallando sus estructuras de base de datos, funciones de MATLAB y análisis de su seguridad
informática.
3.2 Características generales del SLD
El principal objetivo del SLD es permitir a los usuarios realizar prácticas como
identificación del modelo, control de nivel de tanques de forma lineal (con previa linealización),
control PID y también validar otros tipos de controladores a través de Internet.
El SLD es una aplicación desarrollada con tecnología web, que modifica su estado a partir
de la interacción con el usuario. Este sistema permite realizar prácticas de sistemas de control con
diferentes tipos de plantas. Brinda además, al usuario registrado, la posibilidad de acceder a su
directorio de prácticas donde se guardan todas las actividades realizadas. Los usuarios que tengan
mayores privilegios cuentan con interfaces para mantener actualizada la base de datos que sirve
de soporte al sistema. También pueden revisar y calificar las prácticas de los usuarios entre otras
tareas adicionales [33].
El SLD tiene las siguientes características:
Disponibilidad: Los sistemas de enseñanza basados en Web deben de poder estar disponibles las
24 horas del día. Esto implica que el sistema debe de tener medidas de autoprotección para
garantizar este aspecto. Todos los experimentos deben de ser equipados con dispositivos
hardware y software que prevengan daños al equipo o al personal presente en el laboratorio.
Accesibilidad: Debido a que el SLR está montado sobre una plataforma Web, permite a los
usuarios acceder al sistema desde cualquier parte del mundo. Para ello solo es necesaria un
computador con conexión a Internet y un navegador Web, tales como el Internet Explorer, google
Chrome, Mozilla Firefox, etc.
26
Facilidad de uso: Para usar el sistema los usuarios solo deben tener los conocimientos básicos de
los sistemas de control, tales como el modelado de sistemas y el diseño de controladores. De esta
forma el usuario se centra en aprender estos temas y evita todos los problemas asociados a la
implementación y operación de los equipos usados en las prácticas.
Además de las características descritas anteriormente, las cuales son comunes a la

mayoría de los sistemas de laboratorios a distancia, este SLD posee características adicionales,
tales como:
Interfaz de usuario rápida y fácil: Una parte esencial en el desarrollo de un sistema de enseñanza
basado en Web es la interfaz de usuario. La principal función de esta parte del sistema es
conformar el pedido de las prácticas y mandarlo hacia el servidor Web. La interfaz de usuario del
SLR está basada en páginas HTML que utilizan funciones Javascript y ASP11; esto permite que
los usuarios puedan acceder al sistema de una forma rápida y sin necesidad de descargar o
instalar ningún software adicional. El sistema cuenta también con páginas de ayuda que
proporcionan información técnica a los usuarios, tal como el modelado matemático de los
dispositivos usados en las prácticas, datos del fabricante, ajuste de reguladores y guías con
prácticas a desarrollar con este sistema.
Administración de múltiples pedidos en forma paralela: El SLR permite atender múltiples

pedidos de forma paralela administrando de forma centralizada dispositivos similares que se
encuentren geográficamente separados pero unidos por redes de área extensa (WAN). Esto
permite una mayor disponibilidad de los equipos y un servicio más rápido y eficiente para los
usuarios; lográndose con esto reducir los tiempos de espera para que un usuario remoto realice
una determinada práctica.
________________________________________
11
ASP/ ASP.NET es un lenguaje de secuencia de comandos (script) del lado del servidor desarrollado por Microsoft.
Es utilizado para la programación de páginas web dinámicas y para la comunicación con bases de datos. Se utiliza
esta tecnología para validar el acceso de los usuarios y comunicarse con las bases de datos del sistema.
27
Desarrollo de controladores de forma remota usando Matlab y Simulink: Una de las

características más importantes del SLR es que permite a los usuarios diseñar sus propios
controladores utilizando el ambiente Matlab-Simulink. Estos programas son un estándar en el
área del control automático, por lo que los usuarios no necesitan perder tiempo aprendiendo
nuevos lenguajes de programación para implementar un nuevo controlador, solo necesitan un
conocimiento básico del ambiente de Matlab y Simulink. A través de la interfaz gráfica de
Simulink, una gran cantidad de bloques pueden ser escogidos y conectados de forma muy
sencilla, lo que permite a los usuarios crear controladores analógicos, digitales o híbridos de
forma rápida.
Al SLD se puede ingresar mediante autentificación o sin esta, las 3 maneras distintas de
entrar al sistema son:
 Usuario anónimo
 Estudiante
 Administrador
Al Usuario Anónimo el sistema le brinda la posibilidad de acceder al Servicio de

autentificación para así poder hacer uso del sistema como Estudiante o Administrador y además
de poder acceder a las páginas de teoría e información de las prácticas y de la plataforma. En caso
de ser un usuario sin registro en el sistema se deben introducir los datos solicitados y
automáticamente se accede a la sesión.
Al actor Estudiante el sistema le brinda la posibilidad de utilizar el Servicio de prácticas.

El sistema crea un directorio personal donde se guardan todos los resultados de los experimentos
realizados por el actor Estudiante. Este puede elegir en qué forma ejecutar la práctica según sean
las opciones y además puede seleccionar que resultados deben ser revisados por el actor
Administrador. Puede igualmente revisar en cada momento todas las prácticas realizadas por él y
eliminar las no deseadas.
28
El Administrador es el de más privilegio del sistema. Este, además de acceder al Servicio

de prácticas, tiene privilegios para chequear los directorios personales de los estudiantes, revisar
sus prácticas y darle una calificación. Tiene la posibilidad de administrar la base de datos del
sistema, crear, editar y eliminar usuarios, introducir nuevas prácticas, configurar las propiedades
de la aplicación mediante el caso de uso Administrar configuración. Tiene también permiso para
realizar reservas de laboratorios.
3.3 Arquitectura del sistema de laboratorios a distancia
El SLD está dividido en tres partes:
1. Interfaz del usuario.
2. Administración de los pedidos de las prácticas.
3. Procesamiento de las prácticas.
En la Tabla 3.1 se relaciona cada una de estas tres partes de la plataforma así como su
implementación.
Tabla 3.1 Partes e implementación de la plataforma [33].
Partes de la Plataforma Implementación en la plataforma
Interfaz de Usuario Sitio web con páginas HTML y PHP
Administración de pedidos de prácticas Aplicaciones propias con web services y PHP

(Servidor y Estación).
Procesamiento de las Practicas MATLAB con Real Time Toolbox y Real

Time Windows Target
29
La Figura 3.1 muestra la interacción de estas tres partes.
Figura 3.1 Funcionamiento general del sistema de laboratorio a distancia.
Los usuarios interactúan con el sistema a través de Internet. Al acceder al sitio Web del
sistema se elige la práctica que se desea realizar. Allí el usuario debe llenar correctamente todos
los datos en el formulario asociado a la práctica y finalmente elegir entre ejecutarla de manera
simulada o real. El CGI12 que se encuentra en el servidor Web recibe los datos y los manda al
Servidor de Administración de Prácticas (SAP) como un nuevo pedido. El SAP verifica cual
estación de trabajo puede realizar la práctica pedida y una vez que la encuentra saca el pedido de
la lista y se lo envía al Cliente de Administración de Prácticas (CAP) instalado en la estación de
trabajo. Cuando el pedido llega al CAP se procesan los datos y se lleva a cabo la práctica
utilizando Matlab-Simulink. Una vez que la práctica ha sido procesada se trasmite el resultado en
sentido inverso al que trajo el pedido para que al final llegue hasta el usuario la respuesta de la
práctica. La respuesta es una página Web que muestra los resultados del procesamiento.
__________________________________
12
CGI es una tecnología web que permite a un cliente (navegador web) solicitar datos de un programa ejecutado en
un servidor web. CGI especifica un estándar para transferir datos entre el cliente y el programa.
30
Es necesario aclarar que el SAP es el encargado de elegir la estación de trabajo correcta,

pero en el caso de este proyecto es una única estación de trabajo. La inclusión de este Servidor de
Administración de Prácticas (SAP) permite adherir más estaciones de trabajo al sistema a futuro.
El servidor Web y el Servidor de Administración de Prácticas (SAP) se instalan en un
computador con sistema operativo Windows 7, ubicado en el laboratorio de control. Este
computador es a la vez, la estación de trabajo por lo cual debe tener instalado el Cliente de
Administración de Prácticas (CAP) así como Matlab y Simulink para el procesamiento de las
prácticas.
Para las prácticas de control, el sistema cuenta con una maqueta compuesta por 4 tanques
de agua interactuantes en los cuales se controla el nivel y 2 bombas para llevar el agua hasta estos
tanques, este es un sistema de múltiples entradas y múltiples salidas (MIMO) que presenta una
dinámica altamente acoplada y fuertemente no lineal, lo que nos permite realizar prácticas
complejas de control o también practicas más simples cerrando las válvulas correspondientes
para realizar prácticas de control en solo 2 tanques.
3.3.1 Integración con MATLAB/simulink
El sistema se ha implementado sobre software libre, tanto el soporte técnico como el

lenguaje de programación debido a las ventajas que este brinda. Solo quedó como software
propietario MATLAB para el procesamiento de las prácticas por las ventajas que tiene este
software en la enseñanza del control [33].
El software libre brinda la posibilidad a los usuarios de ejecutar, copiar, distribuir,
estudiar, cambiar y mejorar los programas desarrollados. El software libre se refiere a cuatro
tipos de libertades para los usuarios. La primera es la libertad de ejecutar el programa para
cualquier propósito. La segunda es la libertad de estudiar cómo trabaja el programa, y adaptarlo a
sus necesidades. El acceso al código fuente es una condición necesaria. La tercera libertad es la
de redistribuir copias para que puedan ayudar a otros usuarios. Por último la libertad de mejorar
el programa y publicar sus mejoras y nuevas versiones, para que se beneficie toda la comunidad
de usuarios y desarrolladores.
En el desarrollo del sistema se utilizó como lenguaje de programación PHP el cual es un
lenguaje interpretado de alto nivel y ejecutado en el servidor. En el caso del servidor de base
31
datos se utilizó MySQL y las consultas se realizaron utilizando el lenguaje SQL13. Se utilizó
igualmente para algunas aplicaciones del cliente códigos programados en JavaScript, el cual es
un lenguaje interpretado orientado a las páginas web. Otra de las tecnologías utilizadas fue
AJAX, que es una técnica de desarrollo web para crear aplicaciones interactivas. Estas se
ejecutan en el cliente y mantiene comunicación con el servidor en segundo plano. El otro
software utilizado en el sistema fue MATLAB/Simulink, el cual fue usado para la programación
de las prácticas, ficheros .m y .mdl asociados a cada práctica. La versión utilizada de MATLAB
fue la 2012.
El sistema presenta como requerimientos técnicos un servidor web Apache, que puede
instalarse sobre Windows o Linux. Este servidor es muy robusto y presenta muchas
funcionalidades. Además debe instalarse PHP versión 5.2.6, tanto en su versión para Windows
como para Linux en dependencia del sistema operativo escogido para el servidor web.
Igualmente el Servidor MySQL como gestor de base de datos, puede instalarse sobre Windows o
Linux.
En el caso de MATLAB, se instala en las estaciones de trabajo, es decir, las que se
conectan directamente al proceso real. En caso de realizar prácticas con cambio de estrategia es
necesario el uso de MATLAB/Simulink para modificar la plantilla base descargada del servidor.
En la Figura 3.2 se muestra la infraestructura del SLD. Las páginas servidoras (1) solicitadas por
la aplicación cliente han sido programadas en lenguaje PHP. Mediante estas páginas se accede a
los formularios web (2) las cuales han sido desarrolladas en XHTML14.
En dependencia del tipo de formulario se accede a un servicio otro. La clase de
autentificación LDAP15 (3) (Lightweight Directory Access Protocol, Protocolo Ligero de Acceso
a Directorios) se encarga de gestionar la conexión con el servidor de dominio y la autentificación
de las credenciales a través de las funciones apropiadas para estos fines. Por su parte la clase de
sesión de usuario UserSession (4) contiene las funciones que manejan los datos personales de los
usuarios y crea una sesión en el servidor. Las clases de configuración (5) están destinadas a
introducir y extraer de archivos los parámetros de configuración.
____________________________________
13
El lenguaje de consulta estructurado o SQL (Structured Query Language) es un lenguaje declarativo de acceso a
bases de datos relacionales que permite especificar diversos tipos de operaciones en estas.
14
XHTML (eXtensible HyperText Markup Language) es básicamente HTML expresado como XML válido.
15
LDAP (Lightweight Directory Access Protocol) es un protocolo a nivel de aplicación que permite el acceso a un
servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red.
32
Figura 3.2 Vista general de la infraestructura del SLD [33].
La lógica de validación (6) lo constituyen un grupo de archivos que contienen códigos de

validación de datos y otras tareas específicas. Se comunica con las clases de conexión con el
servidor de base de datos SQL (8) el cual cuenta con métodos capaces de establecer una
conexión, hacer consultas a la base de datos y hacer un procesado primario de la información
resultante.
El Cliente Web Services (7), es el encargado de recoger los parámetros de las prácticas
que se desean realizar y enviárselos al servidor para ser procesados, quedándose a la espera de la
respuesta. Para esto se comunica tanto con las clases de conexión con el servidor de base de datos
SQL (8) como con el Servidor de Web Services (10).
33
El servidor de video (9) es un servidor de video streaming para la realimentación visual

que permite visualizar en tiempo real el desarrollo de la práctica ejecutada en el dispositivo real.
El servidor de Web Services (10) es el encargado de procesar los datos de las prácticas,
ejecutarlas y enviar la respuesta al cliente. Para esto se comunica con la planta física (11) a través
de la tarjeta de adquisición de datos. El software utilizado para ejecución de las prácticas es el
MATLAB/Simulink.
El desarrollo de la práctica puede ser visualizado a través de una cámara Webcam (12)
dedicada a la realimentación visual. Esta visualización es transmitida por streaming por medio
del servidor de video (9).
El video y el resultado de la ejecución de la práctica conforman la respuesta de datos (13)
en formato XHTML, devueltos a la aplicación cliente para que puedan ser visualizados por el
usuario final. Todo el diseño del sitio es a través de hojas de estilos CSS22 (14) las que son
usadas para definir la presentación de los resultados [33].
3.3.2 Interfaz gráfica del cliente
La interfaz de usuario se ha desarrollado con páginas HTML y PHP (versión 5.2.6) para el
registro de usuarios y la administración y gestión del sitio web. También se ha hecho uso de
funciones en JavaScript y de la tecnología AJAX. El sistema está formado por dos tipos de
interfaces mediante las cuales interactúan los usuarios registrados: una para los usuarios
Estudiante y otra para los usuarios Administrador. Un usuario Administrador es por defecto un
Usuario Estudiante por lo que puede pasar de un nivel de privilegio a otro con solo hacer clic en
Usar o en Administrar en la barra de navegación.
La arquitectura general de una aplicación web es similar a un sistema cliente-servidor,
aunque con algunas diferencias. Una de las principales diferencias es la distribución, donde los
aspectos fundamentales a la configuración de la aplicación se encuentran en componentes del
lado del servidor; ningún software específico, ni opciones adicionales son necesarias del lado del
cliente [54]. Además, el principal protocolo de comunicación para las aplicaciones web es HTTP,
el cual está diseñado para soportar conexiones no permanentes, haciendo robusto y sin fallos a
múltiples instancias. También limita la comunicación directa de los objetos clientes con los
objetos del servidor.
34
En la figura 3.3 Se muestra la página web del SLD y se mencionan sus principales zonas.
Figura 3.3 Esquema de la interfaz de usuarios del SLD [56].
1. Logo del Sistema.
2. Fecha y hora.
3. Barra de navegación.
4. Formulario de autentificación, información del usuario, barra de navegación y opciones.
5. Cuerpo de la página.
Se puede acceder al sistema desde un ordenador con conexión a Internet usado cualquier
navegador para web.
A la interfaz de usuario se le ha adicionado una realimentación visual en tiempo real con
el objetivo de que el usuario pueda observar cómo se desarrolla la experiencia, lo cual hace aún
más atractiva la ejecución de las practicas. Para el streaming se utiliza el software
UnrealMediaServer.
35
Cuando un usuario accede al sitio Web del SLD, debe registrarse o autentificarse en el
sistema proporcionando su nombre de usuario y su clave. Esto permite tener dos tipos de
usuarios: usuarios de prácticas y usuarios administradores. Una vez dentro del sistema los
usuarios de prácticas pueden llevar a cabo varias operaciones, tales como ver las páginas de
teoría, contactar con los desarrolladores del sistema así como ver las prácticas disponibles en el
sistema. Todas estas páginas se encuentran localizadas en el servidor Web del sistema, el cual es
común para todas las prácticas.
Después de que el usuario ha seleccionado alguna práctica, aparece una página Web que
contiene el diagrama de bloques del sistema, una explicación de la simbología utilizada en la
práctica, enlaces a las páginas de teoría de la práctica y un formulario en donde el usuario puede
definir el tipo de control, modificar los parámetros del controlador o crear un controlador
definido por el usuario y un cuadro en el que se visualiza en tiempo real la maqueta mediante una
cámara instalada en el laboratorio.
 Prácticas con controlador predefinido
En la pestaña “Practicas” del sitio web, se ofrece al usuario la posibilidad de utilizar un

controlador predefinido al cual se puede modificar sus parámetros.
A esta práctica se puede optar por dos formas de ejecución: de forma simulada, donde se simula
la ejecución y se obtiene una respuesta idealizada de la práctica o de forma real.
En la figura 3.4 se muestra la ventana del sitio web correspondiente a la práctica con control
predefinido.
36
Figura 3.4 Ventana de práctica con control predefinido [56].
 Prácticas con controlador definido por el usuario
Cuando el usuario accede a alguna práctica en la que se puede definir el controlador a usar,
aparece una página de la cual el usuario debe descargar un archivo de Simulink (*.mdl) que
contiene el diagrama de bloques de la práctica correspondiente. Para realizar las prácticas el
usuario debe tener instalado el software Matlab-Simulink para modificar el archivo de Simulink
descargado.
37
En este archivo el usuario debe modificar los subsistemas Referencia y Controlador

utilizando el software Matlab-Simulink, sin alterar el nombre de las entradas y salidas de los
subsistemas.
Una vez realizada la modificación, el usuario debe subir al servidor el fichero modificado y
decidir si quiere realizar una simulación o controlar el proceso real. Cuando se manda a ejecutar
el proceso real el SLD realiza primero una simulación del sistema y sobre los datos obtenidos de
la misma se realizan una serie de pruebas para determinar si el controlador se puede implementar
en el sistema real.
La figura 3.5 muestra la ventana del sitio web correspondiente a la práctica con controlador
definido por el usuario
Figura 3.5 Ventana de práctica con control definido por usuario [56].
38
3.4 Estructura de la base de datos
La base de datos será la encargada de gestionar el almacenamiento de la información

requerida [33]. A partir del modelo conceptual se puede obtener un modelo lógico de cómo serán
almacenados los datos del sistema. En la Figura 3.6 se muestra el modelo lógico de la base de
datos donde se puede apreciar cómo se distribuye la información. Los campos marcados como
PK indican que se trata de una clave primaria.
A continuación se define de manera general la función de cada una de las siete tablas que
conforman la base de datos:
sld_practices: Contiene los datos de todas prácticas realizadas por los usuarios.
sld_practices_data: Contiene todas las prácticas disponibles en el sistema, su nombre, el tipo de

práctica, etc.
sld_station: Contiene la relación de todas las estaciones de trabajo del sistema, su estado, las
prácticas que se pueden realizar en ella, etc.
sld_users: Contiene los datos de todos los usuarios registrados en el sistema, así como su login y
password.
sld_users_groups: Contiene todos los grupos de usuarios realizados para los tiempos de
laboratorio.
calendar_tasks: Contiene la relación de las reservas de laboratorio
comments: Contiene todos los comentarios realizados por los estudiantes y profesores para cada
práctica.
39
Figura 3.6 Modelo Lógico de la Base de Datos [33].
Una de las tablas más importantes del sistema es sld_users debido a que almacena la
información de todos los usuarios registrados. El campo name almacena el nombre del usuario y
el campo login el nombre de usuario en el sistema, mientras que la contraseña de cada usuario es
almacenado en el campo password. En esta tabla se almacena tanto la fecha (date) como la hora
(time) de acceso al sistema. Hay que destacar que en esta tabla se verifica que no se repita ni el
nombre (name) ni el nombre de usuario (login).
Otra tabla de gran importancia en el sistema es sld_practices_data. Esta tabla almacena
todos los datos de las prácticas que se desarrollan en el sistema. El campo pname almacena el
nombre abreviado de la práctica, mientras que en pcname se guarda el nombre completo de la
práctica, este será el que luego se visualizará en la página de prácticas del sistema. En el capo
type se define el tipo de práctica, si es simulada o real.
En la tabla sld_station se relacionan todas las estaciones disponibles en el sistema, además
de las prácticas que se pueden realizar en cada una de estas estaciones. Es una tabla fundamental
para poder desarrollar la propiedad de paralelismo del sistema. Además con los datos de esta
40
práctica se desarrolla la aplicación que muestra el tiempo de espera para cada práctica. El campo
state representa el estado de la estación apagada (off), en espera (wait) u ocupada (busy).
3.5 Estructura de las funciones de MATLAB
En las estaciones de trabajo, MATLAB es el encargado de ejecutar las prácticas sobre la

maqueta con los parámetros enviados por el cliente. Los valores de los parámetros son cambiados
en Simulink de manera automática gracias a la programación desarrollada.
A continuación se detalla la estructura de las funciones que hacen posible la ejecución de

las prácticas tanto de forma real como simulada.
3.5.1 Ejecución de prácticas de forma real con control predefinido
Al momento de ejecutar la práctica real con control predefinido desde la página web, el
servidor ordena ejecutar el archivo “m_CT_T1_PIDFr.m” ubicado en la ruta
“D:\www\SLDStation\practicas\CT_T1_PIDFr” en la estación de trabajo.
En la figura 3.7 se muestra el código del archivo m_CT_T1_PIDFr.m
41
1 close_system(gcs,0);
2
3 vars = who;
4 if length(vars) == 5,
5 if P >= 0 && P <= 10 && I >= 0 && I <= 10 && D >= 0 && D <= 10 && O >= 1
6 && O <= 10 && Fc > 0 && Fc < 5,
7 bdclose('all');
8 %Presumo no hay error
9 varerror = '0';
10
11 % Datos específicos de CT_T1_PIDr
12 id = 'CT_T1_PIDFr';
13 PracticeFile = 'CT_T1_PIDFr';
14 Graph1File = 'CT_T1_PID_nivelr.jpg';
16 Plot1 = 'plot(simout.time, simout.signals.values(:,2:4))';
17 Graph2File = 'CT_T1_PID_mandor.jpg';
18 Plot2 = 'plot(simout.time, simout.signals.values(:,1))';
19
20 % Inicializar la cadena de retorno.
21 retstr = char('');
22
23 % Inicialización de la estructura de datos
24 p = what;
25 mldir = p.path; % Path completo donde está el mdl y el html plantilla
26 outdir = [p.path '\out'];% Path donde queda html y sus graficas
27 htmldir = [p.path '\html'];
28
29 pf = PracticeFile;
30
31 % Pone los parámetros en el mdl
32 eval(pf);
33 set_param([pf '/Controler'],'P',num2str(P));
34 set_param([pf '/Controler'],'I',num2str(I));
35 set_param([pf '/Controler'],'D',num2str(D));
36 set_param([pf '/Filter'],'O',num2str(O));
37 set_param([pf '/Filter'],'Fc',num2str(Fc));
38
39
40 %Graba las variables del directorio
41 save globales;
42
43 %Creo el codigo
44 try
45 make_rtw;
46 catch
47 varerror = 'Error creando el código en Real Time Windows Target';
48 return;
49 end
50
51 %Simulink cambia a modo externo
52 set_param(gcs,'SimulationMode','external');
53
54 %MatLab carga la aplicación en tiempo real y la conecta con los
55 bloques de simulink
56 set_param(gcs,'SimulationCommand','connect');
57
58 %Inicializa la simulación en tiempo real
59 set_param(gcs,'SimulationCommand','start');
60
61 else
62 varerror= 'ERROR 1: Hay variables fuera de rango.';
63 end
64 else
65 varerror= 'ERROR 2: Las variables no se han introducido correctamente';
66 end
Figura 3.7 Código del archivo m_CT_T1_PIDFr.m
42
Al ejecutarse el archivo, en la línea 1 de código, cierra todo archivo de extensión “.m” que
pudiese estar abierto, resultante de prácticas anteriores ya finalizadas. En la línea 4 se verifica que
se haya ingresado en la página cada uno de los valores que se requieren para el controlador, los
cuales son: Parte proporcional del filtro (P), parte integral (I), parte derivativa (D), orden del
filtro (O) y frecuencia de corte (Fc). Si falta alguna de estas variables o se ingresa un carácter
incorrecto, se enviara devuelta el siguiente mensaje “ERROR: Las variables no se han
introducido correctamente.”
Luego en la línea 5, se condiciona a que estos valores estén dentro de valores razonables
(P, I, D, entre 0 y 10; O, mayor o igual a 1 y menor o igual a 10; Fc, mayor a 0 y menor que 5).
En el caso de haber un valor fuera de rango, se mostrara un mensaje “ERROR: Hay variables
fuera de rango.”
En la línea 7, con el comando bdclose(‘all’) se cierra cualquier ventana de simulink que
pudiese estar abierta excepto la que se está ejecutando. Luego se asume que no hay error
asignando varerror = ‘0’ en la línea 9. En las siguientes líneas de código se especifican los datos
del fichero CT_T1_PIDr como lo son la identificación de la práctica (id = CT_T1_PIDFr) el cual
debe ser exactamente el mismo nombre con el que se identifica en la base de datos, también se
identifica el nombre del archivo que contiene la practica el cual posee el mismo nombre del id.
Luego, se asigna el nombre del archivo en formato .jpg (CT_T1_PID_nivelr.jpg) con el que se
exportaran los gráficos de nivel de los tanques. Después, en plot1 (línea 16) se grafica lo que
contendrá la imagen CT_T1_PID_nivelr.jpg. En esta se grafica tiempo y señal de salida
correspondientes a todas las filas desde la columna 2 hasta la 4 de la matriz de datos. En las
líneas de código 17 y 18 se repite el mismo proceso esta vez para el grafico del mando de nombre
CT_T1_PID_mandor.jpg para el que se grafica tiempo y señal de salida del mando
correspondiente a todas las filas de la columna 1 de la matriz de datos.
En la línea 21 se inicializa la cadena de retorno “retstr” y luego la estructura de datos. En
las siguientes líneas se asigna la ruta o path en las que se encuentra el archivo .mdl y html
plantilla, ruta donde quedara el html resultante con los graficos y la ruta del fichero html.
En la línea de código 38 se asigna el nombre “pf” al fichero .mdl que se debe ejecutar
para luego ejecutarlo con el comando “eval(pf)”. Dentro del mdl ejecutado (Figura 3.8) Se
asignan los valores de “P”, “I”, “D”, “O” y “Fc” del bloque controler (líneas de código 33 a 37).
Para asignar estos valores en el archivo .mdl, primero se deben transformar a cadena con el
43
comando “num2str” ya que desde el sistema son enviados como número. Finalmente se guarda
las variables con el comando “save globales”
Figura 3.8 Archivo simulink de práctica en modo real con controlador predefinido.
Visto de manera más gráfica, los pasos anteriores desde la línea de codigo 32 hasta la 41
es equivalente a abrir el archivo .mdl, dar doble clic al bloque controler, modificar sus parámetros
y dar clic a OK como se muestra en la figura 3.9
Figura 3.9 Cambiar parámetros al bloque controler desde simulink.
44
Una vez cambiados los parámetros intenta compilar el .mdl con el comando try, si no
logra compilar devuelve un mensaje “Error creando el código en Real Time Windows Target”. Si
compila el código, pasa al siguiente comando (línea 52) con el cual cambia a MATLAB a modo
externo, luego en la línea 56 carga la aplicación en tiempo real y la conecta con los bloques de
simulink. Finalmente en la línea 59 inicializa la simulación en tiempo real y termina de ejecutarse
el archivo .mdl.
El archivo .mdl está configurado para que al momento de terminar, cree una variable de
salida llamada “simout” que es enviada al workspace de MATLAB y ejecute el archivo
“salida.m”. Esta configuración se puede ver dentro del archivo .mdl dando clic a File, luego
Model Properties. Ahí se abrirá una ventana, en esta, dar clic en la pestaña Callbacks y luego en
la lista lateral izquierda dar clic en StopFcn*. Aquí muestra lo que hace cuando termina de
ejecutarse el programa como se ve en la figura 3.10
Figura 3.10 Configuración de StopFcn* del archivo .mdl.
45
Dentro del archivo “salida.m” se tiene el código de la Figura 3.11
1 function retstr=salida(simout)
2 % Practica de control de Tanques
3
4 % Datos especificos de CT_T1_PID
5 id = 'CT_T1_PIDFr';
6 PracticeFile = 'CT_T1_PIDFr';
7 Graph1File = 'CT_T1_PID_nivelr.jpg';
9 Graph2File = 'CT_T1_PID_mandor.jpg';
11
12 % Inicilizar la cadena de retorno.
14
15 % Inicializacion de la estructura de datos
16 p = what;
17 mldir = p.path; % Path completo donde esta el mdl y el html plantilla
18 outdir = [p.path '\out']; % Path donde quedara el html
20
22
23 % Creando las figuras
24 cd(outdir);
25
26 h = figure('visible','off');
27
28 % Ajuste del tamaño de la figura
29 p = get(gcf, 'position');
30 p(3) = 380;
31 p(4) = 310;
32 set(gcf, 'Position', p, 'PaperPosition', [.25 .25 4 3]);
33
34 %Creando figura 1
35 eval(Plot1);
36 grid on;
37 legend('Nivel deseado en T1','Nivel real en T1','Nivel filtrado en
38 T1','Location','SouthEast');
39 GraphFile = sprintf(Graph1File);
40 print(h, '-djpeg', '-r0', GraphFile);
41
43 eval(Plot2);
44 grid on;
47
48 close(h);
49
50 % Creando el fichero de respuesta.
51 vec = [simout.time simout.signals.values(:,2:4) simout.signals.values(:,1)];
52 str = ['save ' PracticeFile '.mat vec -ascii -tabs'];
53 eval(str);
54
55 cd(mldir);
56
57 varerror = '0';
58 clc
Figura 3.11 Código del archivo salida.m
46
Este archivo recibe las variables de simout, define los datos específicos de igual manera que en el
archivo .mdl, luego en la línea 13 vuelve a inicializar la cadena de retorno, inicializa la estructura
de datos y asigna el nombre “pf” a PracticeFile. En la línea 24 cambia a MATLAB al directorio
salida. Luego se crea una variable “h” que será un puntero a la figura invisible, entonces lo que se
haga sobre la variable h se hará a la figura que no se mostrará. En las siguientes líneas de código
se ajusta el tamaño de la figura al requerido para la página web. En la línea 35 se evalúa la cadena
plot1 (correspondiente a la señal de nivel del tanque 1), en las siguientes líneas se activa la grilla
para el gráfico, se asigna una leyenda para las señales y su posición, se abre un fichero gráfico y
se guarda la imagen en formato jpeg. De igual manera se crea otra imagen esta vez evaluando
plot2 (correspondiente a la señal de mando). Luego, en la línea 48 cierra la figura invisible para
que no quede “virtualmente abierta”. Para devolver los datos al sistema en la línea 51 se crea un
fichero de respuesta en el cual contiene los vectores con las señales de tiempo nivel y mando.
Después se guardan estos datos con extensión “.mat”. En la línea 55 vuelve MATLAB al
directorio en el que estaba originalmente y se envía varerror = ‘0’ lo que quiere decir que no hubo
errores en la ejecución. Cuando recibe esta señal, el servidor busca en la carpeta
“D:\www\SLDStation\practicas\CT_T1_PIDFr\out” la plantilla salida.html creada con las
imágenes y datos guardados resultantes de los códigos de programación. Finalmente Esta
plantilla es mostrada al usuario en la página web del SLD.
3.5.2 Ejecución de prácticas de forma simulada con control predefinido
La ejecución de prácticas simuladas es similar a las prácticas reales, pero más sencillo.
Este solo requiere un archivo de extensión “.m” y otro de extensión “.mdl” ya que solo se simula
en MATLAB sin necesidad de esperar a que termine la ejecución en la maqueta de tanques
interactuantes. Al momento de ejecutar la práctica simulada con control predefinido desde la
página web, el servidor ordena ejecutar el archivo “m_CT_T1_PIDFs.m” ubicado en la ruta
“D:\www\SLDStation\practicas\CT_T1_PIDFs” en el servidor para optimizar recursos. Las
estaciones de trabajo se encargan de realizar solo las prácticas reales.
En la figura 3.12 se muestra el código del archivo m_CT_T1_PIDFs.m
47
1 close_system(gcs,0);
2 vars = who;
3 if length(vars) == 5,
4 if P >= 0 && P <= 10 && I >= 0 && I <= 10 && D >= 0 && D <= 10 && O >= 1
5 && O <= 10 && Fc > 0 && Fc < 5,
6
7 bdclose('all');
8
9 % Datos específicos de CT_T1_PIDs
10 id = 'CT_T1_PIDFs';
11 PracticeFile = 'CT_T1_PIDFs';
12 Graph1File = 'CT_T1_PID_nivels.jpg';
14 Graph2File = 'CT_T1_PID_mandos.jpg';
16
17 % Inicializar la cadena de retorno.
19
20 % Inicialización de la estructura de datos
21 p = what;
22 mldir = p.path; % Path completo donde está el mdl y el html plantilla
23 outdir = [p.path '\out']; % Path donde quedara el html resultante con sus graficas
25
27 eval(pf);
28 set_param([pf '/Controler'],'P',num2str(P));
29 set_param([pf '/Controler'],'I',num2str(I));
30 set_param([pf '/Controler'],'D',num2str(D));
31 set_param([pf '/Filter'],'O',num2str(O));
32 set_param([pf '/Filter'],'Fc',num2str(Fc));
33 sim(pf);
34
35 % Creando las figuras
36 cd(outdir);
37 h = figure('visible','off');
38
39 % Ajuste del tamaño de la figura
40 p = get(gcf, 'position');
41 p(3) = 380;
42 p(4) = 310;
43 set(gcf, 'Position', p, 'PaperPosition', [.25 .25 4 3]);
44
46 eval(Plot1);
47 grid on;
48 legend('Nivel deseado en T1','Nivel simulado en T1','Location','SouthEast');
51
53 eval(Plot2);
54 grid on;
57
58 close(h);
59
60 % Creando el fichero de respuesta.
61 vec = [simout.time simout.signals.values(:,2:3) simout.signals.values(:,1)];
62 str = ['save ' PracticeFile ' vec -ascii -tabs'];
63 eval(str);
64
65 cd(mldir);
66 varerror = '0';
67 clc
68 else
69 varerror= 'Hay variables fuera de rango.';
70 end
71 else
72 varerror= 'Las variables no se han introducido correctamente.';
73 end
Figura 3.12 Código del archivo CT_T1_PIDFs.m
48
Al ejecutarse el archivo, en la línea 1 de código, cierra todo archivo de extensión “.m” que
pudiese estar abierto, resultante de prácticas anteriores ya finalizadas. En la línea 3 se verifica que
se haya ingresado en la página cada uno de los valores que se requieren para el controlador, los
cuales son: Parte proporcional del filtro (P), parte integral (I), parte derivativa (D), orden del
filtro (O) y frecuencia de corte (Fc). Si falta alguna de estas variables o se ingresa un carácter
incorrecto, se enviara devuelta el siguiente mensaje “ERROR: Las variables no se han
introducido correctamente.”
Luego en la línea 4, se condiciona a que estos valores estén dentro de valores razonables
(P, I, D, entre 0 y 10; O, mayor o igual a 1 y menor o igual a 10; Fc, mayor a 0 y menor que 5).
En el caso de haber un valor fuera de rango, se mostrara un mensaje “ERROR: Hay variables
fuera de rango.”
En la línea 7, con el comando bdclose(‘all’) se cierra cualquier ventana de simulink que
pudiese estar abierta excepto la que se está ejecutando. En las siguientes líneas de código se
especifican los datos del fichero CT_T1_PIDS como lo son la identificación de la práctica (id =
CT_T1_PIDFS) el cual debe ser exactamente el mismo nombre con el que se identifica en la base
de datos, también se identifica el nombre del archivo que contiene la practica el cual posee el
mismo nombre del id. Luego, se asigna el nombre del archivo en formato .jpg
(CT_T1_PID_nivelS.jpg) con el que se exportaran los gráficos de nivel de los tanques. Después,
en plot1 (línea 13) se grafica lo que contendrá la imagen CT_T1_PID_nivels.jpg. En esta se
grafica tiempo y señal de salida correspondientes a todas las filas desde la columna 2 hasta la 4
de la matriz de datos. En las líneas de código 14 y 15 se repite el mismo proceso esta vez para el
grafico del mando de nombre CT_T1_PID_mandos.jpg para el que se grafica tiempo y señal de
salida del mando correspondiente a todas las filas de la columna 1 de la matriz de datos.
En la línea 18 se inicializa la cadena de retorno “retstr” y luego la estructura de datos. En
las siguientes líneas se asigna la ruta o path en las que se encuentra el archivo .mdl y html
plantilla, ruta donde quedara el html resultante con los graficos y la ruta del fichero html.
En la línea de código 26 se asigna el nombre “pf” al fichero .mdl que se debe ejecutar
para luego ejecutarlo con el comando “eval(pf)”. Dentro del mdl ejecutado se asignan los valores
de “P”, “I”, “D”, “O” y “Fc” del bloque controler (líneas de código 28 a 32). Para asignar estos
valores en el archivo .mdl, primero se deben transformar a cadena con el comando “num2str” ya
que desde el sistema son enviados como número. En la línea 33 se usa el comando sim(pf) para
iniciar la simulación.
49
En la línea 36 cambia a MATLAB al directorio salida. Luego se crea una variable “h”
que será un puntero a la figura invisible, entonces lo que se haga sobre la variable h se hará a la
figura que no se mostrará. En las siguientes líneas de código se ajusta el tamaño de la figura al
requerido para la página web. Para crear la primera figura, en la línea 46 se evalúa la cadena
plot1 (correspondiente a la señal de nivel del tanque 1), en las siguientes líneas se activa la grilla
para el gráfico, se asigna una leyenda para las señales y su posición, se abre un fichero gráfico y
se guarda la imagen en formato jpeg. De igual manera se crea otra imagen esta vez evaluando
plot2 (correspondiente a la señal de mando). Luego, en la línea 58 cierra la figura invisible para
que no quede “virtualmente abierta”. Para devolver los datos al sistema en la línea 61 se crea un
fichero de respuesta en el cual contiene los vectores con las señales de tiempo nivel y mando.
Después se guardan estos datos. En la línea 65 vuelve MATLAB al directorio en el que estaba
originalmente y se envía varerror = ‘0’ lo que quiere decir que no hubo errores en la ejecución.
Cuando recibe esta señal, el servidor busca en la carpeta
“D:\www\SLDStation\practicas\CT_T1_PIDFs\out” la plantilla salida.html creada con las
imágenes y datos guardados resultantes de los códigos de programación. Finalmente Esta
plantilla es mostrada al usuario en la página web del SLD.
3.6 Seguridad informática del SLD
La seguridad informática, también conocida como ciberseguridad o seguridad de

tecnologías de la información, es el área de la informática que se enfoca en la protección de la
infraestructura computacional y todo lo relacionado con esta y, especialmente, la información
contenida o circulante. Para ello existen una serie de estándares, protocolos, métodos, reglas,
herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la
información. La seguridad informática comprende software (bases de datos, metadatos, archivos),
hardware y todo lo que signifique un riesgo si esta información confidencial llega a manos de
otras personas, convirtiéndose, por ejemplo, en información privilegiada.
El sistema de laboratorios a distancia está montado en un servidor el cual utiliza una IP

pública. Esto lo hace accesible desde cualquier lugar del mundo a través de un computador, pero
a la vez lo hace vulnerable frente a posibles intentos de intervenir el sistema. Originalmente el
sistema fue montado en un servidor utilizando XAMPP versión 1.6.5 el cual cuenta con Apache
v2.2.6 como servidor, una base de datos con MySQL v5.0.51 y lenguaje PHP v4.4.7. En la
50
actualidad, existen versiones más recientes que ofrecen mayor seguridad y mejoras. Es por esto
que se han actualizado estas versiones utilizando XAMPP versión 1.6.8 el que cuenta con un
servidor Apache v2.2.9, MySQL v5.0.67 y uno de los cambios más significativos es que se pasó
a PHP v5.2.6.
En los anexos 1 y 2, ambas versiones fueron analizadas mediante el software Retina

Network Security Scanner para evaluar las vulnerabilidades en la seguridad que estas presentan,
Entregando los resultados de la figura 3.13.
Figura 3.13 Evaluación de seguridad informática del SLD
En los gráficos se compara la cantidad de vulnerabilidades que presenta el servidor con

las dos versiones de XAMPP señaladas.
Las vulnerabilidades o nivel de riesgo se separan en cuatro partes las cuales se describen a
continuación:
 Información: Es la información auditada en la prueba de seguridad. No necesariamente

significa un riesgo.
 Nivel de Riesgo - Bajo: una vulnerabilidad de bajo riesgo es típicamente uno que sólo
presenta una amenaza en circunstancias específicas y poco probables. una vulnerabilidad
de este tipo puede proporcionar un atacante con información que podría ser combinada
51
con otras, las vulnerabilidades de alto riesgo, con el fin de poner en peligro el host o sus
usuarios.
 Nivel de Riesgo - Medio: vulnerabilidades de riesgo medio son serias amenazas a la
seguridad que permitirían a un usuario de confianza, pero sin privilegios, asumir el
control completo de un host o permitirían a un usuario que no se confía a interrumpir el
servicio o acceder a información sensible.
 Nivel de Riesgo - Alto: Una vulnerabilidad ha sido designada como de alto riesgo si se
permitiría a un usuario que no se ha dado ninguna cantidad de confianza, convertirse en
un usuario susceptible de tomar el control del host. Otras vulnerabilidades que afectan
gravemente a la seguridad global y la facilidad de uso de la red también pueden ser
designadas como de alto riesgo.
3.7 Instalación del SLD
Para la instalación del sistema de laboratorios a distancia, se utiliza el software XAMPP,

debido a su sencillez y accesibilidad. Antes de comenzar con la instalación del servidor, es
necesario definir qué es XAMPP y sus principales características.
XAMPP es un servidor independiente de plataforma de código libre y gratuito. Este
permite instalar de forma sencilla Apache (servidor web más popular) en un computador, sin
importar el sistema operativo (Linux, Windows, MAC o Solaris). XAMPP incluye además
servidores de bases de datos como MySQL y SQLite con sus respectivos gestores phpMyAdmin
y phpSQLiteAdmin. Incorpora también el intérprete de PHP, el intérprete de Perl, servidores de
FTP como ProFTPD ó FileZilla FTP Serve.
52
Para este sistema de laboratorios a distancia, se utiliza XAMPP versión 1.6.8 el cual contiene:
 Apache v2.2.9
 MySQL v5.0.67
 PHP v5.2.6
También es necesario tener MATLAB instalado en el servidor y estaciones de trabajo,

además del toolbox webserver para lograr la ejecución de las prácticas.
El toolbox webserver de MATLAB permite crear aplicaciones de MATLAB que utilizan las
capacidades de la World Wide Web para enviar datos a MATLAB para calcular y mostrar los
resultados en un navegador Web. El servidor Web MATLAB depende de red TCP / IP para la
transmisión de datos entre el sistema cliente y MATLAB. El software de red y hardware
necesarios deben estar instalados en su sistema antes de utilizar el servidor Web de MATLAB.
A continuación se describe paso a paso las instrucciones para montar el servidor web HTTP y
base de datos para el sistema de laboratorio a distancia de la Universidad del Bío-Bío.
1.- Ejecutar xampp-win32-1.6.8-installer.exe
Elegir la ruta de instalación, por defecto es c:\xampp\ (Figura 3.13), luego dar clic en next.
Figura 3.14 Ruta de instalación XAMPP por defecto
53
2.- En la ventana siguiente (Ver Figura 3.14) marcar los check box “Install Apache as service” e
“install MySQL as service” los cuales permiten que al momento de encender el computador, se
inicie automáticamente el servidor y base de datos. Los check box que ya están marcados por
defecto no se modifican, como se muestra en la imagen. Finalmente dar clic a install.
Figura 3.15 Selección de servicios a instalar.
3.- Pegar la carpeta “www” en el directorio deseado, en este caso la carpeta se deja en la unidad
de disco local (D:) en la ruta D:\
4.- Una vez instalado ejecutar el “XAMPP Control Panel” en la ventana de panel de control de
XAMPP dar click en el botón start a en Apache y MySql como se muestra en la Figura 3.15
54
Figura 3.16 Panel de control de XXAMP.
5.- En la barra de dirección del navegador de internet (Chrome, Explorer, Mozilla Firefox, opera,
etc.) escribir “localhost” y presionar la tecla Enter, aquí aparecerá una ventana donde se
selecciona el idioma para luego mostrar la página de la figura 3.16
Figura 3.17 Menú principal XAMPP.
55
6.- En la barra de opciones lateral izquierda, dar clic en phpMyAdmin la cual nos muestra en
pantalla el administrador de base de datos (también se puede acceder escribiendo
“localhost/phpmyadmin” en la barra de dirección). En el cuadro Crear nueva base de datos
escribir “web36db2” y dar clic en Crear como se muestra en la figura 3.17
Figura 3.18 Creación de base de datos.
Aquí se crea la base de datos vacía, ahora para importar las tablas de datos dar clic en la
pestaña Importar, luego en seleccionar archivo. En este se busca la ruta donde se encuentra el
archivo webdb36db2.sql y finalmente dar clic en continuar. Ahora se encuentra la base de datos
creada con todas las tablas necesarias para el SLD.
Ahora, para evitar que cualquier usuario intervenga en la base de datos se debe asignar un
password a esta. Para ello, en la pestaña privilegios de la base de datos creada, dar clic en editar
privilegios en el usuario root del servidor localhost como se observa en la figura 3.18.
56
Figura 3.19 Edición de privilegios de usuario root.
En la nueva ventana ir al cuadro cambio de contraseña. Aquí escribir la contraseña,

luego reescribirla en el cuadro de texto de la derecha (figura 3.19) y dar clic en continuar. Ahora
la base de datos se encuentra protegida con el password asignado.
Figura 3.20 Asignación de password a la BD.
Para los siguientes cambios se recomienda descargar algún editor de texto como por ejemplo
notepad++ el cual es un software libre. Este editor posee características que facilitan la
programación como:
57
 Coloreado y envoltura de sintaxis: si se escribe en un lenguaje de programación o marcado,

Notepad++ es capaz de resaltar las expresiones propias de la sintaxis de ese lenguaje para
facilitar su lectura.
 Pestañas: al igual que en muchos navegadores, se pueden abrir varios documentos y
organizarlos en pestañas.
 Resaltado de paréntesis e indentación: cuando el usuario coloca el cursor en un paréntesis,
Notepad++ resalta éste y el paréntesis correspondiente de cierre o apertura. También funciona
con corchetes y llaves
 Numero de línea: En el borde lateral izquierdo muestra en el número de línea de cada línea
de programación.
7.- En el archivo C:\xampp\phpMyAdmin\config.inc.php ir a la línea N°19 y reemplazar

‘config’ por ‘http’, este campo permite definir un dominio de autenticación HTTP personalizado
que será mostrado al usuario en el cual deberá ingresar nombre de usuario y contraseña cuando
intente acceder a la base de datos. En la línea de código N°21 introducir dentro de las comillas el
mismo password asignado en el paso 6. El nombre de usuario se mantendrá como ‘root’ (línea
N°20). Finalmente guardar cambios.
8.- La ruta por defecto donde se dejan los archivos del servidor web HTTP a montar es
“C:\xampp\htdocs”. Por razones de orden, simplicidad y respaldo frente a posibles fallas del
sistema operativo del computador en el cual está montado el servidor, la ruta para los archivos del
servidor se cambia a “D:\www”. Para que apache reconozca la nueva ruta de los archivos, se
debe editar el archivo “C:\xampp\apache\conf\httpd.conf”. Una vez dentro del archivo, ir a la
línea 176 y reemplazar DocumentRoot "C:/xampp/htdocs" por DocumentRoot "D:/www".
Posteriormente ir a la línea 203 y reemplazar <Directory "C:/xampp/htdocs"> por
<Directory "D:/www"> y guardar cambios.
58
9.- Para permitir la comunicación entre la página web y MATLAB, se debe añadir el toolbox
webserver. Para ello, se debe ejecutar MATLAB, ir a la pestaña file dar clic a set path... y añadir
la carpeta “webserver”, luego dar clic a save.
10.- Detener y volver a iniciar Apache y MySql desde el panel de control de XAMPP.
11.- Finalmente, ejecutar activar.bat ubicado en “D:\www”, ejecutar del botón de inicio: Live
Server Configurator (ULiveSrcConfig) y Media Server Configurator (UnrealMediaServer). En
UnrealMediaServer, en el ícono “livetanks”, dar clic derecho y pinchar en “Start HLS
broadcasting”.
Ahora ya se puede acceder a la página del sistema de laboratorio a distancia desde el
servidor escribiendo “localhost” en la barra de dirección del navegador o a la base de datos
escribiendo “localhost/phpmyadmin”. Desde cualquier computador se puede acceder al sistema
mediante la dirección http://www.sldubb.ubiobio.cl/.
3.8 Puesta en marcha del SLD
Una vez instalado el SLD, cada vez que se reinicie o encienda el computador en donde se
encuentra el servidor o estación de trabajo es necesario volver a ejecutar el archivo activar.bat
ubicado en “D:\www” y ejecutar del botón de inicio: Live Server Configurator (ULiveSrcConfig)
y Media Server Configurator (UnrealMediaServer). En UnrealMediaServer, en el ícono
“livetanks”, dar clic derecho y pinchar en “Start HLS broadcasting”. Además, se sugiere verificar
que se haya iniciado Apache y MySql del panel de control de XAMPP.
3.9 Añadir prácticas al SLD
A continuación se muestran los pasos para agregar prácticas a la página web, detallando los
cambios necesarios tanto en la base de datos como en el archivo de extensión “.php”
correspondiente a la práctica.
Para una mejor comprensión de las instrucciones se ejemplificará como se añade la práctica
de control de nivel en tanque 1 de forma real con control PID.
59
Para añadir prácticas al SLD se debe seguir los siguientes pasos:
1.- En la ruta “D:\www\SLDStation\practicas” se debe agregar la carpeta correspondiente a la

práctica que se desea agregar. Dicha carpeta contiene los archivos de MATLAB de extensión
“.m” y “.mdl” además de una carpeta llamada “out” en la cual se guardan las imágenes y plantilla
en html, resultantes de la ejecución de la práctica. Para el caso del ejemplo se agrega la carpeta
llamada CT_T1_PIDFr como se muestra en la Figura 3.20
Figura 3.21 Agregar carpeta de práctica CT_T1_PIDFr al sistema.
2.- Luego desde un navegador web (Chrome, mozilla Firefox, etc.) accedemos a la base de datos
ingresando localhost/phpmyadmin en la barra de dirección. Aparecerá un cuadro en el cual se
debe ingresar el nombre de usuario y contraseña que se haya asignado en el momento de la
instalación. Luego de ingresar estos datos correctamente accederemos a la base de datos, donde
seleccionaremos web36db2 de la lista de base de datos del menú lateral izquierdo como lo
muestra la Figura 3.21
60
Figura 3.22 Ventana principal de base de datos.
3.- Dentro de esta base de datos, se muestran todas las tablas que contiene. La tabla que contiene
los datos de las prácticas que ejecuta el servido es sld_practices_data. Para ver su contenido se
debe dar clic en el botón Examinar como se muestra en la Figura 3.22
Figura 3.23 Tablas que conforman la base de datos.
4.- Ahora se muestran las prácticas que contiene el SLD, para ingresar una nueva práctica, dar
clic en la pestaña Insertar como se aprecia en la Figura 3.23
61
Figura 3.24 Contenido de tabla sld_practices_data.
5.- Luego de dar clic en Insertar, se muestra una tabla la que se debe llenar con los datos de la
práctica que se desea ingresar. A continuación en la Figura 3.24 se muestra como ejemplo los
datos ingresados para añadir la práctica “Control de nivel de un tanque con PID” simulada.
Simulada.
62
 En el campo “id” se le asigna un número de identificación a la tabla, a esta tabla se le

asigna el número 3 para seguir la secuencia ya que existía una práctica que utilizaba los
números 1 y 2 para la ejecución real y simulada respectivamente.
 El campo “sid” siempre se debe llenar con un 1.
 En el campo “pname” se debe ingresar el nombre del archivo de MATLAB a ingresar.
 En el campo “pcname” se ingresa el nombre de la práctica que aparecerá en la página
web.
 En el campo “categoría” se escribe el nombre alusivo a todas las prácticas de una estación
de trabajo. En HTML para escribir poner una tilde a una letra se debe escribir
&(letra)acute; por ejemplo para la letra “á” se debe escribir á
 En el campo “path” se ingresa la ruta de la carpeta donde se encuentran los archivos de
MATLAB de la práctica.
 En el campo “stpath” se ingresa la ruta de la carpeta que contiene los archivos de salida
(gráficos en formato jpeg y plantilla HTML) luego de ejecutar la práctica.
 El campo “purl” se deja en blanco.
 Al campo “nfiles” siempre se le asigna un cero.
 El campo “type” se escribe “Real” si se trata de una práctica de forma real o “Simulada”
para una práctica simulada.
 En el campo “visibilidad”, cuando se trata de una misma practica que se puede ejecutar de
forma real y simulada, se debe llenar este campo en una como “visible” y la otra como
“oculta” ya que si se deja las 2 visibles, aparecerá 2 veces una misma práctica.
Luego, dar clic a continuar y ya se habrá ingresado la práctica. Ahora para añadir la misma
practica pero de forma Real se debe repetir los pasos 4 y 5. Finalmente dar clic en continuar.
La tabla con los datos para la práctica real queda como se muestra en la Figura 3.25
63
Real.
Con estos pasos se logra agregar una práctica al sistema, la cual se muestra en la página
web del SLD como en la Figura 3.26, En donde se puede ver los campos “categoría” y “pcname”
ingresados en la base de datos.
Figura 3.27 Práctica agregada al SLD.
64
Para agregar textos, imágenes o botones en la página que se muestra al hacer clic en cada
práctica, se debe modificar el archivo de extensión “.php” correspondiente a la práctica en la ruta
“D:\www\user\practices”. Para el caso de ejemplo el archivo correspondiente a la práctica
Control de nivel de un tanque con PID es “m_CT_T1_PIDFr.php” ubicado en la ruta
mencionada. Para cada práctica debe existir un archivo .php que posee la estructura de la página a
mostrar. Esta estructura es muy similar para todas las prácticas, solo cambian los textos,
imágenes y botones.
En este capitulo se ha explicado de manera clara todos los aspectos del SLD instalado en la
Universidad del Bío-Bío, comenzando con una descripción de sus características generales, para
luego profundizar con las descripciones de su arquitectura, estructura de la base de datos y
estructura de funciones de MATLAB. Además, se deja el detalle completo de los pasos a seguir
para la instalación, puesta en marcha y adhesión de prácticas al SLD.
Este capitulo es fundamental para el administrador que desee agregar nuevas estaciones de
trabajo, practicas o realizar modificaciones de ellas, ya que permite entender el funcionamiento
del sistema y a la vez puede ser usado como manual para llevar a cabo dichas acciones.
65
CAPÍTULO 4. Aplicación del SLD
CAPÍTULO 4. APLICACIÓN DEL SLD
4.1 Introducción
En este capítulo se muestra cómo se utiliza la maqueta de tanques interactuantes mediante

el SLD. Para ello, primero se debe caracterizar la maqueta analizando su modelado para luego
definir algunas de las estrategias de control a aplicar sobre esta.
4.2 Sistema de tanques interactuantes de feedback
La configuración de tanques acoplados es un modelo de un fragmento de planta química.

Muy a menudo los tanques están acoplados a través de tuberías y se debe controlar el flujo y
nivel del reactivo. Los acoplamientos entre los tanques pueden ser modificados para cambiar la
dinámica del sistema que imponga el uso de diferentes controladores. La unidad de tanques
acoplados, desarrollada por Feedback [53], permite el diseño de los diferentes controladores y las
pruebas en tiempo real utilizando Matlab y Simulink. El diseño general de la maqueta se muestra
en la Figura 4.1
Figura 4.1 Maqueta tanques acoplados o interactuantes.
66
La unidad de tanques acoplados consiste en 4 tanques colocados en una plataforma. Un quinto

tanque se encuentra en la parte inferior, en el cual hay 2 bombas sumergibles que suministran el
agua a los tanques. El agua fluye libremente a los tanques de más abajo a través de los orificios
configurables. La forma en que el agua fluye se puede configurar de muchas maneras con las
válvulas manuales (MVA, MVB... MVG, MV1, MV2, MV3, MV4). La configuración de las
válvulas permite cambiar la dinámica de los acoplamientos y la generación de pasos de
perturbaciones que da amplias posibilidades de control. En la Figura 4.2 se muestra la
identificación de cada válvula, tanque y bomba de la maqueta.
Figura 4.2 Identificación de componentes de la maqueta.
67
4.3 Modelado de tanques en cascada
Cada proyecto de control comienza con el modelado de la planta, de esta manera toda la
información recopilada nos permite entender el proceso en sí. Inicialmente se considera el
modelo correspondiente a uno y dos tanques acoplados, con una constante que relaciona el flujo
de agua de entrada con respecto a la tensión de control indicada por software. Esta contante de
tiempo del circuito eléctrico (tarjeta de adquisición de datos) es significativamente más pequeña
que la constante de tiempo de los estanques, por lo tanto, los circuitos eléctricos que accionan las
bombas pueden ser tratados como una simple ganancia de amplificación en el modelo. La Figura
4.3 presenta el sistema físico de dos tanques en cascada. Para lograr esta configuración se debe
dejar abiertas las válvulas MVB, MV1 y MV2; el resto cerradas, el proceso a modelar sería el
siguiente
Figura 4.3 Modelo físico tanques en cascada.
Donde h1(t) y h2(t) son el nivel en cada tanque [cm], u(t) el voltaje aplicado a la bomba [v], η es
la constante de proporcionalidad de la misma [cm^3/min.v], A, a1 y a2 el área de la sección
transversal de los tanques y las tuberías respectivamente [cm^2] y g la aceleración de la gravedad
[cm/s^2].
68
Modelo No lineal
Generalmente, los modelos fenomenológicos no son lineales, es decir, al menos uno de

los estados (i -> corriente de control a Bomba, h-> nivel de agua) es un argumento de una función
no lineal. Con el fin de representar un modelo como una función de transferencia (una forma de
representación lineal dinámica de plantas utilizadas en ingeniería de control), es necesario
linealizar.
De acuerdo con el diagrama presentado en la Figura 4.3, las ecuaciones del modelo no
lineal son las siguientes:
Para estanque 1:
( )
( ) ( )
( )
( ) √ ( )
( )
( ) √ ( ) ( )
Para estanque 2:
( )
( ) ( )
( )
√ ( ) √ ( )
√ ( ) √ ( ) ( )
69
Las ecuaciones (1) y (2) constituyen un modelo no lineal de este sistema. En ellas k1 y k2
son las constantes de proporcionalidad entre el flujo y la raíz cuadrada de la presión que está
asociada al factor de fricción, diámetro y largo de la tubería, el tipo de fluido y la aceleración de
la gravedad:
√ √
Modelo Lineal
Para determinar la función de transferencia de este sistema es necesario linealizarlo alrededor de

un punto de operación. Igualando a cero las ecuaciones (1) y (2) y evaluando para un voltaje
constante en la bomba uo, se obtienen los puntos de operación h1o y h2o:
( ) ( )
( ) ( )
Para pequeñas variaciones alrededor del punto de operación se obtiene:
( √ ) √
( )
70
Poniendo en términos de variaciones las ecuaciones (1) y (2) y utilizando la ecuación (5) según
corresponda, se obtiene:
̇( ) () ( ) ( )
̇ ( ) ( ) ( )
Aplicando Transformada de Laplace en (6) se obtiene:
( ) ( ) ( )
( )( ) ( )
( ) ⁄
( )
( )
Aplicando Transformada de Laplace en (7) se obtiene:
( ) ( ) ( )
( )( ) ( )
( )
( )
( )
71
En bloques, este modelo queda de la siguiente forma:
Figura 4.4 Diagrama de bloques de tanques en cascada.
4.4 Identificación experimental del sistema
A continuación se muestra la respuesta temporal del sistema en lazo abierto (Figura 4.5),
ante una entrada tipo paso escalón a 3v en t=0, luego a 3.3v en t=1000s y finalmente a 2.7v en
t=2000s. Todas las mediciones se han hecho con un período de muestreo de 0.1s. A partir de
estas gráficas pueden obtenerse las ganancias estáticas K1 y K2 y las constantes de tiempo τ1 y
τ2.
Figura 4.5 Respuesta temporal del sistema en lazo abierto.

72
4.5 Control de nivel con PID
Matlab proporciona diversos métodos de análisis para los sistemas lineales en lo que se
refiere a la dinámica (herramientas como lugar geométrico de las raíces, análisis de frecuencia -
diagramas Bode, diagramas de Nyquist, identificación de polos y ceros, etc.) Con la información
que Matlab proporciona acerca de la dinámica del sistema, los controladores pueden ser
diseñados. Las siguientes secciones explican cómo funciona el controlador PID, y cómo se puede
sintonizar, para finalmente describir como se utilizan en la maqueta de tanques interactuantes.
Control de la Planta
Existen numerosos algoritmos de control, sin embargo, el control PID es el más popular
debido a su simplicidad. Un esquema general de un sistema de circuito cerrado de control simple
se presenta en la Figura 4.6.
Figura 4.6 Sistema de control simple – Lazo cerrado.
Suponiendo que la planta está representada por la función de transferencia basada en el modelo
lineal escrita como:
( )
( ) (10)
( )
Dónde: S es el operador de Laplace.
73
La idea de los algoritmos de control, es la de encontrar funciones (función de

transferencia continua, discreta, o cualquier función pudiendo ser del tipo no lineal) que cumplan
con los requisitos de; respuesta dinámica, frecuencias de amortiguación, buena respuesta a los
cambios dinámicos en relación al valor deseado, etc.
En función de los valores actuales y pasados de la señal de error (situada en la entrada de
cualquier controlador), el controlador variará la señal ( ) (situada a la salida del controlador y a
la entrada de la planta a controlar) de tal manera que la señal de salida medida o deseada
( ( )) del sistema general, equipare en gran medida a la señal de salida real ( ) en todo
momento.
Existen variados métodos de ajuste en el diseño de un controlador, todos ellos consideran
el comportamiento del sistema en lazo cerrado “closed loop system” (planta con controlador, ver
Figura 4.6) para proporcionar parámetros de acuerdo a las características asumidas por el sistema.
Con la conocida función de transferencia ( ), es posible encontrar parámetros satisfactorios
para el controlador ( ), de tal manera que el sistema en lazo cerrado herede las características
deseadas descritas por la función de transferencia ( ).
( ) ( )
( ) ( ) ( )
(11)
Controlador PID
Un controlador PID consiste en 3 bloques: Proporcional, Integral y Derivativo. La

ecuación que gobierna un controlador PID es la siguiente:
()
() ( ) ∫ ( ) (12)
() ( ) () (13)
A través de la transformada de Laplace, podemos representar la estructura anterior como

una función de trasferencia dada por:
( ) ( ) ( ) (14)
74
( )
( ) ( ) (15)
( )
Cada bloque en un controlador PID (P, I y D) juega un rol importante. Sin embargo para
algunas aplicaciones, la parte integral o derivativa tiene que ser excluida para entregar resultados
satisfactorios.
 El bloque proporcional es responsable principalmente de variar la velocidad del sistema,

sin embargo para plantas con oscilaciones provoca incrementos en éstas si el valor de la
constante P (proporcional) es seteada con un valor demasiado alto.
 La parte integral es muy importante, asegurando un error cero en estado estacionario, lo

que significa que la salida del regulador va a ser exactamente la deseada, sin embargo, la
acción integral del regulador hace que el sistema responda lento ante cambios del valor
deseado, así también para sistemas con respuestas muy rápidas, siendo para éstos casos
importante omitir esta acción en el controlador.
 La parte derivativa ha sido introducida para hacer la respuesta más rápida, sin embargo
ésta es muy sensible al ruido y puede causar una reacción muy inestable en el sistema, por
lo tanto muy a menudo es omitida en el diseño del controlador.
La reacción inestable de la parte derivativa puede ser reducida mediante el filtrado en la
señal de salida, pero también provocaría una respuesta más lenta en el controlador,
indeterminado el sentido de uso de esta acción. Un filtrado apropiado puede ayudar a
reducir ruido de alta frecuencia sin degradar la calidad del sistema de control en bandas de
baja frecuencia.
75
En el SLD se encuentra disponible la práctica “CONTROL DE NIVEL EN T1 CON

REGULADOR PID Y FILTRO” [56].
A continuación se muestra el esquema para el control de nivel de un tanque.
Figura 4.7 Esquema para el control de nivel de un tanque con regulador PID y filtro.
En esta práctica se Introducen los parámetros del regulador PID con anti-windup que se desea
ensayar así como los del filtro para la medición del nivel. La estructura implementada para el
regulador es de la forma suma de ganancias proporcional (P), integral (I) y derivativa (D) con
anti-windup tipo clamping. El filtro es un Butterworth de orden (O) y frecuencia de corte (Fc). El
control y filtrado se realizan a una frecuencia de muestreo de 10 Hz.
La secuencia experimental consiste en aplicar 5v a la bomba durante 20s con lo cual el
tanque alcanza un nivel de 12cm que es el punto de operación para 3v. A los 30s se activa el
controlador con los parámetros enviados y a los 40s la referencia (nivel deseado) pasa de 12cm a
18cm. De esta manera el sistema funciona en el mismo punto de operación identificado (ver 4.4
identificación experimental del sistema).
La opción Simular permite ver la evolución del nivel con el regulador ajustado sobre un
modelo "simulado" del sistema. La opción Real implementa el regulador ajustado sobre el
sistema real.
76
4.6 Control de nivel con otra estrategia de control
En el SLD se encuentra disponible la práctica “CONTROL DE NIVEL EN T1 CON CAMBIO

DE REGULADOR”
El esquema para el control de nivel de un tanque es el de la Figura 4.8
Figura 4.8 Esquema para control de nivel de un tanque con cambio de regulador[53].
En esta práctica se puede introducir cualquier tipo de regulador (físicamente realizable) para su
implementación sobre el sistema de tanques real. Para ello pulsar Descargar para obtener el
modelo de Simulink que, una vez modificado, se ejecutará sobre el sistema real. Los cambios que
se pueden hacer en este modelo son los siguientes:
Modificar los subsistemas "Desired water level & trigger" y "Controller" sin alterar su nombre ni
sus conexiones.
Ajustar el tiempo de ejecución del modelo que no podrá exceder de 120 segundos.
Una vez guardado el modelo subirlo a la plataforma pulsando en Examinar. Con la opción
Simular se obtendrá la evolución del nivel con el regulador implementado sobre un modelo
"simulado" del sistema de tanques. Si los resultados son aceptables pulsar Real para ver el
comportamiento del nivel real. La duración del ensayo con la opción Simular es instantánea; con
la opción Real dependerá del tiempo de ejecución ajustado en el modelo de Simulink.
77
Al no tener físicamente la maqueta cuando es utilizada remotamente, es necesario tener un

claro conocimiento de sus características, modelado y posibilidades de control disponibles. En
este capitulo se deja documentado todo lo requerido respecto a la maqueta de tanques
interactuanes y su control, lo cual también esta disponible en la pagina web del SLD.
78
Conclusiones
_____________________________________________________________________________________________
CONCLUSIONES
En este trabajo de título se realizó un análisis de las diversas arquitecturas de hardware y software
empleadas en los laboratorios remotos reportados en la literatura especializada, para llevar a cabo
el objetivo esencial consistente en implementar el software necesario para integrar la maqueta de
tanques interactuantes al sistema de laboratorios remotos de modo que se permita la realización
de prácticas de control de nivel en los tanques que posee la maqueta. Además se detalla la
implementación de los softwares necesarios, tanto en Matlab como en Simulink, para realizar
experiencias didácticas relativas al control de nivel en tanques interactuantes a través del SLD.
Se deja documentada la arquitectura del SLD implementado, la estructura de su base de
datos y estructura de las funciones utilizadas en Matlab y el procedimiento para montar el
servidor y estaciones de trabajo que conforman el SLD. También, se deja detallada las
aplicaciones del SLD donde se modela la planta a utilizar y se describen las prácticas disponibles
en el sistema.
Conclusiones
En colaboración con el Grupo de Automatización Robótica y Percepción (GARP) de la

Universidad Central “Marta Abreu” de Las Villas y el Departamento de automática, Ingeniería
electrónica e Informática Industrial de la Universidad Politécnica de Madrid. Se deja a
disposición de la Universidad del Bío-Bío un sistema de laboratorio a distancia, el cual adhiere
tecnologías actuales a la formación de los estudiantes.
Una de las características más destacables es que con el SLD será posible que la totalidad
de los alumnos utilicen y se familiaricen con el sistema y la planta a controlar lo cual antes no era
posible por el escaso tiempo de laboratorio en función de la cantidad de alumnos. La maqueta
estará disponible las 24 horas del día.
79
Para adquirir conocimiento y desarrollar habilidades como el diseño de reguladores o

ajuste de estos, identificación de sistemas, etc. Es muy útil el sistema de laboratorios a distancia,
debido a que permite visualizar y ver resultados tangibles del control que se aplica, lo cual a
veces resulta difícil de comprender de forma simulada. Además, al tener menor restricción de
tiempo, permite mejorar el aprendizaje.
El SLD no está limitado solamente a la maqueta de tanques interactuantes ni al lugar

físico, sino que se pueden agregar estaciones de trabajo y prácticas fácilmente en cualquier lugar,
utilizando los archivos correspondientes descritos en el capítulo 3.
Como medida para prevenir la intervención de personas ajenas a la administración del

sistema, se aumentó la seguridad actualizando la versión del servidor, gestor de base de datos y el
lenguaje de programación. Las versiones más recientes ofrecen cada vez mayor seguridad
mejorando defectos o vulnerabilidades de las versiones anteriores.
Trabajo a futuro
La incorporación de nuevas plantas físicas al Sistema de Laboratorios a Distancia posibilitaría,

además de mejorar las competitividades de los usuarios, ampliar su uso también a fines
investigativos.
En cuanto a la planta de tanques interactuantes se podría reemplazar las válvulas manuales por
electroválvulas on-off, para realizar prácticas de control más complejas, teniendo mayor control
sobre la variable controlada gracias a la mayor cantidad de variables manipuladas.
80
Bibliografía.
BIBLIOGRAFÍA
[1] M. J. Callaghan, J. Harkin, T. M. Mcginnity, y L. P. Maguire, "Paradigms in Remote

Experimentation," International Journal of Online Engineering (iJOE), vol. 3, 2007.
[2] L. Gomes y S. Bogosyan, "Current Trends in Remote Laboratories," Industrial Electronics,

IEEE Transactions on, vol. 56, pp. 4744-4756, 2009.
[3] C. Gravier, J. Fayolle, B. Bayard, M. Ates, y L. J., "State of the Art About Remote
Laboratories Paradigms - Foundations of Ongoing Mutations," International Journal of
Online Engineering (iJOE), vol. 4(1), pp. 19-25, 2008.
[4] J. Ma y J. V. Nickerson, "Hands-on, simulated, and remote laboratories: A comparative

literature review," ACM Comput. Surv., vol. 38, p. 7, 2006.
[5] C. Schmid, "Grid supported virtual laboratories with collaboration in engineering

education," International Journal of Online Engineering (iJOE), vol. 4, pp. 55-62, 2008.
[6] R. Costa-Castello, M. Vallés, L. M. Jiménez, L. Díaz-Guerra, A. Valera, y R. Puerto,

"Integración de dispositivos físicos en un laboratorio remoto de control mediante diferentes
plataformas: Labview, Matlab y C/C++," Revista Iberoamericana de Automática e
Informática Industrial (RIAI), vol. 7, pp. 23-34, 2010.
[7] S. Dormido. (2008) Compartiendo recursos de experimentación a través de internet : la

experiencia Automatl@bs. Revista 100cias@uned. 227-237.
[8] J. L. Guzmán, M. Domínguez, M. Berenguel, J. J. Fuertes, F. Rodríguez, y P. Reguera,

"Entorno de experimentación para la Enseñanza de Conceptos Básicos de Modelado y
Control," Revista Iberoamericana de Automática e Informática Industrial (RIAI), vol. 7, pp.
10-22, 2010.
[9] H. Vargas, J. Sánchez, C. A. Jara, F. A. Candelas, O. Reinoso, y J. L. Díez, "Docencia en

Automática: Aplicación de las TIC a la realización de actividades prácticas a través de
Internet," Revista Iberoamericana de Automática e Informática Industrial (RIAI), vol. 7, pp.
35-45, 2010.
81
Bibliografía.
[10] H. Vargas, J. Sánchez, C. A. Jara, F. Torres, S. Dormido, y F. A. Candelas, "A Network of

Automatic Control Web-Based Laboratories," IEEE Transactions on Learning
Technologies, vol. 4, pp. 197-208, 2011.
[11] GOLC web site, http://www.online-engineering.org/GOLC_about.php
[12] S. Dormido, "Control Learning: Present and Future," Annual Reviews in Control, vol. 28,
pp. 115-136, 2004.
[13] V. J. Harward, J. A. del Alamo, S. R. Lerman, P. H. Bailey, J. Carpenter, K. DeLong, C.

Felknor, J. Hardison, B. Harrison, I. Jabbour, P. D. Long, T. Mao, L. Naamani, J.
Northridge, M. Schulz, D. Talavera, C. Varadharajan, S. Wang, K. Yehia, R. Zbib, y D.
Zych, "The iLab Shared Architecture: A Web Services Infrastructure to Build Communities
of Internet Accessible Laboratories " Proceedings of the IEEE, vol. 96, pp. 931 - 950, 2008.
[14] F. Anwar, E. Lindsay, y R. Sarukkalige, "Key factors for determining the suitability of
converting a fluid-mechanics laboratory to remote-access mode," Australasian Journal of
Engineering Education, vol. 17, pp. 11-18, 2011.
[15] F. A. Candelas y J. Sánchez, "Recursos Didácticos Basados en Internet para el Apoyo a la

Enseñanza de Materias del Área de Ingeniería de Sistemas y Automática," Revista
Iberoamericana de Automática e Informática Industrial (RIAI), vol. 2, pp. 93-101, 2005.
[16] J. Garcia-Zubia, P. Orduna, D. Lopez-de-Ipina, y G. R. Alves, "Addressing Software

Impact in the Design of Remote Laboratories," Industrial Electronics, IEEE Transactions
on, vol. 56, pp. 4757-4767, 2009.
[17] D. Lopez, R. Cedazo, F. M. Sanchez, y J. M. Sebastian, "Ciclope Robot: Web-Based

System to Remote Program an Embedded Real-Time System," Industrial Electronics, IEEE
Transactions on, vol. 56, pp. 4791-4797, 2009.
[18] Mario Fernández, Ernesto Rubio, Proyecto “Macrolaboratorio de formación conjunta para
sistemas de control automático”, Proyecto FDE ING 2030, 2016.
82
Bibliografía.
[19] Ernesto Rubio, Iván Santana, Jaime Rohten, Paulina LLarena, Proyecto “Sistema de
prácticas remotas de control automático en tiempo real para la formación de estudiantes de
Ingeniería Civil en Automatización”, Proyecto interno UBB IenDU, 2016.
[20] M. Casini, D. Prattichizzo, y A. Vicino, "The automatic control telelab: a user-friendly

interface for distance learning," Education, IEEE Transactions on, vol. 46, pp. 252 - 257,
2003.
[21] M. Casini, D. Prattichizzo, y A. Vicino, "The automatic control telelab:A web-based

technology for distance learning," IEEE Control Syst. Mag., vol. 24, pp. 36-44, 2004.
[22] I. Calvo, M. Marcos, D. Orive, y I. Sarachaga, "Building complex remote learning

laboratories," Computer Applications in Engineering Education, vol. 18, pp. 53-66, 2010.
[23] N. Aliane, "Experiencia de Uso de un Laboratorio Remoto de Control," Revista

Iberoamericana de Automática e Informática Industrial (RIAI), vol. 7, pp. 85-90, 2010.
[24] R. Puerto, O. Reinoso, R. Ñeco, N. García, y L. M. Jiménez, "RECOLAB: Laboratorio

remoto de control utilizando Matlab y Simulink," Revista Iberoamericana de Automática e
Informática Industrial, vol. 2, pp. 64-72, 2005.
[25] J. S. Welsh, T. Daredia, F. Sobora, L. Vlacic, y G. C. Goodwin, "Simulated versus

Hardware Laboratories for Control Education: A Critical Appraisal," en 17th World
Congress The International Federation of Automatic Control (IFAC), Seoul, Korea, 2008.
[26] Q. Yuliang, L. Guo-Ping, Z. Geng, y H. Wenshan, "NCSLab: A Web-Based Global-Scale

Control Laboratory With Rich Interactive Features," Industrial Electronics, IEEE
[27] A. Rojko, D. Hercog, y K. Jezernik, "Power Engineering and Motion Control Web
Laboratory: Design, Implementation, and Evaluation of Mechatronics Course," Industrial
Electronics, IEEE Transactions on, vol. 57, pp. 3343-3354, 2010.
[28] F. A. Candelas, F. Torres, P. Gil, F. Ortiz, S. Puente, y J. Pomares, "Laboratorio Virtual

Remoto para robótica y evaluación de su impacto en la docencia," Revista Iberoamericana
de Automática e Informática Industrial (RIAI), vol. 1, pp. 49-57, 2004.
83
Bibliografía.
[29] F. Torres, F. A. Candelas, S. T. Puente, J. Pomares, P. Gil, y F. Ortíz, "Experiences with

Virtual Environment and Remote Laboratory for Teaching and Learning Robotics at the
University of Alicante," International Journal of Engineering Education, vol. 22, pp. 766-
776, 2006.
[30] C. A. Jara, F. A. Candela, S. T. Puente, y F. Torres, "Hands-on experiences of

undergraduate students in Automatics and Robotics using a virtual and remote laboratory,"
Computers & Education, vol. 57, pp. 2451-2461, 2011.
[31] A. Gardel, I. Bravo, J. L. Lázaro, y P. A. Revenga, "Remote Automation Laboratory Using

a Cluster of Virtual Machines," Industrial Electronics, IEEE Transactions on, vol. 57, pp.
3276-3283, 2010.
[32] I. Santana, "Administración de sistemas de laboratorios a distancia," MSc, Departamento

de Automática y Sistemas Computacionales, Universidad Central de Las Villas, Santa
Clara, 2004.
[33] Santana Ching, Iván. "Herramientas Para La Docencia En Automática Orientadas Hacia La
Metodología Ects." Universidad Politécnica de Madrid, 2012.
[34] Sartorius Castellanos, Aldo R., Luis Hernández Santana, Rafael Aracil Santonja, Ernesto
Rubio Rodríguez and Iván Santana Ching. "Virtual and Remote Laboratory for Robot
Manipulator Control Study." International Journal of Engineering Education, special issue
on Robotic in Engineering Education 22, no. 4 (2006): 10.
[35] F. Torres, F. Candelas, S. Puente, F. Ortiz, J. Pomares, P. Gil, M. Baquero, y A. Belmonte,

"Laboratorios Virtuales para el aprendizaje práctico de asignaturas de ingeniería,"
presentado en la I Jornadas de Redes de Investigación en Docencia Universitaria, Instituto
de Ciencias de la Educación, Universidad de Alicante, 2003.
[36] A. Balestrino, A. Caiti, y E. Crisostomi, "From Remote Experiments to Web-Based

Learning Objects: An Advanced Telelaboratory for Robotics and Control Systems,"
Industrial Electronics, IEEE Transactions on, vol. 56, pp. 4817-4825, 2009.
84
Bibliografía.
[37] P. Bisták, "Matlab and Java Based Virtual and Remote Laboratories for Control
Engineering," en 17th Mediterranean Conference on Control & Automation, Makedonia
Palace, Thessaloniki, Greece, 2009, pp. 1439-1444.
[38] F. M. Schaf y C. E. Pereira, "Integrating Mixed-Reality Remote Experiments into Virtual

Learning Environments Using Interchangeable Components," Industrial Electronics, IEEE
[39] R. Dormido, H. Vargas, N. Duro, J. Sanchez, S. Dormido-Canto, G. Farias, F. Esquembre,

y S. Dormido, "Development of a Web-Based Control Laboratory for Automation
Technicians: The Three-Tank System," Education, IEEE Transactions on, vol. 51, pp. 35-
44, 2008.
[40] E. Fabregas, G. Farias, S. Dormido-Canto, S. Dormido, y F. Esquembre, "Developing a

remote laboratory for engineering education," Computers & Education, vol. 57, pp. 1686-
1697, 2011.
[41] G. Farias, R. De Keyser, S. Dormido, y F. Esquembre, "Developing Networked Control

Labs: A Matlab and Easy Java Simulations Approach," Industrial Electronics, IEEE
[42] A. M. Hernandez, M. A. Maanas, y R. Costa-Castello, "Learning Respiratory System

Function in BME Studies by Means of a Virtual Laboratory: RespiLab," Education, IEEE
[43] C. A. Jara, F. A. Candelas, P. Gil, F. Torres, F. Esquembre, y S. Dormido, "EJS+EjsRL: An

interactive tool for industrial robots simulation, Computer Vision and remote operation,"
Robotics and Autonomous Systems, vol. 59, pp. 389-401, 2011.
[44] C. A. Jara, F. A. Candelas, F. Torres, S. Dormido, F. Esquembre, y O. Reinoso, "Real-time

collaboration of virtual laboratories through the Internet," Computers & Education, vol. 52,
pp. 126-140, 2009.
[45] Z. Aydogmus y O. Aydogmus, "A Web-Based Remote Access Laboratory Using SCADA,"
Education, IEEE Transactions on, vol. 52, pp. 126-132, 2009.
85
Bibliografía.
[46] M. Domínguez, P. Reguera, y J. Fuentes, "Laboratorio Remoto para la enseñanza de la

Automática en la Universidad de Leon," Revista Iberoamericana de Automática e
Informática Industrial, vol. 2(2), pp. 36-45, 2005.
[47] X. Liu, H. Liu, Z. Bao, B. Ju, y Z. Wang, "A web-based self-testing system with some
features of Web 2.0: Design and primary implementation," Computers & Education, vol.
55, pp. 265-275, 2010.
[48] C. A. Ramos-Paja, J. M. R. Scarpetta, y L. Martinez-Salamero, "Integrated Learning

Platform for Internet-Based Control-Engineering Education," Industrial Electronics, IEEE
[49] J. Santos, J. Mendonca, y J. C. Martins, "Instrumentation remote control through internet

with PHP," en Virtual Environments, Human-Computer Interfaces and Measurement
Systems, 2008. VECIMS 2008. IEEE Conference on, 2008, pp. 41-44.
[50] A. G. Vicente, Mu, x00F, I. B. oz, J. L. L. Galilea, y P. A. R. del Toro, "Remote

Automation Laboratory Using a Cluster of Virtual Machines," Industrial Electronics, IEEE
[51] R. Puerto, L. M. Jiménez, y O. Reinoso, "Remote control laboratory via Internet using
Matlab and Simulink," Computer Applications in Engineering Education, vol. 18, pp. 694–
702, 2010.
[52] J. Trevelyan, "Towards Cost Effective On-Line Laboratories," presentado en la World

Congress Networked Learning in a Global Environment, Berlin, 2002.
[53] Feedback, "Coupled tanks control experiments", 2013.
[54] D. Fensel, F. M. Facca, E. Simperl, y I. Toma, "Semantic Web Services," ed: Springer
Berlin Heidelberg, 2011, pp. 87-104.
[55] P. Bauer, V. Fedak, y O. Rompelman, "PEMCWebLab - Distance and virtual laboratories

in electrical engineering: Development and trends," en Power Electronics and Motion
Control Conference, 2008. EPE-PEMC 2008. 13th, 2008, pp. 2354-2359.
86
Bibliografía.
[56] Ernesto Rubio, Iván Santana, Vladimir Esparza, Jaime Rohten, "Remote Laboratories for
Control Education: Experience at the Universidad del Bío-Bío" IEEE ICA/ACCA, ISSN
0719-5567, VOL. 22, Pages 285-290, 2016.
87
Anexos.
ANEXOS
Anexo 1 Análisis de vulnerabilidad en servidor con XAMPP v1.6.5
Retina Network Security Scanner

Network Vulnerability Assessment & Remediation Management
30-09-2016 - Report created by version 5.25.1.3185
Executive Report
CONFIDENTIAL INFORMATION
The following report contains company confidential information. Do not distribute, email,
fax, or transfer via any electronic mechanism unless it has been approved by the recipient
company's security policy. All copies and backups of this document should be saved on
protected storage at all times. Do not share any of the information contained within this
report with anyone unless they are authorized to view the information. Violating any of the
previous instructions is grounds for termination.
88
Anexos.

Metrics for 'version 1.6.5'

File name: version 1.6.5.rtd
Audits revision: 3178
Scanner version: 5.24.2
Start time: 30-09-2016 12:43:13
Duration: 0d 0h 5m 5s
Credentials: - Null Session -
Audit groups: All Audits
Address groups: N/A
IP ranges: 192.168.2.56
Total hosts attempted: 1
Total hosts scanned: 1
No access: 0
89
Anexos.

NETWORK ANALYSIS RESULTS

Report Summary
Scanner Name Retina Machines Scanned 1
Scanner Version 5.24.2.3178 Vulnerabilities Total 150
Scan Start Date 30-09-2016 High Risk Vulnerabilities 44
Medium Risk
Scan Start Time 12:43:13 81
Vulnerabilities
Scan Duration 0h 5m 5s Low Risk Vulnerabilities 25
Scan Name version 1.6.5 Information Only Audits 34
Scan Status Completed Credential Used
Vulnerable Machines 1
Top 5 Most Vulnerable Hosts
Num. of Vulnerabilities By % of Vulnerabilities By Risk Avg. of Vulnerabilities By

Risk Risk
90
Anexos.

TOTAL VULNERABILITIES BY CATEGORY
The following is an overview of the total vulnerabilities by audit category.
Accounts AIX Local Security Audits
Anti-Virus Arch Linux Local Security Audits
Backdoors Caldera Local Security Audits
CentOS Local Security Audits CGI Scripts
Cisco Local Security Audits Cisco Local

Conectiva Local Security Audits
Security Audits
Database Debian Local Security Audits
DNS Services DoS
91
Anexos.
EnGarde Local Security Audits Fedora Local Security Audits
FreeBSD Local Security Audits FTP Servers
Gentoo Local Security Audits HPUX Local Security Audits
Immunix Local Security Audits In Configuration We Trust
IP Services IRIX Local Security Audits
Juniper Local Security Audits Local UNIX Security Audits
Mac OS X Local Security Audits Mail Servers
Mandrake Local Security Audits Miscellaneous
NetBIOS
Mobile Mobile devices, software, and
configuration.
92
Anexos.
NetBSD Local Security Audits OpenBSD Local Security Audits
P2P Networking P2P Networks can expose

computers to multiple vulnerabilities including
Oracle Linux Local Security Audits
sensitive information disclosure, denial of
service, and remote code execution
Peer-To-Peer P2P File Sharing Applications Personally Identifiable Information
Red Hat Local Security Audits Registry
Remote Access RPC Services
Scientific Linux Local Security Audits SCO Local Security Audits
Service Control Slackware Local Security Audits
SNMP Servers Solaris Local Security Audits
93
Anexos.
Spyware SSH Servers
SuSE Local Security Audits Trustix Local Security Audits
TurboLinux Local Security Audits Ubuntu Local Security Audits
User Virtualization
VMware Security Hardening Web Application
Web Servers Windows
Wireless
94
Anexos.

TOP 20 VULNERABILITIES
The following is an overview of the top 20 vulnerabilities on your network.
Rank Vulnerability Name Count

1. SSL/TLS Cipher Block Chaining Cipher Suites Supported 3
2. SSL/TLS Cipher Suites Supported 3
3. SSL Weak Cipher Suite Encryption Algorithm Key Length Supported 3
4. SSL Weak Cipher Suite Supported 3
5. SSL/TLS RC4 Cipher Suites Supported 3
6. SSL/TLS Versions Supported 3
7. Microsoft Windows User Password Not Required 2
8. OpenSSL Multiple Vulnerabilities (20090518) 2
9. OpenSSL Multiple Vulnerabilities (20120312) - Banner 2
10. OpenSSL Multiple Vulnerabilities (20160503) - Remote 2
11. PHP 4 Multiple Vulnerabilities (20100722) 2
12. PHP 4 php_sprintf_appendstring() Remote Integer Overflow 2
13. PHP 4.2 LCG Entropy Weakness 2
14. PHP 4.2 tempnam Function Security Bypass (20100225) 2
15. PHP Error Log safe_mode Bypass 2
16. PHP hash_update_file Vulnerability 2
17. PHP JPEG Exif Data Processing Denial of Service 2
18. PHP Multiple Unspecified Vulnerabilities (20090916) 2
19. PHP Multiple Vulnerabilities (200805) 2
Top 20 Vulnerabilities
95
Anexos.

TOP 20 OPEN PORTS

The following is an overview of the top 20 open ports on your network.
Rank Port Number Description Count

WWW-HTTP - World Wide Web HTTP (Hyper Text Transfer
1. TCP:80 1
Protocol)
2. TCP:135 RPC-LOCATOR - RPC (Remote Procedure Call) Location Service 1
3. TCP:139 NETBIOS-SSN - NETBIOS Session Service 1
HTTPS - HTTPS (Hyper Text Transfer Protocol Secure) - SSL
4. TCP:443 1
(Secure Socket Layer)
5. TCP:445 MICROSOFT-DS - Microsoft-DS 1
6. TCP:3306 MySQL 1
7. TCP:5119 1
8. TCP:5120 1
9. TCP:5130 1
10. TCP:5354 Multicast DNS Responder IPC 1
11. TCP:49152 1
12. TCP:49153 1
13. TCP:49154 1
14. TCP:49156 1
15. TCP:49165 1
16. TCP:49232 1
17. TCP:49339 1
18. TCP:49418 1
19. UDP:137 NETBIOS-NS - NETBIOS Name Service 1
20. UDP:138 NETBIOS-DGM - NETBIOS Datagram Service 1
Top 20 Open Ports
96
Anexos.

TOP 20 RUNNING SERVICES
The following is an overview of the top 20 running services on your network.
Rank Name Description Count

1. WPDBusEnum 15
2. lmhosts 14
3. AppIDSvc 13
4. Browser 13
5. Dnscache 13
6. TabletInputService 13
7. WebClient 13
8. wudfsvc 13
9. AudioEndpointBuilder 12
10. Audiosrv 12
11. BFE 12
12. bthserv 12
13. CscService 12
14. Dhcp 12
15. dot3svc 12
16. IKEEXT 12
17. KtmRm 12
18. LanmanWorkstation 12
19. MpsSvc 12
20. PolicyAgent 12
Top 20 Running Services
97
Anexos.

TOP 20 OPERATING SYSTEMS
The following is an overview of the top 20 operating systems on your network.
Rank Operating System Name Count

1. Windows 7, Service Pack 1 1
Top 20 Operating Systems
98
Anexos.

TOP 20 USER ACCOUNTS
The following is an overview of the top 20 user accounts on your network.
Rank Account Name Count

1. Administrador 1
2. Equipo-Servo 1
3. Invitado 1
4. IUSER_RETANON 1
5. IUSER_RETINA 1
Top 20 User Accounts
99
Anexos.

TOP 20 NETWORK SHARES
The following is an overview of the top 20 network shares on your network.
Rank Share Name Count

1. ADMIN$ 1
2. C$ 1
3. D$ 1
4. IPC$ 1
Top 20 Network Shares
100
Anexos.

BOTTOM 20 VULNERABILITIES
The following is an overview of the bottom 20 vulnerabilities on your network.

1. Account Lockout Reset Time 1
2. Account Lockout Threshold - PCI DSS/HiTrust 1
3. Microsoft Windows Decoy Administrator 1
4. Microsoft Windows Local Account Password Expiration 1
5. Minimum Password Age 1
6. Minimum Password Length 1
7. Password Does Not Expire 1
8. Password History 1
9. MySQL Database Server Detected 1
10. Microsoft Windows Operating System Older Than Newest Major Version 1
11. Web Proxy Allows Executables 1
12. WebClient (WebDAV) Service Not Disabled 1
13. ICMP Timestamp Request 1
14. SSLv2 Detected 1
15. Apple Safari Basic Auth/Child Window Vulnerabilities (Zero-Day) - Windows 1
16. Apple Safari Multiple Vulnerabilities 1
17. Google Chrome < 53.0.2785.89 Multiple Vulnerabilities - Windows 1
18. HTTP 403 Forbidden Response Detected 1
19. mDNS Service Detected - Windows 1
20. Microsoft EMET Not Installed 1
Bottom 20 Vulnerabilities
101
Anexos.

BOTTOM 20 OPEN PORTS

The following is an overview of the bottom 20 open ports on your network.

1. TCP:80 1
Protocol)
4. TCP:443 1
6. TCP:3306 MySQL 1
7. TCP:5119 1
8. TCP:5120 1
9. TCP:5130 1
11. TCP:49152 1
12. TCP:49153 1
13. TCP:49154 1
14. TCP:49156 1
15. TCP:49165 1
16. TCP:49232 1
17. TCP:49339 1
18. TCP:49418 1
Bottom 20 Open Ports
102
Anexos.

BOTTOM 20 RUNNING SERVICES
The following is an overview of the bottom 20 running services on your network.

1. eEyeUpdateSvc 8
2. FontCache3.0.0.0 8
3. MozillaMaintenance 8
4. VIAKaraokeService 8
5. wmiApSrv 8
6. AdobeARMservice 9
7. ALG 9
8. aspnet_state 9
9. eeyeevnt 9
10. eEyeUpdateSchedulerSvc 9
11. EhttpSrv 9
12. ekrn 9
13. gupdate 9
14. gupdatem 9
15. idsvc 9
16. IEEtwCollectorService 9
17. Intel(R) Capability Licensing Service Interface 9
18. jhi_service 9
19. KeyIso 9
20. LMS 9
Bottom 20 Running Services
103
Anexos.

BOTTOM 20 OPERATING SYSTEMS
The following is an overview of the bottom 20 operating systems on your network.

Bottom 20 Operating Systems
104
Anexos.

BOTTOM 20 USER ACCOUNTS
The following is an overview of the bottom 20 user accounts on your network.

1. Administrador 1
2. Equipo-Servo 1
3. Invitado 1
4. IUSER_RETANON 1
5. IUSER_RETINA 1
Bottom 20 User Accounts
105
Anexos.

BOTTOM 20 NETWORK SHARES
The following is an overview of the bottom 20 network shares on your network.

1. ADMIN$ 1
2. C$ 1
3. D$ 1
4. IPC$ 1
Bottom 20 Network Shares
106
Anexos.
Anexo 2 Análisis de vulnerabilidad en servidor con XAMPP v1.6.8

Executive Report
CONFIDENTIAL INFORMATION
The following report contains company confidential information. Do not distribute, email,
fax, or transfer via any electronic mechanism unless it has been approved by the recipient
company's security policy. All copies and backups of this document should be saved on
protected storage at all times. Do not share any of the information contained within this
report with anyone unless they are authorized to view the information. Violating any of the
previous instructions is grounds for termination.
107
Anexos.

Metrics for 'version 1.6.8'

File name: versión 1.6.8.rtd
Audits revision: 3178
Scanner version: 5.24.2
Start time: 30-09-2016 13:17:34
Duration: 0d 0h 5m 35s
Credentials: - Null Session -
Audit groups: All Audits
Address groups: N/A
IP ranges: 192.168.2.56
Total hosts attempted: 1
Total hosts scanned: 1
No access: 0
108
Anexos.

NETWORK ANALYSIS RESULTS

Report Summary
Scanner Name Retina Machines Scanned 1
Scanner Version 5.24.2.3178 Vulnerabilities Total 138
Scan Start Date 30-09-2016 High Risk Vulnerabilities 40
Medium Risk
Scan Start Time 13:17:34 73
Vulnerabilities
Scan Duration 0h 5m 35s Low Risk Vulnerabilities 25
Scan Name version 1.6.8 Information Only Audits 34
Scan Status Completed Credential Used
Vulnerable Machines 1
Top 5 Most Vulnerable Hosts
Num. of Vulnerabilities By % of Vulnerabilities By Risk Avg. of Vulnerabilities By

Risk Risk
109
Anexos.

TOTAL VULNERABILITIES BY CATEGORY
The following is an overview of the total vulnerabilities by audit category.
Accounts AIX Local Security Audits
Anti-Virus Arch Linux Local Security Audits
Backdoors Caldera Local Security Audits
CentOS Local Security Audits CGI Scripts
Cisco Local Security Audits Cisco Local

Conectiva Local Security Audits
Security Audits
Database Debian Local Security Audits
DNS Services DoS
110
Anexos.
EnGarde Local Security Audits Fedora Local Security Audits
FreeBSD Local Security Audits FTP Servers
Gentoo Local Security Audits HPUX Local Security Audits
Immunix Local Security Audits In Configuration We Trust
IP Services IRIX Local Security Audits
Juniper Local Security Audits Local UNIX Security Audits
Mac OS X Local Security Audits Mail Servers
Mandrake Local Security Audits Miscellaneous
NetBIOS
Mobile Mobile devices, software, and
configuration.
111
Anexos.
NetBSD Local Security Audits OpenBSD Local Security Audits
P2P Networking P2P Networks can expose

computers to multiple vulnerabilities including
Oracle Linux Local Security Audits
sensitive information disclosure, denial of
service, and remote code execution
Peer-To-Peer P2P File Sharing Applications Personally Identifiable Information
Red Hat Local Security Audits Registry
Remote Access RPC Services
Scientific Linux Local Security Audits SCO Local Security Audits
Service Control Slackware Local Security Audits
SNMP Servers Solaris Local Security Audits
112
Anexos.
Spyware SSH Servers
SuSE Local Security Audits Trustix Local Security Audits
TurboLinux Local Security Audits Ubuntu Local Security Audits
User Virtualization
VMware Security Hardening Web Application
Web Servers Windows
Wireless
113
Anexos.

TOP 20 VULNERABILITIES
The following is an overview of the top 20 vulnerabilities on your network.

1. SSL/TLS Cipher Block Chaining Cipher Suites Supported 3
2. SSL/TLS Cipher Suites Supported 3
3. SSL Weak Cipher Suite Encryption Algorithm Key Length Supported 3
4. SSL Weak Cipher Suite Supported 3
5. SSL/TLS RC4 Cipher Suites Supported 3
6. SSL/TLS Versions Supported 3
7. Microsoft Windows User Password Not Required 2
8. OpenSSL Multiple Vulnerabilities (20090518) 2
9. OpenSSL Multiple Vulnerabilities (20120312) - Banner 2
10. OpenSSL Multiple Vulnerabilities (20160503) - Remote 2
11. PHP 5 Multiple Vulnerabilities (20100722) 2
12. PHP 5.2 LCG Entropy Weakness 2
13. PHP 5.2 tempnam Function Security Bypass (20100225) 2
14. PHP Error Log safe_mode Bypass 2
15. PHP hash_update_file Vulnerability 2
16. PHP JPEG Exif Data Processing Denial of Service 2
17. PHP Multiple Unspecified Vulnerabilities (20090916) 2
Top 20 Vulnerabilities
114
Anexos.

TOP 20 OPEN PORTS
The following is an overview of the top 20 open ports on your network.

1. TCP:80 1
Protocol)
4. TCP:443 1
6. TCP:3306 MySQL 1
7. TCP:5120 1
9. TCP:49152 1
10. TCP:49153 1
11. TCP:49154 1
12. TCP:49156 1
13. TCP:49157 1
14. TCP:57564 1
15. TCP:57622 1
16. TCP:59387 1
Top 20 Open Ports
115
Anexos.

TOP 20 RUNNING SERVICES
The following is an overview of the top 20 running services on your network.

1. WPDBusEnum 15
2. lmhosts 14
3. AppIDSvc 13
4. Browser 13
5. Dnscache 13
6. TabletInputService 13
7. WebClient 13
8. wudfsvc 13
9. AudioEndpointBuilder 12
10. Audiosrv 12
11. BFE 12
12. bthserv 12
13. CscService 12
14. Dhcp 12
15. dot3svc 12
16. IKEEXT 12
17. KtmRm 12
18. LanmanWorkstation 12
19. MpsSvc 12
20. PolicyAgent 12
Top 20 Running Services
116
Anexos.

TOP 20 OPERATING SYSTEMS
The following is an overview of the top 20 operating systems on your network.

Top 20 Operating Systems
117
Anexos.

TOP 20 USER ACCOUNTS
The following is an overview of the top 20 user accounts on your network.

1. Administrador 1
2. Equipo-Servo 1
3. Invitado 1
4. IUSER_RETANON 1
5. IUSER_RETINA 1
Top 20 User Accounts
118
Anexos.

TOP 20 NETWORK SHARES
The following is an overview of the top 20 network shares on your network.

1. ADMIN$ 1
2. C$ 1
3. D$ 1
4. IPC$ 1
Top 20 Network Shares
119
Anexos.

BOTTOM 20 VULNERABILITIES
The following is an overview of the bottom 20 vulnerabilities on your network.

1. Account Lockout Reset Time 1
2. Account Lockout Threshold - PCI DSS/HiTrust 1
3. Microsoft Windows Decoy Administrator 1
4. Microsoft Windows Local Account Password Expiration 1
5. Minimum Password Age 1
6. Minimum Password Length 1
7. Password Does Not Expire 1
8. Password History 1
9. MySQL Database Server Detected 1
10. Microsoft Windows Operating System Older Than Newest Major Version 1
11. Web Proxy Allows Executables 1
12. WebClient (WebDAV) Service Not Disabled 1
13. ICMP Timestamp Request 1
14. SSLv2 Detected 1
15. Apple Safari Basic Auth/Child Window Vulnerabilities (Zero-Day) - Windows 1
16. Apple Safari Multiple Vulnerabilities 1
17. Google Chrome < 53.0.2785.89 Multiple Vulnerabilities - Windows 1
18. HTTP 403 Forbidden Response Detected 1
19. mDNS Service Detected - Windows 1
20. Microsoft EMET Not Installed 1
Bottom 20 Vulnerabilities
120
Anexos.

BOTTOM 20 OPEN PORTS
The following is an overview of the bottom 20 open ports on your network.

1. TCP:80 1
Protocol)
4. TCP:443 1
6. TCP:3306 MySQL 1
7. TCP:5120 1
9. TCP:49152 1
10. TCP:49153 1
11. TCP:49154 1
12. TCP:49156 1
13. TCP:49157 1
14. TCP:57564 1
15. TCP:57622 1
16. TCP:59387 1
Bottom 20 Open Ports
121
Anexos.

BOTTOM 20 RUNNING SERVICES
The following is an overview of the bottom 20 running services on your network.

1. eEyeUpdateSvc 8
2. FontCache3.0.0.0 8
3. MozillaMaintenance 8
4. VIAKaraokeService 8
5. wmiApSrv 8
6. AdobeARMservice 9
7. ALG 9
8. aspnet_state 9
9. eeyeevnt 9
10. eEyeUpdateSchedulerSvc 9
11. EhttpSrv 9
12. ekrn 9
13. gupdate 9
14. gupdatem 9
15. idsvc 9
16. IEEtwCollectorService 9
17. Intel(R) Capability Licensing Service Interface 9
18. jhi_service 9
19. KeyIso 9
20. LMS 9
Bottom 20 Running Services
122
Anexos.

BOTTOM 20 OPERATING SYSTEMS
The following is an overview of the bottom 20 operating systems on your network.

Bottom 20 Operating Systems
123
Anexos.

BOTTOM 20 USER ACCOUNTS
The following is an overview of the bottom 20 user accounts on your network.

1. Administrador 1
2. Equipo-Servo 1
3. Invitado 1
4. IUSER_RETANON 1
5. IUSER_RETINA 1
Bottom 20 User Accounts
124
Anexos.

BOTTOM 20 NETWORK SHARES
The following is an overview of the bottom 20 network shares on your network.

1. ADMIN$ 1
2. C$ 1
3. D$ 1
4. IPC$ 1
Bottom 20 Network Shares
125
Anexos.

GLOSSARY
The following is glossary of common terms used throughout this report.
 DoS Attack: A Denial of Service (DoS) attack is a remote attack against a servers
TCP/IP stack or services. DoS attacks can saturate a servers bandwidth, saturate
all available connections for a particular service, or even crash a server.
 Exploit: A script or program that takes advantage of vulnerabilities in services or
programs to allow an attacker to gain unauthorized or elevated system access.
 Host: A node on a network. Usually refers to a computer or device on a network
which both initiates and accepts network connections.
 IP Address: The 32-bit address defined by the Internet Protocol in STD 5, RFC
791. It is usually represented in dotted decimal notation. Any device connected to
the Internet that used TCP/IP is assigned an IP Address. An IP Address can be
likened to a home address in that no two are alike.
 Netbios: Network Basic Input Output System. The standard interface to networks
on IBM PC and compatible networks.
 Ping: A program used to test reachability of destination nodes by sending them an
ICMP echo request and waiting for a reply.
 Port: A port in the network sense is the pathway that a computer uses to transmit
and receive data. As an example, Web Servers typically listen for requests on port
80.
 Registry: The internal system configuration that a user can customize to alter his
computing environment on the Microsoft Windows Platform. The registry is
organized in a hierarchical structure of subtrees and their respective keys,
subkeys, and values that apply to those keys and subkeys
 Risk Level - Info: Retina may provide additional information about a host that
does not necessarily represent a security threat, but may be useful to the
administrator in order to better assess the security of the host, or the network at
large. These alerts are displayed with the list of discovered vulnerabilities, and are
indicated by a green 'I' icon.
 Risk Level - Low: A low-risk vulnerability is typically one that only presents a
threat in specific and unlikely circumstances. Such a vulnerability may provide an
126
Anexos.
attacker with information that could be combined with other, higher-risk

vulnerabilities, in order to compromise the host or its users.
 Risk Level - Medium: Medium-risk vulnerabilities are serious security threats that
would allow a trusted but non-privileged user to assume complete control of a
host, or would permit an untrusted user to disrupt service or gain access to
sensitive information.
 Risk Level - High: A vulnerability is designated as high-risk if it would allow a user
who has not been given any amount of trust on a susceptible host to take control
of it. Other vulnerabilities that severely impact the overall safety and usability of the
network may also be designated as high-risk.
 Service: A service is a program running on a remote machine that in one way or
another provides a service to users. For example, when you visit a website the
remote server displays a web page via its web server service.
 Share: A folder, set of files, or even a hard drive partition set up on a machine to
allow access to other users. Shares are frequently set up with incorrect file
permissions which could allow an attacker to gain access to this data.
 Sniffer: frequently attackers will place a sniffer program on a compromised
machine. The sole purpose of a sniffer is to collect data being transmitted on the
network in clear-text including usernames and passwords.
 Subnet: A portion of a network, which may be a physically independent network
segment, which shares a network address with other portions of the network and is
distinguished by a subnet number.
 Vulnerability: A weakness or a flaw in a program or service that can allow an
attacker to gain unauthorized or elevated system access.
127

Proyecto de Título Gabriel Rubilar PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto de Título Gabriel Rubilar PDF

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

DEPTO. INGENIERÍA ELÉCTRICA Y ELECTRÓNICA

“INTEGRACIÓN DE UNA MAQUETA DE CONTROL DE NIVEL EN

PROYECTO DE TÍTULO PARA OPTAR AL TÍTULO DE

“INTEGRACIÓN DE UNA MAQUETA DE CONTROL DE NIVEL EN TANQUES INTERACTUANTES A

DOCENTE PATROCINANTE: D. Sc. ANGEL ERNESTO RUBIO RODRÍGUEZ

El haber llegado al momento culmine de mi carrera de pregrado y este trabajo de título es el

Gabriel Rubilar Figueroa

El presente proyecto de título está orientado a la implementación de un sistema de

Tabla 3.1 Partes e implementación de la plataforma. Software utilizado [33] .............................. 29

Figura 2.1 Arquitectura del sistema ACT [20, 21]. ......................................................................... 6

Figura 3.22 Ventana principal de base de datos. ........................................................................... 61

Para implementar el software necesario se analiza las diversas arquitecturas de hardware y

Se espera como resultado entregar a la Universidad del Bío-Bío un sistema de laboratorio

1.2.1 Objetivo General

Implementar el software necesario para integrar la maqueta de tanques interactuantes a un

1.2.2 Objetivos Específicos

Analizar críticamente las diversas arquitecturas de hardware y software empleadas en los

Implementar el software necesario, tanto en Matlab como en Simulink, para realizar

Desarrollar un conjunto de experiencias didácticas relativas al control de nivel en tanques

Validar el funcionamiento del sistema integrado Maqueta-SLR.

CAPÍTULO 2. SISTEMAS DE LABORATORIOS REMOTOS

En este capítulo, se realiza un estudio detallado de una amplia muestra de sistemas de

2.2 Laboratorios virtuales y remotos aplicados a la ingeniería de control automático

Los laboratorios remotos se encuentran en evolución constante y no se restringen a una sola

2.3 Arquitecturas de hardware y software empleadas en los laboratorios remotos

A continuación se analizan las arquitecturas utilizadas en distintos laboratorios remotos aplicados

Figura 2.1 Arquitectura del sistema ACT [20, 21].

Figura 2.2 Arquitectura de referencia para la construcción de laboratorios remotos

 El sistema LABNET: Laboratorio remoto para control de procesos es un laboratorio

Figura 2.3 Arquitectura del sistema LABNET [23].

El servidor de LABNET es una aplicación que se encarga de la gestión de los usuarios, de

Figura 2.4 Cliente LABNET [23]

El entorno de LABNET ofrece la posibilidad de realizar experimentos de control en lazo

 El sistema RECOLAB: Laboratorio de Prácticas de Control de Procesos vía Internet está

en la simulación. La aplicación devuelve al usuario toda la información referente a la ejecución

Figura 2.5 Interface de usuario de RECOLAB [24]

Figura 2.6 Arquitectura de RECOLAB [24].

La comunicación cliente-servidor se realiza a través del protocolo HTTP (HyperText Transfer

 El sistema Laboratorios Virtuales para el Diseño de Sistemas de Control (Virtual

Figura 2.8 Arquitectura del NCSLab [26].

El NCSLab adoptó MATLAB como sistema de modelado y simulación por la amplia

 El Laboratorio Remoto de Mecatrónica (Remote Laboratory of Mechatronics) de la

Figura 2.9 Arquitectura del laboratorio remoto implementado en la Universidad de

 ROBOLAB: Laboratorio Virtual remoto para la enseñanza de robótica, es un laboratorio

Figura 2.10 Arquitectura del sistema RoboLab (RobUALab) [28].

 El Laboratorio de Automatización Remoto (RAL) de la Universidad de Alcalá permite el

Figura 2.11 Arquitectura del Laboratorio de Automatización Remoto (RAL) [31].

En el sistema laboratorio virtual y remoto del Departamento de Informática y Automática

 En el sistema de laboratorios a distancia Implementado en la Universidad Politécnica de

El SLD permite implementar dos tipos prácticas:

Figura 2.12 Equipos disponibles en el laboratorio de la UPM [33].

El laboratorio de automática de la UCLV tiene a disposición un motor DC y un Robot IRb-6

Figura 2.13 Equipos disponibles en el laboratorio de la UCLV.

El sistema está desarrollado en lenguaje de programación PHP ejecutado en el servidor. En el

Figura 2.14 Arquitectura del sistema SLD [33].

2.4 Partes que componen un SLD en general

2.4.1 Interfaz de usuario

El uso de aplicaciones específicas tiene como desventaja fundamental el hecho de tener

2.4.2 Gestión de las prácticas

Gestión de prácticas mediante MATLAB Web Server

Gestión de prácticas mediante LabVIEW Internet Tool-kit

LabVIEW tiene la particularidad de que se puede unir el nivel de interfaz de usuario y el