PROYECTO SISTEMAS DE POTENCIA.

I SEMESTRE 2017

AGENTE AGREGADOR DE RESPUESTA DE LA DEMANDA

Condiciones generales:

Parte I.

El sistema elctrico para pruebas debe responder a un programa de Respuesta a La Demanda (RD)
por incentivo, constituyndose en un agregador de la demanda.

Una primera parte est compuesta por una aplicacin de software en la nube (aplicacin de Cloud
Computing), en donde se realizar una base de datos. Dicha base de datos recopilara informacin
sobre los usuarios, que ser organizada en primera instancia de la siguiente manera (Tabla 1).

Los usuarios de la plataforma que aloja la base de datos (MYSQL, PHP, POSTGRESS o similar) ingresan
datos de identificacin, datos sobre la topologa en que se encuentran (estos datos topolgicos son
ingresados por el administrador de la plataforma), los niveles de potencia con que cuentan y con
cuanta potencia desean (pueden) participar, adems de la(s) franja(s) horaria(s) cuando estn
dispuestos a participar dentro del programa de RD.

Para la notacin, a manera de ejemplo, se observa que el usuario N1, posee 450 kW de potencia
instalada que eventualmente puede llegar a consumir, y que el operador de red le ha dispuesto. De
estos 450 kW el usuario pacta que puede desconectar por completo sus 450 kW en la franja de da
tipo A correspondiente a las 00:00 hasta las 06:00; entretanto que puede desconectar un total de
200kW en la franja tipo D.
Como puede verse tambin, los usuarios pactan un mnimo de tiempo para el aviso de que va a
realizarse la desconexin del total de carga pactada previamente, y un nmero mximo de veces en
el da que se admite realizar dicha desconexin.

Operacin del agente integrador

La demanda para disminucin de energa es enviada por parte del operador de la red al agente
integrador de Recursos Energticos Distribuidos (DER). El agente de DER inicialmente configura la
oferta para dar respuesta al requerimiento, utilizando una matriz de despacho donde se tienen los
recursos disponibles de potencia de los usuarios por cada hora (dentro de la franja horaria), y su
tasa de participacin confiable. De igual forma se debe tener en cuenta el nmero mximo de veces
que los usuarios han pactado participar durante el da.

1. Se recibe el pedido de energa que el operador de la red requiere reducir de

manera global. El pedido de energa a reducir se organiza como un vector para cada
hora del da siguiente: =[1 , 2, , 24 ]
2. El agente integrador inicia la seleccin de recursos disponibles para cada hora,
revisando que usuarios tiene a disposicin por cada franja horaria A, B,C,D
3. Con los recursos de RD disponibles por franja y por usuario establece una matriz
de despacho para satisfacer los niveles de reduccin de energa solicitados para
cada hora.
4. Para la matriz se organizan primero los recursos de aquellos usuarios que han sido
estimados como los ms confiables en el momento de responder a un
requerimiento. Los usuarios se caracterizan por su tasa de participacin confiable.
Se estima cada da.
 5. La potencia gestionable de cada usuario se multiplica por su tasa de participacin
confiable, y se suma a la de los otros usuarios.

6. La suma de los productos de recurso energtico de cada usuario por su tasa de

participacin debe ser igual a la demanda hecha para cada hora particular. A manera de
ejemplo, se analizar un pedido para la franja horaria A:
El pedido de disminucin de potencia para cada hora para la franja A del da de maana es
el siguiente:
=[1 , 2 , 3 , 4 , 5 , 6 ]=[600, 650, 450, 500,650,150]

En la franja A estn habilitados para responder a un requerimiento las cargas de los

usuarios 1 = 450 kW (3), 2 =650 kW (2), 4 = 15 kW (2), 9 = 150 kW (3), 11 = 250 kW (1) ,
12 = 250 kW(4) con tasas de participacin confiable de 80%, 80% , 98%, 60%, 55%, 77%.
Nota en parntesis estn las veces del da que cada usuario puede desconectarse en esa
franja.
El vector de pedido de reduccin de energa para la franja A por parte del operador de la
red (pedido global de reduccin), y la matriz para la franja A se ven a continuacin:
En la parte derecha se observa la columna que contiene los valores de tasa de participacin
confiable de cada usuario. Estos ndices se evalan de forma estadstica y se tienen en cuenta luego
de una gran serie de ofertas que se han configurado a partir de la participacin de los usuarios con
sus recursos de RD. Para el trabajo a realizar se propone utilizar un aplicativo que genere datos
aleatorios como lo es el simulador de Montecarlo, o cualquier funcin de randomizacin estndar
de algn software como el MATLAB o Visual C++

Resultados obtenidos:

1 = 600=15*0.98+650*0.8+81.625*0.8 Operan e4, e2 y e1

2 = 650=15*0.98+650*0.8+144.125*0.8 Operan e4, e2 y e1
3 = 450=450*0.8+116.88*0.77 Operan e1 y e12 ! Fuera e4 y e2
4 = 500>250*0.77+150*0.6+250*0.55 = 420 OJO NO SE DESPACHA Operan
e12, e9 y e11
5 = 600=250*0.77+150*0.6+250*0.55 = 420 OJO NO SE DESPACHA Operan
e12, e9 y e11
6 = 150=194.805*0.77 Opera e12

Nota1: Los porcentajes de tasa de participacin efectiva se deben generar con una
funcin aleatoria randomizada (puede usarse un aplicativo de funcin de
Montecarlo)
Nota 2: La restriccin tcnica inicial est en el hecho de que para cada hora se debe
procurar configurar una oferta que sea igual a lo demandado.
Nota 3: Para el despacho del servicio el orden de prelacin ser el siguiente:
Primero se ve quienes estn disponibles por franja, luego los que tengan mejor
ndice de participacin confiable, y luego los que tienen mayor potencia
Nota 3: Existe una restriccin de nmero de veces por franja (por da) que un
usuario puede participar y debe tenerse en cuenta.
Nota 4: Existe la restriccin por flujo de potencia. Si se supera un mximo admisible
de potencia reactiva se conectan compensadores (FACTS); y de no mejorarse la
condicin, deber negarse el servicio en esa hora.

En la figura 1, se muestra el algoritmo de operacin para la gestin de los recursos

de RD y la interaccin entre el operador de red, el administrador del mecanismo de
RD y los usuarios en la plataforma web.

Figura 1. Algoritmo para despacho de oferta de reduccin de consumo para la

implementacin de RD.
Red de prueba

En la figura 2 se observa la red IEEE de 14 nodos propuesta como escenario de prueba.

Figura 2. Red IEEE de 14 nodos

La forma topolgica de la red de manera simple se ve en la figura 3.

Figura 3. Topologa de la red

En la topologa de la red se observa que existirn cargas gestionables y no gestionables. Como cargas
no-gestionables (NG) se tienen las marcadas con los nmeros 4, 8, 11, 12, 13 y 14.

Las cargas gestionables dentro del programa de respuesta de la demanda (Grd) sern las marcadas
con los nmeros 1, 2, 3, 5, 6, 7, 9, 10.

En la red conformada se contara con elementos disyuntores cuando se requiera entrar en rgimen
de desconexin total de las cargas (Desconexin completa del total de cargas que se encuentran
bajo el programa de RD) y con dispositivos de deslastre de carga, para aquello casos cuando la oferta
de una hora se configure de manera fraccionada.

LA PLATAFORMA DE SEGUIMIENTO AL SISTEMA

Para el proyecto de utilizacin de RD se plantea realizar una aplicacin de software en MATLAB,

LABVIEW, MACRO DE EXCEL, VISUAL C++. La aplicacin debe enviar informacin sobre el estado de
la red en cada momento de operacin haca una aplicacin de tipo CLOUD COMPUTING.

En la aplicacin de Cloud Computing se perfilaran dos tipos de usuarios: Un administrador que recibe
toda la informacin de estado de la red (usuarios que tiene, quienes participan, en que franja, con
cuanto potencia, cuantas veces, flujo de potencia actual en la red). De igual forma es a este usuario
administrador al que le llega la peticin de disminucin de potencia para cada hora del da de
maana. Al recibir la informacin del pedido el administrador busca de manera automtica en sus
listas de recursos la forma de configurar una oferta para responder al requerimiento hecho por el
operador de la red.

El proyecto debe contener la visualizacin a partir de un aplicativo de CLOUD COMPUTING, que se

apoya en APPS para telfonos mviles. En este caso el sistema enviar el estado de LEDS y
elementos de conmutacin de las cargas a una tarjeta de comunicacin de tipo ARDUINO, que luego
reenviar dicha informacin a un telfono celular, Tablet, PC o cualquier dispositivo mvil similar.

Parte III

Con el fin de lograr que la red permanezca en un balance de potencias activa y reactiva se solicita
realizar un anlisis de flujo de carga para cada ocasin que se desconectaran las cargas participantes
en el programa de RD. Si la potencia activa o la reactiva superan ciertos lmites mximos el sistema
de gestin del programa de RD debe conectar compensadores para lograr estabilizar los flujos o en
su defecto no permitir que se desconecten dichas cargas en esa hora particular.

OPCIONAL: se puede utilizar un medidor PQA para hacer el monitoreo de la red en todo momento
y que la conexin de los capacitores se realice en cualquier rgimen si se detecta un desbalance
entre potencia activa y reactiva considerado como no admisible. Como no admisible ser todo
balance que implique un Factor de potencia (coseno Fi 0.6).

ENTREGABLES
Para la entrega del proyecto final se tendr en cuenta no solo los ensambles funcionales, sino
tambin la documentacin respectiva correspondiente a:

Proyecto ensamblado en software de sistemas de potencia, enlazado con un software de

control y con visualizacin en el servicio web y/o en dispositivos ANDROID por transmisin
BLUETOOTH o similar.
Bitcora de ensamble. Descripcin pas a paso de las fases de trabajo desarrolladas, con los
respectivos clculos, diseos y simulaciones a las que haya habido lugar previo a la
implementacin de cada eslabn funcional.
Descripcin tcnica del proyecto implementado: dimensiones, materiales, parmetros
funcionales, protecciones, rangos de trabajo.
Manual de operacin: Modos de operacin manual y automatizadas, maniobras a realizar,
tiempos de operacin, escenarios de puesta en marcha, escenarios de falla, restricciones de
operacin entre otras condiciones.

Tiempo de ejecucin mximo: 12 semanas

Se considera la presentacin de avances cada dos semanas, el cronograma respectivo ser

concertado por alumnos y docentes.

Grupos de trabajo: Mximo 2 personas

CRONOGRAMA DE PRCTICAS Y ENTREGAS:

0. 02 DE marzo Avance I

1. 16 DE marzo Avance II

2. 30 de marzo Avance II
3. 06 de abril Avance IV

SEMANA SANTA

4. 20 de abril Avance V
5. 04 DE mayo Avance VI
6. 18 DE mayo Avance VII
7. 25 DE mayo ENTREGA FINAL y Presentacin de Documentacin

NOTA: Las entregas de cada parte pueden hacerse antes de las fechas estipuladas, de la misma
forma que la entrega final.