Marco de trabajo para la generación de software para la gestión de sistemas de energía solar

Departamento de Lenguajes y Ciencias de la Computaci´ on Tesis Doctoral MARCO DE TRABAJO PARA LA GENERACI ´ ON DE SOFTWARE PARA LA GESTI ´ ON DE SISTEMAS DE ENERG´ IA SOLAR Autor´ ıa: Ildefonso Mart´ınez Marchena Direcci´ on: Llanos Mora L´opez Mayo, 2015 AUTOR: Ildefonso Martínez Marchena EDITA: Publicaciones y Divulgación Científica. Universidad de Málaga Esta obra está sujeta a una licencia Creative Commons: Reconocimiento - No comercial - SinObraDerivada (cc-by-nc-nd): Http://creativecommons.org/licences/by-nc-nd/3.0/es Cualquier parte de esta obra se puede reproducir sin autorización pero con el reconocimiento y atribución de los autores. No se puede hacer uso comercial de la obra y no se puede alterar, transformar o hacer obras derivadas. Esta Tesis Doctoral está depositada en el Repositorio Institucional de la Universidad de Málaga (RIUMA): riuma.uma.es La Dra. Llanos Mora L´opez, Titular de Universidad en el Departamento de Lenguajes y Ciencias de la Computaci´on de la Universidad de M´alaga Certifica Que Ildefonso Mart´ınez Marchena, Ingeniero en Inform´atica, ha realizado bajo su direcci´on la tesis doctoral titulada MARCO DE TRABAJO PARA LA GENERACI ´ ON DE SOFTWARE PARA LA GESTI ´ ON DE SISTEMAS DE ENERG´ IA SOLAR, que se recoge en la presente memoria, cumpliendo todos los requisitos legales para optar al grado de Doctor, por lo que autoriza su lectura y defensa p´ublica. Y para que as´ı conste y tenga los efectos oportunos, firmo este certificado en M´alaga, a 10 de mayo de 2015 Dra. Llanos Mora L´opez A Laura y Encarni Agradecimientos Durante el desarrollo de este trabajo he tenido la gran suerte de estar rodeado de grandes personas que, gracias a su apoyo, sacrificio, esfuerzo y ayuda han permitido que esta tesis vea la luz. Me gustar´ıa que estas primeras l´ıneas fuesen de un agradecimiento especial a Encarni, mi mujer, por su continuo ´animo y apoyo haci´endose cargo de muchas de mis responsabilidades personales para poder yo dedicarle tiempo al desarrollo de este trabajo. Sin ella esta tesis no ser´ıa posible ya que siempre ha estado ah´ı para ofrecerme su mano a la que agarrarme en los momentos en los que he necesitado levantarme. A mi hija Laura, que espero alg´un d´ıa pueda devolverle todas las horas que no le he podido dedicar, por sus continuas visitas a los pies de mi escritorio buscando juego cada vez que ve´ıa que pasaba varias horas sin salir del despacho. A mis padres, de los cuales he aprendido que el esfuerzo y la dedicaci´on son las principales obligaciones para con su trabajo que un hombre debe tener y poder llegar a sentirse orgulloso de si mismo. Y a mi directora de tesis, Llanos Mora y a Mariano Sidrach, por su paciencia, total disponibilidad y sugerencias en todas las cuestiones t´ecnicas y te´oricas de este trabajo, por guiarme con su gran conocimiento y experiencia, y de cuyas facetas de cient´ıficos y brillantes investigadores no hacen m´as que impresionarme d´ıa a d´ıa, pero m´as a´un, si cabe, por sus valores y calidad humana donde han sabido demostrar y dejar huella en todo lo que han hecho a lo largo de sus carreras personales y profesionales. A todos, gracias. Parte de este trabajo de investigaci´on ha sido financiado por la Junta de Andaluc´ıa (proyecto No. TICP–6441) Resumen El auge que est´an alcanzando los sectores relacionados con la gesti´on de sistemas energ´eticos y en especial, los relacionados con las energ´ıas renovables, est´an propiciando la necesidad de disponer de mecanismos para la monitorizaci´on y la vigilancia energ´etica de los mismos. El objetivo de esta tesis es la de proponer y desarrollar un marco de trabajo, integrado con una metodolog´ıa y procedimientos, para generar programas para la monitorizaci´on y supervisi´on de sistemas de energ´ıa solar. Para el desarrollo de este marco de trabajo se ha propuesto una arquitectura software basada en capas, cada una de las cuales incluye componentes desarrollados a partir de interfaces especializados que ofrecen funcionalidades para la definici´on, modelizado, comunicaci´on, almacenamiento, supervisi´on, evaluaci´on y predicci´on del funcionamiento de sistemas energ´eticos. Esta arquitectura permite describir las partes de un sistema energ´etico y la interacci´on entre ellas, as´ı como los patrones que se utilizan para su composici´on y las restricciones de estos patrones. Otra aportaci´on de esta tesis es la definici´on de los est´andares utilizados para el establecimiento de conexiones y coordinaci´on entre los componentes de cada capa. La propuesta que se hace de utilizar un marco de trabajo para desarrollar software para la gesti´on de sistemas energ´eticos facilita la construcci´on de nuevo software de gesti´on, evita los detalles de bajo nivel y minimiza los tiempos de desarrollo. El marco de trabajo puede extenderse y seguir un esquema desacoplado al no existir relaciones directas entre clases a favor de las relaciones establecidas entre interfaces. Mecanismos como la inyecci´on de dependencias o la implementaci´on por delegaci´on de interfaces hacen posible que este marco de trabajo desarrollado sea altamente desacoplado y f´acilmente extensible y configurable. Otra importante aportaci´on de la tesis es la propuesta de un sistema de comunicaciones que permite mecanismos de intercambio de informaci´on utilizando est´andares abiertos. Uno de los grandes problemas en el desarrollo de sistemas de monitorizaci´on y supervisi´on de sistemas energ´eticos es la diversidad de dispositivos y protocolos existentes. Para resolver este problema, el sistema de comunicaciones propuesto est´a totalmente separado de las dem´as funcionalidades y se basa en la utilizaci´on del est´andar OPC. Esto permite disponer de un mecanismo ´unico, sencillo y eficiente de comunicaci´on con todos los dispositivos con los que se debe intercambiar informaci´on que forman parte de las instalaciones. El marco de trabajo presentado proporciona adem´as, xvi ´ INDICE DE FIGURAS 4.19. Implementaci´on de un servidor OPC para inversores con protocolo basadoenSNMP ............................... 52 4.20. Formulario de configuraci´on de los par´ametros SNMP para servidor OPC 53 4.21. Jerarqu´ıa de implementaci´on . . . . . . . . . . . . . . . . . . . . . . . . 54 4.22. Contenedor de Arduinos . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.23. Jerarqu´ıa de protocolos para cada Arduino . . . . . . . . . . . . . . . . 56 4.24. Esquema general del servidor OPC para Arduino . . . . . . . . . . . . 56 4.25. OPC Server para Arduino . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.26. OPC Server para Arduino registrado en el sistema operativo . . . . . . 57 4.27. Cliente OPC utilizando un servidor OPC . . . . . . . . . . . . . . . . . 58 4.28. Configuraci´on del OPC Server para Arduino Serie . . . . . . . . . . . . 58 4.29. Configuraci´on del OPC Server para Arduino Ethernet . . . . . . . . . . 58 4.30. Configuraci´on del OPC Server para Arduino Y´ UN............ 59 4.31. Utilizaci´on del servidor OPC para Arduino y el SCADA Wincc . . . . . 59 4.32. Problema de la interconexi´on entre multitud de dispositivos para acceder a informaci´on almacenada . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.33. Utilizaci´on de OPC-HDA para unificar el acceso a la informaci´on almacenada.................................... 61 4.34. Modelo de objeto OPC-HDA . . . . . . . . . . . . . . . . . . . . . . . . 61 4.35. Diagrama de secuencia entre un sistema de monitorizaci´on y un dispositivo a trav´es de un cliente OPC-HDA y un servidor OPC-HDA . . . . 62 4.36. Implementaci´on de la clase gen´erica para servidores OPC-HDA . . . . . 63 4.37. Implementaci´on de la clase gen´erica para el interfaz de usuario de servidoresOPC-HDA .............................. 64 4.38. Implementaci´on de la clase gen´erica para servidores OPC-HDA configurables .................................... 65 4.39. Implementaci´on de la clase gen´erica para servidores OPC-HDA para inversores con protocolo Modbus. . . . . . . . . . . . . . . . . . . . . . 66 4.40. Implementaci´on de las clases particulares de servidores OPC-HDA para inversores con protocolo Modbus . . . . . . . . . . . . . . . . . . . . . 67 4.41. Implementaci´on de la interfaz de conexi´on utilizando IP a trav´es de GPRS 67 4.42. Implementaci´on del servidor OPC-HDA para WebBox . . . . . . . . . . 68 4.43. Implementaci´on del servidor OPC descarga de ficheros de los inversores 69 4.44. Implementaci´on del servidor OPC para inversores con servidor FTP. . . 70 4.45. Implementaci´on de la clase base para la descarga de ficheros remotos de dispositivos.................................. 71 4.46. Clase que implementa el protocolo propietario. . . . . . . . . . . . . . . 72 4.47. Implentaci´on de servidor OPC-HDA para un inversor comercial con protocolo propietario, versi´on 1.1 . . . . . . . . . . . . . . . . . . . . . . . 72 4.48. Implentaci´on de servidor OPC-HDA para un inversor comercial con protocolo propietario, versi´on 1.2 . . . . . . . . . . . . . . . . . . . . . . . 73 5.1. Esquema de los elementos que componen una instalaci´on . . . . . . . . 76 5.2. Clases para el modelizado de usuarios . . . . . . . . . . . . . . . . . . . 79 5.3. Clases para el modelizado de un usuario . . . . . . . . . . . . . . . . . 79 5.4. Modelizado de una instalaci´on gen´erica basada en interfaces . . . . . . 80 ´ INDICE DE FIGURAS xvii 5.5. Modelo de una instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.6. Creaci´on de nuevos tipos de instalaciones haciendo uso de la herencia de interfaces .................................. 82 5.7. Grupos de instalaciones y relaci´on con los usuarios del marco de trabajo 82 5.8. Modelo de un grupo de dispositivos . . . . . . . . . . . . . . . . . . . . 83 5.9. Asociaci´on de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.10. Modelado de un dispositivo o sistema . . . . . . . . . . . . . . . . . . . 85 5.11. Modelado de un dispositivo tipo invesor . . . . . . . . . . . . . . . . . 85 5.12. Jerarqu´ıa de modelizado medidas . . . . . . . . . . . . . . . . . . . . . 86 5.13. Modelado de medidas constantes . . . . . . . . . . . . . . . . . . . . . 87 5.14. Sistema de adquisici´on de tiempos de medidas . . . . . . . . . . . . . . 87 5.15. Modelado de medidas diarias . . . . . . . . . . . . . . . . . . . . . . . . 88 5.16. Modelado de alarmas y eventos . . . . . . . . . . . . . . . . . . . . . . 88 5.17. Modelado de medidas globales . . . . . . . . . . . . . . . . . . . . . . . 88 5.18. Clase para el modelizado de medidas . . . . . . . . . . . . . . . . . . . 89 5.19. Representaci´on real de un canal f´ısico . . . . . . . . . . . . . . . . . . . 89 5.20. Modelizado de medidas calculadas . . . . . . . . . . . . . . . . . . . . . 91 6.1. Modelo de almacenamiento en base de datos de usuarios . . . . . . . . 95 6.2. Interfaz para la administraci´on de usuarios . . . . . . . . . . . . . . . . 96 6.4. Implementaci´on de grupos de instalaciones . . . . . . . . . . . . . . . . 96 6.3. Modelo de almacenamiento en base de datos de instalaciones . . . . . . 97 6.5. Agrupaci´on de instalaciones . . . . . . . . . . . . . . . . . . . . . . . . 97 6.6. Modelo de almacenamiento en base de datos del modelizado de dispositivos 98 6.7. Librer´ıa de dispositivos modelizados . . . . . . . . . . . . . . . . . . . . 99 6.8. Almacenamiento de datos de diferentes tipos medidas . . . . . . . . . . 101 6.9. Algoritmo para la sincronizaci´on con las plantas . . . . . . . . . . . . . 104 6.10. Algoritmo para la sincronizaci´on de una instalaci´on . . . . . . . . . . . 105 6.11. Algoritmo para la sincronizaci´on de una media . . . . . . . . . . . . . . 106 6.12. Algoritmo para la sincronizaci´on de una media en un d´ıa . . . . . . . . 107 7.1. Selecci´on gen´erica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.2. Interfaz sujeto observable ISubject . . . . . . . . . . . . . . . . . . . . 111 7.3. InterfazIObserver.............................. 111 7.4. Modelado de comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.5. Modelado de categor´ıas de comandos . . . . . . . . . . . . . . . . . . . 113 7.6. Sistema de comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.7. Sistema de comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.8. Sistema din´amico de propiedades . . . . . . . . . . . . . . . . . . . . . 115 7.9. interfaz para la implementaci´on del sistema de configuraciones din´amico 116 7.10. Configuraci´on del puerto de comunicaciones serie . . . . . . . . . . . . 117 7.11. Configuraci´on del puerto de comunicaciones serie . . . . . . . . . . . . 117 7.12. Formulario para la configuraci´on del puerto de comunicaciones serie . . 118 7.13. Formulario para la configuraci´on del model telef´onico . . . . . . . . . . 118 7.14. interfaz para contenedor de formularios de configuraci´on . . . . . . . . 119 7.15. Formulario contenedor de formulario de configuraci´on . . . . . . . . . . 119 xviii ´ INDICE DE FIGURAS 7.16. Formulario contenedor de formulario de configuraci´on del puerto serie e Internet ................................... 120 7.17. Inyecci´on de par´ametros de configuraci´on en tiempo de ejecuci´on . . . . 120 8.1. Esquema de una planta de energ´ıa solar fotovoltaica . . . . . . . . . . . 126 8.2. Diagrama de flujo para la evaluaci´on de una planta de energ´ıa solar fotovoltaica.................................. 131 9.1. Unificaci´on de protocolos y dispositivos en un ´unico sistema de gesti´on y publicaci´on multicanal de la informaci´on . . . . . . . . . . . . . . . . 147 9.2. Estructura l´ogica de la arquitectura software propuesta para sistemas energ´eticos.................................. 148 9.3. Infraestructura de comunicaciones para la gesti´on de varias instalaciones 149 9.4. Inclusi´on del dominio fv basado en dispositivo virtual . . . . . . . . . . 150 9.5. Servidor OPC-HDA con la l´ogica de gesti´on del dominio fotovoltaico . . 151 9.6. Diagrama de estados de publicaci´on de canales del servidor HDA de base dedatos ................................... 152 9.7. C´alculo de canales fotovoltaicos para una instalaci´on determinada . . . 153 9.8. Inclusi´on de modelos de predicci´on y evaluaci´on . . . . . . . . . . . . . 154 10.1. Vista general de la gesti´on de instalaciones energ´eticas . . . . . . . . . 159 10.2. Formulario de alta de una instalaci´on . . . . . . . . . . . . . . . . . . . 160 10.3. Agrupaci´on de instalaciones en grupos . . . . . . . . . . . . . . . . . . 160 10.4. Librer´ıa de dispositivos predefinidos . . . . . . . . . . . . . . . . . . . . 161 10.5. Personalizaci´on de medidas y dispositivos . . . . . . . . . . . . . . . . . 161 10.6. Formulario de alta de dispositivos . . . . . . . . . . . . . . . . . . . . . 162 10.7. ´ Arbol con los dispositivos conectados a un dispositivo y componente para la visualizaci´on de los sistemas conectados a un dispositivo . . . . 162 10.8. Gesti´on de instalaciones y dispositivos . . . . . . . . . . . . . . . . . . 163 10.9. Componente para la edici´on de un item OPC . . . . . . . . . . . . . . . 164 10.10.Librer´ıa de servidores OPC disponibles en el sistema . . . . . . . . . . 165 10.11.Configuraci´on de servidores OPC . . . . . . . . . . . . . . . . . . . . . 166 10.12.Roles y permisos sobre el marco de trabajo . . . . . . . . . . . . . . . . 166 10.13.Sincronizador de instalaciones . . . . . . . . . . . . . . . . . . . . . . . 167 10.14.Visualizaci´on de canales en la aplicaci´on . . . . . . . . . . . . . . . . . 168 10.15.Visualizaci´on de canales en la web . . . . . . . . . . . . . . . . . . . . . 168 10.16.Esquema f´ısico del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 169 10.17.Componentes incluidos en el programa de gesti´on y su interrelaci´on con los subsistemas de las plantas fotovoltaicas . . . . . . . . . . . . . . . . 171 10.18.Wpvs Yf,day para todas las instalaciones analizadas . . . . . . . . . . . 172 10.19.Rendimiento final diario para cinco instalaciones . . . . . . . . . . . . . 173 10.20.Valores registrados de PCA y de irradiancia para un d´ıa con rendimiento finaldiariobajo............................... 173 10.21.PCA (medidas) versus P∗ CA (estimadas) .................. 174 xix ´ Indice de Tablas 4.1. Elementos que conforman el interfaz que implementa el modelo de objeto OPC-HDA.................................. 62 5.2. Identificadores de los OPC Items (n: nombre, sis: sistema, med: medida, ins: instalaci´on, grp: grupo, sec: secci´on, dis: dispositivo) .......... 91 8.1. Descripci´on de las caracter´ısticas de las instalaciones . . . . . . . . . . 141 8.2. Intervalos utilizados y variables significativas para cada intervalo . . . . 142 8.3. Error medio de predicci´on del modelo propuesto . . . . . . . . . . . . . 143 “Hay tres maneras de adquirir sabidur´ıa: primero, por la reflexi´on, que es la m´as noble; segundo, por imitaci´on, que es la m´as sencilla; y tercero, por la experiencia, que es la m´as amarga” – Confucio 1 Introducci´on y objetivos 1.1. Introducci´on El importante desarrollo que est´an alcanzando las tecnolog´ıas que permiten el intercambio de datos e informaci´on a trav´es de la red est´a facilitando el desarrollo de programas y servicios en muchos ´ambitos distintos, ya que se posibilita un acceso a la informaci´on desde cualquier lugar y ya actualmente, desde diversos y distintos dispositivos. Uno de los sectores en los que se est´a haciendo un uso importante de estas tecnolog´ıas es el relacionado con la gesti´on y supervisi´on de sistemas energ´eticos y m´as concretamente en los sistemas de energ´ıa solar, y entre estos, los de energ´ıa solar fotovoltaica. El n´umero de instalaciones de energ´ıa solar de este tipo ha experimentado un importante crecimiento en los ´ultimos a˜nos debido a muchos factores, entre ellos: a la necesidad de utilizar fuentes energ´eticas que contribuyan a la reducci´on de las emisiones de carbono, al establecimiento de pol´ıticas de apoyo para la implantaci´on de este tipo de sistemas, a la mejora de la eficiencia de estos sistemas y a la importante reducci´on en el precio de todos los componentes que los integran. De acuerdo con los datos publicados en el ”Global Market Outlook for Photovoltaics 2014-2018”, [Ass14] en el a˜no 2013 se instalaron m´as de 38.4GW de sistemas fotovoltaicos. Conforme aumenta el n´umero de instalaciones de energ´ıa solar, surge cada vez m´as, la necesidad de disponer de soluciones que permitan una gesti´on de las mismas de cara a poder lograr un mejor funcionamiento de sus componentes. Entre las tareas a las que deber´ıa dar respuesta este software se pueden citar: modelizado de la instalaci´on 1 21. Introducci´on y objetivos energ´etica recogiendo toda la configuraci´on f´ısica y l´ogica de la misma, recogida de datos de los dispositivos que la conforman (monitorizaci´on), an´alisis y evaluaci´on del funcionamiento de cada instalaci´on (incluidos los diferentes subsistemas), generaci´on de informes de funcionamiento y producci´on, publicaci´on de los datos orientados a multicanales y multidispositivos, gesti´on de alarmas y eventos y, en el caso de determinado tipos de sistemas conectados a red, previsi´on de la energ´ıa que la planta producir´a el d´ıa siguiente, en una escala horaria. En el caso de sistemas energ´eticos convencionales todas estas tareas se viene realizando mediante los sistemas conocidos como sistemas SCADA (Supervisory Control and Data Acquisition). El tama˜no de estos sistemas energ´eticos justifica la utilizaci´on de este tipo de aplicaciones, ya que el coste asociado a la gesti´on y mantenimiento es totalmente asumible dentro de los costes del sistema en general. En los ´ultimos a˜nos, est´an surgiendo sin embargo, gran cantidad de instalaciones energ´eticas basadas en la utilizaci´on de fuentes de energ´ıas renovables, cuyo tama˜no y coste no justifica la utilizaci´on de SCADAS por lo que la existencia de alternativas m´as apropiadas para este tipo de sistemas son altamente deseables. En general, estos sistemas energ´eticos, especialmente los de peque˜na y mediana potencia, se ubican en emplazamientos dispersos, y no suelen disponer de sistemas propios de monitorizaci´on, ya que no hay personal en las plantas que pueda hacer esa vigilancia in situ. Sin embargo, poder disponer de informaci´on del funcionamiento de los sistemas energ´eticos es muy importante para poder intervenir en caso de que se detecten problemas o fallos, tal y como se apunta en [SWKL97]. Tradicionalmente, para monitorizar sistemas de energ´eticos de peque˜no y medio tama˜no, los fabricantes de los dispositivos que forman parte de la instalaci´on, suministran su propio software con las funcionalidades m´ınimas para su mantenimiento b´asico. Estos programas suelen estar instalados en las propias plantas por lo que se hace necesaria una supervisi´on personal y desde dichas ubicaciones. Con este planteamiento tradicional, han aparecido en los ´ultimos a˜nos varios problemas, a saber: 1. Utilizaci´on de distintos programas para recuperar la informaci´on de las plantas, dependiendo, en general, del software desarrollado por los fabricantes de alguno de los subsistemas (normalmente de los inversores). 2. Necesidad de contar con especialistas en el sistema que se est´a monitorizando para poder hacer una evaluaci´on correcta del funcionamiento del mismo. 3. Imposibilidad de integrar la informaci´on de distintas plantas en una sola herramienta o incluso, en algunos casos, no poder integrar la informaci´on proveniente de todos los dispositivos del sistema al tener que utilizar un software diferente para cada uno. 4. Necesidad de modificar los programas de monitorizaci´on cuando se modifica alg´un 1.1. Introducci´on 3 componente de la instalaci´on. 5. A veces, la necesidad de desplazarse a cada instalaci´on para tener acceso a la informaci´on. 6. Los fabricantes de los subsistemas que incluyen la toma de datos no suelen facilitar controladores eficientes de comunicaci´on. 7. Cada fabricante desarrolla su propio protocolo de intercambio de informaci´on. Por otra parte, esta supervisi´on, para que sea ´util, debe hacerse por parte de t´ecnicos especializados en este tipo de sistemas, con el objeto de poder detectar y diagnosticar problemas de funcionamiento de las plantas ya que el prop´osito de este tipo de sistemas suele ser exclusivamente la recogida de datos y no la evaluaci´on del funcionamiento. Al depender fuertemente el funcionamiento de una instalaci´on de caracter´ısticas propias de la misma, se hace dif´ıcil incorporar en los programas de monitorizaci´on, modelos de evaluaci´on que sean generales y v´alidos para todos los sistemas. De manera general, se puede afirmar que los programas desarrollados para la gesti´on de sistemas energ´eticos deben tener en cuenta la complejidad y caracter´ısticas de los mismos, entre otras funcionalidades deben ser capaces de dar respuesta a las cuestiones que se recogen en el trabajo de [WKS+01] y que para el caso de sistemas energ´eticos se pueden sintetizar de la siguiente forma: 1. Adaptabilidad: capacidad de reconfigurar f´acilmente las aplicaciones cuando se cambie la configuraci´on del sistema energ´etico. Esto es muy importante que ya en los sistemas energ´eticos, durante su periodo de funcionamiento, pueden producirse cambios en los dispositivos que los integran, como pueden ser sustituci´on de alg´un componente incluso de otra marca o fabricante. 2. Extensibilidad: posibilidad de incorporar nuevos algoritmos y modelos de gesti´on sin necesidad de volver a dise˜nar los componentes que hay ya en el sistema. 3. Interoperabilidad: posibilidad de operar con distintas plataformas hardware y, especialmente, distintos protocolos de red. Es tambi´en importante que por las caracter´ısticas del emplazamiento disperso de los sistemas energ´eticos (especialmente los de baja potencia) est´e prevista la utilizaci´on de redes inal´ambricas o diferente tipo de sistema de comunicaci´on en cada caso. 4. Arquitectura abierta: se debe permitir la configuraci´on y el intercambio de componentes, es decir se deben desarrollar arquitecturas software que sean flexibles y soporten herramientas y algoritmos de distintas fuentes y dominios. 5. Arquitectura moderna: se espera de los sistemas software que proporcionen el mayor n´umero de funcionalidades y adem´as hagan uso de la tecnolog´ıa cada vez m´as avanzada en este ´ambito. 41. Introducci´on y objetivos Adem´as de estos requisitos generales, el dominio de la aplicaci´on que se propone en esta tesis hace que se pueda dar respuesta tambi´en a estos requisitos espec´ıficos: Acceso remoto a la informaci´on almacenada en los distintos dispositivos de las plantas para poder evaluar el funcionamiento de las mismas. Es decir, posibilidad de conectarse a los dispositivos de la instalaci´on para obtener los datos registrados. Esta conexi´on deber´ıa poder hacerse utilizando distintos protocolos y sistemas. Integraci´on de dispositivos de diferentes marcas y modelos y de distintos fabricantes. Capacidad para almacenar todos los datos de la planta, no solo los registrados sino tambi´en aquellos par´ametros calculados y toda la informaci´on general de la planta y sus dispositivos. Posibilidad de procesar la informaci´on para evaluar el funcionamiento de la planta y para detectar posibles problemas utilizando diferentes modelos en funci´on de la configuraci´on de cada planta. Posibilidad de ejecutar tareas programadas para automatizar las tareas de recuperaci´on de la informaci´on, an´alisis y evaluaci´on. Facilidades para disponer de la informaci´on general y de la informaci´on cr´ıtica como alarmas y eventos a trav´es de distintos medios. Incorporaci´on de mecanismos que permitan env´ıos de alertas al gestor o propietarios de la plantas. Informaci´on accesible desde distintos canales a diferentes servicios y utilizando diversos protocolos. Unos de los problemas m´as frecuentes e importantes en el dominio de la gesti´on energ´etica, es que las herramientas cl´asicas desarrolladas para la monitorizaci´on y control de este tipo de sistemas no suelen permitir la conectividad de diferentes sistemas y aplicaciones por la ausencia de interfaces est´andares de intercambio de informaci´on. Esto es as´ı, especialmente, en las aplicaciones que se han desarrollado para sistemas energ´eticos de peque˜na y media potencia. Sin embargo, dado el importante incremento que este tipo de sistemas est´a experimentando en los ´ultimos a˜nos, y la variedad de soluciones que han aparecido, se constata que ser´ıa muy conveniente poder contar con componentes est´andar que permitieran la conectividad de distintos sistemas de manera m´as sencilla. Los sistemas tipo SCADA (Supervisory Control and Data Acquisition) que se utilizan en la monitorizaci´on y gesti´on de plantas de energ´ıa de peque˜na y, especialmente, media potencia est´an normalmente basados en desarrollo muy gen´ericos y poco orientados al dominio de la energ´ıa fotovoltaica. Adem´as, este tipo de soluciones son siempre 1.1. Introducci´on 5 propietarias y no permiten conectividad con otro tipo de soluciones, por lo que cuando se opta por una de estos paquetes, es dif´ıcil, si no imposible, cambiar a otras soluciones. As´ı, cuando son necesarios cambios en los sistemas desarrollados, es necesario recurrir al mismo tipo de sistema con el que se desarroll´o el programa. Esto implica otra serie de problemas adicionales, como son: Es necesario utilizar programas diferentes para recuperar la informaci´on de estos sistemas, dependiendo del software desarrollado por cada fabricante. Normalmente, no es sencillo conectar las aplicaciones y datos de sistemas diferentes. Es decir, es dif´ıcil integrar la informaci´on de distintas instalaciones. El software de supervisi´on debe actualizarse si se modifica alguno de los subsistemas de la planta. A veces, la informaci´on solo es accesible de manera local, especialmente para peque˜nas instalaciones. Cada fabricante desarrolla su propio protocolo de comunicaciones, en muchos casos propietarios, no estandarizados y desconocidos, y a veces, los controladores de comunicaci´on suministrados por los fabricantes no son eficientes. La falta de est´andares en el desarrollo de las interfaces de nivel de aplicaci´on hace que sea dif´ıcil interconectar las diferentes aplicaciones desarrolladas por diferentes fabricantes. Esto no es un problema espec´ıfico de los sistemas de monitorizaci´on y control. La necesidad de utilizar est´andares en el proceso de desarrollo de software ya ha sido considerada en muchos otros ´ambitos de los sistemas industriales de control y monitorizaci´on, y se ha puesto de manifiesto desde hace tiempo, [Ple94], [God97], [DO03]. En el caso de los sistemas de supervisi´on y gesti´on para instalaciones energ´eticas, se pueden destacar las siguientes soluciones propuestas: Una de las primeras propuestas fue hecha por [BM98]. Presentan un sistema de adquisici´on de datos para la monitorizaci´on del funcionamiento de sistemas fotovoltaicos. Proponen la utilizaci´on de una arquitectura basada en el microprocesador MC68B09. La adquisici´on de los datos se controla a partir de un temporizador programable. El microsistema permite el tratamiento de los datos en tiempo real. Los datos se transfieren al ordenador a trav´es de un puerto serie bidireccional usando el protocolo RS232C. El sistema propuesto es responsable de la adquisici´on secuencial y el tratamiento preliminar de los datos y de la transferencia diaria de los mismos al ordenador central. El sistema tiene algunas limitaciones relacionadas con la capacidad de memoria. Para cada instalaci´on es necesario instalar un microsistema y un m´odem para la transferencia de datos al ordenador central. 12 2. Marcos de trabajo, Arquitectura Software y Metodolog´ıas que en un marco de trabajo el control del flujo est´a en el propio c´odigo, que realiza llamadas al c´odigo de la aplicaci´on, mecanismo com´unmente denominado inversi´on del control. Los marcos de trabajo son el servicio mientras que en una librer´ıa de clases los servicios se obtienen heredando funciones de las librer´ıas de clases. En un marco de trabajo hay una mayor abstracci´on de los servicios ya que se oculta su complejidad y se automatizan las caracter´ısticas est´andares y se ofrece mecanismo de excepciones. En una librer´ıa de clases el usuario ha de determinar qu´e m´etodos ofrece la librer´ıa y en qu´e orden deben ser invocados. En un marco de trabajo, una vez construido, la cantidad de c´odigo a implementar suele ser menor que en una librer´ıa de clases. El coste de mantenimiento es menor en un marco de trabajo. En un marco de trabajo se reduce la complejidad, ya que el usuario tiene que escribir muy poco c´odigo mientras que en una librer´ıa de clases el usuario tiene que crear nuevas clases para cada aplicaci´on que se desarrolle adem´as de desarrollar la propia aplicaci´on. Los marcos de trabajo, en general, incluyen: Soporte para el desarrollo de programas. Bibliotecas de componentes. Posibilidad de incluir scripting (Lenguaje de scripting). Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de programas. Una gran ventaja de abordar la construcci´on del software mediante marcos de trabajo es que estos permiten: Facilitar el desarrollo de software ya que proporcionan c´odigo que no se tendr´a que reescribir. Evitar los detalles de bajo nivel, permitiendo concentrar m´as esfuerzo y tiempo en identificar los requerimientos de software. Minimizar los tiempos de desarrollo. Construir una arquitectura consistente entre aplicaciones. 2.3. Metodolog´ıas ´agiles para el desarrollo del marco de trabajo 13 Algunas de las desventajas que se pueden citar cuando se utilizan marcos de trabajo es que limitan la flexibilidad de los usuarios, en el sentido de que los componentes que este construya deben tener en cuenta las restricciones impuestas por la arquitectura en la que se basan. Esta limitaci´on no es tan importante si el dise˜no de la arquitectura se plantea de manera adecuada al dominio de la aplicaci´on. Los marcos de trabajo pueden dise˜narse y desarrollarse utilizando lo que se conoce como patrones de dise˜no. Un patr´on de dise˜no es una arquitectura que soluciona problemas concretos dentro de la arquitectura general de un sistema. Sirven adem´as para documentar el dise˜no que se realiza. En la propuesta que se presenta, se hace uso, en gran medida, de los patrones de dise˜no m´as conocidos y utilizados, [GHJV95]. En este trabajo se abordan tanto los aspectos relacionados con la arquitectura de dise˜no software como las propuestas concretas que permiten generar diferentes productos finales; como se describe en un cap´ıtulo posterior de la memoria, alguno de estos ya han sido probados en instalaciones energ´eticas reales. Los requisitos iniciales que se le han exigido al marco de trabajo y siempre teniendo en cuenta que su aplicaci´on debe ser directa y efectiva, han sido, tal y como se ha comentado en una secci´on previa: Sistema extensible y ampliable Altamente desacoplado De alto rendimiento 2.3. Metodolog´ıas ´agiles para el desarrollo del marco de trabajo Desde el comienzo del trabajo, se ha puesto especial cuidado en el ciclo de desarrollo del software. En cada ciclo de desarrollo se han extraido conclusiones que han sido aplicadas para mejorar sustancialmente el trabajo, apoy´andose en la utilizaci´on de metodolog´ıas ´agiles, que permiten una adaptaci´on r´apida y eficaz al cambio. La redefinici´on del trabajo realizado ha desembocado en un marco de trabajo que permite la creaci´on de aplicaciones y herramientas de apoyo de manera sencilla, f´acil y de alto rendimiento. Para poder cumplir con los requisitos exigidos al marco de trabajo, desde el punto de vista de su desarrollo, se ha realizado un estudio de las metodolog´ıas del software as´ı como de los lenguajes de programaci´on y entornos de desarrollo apropiados. La utilizaci´on de lenguajes orientados a objetos, en una primera instancia, puede parecer que es lo m´as m´as apropiado, ya que permiten aplicar multitud de paradigmas para el desarrollo del marco de trabajo como son la encapsulaci´on, polimorfismo y 14 2. Marcos de trabajo, Arquitectura Software y Metodolog´ıas utilizaci´on de patrones de dise˜no [GHJV95] lo que hace que se pueda disponer de un sistema ampliable, extensible. Sin embargo, para el desarrollo del marco de trabajo se plante´o como requisito que se pudiera integrar en los sistemas operativos actuales con herramientas y librer´ıas de desarrollo de terceros, por lo que la utilizaci´on de herramientas y metodolog´ıas formales no se hacen apropiados para este caso. Una de las caracter´ısticas m´as cr´ıticas que deb´ıa tener en cuenta el sistema era el rendimiento del mismo, ya que deb´ıa permitir desarrollar aplicaciones para sistemas reales donde existen dispositivos con requisitos cambiantes y de diversa naturaleza, es decir, no se pretend´ıa disponer solo de un marco te´orico sino que, como se presenta en cap´ıtulos posteriores, este marco de trabajo deb´ıa poder ser utilizado, y por lo tanto validado, en instalaciones reales. Respecto a la selecci´on del lenguaje de implementaci´on del marco de trabajo se analizaron varias opciones. Una de las posibilidades que se analizaron fue la utilizaci´on de Java; sin embargo, no se obtuvieron buenos resultados debido a que la velocidad y el tratamiento a bajo nivel de dispositivos electr´onicos complejos result´o ser un h´andicap insalvable. La opci´on de utilizaci´on de C o C++ resultaba tambi´en muy apropiada debido a su alto rendimiento y la posibilidad de ofrecer interfaces de conexi´on con librer´ıas y APIs de terceros pero no disponer de un paradigma de programaci´on orientada a objeto pura al contrario que Java tambi´en hizo que se desestimara la utilizaci´on de este lenguaje. Finalmente se ha optado por utilizar Object Pascal ya que combina lo bueno de una programaci´on a objetos pura donde aplicar metodolog´ıas de desarrollo orientado a objetos y componentes, [Mey99], y el rendimiento de ejecuci´on y utilizaci´on de recursos comparable a C y C++. Debido a que uno de los objetivos principales de este trabajo era disponer de una soluci´on final o marco de trabajo totalmente operativo, con la dificultad a˜nadida de que pueda ser un sistema que permita tanto su extensi´on como modificaci´on, la decisi´on de la metodolog´ıa elegida para su desarrollo ha sido sumamente importante. Las metodolog´ıas tradicionales, como el desarrollo en cascada (Figura 2.1) (que es un enfoque metodol´ogico que dispone el proceso de desarrollo en etapas y una vez finalizadas se dispone del sistema final), han dejado de ser apropiadas para sistemas no cerrados y que pueden cambiar como es el caso de los sistemas energ´eticos: el sistema final se pretende que siga siendo un sistema vivo y que tenga capacidad para reaccionar ante modificaciones y cambios de requisitos que no pueden preverse a priori. 2.3. Metodolog´ıas ´agiles para el desarrollo del marco de trabajo 15 Figura 2.1: Metodolog´ıa de desarrollo en cascada Por ello, para los desarrollos de este trabajo se ha elegido la utilizaci´on de metodolog´ıas ´agiles. Estas metodolog´ıas se basan en un desarrollo iterativo e incremental (Figura 2.2), [Gri91], de manera que se establece un ciclo de vida en cada iteraci´on y se aplican diversas estrategias y procedimientos para mejorar la calidad del producto final. Figura 2.2: Metodolog´ıa de desarrollo ´agil Las metodolog´ıas ´agiles fueron inicialmente propuestas en febrero de 2001, en una reuni´on en la que estuvieron expertos en distintos tipos de metodolog´ıa (Programaci´on Extrema, SCRUM, DSDM, Desarrollo de Software Adaptativo, Crystal, Desarrollo Guiado por Caracter´ısticas y otros similares) y cuyo objetivo era consensuar una alternativa para el proceso de desarrollo de software. Tras esta reuni´on hicieron p´ublico 16 2. Marcos de trabajo, Arquitectura Software y Metodolog´ıas el ”Manifiesto para el Desarrollo ´ Agil de Software”1que valora: Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentaci´on extensiva. Colaboraci´on con el cliente sobre negociaci´on contractual. Respuesta ante el cambio frente seguir un plan. El desarrollo de software, seg´un este manifiesto, se basa en doce principios: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tard´ıas del desarrollo. Los procesos ´ Agiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo m´as corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecuci´on del trabajo. 6. El m´etodo m´as eficiente y efectivo de comunicar informaci´on al equipo de desarrollo y entre sus miembros es la conversaci´on cara a cara. 7. El software funcionando es la medida principal de progreso. 8. Los procesos ´ Agiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atenci´on continua a la excelencia t´ecnica y al buen dise˜no mejora la Agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y dise˜nos emergen de equipos auto-organizados. 1Firmantes del manifiesto: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas 2.3. Metodolog´ıas ´agiles para el desarrollo del marco de trabajo 17 12. A intervalos regulares el equipo reflexiona sobre c´omo ser m´as efectivo para a continuaci´on ajustar y perfeccionar su comportamiento en consecuencia. El principal objetivo de la utilizaci´on de las metodolog´ıas ´agiles es el de minimizar los riesgos. Para conseguir este objetivo los desarrollos que se hacen se van liberando en cortos periodos de tiempo. De esta manera, en cada ciclo o iteraci´on se intentan a˜nadir pocas funcionalidades y se hace ´enfasis en que la calidad del c´odigo sea la mejor posible. Normalmente, en este tipo de metodolog´ıa se utilizan t´ecnicas de refactorizaci´on [Ker04], pruebas unitarias e integraci´on continua para el control, el seguimiento y garantizar la calidad del producto que est´a siendo desarrollado. 2.3.1. Programaci´on extrema La programaci´on extrema o eXtreme Programming (XP) es una metodolog´ıa de desarrollo de la ingenier´ıa de software formulada por Kent Beck, [Bec99]. Es una de las metodolog´ıas ´agiles de desarrollo del software. XP se diferencia de las metodolog´ıas tradicionales, al igual que el resto de las metodolog´ıas ´agiles, en que pone mayor ´enfasis en la capacidad de adaptaci´on al cambio de requisitos frente a la previsibilidad. El cambio de requisitos se considera dentro de las metodolog´ıas ´agiles como algo natural, inevitable e incluso deseable, por lo que la metodolog´ıa que mejor pueda enfrentarse a esta situaci´on conseguir´an una mayor tasa de ´exito aproxim´andose de esta manera al comportamiento natural y de la manera menos traum´atica a lo que se considera la vida de un producto software. En este caso se invierte menos esfuerzo intentando definir todos los requisito para as´ı disponer de mayores recursos al tener que evitar controlar los cambios de los mismos. Esto hace justamente algo deseable cuando nos enfrentamos al desarrollo de un sistema sujeto al cambio como un marco de trabajo. La Programaci´on Extrema puede considerarse como la utilizaci´on y aplicaci´on de las mejores metodolog´ıas de desarrollo durante todo el ciclo de desarrollo del software aplic´andolas de manera din´amica y continua. Algunos de los valores sobre los que se sustenta la programaci´on extrema son: Simplicidad: Es la base de la XP. Cuanto m´as simple est´e desarrollado m´as facilidad de mantenimiento y menos errores podr´an generarse. La simplicidad no solo se aplica al c´odigo fuente sino tambi´en a la documentaci´on premiando el c´odigo autocomentado ya que su detallada expresividad desde el punto de vista sint´actico no afecta al rendimiento del mismo. En este sentido, se potencia el uso de t´ecnicas de refactorizaci´on, donde el cambio sint´actico no afecta al comportamiento sem´antico del c´odigo, y que permiten simplificarlo significativamente, dot´andolo de una mayor expresividad Comunicaci´on: fundamentalmente a trav´es del c´odigo autocomentado. El mejor canal de comunicaci´on debe ser el propio c´odigo. Debe estar autocomentado de- 18 2. Marcos de trabajo, Arquitectura Software y Metodolog´ıas jando los comentarios expl´ıcitos solo para aquello que no vaya a variar como el objetivo de una clase o procedimiento. Otra de las formas de que el c´odigo se exprese debe ser a trav´es de las pruebas unitarias donde se muestra realmente su funcionalidad con los tests aplicados. Todo esto sumado a la estrecha colaboraci´on con otros programadores o el cliente (programaci´on a pares), quien puede indicar qu´e prioridad tienen las funcionalidades a implementar, hacen que la comunicaci´on sea un elemento de gran valor durante el ciclo de desarrollo software. Retroalimentaci´on: Es importante que el usuario final se encuentre involucrado durante todo el desarrollo del proyecto disponiendo en todo momento de sus comentarios y necesidades, as´ı como informarle continuamente de los avances gracias a los ciclos cortos de liberaci´on del producto que est´a siendo desarrollado y que propone esta metodolog´ıa. Las caracter´ısticas de la Programaci´on Extrema la hacen apropiada como metodolog´ıa con la que se ha abordado este proyecto y se ha materializado la arquitectura subyacente. As´ı, algunas de las t´ecnicas m´as importantes que se pueden utilizar para aplicar esta metodolog´ıa de manera adecuada son la refactorizaci´on, el desarrollo dirigido por pruebas y la integraci´on continua. Las t´ecnicas de refactorizaci´on de c´odigo se presentaron inicialmente en 1991 en la tesis doctoral de William G. Griswold [Gri91]; una catalogaci´on y explicaci´on detallada de las mismas se recoge en [Fow99]. La refactorizaci´on se puede aplicar para mejorar la calidad y expresividad del c´odigo fuente. Es una t´ecnica que ni resuelve errores ni a˜nade ninguna funcionalidad pero su aplicaci´on hace que el c´odigo sea m´as claro, que se reduzca su complejidad y que se genere un c´odigo m´as f´acil de mantener. La aplicaci´on de las t´ecnicas de refactorizaci´on pueden aplicarse de manera indeterminada sobre todos los puntos del c´odigo fuente o puede aplicarse siguiendo una estrategia definida para, por ejemplo, llegar a aflorar patrones subyacentes dentro del c´odigo y as´ı poder transformarlo en patrones conocidos, [GHJV95]. Esto se denomina refactorizar hacia patrones de dise˜no [Ker04]. Otra de las t´ecnicas, como la aplicaci´on de un ciclo de desarrollo dirigido por pruebas, puede describirse con los siguientes pasos (figura 2.3): Se escribe un test para una clase o m´odulo determinado, y se desarrolla el test hasta lograr compilarlo. Inicialmente el test aplicado a dicha clase o m´odulo no funciona ya que todav´ıa no se ha implementado la funcionalidad requerida. Implementar la funcionalidad requerida y conseguir que pase el test. Una vez pasado el test sobre la funcionalidad buscada se aplican t´ecnicas de refactorizaci´on. 2.3. Metodolog´ıas ´agiles para el desarrollo del marco de trabajo 19 Figura 2.3: Ciclo de desarrollo basado en pruebas unitarias El desarrollo es, por tanto, totalmente guiado por las pruebas. Adem´as, la utilizaci´on de pruebas unitarias ayuda a la documentaci´on, ya que el test describe por si mismo la funcionalidad a implementar, y permite mantener el c´odigo m´as desacoplado ya que la detecci´on de un error se detecta en cada test y la propia naturaleza de la aplicaci´on de un test hace que la implementaci´on deba mantenerse aislada para poder ser probada. Por ´ultimo, de acuerdo con la propuesta hecha en [Bec99], la programaci´on no es solo un problema de divide y vencer´as, sino un problema de divide, prueba, integra y vencer´as. Por ello, cada desarrollo que se ha hecho en este trabajo ha ido integr´andose de manera continua. El este sentido, durante el desarrollo del marco de trabajo se han identificado unas etapas recurrentes y la comprobaci´on para pasar de una etapa a otra se ha hecho de forma automatizada, en el sentido de que se ha comprobado que la base completa del c´odigo compila sin errores y cada unidad pasa los tests correspondientes. Disponer de estos mecanismos ha permitido, por una parte, tener la seguridad de que lo que se ha ido desarrollando funcionaba, y por otra, acortar el tiempo de producci´on. Algunos de los pasos que se han seguido para asegurar la integraci´on continua son: Integraci´on de los diferentes recursos externos necesarios que forman parte de los 20 2. Marcos de trabajo, Arquitectura Software y Metodolog´ıas requisitos necesarios para compilar o ejecutar el proyecto. Vigilancia del repositorio de c´odigo del proyecto en busca de modificaciones para compilar o ejecutar el producto. En caso de compilaci´on correcta ejecutar los test unitarios que forman parte de proyecto. Generaci´on del producto y/o despliegue sobre un sistema o entorno de desarrollo de producci´on o pruebas. 2.4. Conclusiones En este cap´ıtulo se ha hecho una revisi´on de lo que es un marco de trabajo y su utilizaci´on en distintos campos, ya que la propuesta de este trabajo es desarrollar un marco de trabajo para la gesti´on de sistemas energ´eticos. Para el desarrollo de este marco de trabajo y debido a su complejidad, se ha considerado que deben utilizarse metodolog´ıas que permitan tener en cuenta la especificidad de este tipo de sistemas, fundamentalmente los cambios que se requerir´an a los sistemas de manera que permitan la integraci´on de nuevos componentes y/o m´odulos como la incorporaci´on de modelos de an´alisis y mecanismos de evaluaci´on y predicci´on del funcionamiento. Para dar respuesta a esto, se han analizado las distintas metodolog´ıas de desarrollo que pueden utilizarse y se han descrito aquellas que se proponen utilizar para el desarrollo de la parte pr´actica de este trabajo. Se propone la utilizaci´on de metodolog´ıas ´agiles, as´ı como un proceso de construcci´on y despliegue automatizado que permita la ejecuci´on de test de unidad para evitar la inclusi´on de nuevos errores y garantizar as´ı una calidad no solo en el resultado final sino del producto al completo durante todas las fases de su desarrollo. “Programar sin una arquitectura o dise˜no en mente es como explorar una gruta solo con una linterna: no sabes d´onde est´as, d´onde has estado ni hacia d´onde vas” – Danny Thorpe 3 Marco de trabajo para el desarrollo de software para la gesti´on de sistemas energ´eticos 3.1. Introducci´on Una vez establecidos los conceptos de marco de trabajo y arquitectura software as´ı como las distintas metodolog´ıas de desarrollo que pueden ser utilizadas, en este cap´ıtulo se presenta el marco de trabajo y la arquitectura que se proponen para el desarrollo del software que permita la gesti´on de sistemas energ´eticos. En este ´ambito, el marco de trabajo que se propone puede ser definido como: Un conjunto integrado de clases e interfaces que pueden ser utilizadas por los desarrolladores de sistemas de adquisici´on de datos, gesti´on energ´etica, evaluaci´on del funcionamiento y predicci´on de la producci´on de sistemas energ´eticos para el desarrollo de soluciones software que den respuesta a estas necesidades. Como en cualquier marco de trabajo, se hace una propuesta de la arquitectura del mismo para que sea posible despu´es desarrollar una estructura de clases e interfaces que implementen las funcionalidades requeridas y que pueda ser f´acilmente ampliada y utilizada gracias a las t´ecnicas de herencia, polimorfismo, composici´on e implementaci´on. El marco de trabajo se ha desarrollado utilizando metodolog´ıas ´agiles como las expuestas en el cap´ıtulo 2 para garantizar una calidad en el software resultante. A partir del mismo, se pueden desarrollar programas para la gesti´on de sistemas energ´eticos de ma21 28 3. Marco de trabajo propuesto Figura 3.2: Conjunto de interfaces que definen el marco de trabajo El marco de trabajo desarrollado consistir´a por lo tanto, en un conjunto de interfaces relacionadas y clases que implementan dichas interfaces y pueden ser extendidas cumpliendo la implementaci´on a la que se comprometan seg´un su interfaz, seg´un se muestra, como ejemplo, en la Fig. 3.2. 3.4.2. Desarrollo utilizando interfaces Durante el desarrollo de este marco de trabajo ha sido necesario desarrollar una gran cantidad de interfaces para la definici´on del mismo. As´ı, la declaraci´on de la interfaz estipula la relaci´on entre otras interfaces y declara el comportamiento que debe implementar la clase que declare dicho interfaz, seg´un se muestra en la Fig. 3.3. Figura 3.3: Implementaci´on contra abstracciones De esta manera, una interfaz se relaciona con otra simplemente por su declaraci´on pero deben ser la clases que las implementan las encargadas de hacer valido dicho comportamiento a nivel sem´antico. 3.4. Propuesta de metodolog´ıa de desarrollo 29 3.4.3. Composici´on frente herencia: una propuesta de soluci´on al problema del diamante en la arquitectura software Los mecanismos principales disponibles para la extensi´on y relaci´on entre clases son la composici´on y la herencia. Durante mucho tiempo se ha premiado el uso de la herencia frente a otros mecanismos pero han surgido muchos problemas debido a que es muy dif´ıcil crear una jerarqu´ıa y una relaci´on entre clases poco acopladas. Este problema, com´unmente conocido como el problema del diamante, ver Fig. 3.4, ha llevado a redefinir la forma en las que modelizar las arquitecturas de clases en otras donde se eviten estos problemas. Figura 3.4: Herencia m´ultiple o problema del diamante Para dar soluci´on a este problema, los lenguajes de programaci´on como C++ han permitido la herencia m´ultiple utilizando mecanismos para desambig¨uar en caso de que existan m´etodos o atributos repetidos en las clases superiores. Sin embargo, el lenguaje de programaci´on que se ha utilizado en este trabajo, basado en Object Pascal, no permite la utilizaci´on de la herencia m´ultiple, al ce˜nirse a un paradigma de programaci´on orientada a objetos m´as puro, por lo que se ha tenido que buscar una soluci´on m´as apropiada. Haciendo uso de la capacidad de poder asignar varios interfaces a una misma clase, la propuesta que se hace es la de asignar a las clases con varios ancestros la definici´on de comportamiento, en lugar de implementaciones. De esta forma se pasa de una herencia m´ultiple a la asignaci´on de m´ultiples definiciones de interfaz, seg´un se muestra en la Fig. 3.5. En muchos casos, esta soluci´on resuelve los problemas asociados a la herencia m´ultiple, pero en el caso de que la finalidad sea la de reutilizar c´odigo implementado por el ancestro, acarrear´a un nuevo problema. El hecho de resolver de esta manera el problema del diamante conlleva la sobrecarga de la implementaci´on de las clases inferiores al tener que soportar la reescritura del c´odigo de las clases superiores para cumplir con los requisitos que imponen las interfaces. Una mejora a esa primera soluci´on es la que se muestra en la Fig. 3.6, que evita la situaci´on descrita. 30 3. Marco de trabajo propuesto Figura 3.5: Primera soluci´on al problema del diamante Figura 3.6: Mejora a la primera soluci´on propuesta al problema del diamante En este caso, la clase inferior no necesita implementar los interfaces superiores ya que puede implementarlos por delegaci´on sobre referencias a clases que internamente puede crear. Esta soluci´on revela una estructura adecuada y permite generar una arquitectura altamente desacoplada haciendo uso de la declaraci´on, delegaci´on y composici´on de interfaces. 3.4.4. Implementaci´on por delegaci´on de interfaces La implementaci´on por delegaci´on de interfaces es un mecanismo que permite a una clase pasar la responsabilidad de cumplimiento de una interfaz a otra clase que normalmente suele ser un atributo de la misma creada con esa finalidad. Se puede afirmar que: Dado un conjunto de interfaces, existir´a al menos una clase que implemente dicho interfaz comprometi´endose a validarlo sint´acticamente y ser´a validado sem´anticamente si dicha implementaci´on supera los test asociados a dicho interfaz haciendo uso de dicha clase. 3.4. Propuesta de metodolog´ıa de desarrollo 31 En el siguiente c´odigo se muestra la propuesta para resolver el problema de la herencia m´ultiple utilizando interfaces y aplicando la delegaci´on para no tener que reimplementar los m´etodos asociados a dichas interfaces: Listing 3.1: Delegaci´on de la implementaci´on de un interfaz 1Class D = class(TObjec,Interfaz B, Interfaz C) 2private 3fImplIntf B : Interfaz B; 4fImplIntf C : Interfaz C; 5pubic 6property ImplementaIntf B : Interfaz B read fImplIntf B write fImplIntf B implements Interfaz B; 7property ImplementaIntf C : Interfaz C read fImplIntf C write fImplIntf C implements Interfaz C; 8end Una vez delegada la implementaci´on del interfaz a los atributos de la clase es posible asignar a los mismos clases que realmente implementan el comportamiento deseado. Esto es se puede realizar en el interior del constructor de la clase asignando la implementaci´on deseada, de acuerdo al siguiente c´odigo: Listing 3.2: Implementaci´on de la interfaz por delegaci´on de manera impl´ıcita 1constructor Class D; 2begin 3fImplIntf B := Clase que implementa interfaz B.create; 4fImplIntf C := Clase que implementa interfaz C.create; 5end Haciendo uso de la composici´on de clases y la delegaci´on de interfaces, el marco de trabajo puede extenderse y seguir un esquema desacoplado al no existir relaciones directas entre clases en favor de las relaciones establecidas entre interfaces. As´ı, una clase puede cambiar de implementaci´on cambiando la clase sobre la que delega la definici´on de la interfaz que debe cumplir sin cambiar las relaciones entre la l´ogica establecida por el marco de trabajo y sus interfaces. Sin embargo, aunque de esta manera se est´a dotando al marco de trabajo de la capacidad de ser f´acilmente conectable y configurable, tambi´en se est´a introduciendo un punto de rigidez al establecer dentro de dicha clase la decisi´on de qu´e implementaci´on utilizar. Para resolver esto se propone la utilizaci´on en la implementaci´on del concepto de inyecci´on dependencias. 3.4.5. Inyecci´on de dependencias La inyecci´on de dependencias consiste en utilizar un mecanismo de asignaci´on de manera externa de las dependencias que una clase pueda tener permitiendo desacoplar dicha clase del resto del sistema, seg´un se muestra en la Fig. 3.7. Este mecanismo permite adem´as poder probar dicha clase ya que puede ser utilizada de manera aislada y conectarla a su vez con diferentes implementaciones. 32 3. Marco de trabajo propuesto Figura 3.7: Inyecci´on de dependencias Un mecanismo b´asico de la inyecci´on de dependencias es la inyecci´on en el constructor, seg´un se muestra en el siguiente c´odigo: Listing 3.3: Inyecci´on de dependencias durante la construcci´on de la instancia de clase 1constructor Class D( aClassB : Interfaz B; aClassC : Interfaz C ); 2begin 3fImplIntf B := aClassB; 4fImplIntf C := aClassC; 5end 6 7begin 8// Se intecta a la clase D dos implementaciones particulares 9Class D.create(Implementacion1IntfB.create, Implementacion3IntfC.create); 10 end En este ejemplo se muestra c´omo se inyecta la dependencia durante la construcci´on del objecto permitiendo de esta manera que la rigidez que produce la introducci´on de una dependencia se realice en el nivel m´as externo del c´odigo. Este mecanismo ser´a muy utilizado en el desarrollo del marco de trabajo propuesto al haber demostrado ser una buena pr´actica en el dise˜no de software. 3.5. Conclusiones En este cap´ıtulo se ha descrito de forma general la arquitectura software y el marco de trabajo propuesto para el desarrollo de sistemas de gesti´on energ´etica. Para el marco de trabajo propuesto se ha optado por utilizar una arquitectura basada en capas donde cada una de ellas tiene una funci´on determinante para el conjunto del sistema. Se ha descrito cada una de las capas y se ha puesto de manifiesto que esta organizaci´on permite disponer de una distribuci´on de las responsabilidades de manera aislada y altamente desacoplada. 3.5. Conclusiones 33 Adem´as se han descrito algunos de los problemas que surgen cuando se dise˜na la arquitectura de un sistema y se han propuesto soluciones que evitan estos problemas. La soluci´on propuesta proporciona caracter´ısticas de algo grado de desacoplo, altamente independiente y f´acilmente extensible y configurable, facilitando as´ı soluciones para problemas comunes en el desarrollo software as´ı como proporcionando indicaciones para una implementaci´on eficiente de la arquitectura. Haciendo uso de las t´ecnicas de desarrollo orientado hacia abstracciones, se dispondr´a de una metodolog´ıa para la codificaci´on eficiente y desacoplada de todos los sistemas que ser´an necesarios para desarrollar el marco de trabajo. Por ´ultimo, tal y como se explic´o en el cap´ıtulo 2, a la hora de afrontar un desarrollo software es necesario disponer de una metodolog´ıa apropiada. En este cap´ıtulo se ha complementado la elecci´on de la metodolog´ıa con varias propuestas que facilitan seguir unos paradigmas de programaci´on que permiten poner de manifiesto una potencia expresiva suficiente para plasmar la arquitectura de manera precisa y eficiente. “El mayor problema en la comunicaci´on es la ilusi´on de que se ha logrado” – George Bernard Shaw 4 Capa de comunicaciones abstracta 4.1. Introducci´on En este cap´ıtulo se describe la capa de comunicaciones abstracta. Se propone un sistema de comunicaciones con los dispositivos que est´a totalmente separado de las dem´as funcionalidades que se incluyen en el marco de trabajo. El objetivo de la propuesta que se hace es conseguir una conectividad abierta utilizando est´andares abiertos. Por otra parte, bas´andose en el modelo que se propone en esta tesis, la integraci´on de modelos de evaluaci´on y predicci´on en los sistemas de gesti´on energ´etica que se desarrollen a partir del marco de trabajo propuesto, se har´a partiendo del mismo esquema de abstracci´on que se propone para las comunicaciones. Como se justificar´a m´as adelante, en este mismo cap´ıtulo, esto permitir´a separar estos modelos del sistema, de manera que se puedan modificar, ajustar, etc. para cada instalaci´on sin necesidad de tener que redise˜nar el sistema. As´ı, la salida y resultados de estos modelos, se proporcionar´a al sistema como un componente m´as. Como es conocido, uno de los grandes retos a los que debe dar respuesta cualquier sistema de monitorizaci´on y gesti´on de plantas energ´eticas es, sin duda, la comunicaci´on del sistema con todos los dispositivos que forman parte del sistema. ´ Esta debe ser eficiente, vers´atil y flexible. Adem´as, es necesario que se puedan integrar los sistemas de automatizaci´on para distintos sistemas energ´eticos, como pueden ser parques e´olicos, sistemas energ´ıa solar t´ermica, sistemas de energ´ıa solar fotovoltaica, tanto aislados como conectados a la red el´ectrica, sistemas de cogeneraci´on, etc. 35 36 4. Capa de comunicaciones abstracta Debido a la gran cantidad de dispositivos, marcas, fabricantes y modelos distintos de dispositivos que pueden formar parte de un sistema energ´etico, implementar un protocolo de comunicaciones para cada uno de ellos supondr´ıa un gran esfuerzo y una gran inversi´on en tiempo, teniendo en cuenta, adem´as, que no siempre se dispone de los protocolos para todos los tipos de dispositivos que se quieran incorporar. Lo que se plantea en este trabajo es utilizar el est´andar OPC (OLE/COM [Gor01], Object Linking and Embedding / Component Model), por ser un sistema est´andar y homog´eneo de comunicaciones. Se trata de conseguir: Generalizaci´on en las comunicaciones. As´ı, la propuesta de utilizar un est´andar, a nivel de implementaci´on permite: •Facilidad y flexibilidad en el desarrollo: Al tener una versi´on implementada de comunicaciones con el protocolo y ser este un est´andar necesitar´a relativamente pocos cambios para reutilizarlo con distintos dispositivos y a˜nadir distintas funcionalidades. •Versatilidad en la monitorizaci´on de distintos dispositivos: El protocolo se basa en un est´andar aprobado y bien definido que implementan distintos modelos de dispositivos y que podr´an ser incorporados al marco de trabajo modificando el servidor de comunicaciones que se desarrolle. La utilizaci´on de distintos canales de comunicaci´on: Al tener implementado un servidor OPC gen´erico se tiene la posibilidad de establecer comunicaci´on de forma remota con dispositivos utilizando distintos medios como pueden ser tecnolog´ıas GSM, GPRS o IP. Creaci´on de un modelizado de dispositivos gen´ericos que no tiene un tipo ni modelo concretos, con lo que la inclusi´on de los dispositivos y el almacenamiento de los datos que de ellos se extraiga, permitir´a una f´acil e inmediata integraci´on en la base de datos. Para dar respuesta a estos requisitos se propone descomponer el sistema de comunicaciones en tres niveles: Nivel del dispositivo: en este nivel se tiene en cuenta el dispositivo concreto con el que se va a intercambiar la informaci´on y en ´el se configuran los par´ametros espec´ıficos de cada dispositivo. Nivel del protocolo: Se define el protocolo de comunicaciones entre el dispositivo y el sistema de gesti´on. Nivel del medio f´ısico: se define el medio f´ısico por el que se va a efectuar el intercambio de informaci´on entre el sistema y el dispositivo. En este nivel se configuran los par´ametros espec´ıficos del medio f´ısico elegido. 4.2. Tecnolog´ıa OPC 37 4.2. Tecnolog´ıa OPC Para establecer las comunicaciones con los distintos dispositivos f´ısicos y virtuales que forman parte de un sistema energ´etico, correspondientes al nivel de protocolo, se propone, como se ha comentado anteriormente, la utilizaci´on del est´andar de comunicaci´on basado en la tecnolog´ıa OPC, que permite resolver de una manera sencilla los problemas de interconexi´on, seg´un la arquitectura OPC Cliente/Servidor que se muestra en la figura 4.1. Figura 4.1: Arquitectura OPC Cliente/Servidor La tecnolog´ıa OPC est´a basada en la tecnolog´ıa OLE/COM (Objetct Linking and Embedding/ Component Model from Microsoft), [Gor01], [LLH+05]. Por una parte, OPC es un est´andar abierto para comunicaciones utilizado en el sector industrial para conectar los sistemas de supervisi´on y adquisici´on de datos e interfaces hombre-m´aquina con los sistemas f´ısicos de control, [Hol04], y se ha utilizado ya en el ´ambito de la monitorizaci´on de sistemas energ´eticos, por ejemplo, en [GCTL08]. Por otra parte, OPC es un est´andar que permite el desarrollo de componentes para interconectar sistemas dispersos creando soluciones robustas y proporcionando interoperabilidad de una manera eficiente, ya que la utilizaci´on de este est´andar permite reducir tiempos y costes en el desarrollo de sistemas de control. OPC define un est´andar de intercambio de informaci´on y las reglas de negociaci´on entre dispositivos de diferentes tipos utilizando el paradigma cliente/servidor. Adem´as, OPC permite de manera sencilla soluciones totalmente escalables que facilitan futuros cambios y la ampliaci´on de los sistemas que se desarrollan usando este est´andar. El dise˜no de interfaces OPC soporta arquitecturas distribuidas. En la actualidad el est´andar OPC est´a apoyado por m´as de 200 empresas e instituciones como son Microsoft, CERN, Compac o National Instruments, lo que garantiza un mantenimiento, revisi´on y mejoras continuas del est´andar para dar respuestas a los nuevos desarrollos. La evoluci´on del est´andar OPC est´a soportado por la fundaci´on 44 4. Capa de comunicaciones abstracta Figura 4.6: Diagrama de secuencia entre un sistema de monitorizaci´on y un dispositivo a trav´es de un cliente OPC-DA y un servidor OPC-DA Es interesante observar que cuando el cliente OPC crea los grupos de medidas que quiere recuperar de un dispositivo podr´ıa establecer una frecuencia de recogida diferente a la que el servidor OPC puede recuperar datos del dispositivo debido a diferencias o particularidades del protocolo. Toda la l´ogica entre el servidor OPC y cliente OPC es gen´erica para cualquier servidor OPC por lo que es apropiado encapsularla en una serie de clases para permitir, de manera sencilla, reutilizar toda esta l´ogica com´un. Las particularidades, como el protocolo de comunicaci´on con el dispositivo as´ı como los interfaces de usuario necesarios para parametrizar los diferentes servidores OPC a desarrollar es justamente lo que cada clase final de la jerarqu´ıa debe implementar, como se muestra en la figura 4.7. Cuando se desarrolla un servidor OPC para un determinado dispositivo se crea una clase que herede de la jerarqu´ıa apropiada. Dicha clase encapsular´a el protocolo de intercambio de informaci´on con el dispositivo y ser´an las clases anfitrionas las que se encargar´an de proporcional el interfaz de comportamiento de servidor OPC (por ejemplo, las clases marcadas en amarillo intenso en la figura 4.7). Adem´as es posible encapsular informaci´on determinada sobre el comportamiento de los dispositivos heredando a su vez de la clase TDevices en el caso que se desee modelizar cualquier particularidad del mismo. La mayor´ıa de la l´ogica encargada de tratar con el protocolo y los dispositivos es la clase de la jerarqu´ıa denominada TCustomDeviceOPCServer, que se muestra en la figura 4.9. Esta clase dispone de la lista de dispositivos a controlar, los eventos que pueden ser sobreescritos por las clases inferiores para la gesti´on del ciclo de recogida 4.3. Marco de trabajo para la generaci´on de servidores OPC-DA 45 Figura 4.7: Jerarqu´ıa para la construcci´on de servidores OPC-DA de datos (OnDeviceOK, OnDeviceRetry, etc...), las funciones que devuelven las clases que deben ser utilizadas para la creaci´on de las instancias apropiadas utilizando para ello una factor´ıa de clases (GetDeviceClass, GetDevicesClass y GetConfiguraDeviceFormClass) y una hebra, RoundTimer, que se encargar´a en cada ciclo de ejecuci´on establecido de preguntar a cada dispositivo por los valores de los puntos de medida que dispone. Esta ´ultima informaci´on se almacena internamente y puede ser recogida por medio del protocolo est´andar por los clientes OPC usando COM+/DCOM [Gor01], [Har01]. Es importante cuando se despliegan m´ultiples aplicaciones, y sobre todo cuando forman parte de un mismo sistema, que todas dispongan de una apariencia uniforme y parecida dando as´ı impresi´on de coherencia y facilidad de uso. Para evitar que esta responsabilidad recaiga en la parte de dise˜no, se ha acoplado a la jerarqu´ıa de clases una serie de elementos visuales comunes permitiendo de esta manera que todas las clases compartan los mismos elementos gr´aficos, seg´un se muestra en la figura 4.10. Figura 4.10: Formulario visual de un servidor OPC 46 4. Capa de comunicaciones abstracta Figura 4.8: Clase encargada de proporcionar el comportamiento de servidor OPC As´ı cualquier servidor OPC desarrollado dispondr´a de un formulario con un mismo aspecto visual as´ı como elementos de men´u con las acciones y funcionalidades comunes, como puede observarse en la figura 4.11. Figura 4.11: Sistema de acciones comunes de cualquier servidor OPC 4.3.2. Servidor OPC-DA para inversores en plantas solares Uno de los subsistemas fundamentales en una instalaci´on de energ´ıa solar de tipo fotovoltaico son los inversores que se encargan de transformar la corriente continua, que proviene de las placas solares, en corriente alterna para que pueda ser usada de manera directa o para que pueda inyectarse a la red. Los inversores disponibles en el mercado pueden ser bastantes diferentes en algunas de sus caracter´ısticas como puede ser los puertos de comunicaci´on, la potencia, caracter´ısticas f´ısicas, etc.. es por ello que 4.3. Marco de trabajo para la generaci´on de servidores OPC-DA 47 Figura 4.9: Clase encargada de proporcionar la comunicaci´on entre los dispositivos y el interfaz OPC el marco de trabajo debe disponer de la capacidad de permitir indicar dichas diferencias utilizando los mecanismos de particularizaci´on. Es cierto que entre todos ellos existe similitudes y que se pueden aprovechar los mecanismos de herencia para reunir en las clases superiores de la jerarqu´ıa de clases los par´ametros comunes que tendr´an todos los inversores desarrollados con el consiguiente ahorro de c´odigo (Fig. 4.12). Figura 4.12: Generalizaci´on de la clase com´un de inversor solar As´ı, en la clase TCustomSolarOPCServerInverter se declaran los canales que disponen todos los inversores, permitiendo as´ı que los inversores que se utilicen dispongan ya de esos canales y facilitar as´ı la creaci´on de los mismos. 48 4. Capa de comunicaciones abstracta Listing 4.1: Declaraci´on en el constructor 1constructor TCustomSolarOPCServerInverter.Create; 2begin 3 4inherited; 5 6// Canales Obligatorios 7AddOPCItem(MS PCC,[iaRead],varDouble or varArray,0,nil); 8AddOPCItem(MS PCA,[iaRead],varDouble or varArray,0,nil); 9AddOPCItem(MS NU ,[iaRead],varDouble or varArray,0,nil); 10 11 // Estado del inversor 12 AddOPCItem(ST ENCENDIDO,[iaRead],varBoolean,0,nil,OPC QUALITY GOOD); 13 AddOPCItem(ST MARCHA ,[iaRead],varBoolean,0,nil,OPC QUALITY GOOD); 14 end; En el c´odigo correspondiente al constructor de la clase que proporciona la funcionalidad gen´erica para disponer de un servidor OPC para inversores solares puede verse la declaraci´on de los canales que compartir´an todos los servidores de este tipo. En este caso canales de potencia continua y alterna y rendimiento del inversor as´ı como algunas se˜nales de alarmas. En los siguientes apartados se describen algunos de los servidores OPC desarrollados para inversores de distintos tipos utilizando el marco de trabajo propuesto y que ponen a prueba su validez. Servidor OPC-DA para inversores monof´asicos con protocolo Modbus De entre los inversores monof´asicos, uno de los protocolos de comunicaci´on m´as utilizado con los inversores es el basado en ModBus. Debido a esta raz´on hay multitud de instalaciones que utilizan este tipo de dispositivos por lo que son unos candidatos apropiados a los que desarrollar el servidor OPC, utilizando el marco de trabajo estudio de esta tesis, para integrarlos dentro de los sistemas desarrollados. Para el modelizado de este inversor ha sido necesario especializar la clase que implementa la l´ogica de un inversor solar gen´erico, seg´un se muestra en la figura 4.13. Figura 4.13: Implementaci´on de un servidor OPC para un inversor monof´asico 4.3. Marco de trabajo para la generaci´on de servidores OPC-DA 49 A continuaci´on se muestran algunas implementaciones disponibles en el marco de trabajo para la comunicaci´on con dispositivos basados en el protocolo ModBus pero para diferentes medios f´ısicos de comunicaci´on. Servidor OPC-DA para inversor trif´asico con protocolo Modbus y comunicaci´on a trav´es de GSM El modelizado de un inversor trif´asico con comunicaciones serie se ha realizado partiendo de la clase gen´erica que permite conectar con cualquier inversor solar utilizando el puerto serie y comunicaci´on telef´onica GSM, de acuerdo con la figura 4.14. Figura 4.14: Implementaci´on de un servidor OPC con comunicaci´on GSM a trav´es de ModBus Puede observarse como la clase anfitriona TCustomOPCSerialServer dispone de una referencia a un componente denominado TDialer. Este componente implementa dos interfaces que el marco de trabajo utilizar´a para configurar dicho componente utilizando un interfaz de usuario apropiado. Por un lado ICPortSerialConfig que configura los par´ametros del puerto serie, figura 4.15 (izquierda), y IModemConfiguration que configura los par´ametros de la comunicaci´on telef´onica utilizando el m´odem, figura 4.15(derecha). 50 4. Capa de comunicaciones abstracta Figura 4.15: Implementaci´on del interfaz para la configuraci´on del puerto serie (izquierda) y m´odem (derecha) Una vez declarada la estructura utilizando las clases que proporciona el marco de trabajo desarrollado se dispondr´a de una comunicaci´on telef´onica con cualquier inversor trif´asico utilizando el protocolo OPC. Puede adem´as apreciarse c´omo la conexi´on l´ogica con el inversor, es decir, la implementaci´on del protocolo, se ha encapsulado dentro de la clase TmlCustomModbusConnection donde se realizar´a el intercambio de informaci´on utilizando el protocolo Modbus. Servidor OPC-DA para inversor trif´asico con protocolo Modbus y a trav´es de GPRS Gracias al avance de las redes de datos y las comunicaciones m´oviles, es cada vez m´as com´un interconectar dispositivos utilizando la red de Internet. Para este tipo de comunicaci´on, la manera m´as generalizada es la utilizaci´on de la capa de red IP. Existe por tanto la capacidad de conectar utilizando el servicio general de paquetes v´ıa radio o GPRS cuya comunicaci´on interna est´a basada en tecnolog´ıa IP. En este caso, y para la creaci´on del servidor OPC para este tipo de dispositivos se ha utilizado la clase TCustomOPCGPRSServer que proporciona la conectividad GPRS y la clase TCustomOPCGPRSModbusServer que proporciona el funcionamiento del protocolo Modbus a trav´es de GPRS, figura 4.16. Puede apreciarse que la implementaci´on se basa en la reutilizaci´on de la interfaz que implementa el protocolo ModBus y extiende el modelo para la conexi´on GPRS. Para la configuraci´on de este servidor OPC ser´a necesario al menos indicar la direcci´on IP del dispositivo y el marco de trabajo permitir´a indicarlo de manera gr´afica haciendo uso de la interfaz IPlantWithGPRSConfiguration, figura 4.17. 4.3. Marco de trabajo para la generaci´on de servidores OPC-DA 51 Figura 4.16: Implementaci´on de un servidor OPC para inversor con comunicaci´on GPRS Figura 4.17: Implementaci´on del interfaz para la configuraci´on del puerto serie 4.3.3. Servidor OPC-DA para inversores con protocolo propietario Para la implementaci´on de un servidor OPC para inversores que tienen un protocolo propietario se ha seguido la misma filosof´ıa de desarrollo para continuar demostrando la facilidad con la que se puede disponer de un servidor OPC para cualquier tipo de inversor. Al ser un protocolo propietario, es decir, no se basa en ning´un protocolo est´andar de intercambio de informaci´on, la implementaci´on del mismo se realizar´a en una clase espec´ıfica y heredar´a el comportamiento de inversor gen´erico que disponga de un puerto serie, figura 4.18. En este caso, la clase superior implementa el comportamiento de una servidor OPC para inversores con un puerto serie de comunicaciones as´ı como el interfaz de usuario para configurar dicho puerto serie. 52 4. Capa de comunicaciones abstracta Figura 4.18: Implementaci´on del interfaz para un protocolo propietario 4.3.4. Servidor OPC-DA para inversores con protocolo SNMP Existen inversores cuyo protocolo de comunicaci´on est´an basados en SNMP (Simple Network Management Protocol). En este caso es necesario instalar un agente que reporta la informaci´on a trav´es de SNMP con el sistema de recogida de informaci´on. Es por ello, que en este caso, el servidor OPC deber´a actuar como sistema escucha de la informaci´on que el agente emite sobre el funcionamiento del inversor utilizando tramas SNMP. Figura 4.19: Implementaci´on de un servidor OPC para inversores con protocolo basado en SNMP La clase que implementa la particularizaci´on de un servidor OPC gen´erico en un servidor OPC, indicar´a adem´as el formulario de configuraci´on necesario para hacer funcionar el protocolo SNMP que implementa. Entre estos par´ametros se encuentra la direcci´on IP donde se encuentra el agente que intercambia informaci´on con el inversor, la informaci´on SNMP y la identificaci´on del dispositivo que se asocia con el inversor, figura 4.20. 4.3. Marco de trabajo para la generaci´on de servidores OPC-DA 53 Figura 4.20: Formulario de configuraci´on de los par´ametros SNMP para servidor OPC 4.3.5. Servidor OPC-DA para Arduino En los ´ultimos a˜nos ha aparecido un nuevo paradigma en la fabricaci´on y utilizaci´on de dispositivos basada en hardware abierto. Uno de sus m´aximos exponentes son los dispositivos basados en una placa con un microprocesador y entorno de desarrollo libre con aplicaci´on en proyectos multidisciplinares. El hardware est´a basado en un microcontrolador Atmel AVR y su f´acil utilizaci´on y bajo coste ha supuesto una autentica revoluci´on entre los aficionados y profesionales del mundo de la electr´onica e incluso entornos educativos. Aprovechando el desarrollo de este marco de trabajo y la total ausencia de ning´un mecanismo de comunicaciones est´andar basado en OPC, se ha desarrollado un servidor OPC que ha permitido que este dispositivo tenga esta funcionalidad y se ha liberado este producto que est´a siendo utilizado por miles de usuarios y ha permitido formar una comunidad alrededor de este producto. Actualmente es el ´unico producto de referencia que a´una la tecnolog´ıa basada en Hardware Libre y la tecnolog´ıa OPC y ha sido desarrollado con el marco de trabajo desarrollado en este tesis. Los dispositivos de esta familia est´an representados por varios modelos con diferentes caracter´ısticas y desde el principio se ha tenido en mente cubrir todos y cada uno de los modelos m´as emblem´aticos. La multitud de variantes y formas de comunicaci´on hac´ıan de este un proyecto complejo pero apropiado para ser implementado siguiendo la filosof´ıa y la arquitectura propuesta. Se han considerado los tres siguientes modelos: El modelo Arduino UNO es el modelo b´asico e implementa en su interior un microcontrolador Atmel AVR ATmega328 a 16MHZ funcionando a 5V con 14 entradas/salidas digitales y 6 entradas/salidas anal´ogicas disponiendo de una memoria flash de 32Kb. La comunicaci´on con el ordenador se realiza a trav´es de comunicaciones serie materializadas sobre una l´ınea USB. El modelo Arduino Ethernet es similar al Arduino UNO pero dispone un puerto de comunicaciones Ethernet proporcionando mayor potencia de comunicaci´on al poder conectarlo a una red local y aumentado considerablemente el alcance de trabajo as´ı como la velocidad de comunicaciones. 60 4. Capa de comunicaciones abstracta 4.4. Marco de trabajo para la generaci´on de servidores OPC-HDA En la secci´on anterior se ha mostrado c´omo la tecnolog´ıa OPC y la parte del marco de trabajo desarrollado, encargado de la construcci´on de servidores OPC-DA, permite desarrollar controladores compatibles con multitud de dispositivos en poco tiempo y de una manera sencilla. La informaci´on que se intercambia con estos dispositivos son se˜nales instant´aneas o en tiempo real. Sin embargo, en multitud de ocasiones, los dispositivos que forman parte de una instalaci´on, almacenan en su interior valores denominados hist´oricos. Estos dispositivos suelen tener una memoria interna y almacenan el valor de sus canales a una frecuencia determinada. As´ı, para acceder a ellos es necesario utilizar el protocolo determinado por el fabricante e inspeccionar la memoria de estos dispositivos para descargar la informaci´on. En este caso la situaci´on es la misma que cuando se necesita disponer de la informaci´on almacenada de diversos dispositivos en los que cada uno almacena la informaci´on de una manera determinada como puede verse en la figura 4.32. Figura 4.32: Problema de la interconexi´on entre multitud de dispositivos para acceder a informaci´on almacenada La utilizaci´on de OPC-HDA permite disponer de un mecanismo de unificaci´on de acceso a la informaci´on independientemente del formato en el que se encuentre almacenada la informaci´on dentro del dispositivo. Al igual que con la parte OPC-DA, solo ser´a necesario conocer el protocolo para la descarga de la informaci´on y la exposi- 4.4. Marco de trabajo para la generaci´on de servidores OPC-HDA 61 ci´on hacia cualquier cliente interesado en esos datos se realizar´a utilizando una forma homog´enea basada en el protocolo OPC-HDA, figura 4.33. Figura 4.33: Utilizaci´on de OPC-HDA para unificar el acceso a la informaci´on almacenada 4.4.1. Servidores OPC-HDA Un servidor OPC-HDA es un componente basado en COM/DCOM que implementa el interfaz OPC-HDA. Esta interfaz est´a basada en el modelo que se muestra en la figura 4.34. Figura 4.34: Modelo de objeto OPC-HDA 62 4. Capa de comunicaciones abstracta En la tabla 4.1 se muestra cada uno de los elementos que conforman el interfaz que implementa el modelo de objeto OPC-HDA. Objeto Descripci´on OPHDAServer Instancia de un servidor OPC-HDA. OPCHDAItems Colecci´on de OPCHDAItem. OPCHDAItem Representa la definici´on de un item o canal de informaci´on. OPCHDABrowser Permite navegar por la estructura de canales disponibles. OPCHDAHistory Colecci´on de valores de un canal determinado. OPCHDAValue Representa un valor hist´orico discreto de un canal determinado. Tabla 4.1: Elementos que conforman el interfaz que implementa el modelo de objeto OPC-HDA De esta manera, el componente que implemente esta interfaz servir´a de clase base para la construcci´on de cualquier servidor OPC-HDA disponiendo as´ı de un mecanismo aut´onomo para la recuperaci´on de los datos de cualquier dispositivo que forme parte de una instalaci´on de gesti´on energ´etica. Al igual que en el caso de la comunicaci´on con cualquier dispositivo del que se quiera recuperar la informaci´on de sus canales instant´aneos, para la recuperaci´on de los valores hist´oricos, la tecnolog´ıa OPC establece el diagrama de secuencia gen´erico que se muestra en la figura 4.35. Figura 4.35: Diagrama de secuencia entre un sistema de monitorizaci´on y un dispositivo a trav´es de un cliente OPC-HDA y un servidor OPC-HDA En este diagrama puede verse c´omo aparecen varios actores. Por un lado el software cliente que usa la tecnolog´ıa OPC-HDA para descargarse los datos de un dispositivo, 4.4. Marco de trabajo para la generaci´on de servidores OPC-HDA 63 el dispositivo a interrogar y el servidor OPC-HDA que conoce el protocolo y el procedimiento apropiado para descargar los datos de dicho dispositivo. Antes de poder utilizar un servidor OPC-HDA, este debe estar disponible en el sistema operativo; para ello, su registro se realiza utilizando el mecanismo de registro de componentes COM/DCOM y haciendo uso del registro del sistema. Una vez registrado, paso que suele hacerse una ´unica vez en el momento de su instalaci´on, este servidor est´a disponible para cualquier sistema que quiera hacer uso del mismo. En la figura 4.36 se muestra la clase base propuesta como punto de partida para creaci´on de cualquier servidor OPC-HDA. Esta clase TCustomHDAServer implementa la l´ogica OPC-HDA con los componentes COM instalados en el sistema y dispone adem´as de un interfaz de usuario para darle a todos los servidores un aspecto visual similar y homog´eneo. Figura 4.36: Implementaci´on de la clase gen´erica para servidores OPC-HDA En la figura 4.37 se detalla el interfaz de usuario ´unico para cualquier servidor OPC-HDA. Existe una referencia bidireccional con la clase que implementa la l´ogica OPC-HDA y, adem´as de un men´u donde realizar las acciones m´as comunes, como puede ser registrar, cerrar, mostrar los eventos, se ha a˜nadido una ventana de bienvenida que suele ser muy ´util para identificar con qu´e dispositivos es compatible el servidor OPCHDA que est´a siendo usado. Siguiendo la estructura desde la clase m´as gen´erica hasta la clase m´as espec´ıfica, que suele ser la que implementa las particularidades para cada dispositivo, se ha cre´ıdo conveniente desarrollar una clase que implementa las funcionalidades para permitir a cada servidor guardar de manera homog´enea toda la informaci´on que necesiten, relativa en la mayor´ıa de las veces, a los par´ametros de configuraci´on y conexi´on con los dispositivos de los que van a extraer la informaci´on, figura 4.38. En esta clase existen m´etodos virtuales que pueden ser sobreescritos por las clases inferiores para configurar el mecanismo de almacenamiento de los par´ametros que sean necesarios. 64 4. Capa de comunicaciones abstracta Figura 4.37: Implementaci´on de la clase gen´erica para el interfaz de usuario de servidores OPC-HDA Con esta jerarqu´ıa propuesta, en los siguientes apartados se detallan algunas implementaciones de servidores OPC-HDA para dispositivos reales muy utilizados en sistema de gesti´on energ´etica. 4.4.2. Servidor OPC-HDA para inversores con protocolo Modbus Uno de los protocolos m´as utilizados para la recuperaci´on de informaci´on hist´orica de los dispositivos es el basado en ModBus. Es por esta raz´on por la que se propone la generalizaci´on de todos los dispositivos de los que disponen de este protocolo en una ´unica clase que encapsular´a la l´ogica y el algoritmo de comunicaci´on que es com´un para todos los tipos de inversores que utilizan ModBus. Partiendo de la clase base anteriormente descrita, se pone a la disposici´on del marco de trabajo la clase TCustomIngeconHDAServer, que implementa los interfaces de configuraci´on de par´ametros, la configuraci´on del protocolo Modbus y dem´as clases de apoyo para representar a cualquier inversor de este tipo, figura 4.39. 4.4. Marco de trabajo para la generaci´on de servidores OPC-HDA 65 Figura 4.38: Implementaci´on de la clase gen´erica para servidores OPC-HDA configurables En la figura 4.40 puede verse c´omo es sencillo implementar servidores OPC-HDA para cualquier inversor de este tipo, haciendo uso de la herencia de clases e interfaces ya que las clases anfitrionas son las encargadas de implementar la l´ogica com´un y solo las particularidades de los diferentes clases de inversores son realizadas en las clases particulares. En el caso de aparecer dispositivos con algunas particularidades muy espec´ıficas, como en el caso de inversores que se conectan utilizando la tecnolog´ıa GPRS, se pueden agrupar dichas funcionalidades e implementar las interfaces apropiadas para resolver el problema de la implementaci´on de dispositivos con caracter´ısticas comunes. En la figura 4.41 se puede observar el dise˜no de la clase TCustomIngeconHDAServerGPRS y el interfaz IPlantWithGPRSConfiguration para dar soluci´on al problema sugerido. Esta interfaz es una extensi´on de una interfaz disponible en el marco de trabajo para proporcionar la capacidad de configuraciones a las clases que la implementen o hagan uso de ella. Pueden verse que los atributos de esta interfaz pertenecen a par´ametros de configuraci´on de una conexi´on IP y en este caso adem´as a par´ametros de autenticaci´on para acceder a la informaci´on del dispositivo. 66 4. Capa de comunicaciones abstracta Figura 4.39: Implementaci´on de la clase gen´erica para servidores OPC-HDA para inversores con protocolo Modbus. 4.4. Marco de trabajo para la generaci´on de servidores OPC-HDA 67 Figura 4.40: Implementaci´on de las clases particulares de servidores OPC-HDA para inversores con protocolo Modbus Figura 4.41: Implementaci´on de la interfaz de conexi´on utilizando IP a trav´es de GPRS 68 4. Capa de comunicaciones abstracta 4.4.3. Servidor OPC-HDA para comunicaci´on con grupos de inversores Algunos sistemas cuentan con un dispositivo que recolecta la informaci´on de distintos inversores. Un ejemplo muy utilizado es el dispositivo WebBox que interroga a una serie de inversores y almacena la informaci´on de los mismos en su memoria interna. Por otro lado, ofrece una conexi´on HTTP que permite con un navegador web acceder a su interior y ver los datos almacenados en forma de p´agina web. Este tipo de dispositivos son interesantes ya que si bien, en caso de disponer de muchos inversores, podr´ıamos conectarnos a todos, podemos dejar que sean estos dispositivos quienes se encarguen de recoger la informaci´on de los mismos y conectarnos a ´el para descargar toda la informaci´on de todos los inversores. En este caso se tiene un dispositivo que tiene un comportamiento que podr´ıa ser com´un, ya que muchos otros dispositivos podr´ıan almacenar la informaci´on en formato de ficheros, por lo que la soluci´on a adoptar pasar´a por dar una soluci´on gen´erica a la misma e incorporar al marco de trabajo dicha soluci´on fuertemente reutilizable. Figura 4.42: Implementaci´on del servidor OPC-HDA para WebBox 4.4. Marco de trabajo para la generaci´on de servidores OPC-HDA 69 Para ello la propuesta que se hace es crear una clase que d´e soporte para el tratamiento de datos en formato de ficheros y se utilizar´a, haciendo uso de la herencia, como base de la implementaci´on final. En este caso ser´a la clase TmlCustomFilesHDAServer, figura 4.42. En la figura 4.42 puede verse la clase desarrollada para el marco de trabajo fruto de su detecci´on durante la fase de desarrollo de un nuevo servidor OPC-HDA. Esta situaci´on hace patente que la recogida de requisitos al inicio de un proyecto ha llegado a no ser importante en estos ´ultimos tiempos, donde las nuevas metodolog´ıas ´agiles, como la que se ha utilizado para el desarrollo de este marco de trabajo, se centran en la capacidad de adaptaci´on al cambio o incorporaci´on eficiente de requisitos en un proyecto ya comenzado. Figura 4.43: Implementaci´on del servidor OPC descarga de ficheros de los inversores 76 5. Caracterizaci´on y modelizado de sistemas energ´eticos Figura 5.1: Esquema de los elementos que componen una instalaci´on la planta y para implementar los modelos de evaluaci´on y predicci´on de los sistemas. Algunas de las medidas virtuales que se han definido a partir de los datos registrados para el citado sistema fotovoltaico podr´ıan ser: eficiencia del inversor, energ´ıa diaria producida, rendimiento de la planta, etc. En la jerarqu´ıa se puede apreciar que no solo los dispositivos disponen de canales o medidas de informaci´on, sino que tambi´en una instalaci´on o una agrupaci´on de dispositivos puede definir sus propios canales de informaci´on como medidas asociadas. Esto significa que cada uno de estos elementos de la jerarqu´ıa propuesta puede tener sus propias medidas, tanto registradas como estimadas o virtuales. El elemento dispositivo tiene, por una parte, toda la informaci´on descriptiva del mismo, tal como nombre, tipo de dispositivo o planta en la que est´a instalado. Un dispositivo se modela como un elemento que tiene varias medidas que a su vez pueden tener simult´aneamente una lista de elementos. De esta forma es posible modelizar un dispositivo utilizando la composici´on de dispositivos; y se puede incluso crear alg´un elemento abstracto partiendo de un conjunto de dispositivos (como puede ser, por ejemplo, una medida estimada sobre alg´un par´ametro de evaluaci´on del conjunto de dispositivos). Este tipo de elemento abstracto se utiliza para almacenar los modelos de evaluaci´on y predicci´on de las instalaciones al igual que si se tratase de un dispositivo real, lo que facilita los resultados de la evaluaci´on a trav´es de sus canales de informaci´on, reduciendo as´ı la complejidad del c´odigo necesario para implementar esta funcionalidad. Los dispositivos pueden ser agrupados en secciones. Varias secciones conforman una instalaci´on y, finalmente, una o m´as instalaciones dan lugar a lo que se ha denominado como grupo de instalaciones. Esta ´ultima agrupaci´on es muy ´util cuando un mismo usuario tiene m´as de una instalaci´on, de manera que el marco de trabajo permite generar aplicaciones para mantener toda la informaci´on de distintas plantas con la misma aplicaci´on y asociados a la misma cuenta de usuario. 5.1. Introducci´on 77 Esta organizaci´on de los elementos de una planta proporciona una correspondencia entre una planta real y el modelo de planta que se construye en el marco de trabajo. La representaci´on de un sistema se puede realizar mediante las siguientes reglas: Grupo de instalaciones →Instalaci´on |Grupo de instalaciones Instalaci´on ; Instalaci´on →Secci´on |Instalaci´on Secci´on ; Secci´on →Dispositivo |Secci´on Dispositivo ; Dispositivo →Medida |Dispositivo Medida ; Para cada uno de esos elementos se pueden especificar las medidas asociadas. As´ı por ejemplo, para el elemento Instalaci´on, las medidas asociadas se podr´ıan representar de la siguiente forma (r: medidas registradas, v: medidas estimadas) Medidas registradas a nivel de Instalaci´on, Instalacion.ri, corresponden a las i medidas que pueden registrarse para una Instalaci´on. Medidas virtuales estimadas para una Instalaci´on, Instalacion.vj, son las jmedidas que se calculan a partir de otras medidas de la Instalaci´on, y que pueden ser funci´on de una o m´as de las siguientes medidas: Seccion.rk, Seccion.vl, Dispositivo.rm, Dispositivo.vn, medida.rp, medida.vq Como ejemplo de posibles medidas asociadas a una instalaci´on podr´ıan ser aquellas donde un dispositivo devolviese un valor que afectase a la instalaci´on por completo como temperatura ambiente,E contador (si hubiera un contador general que registrara toda la energ´ıa generada por la Instalaci´on), etc.; las posibles medidas estimadas para una instalaci´on podr´ıan ser: Potencia total, que se calcular´ıa como suma de las potencia de todos los generadores que haya en la instalaci´on, Rendimiento diario, calculado a partir del balance energ´etico diario de la instalaci´on, etc. Tambi´en se pueden definir medidas virtuales para almacenar informaci´on de la instalaci´on necesaria para su correcta gesti´on, como puede ser latitud ylongitud del emplazamiento, etc. As´ı, de los elementos descritos, los dispositivos suelen ser los que registran los datos f´ısicos de la instalaci´on (medidas f´ısicas de par´ametros reales, como puede ser potencia, intensidad, etc.). Pero todos ellos pueden tener asociada informaci´on que no corresponda con las medidas f´ısicas pero que sea ´util para describir caracter´ısticas de los mismos. Esta informaci´on se almacena en forma de lo que se ha denominado medida virtual o 78 5. Caracterizaci´on y modelizado de sistemas energ´eticos calculada. En un apartado posterior se definen detalladamente todos los tipos de medida que se han contemplado en el marco de trabajo. Cada medida (real o virtual) ir´a siempre asociada a uno de los elementos enumerados anteriormente. 5.2. Modelizado y gesti´on de usuarios En el momento que existe la posibilidad de desarrollar un sistema que puede ser usado por diferentes personas aparece la necesidad de establecer criterios o restricciones para el acceso de la informaci´on que dependa del rol de la persona que est´a accediendo al mismo. La inclusi´on de la funcionalidad que permita modelizar diferentes roles con el marco de trabajo proporciona que un determinado usuario disponga de diferentes privilegios frente a diferentes sistemas a gestionar. Cada usuario ser´a ´unico en el sistema y se autenticar´a con un nombre de usuario y una contrase˜na. Un usuario dispondr´a de capacidad de asociaci´on con un grupo de instalaciones por diferentes roles y as´ı podr´a disponer de diferentes roles dependiendo de las instalaciones o sistemas a las que tenga acceso. Se han definido los siguientes tipos de roles o perfiles: Administrador: los usuarios con este perfil tienen acceso a todos los sistemas y puede realizar cualquier tarea dentro del marco de trabajo. Gestor: los usuarios con este perfil dispondr´an de acceso a un grupo de instalaciones, permitiendo de esta manera, que un mismo usuario tenga acceso y control con sus mismos datos de acceso a varias instalaciones. El marco de trabajo proporciona las clases e interfaces apropiadas para modelizar el almacenamiento de los roles al mismo, siendo adem´as posible extenderlas proporcionando nuevas funcionalidades a la hora de utilizarlas. Primeramente se ha creado una clase ISMDBUsers que contendr´a la lista de usuarios y permitir´a gestionar y proporcionar a los usuarios del marco de trabajo la gesti´on con usuarios, figura 5.2. Esta clase soporta el interfaz IUsers que implementa el modelizado de dicho comportamiento. Adem´as, dispone de los mecanismos de persistencia para poder almacenar y recuperar la informaci´on de la base de datos asociada al marco de trabajo siguiendo un modelo relacional mostrado en el cap´ıtulo 6. 5.2. Modelizado y gesti´on de usuarios 79 Figura 5.2: Clases para el modelizado de usuarios Cada usuario dispone de propiedades para almacenar la informaci´on m´as relevante. Esta clase puede extenderse siempre que se implemente las funcionalidades del interfaz correspondiente. En la figura 5.3 se muestran las clases para el caso IISMDBUser. Figura 5.3: Clases para el modelizado de un usuario Puede verse que un usuario puede relacionarse con un grupo de instalaciones sobre las que tendr´a permisos para acceder y gestionar a trav´es de la propiedad InstallationGroup 80 5. Caracterizaci´on y modelizado de sistemas energ´eticos 5.3. Modelizado de una instalaci´on energ´etica Para la utilizaci´on del marco de trabajo en la gesti´on de sistemas energ´eticos, una de las tareas fundamentales que se deben poder realizar de manera sencilla es el modelizado de cada sistema que se vaya a gestionar. Este modelizado debe permitir definir todos los dispositivos que lo integran y la asociaci´on del sistema a uno o m´as usuarios con su rol determinado. Para ello se parte de una jerarqu´ıa gen´erica para m´as adelante ver las posibilidades de extensi´on, figura 5.4. Figura 5.4: Modelizado de una instalaci´on gen´erica basada en interfaces Cada sistema energ´etico, al igual que el grupo de sistemas, dispondr´a de la capacidad de modelizar medidas asociadas a este independientemente de las medidas de los dispositivos. Una vez que se ha modelizado un sistema o instalaci´on, es necesario modelizar cada uno de los subsistemas que lo integran. Un sistema energ´etico o instalaci´on se puede considerar que est´a formado por elementos cada uno con una capacidad de generaci´on, adquisici´on o procesamiento de datos. Estos elementos aunque dispersos f´ısicamente forman la instalaci´on oagrupaci´on de instalaciones. Tambi´en se ha implementado un mecanismo de asociaci´on para permitir que un sistema disponga de asociaciones transversales. De esta manera, se pueden asociar diferentes dispositivos en diferentes secciones para rese˜nar que existe una relaci´on f´ısica u organizativa entre ambos; por ejemplo, en el caso de una instalaci´on de energ´ıa solar fotovoltaica, un inversor y su contador de energ´ıa o una placa fotovoltaica y el inversor que recoge la energ´ıa que produce. Una vez se ha descrito el sistema que se propone para modelizar todo el sistema conceptual de una instalaci´on real, se analizan ahora los elementos f´ısicos de los sistemas energ´eticos. El elemento f´ısico b´asico que se va a modelizar es el dispositivo, que es el componente por excelencia dentro de un sistema energ´etico. En los sistemas energ´eticos existen multitud de clases diferentes de dispositivos y con objetivos diferentes como pueden ser registradores de datos, inversores, m´odems, sistemas de adquisici´on de datos, conversores, sensores de temperatura, c´elulas calibradas o piran´ometro para medir radiaci´on, etc. Por otra parte, el dispositivo mantiene toda la informaci´on descriptiva del elemento que describe como pueden ser el nombre, la clase de dispositivo, descripci´on y instalaci´on a la que pertenece, entre otras. 5.3. Modelizado de una instalaci´on energ´etica 81 En la figura 5.5 se muestran la clase e interfaces que modelan una instalaci´on. Figura 5.5: Modelo de una instalaci´on 82 5. Caracterizaci´on y modelizado de sistemas energ´eticos Siguiendo las directrices y metodolog´ıa de desarrollo expuestas en el cap´ıtulo 3, se ha definido el marco de trabajo basando su estructura en interfaces y dise˜nando las clases que los implementan. De esta manera es sencillo a˜nadir nuevas clases a la estructura siempre y cuando se implementen el comportamiento que define la interfaz. As´ı, en la figura 5.6 se muestra la capacidad de particularizaci´on al poder hacer uso de la herencia y adaptar las clases para instalaciones t´ermicas o solares ISMDBFVInstallation o IISMDBTermalInstallation. Figura 5.6: Creaci´on de nuevos tipos de instalaciones haciendo uso de la herencia de interfaces Observando la implementaci´on, figura 5.7 se comprueba c´omo la propia instalaci´on puede disponer de sus propias medidas o canales de informaci´on IISDBMeasures definidas por lo general como medidas virtuales o calculadas a partir de medidas de los dispositivos. Figura 5.7: Grupos de instalaciones y relaci´on con los usuarios del marco de trabajo Tambi´en se observa c´omo este modelizado permite agrupar instalaciones a trav´es del interfaz IISMDBGroup y c´omo su relaci´on con el interfaz IISMDBUser establece la asociaci´on entre usuario-instalaciones. Se aprecia la referencia circular de la interfaz que modela la agrupaci´on de instalaciones permitiendo tener tantos niveles de grupos como sean necesarios. 5.4. Modelizado y caracterizaci´on de grupos de dispositivos 83 5.4. Modelizado y caracterizaci´on de grupos de dispositivos Para muchos sistemas es necesario disponer de la facultad de poder organizar o agrupar los dispositivos que forman parte de los mismos, ya sea porqu´e est´an f´ısicamente organizados de una manera determinada, ya sea porqu´e es interesante disponer de medidas o canales en las que se vean involucrados una serie determinada de dispositivos. Para dar respuesta a esta necesidad, a una asociaci´on de dispositivos se la denomina secci´on y representar´a a un conjunto de dispositivos y a un conjunto de posibles medidas o canales que por su naturaleza pueden representar informaci´on sobre los dispositivos que asocia. En el diagrama de clases asociado que se muestra en la figura 5.8 puede verse la clase TISMDBSection que implementa el interfaz IISMDSection. ´ Este a su vez dispone de un conjunto de dispositivos o sistemas IISMDBSystem y una referencia a un grupo de medidas ISMDBMeasures. Figura 5.8: Modelo de un grupo de dispositivos Se ha establecido adem´as la posibilidad de enlazar por medio de la referencia a ISMDBSystemAsocs de asociaciones entre grupos de dispositivos o secciones, seg´un se muestra en la figura 5.9. Esta funcionalidad ha sido necesaria introducirla para establecer una relaci´on entre dispositivos que por su funci´on deben trabajar juntos pero forman parte de una secci´on donde existen muchos m´as dispositivos. 84 5. Caracterizaci´on y modelizado de sistemas energ´eticos Figura 5.9: Asociaci´on de dispositivos 5.5. Modelizado y caracterizaci´on de dispositivos Los elementos que se han tratado son conceptos abstractos y organizativos de los dispositivos que finalmente forman parte de una instalaci´on. Estos ´ultimos son los que al final se trasladan en elementos f´ısicos y reales que procesan y generan informaci´on. Los dispositivos o sistemas que forman parte de una instalaci´on pueden ser de diferente ´ındole y disponer de diferentes canales de informaci´on o medidas. Teniendo en cuenta la heterogeneidad que existe respecto a los dispositivos que forman parte de una instalaci´on se ha definido la estructura de clases e interfaces que se muestra en la figura 5.10 Cada dispositivo o sistema mantiene una referencia con la instalaci´on a la que pertenece. Puede verse en la declaraci´on del interfaz la referencia circular a otros posibles dispositivos para tratar el caso que se ha rese˜nado en el apartado anterior. El mecanismo de herencia que proporciona la programaci´on orientada a objetos permite particularizar el interfaz de dispositivo para adaptarlo a dispositivos particulares que no puedan ser tratados, por su naturaleza y caracter´ısticas, de manera gen´erica. As´ı, es posible declarar, partiendo de la interfaz gen´erica, diferentes dispositivos con sus propias particularidades. En este caso y por ejemplo c´elulas de radiaci´on, generadores, inversores o contadores el´ectricos. En la figura 5.11 se muestra, a modo de ejemplo, la utilizaci´on de clases e interfaces declaradas en el marco de trabajo para la definici´on de un dispositivo de tipo inversor. Simplemente heredando (y de esta manera implementando el interfaz apropiado), se puede extender la clase sistema, que representa a un dispositivo, para definir un inversor con los m´etodos y propiedades que sean necesarios. 5.5. Modelizado y caracterizaci´on de dispositivos 85 Figura 5.10: Modelado de un dispositivo o sistema Figura 5.11: Modelado de un dispositivo tipo invesor 92 5. Caracterizaci´on y modelizado de sistemas energ´eticos del interfaz IObserver [7.3] los cambios producidos en el valor de la medida o de su timestamp. En el caso de detectar una cambio lanzar´a la ejecuci´on del script que actualizar´a el valor de la medida teniendo en cuenta los valores de las diferentes medidas reales o virtuales asociadas a dicho script. 5.7. Conclusiones En este cap´ıtulo se ha propuesto un modelizado basado en clases e interfaces para un sistema energ´etico completo que permite efectuar consideraciones sobre el modelo tal y como se har´ıa sobre el sistema real. Este modelizado hace posible disponer de una representaci´on l´ogica de un sistema f´ısico real y da respuesta a la complejidad de detalles que hay que tener en cuenta para este tipo de modelizado. Se ha hecho tambi´en una propuesta para modelizar los elementos que conforman un sistema energ´etico, desde la instalaci´on de manera general hasta las medidas o puntos de informaci´on pasando por los diferentes dispositivos as´ı como los posibles niveles de acceso o usuarios que tienen alguna capacidad de gesti´on sobre la planta. Se ha propuesto, finalmente, un modelizado adecuado para las medidas, que son la ´ultima informaci´on y, en definitiva, m´as importante, ya que son las responsables de disponer de los par´ametros de funcionamiento de las instalaciones, y por lo tanto su gesti´on y su capacidad de configuraci´on son quiz´as la parte m´as importante al basarse toda la informaci´on y toma de decisiones en el contenido de las mismas. “La belleza es m´as importante en inform´atica que en ninguna otra tecnolog´ıa debido a la gran complejidad del software. La belleza es la defensa definitiva contra la complejidad” – David Gelernter 6 Capa de almacenamiento y persistencia de la informaci´on 6.1. Introducci´on Para cada sistema que se quiera desarrollar es necesario almacenar informaci´on, no solo de los datos registrados sino tambi´en de la configuraci´on de la planta que se gestiona, dispositivos que incorpora, agrupaci´on de instalaciones, perfiles de usuarios, etc. Por ello, es necesario utilizar una base de datos para mantener esa informaci´on, tal y como se detallaba en la arquitectura propuesta en el cap´ıtulo 3. En concreto, ser´a necesario almacenar: Datos: contendr´a los datos instant´aneos almacenados por los dispositivos y los datos calculados en forma de datos diarios y datos globales. Caracter´ısticas de los elementos del sistema: incorporar´a todos los datos referentes a las plantas, los grupos, los inversores. Eventos: almacenar´a los diferentes eventos y alarmas que se produzcan en los diferentes dispositivos. Roles de usuario y permisos, para controlar los accesos a los distintos sistemas. Para ello, una posible organizaci´on de esta informaci´on es la siguiente: •Datos de cada usuario (nombre, contrase˜na, rol asociado a cada planta, etc..) 93 94 6. Almacenamiento y persistencia de la informaci´on •Tipos de roles: consulta de una o m´as plantas y administrador. El rol de consulta servir´a para dar acceso a la informaci´on de las plantas (eventos, datos instant´aneos, diarios, informaci´on de las plantas, etc.). El rol de administrador permitir´a ver la informaci´on de todas las plantas y gestionar los usuarios. Para hacer persistente el modelizado de toda esta informaci´on se propone la utilizaci´on de sistemas gestores de bases de datos compatibles con el est´andar SQL92. De esta manera y al hacerlo de manera gen´erica, la base de datos de almacenamiento puede ser elegida en cada caso para permitir una mayor flexibilidad. En este caso, todo el desarrollo se ha realizado para su utilizaci´on con el SGBD de fuentes abiertas PostgreSQL. Desde un comienzo se pens´o en la utilizaci´on e incorporaci´on de marcos de trabajo para la persistencia de clases disponibles de manera libre pero el rendimiento no era el apropiado ya que la frecuencia de almacenamiento de la informaci´on podr´ıa llegar a ser muy exigente debido, en muchos casos, a la cantidad de datos que provienen de los dispositivos. Por esta raz´on se ha generado un modelo entidad-relaci´on propio y asociado a cada clase. Esta modificaci´on no entra en conflicto con la facilidad y flexibilidad de poder extender las clases con nuevos atributos persistentes al primar un alto grado de exigencia en la organizaci´on del c´odigo fuente del marco de trabajo desarrollado. 6.2. Modelo de persistencia del modelizado de usuarios y perfiles de acceso La informaci´on correspondiente a los usuarios, los roles y la correspondencia con cada instalaci´on dispone de una persistencia en base de datos a trav´es del modelo entidad-relaci´on mostrado en la figura 6.1. Hay que destacar que en este modelo propuesto cada usuario puede disponer de un rol determinado para cada instalaci´on y a su vez cada rol tendr´a disponible una serie de servicios que estar´an disponibles dentro del marco de trabajo. Con este modelizado, el sistema puede almacenar dicha informaci´on y recuperarla de manera sencilla cuando se invoca cada instancia de cada clase. En la figura 6.2 puede verse una implementaci´on con la utilizaci´on de la clase de definici´on de usuarios donde dicha informaci´on se almacena y recupera de la base de datos. 6.3. Modelo de persistencia del modelizado de instalaciones 95 Figura 6.1: Modelo de almacenamiento en base de datos de usuarios 6.3. Modelo de persistencia del modelizado de instalaciones Para proporcionar persistencia de almacenamiento de las instalaciones se ha desarrollado el modelo que se muestra en la figura 6.3. En este caso, es necesario almacenar la informaci´on de cada instalaci´on y la forma de agrupaci´on en grupos y secciones de dispositivos. El modelo soporta las relaciones para establecer una integridad referencial y as´ı permitir operaciones y modificaciones en cascada. En la figura 6.4 se muestra la aplicaci´on de la instanciaci´on de grupos y en la figura 6.5 su asociaci´on con instalaciones utilizando las clases proporcionadas por el marco 96 6. Almacenamiento y persistencia de la informaci´on Figura 6.2: Interfaz para la administraci´on de usuarios de trabajo y el modelo entidad relaci´on para su almacenamiento y recuperaci´on de la base de datos utilizada. Figura 6.4: Implementaci´on de grupos de instalaciones 6.3. Modelo de persistencia del modelizado de instalaciones 97 Figura 6.3: Modelo de almacenamiento en base de datos de instalaciones Figura 6.5: Agrupaci´on de instalaciones 98 6. Almacenamiento y persistencia de la informaci´on 6.4. Modelo de persistencia del modelizado de dispositivos Para poder almacenar la informaci´on referente a los dispositivos modelizados de una planta determinada se propone el uso del modelo entidad relaci´on que se muestra en la figura 6.6. Figura 6.6: Modelo de almacenamiento en base de datos del modelizado de dispositivos Seg´un esta propuesta, un dispositivo estar´a asociado a un grupo de dispositivos o secci´on y el dispositivo ser´a de un tipo o clase determinada. El asociar los atributos o medidas de un dispositivo a una clase de dispositivo en lugar de una instancia permite que se pueda reutilizar el modelizado de un dispositivo tantas veces como apariciones reales de dicho disposito ocurran en una planta real sin tener que volver a definir sus canales. Las medidas y los dispositivos asociados son elementos que es necesario modelizar muy frecuentemente. Por ello, el marco de trabajo proporciona un repositorio de medidas ydispositivos perfectamente modelizados. Este repositorio se puede utilizar cuando se definen y a˜naden nuevos dispositivos durante el modelizado de una planta, sin necesidad de volver a definirlos cada vez. Adem´as, es f´acil crear nuevos dispositivos a partir de los que ya existan. Los dispositivos que se pueden incluir son de diferentes clases que, por ejemplo, en dispositivos para sistemas de energ´ıa solar podr´ıan ser: inversores, generadores, contadores de energ´ıa, c´elulas para medir radiaci´on, piran´ome- 6.5. Almacenamiento de los canales de dispositivos 99 tros, sensores de temperatura y sistemas de adquisici´on de datos locales, entre otros. Este repositorio permitir´a la inclusi´on de nuevos dispositivos y medidas relacionados con los predefinidos lo que supondr´a que el dise˜no de una nueva aplicaci´on de gesti´on energ´etica se pueda hacer de forma m´as r´apida a partir de ese repositorio. En la figura 6.7 puede verse una librer´ıa de dispositivos modelizada en base a clases de dispositivos y con canales ya definidos. Al encontrarse este repositorio en la propia base de datos, se pueden reutilizar los dispositivos definidos desde cualquier aplicaci´on que haga uso de este marco de trabajo para la construcci´on de aplicaciones de gesti´on energ´etica. Figura 6.7: Librer´ıa de dispositivos modelizados 6.5. Almacenamiento de la informaci´on de los canales de los dispositivos Uno de los retos a la hora de desarrollar el marco de trabajo ha sido la forma de almacenar gran cantidad de datos, en algunos casos, a alta frecuencia. La informaci´on que proviene de los dispositivos puede ser informaci´on hist´orica o informaci´on en tiempo real. En el caso de informaci´on hist´orica, el almacenamiento puede realizarse a baja frecuencia debido a que se dispone de la informaci´on en el dispositivo durante un 100 6. Almacenamiento y persistencia de la informaci´on relativo largo periodo de tiempo. Sin embargo en casos de informaci´on en tiempo real, los dispositivos generan informaci´on que es necesario almacenar cuanto antes. Adem´as es necesario que tener en cuenta que la informaci´on a almacenar puede ser de diferente tipo por lo que no es posible tratarla toda de la misma manera. De manera formal se puede ver la informaci´on a almacenar de la manera que se describe a continuaci´on. Si se denominan todos los dispositivos de una instalaci´on dada como d1, ..., dkse tendr´a que: ∀di∃(di, ti, vi) (6.1) donde tirepresenta un instante determinado en el tiempo y viun valor asociado a dicho dien ese instante ti. Cada valor puede ser de un tipo determinado como n´umeros enteros, valores flotantes, valores booleanos o incluso cadenas de caracteres, por lo que su almacenamiento tendr´a que realizarse de manera diferente sin sacrificar rendimiento. Por ello, la soluci´on adoptada ha sido la disposici´on al marco de trabajo de tablas espec´ıficas para el almacenamiento de dicha informaci´on, figura 6.8. De esta manera, cada canal conoce el tipo de informaci´on y almacenar´a y recuperar´a dichos valores de la tabla apropiada logrando una alta frecuencia de almacenamiento en la base de datos. 6.6. Mecanismo de sincronizaci´on para el almacenamiento de los canales de los dispositivos El poder disponer del estado de una instalaci´on en cualquier momento dado es una ventaja importante para estudiar su funcionamiento actual e incluso para poder inferir algunos par´ametros sobre el comportamiento futuro. En muchas ocasiones es sencillo que se disponga de toda la informaci´on pero ocurren situaciones que en las que no se puede controlar cuando se quiere recuperar la informaci´on de todos los dispositivos y por alguna raz´on esto no es posible. Es entonces cuando se hace necesario disponer de mecanismos para tener la capacidad de recuperar la informaci´on de cualquier estado en el que ha estado la planta. Existen por supuesto, algunas limitaciones como que ocurran problemas o cortes de comunicaci´on entre los dispositivos que proporcionan valores en tiempo real, pero si el dispositivo dispone de una memoria interna o dichos dispositivos son registradores de datos es posible implementar alg´un mecanismo inteligente para disponer de la informaci´on de la forma m´as coherente y precisa posible. 6.6. Mecanismos de sincronizaci´on de dispositivos 101 Figura 6.8: Almacenamiento de datos de diferentes tipos medidas En el marco de trabajo desarrollado se ha implementado de manera transparente, un algoritmo de sincronizaci´on lo suficientemente vers´atil para poder reanudar la descarga y mantener la informaci´on lo m´as fiable posible ante causas que en alg´un momento no permitan descargar la aplicaci´on. Estos casos pueden llegar a ser muy comunes cuando se realizan conexiones a dispositivos a trav´es de tecnolog´ıas m´oviles o dichos dispositivos se encuentran en puntos geogr´aficamente complicados causando problemas en las comunicaciones. El proceso de sincronizaci´on se divide en dos niveles, partiendo de la cola de sincronizaciones, que es el nivel m´as externo, hasta llegar a la sincronizacion de un d´ıa para una medida concreta, que corresponde al nivel mas interno. As´ı, el proceso se puede desglosar de la siguiente manera: A un nivel superior se utiliza el algoritmo del sincronizador. Este es el algoritmo de funcionamiento del programa encargado de atender las peticiones de sincronizaci´on de las instalaciones seg´un una cola de planificaci´on (Fig. 6.9). 108 6. Almacenamiento y persistencia de la informaci´on 6.7. Conclusiones Una vez modelizada la instalaci´on, la informaci´on de la misma, tanto de su modelo como del contenido de los datos que representan su funcionamiento, debe poder ser almacenada y recuperada de manera eficiente. La utilizaci´on en este caso de una capa espec´ıfica para dotar de persistencia a la informaci´on en bases de datos y la utilizaci´on de sistemas gen´ericos para realizarla permite disponer de m´ultiples opciones para la utilizaci´on de los sistemas que m´as convengan en cada caso. Opciones como la utilizaci´on de sistemas gestores de bases de datos basados en fuentes abiertas, como PostgreSQL o MariaDB, o incluso licenciados como Oracle, abren un abanico de opciones sin tener una dependencia a priori con el sistema a utilizar. Por otra parte, se han expuesto una serie de algoritmos que garantizan disponer en todo momento de la m´axima informaci´on posible de los dispositivos, lo que se hace independientemente de que en los casos reales, multitud de problemas relacionados con protocolos, fallos de comunicaci´on, sistemas de comunicaci´on ineficientes o con ruido pueden ser despreciados, garantizando una coherencia en la informaci´on y en los datos. Esto es realmente importante si se quiere tener una idea de c´omo se comporta el sistema o incluso a la hora de inferir informaci´on o realizar evaluaciones o predicciones de las instalaciones que se est´an gestionando. “Cualquier bug lo suficientemente avanzado es indistinguible de una funcionalidad” – Rich Kulawiec 7 Capa de soporte a la implementaci´on 7.1. Introducci´on Dentro de un marco de trabajo aparecen multitud de relaciones y referencias entre objetos que pueden hacer que la complejidad e interrelaci´on entre los mismos se haga muy complicada, causando adem´as un problema al disponer de un sistema altamente acoplado. Adem´as, en los lenguajes de programaci´on de mayor rendimiento, los sistemas de tipado fuerte hacen que haya que estar continuamente asociando los tipos de los objetos y la inclusi´on de nuevas referencias han de pasar por fuerza porque dichos tipos sean compatibles. 7.2. Sistema de selecci´on gen´erica Para evitar estos casos, en este trabajo se propone que la comunicaci´on entre clases se realice traspasando una interfaz gen´erica, figura 7.1. De esta manera, solo en destino es necesario comprobar si dicha instancia implementa la interfaz necesaria y evita pasar y definir tipos que sean compatibles para conseguir con ´exito la compilaci´on del sistema. As´ı, cualquier clase que quiera disponer de la funcionalidad de poder facilitar a otra una referencia a cualquier otra clase podr´a hacerlo implementando el interfaz ISelection. Se proporciona adem´as una clase que implementa esa interfaz para que cualquier otra clase pueda implementar por delegaci´on de interfaz el interfaz ISelection. 109 110 7. Capa de soporte a la implementaci´on Figura 7.1: Selecci´on gen´erica Una instancia que, por ejemplo, tenga un conjunto de objetos de tipo dispositivo o un conjunto de usuarios no necesitar´an declarar esa lista de objetos de manera diferente, sino que utilizando la misma implementaci´on guardar´a los interfaces de esas clases y cuando otro objeto tenga la necesidad de utilizarlos simplemente mirar´a si los objetos implementan la interfaz deseada y si es as´ı tendr´a los objetos que desea. Esta soluci´on se puede realizar en los lenguajes de programaci´on modernos haciendo uso de los templates pero tienen como inconveniente que en tiempo de preprocesamiento, antes de la compilaci´on, el c´odigo se duplica para cada tipo diferente por lo que hace que los programas crezcan y no sean igual de eficientes que la soluci´on que se plantea en este trabajo. 7.3. Sistema Sujeto-Observador En marco de trabajo desarrollado, la comunicaci´on entre las clases se realiza bajo eventos. Con los eventos es posible eliminar los algoritmos iterativos ya que la ejecuci´on de los m´etodos de las clases se ejecutan bajo ciertas circunstancias. Realizar una implementaci´on de mecanismos de eventos en cada clase puede llegar a ser muy costosa y compleja por lo que el marco desarrollado facilita la interacci´on entre clases usando eventos, proporcionando clases e interfaces reutilizables para esta tarea. 7.3. Sistema Sujeto-Observador 111 Para implementar esta funcionalidad se ha realizado una modificaci´on del patr´on sujeto-observador utilizando interfaces. Por un lado se cuenta con el interfaz ISubject proporcionando, a la clase que lo implemente, poder ser observado y avisar sobre cualquier evento a la clases que lo observen. Se proporciona adem´as una clase que implementa dicha interfaz (Fig. 7.2) para facilitar su inclusi´on por agregaci´on y delegaci´on de la implementaci´on de dicha interfaz siguiendo los mecanismos explicados en el apartado 3.4.4.. Figura 7.2: Interfaz sujeto observable ISubject Por otro lado se tiene el interfaz IObserver que permite, a las clases que lo implementan, observar las clases que implementan el interfaz ISubject y recibir notificaciones de las mismas, figura 7.3. Figura 7.3: Interfaz IObserver De esta manera, no es necesario estar comprobando variables ni estados de las clases de manera s´ıncrona. En el momento que se crean las diferentes instancias de las clases, se establecen los enlaces entre sujetos y observadores y los cambios producidos en ciertas instancias producir´an eventos sobre las instancias que los observan disponiendo as´ı de un mecanismo de notificaci´on de eventos totalmente as´ıncrono. Con esta propuesta se consigue reducir mucho la carga del marco de trabajo y se proporciona una manera elegante y clara de producirse flujos de informaci´on y eventos. 112 7. Capa de soporte a la implementaci´on 7.4. Sistema de acciones y comandos La interacci´on con el usuario es siempre una funcionalidad deseable en cualquier sistema por muy automatizado que se encuentre. Existen multitud de soluciones para separar la parte de los datos, la l´ogica de negocio y la interfaz del usuario como los patrones basados en Modelo-Vista-Controlador que buscan la separaci´on de conceptos y reutilizaci´on de c´odigo en la arquitectura del software. Debido a que el marco de trabajo desarrollado est´a basado en interfaces software, se ha visto la oportunidad de poder conectar dichas definiciones de procedimientos o propiedades con el interfaz gr´afico de una manera sencilla registrando la asociaci´on de definici´on de interfaz con acciones del interfaz de usuario. De esta manera es sencillo incorporar a las aplicaciones desarrolladas con este marco de trabajo acciones asoci´andolas simplemente a los objetos a los que se quiere dotar de acciones o comandos determinados, figura 7.4. Figura 7.4: Modelado de comandos El interfaz ICommand facilita la creaci´on dentro del sistema de comandos que podemos asociar a cualquier instancia como se muestra en la figura 7.5. A su vez, cada comando puede estar agrupado en diferentes categor´ıas permitiendo al interfaz de usuario mostrar los comandos agrupados para una mejor experiencia del usuario, figura 7.6. En esta figura puede verse c´omo integrar un menu contextual con el sistema de comandos para que los muestre de manera gr´afica. As´ı, dado un objeto que soporte una selecci´on de instancias de objetos, se le aplicar´a la lista de comandos que son compatibles con las interfaces que soporte. 7.4. Sistema de acciones y comandos 113 Figura 7.5: Modelado de categor´ıas de comandos En la figura 7.7 puede verse c´omo el marco de trabajo aplica autom´aticamente, sobre los objetos seleccionados, los comandos disponibles en el sistema, permitiendo incluso diferentes representaciones visuales de los mismos. En este caso un men´u contextual y un panel de acciones para representar las mismas acciones disponibles. 114 7. Capa de soporte a la implementaci´on Figura 7.6: Sistema de comandos Figura 7.7: Sistema de comandos 7.5. Sistema din´amico de propiedades 115 7.5. Sistema din´amico de propiedades Cada vez que se define una clase con programaci´on orientada a objectos o incluso en otros paradigmas de programaci´on, es necesario conocer la estructura de la misma y sus atributos. Esto hace que en todo momento se disponga de una dependencia entre los tipos, atributos y m´etodos y las dem´as clases que se relacionan con ellas y que conozcan esta estructura en tiempo de compilaci´on. Una desventaja evidente es la poca flexibilidad que ofrece esta condici´on ya que la inclusi´on de nuevos atributos en las clases ya definidas pasa por modificar en tiempo de dise˜no los desarrollos. Para dar respuesta a esta situaci´on, en este trabajo se proporciona al marco de trabajo de un mecanismo de extensi´on en tiempo de ejecuci´on, lo que es una ventaja y mejora a˜nadida al permitir que las clases se construyan y modifiquen en el momento de su utilizaci´on. En la figura 7.8 pueden verse los interfaces que pone a disposici´on el marco de trabajo para que las clases que se utilicen puedan se extendidas en tiempo de ejecuci´on. Cada clase puede hacer uso de una lista de propiedades IProps y definir nuevas propiedades o atributos con diferentes niveles de acceso (solo lectura, solo escritura o de lectura/escritura). Figura 7.8: Sistema din´amico de propiedades 116 7. Capa de soporte a la implementaci´on Disponer de esta funcionalidad proporciona una flexibilidad que elimina la limitaci´on de tener que modificar las clases codificadas, ya que permite a˜nadir nuevos atributos a las mismas en tiempo de ejecuci´on y las clases relacionadas o dependientes pueden consultar dichos atributos en el momento apropiado. Cada propiedad dispone a su vez de la capacidad de ser observada (v´ease 7.3) por lo que se a˜nade adem´as la funcionalidad de ser notificado por el cambio de los valores de dichos atributos. 7.6. Sistema din´amico de configuraci´on La arquitectura de clases anteriormente presentada permite modelizar un servidor OPC para cada dispositivo con la condici´on de conocer el protocolo de intercambio de informaci´on con el mismo. Sin embargo existe todav´ıa una funcionalidad importante que debe ser implementada y est´a relacionado con los par´ametros de configuraci´on del protocolo y el dispositivo. Ser´a, por ejemplo, necesario facilitar al sistema los par´ametros de conexi´on f´ısicos, si la comunicaci´on es con un dispositivo por medio de un puerto serie, o el n´umero de tel´efono, si es a trav´es de una l´ınea telef´onica. Para facilitar esta funcionalidad, se ha tenido en cuenta que el marco de trabajo proporcione una serie de clases de ayuda as´ı como un flujo de comportamiento para indicar y facilitar los par´ametros de configuraci´on de cada servidor OPC que se desea desarrollar, figura 7.9. Figura 7.9: interfaz para la implementaci´on del sistema de configuraciones din´amico As´ı, para cada caso que se deba disponer de la capacidad de proporcionar par´ametros de configuraci´on, se heredar´a del interfaz IConfiguration. En la figura 7.10 se muestra c´omo proporcionar los par´ametros de configuraci´on de un dispositivo que necesita configurar su puerto de comunicaciones serie.Como es una situaci´on muy com´un, se ha creado un servidor OPC gen´erico que permite la comunicaci´on con dispositivos por el puerto de comunicaciones serie, al que se ha denominado TCustomOPCSerialServer. 7.6. Sistema din´amico de configuraci´on 117 Figura 7.10: Configuraci´on del puerto de comunicaciones serie Este clase tendr´a un componente que se encargar´a de la gesti´on directamente con el puerto de comunicaciones, en este caso TmlDialer, e implementar´a adem´as el interfaz IConfiguration, que es un componente que puede ser externamente configurado. Cuando el sistema encuentra una clase que implementa esta interfaz buscar´a el formulario existente que permite configurar dicha clase y lo lanzar´a bajo petici´on del usuario, figura 7.11. Figura 7.11: Configuraci´on del puerto de comunicaciones serie En este caso un SerialCPortConfigForm, figura 7.12, permitir´a configurar dicha instancia y se encargar´a a su vez de proporcionar las funcionalidades de persistencia en disco para almacenar o recuperar la configuraci´on proporcionada. 124 8. Modelos para sistemas fotovoltaicos convencionales. En general, para asegurar un buen funcionamiento de estos sistemas y una correcta integraci´on de los mismos en la red el´ectrica hay que dar una adecuada respuesta a dos problemas: Evaluar el funcionamiento del sistema, partiendo de los par´ametros que se registran en mismo. Hacer una predicci´on a corto plazo de la energ´ıa que el sistema va a producir. En cada sistema energ´etico se recogen valores de varios par´ametros en escalas temporales que pueden variar desde 1 a 30 minutos, durante todos los d´ıas. As´ı, al cabo de cierto tiempo, la cantidad de informaci´on que se tiene de cada planta puede llegar a ser importante, por lo que ser´ıa muy valioso poder sistematizar de alguna manera el tratamiento y an´alisis de esta informaci´on registrada para que pudiese realizarse de forma autom´atica su gesti´on sin necesidad de contar con expertos. Por una parte, para resolver el primer problema planteado, el de la evaluaci´on de este tipo de plantas, se han propuesto varios modelos, la mayor´ıa obtenidos a partir del ajuste de los datos experimentales de los subsistemas que integran las plantas o bien a partir de modelos f´ısicos m´as o menos aproximados de las mismas. Para cada planta, dependiendo de sus par´ametros de dise˜no, se utiliza un ´unico modelo para evaluar su funcionamiento, como por ejemplo los propuestos por: [YCW+04], en el que se presenta un modelo para la gesti´on de una planta energ´etica h´ıbrida (e´olico, solar y bater´ıas como sistema de almacenamiento) basado en la utilizaci´on de l´ogica fuzzy. En general, estos modelos funcionan bastante bien en determinadas condiciones, pero suelen ser bastante inexactos para condiciones de funcionamiento no previstas en su dise˜no. Por ejemplo, en el caso de sistemas cuya fuente de energ´ıa es la radiaci´on solar, los modelos no suelen funcionar muy bien para d´ıas en los que hay presencia de nubes y, como consecuencia, la variabilidad de la fuente energ´etica es alta. Adem´as, estos modelos de evaluaci´on han sido estimados de forma general, sin tener en cuenta las caracter´ısiticas de cada instalaci´on, y suelen ser fijos durante todo el periodo de operaci´on del sistema. Sin embargo, se sabe que los par´ametros de un sistema pueden cambiar a lo largo de su vida ´util, por diversos motivos, como puede ser envejecimiento de los sistemas de generaci´on, degradaci´on de los componentes, presencia de suciedad, etc. Por ello, ser´ıa importante poder contar con modelos que permitan tener en cuenta caracter´ısticas propias de cada instalaci´on y que permitan tambi´en integrar de manera sencilla los posibles cambios que ocurran en los sistemas a lo largo de su vida ´util. Por otra parte, el segundo problema planteado est´a directamente relacionado con las normativas de cada pa´ıs, que est´an obligando a que las compa˜n´ıas productoras de 8.1. Introducci´on 125 electricidad mediante fuentes no convencionales, faciliten con antelaci´on los datos de producci´on de sus sistemas. En este sentido, por ejemplo, el mercado de electricidad en Espa˜na, operado por Red El´ectrica, cambi´o de un sistema centralizado a un sistema competitivo en 1998. En este mercado global, para conseguir una penetraci´on real de los sistemas de producci´on de electricidad a partir de fuentes no convencionales, como son los sistemas de energ´ıa solar, se hace necesario suministrar informaci´on de la previsi´on de producci´on horaria de energ´ıa el´ectrica con un d´ıa de antelaci´on. La desviaci´on de estas previsiones, para plantas de determinado tama˜no, est´a penalizada econ´omicamente, por lo que disponer de modelos que sean capaces de hacer estas predicciones de manera precisa es fundamental. Sin embargo, esta predicci´on es dif´ıcil en el caso de las instalaciones de energ´ıa solar, tanto t´ermica, termosolar como fotovoltaica, debido a la dependencia de la producci´on con la variable climatol´ogica radiaci´on solar. El comportamiento de esta variable puede cambiar dr´asticamente de un d´ıa a otro, incluso en el mismo d´ıa, por los cambios que puede haber en la atm´osfera. As´ı, aunque es posible conocer con mucha precisi´on la radiaci´on que llega a la parte exterior de la atm´osfera -radiaci´on extraterrestre, una vez que esta penetra en la atm´osfera hay diferentes factores que afectan la cantidad de energ´ıa que alcanza la superficie de tierra. Entre estos factores el m´as importante es la presencia de nubes en la atm´osfera, que tiene un cierto componente aleatorio. Por tanto, el desarrollo de herramientas que permitan la supervisi´on, evaluaci´on del funcionamiento y predicci´on de la producci´on de sistemas energ´eticos que utilicen fuentes de energ´ıa no convencionales puede contribuir a la optimizaci´on de estos sistemas y a un mayor desarrollo de los mismos. En este trabajo se proponen modelos que est´an basados en t´ecnicas estad´ısticas y aprendizaje autom´atico como medio para representar las relaciones observadas entre las variables independientes y la variable dependiente que se definan en cada problema para los que se propone su utilizaci´on. Los dos problemas que se tratan son: La evaluaci´on del funcionamiento de un sistema energ´etico en el que intervengan componentes que presenten cierta aleatoriedad, como son los sistemas de energ´ıa solar fotovoltaica, debido a la componente no determinista de la fuente de energ´ıa de los mismos. La predicci´on a corto plazo de la producci´on de energ´ıa de un sistema que presente alguna componente que no sea totalmente determinista entre las variables que influyen en este par´ametro, como son, nuevamente, los sistemas de energ´ıa solar fotovoltaica. Un sistema de energ´ıa solar fotovoltaica es una instalaci´on energ´etica que consta de varios subsistemas comunes como puede verse en la figura 8.1. 126 8. Modelos para sistemas fotovoltaicos Figura 8.1: Esquema de una planta de energ´ıa solar fotovoltaica Las medidas que con mayor frecuencia se registran en las instalaciones fotovoltaicas, fundamentalmente en los inversores, estaciones meteorol´ogicas y sensores de temperatura son: tensi´on en continua, intensidad en continua, tensi´on alterna, intensidad alterna, potencia activa, radiaci´on global, radiaci´on directa, temperatura ambiente, temperatura m´odulos y frecuencia. Con estas medidas de cada dispositivo se tiene una imagen tanto en el momento instant´aneo como de su funcionamiento pasado si se utilizan datos almacenados. A partir de estas medidas, se obtienen las medidas virtuales o estimadas que ser´an calculadas por el marco de trabajo usando los mecanismos que se han expuesto en un cap´ıtulo previo. Estas medidas pueden ser de dos tipos: medidas diarias y medidas globales. Las medidas diarias son aquellas que describen el comportamiento de un sistema en un d´ıa espec´ıfico, mientras que las medidas globales son las que tienen informaci´on de todo el sistema desde que se inici´o su monitorizaci´on. Adem´as de estas informaci´on se cuenta con las medidas instant´aneas de cada momento en el que se registran por cada dispositivo de la instalaci´on. 8.2. Evaluaci´on de sistemas de energ´ıa solar fotovoltaica Para el caso de los sistemas de energ´ıa solar fotovoltaica se han utilizado las medidas diarias que permiten evaluar el comportamiento de este tipo de sistemas propuestas por [Be95]. 8.2. Evaluaci´on de sistemas FV 127 Partiendo de estos trabajos, se propone, por una parte, la utilizaci´on de un ´ındice de rendimiento o productividad diario (daily final yield) y, por otra, la utilizaci´on de balances diarios de energ´ıa (producida y estimada). El primer par´ametro es muy adecuado para comparar distintas instalaciones que tengan tama˜nos diferentes y que trabajen en diferentes condiciones meteorol´ogicas. El rendimiento diario final, Yf,d, se define como la energ´ıa ´util diaria producida por el sistema por cada kWpinstalado: Yf,d =Ed PST C (8.1) donde PST C es la potencia nominal fotovoltaica instalada en condiciones est´andar (STC) de 1kW/m2irradiancia solar y 25◦C de temperatura de c´elula. La energ´ıa ´uitl diaria de salida o energ´ıa diaria suministrada por un sistema, Edse obtiene a partir de la expresi´on: Ed=Zd PAC(t)d(t)≈ n X j=1 Pj AC 4t(8.2) donde nes el n´umero de medidas a lo largo del d´ıa y Pj AC es el valor registrado de potencia generada a la salida del inversor. Como ha sido previamente propuesto, ver por ejemplo [ADMC11], la potencia de salida del inversor tiene una relaci´on lineal con la irradiancia solar, si se desprecia el efecto de la temperatura. En este trabajo se propone incluir este efecto en el modelo que permite estimar la potencia de salida generada por el inversor, (P∗ AC), de acuerdo con la expresi´on 8.3. P∗ AC =PST C Gβ 1000(1 + γ(Tmod −25))GL (8.3) donde, Gβes la irradiancia global en la superficie de los m´odulos, βes la inclinaci´on de los m´odulos, γes el coeficiente de temperatura de Pm,Tmod es la temperatura de los m´odulos y GL es el coeficiente global de p´erdidas del sistema. La Eq.8.3 se ha obtenido a partir de la expresi´on propuesta por [Ost86]. Esta expresi´on incluye tanto las p´erdidas producidas por la temperatura como otro tipo de p´erdidas (suciedad, p´erdidas por distribuci´on espectral, etc.) Los resultados obtenidos con este modelo se utilizan para estimar la energ´ıa que deber´ıa suministrar el sistema fotovoltaico, E∗ d. La energ´ıa diaria estimada que deber´ıa producir una instalaci´on, E∗ d, se calcula a partir de la Eq. 8.4. 128 8. Modelos para sistemas fotovoltaicos E∗ d=Zd P∗ AC(t)d(t)≈ n X j=1 P∗(j) AC 4t(8.4) La propuesta que se hace en este trabajo es evaluar el funcionamiento de una planta utilizando los valores de energ´ıa diaria estimada, E∗ day, con los de energ´ıa realmente producida, Ed. De manera similar, para detectar problemas en el funcionamiento de una instalaci´on, el valor de rendimiento diario, Eq.8.1, se compara con el valor de rendimiento diario estimado, Y∗ f,day, calculado seg´un la Eq. 8.5. Y∗ f,day =E∗ day PST C (8.5) Por otra parte, se han estimado tambi´en los siguientes par´ametros: Energ´ıa diaria producida en alterna, ED,CA. Se calcula a partir de la expresi´on ED,CA =Zt Pcatdt donde tes el tiempo transcurrido durante un d´ıa espec´ıfico y Pca(t) es la potencia en alterna obtenida del inversor en el tiempo t. En secciones, instalaciones y grupos se calcula como la suma de la ED,CA de todos los elementos contenidos en las distintas agrupaciones. Energ´ıa diaria en continua entregada al inversor por el campo de paneles, ED,CC , calculada a partir de la expresi´on: ED,CC =Zt Pcctdt similar a la propuesta para estimar ED,CA. Energ´ıa diaria recibida por el campo de paneles, ED, calculada a partir de la expresi´on: ED=RtRad(t)dt 3600 donde Rad(t) es la radiaci´on recibida en el tiempo t. Rendimiento diario del inversor, µD, calculado como: µD=ED,CA ED,CC 100 8.3. Modelo propuesto para evaluar sistemas FV 129 Productividad media diaria del inversor, Y ield, calculada a partir de la expresi´on: Y ield =ED,CA Wp donde Wpes la potencia pico del generador fotovoltaico conectado al inversor. Wpser´a una medida constante asociada al dispositivo que representa al generador haciendo uso de los mecanismos que proporciona el marco de trabajo indicadas en 5.6. Rendimiento gen´erico medio del inversor, PR, calculado como: PR =1000Y ield 100ED En el caso de las medidas globales asociadas a este tipo de instalaciones se propone la utilizaci´on de las siguientes medidas: Energ´ıa total en alterna, Et,CA. Es la suma de todos los valores de ED,CA del sistema. Energ´ıa total en continua, Et,CC. Es la suma de todos los valores de ED,CC del sistema. Rendimiento global del sistema, µg. Se calcula como la media aritm´etica de todos los valores de µDdel sistema. Productividad global del sistema. Y ieldg. Se calcula como la media aritm´etica de todos los valores de Y ield del sistema. 8.3. Modelo estad´ıstico propuesto para evaluar el funcionamiento de un sistema de energ´ıa solar fotovoltaica A partir de los valores estimados descritos en la secci´on anterior y las medidas realmente registradas, en este trabajo se propone que la comprobaci´on del funcionamiento de un sistema energ´etico se realice utilizando una metodolog´ıa similar a la propuesta en [VAA+09] basada en estad´ıstica descriptiva einferencial. El valor medio de los par´ametros definidos en Eq. 8.1 and 8.2 se propone la estimaci´on de la desviaci´on est´andar de estos par´ametros para cada tipo de instalaci´on (teniendo en cuenta tipos de m´odulos fotovoltaicos e inversor). Utilizando los resultados obtenidos, para evaluar el funcionamiento de cada planta se realiza un an´alisis estad´ıstico entre los valores estimados de estos par´ametros y los registrados. Se eval´ua si existen diferencias significativas entre ambos valores utilizando el test de Jarque-Bera (suponiendo una distribuci´on normal), 130 8. Modelos para sistemas fotovoltaicos [JBA87]. Los valores se estiman a partir de los registros hist´oricos de cada instalaci´on, utilizando solo aquellos valores para los que la instalaci´on ha funcionado correctamente. As´ı, para cada par´ametro evaluado, cada nuevo par de valores registrado, X, y su estimaci´on, X∗e n un instante i, la diferencia entre ambos se analiza utilizando el siguiente criterio (nivel de significaci´on 5 %): d(i) X=X(i)−X∗(i); if d(i) X/∈[−1,96ˆσ, +1,96ˆσ]then mark (i),(8.6) donde ˆσes la desviaci´on est´andar del par´ametro X. Todos los valores marcados (i) corresponden a situaciones en las que ha habido alg´un problema en el funcionamiento de la instalaci´on. Para la potencia generada, P(i) AC, y su correspondiente estimaci´on utilizando Eq.8.3, P∗(i) AC , el criterio es el siguiente: d(i) PAC =P(i) AC −P∗(i) AC ; if d(i) PAC /∈[−1,96ˆσ, +1,96ˆσ]then mark (i),(8.7) Para el rendimiento final diario, Yf,d, la expresi´on utilizada para decidir si hay alg´un problema de funcionamiento en la planta se obtiene a partir de la Eq.8.6 particularizada para este par´ametro: d(i) Yf,d =Y(i) f,day −Y∗(i) f,d ; if d(i) Yf,d /∈[−1,96ˆσ, +1,96ˆσ]then mark (i),(8.8) La Fig. 8.2 muestra el diagrama de flujo propuesto para la evaluaci´on diaria de una planta fotovoltaica. 8.3. Modelo propuesto para evaluar sistemas FV 131 Figura 8.2: Diagrama de flujo para la evaluaci´on de una planta de energ´ıa solar fotovoltaica. 132 8. Modelos para sistemas fotovoltaicos 8.4. Modelo para la predicci´on de la producci´on de energ´ıa de un sistema fotovoltaico La predicci´on a corto plazo de variables continuas se ha hecho tradicionalmente a partir de la teor´ıa de series temporales. En los ´ultimos a˜nos, tambi´en se est´an empezando a utilizar distintas herramientas basadas en modelos de aprendizaje autom´atico. En general, los m´etodos utilizados para series temporales continuas intentan encontrar modelos que sean capaces de reproducir tanto las caracter´ısticas estad´ısticas como las secuenciales de las series originales y predecir a corto, medio y/o largo plazo el comportamiento de las variables analizadas. Por una parte, los modelos estad´ısticos cl´asicos se basan en la utilizaci´on de los modelos estoc´asticos, que asumen que los datos tienen una estructura interna; esta estructura puede ser identificada utilizando las funciones de autocorrelaci´on y autocorrelaci´on parcial, [BJ76], [GH05], [BD02]. Utilizando estas funciones, se hace una selecci´on previa de los modelos que se van a utilizar. Para estos modelos, el siguiente paso es estimar sus par´ametros. En este estimaci´on, se suele asumir que la dependencia entre los valores de la serie es constante a lo largo del tiempo. El hecho de tener que hacer una selecci´on previa de modelos y la restricci´on de que los par´ametros estimados sean constantes a lo largo del tiempo supone una limitaci´on a la hora de utilizar estos modelos para algunas variables para las que se sabe que no tienen este comportamiento. Por otra parte, tambi´en se est´an empezando a utilizar m´etodos y t´ecnicas de aprendizaje autom´atico para la predicci´on de series temporales, como por ejemplo en los trabajos de [GL03], [XDT04], [ZQ05], [WH08], [SC93], [SC94], [HCL98]. Para la predicci´on de variables que intervienen en el funcionamiento de sistemas energ´eticos, se pueden citar los trabajos de [PMS07], en el que se propone un modelo para estimar valores de energ´ıa solar a partir del par´ametro cielo cubierto (medido por United States National Weather Service (NWS), [MLMdCMB05] en el que se propone la utilizaci´on de un tipo especial de aut´omata finito probabilista para la predicci´on de variables clim´aticas, [VAR08] en donde se proponen distintas aproximaciones para la estimaci´on de valores de radiaci´on solar, [GPC06] [GNAB09] en los que se propone la utilizaci´on de redes neuronales artificiales para la predicci´on de radiaci´on solar; [CDCL11] que utilizan un mapa autoorganizado (self-organized map, SOM) para la clasificar el tipo de climatolog´ıa local, aunque en este trabajo se utilizan las predicciones meteorol´ogicas de irradiaci´on solar, humedad relativa y temperatura del emplazamiento, suministradas por los servicios meteorol´ogicos (online); y en [BMP13] se propone la combinaci´on de modelos SARIMA (autoregresivos y medias m´oviles integrados, estacionales). En lo que se refiere a la predicci´on de la energ´ıa producida por un sistema fotovoltaico, se pueden citar los siguientes trabajos: [LHHB09] en el que se presenta un modelo para predicci´on de producci´on de energ´ıa a partir de la predicci´on de radiaci´on solar; [BMN09] en el que se propone un m´etodo on-line para hacer predicci´on a corto 8.4. Modelo de predicci´on de producci´on FV propuesto 133 plazo de la producci´on de plantas fotovoltaicas utilizando modelos autorregresivos y num´ericos; [SRIS09] en el que se analiza la utilizaci´on de redes neuronales artificiales para predicci´on de la producci´on de sistemas fotovoltaicos; [FOT+11] en que se propone la utilizaci´on de un perceptr´on multicapa y m´aquinas de vectores de soporte (support vector machine) para la predicci´on de la producci´on de una instalaci´on fotovoltica en Jap´on; [LSH+11] se presenta y evalua la predicci´on de potencia de un sistema en la Universidad de Oldenburg proporcionando una predicci´on de hasta dos d´ıas con una resoluci´on horaria; en [SCST12] se proponen varios modelos de predicci´on de la potencia de salida y la eficiencia de un sistema fotovoltaico pero en una base mensual y anual; en [FOT+12] se propone la utilizaci´on de regresiones de vectores de soporte y modelos num´ericos tambi´en la predicci´on de una planta fotovoltaica instalada en Jap´on; en [ZMAP14a] y [ZMAP14b] se presentan los resultados obtenidos de analizar y evaluar modelos, construidos con m´etodos estad´ısticos y basados en la predicci´on de modelos num´ericos, para la predicci´on de la producci´on de algunas plantas fotovoltaicas en Francia; en [DSFOO+14] se eval´uan tres estrategias basadas en predicciones meteorol´ogicas, generaci´on fotovoltaica previa y regresi´on de m´aquinas de soporte vectorial, para obtener la predicci´on regional a un d´ıa de generaci´on fotovoltaica; en [YHHP14] se proponen tres etapas, clasificaci´on, entrenamiento y predicci´on utilizando SOM, redes LVQ (Learnig Vector Quantization) para modelizar los valores pasados de producci´on fotovoltaica, regresi´on con m´aquinas de soporte vectorial para entrenar las entradas/- salidas de temperatura, probabilidad y predicci´on; y los recientes trabajos de [BTM15] en el que se propone la predicci´on de la producci´on con una antelaci´on de 6 horas y [WZM+15] en la que se propone un modelo para la predicci´on de la potencia fotovoltaica basada en el reconocimiento de patrones meteorol´ogicos y la extracci´on de caracter´ısticas de radiaci´on solar y SVM. Por otra parte, los modelos estad´ısticos pueden trabajar con valores continuos pero algunos modelos de aprendizaje autom´atico solo pueden ser utilizado para datos que puedan ser representados de manera discreta o nominal. Esto implica que cuando se quieran utilizar estos modelos ser´a necesario hacer previamente una discretizaci´on de las variables que sean continuas, tal y como ha sido se˜nalado en [DK95], [LHTD02]. Para la discretizaci´on de valores continuos se han propuesto diferentes m´etodos, entre otros se pueden citar los trabajos de [DK95], [PT98], [MLRMBR00], [LHTD02] y [Bou04]. Respecto a los resultados obtenidos en la predicci´on del par´ametro radiaci´on solar, una de las conclusiones es que el error y precisi´on de estos modelos var´ıa pero en todos los casos es significativo, como se concluye en [PMS07], [MLMdCMB05], [VAR08], [MP10], [Rei09], [KOV+11], [CCM+13]. El error, en t´erminos de energ´ıa, es alrededor del 32 % en [MP10], var´ıa entre el 30 y el 40 % en [Rei09] y var´ıa entre el 23 y el 28 % en [CCM+13]. La predicci´on de la producci´on de energ´ıa en un sistema fotovoltaico o termosolar se hace a partir de los par´ametros propios de la instalaci´on conocidos, y de la predicci´on de los valores de energ´ıa que el sistema recibir´a. Este par´ametro es conocido como radiaci´on solar, cuando se trabaja con intervalos de tiempo, o irradiancia, cuando se trabaja con valores instant´aneos. Los valores de radiaci´on solar se registran de manera