Scad A

ANLISIS DE LA METODOLOGA DE IMPLANTACIN DE UN SISTEMA DISTRIBUIDO DE MONITORIZACIN, SUPERVISIN Y ADQUISICIN DE DATOS DE UNA PLANTA SOLAR DE CONCENTRACIN MEDIANTE UN SISTEMA
SCADA EN LA TECNOLOGA INDUSTRIAL
Autor: Juan Carlos Ramrez Fernndez
ANLISIS DE LA METODOLOGA DE IMPLANTACIN DE UN SCADA DE UNA PLANTA SOLAR DE CONCENTRACIN MEDIANTE UN SISTEMA SCADA EN LA TECNOLOGA INDUSTRIAL
INDICE
1. INTRODUCCIN ...................................................................................................................... 3 2. SISTEMA SCADA..................................................................................................................... 5 3. LABVIEW .................................................................................................................................. 8 4. COMUNICACIN APLICACIN SCADA CON EL ENTORNO ............................................ 10 5. MODELO CLIENTE-SERVIDOR ............................................................................................ 12 6. SERVIDOR.............................................................................................................................. 13 7. CLIENTES............................................................................................................................... 16 7.1. CLIENTES LOCALES ...................................................................................................... 17 7.2. CLIENTES REMOTOS .................................................................................................... 18 7.3. ESTRUCTURA DE PROTOCOLOS................................................................................ 18 7.4. EJEMPLOS IMPLEMENTADOS...................................................................................... 25 8. PROTOCOLOS EFICIENTES................................................................................................. 29 8.1. PROTOCOLO UNO A UNO............................................................................................. 30 8.2. PROTOCOLO UNO A N .................................................................................................. 30 8.3. PROTOCOLO PARA VARIABLES ALTERNATIVAS ...................................................... 31 9. HISTRICOS .......................................................................................................................... 32 9.1. EXCEL VERSUS TXT...................................................................................................... 32 9.2. LOCAL VERSUS REMOTO............................................................................................. 36 9.3. USUARIO DE HISTRICO.............................................................................................. 38 10. CONTROL CAMPO .............................................................................................................. 39 10.1. FUNCIN....................................................................................................................... 39 10.2. ORDEN DE CAMPO ...................................................................................................... 41 10.3. ORDEN DE HELIOSTATO ............................................................................................ 41 10.4. CALCULA COORDENADA............................................................................................ 41 10.5. ENVO DE ORDEN A HELIOSTATO ............................................................................ 42 10.6. ACTUALIZACIN DE BASE DE DATOS ...................................................................... 42 10.7. TORRE DE PROTOCOLOS .......................................................................................... 42 11. DESCRIPCIN DEL CDIGO.............................................................................................. 46 11.1. SERVIDOR LOCAL ....................................................................................................... 46 11.2. DESCRIPCIN DE CLIENTES ..................................................................................... 74 12. CONCLUSIN .................................................................................................................... 101 13. BIBLIOGRAFA .................................................................................................................. 102
1. INTRODUCCIN
El objetivo de esta investigacin es el diseo de una metodologa de implantacin de un sistema distribuido de monitorizacin, supervisin y adquisicin eficiente de datos de una planta solar de concentracin usando un sistema SCADA . Se utilizar una herramienta o lenguaje de programacin denominado LABVIEW, totalmente grfico, facilitando el
1
entendimiento y manejo de aplicaciones tipo SCADA. Para ello, se va a desarrollar cada una de sus partes en los prximos puntos. La idea es conseguir un sistema SCADA para una planta solar orientada, en principio, a un total de unos mil heliostatos. El diseo de los programas y la base de datos se han dimensionado para esta capacidad. El hardware que se ha utilizado consta de tres ordenadores conectados a una red local para comunicacin interna. Siempre se ha dejado la posibilidad de ampliar el nmero de computadoras para poder ajustarse a las necesidades futuras. En cuanto al software, se ha elegido el programa comercial LabView, una de las posibilidades que ofrece la empresa National Instrument. La forma de programar este software es muy parecida al lenguaje C pero con grandes ventajas en cuanto a interfaz hombre-mquina se refiere. El sistema operativo que se va a usar es Windows Server 2008 debido a su versatilidad. Lo ideal para un proceso industrial de este tipo sera usar sistemas que permitan trabajar en tiempo real estricto pero, dadas las caractersticas de este proceso en particular, es posible pensar en un sistema operativo en tiempo real suave, es decir, que bajo ciertas circunstancias o eventos, se puede superar ciertos lmites estrictos de tiempo.
Esta publicacin est orientada hacia el Bachillerato, en concreto, para la materia Tecnologa Industrial II.
Esta formacin postobligatoria capacita al alumno para una formacin posterior universitaria o ciclo formativo de Grado Superior.
La normativa en la que est basada esta publicacin para la aplicacin al Bachillerato es la siguiente:
- Ley Orgnica 2/2006, de 3 de mayor, de Educacin (en adelante, L.O.E.). - Ley 17/2007, de 10 de diciembre, de Educacin de Andaluca (en adelante, L.E.A.) - Real Decreto 1467/2007, de 2 de noviembre, por el que se establece la estructura y enseanzas mnimas del Bachillerato.
Acrnimo en ingls de Supervisory, Control And Data Adquisition
- Decreto 416/2008, de 22 de julio, por el que se establece la ordenacin y las enseanzas correspondientes al Bachillerato en Andaluca - Orden de 5 de agosto de 2008, por la que se desarrolla el currculo del Bachillerato en Andaluca
Nuestra vida cotidiana est marcada por la Tecnologa. La evolucin tecnolgica ha marcado nuestra forma de vivir, de relacionarnos socialmente. Conceptos como la innovacin tecnolgica, calidad de vida, respeto del medio ambiente, estn ligados con la Tecnologa.
Por lo tanto, es necesario prestar especialmente atencin a este tipo de formacin en Bachillerato, donde el alumno adquirir conocimientos cientficos y tecnolgicos.
La Tecnologa Industrial se basa en los conocimientos adquiridos relacionados con esta materia durante la ESO, donde el alumno, participando colectivamente de forma activa y crtica podr profundizar en lo estudiado hasta ahora, respetando los valores adquiridos (respecto por el medio ambiente, consumo razonable de recursos energticos, conciencia de las consecuencias para la sociedad del uso de la tecnologa). El alumno tendr oportunidad de estudiar tcnicas especficas y desarrollos tecnolgicos relacionados con la actividad industrial.
Los ncleos temticos propuestos en Bachillerato son:
1. Uso responsable de las materias primas. Materiales de uso tcnico. 2. Consumo energtico. Ahorro y eficiencia energtica en la industria. 3. Los avances tecnolgicos. I+D+I. Mquinas. 4. Automatizacin. Control de procesos y mquinas.
Este documento se centra sobre todo en los ncleos temticos 3 y 4, ya que supone un ejemplo de avance tecnolgico con una plataforma basada en un sistema SCADA, aplicada para el control de una planta solar, como parte de un proceso de automatizacin.
Particularizando cada ncleo temtico a Tecnologa Industrial II, respecto al "uso responsable de las materias primas. Materiales de uso tcnico", se abordan tcnicas relacionadas en mayor medida con los ensayo, reciclado de materiales, normas de precaucin y prevencin en el manejo de materiales, instrumentos, etc.
Respecto al ncleo temtico "Consumo energtico. Ahorro y eficiencia energtica en la industria", se debe abordar desde la materia de Tecnologa Industrial II con los contenidos relacionados con las energa til, rendimiento y aspectos relacionados con las prdidas energticas en mquinas, haciendo distintos ensayos y tcnicas de experimentacin sobre
montajes reales donde puedan realizar comprobaciones directas de consumo energtico, as como el coste econmico asociado a este consumo.
Respecto al ncleo temtico "Los avances tecnolgicos, la I+D+I. Mquinas", se debe abordar contenidos relacionados con motores elctricos y mquinas trmicas, teniendo la posibilidad de experimentar con diferentes mquinas, as como comprender la funcin de cada uno de los elementos. Es importante abordar en este sentido el manejo de distintos tipos de herramientas de simulacin de circuitos de control automtica, elctricas, electrnicas, neumtico, etc.
Por ltimo, el ncleo temtico "Automatizacin. Control de procesos y mquinas" se desarrollar en Tecnologa Industrial II, abordando contenidos relacionados con los sistemas automticos. Se vern conceptos como regulacin y control, as como la adquisicin de conocimientos relativos al control y programacin de sistemas automticos.
Por tanto, la aplicacin del tema de esta publicacin es directa y encaja perfectamente con los contenidos de la materia de Tecnologa Industrial II de Bachillerato.
2. SISTEMA SCADA
Se trata de una aplicacin software especialmente diseada para funcionar sobre ordenadores en el control de produccin, proporcionando comunicacin con los dispositivos de campo (controladores autnomos, autmatas programables, etc.) y controlando el proceso de forma automtica desde la pantalla del ordenador.
La comunicacin se realiza mediante buses especiales o redes LAN. Todo esto se ejecuta normalmente en tiempo real y estn diseados para dar al operador de planta la posibilidad de supervisar y controlar dichos procesos.
Los programas necesarios, y en su caso, el hardware adicional que se necesite, se denomina en general sistema SCADA y debe estar en disposicin de ofrecer las siguientes prestaciones: Posibilidad de crear paneles de alarma, que exigen la presencia del operador para reconocer una parada o situacin de alarma, con registro de incidencias. Generacin de histricos de seal de planta que pueden ser volcados para su proceso sobre una hoja de clculo. Ejecucin de programas, que modifican la ley de control, o incluso anular o modificar las tareas asociadas al autmata, bajo ciertas condiciones. Posibilidad de programacin numrica, que permite realizar clculos aritmticos de elevada resolucin sobre la CPU del ordenador.
Con ellas, se pueden desarrollar aplicaciones para ordenadores (tipo PC, por ejemplo), con captura de datos, anlisis de seales, presentaciones en pantalla, envo de resultados a disco e impresora, etc. Adems, todas estas acciones se llevan a cabo mediante un paquete de funciones que incluye zonas de programacin en un lenguaje de uso general (como C, Pascal, Basic), lo cual confiere una potencia muy elevada y una gran versatilidad. Algunos SCADA ofrecen libreras de funciones para lenguajes de uso general que permiten personalizar de manera muy amplia la aplicacin que desee realizarse con dicho SCADA.
Un SCADA debe cumplir los siguientes objetivos para que su instalacin sea perfectamente aprovechada: Deben ser sistemas de arquitectura abierta, capaces de crecer adaptarse segn las necesidades cambiantes del sistema. Deben comunicarse con total facilidad y de forma transparente al usuario con el equipo de planta y con el resto de la red (redes locales y de gestin). Deben ser programas sencillos de instalar, sin excesivas exigencias de hardware, y fciles de utilizar, con interfaces amigables con el usuario.
Los mdulos bloques software que permiten las actividades de adquisicin, supervisin y control de un SCADA son los siguientes: Configuracin: permite al usuario definir el entorno de trabajo de su SCADA, adaptndolo a la aplicacin particular que se desea desarrollar. Interfaz grfica del operador: proporciona al operador las funciones de control y supervisin de la planta. El proceso se representa mediante sinpticos grficos almacenados en el ordenador de proceso y generados desde el editor incorporado en el SCADA o importados desde otra aplicacin durante la configuracin del paquete. Mdulo de proceso: ejecuta las acciones de mando preprogramadas a partir de los valores actuales de variables ledas. Gestin y archivo de datos: se encarga del almacenamiento y procesado ordenado de los datos, de forma que otra aplicacin o dispositivo pueda tener acceso a ellos. Comunicaciones: se encarga de la transferencia de informacin entre la planta y la arquitectura hardware que soporta el SCADA, y entre sta y el resto de elementos informticos de gestin.
Entre los conceptos asociados a sistemas SCADA, se debe distinguir:
Tiempo real
La capacidad en tiempo real se refiere a la capacidad del ordenador en programas de procesamiento de datos para que siempre est listo para procesar y proporcionar los resultados dentro de un tiempo especificado. En este contexto "tiempo real estricto" significa que el sistema reacciona a los eventos externos dentro de un tiempo especificado en un 100%
de los casos. Adems si se habla de tiempo real el sistema debe responder en tiempos concretos tambin en un 100% de los casos. Si los tiempos concretos de reaccin pueden superarse en ciertos casos, como en sistemas no crticos, hablamos de "tiempo real suave".
Hardware en sistemas de supervisin: PLC y PC
Las tareas automatizadas de control, visualizacin y computacin pueden ser efectuadas por PLCs (conectados en red mediante los mdulos adecuados) mejor que con sistemas exclusivos de control basados en PC. Lo que finalmente es prctico, no obstante, depende de un gran nmero de factores y la mayora deben ser considerados individualmente para cada proyecto de automatizacin. As, por ejemplo, los actuales conocimientos y preferencias del usuario pueden jugar un mayor papel que la pura potencia del ordenador. Los factores cruciales, no obstante, son los atributos de capacidad en tiempo real y las propiedades de seguridad que hasta ahora han sido fuertemente asociadas con el PLC, aunque el PC tambin puede disponer de la caracterstica de capacidad en tiempo real. Un sistema de control es inconcebible sin capacidad en tiempo real.
Es comn, en sistemas de control por ordenador, tener que elegir segn las caractersticas del sistema a supervisar, entre el PLC el PC. Se debe elegir aquel hardware que mejor se adapte a las necesidades del sistema a supervisar. Los controladores lgicos programables, en la mayora de los casos, estn diseados especficamente para ser empleados en ambientes industriales exigentes y han sido continuamente desarrollados de forma que sus sistemas operativos en tiempo real representan su mayor virtud. Ellos son y seguirn siendo, no obstante, la primera eleccin para todo control de tareas crticas o extremas por su rendimiento y simpleza, en los que un PC podra estar simplemente "sobrecargado" debido al trabajo que le pueden suponer otras tareas de mbito comn, como la gestin y visualizacin de datos, accesos a perifricos, bases de datos, etc. Si adems del control de tareas, se necesita un procesamiento de datos, trabajo en red visualizacin (una aplicacin SCADA), un sistema basado en PC debe ser tomado en consideracin.
En cuanto a sistemas operativos, Windows Server 2008, por ejemplo, no es estrictamente un sistema operativo en tiempo real como el de un PLC, pero puede actuar de forma suficientemente rpida para aplicaciones "suaves" en tiempo real, gracias a su arquitectura de micro-kernel. Como el sistema operativo slo puede proporcionar respuestas suaves en tiempo real, lo ms simple es emplear extensiones hardware para las tareas crticas (placas de expansin PC) y soluciones software para el resto de tareas. Esto nos lleva a una compatibilidad con futuros sistemas operativos y una solucin totalmente factible actualmente. Estas tarjetas de expansin asumen las tareas crticas en tiempo real que el ordenador (PC) no puede atender e incorporan
DSPs (Procesadores de Seales Digitales) microcontroladores, que aportan una ayuda a la anterior sobrecarga mencionada para los ordenadores (PC).
An no se ha establecido un estndar para poseer extensiones compatibles en tiempo real de sistemas operativos. De una forma estrictamente determinante, los sistemas estndar actuales deben ser modificados de forma general, as que la principal ventaja de un sistema basado en PC (su estructura abierta) puede llegar a ser un inconveniente. No obstante, la estructura abierta permite a la empresa el programador ms libertad en la eleccin de la herramienta adecuada para el anlisis, diseo y programacin del sistema SCADA. La solucin comienza a ser propietaria nuevamente, es decir, cada empresa ofrece su solucin y la conversin a futuras generaciones de sistemas operativos lo hace ms difcil.
3. LABVIEW
LabView es una herramienta diseada especialmente para monitorizar, controlar, automatizar y realizar clculos complejos de seales analgicas y digitales capturadas a travs de tarjetas de adquisicin de datos, puertos serie y GPIBs (Buses de Intercambio de Propsito General). Es un lenguaje de programacin de propsito general, como es el Lenguaje C Basic, pero con la caracterstica que es totalmente grfico, facilitando de esta manera el entendimiento y manejo de dicho lenguaje para el diseador y programador de aplicaciones tipo SCADA. Incluye libreras para la adquisicin, anlisis, presentacin y almacenamiento de datos, GPIB y puertos serie, adems de otras prestaciones, como la conectividad con otros programas, por ejemplo de clculo, como Matlab.
Est basado en la programacin modular, lo que permite crear tareas muy complicadas a partir de mdulos o sub-mdulos mucho ms sencillos. Adems estos mdulos pueden ser usados en otras tareas, con lo cual permite una programacin ms rpida y provechosa. Tambin ofrece la ventaja de debugging en cualquier punto de la aplicacin. Es decir, permite la posibilidad de poner break-points, ejecucin paso a paso, ejecucin hasta un punto determinado y se puede observar como los datos van tomando valores a medida que se va ejecutando la aplicacin. Adems tambin lleva incorporado generadores de seales para poder hacer un simulador.
LabView es un lenguaje completamente grfico y tiene un resultado totalmente parecido a un instrumento, por ello a todos los mdulos creados con LabView se les llama VI (Instrumento Virtual). Existen dos conceptos bsicos en LabView: el Front Panel (Panel Frontal) y el Block diagram (Diagrama de Bloque). El Panel Frontal es la interfaz que el usuario esta viendo y puede ser totalmente parecido al instrumento del cual se estn recogiendo los datos, de esta manera el usuario sabe con precisin cual es el estado actual de dicho instrumento y los valores de las
seales que se estn midiendo. El diagrama de bloques es el conexionado de todos los controles y variables, que tendra cierto parecido al diagrama del esquema elctrico del instrumento.
LabView tiene la caracterstica de descomposicin modular ya que cualquier VI que se ha diseado puede convertirse fcilmente en un mdulo que puede ser usado como una subunidad dentro de otro VI. Esta peculiaridad podra compararse a la caracterstica de procedimiento en los lenguajes de programacin estructurada.
Es un sistema abierto, es decir, cualquier fabricante de tarjetas de adquisicin de datos o instrumentos en general puede proporcionar el driver de su producto en forma de VI dentro del entorno de LabView. Tambin es posible programar mdulos para LabView en lenguajes como C y C++, conocidos como Sub-VIs y no se difieren a los VI creados con LabView salvo por la interfaz del lenguaje en el que han sido programados. Se podra decir que en cualquier VI existen dos caras bien diferenciadas: El Panel Frontal y el Diagrama de Bloques.
PANEL FRONTAL
Es la cara que el usuario del sistema est viendo cuando se est monitorizando controlando, sea, la interfaz del usuario. Contiene una amplia gama de controles e indicadores. En la figura 1 se muestra un ejemplo de Panel Frontal.
Figura 1. Ejemplo de Panel Frontal
Todos los controles tienen una forma visual que indican al usuario cual es el estado de dicho control en el instrumento real. Es muy importante en un sistema SCADA que el usuario no tenga que interpretar nada, sino que todo le sea claro y conciso, las interpretaciones pueden dar lugar a falsas actuaciones y, por consiguiente, podran existir lamentables errores. Adems, dos usuarios podran interpretar de manera diferente cualquier evento.
DIAGRAMA DE BLOQUES Es la cara oculta del Panel Frontal, es decir, una cara que el usuario del sistema no puede ver.
En ella estn todos los controles e indicadores interconectados, parecindose mucho a un diagrama de esquema elctrico. Esta cara es mucho menos conceptual que el Panel Frontal y para el usuario sera muy difcil entenderla. La figura 2 es un ejemplo diagrama de bloques.
Figura 2. Ejemplo de Diagrama de Bloques
Se puede observar como todos los mdulos estn interconectados mediante lneas de conexin. Por ellas circulan los diferentes datos o valores del VI y de esta manera se logra que funcione como un conjunto de elementos, mdulos y sub-mdulos.
4. COMUNICACIN APLICACIN SCADA CON EL ENTORNO
En este apartado se detallan los conceptos bsicos de la comunicacin de un sistema SCADA con todo su entorno: Adquisicin de Datos para ordenadores (tarjetas de adquisicin de datos) y Redes LAN y el protocolo TCP/IP, para aplicaciones servidor/cliente.
TARJETAS DE ADQUISICIN DE DATOS Es una forma de medir las seales y transferir los datos al ordenador (llamadas comercialmente tarjetas DAQ). Estas tarjetas poseen Convertidores Analgico/Digitales (ADC) y Convertidores Digital/Analgicos (DAC) que permiten la entrada/salida de seales analgicas y digitales. Normalmente, las tarjetas DAQ se instalan en los buses de alta velocidad del PC como los buses PCI. En funcin de la velocidad de la placa base del PC, la velocidad mxima de transferencia de datos entre componentes de dicha placa base suele estar entre el microprocesador y la memoria.
REDES LAN Y PROTOCOLO TCP/IP Existen diferentes medios para que los datos puedan ser intercambiados entre los instrumentos de campo y el ordenador. Muchos de los instrumentos poseen un puerto serie, mediante el cual la informacin es enviada al ordenador o a otros instrumentos. El uso de GPIB (Buses de
10
Intercambio de Propsito General) permiten transferir datos a travs de puertos paralelos, puertos series y redes de instrumentos u ordenadores.
Una de las principales evoluciones de la informtica ha sido el paso del modo centralizado al modo distribuido o repartido. Uno de los efectos de los progresos realizados en el plano de los componentes fsicos est, en muchos casos, en el abandono de la mquina central encargada de la ejecucin de las diferentes tareas en beneficio de varias mquinas. En dicho entorno, rpidamente se hace sentir la necesidad de intercambio de informacin entre diferentes mquinas. Puede tratarse de intercambio de datos entre programas o de archivos o informaciones entre usuarios. El concepto de red corresponde a esta interconexin entre diferentes mquinas.
El desarrollo de las redes est en constante evolucin y se pueden caracterizar por el paso del modo repartido al modo distribuido. En el primero, los recursos necesarios para una actividad deben localizarse explcitamente. Por tanto, un usuario tiene que tener una cierta idea de la topografa de la red. Con el concepto de distribucin, los diferentes recursos de un mismo tipo constituyen un recurso virtualmente nico. Por ejemplo, los discos de las diferentes unidades constituyen un disco virtual nico al cual pueden acceder los diferentes sistemas de una manera totalmente transparente.
Un primer criterio de clasificacin de redes es el alejamiento de sus diferentes componentes. En el caso de una red local, la distancia que separa los huspedes no excede de varios kilmetros permitiendo una interconexin fsica que se realiza mediante diferentes soportes. En una red a larga distancia para la unin entre dos huspedes puede utilizarse como soporte la lnea telefnica o satlites.
La multiplicacin de redes locales, que ofrecen servicios a un grupo restringido de usuarios, ha mostrado rpidamente sus lmites y se ha dejado sentir la necesidad de superar el cuadro local de sus intercambios. La satisfaccin de estas necesidades ha chocado con la heterogeneidad de las redes. Por iniciativa del DARPA , se han realizado investigaciones para obtener una red lgica que, a priori, permita la interconexin de todas las redes, cualquiera que sea la tecnologa. Estas investigaciones convergen en la definicin de una serie de protocolos a los que generalmente se hace referencia nombrando los dos protocolos principales, es decir, TCP/IP.
2
Las interfaces IP aseguran la gestin de los protocolos especficos a cada tipo de red fsica. Uno de los papeles que les incumbe es la fragmentacin de los mensajes que se van a emitir, es decir, se trata de dividir los mensajes para enviarlos mediante una trama fsica. El protocolo IP se utiliza para el intercambio de paquetes de informacin en modo no conectado. Por tanto,
2
Acrnimo en ingls de Defence Advanced Research Project Agency
11
no garantiza la llegada correcta de los mensajes. Esta funcionalidad se introducir mediante el protocolo TCP, orientado a conexin, es decir, ofrece un servicio seguro de transporte de informacin (octetos). Los octetos que se emiten desde un lado de la conexin se liberan en el mismo orden al otro lado de la conexin. Este grupo de octetos no tiene ninguna estructura. La conexin se realiza en modo dplex, es decir, soporta una comunicacin simultnea en los dos sentidos.
El modelo de servidor/cliente es el modo de interaccin ms corriente entre aplicaciones en una red. Un servidor es un programa que ofrece un servicio en la red, es decir, que realiza una funcin especfica. En ciertas circunstancias, este trmino designar a una mquina. Este ser el caso si dicha mquina est dedicada a un servicio particular (por ejemplo, servidor de datos adquiridos). Un cliente es un programa que dirige a un servidor una peticin especfica que corresponde a una demanda de servicio. De este modo, en el caso de aplicaciones que se comuniquen utilizando estos protocolos, se enviar una peticin de un cliente a un servidor por mediacin de un paquete que contiene, en particular, un nmero de puerto que corresponde al servicio y el nmero del puerto donde el cliente espera la respuesta.
Muchos de los sistemas SCADA empleados necesitan comunicarse va red, puertos GPIB, telefnica o satlite. Mientras existen unos ordenadores que estn capturando datos en campo, hay otros que se encargan de recoger la informacin y gestionarla, Centros de Control.
5. MODELO CLIENTE-SERVIDOR
Para el diseo de la aplicacin se ha decidido en un modelo cliente-servidor. Dadas las especificaciones que se plantean, el diseo debe incluir una base de datos que registre todas las variables del sistema. Por tanto, este modelo viene muy bien para el acceso a la misma. Por ejemplo, para hacer una escritura existe un cliente que realiza una peticin al servidor. El servidor atiende dicha peticin y devuelve una respuesta. Esta respuesta es obligatoria, ya que se trata de un acuse de recibo, es decir, es la nica forma que tiene el cliente de saber que su peticin ha sido atendida. En el caso de una lectura no existe ningn problema, ya que el valor ledo puede servir como acuse de recibo. En el caso de escritura no ocurre lo mismo.
En un modelo cliente-servidor, el servidor puede atender a muchos usuarios. El acceso al mismo debe hacerse de forma que no se pierda ninguna peticin y que no existan problemas de acceso a recursos compartidos. Para ello, se ha pensando en el uso de colas que guardan las peticiones y los resultados. Para que un cliente pueda ser distinguido de otro, a cada peticin se le asigna un nmero que identifique la misma. Por tanto, es posible utilizar este nmero como acuse de recibo en el caso de una escritura en la base de datos, por ejemplo. El cliente sabe que se ha realizado su operacin con xito porque el servidor le ha devuelto el nmero de peticin del servicio.
12
La solucin que se presenta es un modelo cliente servidor, con dos colas, una para las peticiones y otra para los resultados. Cada valor insertado en la cola contiene el nmero de peticin que es lo nico que asocia dicha peticin con un cliente en concreto.
6. SERVIDOR
En el diseo de la aplicacin, el servidor local ser aquel que gestione el acceso a la base de datos. De entrada, se puede observar que esta estructura ser crtica en el sistema ya que una gestin ralentizada a la misma conlleva retardos importantes que inestabilizan el sistema. Para el control de la base de datos (BD) existe un servidor local. Los puntos de acceso al mismo son dos colas, una cola de peticiones y otra de resultado. Para realizar las peticiones hace falta una estructura de datos que sean entendidos por el agente, es decir, hace falta un protocolo para poner de acuerdo a cliente y servidor. El protocolo de acceso a la BD consiste en paquetes con el formato que se muestra en la figura 3.
ID
FILA
COLUMNA
LECT/ESC
VALOR
Figura 3. Paquete de acceso a la Base de Datos La solucin adoptada para la BD consiste en un vector de tamao definido que guarde las variables del sistema. Dada la forma de programar en LabView (lenguaje G), la BD se puede sustituir por un mdulo o subprograma que realice las mismas funciones, por ejemplo, Microsoft Access, sin que esto tenga asociado graves trastornos en la aplicacin.
Se va a explicar cada parte del paquete de acceso a la BD: ID: Es un nmero de peticin que sirve para identificar el cliente. FILA: Es un nmero de 4 cifras que se usa para direccionar la BD. Inicialmente, se ha supuesto que el tamao mximo del vector sea de 10000 elementos, suficientes para guardar todos los estados del proceso industrial. Este valor es reajustable desde comando. COLUMNA: Es un nmero con dos lecturas. Se podra pensar en una BD de dos dimensiones con todas las ventajas que esto presenta. Tambin se puede utilizar para distinguir clientes que realicen la misma peticin, ya que segn el diseo desarrollado hay peticiones de servicio especiales a las que el servidor les da un trato especial. Este es el caso de un acceso a n elementos en donde el tamao del paquete es variable en funcin de n. Por tanto, si se le asocia un ID a esta operacin, dos clientes que quieran solicitar el mismo servicio podran interferirse. Por tanto, con esta solucin se resuelve el problema. LECT/ESC: Es un byte que se usa para distinguir lecturas escrituras de elementos de la BD.
13
VALOR: Es una estructura de 14 dgitos que se usa para el caso de escritura a BD en un sentido, es decir, el cliente usa este campo para dar al servidor el valor a escribir, para la lectura en el otro, es decir, el servidor utiliza este campo para devolver al cliente el elemento ledo de BD.
Este ha sido el ejemplo de acceso a un elemento de la BD. Se puede comprobar que se trata de una estructura sencilla, de longitud constante, por lo que no es necesario incluir campos de Longitud. Hay protocolos ms complicados, en los que se hace peticiones remotas al servidor y en donde sera necesario incluir dicho campo que indique el tamao de los datos, ya sea a leer escribir. Para trabajar con protocolos de Red/Transporte en Lenguaje G, los elementos valores deben tener un formato de cadena de caracteres que simplifiquen el acceso a BD y minimicen el nmero de operaciones hasta llegar a leer/escribir. Por tanto, cada elemento de BD es una cadena de caracteres formada por 14 dgitos caracteres.
El servidor que gestiona BD debe estar constantemente comprobando la cola de entrada. Si hay una peticin (elementos en cola > 0), se tiene que sacar el elemento de la misma, atender la peticin y escribir el resultado en la cola de salida con el formato adecuado. Bsicamente la funcin del servidor se puede resumir en un bucle que constantemente realice lo que se ha descrito con anterioridad. Pero hay que destacar que el bucle debe ser dinmico ya que no puede tener velocidad de operacin constante. Esto podra saturar el sistema estando el servidor en vaco o hara que fuese ineficiente, ya que, an con tareas pendientes, el servidor estara libre poco cargado.
Por tanto, este es uno de los aspectos ms importantes en el diseo del servidor que gestiona el acceso a BD, es decir, un bucle que debe ir rpido cuando haya tareas por atender y viceversa. La solucin a este problema es evitar el polling a la cola y atender mediante eventos sucesos. Como se ha mencionado previamente, para la BD se ha escogido un vector de tamao definido. Una posible distribucin de la misma es la que se muestra en la figura 4.
14
Estacin Meteorolgica Control Global Foco Tanque Variables del sistema
1-10 11-49 50-149 150-249 250-349 350-499
Coordenadas Grupo en Foco
500-699 700-999
Numero de Heliostato Acimut Elevacin Estado Orden Heliostato Orden Campo X-Foco Y-Foco
1000-1999 2000-2999 3000-3999 4000-4999 5000-5999 6000-6499 6500-7499 7500-8499
Figura 4. Ejemplo de distribucin de elementos en la Base de Datos Como se puede comprobar en este ejemplo, hay transacciones que se pueden realizar de elemento en elemento, como es el caso de las variables que necesita la estacin meteorolgica, que debido a su escaso nmero, es ms eficiente emplear un protocolo uno a uno. En cambio, hay operaciones que implican transacciones de 1000 elementos ms. Este es el caso de la lectura ngulo de acimut y elevacin para cada heliostato. No es viable hacer esta operacin de uno en uno porque perderamos demasiado tiempo al realizar un total de 2000 transacciones. En este caso se opta por utilizar un protocolo ms eficiente en donde se le da al servidor una direccin de BD, un tamao y la operacin a realizar, ya sea lectura escritura. De esta forma, en una sola transaccin se ha ledo o escrito n elementos, ahorrado mucho tiempo de proceso.
Para hacer uso eficiente de las colas, hay que tener en cuenta que un tamao de cola demasiado grande, por ejemplo, mil elementos que hace que el sistema no sea eficiente. Por tanto, se pierde demasiado tiempo gestionando la cola elemento a elemento. Para el desarrollo de la aplicacin se ha diseado colas de tamao 10, longitud suficiente para cumplir con las especificaciones del sistema.
Finalmente, se concluye este apartado con un esquema de funcionamiento del servidor local como se muestra en la figura 5.
15
SERVIDOR
LOCAL
Figura 5. Esquema de funcionamiento del servidor local
Por tanto, el esquema global de funcionamiento de cliente-servidor en la investigacin sera el que se muestra en la figura 6. CLIENTE 2 CLIENTE 1 CLIENTE 3
SERVIDOR LOCAL
Figura 6. Esquema global de funcionamiento de cliente-servidor Se puede observar que la nica conexin entre el cliente y servidor son las colas de entrada y salida.
7. CLIENTES
En este apartado se describe la tipologa de clientes que existe en la aplicacin y la ambigedad cliente-servidor que existe con los distintos subprogramas, ya que, un mdulo es un cliente del servidor local pero a la vez tambin puede realizar las funciones de servidor de clientes remotos, por ejemplo.
16
7.1. CLIENTES LOCALES
Dentro de clientes locales hay que distinguir entre clientes que estn en la misma mquina que el servidor local y clientes que residen en mquinas remotas. A este ltimo tipo de clientes se les va a conocer como clientes remotos que se detallan ms adelante. Para este tipo de clientes es necesario tener un mdulo que atienda las peticiones y debido a la sencillez del servidor local, ste no se puede encargar de atender estas peticiones remotas debido a que su funcin nica y exclusivamente ser atender elementos en cola de entrada. Por tanto, para los clientes remotos van a existir clientes locales que a la vez realicen funciones de servidores de clientes remotos. Este concepto se ilustra en la figura 7.
CLIENTE 2 CLIENTE 1
SERVIDOR LOCAL CLIENTE REMOTO
CLIENTE ESPECIAL
CONTROL 1
CONTROL 2
CONTROL 3
Figura 7. Esquema sobre tipos de clientes locales en la aplicacin
Existen dos tipos de clientes (cliente 1 y cliente 2) que residen en la misma mquina que el servidor local (CONTROL 3). Los usuarios finales que harn uso de stos se encuentran en el mismo ordenador. En cambio, existen clientes especiales (cliente especial) que nicamente acceden al servidor local para atender las peticiones de clientes remotos, es decir, clientes cuyos usuarios estn en mquinas remotas. Por tanto, se podran entender que estos clientes especiales son, por un lado, clientes del servidor local, pero por otro lado, podran ser servidores de los clientes remotos. Incluso, cuando ms adelante se estudie el cdigo de estos mdulos, la estructura que presentan es muy similar a la que presenta un servidor convencional.
17
7.2. CLIENTES REMOTOS
En primer lugar, hay que mencionar que debera existir la misma tipologa de este tipo de clientes como la que existe de clientes locales (no especiales). Para este tipo de clientes, acceder a BD debe hacerse de forma transparente, es decir, no se tienen que preocupar si residen en la misma mquina no, sino que, a travs de un protocolo parecido al que se usa para comunicarse con el servidor local se consiga realizar una transaccin. La solucin a esta cuestin es la aparicin de un intermediario que se comunique con el cliente especial que atender las peticiones remotas. Este concepto se refleja en la figura 8.
CLIENTE 2 CLIENTE REM OTO 1 CLIENTE 1
CLIENTE REMOTO 2
SERVIDOR LOCAL
MDULO ESPECIAL
CLIENTE ESPECIAL
CONTROL 1
CONTROL 2
CONTROL 3
Figura 8. Esquema sobre el mdulo especial de los clientes remotos en la aplicacin
En este esquema existe un nuevo mdulo que hasta ahora no haba aparecido (mdulo especial). En este subprograma tambin aparece la ambigedad cliente-servidor, ya que se trata de un servidor de clientes remotos, pero tambin es cliente del servidor local. Lo que s est claro es que est al mismo nivel que cliente especial en la mquina donde reside la BD. Por tanto, tenemos toda una estructura de protocolo que refleja el funcionamiento del sistema.
7.3. ESTRUCTURA DE PROTOCOLOS
La estructura de protocolos queda reflejada en la figura 9.
Existen mensajes que recorren toda la estructura de protocolos, creados en cliente remoto hasta llegar a servidor local. El servidor devuelve el resultado y se sigue el camino inverso hasta llegar de nuevo el cliente remoto, donde se ha atendido su peticin.
18
CLIENTE REMOTO
SERVIDOR LOCAL
MDULO ESPECIAL TRANSPORTE RED ENLACE
CLIENTE ESPECIAL TRANSPORTE RED ENLACE
NIVEL FSICO
NIVEL FSICO
Figura 9. Estructura de protocolos
Para la realizacin de este Proyecto se dispone de tres ordenadores. En figuras anteriores ya se vislumbra el nombre que se les ha dado, CONTROL 1, 2 y 3. Como primera solucin, que cumple las especificaciones del sistema, se ha conectado a red local y como medio de transmisin se ha utilizado cable coaxial (RG-58) que hace las funciones de bus local. Esta topologa se puede variar fcilmente para obtener otra solucin, que nos d por ejemplo mayor ancho de banda (por ejemplo, el uso de cable de pares y un HUB que simule el bus local) pero que implica un coste adicional.
Subiendo en la torre de protocolos, aparece una capa que realiza las funciones de nivel de transporte, red y enlace que se describe en el modelo OSI. Esta capa la proporciona directamente LabView con diversos protocolos posibles para la comunicacin. En concreto, se ha optado por el protocolo de comunicaciones TCP/IP, dado su eficiencia. Tambin permite que cualquier cliente remoto pueda acceder a BD para realizar una transaccin ya sea en cualquiera de los ordenadores que compone el hardware de la solucin para el control a 1000 Km de distancia en una mquina remota.
El siguiente subprograma es el mdulo especial, en un lado de la comunicacin y cliente especial en el otro. La comunicacin entre estos dos programas consiste nicamente en establecer una conexin TCP/IP por la que intercambian datos. El flujo de estos datos siempre ser el mismo, es decir, el mdulo especial recoge los datos de la capa superior y se los enva a cliente especial. En este caso el paquete que recibe de cliente remoto para mdulo especial son datos. nicamente aade informacin que formar parte del protocolo a este nivel. Esta funcin siempre es opcional pero para este caso se va a hacer uso del concepto ya que es necesario aadir datos innecesarios para cliente remoto. En concreto se trata de la LONGITUD. El cliente especial, en el otro lado, no sabe cuntos bytes tiene que leer del puerto. Solamente existen dos formas posibles: una, que la longitud del paquete sea constante; dos, que mdulo especial enve en una posicin determinada la longitud del paquete al menos de la parte variable. Este concepto aparecer despus cuando se particularice para cada protocolo en cuestin.
19
Cuando cliente remoto quiera realizar una transaccin que involucre a un solo elemento (protocolo uno a uno), el tamao del mensaje es constante y no es necesario aadir longitud. En cambio, cuando se utilice un protocolo ms eficiente donde cada transaccin involucre a n elementos de BD, donde n es variable y es parte del mensaje as como si se trata de mensaje de LECT/ESC... etc., en este caso s es necesario aadir LONGITUD como parte del mensaje que mdulo especial enva a cliente especial. A continuacin se muestra, en la figura 10, un esquema de encapsulacin de datos que se sigue en una torre de protocolos como la descrita previamente.
Nivel N
Datos
Nivel N-1
Datos (N)
Cabecera (N-1)
. . .
Nivel 2 Datos (3) Cabecera (2)
Nivel 1
Datos (2)
Cabecera (1)
Figura 10. Esquema de encapsulacin de datos que se sigue en una torre de protocolos
7.3.1. TIPOS DE PROTOCOLOS
En este apartado se describe la transferencia de mensajes que se tiene en la estructura de capas para los tipos de protocolos principales.
7.3.1.1. REMOTO
1. Protocolo uno a uno Se le nombra de esta forma ya que se trata de un protocolo bsico donde cliente remoto solicita en cada transaccin la lectura/escritura de un elemento. Dada la sencillez del mismo,
20
este tipo de mensajes tendr una longitud constante, por lo que no se necesita aadir la LONGITUD (L) desde el punto de vista de clientes especiales. Atendiendo a la encapsulacin de paquetes, se detalla en la figura 11 el flujo de informacin para un caso de lectura en BD.
CLIENTE REMOTO
SERVIDOR LOCAL
ID F C lect Relleno
ID
Valor ledo
ID
ID Valor ledo
F C lect Relleno
MDULO ESPECIAL
CLIENTE ESPECIAL
ID
F C lect Relleno
ID
Valor ledo
ID
Valor ledo
ID
F C lect Relleno
MQUINA REMOTA
MQUINA LOCAL
PROTOCOLO TCP / IP Figura 11. Flujo de informacin para lectura en BD con protocolo uno a uno Se observa que el tamao de los paquetes es constante. Cuando la cantidad de informacin no es suficiente para completar el tamao del paquete, se le aade datos de relleno. En particular para ID se emplea 10 dgitos, 4 dgitos par F, 4 dgitos para C, 1 byte para lect y, finalmente 14 dgitos para Valor ledo (este formato ya se explic en un apartado anterior). No es necesario aadir informacin adicional (es decir, cabecera segn el esquema de encapsulacin) para pasar de una capa a otra. Por tanto, cada nivel espera del nivel anterior/superior un nmero de bytes dgitos conocidos.
El caso de escritura es exactamente igual con el tamao de mensaje conocido por todas las capas, slo que en la direccin cliente remoto hacia servidor local, en vez de utilizar relleno en el paquete. En ese trozo de mensaje ira el valor a leer escribir, y viceversa para el sentido contrario.
21
2. Protocolo uno a N
Este protocolo es ms eficiente que el anterior ya que, en cada transaccin con el servidor, se escribe/lee N elementos. De esta forma, hacemos ms eficiente el sistema debido a que la aplicacin se sobrecarga con la tasa de transacciones por segundo que es capaz de soportar el servidor, ya se escriba uno mil elementos en cada una. Por tanto, complicando un poco la estructura de mensajes, se logra ms eficiencia en el funcionamiento. Este concepto se muestra en la figura 12.
CLIENTE REMOTO
ID F C lect Index T am Relleno
SERVIDOR LOCAL
ID Lista valores ID F C lect Index Tam Relleno Lista valores
ID
MDULO ESPECIAL
ID F C lect Index Tam Relleno ID Longitud Lista valores ID Longitud
CLIENTE ESPECIAL
Lista valores
ID F C lect Index Tam Relleno
MQUINA REMOTA
MQUINA LOCAL
PROTOCOLO TCP / IP Figura 12. Flujo de informacin para lectura en BD con protocolo uno a N. Cliente remoto El tamao del mensaje aumenta a medida que baja la torre de protocolos. Al enviar una lista de valores no constante, mediante protocolo TCP/IP, es necesario aadir el parmetro LONGITUD L (longitud de valores variables). Por tanto, el otro extremo no tiene ms que obtener L para leer una cantidad de bytes por el puerto.
Para el cliente final es transparente la forma de acceder a la BD (remota localmente), ya que, nicamente entrega unos datos al nivel anterior y ste ya se preocupa del resto. Para el caso de escritura de N elementos, la estructura es similar pero con algunas diferencias que se detalla en la figura 13.
22
CLIENTE REMOTO
ID F C esc Index Tam ID Lista de valores ID F C lect Index Tam ID Relleno Lista de valores
SERVIDOR LOCAL
MDULO ESPECIAL
ID F C lect Index Tam Longitud = 0 Longitud Lista de valores Relleno Relleno Longitud = 0 ID ID
CLIENTE ESPECIAL
ID F C lect Index Tam Longitud Lista de valores
MQUINA REMOTA
MQUINA LOCAL
PROTOCOLO TCP / IP Figura 13. Flujo de informacin para escritura en BD con protocolo uno a N. Cliente remoto En el caso de lectura de N elementos, no se enva el parmetro L en la direccin cliente remoto a servidor local, ya que la peticin se realizaba a travs de un mensaje de tamao constante. En cambio, en el otro sentido, s se hace necesario.
En la escritura, L se enva en ambos sentidos. A la hora de disear el mdulo especial en la mquina remota, se toma como premisa que tendr varios clientes en una dinmica de funcionamiento normal. Por tanto, cuando recibe un mensaje, ste puede ser de cualquiera de los clientes que tiene asociado. Esto implica que se distinga cada caso (protocolo uno a uno y uno a N). La distincin entre protocolos es sencilla, ya que con una nica identificacin de peticin asociada a este protocolo (uno a N) se puede diferenciar del resto. Pero diferenciar una lectura de una escritura en la mquina remota se hace ms difcil. Una forma posible es que la mquina local (a travs de cliente especial) enve una LONGITUD = 0. De esta forma, el mdulo especial, diferencia cada protocolo con ID y si se trata de lectura escritura con el parmetro LONGITUD ( LONGITUD =0 , se trata de una escritura a BD; LONGITUD > 0, lectura a BD).
23
7.3.1.2. LOCAL
En este caso, el flujo de mensajes se reduce considerablemente. Adems no se necesita una cabecera adicional que incluya la longitud de la parte variable, ya que al usar colas, los elementos pueden ser variables y no hay que preocuparse de su tamao.
1. Protocolo uno a uno Se muestra el caso de lectura en BD en la figura 14.
ID
F C lect Relleno
SERVIDOR LOCAL
ID
Valor ledo
CLIENTE LOCAL
CLIENTE LOCAL
Figura 14. Flujo de informacin para lectura en BD con protocolo uno a N. Cliente local
En la escritura, el flujo de mensajes es exactamente igual, slo que se le pasa un valor al servidor y ste devuelve la identificacin de la peticin y relleno. Esta identificacin ID se utilizar como acuse de recibo.
2. Protocolo uno a N
Se muestra el caso de escritura en BD en la figura 15.
El flujo de mensajes es muy parecido al que tiene lugar en el protocolo anterior, slo que se entrega una lista de valores para el caso de lectura en BD. El servidor devuelve la identificacin de la peticin e informacin de relleno que sirve para mantener un tamao de mensaje constante.
24
ID
F C Esc Relleno
SERVIDOR LOCAL
Lista Valores
ID
Relleno
CLIENTE LOCAL
CLIENTE LOCAL
Figura 15. Flujo de informacin para escritura en BD con protocolo uno a N. Cliente local Para el caso de lectura de N variables, la forma de los mensajes es parecida, slo que el relleno aparece en el sentido cliente a servidor local y la lista de variables datos en el sentido inverso.
En estas figuras aparece un elemento nuevo, que se incluye como una caja negra que realiza las funciones de protocolo. Ms adelante, cuando se pase a la descripcin del cdigo de la aplicacin, se pone de manifiesto esta estructura. Para el cliente, la comunicacin con el servidor es exactamente igual que hacerlo con una caja negra subprograma a la que le pasa unos valores de entrada y ste le devuelve unos parmetros de salida, como podra ser la identificacin de la peticin y los valores (resultado de la lectura) relleno (resultado de la escritura).
7.4. EJEMPLOS IMPLEMENTADOS
En este apartado se realiza una breve descripcin de algunos clientes implementados para terminar de mostrar el funcionamiento flujo de informacin que tiene lugar en la aplicacin.
7.4.1. ESTACIN METEOROLGICA
Este cliente de la BD realizar accesos remotos a la misma y su funcin ser nicamente escribir en determinadas variables. En concreto, slo en las primeras 10 posiciones, segn se mostr en la distribucin de elementos en el vector en una figura anterior. Como no se trata de un elevado nmero de variables y frecuencia de refresco es pequea (se escribe en las 10 variables, una vez por segundo), se opta por utilizar el protocolo uno a uno.
25
La situacin fsica del cliente ser la mquina CONTROL2 y este ordenador tiene comunicacin mediante el puerto serie a una estacin meteorolgica, que peridicamente est enviando informacin. El flujo de informacin se muestra en la figura 16.
ESTACIN METEOROLGICA
ID 6 0 1 +000021.600000 ID **************
SERVIDOR LOCAL
ID **************
ID
6 0 1 +000021.600000
MDULO ESPECIAL
ID 6 0 1 +000021.600000 ID ************** ID **************
CLIENTE ESPECIAL
ID 6 0 1 +000021.600000
MQUINA REMOTA
MQUINA LOCAL
PROTOCOLO TCP/IP
Figura 16. Flujo de informacin de la estacin meteorolgica Se ha representado el caso de escritura de una temperatura que la estacin meteorolgica ha transmitido por uno de los puertos de CONTROL2 y la estructura del mensaje es relativamente sencilla. En ella se indica que se va a realizar en la posicin 6 por parte de un cliente normal (tipo 0) la escritura (1) del valor 21,6 grados (+000021,600000). El servidor despus de atender la transaccin devuelve el mismo ID y un valor de relleno (**************) que le sirve al cliente como acuse de recibo (en teora de redes a esta operacin se le conoce como ACK acknowledge- de la solicitud reconocimiento de la peticin).
7.4.2. INTERFAZ HOMBRE MQUINA (MMI) DE VISUALIZACIN DE ESTACIN METEOLGICA
Este es el caso de un cliente que tendr que existir en las tres mquinas por defecto, ya que un operador podr visualizar el estado meteorolgico de la planta solar desde cualquier ordenador que forme parte del sistema de control cualquier ordenador remoto en cualquier lugar del mundo mediante conexin TCP/IP.
26
nicamente tiene que leer en torno a 10 variables de la BD, por tanto, de nuevo se usar un protocolo uno a uno. Por tanto, a continuacin se va a mostrar el flujo de informacin para los dos casos posibles:
1. Transaccin local a la base de datos
Como la funcin de este cliente es mostrar por pantalla la temperatura del campo, la velocidad del viento, la irradiancia solar, etc. no va a escribir nunca en BD, sino que realizar siempre operaciones de lectura. Este flujo de informacin se muestra en la figura 17.
SERVIDOR LOCAL
ID 6 1 0 **************
ID
+000021.600000
CLIENTE LOCAL
CLIENTE LOCAL
Figura 17. Flujo de informacin en la transaccin local a la Base de Datos En este caso, se ha realizado una operacin sobre la variable 6 (variable que guarda informacin sobre la temperatura de la Planta Solar), por parte de un cliente norma (cliente tipo 1) y es una operacin de lectura (0). Para mantener el tamao del paquete que se le entrega al servidor constante se completa con informacin de relleno (**************). El servidor atiende esta operacin y devuelve el valor en cuestin de 21,6 grados centgrados (+000021,600000).
2. Transaccin remota a la base de datos
Este flujo de informacin se muestra en la figura 18.
27
VISUALIZACIN ESTADO METEOROLGICO

ID 6 1 0 ************** ID +000021.600000 ID +000021.600000 ID 6 1 0 **************
SERVIDOR LOCAL
MDULO ESPECIAL
ID 6 1 0 ************** ID +000021.600000 ID +000021.600000
CLIENTE ESPECIAL
ID 6 1 0 **************
MQUINA REMOTA
MQUINA LOCAL
PROTOCOLO TCP / IP Figura 18. Flujo de informacin en la transaccin remota a la Base de Datos El funcionamiento es muy parecido al caso local, aunque hay ms agentes implicados para realizar la transaccin.
7.4.3. OTROS EJEMPLOS
En este apartado se har una breve introduccin de otros clientes que tambin forman parte de la aplicacin final, slo que por el flujo de informacin o por que es necesario introducir algunos aspectos ms avanzados del Proyecto se estudian en apartados posteriores.
1. Control Campo Este es un cliente importante ya que se encarga de controlar y adquirir datos de los 1000 heliostatos que forman parte del campo exterior.
28
Para las transacciones con la BD se utiliza, evidentemente, el protocolo uno a N, debido a que se necesita conocer datos relacionados con todos los elementos que forman el campo, por lo que se necesitan hacer lecturas/escrituras de miles de elementos. Por ejemplo, para enviar una orden a un heliostato, se necesita conocer acimut y elevacin. Si esto es necesario para todos los heliostatos, tendramos que realizar 2000 lecturas sobre la BD. Se hace imprescindible el uso de un protocolo eficiente que en pocas transacciones sea capaz de obtener informacin y actualizar BD, sin que esto provoque sobrecarga del sistema.
2. Calcula Coordenada Este bloque se encarga de calcular el acimut y elevacin de todos los heliostatos a partir de las coordenadas cartesianas que tienen en el campo y de la posicin del Sol. Por tanto, tiene que conocer acimut y elevacin de todos los elementos (2000 valores) y de actualizar la BD con los nuevos valores calculados (2000 valores). Tambin se hace imprescindible el uso de un protocolo eficiente (uno a N).
3. Histrico Este cliente se ha diseado con la funcin de crear histricos del sistema. De nuevo aparece el concepto de cliente remoto/cliente local, ya que se debera permitir la creacin de histricos desde cualquier mquina. Para la generacin de histricos locales se ha diseado un protocolo especializado que sea capaz de pedir 500 variables por ejemplo al servidor, pero salteadas. Este detalle es importante, ya que hasta ahora slo se han especificado dos tipos de protocolos, uno a uno y uno a N (direccin y nmero de elementos consecutivos). Por tanto, si deseamos leer 500 variables que van desde la posicin 1 hasta la 8000, tendramos que realizar 500 transacciones para cada uno (protocolo uno a uno ) o leer 8000 variables por cada transaccin (protocolo uno a N). Por tanto, para dotar al sistema de eficiencia se opta por disear un nuevo tipo de protocolo.
Tambin hay que resaltar que la generacin de histricos se puede volcar sobre ficheros de Excel (LabView lo permite) o sobre ficheros de texto. La gestin de informacin en formato Excel es ms sencilla que en formato texto, pero es necesario mantener abierto el fichero abierto (que va almacenando el histrico en memoria) con el consiguiente aumento del uso de memoria RAM. Estoy podra ralentizar el sistema si se solicitan histricos de muchas variables y durante mucho tiempo. Para resolver este problema, el usuario podr generar histricos en formato Excel texto (extensin txt).
8. PROTOCOLOS EFICIENTES
Se detallan cada uno de los protocolos.
29
8.1. PROTOCOLO UNO A UNO
El tipo de mensajes que utiliza este protocolo se detall previamente. Por cada transaccin con el servidor, se realiza una operacin de lectura/escritura en BD y por ello, se pierde eficiencia. En teora de redes, este tipo de protocolo es del tipo enva y espera, como se indica en la figura 19. Este protocolo se usar cuando el nmero de elementos a leer escribir sea pequeo.
Mensaje de peticin
Tiempo de proceso
Mensaje de respuesta
Figura 19. Protocolo uno a uno 8.2. PROTOCOLO UNO A N
En este protocolo, por cada transaccin con el servidor, se puede escribir/leer N elementos en la BD. Esto es til para algunos de clientes que, por el tipo de transacciones que realizan con BD, necesitan escribir un gran nmero de elementos en BD y es muy eficiente si el nmero de elementos es consecutivo. Se aclara este protocolo con el siguiente ejemplo, para aquellos clientes que tengan que actualizar la posicin de los 1000 heliostatos, es decir, transmitirle a cada uno el ngulo de acimut y elevacin, y recoger de cada uno el acimut y elevacin real.
Esto implica lectura de 2000 elementos en BD, 1000 de acimut y 1000 de elevacin a transmitir a cada elemento del campo; la escritura de 3000 elementos, 1000 de acimut real, 1000 de elevacin real y 1000 para la actualizacin de estado. Lgicamente, la distribucin de estas variables de estado en BD es consecutiva, por lo que este protocolo es ideal para este tipo de clientes. Un ejemplo de cliente en nuestra aplicacin es Control Campo, como se muestra en la figura 20, que es el que se encarga de la comunicacin con el campo.
30
Mensaje de peticin
Mensaje de respuesta Tiempo de proceso
Figura 20. Protocolo uno a N En la figura anterior se ha representado un ejemplo de escritura de N elementos en BD. Comparndola con la figura anterior para el protocolo uno a uno, es lgico que el servidor necesite ms tiempo de CPU para la preparacin de datos de N elementos en vez de 1 elemento. Este protocolo se usa para la escritura/lectura de un nmero de elementos considerable.
8.3. PROTOCOLO PARA VARIABLES ALTERNATIVAS
Este tipo de protocolo se usa para leer/escribir un nmero elevado de variables no consecutivas. Por ejemplo, si se necesita leer 500 variables, donde la primera es la variable que ocupa la posicin 10 en la BD y otra, ocupa la posicin 8.000, se podra utilizar el protocolo uno a uno, que realizara 500 transacciones. Tambin es posible usar el protocolo uno a N, pero que para leer/escribir 500 variables se tiene que leer forzosamente 7990 variables y de stas hay que filtrar y escoger slo las que se necesitan. Por tanto, ninguno de los dos protocolos es el ms indicado. Parece adecuado el diseo de un tipo de protocolo, como se muestra en la figura 21, que haga eficiente este tipo de operaciones.
31
Mensaje de peticin
Mensaje de respuesta
Tiempo de proceso
Figura 21. Protocolo para variables alternativas
En esta figura se muestra el uso de este protocolo para una escritura de elementos en BD. Un ejemplo de clientes de la aplicacin que hagan uso del mismo, es Histrico Local, que se encarga de la generacin de histricos en la misma mquina en donde est la BD. En la configuracin de histrico, se debe indicar las variables que se desean. Por tanto, si el nmero de variables es grande y el intervalo de tiempo entre muestreos es pequeo, este protocolo se convierte en ideal para este tipo de clientes y hace eficiente esta operacin.
9. HISTRICOS
En un sistema SCADA para el control, supervisin y adquisicin de datos de un proceso industrial, en general, la generacin de histricos se hace imprescindible. En el caso particular de la planta solar, una de las muchas aplicaciones de los histricos sera el estudio del resultado de determinadas estrategias de control la evolucin meteorolgica a lo largo del da.
9.1. EXCEL VERSUS TXT
En este caso particular se genera histricos mediante dos posibilidades: volcado de datos sobre Excel sobre un fichero de texto. A continuacin, se comenta las ventajas e inconvenientes de cada uno. 9.1.1. GENERACIN DE HISTRICOS SOBRE UN FICHERO DE EXCEL Este mdulo tiene la funcin de pedir datos al servidor de BD peridicamente. Inicialmente arranca una ventana de configuracin que solicita las variables a las que se quiere obtener el histrico y el intervalo de tiempo que transcurre entre muestreos, es decir, entre peticiones de lectura al servidor.
32
Se hace uso de la facilidad que LabView ofrece de comunicacin con otras aplicaciones que corren sobre la misma mquina mediante protocolo DDE . Los requisitos que se necesitan son los siguientes:
3
1. Se necesita tener el programa Excel abierto, ya que de forma contraria, al arrancar el mdulo de histricos aparece un mensaje de error informando de que ha sido imposible establecer la comunicacin. 2. La generacin se hace sobre la hoja Excel abierta. Cabe la posibilidad de cerrar y abrir la hoja cada vez que se realiza un muestreo de las variables de BD. El problema es que se carga el sistema de forma innecesaria ya que cada cierto tiempo se tiene que abrir la hoja Excel, cargar los datos en memoria, hacer las modificaciones necesarias, es decir, actualizar la hoja, y finalmente, volver a cerrarla. Por tanto, la operacin se hace ineficiente. La solucin que se lleva a cabo consiste en abrir la hoja Excel y no cerrarla hasta que no finalice la generacin de histrico. De esta manera, se vuelcan los datos directamente sobre esta aplicacin. Estos datos se van cargando directamente sobre memoria RAM sin acceder al disco duro hasta la finalizacin del histrico.
En cuanto a los inconvenientes que se tienen:
1. El inconveniente principal que tiene la solucin descrita es que los datos se van almacenando temporalmente sobre memoria RAM. Esto quiere decir que si la generacin se programa para mucho tiempo y el nmero de variables es elevado, el uso de memoria del ordenador aumenta. Llegando a casos extremos, para un tiempo demasiado grande cabe la posibilidad de detectar mal funcionamiento en la mquina, incluso llegando a aparecer algn mensaje de error si el tamao de la hoja es demasiado grande. 2. El utilizar una hoja Excel hace que automticamente aparezcan las limitaciones del propio programa. Excel utiliza para las columnas, un byte de direccionamiento y para las filas, dos bytes de direccionamiento. El SCADA genera los histricos de la siguiente forma, cada columna muestra el histrico de una variable de la BD. Esto quiere decir que se podra generar como mximo el histrico de 256 variables. Para un nmero mayor, habra que volver a ejecutar el mdulo para poder programar ms variables. El lmite de filas impone una condicin sobre el tiempo mximo que se puede estar obteniendo informacin. Si se programa la generacin de histricos cada cierto tiempo T, el tiempo mximo que se puede estar generando histrico sera:
Tmax = 216 T = 65536 T
Acrnimo en ingls de Dinamic Data Exchange
33
Para un ejemplo de T = 10 seg:
Tmax = 65536 10 seg = 182 horas

El funcionamiento general de este cliente se detalla a continuacin:
Inicialmente, se abre una ventana de dilogo con el usuario donde se programa la generacin de histrico (intervalo de tiempo entre peticin de datos al servidor y variables). A continuacin, el mdulo Genera histrico se programa para pedir una peticin de lectura al servidor cada intervalo de tiempo programado. Esta peticin se inserta en la cola y es atendida por el servidor local, que accede a BD para realizar la operacin. El resultado se devuelve al mdulo a travs de una cola de salida. Este resultado es recogido y se guarda en la hoja Excel a travs de un dilogo mediante protocolo DDE con dicho programa. Este funcionamiento se detalla mediante la figura 22.
USUARIO
1
PROTOCOLO DDE
GENERA HISTRICO
6
SERVIDOR LOCAL
Figura 22. Generacin de histricos sobre un fichero Excel
34
Este ejemplo representa el funcionamiento de los histricos a nivel local. En el siguiente apartado se discute la opcin local frente a remoto. 9.1.2. GENERACIN DE HISTRICOS SOBRE UN FICHERO DE TEXTO Para resolver algunos de los inconvenientes de la generacin de histricos sobre fichero Excel se presenta una segunda opcin para la generacin de histrico. De esta forma, el usuario final, durante el trabajo cotidiano, segn el tipo de histrico (nmero de variables y tiempo programado) se podr elegir la opcin ms adecuada. Los requisitos que se necesitan son:
De la misma forma que se hizo para el primer tipo de generacin, los requisitos de esta segunda opcin son mnimos, ya que no es necesario tener abierta ninguna aplicacin, ya que el fichero de texto se puede abrir y modificar de forma transparente. En cuanto a los inconvenientes que se tienen:
Como principal inconveniente, se tiene la visualizacin directa de la informacin adquirida desde el fichero de texto, ya que no queda agrupada de la misma forma como en el caso de Excel. As como la manipulacin de los datos, que se hace ms difcil. En cambio, se resuelve los problemas de nmero mximo de variables y tiempo mximo, ya que no se tiene un lmite. Tambin se resuelve los problemas de aumento del uso de memoria RAM ya que el tamao que ocupa es pequeo (al ser texto) en comparacin con la hoja, junto con el programa Excel.
El esquema de funcionamiento es muy parecido al que se tena para la hoja de Excel, como se muestra en la figura 23.
FICHERO DE TEXTO
1 7
USUARIO
GENERA HISTRICO
6
2 3 5
SERVIDOR LOCAL
Figura 23. Generacin de histricos sobre un fichero de texto 35
9.2. LOCAL VERSUS REMOTO
En este apartado se pretende exponer las diferencias que existen entre la generacin de histricos de forma local frente a la remota, refirindonos a esta ltima a la generacin de histricos desde una mquina remota.
Hasta ahora se han introducido tres tipos de protocolos: protocolo uno a uno, uno a N y protocolo de variables no consecutivas. Este ltimo protocolo slo se ha diseado a nivel local, pensando que fundamentalmente la generacin de histricos se har desde el ordenador que tenga la funcionalidad MMI , esto es, desde CONTROL 3. En este ordenador reside tambin la BD, por tanto, es poco probable que se generen histricos desde otros ordenadores.
4
Debido a que es necesario cubrir todas las posibles alternativas y pensando en alguna opcin de programacin de histricos desde algn ordenador cuya funcin no sea sta, es decir, CONTROL 1 CONTROL 2, tambin se va a contemplar esta ltima posibilidad, pero no se ha diseado un protocolo de variables no consecutivas remoto, ya que, en principio, slo lo usara este cliente y no de forma usual. Por lo que, para este caso excepcional, se utilizar el protocolo uno a N que sustituya al anterior.
9.2.1. LOCAL
Segn lo que se ha comentado anteriormente, este protocolo est diseado para ser ejecutado en la mquina CONTROL 3, que es donde reside la BD. La torre de protocolos que se sigue en este caso es la que se muestra en la figura 24.
USUARIO FINAL EXCEL o TXT GENERA HISTRICO SERVIDOR LOCAL
Figura 24. Generacin de histricos de forma local El protocolo DDE se utiliza en caso de usarse la hoja Excel y la que se utilice para la generacin de histricos. La figura 24 sera la estructura que se tendra dentro de la misma mquina.
36
9.2.2. REMOTO
Para el caso de generacin de histricos desde una mquina remota, ya sea desde CONTROL 1 CONTROL 2 desde cualquier otra que tenga acceso a CONTROL 3, mediante el protocolo TCP/IP, la estructura de protocolos que se tendra sera la que se muestra en la figura 25.
USUARIO FINAL
EXCEL o TXT
GENERA HISTRICO MDULO ESPECIAL TRANSPORTE RED ENLACE NIVEL FSICO
SERVIDOR LOCAL CLIENTE ESPECIAL TRANSPORTE RED ENLACE NIVEL FSICO
Figura 25. Generacin de histricos de forma remota
Como protocolo de transporte/red se utiliza el protocolo TCP/IP. El protocolo que utiliza el subprograma mdulo especial con el mdulo cliente especial no se le ha dado un nombre especfico, pero es muy simple, ya que nicamente lo que se hace es establecer una conexin entre ambas mquinas por las que poder enviar datos. Tambin utiliza un modelo clienteservidor porque en la mquina local (donde reside BD), el mdulo cliente especial, se mantiene escuchando por el puerto, a la espera de establecimiento de conexin. Mientras que en la mquina remota, el mdulo especial es el que realiza la peticin de establecimiento de conexin.
Acrnimo en ingls de Man-Machine Interface
37
9.3. USUARIO DE HISTRICO
El histrico generado se puede visualizar directamente desde el fichero generado. En este caso la hoja de Excel es una opcin elegante para tal fin. Pero mantenindonos dentro del entorno del SCADA, y en concreto, del programa LabView, se necesita recoger los datos del fichero generado y presentarlos como una pantalla ms, como una opcin ms de la aplicacin. Por tanto, se necesita un nuevo subprograma que acceda al fichero de histricos, recoja los datos necesarios y los muestre en pantalla.
Desde el principio, y haciendo distincin entre las distintas divisiones del Proyecto, en esta parte se disea el entorno que necesita el cliente para acceder a cualquier servicio, pero nunca se especifica un cliente en cuestin, sino que siempre se ha presentado como una caja negra, en donde, a travs de un protocolo, hace la solicitud de una transaccin.
En este apartado tampoco se viola la filosofa seguida, pero s que se preparan los datos para que un usuario final slo tenga que representar esa informacin en pantalla. En concreto, se describe un subprograma que recoge los datos de un fichero y forma un vector de tiempos, por un lado. Por otro lado, se obtiene una matriz, donde cada fila corresponde al histrico de una determinada variable. Tanto el vector, como la matriz, son parmetros de salida que se le entregan a un cliente de histricos, como se muestra en la figura 26.
REPRESENTACIN HISTRICOS
CONFIGURACIN DE HISTRICOS
USUARIO DE HISTRICOS
GENERACIN DE HISTRICOS
Figura 26. Estructura de usuario de histrico En esta figura se pone de manifiesto la distincin entre cliente final y entorno de la aplicacin. Se han diseado los mdulos para que un cliente final pueda realizar la solicitud de un servicio
38
desde cualquier mquina, de forma transparente para l. El cliente final se ha representado en la figura con elipses y se representan como las cajas negras de las que se ha mencionado con anterioridad. En cambio, el entorno necesario para que un cliente pueda realizar una operacin se ha representado como cajas cuadradas. stas se han diseado en esta parte de la investigacin y de las que, ms adelante, en un apartado posterior, se describir el cdigo.
10. CONTROL CAMPO
Este es un cliente especial que por el funcionamiento del mismo, y por su importancia, se va a describir con detalle en esta parte del trabajo. Posteriormente se describir su protocolo.
10.1. FUNCIN
Este mdulo subprograma se encarga de actualizar la posicin de todos los heliostatos que conforman el campo. La actualizacin implica el envo de informacin en ambos sentidos. En el sentido control del campo, la informacin que se le puede enviar a cada elemento es diferente, segn la orden que se transmita.
10.1.1. RDENES Para cada orden, cada elemento del campo debe responder con el estado en el que se encuentra informacin que se le solicite en la orden. De esta forma, este estado sirve como acuse de recibo para el sistema SCADA.
1. Peticin de estado Esta orden no requiere transmisin de datos adicionales en el control, pero s requiere el envo de datos en el sentido de adquisicin de informacin, es decir, cada heliostato debe enviar informacin del estado en el que se encuentra.
2. Mover heliostato Esta orden requiere que el sistema SCADA enve, a cada heliostato del campo, informacin sobre la posicin que debe tomar. Esta posicin se le va a dar en forma de ngulos (acimut y elevacin). Cada heliostato responde con un byte de estado, informando el estado actual en el que se encuentra.
3. Buscar Cero Esta orden no requiere de transmisin de datos adicionales en el control. Cada elemento del campo responde con un byte de estado. Cada heliostato retorna a un estado inicial cero tras recibir esta orden.
39
10.1.2. ESTADOS
Los estados posibles en los que se puede encontrar un heliostato en el campo pueden ser los siguientes:
1. 2. 3. 4. 255.
Parado Movimiento Buscando fin de carrera Fin de carrera Imposible de comunicar (timeout).
A travs de la orden 3 (buscar cero), se llega al estado 3. En l se ordena al heliostato que retorne a una posicin inicial cero. Mientras se mueve hacia la misma, el estado es el 3. Cuando la consigue, el estado es el 4. Para entender mejor el funcionamiento de este mdulo, se presenta la figura 27.
COMUNI CACIN SERI E
1
CONTROL DE CAMP O
CALCULA
COORDENADA
Figura 27. Estados de los heliostatos
40
El funcionamiento de control campo consiste en repetir una serie de operaciones de forma peridica. Por tanto, se tiene un bucle que siempre realiza lo mismo. Las operaciones a realizar son las siguientes:
1. 2. 3. 4. 5.
Comprobar si hay alguna orden de campo. Obtener orden para cada heliostato. Calcula la posicin para cada heliostato. Enva orden para cada heliostato. Actualiza base de datos.
10.2. ORDEN DE CAMPO
Dentro del sistema de control de la planta solar, adems de enviar una orden a cada uno de los heliostatos, se pretende tener un sistema ms inteligente, en el que se pueda ejecutar macros que afecten a ms de un heliostato a todos, en general. En principio, se han reservado 500 variables para tal fin.
Un ejemplo de uso sera la orden abatimiento por seguridad, con la que todos los heliostatos se abatiran por diversos motivos, por ejemplo, gran velocidad del viento, posicin de limpieza, en la que todos parte se colocaran en posicin especial para que el personal de mantenimiento realice funciones de limpieza de los espejos. Por tanto, el mdulo control de campo, en primer lugar, comprueba que no hay ninguna orden de campo; en caso contrario, realizara la accin adecuada a cada orden.
10.3. ORDEN DE HELIOSTATO
El mdulo de control, una vez comprobado que no existe ninguna orden de campo, lee de BD la orden para cada heliostato (1000 rdenes). Es apropiado en este tipo de operaciones que se utilice el protocolo uno a N, ya que en una sola transaccin con el servidor, se logra leer 1000 variables.
10.4. CALCULA COORDENADA
Dependiendo del tipo de orden, puede que haga falta la nueva posicin a la que deba apuntar cada elemento del campo. Incluso sin llegar a hacer falta, se procede al clculo de la nueva posicin, ya que al final del subprograma hay que actualizar la BD y en esta actualizacin tambin se ve afectada las variables relacionadas con acimut y elevacin. Este mdulo calcula los nuevos ngulos de acimut y elevacin a partir de unos determinados parmetros, como puede ser la posicin de cada heliostato en el campo la posicin del Sol.
41
10.5. ENVO DE ORDEN A HELIOSTATO
Esta es una operacin crtica en el sistema, ya que debe comunicarse con cada heliostato, transmitir la nueva orden y obtener estado. Para ello, esperar un byte que le enva el elemento en cuestin.
La comunicacin con cada espejo debe realizarse en el menor tiempo posible. Para un total de 1000 heliostatos, si por cada heliostato se consume 20 milisegundos, se tardara un total de 20 segundos en actualizar la posicin de todo el campo.
El mdulo de control hace uso de un mdulo de comunicacin, al que pasndole una direccin de elemento y la orden correspondiente, devuelve un byte de estado. Este mdulo no se describe con detalle en esta parte de la investigacin.
10.6. ACTUALIZACIN DE BASE DE DATOS
Tras concluir la comunicacin con el campo de heliostatos, es necesario actualizar la BD. Se actualiza el estado de cada heliostato, orden, acimut, elevacin, orden de campo... etc. Es necesario actualizar orden de heliostato ya que en caso contrario, se volvera a ejecutar la misma orden. Este es un aspecto importante, pues debe haber un sincronismo entre actualizacin de orden por parte del control campo y del mdulo de usuario, que a partir de la informacin transmitida por el personal de control de la Planta, actualice la nueva orden para cada elemento. Tambin es necesario actualizar rdenes de campo, si hubo, por el mismo motivo por el que se actualiza orden de heliostato.
10.7. TORRE DE PROTOCOLOS
Segn se ha especificado en el funcionamiento de este mdulo, existe dos flujos diferentes de informacin, uno de ellos consiste en la transaccin de informacin con BD, ya sea para escribir para leer variables, y otro, la actuacin sobre el campo, operacin importante ya que es la que da nombre al sistema SCADA (Supervisin, Control y Adquisicin de Datos). Con este ltimo flujo de informacin se tiene el control y la adquisicin de datos del proceso planta solar. La supervisin del sistema no se contempla en este trabajo y es relativamente sencilla, ya que slo se tiene que supervisar que determinadas variables de BD no sobrepasen determinados lmites.
El esquema que se plantea para este mdulo se recoge en la figura 28.
42
CONTROL CAMPO HELIOSTATOS MDULO ESPECIAL TRANSPORTE RED ENLACE NIVEL FSICO
SERVIDOR LOCAL CLIENTE ESPECIAL TRANSPORTE RED ENLACE NIVEL FSICO
Figura 28. Torre de protocolos
10.7.1. UN CASO DE LECTURA
En el diagrama de la figura 29 se detalla el tipo de informacin que pasa de unos mdulos a otros y entender mejor el proceso de encapsulacin en el que se ven involucrados los datos. Esta informacin ser de gran utilidad para posteriormente entender el cdigo.
Para un caso de lectura, el mdulo de control de campo, enva un paquete normal, de tamao constante, similar al que se enva cuando se quiere leer un slo elemento. Este paquete permanece invariable hasta llegar al servidor.
En el servidor tiene lugar la lectura de los elementos que se indican en el mensaje, comenzando por el elemento de posicin index y para un total de Tam elementos. A esta informacin se le aade la identificacin de peticin y se enva de vuelta al origen. Cuando llega a cliente especial, el tamao de los datos no es la usual, por tanto, es necesario calcularlo para que en el destino se pueda extraer correctamente los datos del puerto.
Una vez que los datos estn en mdulo especial, se le quita la longitud, ya que sta no es necesaria para la extraccin por parte del mdulo de control.
43
1
ID
CONTROL CAMPO
ID
SERVIDOR LOCAL 6
ID
Datos_variables
4
ID
F C lect Relleno Index Tam 44 1 4 5 5
Datos_variables
<variable> <variable>
MDULO ESPECIAL 5
ID
Long_Datos Datos_variable 4 <variable>
CLIENTE ESPECIAL
ID
Figura 29. Un caso de lectura en el flujo de informacin En este diagrama no se ha incluido las capas que estn por debajo de mdulo especial/cliente especial, ya que el servicio de transporte es ofrecido directamente por LabView.
10.7.2. UN CASO DE ESCRITURA
Para el caso de escritura en BD, el mdulo de control de campo solicita una transaccin en la que se realice la escritura de un determinado nmero de elementos. El tamao del mensaje no es el tpico, ya que a ste hay que aadirle al final las variables que se quieren escribir (que forman un parte del mensaje de longitud variable, en funcin del nmero de elementos). Antes de ser enviado a la mquina que contiene el servidor local, mdulo especial debe aadir al mensaje la longitud de los datos variables, para que de esta forma en el destino se pueda extraer de forma adecuada el paquete.
Cuando el mensaje est en destino y ha sido extrado por cliente especial, llega al servidor local, que atiende este servicio especial. Tanto en lectura como en escritura, para solicitar este
44
servicio, se usa un ID (identificacin de la peticin) especial y el cliente debe ser tambin especial (C).
El servidor atiende la peticin y devuelve un mensaje similar al que se devuelve con la escritura de un elemento (en principio no hay ninguna diferencia). Cuando el mensaje llega a cliente especial, ste aade longitud aunque aparentemente no se debera hacer. De esta forma se consigue que en destino, mdulo especial pueda distinguir un caso de lectura/escritura de N elementos, cualquier otro caso, con el parmetro longitud. Si longitud = 0 (como es el caso), se trata de un caso de escritura de un determinado nmero de elementos en BD. Una vez extrado el mensaje y diferenciado la lectura de la escritura, se le extrae el parmetro longitud y se entrega al mdulo de control de campo que usa este ID como acuse de recibo (confirmacin de que la escritura se ha hecho de forma adecuada). En la figura 30 se muestra el caso de escritura.
1
ID
F C esc Relleno Index Tam 44 1 4 5 5
CONTROL CAMPO 6
ID
Relleno 14
SERVIDOR LOCAL 4
ID
ID
Relleno 14
Datos_escritura <variable>
Datos_escritura <variable>
MDULO ESPECIAL 5
ID
Long = 0 4
CLIENTE ESPECIAL
ID
Long_Datos Datos_escritura 4 <variable>
Figura 30. Un caso de escritura en el flujo de informacin
45
11. DESCRIPCIN DEL CDIGO En este captulo se hace una descripcin del cdigo de todos los conceptos tericos que se expusieron en el captulo anterior, por ejemplo, la descripcin del servidor de local que gestiona las transacciones a BD, el cliente Control de Campo, la generacin de histricos... etc. Adems de esta descripcin, en cada Virtual Instrument perteneciente a la aplicacin se especifica cierta informacin de funcionamiento.
11.1. SERVIDOR LOCAL
En la figura 31 se muestra el panel frontal de la aplicacin:
Figura 31. Panel frontal de servidor local A primera vista, de cara al operador es bastante simple, en el que slo se puede configurar los tamaos de las colas. Existe un botn de STOP que para el servidor. Como se mencion en la descripcin terica de la aplicacin, para realizar una peticin al servidor, existen dos colas, una de entrada donde los clientes introducen las solicitudes y una de salida, donde el servidor inserta el resultado de las peticiones.
Con Tam_cola y Tam_cola 2, se configura el tamao de estas colas. Este tamao debe ser pequeo, para que el tiempo de gestin de cola sea pequeo. Con un valor de 10 para ambas
46
es suficiente, ya que el servidor es demasiado rpido y es difcil encontrar elementos en cola de entrada y salida.
Numeric es un indicador de los pasos que est realizando el servidor, de esta forma si tiene muchas peticiones, numeric se va incrementando rpidamente. En otro caso, este aumento es a una velocidad muy baja. Estos incrementos cada cierto tiempo, cuando el servidor est en vaco, se deben a un timeout con el que se ha diseado el subprograma y de esta forma as poder sacar al servidor de la espera del evento y evitar la espera infinita del mismo. A continuacin, en la figura 32, se muestra la parte de programacin del servidor local, es decir, el diagrama de bloques del subprograma.
Figura 32. Diagrama de bloques del servidor local Esta primera pantalla corresponde a la fase de iniciacin del servidor. Como se detall en la descripcin terica del captulo anterior, se ha dimensionado una BD para 10000 variables. Estas se inicializan con un valor de relleno (*).
Al botn de parada se le ha asociado una variable global. Esta es la forma de poder trabajar con varios bucles en paralelo y poder pararlo desde uno de control. El problema es que al ser una variable global, al comenzar la ejecucin del programa, la variable recuerda el valor de la ltima ejecucin. En la figura 33 se muestra la pantalla que representa la estructura bsica del gestor de BD.
47
Figura 33. Estructura bsica del gestor de base de datos del servidor local Una de las ventajas de LabView es la programacin modular. Para el diseo del servidor se ha hecho uso de esta posibilidad, es decir, se tiene dos bucles, uno de control y otro de trabajo normal.
Antes de entrar en los bucles, se inicializan las colas (Q1 y Q2). Q1 es la cola de entrada de peticiones y Q2, la cola de resultado de las mismas.
1. BUCLE DE CONTROL
Comprueba el estado de las colas (nmero de elementos) y los muestra al operador, por un lado, y por el otro, lee el valor de las variables de entrada STOP, que es una variable de tipo booleano. Esta variable es la que refresca el valor de la variable global asociada a ella y que ser la que pare el bucle de operacin.
Si el operador pulsa el botn de STOP, el subprograma se sale por el bucle de control y finaliza con la destruccin de las colas creadas al inicio. Este evento cambia el estado de la variable global y cambia a FALSE la condicin del bucle de operacin.
48
2. BUCLE DE OPERACIN
Este bucle es muy importante para el desarrollo adecuado del trabajo, ya que debe ser dinmico, en el sentido que debe ajustar la velocidad a la cantidad de carga, es decir, ir rpido cuando haya peticiones por atender y despacio cuando no las haya. Se hace necesaria la programacin orientada a eventos en la que se debe esperar al evento insertar elemento en cola para que acte el servidor. Este efecto se consigue con la accin que se muestra en la figura 34.
Figura 34. Ejemplo de programacin orientada a eventos Esta operacin que tiene lugar en el bucle es equivalente a lee_elemento_cola si hay y si no espera 5000 ms (5 segundos). De esta forma, si hay elementos en cola el bucle atiende con velocidad alta y si no, cada cinco segundos, se sale (timeout = 5 segundos). Por tanto, de la espera del evento se puede salir por dos motivos:
a)
Ningn cliente insert elementos en cola y se activ el timeout.
Esto quiere decir que el bucle no debe hacer nada. Por tanto, el resultado de lee_cola (timeout) debe entrar en un IF un CASE. Si es falso debe dejar BD igual, y no debe afectar la condicin del bucle, es decir, la condicin se compone de:
VARIBLE GLOBAL PROBLEMAS DURANTE LA OPERACIN
Por tanto, si no hay elementos en la cola, la condicin de problemas durante la operacin no debe afectar a la condicin del bucle; si se sale de ste, que sea porque hubo alguna modificacin en la variable global. Esto se especifica con ms detalle en la figura 35.
49
Figura 35. Caso de no insercin de elementos en cola en la salida de la espera del evento b) Algn cliente insert elementos en cola y la peticin ha sido leda. Este caso se refleja
en la figura 36.
Figura 36. Caso de insercin de elementos en cola en la salida de la espera del evento En este caso, se atiende la peticin. Para ello se ejecuta el subprograma Atender_cola.vi cuyo icono corresponde a Serve cola. En este caso, hay que comprobar que no hubo problemas durante la operacin y, si los hubo, que se salga del bucle, modificando la condicin de salida.
50
La lnea gruesa del color rosa representa toda la base de datos. Es un vector de variables cadena de caracteres de tamao 10000. Se dise de esta manera para que se pueda insertar en un elemento cualquier valor, ya sea numrico, una fecha... etc. simplemente haciendo la correspondencia a cadena de caracteres (String). Adems de esta forma se aprovecha el formato String que es obligatorio utilizar para insertar en elementos en colas enviar informacin a travs de la red (por ejemplo, mediante TCP / IP).
11.1.1. ATENDER COLA
En este apartado se va a explicar el panel frontal y el diagrama de bloques de este mdulo.
1. FRONT PANEL
Se muestra en la figura 37 esta pantalla.
Figura 37. Panel frontal del mdulo ATENDER COLA
En esta pantalla, nicamente se visualizan los parmetros de entrada y de salida de entrada/salida de este mdulo. Por ejemplo, la cola de escritura debe ser un parmetro de
51
lect/esc. Esto se consigue con dos variables, una de control (funcin de entrada) y otra indicadora (funcin de salida). Otra variable de entrada/salida es BD (in, entrada y out, salida). Tambin se pasa el elemento que se ha ledo y se saca la identificacin de la peticin (variable de tipo indicador).
2. BLOCK DIAGRAM
Figura 38. Diagrama de bloques del mdulo ATENDER COLA Una vez que se ha ledo una peticin de la cola, se separa la identificacin de la peticin y de la peticin en s, y ambas cosas se introducen en un nuevo subprograma mdulo cuyo incono se ha llamado gesti uno. Despus de la gestin del elemento, se inserta el resultado en la cola de salida, como se muestra en la figura 39.
52
Figura 39. Insercin de un elemento en la cola de salida El mdulo Gestiona_uno se encarga de procesar la peticin, como se muestra a continuacin.
11.1.1.1. GESTIONA_UNO
En este apartado se va a explicar el panel frontal y el diagrama de bloques de este mdulo.
1. FRONT PANEL
Figura 40. Panel frontal del mdulo GESTIONA UNO
53
Esta pantalla no muestra mucha informacin como suele ocurrir en los mdulos intermedios. Los parmetros que aparecen son del siguiente tipo:
BD_*: parmetro de entrada/salida (actualizacin de la BD).
Output Array: es una variable auxiliar que realiza funciones de visualizacin del resultado y obliga a que el vector que se pasa a una estructura FOR sea de una determinada forma (con unos determinados dgitos de precisin).
ID_*: parmetro de entrada/salida (identificacin de peticin).
String_*: parmetro de entrada/salida (peticin con formato String).
2. BLOCK DIAGRAM
Figura 41. Diagrama de bloques del mdulo GESTIONA UNO Este mdulo es importante en el procesamiento de la peticin ya que distingue varios casos y si se trata de una transaccin de lectura escritura. En principio, la peticin en formato String se transforma en F C lect/esc Valor. Esto se hace a travs de un subprograma sencillo:
54
Transforma_String. El siguiente paso es distinguir si se trata de una peticin especial, es decir, si se va a usar el protocolo uno a uno uno a N. Esto se hace a travs de C. Con este parmetro se va a identificar los distintos tipos de cliente. Para C=9999, se trata de un caso especial en el que se va a usar el protocolo uno a N el protocolo de variables no consecutivas.
Si se trata de una peticin especial (C=9999) hay que distinguir el caso de protocolo uno a N de variables no consecutivas. Esto se hace con ID de la peticin, ya que para ID = 1, se trata del protocolo de variables no consecutivas y para ID = 0, se usar el protocolo uno a N.
PROTOCOLO UNO A N
Con la identificacin de la peticin se entra en un Case. Para el caso 0, se trata de este protocolo en cuestin. La peticin se procesa de nuevo, ya que en Transforma_String se proces una peticin normal de un elemento. Se obtiene un index y un tamao, que se utilizar para escribir/leer en BD. Con la variable que recoge el caso de lect/esc se entra en un IF CASE para distinguir cada caso.
Si se trata de una lectura, simplemente hay que obtener un vector final que contenga el resultado. Para ello se lee de BD a partir de index, un nmero total de Tam elementos. Como se puede observar en la figura 42, la BD no se modifica.
Figura 42. Caso de lectura en el protocolo uno a N del mdulo GESTIONA UNO 55
Para una escritura, hay que sacar los elementos de la peticin que de alguna forma el cliente haya insertado. La peticin se compone de index + offset + valores a esc. Los valores a esc se transforman de formato String al formato adecuado (DBL, con un nmero determinado de dgitos de precisin) y se introduce en un FOR para realizar la escritura.
Todos los elementos se escriben en BD a partir de la posicin index. La BD se modifica en la estructura FOR. Para hacer ms rpida la operacin de escritura se ha aadido un shift register que de alguna forma evita que LabView trabaje en paralelo, es decir, con todo el vector (10000 elementos) en cada transaccin y mantenga una copia de la misma, con lo que en cada paso slo se trabaja con un elemento, para dar al final el vector BD actualizado.
Este concepto es muy importante a la hora de trabajar con LabView porque si el programador no est muy experimentado con la aplicacin puede ocurrir que en tiempo de ejecucin se maneje un volumen de datos mucho mayor de lo que se desea, con lo que se ralentiza mucho el sistema. Esto se plasma en la figura 43.
Figura 43. Caso de escritura en el protocolo uno a N del mdulo GESTIONA UNO
56
PROTOCOLO DE VARIABLES NO CONSECUTIVAS
El mdulo gestiona_uno distingue este protocolo si se tiene las siguientes condiciones: C = 9999 ID = 1 Con C distinguimos si se trata de un caso especial y con ID, dentro del caso especial, si se trata del protocolo en cuestin. Este protocolo se ha diseado nica y exclusivamente para un cliente (genera histricos), como se muestra en la figura 44. Este cliente lee de la BD un nmero grande de variables que no tienen por qu estar consecutivas. Por tanto, como es usado por este cliente, slo se presenta el caso de lectura. En posteriores revisiones se podra completar este mdulo con el caso de escritura para este protocolo.
Figura 44. Caso de lectura en el protocolo de variables no consecutivas
El funcionamiento es muy simple, ya que despus de sacar F C lect / esc, lo que queda de la cadena de caracteres son los valores en formato string. Con estos valores se forma un vector. Para ello se usa una caja que ya ofrece LabView, con la que a partir de una cadena, nos da una matriz. Al tratarse de un vector, slo nos interesa la primera fila, por lo que deshabilitamos la opcin columna y se escoge la fila cero.
nicamente resta de leer de BD y para ello, se usa una estructura FOR. Con el resultado se crea una cadena de caracteres de salida, que tiene como cabecera el ID inicial.
57
PROTOCOLO UNO A UNO
Para terminar con este mdulo, hay que distinguir el caso de transacciones en las que slo se ve involucrado un elemento. Para usar este protocolo se necesita que se den las siguientes condiciones: C distinto de 9999 Es decir, C = 9999 se ha reservado para transacciones especiales. Simplemente con un C distinto de ese valor, se usar el protocolo uno a uno.
Este protocolo es sencillo, ya que una vez visto los anteriores, la escritura lectura de un solo elemento es ms sencilla. A continuacin se muestra, en la figura 45, la lectura de un elemento de la BD.
Figura 45. Caso de lectura en el protocolo uno a uno Se puede comprobar que BD permanece invariable y que en la peticin la lectura se ha solicitado de la siguiente manera: F C lect/esc Relleno. Se ignora el relleno en este caso. Para la escritura, en lugar de relleno, el cliente enva el valor que desea escribir en BD, como se muestra en la figura 46.
58
Figura 46. Caso de escritura en el protocolo uno a uno Para formar la cadena de caracteres a enviar, se usa la identificacin de la peticin y un valor de relleno para completar el tamao del paquete enviado.
11.1.1.1.1. TRANSFORMA STRING
Para finalizar con el mdulo del servidor local, nicamente resta por describir la funcin que realiza este mdulo.
1. FRONT PANEL Se muestra en la figura 47 esta pantalla.
Figura 47. Panel frontal del mdulo TRANSFORMA STRING
59
En el panel frontal hay una variable de entrada y el resto de variables son de salida. La variable de entrada es la cadena de caracteres que se obtiene de la cola, a la que previamente ya se ha separado la identificacin de la peticin. Como parmetros de salida se tiene:
Fila: parmetro que se usa como direccin de la posicin a leer/escribir de BD.
Columna: parmetro que distingue entre clientes.
Lectura/Escritura: parmetro que indica si se trata de una transaccin de lectura de escritura. Valor: parmetro que contiene el valor de la variable a escribir relleno si se trata de una lectura.
El funcionamiento de este subprograma se deduce a primera vista con slo observar los parmetros de entrada y de salida. Este mdulo se encarga de procesar la peticin, es decir, obtener la informacin til de la cadena de caracteres que se extrae de la cola de entrada al servidor local.
2. BLOCK DIAGRAM
Figura 48. Diagrama de bloques del mdulo TRANSFORMA STRING
60
El diagrama de bloques es muy simple, ya que LabView ofrece herramientas potentes para trabajar con cadenas de caracteres. En concreto, la herramienta de la que se hace uso en este mdulo es Scan from String, que permite obtener informacin encapsulada en una cadena de caracteres. A esta caja se le puede pasar un parmetro de configuracin de la cadena y simplemente obtener las salidas deseadas, como se muestra en la figura 49.
Esta herramienta tambin permite extraer algunos parmetros y dejar el resto de la cadena invariable. Esto es til, ya que la peticin puede usar cualquier protocolo. El comienzo de toda peticin es idntico, lo que vara es el final. Por tanto, el comienzo lo procesamos y dejamos el final invariable.
Figura 49. Herramienta Scan From String
Figura 50. Herramienta Format Into String 61
Otra herramienta tambin muy til y que la usar todo cliente para encapsular los datos, es la que realiza el proceso inverso. Se trata del mdulo Format into String, como se muestra en la figura 50.
11.1.2. RESUMEN DEL MDULO SERVIDOR LOCAL
En este apartado se ilustra un esquema de mdulos que se usan en el programa servidor local, como se muestra en la figura 51.
SERVIDOR LOCAL
GLOBAL_ESC
ATENDER_COLA
Gestiona_uno
Transforma_String
Figura 51. Esquema de mdulos del programa servidor local
Las variables globales en LabView se gestionan como un mdulo ms, pero algo especial, porque no tiene diagrama de bloques. En este mdulo iran todas las variables globales del sistema. En particular, para el servidor local, se ha usado una sola variable global que sirve para parar el programa. Esta variable global reside en el Virtual Instrument como Global_esc.vi.
11.1.3. PROTOCOLO DE COMUNICACIN CON SERVIDOR LOCAL
Una vez presentado el servidor local y su funcionamiento, en este apartado se describe el protocolo de comunicacin con el servidor local para los distintos escenarios, es decir, para una transaccin de un elemento (tanto a nivel local como remoto), para una transaccin de N elementos (tanto a nivel local como remoto) y el protocolo de variables no consecutivas.
62
11.1.3.1. PROTOCOLO UNO A UNO
11.1.3.1.1. LOCAL
Para poder realizar una lectura/escritura con la BD desde la misma mquina en la que reside el mdulo que tiene que existir en el programa del cliente, debe hacerse de la siguiente forma.
1. FRONT PANEL
Figura 52. Panel frontal del protocolo uno a uno local
El usuario que quiera realizar una escritura/lectura de un elemento a nivel local, solamente debe escribir una cadena (con el formato adecuado) y aadir una identificacin a esa peticin. Cuando se ejecute el subprograma tendr la certeza de que se ha realizado su peticin, ya que si lo desea podr disponer de la identificacin de su peticin como parmetro de salida (acuse de recibo) y el valor deseado en caso de lectura, relleno en caso de escritura.
2. DIAGRAMA DE BLOQUES
El usuario deber insertar, en la cola de entrada del servidor, una peticin con el formato adecuado (F C lect/esc Valor). La ejecucin se divide en tres partes: La primera de ellas consiste en la insercin de los datos en la cola de entrada, a los que previamente se les ha realizado el procesado adecuado, es decir, se le ha aadido la identificacin de la peticin, como se muestra en la figura 53.
63
Figura 53. Insercin de los datos en la cola de entrada
Antes de insertar los datos en cola, es necesario abrir crear la misma. Esta funcin la realiza la caja Create_queue.vi que devuelve un puntero identificacin de la cola especificada, si existe, crea una cola nueva, si no existe.
Es necesario que para un correcto funcionamiento de la aplicacin se arranque en primer lugar, el servidor, es decir, que sea ste el que controle la creacin de las colas, ya que es ste el que la destruye cuando finalice la ejecucin del mismo. En otro caso, un cliente crea una cola que todava no existe y esperara indefinidamente, ya que no hay servidor que atienda la cola. En este caso debera aparecer un mensaje de error algo parecido, como se muestra en la figura 54.
64
Figura 54. Creacin de colas por parte del servidor La segunda parte de ejecucin del protocolo consiste en mantenerse a la espera mientras el servidor atiende la peticin. Esto se implementa mediante un bucle al que se le aade una temporizacin para evitar sobrecargar el sistema ya que en caso contrario el bucle ira demasiado rpido (se ejecutara demasiadas veces) mientras se est a la espera del servicio, como se muestra en la figura 55.
Figura 55. Mantenimiento a la espera mientras el servidor atiende la peticin
65
En esta parte del protocolo, el cliente permanece a la espera mientras el servidor est realizando el servicio. En cada iteracin del bucle, se solicita el estado en el que se encuentra la cola de salida. Se mira el nmero de servicios que hay en la misma y se compara la identificacin del servicio con la propia. Si fuese igual, se extrae el elemento de la cola, en otro caso, se deja la cola invariable, ya que se trata de un servicio a otro cliente. Por tanto, la importancia de la identificacin de la peticin es grande, ya que si dos clientes realizan la solicitud con el mismo ticket se corre el riesgo de interferir uno en el otro.
Finalmente, la ejecucin de la ltima parte del protocolo implica que hubo una respuesta a la solicitud realizada, ya que la identificacin de la misma coincide. El siguiente paso ser extraer la informacin y pasarla al programa principal del cliente como parmetro de salida, como se muestra en la figura 56.
Figura 56. Respuesta a la solicitud realizada 11.1.3.1.2. REMOTO
Para el caso de una peticin de una transaccin con BD desde una mquina en la que no reside la misma, es necesario construir todo una torre de protocolos en la que la mquina remota se pueda comunicar adecuadamente con la mquina local. Este tipo de protocolos se detalla en el apartado siguiente cuando se describa el cdigo del mdulo especial y cliente especial al que se hace referencia en la descripcin terica.
66
11.1.3.2. PROTOCOLO UNO A N
11.1.3.2.1. LOCAL
Para este caso se ha diseado el mdulo Index_offset.vi. Este mdulo se encarga de realizar el procesamiento adecuado de los datos para insertarlos en la cola y que el servidor local los pueda entender.
1. PANEL FRONTAL
Figura 57. Panel frontal del protocolo uno a N local Los parmetros que aparecen en este mdulo son los siguientes:
Offset: es un parmetro de entrada que se utiliza para indicar la direccin de comienzo de la escritura/lectura de variables en BD (entrada).
Tam: nmero de elementos en esta transaccin (entrada).
Lect/Esc: indica si la transaccin es de lectura de escritura.
Array esc: parmetro de entrada. Mediante este array se pasan los valores en un caso de escritura.
Resultado: parmetro de salida que contiene el resultado de la transaccin (relleno en caso de escritura los valores en formato adecuado en caso de escritura).
67
2. BLOCK DIAGRAM
Figura 58. Diagrama de bloques del protocolo uno a N local
El funcionamiento de esta ventana es distinto en caso de lectura escritura, evidentemente. Para el caso de escritura en BD, como se muestra en la figura 59, el array de valores hay que convertirlo a formato String (cadena de caracteres). Para ello, LabView ofrece una herramienta que realiza esta operacin directamente, indicndole nicamente la configuracin de los datos que se le est pasando. Junto a esta transformacin de datos, se tiene un procesamiento de la peticin de escritura, en la que se convierte los parmetros de entrada offset y tam a la estructura adecuada y el resultado se une a la cadena con los valores a escribir. Al resultado final se le coloca una cabecera y ya est listo para escribir en la cola de entrada al servidor. Finalmente el formato del mensaje que se inserta en la cola, tiene el siguiente formato: F C lect/esc 0000 Offset Tam Valores_a_escribir Este valor se inserta en la cola con el mdulo Cliente_index_offset.vi. Para el valor de lectura, el array de valores a escribir se ignora.
68
Figura 59. Escritura en la base de datos El mdulo Cliente_index_offset.vi consiste en la insercin en la cola de un valor y esperar el resultado. Se trata de un caso especial (C=9999 y ID = 0). La insercin en la cola de entrada se hace de la siguiente manera, como se muestra en la figura 60, 61 y 62.
Figura 60. Insercin en la cola de entrada del servidor local
69
Figura 61. Espera del resultado de la transaccin
Figura 62. Extraccin del mensaje con los valores ledos relleno En estas imgenes se ha representado el proceso de insercin del mensaje en la cola de entrada del servidor local, espera del resultado de la transaccin y finalmente, la extraccin del
70
mensaje con los valores ledo, para el caso de lectura, relleno, si se trata de una escritura en BD. Se separa la identificacin de la peticin y la cadena de caracteres con el resultado, y se entrega de forma separada al cliente (ascendiendo en la torre de protocolos).
11.1.3.2.2. REMOTO
Se ve en el siguiente apartado ya que es necesario introducir algunos elementos que afectan directamente a la comunicacin entre mquinas distantes.
11.1.3.3. PROTOCOLO DE VARIABLES NO CONSECUTIVAS
Se trata de un protocolo adaptado a un determinado tipo de cliente. El cliente en cuestin, es el que se encarga de la generacin de histricos. El programa inicialmente presenta una pantalla para la configuracin de la generacin, como se muestra en la figura 63.
Figura 63. Pantalla de configuracin de generacin de histricos
71
En la configuracin, se puede programar las variables de la BD que interesan, as como el tiempo de muestreo y el lugar en disco duro donde se guarden los ficheros, pero no aparece el nombre. En este caso, se genera un fichero con un nombre que sigue el siguiente formato:
aammdd.xls aa: ao mm: mes dd: da
De esta forma, cuando empiece un nuevo da, se cierra el fichero actual de histricos y se abre uno nuevo. As se evita que la memoria RAM del computador aumente de forma descontrolada pudiendo afectar incluso al funcionamiento interno.
Lo ms interesante del cdigo en lo que concierne a esta parte del proyecto, es el acceso a BD. Para esto, se tiene que generar un paquete de datos especial, en el que se hace uso de un cliente especial, como se muestra en la figura 64.
Figura 64. Acceso a la base de datos
Fila: 0 Cliente: 9999 Lect/Esc: 0 (lectura)
El resto del paquete que constituye el protocolo de variables no consecutivas est formado por un vector que contiene las posiciones que se desean muestrear. Esta informacin se transforma a cadena de caracteres y se accede a la cola de peticiones del servidor local.
72
Como se puede observar, el acceso es local, pero aadiendo ms informacin podra transformarse a remoto. Debido a que normalmente el tiempo de muestreo es muy grande en comparacin a la frecuencia interna del ordenador, este mdulo carga muy poco el sistema, de ah que resida en la misma mquina que la BD.
El programa que gestiona la cola de acceso a BD tiene que distinguir si se trata de un cliente especial no, es decir, distinguir entre protocolos, como se muestra en la figura 65.
Figura 65. Distincin de protocolos en el programa que gestiona la cola de acceso a base de datos
Aunque ya se ha descrito con anterioridad este mdulo, se puede observar que se distingue entre protocolos. Si el cliente ( protocolo) es 9999, entonces se trata de un cliente especial, y como tal, necesita un tratamiento especial. La trama se extrae inicialmente igual que siempre (Fila Columna lect / esc). El resto de informacin es necesario transformarla a vector y realizar tantas lecturas de BD, como tamao tenga el vector, ya que cada componente constituye la direccin a leer. Finalmente el resultado se empaqueta junto con la identificacin del proceso para, finalmente, insertarla en la cola de resultado de peticiones.
La pantalla principal de este mdulo ser mostrada al tcnico de la planta. Adems tiene otras funciones que no se han descrito en este apartado, ya que la informacin extrada es
73
comparada con unos determinados lmites. Si se sobrepasan, entonces, se genera una ALARMA SONORA que, a modo de ejemplo, se ha configurado como un pitido.
11.2. DESCRIPCIN DE CLIENTES
11.2.1. CLIENTES INVOLUCRADOS EN EL ACCESO REMOTO
Antes de empezar con la descripcin del cdigo de los mdulos involucrados, es interesante retomar una figura que ya se ha descrito anteriormente, como se muestra en la figura 66.
CLIENTE REMOTO SERVIDOR LOCAL

ID Lista valores ID ID Lista valores F C lect Index Tam Relleno
ID F C lect Index T am Relleno
MDULO ESPECIAL
ID F C lect Index Tam Relleno ID Longitud Lista valores ID Longitud
CLIENTE ESPECIAL
ID Lista valores F C lect Index Tam Relleno
MQUINA REMOTA
MQUINA LOCAL
PROTOCOLO TCP/IP
Figura 66. Flujo de informacin para lectura en BD con protocolo uno a uno Se trata de una peticin de lectura de N elementos al servidor local. En el sentido cliente a servidor, el paquete intercambiado tiene tamao constante, con lo que al transcurrir por la torre de protocolos, cada nivel no necesita aadir informacin. El sentido inverso, s es necesario introducir un campo a nivel de servidor_remoto.vi y cliente_remoto.vi (ya que as es como se ha identificado a los subprogramas) , respectivamente, cliente especial y mdulo especial (como se ha identificado en la descripcin terica del trabajo). A la informacin intercambiada a este
74
nivel es necesario aadirle la longitud ya con el resultado de la transaccin se forma un paquete que tiene tamao desconocido, al menos, no predecible.
1. SERVIDOR REMOTO
A efectos de la comunicacin entre mdulo especial y cliente especial, uno de los dos tiene que permanecer a la escucha y el otro, el que inicia la comunicacin. Por tanto, el que permanece a la escucha hace las funciones de servidor, ya que siempre est a disposicin del otro, siempre permanece a la escucha en un puerto determinado, y de ah es de donde le viene el nombre al subprograma. Todo esto se muestra en la figura 67.
Figura 67. Caso de servidor remoto El mdulo consiste en un bucle infinito y permanece siempre a la espera, escuchando en el puerto durante 500 ms. Si durante este perodo de tiempo no recibe informacin, se inicia una nueva iteracin en el bucle. Esto se hace as, porque de otra forma no sera posible para el servidor. Para que se inicie un tratamiento de la informacin, lo que reciba por el puerto debe ser distinto de cadena de caracteres vaca. Cuando es distinto, entra en el mdulo Enva/Recibe, que se describe a continuacin.
En toda comunicacin establecida, debe ser posible finalizar la misma y ser el cliente el que finalice la conversacin con el servidor. Por tanto, en el servidor debe hacerse un anlisis
75
adicional, ya que es posible que el cliente desee terminar la conexin, como se muestra en la figura 68.
Figura 68. Finalizacin de la conversacin con el servidor por parte del cliente El mdulo de servidor_remoto.vi se extrae el primer carcter. Este carcter se analiza en FIN ?, si se trata del carcter de fin de conexin entonces se sale del bucle. En otro caso, se sigue con el anlisis de la peticin de transaccin a BD.
Pero adems el mdulo FIN tiene otras funciones, adems de identificar el carcter de fin de conexin. Si el cliente_remoto solicita una peticin de lectura/escritura de N elementos, en este mdulo se tiene que tener en cuenta varios puntos: Si se trata de un cliente especial ( es decir, si se est usando el protocolo uno a uno el protocolo uno a N). Si se trata de una lectura escritura. En el caso de lectura hay que aadir informacin de longitud en el sentido servidor_remoto a cliente_remoto, ya que el contenido de la informacin extrada de BD tiene un tamao desconocida para cliente_remoto. En cambio, en el caso de escritura, figura 69, el campo de longitud se usa slo en el sentido cliente_remoto a servidor_remoto, ya que es aqul que incorpora el contenido de los elementos que se van a escribir en BD.
76
Figura 69. Caso de escritura de N elementos En principio, se compara el primer carcter recibido con q. Si coincide, entonces se trata de un caso de fin de conexin. No hay posibilidad de confusin, ya que los paquetes de informacin normales entre cliente y servidor siempre comienzan con un nmero (Fila).
Si se trata de una peticin de transaccin normal a BD, se leen el resto de caracteres que componen la cabecera, es decir, la parte del paquete constante, ya se trate de un tipo de cliente u otro, de una lectura escritura de N elementos. Por tanto, la siguiente distincin es el tipo de cliente. En este caso se tiene un control sobre el nmero de clientes que pueden hacer uso del protocolo uno a N (0,2... 10). Y dentro de este tipo de clientes, se distingue entre una lectura y escritura. El caso mostrado es una escritura de N elementos a BD. Por tanto, se necesita leer tambin todos los valores que se van a escribir, por lo que se extrae el campo longitud dentro del paquete, se traduce esos caracteres a nmero y se lee del puerto el nmero que ha enviado Cliente_remoto. Una vez extrada toda la informacin, se forma el nuevo paquete para acceder al servidor local y se inserta en la cola de peticiones de servicio. Una vez concluido el servicio, se le informa a cliente_remoto que su solicitud ha tenido xito y se le enva un acuse de recibo (*******). Para concluir con este mdulo, se describe un caso de lectura de N elementos, como se muestra en la figura 70.
77
Figura 70. Caso de lectura de N elementos En este caso, servidor_remoto no tiene que leer ms datos del puerto y slo tiene que insertar la peticin en la cola destinada a tal fin. Una vez atendida la solicitud, el siguiente paso es calcular el tamao de los datos y formar un paquete junto con los datos ledos (figura 71). Finalmente, el paquete formado, ya sea una lectura escritura sigue su transcurso, ya sea con el acuse de recibo con los datos ledos, se envan al cliente_remoto junto con la identificacin del proceso (ID) a travs del puerto.
78
Figura 71. Mdulo de creacin del paquete y envo al cliente remoto
1. CLIENTE REMOTO
Una vez comentado servidor_remoto, es necesario describir el funcionamiento del otro extremo de la comunicacin, como se muestra en la figura 72.
Figura 72. Descripcin de la comunicacin con el servidor remoto 79
Inicialmente, se intenta establecer la comunicacin con el servidor_remoto. Para ello se le pasa como parmetros la direccin IP y el puerto por el que se va a intentar la comunicacin. Como se puede comprobar, la estructura no tiene nada que ver con la del servidor, ya que aquel se mantena a la espera de algn cliente posible.
Una vez establecida la conexin, entra en un nuevo subprograma (client_remot) que realiza toda la comunicacin, como se muestra en la figura 73. Cuando finalice la ejecucin del mismo, significar que por el motivo que sea, ha finalizado la comunicacin y hay que hacrselo saber al servidor. Para ello se le enva q (carcter de fin de conexin).
Figura 73. Descripcin del subprograma CLIENT_REMOT En esta pantalla existe cierta complicacin en la estructura del programa, pero la descripcin del mismo se realiza por partes:
Existen tres bucles de trabajo: un bucle de lectura, una de escritura en el puerto y finalmente un tercer bucle de control del receptor.
Bucle de escritura en el puerto:
80
Se muestra en la figura 74.
Figura 74. Bucle de escritura en el puerto En este bucle se realiza la lectura de datos del puerto. En primer lugar, se hace referencia a la cola que cre el servidor local y si hay datos en la misma, se extraen y se realiza la escritura en el puerto.
Bucle de lectura del puerto
Figura 75. Bucle de lectura del puerto
81
Este bucle realiza la lectura de los datos del puerto pero, antes de hacerlo, registra el cliente que hace peticin de la transaccin, si no lo estaba ya. Una vez registrado, crea una cola especial para l, al que le asigna un identificativo.
Pero hasta ahora no se ha descrito cmo se hace la recepcin en el puerto, es decir, anteriormente se explic que a este nivel era necesario rellenar un campo de longitud que todava no se ha descrito en este apartado. A continuacin, se muestra en la figura 76.
Figura 76. Recepcin en el puerto En el centro del bucle de esta nueva figura aparece un CASE, que segn el tipo de cliente protocolo que se use, hace uno u otra cosa. Entonces, para el caso del protocolo uno a N, el cliente tendr un identificativo como ya se explic en el Servidor_remoto entre 0,2,3 ... 10. Si est dentro de alguno de estos valores, se le hace un tratamiento especial para que entre en un nuevo subprograma: Si Index
Dentro del subprograma se distingue entre el caso en el que se trata de una solicitud de un cliente cualquiera de una transaccin en la base de datos, usando el protocolo uno a N para una lectura escritura, ya que se hace un tratamiento diferente. Como ya se coment cuando se describi en detalle el otro extremo de la comunicacin segn se tratase de una transaccin de lectura escritura, se aada la longitud simplemente se rellenaba con valor 0 (L = 0).
1. Un caso de lectura:
En este caso, como se muestra en la figura 77, se extrae el campo longitud de los datos recibidos y si es un nmero mayor que cero entonces quiere decir que el paquete de
82
informacin trae ms datos, por tanto, es una transaccin de lectura y hay que terminar de leer los datos del puerto.
Figura 77. Caso de lectura del puerto Una vez que se ha extrado la informacin correctamente, se forma el paquete para el cliente que se apoya en Cliente_remoto. Para ello, como se puede observar desaparece el campo longitud en el formato.
2. Un caso de escritura
Se detalla en la figura 78.
Figura 78. Caso de escritura del puerto
83
En este caso, la longitud de los datos resultado de la transaccin a BD es cero, que quiere decir que se hizo una escritura y nada ms. El Cliente_remoto en este caso, aade un acuse de recibo reconocimiento de que la escritura tuvo xito.
Bucle de control
Figura 79. Bucle de control en el puerto Tiene la funcin de controlar el programa en definitiva, ya que si el operador necesita finalizar la ejecucin, tendr que parar la aplicacin de alguna forma y si se da la condicin, finalice el programa destruyendo las colas.
11.2.2. CLIENTES FINALES
11.2.2.1. LOCALES A SERVIDOR LOCAL
Una vez descrito el cdigo para protocolos eficientes como puede ser el protocolo uno a N el protocolo de variables no consecutivas, en este apartado se va a describir algunos clientes que hacen uso de estos protocolos y en los que se ver la eficacia de su uso, porque de otra forma si se utilizara un protocolo poco eficiente consumira mucho tiempo de CPU, con lo que se ralentizara en demasa el sistema.
84
11.2.2.1.1. GENERACIN DE HISTRICOS
Este cliente se ha desarrollado con la idea de generar histricos de determinadas variables. En concreto, el operador podr configurar el mdulo para tomar muestras cada cierto perodo de tiempo. Hay dos formas de generar histricos:
1. Generacin de histricos usando un fichero de texto.
Es una forma bastante eficiente, ya que en cada transaccin se abre un fichero de texto, se aade las muestras correspondientes a ese instante de tiempo y se cierra. Por tanto, la informacin no se almacena constantemente en RAM, sino que se hace un acceso a disco duro, para abrir, adjuntar y cerrar la informacin. Esta generacin se muestra en la figura 80. Al tratarse de ficheros de texto (.txt), apenas consume memoria RAM en la accin de aadir informacin al fichero, por lo que el sistema no se ve afectado.
Figura 80. Generacin de histricos usando un fichero de texto En esta primera pantalla, a partir de la configuracin que el operador ha establecido en la pantalla principal, se crea una cabecera de fichero para que a la hora de abrir el mismo sea legible por cualquier usuario. A diferencia de Excel, la presentacin de la informacin no es tan elegante, as que lo que se gana en eficiencia se pierde en presentacin.
85
Una vez creada la cabecera del fichero, el siguiente paso es tomar muestras cada tiempo_de_muestreo. Esto se hace en la siguiente pantalla de la figura 81.
Figura 81. Toma de muestras en la generacin de histricos usando un fichero de texto Simplemente consiste en un bucle en donde se toman las muestras y se escribe en el fichero cuya identificacin se le pasa de la pantalla anterior. Aqu se hace uso del protocolo de variables no consecutivas (Client histor) y se muestra en la figura 82.
Figura 82. Uso del protocolo de variables no consecutivas en la generacin de histricos usando un fichero de texto 86
Para hacer uso de este protocolo, simplemente hay que rellenar los campos de acuerdo a lo preestablecido, es decir, fundamentalmente asignando 9999 al campo columna.
2. Generacin de histricos usando Microsoft Excel
Como ya se ha comentado, al usar esta aplicacin se tiene la ventaja de tener capacidad de representacin de la informacin. A cambio, segn la forma que tiene LabView de trabajar con aplicaciones de este tipo, el fichero debe estar abierto para poder escribir en l. Esto significa que debe cargarse en RAM antes de poder aadir las muestras nuevas. Si el perodo de tiempo entre muestras es pequeo, es posible que se tenga un fichero bastante grande con un aumento considerable de uso de memoria principal.
De todas formas, se ha profundizado en esta opcin de generacin ya que lo normal es configurar un tiempo_muestreo grande (minutos). Esto significa que el nmero de muestras en total que se pueden obtener en un da componen un fichero de tamao asequible. Se ha diseado este mdulo, para que se cierre el fichero cada da y se abra uno nuevo con el formato que ya se ha comentado anteriormente: aammdd.xls, es decir, ao, mes y da.
Cuando se arranca el programa por primera vez, se comprueba que no existe un fichero con ese nombre, si es as, se aaden las muestras nuevas al principio. De esta forma, la interferencia que se puede provocar ante una cada del sistema es mnima, ya que con slo arrancar de nuevo la aplicacin se va aadiendo la informacin al fichero de histricos existente. Dentro de la inmensidad del bucle que tiene el control del mdulo se destaca dos partes del mismo:
Una primera parte, en la que se comenta el uso del protocolo de variables no consecutivas. Este subprograma es el mismo que se utiliz para la generacin de histricos con ficheros de texto (TXT) y se muestra en la figura 83.
87
Figura 83. Uso del protocolo de variables no consecutivas en la generacin de histricos usando Ms Excel Finalmente, antes de salir del bucle, para terminar con este tipo de cliente local, se tiene una serie de condiciones que se memorizan a la entrada al mismo, como se muestra en la figura 84. De esta forma se tiene varias formas de salir:
Porque el operador haya pulsado el botn de parada. Porque se pase de un da a otro, es decir, de las 23:5x a las 00:0x. Por tanto, en estas condiciones se tiene que salir del bucle para volver a crear un nuevo fichero y abrirlo para ir almacenando las nuevas muestras. Por ltimo, cada cierto nmero de muestras (en este caso, se ha configurado a tres) el programa se sale del bucle y guarda la informacin a disco duro. Despus vuelve a entrar al mismo. De esta forma tendremos redundancia en el sistema ante una posible cada del sistema, ya que de otra forma, es posible que se perdiera el histrico de todo un da, ya que el fichero, durante la ejecucin del bucle, siempre est abierto y la informacin se va almacenando en memoria principal. Se guarda esta informacin en el medio externo cuando se sale del bucle y comienza un nuevo ciclo de muestreo.
88
Figura 84. Condiciones que se memorizan en la entrada del bucle Se podra estudiar con algo ms de detalle la condicin de cambio de da. Para ello se ha diseado una rutina que da la condicin verdadero o falso, como se muestra en la figura 85.
Figura 85. Subrutina de cambio de da Esta subrutina solicita la fecha actual, la compara con el valor antiguo y actualiza la variable de salida Medianoche?
89
11.2.2.1.2. SEGURIDAD DEL SISTEMA
En un proyecto de este tipo, siempre es necesario disponer de determinadas medidas de seguridad. En esta lnea, es posible la definicin de usuarios con su contrasea asociada. Bsicamente este cliente consiste en dos mdulos:
Root.vi, que tiene la funcin de poder aadir nuevos usuarios y contraseas al sistema. Para ello dispone de un fichero en el que se guarda la informacin encriptada.
Login.vi, que est a la vista del operador y realiza las funciones de autenticacin. Mientras no se autentifique el operador no podr operar en el sistema, es decir, no podr enviar consignas de control como puede ser mover un determinado grupo de heliostatos acciones similares. Para realizar estas acciones se ha reservado una posicin en BD para tales menesteres.
Cuando el operador se autentifique se actualiza esta posicin (posicin cero en BD). De esta forma, cada vez que se desee generar una consigna de control, el sistema en primer lugar lee la posicin de memoria y si el resultado es satisfactorio, realiza la operacin, en otro caso, muestra un mensaje advirtiendo al operador que es necesario que se identifique para poder desarrollar la accin.
Se detallan estos mdulos:
Root.vi
En la figura 86 se muestra la pantalla principal, donde se observa al operador con privilegios especiales, es decir, de alguna forma slo estar disponible este mdulo en un directorio reservado a un determinado perfil de usuario.
Como se ha implementado la aplicacin en Windows Server 2008, desarrollar esta posibilidad es aparentemente sencillo, ya que slo se necesita reservar un directorio para este tipo de mdulos y al que slo tenga acceso usuarios con un determinado perfil. Para ello, se solicitar usuario y contrasea cada vez que se acceda a l. En LabView se ha diseado este mdulo como se muestra en la figura 87.
90
Figura 86. Pantalla principal de mdulo ROOT.VI En esta pantalla principal se dan de alta nuevos usuarios. Como medida de seguridad el usuario deber repetir la contrasea para que tenga xito la accin.
Figura 87. Diseo del mdulo ROOT.VI en LabView 91
El mdulo consiste bsicamente en un bucle que permanece a la espera hasta que el usuario introduce un nuevo alta. Si tiene xito, finaliza la ejecucin. En otro caso, informa del error y permanece a la espera.
Login.vi
Finalmente, para terminar con este tipo de cliente, se muestra en la figura 88 la pantalla que se presenta al operador:
De esta forma, el operador slo tiene que introducir login y password, el sistema le validar si ha sido dado de alta con el mdulo anterior y tambin recoge la posibilidad de bloquear el sistema.
Esto se podra utilizar como medida de seguridad cuando el operador se ausente del puesto de trabajo y desee bloquear el sistema, es decir, que vuelva a solicitar usuario y contrasea cuando se introduzca una nueva consigna de control. Esta opcin queda recogida con el botn Bloquear que aparece en la figura. La descripcin del cdigo se recoge en el siguiente subprograma de la figura 89.
92
Figura 89. Descripcin del cdigo del subprograma LOGIN.VI
En esta primera opcin, si el operador desea bloquear el sistema se rellena con un cero la posicin cero de la Base de Datos. En otro caso, tiene lugar la autenticacin del usuario y si tiene xito, se rellena con un uno la posicin cero de la BD.
Se entra en una u otra opcin segn el valor que tenga la variable lgica Bloquear. Esta variable, por defecto, tiene un valor, para que inicialmente el usuario tenga que validarse para poder acceder al sistema. Se muestra el cdigo en la figura 90.
93
Figura 90. Descripcin del cdigo del bloqueo del sistema Comprobacin de la existencia de usuario validado
Una vez descrito el procedimiento para validarse, slo queda comentar cmo comprueba el sistema que existe en todo momento un usuario validado. Para esto, existe un mdulo que tiene la funcin de generar consignas. Dada su importancia sobre el funcionamiento del sistema, a modo de prueba, se le ha asociado la comprobacin de autenticacin. Esto quiere decir, que a peticin del cliente, es posible construir un software completamente a medida y asociar a un mdulo en concreto un nivel de seguridad. En concreto, el mdulo se describe en la figura 91.
Figura 91. Mdulo que comprueba la autenticacin 94
Como se puede observar, esta es la pantalla principal del tcnico, desde donde se puede aplicar determinadas consignas de control al campo de heliostatos. Si un operador no se ha validado, entonces, aparece un mensaje informando de esa circunstancia, como se muestra en la pgina 92.
Por tanto, cada vez que se quiera mover un grupo de heliostatos, por ejemplo, el mdulo hace una consulta a la BD y comprueba si existe usuario validado. Esto se puede comprobar en las siguientes figuras donde se muestra la circunstancia descrita anteriormente y en donde aparece el cdigo del mdulo, al menos, de la parte que se est describiendo ahora (comprobacin de la existencia de usuario validado). El cdigo se describe en la figura 93.
Figura 92. Mensaje de no validacin
95
Figura 93. Descripcin del cdigo del mensaje de no validacin En esta parte del cdigo de programa existe una rutina que es la que da la condicin de acceso a la ejecucin de la consigna de control (Exec). Esta rutina se describe en la figura 94.
Figura 94. Descripcin de la rutina que da la condicin de acceso a la ejecucin de la consigna de control
Se hace una consulta a BD y como se va a leer un solo elemento, se utiliza el protocolo uno a uno. Se lee la posicin cero y se comprueba si es igual a uno. Si es as, entonces el usuario
96
est validado. En caso contrario, aparece el mensaje que se mostr anteriormente informando de la ausencia de usuario validado.
11.2.2.2. REMOTOS A SERVIDOR LOCAL
En este apartado se describe algn ejemplo de clientes remotos que acceden a Servidor Local. En concreto, se estudiar el cliente Control Campo, por ser el ms completo ya que hace uso de la mayora de los protocolos introducidos en la descripcin del sistema.
11.2.2.2.1. CONTROL CAMPO
Este mdulo es uno de los ms importantes en el funcionamiento eficiente del sistema. En general, se encarga de transferir las consignas al campo de heliostatos. Si el campo est compuesto por mil elementos, deber comunicarse con todos dentro de un intervalo de tiempo asequible, ya que la posicin de cada uno debe actualizarse tan rpido como sea posible ya que el sol est en permanente movimiento. Como requisitos del diseo, se tiene que cada heliostato se debe actualizar cada medio minuto como mximo.
Este mdulo cumple con estas exigencias, ya que consigue comunicarse con cada uno durante la fase de experimentacin en 15 segundos aproximadamente. Aunque el sistema trabaje en vaco, para el funcionamiento interno no afecta. Esto es debido a que cada uno se espera un tiempo de espera de rigor, pasado el cul si el heliostato no ha respondido, se considera que est fuera de servicio y as se indica en la pantalla de estado del heliostato zona de la base de dato donde se actualiza constantemente el estado de todos los heliostatos. Esta descripcin de la rutina se muestra en la figura 95.
Figura 95. Descripcin del mdulo CONTROL CAMPO 97
Como se puede observar, el mdulo consiste en bucle que tiene muchas funciones a realizar. Este bucle tarda, como ya se ha mencionado anteriormente, 15 segundos en ejecutarse. Terminado ese tiempo se comunica con todos los heliostatos que componen el campo. En esta primera figura, se accede a BD mediante el protocolo uno a N y se lee en una sola transaccin 500 posiciones que van desde la posicin 6000 a la posicin 6499. Estas posiciones se han reservado para un uso futuro en el que se podrn programar determinadas MACROS en las que el operador podr guardar determinadas acciones que sern repetitivas en el funcionamiento normal de la planta, como puede ser abatir todos los elementos del campo de una determinada forma, obligarlos a que sigan un determinado camino de seguridad muchas otras ms.
Con esas posiciones se forma un vector, en el que se registran aquellas acciones que tengan un valor distinto de cero guardado en BD, es decir, si para una de las posiciones no se ha programado accin alguna no est en uso, se actualiza a cero. De esta forma, en el vector se tiene nicamente aquellas macros que estn activas. La descripcin del cdigo se muestra en la figura 96.
Figura 96. Descripcin del cdigo del vector de macros activas
98
En la continuacin del cdigo, se observa que no se ha programado an, como ya he comentado anteriormente, ninguna macro (el tamao del vector con las macros activas ser siempre cero, al menos durante la fase de experimentacin).
Si el tamao de vector es cero, entonces el siguiente paso sera leer la orden particular para cada uno de los heliostatos. Para estas posiciones se ha reservado en BD una zona, que van de la posicin 5000 a la posicin 5999, como se muestra en la figura 97.
Figura 97. Descripcin del cdigo de lectura de orden para cada uno de los heliostatos Con los valores ledos, se forma un vector que se utilizar como entrada a la estructura FOR que es la que se comunica con todos los heliostatos. A la vez, se hace un clculo de la posicin de cada heliostato (Calc Coord). Este mdulo se proporciona la posicin del sol en su defecto la posicin de cada uno de los heliostatos. Como requisito inicial del trabajo de investigacin, este mdulo deber ser proporcionado, es decir, no ser objetivo de esta tarea calcular los datos necesarios para obtener la posicin de cada elemento que constituye el campo. Pero an as, y anticipndonos a este hecho, se tiene en cuenta este detalle y se reserva un mdulo que, en principio, simula la funcin asignada. nicamente, este mdulo hace una transaccin de lectura de BD y lee los dos grados de libertad (acimut y elevacin) de cada elemento, que van de la posicin 2000 a la posicin 3999. Con esta informacin se crea dos vectores que pasa al mdulo general como parmetros de salida del sistema.
99
La descripcin de este mdulo se detalla en la figura 98.
Figura 98. Descripcin del mdulo que obtiene la posicin de cada elemento que constituye el campo Con la orden a cada heliostato, as como con la posicin que cada uno debe tener, se entra en una estructura FOR en donde tiene lugar la comunicacin individual con cada elemento. Esta estructura es la que consume ms tiempo en el bucle porque es la que se encarga de establecer la conexin con cada elemento, si es posible, esperar un determinado tiempo (timeout) antes de informar del estado del mismo.
Por defecto, si para un determinado heliostato no hay consigna en cuestin, es decir, no hay ninguna orden, se le solicita que informe del estado en el que se encuentra, ya que as conseguimos asegurar el correcto funcionamiento del campo y poder actuar rpidamente si un determinado elemento se avera. Por tanto, ste est constantemente informando de su estado. Una vez que la ejecucin del programa finaliza con la estructura FOR, disponemos de un vector de estado de todos los heliostatos. Este nuevo vector de estados de los heliostatos, as como las nuevas posiciones calculadas por el mdulo Calcula_coord, se utilizan para formar un vector con el que se actualiza la BD. Esto se hace desde la posicin 2000 hasta la posicin 4999. Es decir, sobrescribimos la posicin de todos los elementos y actualizamos una nueva zona en BD (desde la 4000 a la 4999) que se reserva para guardar el estado de todos los heliostatos. Como se trata de un bucle, constantemente est realizando la actividad que se ha descrito en este apartado.
100
12. CONCLUSIN
En este apartado nos centraremos en la contribucin que supone el nuevo impulso de iniciativas como este trabajo que dan a conocer la temtica relacionada con este importante campo de la Tecnologa de Informacin y Comunicacin en las Energas Renovables, en concreto, en la energa solar. Esta aportacin innovadora permite la aproximacin a los retos de futuro y muestra la posibilidad de actuacin en dicho campo con las favorables consecuencias sobre el medio ambiente y la sociedad en general.
En este trabajo, se ha intentado concluir lo mejor que ofrece este Sistema de Informacin que planifica una planta solar de concentracin mediante un sistema SCADA. Entre las conclusiones ms importantes que ofrece esta investigacin, se encuentra la versatilidad que proporciona en la implantacin de un proyecto distribuido de monitorizacin, supervisin y adquisicin eficiente de datos de una planta solar de concentracin.
Adems, el software LABVIEW facilita extraordinariamente el manejo de aplicaciones de este tipo SCADA y asume perfectamente los futuros dimensionamientos que se realicen de la red local. Este programa es compatible con el sistema operativo usado, Windows Server 2008, en la red de rea local y asume favorablemente todos los posibles riesgos del trabajo con los datos en tiempo real.
La implementacin y desarrollo del hardware necesario para la finalizacin del proyecto se deja como posibles lneas de investigacin futuras tesis.
101
13. BIBLIOGRAFA
REFERENCIA LEGAL
LEY ORGNICA 2/2006, de 3 de mayor, de Educacin (en adelante, L.O.E.).
LEY 17/2007, de 10 de diciembre, de Educacin de Andaluca (en adelante, L.E.A.)
REAL DECRETO 1467/2007, de 2 de noviembre, por el que se establece la estructura y enseanzas mnimas del Bachillerato.
DECRETO 416/2008, de 22 de julio, por el que se establece la ordenacin y las enseanzas correspondientes al Bachillerato en Andaluca
ORDEN de 5 de agosto de 2008, por la que se desarrolla el currculo del Bachillerato en Andaluca
REFERENCIA BIBLIOGRFICA
RODRGUEZ PENIN, A. Sistemas Scada. 2 edicin. Ed. Marcombo, 2007
BOYER, S.A. SCADA: supervisory control and data acquisition. Ed. Cop. 1999.
BAILEY, D. y WRIGHT, E. Practical SCADA for industry. Ed. Newnes Books, 2003.
LZARO, A.M. LabVIEW: Programacin grfica para control de instrumentacin. Ed. Paraninfo, 2005
LAJARA, J.R. y PELEGR, J. LabVIEW: Entorno grfico de programacin. Ed. Marcombo, S.A., 2007.
102

Scad A

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Scad A

Caricato da

Copyright:

Formati disponibili

ANLISIS DE LA METODOLOGA DE IMPLANTACIN DE UN SISTEMA DISTRIBUIDO DE MONITORIZACIN, SUPERVISIN Y ADQUISICIN DE DATOS DE UNA PLANTA SOLAR DE CONCENTRACIN MEDIANTE UN SISTEMA

SCADA EN LA TECNOLOGA INDUSTRIAL

Autor: Juan Carlos Ramrez Fernndez

Acrnimo en ingls de Supervisory, Control And Data Adquisition

Los ncleos temticos propuestos en Bachillerato son:

Entre los conceptos asociados a sistemas SCADA, se debe distinguir:

Hardware en sistemas de supervisin: PLC y PC

Figura 1. Ejemplo de Panel Frontal

Figura 2. Ejemplo de Diagrama de Bloques

4. COMUNICACIN APLICACIN SCADA CON EL ENTORNO

Acrnimo en ingls de Defence Advanced Research Project Agency

Estacin Meteorolgica Control Global Foco Tanque Variables del sistema

1-10 11-49 50-149 150-249 250-349 350-499

Coordenadas Grupo en Foco

1000-1999 2000-2999 3000-3999 4000-4999 5000-5999 6000-6499 6500-7499 7500-8499

7.1. CLIENTES LOCALES

SERVIDOR LOCAL CLIENTE REMOTO

Figura 7. Esquema sobre tipos de clientes locales en la aplicacin

7.2. CLIENTES REMOTOS

Figura 8. Esquema sobre el mdulo especial de los clientes remotos en la aplicacin

7.3. ESTRUCTURA DE PROTOCOLOS

La estructura de protocolos queda reflejada en la figura 9.

MDULO ESPECIAL TRANSPORTE RED ENLACE

CLIENTE ESPECIAL TRANSPORTE RED ENLACE

Figura 9. Estructura de protocolos

7.3.1. TIPOS DE PROTOCOLOS

ID F C lect Index Tam Relleno

1. Protocolo uno a uno Se muestra el caso de lectura en BD en la figura 14.

Se muestra el caso de escritura en BD en la figura 15.

7.4. EJEMPLOS IMPLEMENTADOS

7.4.1. ESTACIN METEOROLGICA

7.4.2. INTERFAZ HOMBRE MQUINA (MMI) DE VISUALIZACIN DE ESTACIN METEOLGICA

1. Transaccin local a la base de datos

2. Transaccin remota a la base de datos

Este flujo de informacin se muestra en la figura 18.

VISUALIZACIN ESTADO METEOROLGICO

7.4.3. OTROS EJEMPLOS

Se detallan cada uno de los protocolos.

8.1. PROTOCOLO UNO A UNO

Figura 19. Protocolo uno a uno 8.2. PROTOCOLO UNO A N

Mensaje de respuesta Tiempo de proceso

8.3. PROTOCOLO PARA VARIABLES ALTERNATIVAS

Figura 21. Protocolo para variables alternativas

9.1. EXCEL VERSUS TXT

En cuanto a los inconvenientes que se tienen:

Tmax = 216 T = 65536 T

Acrnimo en ingls de Dinamic Data Exchange

Para un ejemplo de T = 10 seg:

Tmax = 65536 10 seg = 182 horas

Figura 22. Generacin de histricos sobre un fichero Excel

Figura 23. Generacin de histricos sobre un fichero de texto 35

9.2. LOCAL VERSUS REMOTO

USUARIO FINAL EXCEL o TXT GENERA HISTRICO SERVIDOR LOCAL

GENERA HISTRICO MDULO ESPECIAL TRANSPORTE RED ENLACE NIVEL FSICO

SERVIDOR LOCAL CLIENTE ESPECIAL TRANSPORTE RED ENLACE NIVEL FSICO

Figura 25. Generacin de histricos de forma remota

Acrnimo en ingls de Man-Machine Interface

9.3. USUARIO DE HISTRICO

10. CONTROL CAMPO

COMUNI CACIN SERI E

Figura 27. Estados de los heliostatos

10.2. ORDEN DE CAMPO

10.3. ORDEN DE HELIOSTATO

10.4. CALCULA COORDENADA