Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingeniería Técnica Industrial: Electrónica Control distribuido de redes inteligentes mediante sistemas multiagente Autor Rafael Tallada Souto Director José Antonio Domínguez Navarro Escuela de Ingeniería y Arquitectura – Universidad de Zaragoza Septiembre 2013 Agradecimientos Quisiera agradecer a todas las personas que de una u otra forma me han acompañado durante estos cuatro años de estudios universitarios su cariño y su apoyo: A mis compañeros de clase, por los buenos momentos que hemos pasado juntos y por haber tenido la paciencia suficiente para aguantarme. A mi familia, por haberme dado la oportunidad de continuar formándome. A Hans Bludszuweit, Logan López y Aitor Alcrudo; por su inestimable ayuda en los momentos más críticos del proyecto. Y por supuesto a Ana, porque gracias a ella los años más duros de mi vida han resultado ser también los mejores. R RR Re ee esumen sumensumen sumen La sociedad actual es testigo de una paulatina transición en la forma de generar y distribuir la energía eléctrica. El sistema tradicional cuya generación de electricidad se concentra en grandes instalaciones centralizadas está dando paso a otro en el que la generación se integra de forma distribuida en la red eléctrica. Uno de los principales motores de este cambio es la progresiva implantación de las energías renovables. Las ventajas de este tipo de energías son de sobra conocidas: se trata de energías respetuosas con el medio ambiente y virtualmente inagotables. Sin embargo, su integración en la red eléctrica entraña nuevos desafíos de control. Para afrontar estos desafíos, las redes eléctricas deberán incorporar elementos de monitorización, comunicación y control; que consigan un balance óptimo entre generación, demanda y almacenamiento energético y, además, reaccionen con rapidez ante los cambios. Nacen así los conceptos de “Red Inteligente” y de “Smart City”. Este PFC ha sido realizado gracias a una beca de iniciación a la investigación de la fundación CIRCE y aborda el control distribuido de una microrred inteligente por medio de un sistema multiagente. Para ello se ha implementado un emulador mediante la tecnología de agentes JADE (desarrollada en Java) que reproduce los flujos de potencia en la microrred, y se han ideado diferentes estrategias para su control. La validación del emulador se ha llevado a cabo con numerosos ensayos y simulaciones, obteniéndose resultados de gran utilidad a la hora de dimensionar de forma óptima los sistemas de almacenamiento eléctrico con los que cuenta la microrred. Finalmente, se ha estudiado la posibilidad de interconectar la tecnología de agentes con el entorno de simulación MATLAB-Simulink. En concreto, se ha diseñado un sistema multiagente que optimiza el despacho económico de potencia de una microrred, modelada de forma gráfica en Simulink. 1 Índice ÍndiceÍndice Índice Índice ÍndiceÍndice Índice ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ....................................... .............. ....... 1 11 1 Índice de figuras Índice de figurasÍndice de figuras Índice de figuras ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ...................................................... ............................................ ...................... 5 55 5 Índice de tablas Índice de tablasÍndice de tablas Índice de tablas ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ....................................................... .............................................. ....................... 7 77 7 Lista de abr Lista de abrLista de abr Lista de abreviaturas eviaturaseviaturas eviaturas ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ............................................... .............................. ............... 9 99 9 1 11 1 Introducción IntroducciónIntroducción Introducción ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ..................................................... .......................................... ..................... 11 1111 11 1.1 Contexto ......................................................................................................................... 11 1.2 Objetivos y alcance del proyecto .................................................................................. 13 1.3 Ámbito y motivación ...................................................................................................... 13 1.4 Organización del documento ........................................................................................ 14 2 22 2 Conceptos previos Conceptos previosConceptos previos Conceptos previos ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ........................................... ...................... ........... 15 1515 15 2.1 Microrredes .................................................................................................................... 15 2.2 Técnicas heurísticas y optimización clásica ................................................................ 17 2.3 Agentes software y sistemas multiagente ................................................................... 18 2.3.1 Qué es un agente ............................................................................................... 18 2.3.2 Sistemas multiagente........................................................................................ 21 2.3.3 Comunicación entre agentes ............................................................................ 21 2.4 Framework JADE ............................................................................................................ 22 2.4.1 Containers y Plataformas .................................................................................. 22 2.4.2 Los agentes AMS, DF y RMA ............................................................................. 23 2.4.3 Agentes en JADE: la clase Agent ....................................................................... 26 2.4.4 Comportamientos .............................................................................................. 27 2.5 Antecedentes ................................................................................................................. 29 3 33 3 Optimizaci OptimizaciOptimizaci Optimización mediante técnicas heurísticas ón mediante técnicas heurísticasón mediante técnicas heurísticas ón mediante técnicas heurísticas ................................ ................................................................ ................................................................ ................................................................ ................................... ...... ... 31 3131 31 3.1 Propuesta de trabajo ..................................................................................................... 31 3.2 Descripción del área sujeto de estudio ....................................................................... 32 3.2.1 Recurso renovable ............................................................................................. 33 3.2.2 Demanda y balance de potencia en PCC ......................................................... 35 3.3 Descripción del modelo ................................................................................................. 37 3.3.1 Datos de entrada y de salida ............................................................................ 40 3.3.1.1 Inputs.................................................................................................... 40 3.3.1.2 Outputs ................................................................................................. 41 3.3.2 Casos de estudio ............................................................................................... 43 3.3.3 Estrategias de control de P (potencia activa) .................................................. 43 3.3.3.1 Peak Shaving ....................................................................................... 44 3.3.3.2 Smoothing (alisamiento de la curva de demanda) ........................... 48 3.3.4 Control de Q (potencia reactiva) ....................................................................... 51 3.4 Implementación informática ......................................................................................... 54 3.4.1 Relación de clases ............................................................................................. 55 3.4.2 Protocolo de interacción FIPA Contract Net ..................................................... 56 2 3.4.2.1 Funcionamiento ................................................................................... 56 3.4.2.2 Clases ContractNetInitiator y ContractNetResponder ...................... 58 3.4.3 Agentes ............................................................................................................... 59 3.4.3.1 Agente Power Manager ....................................................................... 59 3.4.3.2 Agente DG ............................................................................................ 61 3.4.3.3 Agente Storage .................................................................................... 62 3.4.3.4 Agente Load ......................................................................................... 63 3.4.4 Elementos físicos ............................................................................................... 63 3.4.4.1 Modelo del convertidor. Clase Converter. .......................................... 63 3.4.4.2 Modelo de la batería. Clase Battery. .................................................. 64 3.4.5 Otras clases........................................................................................................ 66 3.4.6 Modo monitorización ......................................................................................... 67 3.5 Resultados ..................................................................................................................... 70 3.5.1 Microrred sin DG ................................................................................................ 70 3.5.1.1 Control de P ......................................................................................... 70 3.5.1.2 Control de Q ......................................................................................... 72 3.5.1.3 Actuación de las baterías .................................................................... 72 3.5.2 Microrred con DG ............................................................................................... 74 3.5.2.1 Control de P ......................................................................................... 74 3.5.2.2 Control de Q ......................................................................................... 78 3.5.2.3 Actuación de las baterías .................................................................... 80 3.6 Conclusiones y líneas futuras ....................................................................................... 84 3.6.1 Conclusiones ...................................................................................................... 84 3.6.1.1 Emulador .............................................................................................. 84 3.6.1.2 Modelo simulado ................................................................................. 84 3.6.2 Líneas futuras .................................................................................................... 85 3.6.2.1 Emulador .............................................................................................. 85 3.6.2.2 Modelo simulado ................................................................................. 88 4 44 4 Optimización clásica Optimización clásicaOptimización clásica Optimización clásica ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ........................................ ................ ........ 89 8989 89 4.1 Caracterización del modelo .......................................................................................... 89 4.1.1 Reguladores Inteligentes .................................................................................. 90 4.1.2 Agente Optimizador ........................................................................................... 91 4.1.2.1 Bloque de previsión de demanda ...................................................... 91 4.1.3 Otros elementos de la microrred ...................................................................... 92 4.1.3.1 Generador eólico (recurso renovable) ............................................... 92 4.1.3.2 Grupo electrógeno diésel (recurso no renovable) ............................. 92 4.1.3.3 Sistemas de almacenamiento ............................................................ 92 4.1.3.4 Cargas .................................................................................................. 93 4.1.3.5 Línea de transmisión ........................................................................... 93 4.1.3.6 Red ....................................................................................................... 93 4.2 Algoritmo de optimización para la gestión de la energía ............................................ 94 4.3 Implementación informática ......................................................................................... 96 4.3.1 Software utilizado .............................................................................................. 96 4.3.1.1 MATLAB-Simulink ................................................................................. 96 4.3.1.2 MACSimJX ............................................................................................ 97 4.3.1.3 A Modeling Language for Mathematical Programming (AMPL)........ 99 4.3.2 Esquema conceptual del modelo de simulación ............................................. 99 4.4 Casos de estudio y resultados .................................................................................... 101 3 4.4.1 Resultados de una optimización para cuatro periodos mediante AMPL ..... 101 4.4.2 Verificación del seguimiento de las consignas .............................................. 103 4.4.3 Respuesta a un cambio brusco de carga ...................................................... 105 4.4.4 Funcionamiento en isla ................................................................................... 108 4.5 Conclusiones y líneas futuras ..................................................................................... 110 4.5.1 Conclusiones .................................................................................................... 110 4.5.2 Líneas futuras .................................................................................................. 111 5 55 5 Conclusiones personales Conclusiones personalesConclusiones personales Conclusiones personales ................................ ................................................................ ................................................................ ................................................................ ............................................................... .............................................................. ............................... 113 113113 113 6 66 6 Anexos AnexosAnexos Anexos ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ............................................................ ........................................................ ............................ 115 115115 115 6.1 Feedback modo Debug (Iteration 1 of 17520, Peak Shaving) ................................ 115 7 77 7 Bibliografía BibliografíaBibliografía Bibliografía ................................ ................................................................ ................................................................ ................................................................ ................................................................ ................................................................ ..................................................... .......................................... ..................... 125 125125 125 11 1 11 1 Introducción IntroducciónIntroducción Introducción A continuación se presenta la memoria del Proyecto Fin de Carrera (PFC) “Control distribuido de redes inteligentes mediante sistemas multiagente”, que ha tenido como principal objetivo la implementación de un emulador de microrredes basado en tecnología de agentes con el que realizar simulaciones para extraer información de interés. En esta memoria se va a exponer el trabajo realizado, los resultados obtenidos en las simulaciones y las conclusiones finales. 1.1 1.11.1 1.1 Contexto ContextoContexto Contexto Resulta innegable que la sociedad actual es testigo de una paulatina transición en la forma de generar y distribuir la energía eléctrica. El sistema tradicional cuya generación de electricidad se concentra en grandes instalaciones centralizadas está dando paso a otro en el que la generación se integra de forma distribuida en la red eléctrica [1]. La causa del cambio está íntimamente relacionada con en el auge imparable de las energías renovables. Las ventajas que este auge supone son bien conocidas: se trata de energías respetuosas con el medio ambiente y virtualmente inagotables. Sin embargo, su integración en la red actual entraña nuevos desafíos. Uno de los principales retos proviene de su naturaleza intrínsecamente aleatoria, que dificulta lograr un equilibrio en tiempo real entre generación y demanda. El uso de sistemas de almacenamiento eléctrico (SAE) ayuda en esta tarea, pero no es suficiente. Para salvar este obstáculo, las redes eléctricas actuales deberán incorporar elementos de monitorización, comunicación y control; que consigan un balance óptimo entre generación, demanda y almacenamiento y, además, reaccionen con rapidez ante los cambios. Fig. 1. Fig. 1.Fig. 1. Fig. 1. Ejemplo de Smart Grid Ejemplo de Smart GridEjemplo de Smart Grid Ejemplo de Smart Grid [2] [2][2] [2] 1 Introducción 12 Nace así el concepto de “Smart Grid” o red inteligente [3]. La definición de Smart Grid varía según el autor. A un primer nivel, se podría definir como la forma de proveer energía, desde la generación a la demanda, que se vale de las tecnologías TIC. Un sistema de esta naturaleza tiene como objetivo prioritario asegurar el suministro. A un segundo nivel, la comunicación establecida entre los distintos elementos de la Smart Grid trae consigo ahorro energético, reducción de costes y una optimización de la generación proveniente de recursos no renovables. Además de la problemática que presenta la ausencia de control sobre el recurso natural, la red eléctrica deberá ser capaz de hacer frente al aumento sostenido de la demanda de energía. Aun teniendo en cuenta el aumento de la eficiencia energética que se presupone en el ámbito de la edificación, el transporte, etc.; se estima que el consumo actual de energía eléctrica va a verse multiplicado por cuatro en 2040. Fig. 2. Fig. 2.Fig. 2. Fig. 2. Evolución del consumo Evolución del consumo Evolución del consumo Evolución del consumo y de la oferta de energía y de la oferta de energíay de la oferta de energía y de la oferta de energía (1949 = 1) (1949 = 1)(1949 = 1) (1949 = 1) Por si esto no fuera suficiente, se prevén incrementos considerables en el consumo eléctrico de carácter puntual debido a la progresiva implantación que va a experimentar el vehículo eléctrico. Estos picos de demanda obligarán al desarrollo de SAE inteligentes que respondan de forma flexible ante esta complejidad creciente. Se plantea también la posibilidad de modificar la curva de demanda actuando directamente sobre el comportamiento del consumidor, incentivando el uso de la energía en periodos con menor demanda global y “penalizándolo” durante dichos picos. Existen modalidades de contrato en algunos países como EE.UU. en los que el consumidor otorga cierto control a la empresa suministradora sobre algún aspecto concreto de su consumo, como el sistema de refrigeración, a fin de que la compañía eléctrica pueda modificar el patrón de demanda en caso de ser necesario. El consumidor recibe como contrapartida descuentos en la factura o tarifas más ventajosas. 0 5 10 15 20 25 1949 1959 1969 1979 1989 1999 2009 2019 2029 2039 Consumo Generación Rafael Tallada Souto 13 1.2 1.21.2 1.2 Objetivos y alcance del proyecto Objetivos y alcance del proyectoObjetivos y alcance del proyecto Objetivos y alcance del proyecto El principal objetivo de este proyecto ha consistido en implementar un emulador de microrredes basado en el “paradigma de agentes”. Este paradigma se centra en el desarrollo de entidades software que pueden actuar de forma autónoma y razonada. Para ello se ha realizado un sistema multiagente (SMA) en el que cada elemento de la microrred cuenta con un agente asociado encargado de su gestión. La efectividad del SMA a la hora de replicar el funcionamiento real de una microrred ha sido evaluada por medio de distintas simulaciones, bajo distintos supuestos de funcionamiento, y con diferentes estrategias de control. La arquitectura y los protocolos utilizados han sido escogidos cuidadosamente para dejar la puerta abierta a futuros desarrollos y mejoras funcionales. El lenguaje de programación elegido ha sido Java debido a dos razones. La primera es que se trata de un lenguaje independiente de la plataforma, lo que ofrece una gran libertad a la hora de ejecutar la SMA en ordenadores con distintos sistemas operativos. La segunda razón es la existencia del framework JADE, basado por completo en lenguaje Java, que facilita sobremanera la implementación de sistemas multiagente, evitando que el programador tenga que preocuparse de desarrollar las funcionalidades de más bajo nivel. Por último, se ha estudiado la posibilidad de emplear un modelo ya existente implementado en el entorno de simulación Simulink para reproducir los flujos de potencia en una microrred. El control de dicha microrred se lleva a cabo de forma externa por agentes en JADE. La comunicación entre ambas plataformas se ha realizado por medio del middleware MACSimJX, mientras que para optimizar el despacho de potencia se ha empleado el lenguaje de modelado algebraico AMPL. 1.3 1.31.3 1.3 Ámbito y motivación Ámbito y motivaciónÁmbito y motivación Ámbito y motivación El presente documento recoge parte del trabajo llevado a cabo para CIRCE durante el curso 2012/2013, en el marco de una beca de iniciación a la investigación. La principal motivación para realizar este PFC fue la posibilidad de integrar en un mismo proyecto programación, cuestiones de control y energías renovables; temas por los que el autor ha ido desarrollando un gran interés a lo largo de su etapa como estudiante de ing. técnica electrónica. Fig. 3. Fig. 3.Fig. 3. Fig. 3. Logo de la fundación CIRCE Logo de la fundación CIRCELogo de la fundación CIRCE Logo de la fundación CIRCE El PFC se enmarca dentro de una de las líneas de investigación abiertas en el área de I+D+i de Integración de Energías Renovables (IER), de la fundación CIRCE, consistente en el diseño óptimo de sistemas integrados de generación y almacenamiento (bombeo hidráulico reversible, baterías, condensadores y supercondensadores), incluyendo la integración en microrredes, tanto conectadas a red como aisladas. 1 Introducción 14 Se abarca también la gestión óptima de flujos energéticos de fuentes renovables como mini y micro hidroeléctrica, eólica, biomasa y fotovoltaica, así como el diseño de controles que aseguren la estabilidad del sistema y minimicen el impacto en red. 1.4 1.41.4 1.4 Organización del documento Organización del documentoOrganización del documento Organización del documento El presente documento consta de memoria y anexos. La memoria consta de cinco capítulos en los que se ofrece un completo resumen trabajo realizado, así como las pertinentes justificaciones, resultados y conclusiones. La información recogida en la memoria es ampliada en los anexos. El primer capítulo de la memoria, en el que está incluido este apartado, es de carácter introductorio; y sitúa al PFC en su contexto, presenta los objetivos a cumplir y el ámbito y motivación para su realización. El capítulo 2 expone algunos conceptos previos necesarios para la comprensión del documento. Este capítulo explicará en qué consiste una microrred y algunas de sus opciones de control, describirá las diferencias entre optimización clásica y optimización mediante técnicas heurísticas, desarrollará el concepto de SMA, realizará una pequeña introducción al framework de agentes JADE y terminará con algunos antecedentes. El contenido del capítulo 3 abarca el grueso del proyecto: el emulador de microrredes mediante SMA, correspondiente a la parte de optimización heurística. El capítulo incluye explicaciones sobre su funcionamiento y sobre el modelo de microrred implementado, realiza un análisis de los datos que se utilizarán para su validación, presenta los resultados obtenidos y termina con las conclusiones y líneas de continuidad. El capítulo 4 enfoca el control desde el punto de vista de la optimización clásica, y presenta los resultados obtenidos al integrar la tecnología de agentes con software de simulación gráfica y optimización lineal. Al igual que en el capítulo 3, se va a proporcionar información acerca de la implementación informática y acerca del modelo y los escenarios de simulación, para finalizar con los resultados y conclusiones obtenidos. Por último, el capítulo 5 recoge conclusiones y valoraciones de carácter personal acerca del trabajo realizado. 15 2 22 2 Conceptos previos Conceptos previosConceptos previos Conceptos previos En el presente capítulo se explican varios conceptos que se han creído necesarios para entender el contenido de la memoria. 2.1 2.12.1 2.1 Microrredes MicrorredesMicrorredes Microrredes No existe una definición de microrred universalmente aceptada [4]. En [5] se define microrred como una “interconexión de fuentes de energía distribuida con elementos de almacenamiento integrados”. En el año 2002, el CERTS (Consortium for Electric Reliability Technology Solutions) establece la siguiente definición para el concepto de microrred: “Agregación de cargas y microgeneradores que se opera como un sistema único y que provee tanto de energía eléctrica como térmica”. Pese a que día de hoy todavía no se ha acuñado una definición formal de microrred, la bibliografía consultada suele coincidir a la hora de señalar los elementos que pueden formar parte de ella. La enumeración de elementos que viene a continuación sigue la clasificación que hace [1]: 1) Generación GeneraciónGeneración Generación: • Renovable o no renovable, en función del recurso energético. • Controlables o intermitentes (modo de operación). 2) Almacenamiento AlmacenamientoAlmacenamiento Almacenamiento: eléctrico / térmico. 3) 3)3) 3) Cargas CargasCargas Cargas: :: : • Eléctricas / térmicas. • Cargas críticas: requieren mayor calidad de suministro (i.e. procesos industriales). • Controlables o no controlables. 4) Interruptor InterruptorInterruptor Interruptor: punto de interconexión con la red eléctrica (PCC, Point of Common Coupling). 5) Protecciones ProteccionesProtecciones Protecciones: • Transiciones conectado-aislado-conectado (detección de condición en isla). • Potencias de cortocircuito para detección de faltas. 6) Sistemas de control controlcontrol control: • Sistemas de control central de la microrred. • Controladores locales (generadores controlados, cargas). • Comunicaciones. • Distribución de la lógica de control (control primario, regulación secundaria y servicios auxiliares). 2 Conceptos previos 16 El carácter distribuido de la generación es una consecuencia del tamaño de los generadores, mucho más pequeños que los de una planta convencional, así como de la disponibilidad física del recurso. Los microgeneradores se instalarán, en la medida de lo posible, próximos a los puntos de consumo para minimizar las pérdidas asociadas al transporte. Lo mismo sucede con las baterías y otros sistemas de almacenamiento. Una microrred deberá ser capaz de llevar a cabo ciertas tareas que garanticen un suministro de calidad. En [1] y [5] se especifican algunas de las funciones con las que es deseable que cualquier microrred cuente: 1) Operación autónoma: que no se requiera de ninguna intervención externa para operar correctamente. 2) Gestión de la operación: despacho de potencia y control de tensiones. 3) Posibilidad de aislarse de la red principal (funcionamiento “en isla”) y capacidad para realizar las conexiones y desconexiones de forma controlada. 4) Seguimiento de carga (load following). 5) Alisamiento de picos de consumo. Las microrredes estudiadas en este PFC disponen además de elementos adicionales para su monitorización, comunicación y control: se pueden considerar redes “inteligentes”. La gestión de las redes inteligentes debe de poder, no sólo de mantener el balance energético entre los generadores, las demandas de la red inteligente y el intercambio con la red principal, sino también optimizar la forma en la que esto se lleva a cabo con el objetivo de minimizar los costes. Existen tres posibles enfoques o arquitecturas de control a la hora de llevar a cabo dichas labores de gestión: control distribuido, centralizado o semidistribuido. Control centralizado Control centralizadoControl centralizado Control centralizado Es el enfoque de control más clásico y extendido. Un único ente recibe todos los datos disponibles y los procesa para devolver posteriormente instrucciones y consignas. Al tratarse del sistema más implantado, existe una gran cantidad de información disponible al respecto. Sus puntos fuertes son la estabilidad, robustez y sencillez a la hora de implementarlo. Como debilidades cabría citar su lenta reacción bajo ciertos supuestos de funcionamiento, ya que su potencia de tratamiento de la información se concentra en un solo punto. Control distribuido Control distribuidoControl distribuido Control distribuido En el lado opuesto al control centralizado se encuentra la arquitectura totalmente descentralizada. Ya no se dispone de un único ente responsable de toda la red, sino que son varios entes o agentes los que se encargan de controlar su entorno más próximo. Cada agente recoge datos en un ámbito local, sin tomar en consideración lo que hay más allá de éste. Este es el enfoque que más está siendo estudiado actualmente, y se postula como la línea de investigación más prometedora. La idea es explotar las ventajas que supone repartir la potencia de tratamiento de información en el espacio, haciendo un uso más eficiente de los recursos. Esto comporta normalmente unos tiempos de reacción más reducidos y, en ocasiones, la eliminación de los “cuellos de botella” que suelen aparecer en sistemas centralizados. Rafael Tallada Souto 17 Control híbrido Control híbrido Control híbrido Control híbrido o semi o semio semi o semi- -- -distribuido distribuidodistribuido distribuido Como su nombre indica, esta arquitectura combina características de las dos anteriores. Si bien existe un notable grado de descentralización, cuenta con niveles jerárquicos definidos, los cuales tienen asociados distintos grados de responsabilidad y ámbitos de actuación. Aúna virtudes de ambas topologías al combinar la flexibilidad de un control distribuido con la sencillez y robustez del centralizado. En base a esto, se ha decidido que la regulación de las dos microrredes objeto de estudio en este PFC siga una arquitectura semi-distribuida. 2.2 2.22.2 2.2 Técnicas heurísticas y Técnicas heurísticas y Técnicas heurísticas y Técnicas heurísticas y o oo optimización ptimizaciónptimización ptimización clásica clásicaclásica clásica La problemática de control abordada en este trabajo se ha enfocado de dos maneras distintas: mediante técnicas heurísticas de optimización y mediante optimización lineal. Heurística HeurísticaHeurística Heurística Con el fin de resolver problemas complicados de manera eficiente, a veces es necesario comprometer algunos requisitos de optimalidad y construir una estructura de control que no garantice encontrar la mejor respuesta, pero que casi siempre encuentre una buena solución. De esta forma surge la idea de heurística. La palabra heurística viene de la palabra griega heuriken que significa “descubrir” (origen también del célebre eureka de Arquímedes). La heurística es una técnica que aumenta la eficiencia de un proceso de búsqueda, aunque posiblemente sacrificando demandas de completitud. Una función heurística es una correspondencia entre las descripciones de estados del problema alguna media de deseabilidad, normalmente representada por números. En general, hay que hacer una ponderación entre el costo de evaluación de una función heurística y el ahorro de tiempo que ésta proporciona [6]. El enfoque mediante técnicas heurísticas del capítulo 3 va a establecer las consignas de control en base a un cierto número de directrices (estrategias). Un control de este tipo asegura buenos resultados, pero no garantiza la solución óptima. Optimización clásica Optimización clásicaOptimización clásica Optimización clásica La optimización, , , , en el sentido clásico del término, consiste en la selección de la mejor solución en algún aspecto concreto de entre todas las alternativas posibles. Los problemas de optimización suelen componerse de tres elementos [7]: • Función objetivo: Función objetivo:Función objetivo: Función objetivo: es la medida cuantitativa del funcionamiento del sistema que se desea optimizar (maximizar o minimizar). El ejemplo más ilustrativo sería una función de coste que interesa minimizar. • Variables: Variables:Variables: Variables: representan las decisiones que se pueden tomar para afectar al valor de la función objetivo. • Restricciones: Restricciones:Restricciones: Restricciones: representan el conjunto de relaciones (expresadas como ecuaciones o inecuaciones) que ciertas variables están obligadas a satisfacer. Los límites físicos de potencia que puede entregar un generador o el nivel de carga máximo de una batería serían ejemplos de restricciones. 2 Conceptos previos 18 La Fig. 4 constituye un ejemplo de optimización. En ella se muestra el gráfico de un paraboloide dado por la ecuación (1). La función objetivo es la propia ecuación y las variables son x e y. En este caso no se contemplan restricciones adicionales. El punto rojo situado en (0, 0, 4) es el que maximiza la función objetivo.    ,   = −    +    + 4 (1) Fig. 4. Fig. 4.Fig. 4. Fig. 4. Optimización de la ecuación Optimización de la ecuación Optimización de la ecuación Optimización de la ecuación ( (( (1 11 1) )) ) 2.3 2.32.3 2.3 Agentes software y sistemas multiagente Agentes software y sistemas multiagenteAgentes software y sistemas multiagente Agentes software y sistemas multiagente Los agentes software surgen dentro del campo de la Inteligencia Artificial, concretamente a partir de trabajos desarrollados en el área de DAI (Distributed Artificial Intelligence). Esta investigación inicial progresa hacia la madurez dando lugar a conceptos como la Programación Orientada a Agentes y los Lenguajes de comunicación de Agentes. Posteriormente, este concepto se extiende al resto de la Ingeniería de Software, planteándose hoy en día la Ingeniería de Software Orientada a Agentes [8]. 2.3.1 2.3.12.3.1 2.3.1 Qué es un agente Qué es un agenteQué es un agente Qué es un agente Al igual que para microrred, no existe una definición universalmente aceptada de agente. No obstante, todas las definiciones coinciden al señalar cuatro características definitorias: los agentes software son entidades autónomas, inteligentes, poseen movilidad, y presentan un comportamiento social [4]. I. Agente como entidad autónoma autónomaautónoma autónoma. Autonomía, reactividad e iniciativa son las tres propiedades que caracterizan al agente como entidad autónoma: • Autonomía: es capaz de trabajar sin la intervención directa del usuario y tiene cierto control sobre sus acciones y estado interno. • Reactividad: puede percibir su entorno (ya sea el mundo físico, a través de sensores, un usuario, por medio de una interfaz gráfica o vocal, aplicaciones Rafael Tallada Souto 19 en la red, otros agentes; etc.) y responder oportunamente a cambios que se produzcan en el mismo. • Iniciativa: es proactivo, puesto que tiene la capacidad de actuar incluso en ausencia de estímulos externos. Su actuación viene determinada por los objetivos a cumplir, y tratará de lograr su consecución [9]. Fig. 5. Fig. 5.Fig. 5. Fig. 5. Agente como entidad autónoma que Agente como entidad autónoma queAgente como entidad autónoma que Agente como entidad autónoma que interacciona con su entorno interacciona con su entornointeracciona con su entorno interacciona con su entorno II. Agente como entidad inteligente inteligenteinteligente inteligente. Un agente es capaz de razonar y aprender: • Razona, porque decide qué objetivos perseguir, a qué eventos reaccionar y cómo actuar para conseguir sus metas. También puede suspender o abandonar un objetivo para dedicarse a otro. • Aprende, porque mediante técnicas de aprendizaje puede adaptarse mejor al entorno y a las variaciones dinámicas de éste. Es capaz de mejorar su proceso de toma de decisiones en base a su experiencia. III. Los agentes poseen movilidad movilidadmovilidad movilidad. Un agente puede migrar de un nodo a otro en una red preservando su estado interno. Este aspecto es de gran importancia por dos motivos: • El agente puede adquirir un conocimiento global del sistema viajando y recopilando estímulos locales. • Permite repartir la potencia de cálculo del sistema entre más de un procesador. 2 Conceptos previos 26 El SMA cuenta con una única plataforma llamada “myPlatform”. Dentro de la plataforma existen cuatro containers, representados por carpetas de color verde. Los containers no tienen por qué estar ejecutándose en el mismo ordenador, sino que pueden estar situados en servidores que estén a kilómetros de distancia y seguir comunicándose vía Ethernet. En el ejemplo de la Fig. 9, el agente “control” se ejecutaría en el edificio Torres Quevedo, mientras que en el Ada Byron se podría encontrar el agente “PV”, encargado de gestionar unas placas fotovoltaicas. En el edificio CIRCE podría estar ejecutándose en el mismo servidor los agentes “load” y “windGenerator”, responsables de la gestión de una carga y de un generador eólico respectivamente. El Main-Container podría haberse arrancado en cualquiera de los servidores mencionados, o en algún otro dispuesto para tal función. 2.4.3 2.4.32.4.3 2.4.3 Agentes en JADE: la clase Agent Agentes en JADE: la clase AgentAgentes en JADE: la clase Agent Agentes en JADE: la clase Agent Crear un agente en JADE es tan sencillo como extender la clase jade.core.Agent e implementar el método setup(), tal y como se muestra en el siguiente fragmento de código: import jade.core.Agent; public class MyAgent extends Agent { protected void setup() { // Comandos a ejecutar durante la inicialización. } } El agente continúa ejecutándose aunque no lleve a cabo ninguna tarea más allá de la propia inicialización. Para poner fin a su ejecución es necesario llamar al método doDelete(). Similar al método setup(), que es invocado por el JADE runtime tan pronto como un agente es iniciado y que lleva a cabo las inicializaciones antes mencionadas, el método takeDown() se invoca justo antes de eliminar el agente y está ideado para llevar a cabo operaciones de limpieza. public class Emergency_Agent extends Agent { protected void setup() { // Comandos a ejecutar durante la inicialización. if(emergency_mode == true) { // El agente continuará ejecutándose. } else { // Si no es necesario se procede a su eliminación. System.out.println(“System running properly. No extra ” + + “action required.”); doDelete(); } } protected void takeDown() { System.out.println(“Emergency-agent ” + getAID().getName()+ + “ terminating.”); } } Rafael Tallada Souto 27 2.4.4 2.4.42.4.4 2.4.4 Comportamientos Comportamientos Comportamientos Comportamientos Un agente realiza su función por medio de sus comportamientos o behaviours. Un comportamiento representa una tarea que un agente es capaz de llevar a cabo y es implementado en una clase que extiende la clase jade.core.behaviours.Behaviour. Para que un agente ejecute una tarea definida en un comportamiento, basta con llamar al método addBehaviour() de la clase Agent. Un comportamiento puede ser añadido en cualquier momento, ya sea en el inicio, cuando el agente ejecuta su método setup(); o desde cualquiera de sus otros comportamientos en ejecución. Una clase que extiende Behaviour debe implementar obligatoriamente dos métodos: action() y done(). El método action() define las operaciones a realizar mientras el comportamiento esté en ejecución, mientras que el done() retorna una variable booleana que especifica si el comportamiento ha sido completado, y tiene por tanto que ser retirado del pool de comportamientos activos. El gráfico de flujo de la Fig. 10 muestra el ciclo de vida de un agente. Los métodos que debe implementar el programador aparecen en color rojo. Fig. 10. Fig. 10.Fig. 10. Fig. 10. Ciclo de v Ciclo de vCiclo de v Ciclo de vida de un agente ida de un agenteida de un agente ida de un agente [12] [12][12] [12] 2 Conceptos previos 28 En el ejemplo que viene a continuación se ha programado un comportamiento llamado MyBehaviour mediante una extensión de la clase Behaviour. Las tareas del comportamiento se incluirían dentro del método action(). public class MyBehaviour extends Behaviour { public void action() { if (something == true) { // Lista de comandos a ejecutar. } } public boolean done() { return true; } } JADE ofrece clases para varios tipos de behaviours. Los tres más importantes son oneshot, cyclic y generic. • One OneOne One- -- -shot shotshot shot behavior behaviorbehavior behavior: :: : este comportamiento se ejecuta una única vez. La clase jade.core.behaviours.OneShotBehaviour implementa el método done() de forma que retorne siempre true, y puede extenderse para implementar comportamientos de esta naturaleza. public class MyOneShotBehaviour extends OneShotBehaviour { public void action() { // Realizar operación X. } } La operación X se realiza una única vez. • Cyclic CyclicCyclic Cyclic behaviour: behaviour:behaviour: behaviour: como su nombre indica, este comportamiento nunca detiene su ejecución y el método action() realiza las mismas operaciones cada vez que es llamado. La clase jade.core.behaviours.CyclicBehaviour implementa el método done() de forma que devuelva siempre false, y puede extenderse para implementar comportamientos que encajen en esta definición. public class MyCyclicBehaviour extends CyclicBehaviour { public void action() { // Realizar operación Y. } } La operación Y se realiza de manera cíclica. • Generic GenericGeneric Generic behaviours behavioursbehaviours behaviours: :: : las operaciones de este tipo de comportamientos varían en función de un estado interno del que se tiene memoria. Se comporta como una Máquina de Estados Finitos (Finite State Machine, FSM), que se mueve de una situación a otra cuando determinadas condiciones son verificadas: Rafael Tallada Souto 29 public class MyThreeStepBehaviour extends Behaviour { private int step = 0; public void action() { switch (step) { case 0: // Realizar operación X. step++; break; case 1: // Realizar operación Y. step++; break; case 2: // Realizar operación Z. step++; break; } } public boolean done() { return step == 3; } } Las operaciones X, Y y Z se llevan a cabo una tras otra hasta que el comportamiento se completa. JADE ofrece la posibilidad de combinar diferentes tipos de comportamientos simples para crear otros más con funciones más especializadas. Además de los tres behaviours antes mencionados, las librerías JADE cuentan con varias clases que contemplan situaciones más específicas. Por citar algunas: SequentialBehaviour, ParallelBehaviour y FSMBehaviour; cuyos nombres son lo suficientemente ilustrativos. 2.5 2.52.5 2.5 Antecedentes AntecedentesAntecedentes Antecedentes El empleo de tecnología de agentes para el control de microrredes ha ido ganando popularidad durante los últimos años. En la revisión bibliográfica llevada a cabo para el proyecto se han encontrado multitud de trabajos que siguen esta línea. A continuación se hará referencia a los que se han considerado de mayor interés. El artículo [13] ofrece una visión panorámica de las investigaciones llevadas a cabo por universidades e instituciones de Europa, EE.UU., Canadá y Japón en el ámbito de las microrredes. En algunos casos, estas investigaciones han conducido a la construcción de emuladores como el que se pretende realizar en CIRCE, y cuyo punto de partida es este PFC. El artículo [14] presenta un emulador de microrredes para uso docente e investigador. Este emulador implementa una parte de la microrred con elementos físicos reales tales como cargas, generadores, baterías y líneas de transmisión, y otra parte mediante simulación con software. Los desarrolladores se valen de la tecnología de agentes y del 2 Conceptos previos 30 framework JADE para implementar el control, y del programa LabVIEW para establecer las comunicaciones con los elementos reales anteriormente mencionados. En los artículos [15] y [16] se pueden encontrar otros dos ejemplos de microrredes emuladas en tiempo real mediante agentes JADE. Ambos hacen especial hincapié en la ontología del SMA desarrollado, especificando los tipos de agentes participantes y sus funciones. En [15], además, se contemplan dos modos de operación: microrred conectada a red y funcionamiento en isla. El artículo [17] presenta el sistema de control de una microrred de tres nodos, estableciendo tres niveles jerárquicos de control que designa como RMU, iNode e iSocket respectivamente. Las siglas de RMU corresponden a Remote Manager Unit, mientras que la “i” que actúa de prefijo para los Nodes (nodos) y Sockets (tomas o enchufes) se refiere a “Intelligent”. El enfoque por optimización clásica realizado en este PFC (capítulo 4) reproducirá esta misma estructura jerárquica, aunque con distinta nomenclatura. Por último, los artículos [18] y [19] combinan un control basado en SMA JADE con microrredes modeladas en Simulink. Ambos diseños se valen del middleware MACSimJX para establecer los canales de comunicación (bidireccionales) entre los agentes y la simulación. 31 3 33 3 Optimiz OptimizOptimiz Optimización aciónación ación mediante técnicas heurísticas mediante técnicas heurísticasmediante técnicas heurísticas mediante técnicas heurísticas En este capítulo se recoge el trabajo llevado a cabo para el proyecto OptimaGrid. OptimaGrid se enmarca dentro de la segunda convocatoria de proyectos del Programa de Cooperación Territorial Espacio Sudeste Europeo (SUDOE) 2007-2013, que apoya el desarrollo regional a través de la cofinanciación de proyectos transnacionales por medio del FEDER. OptimaGrid tiene como objetivos definir, diseñar e implementar sistemas de control inteligentes de la energía que permitan gestión en tiempo real de una micro-red de distribución de energía eléctrica, aplicada a un área industrial con elevado porcentaje de penetración de energías renovables. Fig. 11. Fig. 11.Fig. 11. Fig. 11. Logos de Logos de Logos de Logos de OptimaGrid, FEDER y SUDOE OptimaGrid, FEDER y SUDOEOptimaGrid, FEDER y SUDOE OptimaGrid, FEDER y SUDOE Se pretende lograr que las áreas industriales sean autogestionables energéticamente, y tratar de cambiar el concepto contaminante asociado a ellas por otro concepto de áreas ecológicas. Para ello se profundiza de nuevo en el concepto “Smart Grid” o Red Inteligente. La red inteligente es la convergencia de la energía eléctrica y las tecnologías de la información y la comunicación (TIC). En OptimaGrid se desarrollan procesos ubicuos en sistemas multiagente, que adoptan dinámicamente el balance generación-demanda, para conseguir un suministro de energía más eficiente, sostenible, económico y seguro, con la máxima prioridad en el uso de los recursos renovables locales. 3.1 3.13.1 3.1 Propuesta de trabajo Propuesta de trabajoPropuesta de trabajo Propuesta de trabajo El proyecto OptimaGrid ha sido llevado a cabo por varios socios, entre los que se encuentra la fundación CIRCE; ha tenido una duración de dos años, y ha seguido tres líneas principales de investigación: 1. Medidas de ahorro y eficiencia energética. 2. Sistemas de almacenamiento de energía. 3. Actuación sobre la curva de demanda. El trabajo realizado en el presente capítulo busca optimizar el uso de los sistemas de almacenamiento de una microrred, situándose por lo tanto dentro de la segunda línea de investigación. Se pretende implementar un sistema distribuido de gestión, basado en una arquitectura multiagente, que controle diversos aspectos de una microrred de forma autónoma. El framework elegido para dicha misión es JADE, por los motivos mencionados en el apartado 2.4. 3 Optimización mediante técnicas heurísticas 32 Este capítulo continúa el trabajo llevado a cabo por Hans Bludszuweit para OptimaGrid, recogido en un informe realizado para CIRCE [20], en el que se realizó un modelo en MATLAB-Simulink que llevaba a cabo la gestión del almacenamiento en función de varias estrategias de control. Los resultados obtenidos con este modelo serán usados como referencia para la validación del emulador de microrredes que se va a realizar. El emulador constaría de dos partes: 1) electrónica de potencia y 2) un simulador de la microrred. Esta propuesta de trabajo encaja perfectamente en el paradigma de simulación “Power Hardware in the Loop” (PHIL) [21], puesto que combina dispositivos hardware que funcionan en tiempo real (cargas, baterías, generadores, etc.) con software de simulación. La electrónica de potencia permitiría la emulación de cualquier generador o carga, así como la conexión con diversos dispositivos reales tales como generadores, baterías o cargas, mientras que el simulador de la microrred estaría formado por un clúster de ordenadores, y se encargaría de llevar a cabo los cálculos de flujos de potencia del resto de la microrred de una forma distribuida. De esta manera, el carácter distribuido de los generadores y cargas que componen una microrred podría ser reproducido en el simulador, al estar éste basado en una arquitectura multiagente. Cada elemento de la microrred (generadores, cargas, etc.) contará con un agente asociado. Una vez inicializados, los agentes deberán de ser capaces de actuar de forma independiente según hayan sido programados. El emulador ofrecerá flexibilidad “plug-andplay” [22]. Una de las principales características de los SMA es precisamente ésta: los agentes pueden “ser enchufados” o ser eliminados de forma totalmente asíncrona en cualquier momento de la ejecución. También pueden replicarse en caso de fallo para asegurar su propia supervivencia y el consiguiente funcionamiento del SMA. Cada agente asociado a un elemento de la microrred dispondrá de dos modos de funcionamiento: simulación y monitorización. En el modo simulación los inputs serán obtenidos de algún tipo de archivo, por ejemplo una hoja de cálculo Excel. De igual manera, los outputs quedarán recogidos en otro archivo con el que poder trabajar con posterioridad. Cuando un agente se encuentre en modo monitorización, los inputs provendrán de lecturas reales del elemento hardware en cuestión, que serán realimentadas a través de tarjetas DPS al agente encargado de su gestión. Los outputs del agente, es decir, las consignas de P y Q a ejecutar por el dispositivo real, se enviarán también al elemento físico por medio de las mismas tarjetas DSP. 3.2 3.23.2 3.2 Descripción del área sujeto de estudio Descripción del área sujeto de estudioDescripción del área sujeto de estudio Descripción del área sujeto de estudio Para validar el funcionamiento del emulador se ha optado por utilizar series temporales de datos reales de demanda y generación de un pequeño polígono industrial. Se trata de áreas en las que la actividad proviene principalmente de talleres, pequeñas factorías y almacenes. Este tipo de parques industriales es muy común en la zona del sudoeste europeo o SUDOE, que abarca Portugal, España y el sudoeste de Francia (Fig. 12). En la ciudad de Zaragoza existen varios polígonos y áreas que encajarían en este perfil, como El Portazgo o Mercazaragoza. La lectura de datos se ha realizado durante todo un año y en intervalos de 30 minutos. En cada lectura quedan registrados los valores medios de la demanda de potencia activa y del factor de potencia del polígono durante la última media hora. En cuanto a la generación, se dispone de sendas series temporales de oferta eólica y fotovoltaica con pasos de tiempo idénticos a los de la demanda. Por lo tanto, se cuenta con un total de 17520 muestras para cada una de las variables de entrada. Rafael Tallada Souto 33 Fig. 12. Fig. 12.Fig. 12. Fig. 12. Mapa del sudoeste e Mapa del sudoeste eMapa del sudoeste e Mapa del sudoeste europeo, SUDOE uropeo, SUDOEuropeo, SUDOE uropeo, SUDOE Ante tal cantidad de datos, resulta de gran utilidad poder analizarlos de forma visual mediante representaciones gráficas. Se ha optado por los diagramas de caja, que proporcionan información acerca de los valores mínimos y máximos que alcanza una variable, de los cuartiles (Q1, Q2 o mediana y Q3) y de la simetría de la distribución. 3.2.1 3.2.13.2.1 3.2.1 Recurso renovable Recurso renovable Recurso renovable Recurso renovable En la Fig. 13 y la Fig. 14 aparecen recogidos los datos de generación eólica y fotovoltaica respectivamente. La interpretación de este tipo de gráficos puede resultar engañosa si el lector no está familiarizado con ellos. Cada figura cuenta con 13 cajas: 12 cajas correspondientes a los meses del año más una última caja en la que se presenta agrupado el año completo. Cada mes cuenta con un rectángulo (caja) de la que salen dos líneas acabadas en un punto (bigotes). El punto superior representa el valor máximo que ha alcanzado la variable en dicho mes, mientras que el inferior representa su valor mínimo. El lado inferior de la caja marca el primer cuartil (Q1), es decir, informa de que el 25% de los valores recogidos durante ese mes están por debajo de dicho punto. El límite superior de la caja corresponde a Q3, el tercer cuartil. Q3 indica que el 75% de los valores de la muestra se sitúan por debajo de él. Finalmente, la línea negra en trazo grueso que une los distintos meses es la encargada de señalar la media aritmética de los valores. Se ha decidido incluir la media en lugar de la mediana (Q2) porque ofrece una mejor perspectiva de la evolución de la disponibilidad del recurso a lo largo del año. 3 Optimización mediante técnicas heurísticas 34 Fig. 13. Fig. 13.Fig. 13. Fig. 13. Recurso eólico anual Recurso eólico anualRecurso eólico anual Recurso eólico anual Los valores mínimos de cada uno de los meses son cero, correspondiendo a momentos en los que no hay potencia útil extraíble del recurso renovable. Exceptuando Julio y Agosto de la gráfica de recurso eólico (Fig. 13), todos los meses sitúan su Q1 en cero, o muy próximo a cero. Un primer cuartil situado en cero pone de manifiesto la gran variabilidad de las energías renovables y supone uno de sus principales inconvenientes. Al menos un 25% del tiempo la potencia extraíble del recurso renovable es nula. En el caso fotovoltaico (Fig. 14) es de prever, ya que durante la noche no hay generación alguna, pero en el caso eólico sí es reseñable que más de una cuarta parte del tiempo el aporte neto a la microrred sea cero. El pico de generación fotovoltaica se sitúa en los meses de primavera y verano, decayendo conforme se acerca el invierno, mientras que en la generación eólica se producen dos: uno en los meses de enero y febrero, y otro en los de julio y agosto. Fig. 14. Fig. 14.Fig. 14. Fig. 14. Recurso fotovoltaico anual Recurso fotovoltaico anualRecurso fotovoltaico anual Recurso fotovoltaico anual 0 50 100 150 200 250 300 ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC ANU Potencia generada [kW] 0 50 100 150 200 250 ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC ANU Potencia generada [kW] Rafael Tallada Souto 35 En la Fig. 15 se ha representado el recurso renovable total, esto es, la suma de generación eólica y fotovoltaica. En esta ocasión el promedio se mantiene razonablemente estable. El alto valor que presenta el recurso eólico en los meses de invierno compensa la escasa generación solar durante los mismos. Durante en verano, el incremento de potencia generada que presentan ambos recursos en sus respectivas gráficas se ve reproducido, como no podía ser de otra manera, en el pico de julio y agosto de la Fig. 15. Fig. 15. Fig. 15.Fig. 15. Fig. 15. Recurso renovable (eól Recurso renovable (eólRecurso renovable (eól Recurso renovable (eólico + fotovoltaico) ico + fotovoltaico)ico + fotovoltaico) ico + fotovoltaico) Para finalizar el análisis del recurso renovable anual, se presentan en la Tabla 2 cinco parámetros estadísticos de especial interés. Tal y como se podía intuir al ver las gráficas, el recurso eólico presenta mayor variabilidad y mayor potencia en general. El recurso fotovoltaico solo puede generar energía de día, de ahí que su mediana se sitúe casi en cero (0.18 kW). Variable VariableVariable Variable Media MediaMedia Media Mediana MedianaMediana Mediana DS ( DS (DS ( DS ( σ) σ)σ) σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo P wind 65.91 21.96 85.22 0 244.12 P pv 36.50 0.18 54.49 0 229.39 P total 102.40 66.87 104.55 0 461.71 Tabla 2. Tabla 2.Tabla 2. Tabla 2. Parámetros estadísticos de Parámetros estadísticos de Parámetros estadísticos de Parámetros estadísticos de las series temporales de P las series temporales de Plas series temporales de P las series temporales de P renovable (kW) renovable (kW)renovable (kW) renovable (kW) 3.2.2 3.2.23.2.2 3.2.2 Demanda y balance Demanda y balance Demanda y balance Demanda y balance de potencia en PCC de potencia en PCCde potencia en PCC de potencia en PCC Una vez estudiada la distribución estadística de la generación renovable del polígono industrial, se pasa a analizar de la distribución de su demanda. El perfil anual de la demanda se muestra en la Fig. 16, y su fisonomía difiere bastante del de la generación renovable. La línea horizontal que representa el consumo promedio de cada mes se mantiene entorno a los 75 kW durante prácticamente todo el año. En lo que a valores máximos y mínimos respecta, se observa una ligera variabilidad a lo largo del año. A los meses de febrero, marzo, septiembre y diciembre les corresponde un valor mínimo de cero kW. Estos valores tan atípicos se deben a cortes de luz esporádicos cuyas causas quedan fuera del alcance de este estudio previo. Sucede igual con el máximo del mes de marzo, al no disponer de información para identificar su origen. 0 50 100 150 200 250 300 350 400 450 500 ENE FEB MAR ABR MAY JUN JUL AGO SEP OCT NOV DIC ANU Potencia generada [kW] 3 Optimización mediante técnicas heurísticas 42      =   −   (3)      =   −   −   (4) La cuarta columna del fichero guarda los valores de potencia reactiva que la microrred importa de la red (la Q que no ha podido cubrir por sí sola). Se calcula con la ecuación (5 ) , cuyos subíndices son idénticos a los de (3 ) y (4 ) .   =   −   (5) El factor de potencia o Cos(φ) de la columna cinco se obtiene de forma directa conociendo los valores de P y Q en el punto de conexión a red (columnas tres y cuatro). Por último, el SOC recogido en la columna seis corresponde a la media aritmética de los SOC de las n baterías que componen la microrred.    ! = 1  # $  %  % & ' (6) Los archivos que producen los agentes instalados en un generador (agentes DG) siguen la estructura de la Tabla 6 y almacenan los valores de P y Q que llegan finalmente al bus AC de la microrred, así como la potencia pérdida en el proceso de transformación que se lleva a cabo en el convertidor asociado. Columna ColumnaColumna Columna Variable VariableVariable Variable Descripción DescripciónDescripción Descripción 1 t Tiempo de simulación [s] 2 P out Potencia activa entregada a la microrred [kW] 3 Q out Potencia reactiva entregada a la microrred [kVAr] 4 P losses Pérdidas en el convertidor [kW] Tabla 6. Tabla 6.Tabla 6. Tabla 6. Archivo de outputs: generador Archivo de outputs: generadorArchivo de outputs: generador Archivo de outputs: generador La Tabla 7 contiene las salidas de los agentes Storage, es decir, los agentes instalados en las baterías. Los agentes Storage cuentan con dos outputs adicionales respecto a los agentes DG: el valor de SOC y el de la corriente de salida. A diferencia de un generador, el valor de P out podrá tomar valores negativos. Valores positivos de P out e iout suponen cesión de potencia al bus de AC de la microrred y valores negativos, absorción. Columna ColumnaColumna Columna Variable VariableVariable Variable Descripción DescripciónDescripción Descripción 1 t Tiempo de simulación [s] 2 P out Potencia activa entregada a la microrred [kW] 3 Q out Potencia reactiva entregada a la microrred [kVAr] 4 P losses Pérdidas en el convertidor [kW] 5 SOC Estado de carga [%] 6 i out Corriente de salida [A] Tabla 7. Tabla 7.Tabla 7. Tabla 7. Archivo de Archivo de Archivo de Archivo de outputs outputsoutputs outputs: batería : batería: batería : batería Rafael Tallada Souto 43 3.3.2 3.3.23.3.2 3.3.2 Casos de estudio Casos de estudioCasos de estudio Casos de estudio Para validar el modelo se ha llevado a cabo un total de 20 simulaciones, ocho para la estrategia de Peak Shaving y doce para la de Smoothing. Con objeto de evaluar el impacto que suponen en el modelo los parámetros que dimensionan el SAE, se han considerado dos casos. El primer caso (caso A) establece una potencia nominal de 100 kW y una capacidad de 1 MWh, mientras que en el segundo (caso B) ambos parámetros han visto duplicado su valor. Como la microrred a emular cuenta con cuatro baterías, los valores de potencia y capacidad totales se han dividido por cuatro. Por ejemplo, para el caso A, cada una de las cuatro baterías tendrá una potencia nominal de 25 kW y una capacidad de 250 kWh. • Caso A: 100 kW / 1MWh → batería de 25 kW / 250 kWh (x4) • Caso B: 200 kW / 2MWh → batería de 50 kW / 500 kWh (x4) Por cada uno de los dos supuestos, se han tomado en consideración cuatro situaciones en relación con la generación renovable distribuida: 1) sin DG, 2) sólo generación eólica, 3) sólo generación fotovoltaica, y 4) eólica + fotovoltaica. Se tienen por lo tanto dos casos para cada una de las dos estrategias, en los que se consideran cuatro situaciones. Nótese que el tiempo de descarga de las baterías no varía de un caso a otro. Tanto en el caso A como en el caso B, las baterías se descargan por completo (suponiendo potencia nominal) en 10 horas. 3.3.3 3.3.33.3.3 3.3.3 Estrategias de control de P (potencia activa) Estrategias de control de P (potencia activa)Estrategias de control de P (potencia activa) Estrategias de control de P (potencia activa) Se han implementado dos estrategias de control de potencia activa en la microrred: Peak Shaving y Smoothing. El diseño realizado permite añadir nuevas estrategias o funciones de optimización sin tener que hacer modificaciones en el código. El agente PowerManager, máxima autoridad de la microrred, es el responsable de controlar el balance de P y Q. PowerManager aparece representado en la Fig. 20 por el recuadro blanco situado dentro del SMA (la nube de color morado). Fig. 20. Fig. 20.Fig. 20. Fig. 20. Ontología de control Ontología de control Ontología de control Ontología de control P y Q P y QP y Q P y Q 3 Optimización mediante técnicas heurísticas 44 Tal y como se ha explicado en el apartado 2.4.4, un agente lleva a cabo sus funciones a través de comportamientos. PowerManager dispone de un comportamiento dedicado en exclusiva al control. Dentro de este comportamiento se realiza una llamada al método getSetPoints(), al que se le pasa como parámetros tres vectores con toda la información necesaria de los generadores, baterías y cargas. El método getSetPoints() debe retornar un vector con las consigas que PowerManager enviará al resto de agentes participantes. Esta forma de operar ofrece mucha flexibilidad, ya que permite el empleo de cualquier control ad hoc, siempre y cuando éste retorne dicho vector. La manera de calcular estas consignas le es completamente irrelevante al agente y sólo es necesario indicarle cuál de las clases que tiene disponibles le corresponde utilizar para ello. El método getSetPoints() pertenece a la clase MainControl. A la hora de establecer la actuación de las baterías, MainControl solicitará ayuda a la clase que contenga la estrategia de P a ejecutar en ese momento. Esto ofrece un segundo nivel de modularidad, posibilitando un encaje muy directo de cualquier estrategia de control de las baterías que se quiera plantear. 3.3.3.1 3.3.3.13.3.3.1 3.3.3.1 Peak Shaving Peak ShavingPeak Shaving Peak Shaving El objetivo de esta estrategia de control de P es reducir los picos de demanda que sobrepasen un valor límite. La microrred del modelo cuenta con una gran potencia de generación instalada, con lo que será habitual encontrar valores negativos de P cc (la microrred cede energía a la red). Independientemente de su signo, las líneas tienen unos límites de potencia que son capaces de conducir sin resultar dañados, por lo que sobrepasar dichos límites puede ser problemático. La estrategia Peak Shaving se vale del SAE para procurar que esto no ocurra. Para ello se fijan dos límites, uno superior y otro inferior, que establecen la máxima potencia que la microrred puede intercambiar con la red eléctrica. En este caso concreto, tras el estudio llevado a cabo en el apartado 3.2, se ha decidido establecer los valores que aparecen en la Tabla 8. Parámetro ParámetroParámetro Parámetro No DG No DGNo DG No DG Eólica 250 kW Eólica 250 kWEólica 250 kW Eólica 250 kW F FF F V 250 V 250V 250 V 250 kW kWkW kW Eólica + FV 500 Eólica + FV 500Eólica + FV 500 Eólica + FV 500 kW kWkW kW P max [kW] 100 100 100 100 P min [kW] - - 100 - 100 - 100 Tabla 8. Tabla 8.Tabla 8. Tabla 8. Parámetros de control: Parámetros de control: Parámetros de control: Parámetros de control: Peak Shaving Peak ShavingPeak Shaving Peak Shaving Se ha optado por mantener los límites constantes independientemente de la generación instalada para centrar la atención del análisis en el impacto que los parámetros dimensionales del SAE tienen en el modelo. Si se quisiera trasladar el control a una microrred real sí sería necesario ajustar estos parámetros en función de la potencia renovable que se hubiera instalado. La mecánica de funcionamiento es muy sencilla. Por poner un ejemplo: si se detecta que la microrred está demandando 120 kW de la red, se dará orden a las baterías para que cedan 20 kW; manteniendo así el valor de P cc entre los límites marcados de ±100 kW. En ocasiones puede ocurrir que las baterías se encuentren tan descargadas que no dispongan de los 20 kW que hacen falta inyectar al bus AC durante todo el periodo de tiempo considerado (30 minutos). Para tratar de evitar esta situación en la medida de lo posible se ha ideado una rutina de carga/descarga automática de las baterías. Rafael Tallada Souto 45 La rutina automática de carga sólo entrará en funcionamiento cuando se den a la vez las siguientes condiciones: 1) No se sobrepasan los límites de potencia de la Tabla 8. 2) La batería se encuentra fuera del rango óptimo de SOC de la Tabla 9. Parámetro ParámetroParámetro Parámetro No DG No DGNo DG No DG Eólica 250 kW Eólica 250 kWEólica 250 kW Eólica 250 kW FV 250 kW FV 250 kWFV 250 kW FV 250 kW Eólica + FV 500 kW Eólica + FV 500 kWEólica + FV 500 kW Eólica + FV 500 kW SOC lower [% ] 90 40 40 30 SOC upper [% ] 100 50 50 40 Tabla 9. Tabla 9.Tabla 9. Tabla 9. Parámetros de carga/descarga Parámetros de carga/descarga Parámetros de carga/descarga Parámetros de carga/descarga autom automautom automática: Peak Shaving ática: Peak Shavingática: Peak Shaving ática: Peak Shaving El rango óptimo de SOC escogido varía de una situación a otra. En ausencia de DG, por ejemplo, los únicos picos que pueden producirse son los de consumo (positivos). Para recortar dichos picos las baterías ceden potencia a la red. De no existir una rutina automática de recarga, las baterías acabarían descargándose por completo, lo que imposibilitaría seguir aplicando el Peak Shaving. Mantener el SOC a un nivel predeterminado proporciona a la batería un margen de actuación razonable, tanto de carga como de descarga. La ecuación (7 ) sirve para, una vez activada la rutina automática, calcular las consignas de descarga de las baterías.  ( = 1 2 ∗ + ,  + ,  ∗ -  −   .//0  1 −   .//0 2 3 (7) La ecuación (8 ) es su equivalente para la carga.  0 = 1 2 ∗ 4 ,  + ,  ∗ 5   !60 −    !60 −  % 7 8 (8) La variable p batt es la potencia máxima que puede ceder o absorber la batería. Como la rutina automática se suele activar cuando el SOC se encuentra en valores intermedios, p batt será igual a la potencia nominal del SAE en cuestión. SOC lower y SOC upper son las variables que aparecen en la Tabla 9, mientras que SOC max y SOC min son los valores máximos y mínimos de carga permitidos. SOC es el estado de carga actual de la batería al inicio del periodo. Con estas ecuaciones se consigue que la recarga (y descarga) automática sea proporcional a la diferencia entre el SOC de la batería y el valor de SOC deseado. Cuanto más alejado se encuentre de este valor, más rápido se cargará. La Fig. 21 muestra la evolución de las consignas en función de ∆SOC, considerando una p batt de 50 kW, un SOC lower de 40% y un SOC min del 5%. 3 Optimización mediante técnicas heurísticas 46 Fig. 21. Fig. 21.Fig. 21. Fig. 21. Rutina RutinaRutina Rutina de carga automática de carga automáticade carga automática de carga automática El valor máximo de P se da con el máximo ∆SOC, es decir, cuando la batería se encuentra a su mínimo valor posible de SOC (en este caso el mínimo permitido es del 5%). Se tiene entonces que ∆SOC = 40 – 5 = 35%, a lo que le corresponde una potencia de carga igual a la nominal: 50 kW. Antes de enviar las órdenes con los valores de carga automática a sus destinatarios, los agentes Storage, la estrategia se asegura de que no se estén superando los límites P max y P min propios de la estrategia Peak Shaving. Si por causa de esta rutina se superara alguno de estos dos valores, el control truncaría la consigna calculada por las ecuaciones (7 ) y (8 ) hasta un valor tal que evite que sean sobrepasados. Por lo tanto, se supedita mantener el SOC en el intervalo deseado a la estrategia principal: evitar los picos de demanda. En la Fig. 22 se pueden observar los resultados conseguidos por la estrategia Peak Shaving durante la octava semana del año (febrero-marzo) en un escenario con DG eólica y fotovoltaica. La línea roja representa el valor original de P cc , es decir, el que tendría lugar en ausencia de baterías; la línea en color azul representa el flujo de potencia en PCC tras la actuación del Peak Shaving. Se ha elegido esta semana en concreto porque se producen varias situaciones que ayudarán a entender mejor el funcionamiento de la estrategia. Lo primero que se debe comprobar es si la estrategia Peak Shaving cumple o no con su razón de ser: recortar los picos. Un vistazo rápido basta para constatar que así es. Si se presta atención al día 1, se puede advertir un pico de demanda que ha sido recortado satisfactoriamente. En los días 2 y 3 se produce una serie de picos de generación que también son recortados con éxito. Por el contrario durante el día 6 tiene lugar un aumento repentino de la generación, que no puede ser contrarrestado con el aporte de las baterías. La potencia necesaria para recortar el pico del día 6 es superior a la máxima que las baterías son capaces de suministrar y se superan los -100 kW establecidos como límite (Tabla 8). A pesar de esta superación, el pico se atenúa considerablemente. En el día 7 se produce otro pico de generación no contrarrestado, pero esta vez la causa tiene su origen en el SOC de las baterías, cuya evolución aparece en la Fig. 23 y será explicada a continuación. 0 10 20 30 40 50 60 0% 5% 10% 15% 20% 25% 30% 35% Potencia de carga [kW] ∆SOC = SOClower - SOCmin Rafael Tallada Souto 47 Fig. 22. Fig. 22.Fig. 22. Fig. 22. Peak Shaving Peak ShavingPeak Shaving Peak Shaving: :: : 8ª semana. 8ª semana.8ª semana. 8ª semana. Fig. 23. Fig. 23.Fig. 23. Fig. 23. Evolución del SOC de las bater Evolución del SOC de las baterEvolución del SOC de las bater Evolución del SOC de las baterías: Peak Shaving ías: Peak Shavingías: Peak Shaving ías: Peak Shaving La Fig. 23 presenta la evolución del SOC global del conjunto de baterías que forman la microrred y va a servir para explicar dos situaciones que se dan en la Fig. 22. La primera de ellas tiene que ver con la rutina automática de carga y descarga. Durante los días 2 y 3 se producen varios picos de generación que son recortados a -100 kW. Sin embargo, cuando P cc (en rojo) vuelve a traspasar el límite inferior, las baterías lo siguen manteniendo a -100 kW (línea azul). Este modo de actuar se debe a la rutina automática de carga, que tiene órdenes de mantener el SOC entre el 30 y el 40%. En efecto, a lo largo de los días 2 y 3 el SOC de la -350 -300 -250 -200 -150 -100 -50 0 50 100 150 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 Pcc [kW] Inicial Final 0 20 40 60 80 100 120 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 SOC global de las baterías [%] 3 Optimización mediante técnicas heurísticas 48 batería fluctúa entre valores que están fuera del rango deseado. La estrategia aprovechará los periodos en los que la generación sea más moderada para vaciar sus baterías hasta el 40%, lo que le permitirá estar preparada para absorber los picos venideros, tanto de generación como de demanda. Lo mismo sucede al final del sexto día y principios del séptimo: las baterías mantienen el balance neto a -100 kW al descargarse de forma automática. La última situación de interés ocurre el último día de la semana, donde se produce un pico de generación que no puede ser ni siquiera atenuado. En este caso las baterías han alcanzado un 100% de SOC y ya no admiten más energía entrante, por lo que la curva de P cc final coincide con la del inicial. Este análsis pone en relieve la importancia de dimensionar correctamente el sistema, así como de establecer unos valores adecuados de SOC deseado. 3.3.3.2 3.3.3.23.3.3.2 3.3.3.2 Smoothing (a Smoothing (aSmoothing (a Smoothing (alisamiento de la curva de demanda lisamiento de la curva de demandalisamiento de la curva de demanda lisamiento de la curva de demanda) )) ) El objetivo de esta estrategia de control de P es suavizar cambios bruscos y picos de corta duración que se producen en la curva de demanda. La consigna de P se calcula mediante una sencilla media móvil con los últimos ω valores de P cc conocidos (9 ) .  0 # = 1 9 # $  % : % & ' (9) El resultado de esta estrategia se muestra en la Fig. 24, donde vuelve a aparecer el valor de P cc pre y post estrategia. La línea en rojo se corresponde con la potencia que la microrred intercambiaría con la red de no existir intervención del SAE, es decir, la curva de consumo menos la de generación. Al igual que para el Peak Shaving, se ha escogido la octava semana del año con objeto de poder comparar más fácilmente ambas estrategias. Fig. 24. Fig. 24.Fig. 24. Fig. 24. Smoothing: 8ª semana Smoothing: 8ª semanaSmoothing: 8ª semana Smoothing: 8ª semana ( (( (ω ωω ω=4 =4=4 =4, 1MWh , 1MWh, 1MWh , 1MWh) )) ) -350 -300 -250 -200 -150 -100 -50 0 50 100 150 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 Pcc [kW] Inicial Final Rafael Tallada Souto 49 El número de valores utilizados para calcular la media móvil en el ejemplo de la Fig. 24 ha sido de cuatro (ω = 4). El parámetro ω causa gran impacto en los resultados de la estrategia. Una ω pequeña provoca un escaso alisamiento de la curva: cuando la estrategia dispone de pocos valores de referencia para el cálculo de la media móvil, sólo se ven modificados los picos de más corta duración; lo que no tiene por qué suponer ningún problema per se. De ser ése el objetivo perseguido, no será necesaria una gran inversión en baterías. Cuanto menor sea ω, menor será la necesidad de disponer de un SAE con grandes prestaciones. Por el contrario, valores grandes de ω requieren disponer de un suministro de potencia sostenido en el tiempo y, por lo tanto, de un sistema de baterías con mayor capacidad y más caro. En el apartado 3.5 se expondrán los resultados obtenidos para un Smoothing con ω = 4 y ω = 8. La Fig. 25 presenta la evolución del estado de carga del conjunto de baterías correspondiente a la Fig. 24. La estrategia Smoothing no necesita de ninguna rutina de carga automática: la propia tendencia de la demanda es la que va cargando y descargando las baterías. Fig. 25. Fig. 25.Fig. 25. Fig. 25. Evolución del SOC de las baterías: Smoothing Evolución del SOC de las baterías: SmoothingEvolución del SOC de las baterías: Smoothing Evolución del SOC de las baterías: Smoothing (ω=4, 1MWh) (ω=4, 1MWh)(ω=4, 1MWh) (ω=4, 1MWh) Se observa que la estrategia Smoothing hace un uso más intensivo del SAE que la estrategia Peak Shaving (Fig. 23). En este caso no existen periodos de SOC constante, o lo que es lo mismo, periodos en los que la batería permanece inactiva. Alisar la curva de demanda supone un trabajo ininterrumpido ya que la consigna de P cc se calcula con una media móvil que no para de variar. Si las variaciones de la curva de demanda guardan cierta simetría, las positivas (picos de demanda) descargarán la batería en la misma medida que la recargan las negativas (picos de generación). El Smoothing es por tanto una estrategia fácil de implementar, a la par que efectiva. 0 10 20 30 40 50 60 70 80 90 100 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 SOC global de las baterías [%] 3 Optimización mediante técnicas heurísticas 50 Duplicar ω y modificar la capacidad del SAE de manera proporcional se consigue un alisado aún mayor de la curva de demanda. El valor de P cc final de la Fig. 26 (en azul) varía mucho más lentamente que en el caso de la Fig. 24, y obvia la mayor parte de los picos que tienen lugar en la línea del P cc inicial (en rojo). Fig. 26. Fig. 26.Fig. 26. Fig. 26. Smoothing: 8ª semana ( Smoothing: 8ª semana (Smoothing: 8ª semana ( Smoothing: 8ª semana (ω ωω ω=8 =8=8 =8, 2MWh , 2MWh, 2MWh , 2MWh) )) ) Fig. 27. Fig. 27.Fig. 27. Fig. 27. Evolución del SOC de las baterías: Smoothing ( Evolución del SOC de las baterías: Smoothing (Evolución del SOC de las baterías: Smoothing ( Evolución del SOC de las baterías: Smoothing (ω=8, 2MWh) ω=8, 2MWh)ω=8, 2MWh) ω=8, 2MWh) -350 -300 -250 -200 -150 -100 -50 0 50 100 150 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 Pcc [kW] Inicial Final 0 20 40 60 80 100 120 Día 1 Día 2 Día 3 Día 4 Día 5 Día 6 Día 7 SOC global de las baterías [%] Rafael Tallada Souto 51 La gráfica de la Fig. 27 constata nuevamente la carga de trabajo de las baterías. Los únicos periodos en los que no se registra actividad se corresponden a instantes de máxima y mínima carga (100 y 5%). El resto del tiempo la batería suplirá o absorberá potencia para cumplir con la consigna de la ecuación (9 ) . Por ejemplo, durante el pico de generación de los días 2 y 3 las baterías tratan de absorber el excedente cargándose por completo. Cuando esto ocurre la media móvil confluye rápidamente con el P cc actual y, en el momento en que se invertirse la tendencia, las baterías disponen de un 100% de SOC para actuar. Una media móvil de ocho valores provoca cierta “inercia” o reticencia a los cambios en la curva de demanda, pero sólo si es respaldada por un SAE que disponga de energía suficiente para compensar desviaciones durante grandes lapsos de tiempo. 3.3.4 3.3.43.3.4 3.3.4 Control de Q (potencia reactiva) Control de Q (potencia reactiva)Control de Q (potencia reactiva) Control de Q (potencia reactiva) El control de potencia reactiva es independiente de las estrategias de control de P. Se lleva a cabo dentro de la clase MainControl (ver Fig. 20) y sigue una máxima muy simple: tratar de copar la máxima demanda de potencia reactiva que sea posible con los recursos de los que dispone la propia microrred, lo que equivale a establecer una consigna de Cos(φ) = 1. La potencia reactiva es inyectada por los convertidores asociados a la DG, en los cuales Q tiene prioridad sobre la P. Los convertidores de las baterías también pueden inyectar Q, pero en este caso se da preferencia a P, lo que en la práctica implica que todo el peso del control de Q recaiga sobre los elementos de generación. Cada generador tiene asociado un factor de coste, que no es más que un input, y como tal, puede variar de un periodo a otro (ver apdo. 3.3.1.1). El control tratará de cubrir la demanda de reactiva al mínimo coste. Para ello utilizará primero la Q que oferta el generador con el menor coste asociado: la Q más barata. Si esto no fuera suficiente, seguirá con la segunda más barata, y así sucesivamente. Si se logra copar toda la demanda de reactiva de manera interna no se tendrá que importar Q de la red, por lo que el factor de potencia visto desde ésta será igual a la unidad. Para poder satisfacer la demanda de potencia reactiva al mínimo coste el agente de control (agente PowerManager) necesita saber cuánta Q le puede encargar a cada uno de los agentes DG y a qué precio. Como cualquier agente en un SMA, PowerManager no dispone de información global del sistema y se va a ver obligado a comunicarse con otros agentes para recabarla. PowerManager solicitará dicha información enviando un mensaje ACL en el marco del protocolo de comunicación FIPA-ContractNet, que será explicado en el apartado 3.4.2. Los agentes DG responderán a esta solicitud mediante otro mensaje ACL en el que se especificarán la potencia disponible (P in ), el coste asociado a la inyección de Q, la potencia aparente nominal (S max ) y el rendimiento (η) del convertidos asociado . Ahora que PowerManager conoce el estado y disponibilidad de cada agente suministrador de Q ya está en condiciones de realizar el cálculo de consignas para el periodo en curso mediante la secuencia de operaciones que se va a detallar a continuación. 3 Optimización mediante técnicas heurísticas 58 3.4.2.2 3.4.2.23.4.2.2 3.4.2.2 Clase ClaseClase Clases ss s ContractNetInitiator ContractNetInitiatorContractNetInitiator ContractNetInitiator y ContractNetResponder y ContractNetRespondery ContractNetResponder y ContractNetResponder Estas clases forman parte del framework de JADE y facilitan la implementación del rol del iniciador y del participante. Ambas clases se puede entender como una máquina de estados, puesto que derivan de la clase FSMBehaviour. Los estados de la FSM (Finite State Machine) de cada clase se pueden deducir a partir de la Fig. 32. La lógica que sigue la FSM para pasar de un estado a otro utiliza las recepciones y envíos de mensajes ACL a modo de trigger, y viene implementada por defecto en la propia clase. Bastará entonces con completar ciertos métodos que modifiquen esta lógica, así como los outputs de cada uno de los estados (si los hay). ContractNetInitiator y ContractNetResponder ponen a disposición del programador una serie de métodos con los que especificar cómo actuar en cada uno de los estados de la FSM. Estos métodos están “en blanco” y corresponde al desarrollador sobrescribirlos para dotarlos de funcionalidad. A continuación se va a proceder a enumerarlos, siguiendo el flujo del diagrama de la Fig. 32: 1) El iniciador solicita propuestas a otros agentes enviando n mensajes ACL de CFP que especifiquen la acción solicitada y las condiciones de ejecución. El programador dispone para ello del método prepareCfps(). Este método exige retornar un vector con las CFP a enviar (normalmente un mismo mensaje ACL con múltiples receptores). 2) Los participantes podrán enviar entonces una propuesta (PROPOSE) en la que se incluyan todas condiciones bajo las que llevarían a cabo su propuesta (precio, tiempo…). Si no realizan ninguna propuesta, los participantes enviarán un mensaje de REFUSE o, si ha habido problemas en la comunicación, un NOT-UNDERSTOOD. El método prepareResponse() es ejecutado cada vez el participante recibe una CFP, por lo que deberá implementarse para dar la respuesta adecuada. 3) ContractNetInitiator identifica los mensajes PROPOSE como “respuestas” (responses) y cuenta con dos métodos para sobrescribir con los que implementar las reacciones del iniciador: handlePropose() y handleAllResponses(). El método handlePropose() se ejecuta de forma independiente con cada PROPOSE, mientras que handleAllResponses() lo hace cuando han sido recibidas todas las propuestas o ha finalizado un tiempo de espera predeterminado. Desde cualquiera de estos dos métodos se puede enviar el correspondiente mensaje de ACCEPT-PROPOSAL (o REJECT-PROPOSAL) en el que se comunique al participante las tareas que debe realizar. El método handleRefuse() especificará la reacción del iniciador ante un mensaje de REFUSE y el handleNotUnderstood() dictaminará el proceder en caso de recibir un NOT-UNDERSTOOD. 4) Los participantes cuyas propuestas fueron aceptadas y que hayan completado su tarea podrán responder con un mensaje INFORM. Si algo ha ido mal, responderán con un mensaje FAILURE. El método en el que se debe llevar a cabo esta acción es prepareResultNotification(). Tanto ContractNetInitiator como ContractNetResponder disponen de métodos que se ejecutan cuando reciben un mensaje ACL que no cumple las especificaciones del protocolo. De nuevo corresponde al programador dotarles de utilidad práctica. Rafael Tallada Souto 59 En el modelo implementado, se utiliza el protocolo FIPA Contract Net para organizar el reparto de potencias entre los distintos elementos de la microrred. En este proceso de “subasta”, los agentes sólo tienen en cuenta un tipo determinado de mensaje (a veces más de uno) según el estado de la FSM en el que se encuentren. Por ejemplo, si ya se ha cerrado el periodo de aceptación de ofertas, ContractNetInitiator ignorará cualquier mensaje de PROPOSE que pudiera recibir. Para una mayor robustez y seguridad en las comunicaciones, se han establecido dos campos adicionales obligatorios para cualquier mensaje ACL referido al proceso de negociación de consignas, que se muestran en la Tabla 11. C CC C ampo ampoampo ampo Descripción DescripciónDescripción Descripción Protocol "fipa - contract - net" Conversation - id “AUCTION” Tabla 11. Tabla 11.Tabla 11. Tabla 11. Campos comunes a todos los mensajes ACL del proceso de subasta Campos comunes a todos los mensajes ACL del proceso de subastaCampos comunes a todos los mensajes ACL del proceso de subasta Campos comunes a todos los mensajes ACL del proceso de subasta De ahora en adelante, si no se especifica lo contrario, se asume que todo mensaje ACL incluye también estos dos campos. 3.4.3 3.4.33.4.3 3.4.3 Agentes AgentesAgentes Agentes En los siguientes cuatro subapartados se detallarán las principales características de cuatro de los cinco agentes implementados para la ocasión, así como información acerca de los mensajes ACL con los que participan en el protocolo FIPA Contract Net. El quinto agente (agente SerialPort) no intercambia ningún mensaje, por lo que no se ha creído necesario incluir explicaciones adicionales a las que se recogen en el apartado 3.4.6, donde se aborda el modo monitorización. 3.4.3.1 3.4.3.13.4.3.1 3.4.3.1 Agente Power Manager Agente Power ManagerAgente Power Manager Agente Power Manager PowerManager extiende la clase Agent para implementar el rol de controlador de la microrred. Exhibe dos comportamientos principales: AMSSubscriberPM y MailBoxPQControl. AMSSubscriberPM es un comportamiento cíclico derivado de la clase AMSSubscriber. Con este comportamiento PowerManager se puede subscribir al servicio de páginas amarillas del agente DF, que le avisa del nacimiento o muerte de cualquier agente DG, Storage o Load, pudiendo así actualizar una lista en la que guarda las AID de los miembros activos de la microrred. Será a los miembros que estén en dicha lista a los que PowerManager enviará las CFP que dan inicio al protocolo FIPA Contract Net. El comportamiento MailBoxPQControl extiende ContractNetInitiator y se ocupa del control propiamente dicho. El nombre MailBox hace referencia a su función de procesado de mensajes ACL. La información interna, tanto de entrada como de salida es almacenada en los vectores de objetos que recoge en la Tabla 12. 3 Optimización mediante técnicas heurísticas 60 Vector VectorVector Vector Almacena… Almacena…Almacena… Almacena… infoGen …la información de cada uno de los generadores activos de la microrred. infoStor …la información de cada uno de las baterías activas de la microrred. infoLoad …la información de cada uno de las cargas activas de la microrred. SetPointsPQ …las consignas de P y Q para todos los elementos activos de la microrred. DataOut …los outputs para cada uno de los periodos. Tabla 12. Tabla 12.Tabla 12. Tabla 12. Vectores utilizados por Vectores utilizados por Vectores utilizados por Vectores utilizados por MailBoxPQControl Como cualquier clase que extienda ContractNetInitiator, MailBoxPQControl sobrescribe los métodos especificados en el apartado 3.4.2.2, de los que se pasa a comentar los más relevantes: • handlePropose: es llamado cada vez que se reciba un mensaje ACL de PROPOSE que cumpla con las especificaciones del protocolo. El método procesa las propuestas según hayan sido enviadas por un agente DG, Storage, o Load; y guarda la información extraída en los vectores de la Tabla 12. • handleAllResponses: se ejecuta tras haber recibido las n propuestas esperadas (o tras agotarse el tiempo de subasta), es decir, tras haberse realizado n llamadas a handlePropose. En este método se hace la llamada al método getSetPoints, al que se le pasa como parámetros infoGen, infoStor e infoLoad y el cual retorna SetPointsPQ. Una vez que se dispone del vector de consignas SetPointsPQ, se procede a enviar los correspondientes mensajes de ACCEPT-PROPOSAL a los agentes que cuyas ofertas han sido aceptadas (Tabla 13). Campo CampoCampo Campo Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades P_SETPOINT Consigna de potencia activa kW Q_SETPOINT Consigna de potencia reactiva kVAr Tabla 13. Tabla 13.Tabla 13. Tabla 13. Mensaje ACL de Mensaje ACL de Mensaje ACL de Mensaje ACL de ACCEPT ACCEPTACCEPT ACCEPT- -- -PROPOSAL PROPOSALPROPOSAL PROPOSAL enviado por el agente enviado por el agente enviado por el agente enviado por el agente PowerManager • handleInform: es llamado cada vez que se reciba un mensaje ACL de INFORM que cumpla con las especificaciones del protocolo. En dichos mensajes los agentes participantes informan de los resultados de sus acciones: los agentes DG comunican sus P y Q de salida (P out y Q out ), que pueden no coincidir con las consignas que PowerManager envió. Los agentes Storage notifican, además de P out y Q out , su SOC al final del periodo. Los valores de P out , Q out y SOC se van sumando a tres variables internas para poder calcular posteriormente los balances globales de P y Q, y el SOC medio del conjunto de baterías. • handleAllResultNotifications: se ejecuta tras haber recibido los n ACL mensajes de INFORM esperados. Este método calcula los balances globales de P y Q, así como el Cos(φ) visto desde el lado de red, y el SOC global de las baterías. Rafael Tallada Souto 61 Para ello se vale de las tres variables internas en las que handleInform fue guardando P out , Q out y SOC de cada uno de los informantes. Una vez calculados estos valores globales, se almacenan en el vector DataOut y se reinician las variables internas para una nueva iteración del protocolo Contract Net. 3.4.3.2 3.4.3.23.4.3.2 3.4.3.2 Agente DG Agente DGAgente DG Agente DG Este agente se instala en un punto de generación distribuida y gestiona tanto el propio generador como su convertidor asociado. Cuenta con un comportamiento llamado MailBoxDG que hereda las características de ContractNetResponder, implementando así el rol de participante del protocolo FIPA Contract Net. Los métodos sobrescritos por MailBoxDG para la ocasión son: • handleCfp: es llamado cuando se reciba un mensaje ACL de CFP que cumpla ciertos requisitos del protocolo. El agente DG responderá a dicha CFP mediante un mensaje de PROPOSE con la información de la Tabla 14. Campo CampoCampo Campo Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades AGENT_SERVICE Servicio prestado: generación - -- - POWER_RESOURCE Potencia renovable disponible kW PRICE Factor de coste €/kVAr VSC_MAX_APPARENT_POWER Potencia aparente nominal del convertidor asociado kVA CONVERTER_EFF Eficiencia del convertidor asociado º/1 Tabla 14. Tabla 14.Tabla 14. Tabla 14. Mensaje ACL de Mensaje ACL de Mensaje ACL de Mensaje ACL de PROPOSE PROPOSEPROPOSE PROPOSE enviado por el agente enviado por el agente enviado por el agente enviado por el agente DG • handleAcceptProposal: el comportamiento llamará a este método cuando reciba un mensaje de ACCEPT-PROPOSAL que satisfaga las condiciones establecidas por ContractNetResponder. Dicho mensaje de aceptación contendrá las consignas de la Tabla 13, que serán pasadas como parámetros a la instancia de la clase Converter, es decir, al convertidor asociado al elemento generador. Cuando el convertidor recibe las consignas, les aplica una eficiencia para obtener los valores de P y Q a la salida, valores que son realimentados al agente para que éste pueda, si no ha surgido ningún problema, incluirlos en un mensaje de INFORM y enviárselos al agente PowerManager. Si algo ha salido mal el agente responderá con un mensaje de FAILURE. Campo CampoCampo Campo Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades AGENT_SERVICE Servicio prestado: generación - P_OUT Potencia activa a la salida del convertidor kW Q_OUT Potencia reactiva a la salida del convertidor kVAr Tabla 15. Tabla 15.Tabla 15. Tabla 15. Mensaje ACL de Mensaje ACL de Mensaje ACL de Mensaje ACL de INFORM INFORMINFORM INFORM enviado por el agente enviado por el agente enviado por el agente enviado por el agente DG 3 Optimización mediante técnicas heurísticas 62 3.4.3.3 3.4.3.33.4.3.3 3.4.3.3 Agente Storage Agente Storage Agente Storage Agente Storage Este agente se instala en un punto de almacenamiento de energía y gestiona tanto la batería como el convertidor con el que se conecta al bus AC. De forma análoga al agente DG, Storage cuenta con un comportamiento llamado MailBoxStorage que extiende ContractNetResponder para implementar el rol de participante en el protocolo FIPA Contract Net. Los métodos sobrescritos son los mismos que los del agente DG (extienden la misma clase), aunque las funcionalidades implementadas cambian: • handleCfp: es llamado cuando se recibe un mensaje ACL de CFP que cumpla los requisitos. El agente Storage responderá a dicha CFP mediante un mensaje de PROPOSE con la información de la Tabla 16. Campo CampoCampo Campo Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades AGENT_SERVICE Servicio prestado: almacenaje - -- - CHARGE_POWER_OFFER P disponible para carga kW DISCHARGE_POWER_OFFER P disponible para descarga kW CHARGING_REACTIVE_OFFER Q disponible en carga kVAr DISCHARGING_REACTIVE_OFFER Q disponible en descarga kVAr PRICE Factor de coste €/kVAr Tabla 16. Tabla 16.Tabla 16. Tabla 16. Mensaje ACL de Mensaje ACL de Mensaje ACL de Mensaje ACL de PROPOSE PROPOSEPROPOSE PROPOSE enviado por el agente enviado por el agente enviado por el agente enviado por el agente Storage Las baterías ofrecen P y Q distintas para carga y descarga, ya que Storage desconoce a priori si se le va pedir que ceda o que absorba energía. Por ejemplo, una batería cargada al 100% ofrecerá su potencia nominal para descarga, pero no podrá ofrecer potencia de carga (no podrá absorber P); y viceversa. La secuencia de cálculo de las ofertas es muy simple: Storage conoce la potencia aparente máxima que puede entregar su convertidor (S con ), así como el estado de la batería al inicio del periodo. Esta información le permite calcular la potencia activa ofertada (P of ), tanto de carga como de descarga. La oferta de potencia reactiva (Q of ) se calcula mediante la ecuación (14 ) , introduciendo cada vez uno de los dos valores de P of .  !? = @   !   − A  !? B  (14) A diferencia de los agentes DG, que priorizan la inyección de Q sobre el suministro de P, los agentes Storage van a dar preferencia a P sobre Q. • handleAcceptProposal: la implementación de este método es idéntica a la del agente DG (apdo. 3.4.3.2), por lo que no se va a volver a explicar aquí. Rafael Tallada Souto 63 3.4.3.4 3.4.3.43.4.3.4 3.4.3.4 Agente Load Agente LoadAgente Load Agente Load Este agente se instala en un punto de consumo y monitoriza la demanda de potencia activa y reactiva. El comportamiento que implementa su rol de participante en el protocolo FIPA Contract Net es MailBoxLoad, que también deriva de ContractNetResponder. Las funciones de este agente son mucho más sencillas que las de los agente DG y Storage, e incluso se podría haber planteado un diseño en el que las cargas no contaran con su propio agente asociado. Se ha decidido aun así dotarlas del rango de agente con vistas a futuras expansiones del emulador. Además, el hecho de que las cargas puedan intervenir como participantes en el proceso de reparto de energía simplifica sobremanera el funcionamiento del conjunto. Los métodos sobrescritos para la ocasión son: • handleCfp: es llamado cada vez que se recibe una CFP que cumpla los requerimientos del protocolo. Si la carga registra consumo en ese periodo responderá con un mensaje de PROPOSE, cuyo contenido aparece en la Tabla 17; de lo contrario responderá con un REFUSE. Campo CampoCampo Campo Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades P_DEMAND Demanda de potencia activa kW Q_DEMAND Demanda de potencia reactiva kVAr Tabla 17. Tabla 17.Tabla 17. Tabla 17. Mensaje ACL de Mensaje ACL de Mensaje ACL de Mensaje ACL de PROPOSE PROPOSEPROPOSE PROPOSE enviado por el agente enviado por el agente enviado por el agente enviado por el agente Load (Con la implementación actual, el agente PowerManager acepta cualquier propuesta enviada por un agente Load). • handleAcceptProposal: la implementación es idéntica a la del apartado 3.4.3.2, con la salvedad de que las cargas se conectan de forma directa al bus AC. No será por tanto necesaria la intermediación de ningún convertidor, y el mensaje ACL de INFORM con el que el agente Load responderá a PowerManager contendrá los mismos valores de P y Q que le indicó éste en el mensaje de aceptación de propuesta (que a su vez son idénticos a los que Load le propuso en un principio). 3.4.4 3.4.43.4.4 3.4.4 Elementos físicos Elementos físicosElementos físicos Elementos físicos Por cuestiones de diseño, se ha preferido que los modelos del convertidor y de la batería sean implementados como objetos Java, de los que los agentes pueden crear una instancia (ver apdo. 2.3.2), en lugar de como agentes en sí. Se busca así caracterizarlos como elementos pasivos, como dispositivos carentes de inteligencia que los agentes pueden crear, eliminar o manejar a su antojo. 3.4.4.1 3.4.4.13.4.4.1 3.4.4.1 Modelo del convertidor Modelo del convertidorModelo del convertidor Modelo del convertidor. Clase Converter. . Clase Converter.. Clase Converter. . Clase Converter. Con esta clase se modelan los convertidores que tanto los agentes DG como los agentes Storage utilizan para conectarse al bus AC de la microrred. Aunque se suponen distintas topologías (Fig. 18), se ha implementado un único modelo de convertidor para todas ellas. En la Fig. 33 aparece un conversor AC-AC con enlace por corriente continua. Sea o no sea ésta la topología del convertidor en cuestión, el conjunto puede ser considerado una “caja negra”, de la que sólo son relevantes sus entradas y salidas. 3 Optimización mediante técnicas heurísticas 64 Dicha caja negra quedaría delimitada por la línea de trazos y puntos que rodea a los dos VSC. Con esta simplificación se obtiene un modelo de convertidor al que le entran una serie de inputs (P in ) y, en función de unos parámetros característicos (S y η), produce unos outputs (P out , Q out y P losses ). Fig. 33. Fig. 33.Fig. 33. Fig. 33. Modelo del converti Modelo del convertiModelo del converti Modelo del convertidor dordor dor Los parámetros característicos del convertidor son su potencia aparente nominal (S) y su eficiencia o rendimiento (η) y se corresponden con las constantes max_aparent_power y EFF. Las variables internas de la clase Converter son tres: • p_out: potencia activa a la salida del convertidor (P out ), en kW. • q_out: potencia reactiva a la salida del convertidor (Q out ), en kVAr. • p_losses: potencia pérdida en la conversión (P losses ), en kW. La clase convertidor cuenta con seis métodos públicos del tipo “get” (getters) accesibles por cualquier agente que haya creado previamente una instancia del objeto. En todos ellos se retorna una de las constantes o variables mencionadas anteriormente. Por ejemplo el método getEfficiency() retorna el valor del rendimiento, el método getP(SetPointP) retorna la p_out para una consigna de P dada y el método getPowerLosses() devuelve el valor de la variable p_losses. 3.4.4.2 3.4.4.23.4.4.2 3.4.4.2 Modelo de la batería Modelo de la bateríaModelo de la batería Modelo de la batería. Clase Battery. . Clase Battery.. Clase Battery. . Clase Battery. Con esta clase se modelan las baterías. Cada agente Storage crea una instancia del objeto Battery en su inicialización, dentro del método setup(). Una vez hecho esto, el agente Storage pasa a tener el control de la batería y puede llevar a cabo múltiples tareas a través de sus métodos. Las constantes que caracterizan la batería son: • nom_power: potencia máxima que el sistema permite ceder o absorber, en kW. • nom_voltage: voltaje nominal de salida, en V. • capacity: cantidad de energía que la batería es capaz de almacenar, en kWh. • min_soc: mínimo estado de carga permitido, en %. • max_soc: máximo estado de carga permitido, en %. • initial_soc: estado de carga inicial, en %. Rafael Tallada Souto 65 Para facilitar las operaciones internas se dispone de las variables energy_capacity y energy_stored, expresadas en kJ y cuyos nombres son suficientemente representativos. Battery dispone de un de ocho métodos accesibles por el agente Storage. De entre los que se pueden destacan getMaxChargePowerOffer, getMaxDischargePowerOffer y discharge. El protocolo FIPA-ContractNet exige a cada agente una propuesta u oferta y el agente Storage no es una excepción. Storage oferta la potencia activa almacenada en su batería. Esta oferta no depende de la disponibilidad del recurso, como en el caso de las ofertas de los generadores, sino que dependerá únicamente de su SOC o estado de carga interno. Una batería totalmente descargada no podrá ofrecer potencia de descarga, pero sí podrá ofrecer su máxima potencia de carga. Por el contrario, una batería totalmente cargada no tiene capacidad de absorber más energía por lo que la potencia de carga será igual a cero. Los métodos getMaxChargePowerOffer y getMaxDischargePowerOffer guardan gran similitud entre sí. Cuando son llamados por Storage, primeramente calcularán la energía almacenada. Para el supuesto de carga se emplea la ecuación (15 ) y para el de descarga la ecuación (16 ) . La variable E a representa la energía disponible (available), expresada en kJ. El resto de variables corresponden a las constantes mencionadas anteriormente: SOC min y SOC max a min_soc y max_soc respectivamente, SOC cu al estado de carga al inicio del periodo (current), y E c a energy_capacity. ;  = 5  1 −  . 100 7 ∗ ;  (15) ;  = 5  . −  % 100 7 ∗ ;  (16) Una vez obtenida la energía disponible E a , y sabiendo que la potencia es energía consumida por unidad de tiempo, se calcula el valor máximo de potencia que sería capaz de entregar la batería durante todo el periodo Ts. Como se está trabajando con periodos treintaminutales, Ts tendrá un valor de 1800 segundos. Por ejemplo, si el valor de max_power_offer (P max ) fuera 450 significaría que hay energía suficiente para entregar 450 kW de forma ininterrumpida durante los próximos 30 minutos.  1 = ;  D ( (17) En la inmensa mayoría de los casos este valor será superior al de potencia máxima permitida (nom_power). Para que esto no suceda, la variable max_power_offer es evaluada por un sencillo if statement antes de ser retornada por el método. Si se supera la potencia nominal, la oferta se trunca al valor de ésta. 3 Optimización mediante técnicas heurísticas 66 3.4.5 3.4.53.4.5 3.4.5 Otras OtrasOtras Otras clases clasesclases clases El emulador cuenta con muchas más clases Java además de los agentes y de los modelos de convertidores y baterías. Por razones de espacio no es posible incluir explicaciones de cada una de ellas, pero se proporciona la Tabla 18 a modo de resumen. Package PackagePackage Package Clase ClaseClase Clase Función FunciónFunción Función Strategies MainControl Control de Q, c álculo de valores agregados de P y Q PeakShaving Control de P: Peak Shaving Smoothing Control de P: Alisamiento de la curva de demanda Inputs InputGenerator Guardar los inputs de la DG (potencia y precio) ReaderInputDem Leer los ficheros .xlsx de demanda ReaderInputGenerator Leer os ficheros .xlsx de generación Data Members Guardar la AID de los miembros activos de la microrred DataGenerator Almacena r la información de la generación DataStorage Almacena r la información del almacenamiento DataDemand Almacena r la información de la demanda SetPoints Almacena r las consignas de P y Q Outputs OutputControl Almacena r los outputs del agente de control OutputGenerator Almacena r los outputs de l agente instalado en la DG OutputStorage Almacena r los outputs del agente instalado en una batería SerialPort TwoWaySerialComm Asistir en la configuración y manejo del puerto serie Assistant Arguments Argumentos pasados a los agentes en su arranque Constants Interfaz Java con las constantes comunes a toda el SMA myDummy (Agente) Ayudar en las tareas de depuración de fallos Tabla 18. Tabla 18.Tabla 18. Tabla 18. Clases secundarias Clases secundariasClases secundarias Clases secundarias El package “Strategies” lleva a cabo el control P/Q de los apartados 3.3.3 y 3.3.4. En el package “Inputs” se encuentran las clases que gestionan los inputs de generación y demanda para el modo simulación. El package “Data” contiene las clases utilizadas para almacenar los datos en las operaciones intermedias. Por ejemplo, la clase DataGenerator alberga variables para almacenar los parámetros de la Tabla 16. PowerManager se valdrá de un vector de objetos DataGenerator para guardar la información suministrada por todos y cada uno de los agentes Storage participantes. Las clases del package “Outputs” almacenan los datos de salida del periodo, y se organizan en grandes vectores (arrays con funcionalidades extra) para ser posteriormente volcados a ficheros .cvs. Rafael Tallada Souto 67 3.4.6 3.4.63.4.6 3.4.6 Modo monitorización Modo monitorizaciónModo monitorización Modo monitorización Si bien el modo monitorización se deja como línea de continuidad para futuros desarrollos del emulador, se han realizado algunos ensayos para verificar su viabilidad. Un agente asociado a un elemento físico de la microrred (generadores, baterías o cargas) puede funcionar en modo simulación, como se ha visto hasta ahora, o en modo monitorización. En el modo simulación los datos de entrada provenían de ficheros .xlsx, mientras que los de salida se almacenaban ficheros .csv. En modo monitorización, por el contrario, los datos se obtienen comunicándose en tiempo real con el elemento físico. Para posibilitar esta comunicación se dispondrá de tarjetas DSP (Digital Signal Processing), que actuarán como intermediarias entre el ordenador en el que se ejecuta el agente y el convertidor que gobierna el elemento real. Dichas tarjetas cuentan con salidas del tipo “puerto serie” y pueden conectarse a un puerto COM del PC para enviar o recibir paquetes de datos bit a bit, es decir, en serie. En el apartado 3.6.2.1, correspondiente a las líneas futuras del emulador, se ha incluido un esquema de esta configuración (Fig. 53). La comunicación serie es el protocolo de bajo nivel más común para la comunicación entre dos o más dispositivos. Normalmente un dispositivo es un ordenador, mientras que el otro dispositivo puede ser un módem, una impresora, otro ordenador, o un instrumento científico como un osciloscopio o, como en esta ocasión, una tarjeta DSP. El puerto serie envía y recibe bytes de información utilizando un formato binario o un formato de texto del tipo ASCII. Antes de enviar o recibir datos, el puerto serie y el instrumento han de tener la misma configuración de comunicación. Para ello es necesario definir los siguientes parámetros: Parámetro ParámetroParámetro Parámetro Descripción DescripciónDescripción Descripción BaudRate Velocidad de transmisión de datos DataBits Número de bits a transmitir en un dato Parity Hablita/ deshabilita el chequeo de la paridad StopBits Numero de bits para indicar el final de un byte Terminator Carácter terminación Flow Control Control de hardware Time out Tiempo límite de comunicación Tabla 19. Tabla 19.Tabla 19. Tabla 19. Parámetros que definen la comunicación serie Parámetros que definen la comunicación serieParámetros que definen la comunicación serie Parámetros que definen la comunicación serie Para validar este concepto se ha creado un nuevo agente: el agente SerialPort. Este agente tiene la capacidad de comunicarse con el puerto COM del PC, tanto para configurarlo según la Tabla 19 como para enviar y recibir datos a través de él. Naturalmente, puede haber más de uno dependiendo de cómo esté distribuida la plataforma multiagente. 3 Optimización mediante técnicas heurísticas 74 3.5.2 3.5.23.5.2 3.5.2 Microrred con DG Microrred con DGMicrorred con DG Microrred con DG Los resultados que vienen a continuación provienen de simulaciones en las que sí se ha considerado generación distribuida. Concretamente, se ha considerado tres posibilidades: 1) Generación eólica (250 kW). 2) Generación fotovoltaica (250 kW). 3) Generación eólica + fotovoltaica (250 + 250 = 500 kW). 3.5.2.1 3.5.2.13.5.2.1 3.5.2.1 Control de P Control de PControl de P Control de P La utilidad de las estrategias de control de P se ve reforzada con la introducción de DG en la microrred. El recurso renovable es inconstante y, en cierto modo, imprevisible. El intercambio de potencia activa con la red va a variar enormemente, exigiendo respuestas rápidas por parte del control tendentes a minimizar las fluctuaciones. Generación eólica Generación eólicaGeneración eólica Generación eólica La Tabla 27 recoge los resultados conseguidos por las estrategias de P en un escenario con generación eólica: Variable VariableVariable Variable Media MediaMedia Media Mediana MedianaMediana Mediana DS (σ) DS (σ)DS (σ) DS (σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo P cc (inicial) 23.6 47.3 72.7 - 189.1 246.5 P cc 1A 23.6 47.8 69.9 - 187.9 233.4 P cc 1B 23.5 47.9 69.1 - 155.1 224.1 P cc 2A ω=4 23.5 42.8 65.4 - 179.2 215.7 P cc 2B ω=4 23.5 42.9 65.0 - 179.2 201.3 P cc 2B ω=8 23.5 44.1 65.0 - 189.1 233.4 Tabla 27. Tabla 27.Tabla 27. Tabla 27. Parámetros estadísticos Parámetros estadísticos Parámetros estadísticos Parámetros estadísticos de las estrategias de P: DG eólica (kW) de las estrategias de P: DG eólica (kW)de las estrategias de P: DG eólica (kW) de las estrategias de P: DG eólica (kW) Lo primero que llama la atención respecto al escenario de la Tabla 23 (no DG) es el efecto que la generación provoca en media y mediana. Si en el anterior escenario el valor promedio de P cc se situaba próximo a 77 kW, ahora lo hace en torno a 23.5 kW. La σ se mueve en dirección contraria y ve duplicado su valor, como resultado de combinar variaciones de la demanda con variaciones de la generación. Las estrategias de control consiguen reducir dichas variaciones en la medida que les es posible, siendo especialmente efectiva la estrategia Smoothing. Los valores máximo y mínimo iniciales se ven ligeramente atenuados tras la ejecución de las estrategias, siendo reseñable el caso 1B. Aunque la estrategia 2 no tenga explicitado ningún objetivo en relación a los picos, el propio alisado de la curva de demanda los termina recortando. La estrategia 1, por el contrario, debe su razón de ser a la limitación de máximos y mínimos, y habrá que evaluar si dichos valores se consideran aceptables. Observando la Fig. 38 se aprecian altas concentraciones de valores en los ±100 kW que establece el Peak Shaving como límite. Estas concentraciones quedan reflejadas en la Fig. 39. Si se presta atención a la líneas rojas, tan sólo un pequeño porcentaje de valores se sitúan por debajo de -100 kW siendo, como era de esperar, ligeramente menor para la línea de trazo discontinuo (1B), correspondiente al caso de mayor almacenamiento. Rafael Tallada Souto 75 La estrategia número 2 modifica la distribución de P cc de una forma mucho más sutil: concentra los valores más extremos en puntos más intermedios. Fig. 38. Fig. 38.Fig. 38. Fig. 38. Distribución de frecuencias de P Distribución de frecuencias de PDistribución de frecuencias de P Distribución de frecuencias de P cc cccc cc : DG eólica : DG eólica: DG eólica : DG eólica (kW) (kW)(kW) (kW) Fig. 39. Fig. 39.Fig. 39. Fig. 39. Distribución acumulada de P Distribución acumulada de PDistribución acumulada de P Distribución acumulada de P cc cccc cc : DG eólica : DG eólica: DG eólica : DG eólica (kW) (kW)(kW) (kW) Generación fotovoltaica Generación fotovoltaicaGeneración fotovoltaica Generación fotovoltaica Las conclusiones extraídas en el caso eólico son extrapolables al caso fotovoltaico, con la salvedad de que el recurso solar presenta un perfil más bajo y menos abrupto que el eólico (ver Fig. 14), tal y como se puede apreciar en los valores de media y mediana, y desviación estándar que aparecen en la Tabla 28. Se constata que los máximos los sigue marcando la demanda, posiblemente coincidiendo con periodos de nula generación solar. Se observa asimismo que, para la estrategia 1, ningún valor mínimo sobrepasa el límite P min ; ni siquiera el caso A, con menor almacenamiento. El caso 2B ω=8 vuelve a ser el que mejor minimiza la variabilidad de P cc . Variable VariableVariable Variable Media MediaMedia Media Mediana MedianaMediana Mediana DS (σ) DS (σ)DS (σ) DS (σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo P cc (inicial) 50.0 62.1 50.1 - 180.2 246.0 P cc 1A 50.0 62.4 48.7 - 100 .0 228.1 P cc 1B 50.0 62.4 48. 3 - 100 .0 228.1 P cc 2A ω=4 50.0 57.7 39.4 - 109.4 228.1 P cc 2B ω=4 50.0 57.7 39.2 - 101.4 207.9 P cc 2B ω=8 49.9 51.8 30.3 - 131.2 246.0 Tabla 28. Tabla 28.Tabla 28. Tabla 28. Parámetros ParámetrosParámetros Parámetros estadísticos estadísticos estadísticos estadísticos de las estrategias de P: DG de las estrategias de P: DG de las estrategias de P: DG de las estrategias de P: DG FV FVFV FV (kW) (kW)(kW) (kW) A continuación se presentan los histogramas correspondientes al caso fotovoltaico. Las diferencias entre la distribución frecuencial del caso fotovoltaico y el caso eólico son muy pequeñas; si acaso destacar el ligero desplazamiento hacia la derecha que se da como consecuencia de una menor potencia generada. 0 2 4 6 8 Frecuencia [%] 0 20 40 60 80 100 LD 1A 1B 2A 2B 2B' 3 Optimización mediante técnicas heurísticas 76 Fig. 40. Fig. 40.Fig. 40. Fig. 40. Distribución de frecuencias de P Distribución de frecuencias de PDistribución de frecuencias de P Distribución de frecuencias de P cc cccc cc : DG : DG : DG : DG fotovoltaica fotovoltaicafotovoltaica fotovoltaica (kW) (kW)(kW) (kW) Fig. 41. Fig. 41.Fig. 41. Fig. 41. Distribución acumulada de P Distribución acumulada de PDistribución acumulada de P Distribución acumulada de P cc cccc cc : DG fotovoltaica : DG fotovoltaica: DG fotovoltaica : DG fotovoltaica (kW) (kW)(kW) (kW) Generación eólica + fotovoltaica Generación eólica + fotovoltaicaGeneración eólica + fotovoltaica Generación eólica + fotovoltaica Para finalizar el estudio de P se realizan otras cinco simulaciones, esta vez considerando la integración conjunta de generación eólica y fotovoltaica. Los parámetros estadísticos obtenidos aparecen en la Tabla 29. Variable VariableVariable Variable Media MediaMedia Media Mediana MedianaMediana Mediana DS (σ) DS (σ)DS (σ) DS (σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo P cc (inicial) - 8.8 16.8 89.1 - 343.7 219.1 P cc 1A - 8.8 8.0 81.2 - 337.7 215.9 P cc 1B - 8.8 7.7 79.5 - 337.7 215.9 P cc 2A ω=4 - 8.8 9.8 77.7 - 338.8 201.0 P cc 2B ω=4 - 8.8 9.4 75.4 - 289.7 172.8 P cc 2B ω=8 - 8.8 9.8 74.1 - 343.7 199.5 Tabla 29. Tabla 29.Tabla 29. Tabla 29. Pará ParáPará Parámetros estadísticos metros estadísticos metros estadísticos metros estadísticos de las estrategias de P: DG eólica + de las estrategias de P: DG eólica + de las estrategias de P: DG eólica + de las estrategias de P: DG eólica + FV FVFV FV (kW) (kW)(kW) (kW) El promedio de P cc presenta valores negativos, es decir, se ha producido una cesión neta de energía de la microrred a la red; cesión de carácter intermitente si se presta atención al valor de la mediana. El motivo por el que el promedio es negativo se debe sobre todo a momentos puntuales de intensa generación, ya que el grueso de los valores, cuya mitad marca la mediana, se encuentra algo alejado del promedio. Paradójicamente, el Peak Shaving (1) registra “peores” valores mínimos que el Smoothing (2). La razón es simple: si el pico que sobrepasa los límites de ±100 kW se mantiene en el tiempo, llega un momento en que las baterías se quedan sin energía que ceder o absorber. El Smoothing, por el contrario, es menos exigente con la potencia instantánea que debe suministrar el almacenamiento y lo dosifica mejor. La distribución de frecuencias de P de la Fig. 42 conserva el patrón de los casos anteriores, si bien exhibe una mayor acumulación en la zona negativa. El pico que 0 2 4 6 8 Frecuencia [%] 0 20 40 60 80 100 LD 1A 1B 2A 2B 2B' Rafael Tallada Souto 77 presenta la estrategia 1 (líneas rojas) en -100 kW presenta una enorme concentración de valores, mientras que su versión positiva registra un notable descenso. El correcto funcionamiento de las estrategias se verifica en el histograma de frecuencia relativa acumulada de la Fig. 43. Las líneas rojas contienen muy pocos valores fuera del rango de ±100 kW, siendo el caso B el que mejores resultados obtiene. La estrategia 2 vuelve a modificar la distribución original (línea negra) en todo el rango de potencias. Si se analizan los resultados desde el punto de vista del SAE (caso A vs. caso B) sólo se aprecian diferencias sustanciales en la estrategia Peak Shaving (1). En la estrategia Smoothing (2) el dimensionamiento de las baterías ejerce menor influencia en el resultado, siendo más determinante el ancho de ventana de la media móvil ω. Fig. 42. Fig. 42.Fig. 42. Fig. 42. Distribución de frecuencias de P Distribución de frecuencias de PDistribución de frecuencias de P Distribución de frecuencias de P cc cccc cc : DG eólica : DG eólica : DG eólica : DG eólica + fotovoltaica + fotovoltaica+ fotovoltaica + fotovoltaica (kW) (kW)(kW) (kW) Fig. 43. Fig. 43.Fig. 43. Fig. 43. Distribución acumulada de P Distribución acumulada de PDistribución acumulada de P Distribución acumulada de P cc cccc cc : DG eólica + : DG eólica + : DG eólica + : DG eólica + fotovoltaica fotovoltaicafotovoltaica fotovoltaica (kW) (kW)(kW) (kW) Resumen del recorte de picos Resumen del recorte de picosResumen del recorte de picos Resumen del recorte de picos La Tabla 30 presenta el cómputo anual de los picos registrados en la curva de P cc cuando se ejecuta la estrategia Peak Shaving, para cada una de las situaciones de DG. Un periodo en el que, de media, la microrred ha absorbido más de 100 kW de la red se considera pico de demanda, y un periodo en el que la microrred ha cedido más de 100 kW a la red se considera pico de generación (-100 kW). Conforme la penetración de la DG aumenta, los picos de generación suceden más frecuentemente, en detrimento de los de demanda. En los casos de DG eólica/DG fotovoltaica la efectividad en la supresión de picos ronda el 90%, es decir, las baterías han sido capaces de equilibrar el balance con la red según lo estipulado para nueve de cada diez picos. Cuando se suman ambas DG, el valor baja hasta un 68% de reducción, para un SAE de 100kW/1MWh (caso A); y hasta un 82% para el caso de 200kW/2MWh (caso B). 0 2 4 6 8 Frecuencia [%] 0 20 40 60 80 100 LD 1A 1B 2A 2B 2B' 3 Optimización mediante técnicas heurísticas 78 Caso CasoCaso Caso Picos de Picos de Picos de Picos de demanda demandademanda demanda Picos de Picos de Picos de Picos de generación generacióngeneración generación Total TotalTotal Total Reducción % Reducción %Reducción % Reducción % DG eólica DG eólicaDG eólica DG eólica Inicial 1796 1660 3456 - 1A 125 403 528 84.72 1B 51 182 233 93.2 6 DG fotovoltaica DG fotovoltaicaDG fotovoltaica DG fotovoltaica Inicial 1476 293 1769 - 1A 125 0 125 92.93 1B 105 0 105 94.06 DG eólica + fotovoltaica DG eólica + fotovoltaicaDG eólica + fotovoltaica DG eólica + fotovoltaica Inicial 752 3228 3980 - 1A 57 1213 1270 68.09 1B 30 696 726 81.7 6 Tabla 30. Tabla 30.Tabla 30. Tabla 30. Reducción de picos Reducción de picosReducción de picos Reducción de picos con con con con Peak Shaving Peak ShavingPeak Shaving Peak Shaving: m : m: m : microrred con DG icrorred con DGicrorred con DG icrorred con DG (kW) (kW)(kW) (kW) 3.5.2.2 3.5.2.23.5.2.2 3.5.2.2 Control de Q Control de QControl de Q Control de Q Con la inclusión de la DG entra en juego el control de Q. La Tabla 32 recopila los parámetros estadísticos de los valores de f.d.p vistos desde el lado de red para los casos de un único tipo de DG, mientras que la Tabla 32 los recopila para el caso agregado. Variable VariableVariable Variable Media MediaMedia Media Mediana MedianaMediana Mediana DS (σ) DS (σ)DS (σ) DS (σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo Cos( φ ) load 0.79 0.7 9 0.0 7 0 1 DG eólica DG eólicaDG eólica DG eólica Cos( φ ) 1A 0.92 1 0.11 0 1 Cos( φ ) 1B 0.92 1 0.12 0 1 Cos( φ ) 2A w=4 0.92 1 0.13 0.01 1 Cos( φ ) 2B ω=4 0.92 1 0.13 0.01 1 Cos( φ ) 2B ω=8 0.91 1 0.16 0 1 DG DG DG DG fotovoltaica fotovoltaicafotovoltaica fotovoltaica Cos( φ ) 1A 0.9 0 0.9 0 0.11 0 1 Cos( φ ) 1B 0.90 0.90 0.11 0 1 Cos( φ ) 2A ω=4 0.87 0.89 0.16 0 1 Cos( φ ) 2B ω=4 0.87 0.89 0.16 0 1 Cos( φ ) 2B ω=8 0.83 0.88 0.2 0 1 Tabla 31. Tabla 31.Tabla 31. Tabla 31. Parámetros estadísticos del control de Q (f.d.p.): Eólica / Parámetros estadísticos del control de Q (f.d.p.): Eólica / Parámetros estadísticos del control de Q (f.d.p.): Eólica / Parámetros estadísticos del control de Q (f.d.p.): Eólica / FV FVFV FV Rafael Tallada Souto 79 Variable VariableVariable Variable Media MediaMedia Media Mediana MedianaMediana Mediana DS (σ) DS (σ)DS (σ) DS (σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo DG eólica + fotovoltaica DG eólica + fotovoltaicaDG eólica + fotovoltaica DG eólica + fotovoltaica Cos( φ ) 1A 0.96 1 0.1 0 1 Cos( φ ) 1B 0.96 1 0.09 0 1 Cos( φ ) 2A ω=4 0.94 1 0.14 0 1 Cos( φ ) 2B ω=4 0.94 1 0.14 0 1 Cos( φ ) 2B ω=8 0.92 1 0.19 0 1 Tabla 32. Tabla 32.Tabla 32. Tabla 32. Parámetros estadísticos del control de Q (f.d.p): Eólica + Parámetros estadísticos del control de Q (f.d.p): Eólica + Parámetros estadísticos del control de Q (f.d.p): Eólica + Parámetros estadísticos del control de Q (f.d.p): Eólica + FV FVFV FV El f.d.p se ha calculado mediante la ecuación (18 ) . Esto quiere decir que para un mismo flujo de potencia reactiva en PCC, el Cos(φ) variará según lo haga el flujo de potencia activa. Debido a este hecho se registran variaciones entre la estrategia 1 y 2, pese a que ambas implementan el mismo control de Q. De entre las tres situaciones de DG simuladas, la que mejores resultados proporciona es la que incluye recurso eólico y fotovoltaico, lo que no es de extrañar teniendo en cuenta que a más recurso disponible, mayor capacidad para aportar Q al sistema. Independientemente de la estrategia de P escogida, el control de Q mejora notable el f.d.p original en todas las situaciones estudiadas. El Cos(φ) promedio para las dos situaciones con penetración eólica es muy superior al 0.79 que presenta originalmente la demanda. En ambos situaciones la mediana se sitúa en 1, lo que significa que en al menos el 50% de las ocasiones el valor del f.d.p registrado ha sido igual a la unidad. Las siguientes tres figuras muestran la distribución acumulada del factor de potencia visto desde el lado de red. El f.d.p inicial (línea negra) registra casi un 40% de valores por debajo del 0.75, dato que mejora sustancialmente tras la adición del control de Q. Fig. 44. Fig. 44.Fig. 44. Fig. 44. Distribución acumulada del f.d.p: DG eólica Distribución acumulada del f.d.p: DG eólicaDistribución acumulada del f.d.p: DG eólica Distribución acumulada del f.d.p: DG eólica Fig. 45. Fig. 45.Fig. 45. Fig. 45. Distribución acumulada del f.d.p: DG Distribución acumulada del f.d.p: DG Distribución acumulada del f.d.p: DG Distribución acumulada del f.d.p: DG fotovoltaica fotovoltaicafotovoltaica fotovoltaica 0 20 40 60 80 100 0 0.25 0.5 0.75 1 Frecuencia [%] 0 20 40 60 80 100 0 0.25 0.5 0.75 1 LD 1A 1B 2A 2B 3 Optimización mediante técnicas heurísticas 80 Fig. 46. Fig. 46.Fig. 46. Fig. 46. Distribución acumulada del Distribución acumulada delDistribución acumulada del Distribución acumulada del f.d.p: DG eólica + fotovoltaica f.d.p: DG eólica + fotovoltaicaf.d.p: DG eólica + fotovoltaica f.d.p: DG eólica + fotovoltaica En la Fig. 44 se observa que en más del 60% de las ocasiones se ha registrado un Cos(φ) igual a la unidad. La Fig. 45 (recurso solar) también mejora notablemente el f.d.p. inicial, aunque en menor medida debido a las razones anteriormente mencionadas. Tal y como se preveía, los mejores resultados se obtienen en la microrred con más potencia renovable instalada (Fig. 46), donde en el 80% de los casos se registra un f.d.p. igual a uno. 3.5.2.3 3.5.2.33.5.2.3 3.5.2.3 Actuación de las ba Actuación de las baActuación de las ba Actuación de las baterías teríasterías terías Se pasa ahora a evaluar el impacto que la generación distribuida y las estrategias de control tienen sobre el estado de carga de las baterías. Para ello se ha recopilado en la Tabla 33 los principales parámetros estadísticos obtenidos a partir de los datos de SOC, agrupados según la DG considerada en cada situación. La microrred con mayor penetración de energías renovables hace un uso más intensivo de las baterías. Con la excepción de los casos 2B ω=4 de eólica y de fotovoltaica, el SOC recorre todo el rango de valores que puede tomar (del 5 a 100%). Se puede observar que la desviación estándar (σ) del caso que contempla DG combinada es notablemente superior al resto de situaciones, es decir, permanece menos tiempo estático o varía de forma más abrupta. En lo que respecta a las estrategias de P, el caso 2B ω=8 vuelve a ser el de mayor exigencia, destacando una σ de 36.7 kW para el caso eólico. 0 20 40 60 80 100 0 0.25 0.5 0.75 1 Frecuencia [%] LD 1A 1B 2A 2B 2B' Rafael Tallada Souto 81 Variable VariableVariable Variable Medi MediMedi Medi a aa a Mediana MedianaMediana Mediana DS (σ) DS (σ)DS (σ) DS (σ) Mínimo MínimoMínimo Mínimo Máximo MáximoMáximo Máximo DG eólica DG eólicaDG eólica DG eólica SOC 1A 45.9 43.7 13.7 5 100 SOC 1B 45.7 44.0 11.2 5 100 SOC 2A ω=4 38.5 34.2 21.8 5 100 SOC 2B ω=4 45.9 42.8 10.2 18.0 77.7 SOC 2B ω=8 44.7 39.6 36.7 5 100 DG fotovoltaica DG fotovoltaicaDG fotovoltaica DG fotovoltaica SOC 1A 43.2 42.2 6.0 5 62.8 SOC 1B 43.5 43.5 5.5 5 55.7 SOC 2A ω=4 48.7 47.1 13.8 5 100 SOC 2B ω=4 51.8 50.6 6.2 26.9 74.9 SOC 2B ω=8 44.0 42.1 19.3 5 100 DG eólica + fotovoltaica DG eólica + fotovoltaicaDG eólica + fotovoltaica DG eólica + fotovoltaica SOC 1A 45.70 38.81 19.68 5 100 SOC 1B 44.90 38.78 18.22 5 100 SOC 2A ω=4 47.6 47.9 28.9 5 100 SOC 2B ω=4 51.0 49.2 30.1 5 100 SOC 2B ω=8 44.1 40.9 25.3 5 100 Tabla 33. Tabla 33.Tabla 33. Tabla 33. Parámetros estadísticos del Parámetros estadísticos delParámetros estadísticos del Parámetros estadísticos del SOC SOCSOC SOC (%) (%)(%) (%) de las baterías de las bateríasde las baterías de las baterías: microrred : microrred: microrred : microrred con DG con DGcon DG con DG Las tres figuras de la siguiente página ilustran la distribución de valores de SOC, agrupados nuevamente según la DG considerada. La distribución de la estrategia Peak Shaving (línea roja) exhibe una elevada concentración de datos en torno al intervalo marcado por las rutinas automáticas de carga de la Tabla 9. En los casos de un único recurso renovable se sitúa alrededor del 45% de SOC, mientras que para el caso de mayor penetración de DG el valor baja un 10% aproximadamente. En lo que respecta al Smoothing (líneas verdes y morada) el perfil de la distribución obedece a una combinación de dos factores: el ancho de ventana de la media móvil, ω; y las propias dimensiones del SAE. El caso 2B sigue infrautilizando las baterías, puesto que dispone de demasiada capacidad y potencia para las consignas que obtiene cada vez que calcula la media móvil de los últimos cuatro valores de P cc (ω=4). 3 Optimización mediante técnicas heurísticas 82 Fig. 47. Fig. 47.Fig. 47. Fig. 47. Distribución acumulada del Distribución acumulada del Distribución acumulada del Distribución acumulada del SOC SOCSOC SOC (%) (%)(%) (%): DG : DG : DG : DG eólica eólicaeólica eólica Fig. 48. Fig. 48.Fig. 48. Fig. 48. Distribución acumulada del Distribución acumulada del Distribución acumulada del Distribución acumulada del SOC SOCSOC SOC (%) (%)(%) (%): DG : DG : DG : DG fotovoltaica fotovoltaicafotovoltaica fotovoltaica Fig. 49. Fig. 49.Fig. 49. Fig. 49. Distribución acumulada del Distribución acumulada del Distribución acumulada del Distribución acumulada del SOC SOCSOC SOC (%) (%)(%) (%): DG eólica + : DG eólica + : DG eólica + : DG eólica + fotovoltaica fotovoltaicafotovoltaica fotovoltaica Llegados a este punto, puede resultar interesante aglutinar en una misma gráfica las diferentes combinaciones de DG y de almacenamiento, para cada una de las estrategias. La Fig. 50 aglutina todas estas combinaciones para la estrategia 1 (Peak Shaving). En ella se distinguen muy claramente los diferentes intervalos de SOC deseado de las rutinas automáticas recogidas en la Tabla 9: 90-100% en ausencia de DG, 40-50% en caso de que la microrred cuente con un único recurso renovable y 30-40% cuando se consideren ambos recursos. Las diferencias entre el caso A y el B son muy pequeñas. 0 20 40 60 80 100 0 25 50 75 100 Frecuencia [%] 0 20 40 60 80 100 0 25 50 75 100 1A 1B 2A 2B 2B' 0 20 40 60 80 100 0 25 50 75 100 Frecuencia [%] 1A 1B 2A 2B 2B' Rafael Tallada Souto 83 Fig. 50. Fig. 50.Fig. 50. Fig. 50. Distribución acumulada del Distribución acumulada del Distribución acumulada del Distribución acumulada del SOC SOCSOC SOC (%): (%): (%): (%): Peak Shaving Peak ShavingPeak Shaving Peak Shaving La Fig. 51 hace lo propio para la estrategia de alisado por media móvil o Smoothing. La penetración de la DG vuelve a ser clave: de las tres líneas negras correspondientes a una microrred sin DG, en dos de ellas ni siquiera se recorren todos los valores posibles de SOC, mientras que para el caso de más DG (líneas rojas) la distribución se equilibra hasta asemejarse a una diagonal que barre todo el rango de la variable. Se concluye que a más generación, mejor aprovechamiento hace la estrategia Smoothing del SAE y, para un mismo nivel de generación, el factor ω juega un papel decisivo. Fig. 51. Fig. 51.Fig. 51. Fig. 51. Distribución acumulada del SOC (%): Smoothing Distribución acumulada del SOC (%): SmoothingDistribución acumulada del SOC (%): Smoothing Distribución acumulada del SOC (%): Smoothing 0 20 40 60 80 100 0 25 50 75 100 Frecuencia [%] A no DG B no DG A wind B wind A PV B PV A wind+PV B wind+PV 0 20 40 60 80 100 0 25 50 75 100 Frecuencia [%] A no DG B no DG B' no DG A wind B wind B' wind A PV B PV B' PV A wind+PV B wind +PV B' wind+PV 4 Optimización clásica 90 4.1.1 4.1.14.1.1 4.1.1 Reguladores Inteligentes Reguladores InteligentesReguladores Inteligentes Reguladores Inteligentes En el nivel más bajo de la estructura organizacional del control se encuentran los Reguladores, encargados del control distribuido de la potencia activa y reactiva que cada elemento generador intercambia con la microrred. La técnica elegida ha sido la p-q droop, válida tanto para redes conectadas como para redes aisladas. El parámetro que define el control de potencia activa es la recta que relaciona potencia y frecuencia, también denominada recta estática potencia-frecuencia, que se corresponde con la gráfica izquierda de la Fig. 55. Esta curva establece la variación de frecuencia del convertidor, en fuente de tensión (Voltage Source Converter, VSC), para una variación de potencia activa dada. Fig. 55. Fig. 55.Fig. 55. Fig. 55. Droops de frecuencia y voltaje Droops de frecuencia y voltaje Droops de frecuencia y voltaje Droops de frecuencia y voltaje [25] [25][25] [25] El Regulador va a controlar la potencia de salida del VSC mediante pequeñas variaciones de frecuencia. Estas pequeñas variaciones de frecuencia, de carácter transitorio, modifican el desfase entre la tensión entregada y la tensión de red. Según exista un desfase u otro, el flujo de potencia activa de la red al generador cambiará, pudiéndose ajustar al deseado. El esquema de conexión de la Fig. 56 ilustra la topología de la conexión. El Regulador controla P∠R S , tanto en magnitud como en fase, por lo que es capaz de modificar el desfase entre P∠R S y ;∠R T para regular el flujo de potencia activa entre el generador o batería y el bus AC de la microrred. Fig. 56. Fig. 56.Fig. 56. Fig. 56. Esquema de conexión a la microrred Esquema de conexión a la microrredEsquema de conexión a la microrred Esquema de conexión a la microrred Rafael Tallada Souto 91 La potencia activa cedida por el Regulador se puede obtener mediante la ecuación (19 ) .  = P; 9U sin  R S − R   (19) La potencia reactiva exhibe un comportamiento íntimamente ligado a la diferencia de potencial existente entre la salida del convertidor y la microrred. Para su control, el Regulador modificará ligeramente la amplitud del voltaje en bornes de los VSC, pero manteniéndola siempre dentro del margen de seguridad establecido. La ecuación (20 ) rige la inyección de Q en dicha configuración:  = P  9U − P; 9U cos  R S − R   (20) La Tabla 34 presenta las cuatro formas en las que puede fluir la potencia, en función de cuál sea la relación entre las fases y magnitudes de V y E. Relaciones de Relaciones de Relaciones de Relaciones de W # y y y y X Flujo de potencia Flujo de potenciaFlujo de potencia Flujo de potencia VSC AC BUS R S > R  P R S < R  P P > ; Q P < ; Q Tabla 34. Tabla 34.Tabla 34. Tabla 34. Principios de funcionamiento: VSC conectado a red Principios de funcionamiento: VSC conectado a redPrincipios de funcionamiento: VSC conectado a red Principios de funcionamiento: VSC conectado a red 4.1.2 4.1.24.1.2 4.1.2 Agente Optimizador Agente OptimizadorAgente Optimizador Agente Optimizador Un nivel jerárquico por encima de los Reguladores se encuentra el agente Optimizador, máxima autoridad dentro de la microrred. El Optimizador ejecuta de forma periódica un algoritmo que tiene por objeto lograr que el coste del balance energético en la microrred sea óptimo. También se encarga de hacer llegar las consignas optimizadas de potencia activa y reactiva a los Reguladores. Con el algoritmo utilizado, el Optimizador realiza dicha optimización de la gestión de la demanda para los siguientes n periodos (cuatro en este caso). Para ello se vale de un bloque previsor de demanda, que toma como referencia los n periodos inmediatamente anteriores. El algoritmo no está sujeto a restricciones de tiempo, ya que se ejecuta con periodicidades lo suficientemente grandes. 4.1.2.1 4.1.2.14.1.2.1 4.1.2.1 Bloque de previsión de demanda Bloque de previsión de demandaBloque de previsión de demanda Bloque de previsión de demanda La demanda futura de energía por parte del consumidor es un dato que a priori escapa al control de la empresa suministradora. Una previsión de la demanda es de vital importancia para gestionar adecuadamente los sistemas de almacenamiento de la microrred. En el caso de estudio, se ha elegido hacer la previsión a cuatro periodos vista. 4 Optimización clásica 92 Teniendo en cuenta que un día tiene 24 horas, quedará dividido en periodos de 6 horas con una demanda diferente en cada uno de ellos. Para el cálculo de la estimación se ha optado por un enfoque “naïf” frente a otros mecanismos como las medias móviles ponderadas. El enfoque naïf considera que el valor de la demanda durante un determinado periodo del día objeto de la previsión será la misma que la demanda que hay durante ese mismo periodo, en el día actual. Por ejemplo, si hoy durante la noche se ha medido que el consumo ha tenido lugar a un ratio de 4 kW de media, se espera que mañana por la noche el consumo sea el mismo. Se podría haber considerado también la estacionalidad en la demanda que suponen los distintos días de la semana (el consumo de un domingo será distinto al de un día laborable), o incluso haber incluido otros factores correctores. Por citar alguno, si se sabe que va a haber una bajada de temperaturas al día siguiente se puede esperar un mayor consumo debido a los sistemas de calefacción. Por motivos de simplicidad y claridad, se ha decidido mantener el enfoque original. 4.1.3 4.1.34.1.3 4.1.3 Otros elementos de la microrred Otros elementos de la microrredOtros elementos de la microrred Otros elementos de la microrred La caracterización del modelo a estudiar se completa con la descripción del resto de componentes que la forman: generadores, sistemas de almacenamiento, cargas, líneas de transmisión y la propia red eléctrica a la que se conecta la microrred. 4.1.3.1 4.1.3.14.1.3.1 4.1.3.1 Generador eólico (recurso renovable) Generador eólico (recurso renovable) Generador eólico (recurso renovable) Generador eólico (recurso renovable) El aerogenerador tiene su rango de funcionamiento limitado a la generación y no se le permite que pase a trabajar como carga. Su potencia aparente nominal es de 4 kVA. Este valor se corresponde a la limitación física del convertidor VSC que tiene asociado. Además de esta restricción, la potencia que es capaz de entregar en cada periodo se ve condicionada por la disponibilidad del recurso natural. Este valor de potencia disponible no es controlable en forma alguna y tampoco se realimenta al Optimizador. 4.1.3.2 4.1.3.24.1.3.2 4.1.3.2 Grupo electrógeno diésel (recurso no r Grupo electrógeno diésel (recurso no rGrupo electrógeno diésel (recurso no r Grupo electrógeno diésel (recurso no renovable) enovable)enovable) enovable) El generador basado en energía no renovable se modela y comporta de la misma forma que el aerogenerador, con la salvedad de que, en este caso, no existe la limitación de recurso. 4.1.3.3 4.1.3.34.1.3.3 4.1.3.3 Sistemas de almacenamiento Sistemas de almacenamientoSistemas de almacenamiento Sistemas de almacenamiento La microrred cuenta con dos baterías, de idénticas características. A diferencia de los elementos generadores, que sólo pueden ceder energía al sistema, el flujo de potencia de las baterías puede ser bidireccional. Según las consignas que reciban, se cargarán o descargarán atendiendo a las necesidades energéticas de la microrred durante el periodo en curso. En este escenario de simulación se ha considerado un rendimiento durante la carga y descarga del 90%, una capacidad de 1 kWh, que el convertidor asociado soporta una potencia aparente máxima de 500 VA, y que ambas baterías comienzan con un estado de carga del 50% (SOC = 500 Wh). Todos estos parámetros se recogen en la Tabla 35. Rafael Tallada Souto 93 Parámetro ParámetroParámetro Parámetro Valor ValorValor Valor Unidad UnidadUnidad Unidad es eses es Capacidad 1 kWh S max del convertidor 500 VA Eficiencia 90 % SOC inicial 50 % Tabla 35. Tabla 35.Tabla 35. Tabla 35. Parámetros de las baterías Parámetros de las bateríasParámetros de las baterías Parámetros de las baterías 4.1.3.4 4.1.3.44.1.3.4 4.1.3.4 Cargas CargasCargas Cargas El modelo cuenta con tres cargas consumidoras de potencia. En este escenario de simulación se ha preferido que todas sean de carácter no controlado. La conexión y desconexión de una carga no controlada es totalmente independiente de cualquier decisión del sistema. • Carga óhmica no controlada de 20 Ω, permanentemente conectada a la red eléctrica. • Carga óhmica no controlada que se conecta de forma directa y brusca al sistema. Para un mayor realismo y aleatoriedad, se hace variar su valor en cada periodo entre 15, 20, 25 Ω, o la desconexión. • Carga inductiva no controlada de L = 84 mH. 4.1.3.5 4.1.3.54.1.3.5 4.1.3.5 Línea de transmisión Línea de transmisiónLínea de transmisión Línea de transmisión Los generadores y las baterías se conectan a las cargas y la red a través de un cable de 400 m, modelado por una impedancia óhmico-inductiva de valores R = 0.7 Ω/km y L = 0.8 H/km. 4.1.3.6 4.1.3.64.1.3.6 4.1.3.6 Red Red Red Red Las redes a las que se pueden conectar los Reguladores son redes de corriente alterna convencionales, con la topología típica de estos sistemas. Los VSC se conectan como una carga más de la red de baja tensión. Una red se puede caracterizar según el valor de su potencia de cortocircuito: • Red fuerte: poseen una potencia de cortocircuito alta, y por consiguiente, no presentan problemas de estabilidad. • Red débil: debido a su baja potencia de cortocircuito, son susceptibles de derivas en alguna de sus variables (amplitud, frecuencia o fase), y de problemas de estabilidad en transitorios bruscos, provocados por conexiones repentinas en las cargas. Todos los escenarios de simulación han sido realizados para una red débil, puesto que si el sistema funciona bajo este supuesto no tendrá problema alguno funcionando con una red fuerte. • Red aislada, o en isla: son un caso extremo de red débil. El principal problema de este tipo de red es que siempre deben mantener, en tiempo real, el balance energético entre generación y demanda, puesto que no hay posibilidad de intercambio con otra red. Se verificará también el comportamiento de la microrred en esta situación. 4 Optimización clásica 94 4.2 4.24.2 4.2 Algoritmo de optimización para la gestión de la energía Algoritmo de optimización para la gestión de la energíaAlgoritmo de optimización para la gestión de la energía Algoritmo de optimización para la gestión de la energía El algoritmo propuesto minimiza la función del coste de la energía en la microrred. En dicha función de coste se suma el coste de los generadores y el coste que supone el sistema de almacenamiento. Para los generadores se tiene en cuenta un precio de la energía (activa y reactiva) por periodo y generador, mientras que para las baterías se ha optado por un coste de funcionamiento, con lo que intentará minimizar los ciclos de carga y descarga.En otras implementaciones se podría considerar que las baterías fueran agentes independientes en el mercado, y vendieran o compraran energía buscando maximizar su beneficio (comprar energía barata para venderla más cara). Respecto a las restricciones, se ha considerado el balance de potencias en la red en cada periodo, el balance energético en cada batería y en cada periodo, y las restricciones técnicas de generadores y baterías. Los datos de entrada del algoritmo de optimización se muestran en la Tabla 36: Variable VariableVariable Variable Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades T P eriodos del problema : /per - 1, per - 2, per - 3 , per - 4 / - G G eneradores considerados : /gen - 1, gen - 2, red/ - B B aterías consideradas /bat - 1, bat - 2/ - dt i D uración de cada periodo h cvpg j,i C oste de la energía activa de cada generador, por periodo €/kWh cvqg j,i C oste de la energía reactiva de cada generador, por periodo €/kVAr h Sgmax j, E stimación de potencia aparente máxima disponible de cada generador, por periodo VA rend k R endimiento de las baterías º/1 Sbmax k P otencia aparente máxima de cada batería VA cvpb k,i C oste variable de la energía activa de cada batería, por periodo €/kWh cvqb k,i C oste variable de la energía reactiva de cada batería, por periodo €/kVAr h demq m,i P revisión del promedio de demanda de potencia reactiva, por periodo VAr demp m,i P revisión del promedio de demanda de potencia activa, por periodo W Tabla 36. Tabla 36.Tabla 36. Tabla 36. Datos de Datos de Datos de Datos de entrada del algoritmo de optimización entrada del algoritmo de optimizaciónentrada del algoritmo de optimización entrada del algoritmo de optimización Rafael Tallada Souto 95 Las variables a optimizar se recogen en la Tabla 37: Variable VariableVariable Variable Descripción DescripciónDescripción Descripción Unidades UnidadesUnidades Unidades pg j,i C onsigna de potencia activa para cada generador, por periodo W qg j,i C onsigna de potencia reactiva para cada generador, por periodo VAR pbc k,i P otencia activa de carga para cada batería, por periodo W pbd k,i P otencia activa de descarga para cada batería, por periodo W qbc k,i P otencia reactiva de carga para el convertidor de cada batería, por periodo VAr qbd k,i P otencia reactiva de descarga para el convertidor de cada batería, por periodo VAr SOC k,i C arga de cada batería, al final de cada periodo Wh Tabla 37. Tabla 37.Tabla 37. Tabla 37. Variables a optimizar Variables a optimizarVariables a optimizar Variables a optimizar Para obtener las consignas de P y Q de las baterías, el Optimizador substrae la potencia de carga de la respectiva potencia de descarga. Se mantiene así el convenio de signos utilizado en los generadores, en las que un valor positivo indica ceder potencia a la microrred. El SOC final es utilizado como SOC inicial para la iteración posterior. La ecuación a minimizar es la del coste total de la microrred (21 ) . • Minimizar: GH[\ = $ $ A , ] ^ , % · `, ] ^ , % + a ] ^ , % · `a ] ^ , % B %∈c^∈d · F [ % # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # + $ $ e `,f · A ,f  g , % + ,f F g , % B + `af · A af  g , % + af F g , % B h % ∈ c g ∈ i · F [ % (21) El problema está sujeto a las restricciones que vienen a continuación: • Balance de potencias en la red, en cada periodo i: $ , ] ^ , % + $ A − ,f  g , % + ,f F g , % · j\ F g B ≥ $ F\k ,  , %  ∈ l g ∈ i ^ ∈ d (22) $ a ] ^ , % + $ A − af  g , % + af F g , % B ≥ $ F\k a  , %  ∈ l g ∈ i ^ ∈ d (23) • Balance energético en cada batería k y en cada periodo i:   g , % =   g , % O ' + A ,f  g , % · j\ F g − ,f F g , % B · F [ % (24) 4 Optimización clásica 96 • Restricciones técnicas en los generadores, para cada generador j y periodo i: @ A , ] ^ , % B  + A a ] ^ , % B  ≤ H]k  ^ , % (25) • Restricciones técnicas en las baterías, para cada batería k y periodo i: @ A ,f  g , % B  + A af  g , % B  ≤ Hfk  g (26) @ A ,f F g , % B  + A af F g , % B  ≤ Hfk  g (27)   g , % ≤ k  g (28) ,f F g , % ≤   g , % O ' F [ % # (29) 4.3 4.34.3 4.3 Implementación informática Implementación informáticaImplementación informática Implementación informática En este apartado se pretenden explicar las cuestiones de carácter práctico acerca de la simulación de la microrred y del funcionamiento del algoritmo de optimización. Se divide en dos partes, en la primera se describirá el software utilizado, mientras que en la segunda abordará el esquema conceptual de la implementación informática. 4.3.1 4.3.14.3.1 4.3.1 Software utilizado Software utilizadoSoftware utilizado Software utilizado La simulación de la microrred no se llevado a cabo utilizando un único software. Para implementar todas las funcionalidades requeridas han hecho falta cuatro programas distintos: JADE, Simulink, MACSimJX y AMPL. El framework JADE ya ha sido abordado en la apartado 2.4, por lo que sólo se explicarán los tres programas restantes. 4.3.1.1 4.3.1.14.3.1.1 4.3.1.1 MATLAB MATLABMATLAB MATLAB- -- -Simulink SimulinkSimulink Simulink Este programa permite modelar sistemas de cierta complejidad a un alto nivel de abstracción gracias a su entorno de programación gráfico. Pese a que existen alternativas de libre distribución, Simulink presenta varias ventajas: 1) Elevado grado de implantación, tanto en el ámbito académico como en el empresarial. 2) Disponibilidad de múltiples librerías de bloques y modelos listos para ser utilizados. En concreto, la librería SimPowerSystem contiene una amplia variedad de elementos eléctricos, que van desde sencillos componentes pasivos hasta elaborados generadores síncronos, pasando por toda suerte de dispositivos electrónicos de potencia. 3) La versatilidad que supone poder mezclar código con programación gráfica. En la simulación de la microrred, se ha explotado dicha ventaja para modelar los Reguladores, el bloque de previsión de demanda, la emulación de conexión Rafael Tallada Souto 97 aleatoria de cargas y el elemento auxiliar que dicta la duración de los periodos de la simulación. 4) La existencia de una herramienta que permitiera el intercambio de datos entre Simulink y la plataforma multiagente en la que iba a actuar el Optimizador: el middleware MACSimJX. Fig. 57. Fig. 57.Fig. 57. Fig. 57. Panorámica del modelo Simulink utilizado Panorámica del modelo Simulink utilizadoPanorámica del modelo Simulink utilizado Panorámica del modelo Simulink utilizado 4.3.1.2 4.3.1.24.3.1.2 4.3.1.2 MACSimJX MACSimJXMACSimJX MACSimJX Aunque Simulink es muy efectivo a la hora de llevar a cabo simulaciones, no ofrece las herramientas necesarias para implementar en él una plataforma multiagente. Sin embargo, las denominas S-functions de las que dispone, permiten encapsular programas escritos en otros lenguajes de programación y hacer que funcionen dentro del propio entorno Simulink [26]. MACSimJX se vale de una S-function para crear una canal de comunicación de datos entre Simulink y un programa externo que posea la capacidad de procesamiento en paralelo que caracteriza a un sistema multiagente, en este caso JADE. MACSimJX presenta una arquitectura cliente-servidor. Como puede observarse en la Fig. 58, la parte del cliente es embebida en Simulink a través de la S-function y la parte del código del servidor es incorporado en un programa separado. La comunicación entre cliente y servidor se lleva a cabo a través de las llamadas named pipes de Windows [27]. 4 Optimización clásica 98 Fig. 58. Fig. 58.Fig. 58. Fig. 58. Estructura de MACsim Estructura de MACsimEstructura de MACsim Estructura de MACsim MACSimJX permite recibir datos a través de la interfaz (S-function) “MACSim” y pasarlos a los agentes que se le especifique para que estos puedan procesarlos. Una vez que dichos agentes han finalizado todas las operaciones con los datos, los resultados son devueltos a Simulink a través de los mismos canales. Los agentes suelen ser diseñados para desempeñar operaciones concretas con los datos de entrada, como por ejemplo realizar alguna optimización. Para llevar a cabo esta tarea, parece lógico dividir a los agentes en dos grupos: el Agent Environment (AE) y la Agent Task Force (ATF). El AE es responsable de la conexión entre Simulink y JADE y el usuario no ha de preocuparse de su funcionamiento interno. En la ATF se encuentran los agentes responsables de la manipulación de los datos, en el caso de estudio del presente trabajo la ATF está formada exclusivamente por el agente Optimizador. Los desarrolladores de MACSimJX recomiendan usar una plantilla con funciones y protocolos ya escritos para programar los agentes que formarán parte de la ATF. Estos protocolos aseguran la sincronización durante el proceso de intercambio de datos. Aparte de esto, su implementación es idéntica al de un agente cualquiera en JADE, con los comportamientos y objetivos que normalmente tendrían. La Fig. 59 muestra de forma intuitiva el funcionamiento de MACSimJX. Fig. 59. Fig. 59.Fig. 59. Fig. 59. Canales CanalesCanales Canales de comunicación de comunicación de comunicación de comunicación establecidos por establecidos porestablecidos por establecidos por MACSimJX MACSimJXMACSimJX MACSimJX [27] [27][27] [27] Rafael Tallada Souto 99 4.3.1.3 4.3.1.34.3.1.3 4.3.1.3 A Modeling Language for Mathematical Programming (AMPL) A Modeling Language for Mathematical Programming (AMPL)A Modeling Language for Mathematical Programming (AMPL) A Modeling Language for Mathematical Programming (AMPL) AMPL es un lenguaje de modelado algebraico para describir y resolver problemas de elevada complejidad matemática que cuenten con un gran número de variables y restricciones [28]. Fue desarrollado por Robert Fourer, David Gay y Brian Kernighan en los Laboratorios Bell. AMPL funciona con docenas de solvers, tanto de código abierto como comerciales: CBC, CPLEX, FortMP, Gurobi, MINOS, IPOPT, SNOPT y KNITRO por citar algunos. Los problemas de optimización son pasados a los solvers como archivos .nl. El uso de AMPL está ampliamente extendido entre agencias gubernamentales, instituciones académicas y empresas. La principal ventaja de AMPL radica en la similitud de su sintaxis con la de la notación matemática, lo que permite una definición concisa pero a la vez legible del problema. 4.3.2 4.3.24.3.2 4.3.2 Esquema conceptual del modelo de simulación Esquema conceptual del modelo de simulaciónEsquema conceptual del modelo de simulación Esquema conceptual del modelo de simulación Toda la microrred, a excepción del Optimizador, ha sido modelada en MATLAB-Simulink. Los Reguladores y el bloque de previsión de demanda han sido programados dentro de sus respectivas embedded MATLAB function. Todos los elementos circuitales (impedancias, fuentes de tensión, shunts de corriente, etc.) provienen de la librería SimPowerSystem. El Optimizador se ejecuta en el entorno JADE, e intercambia información en tiempo real con Simulink a través del middleware MACSimJX. La Fig. 60 muestra una captura de pantalla de la GUI RMA del SMA implementado para la ocasión. Fig. 60. Fig. 60.Fig. 60. Fig. 60. SMA en el que se ejecuta el SMA en el que se ejecuta el SMA en el que se ejecuta el SMA en el que se ejecuta el agente agente agente agente Optimizador OptimizadorOptimizador Optimizador Para llevar a cabo la optimización del balance energético, es decir, para calcular las consignas de P y Q que enviará a los Reguladores, el Optimizador solicitará la asistencia del programa AMPL. 4 Optimización clásica 106 La Tabla 42 contiene las consignas de P cada elemento para el periodo 3. Los Reguladores tratarán de seguirlas en el nuevo régimen de carga. Consigna ConsignaConsigna Consigna per perper per- -- -3 33 3 Potencia reactiva [VAr] Potencia reactiva [VAr]Potencia reactiva [VAr] Potencia reactiva [VAr] Q(gen-1) 0 Q(gen-2) 0 Q(red) 0 Q(bat-1) 153.918 Q(bat-2) 312.842 Tabla 43. Tabla 43.Tabla 43. Tabla 43. Consignas de Q para el periodo 3 Consignas de Q para el periodo 3Consignas de Q para el periodo 3 Consignas de Q para el periodo 3 El consumo inicial del periodo 3 lo realiza una carga óhmica pura de 20 Ω. De forma repentina, se conecta una segunda carga, de idéntico valor en paralelo a la primera, dando lugar a la carga de 10 Ω: • Carga no controlada inicial: 20 Ω (2.6 kW) • Carga no controlada inicial: 10 Ω (5.2 kW) En la Fig. 64 se observa que el sistema se encuentra en el régimen permanente, con los cuatro elementos entregando la potencia que les solicita el Optimizador. En el punto temporal denominado como “conexión repentina” se conecta la segunda carga. Fig. 64. Fig. 64.Fig. 64. Fig. 64. Respuesta Respuesta Respuesta Respuesta a a a a cambio brusco en la carga duran cambio brusco en la carga durancambio brusco en la carga duran cambio brusco en la carga durante el periodo 3: P te el periodo 3: Pte el periodo 3: P te el periodo 3: P 0 500 1000 1500 2000 2500 3000 3500 4000 4500 Conexión repentina +40s Potencia [W] Gen. Eólica Gen. Diésel Baterías Rafael Tallada Souto 107 Durante este periodo, el grupo electrógeno diésel entrega 4kW, su máxima potencia. Es por ello que no puede superar este valor pese al cambio producido. Las dos baterías y el aerogenerador sí que verán variar su potencia entregada. Al producirse este escalón, los Reguladores actúan variando la frecuencia de los VSC hasta dejar el desfase de tensiones en el punto deseado. Al cabo de un tiempo, las potencias vuelven a ser las requeridas. Es importante prestar atención a dos hechos. El primero es que esta reacción sólo es posible si la microrred se encuentra conectada a red, ya que será la red la que asuma el incremento de consumo de las cargas. Los cuatro generadores no ven modificada, tras el periodo de transición que se muestra en la gráfica, la potencia que entregan. Tal y como está implementado el bloque de previsión, el Optimizador no modifica las consignas de forma instantánea, sino que considera razonable atender a la previsión y esperar que sea un cambio de carácter temporal. El segundo hecho a destacar es que la estimación del recurso renovable ha sido algo conservadora. Se observa que el aerogenerador dispone de algo más de potencia que la prevista y puede entregar el pico producido por la conexión repentina de la carga. En el caso que viene a continuación se estudiará la situación contraria, menor disponibilidad del recurso natural de la que se prevé. En lo que respecta a la potencia reactiva, los Reguladores reaccionan rápidamente ante el aumento de corriente que se ha producido y consiguen mantener las consignas del Optimizador sin dificultad, tal y como se muestra en la Fig. 65. Fig. 65. Fig. 65.Fig. 65. Fig. 65. Respuesta Respuesta Respuesta Respuesta a a a a cambio brusco de la carga óhmica cambio brusco de la carga óhmicacambio brusco de la carga óhmica cambio brusco de la carga óhmica durante durante durante durante el el el el periodo 3: Q periodo 3: Qperiodo 3: Q periodo 3: Q -50 0 50 100 150 200 250 300 350 400 450 500 Conexión repentina +40s Potencia reactiva [VAr] Gen. Eólica Gen. Diésel Batería 1 Batería 2 4 Optimización clásica 108 Un caso más interesante para analizar la reacción del control de Q sería conectar una carga inductiva, en lugar de la anterior puramente óhmica. Para ello, se sustituye la resistencia de 20Ω por una bobina de 84mH y se vuelve a simular el modelo. La respuesta es la siguiente: Fig. 66. Fig. 66.Fig. 66. Fig. 66. Respuesta Respuesta Respuesta Respuesta a a a a cambio brusco cambio brusco cambio brusco cambio brusco de la carga de la carga de la carga de la carga i ii inductiva nductivanductiva nductiva durante el periodo 3: Q durante el periodo 3: Qdurante el periodo 3: Q durante el periodo 3: Q Los Reguladores tampoco tienen ningún problema para volver al estado de consignas iniciales. Al igual que en el caso anterior, va a ser la red la que supla la diferencia entre demanda de potencia reactiva y el sumatorio de potencias entregadas por los generadores. 4.4.4 4.4.44.4.4 4.4.4 Funcionamiento en isla Funcionamiento en isla Funcionamiento en isla Funcionamiento en isla Interesa conocer también el comportamiento de la microrred trabajando de manera aislada, o “en isla”. Para ello, basta con desconectar el generador que modela la red en Simulink. Hasta el momento, la red había sido la responsable de compensar la diferencia entre la demanda y el sumatorio de consignas, pero ahora ya no cabrá esta posibilidad. El escenario simulado no forma parte de ningún periodo de la optimización del apartado A, puesto que ésta no se realizó bajo el supuesto de desconexión de red. No obstante, si se desea utilizar el algoritmo para obtener el balance óptimo de la microrred funcionando en isla, bastará con indicarle que la potencia disponible Smax(red) es 0 VA. Las consigas escogidas para la ocasión se presentan en la Tabla 44 y se han sido escogido arbitrariamente para poder visualizar lo mejor posible la respuesta del sistema. El Optimizador va a requerir al Regulador del aerogenerador su potencia nominal (4 kW), mientras que al grupo electrógeno no le va a encomendar generación alguna. A las baterías les va a dictar unas consignas de carga de 500 y 200 W respectivamente. -400 -300 -200 -100 0 100 200 300 400 Conexión repentina +40s Potencia reactiva [[VAr] Gen. Eólica Gen. Diésel Batería 1 Batería 2 Rafael Tallada Souto 109 Consigna ConsignaConsigna Consigna [W] [W][W] [W] P(gen-1) 4000 P(gen-2) 0 P(bat-1) -500 P(bat-2) -200 Tabla 44. Tabla 44.Tabla 44. Tabla 44. Consignas de potencia Consignas de potenciaConsignas de potencia Consignas de potencia activa activaactiva activa Para analizar la respuesta de la microrred ante un decremento de disponibilidad del recurso renovable, la potencia extraíble del viento caerá de forma temporal hasta los 2000 W, para volver después a su valor de partida (la consigna no varía). A los 100 segundos de simulación se conectará, en paralelo, una segunda carga que sumará su consumo al de la que había inicialmente. Los valores inicial y final de dicha carga coinciden con los del caso anterior (20 y 10 Ω). La Fig. 67 muestra la forma de reaccionar de la microrred ante los eventos anteriormente mencionados cuando se encuentra funcionando aislada de la red. Fig. 67. Fig. 67.Fig. 67. Fig. 67. Funciona FuncionaFunciona Funcionamiento en isla: P miento en isla: Pmiento en isla: P miento en isla: P Se observa que el reparto de potencias difiere sustancialmente de los casos de simulación anteriores, en los que sí existía conexión a red. En efecto, el aerogenerador (línea azul) comienza entregando 3500 W, pese a que la consigna del Optimizador son 4000 W y dispone de viento suficiente. La razón de esta discrepancia radica en que en este tipo de redes, prima mantener el equilibrio energético entre generación y demanda por encima de cualquier otro requerimiento. Se verifica que esto es así fácilmente: de estos 3500 W, 700 W los absorben las baterías y 2600 W la carga. Los 200 W sobrantes se disipan en las líneas que unen los generadores con las cargas, modeladas como impedancias RL. -1000 0 1000 2000 3000 4000 5000 20s 40s 60s 80s 100s 120s 140s Potencia [W] Gen. Eólica Gen. Diésel Batería 1 Batería 2 4 Optimización clásica 110 Transcurridos 20 segundos el viento baja de intensidad, obligando al grupo electrógeno a arrancar y a las baterías a devolver energía a la red para mantener el equilibrio. Cuando se vuelve a disponer de potencia proveniente del recurso natural, el generador diésel y las baterías recuperan sus puntos de funcionamiento anteriores a la perturbación. Finalmente, se analiza la respuesta de los cuatro elementos ante el brusco aumento de demanda, que tiene lugar a los 100 segundos como consecuencia de conectar una segunda carga en paralelo. El aerogenerador comienza a entregar su potencia nominal y el resto de elementos incrementan de forma análoga su potencia para mantener el balance en la microrred, manteniendo así el equilibrio entre generación y demanda. 4.5 4.54.5 4.5 Conclusiones ConclusionesConclusiones Conclusiones y líneas futuras y líneas futurasy líneas futuras y líneas futuras En este capítulo se ha propuesto un sistema de control y optimización para una microrred de corriente alterna. Se ha optado por un sistema de control semidistribuido, con dos elementos reguladores, de funciones y responsabilidades diferenciadas. La potencia activa y reactiva es controlada en tiempo real por los Reguladores mediante la técnica P-Q droop. Un nivel jerárquico por encima de ellos se sitúa el Optimizador, cuya función es optimizar el coste del balance energético de la microrred. Se ha presentado el algoritmo de control, la idiosincrasia del software utilizado para la simulación, y se ha verificado el buen funcionamiento del sistema en diversos escenarios y situaciones. 4.5.1 4.5.14.5.1 4.5.1 Conclusio ConclusioConclusio Conclusion nn nes eses es Las conclusiones extraídas son: • El control implementado funciona correctamente, tanto al nivel de la optimización como al del control PQ. La arquitectura semidistribuida permite dotar al sistema de flexibilidad manteniendo la posibilidad de tomar decisiones a un nivel global. • La comunicación en tiempo real entre un SMA en JADE y un modelo Simulink es posible mediante el middleware MACSimJX, aunque su utilización presenta un inconveniente: ralentiza la simulación. Estas comunicaciones se llevan a cabo con una periodicidad definida e invariable, que debe coincidir con el paso de simulación del modelo Simulink. Este hecho impide a Simulink aumentar el paso de tiempo en los momentos de menor carga de cálculo, lo que implica que toda la simulación se lleve a cabo con el mínimo paso de simulación. La diferencia llega a ser de varios órdenes de magnitud. • El acierto del agente supervisor a la hora de optimizar depende de lo acertadas que sean sus previsiones de demanda y de generación. • AMPL resulta ideal para el modelado de problemas de esta naturaleza. La curva de aprendizaje es muy favorable debido a una sintaxis sencilla e intuitiva. • Para aprovechar al máximo las posibilidades de integrar la tecnología de agentes y el entorno Simulink, los modelos que implementen cada uno de ellos deberán coincidir en la escala de tiempo. Por ejemplo, si Simulink modela con un paso de tiempo adecuado para el régimen transitorio (del orden de 10 -4 segundos), el SMA deberá trabajar a una escala de tiempo similar. Esto no se ha respetado, al haber mezclado optimización a un orden de magnitud de horas con un control P/F en el entorno del milisegundo. Rafael Tallada Souto 111 4.5.2 4.5.24.5.2 4.5.2 Líneas futuras Líneas futurasLíneas futuras Líneas futuras Las posibles líneas de continuidad son: • Previo a un cambio radical en el modelo, sería conveniente tratar de lograr que los canales de comunicación abiertos entre el agente Optimizador y Simulink funcionaran únicamente en los momentos puntuales requeridos. En la implementación actual este flujo de datos nunca cesa. Por un lado los inputs que recibe la función MACSim (estimaciones de demanda), son enviados en cada paso de simulación; aunque tan sólo son leídas y guardadas de forma puntual una vez que han pasado los n periodos. Asimismo, los outputs de la función MACSim (consignas para los Reguladores) permanecen inalterados durante un periodo completo, mientras que son enviados a través de MACSim de forma continua. Debería ser posible acceder al código y modificarlo para “cerrar” dichos canales cuando no se necesiten. • El modelo de previsión de la demanda y de la generación no controlable puede mejorarse con el desarrollo de algún modelo basado en redes neuronales o similar, que permitiría mejorar el control y obtener mejores precios en el mercado eléctrico. • El agente Optimizador podría comunicarse con otros agentes Optimizadores mediante los canales habituales de JADE para, mediante un proceso de subasta, intercambiar energía con otras microrredes para minimizar su coste. • Para acelerar la simulación se plantea la utilización de un clúster de ordenadores para dividir la carga de cálculo necesaria. Si esto no fuera posible se podría reducir el nivel de detalle de los objetos modelados (utilizar modelos propios en lugar de los de la librería SimPowerSystem) o reducir al mínimo los elementos de la microrred que Simulink tiene que simular. 113 5 55 5 Conclusiones personales Conclusiones personalesConclusiones personales Conclusiones personales El desarrollo de este PFC me ha dado la oportunidad de trabajar en el campo de las energías renovables, por el que siempre he tenido un gran interés. He podido colaborar en investigaciones llevadas a cabo por la fundación CIRCE, de aplicación real en la industria eléctrica, lo que me ha hecho ser consciente de la gran dificultad que los proyectos de esta índole entrañan. Gracias a este PFC he aprendido y manejado conceptos y herramientas nuevos, tanto en el ámbito del software como en el de los sistemas de potencia; y he tenido la ocasión de trabajar codo a codo con ingenieros e investigadores de gran experiencia. Las tareas de programación han supuesto una excelente forma de entrenar mi paciencia, especialmente durante las fases de depuración de fallos. Asimismo, la redacción de la memoria me ha permitido mejorar los conocimientos de Microsoft Excel y Word. Este PFC no es un punto y final, sino más bien un punto y aparte, puesto que se continuará trabajando en él a lo largo del año académico 2013/2014; siguiendo las líneas de continuidad que aquí se han detallado. 115 6 66 6 Anexo AnexoAnexo Anexos ss s 6.1 6.16.1 6.1 Feedback modo Feedback modo Feedback modo Feedback modo Debug DebugDebug Debug (Iteration 1 of 17520, (Iteration 1 of 17520, (Iteration 1 of 17520, (Iteration 1 of 17520, Peak Shav Peak ShavPeak Shav Peak Shaving inging ing) )) ) A continuación se presenta el feedback que proporciona el emulador cuando se activan los tres modos de depuración de fallos: BatteryDebug, ReactiveDebug y ACLdebug. El carácter asíncrono inherente a un SMA se pone de manifiesto en el orden en el que este feedback aparece en pantalla. El texto en negrita se sigue mostrando estén o no estén activados los modos Debug. ago 30, 2013 7:36:30 PM jade.core.Runtime beginContainer INFO: ---------------------------------- This is JADE 4.2.0 - revision 6574 of 2012/06/20 15:38:00 downloaded in Open Source, under LGPL restrictions, at http://jade.tilab.com/ ---------------------------------------- Retrieving CommandDispatcher for platform MicroGrid ago 30, 2013 7:36:31 PM jade.imtp.leap.LEAPIMTPManager initialize INFO: Listening for intra-platform commands on address: - jicp://155.210.29.118:1099 ago 30, 2013 7:36:33 PM jade.core.BaseService init INFO: Service jade.core.management.AgentManagement initialized ago 30, 2013 7:36:33 PM jade.core.BaseService init INFO: Service jade.core.messaging.Messaging initialized ago 30, 2013 7:36:33 PM jade.core.BaseService init INFO: Service jade.core.resource.ResourceManagement initialized ago 30, 2013 7:36:34 PM jade.core.BaseService init INFO: Service jade.core.mobility.AgentMobility initialized ago 30, 2013 7:36:34 PM jade.core.BaseService init INFO: Service jade.core.event.Notification initialized ago 30, 2013 7:36:34 PM jade.mtp.http.HTTPServer <init> INFO: HTTP-MTP Using XML parser com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser ago 30, 2013 7:36:34 PM jade.core.messaging.MessagingService boot INFO: MTP addresses: http://155.210.29.118:7778/acc ago 30, 2013 7:36:35 PM jade.core.AgentContainerImpl joinPlatform INFO: -------------------------------------- Agent container [email protected] is ready. -------------------------------------------- <load2> agent reading data from: [load2.xlsx] <wind> agent reading data from: [wind1.xlsx] <load1> agent reading data from: [load1.xlsx] <pv1> agent reading data from: [pv1.xlsx] <pv2> agent reading data from: [pv2.xlsx] <load3> agent reading data from: [load3.xlsx] <pv4> agent reading data from: [pv4.xlsx] <load4> agent reading data from: [load4.xlsx] <pv3> agent reading data from: [pv3.xlsx] <battery2@MicroGrid> sending {INFORM} to <jade.util.leap.ArrayList$1@ab1bf>: READY <battery1@MicroGrid> sending {INFORM} to <jade.util.leap.ArrayList$1@138fec2>: READY <battery4@MicroGrid> sending {INFORM} to <jade.util.leap.ArrayList$1@dd9715>: READY <battery3@MicroGrid> sending {INFORM} to <jade.util.leap.ArrayList$1@165532d>: READY <power_manager> agent registered successfully its service CONTROL, type "POWER_CONTROL". <power_manager> waiting in "blockingReceive" mode. 1 messages received. <power_manager> waiting in "blockingReceive" mode. 2 messages received. <power_manager> waiting in "blockingReceive" mode. 3 messages received. <power_manager> waiting in "blockingReceive" mode. 4 messages received. <power_manager> waiting in "blockingReceive" mode. <power_manager@MicroGrid> agent is ready! 6 Anexos 122 {ACCEPT-PROPOSAL} sent by <power_manager@MicroGrid> successfully received by <pv3@MicroGrid>: P set point [kW]: 0.0 | Q set point [kVAr]: 0.0 POWER_LOSSES AFTER getQ(): 0.0 MARGIN_FOR_P = SQRT(30.0^2 - 0.0^2) - 0.0 = 30.0 [kW] p_out = SetPointP * EFF = 0.0 * 0.95 = 0.0 [kW] POWER_LOSSES AFTER getP(): 0.0 RETURNING POWER_LOSSES BY getPowerLosses(): 0.0 <pv3@MicroGrid> sending {INFORM} to <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 0.0 | Q out [kVAr]: 0.0 {INFORM} sent by <load3@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: CONSUMPTION | Real power consumed [kW]: 8.7682794495 | Reactive power consumed [kVAr]: 6.321833622 {ACCEPT-PROPOSAL} sent by <power_manager@MicroGrid> successfully received by <battery3@MicroGrid>: P set point [kW]: 0.0 | Q set point [kVAr]: 0.0 POWER_LOSSES AFTER getQ(): 0.0 MARGIN_FOR_P = SQRT(51.0^2 - 0.0^2) - 0.0 = 51.0 [kW] p_out = SetPointP * EFF = 0.0 * 0.95 = 0.0 [kW] POWER_LOSSES AFTER getP(): 0.0 RETURNING POWER_LOSSES BY getPowerLosses(): 0.0 <battery3@MicroGrid> sending {INFORM} to <power_manager@MicroGrid>: Type: STORAGE | P out [kW]: 0.0 | Q out [kVAr]: 0.0 | SOC [%]: 50.0 {ACCEPT-PROPOSAL} sent by <power_manager@MicroGrid> successfully received by <load4@MicroGrid>: P set point [kW]: 2.9227598165 | Q set point [kVAr]: 2.107277874 <load4@MicroGrid> sending {INFORM} to <power_manager@MicroGrid>: Type: CONSUMPTION | Real power consumed [kW]: 2.9227598165 | Reactive power consumed [kVAr]: 2.107277874 {ACCEPT-PROPOSAL} sent by <power_manager@MicroGrid> successfully received by <pv4@MicroGrid>: P set point [kW]: 0.0 | Q set point [kVAr]: 0.0 POWER_LOSSES AFTER getQ(): 0.0 MARGIN_FOR_P = SQRT(100.0^2 - 0.0^2) - 0.0 = 100.0 [kW] p_out = SetPointP * EFF = 0.0 * 0.95 = 0.0 [kW] POWER_LOSSES AFTER getP(): 0.0 RETURNING POWER_LOSSES BY getPowerLosses(): 0.0 <pv4@MicroGrid> sending {INFORM} to <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 0.0 | Q out [kVAr]: 0.0 {INFORM} sent by <load1@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: CONSUMPTION | Real power consumed [kW]: 29.227598165 | Reactive power consumed [kVAr]: 21.07277874 {INFORM} sent by <load2@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: CONSUMPTION | Real power consumed [kW]: 17.536558899 | Reactive power consumed [kVAr]: 12.643667244 {INFORM} sent by <load4@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: CONSUMPTION | Real power consumed [kW]: 2.9227598165 | Reactive power consumed [kVAr]: 2.107277874 <pv4> just added: | 0,0000 | 0,0000 | 0,0000 | to its DataOutVector. <pv1> just added: | 0,0000 | 0,0000 | 0,0000 | to its DataOutVector. <battery1> just added: | 0,00000000000000 | 0,00000000000000 | 0,00000000000000 | 50,00000000000000 | 0,00000000000000 | to its DataOutVector. <wind> just added: | 43,7274 | 42,1456 | 4,5196 | to its DataOutVector. <battery4> just added: | 0,00000000000000 | 0,00000000000000 | 0,00000000000000 | 50,00000000000000 | 0,00000000000000 | to its DataOutVector. {INFORM} sent by <pv4@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 0.0 | Q out [kVAr]: 0.0 {INFORM} sent by <pv1@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 0.0 | Q out [kVAr]: 0.0 {INFORM} sent by <battery1@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: STORAGE | P out [kW]: 0.0 | Q out [kVAr]: 0.0 | SOC [%]: 50.0 1. <battery1> power_batteries = 0.0 | p_out = 0.0 2. <battery1> power_batteries = 0.0 {INFORM} sent by <wind@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 43.72737212599999 | Q out [kVAr]: 42.14555748 {INFORM} sent by <battery4@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: STORAGE | P out [kW]: 0.0 | Q out [kVAr]: 0.0 | SOC [%]: 50.0 1. <battery4> power_batteries = 0.0 | p_out = 0.0 2. <battery4> power_batteries = 0.0 Rafael Tallada Souto 123 <battery2> just added: | 0,00000000000000 | 0,00000000000000 | 0,00000000000000 | 50,00000000000000 | 0,00000000000000 | to its DataOutVector. <pv2> just added: | 0,0000 | 0,0000 | 0,0000 | to its DataOutVector. <pv3> just added: | 0,0000 | 0,0000 | 0,0000 | to its DataOutVector. <battery3> just added: | 0,00000000000000 | 0,00000000000000 | 0,00000000000000 | 50,00000000000000 | 0,00000000000000 | to its DataOutVector. {INFORM} sent by <battery2@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: STORAGE | P out [kW]: 0.0 | Q out [kVAr]: 0.0 | SOC [%]: 50.0 1. <battery2> power_batteries = 0.0 | p_out = 0.0 2. <battery2> power_batteries = 0.0 {INFORM} sent by <pv2@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 0.0 | Q out [kVAr]: 0.0 {INFORM} sent by <pv3@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: GENERATION | P out [kW]: 0.0 | Q out [kVAr]: 0.0 {INFORM} sent by <battery3@MicroGrid> successfully received by <power_manager@MicroGrid>: Type: STORAGE | P out [kW]: 0.0 | Q out [kVAr]: 0.0 | SOC [%]: 50.0 1. <battery3> power_batteries = 0.0 | p_out = 0.0 2. <battery3> power_batteries = 0.0 <power_manager> just added: | 14,72782420400000800 | 14,72782420400000800 | 0,00000000000000000 | 1,00000000000000000 | 50,00000000000000000 | to its DataOutVector. Final power net balance: 14.727824204000008 [kW] Reactive power net balance: 0.0 [kVAr] Global state of charge (SOC) of the storage system: 50.0 % Power factor, as seen from the grid side: 1,00000000000000000 END OF FIPA-CONTRACT-NET PROTOCOL. ITERATION #1 of 17520. ________________________________________________________________________________________________________ 125 7 77 7 Bibliografía BibliografíaBibliografía Bibliografía [1] G. Piernavieja Izquierdo, «Microrredes con elevada penetración de Energías Renovables y Almacenamiento Energético,» de Integración en red: soluciones para altas penetraciones eólicas en sistemas insulares , Las Palmas de Gran Canaria, 2010. [2] European Comission, «Vision and Strategy for Europe's Electricity Networks of the Future,» RTD info, 2006. [3] P. Crossley, A. Beviz, J. M. Angulo y S. Arnaltes, «Smart energy systems: Transitioning renewables onto the grid,» Renewable Energy Focus, vol. 11, nº 5, pp. 54-56, 5859, 2010. [4] C. A. Bes, Control distribuido de micro - redes, PFC Ingeniería Industrial, Universidad de Zaragoza, 2012. [5] J. A. Domínguez, Servicios complementarios para la correcta gestión de una microrred, Sangüesa, 2011. [6] S. A. Ramos, «Modelos y Optimización I: Apunte de Heurísticas,» noviembre 2007. [En línea]. Available: http://materias.fi.uba.ar/7114/guiaTP.php. [Último acceso: 16 8 2013]. [7] A. Ramos, P. Sánchez, J. M. Ferrer, J. Barquín y P. Linares, «Mod elos matemáticos de optimización,» septiembre 2010. [En línea]. Available: http://www.gams.com/docs/contributed/modelado_en_gams.pdf. [Último acceso: 19 8 2013]. [8] J. J. Gómez Sanz y R. Fuentes, Introducción a la tecnología de agentes, Universidad Complutense de Madrid, 2003. [9] F. Bellifemine, G. Caire, G. Rimassa y A. Poggi, «JADE: A White Paper,» Septiembre 2003. [En línea]. Available: http://jade.tilab.com/papers/2003/WhitePaperJADEEXP.pdf. [Último acceso: 10 04 2013]. [10] Univ. Politécnica de Valencia. Dept. Sistemas Informáticos y Computación, «SMA, curso de doctorado,» 2002. [En línea]. Available: http://www.upv.es/sma/web/sma.htm. [Último acceso: 5 8 2013]. [11] Foundation for Intelligent Physical Agents, FIPA, «The Fo undation for Intelligent Physical Agents,» 2012. [En línea]. Available: http://www.fipa.org/specs/fipa00037/index.html. [Último acceso: 23 Julio 2013]. [12] G. Caire, «Jade Programming for Beginners,» 30 Junio 2009. [En línea]. Available: http://jade.tilab.com/doc/tutorials/JADEProgramming-Tutorial-for-beginners.pdf. [Último acceso: 10 04 2013]. [13] N. Hatziargyriou, H. Asano, R. Iravani y C. Marnay, «Microgrids,» IEEE power & energy magazine, nº Julio/Agosto, pp. 78-94, 2007. [14] O. Mohammed, M. N ayeem y A. Kaviani, «A laboratory based microgrid and distributed 7 Bibliografía 126 generation infrastructure for studying connectivity issues to operational power systems,» de Power and Energy Society General Meeting, IEEE , Minneapolis, MN, 2010. [15] H. Nwe Aung, A. M. Khambadkone, D. Srinivasan y T. Logenthiran, «Agent - based Intelligent Control for Real-time Operation of a Microgrid,» de PEDESPOWER INDIA 2010 : Joint International Conference on Power Electronics, Drives and Energy Systems & 2010 Power India, New Delhi, India, 2010. [16] C. Colson, M. Nehrir y R. Gunderson, «Multi - agent Microgrid Power Management,» de 18th IFAC World Congress, Milán, Italia, 2011. [17] A. Ruiz - Álvarez, A. Colet - Subirach, F. Álvarez - Cuevas Figuerola, O. Gomis - Bellmunt y A. Suidrà-Andreu, «Operation of a Utility Connected Microgrid Using an IEC 61850Based Multi-Level Management System,» The IEEE Transactions on Smart Grid (TSG), vol. 3, nº 2, pp. 858 - 865, 2012. [18] M. Kouluri y R. Pandey, «Intelligent agent based micro grid control,» de 2nd International Conference on Intelligent Agent and Multi-Agent Systems (IAMA) , Chennai, 2011. [19] M. Rajendram y R. Pandey, «Multi Agent Control for two area power system netw ork,» de International Conference on Computing, Electronics and Electrical Technologies (ICCEET), , Kumaracoil, 2012. [20] H. Bludszuweit, «Simulation of mini - grids with high penetration of renewable energies and storage systems to manage energy,» Zaragoza, 2012. [21] C. - H. Yoo, W. - J. Choi, I. - Y. Chung, D. - J. Won, S. - S. Hong y B. - J. Jang, «Hardware - In - the - Loop Simulation of DC Microgrid with MultiAgent System for Emergency Demand Response,» de Power and Energy Society General Meeting, San Diego, CA, 2012. [22] A. L. Dimeas y N. D. Hatziargyriou, «A MAS architecture for Microgrids control,» de Intelligent Systems Application to Power Systems, Proceedings of the 13th International Conference on, Arlington, VA, 2005. [23] Foundation for Intelli gent Physical Agents, FIPA, «The Foundation for Intelligent Physical Agents,» [En línea]. Available: http://www.fipa.org/specs/fipa00029/SC00029H.html. [Último acceso: 8 8 2013]. [24] K. Jarvi, «RXTX,» 7 7 2011. [En línea]. Available: http://rxtx.qbang.org/wiki/index.php/Main_Page. [Último acceso: 2013 8 12]. [25] A. Engler, «ISET's Microgrid Research: Past, Present, Future,» de Symposium on Microgrids, Nagoya, Japón, 2007. [26] C. R. Robinson, P. Mendham y T. Clarke, «Systems Design using Agent Control,» University of York, 2009. [En línea]. Available: http://www.agentcontrol.co.uk/. [Último acceso: 10 04 2013]. [27] C. R. Robinson, P. Mendham y T. Clarke, «MACSimJX: A Tool for Enabling Agent Modelling with Simulink Using JADE,» Journal of Physical Agents, vol. 4, nº 3, Septiembre 2010. [28] R. Fourer, D. M. Gay y B. W. Kernighan, AMPL A Modeling Language for Mathematical Rafael Tallada Souto 127 Programming, Segunda ed., Duxbury/Thomson, 2003. [29 ] D. Grimshaw, «JADE Administration Tutorial,» 26 Marzo 2010. [En línea]. Available: http://jade.tilab.com/doc/tutorials/JADEAdmin/index.html. [Último acceso: 10 04 2013]. [30] F. Bellifemine, G. Caire, T. Trucco y G. Rimassa, «JADE Programmer's Guide,» 8 Abril 2010. [En línea]. Available: http://jade.tilab.com/doc/programmersguide.pdf. [Último acceso: 10 04 2013]. [31] IEEE computer Society, «The Foundation for Intelligent Physical Agents,» 2013. [En línea]. Available: http://www.fipa.org/index.html. [Último acceso: 10 04 2013]. [32] J. Lewis y W. Loftus, Java software solutions: foundations of program design, Boston: Addison-Wesley, 2012.