ACCESO REMOTO A ENSAYOS DE CONTROL EN TIEMPO REAL BASADOS EN MATLAB

Transcripción

1 ACCESO REMOTO A ENSAYOS DE CONTROL EN TIEMPO REAL BASADOS EN MATLAB Rafael Palacios, Ramón Rodríguez Pecharromán ETS Ingeniería (ICAI) Universidad Pontificia Comillas Alberto Aguilera Madrid Rafael.Palacios@iit.upco.es Resumen Este artículo presenta un sistema para acceso remoto por Internet a equipos del Laboratorio de Control de la Escuela Técnica Superior de Ingeniería (ICAI), de la Universidad Pontificia Comillas de Madrid. En este se trabaja habitualmente con Matlab para realizar las prácticas presenciales y por lo tanto se ha querido mantener Matlab como herramienta para las simulaciones y los ensayos que se realizan en remoto. En algunos casos la interacción con el servidor web se puede realizar por medio de la herramienta Matlab Web Server, pero en este artículo se presenta una solución alternativa para conectar con Matlab de una manera más flexible y que permite realizar el control en tiempo real de los equipos del. El sistema está accesible en :// 1. Motivación El desarrollo del sistema que se presenta en este artículo pone al alcance de usuarios de Internet una de las prácticas que se desarrollan habitualmente en el Laboratorio de Control. La ventaja de hacer las prácticas accesibles por Internet es que permite a los alumnos realizarlas en cualquier momento y fuera del horario normal del. Además permite que otras personas que se conecten de manera remota, por ejemplo desde Universidades de otros países, tengan también acceso a las prácticas. Es importante destacar que todo el software específico (Matlab, drivers de acceso a las tarjetas de control, programas de comunicaciones) está instalado en los ordenadores de la Universidad y algunos tienen licencias que pertenecen a la Universidad. Sin embargo los alumnos no tienen necesidad de instalar ninguno de estos programas ni requieren poseer licencias ya que para el acceso sólo necesitan disponer de un navegador de Internet estándar. El acceso puede realizarse por lo tanto desde las aulas de ordenadores para alumnos, desde un cibercafé o desde dispositivos móviles como PDAs tipo Palm o Blackberry. Se contaba inicialmente con cierta experiencia en cuanto a comunicaciones por Internet e interacción con equipos físicos para realizar ciertas actuaciones. Los principales ejemplos son la aplicación para actuar desde un navegador sobre el mecanismo de apertura de puerta de un edificio [3], y un sistema para enviar órdenes y recibir variables de estado de un robot conectado a Internet mediante sistemas de poco ancho de banda [4]. Este tipo de aplicaciones siempre han resultado muy vistosas y atractivas para los alumnos y en general para cualquier usuario con cierta experiencia en Internet. El de control cuenta con varios sistemas preparados para hacer ensayos: Sistema térmico (control de temperatura de un flujo de aire) Servomecanismo de posición y velocidad Sistema hidráulico (control del nivel de un depósito de agua) Brazo robot Todos los sistemas se controlan mediante un ordenador personal en el entorno de trabajo del programa Matlab Simulink. El control en tiempo real se consigue mediante las herramientas RTW (Real Time Workshop) y RTWT (Real Time Windows Target). El uso de estas herramientas permite al alumno identificar el sistema a controlar, diseñar el control adecuado para el mismo y finalmente probar dicho control sobre el sistema real. Todo ello se realiza en el mismo entorno de trabajo, lo que permite centrar el esfuerzo en el diseño del control y no en la implementación del mismo.

2 Para el presente desarrollo se ha utilizado el servomecanismo de control de posición y velocidad (Figura 1), ya que permite realizar ensayos rápidos en los que cada prueba dura unos pocos segundos. Figura 1. Servomecanismo de posición y velocidad 2. Descripción general Este desarrollo forma parte del proyecto WLAB para desarrollo de s con acceso remoto, pensado para s con acceso Web y acceso Wireless. Existe cierta confusión en la nomenclatura de este tipo de sistemas. En [1] se incluye una clasificación de los mismos que resulta clarificadora. El diseño general de WLAB, descrito en [5], contempla varias modalidades para realizar las prácticas remotas y varios tipos de prácticas. Como modalidades se distingue entre prácticas que se realizan de manera individual (o en grupos que trabajan sobre el mismo ordenador) y prácticas en grupo que realizan por varios alumnos accediendo cada uno desde un ordenador. Como tipos de prácticas se diferencia entre simulaciones, que son puramente informáticas, y ensayos reales, que actúan sobre un sistema físico. Además se diferencia entre escenarios con modo de acceso rápido y modo de acceso lento o continuo. El modo de interacción rápido es de tipo bloqueante, es decir que la comunicación entre el interfaz de usuario y el alumno queda interrumpida durante los pocos segundos que dura el experimento. Por el contrario el modo de interacción lento no es bloqueante, y mientras se realiza el ensayo la información del interfaz se actualiza automáticamente. Resulta más complicado de implementar por la manera en que se deben presentar los resultados y porque debe permitir que el usuario modifique parámetros durante el ensayo. El tipo de sistema que se describe en este artículo, de acuerdo a la estructura general de WLAB, permite realizar prácticas de tipo individual, tanto de simulación como de ensayo, y sólo de tipo rápido. Es de destacar que los ensayos sobre el servomecanismo de control de posición y velocidad se realizan en tiempo real. La Figura 2 muestra el esquema de los equipos necesarios para la implementación. La seguridad es una de las cuestiones clave en el desarrollo de s con acceso remoto [2]. Por ello, uno de los requisitos que se ha impuesto al sistema es proporcionar un único punto de acceso desde Internet, ya que esto facilita la gestión de la seguridad. Al estar toda la red local aislada de Internet por medio de un Firewall, todos los posibles ataques externos afectan únicamente a un servidor web especialmente protegido. Además el acceso se realiza exclusivamente en protocolo, lo que evita posibles ataques por otros puertos y garantiza que sólo se requiera un navegador de Internet en el lado del cliente. Internet Figura 2. Esquema general de funcionamiento El servidor web se encarga de establecer las conexiones con los distintos ordenadores que controlan los experimentos o que corren las simulaciones (esta conexión es de tipo local). Los parámetros del ensayo se recogen en formularios html, el servidor web los envía a los ordenadores de cálculo y recoge los resultados. Por lo tanto el único requisito para el alumno es contar con un navegador que soporte html estándar, lo cual abre la posibilidad casi a cualquier dispositivo desde grandes ordenadores a PDAs. Los requisitos necesarios para realizar los experimentos nunca son inusitados porque todos los cálculos se realizan en los ordenadores de la Universidad y la mayor carga hacia el exterior es la transmisión de las gráficas de resultados, que no suponen ningún

3 problema ni siquiera para dispositivos portátiles con poco ancho de banda. 3. Prácticas de simulación En el caso de simulaciones, bastaría con que el servidor web se comunicase con una máquina para correr procesos de simulación en Matlab. Dicha máquina puede ser el propio servidor web o bien otro ordenador que se dedique exclusivamente a correr las simulaciones. Por lo tanto el esquema más habitual sería el que aparece en la Figura 3 Internet Figura 3. Prácticas de simulación Ordenador de simulaciones 3.1. Simulaciones que no requieren tiempo real Matlab proporciona una toolbox llamada Matlab WebServer que ha sido desarrollada específicamente para este tipo de aplicaciones. Se puede utilizar para correr programas Matlab implementados mediante funciones o scripts, o bien para ejecutar programas desarrollados con la herramienta Simulink. Matlab WebServer arranca un programa de comunicaciones y un proceso Matlab en el ordenador de simulaciones. Mediante un formulario web, el servidor recibe las información necesaria para lanzar una simulación, entonces pasa los parámetros al programa de comunicaciones el cual se comunica con el proceso Matlab para pasarle los parámetros y recibir los resultados, finalmente devuelve los resultados al servidor web que se los presenta al alumno. El programa Matlab que se ejecuta suele ser una función que arranca las simulaciones desarrolladas en Simulink de la siguiente manera: sim('programa_simulacion'); Es habitual tener que cambiar algunos parámetros antes de iniciar la simulación. Aunque en modo interactivo todas las variables del workspace son accesibles desde Simulink, en modo comando es necesario pasar las variables al modelo de Simulink. Por o tanto los pasos son: cargar el modelo, preparar los parámetros mediante instrucciones setparam, arrancar la simulación, y finalmente cerrar el modelo, por ejemplo: cubas_prop set_param('cubas_prop/kp','gain','kp'); sim('cubas_prop') bdclose La variable Kp del ejemplo anterior debe ser una variable global, por lo tanto si las instrucciones anteriores se ejecutan desde una función (en lugar de hacerlo desde un script de Matlab) es necesario declarar Kp como global. Existe la posibilidad de arrancar varios procesos Matlab en el ordenador de simulaciones, de manera que el sistema es capaz de correr varias simulaciones simultáneas y por lo tanto se puede atender a varios alumnos a la vez. En este caso sería necesario contar con un licencia de Matlab Web Server toolbox y de tantas de licencias de Matlab, Simulink y toolboxes de cálculo como procesos paralelos se quieran ejecutar. En el caso de simulaciones que requieran mucha potencia de cálculo, sería necesario utilizar varios servidores de Matlab, tal y como se muestra en la Figura 4. Bastaría sin embargo con único servidor web, ya que la carga que produce este tipo de aplicaciones en el servidor nunca es grande pues los cálculos no se realizan en él. Para este segundo planteamiento sería necesario contar con una licencia de Matlab WebServer para cada servidor de cálculo y licencias de Matlab, Simulink, toolboxes para cada proceso en marcha, sumando los procesos Matlab de todos los servidores de cálculo.

4 implementar un timer que se arranca transcurrido un cierto tiempo. Un ejemplo de la función timer_fin se presenta a continuación: Ordenador de simulación Ordenador de simulación Figura 4. Simulaciones con alta carga computacional 3.2. Simulaciones en tiempo real Matlab WebServer no soporta la ejecución de simulaciones en tiempo real basadas en Simulink, ya que no admite la ejecución en modo externo. En la literatura se presentan diversas soluciones a este problema. En [6] se opta por completar el MWS con rutinas propias desarrolladas para acceder al hardware en tiempo real, o bien por salir del entorno Matlab y utilizar otras herramientas como WinCon. En este artículo se propone otra manera de realizar simulaciones y ensayos en tiempo real. Es posible lanzar procesos de Simulink que requieren tiempo real desde la línea de comandos sin necesidad de arrancar el entorno gráfico. Tras cargar los parámetros de la simulación en variables, la simulación en tiempo real servo_lab se lanza mediante los siguientes comandos que arrancan una simulación y luego preparan un timer para cerrar el proceso: servo_lab set_param('servo_lab','simulationcommand','connect') set_param('servo_lab','simulationcommand','start') %Timer para cierre t3=timer('executionmode','fixedrate','startdelay',10,'timerfcn','timer_fin','period',1,'taskstoexecute', 1); start(t3) Dado que la simulación se ejecuta en paralelo con el proceso principal de Matlab, el control vuelve a la función principal que debe esperar a que termine la simulación. No se ha encontrado ningún método de detectar el final de la simulación ni son válidas las funciones sleep/pause porque interfieren con el proceso en tiempo real. Por esta razón se ha optado por function timer_fin load data_0 plot(ref(:,1),[ref(:,2) vel(:,2)]) print -djpeg result bdclose quit El tiempo que se fija al definir el timer debe estar calculado de tal manera que lo active cuando la simulación haya terminado. Cuando la función timer se activa se crean las gráficas de resultados, se cierra el proceso de Simulink y luego se cierra todo el entorno Matlab para devolver el control al servidor web. Recogiendo los comandos anteriores en una función que reciba los parámetros de la simulación como argumentos, es posible arrancar Matlab desde la línea de comandos mediante la siguiente llamada tipo unix: matlab r 'global Kp; servo(0.01)' Existe la posibilidad de modificar esta llamada con las opciones nodisplay, -nodesktop, y jvm para controlar si se quiere que aparezcan o no las ventanas de Matlab en la pantalla del ordenador de simulación. Sin poner ninguna de estas opciones se puede comprobar (estando en el ) que el ordenador de simulación está recibiendo las llamadas del servidor web y está generando correctamente las gráficas. Las simulaciones en tiempo real tienen sentido en aplicaciones de entrenadores de operadores de planta, por ejemplo, pero no son un objetivo prioritario en este desarrollo. Sin embargo, esta manera de llamar a Matlab es la que se ha aplicado también para realizar los ensayos en tiempo real, como se describe más adelante. Por otro lado es interesante comentar que también se puede aplicar este método de correr procesos de Matlab para realizar simulaciones que no requieran tiempo real, habiéndose desarrollado una alternativa a la toolbox de WebServer. Esta alternativa está formada por un programa PHP que recibe los parámetros de la simulación de un formulario HTML y realiza una llamada externa a Matlab quedando a la espera de que concluya la ejecución (llamada tipo exec). Si las simulaciones corren en el mismo servidor web, entonces basta ejecutar el comando Matlab desde PHP, y si se desea que las simulaciones corran en otros

5 ordenadores, entonces hay que llamar a Matlab por medio de rsh (remote shell) o la versión segura para ejecución remota ssh (secure shell). Con este sistema es necesario disponer de tantas licencias de Matlab como procesos paralelos ocurran en la realidad, sin embargo no es necesario disponer de licencias de Matlab WebServer. Una diferencia importante con respecto a WebServer, es que cada simulación requiere un tiempo mayor puesto que Matlab debe arrancar desde cero para correr cada simulación, mientras que en el sistema WebServer el proceso Matlab siempre está arrancado a la espera de recibir trabajos. Esto se traduce en mayores tiempos de espera para los usuarios. Por otro lado si se lanzan más simulaciones simultáneas que licencias, en WebServer el interfaz de usuario se queda bloqueado a la espera de que quede libre un proceso Matlab para correr la simulación, mientras que en el método de llamada por comando se obtiene un error de falta de licencia y el control vuelve inmediatamente. 4. Prácticas de ensayos en equipos reales El objetivo fundamental del sistema desarrollado ha sido permitir que los alumnos de la Universidad realicen sus prácticas de por Internet, como si se encontrasen físicamente en el. Para realizar la primera aplicación práctica se ha elegido el servomecanismo de control de posición y velocidad cuya imagen aparece en la Figura 1. Este equipo tiene la ventaja de que tiene una respuesta muy rápida y por lo tanto cada vez que se realiza una modificación de los parámetros se puede solicitar un nuevo ensayo que dura pocos segundos. Por lo tanto es un buen ejemplo de la aplicación de ensayos rápidos contemplada en la estructura general de WLAB y se puede implementar haciendo que el interfaz de usuario no se repinte entre la orden de inicio de ensayo y la obtención de los resultados finales. El esquema general del control que se utiliza para esta práctica aparece en la Figura 5 Figura 5. Esquema del control en tiempo real Los comandos para ejecutar procesos en tiempo real que actúan directamente sobre el hardware son los mismos que los presentados para realizar simulaciones en tiempo real. La diferencia principal es que en este caso sí es necesario realizar la llamada a Matlab por medio de los comandos rsh ó ssh ya que sólo tiene sentido correr el proceso en el ordenador conectado físicamente con el equipo de ensayos del. Por lo tanto el esquema de funcionamiento es similar al que aparece en al Figura 4, salvo que los ordenadores que corren Matlab contienen los drivers de acceso a las tarjetas de adquisición de datos, el kernel de tiempo real y están conectados físicamente a los equipos del (Figura 6). Figura 6. Prácticas de ensayos reales La página que gestiona las peticiones de ensayos y que se ejecuta en el servidor web debe tener en cuenta varias consideraciones. En primer lugar puede no ser válido cualquier ordenador del para realizar el ensayo, ya que es necesario enviar la tarea al ordenador conectado con el equipo concreto que se quiere ensayar. En el caso de correr simulaciones existe más flexibilidad en la asignación de tareas aunque también se suele asignar cada tipo de tarea a un ordenador concreto. En segundo lugar hay que tener en cuenta que los ordenadores personales sólo pueden correr un proceso en tiempo real cada vez, especialmente en el caso de ensayos reales. Para evitar problemas lo más sencillo es restringir

6 a un ensayo de tiempo real por equipo, lo cual se controla fácilmente mediante variables de sesión que se registran en una base de datos. En tercer lugar es necesario que la página web que trata los datos del formulario se asegure de lanzar un proceso de Matlab con parámetros válidos y que dicho proceso no puede fallar, ya que de lo contrario el sistema se quedaría bloqueado esperando la respuesta y se podría llenar la pila de procesos. Adicionalmente es recomendable en el caso de los ensayos reales poner protecciones tipo hardware pare evitar que los equipos puedan sufrir o causar deterioros. Hay que tener en cuenta que en las prácticas presenciales es fácil detectar si un equipo está funcionando fuera de la normalidad por percepción visual o acústica directa, sin embargo en el caso de ensayos remotos hay que extremar la seguridad. Es conveniente, también, incorporar al sistema la transmisión de audio y video para que el usuario alcance una mayor sensación de contacto físico con el equipo real. 5. Conclusiones Se ha desarrollado un sistema para acceso remoto por Internet a equipos del Laboratorio de Control de la Escuela Técnica Superior de Ingeniería (ICAI), de la Universidad Pontificia Comillas de Madrid. Los equipos del Laboratorio funcionan en el entorno de trabajo del programa Matlab-Simulink. Este desarrollo es parte del sistema WLAB de s con acceso remoto, que contempla diferentes situaciones: simulaciones y ensayos, trabajo individual y en grupo, etc. Este artículo se centra en el caso de simulaciones y de ensayos con equipos reales, del tipo que denominamos rápido Matlab proporciona una toolbox llamada Matlab WebServer que ha sido desarrollada específicamente para este tipo de aplicaciones. En el artículo se presenta otra forma de enlace entre el servidor web y los ordenadores que ejecutan las simulaciones o ensayos. En el caso de simulaciones, es una alternativa con ventajas e inconvenientes. Sin embargo, en el caso de ensayos con equipos reales es imprescindible, ya que el control en tiempo real de equipos externos mediante Simulink no está soportado por el Matlab WebServer. Actualmente se está desarrollando el modo de funcionamiento lento, que debido a la duración del ensayo no permite dejar el interfaz web bloqueado hasta obtener los resultados finales, como se ha hecho ahora. El sistema que se está desarrollando para ensayos lentos muestra gráficas del estado del sistema que se refrescan automáticamente y permite cambian los parámetros del control durante el ensayo. Este enfoque es el más apropiado para algunas prácticas como por ejemplo el control de nivel del depósito de agua. Referencias [1] Dormido Bencomo, S. "Control learning: present and future", 2002 IFAC, 15th Triennial World Congress, Barcelona, Spain [2] Ko, C.C., Chen, B.M. Chen J., Creating Web-based Laboratories. Springer, 2004 [3] Palacios, R. "Remote Automatic Doorman via the Internet", Communications of the ACM, Vol 45. Nº 10, pp October [4] Palacios, R. Sánchez, A. " Sistema para el control remoto de un robot mediante un navegador de Internet", Anales de Mecánica y Electricidad. Vol. LXXVIII, Mayo-Junio pp [5] Rodríguez Pecharromán, R., Palacios, R. "Laboratorio para Acceso Remoto por Internet: WLAB", I Jornadas: Laboratorios Virtuales y Remotos diciembre de 2003, Madrid. [6] Valera, A., Díez, J.L., Vallés, M. y Albertos, P. (2005) Virtual and Remote Control Laboratory Development, IEEE Control Systems, vol. 25, no. 1, pp