Autor: Juan Carlos Ramírez Fernández

Transcripción

1 ANÁLISIS DE LA METODOLOGÍA DE IMPLANTACIÓN DE UN SISTEMA DISTRIBUO DE MONITORIZACIÓN, SUPERVISIÓN Y ADQUISICIÓN DE DATOS DE UNA PLANTA SOLAR DE CONCENTRACIÓN MEDIANTE UN SISTEMA SCADA EN LA TECNOLOGÍA INDUSTRIAL Autor: Juan Carlos Ramírez Fernández

2 INDICE 1. INTRODUCCIÓN SISTEMA SCADA LABVIEW COMUNICACIÓN APLICACIÓN SCADA CON EL ENTORNO MODELO CLIENTE-SERVOR SERVOR CLIENTES CLIENTES LOCALES CLIENTES REMOTOS ESTRUCTURA DE PROTOCOLOS EJEMPLOS IMPLEMENTADOS PROTOCOLOS EFICIENTES PROTOCOLO UNO A UNO PROTOCOLO UNO A N PROTOCOLO PARA VARIABLES ALTERNATIVAS HISTÓRICOS EXCEL VERSUS TXT LOCAL VERSUS REMOTO USUARIO DE HISTÓRICO CONTROL CAMPO FUNCIÓN ORDEN DE CAMPO ORDEN DE HELIOSTATO CALCULA COORDENADA ENVÍO DE ORDEN A HELIOSTATO ACTUALIZACIÓN DE BASE DE DATOS TORRE DE PROTOCOLOS DESCRIPCIÓN DEL CÓDIGO SERVOR LOCAL DESCRIPCIÓN DE CLIENTES CONCLUSIÓN BIBLIOGRAFÍA

3 1. INTRODUCCIÓN El objetivo de esta investigación es el diseño de una metodología de implantación de un sistema distribuido de monitorización, supervisión y adquisición eficiente de datos de una planta solar de concentración usando un sistema SCADA 1. Se utilizará una herramienta o lenguaje de programación denominado LABVIEW, totalmente gráfico, facilitando el entendimiento y manejo de aplicaciones tipo SCADA. Para ello, se va a desarrollar cada una de sus partes en los próximos puntos. La idea es conseguir un sistema SCADA para una planta solar orientada, en principio, a un total de unos mil heliostatos. El diseño 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 comunicación interna. Siempre se ha dejado la posibilidad de ampliar el número 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-máquina 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 sería usar sistemas que permitan trabajar en tiempo real estricto pero, dadas las características 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 límites estrictos de tiempo. Esta publicación está orientada hacia el Bachillerato, en concreto, para la materia Tecnología Industrial II. Esta formación postobligatoria capacita al alumno para una formación posterior universitaria o ciclo formativo de Grado Superior. La normativa en la que está basada esta publicación para la aplicación al Bachillerato es la siguiente: - Ley Orgánica 2/2006, de 3 de mayor, de Educación (en adelante, L.O.E.). - Ley 17/2007, de 10 de diciembre, de Educación de Andalucía (en adelante, L.E.A.) - Real Decreto 1467/2007, de 2 de noviembre, por el que se establece la estructura y enseñanzas mínimas del Bachillerato. 1 Acrónimo en inglés de Supervisory, Control And Data Adquisition 3

4 - Decreto 416/2008, de 22 de julio, por el que se establece la ordenación y las enseñanzas correspondientes al Bachillerato en Andalucía - Orden de 5 de agosto de 2008, por la que se desarrolla el currículo del Bachillerato en Andalucía Nuestra vida cotidiana está marcada por la Tecnología. La evolución tecnológica ha marcado nuestra forma de vivir, de relacionarnos socialmente. Conceptos como la innovación tecnológica, calidad de vida, respeto del medio ambiente, están ligados con la Tecnología. Por lo tanto, es necesario prestar especialmente atención a este tipo de formación en Bachillerato, donde el alumno adquirirá conocimientos científicos y tecnológicos. La Tecnología Industrial se basa en los conocimientos adquiridos relacionados con esta materia durante la ESO, donde el alumno, participando colectivamente de forma activa y crítica podrá profundizar en lo estudiado hasta ahora, respetando los valores adquiridos (respecto por el medio ambiente, consumo razonable de recursos energéticos, conciencia de las consecuencias para la sociedad del uso de la tecnología). El alumno tendrá oportunidad de estudiar técnicas específicas y desarrollos tecnológicos relacionados con la actividad industrial. Los núcleos temáticos propuestos en Bachillerato son: 1. Uso responsable de las materias primas. Materiales de uso técnico. 2. Consumo energético. Ahorro y eficiencia energética en la industria. 3. Los avances tecnológicos. I+D+I. Máquinas. 4. Automatización. Control de procesos y máquinas. Este documento se centra sobre todo en los núcleos temáticos 3 y 4, ya que supone un ejemplo de avance tecnológico con una plataforma basada en un sistema SCADA, aplicada para el control de una planta solar, como parte de un proceso de automatización. Particularizando cada núcleo temático a Tecnología Industrial II, respecto al "uso responsable de las materias primas. Materiales de uso técnico", se abordan técnicas relacionadas en mayor medida con los ensayo, reciclado de materiales, normas de precaución y prevención en el manejo de materiales, instrumentos, etc. Respecto al núcleo temático "Consumo energético. Ahorro y eficiencia energética en la industria", se debe abordar desde la materia de Tecnología Industrial II con los contenidos relacionados con las energía útil, rendimiento y aspectos relacionados con las pérdidas energéticas en máquinas, haciendo distintos ensayos y técnicas de experimentación sobre 4

5 montajes reales donde puedan realizar comprobaciones directas de consumo energético, así como el coste económico asociado a este consumo. Respecto al núcleo temático "Los avances tecnológicos, la I+D+I. Máquinas", se debe abordar contenidos relacionados con motores eléctricos y máquinas térmicas, teniendo la posibilidad de experimentar con diferentes máquinas, así como comprender la función de cada uno de los elementos. Es importante abordar en este sentido el manejo de distintos tipos de herramientas de simulación de circuitos de control automática, eléctricas, electrónicas, neumático, etc. Por último, el núcleo temático "Automatización. Control de procesos y máquinas" se desarrollará en Tecnología Industrial II, abordando contenidos relacionados con los sistemas automáticos. Se verán conceptos como regulación y control, así como la adquisición de conocimientos relativos al control y programación de sistemas automáticos. Por tanto, la aplicación del tema de esta publicación es directa y encaja perfectamente con los contenidos de la materia de Tecnología Industrial II de Bachillerato. 2. SISTEMA SCADA Se trata de una aplicación software especialmente diseñada para funcionar sobre ordenadores en el control de producción, proporcionando comunicación con los dispositivos de campo (controladores autónomos, autómatas programables, etc.) y controlando el proceso de forma automática desde la pantalla del ordenador. La comunicación se realiza mediante buses especiales o redes LAN. Todo esto se ejecuta normalmente en tiempo real y están diseñados 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 disposición de ofrecer las siguientes prestaciones: Posibilidad de crear paneles de alarma, que exigen la presencia del operador para reconocer una parada o situación de alarma, con registro de incidencias. Generación de históricos de señal de planta que pueden ser volcados para su proceso sobre una hoja de cálculo. Ejecución de programas, que modifican la ley de control, o incluso anular o modificar las tareas asociadas al autómata, bajo ciertas condiciones. Posibilidad de programación numérica, que permite realizar cálculos aritméticos de elevada resolución sobre la CPU del ordenador. 5

6 Con ellas, se pueden desarrollar aplicaciones para ordenadores (tipo PC, por ejemplo), con captura de datos, análisis de señales, presentaciones en pantalla, envío de resultados a disco e impresora, etc. Además, todas estas acciones se llevan a cabo mediante un paquete de funciones que incluye zonas de programación en un lenguaje de uso general (como C, Pascal, ó Basic), lo cual confiere una potencia muy elevada y una gran versatilidad. Algunos SCADA ofrecen librerías de funciones para lenguajes de uso general que permiten personalizar de manera muy amplia la aplicación que desee realizarse con dicho SCADA. Un SCADA debe cumplir los siguientes objetivos para que su instalación sea perfectamente aprovechada: Deben ser sistemas de arquitectura abierta, capaces de crecer ó adaptarse según 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 gestión). Deben ser programas sencillos de instalar, sin excesivas exigencias de hardware, y fáciles de utilizar, con interfaces amigables con el usuario. Los módulos ó bloques software que permiten las actividades de adquisición, supervisión y control de un SCADA son los siguientes: Configuración: permite al usuario definir el entorno de trabajo de su SCADA, adaptándolo a la aplicación particular que se desea desarrollar. Interfaz gráfica del operador: proporciona al operador las funciones de control y supervisión de la planta. El proceso se representa mediante sinópticos gráficos almacenados en el ordenador de proceso y generados desde el editor incorporado en el SCADA o importados desde otra aplicación durante la configuración del paquete. Módulo de proceso: ejecuta las acciones de mando preprogramadas a partir de los valores actuales de variables leídas. Gestión y archivo de datos: se encarga del almacenamiento y procesado ordenado de los datos, de forma que otra aplicación o dispositivo pueda tener acceso a ellos. Comunicaciones: se encarga de la transferencia de información entre la planta y la arquitectura hardware que soporta el SCADA, y entre ésta y el resto de elementos informáticos de gestión. 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% 6

7 de los casos. Además si se habla de tiempo real el sistema debe responder en tiempos concretos también en un 100% de los casos. Si los tiempos concretos de reacción pueden superarse en ciertos casos, como en sistemas no críticos, hablamos de "tiempo real suave". Hardware en sistemas de supervisión: PLC y PC Las tareas automatizadas de control, visualización y computación pueden ser efectuadas por PLCs (conectados en red mediante los módulos adecuados) mejor que con sistemas exclusivos de control basados en PC. Lo que finalmente es práctico, no obstante, depende de un gran número de factores y la mayoría deben ser considerados individualmente para cada proyecto de automatización. 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 también puede disponer de la característica de capacidad en tiempo real. Un sistema de control es inconcebible sin capacidad en tiempo real. Es común, en sistemas de control por ordenador, tener que elegir según las características 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 lógicos programables, en la mayoría de los casos, están diseñados específicamente 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 seguirán siendo, no obstante, la primera elección para todo control de tareas críticas o extremas por su rendimiento y simpleza, en los que un PC podría estar simplemente "sobrecargado" debido al trabajo que le pueden suponer otras tareas de ámbito común, como la gestión y visualización de datos, accesos a periféricos, bases de datos, etc. Si además del control de tareas, se necesita un procesamiento de datos, trabajo en red ó visualización (una aplicación SCADA), un sistema basado en PC debe ser tomado en consideración. 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 rápida para aplicaciones "suaves" en tiempo real, gracias a su arquitectura de micro-kernel. Como el sistema operativo sólo puede proporcionar respuestas suaves en tiempo real, lo más simple es emplear extensiones hardware para las tareas críticas (placas de expansión PC) y soluciones software para el resto de tareas. Esto nos lleva a una compatibilidad con futuros sistemas operativos y una solución totalmente factible actualmente. Estas tarjetas de expansión asumen las tareas críticas en tiempo real que el ordenador (PC) no puede atender e incorporan 7

8 DSP s (Procesadores de Señales Digitales) ó microcontroladores, que aportan una ayuda a la anterior sobrecarga mencionada para los ordenadores (PC). Aún no se ha establecido un estándar para poseer extensiones compatibles en tiempo real de sistemas operativos. De una forma estrictamente determinante, los sistemas estándar 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 más libertad en la elección de la herramienta adecuada para el análisis, diseño y programación del sistema SCADA. La solución comienza a ser propietaria nuevamente, es decir, cada empresa ofrece su solución y la conversión a futuras generaciones de sistemas operativos lo hace más difícil. 3. LABVIEW LabView es una herramienta diseñada especialmente para monitorizar, controlar, automatizar y realizar cálculos complejos de señales analógicas y digitales capturadas a través de tarjetas de adquisición de datos, puertos serie y GPIBs (Buses de Intercambio de Propósito General). Es un lenguaje de programación de propósito general, como es el Lenguaje C ó Basic, pero con la característica que es totalmente gráfico, facilitando de esta manera el entendimiento y manejo de dicho lenguaje para el diseñador y programador de aplicaciones tipo SCADA. Incluye librerías para la adquisición, análisis, presentación y almacenamiento de datos, GPIB y puertos serie, además de otras prestaciones, como la conectividad con otros programas, por ejemplo de cálculo, como Matlab. Está basado en la programación modular, lo que permite crear tareas muy complicadas a partir de módulos o sub-módulos mucho más sencillos. Además estos módulos pueden ser usados en otras tareas, con lo cual permite una programación más rápida y provechosa. También ofrece la ventaja de debugging en cualquier punto de la aplicación. Es decir, permite la posibilidad de poner break-points, ejecución paso a paso, ejecución hasta un punto determinado y se puede observar como los datos van tomando valores a medida que se va ejecutando la aplicación. Además también lleva incorporado generadores de señales para poder hacer un simulador. LabView es un lenguaje completamente gráfico y tiene un resultado totalmente parecido a un instrumento, por ello a todos los módulos creados con LabView se les llama VI (Instrumento Virtual). Existen dos conceptos básicos 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 están recogiendo los datos, de esta manera el usuario sabe con precisión cual es el estado actual de dicho instrumento y los valores de las 8

9 señales que se están midiendo. El diagrama de bloques es el conexionado de todos los controles y variables, que tendría cierto parecido al diagrama del esquema eléctrico del instrumento. LabView tiene la característica de descomposición modular ya que cualquier VI que se ha diseñado puede convertirse fácilmente en un módulo que puede ser usado como una subunidad dentro de otro VI. Esta peculiaridad podría compararse a la característica de procedimiento en los lenguajes de programación estructurada. Es un sistema abierto, es decir, cualquier fabricante de tarjetas de adquisición de datos o instrumentos en general puede proporcionar el driver de su producto en forma de VI dentro del entorno de LabView. También es posible programar módulos 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 podría 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, podrían existir lamentables errores. Además, dos usuarios podrían 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. 9

10 En ella están todos los controles e indicadores interconectados, pareciéndose mucho a un diagrama de esquema eléctrico. Esta cara es mucho menos conceptual que el Panel Frontal y para el usuario sería muy difícil entenderla. La figura 2 es un ejemplo diagrama de bloques. Figura 2. Ejemplo de Diagrama de Bloques Se puede observar como todos los módulos están interconectados mediante líneas de conexión. Por ellas circulan los diferentes datos o valores del VI y de esta manera se logra que funcione como un conjunto de elementos, módulos y sub-módulos. 4. COMUNICACIÓN APLICACIÓN SCADA CON EL ENTORNO En este apartado se detallan los conceptos básicos de la comunicación de un sistema SCADA con todo su entorno: Adquisición de Datos para ordenadores (tarjetas de adquisición de datos) y Redes LAN y el protocolo TCP/IP, para aplicaciones servidor/cliente. TARJETAS DE ADQUISICIÓN DE DATOS Es una forma de medir las señales y transferir los datos al ordenador (llamadas comercialmente tarjetas DAQ). Estas tarjetas poseen Convertidores Analógico/Digitales (ADC) y Convertidores Digital/Analógicos (DAC) que permiten la entrada/salida de señales analógicas y digitales. Normalmente, las tarjetas DAQ se instalan en los buses de alta velocidad del PC como los buses PCI. En función de la velocidad de la placa base del PC, la velocidad máxima 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 información es enviada al ordenador o a otros instrumentos. El uso de GPIB (Buses de 10

11 Intercambio de Propósito General) permiten transferir datos a través de puertos paralelos, puertos series y redes de instrumentos u ordenadores. Una de las principales evoluciones de la informática 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 físicos está, en muchos casos, en el abandono de la máquina central encargada de la ejecución de las diferentes tareas en beneficio de varias máquinas. En dicho entorno, rápidamente se hace sentir la necesidad de intercambio de información entre diferentes máquinas. Puede tratarse de intercambio de datos entre programas o de archivos o informaciones entre usuarios. El concepto de red corresponde a esta interconexión entre diferentes máquinas. El desarrollo de las redes está en constante evolución y se pueden caracterizar por el paso del modo repartido al modo distribuido. En el primero, los recursos necesarios para una actividad deben localizarse explícitamente. Por tanto, un usuario tiene que tener una cierta idea de la topografía de la red. Con el concepto de distribución, 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 clasificación de redes es el alejamiento de sus diferentes componentes. En el caso de una red local, la distancia que separa los huéspedes no excede de varios kilómetros permitiendo una interconexión física que se realiza mediante diferentes soportes. En una red a larga distancia para la unión entre dos huéspedes puede utilizarse como soporte la línea telefónica o satélites. La multiplicación de redes locales, que ofrecen servicios a un grupo restringido de usuarios, ha mostrado rápidamente sus límites y se ha dejado sentir la necesidad de superar el cuadro local de sus intercambios. La satisfacción de estas necesidades ha chocado con la heterogeneidad de las redes. Por iniciativa del DARPA 2, se han realizado investigaciones para obtener una red lógica que, a priori, permita la interconexión de todas las redes, cualquiera que sea la tecnología. Estas investigaciones convergen en la definición de una serie de protocolos a los que generalmente se hace referencia nombrando los dos protocolos principales, es decir, TCP/IP. Las interfaces IP aseguran la gestión de los protocolos específicos a cada tipo de red física. Uno de los papeles que les incumbe es la fragmentación de los mensajes que se van a emitir, es decir, se trata de dividir los mensajes para enviarlos mediante una trama física. El protocolo IP se utiliza para el intercambio de paquetes de información en modo no conectado. Por tanto, 2 Acrónimo en inglés de Defence Advanced Research Project Agency 11

12 no garantiza la llegada correcta de los mensajes. Esta funcionalidad se introducirá mediante el protocolo TCP, orientado a conexión, es decir, ofrece un servicio seguro de transporte de información (octetos). Los octetos que se emiten desde un lado de la conexión se liberan en el mismo orden al otro lado de la conexión. Este grupo de octetos no tiene ninguna estructura. La conexión se realiza en modo dúplex, es decir, soporta una comunicación simultánea en los dos sentidos. El modelo de servidor/cliente es el modo de interacción más corriente entre aplicaciones en una red. Un servidor es un programa que ofrece un servicio en la red, es decir, que realiza una función específica. En ciertas circunstancias, este término designará a una máquina. Este será el caso si dicha máquina está dedicada a un servicio particular (por ejemplo, servidor de datos adquiridos). Un cliente es un programa que dirige a un servidor una petición específica que corresponde a una demanda de servicio. De este modo, en el caso de aplicaciones que se comuniquen utilizando estos protocolos, se enviará una petición de un cliente a un servidor por mediación de un paquete que contiene, en particular, un número de puerto que corresponde al servicio y el número del puerto donde el cliente espera la respuesta. Muchos de los sistemas SCADA empleados necesitan comunicarse vía red, puertos GPIB, telefónica o satélite. Mientras existen unos ordenadores que están capturando datos en campo, hay otros que se encargan de recoger la información y gestionarla, Centros de Control. 5. MODELO CLIENTE-SERVOR Para el diseño de la aplicación se ha decidido en un modelo cliente-servidor. Dadas las especificaciones que se plantean, el diseño 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 petición al servidor. El servidor atiende dicha petición 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 petición ha sido atendida. En el caso de una lectura no existe ningún problema, ya que el valor leído 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 petición 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 petición se le asigna un número que identifique la misma. Por tanto, es posible utilizar este número 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 operación con éxito porque el servidor le ha devuelto el número de petición del servicio. 12

13 La solución 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 número de petición que es lo único que asocia dicha petición con un cliente en concreto. 6. SERVOR En el diseño de la aplicación, el servidor local será aquel que gestione el acceso a la base de datos. De entrada, se puede observar que esta estructura será crítica en el sistema ya que una gestión 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. FILA COLUMNA LECT/ESC VALOR Figura 3. Paquete de acceso a la Base de Datos La solución adoptada para la BD consiste en un vector de tamaño definido que guarde las variables del sistema. Dada la forma de programar en LabView (lenguaje G), la BD se puede sustituir por un módulo o subprograma que realice las mismas funciones, por ejemplo, Microsoft Access, sin que esto tenga asociado graves trastornos en la aplicación. Se va a explicar cada parte del paquete de acceso a la BD: : Es un número de petición que sirve para identificar el cliente. FILA: Es un número de 4 cifras que se usa para direccionar la BD. Inicialmente, se ha supuesto que el tamaño máximo del vector sea de elementos, suficientes para guardar todos los estados del proceso industrial. Este valor es reajustable desde comando. COLUMNA: Es un número con dos lecturas. Se podría pensar en una BD de dos dimensiones con todas las ventajas que esto presenta. También se puede utilizar para distinguir clientes que realicen la misma petición, ya que según el diseño 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 tamaño del paquete es variable en función de n. Por tanto, si se le asocia un a esta operación, dos clientes que quieran solicitar el mismo servicio podrían interferirse. Por tanto, con esta solución se resuelve el problema. LECT/ESC: Es un byte que se usa para distinguir lecturas ó escrituras de elementos de la BD. 13

14 VALOR: Es una estructura de 14 dígitos 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 leído 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 más complicados, en los que se hace peticiones remotas al servidor y en donde sería necesario incluir dicho campo que indique el tamaño 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 número de operaciones hasta llegar a leer/escribir. Por tanto, cada elemento de BD es una cadena de caracteres formada por 14 dígitos ó caracteres. El servidor que gestiona BD debe estar constantemente comprobando la cola de entrada. Si hay una petición (elementos en cola > 0), se tiene que sacar el elemento de la misma, atender la petición y escribir el resultado en la cola de salida con el formato adecuado. Básicamente la función 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 dinámico ya que no puede tener velocidad de operación constante. Esto podría saturar el sistema estando el servidor en vacío o haría que fuese ineficiente, ya que, aún con tareas pendientes, el servidor estaría libre ó poco cargado. Por tanto, este es uno de los aspectos más importantes en el diseño del servidor que gestiona el acceso a BD, es decir, un bucle que debe ir rápido cuando haya tareas por atender y viceversa. La solución 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 tamaño definido. Una posible distribución de la misma es la que se muestra en la figura 4. 14

15 Estación Meteorológica 1-10 Control Global Foco Tanque Variables del sistema Coordenadas Grupo en Foco Numero de Heliostato Acimut Elevación Estado Orden Heliostato Orden Campo X-Foco Y-Foco Figura 4. Ejemplo de distribución 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 estación meteorológica, que debido a su escaso número, es más eficiente emplear un protocolo uno a uno. En cambio, hay operaciones que implican transacciones de 1000 elementos ó más. Este es el caso de la lectura ángulo de acimut y elevación para cada heliostato. No es viable hacer esta operación de uno en uno porque perderíamos demasiado tiempo al realizar un total de 2000 transacciones. En este caso se opta por utilizar un protocolo más eficiente en donde se le da al servidor una dirección de BD, un tamaño y la operación a realizar, ya sea lectura ó escritura. De esta forma, en una sola transacción se ha leído o escrito n elementos, ahorrado mucho tiempo de proceso. Para hacer uso eficiente de las colas, hay que tener en cuenta que un tamaño 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 aplicación se ha diseñado colas de tamaño 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

16 SERVOR LOCAL Figura 5. Esquema de funcionamiento del servidor local Por tanto, el esquema global de funcionamiento de cliente-servidor en la investigación sería el que se muestra en la figura 6. CLIENTE 2 CLIENTE 1 CLIENTE 3 SERVOR LOCAL Se puede observar que la única conexión entre el cliente y servidor son las colas de entrada y salida. Figura 6. Esquema global de funcionamiento de cliente-servidor 7. CLIENTES En este apartado se describe la tipología de clientes que existe en la aplicación y la ambigüedad cliente-servidor que existe con los distintos subprogramas, ya que, un módulo es un cliente del servidor local pero a la vez también puede realizar las funciones de servidor de clientes remotos, por ejemplo. 16

17 7.1. CLIENTES LOCALES Dentro de clientes locales hay que distinguir entre clientes que están en la misma máquina que el servidor local y clientes que residen en máquinas remotas. A este último tipo de clientes se les va a conocer como clientes remotos que se detallan más adelante. Para este tipo de clientes es necesario tener un módulo 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 función ú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 1 CLIENTE 2 CLIENTE REMOTO SERVOR LOCAL CLIENTE ESPECIAL CONTROL 1 CONTROL 2 CONTROL 3 Figura 7. Esquema sobre tipos de clientes locales en la aplicación Existen dos tipos de clientes (cliente 1 y cliente 2) que residen en la misma máquina que el servidor local (CONTROL 3). Los usuarios finales que harán 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 están en máquinas remotas. Por tanto, se podrían entender que estos clientes especiales son, por un lado, clientes del servidor local, pero por otro lado, podrían ser servidores de los clientes remotos. Incluso, cuando más adelante se estudie el código de estos módulos, la estructura que presentan es muy similar a la que presenta un servidor convencional. 17

18 7.2. CLIENTES REMOTOS En primer lugar, hay que mencionar que debería existir la misma tipología 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 máquina ó no, sino que, a través de un protocolo parecido al que se usa para comunicarse con el servidor local se consiga realizar una transacción. La solución a esta cuestión es la aparición de un intermediario que se comunique con el cliente especial que atenderá las peticiones remotas. Este concepto se refleja en la figura 8. CLIENTE REMOTO 1 CLIENTE 1 CLIENTE 2 CLIENTE REMOTO 2 SERVOR LOCAL MÓDULO ESPECIAL CLIENTE ESPECIAL CONTROL 1 CONTROL 2 CONTROL 3 Figura 8. Esquema sobre el módulo especial de los clientes remotos en la aplicación En este esquema existe un nuevo módulo que hasta ahora no había aparecido (módulo especial). En este subprograma también aparece la ambigüedad cliente-servidor, ya que se trata de un servidor de clientes remotos, pero también es cliente del servidor local. Lo que sí está claro es que está al mismo nivel que cliente especial en la máquina donde reside la BD. Por tanto, tenemos toda una estructura de protocolo que refleja el funcionamiento del sistema 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 petición. 18

19 CLIENTE REMOTO SERVOR LOCAL MÓDULO ESPECIAL TRANSPORTE RED ENLACE CLIENTE ESPECIAL TRANSPORTE RED ENLACE NIVEL FÍSICO NIVEL FÍSICO Figura 9. Estructura de protocolos Para la realización 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 solución, que cumple las especificaciones del sistema, se ha conectado a red local y como medio de transmisión se ha utilizado cable coaxial (RG-58) que hace las funciones de bus local. Esta topología se puede variar fácilmente para obtener otra solución, 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 comunicación. En concreto, se ha optado por el protocolo de comunicaciones TCP/IP, dado su eficiencia. También permite que cualquier cliente remoto pueda acceder a BD para realizar una transacción ya sea en cualquiera de los ordenadores que compone el hardware de la solución para el control ó a 1000 Km de distancia en una máquina remota. El siguiente subprograma es el módulo especial, en un lado de la comunicación y cliente especial en el otro. La comunicación entre estos dos programas consiste únicamente en establecer una conexión TCP/IP por la que intercambian datos. El flujo de estos datos siempre será el mismo, es decir, el módulo especial recoge los datos de la capa superior y se los envía a cliente especial. En este caso el paquete que recibe de cliente remoto para módulo especial son datos. Únicamente añade información que formará parte del protocolo a este nivel. Esta función siempre es opcional pero para este caso se va a hacer uso del concepto ya que es necesario añadir datos innecesarios para cliente remoto. En concreto se trata de la LONGITUD. El cliente especial, en el otro lado, no sabe cuántos bytes tiene que leer del puerto. Solamente existen dos formas posibles: una, que la longitud del paquete sea constante; dos, que módulo especial envíe en una posición determinada la longitud del paquete ó al menos de la parte variable. Este concepto aparecerá después cuando se particularice para cada protocolo en cuestión. 19

20 Cuando cliente remoto quiera realizar una transacción que involucre a un solo elemento (protocolo uno a uno), el tamaño del mensaje es constante y no es necesario añadir longitud. En cambio, cuando se utilice un protocolo más eficiente donde cada transacción 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 añadir LONGITUD como parte del mensaje que módulo especial envía a cliente especial. A continuación se muestra, en la figura 10, un esquema de encapsulación de datos que se sigue en una torre de protocolos como la descrita previamente. Nivel N Datos Nivel N-1 Nivel 2 Datos (N) Datos (3)... Cabecera (N-1) Cabecera (2) Nivel 1 Datos (2) Cabecera (1) Figura 10. Esquema de encapsulación de datos que se sigue en una torre de protocolos 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 REMOTO 1. Protocolo uno a uno Se le nombra de esta forma ya que se trata de un protocolo básico donde cliente remoto solicita en cada transacción la lectura/escritura de un elemento. Dada la sencillez del mismo, 20

21 este tipo de mensajes tendrá una longitud constante, por lo que no se necesita añadir la LONGITUD (L) desde el punto de vista de clientes especiales. Atendiendo a la encapsulación de paquetes, se detalla en la figura 11 el flujo de información para un caso de lectura en BD. CLIENTE REMOTO F C lect Relleno SERVOR LOCAL Valor leído Valor leído F C lect Relleno MÓDULO ESPECIAL CLIENTE ESPECIAL F C lect Relleno Valor leído Valor leído F C lect Relleno MÁQUINA REMOTA MÁQUINA LOCAL PROTOCOLO TCP / IP Figura 11. Flujo de información para lectura en BD con protocolo uno a uno Se observa que el tamaño de los paquetes es constante. Cuando la cantidad de información no es suficiente para completar el tamaño del paquete, se le añade datos de relleno. En particular para se emplea 10 dígitos, 4 dígitos par F, 4 dígitos para C, 1 byte para lect y, finalmente 14 dígitos para Valor leído (este formato ya se explicó en un apartado anterior). No es necesario añadir información adicional (es decir, cabecera según el esquema de encapsulación) para pasar de una capa a otra. Por tanto, cada nivel espera del nivel anterior/superior un número de bytes ó dígitos conocidos. El caso de escritura es exactamente igual con el tamaño de mensaje conocido por todas las capas, sólo que en la dirección cliente remoto hacia servidor local, en vez de utilizar relleno en el paquete. En ese trozo de mensaje iría el valor a leer ó escribir, y viceversa para el sentido contrario. 21

22 2. Protocolo uno a N Este protocolo es más eficiente que el anterior ya que, en cada transacción con el servidor, se escribe/lee N elementos. De esta forma, hacemos más eficiente el sistema debido a que la aplicación 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 más eficiencia en el funcionamiento. Este concepto se muestra en la figura 12. CLIENTE REMOTO SERVOR LOCAL F C lect Index T am Relleno Lista valores Lista valores F C lect Index Tam Relleno MÓDULO ESPECIAL CLIENTE ESPECIAL F C lect Index Tam Relleno Longitud Lista valores Longitud Lista valores F C lect Index Tam Relleno MÁQUINA REMOTA MÁQUINA LOCAL PROTOCOLO TCP / IP Figura 12. Flujo de información para lectura en BD con protocolo uno a N. Cliente remoto El tamaño 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 añadir el parámetro LONGITUD ó L (longitud de valores variables). Por tanto, el otro extremo no tiene más 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

23 CLIENTE REMOTO SERVOR LOCAL F C esc Index Tam Lista de valores F C lect Index Tam Relleno Lista de valores MÓDULO ESPECIAL CLIENTE ESPECIAL F C lect Index Tam Longitud Lista de valores Longitud = 0 Relleno Longitud = 0 Relleno F C lect Index Tam Longitud Lista de valores MÁQUINA REMOTA MÁQUINA LOCAL PROTOCOLO TCP / IP Figura 13. Flujo de información para escritura en BD con protocolo uno a N. Cliente remoto En el caso de lectura de N elementos, no se envía el parámetro L en la dirección cliente remoto a servidor local, ya que la petición se realizaba a través de un mensaje de tamaño constante. En cambio, en el otro sentido, sí se hace necesario. En la escritura, L se envía en ambos sentidos. A la hora de diseñar el módulo especial en la máquina remota, se toma como premisa que tendrá varios clientes en una dinámica 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 distinción entre protocolos es sencilla, ya que con una única identificación de petición asociada a este protocolo (uno a N) se puede diferenciar del resto. Pero diferenciar una lectura de una escritura en la máquina remota se hace más difícil. Una forma posible es que la máquina local (a través de cliente especial) envíe una LONGITUD = 0. De esta forma, el módulo especial, diferencia cada protocolo con y si se trata de lectura ó escritura con el parámetro LONGITUD ( LONGITUD =0, se trata de una escritura a BD; LONGITUD > 0, lectura a BD). 23

24 LOCAL En este caso, el flujo de mensajes se reduce considerablemente. Además 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 tamaño. 1. Protocolo uno a uno Se muestra el caso de lectura en BD en la figura 14. F C lect Relleno SERVOR LOCAL Valor leído CLIENTE LOCAL CLIENTE LOCAL Figura 14. Flujo de información para lectura en BD con protocolo uno a N. Cliente local En la escritura, el flujo de mensajes es exactamente igual, sólo que se le pasa un valor al servidor y éste devuelve la identificación de la petición y relleno. Esta identificación 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, sólo que se entrega una lista de valores para el caso de lectura en BD. El servidor devuelve la identificación de la petición e información de relleno que sirve para mantener un tamaño de mensaje constante. 24

25 Lista Valores F C Esc Relleno SERVOR LOCAL Relleno CLIENTE LOCAL CLIENTE LOCAL Figura 15. Flujo de información 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, sólo 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. Más adelante, cuando se pase a la descripción del código de la aplicación, se pone de manifiesto esta estructura. Para el cliente, la comunicación 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 parámetros de salida, como podría ser la identificación de la petición y los valores (resultado de la lectura) ó relleno (resultado de la escritura) EJEMPLOS IMPLEMENTADOS En este apartado se realiza una breve descripción de algunos clientes implementados para terminar de mostrar el funcionamiento ó flujo de información que tiene lugar en la aplicación ESTACIÓN METEOROLÓGICA Este cliente de la BD realizará accesos remotos a la misma y su función será únicamente escribir en determinadas variables. En concreto, sólo en las primeras 10 posiciones, según se mostró en la distribución de elementos en el vector en una figura anterior. Como no se trata de un elevado número de variables y frecuencia de refresco es pequeña (se escribe en las 10 variables, una vez por segundo), se opta por utilizar el protocolo uno a uno. 25

26 La situación física del cliente será la máquina CONTROL2 y este ordenador tiene comunicación mediante el puerto serie a una estación meteorológica, que periódicamente está enviando información. El flujo de información se muestra en la figura 16. ESTACIÓN METEOROLÓGICA SERVOR LOCAL ************** ************** MÓDULO ESPECIAL CLIENTE ESPECIAL ************** ************** MÁQUINA REMOTA MÁQUINA LOCAL PROTOCOLO TCP/IP Figura 16. Flujo de información de la estación meteorológica Se ha representado el caso de escritura de una temperatura que la estación meteorológica 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 posición 6 por parte de un cliente normal (tipo 0) la escritura (1) del valor 21,6 grados ( ,600000). El servidor después de atender la transacción devuelve el mismo y un valor de relleno (**************) que le sirve al cliente como acuse de recibo (en teoría de redes a esta operación se le conoce como ACK acknowledge- de la solicitud ó reconocimiento de la petición) INTERFAZ HOMBRE MÁQUINA (MMI) DE VISUALIZACIÓN DE ESTACIÓN METEOLÓGICA Este es el caso de un cliente que tendrá que existir en las tres máquinas por defecto, ya que un operador podrá visualizar el estado meteorológico de la planta solar desde cualquier ordenador que forme parte del sistema de control ó cualquier ordenador remoto en cualquier lugar del mundo mediante conexión TCP/IP. 26

27 Ú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 continuación se va a mostrar el flujo de información para los dos casos posibles: 1. Transacción local a la base de datos Como la función 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 información se muestra en la figura 17. SERVOR LOCAL ************** CLIENTE LOCAL CLIENTE LOCAL Figura 17. Flujo de información en la transacción local a la Base de Datos En este caso, se ha realizado una operación sobre la variable 6 (variable que guarda información sobre la temperatura de la Planta Solar), por parte de un cliente norma (cliente tipo 1) y es una operación de lectura (0). Para mantener el tamaño del paquete que se le entrega al servidor constante se completa con información de relleno (**************). El servidor atiende esta operación y devuelve el valor en cuestión de 21,6 grados centígrados ( ,600000). 2. Transacción remota a la base de datos Este flujo de información se muestra en la figura