New Page 1

Diseñar un sistema destinado a la simulación y control de una planta química.

El sistema consta de 3 aplicaciones independientes destinadas al diseño, +simulación y control de la planta, respectivamente. Estas tres aplicaciones se +explican a continuación:

1 - Diseño de la planta

Aplicación Windows, ya sea basada en un diálogo o SDI (Single Document +Interface), destinada al diseño de la planta en forma gráfica.

El sistema debe poder cargar y grabar el diseño de la planta en un archivo de +texto.

Parte 1 - Modelo de la planta

El programa debe permitir insertar, borrar y mover cada uno de estos +elementos.

Algunos de estos elementos de la planta tendrán atributos y estados, tal como +se detalla en la siguiente tabla:

Cada elemento del sistema deberá poder asociarse un atributo adicional que +será el nombre del objeto

A continuación se muestra el despiece de la planta en los diferentes objetos +que la componen.

Parte 2 - Sistema de control

Seleccionando alguna opción en la aplicación se debe pasar al diseño del +sistema de control de la planta.

En este modo, no se podrá modificar los objetos que componen la planta, sino +que se mostrarán y permitirá modificar los elementos que determinan el control +de la misma.

Como se mencionó anteriormente, algunos objetos pueden tener estados +asociados. El programa debe desplegar dos entradas, que permitan modificar dicho +estado (abrir/cerrar) y
+una salida que permita leer dicho estado. En el caso del tanque, sólo se tendrán +2 salidas que indicarán si el contenido del mismo es superior/inferior a un +porcentaje dado.
+
+Estas entradas y salidas deben poder conectarse utilizando un editor gráfico, y +debe permitir agregar los símbolos binarios AND y OR, el símbolo unitario +NEGADOR, un pulsador y un
+temporizador, tal como se muestra en el diagrama.

+Esta lógica debe grabarse en el archivo con la descripción de la planta en +formato texto, utilizando la nomenclatura que los alumnos prefieran.

2 - Simulación

El programa debe cargar una planta de un archivo de texto generada por la +aplicación de diseño descripta anteriormente, simular el funcionamiento de la +misma y comunicarse con el programa de control para permitir la visualización y +control de la planta.

Todos los parámetros requeridos por esta aplicación deben recibirse por línea +de comandos.

Módulo Simulación

Debe simular el funcionamiento de la planta en base al modelo que se describe +en el apéndice I

Servidor TCP/IP.

Debe implementar la comunicación con una o más aplicaciones de control de la +planta.

El protocolo utilizado para la comunicación debe ser en formato texto, y debe +basarse en la filosofía web-services, que se describe a continuación:

El cliente (aplicación de control) envía un requerimiento al servidor en +formato texto (preferentemente XML). Estos requerimientos pueden interpretarse +como llamadas a funciones, donde se pasa el nombre de la "funcion" a invocar y +sus parámetros.

3 - Aplicación de control.

Aplicación win32 similar a la descripta en el punto 1 y con similar interfaz +gráfica. El programa no debe permitir modificar la planta, sino que debe mostrar +el estado de la misma.

Esta aplicación debe mostrar el estado de todos los elementos que componen la +planta en forma gráfica, animando cada elemento para indicar los flujos de +líquido, con el color correspondiente a cada líquido.

Si la capacidad máxima de un tanque es superada, el programa debe emitir una +alerta.

El sistema deberá mostrar el contenido de los tanques con el color de los +líquidos que lo llenaron.
+

Apéndice I - Modelo de simulación

La planta puede entenderse como un grafo dirigido, donde cada objeto +representa un nodo del grafo y cada caño una arista. Si bien en un caño el +líquido puede fluir en ambas direcciones,
+simplificaremos el modelo suponiendo que el liquido fluye en una única +dirección.
+
+Los objetos de la planta pueden dividirse en 3 tipos:

1 - Fuentes. (ejemplo: bomba)
+2 - Drenajes. (ejemplo: salida)
+3 - Los restantes objetos (válvulas, bifurcaciones, uniones, etc) son +idealizados suponiendo que no almacenan líquido.

Un caso particular de dispositivo es el tanque, que constituye una fuente y +drenaje al mismo tiempo.

Para simular la planta, se analizan todos los flujos de liquido entre todas +las fuentes y drenajes.

Las bifurcaciones son simplificadas suponiendo que divide el flujo de líquido +en dos.
+Las uniones son simplificadas suponiendo que sólo aceptan el 50% del caudal +posible de cada entrada.

Si una válvula / bomba está cerrada, el programa debe considerar que dicha +parte del grafo no está presente.
+
+Ejemplo:

Tomando el diseño de la planta dado anteriormente, se lo dividirá en un +grafo, tal como se muestra a continuación:

El sistema deberá iterar n veces por segundo, determinando los caudales en +cada arista del grafo. Una vez hecho esto se actualizará los contenidos de +líquido en cada tanque en base a los caudales determinados.

Una vez hecho esto se determinará el caudal en cada arista, tal como se +muestra a continuación:

Flujo en arista 1
+Si la bomba 1 está apagada: 0
+Si la bomba 1 está encendida y la 2 apagada:
+mínimo entre:
+* caudal max. entregado por la bomba
+* caudal max. arista 1
+* caudal máx. arista 3
+Si la bomba 1 y 2 están encendidas:
+* caudal max. entregado por la bomba
+* caudal max. arista 1
+* mitad del caudal máx. arista 3.
+
+Flujo en arista 2
+Similar flujo en arista 1
+
+Flujo en arista 3
+Suma de los flujos por las aristas 1 y 2
+
+Flujo en arista 4
+Si la válvula 5 está cerrada, el flujo será 0.
+En caso contrario:
+Si la bomba 8 está apagada, el grafo se reduce y el flujo estará
+dado por el mínimo caudal entre
+* máximo caudal posible en arista 4
+* máximo caudal posible en arista 5
+* máximo caudal posible en arista 8 por dos, ya que sólo la mitad
+del caudal se irá por esta arista.
+* máximo caudal posible en arista 6 por dos, ya que sólo la mitad
+del caudal se irá por esta arista.
+* máximo caudal posible en arista 9 por dos.
+
+Si la bomba 8 está abierta, el análisis es similar solo que el
+último flujo será directamente:
+* máximo caudal posible en arista 9.
+
+Flujo en arista 5
+Será idéntico al flujo por la arista 4
+
+Flujo en arista 6
+Será la mitad del flujo en la arista 5
+
+Flujo en arista 8
+Será la mitad del flujo en la arista 5
+
+Flujo en arista 9
+Suma de los flujos en aristas 6 y 7
+
+Los restantes flujos pueden ser determinados por los alumnos.
+
+En este análisis no se tuvo en cuenta la existencia de líquido en un tanque. Si +un tanque está vacío, debe considerarse que no hay flujo de líquido (válvula +cerrada). Si un cuanto de flujo de líquido resulta ser superior al líquido +existente en un tanque, dicho caudal deberá ser limitado al caudal existente.

Una vez determinado el caudal en cada arista del grafo, el programa debe +actualizar el contenido de todos los tanques.

Tener en cuenta que cada bomba de la planta entrega líquidos de distinto tipo +(color) lo cual deberá ser tenido en cuenta al actualizar los volúmenes de cada +tanque, de tal forma que el color mostrado en el grafo sea proporcional (en +forma aproximada) a la densidad de los líquidos entrantes.

Si un tanque contiene 10 litros de líquido rojo (255,0,0) y recibe 10 litros +de líquido de verde (0,255,0), el color resultante será:

Callbacks in C++: The OO Way

by Jürgen Hermann
last updated 2001/08/02 (version +1.1.1.1)
also available as XML

What are Callbacks?

Many operating systems and other subsystems (like GUI libraries) feature a +special type of hook into those systems, named callbacks or callback functions. +Upon initialization or by calling an API function you pass pointers to the +callback into the subsystem, for later use. The problem with those functions is, +since these subsystems are nowadays not yet OO, that they have no notion of what +an object is. So if you want to have a callback object instead of +a mere function, some OO magic is called for.

As an example, consider the BeginThread API that many OSes have +in a quite similar form; we assume that it takes a pointer to the function that +provides the actual code for the newly created thread plus a data +pointer that is passed to that function as a startup parameter. Thus, +we end up with BeginThread (void (*thread_func) (void*), void* +startup_data). Now let's make a Thread class of +that.

A simple Thread class

What we want to have is an ABC (abstract base class) that you can inherit +from, creating specialized thread classes and in turn thread objects (i.e. +actual threads). The code of the thread is located in a pure +virtual function code that is provided by the inherited +class. code is then similar to the thread_func +parameter of the BeginThread call, but is a full-blown member +function, not just a C function. So, we get this interface for the +Thread class:

class Thread {
+public:
+    virtual ~Thread();
+    void run();
+
+protected:
+    Thread();
+    virtual void code() = 0;
+
+private:
+    int running;
+
+    static void dispatch(void* thread_obj);
+};
+

This might seem quite unusual to you (like having a protected constructor), +but things will be explained in due course.

Thread implementation

When we put the thread concept into a class, we have to consider lifetime. A +thread exists as long as the thread function does not return, thus the object +has to have the same lifetime. Because of this, an auto thread +object does not make much sense; we insure that every thread object exists on +the heap by making the ctor protected and providing a static factory method +create for thread objects in each derived class:

Thread::Thread() 
+    : running(0) 
+{
+}
+
+DerivedThread& DerivedThread::create()
+{
+    return *new DerivedThread;
+}
+

create has to be added to every inherited class, returning an +object of that class.

Next, we need a run method that actually starts the thread. This +can't be done in the ctor: when code would be registered as a +thread of execution in the base class ctor, the superclass would +not yet be fully created and calling code would be quite invalid +and dangerous. run does its job by registering the +dispatch function as a thread, giving that thread the object +pointer as a startup parameter; since dispatch is static, it has a +prototype that matches the void(*)(void*) parameter of +BeginThread.

void Thread::run()
+{
+    // Don't start two threads on the same object
+    if (running) return;
+
+    // Create an OS thread, using the static callback
+    BeginThread(Thread::dispatch, this);
+    running = 1;
+}
+

So finally, dispatch is called and performs the step from a +procedural callback to the callback object:

void Thread::dispatch(void* thread_obj)
+{
+    // Call the actual OO thread code
+    ((Thread*)thread_obj)->code();
+
+    // After code() returns, kill the thread object
+    delete (Thread*)thread_obj;
+}
+

A real Thread class

A real-world thread class has to consider a few things we have ignored here. +These things include:

more access to the thread data, like a method giving the thread ID. +
a method for killing the thread, including the deletion of the thread + object.

Developed and tested on Windows NT, this is the source for a little +example program that implements the above in the real world. If you run it, you +get something similar to the following output:

[\cscene\callback]callback
+Started thread #80 for dice1
+Started thread #84 for dice2
+dice1 rolled 1
+dice2 rolled 1
+dice2 rolled 3
+dice1 rolled 1
+dice2 rolled 4
+dice1 rolled 6
+dice1 rolled 3
+dice2 rolled 3
+dice1 rolled 1
+dice1 rolled 4
+dice2 rolled 4
+dice2 rolled 3
+dice1 rolled 1
+dice2 rolled 6
+dice1 rolled 2
+dice2 rolled 2
+dice1 rolled 1
+dice2 rolled 4
+dice2 rolled 1
+dice1 rolled 4
+dice1 rolled 5
+dice2 rolled 1
+dice1 rolled 3
+dice2 rolled 3
+dice1 rolled 2
+dice1 rolled 6
+dice2 rolled 2
+dice1 rolled 1
+dice2 rolled 3
+dice1 rolled 4
+dice1 rolled 5
+dice2 rolled 3
+dice2 rolled 6
+dice1 rolled 4
+

Have fun!

Elemento	Atributos	Estados
caños	caudal máximo (litros / seg.)
codos
bifurcaciones
uniones
tanque	capacidad (en litros)	cantidad de litros en el tanque (valor real)
bomba	caudal máximo (litros / seg.). Color del líquido.	encendida/apagada (valor binario)
drenaje
válvula		abierta/cerrada (valor binario)

Trabajo práctico final

Introducción