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.

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.

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.

¿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.