METODOLOG A DE IMPLANTACI N DE SCADA EN LA … · en general sistema SCADA y debe estar en disposición de ofrecer las siguientes prestaciones: Posibilidad de crear paneles de alarma,

ANÁLISIS DE LA METODOLOGÍA DE

IMPLANTACIÓN DE UN SISTEMA

DISTRIBUIDO 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

ANÁLISIS DE LA METODOLOGÍA DE IMPLANTACIÓN DE UN SCADA DE UNA PLANTA SOLAR DE CONCENTRACIÓN MEDIANTE UN SISTEMA SCADA EN LA TECNOLOGÍA INDUSTRIAL

2

INDICE

1. INTRODUCCIÓN ...................................................................................................................... 3 2. SISTEMA SCADA ..................................................................................................................... 5 3. LABVIEW .................................................................................................................................. 8 4. COMUNICACIÓN APLICACIÓN 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. HISTÓRICOS .......................................................................................................................... 32

9.1. EXCEL VERSUS TXT...................................................................................................... 32 9.2. LOCAL VERSUS REMOTO............................................................................................. 36 9.3. USUARIO DE HISTÓRICO.............................................................................................. 38

10. CONTROL CAMPO .............................................................................................................. 39

10.1. FUNCIÓN....................................................................................................................... 39 10.2. ORDEN DE CAMPO...................................................................................................... 41 10.3. ORDEN DE HELIOSTATO ............................................................................................ 41 10.4. CALCULA COORDENADA............................................................................................ 41 10.5. ENVÍO DE ORDEN A HELIOSTATO ............................................................................ 42 10.6. ACTUALIZACIÓN DE BASE DE DATOS ...................................................................... 42 10.7. TORRE DE PROTOCOLOS.......................................................................................... 42

11. DESCRIPCIÓN DEL CÓDIGO.............................................................................................. 46

11.1. SERVIDOR LOCAL ....................................................................................................... 46 11.2. DESCRIPCIÓN DE CLIENTES ..................................................................................... 74

12. CONCLUSIÓN .................................................................................................................... 101 13. BIBLIOGRAFÍA .................................................................................................................. 102


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


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


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.


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%


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


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


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 sub-

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

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.

Figura 1. Ejemplo de Panel Frontal


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.

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

Figura 2. Ejemplo de Diagrama de Bloques


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 DARPA2, 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


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-SERVIDOR

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.


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

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.

ID FILA COLUMNA LECT/ESC VALOR

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:

� ID: 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 10000 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 ID 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.

Figura 3. Paquete de acceso a la Base de Datos


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.


15

Estación Meteorológica 1-10

Control Global 11-49

Foco 50-149

Tanque 150-249

Variables del sistema 250-349

350-499

Coordenadas Grupo en Foco 500-699

700-999

Numero de Heliostato 1000-1999

Acimut 2000-2999

Elevación 3000-3999

Estado 4000-4999

Orden Heliostato 5000-5999

Orden Campo 6000-6499

X-Foco 6500-7499

Y-Foco 7500-8499

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.

Figura 4. Ejemplo de distribución de elementos en la Base de Datos


16

Por tanto, el esquema global de funcionamiento de cliente-servidor en la investigación sería el

que se muestra en la figura 6.

Se puede observar que la única conexión entre el cliente y servidor son las colas de entrada y

salida.

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.

SERVIDOR

LOCAL

SERVIDOR

LOCAL

CLIENTE 1

CLIENTE 2

CLIENTE 3

Figura 5. Esquema de funcionamiento del servidor local

Figura 6. Esquema global de funcionamiento de cliente-servidor


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.

CONTROL 1

CONTROL 2

CONTROL 3

SERVIDOR LOCAL

CLIENTE 1

CLIENTE 2

CLIENTE ESPECIAL

CLIENTE REMOTO

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.

Figura 7. Esquema sobre tipos de clientes locales en la aplicación


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.

CONTROL 1

CONTROL 2

CONTROL 3

SERVIDOR LOCAL

CLIENTE 1

CLIENTE 2

CLIENTE ESPECIAL

MÓDULO ESPECIAL

CLIENTE REMOTO 1

CLIENTE REMOTO 2

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.

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 petición.

Figura 8. Esquema sobre el módulo especial de los clientes remotos en la aplicación


19

CLIENTE REMOTO

MÓDULO ESPECIAL

CLIENTE ESPECIAL

SERVIDOR LOCAL

NIVEL FÍSICO

TRANSPORTE RED

ENLACE

TRANSPORTE RED

ENLACE

NIVEL FÍSICO

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.

Figura 9. Estructura de protocolos


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.

Datos

Cabecera (N-1)

Datos (3)

Datos (N)

Cabecera (2)

Datos (2) Cabecera (1)

Nivel N

Nivel N-1

Nivel 2

Nivel 1

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 básico donde cliente remoto

solicita en cada transacción la lectura/escritura de un elemento. Dada la sencillez del mismo,

Figura 10. Esquema de encapsulación de datos que se sigue en una torre de protocolos

.

.

.


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.

PROTOCOLO TCP / IP

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

Figura 11. Flujo de información para lectura en BD con protocolo uno a uno

CLIENTE REMOTO

MÓDULO ESPECIAL

MÁQUINA REMOTA

MÁQUINA LOCAL

CLIENTE ESPECIAL

SERVIDOR LOCAL

F C lect Relleno

F C lect Relleno F C lect Relleno

F C lect Relleno

ID

ID

ID ID Valor leído ID Valor leído ID

Valor leído ID

Valor leído ID


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

MÓDULO ESPECIAL

MÁQUINA REMOTA

MÁQUINA LOCAL

CLIENTE ESPECIAL

SERVIDOR LOCAL

F C lect Index Tam Relleno


ID

ID

ID ID ID ID

Lista valores

ID

ID


F C lect Index Tam Relleno Lista valores

Lista valores Lista valores Longitud Longitud

PROTOCOLO TCP / IP

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

Figura 12. Flujo de información para lectura en BD con protocolo uno a N. Cliente remoto


23

CLIENTE REMOTO

MÓDULO ESPECIAL

MÁQUINA REMOTA

MÁQUINA LOCAL

CLIENTE ESPECIAL

SERVIDOR LOCAL

F C esc Index Tam

F C lect Index Tam

ID

ID ID

ID

ID

Relleno

Longitud = 0

Lista de valores

Longitud

Lista de valores

F C lect Index Tam

ID

Longitud

Lista de valores

F C lect Index Tam

ID

Lista de valores

Relleno

ID

Longitud = 0

Relleno

PROTOCOLO TCP / IP

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 ID 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).

Figura 13. Flujo de información para escritura en BD con protocolo uno a N. Cliente remoto


24

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

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

Figura 14. Flujo de información para lectura en BD con protocolo uno a N. Cliente local

SERVIDOR LOCAL

CLIENTE LOCAL

CLIENTE LOCAL

F C lect Relleno ID

Valor leído ID


25

SERVIDOR LOCAL

CLIENTE LOCAL

CLIENTE LOCAL

F C Esc Relleno ID

Relleno ID

Lista Valores

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

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

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

Figura 15. Flujo de información para escritura en BD con protocolo uno a N. Cliente local


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.

PROTOCOLO TCP/IP

ESTACIÓN METEOROLÓGICA

MÓDULO ESPECIAL

MÁQUINA REMOTA

MÁQUINA LOCAL

CLIENTE ESPECIAL

SERVIDOR LOCAL 6 0 1 +000021.600000

6 0 1 +000021.600000

ID

ID

ID ID

ID

ID

**************

ID

ID

6 0 1 +000021.600000

6 0 1 +000021.600000

**************

**************

**************

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 (+000021,600000).

El servidor después de atender la transacción devuelve el mismo ID 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).

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

Figura 16. Flujo de información de la estación meteorológica


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.

SERVIDOR LOCAL

CLIENTE LOCAL

CLIENTE LOCAL

6 1 0 ************** ID

+000021.600000 ID

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 (+000021,600000).

2. Transacción remota a la base de datos

Este flujo de información se muestra en la figura 18.

Figura 17. Flujo de información en la transacción local a la Base de Datos


28

VISUALIZACIÓN ESTADO METEOROLÓGICO

MÓDULO ESPECIAL

MÁQUINA REMOTA

MÁQUINA LOCAL

CLIENTE ESPECIAL

SERVIDOR LOCAL 6 1 0 **************

ID

ID

ID ID

ID

ID

ID

ID

+000021.600000

6 1 0 **************

6 1 0 ************** 6 1 0 **************

+000021.600000

+000021.600000

+000021.600000

PROTOCOLO TCP / IP

El funcionamiento es muy parecido al caso local, aunque hay más agentes implicados para

realizar la transacción.

7.4.3. OTROS EJEMPLOS

En este apartado se hará una breve introducción de otros clientes que también forman parte de

la aplicación final, sólo que por el flujo de información o por que es necesario introducir algunos

aspectos más 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.

Figura 18. Flujo de información en la transacción remota a la Base de Datos


29

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 elevación. Si esto es necesario para todos

los heliostatos, tendríamos que realizar 2000 lecturas sobre la BD. Se hace imprescindible el

uso de un protocolo eficiente que en pocas transacciones sea capaz de obtener información y

actualizar BD, sin que esto provoque sobrecarga del sistema.

2. Calcula Coordenada

Este bloque se encarga de calcular el acimut y elevación de todos los heliostatos a partir de las

coordenadas cartesianas que tienen en el campo y de la posición del Sol. Por tanto, tiene que

conocer acimut y elevación de todos los elementos (2000 valores) y de actualizar la BD con los

nuevos valores calculados (2000 valores). También se hace imprescindible el uso de un

protocolo eficiente (uno a N).

3. Histórico

Este cliente se ha diseñado con la función de crear históricos del sistema. De nuevo aparece el

concepto de cliente remoto/cliente local, ya que se debería permitir la creación de históricos

desde cualquier máquina.

Para la generación de históricos locales se ha diseñado un protocolo especializado que sea

capaz de pedir 500 variables por ejemplo al servidor, pero salteadas. Este detalle es

importante, ya que hasta ahora sólo se han especificado dos tipos de protocolos, uno a uno y

uno a N (dirección y número de elementos consecutivos). Por tanto, si deseamos leer 500

variables que van desde la posición 1 hasta la 8000, tendríamos que realizar 500 transacciones

para cada uno (protocolo uno a uno ) o leer 8000 variables por cada transacción (protocolo uno

a N). Por tanto, para dotar al sistema de eficiencia se opta por diseñar un nuevo tipo de

protocolo.

También hay que resaltar que la generación de históricos se puede volcar sobre ficheros de

Excel (LabView lo permite) o sobre ficheros de texto. La gestión de información en formato

Excel es más sencilla que en formato texto, pero es necesario mantener abierto el fichero

abierto (que va almacenando el histórico en memoria) con el consiguiente aumento del uso de

memoria RAM. Estoy podría ralentizar el sistema si se solicitan históricos de muchas variables

y durante mucho tiempo.

Para resolver este problema, el usuario podrá generar históricos en formato Excel ó texto

(extensión txt).

8. PROTOCOLOS EFICIENTES

Se detallan cada uno de los protocolos.


30

8.1. PROTOCOLO UNO A UNO

El tipo de mensajes que utiliza este protocolo se detalló previamente. Por cada transacción con

el servidor, se realiza una operación de lectura/escritura en BD y por ello, se pierde eficiencia.

En teoría de redes, este tipo de protocolo es del tipo envía y espera, como se indica en la figura

19. Este protocolo se usará cuando el número de elementos a leer ó escribir sea pequeño.

Mensaje de petición

Tiempo de proceso

Mensaje de respuesta

8.2. PROTOCOLO UNO A N

En este protocolo, por cada transacción 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 número de elementos en BD y es muy eficiente si el número de

elementos es consecutivo. Se aclara este protocolo con el siguiente ejemplo, para aquellos

clientes que tengan que actualizar la posición de los 1000 heliostatos, es decir, transmitirle a

cada uno el ángulo de acimut y elevación, y recoger de cada uno el acimut y elevación real.

Esto implica lectura de 2000 elementos en BD, 1000 de acimut y 1000 de elevación a transmitir

a cada elemento del campo; la escritura de 3000 elementos, 1000 de acimut real, 1000 de

elevación real y 1000 para la actualización de estado. Lógicamente, la distribución 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 aplicación es Control Campo, como se muestra en la

figura 20, que es el que se encarga de la comunicación con el campo.

Figura 19. Protocolo uno a uno


31


Tiempo de proceso Mensaje de respuesta

En la figura anterior se ha representado un ejemplo de escritura de N elementos en BD.

Comparándola con la figura anterior para el protocolo uno a uno, es lógico que el servidor

necesite más tiempo de CPU para la preparación de datos de N elementos en vez de 1

elemento. Este protocolo se usa para la escritura/lectura de un número de elementos

considerable.

8.3. PROTOCOLO PARA VARIABLES ALTERNATIVAS

Este tipo de protocolo se usa para leer/escribir un número elevado de variables no

consecutivas. Por ejemplo, si se necesita leer 500 variables, donde la primera es la variable

que ocupa la posición 10 en la BD y otra, ocupa la posición 8.000, se podría utilizar el protocolo

uno a uno, que realizaría 500 transacciones. También 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 sólo las que se necesitan. Por tanto, ninguno de los dos

protocolos es el más indicado. Parece adecuado el diseño de un tipo de protocolo, como se

muestra en la figura 21, que haga eficiente este tipo de operaciones.

Figura 20. Protocolo uno a N


32


Tiempo de proceso Mensaje de respuesta

En esta figura se muestra el uso de este protocolo para una escritura de elementos en BD. Un

ejemplo de clientes de la aplicación que hagan uso del mismo, es Histórico Local, que se

encarga de la generación de históricos en la misma máquina en donde está la BD. En la

configuración de histórico, se debe indicar las variables que se desean. Por tanto, si el número

de variables es grande y el intervalo de tiempo entre muestreos es pequeño, este protocolo se

convierte en ideal para este tipo de clientes y hace eficiente esta operación.

9. HISTÓRICOS

En un sistema SCADA para el control, supervisión y adquisición de datos de un proceso

industrial, en general, la generación de históricos se hace imprescindible. En el caso particular

de la planta solar, una de las muchas aplicaciones de los históricos sería el estudio del

resultado de determinadas estrategias de control ó la evolución meteorológica a lo largo del

día.

9.1. EXCEL VERSUS TXT

En este caso particular se genera históricos mediante dos posibilidades: volcado de datos

sobre Excel ó sobre un fichero de texto. A continuación, se comenta las ventajas e

inconvenientes de cada uno.

9.1.1. GENERACIÓN DE HISTÓRICOS SOBRE UN FICHERO DE EXCEL

Este módulo tiene la función de pedir datos al servidor de BD periódicamente. Inicialmente

arranca una ventana de configuración que solicita las variables a las que se quiere obtener el

histórico y el intervalo de tiempo que transcurre entre muestreos, es decir, entre peticiones de

lectura al servidor.

Figura 21. Protocolo para variables alternativas


33

Se hace uso de la facilidad que LabView ofrece de comunicación con otras aplicaciones que

corren sobre la misma máquina mediante protocolo DDE3. Los requisitos que se necesitan son

los siguientes:

1. Se necesita tener el programa Excel abierto, ya que de forma contraria, al arrancar el

módulo de históricos aparece un mensaje de error informando de que ha sido imposible

establecer la comunicación.

2. La generación 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 operación se

hace ineficiente. La solución que se lleva a cabo consiste en abrir la hoja Excel y no

cerrarla hasta que no finalice la generación de histórico. De esta manera, se vuelcan

los datos directamente sobre esta aplicación. Estos datos se van cargando

directamente sobre memoria RAM sin acceder al disco duro hasta la finalización del

histórico.

En cuanto a los inconvenientes que se tienen:

1. El inconveniente principal que tiene la solución descrita es que los datos se van

almacenando temporalmente sobre memoria RAM. Esto quiere decir que si la

generación se programa para mucho tiempo y el número 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 máquina,

incluso llegando a aparecer algún mensaje de error si el tamaño de la hoja es

demasiado grande.

2. El utilizar una hoja Excel hace que automáticamente 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 históricos de la siguiente

forma, cada columna muestra el histórico de una variable de la BD. Esto quiere decir

que se podría generar como máximo el histórico de 256 variables. Para un número

mayor, habría que volver a ejecutar el módulo para poder programar más variables. El

límite de filas impone una condición sobre el tiempo máximo que se puede estar

obteniendo información. Si se programa la generación de históricos cada cierto tiempo

T, el tiempo máximo que se puede estar generando histórico sería:

TTT ⋅=⋅= 65536216max

3 Acrónimo en inglés de Dinamic Data Exchange


34

Para un ejemplo de T = 10 seg:

horassegT 1821065536max =⋅=

El funcionamiento general de este cliente se detalla a continuación:

Inicialmente, se abre una ventana de diálogo con el usuario donde se programa la generación

de histórico (intervalo de tiempo entre petición de datos al servidor y variables). A continuación,

el módulo Genera histórico se programa para pedir una petición de lectura al servidor cada

intervalo de tiempo programado. Esta petición se inserta en la cola y es atendida por el servidor

local, que accede a BD para realizar la operación. El resultado se devuelve al módulo a través

de una cola de salida. Este resultado es recogido y se guarda en la hoja Excel a través de un

diálogo mediante protocolo DDE con dicho programa. Este funcionamiento se detalla mediante

la figura 22.

GENERA HISTÓRICO

SERVIDOR LOCAL

USUARIO

PROTOCOLO DDE

1

2

3

4

5

6

7

8

Figura 22. Generación de históricos sobre un fichero Excel


35

Este ejemplo representa el funcionamiento de los históricos a nivel local. En el siguiente

apartado se discute la opción local frente a remoto.

9.1.2. GENERACIÓN DE HISTÓRICOS SOBRE UN FICHERO DE TEXTO

Para resolver algunos de los inconvenientes de la generación de históricos sobre fichero Excel

se presenta una segunda opción para la generación de histórico. De esta forma, el usuario

final, durante el trabajo cotidiano, según el tipo de histórico (número de variables y tiempo

programado) se podrá elegir la opción más adecuada.

Los requisitos que se necesitan son:

De la misma forma que se hizo para el primer tipo de generación, los requisitos de esta

segunda opción son mínimos, ya que no es necesario tener abierta ninguna aplicación, 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 visualización directa de la información adquirida

desde el fichero de texto, ya que no queda agrupada de la misma forma como en el caso de

Excel. Así como la manipulación de los datos, que se hace más difícil.

En cambio, se resuelve los problemas de número máximo de variables y tiempo máximo, ya

que no se tiene un límite. También se resuelve los problemas de aumento del uso de memoria

RAM ya que el tamaño que ocupa es pequeño (al ser texto) en comparación con la hoja, junto

con el programa Excel.

El esquema de funcionamiento es muy parecido al que se tenía para la hoja de Excel, como se


Figura 23. Generación de históricos sobre un fichero de texto

GENERA HISTÓRICO

SERVIDOR LOCAL

USUARIO

1

2

3

4

5

6

7

8

FICHERO DE TEXTO


36

9.2. LOCAL VERSUS REMOTO

En este apartado se pretende exponer las diferencias que existen entre la generación de

históricos de forma local frente a la remota, refiriéndonos a esta última a la generación de

históricos desde una máquina 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 sólo se ha diseñado a nivel local,

pensando que fundamentalmente la generación de históricos se hará desde el ordenador que

tenga la funcionalidad MMI4, esto es, desde CONTROL 3. En este ordenador reside también la

BD, por tanto, es poco probable que se generen históricos desde otros ordenadores.

Debido a que es necesario cubrir todas las posibles alternativas y pensando en alguna opción

de programación de históricos desde algún ordenador cuya función no sea ésta, es decir,

CONTROL 1 ó CONTROL 2, también se va a contemplar esta última posibilidad, pero no se ha

diseñado un protocolo de variables no consecutivas remoto, ya que, en principio, sólo lo usaría

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

Según lo que se ha comentado anteriormente, este protocolo está diseñado para ser ejecutado

en la máquina 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.

El protocolo DDE se utiliza en caso de usarse la hoja Excel y la que se utilice para la

generación de históricos. La figura 24 sería la estructura que se tendría dentro de la misma

máquina.

GENERA HISTÓRICO

SERVIDOR LOCAL

EXCEL o TXT

USUARIO FINAL

Figura 24. Generación de históricos de forma local


37

9.2.2. REMOTO

Para el caso de generación de históricos desde una máquina 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 tendría sería la que se muestra en la

figura 25.

Como protocolo de transporte/red se utiliza el protocolo TCP/IP. El protocolo que utiliza el

subprograma módulo especial con el módulo cliente especial no se le ha dado un nombre

específico, pero es muy simple, ya que únicamente lo que se hace es establecer una conexión

entre ambas máquinas por las que poder enviar datos. También utiliza un modelo cliente-

servidor porque en la máquina local (donde reside BD), el módulo cliente especial, se mantiene

escuchando por el puerto, a la espera de establecimiento de conexión. Mientras que en la

máquina remota, el módulo especial es el que realiza la petición de establecimiento de

conexión.

4 Acrónimo en inglés de Man-Machine Interface

GENERA HISTÓRICO

EXCEL o TXT

USUARIO FINAL

CLIENTE ESPECIAL

SERVIDOR LOCAL

NIVEL FÍSICO

TRANSPORTE RED ENLACE

MÓDULO ESPECIAL

TRANSPORTE RED ENLACE NIVEL FÍSICO

Figura 25. Generación de históricos de forma remota


38

9.3. USUARIO DE HISTÓRICO

El histórico generado se puede visualizar directamente desde el fichero generado. En este caso

la hoja de Excel es una opción elegante para tal fin. Pero manteniéndonos dentro del entorno

del SCADA, y en concreto, del programa LabView, se necesita recoger los datos del fichero

generado y presentarlos como una pantalla más, como una opción más de la aplicación. Por

tanto, se necesita un nuevo subprograma que acceda al fichero de históricos, recoja los datos

necesarios y los muestre en pantalla.

Desde el principio, y haciendo distinción entre las distintas divisiones del Proyecto, en esta

parte se diseña el entorno que necesita el cliente para acceder a cualquier servicio, pero nunca

se especifica un cliente en cuestión, sino que siempre se ha presentado como una caja negra,

en donde, a través de un protocolo, hace la solicitud de una transacción.

En este apartado tampoco se viola la filosofía seguida, pero sí que se preparan los datos para

que un usuario final sólo tenga que representar esa información 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 histórico de una

determinada variable. Tanto el vector, como la matriz, son parámetros de salida que se le

entregan a un cliente de históricos, como se muestra en la figura 26.

REPRESENTACIÓN

HISTÓRICOS

USUARIO DE HISTÓRICOS

GENERACIÓN DE HISTÓRICOS

CONFIGURACIÓN DE

HISTÓRICOS

En esta figura se pone de manifiesto la distinción entre cliente final y entorno de la aplicación.

Se han diseñado los módulos para que un cliente final pueda realizar la solicitud de un servicio

Figura 26. Estructura de usuario de histórico


39

desde cualquier máquina, 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 operación

se ha representado como cajas cuadradas. Éstas se han diseñado en esta parte de la

investigación y de las que, más adelante, en un apartado posterior, se describirá el código.

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. FUNCIÓN

Este módulo ó subprograma se encarga de actualizar la posición de todos los heliostatos que

conforman el campo. La actualización implica el envío de información en ambos sentidos. En el

sentido control del campo, la información que se le puede enviar a cada elemento es diferente,

según 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 ó información que se le solicite en la orden. De esta forma, este estado sirve como

acuse de recibo para el sistema SCADA.

1. Petición de estado

Esta orden no requiere transmisión de datos adicionales en el control, pero sí requiere el envío

de datos en el sentido de adquisición de información, es decir, cada heliostato debe enviar

información del estado en el que se encuentra.

2. Mover heliostato

Esta orden requiere que el sistema SCADA envíe, a cada heliostato del campo, información

sobre la posición que debe tomar. Esta posición se le va a dar en forma de ángulos (acimut y

elevación). 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 transmisión 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.


40

10.1.2. ESTADOS

Los estados posibles en los que se puede encontrar un heliostato en el campo pueden ser los

siguientes:

1. Parado

2. Movimiento

3. Buscando fin de carrera

4. Fin de carrera

255. Imposible de comunicar (timeout).

A través de la orden 3 (buscar cero), se llega al estado 3. En él se ordena al heliostato que

retorne a una posición 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 módulo,

se presenta la figura 27.

CONTROL

DE CAMPO

CALCULA COORDENADA

COMUNICACIÓN

SERIE

1

2

3

Figura 27. Estados de los heliostatos


41

El funcionamiento de control campo consiste en repetir una serie de operaciones de forma

periódica. Por tanto, se tiene un bucle que siempre realiza lo mismo. Las operaciones a realizar

son las siguientes:

1. Comprobar si hay alguna orden de campo.

2. Obtener orden para cada heliostato.

3. Calcula la posición para cada heliostato.

4. Envía orden para cada heliostato.

5. Actualiza base de datos.

10.2. ORDEN DE CAMPO

Dentro del sistema de control de la planta solar, además de enviar una orden a cada uno de los

heliostatos, se pretende tener un sistema más inteligente, en el que se pueda ejecutar macros

que afecten a más de un heliostato ó a todos, en general. En principio, se han reservado 500

variables para tal fin.

Un ejemplo de uso sería la orden abatimiento por seguridad, con la que todos los heliostatos se

abatirían por diversos motivos, por ejemplo, gran velocidad del viento, ó posición de limpieza,

en la que todos ó parte se colocarían en posición especial para que el personal de

mantenimiento realice funciones de limpieza de los espejos.

Por tanto, el módulo control de campo, en primer lugar, comprueba que no hay ninguna orden

de campo; en caso contrario, realizaría la acción adecuada a cada orden.

10.3. ORDEN DE HELIOSTATO

El módulo 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 transacción con el servidor, se logra leer 1000

variables.

10.4. CALCULA COORDENADA

Dependiendo del tipo de orden, puede que haga falta la nueva posición a la que deba apuntar

cada elemento del campo. Incluso sin llegar a hacer falta, se procede al cálculo de la nueva

posición, ya que al final del subprograma hay que actualizar la BD y en esta actualización

también se ve afectada las variables relacionadas con acimut y elevación.

Este módulo calcula los nuevos ángulos de acimut y elevación a partir de unos determinados

parámetros, como puede ser la posición de cada heliostato en el campo ó la posición del Sol.


42

10.5. ENVÍO DE ORDEN A HELIOSTATO

Esta es una operación crítica en el sistema, ya que debe comunicarse con cada heliostato,

transmitir la nueva orden y obtener estado. Para ello, esperará un byte que le envía el elemento

en cuestión.

La comunicación 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 tardaría un total de 20

segundos en actualizar la posición de todo el campo.

El módulo de control hace uso de un módulo de comunicación, al que pasándole una dirección

de elemento y la orden correspondiente, devuelve un byte de estado. Este módulo no se

describe con detalle en esta parte de la investigación.

10.6. ACTUALIZACIÓN DE BASE DE DATOS

Tras concluir la comunicación con el campo de heliostatos, es necesario actualizar la BD. Se

actualiza el estado de cada heliostato, orden, acimut, elevación, orden de campo... etc.

Es necesario actualizar orden de heliostato ya que en caso contrario, se volvería a ejecutar la

misma orden. Este es un aspecto importante, pues debe haber un sincronismo entre

actualización de orden por parte del control campo y del módulo de usuario, que a partir de la

información transmitida por el personal de control de la Planta, actualice la nueva orden para

cada elemento. También 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

Según se ha especificado en el funcionamiento de este módulo, existe dos flujos diferentes de

información, uno de ellos consiste en la transacción de información con BD, ya sea para

escribir ó para leer variables, y otro, la actuación sobre el campo, operación importante ya que

es la que da nombre al sistema SCADA (Supervisión, Control y Adquisición de Datos). Con

este último flujo de información se tiene el control y la adquisición de datos del proceso ó planta

solar. La supervisión del sistema no se contempla en este trabajo y es relativamente sencilla,

ya que sólo se tiene que supervisar que determinadas variables de BD no sobrepasen

determinados límites.

El esquema que se plantea para este módulo se recoge en la figura 28.


43

CONTROL CAMPO

CLIENTE ESPECIAL

SERVIDOR LOCAL

NIVEL FÍSICO

TRANSPORTE RED ENLACE

MÓDULO ESPECIAL

TRANSPORTE RED ENLACE NIVEL FÍSICO

HELIOSTATOS

10.7.1. UN CASO DE LECTURA

En el diagrama de la figura 29 se detalla el tipo de información que pasa de unos módulos a

otros y entender mejor el proceso de encapsulación en el que se ven involucrados los datos.

Esta información será de gran utilidad para posteriormente entender el código.

Para un caso de lectura, el módulo de control de campo, envía un paquete normal, de tamaño

constante, similar al que se envía cuando se quiere leer un sólo 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 posición index y para un total de Tam elementos. A esta

información se le añade la identificación de petición y se envía de vuelta al origen. Cuando

llega a cliente especial, el tamaño 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 están en módulo especial, se le quita la longitud, ya que ésta no es

necesaria para la extracción por parte del módulo de control.

Figura 28. Torre de protocolos


44

En este diagrama no se ha incluido las capas que están por debajo de módulo 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 módulo de control de campo solicita una transacción en la

que se realice la escritura de un determinado número de elementos. El tamaño del mensaje no

es el típico, ya que a éste hay que añadirle al final las variables que se quieren escribir (que

forman un parte del mensaje de longitud variable, en función del número de elementos).

Antes de ser enviado a la máquina que contiene el servidor local, módulo especial debe añadir

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 extraído por cliente especial, llega al servidor

local, que atiende este servicio especial. Tanto en lectura como en escritura, para solicitar este

CONTROL CAMPO

CLIENTE ESPECIAL

SERVIDOR LOCAL

MÓDULO ESPECIAL

ID

F C lect Relleno Index Tam

4 4 1 4 5 5

ID


4 4 1 4 5 5

ID


4 4 1 4 5 5

ID

Datos_variables

Long_Datos Datos_variable

ID

4 <variable>

ID

Datos_variables

<variable> <variable>

1

2

3 4

5

6

Figura 29. Un caso de lectura en el flujo de información


45

servicio, se usa un ID (identificación de la petición) especial y el cliente debe ser también

especial (C).

El servidor atiende la petición 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 añade longitud aunque aparentemente no se debería hacer. De esta forma se

consigue que en destino, módulo especial pueda distinguir un caso de lectura/escritura de N

elementos, ó cualquier otro caso, con el parámetro longitud. Si longitud = 0 (como es el caso),

se trata de un caso de escritura de un determinado número de elementos en BD.

Una vez extraído el mensaje y diferenciado la lectura de la escritura, se le extrae el parámetro

longitud y se entrega al módulo de control de campo que usa este ID como acuse de recibo

(confirmación de que la escritura se ha hecho de forma adecuada). En la figura 30 se muestra

el caso de escritura.

CONTROL CAMPO

CLIENTE ESPECIAL

SERVIDOR LOCAL

MÓDULO ESPECIAL

ID

F C esc Relleno Index Tam

4 4 1 4 5 5

ID


4 4 1 4 5 5

ID

Relleno

Long = 0

ID

4

ID

Datos_escritura

<variable>

14

Long_Datos Datos_escritura

4 <variable>

ID


4 4 1 4 5 5

Datos_escritura

<variable>

Relleno

14

1

2

3 4

5

6

Figura 30. Un caso de escritura en el flujo de información


46

11. DESCRIPCIÓN DEL CÓDIGO

En este capítulo se hace una descripción del código de todos los conceptos teóricos que se

expusieron en el capítulo anterior, por ejemplo, la descripción del servidor de local que gestiona

las transacciones a BD, el cliente Control de Campo, la generación de históricos... etc.

Además de esta descripción, en cada Virtual Instrument perteneciente a la aplicación se

especifica cierta información de funcionamiento.

11.1. SERVIDOR LOCAL

En la figura 31 se muestra el panel frontal de la aplicación:

A primera vista, de cara al operador es bastante simple, en el que sólo se puede configurar los

tamaños de las colas. Existe un botón de STOP que para el servidor. Como se mencionó en la

descripción teórica de la aplicación, para realizar una petición 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 tamaño de estas colas. Este tamaño debe ser

pequeño, para que el tiempo de gestión de cola sea pequeño. Con un valor de 10 para ambas

Figura 31. Panel frontal de servidor local


47

es suficiente, ya que el servidor es demasiado rápido y es difícil 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 rápidamente. En otro caso, este aumento es

a una velocidad muy baja. Estos incrementos cada cierto tiempo, cuando el servidor está en

vacío, se deben a un timeout con el que se ha diseñado el subprograma y de esta forma así

poder sacar al servidor de la espera del evento y evitar la espera infinita del mismo.

A continuación, en la figura 32, se muestra la parte de programación del servidor local, es decir,

el diagrama de bloques del subprograma.

Esta primera pantalla corresponde a la fase de iniciación del servidor. Como se detalló en la

descripción teórica del capítulo anterior, se ha dimensionado una BD para 10000 variables.

Estas se inicializan con un valor de relleno (*).

Al botón 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 ejecución del programa, la variable recuerda el valor de la

última ejecución. En la figura 33 se muestra la pantalla que representa la estructura básica del

gestor de BD.

Figura 32. Diagrama de bloques del servidor local


48

Una de las ventajas de LabView es la programación modular. Para el diseño 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 (número 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 operación.

Si el operador pulsa el botón de STOP, el subprograma se sale por el bucle de control y finaliza

con la destrucción de las colas creadas al inicio. Este evento cambia el estado de la variable

global y cambia a FALSE la condición del bucle de operación.

Figura 33. Estructura básica del gestor de base de datos del servidor local


49

2. BUCLE DE OPERACIÓN

Este bucle es muy importante para el desarrollo adecuado del trabajo, ya que debe ser

dinámico, en el sentido que debe ajustar la velocidad a la cantidad de carga, es decir, ir rápido

cuando haya peticiones por atender y despacio cuando no las haya.

Se hace necesaria la programación orientada a eventos en la que se debe esperar al evento

insertar elemento en cola para que actúe el servidor. Este efecto se consigue con la acción que

se muestra en la figura 34.

Esta operación 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) Ningún 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 condición

del bucle, es decir, la condición se compone de:

VARIBLE GLOBAL ó PROBLEMAS DURANTE LA OPERACIÓN

Por tanto, si no hay elementos en la cola, la condición de problemas durante la operación no

debe afectar a la condición del bucle; si se sale de éste, que sea porque hubo alguna

modificación en la variable global.

Esto se especifica con más detalle en la figura 35.

Figura 34. Ejemplo de programación orientada a eventos


50

b) Algún cliente insertó elementos en cola y la petición ha sido leída. Este caso se refleja

en la figura 36.

En este caso, se atiende la petición. 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 operación y, si los hubo, que se salga del bucle, modificando la condición de salida.

Figura 35. Caso de no inserción de elementos en cola en la salida de la espera del evento

Figura 36. Caso de inserción de elementos en cola en la salida de la espera del evento


51

La línea gruesa del color rosa representa toda la base de datos. Es un vector de variables

cadena de caracteres de tamaño 10000. Se diseñó de esta manera para que se pueda insertar

en un elemento cualquier valor, ya sea numérico, una fecha... etc. simplemente haciendo la

correspondencia a cadena de caracteres (String). Además de esta forma se aprovecha el

formato String que es obligatorio utilizar para insertar en elementos en colas ó enviar

información a través 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 módulo.

1. FRONT PANEL

Se muestra en la figura 37 esta pantalla.

En esta pantalla, únicamente se visualizan los parámetros de entrada y de salida ó de

entrada/salida de este módulo. Por ejemplo, la cola de escritura debe ser un parámetro de

Figura 37. Panel frontal del módulo ATENDER COLA


52

lect/esc. Esto se consigue con dos variables, una de control (función de entrada) y otra

indicadora (función de salida). Otra variable de entrada/salida es BD (in, entrada y out, salida).

También se pasa el elemento que se ha leído y se saca la identificación de la petición (variable

de tipo indicador).

2. BLOCK DIAGRAM


Una vez que se ha leído una petición de la cola, se separa la identificación de la petición y de la

petición en sí, y ambas cosas se introducen en un nuevo subprograma ó módulo cuyo incono

se ha llamado gesti uno.

Después de la gestión del elemento, se inserta el resultado en la cola de salida, como se


Figura 38. Diagrama de bloques del módulo ATENDER COLA


53

El módulo Gestiona_uno se encarga de procesar la petición, como se muestra a continuación.

11.1.1.1. GESTIONA_UNO

En este apartado se va a explicar el panel frontal y el diagrama de bloques de este módulo.

1. FRONT PANEL


Figura 39. Inserción de un elemento en la cola de salida

Figura 40. Panel frontal del módulo GESTIONA UNO


54

Esta pantalla no muestra mucha información como suele ocurrir en los módulos

intermedios. Los parámetros que aparecen son del siguiente tipo:

BD_*: parámetro de entrada/salida (actualización de la BD).

Output Array: es una variable auxiliar que realiza funciones de visualización del resultado y

obliga a que el vector que se pasa a una estructura FOR sea de una determinada forma (con

unos determinados dígitos de precisión).

ID_*: parámetro de entrada/salida (identificación de petición).

String_*: parámetro de entrada/salida (petición con formato String).

2. BLOCK DIAGRAM


Este módulo es importante en el procesamiento de la petición ya que distingue varios casos y

si se trata de una transacción de lectura ó escritura. En principio, la petición en formato String

se transforma en F C lect/esc Valor. Esto se hace a través de un subprograma sencillo:

Figura 41. Diagrama de bloques del módulo GESTIONA UNO


55

Transforma_String. El siguiente paso es distinguir si se trata de una petición especial, es decir,

si se va a usar el protocolo uno a uno ó uno a N. Esto se hace a través de C. Con este

parámetro 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 petición especial (C=9999) hay que distinguir el caso de protocolo uno a N ó

de variables no consecutivas. Esto se hace con ID de la petición, 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 identificación de la petición se entra en un Case. Para el caso 0, se trata de este

protocolo en cuestión. La petición se procesa de nuevo, ya que en Transforma_String se

procesó una petición normal de un elemento. Se obtiene un index y un tamaño, 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 número 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 módulo GESTIONA UNO


56

Para una escritura, hay que sacar los elementos de la petición que de alguna forma el cliente

haya insertado. La petición se compone de index + offset + valores a esc. Los valores a esc se

transforman de formato String al formato adecuado (DBL, con un número determinado de

dígitos de precisión) y se introduce en un FOR para realizar la escritura.

Todos los elementos se escriben en BD a partir de la posición index. La BD se modifica en la

estructura FOR. Para hacer más rápida la operación de escritura se ha añadido un shift register

que de alguna forma evita que LabView trabaje en paralelo, es decir, con todo el vector (10000

elementos) en cada transacción y mantenga una copia de la misma, con lo que en cada paso

sólo 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 aplicación puede ocurrir que en tiempo de ejecución 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 módulo GESTIONA UNO


57

PROTOCOLO DE VARIABLES NO CONSECUTIVAS

El módulo 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 cuestión. Este protocolo se ha diseñado única y exclusivamente para un

cliente (genera históricos), como se muestra en la figura 44. Este cliente lee de la BD un

número grande de variables que no tienen por qué estar consecutivas. Por tanto, como es

usado por este cliente, sólo se presenta el caso de lectura. En posteriores revisiones se podría

completar este módulo con el caso de escritura para este protocolo.

El funcionamiento es muy simple, ya que después 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, sólo nos interesa la primera fila, por lo que deshabilitamos

la opción 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.

Figura 44. Caso de lectura en el protocolo de variables no consecutivas


58

PROTOCOLO UNO A UNO

Para terminar con este módulo, hay que distinguir el caso de transacciones en las que sólo 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 más sencilla. A continuación se muestra, en la figura 45, la lectura de un elemento

de la BD.

Se puede comprobar que BD permanece invariable y que en la petición 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 envía el valor que desea escribir en BD, como se


Figura 45. Caso de lectura en el protocolo uno a uno


59

Para formar la cadena de caracteres a enviar, se usa la identificación de la petición y un valor

de relleno para completar el tamaño del paquete enviado.

11.1.1.1.1. TRANSFORMA STRING

Para finalizar con el módulo del servidor local, únicamente resta por describir la función que

realiza este módulo.

1. FRONT PANEL


Figura 46. Caso de escritura en el protocolo uno a uno

Figura 47. Panel frontal del módulo TRANSFORMA STRING


60

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 identificación de la petición. Como parámetros de salida se tiene:

Fila: parámetro que se usa como dirección de la posición a leer/escribir de BD.

Columna: parámetro que distingue entre clientes.

Lectura/Escritura: parámetro que indica si se trata de una transacción de lectura ó de escritura.

Valor: parámetro 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 sólo observar los

parámetros de entrada y de salida. Este módulo se encarga de procesar la petición, es decir,

obtener la información ú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 módulo TRANSFORMA STRING


61

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

módulo es Scan from String, que permite obtener información encapsulada en una cadena de

caracteres. A esta “caja” se le puede pasar un parámetro de configuración de la cadena y

simplemente obtener las salidas deseadas, como se muestra en la figura 49.

Esta herramienta también permite extraer algunos parámetros y dejar el resto de la cadena

invariable. Esto es útil, ya que la petición puede usar cualquier protocolo. El comienzo de toda

petición es idéntico, lo que varía 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


62

Otra herramienta también muy útil y que la usará todo cliente para encapsular los datos, es la

que realiza el proceso inverso. Se trata del módulo Format into String, como se muestra en la

figura 50.

11.1.2. RESUMEN DEL MÓDULO SERVIDOR LOCAL

En este apartado se ilustra un esquema de módulos que se usan en el programa servidor local,


SERVIDOR LOCAL

GLOBAL_ESC ATENDER_COLA

Gestiona_uno

Transforma_String

Las variables globales en LabView se gestionan como un módulo más, pero algo especial,

porque no tiene diagrama de bloques. En este módulo irían 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 COMUNICACIÓN CON SERVIDOR LOCA L

Una vez presentado el servidor local y su funcionamiento, en este apartado se describe el

protocolo de comunicación con el servidor local para los distintos escenarios, es decir, para una

transacción de un elemento (tanto a nivel local como remoto), para una transacción de N

elementos (tanto a nivel local como remoto) y el protocolo de variables no consecutivas.

Figura 51. Esquema de módulos del programa servidor local


63

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 máquina en la que reside el

módulo que tiene que existir en el programa del cliente, debe hacerse de la siguiente forma.

1. FRONT PANEL


El usuario que quiera realizar una escritura/lectura de un elemento a nivel local, solamente

debe escribir una cadena (con el formato adecuado) y añadir una identificación a esa petición.

Cuando se ejecute el subprograma tendrá la certeza de que se ha realizado su petición, ya que

si lo desea podrá disponer de la identificación de su petición como parámetro 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 petición con el formato

adecuado (F C lect/esc Valor). La ejecución se divide en tres partes:

La primera de ellas consiste en la inserción de los datos en la cola de entrada, a los que

previamente se les ha realizado el procesado adecuado, es decir, se le ha añadido la

identificación de la petición, como se muestra en la figura 53.

Figura 52. Panel frontal del protocolo uno a uno local


64

Antes de insertar los datos en cola, es necesario abrir ó crear la misma. Esta función la realiza

la caja Create_queue.vi que devuelve un puntero ó identificación de la cola especificada, si

existe, ó crea una cola nueva, si no existe.

Es necesario que para un correcto funcionamiento de la aplicación se arranque en primer lugar,

el servidor, es decir, que sea éste el que controle la creación de las colas, ya que es éste el

que la destruye cuando finalice la ejecución del mismo. En otro caso, un cliente crea una cola

que todavía no existe y esperaría indefinidamente, ya que no hay servidor que atienda la cola.

En este caso debería aparecer un mensaje de error ó algo parecido, como se muestra en la

figura 54.

Figura 53. Inserción de los datos en la cola de entrada


65

La segunda parte de ejecución del protocolo consiste en mantenerse a la espera mientras el

servidor atiende la petición. Esto se implementa mediante un bucle al que se le añade una

temporización para evitar sobrecargar el sistema ya que en caso contrario el bucle iría

demasiado rápido (se ejecutaría demasiadas veces) mientras se está a la espera del servicio,


Figura 54. Creación de colas por parte del servidor

Figura 55. Mantenimiento a la espera mientras el servidor atiende la petición


66

En esta parte del protocolo, el cliente permanece a la espera mientras el servidor está

realizando el servicio. En cada iteración del bucle, se solicita el estado en el que se encuentra

la cola de salida. Se mira el número de servicios que hay en la misma y se compara la

identificación 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 identificación de la petición 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 ejecución de la última parte del protocolo implica que hubo una respuesta a la

solicitud realizada, ya que la identificación de la misma coincide. El siguiente paso será extraer

la información y pasarla al programa principal del cliente como parámetro de salida, como se


11.1.3.1.2. REMOTO

Para el caso de una petición de una transacción con BD desde una máquina en la que no

reside la misma, es necesario construir todo una torre de protocolos en la que la máquina

remota se pueda comunicar adecuadamente con la máquina local. Este tipo de protocolos se

detalla en el apartado siguiente cuando se describa el código del módulo especial y cliente

especial al que se hace referencia en la descripción teórica.

Figura 56. Respuesta a la solicitud realizada


67

11.1.3.2. PROTOCOLO UNO A N

11.1.3.2.1. LOCAL

Para este caso se ha diseñado el módulo Index_offset.vi. Este módulo 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


Los parámetros que aparecen en este módulo son los siguientes:

Offset: es un parámetro de entrada que se utiliza para indicar la dirección de comienzo de la

escritura/lectura de variables en BD (entrada).

Tam: número de elementos en esta transacción (entrada).

Lect/Esc: indica si la transacción es de lectura ó de escritura.

Array esc: parámetro de entrada. Mediante este array se pasan los valores en un caso de

escritura.

Resultado: parámetro de salida que contiene el resultado de la transacción (relleno en caso de

escritura ó los valores en formato adecuado en caso de escritura).

Figura 57. Panel frontal del protocolo uno a N local


68

2. BLOCK DIAGRAM


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 operación directamente, indicándole únicamente la configuración de los datos

que se le está pasando. Junto a esta transformación de datos, se tiene un procesamiento de la

petición de escritura, en la que se convierte los parámetros 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 módulo Cliente_index_offset.vi.

Para el valor de lectura, el array de valores a escribir se ignora.

Figura 58. Diagrama de bloques del protocolo uno a N local


69

El módulo Cliente_index_offset.vi consiste en la inserción en la cola de un valor y esperar el

resultado. Se trata de un caso especial (C=9999 y ID = 0). La inserción en la cola de entrada se

hace de la siguiente manera, como se muestra en la figura 60, 61 y 62.

Figura 59. Escritura en la base de datos

Figura 60. Inserción en la cola de entrada del servidor local


70

En estas imágenes se ha representado el proceso de inserción del mensaje en la cola de

entrada del servidor local, espera del resultado de la transacción y finalmente, la extracción del

Figura 61. Espera del resultado de la transacción

Figura 62. Extracción del mensaje con los valores leídos ó relleno


71

mensaje con los valores leído, para el caso de lectura, ó relleno, si se trata de una escritura en

BD. Se separa la identificación de la petición 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 comunicación entre máquinas 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 cuestión, es el

que se encarga de la generación de históricos. El programa inicialmente presenta una pantalla

para la configuración de la generación, como se muestra en la figura 63.

Figura 63. Pantalla de configuración de generación de históricos


72

En la configuración, 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: año

mm: mes

dd: día

De esta forma, cuando empiece un nuevo día, se cierra el fichero actual de históricos 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 más interesante del código 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.

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 información se

transforma a cadena de caracteres y se accede a la cola de peticiones del servidor local.

Figura 64. Acceso a la base de datos


73

Como se puede observar, el acceso es local, pero añadiendo más información podría

transformarse a remoto. Debido a que normalmente el tiempo de muestreo es muy grande en

comparación a la frecuencia interna del ordenador, este módulo carga muy poco el sistema, de

ahí que resida en la misma máquina 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.

Aunque ya se ha descrito con anterioridad este módulo, 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 información es necesario transformarla a vector y realizar

tantas lecturas de BD, como tamaño tenga el vector, ya que cada componente constituye la

dirección a leer. Finalmente el resultado se empaqueta junto con la identificación del proceso

para, finalmente, insertarla en la cola de resultado de peticiones.

La pantalla principal de este módulo será mostrada al técnico de la planta. Además tiene otras

funciones que no se han descrito en este apartado, ya que la información extraída es

Figura 65. Distinción de protocolos en el programa que gestiona la cola de acceso a base de datos


74

comparada con unos determinados límites. Si se sobrepasan, entonces, se genera una

ALARMA SONORA que, a modo de ejemplo, se ha configurado como un pitido.

11.2. DESCRIPCIÓN DE CLIENTES

11.2.1. CLIENTES INVOLUCRADOS EN EL ACCESO REMOTO

Antes de empezar con la descripción del código de los módulos involucrados, es interesante

retomar una figura que ya se ha descrito anteriormente, como se muestra en la figura 66.

CLIENTE REMOTO

MÓDULO ESPECIAL

MÁQUINA REMOTA

MÁQUINA LOCAL

CLIENTE ESPECIAL

SERVIDOR LOCAL



ID

ID

ID ID ID ID

Lista valores

ID

ID

F C lect Index Tam Relleno Lista valores

Lista valores Lista valores Longitud Longitud F C lect Index Tam Relleno

Se trata de una petición de lectura de N elementos al servidor local. En el sentido cliente a

servidor, el paquete intercambiado tiene tamaño constante, con lo que al transcurrir por la torre

de protocolos, cada nivel no necesita añadir información. 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 módulo especial (como

se ha identificado en la descripción teórica del trabajo). A la información intercambiada a este

PROTOCOLO TCP/IP

Figura 66. Flujo de información para lectura en BD con protocolo uno a uno


75

nivel es necesario añadirle la longitud ya con el resultado de la transacción se forma un

paquete que tiene tamaño desconocido, ó al menos, no predecible.

1. SERVIDOR REMOTO

A efectos de la comunicación entre módulo especial y cliente especial, uno de los dos tiene que

permanecer a la escucha y el otro, el que inicia la comunicación. Por tanto, el que permanece a

la escucha hace las funciones de servidor, ya que siempre está a disposición 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.

El módulo consiste en un bucle infinito y permanece siempre a la espera, escuchando en el

puerto durante 500 ms. Si durante este período de tiempo no recibe información, se inicia una

nueva iteración en el bucle. Esto se hace así, porque de otra forma no sería posible para el

servidor. Para que se inicie un tratamiento de la información, lo que reciba por el puerto debe

ser distinto de cadena de caracteres vacía. Cuando es distinto, entra en el módulo

Envía/Recibe, que se describe a continuación.

En toda comunicación establecida, debe ser posible finalizar la misma y será el cliente el que

finalice la conversación con el servidor. Por tanto, en el servidor debe hacerse un análisis

Figura 67. Caso de servidor remoto


76

adicional, ya que es posible que el cliente desee terminar la conexión, como se muestra en la

figura 68.

El módulo de servidor_remoto.vi se extrae el primer carácter. Este carácter se analiza en FIN ?,

si se trata del carácter de fin de conexión entonces se sale del bucle. En otro caso, se sigue

con el análisis de la petición de transacción a BD.

Pero además el módulo FIN tiene otras funciones, además de identificar el carácter de fin de

conexión. Si el cliente_remoto solicita una petición de lectura/escritura de N elementos, en este

módulo 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 añadir información

de longitud en el sentido servidor_remoto a cliente_remoto, ya que el contenido de la

información extraída de BD tiene un tamaño desconocida para cliente_remoto. En

cambio, en el caso de escritura, figura 69, el campo de longitud se usa sólo en el

sentido cliente_remoto a servidor_remoto, ya que es aquél que incorpora el contenido

de los elementos que se van a escribir en BD.

Figura 68. Finalización de la conversación con el servidor por parte del cliente


77

En principio, se compara el primer carácter recibido con “q”. Si coincide, entonces se trata de

un caso de fin de conexión. No hay posibilidad de confusión, ya que los paquetes de

información normales entre cliente y servidor siempre comienzan con un número (Fila).

Si se trata de una petición de transacción 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 distinción es el tipo de cliente. En este caso se tiene un control sobre el

número 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 también

todos los valores que se van a escribir, por lo que se extrae el campo longitud dentro del

paquete, se traduce esos caracteres a número y se lee del puerto el número que ha enviado

Cliente_remoto. Una vez extraída toda la información, 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 envía un acuse de recibo

(*******).

Para concluir con este módulo, se describe un caso de lectura de N elementos, como se


Figura 69. Caso de escritura de N elementos


78

En este caso, servidor_remoto no tiene que leer más datos del puerto y sólo tiene que insertar

la petición en la cola destinada a tal fin. Una vez atendida la solicitud, el siguiente paso es

calcular el tamaño de los datos y formar un paquete junto con los datos leídos (figura 71).

Finalmente, el paquete formado, ya sea una lectura ó escritura sigue su transcurso, ya sea con

el acuse de recibo ó con los datos leídos, se envían al cliente_remoto junto con la identificación

del proceso (ID) a través del puerto.

Figura 70. Caso de lectura de N elementos


79

1. CLIENTE REMOTO

Una vez comentado servidor_remoto, es necesario describir el funcionamiento del otro extremo

de la comunicación, como se muestra en la figura 72.

Figura 71. Módulo de creación del paquete y envío al cliente remoto

Figura 72. Descripción de la comunicación con el servidor remoto


80

Inicialmente, se intenta establecer la comunicación con el servidor_remoto. Para ello se le pasa

como parámetros la dirección IP y el puerto por el que se va a intentar la comunicación. Como

se puede comprobar, la estructura no tiene nada que ver con la del servidor, ya que aquel se

mantenía a la espera de algún cliente posible.

Una vez establecida la conexión, entra en un nuevo subprograma (client_remot) que realiza

toda la comunicación, como se muestra en la figura 73. Cuando finalice la ejecución del mismo,

significará que por el motivo que sea, ha finalizado la comunicación y hay que hacérselo saber

al servidor. Para ello se le envía “q” (carácter de fin de conexión).

En esta pantalla existe cierta complicación en la estructura del programa, pero la descripción

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:

Figura 73. Descripción del subprograma CLIENT_REMOT


81

Se muestra en la figura 74.

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 74. Bucle de escritura en el puerto

Figura 75. Bucle de lectura del puerto


82

Este bucle realiza la lectura de los datos del puerto pero, antes de hacerlo, registra el cliente

que hace petición de la transacción, 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 cómo se hace la recepción en el puerto, es decir,

anteriormente se explicó que a este nivel era necesario rellenar un campo de longitud que

todavía no se ha descrito en este apartado. A continuación, se muestra en la figura 76.

En el centro del bucle de esta nueva figura aparece un CASE, que según 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 transacción 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 comunicación según se tratase de una transacción

de lectura ó escritura, se añadía 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 número mayor que cero entonces quiere decir que el paquete de

Figura 76. Recepción en el puerto


83

información trae más datos, por tanto, es una transacción de lectura y hay que terminar de leer

los datos del puerto.

Una vez que se ha extraído la información 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 77. Caso de lectura del puerto

Figura 78. Caso de escritura del puerto


84

En este caso, la longitud de los datos resultado de la transacción a BD es cero, que quiere

decir que se hizo una escritura y nada más. El Cliente_remoto en este caso, añade un acuse

de recibo ó reconocimiento de que la escritura tuvo éxito.

• Bucle de control


Tiene la función de controlar el programa en definitiva, ya que si el operador necesita finalizar

la ejecución, tendrá que parar la aplicación de alguna forma y si se da la condición, finalice el

programa destruyendo las colas.

11.2.2. CLIENTES FINALES

11.2.2.1. LOCALES A SERVIDOR LOCAL

Una vez descrito el código 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 consumiría mucho tiempo de CPU, con lo que se

ralentizaría en demasía el sistema.

Figura 79. Bucle de control en el puerto


85

11.2.2.1.1. GENERACIÓN DE HISTÓRICOS

Este cliente se ha desarrollado con la idea de generar históricos de determinadas variables. En

concreto, el operador podrá configurar el módulo para tomar muestras cada cierto período de

tiempo. Hay dos formas de generar históricos:

1. Generación de históricos usando un fichero de texto.

Es una forma bastante eficiente, ya que en cada transacción se abre un fichero de texto, se

añade las muestras correspondientes a ese instante de tiempo y se cierra. Por tanto, la

información no se almacena constantemente en RAM, sino que se hace un acceso a disco

duro, para abrir, adjuntar y cerrar la información. Esta generación se muestra en la figura 80.

Al tratarse de ficheros de texto (.txt), apenas consume memoria RAM en la acción de añadir

información al fichero, por lo que el sistema no se ve afectado.

En esta primera pantalla, a partir de la configuración 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 presentación de la información no es tan

elegante, así que lo que se gana en eficiencia se pierde en presentación.

Figura 80. Generación de históricos usando un fichero de texto


86

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.

Simplemente consiste en un bucle en donde se toman las muestras y se escribe en el fichero

cuya identificación 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 81. Toma de muestras en la generación de históricos usando un fichero de texto

Figura 82. Uso del protocolo de variables no consecutivas en la generación de históricos usando un fichero de texto


87

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. Generación de históricos usando Microsoft Excel

Como ya se ha comentado, al usar esta aplicación se tiene la ventaja de tener capacidad de

representación de la información. A cambio, según 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 añadir las muestras nuevas. Si el período de

tiempo entre muestras es pequeño, 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 opción de generación ya que lo normal es

configurar un tiempo_muestreo grande (minutos). Esto significa que el número de muestras en

total que se pueden obtener en un día componen un fichero de tamaño asequible. Se ha

diseñado este módulo, para que se cierre el fichero cada día y se abra uno nuevo con el

formato que ya se ha comentado anteriormente: aammdd.xls, es decir, año, mes y día.

Cuando se arranca el programa por primera vez, se comprueba que no existe un fichero con

ese nombre, si es así, se añaden las muestras nuevas al principio. De esta forma, la

interferencia que se puede provocar ante una caída del sistema es mínima, ya que con sólo

arrancar de nuevo la aplicación se va añadiendo la información al fichero de históricos

existente. Dentro de la inmensidad del bucle que tiene el control del módulo 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 generación de históricos con ficheros de

texto (TXT) y se muestra en la figura 83.


88

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 botón de parada.

� Porque se pase de un día 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 número de muestras (en este caso, se ha configurado a tres) el

programa se sale del bucle y guarda la información a disco duro. Después vuelve a

entrar al mismo. De esta forma tendremos redundancia en el sistema ante una posible

caída del sistema, ya que de otra forma, es posible que se perdiera el histórico de todo

un día, ya que el fichero, durante la ejecución del bucle, siempre está abierto y la

información se va almacenando en memoria principal. Se guarda esta información en el

medio externo cuando se sale del bucle y comienza un nuevo ciclo de muestreo.

Figura 83. Uso del protocolo de variables no consecutivas en la generación de históricos usando Ms Excel


89

Se podría estudiar con algo más de detalle la condición de cambio de día. Para ello se ha

diseñado una rutina que da la condición verdadero o falso, como se muestra en la figura 85.

Esta subrutina solicita la fecha actual, la compara con el valor antiguo y actualiza la variable de

salida Medianoche?

Figura 84. Condiciones que se memorizan en la entrada del bucle

Figura 85. Subrutina de cambio de día


90

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 línea, es posible la definición de usuarios con su contraseña asociada.

Básicamente este cliente consiste en dos módulos:

Root.vi, que tiene la función de poder añadir nuevos usuarios y contraseñas al sistema. Para

ello dispone de un fichero en el que se guarda la información encriptada.

Login.vi, que está a la vista del operador y realiza las funciones de autenticación. 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 posición en BD para tales menesteres.

Cuando el operador se autentifique se actualiza esta posición (posición cero en BD). De esta

forma, cada vez que se desee generar una consigna de control, el sistema en primer lugar lee

la posición de memoria y si el resultado es satisfactorio, realiza la operación, en otro caso,

muestra un mensaje advirtiendo al operador que es necesario que se identifique para poder

desarrollar la acción.

Se detallan estos módulos:

• Root.vi

En la figura 86 se muestra la pantalla principal, donde se observa al operador con privilegios

especiales, es decir, de alguna forma sólo estará disponible este módulo en un directorio

reservado a un determinado perfil de usuario.

Como se ha implementado la aplicación en Windows Server 2008, desarrollar esta posibilidad

es aparentemente sencillo, ya que sólo se necesita reservar un directorio para este tipo de

módulos y al que sólo tenga acceso usuarios con un determinado perfil. Para ello, se solicitará

usuario y contraseña cada vez que se acceda a él. En LabView se ha diseñado este módulo



91

En esta pantalla principal se dan de alta nuevos usuarios. Como medida de seguridad el

usuario deberá repetir la contraseña para que tenga éxito la acción.

Figura 86. Pantalla principal de módulo ROOT.VI

Figura 87. Diseño del módulo ROOT.VI en LabView


92

El módulo consiste básicamente en un bucle que permanece a la espera hasta que el usuario

introduce un nuevo alta. Si tiene éxito, finaliza la ejecución. 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 sólo tiene que introducir login y password, el sistema le validará si

ha sido dado de alta con el módulo anterior y también recoge la posibilidad de bloquear el

sistema.

Esto se podría 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 contraseña

cuando se introduzca una nueva consigna de control. Esta opción queda recogida con el botón

“Bloquear” que aparece en la figura. La descripción del código se recoge en el siguiente

subprograma de la figura 89.


93

En esta primera opción, si el operador desea bloquear el sistema se rellena con un cero la

posición cero de la Base de Datos. En otro caso, tiene lugar la autenticación del usuario y si

tiene éxito, se rellena con un uno la posición cero de la BD.

Se entra en una u otra opción según el valor que tenga la variable lógica Bloquear. Esta

variable, por defecto, tiene un valor, para que inicialmente el usuario tenga que validarse para

poder acceder al sistema. Se muestra el código en la figura 90.

Figura 89. Descripción del código del subprograma LOGIN.VI


94

• Comprobación de la existencia de usuario validado

Una vez descrito el procedimiento para validarse, sólo queda comentar cómo comprueba el

sistema que existe en todo momento un usuario validado. Para esto, existe un módulo que

tiene la función de generar consignas. Dada su importancia sobre el funcionamiento del

sistema, a modo de prueba, se le ha asociado la comprobación de autenticación.

Esto quiere decir, que a petición del cliente, es posible construir un software completamente a

medida y asociar a un módulo en concreto un nivel de seguridad. En concreto, el módulo se

describe en la figura 91.

Figura 90. Descripción del código del bloqueo del sistema

Figura 91. Módulo que comprueba la autenticación


95

Como se puede observar, esta es la pantalla principal del técnico, 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 página 92.

Por tanto, cada vez que se quiera mover un grupo de heliostatos, por ejemplo, el módulo 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 código del módulo, ó al menos, de la parte que se está describiendo ahora

(comprobación de la existencia de usuario validado). El código se describe en la figura 93.

Figura 92. Mensaje de no validación


96

En esta parte del código de programa existe una rutina que es la que da la condición de acceso

a la ejecución de la consigna de control (Exec). Esta rutina se describe en la figura 94.

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 posición cero y se comprueba si es igual a uno. Si es así, entonces el usuario

Figura 93. Descripción del código del mensaje de no validación

Figura 94. Descripción de la rutina que da la condición de acceso a la ejecución de la consigna de control


97

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 algún ejemplo de clientes remotos que acceden a Servidor Local.

En concreto, se estudiará el cliente Control Campo, por ser el más completo ya que hace uso

de la mayoría de los protocolos introducidos en la descripción del sistema.

11.2.2.2.1. CONTROL CAMPO

Este módulo es uno de los más 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 posición de cada uno debe actualizarse tan rápido como sea posible ya

que el sol está en permanente movimiento. Como requisitos del diseño, se tiene que cada

heliostato se debe actualizar cada medio minuto como máximo.

Este módulo cumple con estas exigencias, ya que consigue comunicarse con cada uno durante

la fase de experimentación en 15 segundos aproximadamente. Aunque el sistema trabaje en

vacío, para el funcionamiento interno no afecta. Esto es debido a que cada uno se espera un

tiempo de espera de rigor, pasado el cuál 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 descripción

de la rutina se muestra en la figura 95.

Figura 95. Descripción del módulo CONTROL CAMPO


98

Como se puede observar, el módulo 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

transacción 500 posiciones que van desde la posición 6000 a la posición 6499. Estas

posiciones se han reservado para un uso futuro en el que se podrán programar determinadas

MACROS en las que el operador podrá guardar determinadas acciones que serán 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 más.

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 acción alguna ó no esté en uso, se actualiza a cero. De esta forma, en el vector se

tiene únicamente aquellas macros que están activas. La descripción del código se muestra en

la figura 96.

Figura 96. Descripción del código del vector de macros activas


99

En la continuación del código, se observa que no se ha programado aún, como ya he

comentado anteriormente, ninguna macro (el tamaño del vector con las macros activas será

siempre cero, al menos durante la fase de experimentación).

Si el tamaño de vector es cero, entonces el siguiente paso sería leer la orden particular para

cada uno de los heliostatos. Para estas posiciones se ha reservado en BD una zona, que van

de la posición 5000 a la posición 5999, como se muestra en la figura 97.

Con los valores leídos, 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 cálculo de la posición

de cada heliostato (Calc Coord). Este módulo se proporciona la posición del sol ó en su defecto

la posición de cada uno de los heliostatos.

Como requisito inicial del trabajo de investigación, este módulo deberá ser proporcionado, es

decir, no será objetivo de esta tarea calcular los datos necesarios para obtener la posición de

cada elemento que constituye el campo. Pero aún así, y anticipándonos a este hecho, se tiene

en cuenta este detalle y se reserva un módulo que, en principio, simula la función asignada.

Únicamente, este módulo hace una transacción de lectura de BD y lee los dos grados de

libertad (acimut y elevación) de cada elemento, que van de la posición 2000 a la posición 3999.

Con esta información se crea dos vectores que pasa al módulo general como parámetros de

salida del sistema.

Figura 97. Descripción del código de lectura de orden para cada uno de los heliostatos


100

La descripción de este módulo se detalla en la figura 98.

Con la orden a cada heliostato, así como con la posición que cada uno debe tener, se entra en

una estructura FOR en donde tiene lugar la comunicación individual con cada elemento. Esta

estructura es la que consume más tiempo en el bucle porque es la que se encarga de

establecer la conexión 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 cuestión, 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 rápidamente si un

determinado elemento se avería. Por tanto, éste está constantemente informando de su

estado.

Una vez que la ejecución 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 módulo Calcula_coord, se utilizan para formar un

vector con el que se actualiza la BD. Esto se hace desde la posición 2000 hasta la posición

4999. Es decir, sobrescribimos la posición 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.

Figura 98. Descripción del módulo que obtiene la posición de cada elemento que constituye el campo


101

12. CONCLUSIÓN

En este apartado nos centraremos en la contribución que supone el nuevo impulso de

iniciativas como este trabajo que dan a conocer la temática relacionada con este importante

campo de la Tecnología de Información y Comunicación en las Energías Renovables, en

concreto, en la energía solar.

Esta aportación innovadora permite la aproximación a los retos de futuro y muestra la

posibilidad de actuación 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 Información que

planifica una planta solar de concentración mediante un sistema SCADA. Entre las

conclusiones más importantes que ofrece esta investigación, se encuentra la versatilidad que

proporciona en la implantación de un proyecto distribuido de monitorización, supervisión y

adquisición eficiente de datos de una planta solar de concentración.

Además, 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 implementación y desarrollo del hardware necesario para la finalización del proyecto se deja

como posibles líneas de investigación ó futuras tesis.


102

13. BIBLIOGRAFÍA

REFERENCIA LEGAL

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.

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

REFERENCIA BIBLIOGRÁFICA

RODRÍGUEZ PENIN, A. Sistemas Scada. 2º edición. 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.

LÁZARO, A.M. LabVIEW: Programación gráfica para control de instrumentación. Ed. Paraninfo,

2005

LAJARA, J.R. y PELEGRÍ, J. LabVIEW: Entorno gráfico de programación. Ed. Marcombo, S.A.,

2007.

Documents

METODOLOG A DE IMPLANTACI N DE SCADA EN LA … · en general sistema SCADA y debe estar en disposición de ofrecer las siguientes prestaciones: Posibilidad de crear paneles de alarma,