Download Software de Supervisión Remota para un Sistema de Control
Document related concepts
Transcript
Software de Supervisión Remota para un Sistema de Control Distribuido García A., Curto B., Moreno V., Moreno A.M. Departamento de Informática y Automática Universidad de Salamanca, España1 E-Mail: control@abedul.usal.es RESUMEN El objetivo de este trabajo es desarrollar un sistema SCADA (Supervisory Control And Data Acquisition) para la supervisión remota de diversas plantas. Está dotado de una interfaz gráfica de usuario amigable, que permite realizar las tareas asociadas a un sistema de este tipo, como la monitorización de las distintas variables de los procesos, toma de decisiones y la actuación remota sobre dichas variables. Las herramientas ya existentes en el mercado que realizan estas funciones presentan grandes limitaciones en cuanto a su carácter cerrado, la dificultad de ampliación y portabilidad a otras plataformas hardware, lo que dificulta enormemente la renovación tecnológica de las empresas. Con objeto de resolver estas limitaciones, la herramienta ha sido desarrollada bajo el sistema operativo Unix, donde están integrados los mecanismos de comunicación entre procesos en una misma máquina y una red de ordenadores. Los primeros llevan a cabo la comunicación con un sistema de control local, que ha sido desarrollado siguiendo unas especificaciones en tiempo real crítico. Los segundos se encargan de la supervisión remota desde múltiples ordenadores conectados mediante una red. En su diseño se ha seguido la arquitectura cliente-servidor, para reducir el flujo de datos a través de la red y para trabajar con una interfaz gráfica en ese sistema operativo como es X-Window. 1 Los autores agradecen la ayuda de la Junta de Castilla y León con el proyecto J0J5/97. Esto ha permitido generar una herramienta con carácter distribuido y portable a plataformas de diferentes fabricantes, así como de diferente capacidad. Además, cumple con las características de fiabilidad y robustez deseables en un entorno industrial. I. INTRODUCCION En la actualidad el uso de los ordenadores para el control automático [3] tiene una importancia fundamental en la infraestructura tecnológica de una sociedad moderna. El ordenador, que al inicio únicamente se encargaba de realizar la tarea de control automático, pasa a tomar nuevas responsabilidades dentro de la jerarquía de control. Entre estas destacan las labores de monitorización y supervisión [3] de diversos controladores locales. Con el desarrollo de las distintas tecnologías de comunicación estas tareas se pueden realizar de forma remota. Así, surgen los denominados sistemas SCADA (Supervisory Control And Data Acquisition), que son el elemento clave en un esquema de control distribuido. Las tareas asociadas a un sistema de este tipo son la adquisición de datos procedentes del controlador, su monitorización en un entorno gráfico y la dotación de utilidades que permitan la toma de decisiones y su aplicación de forma remota. La realización de estas actividades en un ordenador con un sistema operativo monotarea obliga al diseñador de la aplicación a planificar una secuencia fija e invariable de operaciones en un mismo proceso de ordenador. Esto conlleva que a la hora de modificar o incorporar elementos a alguno de sus módulos sea necesario un nuevo diseño de la aplicación completa. Con un sistema operativo multitarea se superan estas restricciones en el diseño. Cada una de las tareas se asocia a un proceso del computador y es el sistema operativo el encargado de determinar en qué momento se ejecuta cada uno de los procesos. De esta forma, las distintas tareas se ejecutan de forma concurrente, y cualquier 2 modificación sólo afectaría a un determinado proceso. Sin embargo, conforme aumenta el número de tareas y su complejidad se puede llegar a sobrecargar el computador. Para paliar este problema, y gracias a los avances en las técnicas de comunicación entre ordenadores, surge el procesamiento distribuido. Los diferentes procesos se pueden ejecutar en los diferentes nodos de la red y, así, se evitaría la sobrecarga de los nodos que componen el sistema SCADA. Este planteamiento supone la existencia de unos protocolos óptimos para la comunicación entre los distintos nodos y de unos mecanismos de comunicación entre procesos (IPCs) eficientes y robustos. Una revisión de las herramientas SCADA utilizadas en los entornos industriales presenta como resultado dos opciones claramente diferenciadas. Por una parte, los sistemas más potentes tienen un carácter fuertemente cerrado, protocolos de red propietarios y elevado coste. La introducción de mejoras y posibles ampliaciones está sujeta a una dependencia estricta con el fabricante propietario de la herramienta. Además, ésta se extiende incluso a la incorporación de terminales que, aunque sean ordenadores personales, han de realizar tareas de emulación de los terminales del fabricante. Esta situación frena cualquier renovación tecnológica de la industria debido al elevado coste que lleva asociado. Como solución alternativa aparece una segunda opción basada en la utilización de ordenadores personales trabajando bajo el sistema operativo MS-DOS / Windows. Aunque estos entornos incorporan utilidades de comunicación en red y una cierta capacidad de multiprocesamiento, sus limitaciones iniciales de diseño hacen que la potencia de la herramienta SCADA, que se ejecute en este entorno, se encuentre lejos de las especificaciones necesarias en muchas instalaciones. Entre ellas destacan la capacidad de procesamiento en tiempo real, la seguridad en el acceso, la robustez, etc. El objetivo de este trabajo era desarrollar una herramienta SCADA para la supervisión remota de diversas plantas, que disponga de la potencia y robustez de la primera opción y que trabaje en un entorno abierto y con costes razonables, tal y como se plantea en la segunda opción. Para conseguir este objetivo final como entorno 3 de desarrollo de la aplicación se ha elegido una red de ordenadores personales trabajando bajo sistema operativo UNIX. Aunque históricamente este sistema operativo se implantó en centros de investigación y universidades, ha evolucionado de forma que en la actualidad se ha extendido a entornos empresariales y de usuario. Desde su origen UNIX fue concebido con capacidad de multiprocesamiento y multiusuario, mostrando un alto grado de normalización pues es comercializado por la mayoría de los fabricantes de computadores. Gracias a su gran implantación ha ido incorporando distintos componentes de comunicación (TCP/IP) [1], interfases gráficas (XWindow) [7], mecanismos de comunicación entre procesos (semáforos, memoria compartida, pipes, ...) [4] que se han convertido en un estándar de hecho en sus respectivas áreas de aplicación. Este sistema operativo se encuentra disponible desde grandes estaciones de trabajo hasta ordenadores personales. Además las aplicaciones que se desarrollan son altamente portables entre las distintas plataformas donde UNIX se ha implantado. La herramienta SCADA se ha diseñado siguiendo el modelo cliente-servidor. Con esta arquitecura se consigue reducir el flujo de datos a través de la red y trabajar con la interfaz gráfica de este sistema operativo, como es X-Window [7]. De esta forma se podrá disponer de múltiples aplicaciones clientes ejecutándose en diferentes nodos de una red que realicen tareas de monitorización y supervisión de diferentes procesos controlados. Dichas tareas disponen de una potente interfaz gráfica con el usuario final, no están limitadas en número ni en el tipo de plataformas donde se ejecuten, no necesitan emulación y todo ello empleando ordenadores de bajo coste. De hecho, la herramienta se ha desarrollado utilizando el sistema operativo LINUX [8], que es una versión de distribución gratuita. De todas formas su implantación en otras versiones o plataformas está garantizada gracias a su diseño y normalización. El resto del artículo está organizado como se explica a continuación. En la sección II se describen brevemente los fundamentos teóricos en los que está basado el diseño de la aplicación. En la sección III se presenta una descripción global de la aplicación, diferenciando los dos módulos que la integran: el servidor de datos y el supervisor cliente. En la sección IV se presenta una visión general de la planta piloto elegida así como 4 del módulo encargado del control local de la planta, que es necesaria para comprender el funcionamiento del servidor. Con esta visión general como base, en la sección V se describe con detalle la interacción de la herramienta SCADA con el módulo de control local del proceso. También se analizan los mecanismos de comunicación entre procesos, en una misma máquina y en máquinas remotas, utilizados para atender el proceso servidor a diferentes supervisores clientes. Las aplicaciones clientes se describen en la sección VI. Para finalizar se presentarán las conclusiones más sobresalientes. II. FUNDAMENTOS TEORICOS En esta sección se describirán los conceptos principales que se han utilizado en el desarrollo de la aplicación, como son: el modelo cliente-servidor, los mecanismos de comunicación entre procesos de una o varias máquinas y el entorno X-Window. Modelo Cliente-Servidor El modelo cliente-servidor [1] [4] constituye prácticamente un estándar para el desarrollo de aplicaciones en red. Generalmente, existe un único proceso servidor que proporciona servicio a uno o varios procesos clientes que pueden estar en la misma máquina o en otra conectada a la red. En la figura 1 se representa un esquema genérico de los programas servidor y cliente. El proceso servidor crea un proceso hijo para atender cada una de las peticiones de los clientes. De esta forma se logra que el servidor continúe aceptando nuevas peticiones. Con la creación de procesos hijos surge la necesidad de una serie de mecanismos para la comunicación y la sincronización entre el padre y los hijos. Para las comunicaciones vía red se van a utilizan los “sockets” de Berkeley y para la comunicación y sincronización entre el proceso padre y los hijos se usan los mecanismos de IPC (Interprocess Communication) de Unix System V, como son semáforos, memoria compartida, colas de mensajes y tuberías. 5 Proceso padre PROCESO SERVIDOR PROCESO CLIENTE Apertura del canal de comunicación Apertura del canal de comunicación Comunicar a la red la dirección de servicio Conectar con la dirección del servidor Esperar petición de servicio Petición de servicio fork Proceso hijo Esperar respuesta Atender al cliente Fin del proceso cliente Fin del proceso hijo Figura 1. Estructura de los programas servidor y cliente Los sockets de Berkeley Existen fundamentalmente dos interfaces relevantes para programación de aplicaciones de comunicación dentro de los sistemas UNIX, los sockets de Berkeley [1] [4] y el interfaz de nivel de transporte TLI (System V Transport Layer Interface) [1] [4]. Ambos ofrecen un sistema de desarrollo de aplicaciones de comunicación accesibles al programador. En esta aplicación se han elegido los sockets de Berkeley debido a que están ampliamente aceptados y a que se han convertido en un estándar de facto. Existen múltiples sistemas que proporcionan las funcionalidades de sockets, como por ejemplo los win sock de Microsoft. 6 Un socket se puede considerar como un punto de comunicación bidireccional a través del cual un proceso puede emitir y recibir información de otro proceso residente en la misma o en diferente máquina. De esta forma un socket ofrece un mecanismo general de comunicación entre dos procesos cualesquiera independientemente de su soporte hardware. Utilizando la terminología OSI, los sockets se pueden considerar como un punto de acceso al nivel de transporte. Toda comunicación se establece entre procesos de usuarios, siendo para ello necesario identificar dichos procesos. Al existir la posibilidad de comunicación entre diferentes máquinas, éstas deben ser lógicamente identificadas. Como es necesario además identificar un protocolo, la estructura que define una comunicación a través de sockets estará formada por el protocolo, la dirección local, el proceso local, la dirección remota y el proceso remoto. Los protocolos elegidos son los de Internet (TCP/IP) [4] debido a su amplia difusión, a no depender de un determinado fabricante y por estar disponibles en los entornos UNIX. Internet ofrece dos protocolos de nivel de transporte: TCP y UDP. El primero está orientado a conexión y proporciona un servicio de transporte fiable; mientras que el segundo es un protocolo sin conexión. Debido a las necesidades que han surgido en la aplicación desarrollada se han empleado ambos protocolos. Respecto de su utilización en un programa, se podría pensar que los sockets se comportan igual que un dispositivo o un fichero en Unix. Si bien es cierto que se pueden usar operaciones como read o write con un socket, existirán algunas diferencias con estas operaciones sobre un fichero debido a las características propias de la gestión de un enlace remoto. La diferencia fundamental entre un descriptor de socket y de fichero es que en este último la disponibilidad es total mientras que en el socket, al mediar un soporte accesible por diferentes nodos y al tratar de comunicar con un proceso remoto con el que no está sincronizado, la disponibilidad no es total sino que es función de la red y del proceso remoto. 7 Los mecanismos de comunicación entre procesos Para atender las peticiones de los clientes, el proceso servidor va a crear procesos hijos que darán servicio individualmente a cada cliente. De esta forma se consigue liberar al servidor y permitir que continúe aceptando nuevas peticiones. Surge, así, la necesidad de comunicación con los procesos hijos. En la aplicación implementada se han utilizado los mecanismos de comunicación entre procesos (IPC) [4] de UNIX System V. Entre los mecanismos empleados destacan: los semáforos, que van a permitir sincronizar procesos; la memoria compartida, que va a permitir que los procesos compartan su espacio de direcciones virtuales; las colas de mensajes, que posibilitan el intercambio de datos con un formato determinado; y las tuberías o pipes que permiten implementar una cola FIFO (First In First Out). El sistema X-Window (X) La utilización de interfaces gráficas de usuarios (GUI) para la supervisión de un sistema de control proporciona una forma más clara e intuitiva de representación de los datos que las pantallas de texto, una mayor portabilidad de la aplicación y un entorno estándar para la interacción con el usuario. En UNIX el entorno natural de desarrollo de este tipo de interfaces es el sistema de ventanas X-Window [7], que fue desarrollado en el MIT (Massachusetts Institute of Tecnology). Este sistema fue diseñado para hacer transparente la existencia de la red y para ser independiente del sistema operativo. Su funcionamiento se basa en el modelo cliente-servidor. El servidor X atiende peticiones de clientes que pueden estar en la misma máquina o en otra distinta. Además, controla todos los accesos a los dispositivos de entrada (el teclado y el ratón) y a los dispositivos de salida (la pantalla), así como atiende los requerimientos de comunicación de los procesos. A la hora de programar en X el concepto más importante es el modelo de programación orientado a eventos. El servidor X captura todos los eventos que suceden en los dispositivos de entrada y salida (mover el ratón, 8 pulsar una tecla, mover una ventana, ocultar una ventana con otra, etc.) e informa al cliente. Este debe ocuparse de atender estos eventos y actuar en consecuencia. Los eventos llegan de forma asíncrona y se van almacenando en una cola de eventos hasta que el cliente los atienda explícitamente. Existen bibliotecas [5] que proporcionan los mecanismos base (funciones y estructuras) para construir una amplia variedad de conjuntos de widget, y entornos de aplicación que simplifican el diseño de aplicaciones gráficas para la interfaz con el usuario. Un widget es un objeto que proporciona una abstracción de interfaces de usuario. Un ejemplo de widget es un botón, un menú popup, un área de texto, un menú pulldown, una lista en la que se puede seleccionar un elemento, etc. III. DESCRIPCION GLOBAL DE LA APLICACION Como ya se ha comentado, el objetivo de este trabajo es desarrollar un sistema SCADA para la supervisión remota de diversas plantas . El sistema supervisor es el encargado de monitorizar el estado de la planta y permitir al usuario la actuación remota sobre algunos elementos de la planta. Ambas tareas se pueden realizar de forma distribuida desde cualquier ordenador conectado a la red. La aplicación se ha desarrollado siguiendo el modelo cliente-servidor. El servidor es el que dispone de los datos de la planta y permite efectuar operaciones remotas, como la parada del actuador, etc. Los clientes pueden solicitar al servidor los datos o la actuación remota sobre el proceso de control local, pero es el servidor el único que las realiza directamente. Los clientes disponen de una interfaz gráfica de usuario (GUI), basada en el sistema de ventanas X-Window, que permite una interacción cómoda y sencilla. 9 IV. LA PLANTA PILOTO Y SOFTWARE DE CONTROL LOCAL La planta [6] está formada por dos depósitos separados por una pared común (figura 2), en cuya parte inferior hay una serie de orificios que permiten el paso del fluido entre ambos. El actuador, una bomba que extrae el líquido de la bandeja sobre la que está colocado todo el conjunto, está conectado al primero de los tanques. En el segundo hay una válvula de accionamiento manual. Con esta configuración, se mantendrá un flujo de líquido a través de todo el sistema: de la bandeja al primer tanque mediante la bomba, de un tanque al otro a través de los orificios en la pared común, para finalmente volver a la bandeja por la válvula manual del segundo tanque. Figura 2. Esquema general del proceso de los tanques acoplados El proceso tendrá dos posibles variables de salida, las alturas del líquido en los dos depósitos, aunque solamente se controlará la altura del segundo tanque. Para medir estas alturas, el sistema dispone de dos sensores, constituido cada uno de ellos por dos cintas metálicas paralelas, colocadas verticalmente sobre una de las paredes del recipiente. Cada sensor se comporta como una resistencia eléctrica variable que, bajo corriente constante, proporciona una tensión que es función del nivel de líquido. La variable sobre la que se actúa para conseguir que la salida alcance un determinado valor de referencia es el caudal de entrada. Una bomba accionada por un motor DC permite actuar sobre la variable de entrada al sistema (que es el caudal que llega al primer depósito) mediante una señal eléctrica. Además, se dispone de una 10 tarjeta de adquisición de datos conectada a un PC y una caja para facilitar el acondicionamiento y conexión de las señales de E/S. Entre estas señales se tienen las procedentes de los dos sensores de altura y la que se envía a la bomba. El software de control local [2] consta de tres módulos claramente diferenciados. El primero se encarga de la conexión con la tarjeta de adquisición de datos para realizar las conversiones A/D y D/A necesarias. El segundo tiene como misión generar la señal de control, a partir de la referencia y de la salida, mediante un algoritmo de control que, además, debe ejecutarse de forma periódica. El tercer módulo se ocupa de la interacción del software de control local con otras aplicaciones externas. En nuestro caso la aplicación externa es el servidor de datos. V. MODULO SERVIDOR DE DATOS El proceso servidor tiene encomendadas dos tareas principales, que son: la interacción con el módulo de control local y la atención al servicio solicitado por los clientes. La primera incluye el acceso a los datos de control y la realización de actuaciones sobre los elementos de control. La segunda tarea comprende la aceptación de nuevas peticiones de servicio por parte de los clientes, el envío de los datos de control a los clientes (monitorización) y la recepción de las peticiones de actuación sobre la planta. A continuación se van a describir detalladamente cada una de estas funciones. Interacción con el módulo de control local La interacción entre el sistema de control local en tiempo real y el sistema de supervisión va a consistir en el intercambio de un conjunto de datos, tanto de entrada como de salida hacia la planta. Por una parte, el controlador va a poner los datos sobre el estado de la planta (alturas en los tanques, señal de error, ...) a disposición del servidor. No sólo pondrá los datos actuales, sino una serie de valores que el controlador [2] ha 11 ido generando de forma periódica durante un determinado intervalo de tiempo. Por otra parte, permitirá modificar ciertos parámetros que marcarán el comportamiento del controlador y realizar ciertas acciones sobre los elementos de control (parar la bomba, modificar la referencia, ...). DA0 DRIVER TARJETA ADQUIS. DATOS + AD0 ALG. CONTROL PROGRAMA SERVIDOR DE DATOS AD1 CONTROL INTERFAZ SUPERVISION Figura 3: Esquema de comunicación entre controlador y servidor. Un esquema de la interconexión entre el controlador y el servidor se muestra en la figura 3. En esta configuración se utilizan ficheros de dispositivos y sus manejadores (drivers) asociados para permitir el intercambio de información entre ambos y, así, acceder al hardware. En este caso se han construido varios ficheros de dispositivos, con un determinado número major y minor, y sus drivers [2]. En la figura 3 aparecen los asociados a los canales A/D para los tanques (AD0 y AD1) y el canal D/A para la bomba (DA0). Un elemento clave en esta interconexión es el “cambio virtual del sistema de ficheros” (VFS) [8]. Cuando se accede a un fichero de dispositivo todas las llamadas al sistema de ficheros se encaminan al correspondiente manejador de dispositivo (driver). De esta forma todos los drivers ofrecen al usuario un interfaz común a todos ellos y las llamadas son las estándares del acceso a ficheros: open, read, write, ioctl, etc. De forma concreta, si se desea conocer cómo ha evolucionado la señal de salida (altura del segundo tanque) habrá que efectuar una operación de lectura (read) sobre el fichero de dispositivo correspondiente (AD1). El sistema virtual de fichero se encarga de encaminar esta llamada al manejador correspondiente, el cual 12 proporciona la información solicitada. Si se desea actuar sobre un determinado elemento de la planta (parar la bomba) habrá que realizar una operación de escritura (write) sobre el fichero de dispositivo AD0. Esta llamada a write será encaminada por VFS al manejador correspondiente que se encargará de escribir el dato sobre la tarjeta de adquisición. Estas operaciones de monitorización y actuación las realizará el servidor a petición de los clientes. Comunicación con los clientes Una de las funciones del proceso servidor es aceptar nuevas conexiones con clientes, para lo cual tiene siempre preparado un socket TCP [1]. Cuando un nuevo cliente solicita una conexión el proceso servidor la acepta y, para atenderla, crea un proceso hijo (figura 1). Se crea entonces un nuevo socket TCP a través del cual el proceso servidor hijo enviará los datos de monitorización obtenidos por el padre al cliente. Surge, así, la necesidad de utilizar algún mecanismo de comunicación entre los procesos padre e hijo, siendo el método elegido “las tuberías o pipes”. La razón de elegir este mecanismo es que el núcleo (kernel) [4] se encarga de gestionar la tubería dotándola de un mecanismo de acceso tipo FIFO (First In First Out) y, así, el proceso hijo leerá los datos en el mismo orden en que los escriba el proceso padre. El kernel se encarga también de la sincronización entre accesos de escritura y lectura. De tal manera que las llamadas a read para sacar datos de la tubería, no van a devolver el control hasta que no haya datos escritos por el otro proceso mediante la correspondiente llamada a write. Cuando la tubería está llena, las llamadas a write quedan bloqueadas hasta que se saquen suficientes datos de la tubería como para poder escribir el bloque deseado. De esta forma, si el padre proporciona los valores de monitorización más deprisa de lo que los hijos lo pueden leer (por ejemplo, con tiempos bajos de muestreo), se garantiza que no habrá pérdida de datos. Se tienen, por tanto, tantos procesos servidores hijos como conexiones, a través de sokets TCP, con clientes se tengan establecidas y cada servidor hijo mantiene con el padre una tubería o pipe para el envío de los datos de 13 monitorización. El proceso servidor padre mantiene una lista enlazada con los datos necesarios para comunicarse con sus procesos hijos (datos de la tubería, pid del proceso, etc.). La monitorización continua hasta que el cliente decida finalizar la conexión. Cuando esto sucede el proceso servidor hijo que atendía a ese cliente debe finalizar de forma ordenada. Esto significa que tiene que: • Notificar al servidor padre que desea finalizar. • Ambos, padre e hijo, deben cerrar las estructuras compartidas que poseen. El proceso servidor padre debe ser avisado de que uno de sus hijos finaliza para que sea eliminado de la lista enlazada. Se utiliza para este fin otro de los mecanismos de IPC que es “el paso de mensajes”. Además, el pipe que ambos mantienen ha de ser cerrada de manera sincronizada, pues en caso contrario si alguno de ellos intenta acceder a una tubería cerrada por el otro extremo el programa finaliza espontáneamente. Se define, por tanto, el cierre de la tubería como “una sección crítica”. Para sincronizar el acceso a esta sección crítica se utiliza otro de los mecanismos de IPC, que son “los semáforos”. El semáforo se activa cada vez que se manda el mensaje de desconexión desde el proceso hijo y se desactiva cuando el proceso padre cierre la tubería. Cuando esto sucede el proceso hijo cierra la tubería y finaliza. Servidor Padre Servidor Hijo Envío del mensaje de cierre Semáforo Abierto Semáforo Cerrado Recepción del mensaje de cierre Cierre de la tubería Cierre de la tubería Semáforo Abierto FINAL Figura 4: Regulación de acceso a la sección crítica. 14 Otra de las tareas del servidor es recibir peticiones de actuación sobre la planta, para lo cual tiene siempre preparado en espera de peticiones un socket UDP. Aunque con el socket TCP se podría lograr la comunicación bidireccional, se ha creído conveniente utilizar otro socket UDP adicional para simplificar el proceso del servidor. Además, se ha elegido del tipo UDP porque la tarea de actuación es puntual. Ficheros de dispositivo Socket TCP Tanque 1 Tanque 2 Tanque 2 Servidor Socket UDP Bomba Cola de mensajes Figura 5: Canales de E/S del servidor Si se tiene en cuenta que las acciones descritas las realiza un único proceso servidor es necesario disponer de un mecanismo de multiplexión. En la figura 4 se muestran todos los canales de E/S que mantiene abiertos el servidor. Para gestionar el acceso a todos estos canales se utiliza la llamada a la función select. Cuando hay algún dato disponible en cualquiera de los canales el servidor realiza la tarea correspondiente a ese canal. Para explicar la base de funcionamiento de la aplicación desarrollada, en la figura 6 se presenta el pseudocódigo del programa servidor (padre/hijo), siguiendo el orden de los eventos entre el cliente y el servidor que aparecen en la gráfica 7. 15 HACER SIEMPRE SI hay petición de conexión de un cliente (1) Aceptar petición de conexión (2) Crear un proceso hijo para atender la petición (3) --------------------------------------------------------------------HACER SIEMPRE SI hay mensaje de control del monitor (10) SI mensaje == FIN_CONEXION Salir del bucle SI-NO Mandar mensaje UDP(16) con acción de control FIN-SI FIN-SI SI hay datos en la tubería (6) Leer datos Mandar datos al cliente (7) FIN-SI FIN_HACER Mandar mensaje a la cola de mensajes (11) Cerrar semáforo HACER MIENTRAS Semáforo cerrado Esperar que se abra el semáforo FIN-HACER Cerrar tubería de lectura Terminar proceso hijo ---------------------------------------------------Añadir datos proceso hijo a la lista enlazada (4) Crear tubería para comunicación de datos (5) FIN-SI SI hay mensaje UDP del cliente (16) Realizar función de control FIN-SI SI hay datos del driver Leer los datos del tanque1, tanque2 y bomba Escribir los datos en la tubería de cada hijo de la lista enlazada (6) FIN-SI SI hay mensaje en la cola de mensajes (13) Quitar proceso de la lista enlazada (14) Cerrar tubería de escritura Abrir semáforo (15) FIN-SI FIN_HACER (8) Cliente lee datos de control (9) Cliente monitoriza los datos de control (12) Cliente-hijo recibe orden de desconexión Figura 6: Pseudocódigo del programa servidor y significado de los eventos VI. MODULO SUPERVISOR En el módulo supervisor se van a realizar dos tareas: la interfaz con el usuario y la comunicación con un servidor remoto. Para la primera se ha elegido el entorno de ventanas X-Window [7] utilizando la biblioteca 16 gráfica EZwgl (EZ Widget and graphic library) [5]; mientras que para llevar a cabo la segunda se ha elegido como mecanismo de comunicación, como ya se ha comentado, los “sockets”. Al ser dos tareas bien diferenciadas, se han desarrollado dos procesos diferentes y la comunicación entre ellos se realiza mediante pipes. Uno de ellos se encarga de comunicarse con el servidor hijo remoto y de escribir los datos sobre el estado de la planta en la tubería. El otro proceso realiza lecturas de la pipe Solicitud 1de conexión Datos de control Crear proceso Hijo 16 RED 2 3 Conexión aceptada Datos tanque 1 UDP TCP Cola de mensajes 9 13 6 pipe Datos tanque 2 hijo 11 SELECT Bloque-datos Datos bomba 11 Servidor 5 7 datos control 12 Cliente Cliente hijo hijo11 8 Maquina pipe Semaf. 10 15 Servidor Servidor Lista enlazada 14 Pid hijo1 Semaf. 4 Procesos Servidores Procesos Clientes Figura 7: Esquema del orden de eventos entre cliente y servidor y se ocupa de la interacción con el usuario. Para gestionar los accesos a la tubería y evitar bloqueos se utiliza otro mecanismo de IPC que es un área de memoria compartida. Cuando el proceso encargado de la comunicación recibe datos por el socket, los coloca en la tubería y activa un flag en el área de memoria compartida. El otro proceso sólo leerá datos de la tubería cuando esta bandera esté activa. Al igual que sucede en el servidor, el cierre ha de ser ordenado para evitar el acceso a una tubería cerrada por el otro extremo. El 17 mecanismo utilizado es el mismo que en el servidor, los semáforos y el cierre de la tubería es igualmente la sección crítica. En cuanto a la interacción con el usuario el programa monitor permite: • Mostrar datos con valores numéricos, gráficos y sinópticos de la planta. • Modificar valores de referencia para el nivel de los tanques. • Parar y activar la bomba. • Modificar parámetros del controlador. En las figuras 8 y 9 se muestran las ventanas diseñadas desde las que se pueden realizar las diferentes acciones. Figura 8: Interfaz con el usuario. Monitorización. 18 Figura 9: Interfaz con el usuario para la actuación VII. CONCLUSIONES En este artículo se ha descrito un sistema SCADA para la supervisión remota de distintas plantas. En concreto, permite la monitorización del estado de la planta, la toma de decisiones y su aplicación de forma remota, con una interfaz de usuario potente y cómoda. En este artículo se ha presentado su aplicación a una planta formada por dos tanques acoplados, pero dado su diseño modular la aplicación a cualquier otra planta o controlador es inmediata. La herramienta desarrollada funciona bajo un sistema operativo abierto y multitarea, como es UNIX. Esta es una característica fundamental pues permite directamente su funcionamiento e integración en una red de ordenadores y, consecuentemente, la aplicación presenta un carácter distribuido, con todas las ventajas que de ello se derivan. Su desarrollo bajo UNIX permite disponer de una amplia variedad de aplicaciones que se han alzado como estándares en diversos campos, como programación, comunicaciones, interfaces gráficas, etc. 19 Todo ello proporciona a esta aplicación un carácter totalmente abierto y fácilmente portable. Como UNIX se encuentra disponible para ordenadores personales, no es necesario realizar una fuerte inversión para la implantación de un sistema de este tipo en una instalación industrial. Además, la interconexión de este software con otros utilizados en el proceso productivo está garantizada. Esta circunstancia en otros tiempos presentaba enormes dificultades de llevarla a la práctica resulta ahora prácticamente inmediata. VIII. BIBLIOGRAFIA [1] D. Comer, Internetworking with TCP/IP: principles, protocols and architecture, Prentice Hall International [2] E.J. Flores, Diseño y desarrollo de un sistema de control distribuido: software en tiempo real, Informe interno de la Universidad de Salamanca (Spain) [3] G. Olsson, G. Piani, Computer systems for automation and control, Prentice Hall International [4] W. R. Stevens, UNIX network programming, Prentice Hall International [5] M. Zou, EZ Widget and Graphics Library, Universidad de Austin (Texas) [6] CE5 Coupled tanks apparatus, Operator manual, TecQuipment [7] The X Window System, Programming with Xlib, Hewlett Packard [8] M.K. Johnson, The Linux kernel hacker’s Guide 20