Download Software de Supervisión Remota para un Sistema de Control

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: [email protected]
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