Post on 09-Jul-2018
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
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
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
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
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
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
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.
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
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%
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
.
.
.
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
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
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
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
F C lect Index Tam Relleno
ID
ID
ID ID ID ID
Lista valores
ID
ID
F C lect Index Tam Relleno
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
31
Mensaje de petición
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
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
32
Mensaje de petición
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
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
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
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
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
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
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
muestra en la figura 23.
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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.
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
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
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
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
F C lect Relleno Index Tam
4 4 1 4 5 5
ID
F C lect Relleno Index Tam
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
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
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
F C esc Relleno Index Tam
4 4 1 4 5 5
ID
Relleno
Long = 0
ID
4
ID
Datos_escritura
<variable>
14
Long_Datos Datos_escritura
4 <variable>
ID
F C esc Relleno Index Tam
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Se muestra en la figura 38 esta pantalla.
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
muestra en la figura 39.
Figura 38. Diagrama de bloques del módulo ATENDER COLA
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
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
Se muestra en la figura 40 esta pantalla.
Figura 39. Inserción de un elemento en la cola de salida
Figura 40. Panel frontal del módulo GESTIONA UNO
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
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
Se muestra en la figura 41 esta pantalla.
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
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
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
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
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
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
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
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
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
muestra en la figura 46.
Figura 45. Caso de lectura en el protocolo uno a uno
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
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
Se muestra en la figura 47 esta pantalla.
Figura 46. Caso de escritura en el protocolo uno a uno
Figura 47. Panel frontal del módulo TRANSFORMA STRING
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
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
Se muestra en la figura 48 esta pantalla.
Figura 48. Diagrama de bloques del módulo TRANSFORMA STRING
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
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
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
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,
como se muestra en la figura 51.
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
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
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
Se muestra en la figura 52 esta pantalla.
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
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
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
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
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,
como se muestra en la figura 55.
Figura 54. Creación de colas por parte del servidor
Figura 55. Mantenimiento a la espera mientras el servidor atiende la petición
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
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
muestra en la figura 56.
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
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
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
Se muestra en la figura 57 esta pantalla.
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
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
68
2. BLOCK DIAGRAM
Se muestra en la figura 58 esta pantalla.
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
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
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
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
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
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
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
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
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
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
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
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
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
F C lect Index Tam Relleno
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 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
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
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
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
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
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
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
muestra en la figura 70.
Figura 69. Caso de escritura de N elementos
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
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
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
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
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
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
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
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
Se muestra en la figura 75.
Figura 74. Bucle de escritura en el puerto
Figura 75. Bucle de lectura del puerto
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
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
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
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
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
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
Se muestra en la figura 79.
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
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
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
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
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
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
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.
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
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
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
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
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
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
como se muestra en la figura 87.
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.