AUTOMATAS PROGRAMABLES - LECCION 6 - PARTES BASICAS DE UN PAQUETE DE SOFTWARE BASADO EN PC

Un paquete de software para control basado en PC consta básicamente de 4 programas y una base de datos dinámica. La base de datos contiene la estrategia de control, que indica de dónde vienen los datos, qué se hace con ellos, y adónde van. La estrategia de control se realiza mediante un programa diseñado mientras que el programa permite crear las pantallas que permitirán al usuario ver datos de la base de datos. Por último, otro programa ejecuta la estrategia de control.

INTRODUCCION

Nos proponemos definir cómo será el software, en todo su conjunto, que permitirá el control de un proceso desde una PC. La principal característica del programa que ejecuta la estrategia de control es que corre en “background” (no es visible), es decir, este programa no provee interfaz al usuario. Esta función es cumplida por el cuarto programa, el de visualización, que toma las pantallas anteriormente creadas y las “conecta” a la base de datos dinámica.

 
CREANDO LA ESTRATEGIA DE CONTROL

Las estrategias se crean utilizando bloques de software que representan los distintos instrumentos utilizados en instrumentación analógica.

Por ejemplo, un lazo PID se construye utilizando un bloque de entrada analógica, un bloque PID y un bloque de salida analógica, como se muestra en la figura 1. Esta metodología es igual a la utilizada en los Sistemas de Control Distribuido. El conjunto de estos bloques, adecuadamente configurado, se denomina estrategia de control, base de datos dinámica o base de datos de control. La forma de crear la base de datos de control es característica de cada proveedor.

Según el diseñador (fabricante), son típicas dos formas de realizar el trabajo:

Llenado de planillas preconfiguradas (Fill in the blanks):
El uso de planillas Fill in the blanks fue el primer método utilizado para la creación de estrategias de control utilizando bloques de software. Este método es utilizado en Sistemas de Control Distribuido, Sistemas de control basados en PC y Sistemas Industriales abiertos. Este método consiste en disponer de una planilla por cada tipo de bloque, que debe ser completada según la estrategia a configurar. La información a completar, y la forma en que está organizada dependen del fabricante.

Generación Gráfica por íconos:
Hablando de Software, un ícono es una imagen gráfica, que representa “algo”. En el caso particular de la generación gráfica de bases de datos de control en un ambiente “iconizado”, se dispone de una pantalla en las que las distintas funciones son representadas por iconos. De este modo, la estrategia de control se construye dibujando bloques, y conectándolos gráficamente. Este método brinda una representación visual de la estrategia de control, que en general es fácil de interpretar. En la medida en que se implementan estrategias de control más complejas el dibujo puede llegar a complicarse. Por otra parte, todos los parámetros, excepto aquellos relacionados con el “softwiring” (estructura de programación), deben ser completados por medio de planillas Fill in the blanks, a las que accede seleccionando el bloque deseado con el mouse. Independientemente de la técnica utilizada, obtendremos como resultado un archivo de configuración almacenado en el disco duro (HD). Este archivo será utilizado posteriormente, para correr la estrategia de control.

 
CREANDO LAS PANTALLAS

La creación de pantallas implica en realidad crear dos cosas: una parte estática de la pantalla (denominada comúnmente “template”) y una parte dinámica, que se “conecta” a variables de la base de datos de control. A través de esta conexión, el software de visualización sabe qué variables debe presentar, en qué parte de la pantalla debe hacerlo, y cómo debe hacerlo. Según el fabricante, estas dos funciones pueden ser integradas en un único paquete, o ser dos funciones separadas, creándose primero el template, y conectándolo después. En la mayor parte de los casos, la información el template y las conexiones se almacenan en archivos separados, en el disco duro.

 
EJECUCION DE LA ESTRATEGIA DE CONTROL

La estrategia de control es ejecutada por un programa que recorre todos los bloques, efectuando los cálculos que en los mismos se indiquen. Para ello, el primer paso del programa de ejecución al ser cargado es copiar la base de datos de control del disco duro o la memoria RAM. El espacio que la base de datos ocupa en la RAM es reservado, para impedir que otros programas la desplacen. De esta forma, la copia de base de datos en la memoria RAM reflejará exactamente al archivo de la base de datos del disco duro, creada por el configurador de estrategias de control. Una vez que el programa de ejecución empiece a procesar la base de datos, empezará a haber diferencias entre los valores contenidos en la base de datos de la RAM, y los contenidos en la base de datos del disco duro. El operador empezará a cambiar el estado A/M de controladores, set points, salidas a válvulas, etc.

Debe recordarse que esta información no es actualizada automáticamente en el disco duro, por lo que al reinicializarse el procesador estos cambios se pierden. Esto significa que la estrategia de control rearrancará desde la posición indicada en el archivo del disco duro, y NO desde la última posición alcanzada.

Una vez que el programa de ejecución empezó a correr, procesará todos los bloques en forma cíclica. Los conceptos de tiempo básico de barrido, distribución de carga en fases, overrun, etc, son aplicables a la ejecución de estrategias de control en una PC.

Un aspecto que diferencia a la ejecución de estrategias de control en una PC comparada con su ejecución en procesadores dedicados al control en un DCS (sistema de control distribuido) o un OIS (sistema industrial abierto) es que la PC debe cumplir funciones que no son requeridas en los procesadores dedicados al control. Entre estas funciones podemos mencionar: el programa de visualización de variables, módulos de aplicación como el registro histórico, la generación de reportes, etc.

Por tal motivo, el análisis de la carga de procesamiento de una PC es más complejo que un DCS o un OIS, ya que la PC debe satisfacer los requerimientos de procesamiento de mayor variedad de programas.

Adicionalmente, la falla de la PC implica la pérdida de más funciones del sistema que la falla de un procesador dedicado al control en un DCS o un OIS.

 
VISUALIZACION DE LA BASE DE DATOS
El programa de visualización nos permite apreciar los resultados del trabajo efectuado por los demás programas.

Nos permite ver las pantallas creadas, para lo cual recupera del disco duro el template, y el archivo que contiene la información relativa a las conexiones a la base de datos. Inmediatamente presenta en el monitor el template, y busca en la base de datos la información indicada en el archivo de conexiones. Con esto, el operador puede ver información de la base de datos. Por supuesto, los datos requieren actualización, la que en general se hace sobre una base de tiempos fijos, dentro del ciclo básico del barrido. Por ejemplo, cada un segundo el programa de visualización busca en la base de datos indicados en el archivo de conexiones, y los presenta en la pantalla.

 
EL DRIVER DE COMUNICACIONES
El driver de comunicaciones es uno de los aspectos de un Software para Control Basado en PC más difundidos y discutidos. Los fabricantes de software disponen de drivers para establecer comunicaciones con la mayor cantidad posible de dispositivos de E/S y así ofrecer su producto a la mayor cantidad posible de usuarios de estos dispositivos.

¿Qué es un driver?
La metodología de creación de las bases de datos de control, y su procesamiento fueron detallados anteriormente. Pero el programa de ejecución de la estrategia de control no se interrelacionan con el dispositivo de E/S. Esta es la función principal del driver, que es un software cuya función es intercambiar datos entre el dispositivo de E/S y la base de datos de control que se encuentra en la memoria RAM de la PC.

Debe existir un driver por cada tipo de dispositivo de E/S.

Para ello, se debe utilizar el driver correspondiente al protocolo de comunicaciones del dispositivo de E/S.

Utilizando este protocolo, el driver interroga al dispositivo de E/S, obteniendo el valor de las variables de proceso que se requieran.

Este valor es copiado a la memoria RAM, en el bloque de la estrategia de control que corresponda.

El driver debe ser configurado, para asociar los bloques de la base de datos, y las variables del dispositivo de E/S. Esta configuración es almacenada en un archivo, que es llamado por el driver al arrancar. De acuerdo a la información configurada, el driver iniciará el proceso de comunicaciones con el dispositivo de E/S. En la mayor parte de los casos se utiliza un esquema maestro-esclavo.

Los parámetros típicos a configurar en un driver son: port de comunicaciones de la PC a utilizar, velocidad, paridad, tiempo de encuesta o polling, tiempo de time out, cantidad de reintentos (retry), e identificación de las variables del dispositivo de E/S a leer y escribir.

Estos últimos se identifican en el driver según la metodología dada por el proveedor del dispositivo de E/S.

Evidentemente, el procesamiento del driver de comunicaciones consume parte de la capacidad de procesamiento del procesador. Cada vez que es ejecutado, el driver analiza que información debe intercambiarse con el dispositivo de E/S, de acuerdo al tiempo de encuesta configurado.

Este tiempo debe ser inferior al tiempo de barrido especificado para el bloque asociado a este dato de E/S. En caso contrario, el bloque sería procesado en varios ciclos de barrido, sin que el driver haya actualizado su contenido en función del valor de la variable en el dispositivo de E/S.

Una recomendación práctica usual es que el tiempo de encuesta debe ser la mitad del tiempo de barrido del bloque. La figura 2 muestra la relación entre el tiempo de barrido y el tiempo de encuesta.

Hay que considerar que la cantidad de datos que pueden transmitirse por medio de una interfaz RS-232 es limitada. Mientras que la capacidad de procesamiento de bloques de la PC puede incrementarse cambiando de un modelo a otro (por ejemplo cambiar una PC MMX por una PC Pentium IV, que es más rápida), no es posible superar el límite de procesamiento del driver, ya que éste depende de la eficiencia del canal de comunicaciones, que es fijada por el protocolo de comunicaciones y la interfaz utilizada. Es posible que la PC tenga capacidad para procesar la cantidad de bloques requeridos por una aplicación, pero que no se pueda intercambiar con el dispositivo de E/S los datos requeridos, dentro de los plazos especificados. Esta situación
se conoce como desborde u overrun del driver de comunicaciones.

Uno de los aspectos que debemos tener en cuenta en la implementación de una aplicación, es que muchos de los drivers disponibles por parte del proveedor de software no incluyen la totalidad de las funciones previstas en el protocolo de comunicaciones. Si bien esto no genera inconvenientes en la mayor parte de las aplicaciones, puede demandar un trabajo adicional en aplicaciones especiales.

Se ha descrito la función de un driver, sin embargo, con frecuencia es deseable comunicarse con más de un dispositivo de E/S por ejemplo un PLC y varios controladores unilazo. Esto es posible ya que generalmente se puede implementar más de un driver, utilizando distintos ports de comunicaciones. La implementación específica depende de cada proveedor.

 
SISTEMA OPERATIVO Y PLATAFORMA
Dado que un objetivo de los paquetes de software para control basado en PC es utilizar el software y hardware de amplia difusión en el mercado en todo lo que sea posible, el sistema operativo más ampliamente utilizado es DOS. Sin embargo, vimos que son múltiples los paquetes de software que deben correr simultáneamente: el software de ejecución de la base de datos, el software de visualización, el software de registro histórico, utilitarios para el manejo de archivos, software para la impresión automática de reportes, etc. Dado que el DOS no ofrece posibilidad de correr varios programas simultáneamente, se debe recurrir a soluciones especiales. Una de ellas es que el fabricante incluya un shell multitarea que trabaje bajo DOS. Otra opción es el uso de programas especiales de otros proveedores, como Desqview, que tiene capacidad multitarea.

Desde hace varios años el DOS es obsoleto, existe la tendencia al uso de otros sistemas operativos o ambientes de trabajo como OS/2, Windows, Linux o Unix, etc. Que brindan en forma standard capacidad multitarea.

Muchos proveedores ofrecen sus paquetes de software para varias de estas plataformas, lo que implica el mantenimiento de diversas versiones del paquete de software. En este caso es importante para el usuario poder reportar sus aplicaciones de una plataforma a otra, sin necesidad de rehacer reingeniería. Esto incluye los templates, bases de datos, configuraciones, etc. Esta portabilidad no es característica de todos los productos.

 
Sobre un trabajo de Ing. Fernando Ventura Gutiérrez
y la coordinación de Ing. Horacio D. Vallejo
FIGURA 1
 
 
FIGURA 2
 
 
FIGURA 3
 
 
¿QUE ES UN PLC?
 
 
¿QUE PRECISA UN PLC
PARA FUNCIONAR?