ARQUITECTURA DE SOFTWARE APLICADA A LOS SIMULADORES DE MERCADOS ELÉCTRICOS COMPETITIVOS

Transcripción

1 ARQUITECTURA DE SOFTWARE APLICADA A LOS SIMULADORES DE MERCADOS ELÉCTRICOS COMPETITIVOS F. Corteggiano, R. Matteoda, D. Moitre, F. Magnago Resumen Debido a los cambios que a partir de la década de 1980 comenzaron a introducirse a escala mundial en la estructura de los mercados de Energía Eléctrica, la arquitectura de software debe rediseñarse para incorporar nuevas funciones que tengan en cuenta la operación del mercado eléctrico y su interacción con la operación del sistema eléctrico de potencia en tiempo real. En este trabajo, una nueva arquitectura de software aplicada a un simulador de mercados eléctricos competitivos es propuesta. La arquitectura está basada en una aplicación de software distribuido utilizando la plataforma J2EE. Ejemplos prácticos ilustran la capacidad del software implementado. Palabras Clave Mercados de Energía Eléctrica Competitivos, arquitectura de software, simulador de mercados eléctricos. I. INTRODUCCION Tradicionalmente la estructura de los mercados de energía eléctrica (MEE) era verticalmente integrada, la cual predominó hasta principios de la década del 90. Desde entonces, la mayoría de los MEE en todo el mundo han reformado sus estructuras hacia una mayor segmentación vertical y horizontal como consecuencia de la introducción de la competencia. [1] En este ambiente competitivo, se pueden distinguir distintos actores que interaccionan entre si y que en general tienen objetivos contrapuestos. Dentro de estos actores se pueden distinguir los generadores de energía, el operador del MEE, las distribuidoras de energía y el operador de la red de transmisión. Como consecuencia de esto, al operar el MEE se deben tomar decisiones en forma muy coordinadas ya que las funciones del mercado eléctrico interactúan con las funciones de seguridad de la red de transmisión eléctrica. En un mercado eléctrico competitivo, los generadores deben realizar ofertas de energía al sistema eléctrico interconectado a través de curvas precio-potencia con el objetivo de maximizar su ganancia, por otra parte, las empresas de distribución eléctrica deben realizar sus demandas de energía eléctrica, la cual también pueden ser curvas precio-demanda, con el objetivo de minimizar el costo de energía que compra. El operador del MEE debe coordinar estas ofertas y pedidos de manera tal que satisfaga las necesidades de demanda eléctrica, minimizando el costo variable de operación y asegurando la confiabilidad y seguridad del sistema de transmisión eléctrica. El operador del mercado eléctrico es quien determina el precio de mercado de energía eléctrica básicamente encontrando la intersección entre la curva de oferta y la curva de demanda en un período de tiempo determinado. El operador tiene la responsabilidad de publicar este precio y proveer a cada participante del mercado con la cantidad y precio de energía aceptada, además de calcular el rendimiento financiero de cada participante. Esta información debe ser mantenida en forma confidencial hasta transmitirse a todos los participantes en forma simultánea. La forma de realizar la oferta, la demanda y la operación del MEE dependen del diseño del mercado. En algunos mercados se puede ofertar energía a un determinado precio o venta de servicios auxiliares tales como reserva rotante o potencia reactiva. En otros mercados estas ofertas pueden incluir además parámetros adicionales relacionados con el costo de proporcionar esta energía, tales como costo de puesta en marcha, parada o restricciones del generador. Pero independientemente del mercado, el decidir la oferta por parte del generador o la operación del mercado se dificulta por diversos factores, entre otros: presencia de múltiples mercados, curvas de costo no convexas, incertidumbres de precios y contingencias de la red eléctrica. Esta forma de operar el sistema eléctrico difiere sustancialmente con la forma tradicional de operar el mismo. Previamente, la operación de un sistema eléctrico se programaba empleando una estructura de software rígido. En adición a esto, el intercambio de información fue diseñado para ser compartida solamente dentro de una misma compañía eléctrica a través de redes internas de comunicación debido a razones de seguridad y porque no existía la necesidad de intercambiar información fuera de la empresa. Por lo tanto, la estructura de software necesaria para operar el sistema eléctrico se ha visto en la necesidad de reestructurarse, con el objetivo de incluir nuevas funciones para operar el mercado y realizar su interacción en tiempo real con las funciones de operación del sistema. Una contribución importante es la de abrir la arquitectura del software dedicado a la operación del sistema eléctrico. El objetivo principal de las arquitecturas abiertas en un ambiente

2 competitivo es el de proveer de una plataforma de software acorde a las nuevas necesidades del MEE, mucho mas eficiente, permitiendo un crecimiento incremental, incluir actualizaciones desde diferentes fuentes, proporcionar un diseño modular, y promover una interacción entre los distintos sectores en forma rápida y segura. Actualmente, los avances en el área de información tecnológica, y especialmente desarrollos en el área de Internet, han resultado ser una solución efectiva. Entre sus características se pueden resaltar las ventajas que ofrece desde el punto de vista de seguridad, velocidad y costo. Como consecuencia de estas características, se presenta como una alternativa para el diseño de la arquitectura de software del MEE, proporcionando una solución para las necesidades de intercambio de información dentro de un ambiente competitivo. El objetivo principal del presente trabajo es el de proponer una nueva arquitectura de software para utilizarla en simuladores de mercados eléctricos competitivos. El diseño de la arquitectura de software propuesta, está basado principalmente en aplicaciones de software distribuidas, permitiendo la interacción entre funciones del operador del MEE, bases de datos, y los distintos participantes del mercado a través de la Internet en un ambiente de acceso abierto, haciendo énfasis fundamentalmente en aspectos de velocidad y seguridad. II. ARQUITECTURA DE SOFTWARE BASADA EN SISTEMAS DISTRIBUIDOS Se define un Sistema Distribuido (SD) como aquel en el que los componentes hardware y software, localizados en ordenadores conectados en red, comunican y coordinan sus acciones solo mediante el paso de mensajes, para el logro de un objetivo. [2]. Se puede decir que un Sistema Distribuido consiste en un conjunto de dispositivos de cómputo unidos todos por una red y equipados con un sistema software no centralizado. De este modo, el software no centralizado conduce a la idea de un sistema software distribuido que permite a los elementos hardware del Sistema Distribuido coordinar sus actividades y compartir los recursos del sistema (hardware, software y datos). El objetivo final del Sistema Distribuido es conseguir que sus usuarios lo vean como un único e integrado entorno de computación, aunque en realidad se trate de diferentes elementos dispersos geográficamente e interconectados por una red. A raíz de la definición de Sistema Distribuido se observan las siguientes características: Concurrencia.- Esta característica de los sistemas distribuidos permite que los recursos disponibles en la red puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red. Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, se encuentra más bien distribuida a los componentes. Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto sigue trabajando. III. ESTRUCTURA DEL SOFTWARE PROPUESTO El software propuesto es desarrollado en lenguaje Java, utilizando la plataforma Java 2 Enterprise Edition (J2EE) [3]. Esta plataforma es una alternativa para aplicaciones que requieren el acceso a base de datos, seguridad, y conectividad con distintos usuarios. Permite ejecutar aplicaciones en un ambiente distribuido, donde el servidor comparte las aplicaciones utilizando Internet como nexos computadora - humano, humano - humano y computadora -computadora. J2EE es una plataforma optimizada para aplicaciones distribuidas de gran escala y permite la interacción con tecnologías ya existentes. Las aplicaciones pueden agruparse en distintas capas, cada una de ellas puede ejecutarse en distintas maquinas ubicadas en lugares remotos. Dentro de las capas, J2EE proporciona un contenedor para cada tipo de componentes de aplicación. Estos contenedores son: contendor cliente, contenedor applet, contenedor de web y el contenedor EJB. Los contenedores proveen del ambiente en tiempo real proporcionando servicios asociados a los siguientes componentes generales: lenguaje Java, applets, Java Server Pages (JSP), y los Enterprise Java Beans (EJB). Los applets son componentes de aplicación que se ejecutan en un WEB browser, tienen acceso a todas las características de Java y se comunican con el servidor de WEB utilizando protocolo HTTP. LA tecnología JSP (Java Server Pages) provee una forma de generar contenidos dinámicos en un cliente Web. JSP es un documento basado en texto y código Java, que describe como crear una respuesta luego de haber recibido una petición. Podemos decir que consta de dos partes, una parte facilita el formato del documento Web, HTML o XML, la otra parte es dinámica y le proporciona el contenido al documento, para lo cual se utilizan normalmente componentes EJB. JSP es incluida en los contenedores de Web que es quien debe soportar HTTP/HTTPS como protocolo para responder a las peticiones. La arquitectura Enterprise JavaBeans (EJB) es la encargada de proveer los componentes de aplicación que realizan la lógica de J2EE. Hay tres tipos de EJB: de sesión (los datos no son persistentes) los cuales manipulan los cálculos, o accesos a base de datos, de entidad que manejan persistencia de datos y de mensajes que permite a los clientes acceder en forma asincrónica a la capa EJB, es decir el cliente envía el mensaje a la cola la cual es escuchada por el manipulador. En forma más especifica, los contenedores proporcionan componentes denominados servicios que son de gran utilidad para los componentes de aplicación. Algunos de estos servicios son: http, https, RMI-IIOP, Java IDL, JDBC APIs, servicio de mensajería JMS, JNDI, Java Mail, Java Beans Activation Framework (JAF), (JAXP), servicios de seguridad, servicios de Web, funciones de manipulación y operación de datos. En una capa inferior está ubicado el servidor, que proporciona las herramientas de manipulación, mantenimiento y operación necesarias para la ejecución de componentes de aplicación.

3 Un componente es un programa de aplicación. J2EE soporta los siguientes tipos de componentes: applets, componentes EJB, componentes de Web y adaptadores de recursos. Los componentes no interactúan entre ellos directamente, la interacción se realiza a través de los contenedores. La interposición de un contenedor entre componentes permite adicionar todos los servicios que provee el contenedor a los componentes. Los applets y las aplicaciones de cliente se ejecutan dentro de la plataforma del cliente, mientras que los componentes EJB, web y los adaptadores de recursos son ejecutados dentro de la plataforma del servidor. Los adaptadores de recursos son componentes de aplicación construidos por el EIS (Enteprise Information System) y son operados por el servidor, de esta manera pueden ser utilizados por otros componentes de aplicación para poder acceder a los datos existentes en el EIS. El contenedor EJB puede ser conectado a las bases de datos a través de la interfase JDBC, las aplicaciones no necesitan establecer conexiones a las bases de datos directamente ya que es el contenedor EJB el que se ocupa de esto. Para realizar la comunicación entre el EJB y una aplicación desarrollada en una plataforma de software diferente, se necesita utilizar una interfase denominada wrapper. Otro servicio importante provisto por J2EE es el de servicio de web, por ejemplo, un cliente que soporta Servicio de Web envía una petición a un servidor del servicio usando el protocolo SOAP sobre HTTP, este servidor recibe la petición, la procesa y retorna una respuesta, los mismo puede realizarse entre cliente-cliente o servidor-cliente. Basada en la tecnología descripta en esta sección, la arquitectura propuesta es desarrollada, la cual se describe en la siguiente sección. IV. ARQUITECTURA PROPUESTA La Figura 1 muestra el esquema general de la arquitectura propuesta. Se pueden identificar cuatro capas distintas: cliente, web, servidor y EIS. El cliente es el que corresponde a los participantes de mercado, como por ejemplo GENCOs o comercializadores, quienes peueden realizar ofertas, o acceder a los resultados de precios de mercado realizados por el MOS o de cálculos realizados por las funciones del EMS utilizando una página de web. Un contenedor de web ubicado en la capa proporciona los servicios asociados con la interacción con Internet, la cual utiliza el protocolo http. Además otras aplicaciones como por ejemplo hojas de cálculos pueden utilizarse para presentar los resultados de simulación a los usuarios, utilizando los servicios de web, estas pueden interconectarse con el MOS utilizando protocolos SOAP (HTTP). En la capa del servidor incluye el contenedor EJB que tiene dos componentes principales: el servicio de web y el simulador de MOS, varias aplicaciones han sido implementadas dentro del MOS de manera tal de simular el mercado eléctrico, incluyendo un predictor de carga y de precio de mercado [4]. SOAP (HTTP) SERVICIO DE WEB SOAP (HTTP) SERVICIO METEOROLOGICO MOS DB HISTORIC DB OTRAS APLICACIONES.NET OFFICE XP JAVA JDBC (SQL) RMI WRAPPER JNI CLEINTE GENCO COMERCIALIZADOR CAPA CLIENTE HTTP / HTTPS CAPA WEB EMS FUNCIONES DE APLICACION CAPA DE SERVIDOR FILE SYSTEM BASE DE DATOS SEP CAPA SISTEMAS DE INFORMACION EXISTENTE Figura 1: Arquitectura propuesta para un mercado eléctrico. Las funciones de EMS, escritas en Fortran, son llamadas por el MOS utilizando un wrapper desarrollado a tal efecto. Esto permitió interconectar las funciones desarrolladas en plataformas J2EE y WIN32. El EIS es el nivel en donde se almacenan los datos, éstos están agrupados en dos bases de datos diferentes, la del MOS que es comunicada con el MOS a través de el protocolo JDBC (SQL) y la base de datos del SEP, que es comunicada directamente con las funciones del EMS en formato texto utilizando un manejador de archivos directamente. Además dentro del EIS se encuentra el servicio de web que permite consultar en tiempo real un servicio público de datos meteorológicos necesarios para la función de predicción. En este caso el MOS genera una petición a la dirección de URL del servidor de datos meteorológicos, esta petición es atendida y los datos son enviados al MOS en tiempo real. Los servicios de web son provistas por una aplicación del Java denominada JAX-RPC, y utiliza el protocolo de comunicación SOAP (HTTP). V. DESARROLLO DE UN SIMULADOR DE MERCADO ELECTRICO A continuación se implementá un simulador de Mercado bilateral cuyo objetivo es utilizar la arquitectura de software presentada en el capítulo anterior, verificar su implementación, y establecer las bases para futuros desarrollos basados en esta tecnología. Basado en los conceptos de mercado competitivo y el modelo de software presentados en capítulos anteriores, a

4 continuación se realiza la implementación un simulador de mercado bilateral [5], [6]. El diseño de la arquitectura de software, para el simulador de mercado se muestra en la Figura 2. Las herramientas de software empleadas son: Eclipse (Entorno visual de desarrollo en Java), JBoss (Servidor de Aplicaciones), Tomcat (Web Server), Gsoap (Desarrollo de Web Services) Figura 2: Arquitectura de Software del Simulador de Mercado. Los clientes del Simulador, generadores, consumidores y el Operador de Mercado MO, utilizando la tecnología de un Web Browser, a través del protocolo HTTP SSL se comunican con el servidor web para el acceso a toda la información que cada participante necesita, esto produce un aislamiento entre el Operador del Sistema y los usuarios. Es decir cada usuario con su perfil sólo accederá a la información autorizada desde cualquier lugar con conexión a Internet. El servidor de aplicaciones JBOSS (tecnología JAVA) presta los servicios indicados en el capítulo anterior, cuyas aplicaciones se nutren de estos servicios para realizar toda la negociación necesaria para el proceso de simulación, el acceso a bases de datos, como así también establecer la comunicación con todos los clientes a través del servidor Web Tomcat. Una de las grandes ventajas en el uso de este tipo de servidores es su escalabilidad, este servidor no depende del sistema operativo, ni del tipo de procesadores a utilizar, es de gran utilidad ya que permite crecer en la complejidad del sistema sin la necesidad de grandes cambios. A medida que la complejidad del sistema crece, se pueden utilizar varios servidores JBOSS, distribuidos en la red cada uno especializado en una tarea en particular. Entre los servicios importates del JBOSS se pueden citar, la encriptación de la información que se transmite, la persistencia de los datos, el manejo de las bases de datos, la duplicación de la información y el servicio web, que permite la publicación de los servicios que se prestan. Otro bloque importante que se observa en Figura 1 son las herramientas de análisis de Sistemas Eléctricos de potencia accesibles a través de Servicios Web. Dichas herramientas, desarrolladas en su gran mayoría en Fortran o C, pueden ser utilizadas por esta tecnología a través de los servicios web, en este caso se desarrolló la herramienta de cálculo de precio de mercado, esto se lleva a cabo de la siguiente manera: el Jboss (negociador) luego de haber almacenado los datos necesarios para el cálculo de precio de mercado, solicita a través del servicio de web el cálculo de precio de mercado, quien lo realiza y lo devuelve al JBOSS, este concepto también se podría utilizar para solicitar un cálculo de flujo de potencia, etc. La base de datos utilizada es mysql, se decidió utilizar la misma por ser una base de datos abierta. Los servicios de JBOSS son lo encargados de establecer la comunicación con la base de datos. Lo mismo se puede hacer con bases de datos como Oracle, Microsoft SQL Server, etc. Y por último Internet, y los protocolos necesarios para establecer una comunicación segura entre las aplicaciones que participan en el mercado. Esta tecnología es posible gracias al crecimiento de Internet, no solo su alcance logrado sino también la confiabilidad de la misma. Se consideran cinco generadores en un período de cuatro horas con una demanda elástica. Se considera un caso base, sin limitaciones y un caso con limitaciones en el mínimo técnico. La potencia de salida mínima y máxima se muestran en la Tabla 1. Los datos resultantes de la oferta de los cinco generadores se muestran en la Tabla 2, donde P es la potencia ofertada en MW y λ el precio ofrecido en $/MWh, en este ejemplo se toman cuatro bloques por generador, cada uno con diferentes ofertas en cantidad y precio. Pmin (MW) Pmax (MW) Unidad 1 Unidad Unidad Unidad Unidad Tabla 1 Datos de los Generadores La demanda elástica es modelada usando cinco bloques de demanda con los precios en orden decreciente. Los bloques de demanda son mostrados en la Tabla 2, donde D es la demanda para cada bloque en MW y λ es el precio en $/MWh.

5 Unidad Hora 1 Hora 2 Hora 3 Hora 4 P λ P λ P λ P λ P λ Tabla 2 Oferta de los generadores (MW) y Oferta de precio ($/MWh) disminuyen. Las restantes unidades incrementan sus ingresos. En la Figura 3 se muestra la comparación de las curvas de oferta y demanda para la primera hora. Se observa que si la curva de la demanda intersecta la parte horizontal de la curva de producción, la demanda consume hasta el último MW demandado y aceptado. El generador marginal sólo generará la necesaria para lograr el balance de la oferta y la demanda. Si la curva de demanda intersecta la parte vertical de la curva de la oferta, entonces todos los generadores producirán hasta el último MW aceptado, pero no toda la demanda será provista. Una manera de analizar los resultados de la simulación es mediante la comparación de los ingresos de cada participante. Luego de realizadas todas las determinaciones de precios limpios, se publican los resultados. Los ingresos totales obtenidos son: 3968, 9579, 10618, 3502 y $ correspondientes a cada uno de los cinco generadores, el precio para cada período es: 16.5, 17, 21 y 21 $/MWh respectivamente. En la Tabla 3 se muestran los resultados obtenidos de cada unidad después del cierre. Precio ($/MWh) Potencia (MW) Figura 3: Comparación de curvas de Oferta y demanda para la primera hora Hora 1 Hora 2 Hora 3 Hora 4 D Tabla 3 Cantidad de Demanda Ofrecida (MW) y Oferta de precio ($/MWh) λ De los resultados obtenidos se puede mostrar que mientras las unidades 3 y 5 no ofrezcan a precios por encima de 18 $/MWh como en las horas 3 y 4, el mercado le permite a ellos producir a su potencia máxima. La unidad 1 produce 0 MW en la hora 1 porque el precio ofrecido por la demanda es 16.5 $/MWh y el precio más bajo de su oferta es de 18 $/MWh. A continuación se analiza el caso con limitaciones, se asume que la unidad 3 tiene una rampa de crecimiento/ decrecimiento igual a 50 MW por hora. Los resultados se muestran en la Tabla 4. Los ingresos totales de cada unidad son ahora: 3979, 9698, 10265, 3532 y $, el precio para cada período es: 16.5, 18, 21 y 21 $/MWh respectivamente. Observese que la unidad 3 viola el límite de rampa de crecimiento/ decrecimiento entre las horas 1 y 2 como se ve en la Tabla 5, de la Tabla 5 se observa que la unidad 3 decrece su producción en la hora 2 para poder satisfacer la razón de crecimiento/decrecimiento y sus ingresos Unidad 1 Unidad 2 Unidad 3 Unidad 4 Unidad 5 Hora Hora Hora Hora Tabla 4: Potencia de Salida de la unidades (MW), sin limitaciones Unidad 1 Unidad 2 Unidad 3 Unidad 4 Unidad 5 Hora Hora Hora Hora Tabla 5: Potencia de Salida de la unidades (MW), con limitaciones Para concluir se pueden inferir algunas conclusiones, como se muestra en la Figura 4 si se adiciona una limitación, aquellas unidades que son afectadas por la limitación disminuyen sus ingresos como es el caso de la unidad 3, mientras que el resto de las unidades los incrementan.

6 Ingresos ($) Unidad Caso sin limitaciones Caso con limitaciones Figura 4: Ingresos de cada unidad para los dos casos de estudio VI. EJEMPLO DE UTILIZACION DEL SIMULADOR DE MERCADO ELECTRICO El simulador desarrollado utiliza JBoss como server, desarrollando una interfase Web para interacción con el usuario. A continuación se detalla el procedimiento utilizado durante una sesión de simulación[7], [8]: En la capa de cliente están los participantes del mercado, GENCO y Comercializadores quienes hacen sus ofertas enviándolas al MO a través del servicio de Web o JSP. EL MO solicita los servicios al EMS para realizar la verificación eléctrica para que la configuración sea posible, esto se hace vinculando las tecnologías existentes con la plataforma J2EE a través de un wrapper El MO solicita los servicios meteorológicos utilizando servicio de Web. Con la verificación y los datos meteorológicos el MO realiza el cálculo de precios El MO publica los resultados a los participantes utilizando servicio de Web o JSP. Los datos históricos son almacenados por el MO en las bases de datos utilizando JDBC. La Figura 5 muestra la página de inicio al Sistema con las siguientes opciones: Figura 5: Página de Inicio al Simulador. Altas Generador: A través de una página Web se cargan los datos de cada uno de los Generadores participantes, donde se presenta una breve descripción del sistema, las opciones de registración y los permisos de acceso al sistema. Ingresar Ofertas: En esta opción el participante ya registrado en el punto anterior, realiza sus ofertas, en este caso se simuló el ejemplo numérico presentado anteriormente, es decir participan 5 generadores en 4 bandas horarias con 4 bloques de oferta cantidadprecio, es decir los datos ingresados al simulador coinciden con los datos de Tabla 2. La Figura 6 muestra la página donde se realizan las ofertas. Ingresar Demanda: En esta página se ingresan los datos de la demanda, en este caso se utilizó una demanda elástica cuyas características se muestran en Tabla 3 Ver Resultados: Luego de finalizado el plazo para realizar las ofertas, los participantes puedan consultar a través de esta página los resultados del remate como se muestra en la Figura 7 Ver Gráficos: Esta opción muestra los resultados del remate en forma gráfica.

7 El desarrollo del simulador permitió comprender que la utilización de Web Services, Aplicaciones Distribuidas, tecnología J2EE sirven para el desarrollo de grandes aplicaciones en muchas corporaciones; como así también cuáles son los puntos claves en los mercados eléctricos competitivos y cómo se puede utilizar las herramientas de software antes citadas para el estudio y análisis de los mismos utilizando simulación de procesos y análisis de oferta y demanda. VIII. REFERENCIAS Figura 6: Página donde se realizan las ofertas Toda esta información es transmitida y recibida hacia y desde el Server usando el protocolo HTTP y a través de JSPs, el servidor entonces pone la información correspondiente en la base de datos. Una vez que todas las ofertas han sido recibidas por el servidor, el simulador accede al programa de aplicación vía el protocolo SOAP, los cálculos son realizados y devueltos al servidor de aplicación y archivados en la base de datos. Estos datos pueden ser accedidos por los agentes. La figura x muestra la página de salida, donde se muestra el resultado del remate. [1] J. Casazza, Electric Power, Market Forces, and the Public Welfare, IEEE Power Engineering Review, Vol. 11, No. 11, 3-5, [2] George Coulouris, Jean Dollimore and Tim Kindberg, Sistemas Distribuidos: Conceptos y Diseño, Ed. Addison- Wesley, [3] [4] D. Moitre, L. Aromataris, L. Trentin, M. Toledo, Estimación del Precio Spot en Mercados Eléctricos Competitivos, Anales del XVIII Congreso Argentino de Control Automático. Buenos Aires, Argentina, [5] S. Harvey and W. Hogan, Market Power and Market Power Simulations, Harvard University press, July 16, [6] I. Otero-Novas, C. Meseguer, C. Batlle, J. Alba, A Simulation Model for a Competitive Generation Market'', IEEE Transactions on Power Systems, Vol. 15, No 1, February 2000, pp [7] F: Magnago, D. Moitre, F. Corteggiano Arquitectura de Software Aplicada a los Mercados Eléctricos Competitivos. X ERLAC 2003, Iguazú, Argentina, Mayo, 2003 [8] F. Corteggiano, R. Matteoda, D. Moitre, F. Magnago Software Architecture for Deregulated Electric Markets. Proceedings of the IEEE PES 2004 General Meeting, Denver, Colorado, June Figura 7: Resultado del remate VII. CONCLUSIONES En este trabajo se ha propuesto una nueva arquitectura de software aplicada a un simulador de mercado de potencia eléctrica. El simulador es una herramienta importante para evaluar el efecto de diferentes parámetros sobre la determinación del precio y el comportamiento del mercado. Las herramientas de programación utilizadas representan el estado del arte en arquitecturas de sistemas abiertos. Si bien el software se utilizó sobre una estructura de mercado eléctrico bilateral, su flexibilidad permite simular otros tipos de estructura de mercado.