desarrollo de un sistema informÁtico de monitorizaciÓn de

ESCUELA SUPERIOR DE INGENIERÍA INFORMÁTICA

INGENIERÍA INFORMÁTICA

Curso Académico 2008/2009

Proyecto Fin de Carrera

DESARROLLO DE UN

SISTEMA INFORMÁTICO

DE MONITORIZACIÓN DE

PLANTAS SOLARES FOTOVOLTAICAS

� Autor �

Javier Vergara Igual

� Tutores �

Juan José Pantrigo Fernández

Jesús Vergara Igual

Febrero, 2009

Dedicado a mi sobrino Jesús y a mi abuelo Ignacio

Agradecimientos

Desde muy pequeño mi vocación, como la de muchos niños más, fue ser futbolista.Con el paso del tiempo, in�uenciado por el boom de los dinosaurios y la película �ParqueJurásico�, quería ser arqueólogo. Siempre me fascinó la historia. Sin embargo, cuandoalcancé la edad de 15 años no tenía nada claro que carrera iba a estudiar, a pesar deestar interesado en veterinaria. Poner en mis manos la vida de animales no me llenabaplenamente. En esa época mi hermano comenzó a estudiar Ingeniería Técnica Informáticade Sistemas. Desde joven estuvo muy interesado en la informática. El primer ordenadorque tuvimos fue un Amstrand. Recuerdo que por aquel entonces comenzaba a hacer susprimeros programas. Por el contrario, yo nunca fui seducido por la informática. Veía alordenador como una máquina para jugar, eso era todo. Al cursar mi hermano la carreracomencé cada vez más a interesarme por el mundo informático. Fue la admiración haciami hermano, que desde pequeño consideré un modelo a seguir, lo que hizo decantarmepor el estudio de Ingeniería Informática. No estoy en absoluto arrepentido de mi elección.A día de hoy me entusiasma poder desempeñar el trabajo para el que he sido formado.Puedo decir que acerté en una de las decisiones importantes de la vida.

Este proyecto no hubiera sido posible sin la ayuda de mis tutores, Juan José PantrigoFernández y Jesús Vergara Igual, mi hermano. A Juanjo le quiero agradecer la con�anzaque ha depositado en mí para llevar a cabo la realización del proyecto. Fue mi profesor ytutor en el primer año de carrera. Gracias a él empecé a interesarme por la programación.De verás, gracias por ser cercano, atento e implicarte como lo has hecho. A mi hermanoJesús quiero agradecerle su apoyo en todo momento, es un ejemplo a seguir en el terrenopersonal y profesional.

A mis padres, Jesús e Ina, por concederme la oportunidad de estudiar, y por el apoyoincondicional recibido durante todos estos años. Gracias por darme siempre lo mejor ypor educarme como lo habéis hecho.

Gracias a mi cuñada Elena por el cariño que me ofrece y haber traído al mundo a misobrino Jesús. La llegada de mi sobrino, su presencia, su compañía...es lo mejor que meha pasado en la vida.

A mis tíos, primos y abuelos.

Gracias a mis amigos de toda la vida, aquellos con los que, a pesar del paso deltiempo, siempre se puede contar: Blasco, Moreno, Alberto, Adri, Raúl, Natalia, Dani,Conde, Camacho, Álvaro, Sergio, Luis y Nabil. Gracias de verdad.

A todos mis amigos y compañeros de Facultad por haberme obsequiado con su amistaddurante todos estos años de carrera, sin la cual el paso por la Universidad no hubiera sido

i

ii Agradecimientos

lo mismo. Me llevo grandes amigos. Gracias a Jorge, Nico, Jose, Jesús, Heras, Antonio,Dani, y en especial a Edmundo. Espero que nuestra amistad nunca se pierda.

Y en especial quiero agradecerle a mi abuelo Ignacio su compañía, sus enseñanzas y elapoyo que siempre me dio. A pesar de no estar ya entre nosotros siempre le llevo conmigo.

En de�nitiva, muchas gracias a todos los que con�aron en mí en todo momento.

Resumen

Este proyecto presenta como objetivo principal monitorizar una planta solarfotovoltaica mediante el uso de un sistema informático. Monitorizar [1] signi�ca:�Observar mediante aparatos especiales el curso de uno o varios parámetros �siológicoso de otra naturaleza para detectar posibles anomalías�. El proceso de observación selleva a cabo a través de un ordenador, que mediante software especí�co debe extraer,tratar y analizar la información que recogen los dispositivos conectados a los panelessolares, conocidos como inversores, cuya funcionalidad básica consiste en transformarcorriente continua en alterna. Los inversores solares fotovoltaicos registran la actividadsolar del parque: radiación, energía acumulada, potencia instantánea de la radiación yotras múltiples mediciones. La interacción entre el ordenador y los inversores no se producede forma directa. Los controladores lógicos programables (del inglés Programmable LogicController, en sus siglas PLC ) son los componentes que actúan de intermediarios en lacomunicación. Un conjunto de inversores, también denominado como �red de inversores�,se conecta directamente a un PLC. Los PLC a su vez, se conectan en red con el PC. De lainteracción entre el ordenador y el controlador lógico programable, y de este último conlos inversores, se recogen los datos necesarios. La observación de la información obtenidase llevará �nalmente a cabo mediante una página web, SMS, correos electrónicos, etcétera.La detección de posibles anomalías es el objetivo �nal del proceso de monitorización, yaque su idea fundamental es ofrecer una forma de supervisar la producción de la planta ydetectar fallos en los componentes.

El proyecto es el resultado del trabajo realizado para una empresa rela-cionada con el ámbito de la energía solar, y más concretamente, dedicada a lainstalación de plantas solares fotovoltaicas en la geografía española. La empresa solicitóla monitorización de uno de sus parques solares para poder así controlar la producciónasociada: facilitar la recopilación de datos de los inversores, supervisar la información paradetectar fallos y anomalías, alertando de su existencia, e informar a sus clientes de losbene�cios de las instalaciones que tengan contratadas.

Para construir el sistema se ha llevado a cabo un amplio proceso de investi-gación, basado en comprender la estructura, actividad y funcionamiento de una plantasolar fotovoltaica. Una vez comprendido el área en el que se iba a desenvolver el sis-tema, se llevó a cabo el desarrollo del mismo. El proyecto se puede dividir en dosgrandes partes, cada una de las cuales se corresponde con la creación de unaaplicación diferente: la primera tiene como objetivo extraer la información del parque,tratarla y analizarla, detectando fallos y anomalías, alertando vía SMS o e-mail a los ad-ministradores del sistema, técnicos de la planta, etcétera. La segunda pretende dar accesovía Internet a los datos recogidos mediante la creación de una página web destinada a talpropósito. El proceso de desarrollo se ha basado en la entrega de prototipos,

iii

iv Resumen

es decir, �mini-sistemas� con su�ciente funcionalidad como para ser probados y exam-inados por la empresa. Actualmente el sistema está en funcionamiento, habiendoconseguido cumplir los objetivos marcados.

El sistema en su totalidad supone una gran innovación a nivel comercial,ya que actualmente no existe ningún sistema de monitorización tan especí�co orientadoal cliente.

Índice general

Agradecimientos i

Resumen iii

1. Introducción 1

1.1. Monitorizar: de�nición y adecuación al sistema . . . . . . . . . . . . . . . . 2

1.2. Energía solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Energía solar fotovoltaica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.2. Principio de funcionamiento . . . . . . . . . . . . . . . . . . . . . . 5

1.3.3. Tipos de sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.4. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.5. Datos económicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.6. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4. Planta solar fotovoltaica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5. Controlador lógico programable (PLC) . . . . . . . . . . . . . . . . . . . . 9

2. Objetivos 11

2.1. Objetivo principal. Finalidad del proyecto . . . . . . . . . . . . . . . . . . 11

2.2. Objetivos operativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Objetivos personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Descripción informática 15

v

vi ÍNDICE GENERAL

3.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1. Modelo de desarrollo en espiral . . . . . . . . . . . . . . . . . . . . 16

3.1.1.1. Aplicación al proyecto . . . . . . . . . . . . . . . . . . . . 16

3.1.2. Modelo de desarrollo evolutivo . . . . . . . . . . . . . . . . . . . . . 18

3.1.2.1. Aplicación al proyecto . . . . . . . . . . . . . . . . . . . . 18

3.1.2.2. Prototipos desarrollados en el proyecto . . . . . . . . . . . 19

3.2. Propuesta. Visión global del sistema . . . . . . . . . . . . . . . . . . . . . . 20

3.3. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4. Prototipo 1: Extracción, tratamiento y análisis de la información de cadainversor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.1. Especi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5. Prototipo 2: Estructura básica de la aplicación web . . . . . . . . . . . . . 37

3.5.1. Especi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.5.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.5.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6. Prototipo 3: Almacenamiento persistente y exportación de información.Presentación de datos en página web . . . . . . . . . . . . . . . . . . . . . 48

3.6.1. Especi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.6.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.6.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.6.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.7. Prototipo 4: Creación y exportación de informes diarios. Presentación enpágina web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.7.1. Especi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.7.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.7.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.7.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

ÍNDICE GENERAL vii

3.8. Prototipo 5: Generación de grá�cas . . . . . . . . . . . . . . . . . . . . . . 56

3.8.1. Especi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.8.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.8.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.8.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.9. Prototipo 6: Creación del sistema de alertas . . . . . . . . . . . . . . . . . 58

3.9.1. Especi�cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.9.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.9.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.9.4. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.10. Puesta en marcha real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.11. Herramientas y tecnologías informáticas utilizadas . . . . . . . . . . . . . . 67

3.11.1. SYSMAC CX-ONE y CX-Programmer . . . . . . . . . . . . . . . . 67

3.11.2. Microsoft .NET y Microsoft .NET Framework . . . . . . . . . . . . 68

3.11.3. Mono Project y MonoDevelop . . . . . . . . . . . . . . . . . . . . . 70

3.11.4. C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.11.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.11.6. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.11.7. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.11.8. CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.11.9. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.11.10.AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.11.11.CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.11.12.FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.11.13.MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4. Aportaciones, conclusiones y trabajos futuros 75

4.1. Aportaciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2. Conclusiones �nales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.3. Di�cultades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

viii ÍNDICE GENERAL

4.4. Lecciones aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.5. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A. Acondicionamiento del entorno del sistema 83

A.1. Con�guración de PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.2. Con�guración del servidor del parque solar . . . . . . . . . . . . . . . . . . 83

A.3. Con�guración del servidor externo . . . . . . . . . . . . . . . . . . . . . . . 84

B. Distribución del código 87

B.1. Distribución del código en el parque solar . . . . . . . . . . . . . . . . . . . 87

B.2. Distribución del código en el servidor externo . . . . . . . . . . . . . . . . 90

C. Contenido del CD-ROM y licencia de uso 93

C.1. Licencia del documento y del código fuente del proyecto . . . . . . . . . . . 93

C.2. Contenido del CD-ROM incluido en este documento . . . . . . . . . . . . . 94

Bibliografía 96

Índice de �guras

1.1. Panel solar fotovoltaico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Seguidor solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Inversor solar fotovoltaico . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Planta solar fotovoltaica en La Herrera (Albacete) . . . . . . . . . . . . . . 8

1.5. Componentes de una planta solar fotovoltaica . . . . . . . . . . . . . . . . 8

1.6. Controlador lógico programable (PLC) . . . . . . . . . . . . . . . . . . . . 10

3.1. Modelo de desarrollo en espiral . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Modelo de desarrollo evolutivo . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3. Modelo de desarrollo en espiral + Modelo de desarrollo evolutivo . . . . . . 20

3.4. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5. Trama de solicitud (Command Frame) . . . . . . . . . . . . . . . . . . . . 26

3.6. Trama de respuesta (Response Frame) . . . . . . . . . . . . . . . . . . . . 26

3.7. Con�guración del parámetro ICF . . . . . . . . . . . . . . . . . . . . . . . 27

3.8. Ejemplo de solicitud de lectura del área de memoria de los PLC . . . . . . 28

3.9. Ejemplo de respuesta ante la lectura del área de memoria de los PLC . . . 28

3.10. Paquete communication_protocol . . . . . . . . . . . . . . . . . . . . . . . 32

3.11. Paquete infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.12. Paquete con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.13. Paquete action_register . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.14. Casos de uso-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.15. Paquete services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.16. Tablas de la Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

ix

x ÍNDICE DE FIGURAS

3.17. Casos de uso-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.18. Paquete contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.19. Diagrama de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.20. Diagrama de despliegue del sistema . . . . . . . . . . . . . . . . . . . . . . 67

3.21. Conjunto de PLC con�guradas . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.22. Arquitectura de Microsoft .NET Framework . . . . . . . . . . . . . . . . . 69

3.23. Arquitectura del Entorno Común de Ejecución para Lenguajes (CLR) . . . 69

3.24. Arquitectura de Mono Project . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.25. Captura de MonoDevelop . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Capítulo 1

Introducción

En la actualidad, la búsqueda de nuevas formas de obtención de energía debido alagotamiento de las fuentes de energía tradicionales, y la concienciación de la sociedad,cada vez más involucrada en preservar el bienestar del planeta, han desembocado en laexplotación poco signi�cativa, pero sí creciente, de las energías renovables y limpias.

Entre todas ellas cabe destacar a la energía solar fotovoltaica, ya que apenas produceimpacto ambiental, al contrario que algunas otras, y gracias a la fuente de energía de la quese abastece, el sol, siendo a efectos prácticos inagotable. Por todo ello, y la rentabilidadque generan a largo plazo, la aparición de complejos solares fotovoltaicos es cada vezmás notoria. Su mecanismo se basa en recoger la energía solar a través de una serie dedispositivos de carácter fotovoltaico, y generar a partir de ellos energía eléctrica.

La �nalidad principal de este proyecto es monitorizar un complejo solar fotovoltaico,más concretamente una planta solar fotovoltaica, haciendo uso de un sistema informático.Para poder comprender el objetivo y desarrollo del proyecto es necesario realizar, enprimer lugar, una descripción del medio en el que se desenvolverá el sistema. El sistemaestá diseñado para funcionar en un entorno real. Actualmente lo está haciendo en unparque solar situado en La Herrera, municipio de la provincia de Albacete, siendo posibletener acceso a él a través de Internet. La razón por la cual el sistema desarrollado estáactualmente implantado se debe a su índole real, siendo su elaboración petición expresade una empresa. La empresa está directamente relacionada con el sector de la energíasolar fotovoltaica, centrando en gran medida sus esfuerzos en la instalación de parquessolares. El sistema está, por lo tanto, hecho a la medida de los requisitos expuestos por elcliente.

Para llevar a cabo el proyecto que recogen estás páginas ha sido necesario un largoproceso de investigación, ya que el área en el que se desenvuelve el sistema es ajena alos conocimientos que un estudiante de Ingeniería Informática puede tener. En primerainstancia, los esfuerzos se centraron en comprender la �losofía de trabajo de la empresay en analizar el sector de actividad de la misma, la energía solar fotovoltaica, realizandoun estudio minucioso del entorno en el que se iba a desenvolver el sistema, el parquesolar. Posteriormente se estudiaron en detalle los requisitos de la empresa. Acto seguidose comenzó a per�lar el sistema para conseguir un producto acorde con las necesidadesdel cliente. Es en este punto donde se llevó a cabo el estudio de las diferentes alternativasinformáticas que ofrecían los dispositivos con los que debía interaccionar el sistema, te-

1

2 Capítulo 1. Introducción

niendo siempre presente los requisitos del cliente, pudiendo ofrecer así la solución idóneapara conseguir �nalmente monitorizar la planta solar fotovoltaica.

1.1. Monitorizar: de�nición y adecuación al sistema

Es de importancia conocer el signi�cado de la palabra monitorizar y la implicación quetiene en el sistema desarrollado. Según la Real Academia Española (R.A.E.) [1] monitor-izar signi�ca: �Observar mediante aparatos especiales el curso de uno o varios parámetros�siológicos o de otra naturaleza para detectar posibles anomalías�.

Teniendo en cuenta la índole del proyecto podemos puntualizar la de�nición anterior-mente expuesta. En el fragmento de la de�nición �observar mediante aparatos especiales�,hay que destacar que tales aparatos son los ordenadores, controladores lógicos program-ables (PLC) e inversores. En la fracción �el curso de uno o varios parámetros �siológicos�,debemos hacer mención de los inversores. Los inversores son dispositivos que registran in-formación acerca de la actividad solar del parque: radiación, voltaje, energía acumulada,impedancia y otros parámetros. Su funcionalidad principal reside en transformar la corri-ente continua, que recogen de los paneles solares fotovoltaicos, en alterna. Asociando losdos fragmentos de la de�nición anteriormente señalados, cabe destacar que la observaciónde la información se produce a través de la interacción de un PC con los inversores, siendoel primero el encargado de, mediante el uso de software especí�co, extraerla, tratarla yanalizarla. Sin embargo, la comunicación no es directa. Participan otros dispositivos, losPLC, actuando de intermediarios. El PC deberá estar conectado en red a los PLC. Deigual forma, estos últimos se conectarán a un conjunto de inversores. El ordenador solici-tará información a los PLC. Los controladores lógicos programables interaccionarán conlos inversores haciendo acopio de los datos necesarios y enviarán, en última instancia, lainformación recogida al PC. La observación de la información recogida se llevará a cabo através de una página web, SMS, correos electrónicos, etcétera. Por último, �detectar posi-bles anomalías� es el objetivo �nal. La idea fundamental de la monitorización es ofreceruna forma de supervisar la producción y detectar fallos en los componentes.

1.2. Energía solar

La energía solar [2] es la producida por el sol y transformada a energía útil por el serhumano. Se trata de una energía alternativa, renovable y limpia.

La potencia de la radiación solar varía, esencialmente, según el momento del día, lascondiciones atmosféricas y la latitud. En condiciones óptimas el valor suele ser superior alos 1000W/m2 en la super�cie terrestre.

La radiación es aprovechable en sus componentes directa y difusa, o en la suma deambas. La radiación directa es aquélla que llega directamente del foco solar, sin re�exioneso refracciones intermedias. La difusa es la emitida por la bóveda celeste diurna graciasa los múltiples fenómenos de re�exión y refracción solar en la atmósfera, en las nubes,y el resto de elementos atmosféricos y terrestres. La radiación directa puede re�ejarse yconcentrarse para su utilización, sin embargo, no es posible concentrar la luz difusa que

1.3. ENERGÍA SOLAR FOTOVOLTAICA 3

proviene de todas direcciones. Según la tecnología de aprovechamiento y utilización, laenergía solar presenta la siguiente clasi�cación:

Energía solar pasiva Aprovecha el calor que desprende el sol sin necesidad de mecan-ismos o sistemas mecánicos.

Energía solar térmica Produce agua caliente de baja temperatura para uso domésticosanitario y calefacción.

Energía solar fotovoltaica Produce electricidad mediante placas de semiconductoresque se excitan al incidir sobre ellas la radiación solar.

Energía solar termoeléctrica Produce electricidad mediante un ciclo termodinámicoconvencional, a partir de un �uido calentado a alta temperatura, el aceite térmico.

Energía solar híbrida Combina la energía solar con la combustión de biomasa, com-bustibles fósiles, energía eólica o cualquier otra energía alternativa.

Energía eólico solar Se abastece de aire calentado por el sol que sube por una chimeneadonde están los generadores de energía.

Otros usos de la energía solar y ejemplos más prácticos de sus aplicaciones, son lossiguientes: parque solar, central térmica solar, portación de agua, cocina solar, desti-lación, evaporación, fotosíntesis, secado, arquitectura sostenible, cubierta solar y acondi-cionamiento y ahorro de energía en edi�caciones (calentamiento de agua, calefaccióndoméstica, iluminación, refrigeración, aire acondicionado, energía para pequeños elec-trodomésticos, etcétera).

1.3. Energía solar fotovoltaica

El proyecto desarrollado está directamente ligado con la energía solar fotovoltaica.Puesto que el conocimiento en este campo no era muy profundo, se realizó un estudio delmismo de cara a facilitar la construcción del sistema.

1.3.1. Conceptos básicos

A continuación, se de�nen una serie de conceptos básicos que son necesarios paraentender la energía solar fotovoltaica y el marco contextual que la rodea:

Energía [3] Es una propiedad de todo cuerpo o sistema material en virtud de la cual éstepuede transformarse, modi�cando su estado o posición, así como actuar sobre otrosoriginando en ellos procesos de transformación. La energía es el motor de múltiplesprocesos que proporcionan al hombre grandes bene�cios.

Célula solar fotovoltaica [4] Dispositivo que se basa en el efecto fotoeléctrico y queconvierte la radiación solar directamente en electricidad. En su forma más simple,se compone de un ánodo y un cátodo recubierto de un material fotosensible. La


Figura 1.1: Panel solar fotovoltaico

Figura 1.2: Seguidor solar

luz que incide sobre el cátodo libera electrones que son atraídos hacia el ánodo, decarga positiva, originando un �ujo de corriente proporcional a la intensidad de laradiación.

Panel solar fotovoltaico [5] Conjunto de celdas fotovoltaicas capaces de producir elec-tricidad usando como fuente la energía solar. Se puede apreciar una imagen en la�gura 1.1.

Seguidor solar [6] Elemento encargado de hacer girar la estructura del panel solar foto-voltaico de tal manera que incida en él la mayor cantidad de radiación solar. Existendos tipos en función del movimiento que realicen: de un eje, giro de Este a Oeste, yde dos ejes, donde además del movimiento mencionado también varía la inclinación.Podemos ver una imagen de este dispositivo en la �gura 1.2.

Inversor solar fotovoltaico [7] Un inversor, también llamado ondulador, es un circuitoutilizado para convertir corriente continua en corriente alterna. La función de uninversor es cambiar un voltaje de entrada de corriente directa a un voltaje simétricode salida de corriente alterna, con la magnitud y frecuencia deseada por el usuarioo el diseñador. Puede verse una foto de un inversor en la �gura 1.3.

Instalación Conjunto de inversores, generalmente formado por 2 ó 3 de estos dispositivos.El parque solar se divide en instalaciones, las cuales se venden a los clientes de laempresa.

Controlador lógico programable (PLC) [8] Dispositivo industrial encargado de lle-var a cabo automatización de tareas.

1.3. ENERGÍA SOLAR FOTOVOLTAICA 5

Figura 1.3: Inversor solar fotovoltaico

Nodo Cada uno de los elementos físicos que forman parte del sistema.

Potencia [9] En Física, potencia es la cantidad de trabajo efectuado por unidad detiempo. Esto es equivalente a la velocidad de cambio de energía en un sistema o altiempo empleado en realizar un trabajo, según queda de�nido por:

P = dE/dt

Donde P es la potencia, E es la energía y t es el tiempo.

Potencia eléctrica [10] La potencia eléctrica se mide en Watts (W) y es el resultadode la multiplicación de la diferencia de potencial en los extremos de una carga y lacorriente que circula por ésta.

Potencia instantánea Es la potencia obtenida en determinado instante de tiempo.

Producción energética Energía procesada a lo largo de un intervalo temporal.

Producción económica Bienes y mercancías obtenidos a lo largo de un intervalo tem-poral.

1.3.2. Principio de funcionamiento

La energía solar fotovoltaica [11] se obtiene tras llevar a cabo la conversión de la energíalumínica proveniente del sol en energía eléctrica. En el proceso de conversión se utilizandispositivos semiconductores tipo diodo, denominados células solares fotovoltaicas, que alrecibir radiación solar se excitan y provocan saltos electrónicos, generando una pequeñadiferencia de potencial en sus extremos. El material más común de uso en la células solareses el silicio. El acoplamiento en serie o paralelo de estos fotodiodos dan lugar a placassolares fotovoltaicas que en conjunción forman paneles solares fotovoltaicos, permitiendola obtención de voltajes mayores. Las placas solares fotovoltaicas se dividen en:

Monocristalinas Se componen de secciones de un único cristal de silicio, reconociblespor su forma circular o hexagonal.

Policristalinas Formadas por pequeñas partículas cristalizadas.

Amorfas Se componen de silicio no cristalizado.

Su efectividad es mayor cuanto mayores son los cristales, pero también su peso, grosory coste. El rendimiento de las primeras puede alcanzar el 20%, mientras que el de lasúltimas puede no llegar al 1%, sin embargo su coste y peso es muy inferior.


1.3.3. Tipos de sistemas

Esencialmente existen dos tipos de sistemas para hacer una instalación de un circuitode energía solar fotovoltaica: paneles estáticos y dinámicos (con seguimiento solar).

Panel solar fotovoltaico estático De uso en cubiertas de naves, o�cinas, viviendas,etc. Consta de placas con una orientación e inclinación estática. El rendimientodepende exclusivamente de una orientación óptima de los módulos y de la radiaciónsolar que recibe la localización en la que se instale. La instalación se puede realizaren todo tipo de tejados. Su ventaja principal es que son más económicos y se puedenintegrar totalmente en cubiertas de edi�cios o casas.

Panel solar fotovoltaico dinámico De uso en suelo urbano o terrenos rústicos. El ob-jetivo es orientar la posición de las placas hacia el sol para conseguir la máximaexposición. Estos seguidores pueden ser de un eje (movimiento de Este a Oeste) ode dos ejes (además de los anteriores, también pueden variar la inclinación). Conestos sistemas se consigue que los paneles fotovoltaicos tengan la máxima captaciónde energía durante todo el día y estaciones.

1.3.4. Aplicaciones

Las instalaciones fotovoltaicas, anteriormente mencionadas, se pueden clasi�car en dosgrandes grupos en función de su aplicación [12]: instalaciones aisladas de la red eléctricae instalaciones conectadas a la red eléctrica.

Instalaciones aisladas de la red eléctrica La energía generada se utiliza para cubrirpequeños consumos eléctricos en el mismo lugar donde se produce la demanda. Es elcaso de aplicaciones como la electri�cación de: viviendas alejadas de la red eléctricaconvencional, servicios y alumbrado público, aplicaciones agrícolas y de ganado, yseñalización y comunicaciones.

Instalaciones conectadas a la red eléctrica Podemos encontrarnos ante dos casos:centrales fotovoltaicas, en las que la energía eléctrica generada se entrega directa-mente a la red eléctrica, como en otra central convencional de generación eléctrica,y sistemas fotovoltaicos en edi�cios o industrias, conectados a la red eléctrica, enlos que una parte de la energía generada se invierte en el mismo autoconsumo deledi�cio, mientras que la energía excedente se entrega a la red eléctrica. Tambiénes posible entregar toda la energía a la red. El usuario recibirá entonces la energíaeléctrica de la red, de la misma manera que cualquier otro abonado al suministro.

1.3.5. Datos económicos

El principal problema que acarrea el uso de los paneles solares fotovoltaicos [13], paraobtener energía solar fotovoltaica, es el coste de la inversión necesaria. Se requieren másde diez años, de una vida útil de cuarenta años o más, para recuperar la inversión inicialy generar ganancias. El precio actual de los módulos fotovoltaicos oscila entre los 3e/W

1.4. PLANTA SOLAR FOTOVOLTAICA 7

y los 4e/W, en función de la cantidad que se compre y la procedencia. Los paneles másbaratos provienen de China y se debe ser muy prudente con la calidad y garantías de losmismos. El precio de 7e/W, aunque algo barato, es el precio completo de una instalación�ja: módulos, estructuras de soporte, onduladores, protecciones, sistemas de medición,costos del proyecto, instalación y permisos administrativos. Un precio normal está entre7e/W y 8e/W. Si la instalación es con seguidores de sol de dos ejes, el costo puede rondarlos 9e/W, aunque la producción eléctrica obtenida es del orden de un 30% superior queen una estática.

1.3.6. Estado del arte

El crecimiento actual de las instalaciones solares fotovoltaicas [13] queda limitado engran medida por la falta de materia prima en el mercado solar, más concretamente siliciode calidad solar, al estar copadas las fuentes actuales.

Actualmente, el acceso a la red eléctrica, por ejemplo en España, requiere una serie depermisos de la administración y la autorización de la compañía eléctrica distribuidora dela zona. Esta tiene la obligación de dar conexión a la red eléctrica, pero en la práctica elpapeleo y la reticencia de las compañías eléctricas está frenando el impulso de las energíasrenovables, el cual podría ser más rápido sin duda alguna.

Las compañías eléctricas buscan motivos técnicos, como la saturación de la red, paracontrolar sus intereses en otras fuentes energéticas, y con la intención de bloquear lainiciativa de los pequeños productores de energía solar fotovoltaica. Esta situación provocauna grave contradicción entre los objetivos de la Unión Europea para impulsar las energíasverdes.

A pesar de que en España la escasa liberalización del sector energético impide eldespegue y la libre competitividad de las energía renovables, el futuro parece esperanzador,puesto que a pesar de las diferentes trabas existentes, el sector se encuentra en expansión.

1.4. Planta solar fotovoltaica

Una planta solar fotovoltaica, parque solar, huerta solar o campo solar, es un recintoo espacio en el que pequeñas instalaciones fotovoltaicas de diferentes titulares comparteninfraestructuras y servicios. Se puede apreciar la imagen de la planta solar fotovoltaicacon la que se ha trabajado en este proyecto en la �gura 1.4.

1.4.1. Componentes

Los elementos principales del parque solar monitorizado son: paneles fotovoltaicos,seguidores, inversores y controladores lógicos programables (PLC). Cabe destacar tambiénel contador de la empresa eléctrica, el cual registra la energía producida, pero que no seráelemento de nuestra incumbencia.

Los componentes anteriormente mencionados se estructuran de la siguiente forma: un


Figura 1.4: Planta solar fotovoltaica en La Herrera (Albacete)

Figura 1.5: Componentes de una planta solar fotovoltaica

panel solar fotovoltaico está conectado en primer lugar a un seguidor, para poder asírecibir la mayor cantidad de radiación solar. En segundo lugar, el panel se conecta con elinversor, el cual registra toda la información relativa a la producción del panel en cuestióny transforma la corriente continua en alterna. Por último, para recoger la información quealberga el inversor, estos deben estar conectados a unos dispositivos, en nuestro casoelementos lógicos programables, los PLC. A través de un PLC, conectándolo previamentea un conjunto de inversores y un PC, se puede obtener la información que registra cadainversor: potencia instantánea, número de caídas, estado, energía cumulada, etcétera.El PLC es el elemento básico en el proyecto que recogen estás páginas, como veremosposteriormente. Por último, los inversores están conectados entre sí para, �nalmente,conectarse también a los contadores. En la �gura 1.5 se puede apreciar una imagen realde los componentes mencionadas en esta sección.

1.4.2. Estado del arte

Como cálculo aproximado [13], cabe mencionar que con una hectárea de parque solar(incluidos paneles, centros de transformación, inversores, caminos de acceso, vallado...) sepuede suministrar la energía que consumen 100 familias.

Para una instalación de 100 kW, la producción económica puede variar entre 72.000 y86.000 euros, dependiendo de la radiación solar. La inversión se puede auto�nanciar conlos propios ingresos, entre 12 y 17 años dependiendo de la carga �nanciera. Otra ventaja

1.5. CONTROLADOR LÓGICO PROGRAMABLE (PLC) 9

es la devolución integral del IVA de la instalación, lo que es aplicable tanto a las personasfísicas como a las sociedades, a lo que se suma la desgravación �scal del 10% por inversiónen medio ambiente.

Las empresas promotoras suelen incluir la gestión de �nanciación, así como la tramitaciónadministrativa y el mantenimiento integral de las Centrales, ofreciendo al propietario laposibilidad de controlar desde Internet la producción anual, mensual o diaria.

La actual economía, dominada por un reducido grupo de grandes productores de en-ergía, se está transformando hacia la libertad de producción energética, gracias al derechode acceso a la red eléctrica por cualquier persona, siempre que se cumplan los niveles deseguridad requeridos.

1.5. Controlador lógico programable (PLC)

Un controlador lógico programable [8] (del inglés Programmable Logic Controller ensus siglas PLC ) es un dispositivo electrónico muy usado en Automatización Industrial.Hoy en día, los PLC no sólo controlan la lógica de funcionamiento de máquinas, plantas yprocesos industriales, sino que también pueden realizar operaciones aritméticas, manejarseñales analógicas para realizar estrategias de control, etcétera, entre las funciones másdestacables, así como otras operaciones que conforman un amplio abanico de control. LosPLC actuales pueden comunicarse con otros controladores y computadoras en redes deárea local, y son una parte fundamental de los modernos sistemas de control distribuido.

Los PLC pueden intercambiar datos con otros dispositivos de varias formas. Típi-camente un PLC puede tener integrado puertos de comunicaciones seriales que puedencumplir con distintos estándares de acuerdo al fabricante. Estos puertos pueden ser de lossiguientes tipos: RS-232, RS-485, RS-422 y Ethernet. Sobre estos tipos de puertos hard-ware las comunicaciones se establecen utilizando algún tipo de protocolo o lenguaje decomunicaciones. En esencia un protocolo de comunicaciones de�ne la manera en que losdatos son empaquetados para su transmisión y como son codi�cados. De estos protoco-los los más conocidos son: Modbus, CANBus y Pro�bus, entre otros. Muchos fabricantesademás ofrecen distintas maneras de comunicar sus PLC con el mundo exterior medianteesquemas de hardware y software protegidos por patentes y leyes de derecho de autor.

La importancia de este dispositivo en el proyecto es muy elevada. El PLC será el únicoelemento con el que deba interaccionar el software desarrollado para recoger los datosregistrados en los inversores. La conexión PC-PLC es, por tanto, esencial en el sistema.Podemos ver una fotografía del PLC utilizado en el proyecto en la �gura 1.6.


Figura 1.6: Controlador lógico programable (PLC)

Capítulo 2

Objetivos

El PFC, Proyecto de Fin de Carrera, constituye el colofón a los estudios de IngenieríaInformática y como tal, presenta como objetivo principal enfrentar al alumno al desarrollode un proyecto informático, cuya �nalidad sea el aprendizaje, que resuelva un problemaconcreto, dando lugar al análisis, diseño, evaluación o desarrollo total o parcial de sistemassoftware y/o hardware en relación al problema informático de partida.

La �nalidad del proyecto va más allá de la resolución del problema en cuestión, siendoprimordial el aprendizaje por parte del alumno de las técnicas y procedimientos empleadosen la elaboración del proyecto, dando lugar en última instancia a sistemas informáticosque resuelvan la di�cultad descrita. Es de rigor, no obstante, enfocar los objetivos delproyecto en el problema a resolver.

2.1. Objetivo principal. Finalidad del proyecto

Pueden existir diferentes personas y/o entidades interesadas en conocer informacióndiversa sobre una planta solar fotovoltaica.

Los propietarios de las llamadas huertas solares son los más preocupados por conocerinformación sobre las mismas. Precisan tener bajo control dos cauces informativos, elcorrespondiente a la producción, siendo este el más importante, y el derivado de losposibles fallos o situaciones anómalas que se puedan dar en el complejo solar. Pretendenobtener un conocimiento profundo del ámbito que rodea a la instalación.

El personal de mantenimiento del parque solar debe conocer fundamentalmente losfallos y anomalías subyacentes a los componentes críticos del complejo, los inversores.Gracias a la información que proporcionan estos dispositivos deben ser capaces de solven-tar los problemas que surjan entorno a los paneles solares, seguidores (en el caso de queexistieran) y a los propios inversores. Los problemas derivados de estos elementos puedenser ocasionados por causas eléctricas, comunicacionales o de suciedad, siendo común estaúltima en los paneles solares.

Cabe destacar que, en determinadas ocasiones, para llevar a cabo la instalación de unparque solar, el propietario o propietarios necesitan que una entidad bancaria �nancie elproceso. La entidad bancaria precisa, en la mayoría de los casos, controlar la información

11

12 Capítulo 2. Objetivos

asociada a la producción del parque, es decir, constatar que existen garantías de que losbene�cios del complejo solar son lo su�cientemente importantes para que la inversiónrealizada pueda ser sufragada.

Como se puede apreciar, es necesario obtener, controlar y manipular múltiple infor-mación de interés. A su vez, esta información puede ser organizada de diferentes formas.En cuanto a la producción de la planta solar fotovoltaica, puede ser interesante tenerconstancia de la producción diaria, mensual, anual, total o histórica. De igual forma, noes menos relevante la producción de un inversor o grupo de inversores, también conocidocomo instalación, e incluso sería interesante conocer la producción diaria, mensual, anual,total o histórica de cada uno de ellos. En referencia a los inversores, es de interés conocerlos fallos asociados a los mismos, tales como: caídas en el sistema, errores de comunicación,producción por debajo de la media con respecto al resto de inversores, etcétera.

En conclusión, es necesario trabajar con gran y diversa información con respecto auna huerta solar. Dicha información debe ser precisa, completa y actualizada, así comoaccesible de forma inmediata y desde cualquier lugar, teniendo en cuenta la heterogeneidadde los interesados y su ubicación dispar.

Un sistema de información como el descrito es complejo. Es necesaria la intervencióninformática para crear un sistema que solvente el problema. Tras la petición por partede la empresa propietaria, ImMODO Solar S.A., de llevar a cabo un proyecto con talescaracterísticas, y estudiar minuciosamente el mismo, se de�nió el objetivo principal. La�nalidad del proyecto consiste en llevar a cabo la monitorización de una planta solarfotovoltaica.

2.2. Objetivos operativos

Para conseguir hacer realidad el objetivo principal del proyecto se tuvieron en cuentauna serie de objetivos secundarios o parciales, también llamados objetivos operativos,que en conjunción daban sentido a la �nalidad mencionada, monitorizar un parque solar.Los objetivos operativos, ordenados secuencialmente en función de su realización, son lossiguientes:

Conocer el contexto en el que va a operar el proyecto, es decir, profundizar en elconocimiento de la energía solar fotovoltaica y los parques solares.

Comprender la estructura de un parque solar.

Hacer hincapié en los componentes más importantes del sistema: inversores y con-troladores lógicos programables (PLC).

Con respecto a los inversores, conocer cual es la información que proporcionan sobresu propio estado y el de los paneles solares.

En referencia a los PLC, comprender su estructura, funcionamiento e interaccióncon los inversores, ya que serán los elementos que se comuniquen directamente conun PC y le proporcionen la información que registren los inversores.

2.3. OBJETIVOS PERSONALES 13

Indagar sobre la interacción de un ordenador con los PLC, haciendo especial énfasisen el protocolo de comunicación del controlador lógico programable.

Aclarar la información que deseaba obtener la empresa que realizó la petición delproyecto, las personas a las que les llegaría esa información y demás pormenores alrespecto, es decir, llevar a cabo un análisis profundo de las necesidades del cliente.

Elaborar un plan de proyecto que en diversas reuniones con el cliente se fuese re�nan-do, hasta obtener una visión cercana a los requerimientos de la empresa solicitante.

Estudiar detenidamente el proyecto y tecnologías informáticas que se fuesen a em-plear en el mismo.

Desarrollar el proyecto para �nalmente monitorizar el complejo solar.

2.3. Objetivos personales

Al margen de los objetivos inherentes al proyecto, es importante destacar aquéllosrelativos al ámbito personal. Obviamente las metas a alcanzar pueden ser muy diversas,desde superar sin pena ni gloria uno de los últimos escollos de la carrera, hasta enrique-cerse y formarse aún más si cabe como ingeniero informático. Mis objetivos estuvieronprincipalmente ligados a la última tendencia, y se describen a continuación:

Abordar un proyecto real. Existen proyectos basados esencialmente en la investi-gación y cuyo uso en el mundo real acaba siendo una utopía. No entraba dentro demis planes desarrollar un sistema informático que no fuera a ser necesario, al menosa corto plazo.

Profundizar en un campo poco explotado y con gran salida en un futuro próximo.

Desarrollar mi proyecto más allá de cuatro paredes, teniendo incluso que desplazarmea varios puntos geográ�cos para instalar el sistema, realizar pruebas, etcétera.

Trabajar no sólo con software sino también con hardware.

Profundizar en el aprendizaje y uso de diversas tecnologías informáticas.

Involucrarme en el cuidado del medio ambiente que quizás, antes de conocer elcontexto en el que se desenvolvía el proyecto, tenía un poco olvidado.

14 Capítulo 2. Objetivos

Capítulo 3

Descripción informática

Este capítulo es esencial para comprender el software desarrollado, siendo por tantoel pilar de este documento. Llegados a este punto tenemos una visión general del medioen el que se desenvolverá el sistema, su estructura, con�guración, etcétera, así como losobjetivos que se pretenden alcanzar. Esta sección servirá de nexo entre los apartadosdescritos anteriormente y el producto �nal.

3.1. Metodología

La Ingeniería del Software es una disciplina de la ingeniería que comprende todos losaspectos relacionados con la producción de software, desde las etapas iniciales correspon-dientes a la especi�cación del sistema hasta el mantenimiento de este tras su utilización,es decir, el �ciclo de vida software�. Todo software posee un ciclo de vida. El ciclo devida se rige por el llamado �proceso software�. Es un conjunto de actividades y resultadosasociados que dan lugar a un producto software. De igual forma, el proceso software estádirigido por un modelo o paradigma de proceso, el cual determina el orden en el que seharán las tareas en el proyecto y provee de requisitos de entrada y salida a cada una delas actividades que lo sustentan.

No existe un proceso ideal. Muchas organizaciones han desarrollado su propio enfoquepara el desarrollo de software. Los procesos han evolucionado para explotar las capacidadesde los integrantes de una empresa u organización, así como las características especí�casde los sistemas en desarrollo.

Partiendo de la idea descrita anteriormente, y teniendo la necesidad de explicar deforma más clara y precisa el proceso llevado a cabo en el desarrollo del proyecto, se hizouso de la fusión de dos metodologías para estructurar el proceso software, el paradigmade desarrollo en espiral y el modelo de proceso evolutivo.

Metodología = Modelo de desarrollo en espiral + Modelo de desarrolloevolutivo

Se optó por hacer uso de estos dos paradigmas de proceso, ya que se adaptan consid-erablemente al desarrollo adecuado al sistema como el que se pretendía desarrollar. Por

15

16 Capítulo 3. Descripción informática

un lado, el modelo de desarrollo en espiral, más que representar el proceso software comouna secuencia de actividades con retrospectiva de una actividad a otra, se fundamenta enrepeticiones múltiples del proceso del ciclo de vida, las cuales se pueden dividir en lo quese denominan �mini-proyectos�, que se obtienen en cada iteración de la espiral. Por otrolado, el modelo de proceso evolutivo se basa en prototipos que se desarrollan, partiendode una implementación inicial expuesta al cliente, apoyándose en los anteriores de formaincremental, re�nando las diferentes versiones hasta que se obtiene un sistema adecuado.Las fases de especi�cación, desarrollo y validación se entrelazan en lugar de separarse,facilitando una rápida retroalimentación entre ellas.

La gran ventaja de la utilización conjunta de ambos modelos de desarrollo reside enposeer puntos de control en cada iteración. De igual forma, no es menos importante la�exibilidad que aportan ante requisitos cambiantes, muy propio de productos softwarecon las características que se pretenden abordar.

3.1.1. Modelo de desarrollo en espiral

Debido a la magnitud del software como el que recoge este documento, es común lautilización de este modelo de proceso para abordar proyectos de gran envergadura. Losproductos software son creados a través de múltiples repeticiones del proceso del ciclode vida, dividiéndose estas en �mini-proyectos�. Cada vuelta en la espiral representa unafase del proceso, es decir, supone un avance en el proceso de desarrollo. No hay �etapas��jas tradicionales, ligadas a actividades como la especi�cación o diseño, cada vuelta enla espiral determina las actividades a realizar. El desarrollo en espiral se puede dividir enlas siguientes fases o etapas:

De�nición de objetivos En esta fase se de�nen los objetivos especí�cos identi�candolas restricciones del proceso y el producto, y se traza un plan detallado de gestión.No es menos importante la identi�cación de los riesgos del proyecto, planteandoestrategias alternativas en función de los mismos.

Evaluación y reducción de riesgos Se lleva a cabo una análisis detallado para cadauno de los riesgos identi�cados en el proyecto, de�niendo los pasos necesarios parareducirlos.

Desarrollo y validación Se elige un modelo para el desarrollo del sistema. Es en estafase donde tiene sentido la utilización del modelo de desarrollo evolutivo. Gracias aeste modelo, tras las iteraciones oportunas, se obtendrá un prototipo válido que dépor concluida esta etapa.

Plani�cación El proyecto se revisa y se toma la decisión de si se debe continuar con unciclo posterior de la espiral. Si se decide continuar se desarrolla la plani�cación dela siguiente fase del proyecto.

3.1.1.1. Aplicación al proyecto

En base a la descripción expuesta en la sección anterior, el correspondiente modelo dedesarrollo en espiral que se ha seguido en este proyecto se puede observar en la �gura 3.1.

3.1. METODOLOGÍA 17

Figura 3.1: Modelo de desarrollo en espiral

Las referencias y plazos temporales se establecieron de manera estricta. El planteamien-to ha sido terminar el proyecto siempre y cuando la satisfacción del cliente con respectoal producto fuese plena, y quedasen cubiertos todos y cada uno de los requisitos deman-dados. Es por esta razón, y debido a la complejidad del proyecto, que el desarrollo ha sidoprolongado, alcanzando una franja temporal de un año aproximadamente.

La de�nición de objetivos del proyecto ha quedado esencialmente marcada por lainteracción con el cliente, y en base a sus pretensiones, la dirección de mis tutores.

La evaluación y reducción de riesgos se ha llevado a cabo por mi parte y la de los tutoresdel proyecto, donde su labor ha sido esencial para indicarme los principales riesgos críticosdel desarrollo y poder así evitarlos.

En cuanto a la fase de desarrollo y validación hay que destacar la aplicación del modelode proceso evolutivo, el cual será explicado en una sección posterior. Es sin duda algunaen esta etapa donde la elaboración del producto cobra sentido, y en la que se plantearondiferentes alternativas arquitectónicas, de comportamiento e implementación. Debido a laimportancia de esta fase, se ha dedicado una sección bastante extensa a describirla condetalle.

En último lugar, y como el modelo de desarrollo en espiral determina, se lleva a caboun plan de elaboración de la siguiente fase, es decir, tiene lugar la plani�cación. Esteplan se elabora en base a los resultados obtenidos en la fase anterior. El prototipo esevaluado en profundidad en función de la satisfacción del cliente con respecto a él. Silos resultados han sido satisfactorios, la siguiente etapa se planteará como un incrementode la funcionalidad del sistema, en caso contrario como un incremento de la robustez yconsistencia del mismo.


3.1.2. Modelo de desarrollo evolutivo

Existen dos tipos de modelo de proceso evolutivo:

Desarrollo exploratorio El objetivo es trabajar con los clientes y desarrollar un sistema�nal con alguna especi�cación inicial. El punto de partida se basa en comprenderexhaustivamente los requisitos. El sistema evoluciona según las nuevas propuestasdel cliente.

Prototipos desechables El objetivo es comprender los requisitos del cliente y desarrol-lar un prototipo para evaluar hasta qué punto se han entendido. El prototipo estádestinado a experimentar con los requisitos del cliente que no se comprenden deltodo.

En mi caso elegí el desarrollo evolutivo basado en prototipos desechables. El motivoes que, en principio, el cliente no tenía muy claro lo que realmente quería, así comotampoco conocía la amplitud que podía alcanzar el desarrollo del producto. La empresaque solicitó el software conocía otros productos comerciales que no plasmaban con detallelo que quería, es decir, no se ajustaban a sus necesidades.

El desarrollo comenzó con una entrevista con los responsables, técnicos, operarios, ydemás personal de la empresa que pudiese entrar en contacto con el sistema, para poderconocer así sus requisitos. A partir de entonces, el objetivo era desarrollar un productomejorado en base a la captura de requisitos inicial, de manera que se fuesen entregandoversiones hasta obtener un sistema acorde con el que el cliente solicitó. La principal ventajaque se obtiene al crear productos intermedios y ser estos supervisados por el cliente, esque el desarrollo del software se adapta muy bien a necesidades inmediatas del mismo, yaque el proceso software se puede abordar de forma creciente. Tan pronto como el clientey usuarios del producto entiendan de forma precisa el problema o problemas que deseansolventar, la resolución de los mismos se puede ver re�ejada en el sistema gracias a lacreación de los sucesivos prototipos. Diremos, a modo de resumen, que un prototipo esuna versión preliminar de un sistema con �nes de demostración o evaluación de ciertosrequisitos. El objetivo de estos prototipos es el de hacer comprender las especi�cacionesdel producto �nal.

Como se puede observar, las fases descritas se pueden solapar con la etapa de desarrolloy validación del modelo en espiral. Por lo tanto, y como conclusión, en este proyecto sedesarrollará un prototipo en cada ciclo del paradigma en espiral. Al �nalizar cada ciclo seobtendrá, como resultado de la fase de diseño e implementación, un nuevo prototipo.

3.1.2.1. Aplicación al proyecto

Como se mencionó en la introducción de la sección 3.1, las fases de especi�cación,desarrollo y validación se entrelazan entre sí para poder re�nar el prototipo vigente yconseguir �nalmente un producto intermedio.

En el desarrollo del proyecto se han llevado a cabo una serie de etapas o fases que sepueden ver re�ejadas en la �gura 3.2.

3.1. METODOLOGÍA 19

Figura 3.2: Modelo de desarrollo evolutivo

Especi�cación Partiendo de los requisitos previos, y según avanza el desarrollo, se vanespeci�cando otros nuevos a tener en cuenta. Estos nuevos requisitos pretenden seruna versión mejorada de los iniciales y una vía de experimentación con los que sonmás ambiguos o no se entienden.

Desarrollo En este fase se pasa a diseñar e implementar el prototipo en cuestión, tenien-do en cuenta las distintas alternativas arquitectónicas y de implementación.

Validación Consta de dos ramas. Una de ellas se basa en las pruebas inherentes aldesarrollo, y la otra, en las llevadas a cabo una vez se ha �nalizado la implementaciónde un prototipo y ha sido entregado al cliente.

Se parte de una especi�cación de requisitos inicial iterando entre las tres fases dedesarrollo citadas para obtener sucesivamente productos intermedios, también llamadosprototipos. Una vez el prototipo ha sido validado se vuelve a iterar sobre el modelode proceso para re�nar los requisitos, agregar otros nuevos o eliminar los que no seannecesarios. A la hora de realizar el diseño e implementación del proyecto, y para explicarde forma más clara y estructurar mejor la memoria, las fases por las que pasará cadaprototipo son las siguientes:

Especi�cación Identi�cación de requisitos que debe cumplir el prototipo.

Diseño Planear cuáles son las técnicas y herramientas para conseguir el objetivo marca-do, la creación del producto en demanda.

Implementación Plasmar en código todas las ideas.

Validación Revisar cada requisito para comprobar que se ha re�ejado la solicitud delcliente.

Se puede observar un esquema global de la metodología utilizada en la �gura 3.3.

3.1.2.2. Prototipos desarrollados en el proyecto

En esta sección se van a enumerar los prototipos que se han elaborado en este proyecto.El número de prototipos coincide con el número de ciclos del modelo en espiral que se han


Figura 3.3: Modelo de desarrollo en espiral + Modelo de desarrollo evolutivo

necesitado para construir el producto �nal.

1. Extracción, tratamiento y análisis de la información de cada inversor.

2. Estructura básica de la aplicación web.

3. Almacenamiento persistente y exportación de información. Presentación de datosen página web.

4. Creación y exportación de informes diarios. Presentación en página web.

5. Generación de grá�cas.

6. Creación del sistema de alertas.

3.2. Propuesta. Visión global del sistema

En su descripción menos precisa, pero sí más amplia, el sistema a desarrollar podríade�nirse como:

�Sistema para monitorizar una parque solar�

3.3. ARQUITECTURA GENERAL DEL SISTEMA 21

Si bien resume perfectamente la �nalidad del proyecto, no recoge todos y cada uno delos cometidos del sistema. A continuación se describen las tareas que debe llevar a cabo:

Interaccionar con cada inversor mediante el uso de controladores lógicos program-ables (PLC).

Recoger los datos que registra cada inversor, solicitando dicha información a losPLC. La información referente a cada inversor se detalla seguidamente: número,red, potencia instantánea, corriente instantánea, voltaje útil, frecuencia, potencia deentrada, relación potencia-voltaje del panel solar, voltaje de entrada, resistencia deaislamiento, impedancia, horas de funcionamiento, número total de horas operativas,número de encendidos, energía total producida, estado y voltaje de referencia de laválvula de control interno.

Tratar la información de la que se hace acopio en la comunicación con los PLC,dando lugar a nuevos parámetros referentes a un inversor: identi�cador, tipo y redlógica a la que pertenece. Gracias a la manipulación de la información de cadainversor el sistema debe procesar los siguientes datos de vital importancia:

• Producción energética diaria, histórica y total de la planta solar fotovoltaica.

• Ganancia monetaria diaria, histórica y total del parque solar.

• Potencia instantánea diaria de cada inversor.

• Energía diaria, histórica y total de cada inversor.

• Ganancia monetaria diaria, histórica y total de cada ondulador.

• Informes sobre la producción, fallos y anomalías.

Análisis de la información, evaluando fallos y anomalías. Podemos distinguir dosconjuntos de fallos: el relativo a los errores en inversores y PLC, y el referente a losfallos inherentes a la ejecución de la aplicación que se comunica con los controladoreslógicos programables. Las anomalías en el sistema se basan en controlar que laproducción de algún inversor se encuentre por debajo de la media.

Almacenar la información tratada y evaluada creando sistemas de respaldo.

Mostrar información relevante del parque solar a cada persona interesada de formaintuitiva, sencilla y cómoda.

Enviar información referente a fallos y anomalías del parque.

Por último, cabe destacar que algunas de las mediciones que registran los inversores nose utilizan en el sistema: frecuencia, relación potencia-voltaje del panel solar, resistenciade aislamiento y alguna otra, sin embargo, pensando en una posible ampliación del sistemay como herramienta de depuración es útil identi�car y almacenar sus valores.

3.3. Arquitectura general del sistema

El propósito de esta sección es mostrar de forma general la estructura del sistemaen función de los componentes hardware y software que la integran. Cada uno de estos


Figura 3.4: Arquitectura general del sistema

elementos, independientemente de su índole, pueden ser identi�cados como módulos queen conjunción, gracias a la conexión y comunicación entre sí, dan sentido al complejo quedescriben estas páginas. Los elementos más importantes del sistema creado son:

Panel solar

Inversor

Controlador lógico programable (PLC)

Servidor situado en la planta solar fotovoltaica

• Aplicación que interacciona con los PLC

Servidor externo al parque solar de dominio de la empresa

• Aplicación web

Es esencial comprender cómo interaccionan cada uno de los módulos entre sí y cuál es lafunción de cada uno de ellos en el sistema.

En la �gura 3.4 se pueden apreciar las conexiones entre los módulos del sistema, o loque es lo mismo, qué componente intercambia información con otro y en qué sentido seproduce dicha comunicación.

Es importante resaltar la existencia de dos módulos software que conforman el núcleodel sistema elaborado: la aplicación que interacciona con los PLC, a la que también vamosa denominar como aplicación de escritorio u OmronMonitor, y la aplicación o página web.

3.3. ARQUITECTURA GENERAL DEL SISTEMA 23

Interacción panel solar - inversor

En primer lugar, cabe destacar que la conexión entre paneles solares e inversores no esuno a uno, es decir, suelen estar conectados varios paneles solares con un único inversor.La interacción entre ambos componentes se produce en un solo sentido, siendo el inversorel encargado de recoger la información de los paneles solares a los que esté conectado. Elinversor recibe la corriente continua que generan los paneles solares en su exposición a losrayos del sol transformándola en corriente alterna.

Conexión inversor - inversor

Los inversores suelen estar conectados entre sí formando redes. En base a las carac-terísticas de los inversores utilizados (Omron, modelo: KP40G), una red no puede estarformada por más de 32 de estos dispositivos. La principal funcionalidad de dicho enlacese basa en permitir la conexión íntegra de cada una de estas redes con un PLC.

Interacción inversor - PLC

Un controlador lógico programable puede interaccionar con varios inversores gracias alas redes que estos forman. El PLC se conecta con el primer inversor de la red, denotadocomo �0�. Gracias a la conexión de datos, la información que envía el PLC se transmite portodos los inversores, respondiendo estos en consecuencia. Esencialmente, el PLC solicitainformación a cada inversor, la cual servirá para monitorizar el parque solar. Los datosque envía cada inversor al PLC se pueden observar en la sección 3.2.

Conexión PLC - PLC

Los PLC, al igual que ocurría con los inversores, están conectados entre sí en unamisma red. La razón de este enlace se basa en permitir a un PC interaccionar con todosy cada de los controladores lógicos programables del parque solar.

Interacción PLC - Servidor situado en el parque solar

El PC estará conectado en la misma red que los PLC, pudiendo así comunicarse conellos. Es en este módulo, el PC situado en el parque solar, donde reside la aplicaciónencargada de recoger la información de cada PLC y actuar de forma consecuente paramonitorizar la huerta solar. La aplicación deberá ser la encargada de recibir la informaciónde los PLC, tratar los datos adecuadamente para que sean legibles e intervenir de formaprecisa en función de la información recogida. Para actuar adecuadamente, el softwaredebe almacenar la información separándola en función de su índole: diaria, histórica ototal. De igual forma, debe evaluar los datos identi�cando fallos y anomalías, para generary enviar correctamente correos electrónicos y SMS, así como elaborar toda la informaciónque precise la aplicación web, ya que serán los tres medios que utilicen las personasrelacionadas con el parque solar para conocer lo que en él acontece.


Interacción Servidor situado en el parque solar - Servidor externo

La interacción entre los dos PC representados en la �gura 3.4 se produce esencialmenteentre las aplicaciones que residen en ambos. La comunicación es básica. La aplicaciónsituada en el servidor del parque solar exportará al PC externo la información sobre laproducción, fallos y anomalías. Todos estos datos serán ubicados adecuadamente paraque la aplicación web pueda hacer uso de ellos. La aplicación web deberá tratar la in-formación para visualizarla correctamente, organizándola en varias secciones, permitir laapertura/descarga de �cheros y generar grá�cas.

3.4. Prototipo 1: Extracción, tratamiento y análisis dela información de cada inversor

3.4.1. Especi�cación

El objetivo principal de este prototipo es extraer, tratar y analizar la informaciónprocedente de los inversores del parque solar, interaccionando con ellos mediante el usode controladores lógicos programables (PLC). Los datos que registra cada inversor son labase del sistema, siendo imprescindibles para su desarrollo.

Para lograr la �nalidad descrita es fundamental, en primera instancia, llevar a cabouna comunicación correcta y precisa con los PLC. El fabricante de los inversores y PLC,Omron, proporciona un protocolo de comunicación con tales dispositivos, siendo por tantola comprensión del mismo, el primer paso a la hora de abordar la creación del prototipo.Tras tener conocimiento preciso del protocolo y conseguir comunicarnos adecuadamentecon los controladores lógicos programables, el siguiente paso debía consistir en extraer lainformación de cada inversor. Bajo petición del cliente, los datos de interés eran la poten-cia instantánea y energía producida. Sin embargo, dadas las características del sistema,era muy importante conocer además el estado de error asociado a cada inversor. El proto-colo de comunicación no permitía solicitar a cada inversor exclusivamente la informaciónrequerida, recibiendo en cada trama de respuesta múltiples datos, como se mencionó enel apartado 3.2.

Una vez la interacción con los PLC, y por ende con los inversores, fuera correcta,el siguiente paso fue tratar la información recogida. En esencia, se debe manipular latrama de respuesta de cada inversor, procedente de la comunicación con los PLC, paratransformar cada secuencia de bytes en información legible por el ser humano, convirtiendolos valores correspondientes a cada medición de notación hexadecimal a decimal. Paratratar la información de cada trama se debía conocer el número de bytes correspondientesa la respuesta de cada inversor, pudiendo así distinguirlas entre sí. De igual forma, eraimprescindible saber qué bytes se correspondían con el valor de cada medida asociada a uninversor como: el número de inversor, red de pertenencia, potencia instantánea, númerode encendidos, impedancia, etcétera, y la unidad en la que estaban representadas: W,KW/h, etcétera, para poder así realizar la conversión oportuna en caso de ser necesario.

Por último, y tras tratar de forma correcta la información de cada inversor, se debeanalizar la misma. El análisis comprende básicamente la identi�cación de fallos y anoma-

3.4. PROTOTIPO 1: EXTRACCIÓN, TRATAMIENTO Y ANÁLISIS DE LAINFORMACIÓN DE CADA INVERSOR 25

lías llevando a cabo la evaluación de la producción de cada inversor, valorando si algunode ellos produce por debajo de la media, detectando la inactividad de los controladoreslógicos programables y analizando el estado de los inversores para discernir, por ejemplo,entre un fallo o apagado del dispositivo en función de la hora del día.

Cabe destacar dos ramas de desarrollo que fueron comunes a varios de los prototiposdescritos. Por un lado, la relacionada con la captura de excepciones propias de la aplicaciónOmronMonitor, y por otro, la vinculada con el registro de cada actividad que realiza dichaaplicación en �chero log. Pretendiendo dotar de robustez a la aplicación desarrollada seideó crear un sistema de retroalimentación, de tal forma que fueran detectados los falloso anomalías relacionados, por ejemplo, con la exportación de la información, el envío decorreos electrónicos y SMS y todo aquéllo que pudiera ser problemático o diese lugar auna situación crítica en el sistema. Del mismo modo, cada actividad llevada a cabo porla aplicación debía quedar registrada sirviendo así de análisis y depuración.

Hay que tener en cuenta que este prototipo no presenta interacción con ningún agenteexterno, es decir, no existe ningún usuario o sistema encargado de manipular la aplicaciónOmronMonitor haciendo uso de la misma. De igual forma, la aplicación debe realizaruna serie de acciones de forma secuencial para conseguir su objetivo, no emergiendo asíposibles alternativas en su ejecución. Por estas razones no se incluye ningún diagramade casos de uso alguno, puesto que no aportaría información relevante. Sin embargo, seproporciona el �ujo detallado de eventos en el cuadro 3.1, que en este caso sí nos aportauna visión clara del propósito de la aplicación.

Programador de tareas Aplicación

1. El Sistema Operativo lanza laejecución

2. Establece conexión con los PLCsolicitando información

3. Recibe respuesta con los datos de losinversores

4. Extrae la información de cada inversor5. Trata los datos identi�cando las

duplas �parámetro-valor�, convirtiendo elformato de los valores (hexadecimal adecimal), transformando unidades y

calculando nuevos parámetros6. Analiza la información contemplando

fallos y anomalías

Cuadro 3.1: Flujo de eventos - Prototipo 1

A lo largo de toda la ejecución se capturan las excepciones inherentes a la propiaaplicación y se registran las actividades que lleva a cabo en el log.


Figura 3.5: Trama de solicitud (Command Frame)

Figura 3.6: Trama de respuesta (Response Frame)

3.4.2. Diseño

Una vez comprendido el protocolo de comunicación usado por los controladores lógicosprogramables (PLC), debemos abordar el desarrollo de la aplicación. En primera instan-cia es preciso realizar un buen diseño. Para conseguir dicho objetivo es necesario quela aplicación reúna características tales como: modularidad, escalabilidad, reutilización,cohesión, bajo acoplamiento, portabilidad, etcétera.

Plasmar el protocolo de comunicación

El PC en el que reside la aplicación interacciona con todos los PLC mediante unaconexión de red. Esencialmente, se debe crear una red local entre el ordenador y los con-troladores lógicos programables, donde cada dispositivo representa a un nodo. El PC puedeser considerado como el nodo an�trión, ya que es el encargado de iniciar la interacciónsolicitando información y recibiéndola en consecuencia.

El protocolo de comunicación se fundamenta en el trasiego, envío y recepción, detramas de bytes a través de la conexión de red. Las tramas contienen múltiple informaciónserializada en formato hexadecimal. Existen dos tipos de tramas diferentes utilizados enel sistema que recogen estas páginas, uno de ellos contiene la secuencia de bytes adecuadapara realizar solicitudes de información, mientras que el otro tipo alberga las tramasde respuesta ante tales peticiones. Los datos correspondientes a cada trama varían enfunción del tipo al que pertenecen. Podemos destacar tres partes comunes a los dos tipos detramas: la correspondiente a la cabecera, la zona reservada al comando �FINS�, y la secciónreservada a añadir información extra, utilizada por ejemplo en las tramas de respuestapara devolver la información solicitada. Las tramas de respuesta contienen además dosbytes más, utilizados para indicar el resultado de la ejecución del comando. Cada vez quese envía una trama de solicitud, esta contiene en su interior los bytes correspondientescon el comando �FINS� adecuado a cada petición que se quiera realizar. La respuestacorrespondiente a dicha petición contendrá el comando �FINS� que se envío inicialmente,pudiendo así conocer el comando que la originó.

Vamos a describir a continuación cada una de las zonas identi�cadas en las imágenes3.5 y 3.6.


Figura 3.7: Con�guración del parámetro ICF

ICF (Information Control Field) Este campo se con�gura tal y como se muestra enla �gura 3.7.

RSV (Reserved) Su valor es siempre �00� en hexadecimal. Estos bits son usados por elsistema. No se puede acceder a ellos en la respuesta.

GCT (Gateway Count: Number of Bridges Passed Through) Cuando la comu-nicación se produce a través de más de 8 capas de red con dispositivos cuyas CPUtengan una versión de unidad 2.0 o superior, debe tomar el valor �07� en hexadeci-mal cuando enviemos una trama, en cualquier otro caso �02�. Cuando se recibe unatrama de respuesta, GCT se decrementa en una unidad por cada red que atraviesay se obtiene el resultado �nal. Dado a que en el parque solar no iban a existir tantascapas de red, y que la versión de CPU de los PLC era la 1.4, el valor de este camposiempre debería ser �02�.

DNA (Destination Network Address) Dirección de red de destino. Su valor se es-peci�ca según los siguientes rangos (hexadecimal):

00: Red local.

01 a 7f: Dirección de red remota (en decimal entre 1 y 127).

DA1 (Destination Node Address) Dirección del nodo destino. Su valor se especi�casegún los siguientes rangos (hexadecimal):

00: Comunicación interna en PLC.

01 a 20: Dirección del nodo usando el dispositivo Controller Link Network (endecimal de 1 a 32).

01 a FE: Rango utilizado para comunicación Ethernet (en decimal de 1 a 254). Estees el rango utilizado en el sistema desarrollado.

FF: Transmisión broadcast.

DA2 (Destination Unit Address) Dirección de unidad de destino. El sistema elabo-rado no es necesario especi�car el número de unidad de cada PLC. Por defecto tomael valor �00� en hexadecimal.

SNA (Source Network Address) Dirección de red origen. Toma los mismos valoresque el parámetro DNA.

SA1 (Source Node Address) Dirección del nodo origen. Presenta el mismo rango queel campo DA1.


Figura 3.8: Ejemplo de solicitud de lectura del área de memoria de los PLC

Figura 3.9: Ejemplo de respuesta ante la lectura del área de memoria de los PLC

SA2 (Source Unit Address) Dirección de la unidad origen. Al igual que ocurría con elparámetro DA2, las unidades no tienen sentido en el sistema, tomando por defectoel valor �00� en hexadecimal.

SID (Service ID) Identi�cador de servicio. Utilizado para identi�car el proceso quegenera la transmisión. Por defecto debe tomar el valor �00� en hexadecimal.

Command Code Parámetro de 2 bytes que almacena el comando �FINS�. En ocasionesprecisa de información extra, la cual se deberá indicar en el campo Text. El únicocomando utilizado ha sido el de lectura de la memoria de entrada/salida (ReadingI/O Memory), cuyo código es �0101� en hexadecimal.

Text Esta región presenta dos usos diferentes en función del tipo de la trama. En latrama de solicitud (Command Frame) se utiliza para indicar información extra conrespecto al comando. En la trama de respuesta (Response Frame) es usada paraalmacenar la información que se solicitó.

End Code Parámetro de 2 bytes que indica el código asociado al resultado que produjoel comando de solicitud.


Se pueden apreciar ejemplos de los dos tipos de tramas en las �guras 3.8 y 3.9.

Sería conveniente crear un módulo especí�co para el protocolo de comunicación, cuyoacoplamiento sea mínimo con el resto del software. Es preciso modularizar esta parte para,esencialmente, favorecer la reutilización de los restantes módulos en otras aplicaciones dela misma índole. De esta forma, se podría hacer uso de inversores y PLC de diversosfabricantes, con características y protocolos diferentes, sin necesidad de modi�car el restode la aplicación. Existen varios aspectos que plasmar con respecto al protocolo. Por unlado, es necesario dar soporte al envío de las tramas de solicitud desde el PC a los PLCconstruyendo el comando �FINS� adecuado. De igual forma, es importante recibir las tra-mas de respuesta, tratarlas y analizarlas adecuadamente haciendo legible su informaciónpara el ser humano.

Extracción de información

Tras conseguir comunicarnos correctamente con los PLC, siguiendo el protocolo decomunicación descrito, el siguiente paso debería consistir en extraer la información nece-saria para monitorizar el parque solar. Para ello es preciso centrarnos en las tramas derespuesta del protocolo. Contienen el valor de cada uno de las parámetros de interés paramonitorizar el parque solar: potencia instantánea, producción energética, estado del in-versor, etcétera. La porción de la trama reservada para el valor de cada una de estasmediciones, ocupa un determinado número de bytes en función del parámetro evaluado.Existen por lo tanto valores que ocupan una palabra (2 bytes), dos palabras (4 bytes) ycuatro palabras (8 bytes). Cada inversor almacena en una región de su memoria interna,destinada para este propósito, todos estos datos. Esta información aparece en zonas con-secutivas de memoria, son los denominados �canales de memoria�. El número de bytes queocupa el valor de cada medición es equiparable al número de canales de memoria de sedeben solicitar para obtenerlo, por ejemplo, el valor de la potencia instantánea ocupa 2bytes en la trama de respuesta, o lo que es lo mismo, 2 canales de memoria en el inversor.

Los primeros bytes de las tramas, tanto de solicitud como de respuesta, se correspondencon la cabecera de las mismas. Contienen información acerca del nodo origen e IP queenvía la trama, el nodo destino y su IP, el número de canales (bytes) de datos que albergala trama y otra información de relevancia. Estos datos son muy importantes para que elPC pueda enviar y recibir tramas correctamente de/a cada PLC de la red, conociendoen todo momento de forma unívoca el emisor y destinatario en la comunicación. Paraextraer la información de cada inversor, la aplicación deberá enviar tramas de solicituda cada uno de los PLC de forma secuencial. En primer lugar construirá la trama conla cabecera idónea para el PLC en cuestión y con el comando �FINS� de solicitud, paraposteriormente enviarlo. Por cada envío la aplicación deberá esperar cierto tiempo pararecibir la respuesta, delegando esta función a un hilo de ejecución paralelo encargadoexclusivamente de este cometido, aumentando así la e�ciencia del proceso. Si se recibeuna trama de respuesta dentro del intervalo de espera, cuyo origen es el PLC esperado,pasaremos a tratar dicha trama adecuadamente. Si se recibe una respuesta tardía de algúnPLC se descarta, ya que es muy probable que se deba a alguna anomalía en la red, seconsidera así un fallo del dispositivo y se continúa esperando por la trama del PLC que esprocesado actualmente. En caso de no recibir respuesta del PLC en el intervalo de tiempodestinado a tal propósito, se considerará que tiene lugar un fallo de comunicación.


Tratamiento de información

Existen dos alternativas en la interacción con un controlador lógico programable(PLC), recibir respuesta del mismo y pasar a tratar dicha información, u obtener unatrama tardía e incluso no recibirla, considerando entonces un fallo en la comunicación conel dispositivo. En el primer caso se debe tratar la información recibida adecuadamente,identi�cando el valor de cada una de las mediciones separándolo del resto, haciendo legibledicho valor realizando una conversión del formato hexadecimal al decimal y transformandola unidad de la medición a una válida y de utilidad por el sistema. Obviamente se repiteeste proceso para cada uno de los inversores conectados al PLC de los que se obtuvorespuesta, calculando dos nuevos valores para cada inversor, la energía y ganancia diarias.Cabe la posibilidad de que el estado de alguno de estos inversores sea identi�cativo defallo o anomalía en el aparato. En este caso el tratamiento es muy similar al que recibe unPLC, considerando un fallo o anomalía en el inversor. Es conveniente procurar mostraradecuadamente por pantalla la información que se obtiene de cada inversor, para podercomprobar así la corrección en el proceso de tratamiento.

Análisis de información

Como se ha podido apreciar en los dos apartados anteriores, �Extracción de infor-mación� y �Tratamiento de información�, se analiza la situación que deriva de no recibirrespuesta de un PLC o recibirla con retraso, así como identi�car un estado erróneo enun determinado inversor. En el primer caso, se actúa considerando un fallo en la comu-nicación con el PLC. En el segundo, más que un fallo podría ser considerado como unaanomalía, ya que no recibir respuesta en el intervalo de tiempo destinado a tal propósitosigni�ca que algo extraño está sucediendo con respecto a ese aparato. En el tercer y últi-mo caso, obtener un estado erróneo de un inversor concreto, se identi�ca como fallo en elmismo independientemente del código asociado. Se propuso al cliente realizar un análisisexhaustivo del estado del inversor, pudiendo así identi�car en cada caso la naturalezaexacta del error, sin embargo, el cliente postpuso la idea para un desarrollo futuro.

Por último hay que destacar el análisis que se debe llevar a cabo con respecto a laproducción energética de cada inversor. Para ello, se establece un porcentaje por debajodel cual un inversor produce de forma anómala. Se debe realizar en primer lugar la sumade la energía que produce cada inversor y dividirla entre el total de los inversores activos.Posteriormente, se debe multiplicar la cantidad obtenida por el porcentaje anteriormentecitado.

(∑

Energa diaria de cada inversor \No de Inversores)×Porcentaje frontera(3.1)

Se debe revisar cada inversor y comprobar si su producción energética está por debajodel valor obtenido al aplicar el algoritmo anterior. Si es así, se deberá registrar estasituación adecuamente.

Es importante resaltar que en principio el cliente comentó que el parque solar ibaa poseer varios tipos de inversores del mismo fabricante, Omron. Cada uno de estos


tipos, debido a sus características, sería capaz de convertir corriente continua a alternaen diferente magnitud, es decir, un inversor �pequeño� no produce la misma energía queuno �grande�. Para soportar esta situación de forma e�ciente y escalable, se debía realizarla evaluación de la producción energética entre los inversores de cada grupo y no entregrupos dispares. Finalmente, el parque solar contiene inversores de un solo tipo, pero esindiferente. Si en el futuro existiese heterogeneidad no sería necesario modi�car nada.

Captura de excepciones propias de la aplicación

Esta aplicación debería realizar un seguimiento propio de su ejecución, capturando fal-los o anomalías en cualquier actividad de la misma. Dicha labor sería de gran importanciapara recuperarse ante errores de poca importancia, así como para servir de depuración ycontrol al administrador del sistema, como es mi caso. Cada fallo o anomalía de relevanciadebería quedar registrado, para poder hacer un análisis profundo y solventar el problema.

Esta funcionalidad no presenta clase alguna relacionada directamente, ya que encualquier parte del código fuente se debe llevar a cabo el control de excepciones.

Registro de actuación

Junto con la captura de excepciones, la aplicación debería presentar un sistema deregistro de actuación, para dejar constancia de todas las actividades que realiza. De estaforma se podría revisar dicho registro y encontrar posibles fallos, errores, etcétera.

3.4.3. Implementación

Para implementar este prototipo se hizo uso del entorno integrado de desarrollo Mon-oDevelop y el lenguaje de programación C#, gracias a la posibilidad de ejecutar el softwareelaborado sobre la plataforma Microsoft .NET. Las ventajas que ofrece dicha plataformason múltiples. Cada una de ellas se puede apreciar en la sección 3.11.

Antes de describir cada una de las clases por separado, es preciso mencionar que losmétodos constructores o aquéllos encargados de devolver o modi�car atributos (get/set)no serán explicados, ya que no aportan información importante.

Paquete communication_protocol

El diagrama de clases de este paquete aparece en la �gura 3.10.

CommandFrame Representa a un comando �FINS�.

Atributos

endCodePosition: Posición del último byte del comando en la trama.

headerBytesNumber: Número de bytes que ocupa la cabecera del comando.


Figura 3.10: Paquete communication_protocol

lastSourcePosition: Posición en la secuencia de bytes del comando en la que seencuentra el identi�cador del último dispositivo que envío la trama.

Measurement Determina la información relacionada con una medición o parámetroconcreto de un inversor.

Atributos

abbreviation: Abreviación descriptiva de la medición.

channels: Número de canales de memoria (bytes) que ocupa la medida.

unit: Unidad física en la que está representada la medición.

InverterFrame Identi�ca la secuencia bytes de la trama que contiene la información deun inversor. Sus atributos pertenecen a la clase Measurement.

Atributos

powerToUtilityGrid: Potencia instantánea.

currentToUtilityGrid: Corriente instantánea.

utilityVoltage: Voltaje útil.

gridFrequency: Frecuencia.

pvinputPower: Potencia de entrada.

currentFromPvpanels: Relación potencia-voltaje.

pvinputVoltage: Voltaje de entrada.


insulatioResistance: Resistencia de aislamiento.

undefined: Sin de�nir.

lineImpedance: Impedancia.

periodUserSetEnergy: Horas de funcionamiento.

totalOperatingHours: Número total de horas operativas.

totalEnergy: Energía total.

totalStartupsNumber: Número total de encendidos.

errorStatus: Estado.

internalUpvcontrolPvreferenceVoltage: Voltaje de referencia de la válvula decontrol interno.

Protocol Clase encargada de implementar el protocolo de comunicación. Alberga aquél-las zonas de mayor importancia de las tramas de comunicación.

Atributos

commandFrame: Atributo de la clase CommandFrame.

inverterFrame: Atributo de la clase InverterFrame.

FINSFrameManager Clase encargada de manipular las tramas. Contiene la de�niciónde su estructura. Presenta varios métodos cuya utilización facilita el tratamiento yanálisis de las tramas de solicitud y respuesta.

Métodos

ByteArrayToString: Permite convertir una secuencia de bytes a una cadena decaracteres.

CreateFINSFrameRequest: Crea una trama de solicitud especi�cando la red por laque será enviada, el nodo origen (exclusivamente el PC), el nodo destino (cualquierPLC) y el número de canales que se solicitan.

DoubleWordConverter: Convierte una palabra de doble tamaño a una cadena decaracteres.

FixMinLength: Permite adaptar el valor de un campo de la trama de respuesta aun valor válido si carece del su�ciente número de bits.

GetHexaDecimalValue: Obtiene el valor en formato hexadecimal a partir del deci-mal.

HexaDecimalConvert: Convierte el mapa de caracteres del formato hexadecimal adecimal.


Figura 3.11: Paquete infrastructure

Paquete infrastructure


Node Esta clase contiene la información de cualquier nodo presente en la infraestructuradel sistema.

Atributos

number: Número de nodo.

MonitorizationComputer Representa al computador encargado de realizar la moni-torización en el parque solar.

Atributos

node: Atributo de la clase Node.

Inverter Clase representativa de un inversor.

Atributos

id: Identi�cador único del inversor.

kind: Tipo de inversor.

number: Número de inversor en la red de inversores de la que forma parte.

InverterComparer Implementa el método Compare de la interfaz IComparer.

Métodos

Compare: Permite comparar dos inversores entre sí para determinar si el númerode inversor del primero (number) es menor, igual, o mayor al del segundo inversorobjeto de la comparación. Se utiliza para ordenar de menor a mayor los inversorespertenecientes a una misma red.


Figura 3.12: Paquete con�guration

PLC Controlador lógico programable.

Atributos

ip

netlogic: Red lógica en la que se encuentra el PLC. Los números de redes lógicasde cada PLC son consecutivos, comenzando a contar desde la �0�.

network: Red de trabajo del PLC. Número en la red real. Al contrario que en elcaso anterior, los números no tienen porqué ser consecutivos.

node: Atributo de la clase Node.

inverters: Lista de inversores conectados al controlador lógico programable.

PLCsStore Representa a un conjunto de PLC, es decir, almacena objetos de todos ycada uno de los controladores lógicos programables del parque solar.

Atributos

plcs: Diccionario almacén de PLC. Indexa cada objeto PLC en función de su IP.

Paquete con�guration

El diagrama de clases de este paquete aparece en la �gura 3.12. Existen dos clasespertenecientes a este paquete que serán descritas posteriormente, ya que sufren modi�-caciones relevantes en otros prototipos. Estas clases son: GeneralCon�guration y XML-Reader.


SolarFarm Contiene información básica acerca del parque solar.

Atributos

name: Nombre.

mail: Correo electrónico asociado a la planta solar fotovoltaica.

group: Grupo empresarial poseedor del parque.

TimeSlot Identi�ca un intervalo de tiempo.

Atributos

begin: Comienzo.

end: Final.

Alert Representa información de relevancia.

Atributos

name: Nombre descriptivo del dato o información.

content: Contenido informativo.

AlertsStore Almacen de alertas.

Atributos

alerts: Diccionario almacén de alertas. Cada alerta estará identi�cada unívoca-mente mediante su nombre descriptivo.

Price Representa al precio del KW/h.

Atributos

year: Año en el que se aplica el precio.

valueAssociated: Valor asociado al precio.

PricesStore Almacen de precios.

Atributos

prices: Diccionario almacén de precios. Cada precio está identi�cado por el año enel que se aplica.

SimpleCSVReader Clase que implementa un lector simple de �cheros CSV.

Métodos

ReadGeneralConfigurationFiles: Este método permite leer un �chero CSV conla información referente a cada �chero XML de con�guración, esencialmente la rutadel �chero y de su XMLSchema que permite validarlo. Devuelve un diccionario destrings en el que se almacenan las duplas: �chero XML y XMLSchema asociado porcada entrada.

AssemblyInfo Fichero generado automáticamente por el IDE Mono Project. Almacenainformación acerca de la aplicación: nombre, propietario, etcétera.

3.5. PROTOTIPO 2: ESTRUCTURA BÁSICA DE LA APLICACIÓN WEB 37

Figura 3.13: Paquete action_register

Paquete action_register


Log Clase identi�cativa del log de la aplicación. Permite registrar en un �chero diariocada actividad que desempeña el software.

Métodos

WriteLine: Permite escribir una línea de texto en el �chero, anteponiendo la fechay hora exactas en las que se produce el evento.

WriteEmptyLine: Añade una línea en blanco al �chero.

3.4.4. Pruebas

Las pruebas de este prototipo se llevaron a cabo gracias a la utilización de un simulador.El simulador era una aplicación facilitada por Omron que permitía simular inversores, yaque debido a la lejanía de la planta solar fotovoltaica, no era posible trabajar in situ coninversores reales. El simulador ya no sólo simulaba inversores, sino que además sus valoresvariaban en función de diferentes condiciones meteorológicas y se podían simular fallos yanomalías, permitiendo así trabajar de forma precisa y plena en el desarrollo del sistema.

En primer lugar conectamos en red un PC, en el que residía el prototipo desarrollado, yun PLC. Tras comprobar que la comunicación era correcta, conectamos mediante el puertoserie el PLC a otro PC, en el cual iba a ejecutarse el simulador. A continuación, pusimosen marcha el simulador y el prototipo, comprobando que la extracción, tratamiento yanálisis de la información. Para ello se mostraba, de forma muy pormenorizada, cada unode los pasos y actividades que la aplicación llevaba a cabo.

3.5. Prototipo 2: Estructura básica de la aplicación web


En este segundo prototipo el objetivo principal es la creación de la estructura básica dela aplicación web. Como se mencionó en secciones anteriores, el proyecto está basado enla creación de dos aplicaciones, aquélla que se comunica con los controladores lógicos pro-gramables y la página web, parte de la cual se explica en la descripción de este prototipo.Si bien no interaccionan de forma directa entre sí, el software web precisa de la informa-ción que le facilita la aplicación que recoge el prototipo 1. Para que el funcionamiento de


ambas aplicaciones esté en armonía, es preciso desarrollar el núcleo principal de ambas porseparado, llevando a cabo �nalmente la cohesión entre ellas. Este prototipo se desarrollóen segundo lugar debido a que se basa en mostrar información procedente del primero,con lo cual la dependencia es clara y en un sentido muy concreto. El orden inverso en lacreación de los prototipos hubiera sido más complejo. Existen tres pilares básicos en laestructura de la aplicación web: soporte para autenticación, presentación de informacióny visualización/obtención de informes.

La autenticación es un requisito necesario. A pesar de no manejar información al-tamente con�dencial, el cliente solicitó que la página web dispusiera de un sistema deautenticación para evitar que cualquier persona, de forma indiscriminada, pudiera cono-cer la ganancia que generaba la planta solar fotovoltaica.

Ya que la principal funcionalidad de la aplicación web es ofrecer la información del par-que solar de forma estructurada, facilitando a los usuarios su visualización desde cualquierenclave, es muy importante que esté dotada de soporte para la presentación de datos. Poresta razón, y teniendo en cuenta el extracto social de un alto porcentaje de los usuarios, elaspecto de la página web debe ser agradable, así como el uso de su interfaz fácil, cómodo eintuitivo. La información que el cliente determinó que se debería mostrar en la página webpodría agruparse en: aquélla relacionada con la producción en el parque solar y la basadaen los errores de cada inversor, así como los informes de producción, fallos y anomalíasque destacaremos posteriormente. En cuanto a la producción del parque solar era muyimportante crear varias secciones:

Parque Esta sección debía poseer a su vez tres subsecciones: �Hoy�, �Histórico� y �Total�.En cada una de ellas se recoge la energía producida y la ganancia de la misma,pudiendo visualizarse en función del día actual, cualquier día pasado y el totaldesde que el parque solar se puso en funcionamiento.

Instalaciones Debe contener las mismas subsecciones que la sección anterior. Su �nal-idad es determinar la energía y ganancia en función de un conjunto de inversores,independientemente de que perteneciesen a la misma red, es decir, estuviesen conec-tados a un mismo PLC, sin embargo, aunque la petición inicial del cliente fue suelaboración, �nalmente cambio de opinión, relegando su realización a un futuro.

Inversores Deben poseer las mismas subsecciones que las anteriores: �Hoy�, �Histórico�y �Total�. La subsección �Hoy� deberá permitir seleccionar cada inversor del parquesolar, visualizándose su potencia instantánea, energía producida y ganancia. Losapartados �Histórico� y �Total� permitir seleccionar un inversor y mostrar su energíay ganancia cada día pasado y en total, respectivamente.

La información asociada a los errores únicamente presenta los inversores agrupados porredes, mostrando si existe error en una red o en algún inversor en concreto.

La aplicación web debe permitir la visualización/obtención de �cheros que contenganinformes sobre la producción, fallos y anomalías de todos aquellos días anteriores al actual.El cliente solicitó que sería conveniente que tales informes pudieran ser tratados porgestores de hojas de cálculo.

En la �gura 3.14 se muestra el diagrama de casos de uso de este prototipo.


Figura 3.14: Casos de uso-1

3.5.2. Diseño

Tras crear el primer prototipo y obtener así una visión más precisa del sistema adesarrollar, es prioritario el desarrollo de la aplicación web que permita visualizar lainformación de manera amigable, cómoda, sencilla e intuitiva.

Como se mencionó en la especi�cación de este prototipo existen, tres pilares básicosa los que debe dar soporte la aplicación web: autenticación de usuarios, presentación dedatos y visualización/obtención de informes.

Autenticación de usuarios

La autenticación de usuarios restringe el acceso a la página web. Un usuario debedisponer únicamente de un nombre y contraseña. Al navegar a la dirección de la pági-na web, el visitante podrá introducir su nombre de usuario y clave para acceder a sucontenido, o bien visualizar la información de contacto del sitio web. En caso de que laautenticación sea errónea será informado al respecto. En caso contrario, se le mostrarála página de inicio de la aplicación, teniendo acceso a realizar las acciones que considereoportunas. Todo usuario autenticado dispondrá de una sesión en el portal, de tal formaque si abandona la página web podrá volver a acceder a ella sin necesidad de autenticarsede nuevo durante un tiempo de inactividad determinado. Pasado ese intervalo de tiempodeberá volver a autenticarse por razones de seguridad.

Una vez que el usuario desee abandonar la página web, deberá poder eliminar la


vigencia de la sesión que posee.

Visualización de información

Una de las principales funcionalidades que presenta la aplicación web está relacionadacon la visualización de información. En la página principal se podrá visualizar informaciónacerca del parque solar y de su empresa arrendadora. A su vez, el usuario deberá disponerde un menú que le facilite llevar a cabo las acciones permitidas. El usuario podrá interac-cionar con la aplicación web mediante el citado menú visualizando tres grandes grupos deinformación: el referente a la producción, el relativo a posible errores en el parque solary el relacionado con los informes. Vamos a detallar cada grupo de información de formaindependiente. Con respecto a la producción existen varias secciones dentro de las cualesel usuario puede visualizar información: �Parque�, �Instalaciones� e �Inversores�.

Parque El usuario podrá observar tres subsecciones: �Hoy�, �Histórico� y �Total�. Si elusuario accede al apartado �Hoy� obtendrá una nueva página en la que podrá visu-alizar la energía producida y la ganancia de todo el parque en el día actual, siemprey cuando exista información al respecto, en caso contrario será informado al respec-to. La unidad en la que aparecerá la energía producida será en KW/h, mientras quela ganancia estará re�ejada en euros. Por otro lado, si el usuario utiliza la sección�Histórico�, podrá seleccionar la fecha en la cual desea observar la energía y ganan-cia de la planta solar. Tales datos serán mostrados si existe el histórico de la fechaseleccionada, en caso contrario se informará al respecto. Para facilitar la interaccióncon el usuario y evitar que haya errores, el usuario únicamente podrá seleccionarfechas válidas, es decir, se tendrá en cuenta el número de días de cada mes, los añosbisiestos, etcétera, así como se controlará la solicitud de datos de una fecha incor-rectamente formada. Por último, si el usuario accede al elemento del menú �Total�podrá contemplar la misma información que del apartado �Hoy�, pero teniendo encuenta la suma de la energía y ganancia desde el primer día en que el parque solarestá en funcionamiento.

Instalaciones Como ya se mencionó en la especi�cación, el cliente quería que esta secciónexistiera a pesar de no tener funcionalidad presente. Pretendía que se terminará decompletar en un futuro próximo.

Inversores Contiene las mismas subsecciones que la sección �Parque�, es decir: �Hoy�,�Histórico� y �Total�. En el apartado �Hoy� el usuario podrá seleccionar un inver-sor de una red determinada para visualizar así la potencia instantánea, energía yganancia del dispositivo en el día de hoy. No se podrá seleccionar un inversor o redinválidos, informando adecuadamente de esta situación. Igualmente, la aplicacióndeberá informar en el caso de que no exista información con respecto a un inversor,bien porque aún no se hayan recogidos datos en el día, debido a que el sol no estéoperativo, o bien porque no exista comunicación con el inversor pues presente unfallo. En la subsección �Histórico� el usuario podrá visualizar la misma informaciónque en el apartado �Hoy�, pudiendo seleccionar la fecha de la que desea obtenertales datos. Se tendrá controlar sobre posibles fallos en la selección. Por último, elelemento �Total� permite al usuario seleccionar un inversor de una red concreta paraobservar la energía producida y ganancia del mismo desde que comenzó su periodode actividad.


En referencia al grupo informativo sobre los errores, el usuario visualizará cada unade las redes de inversores del parque solar contemplando si existen fallos o no en cada unode los inversores. Esta información es de especial utilidad para los técnicos del complejoempresarial.

Visualización y obtención de informes

La aplicación web dispondrá de una sección en el menú destinada a ofrecer informesal usuario. Existirán dos tipos de informes, los relacionados con la producción y los con-cernientes a los fallos en el parque solar. Si el usuario accede al apartado �Producción�podrá seleccionar una fecha de la que desee obtener el informe. Como en otras ocasiones,se controlará que el usuario no introduzca una fecha inválida. En caso de que exista infor-mación en la fecha seleccionada, el usuario podrá visualizar e incluso obtener el informe,en caso contrario, se avisará de la inexistencia del mismo. Con respecto a la sección �Fal-los� el proceso es el mismo, lo único que cambia es el contenido del informe, re�ejando losfallos y anomalías del parque solar y la aplicación OmronMonitor.


Para llevar a cabo la implementación de este prototipo se ha hecho uso de múltiplesherramientas y tecnologías informáticas entre las que cabe destacar:

PHP Lenguaje de programación utilizado para dotar de dinamismo a la aplicación weben el lado del servidor.

HTML Lenguaje empleado para crear la estructura básica de las distintas páginas.

CSS Lenguaje formal usado para de�nir las hojas de estilo en cascada que pudieran darun aspecto amigable, elegante y profesional al software.

JavaScript Lenguaje de script cuyo ejecución tiene lugar esencialmente en la lado delcliente, proporcionando dinamismo en la realización de ciertas actividades.

Ajax JavaScript + XML. Permite interaccionar desde el lado del cliente con el servidor,obteniendo resultados y mostrándolos sin que el usuario aprecie dicha comunicación,es decir, de forma totalmente transparente y versátil.

A continuación se va a hacer mención de cada página web que forma parte de laaplicación describiendo los �cheros que participan en su construcción. Es necesario decirque algunos �cheros se utilizan en múltiples páginas. Por esta razón, su funcionalidad serádescrita una única vez.

Aspecto de la página web

El aspecto de la página web reside en la utilización de dos hojas de estilo en casca-da: colour.css y style.css. En estos dos �cheros se recoge la especi�cación formal de losatributos de cada uno de los elementos HTML de la aplicación web. Para favorecer la


modi�cación de tales atributos, eliminando la di�cultad que supondría la utilización deuna sola hoja de estilo, se separon en dos hojas, colour.css y style.css, recogiendo el colory estilo, respectivamente. La hoja de estilo en cascada colour.css hace uso además de lasimágenes utilizadas en elaborar la apariencia del software.

Ficheros comunes a varias páginas

header.php Presenta el código HTML correspondiente a la cabecera de todas las distin-tas páginas restringidas de la aplicación. La separación de este fragmento de códigodel resto permite su reutilización en cada página.

footer.php Presenta el código HTML correspondiente al pie de todas las páginas queconforman la aplicación. Como header.php permite ser reutilizado en cada página.

Estructura básica de cada página Los �cheros que vamos a citar posteriormente con-tienen la estructura básica HTML de la página a la que corresponden. Realizan lainclusión de aquéllos �cheros PHP necesarios para completar el contenido de lapágina, como los �cheros header.php y footer.php, entre otros. Los �cheros son: in-dex.php, contact.php, index_login.php, today_park_production.php,historic_park_production.php, total_park_production.php,today_inverters_production.php, historic_inverters_production.php,total_inverters_production.php, historic_production_export.php,historic_failures_export.php, errors.php, today_energy_chart.php, to-day_power_chart.php y historic_production_chart.php

functions.php Este �chero contiene funciones de utilidad para la construcción de diver-sas páginas.

data_last_update(): Devuelve la fecha y hora de la última actualización de datosen la Base de Datos local. Esta información resulta de gran importancia, ya quepueden así hacerse una idea de la validez de la información que se visualiza.

get_inverters_number(): Permite conocer el número de inversores conectadosdel parque solar.

show_inverters_ids(): Devuelve el identi�cador de todos los inversores. Se utilizapara crear las listas desplegables en las que se debe seleccionar un inversor.

show_netlogics_ids(): Permite obtener el identi�cador de todas y cada una delas redes lógicas del parque, para poder así construir listas desplegables de selección.

db_functions.php Debido a que el acceso a la Base de Datos es muy común en laaplicación, era conveniente facilitar un �chero con las funciones que permitieraninteraccionar con ella.

user_session.php Está formado íntegramente por código PHP. Se encarga de compro-bar dinámicamente si el visitante de la aplicación posee sesión válida en la misma,es decir, está autenticado y puede acceder al contenido restringido, o bien todo locontrario, dejándole navegar de forma exclusiva por las páginas de inicio/autenti-cación y contacto. Este �chero es de gran utilidad en todas las páginas que formanparte del software, exceptuando la destinada a mostrar la información de contacto,para dotarlo de la seguridad adecuada.


genericAJAX.js Contiene las variables y función que forman el núcleo de AJAX. Sedebe incluir en todas aquéllas páginas que quieran hacen uso de esta tecnología.

dateControl.js Código JavaScript que lleva a cabo el control de las fechas mostrándolascorrectamente en función de la elección del usuario, teniendo en cuenta el númerode días de cada mes, años bisiestos, etcétera.

inverterControl.js Ya que cada red de inversores del parque solar puede tener unnúmero diferente de inversores, es preciso que, en función de seleccionar una red uotra, aparezcan los inversores correspondientes a dicha red. Este trasiego de informa-ción se llevaba a cabo mediante el uso de AJAX, de forma totalmente transparenteal usuario.

editor_inverter_change: Desencadena la petición AJAX.

synchronousInvertersIdsRequest: Realiza la solicitud haciendo uso del núcleoAJAX a la url indicada, utilizando el método GET y pasando como parámetro lared lógica seleccionada.

receiverInvertersIdsResponse: Recibe la respuesta del servidor tratándola ypresentándola en la página adecuadamente.

get_inverters_ids.php Recibe la solicitud para obtener la producción de un inversorconcreto. Accede a la Base de Datos para llevar a cabo su cometido, devolviendodicha información o el mensaje informativo de error en caso contrario en formatoXML.

Página de inicio/autenticación

Ficheros comunes: footer.php, user_session.php, genericAJAX.js,db_functions.php

Ficheros especí�cos

index.php

formValidation.js Alberga las funciones encargadas de validar la autenticación deun visitante.

• isRegisteredUser: Desencadena la llamada al código en PHP que compruebasi el nombre de usuario y contraseña introducidos se corresponden con algúnusuario del sistema, devolviendo la respuesta oportuna en formato XML.

• synchronousAuthenticationChecker: Hace uso del núcleo de AJAX envian-do la petición a la url especi�cada, utilizando el método POST y pasando comoparámetro el nombre de usuario y contraseña recogidos en el formulario.

• receiverAuthenticationResponse: Función encargada de recibir la respues-ta del servidor en formato XML y tratarla en consecuencia, mostrando un men-saje informativo en caso de que la autenticación sea errónea.

authentication.php Código PHP que recibe la solicitud proveniente de formVal-idation.js. Accede a la Base de Datos para comprobar la validez de los datosrecibidos como parámetros: nombre de usuario y contraseña. Si el usuario estáregistrado le otorgará una sesión. En cualquier caso, construirá y enviará larespuesta oportuna en XML.


Página de contacto

Ficheros comunes: footer.php

Ficheros especí�cos: contact.php

Página de inicio (usuario autenticado)

Ficheros comunes: footer.php, user_session.php

Ficheros especí�cos: index_login.php

Página Producción->Parque->Hoy

Ficheros comunes: header.php, footer.php, functions.php, user_session.php


today_park_production.php

get_today_park_production.php Código PHP que accede a la Base de Datossumando la energía y ganancia diaria de cada uno de los inversores, mostrando�nalmente su resultado.

Página Producción->Parque->Histórico

Ficheros comunes: header.php, footer.php, user_session.php, genericAJAX.js, date-Control.js


historic_park_production.php

historicParkProduction.js Comprueba si todos los datos introducidos son cor-rectos mostrando una alerta en caso contrario. Si toda la información es válidadesencadena la solicitud AJAX de la energía y ganancia correspondientes a lafecha seleccionada.

• getParkDayData: Comprueba si se ha introducido una fecha válida, no dejando,por ejemplo, algún fragmento de la misma sin indicar.

• synchronousParkDayDataRequest: Hace uso del núcleo de AJAX enviandola petición a la url especi�cada, utilizando el método GET y pasando comoparámetros el día, mes y año indicados en el formulario.

• receiverParkDayDataResponse: Recibe la respuesta del servidor tratándolay mostrándola adecuadamente.

get_historic_park_production.php Recibe la petición realizada en el �cherohistoricParkProduction.js. Comprueba si existe algún �chero CSV en la fechaindicada recopilando su información y construyendo la respuesta en adecuadaen XML. En caso contrario devolverá la respuesta oportuna.


Página Producción->Parque->Total

Ficheros comunes: header.php, footer.php, functions.php, db_functions.php,user_session.php


total_park_production.php

get_total_park_production.php Suma la energía y ganancia de cada inversorque contiene cada �chero CSV correspondiente a cada uno de los días pasadoscon respecto al día actual. De igual forma, suma los datos con respecto a talesparámetros que aparecen en cada entrada de la Base de Datos con respecto aldía actual.

Página Producción->Inversores->Hoy

Ficheros comunes: header.php, footer.php, functions.php, db_functions.php,user_session.php, genericAJAX.js, inverterControl.js, get_inverters_ids.php


today_inverters_production.php

todayInvertersProduction.js Comprueba que se han seleccionado una red e in-versor válidos, desencadenando posteriormente la solicitud AJAX para obtenerla información relativa al inversor.

• getInverterData: Comprueba que se introduzcan una red lógica e inversorválidos.

• synchronousInverterDataRequest: Realiza la solicitud AJAX utilizando elmétodo GET y pasando como parámetros el número de red lógica e inversor.

• receiverInverterDataResponse: Recibe la respuesta del servidor procesán-dola en consecuencia.

get_today_inverter_production.php Código PHP encargado de procesar lasolicitud anteriormente señalada y devolver la respuesta adecuada en formatoXML.

Página Producción->Inversores->Histórico

Ficheros comunes: header.php, footer.php, functions.php, user_session.php, gener-icAJAX.js, dateControl.js, inverterControl.js, get_inverters_ids.php


historic_inverters_production.php

historicInvertersProduction.js Valida la fecha, red lógica e inversor selecciona-dos, realizando posteriormente la petición oportuna al servidor.

• getInverterDayData: Valida la fecha, red lógica e inversor y desencadena lapetición AJAX.


• synchronousInverterDayDataRequest: Lleva a cabo la petición al servidor.

• receiverInverterDayDataResponse: Obtiene la respuesta del servidor enformato XML y la trata adecuadamente mostrando la información solicitada oun mensaje informativo en caso de no disponer de la misma.

get_historic_inverters_production.php Este módulo está formado en su to-talidad por código PHP. Maneja la solicitud anteriormente descrita, obteniendola información del �chero CSV correspondiente a la fecha interceptada y de-vuelve la respuesta oportuna. En caso de error o no disponer de la informaciónse indicará adecuadamente.

Página Producción->Inversores->Total

Ficheros comunes: header.php, footer.php, functions.php, db_functions.php,user_session.php, genericAJAX.js, inverterControl.js, get_inverters_ids.php


total_inverters_production.php

totalInvertersProduction.js Contiene el código JavaScript, que al igual que enel �chero historicInvertersProduction.js de la página �Producción->Inversores->Hoy�, comprueba la información introducida y realiza la petición al servidor.

get_total_inverter_production.php Recibe la solicitud accediendo al �cheroalmacenado con la fecha indicada, obteniendo los datos y sumándolos al con-tenido de la Base de Datos. Devuelve la respuesta, correcta o identi�cativa deerror, en formato XML.

Página Informes->Producción



historic_production_export.php

historicProductionExport.js Valida la información introducida y solicita la peti-ción al servidor.

get_test_historic_production_�le.php Con base en la petición recibida com-prueba si existe el �chero CSV, devolviendo una respuesta con el enlace opor-tuno de descarga, o bien informando de la situación contraria.

get_historic_production_csv_�le.php Permite abrir o descargar el �cherodel enlace que aparece en la página.


Página Informes->Fallos

Los �cheros que utiliza realizan las mismas funciones que los de la página anterior,teniendo simplemente en cuenta que en este caso se manejan los informes que recogen losfallos y anomalías.


Ficheros especí�cos: historic_failures_export.php, historicFailuresExport.js,get_test_historic_failures_�le.php, get_historic_failures_csv_�le.php

Página ERRORES

Ficheros comunes: header.php, footer.php, functions.php, db_functions.php,user_session.php, genericAJAX.js, dateControl.js


errors.php

get_today_errors.php Completa la información de la página. Muestra cada reddel parque junto a sus inversores. Comprueba por cada uno de los inversores,accediendo a la Base de Datos, si presentan error alguno o no, mostrando unicono identi�cativo en cada caso.

Salir de la página web

logout.php Invalida la sesión del usuario, teniendo este que volver a autenticarse paratener acceso al contenido restringido de la aplicación.

3.5.4. Pruebas

En esencia, las pruebas de este prototipo eran simples. Se fue probando cada una de laspáginas individualmente, haciendo especial hincapié en la autenticación, la visualizaciónde la información y la visualización/obtención de informes. Dadas las circunstancias, ycomo en este punto aún no existía comunicación entre las dos aplicaciones del sistema,se generaron manualmente las tablas de la Base de Datos y los �cheros que contenían losinformes. Era muy importante tener en cuenta cómo se iba a mostrar la información, quéocurría si aún no se disponía de datos para presentar al usuario, controlar la selección delas fechas en las páginas de histórico, etcétera.


3.6. Prototipo 3: Almacenamiento persistente y exportaciónde información. Presentación de datos en páginaweb


El objetivo principal de este prototipo consistía en comenzar a cohesionar ambas apli-caciones.

El software web debe mostrar información diaria del parque solar, de tal forma queaquéllos usuarios interesados puedan observar la producción, fallos o anomalías a lo largodel día, estando informados en tiempo real. Debido a la ubicación dispar y remota entrelas aplicaciones desarrolladas en el proyecto software y la precariedad de la conexión aInternet, era preciso desarrollar un sistema de respaldo para que la información diaria nose perdiera por algún fallo en la aplicación del parque solar o el mal estado de la conexión.

Como se citó en el prototipo 1, la captura de fallos y anomalías y el registro de ac-tuación en �chero log de OmronMonitor, eran tareas en continuo desarrollo debido alcrecimiento de la aplicación al elaborar nuevos prototipos incrementando sus funcionali-dades.

Por último, la información que OmronMonitor suministra a la aplicación web, debepoder visualizarse correctamente en esta última atendiendo a las secciones descritas enel prototipo 2. En el cuadro 3.2 se puede apreciar el �ujo de eventos asociado a esteprototipo.

Flujos alternativos del cuadro 3.2

3.1: Si no se recibe respuesta de algún PLC se almacenará la información identi�cativadel fallo.

6.1: Si algún inversor produce por debajo de la media se dejará constancia de ello.

7.1: Contempla que se pueda producir fallo al almacenar los datos, salvando dicha infor-mación si es posible.

8.1: Si se produce un fallo al exportar la información se almacenarán los datos que loidenti�quen.

De esta forma se identi�cará y almacenará cualquier fallo crítico que se produzca durantela ejecución de la aplicación OmronMonitor. De igual forma que en el prototipo 1, secapturan las excepciones inherentes a la propia aplicación y se registran las actividadesque lleva a cabo en el log.

3.6.2. Diseño

La aplicación maneja gran cantidad de información importante que no se desea perder.Un ejemplo claro son los datos diarios acerca de la producción en el parque solar, fallos

3.6. PROTOTIPO 3: ALMACENAMIENTO PERSISTENTE Y EXPORTACIÓN DEINFORMACIÓN. PRESENTACIÓN DE DATOS EN PÁGINA WEB 49








fallos y anomalías7. Almacena la información de cadainversor con respecto a la producción.Salva los fallos de los PLC e inversores8. Exporta los datos sobre la producción

diaria


y anomalías de la planta y aplicación. Cada día será preciso recopilar la informaciónacerca de la producción para mostrarla en la página web. De igual forma, es interesantealmacenar cada uno de los fallos que tienen lugar en el parque o que se relacionan conla aplicación, algunos de ellos serán también presentados en la aplicación web, como losfallos en los inversores, por poner un ejemplo.

La información referente a la producción diaria se debe almacenar de forma local,para posteriormente ser exportada al servidor donde reside el software web. Se guardarála información de cada uno de los inversores activos y cuyo estado sea idóneo. Cada vezque se procese la información de un inversor será almacenada consecuentemente: potenciainstantánea, impedancia, número de encendidos, energía total, etcétera. El fabricante delos inversores nos alertó de una cuestión importante. El cliente, como se ha mencionadoa lo largo de la memoria, estaba interesado en poder visualizar la energía producida porcada inversor en el día, sin embargo, el único parámetro que un inversor KP40G trataes la energía total. Esta situación planteaba una cuestión, cómo podríamos obtener laenergía diaria de la forma más precisa posible. Se pensaron en varias alternativas dediseño hasta obtener la solución más adecuada. Se ideó crear un almacén local, ligadoa la aplicación OmronMonitor, siempre vigente. En dicho almacén se haría acopio de laenergía total producida por cada inversor al �nalizar el día. Por otro lado, haríamos usode un almacén renovable diariamente, en el que se almacenara la energía diaria de cadainversor. Inicialmente, el primer día en el que se pusiera en funcionamiento el parque solar,el almacén de energía total estaría vacío, de tal forma que el primer día, la energía diariay total serían equivalentes. Al �nalizar el día, el valor del campo �energía total� de cadainversor en la trama de respuesta sería salvado en el almacén total. Al día siguiente, paraobtener la energía diaria real, se debería hacer una simple operación aritmética, restando


Figura 3.15: Paquete services

al valor de la secuencia de bytes correspondiente con la energía total el dato asociadocon la energía total del inversor de la que se tuvo constancia el día anterior. De igualforma, al procesar la información de un inversor se debería calcular la ganancia diariaobtenida, multiplicando el precio del KW/h por la energía producida. Obviamente, alcliente también le interesada conocer la ganancia total de cada inversor. Es por ello quecada día se debía sumar la ganancia del día actual con la de los anteriores, situada enel almacén total. Los datos diarios sobre la ganancia y energía de cada inversor deberíanser exportados al servidor en el que reside la aplicación web, para que esta hiciera uso deellos y poder así presentarlos.

Para registrar los fallos del parque solar y de la aplicación se idearon varios almacenes.Concretamente se pensó en destinar un almacén para los fallos y anomalías de los PLC,otro para los inversores, otro para la producción y un último para los fallos internos dela aplicación. Únicamente los fallos en los inversores deberían ser exportados diariamentecada cierto tiempo al PC externo, la información del resto de fallos sería utilizada conotro propósito que veremos en el prototipo 4. Al �nalizar cada día el único almacén localvigente sería el de la producción total, mientras que el resto debería ser preparado parael día siguiente, eliminando cualquier información de su interior.


Para desarrollar este prototipo se utilizaron las mismas herramientas y tecnologías quelas citadas en el punto 3.4.3.

3.6. PROTOTIPO 3: ALMACENAMIENTO PERSISTENTE Y EXPORTACIÓN DEINFORMACIÓN. PRESENTACIÓN DE DATOS EN PÁGINA WEB 51

Paquete services


Server Representa a un servidor. La información referente a un servidor es muy comúnpara, por ejemplo, comunicarse con una Base de Datos, un servidor FTP, un servidorSMTP, etcétera.

Atributos

path: Especi�ca la ruta del servidor.

User Clase que identi�ca a un usuario de cualquier servicio, como por ejemplo, FTP,SMS, etcétera.

Atributos

account: Cuenta del usuario.

id: Identi�cador.

password: Contraseña.

Paquete services.data_base

DataBase Representa a una Base de Datos. Permite crear objetos identi�cativos de lasdos Bases de Datos utilizadas en el proyecto, la local y la externa.

Atributos

name: Nombre de la Base de Datos.

server: Objeto de la clase Server.

user: Objeto de la clase User.

DataBaseMySQLManager Esta clase permite manejar una Base de Datos MySQL. Sise utilizase otra Base de Datos diferente, habría que adaptar pocas líneas de códigopara obtener la �nalidad deseada.

Métodos

QueryDataBase: Permite establecer una conexión con una Base de Datos, realizaruna consulta y cerrar la comunicación de forma íntregra.

La única tabla de la �gura 3.16 que se alberga en el servidor externo es daily_production.La Base de Datos local contiene todas las tablas que aparecen en la �gura.


Figura 3.16: Tablas de la Base de Datos

3.6.4. Pruebas

Para probar este prototipo se comprobó mediante el uso de la aplicación phpmyadminla correcta creación, contenido y borrado de las tablas de las Bases de Datos de ambosservidores. En la aplicación web se examinó si la presentación de los datos era la adecuada.

3.7. Prototipo 4: Creación y exportación de informesdiarios. Presentación en página web


En este cuarto prototipo el objetivo principal se basa en la creación de informes diarioscon la información relativa al parque solar, permitiendo su procesamiento en la páginaweb. Al margen de los datos diarios de la planta solar fotovoltaica, el cliente exigió podertratar un historial de informes sobre la producción, fallos y anomalías, pudiendo inclusiveobtenerlos de forma rápida y sencilla para uso personal de cualquier usuario de la páginaweb. Al igual que ocurría en el prototipo 3, es preciso desarrollar un sistema de respaldopara que el informe de cada día no se perdiera por algún fallo en la aplicación del parquesolar o el mal estado de la conexión. El diagrama de casos de uso de este prototipo sepuede ver en el cuadro 3.3.


3.7. PROTOTIPO 4: CREACIÓN Y EXPORTACIÓN DE INFORMES DIARIOS.PRESENTACIÓN EN PÁGINA WEB 53









diaria9. Crea los informes sobre la producción

diaria, fallos y anomalías10. Exporta los informes







9.1: Registra si se produce algún error al crear los informes.

10.1: Si se produce algún fallo en la exportación se almacenará la información identi�cativadel mismo.

Como podemos apreciar se identi�cará y almacenará cualquier fallo crítico que se produzcadurante la ejecución de la aplicación OmronMonitor. De igual forma, como ocurría losprototipos 1 y 3, captura las excepciones inherentes a la propia aplicación y registra lasactividades que lleva a cabo en el log.

3.7.2. Diseño

Al �nalizar cada día, la aplicación debería realizar una ejecución de salvaguarda, esdecir, almacenar la información relativa a la producción, fallos y anomalías diarios en unsoporte sencillo, de poco espacio y fácil procesamiento. Concretamente, aclarando algunasde las cuestiones citadas en el prototipo 3, la aplicación debería salvar la información delalmacén diario de producción en un soporte independiente, así como almacenar los datosde los almacenes de fallos y anomalías de PLC, inversores, producción y aplicación en uninforme conjunto. Ya no sólo sería necesario un almacenamiento local, sino que tambiénse precisaría de la exportación de estos informes al servidor externo por dos razones: laaplicación web necesita utilizar tales informes y por razones de seguridad, optando por lareplicación de datos en nodos distintos. La página web utiliza estos informes de diferentesformas. Por un lado usa cada uno de los informes de producción diaria para dar sentido alas secciones de �Histórico� y �Total� de la página web, así como al apartado �Producción�de la sección �Informes�. La utilidad en la subsección �Histórico� es clara, ya que cadainforme presentará la fecha de la que hace acopio de información, pudiendo así tratarlay mostrarla en la web. Con respecto al apartado �Total�, ocurre de forma similar. Esnecesario tratar cada informe diario junto con la información del almacén del día actualpara obtener la energía producida y ganancia total.



Podemos visualizar el diagrama de clases de este paquete en la �gura 3.12.

SimpleCSVWriter Esta clase se relaciona con un escritor de �cheros CSV muy simple.

3.7. PROTOTIPO 4: CREACIÓN Y EXPORTACIÓN DE INFORMES DIARIOS.PRESENTACIÓN EN PÁGINA WEB 55

Métodos

DailyProductionSummaryWriter: Crea un �chero CSV, en la ruta y con el nombreespeci�cado, con la información diaria de la producción.

DailyFailuresSummaryWriter: Construye un �chero CSV, en la ruta y con elnombre indicado, con los datos de los fallos y anomalías diarios.

Paquete services.ftp


FilesDirectory Esta clase identi�ca a un directorio para almacenar �cheros.

Atributos

path: Ruta del directorio.

FTPClient Permite llevar a cabo las funcionalidades de un cliente de FTP. Esta clasefue reutilizada y es muy extensa, considerando así no explicarla en profundidad.

FTPServer Representa a un servidor FTP.

Atributos

server: Atributo de la clase Server.

user: Atributo de la clase User.

localDirectory: Atributo de la clase FilesDirectory. Identi�ca la carpeta local dela que se exportarán los �cheros.

remoteDirectory: Atributo de la clase FilesDirectory. Directorio remoto al que se�subirán� los �cheros.

FTPUpload Clase que permite exportar �cheros haciendo uso de la clase FTPClient.

Métodos

FileUploadPermite subir un �chero de un directorio local a uno remoto.

3.7.4. Pruebas

Para probar este prototipo, al margen de comprobar que las funcionalidades desarrol-ladas con anterioridad funcionasen correctamente, se prestó atención en que los �cheroscon los informes diarios de producción y fallos contuvieran la información correcta ypudieran ser visualizados adecuadamente en la página web.


Figura 3.17: Casos de uso-2

3.8. Prototipo 5: Generación de grá�cas


El objetivo de este prototipo consiste en dotar a la aplicación web de un sistema degrá�cas. Al examinar el prototipo 4 el cliente pensó en que sería buena idea añadir grá�casa la página web, para poder así visualizar de forma más amigable cierta información. Elcliente expresó su deseo de añadir una sección más al menú �Producción� de la aplicaciónweb que recogiese grá�cas sobre la energía diaria producida por cada inversor del parquesolar y la potencia instantánea de cada uno de ellos, organizados en función de las redesa las que pertenecían. El cliente también pidió crear una subsección para tener acceso alhistorial de grá�cas sobre la producción energética. El diagrama 3.17 es complementarioa la �gura 3.14.

3.8.2. Diseño

Para llevar a cabo este prototipo se debía, en primera instancia, adecuar la página weba la nueva sección �Grá�cas� solicitada por el cliente. Esta sección tendría internamentetres subsecciones: �Energía hoy�, �Potencia hoy� e �Histórico�. Si el usuario accede a �En-ergía hoy� deberá observar cada una de la redes de inversores ordenadas por número dered, de menor a mayor. Cada una de estas redes mostrará sus inversores indicando, medi-ante un diagrama de barras horizontal, la energía producida por cada uno de ellos. Paramostrar estos datos la aplicación web deberá utilizar el almacén de producción diaria. Alseleccionar el apartado �Potencia hoy� el usuario de la aplicación web visualizará cada redde inversores del parque, del mismo modo que ocurría en �Energía hoy�, con la única difer-encia de que en lugar de mostrar la energía producida, presenta la potencia instantáneade cada inversor en el preciso instante de su consulta. En los dos apartados anteriores seinformará además si alguna de las redes no responde. La subsección �Histórico� permitiráal usuario seleccionar una fecha en concreto para mostrar la grá�ca de energía de ese día.Se controlará la elección de una fecha inválida.

3.8. PROTOTIPO 5: GENERACIÓN DE GRÁFICAS 57


Aquellos �cheros de uso común están descritos en la sección 3.5.3.

Librería libchart en PHP

Se hizo uso de esta librería para poder, mediante el uso de las funciones que facilitasu interfaz, construir las grá�cas de la página web.

Página Producción->Grá�cas->Energía hoy



today_energy_chart.php

get_today_energy_chart.php Accede a la información de la Base de Datosreferente a la producción diaria, creando una grá�ca por cada red de inversores.

Página Producción->Grá�cas->Potencia hoy



today_power_chart.php

get_today_power_chart.php Obtiene la información de la Base de Datos conrespecto a la potencia instantánea de cada inversor en función de la últimamedición, creando una grá�ca por cada red de inversores.

Página Producción->Grá�cas->Histórico



historic_production_chart.php

historicProductionChart.js Comprueba que se introduzca una fecha correcta,creando la petición AJAX correspondiente.

get_historic_production_chart.php Recibe la solicitud generada por el �cherohistoricProductionChart.js extrayendo la información del �chero CSV solicita-do y procesando la grá�ca correspondiente.


3.8.4. Pruebas

La pruebas consistieron en comprobar que las grá�cas se visualizaran bien y contu-vieran la información correcta. Las principales di�cultades surgieron en la utilización delmódulo PHP externo libchart para generar las grá�cas.

3.9. Prototipo 6: Creación del sistema de alertas


El objetivo de este prototipo se fundamenta en ampliar la monitorización del parquesolar. La página web es de gran utilidad para conocer múltiple información, sin embargo,es preciso acceder expresamente a ella. Existen otro medios de comunicación como losmensajes de móvil o los correos electrónicos, cuya familiaridad con el ser humano estámuy extendida, siendo los soportes de comunicación más utilizados. Presentan ademásotra ventaja muy importante, basada en la recepción de información continua sin previaacción del usuario, pudiendo aplicar el símil informático de la comunicación no orientadaa conexión, ya que no es preciso que una persona lleve a cabo una determinada activi-dad para recibir información vía SMS o e-mail. En el sistema que abordamos es precisoúnicamente que la persona interesada haya facilitado su número de teléfono y direcciónde correo electrónico para estar siempre informado. El cliente nos puso un ejemplo muyclaro de las ventajas de uno de estos soportes de comunicación, utilizando como ejemplo alos técnicos del parque solar. Supongamos que un técnico tiene bajo control varios parquesolares y está continuamente desplazándose de uno a otro sin posibilidad de acceder fácil-mente a la página web. Gracias al envío de SMS puede recibir en su móvil, PDA, etcétera,un mensaje alertándole de algún fallo o anomalía en una planta solar, obteniendo la in-formación de forma inmediata y pudiendo actuar en consecuencia. La utilidad del correoelectrónico fue expuesta por mí, considerándola el cliente de gran ayuda. El administradordel sistema quiere tener constancia de cualquier fallo o anomalía del sistema en cualquiermomento a lo largo del día. El envío continuo de SMS sería poco e�ciente, teniendo encuenta que en ocasiones los problemas tardan tiempo en resolverse. Es por ello que en estecaso es preferible recibir un correo electrónico cada cierto tiempo con un informe acercade fallos o anomalías.

Conseguir un sistema de envío de SMS y correos electrónicos preciso era de vitalimportancia para el cliente, ya que consideraba que dotaría de mayor riqueza al sistemaampliando el concepto de monitorización, inicialmente ligado a la página web. El �ujo deeventos de este prototipo aparece en el cuadro 3.4.





3.9. PROTOTIPO 6: CREACIÓN DEL SISTEMA DE ALERTAS 59









diaria9. Crea los informes sobre la producción

diaria, fallos y anomalías10. Exporta los informes

11. Envía los correos electrónicos con elresumen de fallos y anomalías




9.1: Registra si se produce algún error al crear los informes.

10.1: Si se produce algún fallo en la exportación se almacenará la información identi�cativadel mismo.

11.1: Contempla que se pueda producir fallo al intentar enviar los correos electrónicos.

Como podemos apreciar se identi�cará y almacenará cualquier fallo crítico que se produzcadurante la ejecución de la aplicación OmronMonitor, alertando mediante el envío SMS sifuera preciso. De igual forma, como ocurría los prototipos 1, 3 y 4 captura las excepcionesinherentes a la propia aplicación y registra las actividades que lleva a cabo en el log.

3.9.2. Diseño

El envío de SMS y correos electrónicos dota de sentido total al concepto de monitor-ización. Ya no sólo es interesante visualizar la información en una página web sino, graciasa la amalgama de tecnologías y medios de comunicación, hacer extensible la coberturainformativa a otros soportes.

Las funcionalidades básicas del sistema estaban cubiertas. Gracias a la modularidadpuesta de mani�esto en el desarrollo del proyecto, y concretamente en la aplicación Om-ronMonitor, se pudieron integrar nuevas funcionalidades de forma sencilla. Se debía asípensar en el desarrollo de dos nuevos módulos claramente diferenciados, el correspondientecon el envío de SMS y el relativo al envío de correos electrónicos.

Envío de SMS y correos electrónicos

El objetivo principal de los SMS es aumentar la cobertura informativa del sistema,no haciendo necesario el uso de Internet en un puesto adecuado para ello, permitiendoa cualquier persona interesada en conocer los sucesos de importancia del parque solar,fundamentalmente fallos y anomalías, estar informada continuamente.

El envío de SMS, así como de correos electrónicos, que veremos posteriormente, sedebía hacer con mucho cuidado. Existe personal de diversa índole, lo que signi�ca que notodos ellos deben recibir la misma información. Se identi�caron tres grupos de personas:administradores, técnicos y trabajadores de la producción.

Administradores Precisan conocer todo tipo de fallos y anomalías, tanto referentes alparque solar, como relativas a la aplicación. En principio no tendrían porque conocerla información de la planta solar fotovoltaica, sin embargo, algún fallo puede derivarde un error en la aplicación como por ejemplo, el envío de una trama de solicitudincorrecta no obteniendo respuesta adecuada.

Técnicos Exclusivamente necesitan conocer aquéllos fallos referentes del parque solarrelativos a los PLC, inversores, etcétera, para así poder solucionarlos.


Trabajadores de la producción Únicamente deben recibir la información acerca defallos o anomalías en la producción, para poder así encargarse de por ejemplo, limpiarlos paneles solares.

Aunque en principio la distinción de personal era la mencionada anteriormente, �nalmenteel cliente expresó que las tareas de los trabajadores de la producción eran delegadas, porel momento, a los técnicos, no existiendo los primeros como tal, aunque sí seguramenteen un futuro.

El envío de SMS se produce de forma controlada, para evitar enviar un gran númeroy no generan gastos innecesarios. Por cada fallo concreto se enviarán, en un intervalo detiempo lo su�cientemente grande, un número concreto de SMS, por ejemplo, para un fallode un inversor concreto en el día se enviarán 3 SMS como mucho. Se tuvo que diseñarcada mensaje para que fuese lo su�cientemente descriptivo y no excesivamente farragoso.Cualquier información que se quisiera especi�car de forma más detallada se describiríamediante un correo electrónico. Los correos electrónicos se utilizarían para extender lainformación que recogen los SMS. Se tuvo que pensar en un �asunto� descriptivo paracada correo electrónico, así como de un cuerpo adecuado. Los correos electrónicos nopresentan número limitado de envío, ya que pueden ser de gran ayuda y no dan lugara ningún problema, como ocurría con los SMS. Sin embargo, para evitar enviar un grannúmero, se optó por enviar, al �nalizar cada ejecución de la aplicación, un único correoelectrónico que recogiese un informe completo.


Paquete services.sms


Sender Clase encarga de enviar SMS

Métodos

SendSMSContact: Envía un SMS a un contacto especi�cando el nombre delmismo y el contenido del SMS.

SendSMSGroup: Envía un SMS a un grupo de contactos.

SendSMS: Método encargado de enviar un SMS.

SendServiceProxy y SMSProxy Clases suministradas por la empresa con la que secontrató el envío de mensajes.

SMSServer Representa a un servidor de mensajería.

Atributos

printStackTrace: Permite indicar si se quiere mostrar una traza del procesamientode los SMS.


Figura 3.18: Paquete contacts

path: Ruta del servidor.

quietMode: Booleano que indica si se desea modo silencioso o no en el envío.

user: Atributo de la clase User.

smsProxy: Atributo de la clase SMSProxy.

Paquete services.smtp


SMTPServer Servidor de SMTP.

Atributos

server: Atributo de la clase Server.

Paquete contacts


Contact Esta clase representa a un contacto al que se le pueden enviar SMS o correoselectrónicos.

Atributos

name: Nombre completo de la persona.

phoneNumber: Número de teléfono móvil.

mail: Dirección de correo electrónico.

Administrator Clase hija de Contact. Hace referencia a un administrador.

ProductionWorker Clase hija de Contact. Hace referencia a un trabajador de la pro-ducción.

Technician Clase hija de Contact. Hace referencia a un técnico. Tanto ella, como las dosanteriores permiten diferenciar entre los contactos a la hora de enviar SMS o correoselectrónicos.


ContactsStore Almacen de contactos.

Atributos

contacts: Diccionario para almacenar los contactos. Quedan indexados por el nom-bre.



GeneralCon�guration Esta clase se especializa en almacenar y permitir el acceso atodos los parámetros de con�guración de los que hace uso la aplicación.

Atributos

solarFarm: Atributo de la clase SolarFarm.

dailyFailuresPath: Ruta del directorio en el que se almacenan los �cheros CSVcon el informe diario de fallos.

dailyProductionPath: Ruta de la carpeta en la que se ubican los �cheros CSVcon el informe diario de producción.

logPath: Ubicación del directorio en el que se almacena el registro diario de ac-tuación de la aplicación.

totalOperationTimeSlot: Atributo de la clase TimeSlot. Intervalo temporal en elque el software presenta operatividad total.

productionBalanceTimeSlot: Atributo de la clase TimeSlot. Franja temporal enla cual se produce el balance de producción entre los inversores del parque solar.

localDataBase: Atributo de la clase DataBase. Identi�ca a la Base de Datos local.

externalDataBase: Atributo de la clase DataBase. Base de Datos externa, utilizadapor la aplicación web.

ftpServer: Atributo de la clase FTPServer.

smtpServer: Atributo de la clase SMTPServer.

smsServer: Atributo de la clase SMSServer.

monitorizationComputer: Atributo de la clase MonitorizationComputer.

plcsAlerts: Atributo de la clase AlertsStore. Almacena cualquier información rel-evante con respecto a los PLC.

invertersKinds: Lista que contiene el tipo de los inversores.

invertersAlerts: Atributo de la clase AlertsStore. Alberga información de interéssobre los inversores.

productionAlerts: Atributo de la clase AlertsStore. Contiene datos de importanciasobre la producción.

ftpAlerts: Atributo de la clase AlertsStore. Presenta información relevante conrespecto al trasiego de datos vía FTP.


externalDataBaseAlerts: Atributo de la clase AlertsStore. Almacena informaciónmuy importante sobre la Base de Datos externa.

prices: Atributo de la clase PricesStore. Almacén de precios.

XMLReader Esta clase se encarga de leer los �cheros en formato XML necesarios parael correcto funcionamiento de la aplicación. Esencialmente existen tres �cheros:

omron-monitor_con�guration.xml Contiene los datos acerca de la con�gu-ración de la aplicación.

plcs.xml Información relevante sobre el protocolo de comunicación, PLC e inver-sores.

contacts.xml Alberga información sobre los contactos.

Métodos

Initializate: Inicializa el lector de cualquier �chero XML.

ValidationCallBack: Valida un �chero XML con su XMLSchema correspondiente.

ReadConfiguration:Método encargado de leer el �chero omron-monitor_con�guration.xml.

ReadPlcs: Procesa el �chero plcs.xml.

ReadContacts: Manipula el �chero contacts.xml.

Paquete core

El diagrama de clases de este paquete no aparece en la memoria debido a su amplitud,sin embargo, se puede visualizar en el contenido del CD-ROM.

OmronMonitorCore Núcleo principal del software. Hace uso del resto de clases paraejecutar las funcionalidades de la aplicación.

Atributos

generalConfigurationFiles: Diccionario que almacena la información básica conrespecto a los �cheros de con�guración, esencialmente su ruta y la de su XMLSchemaen el árbol de directorios.

messageReceived, stopThread, lastSource, endCode, plcResult, response:Estos atributos permiten implementar la conexión con los PLC mediante el uso deun hilo paralelo de ejecución. No son muy relevantes.

Métodos

SendFrame: Interfaz que permite enviar un frame a través de la red mediante elprotocolo UDP, especi�cando el contenido del mismo, dirección y puerto de envío.

SendMail: Método que envía un correo electrónico especi�cando el grupo de contac-tos al que será enviado, asunto y contenido del mismo.


ReceiveCallback y ReceiveMessages: Estos métodos permiten al hilo paralelode ejecución, destinado a procesar la respuesta de los PLC, recibir los mensajesprocedentes de estos dispositivos.

ReadLoadFile: Hace uso de la clase SimpleCSVReader para leer el �chero de cargade la aplicación. En él reside la información acerca del resto de �cheros que contienelos datos básicos para garantizar el funcionamiento del software.

ReadGeneralConfiguration: Utiliza la clase XMLReader para leer los �cheros:omron-monitor_con�guration.xml, plcs.xml y contacts.xml.

CreateDataBaseTables: Crea cada una de las tablas de la Base de Datos local:total_production (almacena información sobre la producción total), daily_production(salva los datos sobre la producción diaria), plcs_failures (fallos y anomalías de losPLC), inverters_failures (almacena los fallos y anomalías con respecto a los inver-sores), production_failures (fallos y anomalías sobre la producción) y others_failures(fallos y anomalías con respecto a la aplicación). A su vez, crea la tabla daily_productionen la Base de Datos externa.

DropDataBaseTables: Se encarga de eliminar todas las tablas de la Base de Datoslocal y remota, exceptuando la tabla total_production.

CreatePLCsConnection: Crea la conexión con los PLC para iniciar la comuni-cación.

SendFINSFramePLC: Este método envía una trama �FINS� de solicitud a un PLCdeterminado haciendo uso del gestor de tramas.

ManagePlcFailure: Procesa y trata el fallo del controlador lógico programableespeci�cado.

ManagePlcResponse: Procesa y trata la trama de respuesta de un PLC, separandopara ello la información de cada inversor. Por cada inversor llama al método queprocesa cada uno de los valores de sus mediciones, o bien al método que trata algúnfallo en el dispositivo.

ManageInverterData: Calcula la energía producida por el inversor en el día, asícomo la ganancia monetaria, insertando o actualizando su entrada correspondienteen la Base De Datos local.

ManageInverterFailure: Procesa y trata el fallo de un determinado inversor.

UpdateDailyInformation: Este método actualiza la información diaria, modi�-cando cada entrada de la tabla total_production, creando y exportando el �cheroCSV con la producción y construyendo y exportando el �chero CSV con la informa-ción de fallos y anomalías. Finalmente elimina las tablas innecesarias, como ya semencionó anteriormente.

ManageArguments: Aunque en la actualidad se están haciendo mejoras con respectoa la funcionalidad de la aplicación, aceptando múltiples argumentos, el software sólofunciona en dos modos, el modo normal, utilizado a lo largo de todo el día, y el modobackup al �nalizar el día, encargado de exportar la información al servidor externoy preparar la aplicación para el día siguiente. Este método evalúa los argumentosutilizados en el lanzamiento de la ejecución de la aplicación.

Main: Programa principal. Recoge la mayor parte de la lógica de OmronMonitorCore.Vamos a citar detalladamente cada uno de los pasos que lleva a cabo este método:


1. Evalúa si se introdujeron los argumentos correctamente, mostrando unmensaje con la información sobre la ejecución de la aplicación en caso dehaberlos introducido de forma errónea.

2. Lee el �chero de caga, load_�le.csv, y posteriormente cada uno de los�cheros de con�guración.

3. Crea el hilo paralelo de ejecución encargado de recibir la respuesta de losPLC.

4. Comienza la interacción con los controladores lógicos programables. Enprimer lugar envía la trama de petición al PLC.

5. Espera un tiempo determinado a recibir la respuesta. Si en dicho tiempose obtiene la trama de respuesta se pasa a procesarla haciendo uso delos método ManagePlcResponse y ManageInverterData (por cada inversorconectado). Si se recibió una respuesta errónea, se tratará adecuadamente

6. La aplicación exporta la tabla daily_production de la Base de Datos local.

7. A continuación, se evalúa si la ejecución de la aplicación se produce en elintervalo horario de total operatividad. Si es así, se lleva a cabo el balancede producción de cada inversor.

8. Finalmente, si se lanzó el software con el �ag �-b�, se hará uso del métodoupdateDailyInformation.

9. En última instancia se enviarán los informes pertinentes mediante correoselectrónicos.

Cabe destacar que a lo largo de todo el código de esta clase se capturan lasexcepciones propias de la aplicación, se evalúan errores enviando los SMS quesean precisos y se actualizan las tablas de la Base de Datos necesarias.

Figura 3.19: Diagrama de paquetes

3.10. PUESTA EN MARCHA REAL 67

Figura 3.20: Diagrama de despliegue del sistema

3.9.4. Pruebas

Las pruebas de este prototipo se centraron en comprobar que los correos electrónicosy SMS llegaban adecuadamente a cada persona y que su contenido fuera el correcto enfunción del destinatario y causa del envío.

3.10. Puesta en marcha real

Tras probar cada prototipo y apreciar que el funcionamiento del sistema era adecuado,se decidió implantar en su entorno real. Los mayores problemas surgieron con la aplicaciónOmronMonitor, ya que el software web, utilizado como soporte para visualizar informa-ción, no entrañaba complicaciones. Los principales problemas que surgieron al adecuarel sistema tenían que ver con la comunicación con los PLC del parque solar. Como semenciona en la sección 4.3 existieron di�cultades relacionadas con la mala conexión entreinversores, inversores y PLC, PLC y red con el PC, etcétera.

3.11. Herramientas y tecnologías informáticas utilizadas

En este apartado se darán a conocer cada una de las herramientas y tecnologías infor-máticas que se han utilizado en el desarrollo del proyecto.

3.11.1. SYSMAC CX-ONE y CX-Programmer

SYSMAC CX-ONE es un paquete integrado de herramientas para autómatas �nitos(en inglés Finite Automata, en sus siglas FA) compuesto por software de soporte para loscontroladores lógicos programables (PLC) de la empresa Omron y otros componentes.

CX-Programmer es una de las herramientas del paquete SYSMAC CX-ONE que per-mite con�gurar un PLC. Entre los diversos parámetros de con�guración que posee un


Figura 3.21: Conjunto de PLC con�guradas

controlador lógico programable, destacan el reloj interno, la red y el software interno querige su funcionamiento. En la �gura 3.21 aparecen todos los PLC que se tuvieron quecon�gurar para poder ser utilizados en el parque solar.

3.11.2. Microsoft .NET y Microsoft .NET Framework

Microsoft .NET [14] es un conjunto de tecnologías software de Microsoft que dan lugara una plataforma de desarrollo sencilla y potente, cuya �nalidad es distribuir el softwareen forma de servicios que puedan ser suministrados remotamente y sean capaces de co-municarse y combinarse unos con otros de manera totalmente independiente del sistemaoperativo, lenguaje de programación y modelo de componentes con los que hayan sidodesarrollados. Microsoft .NET se fundamenta en el uso globalizado de sistemas distribui-dos, utilizando XML como el pegamento universal para permitir que las funciones que seejecutan en diferentes computadoras a través de una organización o del mundo se unanen una sola aplicación. Su propuesta es ofrecer una manera rápida, económica, segura yrobusta de desarrollar aplicaciones, permitiendo una integración más rápida y ágil entreempresas y un acceso más simple y universal a todo tipo de información desde cualquiertipo de dispositivo.

Microsoft .NET Framework es el corazón de la plataforma Microsoft .NET. Este frame-work [15] constituye el marco de trabajo y ejecución común a la tecnología Microsoft .NET.En la �gura 3.22 se puede observar su arquitectura.

Los componentes principales de Microsoft .NET Framework son:

El conjunto de lenguajes de programación Microsoft .NET Framework soporta var-ios lenguajes de programación gracias a la capa de Especi�cación Común de Lengua-jes (del inglés Common Language Speci�cations, en sus siglas CLS ), que proporcionauna abstracción común a todos y cada uno de los lenguajes, entre los que cabedestacar C#, considerado como el lenguaje principal, puesto que es el único desar-rollado especí�camente para la plataforma.

3.11. HERRAMIENTAS Y TECNOLOGÍAS INFORMÁTICAS UTILIZADAS 69

Figura 3.22: Arquitectura de Microsoft .NET Framework

Figura 3.23: Arquitectura del Entorno Común de Ejecución para Lenguajes (CLR)

La Biblioteca de Clases Base La Biblioteca de Clases Base (del inglés Base Class Li-brary, en sus siglas BCL) gestiona la mayoría de las operaciones básicas que seencuentran involucradas en el desarrollo de aplicaciones.

El Entorno Común de Ejecución para Lenguajes El Entorno Común de Ejecuciónpara Lenguajes (del inglés Common Language Runtime, en sus siglas CLR) es elmotor encargado de gestionar la ejecución de las aplicaciones desarrolladas en losdistintos lenguajes, a las que ofrece numerosos servicios que simpli�can su desarrolloy favorecen su �abilidad y seguridad.

La herramienta de desarrollo compila el código fuente de cualquiera de los lengua-jes soportados en un código intermedio, el Lenguaje Intermedio Común (del inglésCommon Intermediate Language, en sus siglas CIL), similar al byte-code de Java.Para generarlo, el compilador se basa en la Especi�cación de Lenguaje Común, quedetermina las reglas necesarias para crear el código intermedio compatible con elCLR.

Para que se lleve a cabo la ejecución se necesita un compilador JIT (del inglésJust-In-Time) que genera el código máquina real que se ejecuta en la plataformadel cliente. De esta forma se consigue con Microsoft .NET independencia de laplataforma de hardware. Podemos ver la arquitectura del CLR en la �gura 3.23.


3.11.3. Mono Project y MonoDevelop

El proyecto Mono (del inglés Mono Project) [16] es una iniciativa de desarrollo abier-to patrocinada por Novell para desarrollar código abierto, más concretamente la versiónUNIX de la plataforma de desarrollo Microsoft .NET. Su objetivo es permitir a los de-sarrolladores de UNIX construir y hacer uso de aplicaciones de la plataforma cruzada.NET.

¾Cuál es la diferencia entre Mono y Microsoft .NET?

La iniciativa Microsoft .NET es un esfuerzo empresarial profundo de Microsoft untanto confuso, es decir, es complejo tener un conocimiento preciso con respecto a ella.Una parte de esta plataforma, quizás la más importante, es el marco de desarrollo oespacio de trabajo (Microsoft .NET Framework). Mono es una implementación del marcode desarrollo, pero no de cualquier otra cosa relacionada con la iniciativa .NET, comoPassport o software-as-a-service.

Mono Project contiene una serie de componentes cuya �nalidad es la creación desoftware:

Una máquina virtual de Infraestructura de Lenguaje Común (del inglésCommon Language Infrastructure, en sus siglas CLI ) que contiene un cargador declases (del inglés Classes Loader), un compilador en tiempo de ejecución (del inglésJust-in-time, en sus siglas JIT ), y un recolector de basura en tiempo de ejecución.

Una librería de clases que puede trabajar con cualquier lenguaje que funcioneen el Entorno de Ejecución Común para Lenguajes (del inglés Common LanguageRuntime, en sus siglas CLR). Las librerías de clases de .NET compatibles estánincluidas.

Un compilador para el lenguaje C#.

La arquitectura de Mono Project es apreciable en la �gura 3.24.

MonoDevelop [17] es un entorno de desarrollo integrado (del inglés Integrated Devel-opment Enviroment, en sus siglas IDE ) libre, diseñado principalmente para el lenguaje deprogramación C# y otros lenguajes .NET, aunque abierto a cualquier tipo de lenguaje.Sin embargo, se espera que MonoDevelop sea algo más que un IDE: se pretende que seauna plataforma extensible sobre la que cualquier tipo de herramienta pueda ser constru-ida. Las principales características MonoDevelop son: completado de código, manejo declases, ayuda incorporada y soporte para proyectos y extensiones.

El entorno integrado de desarrollo MonoDevelop ha sido utilizado en el proyecto parallevar a cabo la implementación de la aplicación OmronMonitor. En la �gura 3.25 se puedever una captura del entorno.


Figura 3.24: Arquitectura de Mono Project

Figura 3.25: Captura de MonoDevelop


3.11.4. C#

C# [18][19] es un lenguaje de programación orientado a objetos desarrollado por Mi-crosoft como parte de la plataforma .NET. Presenta sintaxis orientada a objetos basadaen C++ y está muy in�uenciado por otros lenguajes de programación como Delphi y Java.Algunas de sus características más importantes son: sencillez, orientación a objetos, ori-entación a componentes, gestión automática de memoria, seguridad de tipos, instruccionesseguras, sistema de tipos uni�cado, extensión de tipos básicos, operadores y modi�cadores,lenguaje que soporta versiones, e�ciente y compatible. Al margen de sus peculiaridades,en su mayoría propias de la orientación a objetos, se trata de un lenguaje de programaciónmultiparadigma que abarca las disciplinas de la programación funcional, imperativa, ori-entada a objetos, genérica y orientada a componentes, lo que aumenta su versatilidad. Enel proyecto he usado la versión C# 2.0 debido a restricciones de la empresa.

3.11.5. XML

XML [20][21], siglas en inglés de eXtensible Markup Language (en español Lenguajede Marcado Extensible), es una especi�cación de propósito general desarrollada por elWorld Wide web Consortium (W3C). Se trata de una adaptación y simpli�cación de unmetalenguaje anterior, SGML, que se orienta a la creación de especi�caciones o modelosde documentos (metalenguajes) o datos con el �n de poder estandarizar el intercambiode información estructurada entre los componentes de una aplicación, o entre distintasaplicaciones o sistemas, de una manera segura, fácil y �able. Existen varias formas dede�nir la estructura de un documento XML, siendo las más usadas la utilización deSchema y DTD, documentos externos en los que se especi�can los elementos, atributos,tipos, relaciones y demás aspectos que debe cumplir un determinado documento XMLpara ser válido con respecto a su Schema o DTD asociado. Esta tecnología se ha utilizadofundamentalmente en el desarrollo de la aplicación OmronMonitor, más concretamente enla creación de los documentos de con�guración y demás información de interés de los quehace uso dicha aplicación. Gracias a su versatilidad y sencillez, ya que cualquier personapuede comprender un documento XML y modi�carlo, se ha utilizado para tal propósito,permitiendo así sin necesidad de manipular y volver a compilar la aplicación, modi�carparámetros de la misma.

3.11.6. PHP

PHP [22][23], acrónimo recursivo derivado de PHP Hypertext Preprocessor (en castel-lano PHP Preprocesador de Hypertexto) es un lenguaje de programación interpretadode �código abierto� (en inglés Open Source) diseñado esencialmente para la creación depáginas web dinámicas, aunque también recoge otros campos de uso. PHP ha sido uti-lizado en este proyecto en la mayor parte de la estructura de la página web creada paravisualizar la información recogida de la planta solar, esencialmente en el tratamiento dela información dinámicamente.


3.11.7. HTML

HTML [24], siglas de HyperText Markup Language (en castellano Lenguaje de Marcasde Hipertexto), es el lenguaje estándar utilizado en la web para representar la informaciónintercambiada por sus usuarios en forma de documentos de hipertexto. Esta tecnologíaha sido utilizado junto con PHP para crear la estructura básica de la aplicación webdesarrollada.

3.11.8. CSS

Las hojas de estilo en cascada (del inglés Cascading Style Sheets, en sus siglas CSS )son un lenguaje formal usado para de�nir la presentación de un documento estructuradoescrito en HTML o XML, y por extensión en XHTML. El uso de CSS se fundamenta enseparar la estructura de un documento de su presentación. CSS ha sido utilizado paraseparar la presentación de la estructura en la página web.

3.11.9. JavaScript

JavaScript [25][26] es un lenguaje de programación interpretado utilizado principal-mente en páginas web. Presenta una sintaxis semejante a la del lenguaje Java y el lenguajeC. Todos los navegadores modernos son capaces de interpretar el código JavaScript in-tegrado dentro de las páginas web. Tradicionalmente se utiliza en páginas web HTMLpara realizar tareas y operaciones en el marco de la aplicación en el lado del cliente, elnavegador, es decir, carece de acceso a funciones del servidor. JavaScript se ejecuta enel agente de usuario al mismo tiempo que las sentencias van descargándose junto con elcódigo HTML. Su uso en el proyecto se ha fundamentado en el desarrollo de la páginaweb, permitiendo así por ejemplo, manejar el control de las fechas en los desplegables dela página sin necesidad de realizar interacción alguna con el servidor, ubicando por tantoparte de la lógica en el lado del cliente única y exclusivamente.

3.11.10. AJAX

AJAX, acrónimo de Asynchronous JavaScript And XML (en castellano JavaScriptAsíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interacti-vas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios,mientras se mantiene la comunicación asíncrona, en ocasiones síncrona, con el servidoren un segundo plano. De esta forma es posible realizar cambios sobre las páginas sinnecesidad de recargarlas obteniendo información del servidor, lo que signi�ca aumentar lainteractividad, velocidad y facilidad de uso en las aplicaciones. AJAX en esencia es unatecnología asíncrona, en el sentido de que los datos adicionales se solicitan al servidor yse cargan en segundo plano sin interferir con la visualización ni el comportamiento de lapágina. Gracias a JavaScript se efectúan las funciones de llamada de AJAX al servidor,mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponibleen los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncronoesté formateado estrictamente en XML, aunque su utilización sea la más extendida. AJAX


es una combinación de cuatro tecnologías ya existentes: XHTML o HTML y CSS, Docu-ment Object Model (DOM), el objeto XMLHttpRequest y XML. Como DHTML, LAMPo SPA, AJAX no constituye una tecnología en sí, sino que es un término que engloba aun grupo de estas que trabajan conjuntamente.

3.11.11. CSV

Los �cheros de Valores Separados por Comas (del inglés Comma-Separated Values[27], en sus siglas CSV ) son un tipo de documento sencillo para representar datos enforma de tabla, en las que las columnas se separan por comas, o punto y coma. Graciasa la sencillez de creación, modi�cación y cómputo de este tipo de �cheros, su uso ha sidoutilizado tanto en la aplicación de escritorio como en la aplicación web, permitiendo asíun procesamiento y comunicación de información de gran �uidez.

3.11.12. FTP

El Protocolo de Transferencia de Ficheros (del inglés File Transfer Protocol [28], ensus siglas FTP) es un protocolo de red para la transferencia de archivos entre sistemasconectados a una red TCP, basado en la arquitectura cliente-servidor. La utilización deesta tecnología en el proyecto se ha basado en la exportación de �cheros relevantes desdeel servidor donde reside la aplicación de escritorio, al servidor en el que reside la aplicaciónweb.

3.11.13. MySQL

MySQL [29] es un sistema de gestión de base de datos relacional, rápido, robusto,multihilo y multiusuario. El servidor MySQL está diseñador para entornos de produccióncríticos con alta carga de trabajo, así como para integrase en software para ser distribuido.MySQL es: un sistema de gestión de bases de datos, de código abierto, rápido, �able yfácil de usar. Su popularidad como aplicación web está muy ligada a PHP, que a menudoaparece en combinación con MySQL. Esta tecnología ha sido utilizada en el proyecto paratrabajar con información relevante de las dos aplicaciones desarrolladas.

Capítulo 4

Aportaciones, conclusiones y trabajosfuturos

En este capítulo se resumen las aportaciones más signi�cativas del proyecto, descri-biendo las conclusiones �nales alcanzadas y las di�cultades encontradas a lo largo deldesarrollo del mismo, así como una serie de mejoras o ampliaciones del sistema elaborado.

4.1. Aportaciones del proyecto

El aporte principal del proyecto es ofrecer un sistema automatizado de monitorizaciónde una planta solar fotovoltaica. El concepto �monitorizar� es relativamente ambiguo ypuede no expresar en profundidad la amplitud del trabajo llevado a cabo. Por ello, sedetallan a continuación las aportaciones más relevantes del proyecto:

Automatización de recogida, procesamiento y cálculo de información por-menorizada de un parque solar. La importancia de esta actividad subyace en desecharla necesidad de realizar estas tareas in situ, siendo una labor poco e�caz, ine�cientey costosa.

Evaluación automatizada de fallos y anomalías. Es de vital importanciadisponer de una base de conocimiento sobre la cual respaldarse para conocer es-ta información y actuar en consecuencia, ya no sólo la referente a los dispositivosque conforman la estructura de la planta solar, sino del propio sistema de monitor-ización, permitiendo así la retroalimentación del mismo.

Es innecesario el desplazamiento de un técnico que evalúe periódicamente el estadode la instalación, puesto que en la mayoría de los casos el sistema obtiene con bas-tante precisión la fuente del fallo o anomalía, interviniendo exclusivamente la �guradel técnico para reparar el problema concreto. De igual forma, la �gura del admin-istrador queda relativamente ajena al devenir del sistema, recibiendo los informespertinentes en caso de problema.

Automatización de envío de información de interés. Los datos más relevantesque precisan conocer las personas preocupadas del correcto funcionamiento de un

75

76 Capítulo 4. Aportaciones, conclusiones y trabajos futuros

parque solar se pueden englobar en tres conjuntos. Por un lado la información ref-erente a la producción, de vital importancia para los propietarios y clientes de laplanta solar. Otro conjunto estaría formado por los datos relativos a los fallos yanomalías propios de la instalación, de especial importancia para los técnicos. Porúltimo, la información referente a fallos o anomalías del sistema informático, muyimportante para los administradores del mismo.

El envío de toda esta información se lleva a cabo mediante dos mecanismos: SMS ycorreos electrónicos, diferenciando en cada caso el contenido de ellos en función delos destinatarios.

Visualización y actualización de toda información importante en una apli-cación web. Es preciso que los interesados en conocer los pormenores del parquesolar a cualquier hora del día, tengan acceso desde cualquier ubicación, y que lainformación ofrecida esté actualizada constantemente.

4.2. Conclusiones �nales

Tras la elaboración del proyecto y su integración plena en un entorno de explotaciónse han obtenido varias conclusiones, relacionadas con el proceso de desarrollo y puesta enmarcha del sistema realizado y con el funcionamiento y utilidad del mismo. A continuaciónse destacan las conclusiones más relevantes:

La interacción con el cliente debe ser continua. Este requisito nos es recordadoconstatemente durante el transcurso de la carrera, sin embargo, debido al carácterdocente de las prácticas que se desarrollan, no se concibe la importancia del mismohasta que no nos enfrentamos ante un proyecto real. Es sin duda alguna de vitalimportancia para que la satisfacción del cliente sea buena, y si la implicación delmismo es elevada, estará interesado en mantener conocimiento continuo del devenirdel producto, como ha sido el caso del proyecto que recogen estas páginas, algo queclaramente mejora la creación del sistema.

La disposición a realizar cambios en el sistema debe estar siempre pre-sente. El cliente puede cambiar de parecer o bien no estar conforme con algunosaspectos del producto. Pongamos un ejemplo para explicar esta situación con másdetalle:

Inicialmente la exigencia de la empresa era que la página web, en la que se informadetalladamente de todos los pormenores de la planta solar fotovoltaica, incluyeragrá�cas diarias, históricas y totales relacionadas con la producción energética delparque solar. Los requisitos del cliente no cambiaron hasta algunos días después deque se pusiera en marcha el periodo de pruebas del sistema informático instaladoen la huerta solar. Fue entonces cuando el cliente pensó que sería mejor mostrargrá�cas referentes a la potencia diaria y producción de energía diaria e histórica decada inversor, agrupando su información en función de la red a la que pertenecían,requisitos con los que en principio no se contaba. De igual forma, creyó convenienteeliminar la grá�ca que recogía la producción energética total de la planta.

El cumplimiento de plazos en la entrega de módulos del sistema o delproducto en su totalidad es muy signi�cativo, ya que de ello depende en gran

4.2. CONCLUSIONES FINALES 77

medida la satisfacción �nal del cliente. En las continuas reuniones con el cliente eramuy repetida la frase: �Lo quiero para ayer�.

El ahorro económico que experimenta la empresa que solicitó la elab-oración del proyecto es considerable. Aunque la inversión en la compra delproducto inicialmente suponga un gasto cuantioso, a la larga el ahorro es más quenotable. Con la adquisición de este sistema es innecesaria la contratación de person-al que recoja, compruebe y analice regularmente in situ la información del parquesolar.

Se puede apreciar el e�ciente y preciso análisis e identi�cación de fallos yanomalías. No es precisa la revisión periódica por un técnico de las instalaciones, yaque el sistema analiza e identi�ca cualquier problema avisándole. El desplazamientodel técnico a la planta solar fotovoltaica se debe realizar únicamente para solucionarel fallo o anomalía, sabiendo de antemano el foco concreto del problema. Pongamosun ejemplo aclaratorio:

Una vez montado el parque solar y estar funcionando el sistema que recogen estaspáginas, se pudo apreciar que un determinado inversor daba constantemente falloa la hora de establecer comunicación con él. El informe con esta información fuerecibido por los técnicos de la empresa, desplazándose al parque solar y solucionan-do el problema. Pudieron comprobar que el fallo había sido solventado, ya que norecibían más SMS y correos electrónicos que les alertarán de su persistencia.

La continua difusión informativa mediante SMS y correos electrónicos esacogida con agrado por propietarios, clientes y técnicos, haciéndonoslo saber. Elestar informados de cualquier problema en el parque solar, la producción energéticay monetaria del mismo, así como otros aspectos sin necesidad de mirar expresamentela página web, fue muy bien recibido.

El sistema creado puede instalarse en diferentes parques solares, dondelos elementos que intervengan en él sean de distinto fabricante y utilicen distin-tos protocolos. Debido a que la aplicación que se comunica con los inversores esmuy modular, permite ser utilizada con otros tipos de estos dispositivos, cambian-do simplemente el módulo de comunicación con el dispositivo concreto, es decir,modi�cando el protocolo.

La aplicación web fue bien acogida por la empresa ImMODO Solar S.A.Sirvió para que fuese utilizada como plantilla para otras webs. Cualquier parquesolar que se monitorice utilizará su aspecto y estructura interna, fomentando así launi�cación de contenidos, algo muy valorado por la empresa.

En de�nitiva, la satisfacción tanto personal como de los propietarios, clientes y técnicosrelacionados con el parque solar ha sido elevada, algo que sin duda alguna es bastantemotivador y me alienta a seguir trabajando en el mundo laboral relacionado con miprofesión.


4.3. Di�cultades encontradas

El desarrollo de todo proyecto de �n de carrera, y por ende la mayoría de proyectosinformáticos, no está exento de di�cultades. A continuación se detallan las más impor-tantes:

Análisis del funcionamiento de un parque solar fotovoltaico. El desconocimien-to en este campo era profundo, y llegar a tener una idea clara, era de vital impor-tancia para poder trabajar correctamente.

Estudio profundo de un PLC. Este dispositivo es básico en el sistema realizado,ya que interacciona directamente con el software destinado al acopio de la informa-ción que recogen los inversores sobre los paneles solares y su propio funcionamiento.Era importante conocer su estructura, funcionamiento, con�guración y protocolo decomunicación del que hacen uso. La complejidad residía, en primera instancia, enel desconocimiento total del aparato, y en segundo lugar, quizás el más importante,en conseguir comprender e implementar el protocolo de comunicación con el PLC.

Evaluación de fallos y anomalías. Contemplar todos los problemas que podíantener lugar en la instalación fue tarea ardua. Sin ir más lejos, un inversor no sabediferenciar entre el código de estado asociado a su desconexión y el código de estadorelativo a un fallo en la comunicación. En cada uno de estos dos casos se debe actuarde forma diferente. En el primero no se debe actualizar la información referente aese inversor, puesto que todos sus campos (por razones propias de los creadores deldispositivo) toman valor �0�. En el segundo se debe informar del error para que seacorregido en el menor tiempo posible.

Comunicación de fallos, anomalías e informes de producción. La ejecucióndel software que recoge la información de los controladores lógicos programables, enfunción de la época del año, puede comenzar por ejemplo a las siete de la mañanay concluir a las diez de la noche. Obviamente, la jornada laboral de los técnicos ola disponibilidad de los clientes y propietarios se ajusta a un horario más reducido.Recibir SMS en toda la franja horaria descrita no era consecuente, por ejemplo enel caso de los técnicos, ya que no trabajan todas esas horas. De igual forma no seríaagradable que un cliente reciba un SMS con el resumen de la producción diaria auna hora inadecuada. El ajuste de los horarios de envío de estos mensajes, así comodiscernir entre los destinatarios de los mismos, llevó su tiempo.

Elección del formato de los �cheros que recogen la información diaria. Al�nalizar el día, la aplicación de escritorio exporta diversos �cheros con informaciónrelevante para la página web: �cheros con la producción energética y potencia decada inversor, informes con fallos y anomalías, etcétera, que en algunos casos podríanalcanzar un tamaño considerable. Por otro lado, debido a la ubicación del parquesolar, la calidad de comunicación de la que dispone el PC no es demasiado elevada.Elegir un formato de �chero cuya transferencia fuese costosa y cuyo procesamientopor la página web fuera lento reduciría la e�ciencia del sistema, siendo por tanto laelección del formato de estos �cheros tarea clave. Tras estudiar distintas alternativas,entre ellas XML, se optó por el formato CSV.

Creación de un sistema de respaldo. Debido a la baja calidad de la comuni-cación en la huerta solar, en ocasiones la exportación de la información diaria al

4.4. LECCIONES APRENDIDAS 79

servidor donde reside la página web, no se llegaba a producir. Era obvio que si dichainformación era únicamente almacenada en tal servidor, se podría perder informa-ción de interés. Es por ello que �nalmente se ideó crear un sistema de respaldo,de tal forma que se almacenase toda la información localmente, y periódicamentefuera exportada al servidor remoto. En cualquier caso, si el error en la comunicaciónperduraba algunos días, se podría rescatar toda la información una vez el problemahubiera sido solucionado.

Ajuste de la ejecución de la aplicación de escritorio. Se tuvo que evaluar cadacuanto tiempo sería lanzado el programa, ya que podría darse lugar a solapamientosen la ejecución. Tras evaluar la carga de procesamiento de cada ejecución y la calidadde la comunicación, se pudieron determinar correctamente los intervalos de tiempoen los que sería lanzado el software.

Fallos en las redes. Al realizar pruebas del sistema en el parque solar se pudieroncomprobar fallos en las redes. Por un lado, existían fallos en las redes formadaspor los inversores, bien porque el técnico encargado de habilitarlas no lo habíahecho o bien porque la conexión de algún inversor fallaba, ya que el proceso paraconectarlos era complejo y propenso a errores. Por otro lado, se podían apreciar fallosde comunicación con algún PLC. La causas de este error podían ser la inexistenciade conexión o fallo en el cable Ethernet utilizado.

Condiciones climatológicas adversas. Surgieron problemas al probar los prototi-pos relacionados con la aplicación situada en el PC del parque solar. En ocasiones laclimatología no era bene�ciosa para poder comprobar que la evaluación de la pro-ducción era correcta, ya que un día nublado no permite ver si los inversores estánproduciendo dentro de unos límites razonables.

Sobretensión de la instalación. Hubo ocasiones en las que se produjo la so-bretensión de la instalación de la planta solar fotovoltaica. Este fenómeno producedescargas que pueden destruir o dañar seriamente el material e incluso dar lugar anuevas sobretensiones. Debido a algún fallo de los técnicos al crear la instalación seprodujeron sobretensiones, que como consecuencia dañaron algún PLC e inversor,los cuales tuvieron que ser reemplazados por otros nuevos.

4.4. Lecciones aprendidas

A lo largo de la realización del proyecto se han aprendido varias lecciones, entre lasque cabe destacar:

Trabajo de investigación de un área ajena a la informática, el mundo fotovoltaico.

Programación de autómatas, es decir, controladores lógicos programables (PLC),muy utilizados en automatización de tareas, esencialmente en procesos industriales.

Hay vida más allá del software para un informático. Durante la carrera nos espe-cializamos esencialmente en el desarrollo de software. Gracias a este proyecto hecomprendido la importancia del hardware, y ello me ha hecho estar más interesadoen el mismo.


Diseño de un sistema formado por múltiples nodos y arquitecturas. En el sistemadesarrollado se trabaja de forma directa con dos servidores situados remotamente ydispositivos electrónicos, tales como inversores y PLC.

Realización de una aplicación web con manejo de bases de datos y páginas dinámicas.Hasta este proyecto había realizado páginas web para uso personal o destinadasa alguna asignatura concreta, sin embargo, nunca lo había hecho de cara a lasexigencias de un cliente.

Afrontar un proyecto real. Esta es la lección más importante, por todo lo que elloconlleva: interacción con el cliente, cumplimiento de plazos, continua adaptación delsistema, presión, etcétera.

4.5. Trabajo futuro

Los objetivos tanto a nivel de proyecto como a nivel a personal se han cumplido, sinembargo, las posibilidades de mejora o ampliación de funcionalidades, como en la mayoríade los proyectos informáticos, son innumerables. A continuación se enumerarán algunasde estas posibilidades:

Sistema de log con niveles Sería interesante crear un sistema de log con niveles, detal forma que cada uno de ellos permitiese registrar con más o menos detalle lasactividades de la aplicación que se comunica con los PLC.

Mejora de informes Los informes no están exentos de mejora. Quizás podrían alma-cenar información más completa y precisa. Sin duda alguna, la creación de nuevosinformes sería útil. Por ejemplo, un informe que recogiese los inversores que menoshan producido al �nalizar el mes o aquellos con mayor índice de fallos, sería de granutilidad.

Interfaz web Otro punto que siempre es motivo de mejora es el relacionado con lainterfaz de la aplicación web. Idear un diseño más sencillo, intuitivo, vistoso, etcétera,es siempre posible.

Aumentar funcionalidades de la aplicación web Si tuviésemos en cuenta pequeñosdetalles, cabría la posibilidad de añadir un mayor número de funcionalidades a lapágina web, como por ejemplo, permitir a los clientes modi�car sus datos personales.También sería interesante incluir una sección personalizada en la que cada clientetuviera disponible documentación acerca de las condiciones contractuales, planes deobra, avisos y otra información de interés en formato electrónico.

Escalabilidad del sistema Cabría pensar en la posibilidad de utilizar el sistema enotros parques, teniendo entonces que replicar y modi�car mínimamente el softwareweb para recoger la información de la nueva planta solar. Obviamente, también sedeberían modi�car los �cheros de con�guración de los que se sustenta el sistema.Como se puede apreciar, los cambios son escasos y no alterarían el funcionamientodel sistema.

4.5. TRABAJO FUTURO 81

Trabajar con otros fabricantes de inversores Si vamos aún más allá, el sistema po-dría ser compatible con múltiples fabricantes de inversores. Existe gran variedad demarcas que fabrican este tipo de dispositivos y que proporcionan una vía de accesopara establecer comunicación con un PC. De esta forma se obtendría un sistemamás heterogéneo y con amplias posibilidades comerciales.

Sea cual sea el nuevo requisito a incluir en este proyecto, siempre se partirá de la basede un sistema estable y que cumple con su cometido de manera e�ciente: la monitorizaciónde una planta solar fotovoltaica. Toda función adicional o mejora que se quiera incluir nosupondrá un desajuste en el sistema base.

Apéndice A

Acondicionamiento del entorno delsistema

En este apéndice se pretende hacer una breve descripción de cómo se preparó el entornodel sistema elaborado, de tal forma que todo encajase a la perfección.

A.1. Con�guración de PLC

Se tuvo que cargar en cada PLC del parque el software propietario de Omron, empresaque suministró los inversores y controladores lógicos programables. El software permite alos PLC interaccionar con inversores y PC haciendo uso de un protocolo de comunicaciónespecí�co ideado por la manufacturadora anteriormente mencionada.

A.2. Con�guración del servidor del parque solar

El PC debía de disponer de características especiales para soportar cambios bruscos detemperatura y largos periodos de actividad, replicación de información, amplia capacidadde almacenamiento, etcétera. Debido a todas estas características se decidió hacer uso deun servidor de altas prestaciones dotado de refrigeración líquida, varios discos duros degran tamaño y otra serie de detalles que generaban un colchón de seguridad con respectoa posibles fallos hardware que se pudieran producir.

Para obtener la máxima funcionalidad y rendimiento de la aplicación OmronMonitorse tuvo que con�gurar adecuadamente el PC en el que iba a ejecutarse:

Sistema operativo Linux, concretamente Ubuntu Server 8.04.

Aplicaciones instaladas Plataforma Mono: para poder compilar y ejecutar laaplicación sobre la plataforma .NET.

Cliente y servidor FTP: permiten el envío y recepción de �cheros entrepuntos remotos.

83

84 Acondicionamiento del entorno del sistema

Cliente y servidor SSH: para poder tener acceso desde el servidor a otropunto exterior y viceversa.

Servidor de correo Post�x: permite el envío de correos electrónicos.

Base de Datos MySQL: posibilita el almacenamiento persistente de infor-mación.

Conexión a Internet En el parque solar no existía posibilidad de establecer una conex-ión de banda ancha. Únicamente se dispone de una antena con conexión GPRS,que a pesar de no ser muy e�ciente es imprescindible dadas las características delsistema desarrollado, donde la comunicación a través de Internet es fundamental.

Automatización de tareas La aplicación que interactúa con los PLC podría ser con-siderada como un �demonio software�, ya que en esencia su ejecución debe ser con-tinuada , en función de determinados intervalos de tiempo, a lo largo de una franjahoraria concreta. Debido a que las horas de luz de sol varían en función de la épocadel año y teniendo en cuenta la precariedad de la conexión a Internet, se debe ajus-tar de forma precisa la franja horaria en la que se ejecutará la aplicación, así comoel intervalo de tiempo entre ejecución y ejecución, debido a la cantidad de informa-ción que el PC debe enviar a la aplicación web. Se hizo uso del cron de Linux paraprogramar la ejecución de la aplicación.

Conexión con PLC Únicamente es necesario conectar un cable de red desde el PC alrouter habilitado, para crear la red entre PC y PLC.

A.3. Con�guración del servidor externo

Las características del PC debían ser, debido a las exigencias del sistema, muy similaresal PC situado en el parque solar. Por esta razón se decidió hacer uso de un servidor conidénticas propiedades.

Para obtener la máxima funcionalidad y rendimiento de la aplicación de web se tuvoque con�gurar adecuadamente el PC en el que iba a ejecutarse:

Sistema operativo Linux, concretamente Ubuntu Server 8.04.

Aplicaciones instaladas :

Servidor web Apache: permite procesar y servir la aplicación web ante peti-ciones externas.

Módulo PHP: lenguaje de script utilizado en la página web para dotarla dedinamismo.

Extensión PHP para generar grá�cas

Cliente y servidor FTP: permiten el envío y recepción de �cheros entrepuntos remotos.

Cliente y servidor SSH: para poder tener acceso desde el servidor a otropunto exterior y viceversa.

A.3. CONFIGURACIÓN DEL SERVIDOR EXTERNO 85

Base de Datos MySQL: posibilita el almacenamiento persistente de infor-mación.

Conexión a Internet Al contrario que en el parque solar, se disponía de conexión debanda ancha.

86 Acondicionamiento del entorno del sistema

Apéndice B

Distribución del código

En el proyecto se pueden distinguir dos aplicaciones bien diferenciadas: la residenteen el servidor del parque solar y la situada en el servidor externo. Cada uno de estosdos módulos software se encarga de llevar a cabo funciones diferentes. Las herramientas ytecnologías informáticas utilizadas en/por cada una de ellas son también distintas. Debidoa las diferencias entre cada una de las aplicaciones, podemos dividir esta sección en dosapartados, uno de ellos estará destinado a recoger la distribución del código en la plantasolar, mientras que el otro se encargará de exponer la organización del código en el servidorexterno. Como apunte adicional cabe destacar que en la explicación de los dos puntos adesarrollar no se tendrán en cuenta los prototipos elaborados, sino que se describirá elsistema en relación al producto �nal.

B.1. Distribución del código en el parque solar

La aplicación nombrada como OmronMonitor necesita un entorno especí�co para fun-cionar correctamente.

Como se mencionó en secciones anteriores, el sistema operativo del PC es UbuntuServer 8.04. Dentro del árbol de �cheros de este sistema se tuvo que ubicar el software deforma precisa. Es innecesaria la existencia de múltiples usuarios con acceso al PC, siendopor tanto la �gura del administrador, identi�cado de forma estándar como root en elsistema operativo, la más importante. Por esta razón y la necesidad del software de teneracceso a múltiples recursos, con la pertinente modi�cación de privilegios que ello conlleva,se decidió ubicar el entorno de la aplicación en la ruta �/root/omron_monitor/�. Dentrodel directorio destacado existen cuatro carpetas cuyo nombre y funcionalidad pasaremosa mencionar a continuación:

historic_failures En este directorio se salvan los �cheros CSV con los fallos y anomalías.

historic_production Alberga los �cheros CSV que contienen información sobre la pro-ducción.

important_information Contiene un �chero CSV con el número de inversor y red a laque pertenece cada uno de ellos. Únicamente se encuentran los inversores activos en

87

88 Distribución del código

el parque solar, es decir, aquellos conectados y cuyo funcionamiento se presuponecorrecto, a pesar de que no se ajuste a la realidad.

log Almacena los �cheros que contienen el registro de actuación de la aplicación.

Debido a que la aplicación fue desarrollada bajo el IDE MonoDevelop' en el lenguajede programación C#, permitiendo así su ejecución sobre la plataforma .NET siendo con-scientes de la gran cantidad de bene�cios que aporta, consta de dos �cheros de especialimportancia para su correcto funcionamiento:

OmronMonitor.exe Ejecutable del software. Núcleo principal de la aplicación.

OmronMonitor.xml Fichero con información relevante acerca del software.

Teniendo en cuenta la gran cantidad de parámetros con�gurables de la aplicación, laposibilidad de realizar cambios futuros y la ine�ciencia que supondría compilar el softwarecada vez que se produjeran cambios en su con�guración, se ideó una estructura modularde �cheros en dos formatos: CSV y XML. Los �cheros utilizados y su funcionalidad sedescriben a continuación:

load_�le.csv Contiene la ruta de cada uno de los �cheros XML de con�guración y desu correspondiente XMLSchema.

omron-monitor_con�guration.xml En él reside la información básica para el correctofuncionamiento de OmronMonitor. A continuación vamos a citar y describir cadauno de los elementos XML por los que está formado:

solar-farm: Recoge información básica acerca del parque solar como: nombre, di-rección de correo electrónico y grupo empresarial poseedor de la planta.

properties: Contiene datos básicos acerca del funcionamiento de la aplicación:rutas de los directorios almacén del histórico de fallos, histórico de producción y log.

Internamente contiene dos elementos: total-operation-time-slot y production-balance-

time-slot. El primero contiene la franja horaria de operatividad total de la aplicación.Es en este intervalo de tiempo cuando el software efectúa la totalidad de sus activi-dades, incluyendo por ejemplo el envío de SMS y correos electrónicos teniendo encuenta la disponibilidad de los operarios del parque solar, restricciones del cliente yotros aspectos. El elemento production-balance-time-slot alberga la franja horaria enla que la aplicación evalúa la producción de todos los inversores entre sí para poderalertar sobre aquéllos que produzcan por debajo de la media. Este intervalo de tiempose determina en base a las horas de pleno rendimiento solar.

local-data-base: Reúne información acerca de la Base de Datos local como: nom-bre, servidor, identi�cador de usuario y contraseña.

external-data-base: Recoge los datos con respecto a la Base de Datos externausada por la aplicación web: nombre, servidor, identi�cador de usuario y contraseña.

ftp-server: Contiene información del servidor de FTP externo, a través del cualexporta los �cheros de interés para la aplicación web. Los datos que alberga son:servidor, identi�cador de usuario y contraseña, directorio raíz local a partir del cualse encuentran los carpetas que almacenan los �cheros que serán enviados y directorioraíz externo.

B.1. DISTRIBUCIÓN DEL CÓDIGO EN EL PARQUE SOLAR 89

smtp-server: Presenta el dominio del servidor encargado del envío de los correoselectrónicos.

sms-server: Reúne toda la información necesaria para el correcto funcionamientodel servidor de envío de SMS. Este módulo en concreto fue suministrado por elproveedor de SMS contratado por la empresa, es por ello que debido a la abstracciónrealizada sobre el mismo, basada únicamente en su utilización, no se explique endetalle toda la información que contiene. Algunos parámetros de interés son: cuenta,nombre y contraseña del cliente contratante, ruta, dominio, identi�cador de usuarioy contraseña del proxy, etcétera.

monitorization-computer: Recoge información acerca del nodo de monitorizacióndel sistema, es decir, sobre el PC encargado de monitorizar el parque solar. Única-mente contiene el número de nodo asignado al PC. Dicha información es de vitalimportancia para el envío de las tramas legibles por el protocolo de comunicación delos PLC.

plcs-alerts: Alberga información muy variada con respecto a los PLC. Como supropio nombre indica son alertas o información relevante acerca de tales dispositivos:número de fallos en la comunicación por cada repetición, repeticiones permitidas,puerto por defecto de comunicación, tiempo de espera para establecer contacto y elnúmero de repeticiones de espera.

inverters-kinds: Debido a que en ciertos parques existe heterogeneidad en cuantoa inversores se re�ere, y pensando en la escalabilidad del sistema, se añadió esteelemento. Incluye información acerca de los tipos de inversores del parque.

inverters-alerts: Al igual que ocurría en el elemento plcs-alerts contiene infor-mación relevante con respecto a los inversores: número de fallos en la comunicaciónpor cada repetición, repeticiones permitidas, el número de bytes y los canales queocupa cada inversor en las tramas del protocolo.

production-alerts: Contiene datos relevantes con respecto a la evaluación de laproducción de los inversores: número de fallos en la comunicación por cada repeti-ción, repeticiones permitidas y el porcentaje por debajo del cual se considera que uninversor produce de forma anómala.

ftp-alerts: Reúne información relevante con respecto a la exportación de datospor FTP: número de fallos en la comunicación por cada repetición y repeticionespermitidas.

external-data-base-alerts: Presenta la misma información que el elemento de-scrito anteriormente con respecto a la Base de Datos externa.

prices: Alberga el precio del KW/h de cada año para realizar los cálculos conrespecto a la ganancia de la producción.

omron-monitor_con�guration.xsd Este �chero contiene el XMLSchema que validael documento XML omron-monitor_con�guration.xml.

plcs.xml Almacena información de relevancia con respecto a los PLC:

plc-inverters-protocol: Contiene toda la información acerca del protocolo decomunicación con los PLC, el cual es de vital importancia para interaccionarcon tales dispositivos y poder monitorizar el parque solar.


plc: Cada uno de estos elementos contiene información con respecto a cadaPLC del parque: IP, número de nodo en la red y número de red lógica. Lared lógica se utiliza para incrementar la legibilidad de los usuarios del sistema,ya que independientemente de que existieran PLC conectadas con númerosde nodo no consecutivos , para el usuario sería transparente y lo vería comouna sucesión, no alarmándose pensando en posibles fallos del sistema. Cadaelemento plc contiene a su vez subelementos inverter. Estos últimos indican eltipo de inversor conectado al PLC, así como su número en la red de inversorespara poder establecer contacto con cada uno de ellos.

plcs.xsd En él reside el XMLSchema que valida el documento XML plcs.xml.

contacts.xml Reúne la información de aquéllas personas a las que irán destinados losSMS y correos electrónicos. Existen tres tipos de contactos: administradores, técni-cos y trabajadores de la producción. En función del grupo al que pertenezca cadapersona será informada de determinados sucesos que acontezcan en el parque solar,siendo muy estricto con respecto a la información que debe recibir cada individuo.Por poner un ejemplo, la información que debe recibir el administrador, estandosobre todo relacionada con posibles fallos o anomalías en la exportación FTP, Basede Datos externa, etcétera, no es la misma que la información que pueda necesitarun técnico, estando relacionada con fallos en PLC, inversores, etcétera.

contacts.xsd Este �chero contiene el XMLSchema que valida el documento XML con-tacts.xml.

La aplicación presenta dos modos de ejecución diferenciados. Por un lado el softwareactúa de forma �normal� realizando las labores rutinarias, sin embargo, existe una ramade ejecución que permite a OmronMonitor llevar a cabo la exportación de los �cheros conla información del día, actualizar la tabla de la Base de Datos local con la informacióntotal y otras funciones que únicamente tienen sentido si se realizan al �nalizar el ciclo deejecuciones �normales� de la aplicación a lo largo del día. Existen, por tanto, dos scriptsencargados de lanzar cada una de las ejecuciones descritas:

normally.sh Se encarga de lanzar la ejecución de la aplicación en la franja horaria pro-ductiva.

�nally.sh Lanza la ejecución de la aplicación en el modo denominado como backup, de-bido a las labores de salvaguarda que se llevan a cabo.

Por último cabe destacar la utilización del cron del sistema operativo para automatizartareas. Gracias a esta herramienta se estableció la franja horaria e intervalos de ejecuciónde los scripts normally.sh y �nally.sh.

B.2. Distribución del código en el servidor externo

La índole de la aplicación que reside en el servidor externo es esencialmente web.Debido al sistema operativo del PC, Ubuntu server 8.04, y la utilización del servidor webApache, por defecto se situó la aplicación en la ruta �/var/www/laherrera/�, siendo �La

B.2. DISTRIBUCIÓN DEL CÓDIGO EN EL SERVIDOR EXTERNO 91

Herrera� el nombre identi�cativo del parque solar. Dentro del directorio destacado existenseis carpetas cuyo nombre y funcionalidad pasaremos a mencionar a continuación:

charts Almacena las grá�cas generadas por la aplicación.

historic_failures En este directorio se recogen los �cheros CSV de fallos exportadospor OmronMonitor para ser utilizados en el software web.

historic_production Alberga los �cheros CSV que exporta OmronMonitor sobre laproducción.

important_information Contiene un �chero CSV con el número de inversor y red a laque pertenece cada uno de ellos. Únicamente se encuentran los inversores activos enel parque solar, es decir, aquéllos conectados y cuyo funcionamiento se presuponecorrecto, a pesar de que no se ajuste a la realidad.

resources Esta carpeta contiene la librería en PHP necesaria para generar las grá�casde forma fácil, e�ciente y vistosa.

style En ella residen las imágenes y el �chero CSS encargados de dotar de un aspectoelegante y amigable a la aplicación web.

El directorio �/var/www/laherrera� contiene a su vez todos los �cheros PHP yJavaScript, descritos en las secciones 3.5.3 y 3.8.3, que forman la estructura dinámicade la página web.

Apéndice C

Contenido del CD-ROM y licencia deuso

C.1. Licencia del documento y del código fuente delproyecto

Licencia del código fuente

El código fuente desarrollado en este proyecto se distribuye bajo la licencia públicaGNU/GPL1. La carpeta �/source_code� contiene el �chero license.txt que especi�ca alcompleto la licencia utilizada. A continuación se expone el preámbulo que aparece en lacabecera de todo �chero de código fuente y que indica el uso de la licencia GNU/GPL:

Copyright (C) 2008, 2009. Javier Vergara Igual

<[email protected]>

This program is free software; you can redistribute it and/or

modify it under the terms of the GNU General Public License as

published by the Free Software Foundation; either version 2 of the

License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

General Public License for more details.

You should have received a copy of the GNU General Public License

along with this program. If not, see <http://www.gnu.org/licenses/>.

1http://www.gnu.org/licenses/gpl.txt

93

http://www.gnu.org/licenses/gpl.txt

94 Contenido del CD-ROM y licencia de uso

Licencia de uso de este documento y del manual de con�guraciónde los PLC

Se otorga permiso para copiar y distribuir este documento completo y el manual encualquier medio siempre que se haga de forma literal y se mantenga esta nota.

C.2. Contenido del CD-ROM incluido en este docu-mento

En el CD-ROM anexo en el presente documento se incluye todo el código fuentedesarrollado en el proyecto, PDF de la memoria y el manual y vídeo de con�guraciónde los PLC. Para conocer en detalle el contenido del CD-ROM este incluye el �chero�readme.html�, en el que se explica en profundidad la estructura de �cheros y directorios.

Código fuente del PFC

El código fuente del proyecto se encuentra situado en el directorio �/source_code/�. Ensu interior podemos ver dos carpetas: �omron-monitor/� y �web/�. En ellas se encuentrael código fuente de la aplicación OmronMonitor y software web, respectivamente.

Memoria de este proyecto

Bajo el directorio �/report/� del CD-ROM se puede encontrar una versión imprimibledel presente documento en formato PDF.

Con�guración de los PLC

En la carpeta �/resources/� se encuentran el �chero plc_con�guration.pdf, en el que seexplica cómo se con�guran los controladores lógicos programables utilizados en el sistemaelaborado. Igualmente se incluye el �chero plc_con�guration.mpg, un vídeo demostrativode la con�guración.

Bibliografía

[1] Real Academia Española. Real Academia Española [en línea] [consulta: septiembre2008]. Disponible en: <http://www.rae.es>.

[2] Wikipedia. Energía solar [en línea] [consulta: septiembre 2008]. Disponible en:<http://es.wikipedia.org/wiki/Energía_solar>.

[3] Wikipedia. Energía [en línea] [consulta: septiembre 2008]. Disponible en: <http://en.wikipedia.org/wiki/Energy>.

[4] Wikipedia. Célula solar fotovoltaica [en línea] [consulta: septiembre 2008]. Disponibleen: <http://es.wikipedia.org/wiki/Célula_fotovoltaica>.

[5] Wikipedia. Panel solar fotovoltaico [en línea] [consulta: septiembre 2008]. Disponibleen: <http://es.wikipedia.org/wiki/Panel_fotovoltaico>.

[6] Wikipedia. Seguidor solar [en línea] [consulta: septiembre 2008]. Disponible en:<http://es.wikipedia.org/wiki/Seguidor_solar>.

[7] Wikipedia. Inversor solar fotovoltaico [en línea] [consulta: septiembre 2008].Disponible en: <http://es.wikipedia.org/wiki/Inversor>.

[8] Wikipedia. Controlador lógico programable (PLC) [en línea] [consulta: octubre2008]. Disponible en: <http://en.wikipedia.org/wiki/Programmable_logic_controller>.

[9] Wikipedia. Potencia [en línea] [consulta: septiembre 2008]. Disponible en: <http://en.wikipedia.org/wiki/Potencia>.

[10] Wikipedia. Potencia eléctrica [en línea] [consulta: septiembre 2008]. Disponible en:<http://en.wikipedia.org/wiki/Potencia_eléctrica>.

[11] Wikipedia. Energía solar fotovoltaica [en línea] [consulta: octubre 2008]. Disponibleen: <http://es.wikipedia.org/wiki/Central_fotovoltaica>.

[12] Aplicaciones de la energía solar fotovoltaica [en línea] [consulta: octubre2008]. Disponible en: <http://energiasolarfotovoltaica.blogspot.com/2006/01/energia-solar-fotovoltaica.html>.

[13] Wikipedia. Planta solar fotovoltaica [en línea] [consulta: octubre 2008]. Disponibleen: <http://es.wikipedia.org/wiki/Huerta_solar>.

[14] Wikipedia. Microsoft .NET [en línea] [consulta: diciembre 2008]. Disponible en:<http://es.wikipedia.org/wiki/.NET_de_Microsoft>.

95

http://www.rae.es

http://es.wikipedia.org/wiki/Energ�a_solar

http://en.wikipedia.org/wiki/Energy

http://en.wikipedia.org/wiki/Energy

http://es.wikipedia.org/wiki/C�lula_fotovoltaica

http://es.wikipedia.org/wiki/Panel_fotovoltaico

http://es.wikipedia.org/wiki/Seguidor_solar

http://es.wikipedia.org/wiki/Inversor

http://en.wikipedia.org/wiki/Programmable_logic_controller

http://en.wikipedia.org/wiki/Programmable_logic_controller

http://en.wikipedia.org/wiki/Potencia

http://en.wikipedia.org/wiki/Potencia

http://en.wikipedia.org/wiki/Potencia_el�ctrica

http://es.wikipedia.org/wiki/Central_fotovoltaica

http://energiasolarfotovoltaica.blogspot.com/2006/01/energia-solar-fotovoltaica.html

http://energiasolarfotovoltaica.blogspot.com/2006/01/energia-solar-fotovoltaica.html

http://es.wikipedia.org/wiki/Huerta_solar

http://es.wikipedia.org/wiki/.NET_de_Microsoft

96 BIBLIOGRAFÍA

[15] Wikipedia. Microsoft .NET Framework [en línea] [consulta: diciembre 2008].Disponible en: <http://en.wikipedia.org/wiki/.NET_Framework>.

[16] Mono Project [en línea] [consulta: diciembre 2008]. Disponible en: <http://www.mono-project.com/>.

[17] MonoDevelop [en línea] [consulta: diciembre 2008]. Disponible en: <http://monodevelop.com/>.

[18] Wikipedia. C# [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/C_Sharp>.

[19] Jay Hilyard and Stephen Teilhet. C# Cookbook. Cookbook. O'REILLY, 2nd edition,January 2006.

[20] Wikipedia. XML [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/XML>.

[21] Óscar González. XML. Guía práctica para usuarios. MULTIMEDIA. ANAYA, 2005edition.

[22] Wikipedia. PHP [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/.php>.

[23] David Sklar and Adam Trachtenberg. PHP Cookbook. Cookbook. O'REILLY, 2ndedition, August 2006.

[24] Wikipedia. HTML [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/Código_HTML>.

[25] Wikipedia. JavaScript [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/JavaScript>.

[26] José Manuel Alarcón. JavaScript. Guía práctica para usuarios. MULTIMEDIA.ANAYA, 2004 edition.

[27] Wikipedia. CSV [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/CSV>.

[28] Wikipedia. FTP [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/FTP>.

[29] Wikipedia. MySQL [en línea] [consulta: diciembre 2008]. Disponible en: <http://es.wikipedia.org/wiki/MySQL>.

http://en.wikipedia.org/wiki/.NET_Framework

http://www.mono-project.com/

http://www.mono-project.com/

http://monodevelop.com/

http://monodevelop.com/

http://es.wikipedia.org/wiki/C_Sharp

http://es.wikipedia.org/wiki/C_Sharp

http://es.wikipedia.org/wiki/XML

http://es.wikipedia.org/wiki/XML

http://es.wikipedia.org/wiki/.php

http://es.wikipedia.org/wiki/.php

http://es.wikipedia.org/wiki/C�digo_HTML

http://es.wikipedia.org/wiki/C�digo_HTML

http://es.wikipedia.org/wiki/JavaScript

http://es.wikipedia.org/wiki/JavaScript

http://es.wikipedia.org/wiki/CSV

http://es.wikipedia.org/wiki/CSV

http://es.wikipedia.org/wiki/FTP

http://es.wikipedia.org/wiki/FTP

http://es.wikipedia.org/wiki/MySQL

http://es.wikipedia.org/wiki/MySQL

desarrollo de un sistema informÁtico de monitorizaciÓn de

Documents