Formalizaci´on de una estrategia de protecci´on de microrredes dentro de una arquitectura de red Juan David Orozco ´Alvarez
Formalizaci´on de una estrategia de protecci´on de microrredes dentro de una arquitectura de red Juan David Orozco ´Alvarez Trabajo de grado presentado como requisito parcial para optar al t´tulo de Ingeniero Electricista Pereira, Julio de 2019
UNIVERSIDAD TECNOL´OGICA DE PEREIRA
Programa de Ingenier´ıa El´ectrica.
Formalizaci´on de una estrategia de protecci´on de microrredes dentro de una arquitectura de red c⃝Juan David Orozco ´Alvarez Director: Juan Jos´e Mora Fl´orez Codirector: Andr´es Ricardo Herrera Orozco Pereira, Julio de 2019 Programa de Ingenier´ıa El´ectrica. Universidad Tecnol´ogica de Pereira La Julita. Pereira(Colombia)
TEL: (+57)(6)3137122
www.utp.edu.co Versi´on web disponible en: http://recursosbiblioteca.utp.edu.co/tesisd/index.html i
Agradecimientos A mi madre Marina, a quien se le dificult´o en estos cinco a˜nos, recordar el programa que eleg´ı, sin embargo, siempre me entrega su amor incondicional; y a mi padre Juan de Dios, que nos mantiene alegres sin importar las circunstancias. A ellos, los pilares de mi vida y a quienes m´as amo, infinitas gracias.
A mis hermanos Esteban y Alexander por el apoyo y a quienes les deseo lo mejor en su vida.
A mis compa˜neros Camilo, Valentina, Daniela, Carlos y Alejandro por coincidir, por la uni´on y por las experiencias compartidas.
Y a mis maestros y amigos Juan Jos´e y Andr´es Ricardo por compartir su sabidur´ıa y ofrecer su acompa˜namiento durante todo este proceso.
ii
Tabla de Contenido
1
Introducci´on
1
1.1
Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Objetivos
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1
General
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.2
Especificos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Propuesta de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Aportes de la tesis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.5
Publicaciones relevantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.6
Descripci´on del contenido de la tesis . . . . . . . . . . . . . . . . . . . . . . .
5
2
Aspectos te´oricos b´asicos
6
2.1
Arquitectura de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Marco de referencia SGAM (Smart Grid Architecture Model) . . . . .
6
2.2
Control centralizado y descentralizado
. . . . . . . . . . . . . . . . . . . . .
8
2.2.1
Control centralizado
. . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2
Control descentralizado . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
Caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.1
Actor
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.2
Escenario
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.3
Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
Estrategia de protecci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4.1
Estrategia de protecci´on adaptiva . . . . . . . . . . . . . . . . . . . .
9
2.4.2
Estrategia de protecci´on basada en optimizaci´on . . . . . . . . . . . .
10
3
Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on 11
3.1
Etapa 1: An´alisis y selecci´on de la estrategia de protecci´on . . . . . . . . . .
11
3.1.1
Paso 1: An´alisis de la bibliograf´ıa de referencia . . . . . . . . . . . . .
12
3.1.2
Paso 2: Identificaci´on de caracter´ısticas generales de la estrategia de protecci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
iii
3.1.3
Paso 3: Selecci´on de la estrategia de protecci´on
. . . . . . . . . . . .
13
3.1.4
Paso 4. An´alisis del funcionamiento de la estrategia de protecci´on . .
13
3.2
Etapa 2: Descripci´on de la estrategia de protecci´on
. . . . . . . . . . . . . .
13
3.2.1
Paso 1: Describir de forma general el caso de uso
. . . . . . . . . . .
14
3.2.2
Paso 2: Realizar diagrama del caso de uso . . . . . . . . . . . . . . .
16
3.2.3
Paso 3: Especificar detalles t´ecnicos . . . . . . . . . . . . . . . . . . .
16
3.2.4
Paso 4: Analizar paso a paso el caso de uso
. . . . . . . . . . . . . .
17
3.2.5
Paso 5: Identificar la informaci´on que se intercambia
. . . . . . . . .
18
3.2.6
Paso 6: Definir los requisitos necesarios para hacer efectiva la comunicaci´on (opcional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.7
Paso 7: Definir t´erminos y definiciones comunes . . . . . . . . . . . .
19
3.3
Etapa 3: Desarrollo de la estrategia de protecci´on en una arquitectura de referencia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1
Paso 1: Desarrollo de la capa de componentes . . . . . . . . . . . . .
19
3.3.2
Paso 2: Desarrollo de la capa de negocios . . . . . . . . . . . . . . . .
19
3.3.3
Paso 3: Desarrollo de la capa de funci´on . . . . . . . . . . . . . . . .
19
3.3.4
Paso 4: Desarrollo de la capa de informaci´on . . . . . . . . . . . . . .
20
3.3.5
Paso 5: Desarrollo de la capa de comunicaci´on . . . . . . . . . . . . .
20
4
Desarrollo de la arquitectura de protecci´on
21
4.1
Etapa 1: An´alisis y selecci´on de la estrategia de protecci´on . . . . . . . . . .
21
4.2
Etapa 2: Descripci´on de la estrategia de protecci´on
. . . . . . . . . . . . . .
23
4.2.1
Paso 1: Describir de forma general el caso de uso
. . . . . . . . . . .
23
4.2.2
Paso 2: Realizar diagrama del caso de uso . . . . . . . . . . . . . . .
24
4.2.3
Paso 3: Especificar detalles t´ecnicos . . . . . . . . . . . . . . . . . . .
25
4.2.4
Paso 4: Analizar paso a paso el caso de uso
. . . . . . . . . . . . . .
28
4.2.5
Paso 5: Identificar la informaci´on que se intercambia
. . . . . . . . .
36
4.2.6
Paso 6: Definir los requisitos necesarios para hacer efectiva la comunicaci´on 37
4.3
Etapa 3: Desarrollo de la estrategia de protecci´on en una arquitectura de referencia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.3.1
Paso 1: Desarrollo de la capa de componentes . . . . . . . . . . . . .
38
4.3.2
Paso 2: Desarrollo de la capa de negocios . . . . . . . . . . . . . . . .
39
4.3.3
Paso 3: Desarrollo de la capa de funci´on . . . . . . . . . . . . . . . .
40
4.3.4
Paso 4: Desarrollo de la capa de informaci´on . . . . . . . . . . . . . .
42
4.3.5
Paso 5: Desarrollo de la capa de comunicaci´on . . . . . . . . . . . . .
42
5
Conclusiones y recomendaciones
44
5.1
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.2
Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
iv
Cap´ıtulo 1 Introducci´on En este cap´ıtulo se define el problema que motiva la investigaci´on, relacionado con la formalizaci´on de estrategias de protecci´on de microrredes en una arquitectura de red. Como consecuencia de lo anterior, tambi´en se presentan los objetivos planteados y adem´as se expone la metodolog´ıa propuesta para lograr la descripci´on de la estrategia seleccionada y su implementaci´on dentro la arquitectura de red. Finalmente, se presentan los aportes del trabajo y una descripci´on del contenido de este documento.
1.1
Planteamiento del problema En referencia a las estrategias de protecci´on de microrredes es necesario reconocer que los sistemas el´ectricos de potencia presentan condiciones de operaci´on que pueden considerarse como normales o anormales, siendo esta ´ultima condici´on una representaci´on de riesgo. Por lo general, con el fin de mantener el correcto funcionamiento del sistema y de los elementos que hacen posible el suministro de energ´ıa a la poblaci´on, se utilizan esquemas de protecci´on que contienen diversos dispositivos que se configuran de tal forma que cumplan funciones espec´ıficas dependiendo de su zona de influencia.
Con el incremento de la demanda de energ´ıa el´ectrica en Colombia, que para enero de 2018 creci´o 3.5 porciento con respecto al mismo mes del a˜no 2017 y a pesar de que se cuenta con una capacidad de generaci´on de aproximadamente 40 porciento por encima de la demanda del pa´ıs (Saavedra (2017)), (Rojas P´erez (2018)), por medio de la Ley 1715 de 2014 se busca promover el desarrollo y el uso de las fuentes de generaci´on de energ´ıa el´ectrica alternativas (Energ´ıa El´ectrica - Ministerio de Minas y Energ´ıa (n.d.)). Mediante esta ley se regula la integraci´on de dichas fuentes al Sistema Energ´etico Nacional que, en conjunto con la resoluci´on CREG 030 de 2018, define los lineamientos para que los usuarios que
Cap´ıtulo 1. Introducci´on
2
generen energ´ıa el´ectrica puedan comerciar. De esta forma, se establecer´an modificaciones sustanciales en la forma de operar y proteger a los sistemas de potencia (Ministerio de Minas y Energ´ıa (2018)).
Como consecuencia, se presentan algunas situaciones que se deben analizar desde el punto de vista de la protecci´on de los sistemas el´ectricos de potencia que consideran la denominada generaci´on distribuida (GD). En este tipo de sistemas recaen una serie de retos en cuanto a su protecci´on debido a que los dispositivos que cumplen esta tarea son dise˜nados para configuraciones radiales y flujos de carga unidireccionales. As´ı, con la instalaci´on de GD en la red existente, pasar´an a existir flujos bidireccionales y se presentar´a una p´erdida de la coordinaci´on de los dispositivos; lo que obliga a realizar reajustes al esquema de protecci´on. Para enfrentar los retos mencionados, surgen estrategias de protecci´on que buscan integrar en su esquema los efectos mencionados para actuar de manera efectiva. Estas estrategias, se pueden dividir en tres grupos: a) esquemas que usan estrategias de optimizaci´on, los cuales intentan mantener el sistema de protecci´on existente haciendo una coordinaci´on de los elementos involucrados para obtener un ´optimo en todos los posibles escenarios de conexi´on de la red utilizando diferentes m´etodos de optimizaci´on (Baghaee et al. (2018)),(Saleh et al. (2015)); b) t´ecnicas adaptivas, que buscan implementar dispositivos de protecci´on apoyados en medici´on de variables locales y toman decisiones para cambiar sus modos de operaci´on seg´un la conexi´on del sistema (Piesciorovsky & Schulz (2017)), (Muda & Jena (2017)); c) estrategias adaptivas basadas en comunicaciones las cuales, en su mayor´ıa, dejan la responsabilidad de monitoreo de la red a un mando centralizado (observador global) que determina los cambios que se deben realizar en el sistema para actuar de manera correcta ante contingencias (Hatziargyriou (2014)), (Laaksonen et al. (2014)), (Ma et al. (2017)), (Zhang et al. (2019)), (Microgrids & Sidhu (2012)), (Ustun & Khan (2015)), (Ustun et al. (2011)) y (Liu et al. (2017)). Mientras que algunas estrategias como (Zamani et al. (2013)) plantean protecciones con mandos descentralizados para la protecci´on del sistema. La inclusi´on de estas tecnolog´ıas de protecci´on basadas en comunicaciones incluye desaf´ıos en cuanto al desarrollo de las redes inteligentes debido a la interacci´on e intercambio de informaci´on permanente entre sus dispositivos (Briefs & Energy (n.d.)). Incluir este tipo de sistemas a los ya existentes hace que la red a lo largo de la cadena de generaci´on sea diversa y por lo tanto es dif´ıcil crear requisitos coherentes para cada una de las partes involucradas.
Por lo tanto, a trav´es del mandato UE M/490 que busca realizar un trabajo para las redes inteligentes se desarrolla por medio de organizaciones de estandarizaci´on, un marco www.utp.edu.co
Cap´ıtulo 1. Introducci´on
3
que permite trabajar y mejorar metodolog´ıas que respalden estos procesos (CEN et al.
(2014)).
Para integrar gradualmente estos sistemas se tienen en cuenta tanto requisitos administrativos como de operaci´on y las descripciones realizadas por medio de otras metodolog´ıas. Todo este procedimiento permitir´a identificar brechas, por ejemplo, en las leyes del lugar donde se busca realizar la formalizaci´on de la estrategia de protecci´on. La implementaci´on de una estrategia de protecci´on es realizada por medio de est´andares que determinan los pasos para describir estos sistemas y analizar los procedimientos que se realizan y los elementos que all´ı participan (CEN et al. (2014)). Para sintetizar, el enfoque principal de este documento ser´a describir detalladamente un esquema de protecci´on por medio del est´andar IEC 62559-2 y asignarlo al modelo de arquitectura para redes inteligentes
CEN-CENELEC-ETSI.
1.2
Objetivos
1.2.1
General Desarrollar una estrategia de protecci´on de microrredes dentro de una arquitectura de red identificando dispositivos, informaci´on intercambiada, requisitos operativos y regulaciones de importancia para su implementaci´on.
1.2.2
Especificos
a) Analizar y discutir el estado actual de los sistemas de protecci´on de microrredes.
b) Identificar y seleccionar estrategias de protecci´on basadas em sistemas de comunicaci´on.
c) Realizar una descripci´on de la estrategia seleccionada mediante el est´andar IEC 62559-2.
d) Asignar la descripci´on realizada en las capas de interoperabilidad de la arquitectura de
referencia para redes inteligentes.
e) Reportar el desarrollo de la arquitectura de referencia donde se evidencie el trabajo
realizado para elaborar este trabajo.
1.3
Propuesta de trabajo La propuesta de trabajo se enfoca en la descripci´on de cualquier estrategia de protecci´on de microrredes para implementarla sobre un marco de referencia que hace parte de una www.utp.edu.co
Cap´ıtulo 1. Introducci´on
4
arquitectura de red.
Inicialmente, se realiza un estudio bibliogr´afico sobre las estrategias de protecci´on de microrredes identificando las t´ecnicas que m´as se utilizan. Estas t´ecnicas por lo general son adaptivas que pueden usar o no comunicaci´on entre sus dispositivos o basadas en m´etodos de optimizaci´on.
Posteriormente, se utiliza el est´andar IEC 62559-2 como herramienta para la descripci´on de la estrategia seleccionada. Este est´andar presenta una gu´ıa para detallar casos de uso especificando sus propiedades y funcionalidades de los dispositivos que interact´uan. Por lo tanto, de la estrategia se extraer´an y se mostrar´an los actores que intervienen, la informaci´on que intercambian y los requisitos y regulaciones necesarias para su implementaci´on divididos en siete pasos.
Finalmente, la informaci´on obtenida por medio del est´andar permitir´a desarrollar las capas de interoperabilidad de la arquitectura de referencia para redes inteligentes del grupo de estandarizaci´on CEN-CENELEC-ETSI. All´ı se mostrar´an los actores que intervienen, la informaci´on intercambiada, protocolos de comunicaci´on, regulaciones y objetivos comerciales de la estrategia de protecci´on seleccionada.
1.4
Aportes de la tesis El principal aporte de este trabajo de grado es contribuir al entendimiento y comprensi´on de metodolog´ıas de estandarizaci´on de los procesos y sistemas, en este caso de microrredes el´ectricas. Gracias al nivel de detalle propuesto en las metodolog´ıas, ser´a posible determinar desde los dispositivos necesarios para lograr sistemas interoperables, hasta pol´ıticas que regulen la implementaci´on de las estrategias de protecci´on.
1.5
Publicaciones relevantes Actualmente se encuentra en curso la redacci´on de un art´ıculo que contiene los procedimientos y resultados del proyecto realizado.
Este ser´a enviado pr´oximamente a una revista de relevancia en el campo de la ingenier´ıa el´ectrica.
www.utp.edu.co
Cap´ıtulo 1. Introducci´on
5
1.6
Descripci´on del contenido de la tesis El documento cuenta con seis cap´ıtulos que se explicar´an en esta secci´on. En primer lugar, el cap´ıtulo introductorio relata la definici´on del problema, objetivos planteados, la propuesta de trabajo y los aportes de la tesis.
El segundo cap´ıtulo presenta los aspectos te´oricos ´utiles para comprender la metodolog´ıa y el desarrollo de la propuesta.
All´ı se hace ´enfasis en definir conceptos utilizados a lo largo de los cap´ıtulos 3 y 4 como arquitectura, marco SGAM, interoperabilidad, control centralizado y descentralizado, caso de uso y estrategias de protecci´on. El cap´ıtulo 3 contiene la metodolog´ıa propuesta para desarrollar la arquitectura de protecci´on donde se plantean tres pasos: an´alisis y selecci´on de la estrategia de protecci´on, descripci´on y desarrollo dentro de una arquitectura de referencia. Luego, en el cap´ıtulo 4 se aplica la metodolog´ıa y se muestra el trabajo realizado durante la selecci´on, descripci´on y desarrollo de la estrategia de protecci´on en las zonas y dominios del marco SGAM.
En el cap´ıtulo 5 se mencionan las conclusiones que se obtienen como consecuencia del trabajo realizado y se hacen algunas recomendaciones de utilidad para continuar con el trabajo realizado, referente a las tem´aticas que no fueron estudiadas en este documento. www.utp.edu.co
Cap´ıtulo 2 Aspectos te´oricos b´asicos Este cap´ıtulo muestra los conceptos b´asicos que se consideran importantes para comprender la metodolog´ıa y el desarrollo espec´ıfico que se presentan en los cap´ıtulos 3 y 4. Los detalles espec´ıficos se presentan en las referencias asociadas.
2.1
Arquitectura de referencia Seg´un (CEN et al. (2014)), una arquitectura de red es un conjunto de propiedades de un sistema que describe los elementos, las relaciones existentes y las t´ecnicas o principios en los que se basa su dise˜no. Est´a contenida dentro de un dominio espec´ıfico denotado por un marco de referencia.
2.1.1
Marco de referencia
SGAM
(Smart Grid Architecture Model) El marco de referencia ofrece las pautas para dise˜nar casos de uso de redes inteligentes representados desde el punto de vista de la interoperabilidad que servir´an para implementar elementos a la red el´ectrica (CEN et al. (2014)). Es un marco tridimensional compuesto por dominios, zonas y cinco capas de interoperabilidad:
negocio, funci´on, informaci´on, comunicaci´on y componentes, tal como se presenta en la figura 2.1.
2.1.1.1
Dominios Se define como un marco detallado de operaci´on acotado entre la cadena de generaci´on: generaci´on, transmisi´on, distribuci´on, DER y consumidores (CEN et al. (2014)).
Cap´ıtulo 2. Aspectos te´oricos b´asicos
7
Figura 2.1. Dominios y zonas del marco SGAM
2.1.1.2
Zonas Representan los niveles administrativos del sistema, divididos en seis partes: proceso, campo, estaci´on, operaci´on, empresa y mercado (CEN et al. (2014)).
2.1.1.3
Ubicaci´on de dispositivos en las zonas del marco SGAM Los dispositivos participantes en un sistema que interact´ua dentro del marco SGAM est´an ubicados en zonas espec´ıficas y deben cumplir lo presentado en la tabla 2.1.
2.1.1.4
Capas de interoperabilidad Es una propiedad que permite a diversos componentes o sistemas, trabajar juntos por un prop´osito espec´ıfico.
(IEC 60050 - International Electrotechnical Vocabulary - Welcome (n.d.)) Por su parte, (CEN et al. (2014)) define la interoperabilidad como a la capacidad de dos o m´as elementos para intercambiar informaci´on utilizada para una cooperaci´on correcta. www.utp.edu.co
Cap´ıtulo 2. Aspectos te´oricos b´asicos
8
Tabla 2.1. Ubicaci´on de dispositivos en zonas del marco SGAM.
2.2
Control centralizado y descentralizado
2.2.1
Control centralizado En un sistema de control centralizado la responsabilidad de tomar decisiones, maximizar u optimizar alg´un proceso recae en un operador de sistema central (Hatziargyriou (2014)). En (Quintanilla & Yarza (2010)) se define un sistema centralizado como un esquema en el que existe un elemento central y decide sobre los dispositivos de protecci´on realizando configuraciones para diferentes topolog´ıas de operaci´on.
2.2.2
Control descentralizado CEN et al. (2014)) define un sistema descentralizado como aquel en el que los participantes cambian permanentemente sus roles e interact´uan cooperativamente para generar informaci´on.
Por su parte (Quintanilla & Yarza (2010)) menciona que es un esquema de control que no requiere de un dispositivo central debido a que la inteligencia est´a repartida entre las www.utp.edu.co
Cap´ıtulo 2. Aspectos te´oricos b´asicos
9
protecciones que lo componen. De esta forma cada dispositivo es aut´onomo para realizar su ajuste dependiendo de la informaci´on que recibe.
2.3
Caso de uso Los autores (Enanv et al. (2010)) y (Gottschalk et al. (2017)) coinciden en que un caso de uso es una descripci´on de las acciones que realiza un sistema y produce un resultado observable. Por su parte (Ref 4) define un caso de uso como una especificaci´on de una serie de acciones que un sistema o cualquier otra entidad puede realizar interactuando con los actores presentes.
2.3.1
Actor Un actor es un elemento dentro del sistema que interact´ua y se comunica con otros elementos (Specification (2013)).
2.3.2
Escenario El escenario es una secuencia de interacciones o eventos causados por la actividad de un actor (Enanv et al. (2010)).
2.3.3
Evento Suceso que es desencadenado por la acci´on de un actor y que hace parte del desarrollo del escenario.
2.4
Estrategia de protecci´on Es un sistema responsable de proteger adecuadamente una microrred ante fallas que se presente (Shiles et al. (2018)). Las estrategias de protecci´on utilizan t´ecnicas que pueden ser: adaptivas, adaptivas que emplean comunicaci´on o basadas en optimizaci´on.
2.4.1
Estrategia de protecci´on adaptiva En este tipo de estrategia las protecciones monitorean las condiciones de la red para verificar que sus ajustes son los correctos para cada modo de operaci´on. En caso de que usen un sistema de comunicaciones, el control de la arquitectura puede ser centralizado o descentralizado (Quintanilla & Yarza (2010)).
www.utp.edu.co
Cap´ıtulo 2. Aspectos te´oricos b´asicos
10
2.4.2
Estrategia de protecci´on basada en optimizaci´on El enfoque de optimizaci´on utiliza un conjunto de posibles escenarios de falla para configurar los dispositivos de protecci´on ante todos los casos posibles de configuraci´on de red (Behnke et al. (2018)).
www.utp.edu.co
Cap´ıtulo 3 Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on Con base en la evoluci´on actual de las redes inteligentes se tiene en cuenta los requerimientos de las nuevas tecnolog´ıas para describir por completo su funcionamiento. Por lo tanto, para desarrollar un problema gen´erico de protecci´on de microrredes, descrito por medio del est´andar IEC 62559 y posteriormente la descripci´on del mismo en una arquitectura de referencia, requiere la elaboraci´on de una metodolog´ıa.
La figura 3.1 muestra la metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on de microrredes.
La metodolog´ıa propuesta en la figura 3.1 se divide en cuatro etapas que se presentan a continuaci´on:
3.1
Etapa 1: An´alisis y selecci´on de la estrategia de protecci´on En esta etapa se realiza una investigaci´on y an´alisis documental para seleccionar la estrategia de protecci´on que se describe dentro de la arquitectura de referencia. Esta etapa se divide en 4 pasos que se presentan a continuaci´on:
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
12
Figura 3.1. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on de microrredes
3.1.1
Paso 1: An´alisis de la bibliograf´ıa de referencia El tema de protecci´on de microrredes ha sido ampliamente tratado en varias referencias, tal como se muestra en el cap´ıtulo 1. A partir del an´alisis de la bibliograf´ıa citada, se debe seleccionar las t´ecnicas de protecci´on m´as relevantes y que tengan la mayor relaci´on posible al tema de investigaci´on. Esto se refiere a las t´ecnicas utilizadas para desarrollar las estrategias de protecci´on que por lo general son de optimizaci´on, adaptivas o basadas en comunicaciones.
3.1.2
Paso 2:
Identificaci´on de caracter´ısticas generales de la estrategia de protecci´on Filtrar la informaci´on m´as relevante para la investigaci´on requiere un an´alisis adicional sobre las caracter´ısticas generales de la estrategia de protecci´on de microrredes que se est´a investigando. Estas caracter´ısticas hacen referencia a las t´ecnicas y dispositivos de protecci´on en las que los autores fundamentan el funcionamiento de las estrategias. Por lo tanto, al identificar estas caracter´ısticas se encontrar´an similitudes entre los documentos analizados. www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
13
3.1.3
Paso 3: Selecci´on de la estrategia de protecci´on Con la informaci´on obtenida en los pasos 1 y 2 es posible seleccionar una estrategia de protecci´on que agrupe la mayor cantidad posible de caracter´ısticas identificadas. De esta forma, la estrategia seleccionada estar´a contenida en las t´ecnicas y dispositivos utilizados com´unmente.
3.1.4
Paso 4.
An´alisis del funcionamiento de la estrategia de protecci´on Un an´alisis del funcionamiento de la estrategia seleccionada permitir´a identificar los elementos que interact´uan e intercambian informaci´on para llevar a cabo las funcionalidades de la estrategia. Adem´as, servir´a como referencia para realizar una descripci´on detallada en la secci´on 3.2.
3.2
Etapa 2: Descripci´on de la estrategia de protecci´on Los pasos descritos hasta este punto entregan las herramientas necesarias para continuar con la etapa 2 de la metodolog´ıa propuesta, dividida en 4 pasos. Esta etapa se desarrolla siguiendo el est´andar IEC 62559-2 que plantea una gu´ıa para la descripci´on de sistemas que pretenden ser desarrollados dentro de una arquitectura de referencia. El est´andar plantea una plantilla de caso de uso est´andar que especifica detalladamente las acciones que realiza un sistema siguiendo los pasos que se muestran a continuaci´on:
- Describir de forma general el caso de uso.
- Realizar diagramas del caso de uso.
- Especificar detalles t´ecnicos.
- Analizar paso a paso el caso de uso.
- Identificar la informaci´on que se intercambia entre actores.
- Definir los requisitos necesarios para hacer efectiva la comunicaci´on (opcional).
- Definir t´erminos y definiciones comunes.
www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
14
El desarrollo de las secciones opcionales se deja en consideraci´on de quien va a describir el caso de uso, puesto que las funciones que caracterizan el sistema determinan la necesidad de que sean desarrolladas.
La plantilla del est´andar IEC 62559-2 recopila toda la informaci´on de estos pasos en tablas que se mostrar´an en el cap´ıtulo 4 de este documento.
3.2.1
Paso 1: Describir de forma general el caso de uso La ejecuci´on de este paso comprende siete secciones que recopilan datos generales del caso de uso, que son:
3.2.1.1
Nombre del caso de uso En esta secci´on se le entrega un ID al caso de uso y un nombre relacionado a las funciones que realiza. Tambi´en debe asign´arsele una ubicaci´on dentro de los dominios y zonas del marco
SGAM.
3.2.1.2
Administraci´on de versiones La administraci´on de versiones debe contener un n´umero en orden consecutivo de los cambios que se realizan en el caso de uso, adem´as de la fecha en que se realiza el cambio, el nombre de la(s) persona(s) que hace(n) el cambio y su estado actual que se especifica como: borrador, actualizaci´on o definitivo.
3.2.1.3
Alcance y objetivos del caso de uso Se plantean los objetivos propuestos que motivaron la descripci´on detallada del caso de uso de forma puntual, antecedidos de un titular breve. El alcance describe los objetivos planteados y los l´ımites que puede tener el caso de uso en un texto corto y preciso. La ´ultima parte de la tabla hace referencia a los casos de negocio relacionados y las restricciones o leyes que afecten la implementaci´on del caso.
3.2.1.4
Narrativa del caso de uso Esta secci´on describe el problema de dos formas: breve y completa. La descripci´on breve no debe contener m´as de diez l´ıneas y la descripci´on completa contiene m´as detalle desde el punto de vista de un usuario, donde se menciona c´omo sucede cada actividad dentro del funcionamiento. Las descripciones se realizan de forma que facilite su comprensi´on, incluso para personas ajenas al proyecto.
www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
15
3.2.1.5
Indicadores clave de rendimiento Los indicadores de rendimiento tienen relaci´on a los objetivos planteados y hacen referencia a los beneficios de implementar el caso de uso. Cada indicador debe tener un ID ´unico, un nombre, una descripci´on y el objetivo al cual est´a sujeto.
3.2.1.6
Condiciones del caso de uso Esta secci´on plantea la posibilidad de que existan un n´umero determinado de suposiciones sobre las condiciones o configuraciones del caso de uso, acompa˜nadas de un requisito que debe cumplirse para que los escenarios se completen con ´exito. Por lo general se relacionan directamente con los actores y los eventos del sistema. Cada suposici´on y requisito previo requerir´a una tabla para su descripci´on.
3.2.1.7
Informaci´on adicional sobre el caso de uso para clasificaci´on/mapeo La informaci´on adicional restante se recopila en este paso e incluye: Relaci´on con otros casos de uso: En caso de que existan desarrollos similares en la tem´atica de protecci´on de microrredes, la relaci´on con los otros casos de uso se especifica con tres posibles enlaces:
Incluido: Se refiere a que el caso de uso que se est´a desarrollando est´a contenido dentro de otro caso de uso con l´ımites m´as amplios.
Extendido: Hace referencia a una descripci´on m´as detallada de otro caso de uso que ya ha sido reportado.
Asociado: El caso de uso puede unirse a otro para conformar un caso de uso m´as grande. Nivel de profundidad: Refleja el grado de especializaci´on del caso de uso que por lo general son: alto nivel, gen´erico, detallado o especializado. Priorizaci´on: El caso de uso debe calificarse desde muy importante hasta obligatorio u opcional. Esto es acordado por las personas que realizan la descripci´on. Relaci´on gen´erica, regional o nacional:
La aplicaci´on del caso de uso debe especificarse en caso de que pueda realizarse en cualquier parte o en sitios espec´ıficos. www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
16
Naturaleza del caso de uso: Describe el campo de atenci´on del caso de uso como t´ecnico, pol´ıtico, negocio, mercado, prueba, etc.
Otras palabras clave para la clasificaci´on: Palabras o frases con las que tambi´en se puede relacionar el caso de uso.
3.2.1.8
Observaciones generales Las observaciones que sean necesarias mencionar y que no encajan en otra categor´ıa de la descripci´on de la secci´on 3.2.1 se insertan aqu´ı separadas por vi˜netas.
3.2.2
Paso 2: Realizar diagrama del caso de uso El diagrama del caso de uso debe contener los actores y escenarios existentes y especifica su interacci´on por medio de l´ıneas de conexi´on. Los actores mostrados en el diagrama deben coincidir con elementos clasificados en la secci´on 3.2.3.1 y los escenarios se ajustan a lo desarrollado en 3.2.4.1. Cualquier tipo de dibujo que represente estos elementos del sistema es permitido.
3.2.3
Paso 3: Especificar detalles t´ecnicos Los detalles t´ecnicos incluyen dos categor´ıas tabuladas, que definen los actores y especifican las referencias bibliogr´aficas consultadas para el desarrollo del caso de uso, as´ı:
3.2.3.1
Actores Los actores se pueden clasificar en grupos seg´un sus propiedades, con tantos grupos como se considere necesario. La tabla contiene el nombre del grupo, una definici´on o descripci´on, una lista de los actores que est´an incluidos, el tipo de actor (persona, sistema, base de datos, organizaci´on o dispositivo) y una corta descripci´on. Si se tienen datos adicionales que no puedan ser colocados en la descripci´on, se a˜naden en la informaci´on espec´ıfica del caso de uso. Cada agrupamiento requiere la construcci´on de una tabla.
3.2.3.2
Referencias En esta tabla se enumeran las referencias consultadas y de utilidad en el caso de uso incluyendo las que fueron consultadas en la secci´on 3.1. La informaci´on requiere un nombre, el tipo de referencia (art´ıculo, sitio web, etc.), referencia, estado (inicial, final, volumen, etc.), www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
17
se especifica el impacto de la referencia en el caso de uso (bajo, medio alto), autores de la referencia y un link de ser necesario.
3.2.4
Paso 4: Analizar paso a paso el caso de uso El an´alisis paso a paso del caso de uso ayudar´a a describir con detalle las actividades que se presentan especificando actores, eventos y escenarios. Esta parte es una asociaci´on a la narrativa realizada en la secci´on 3.2.1.4 y debe tener una relaci´on directa con el diagrama del caso de uso desarrollado en la secci´on 3.2.2. Cada paso describe una comunicaci´on o actividad entre los actores listados en la secci´on 3.2.3.1. El an´alisis est´a dividido en dos partes, como se muestra a continuaci´on:
3.2.4.1
Resumen de escenarios En esta secci´on se tabulan los escenarios que existen dentro del caso de uso en orden de ejecuci´on.
Generalmente se enumeran primero los escenarios normales, es decir, aquellos que no representan una falla.
La tabla contiene la numeraci´on en orden ascendente, nombre, descripci´on completa y el actor que hace que el escenario se ejecute, el evento que desencadena, la condici´on previa para que el actor ejecute su actividad y el evento posterior que da paso a las dem´as actividades que componen el escenario.
3.2.4.2
Pasos-escenarios En esta secci´on es necesario introducir el nombre del escenario que se va a describir, numerar el orden de ejecuci´on de las actividades, el evento y por ´ultimo el nombre y una descripci´on del proceso que se est´a llevando a cabo. El evento siguiente es activado por el que acaba de terminar y cada uno de ellos se describe de la misma forma hasta que el escenario cumpla su funci´on y pueda volver a iniciarse. El procedimiento se realiza para cada escenario existente en el caso de uso.
La segunda parte de la tabla caracteriza el tipo de se˜nal producida por un actor, se especifica el actor que produce la informaci´on, el que recibe esta informaci´on, la informaci´on intercambiada entre actores presentada en la secci´on 3.2.5 y algunos requisitos establecidos que se mostrar´an en la secci´on 3.2.6. El tipo de se˜nal que un actor produce puede clasificarse as´ı:
Obtener (predeterminado):
El actor receptor obtiene una informaci´on despu´es de solicitarla al productor.
www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
18
Crear: El actor productor crea un elemento de informaci´on y lo env´ıa al receptor. Cambiar: El actor productor actualiza la informaci´on contenida el receptor. Borrar: El productor de informaci´on borra la informaci´on del receptor. Cancelar / cerrar: Un proceso ha terminado.
Ejecutar: Una acci´on o servicio es realizada.
Informar: El actor que produce la informaci´on entrega informaci´on de datos almacenados. Temporizar: Si un actor hace las veces de productor y receptor debe tener un tiempo de espera.
Repetir: Se realizan acciones de intercambio hasta satisfacer una condici´on definida en alg´un evento.
El productor y el receptor de la informaci´on son los actores de la secci´on 3.2.3.1.
3.2.5
Paso 5: Identificar la informaci´on que se intercambia Esta secci´on hace referencia a la informaci´on intercambiada entre actores, proporcion´andoles una caracter´ıstica particular de la informaci´on (enviar, almacenar, informar, actualizar, etc.). Adicionalmente, la tabla debe contener un ID espec´ıfico, una breve descripci´on y requisitos (de ser necesario) de la informaci´on intercambiada mostrados en la secci´on 3.2.6 para que el proceso se cumpla.
3.2.6
Paso 6: Definir los requisitos necesarios para hacer efectiva la comunicaci´on (opcional) Generalmente estos requisitos pretenden proteger, almacenar o cifrar correctamente los datos que se manejan dentro del caso de uso. Se clasifican en categor´ıas asign´andoles un ID, un nombre ´unico y una breve descripci´on. Luego, a cada requisito se le asigna un ID que se relaciona con el ID de su categor´ıa y posteriormente adquieren un nombre y una descripci´on. www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
19
3.2.7
Paso 7: Definir t´erminos y definiciones comunes Contiene t´erminos y definiciones comunes que se han utilizado a lo largo de la descripci´on del caso de uso, organizados en un glosario.
3.3
Etapa 3: Desarrollo de la estrategia de protecci´on en una arquitectura de referencia La etapa 3 de la metodolog´ıa propuesta muestra c´omo asignar un caso de uso al marco de referencia SGAM desarrollado en (CEN et al. (2014)). Es importante reconocer en qu´e dominios y zonas del marco realiza sus funciones para desarrollar correctamente las capas. Estas capas son una representaci´on dentro del marco SGAM que buscan que el sistema sea interoperable.
El desarrollo de la estrategia de protecci´on en la arquitectura est´a compuesto por cinco pasos que se muestran a continuaci´on:
3.3.1
Paso 1: Desarrollo de la capa de componentes El desarrollo de esta capa se deriva del diagrama del caso de uso realizado en la secci´on 3.2.2 que muestra los actores y escenarios de la estrategia de protecci´on. Debido a que el diagrama del caso de uso es un dibujo libre, los actores se deben llevar a una representaci´on t´ecnica que muestre la comunicaci´on existente entre ellos. Tanto los actores como los escenarios se ubican en los dominios y zonas apropiados y ser´a la base para desarrollar las cuatro capas siguientes.
3.3.2
Paso 2: Desarrollo de la capa de negocios Aqu´ı se mencionan los objetivos comerciales y las restricciones econ´omicas y regulatorias del caso de uso. Esta informaci´on est´a definida en los alcances y objetivos de la secci´on 3.2.1.3. Las restricciones y limitaciones mencionadas deben tenerse en cuenta como requisitos funcionales para su implementaci´on.
3.3.3
Paso 3: Desarrollo de la capa de funci´on La capa de funci´on est´a dise˜nada para representar las actividades de los actores dentro de los escenarios, ubic´andolos en los dominios y zonas adecuados. La relaci´on entre actores y escenarios se deriva de la segunda parte de la tabla referente a los pasos-escenarios www.utp.edu.co
Cap´ıtulo 3. Metodolog´ıa propuesta para el desarrollo de la arquitectura de protecci´on
20
desarrollados en la secci´on 3.2.4.2.
Una vez ubicados, se representa mediante l´ıneas de conexi´on los actores que intervienen en el desarrollo de los escenarios.
3.3.4
Paso 4: Desarrollo de la capa de informaci´on Esta capa representa la informaci´on que se utiliza y se intercambia entre los actores del caso de uso, contenida en la secci´on 3.2.5. Esta informaci´on debe mostrarse de forma escrita sobre las flechas que representan la comunicaci´on.
3.3.5
Paso 5: Desarrollo de la capa de comunicaci´on Su ´enfasis es describir los protocolos que se utilizan para el intercambio de la informaci´on entre los actores del caso de uso. Deben ilustrarse mencionando el est´andar que describe los protocolos que hacen efectiva la comunicaci´on.
www.utp.edu.co
Cap´ıtulo 4 Desarrollo de la arquitectura de protecci´on En este cap´ıtulo ejecuta la descripci´on de una estrategia de protecci´on de microrredes dentro de una arquitectura de referencia siguiendo la metodolog´ıa mencionada en el cap´ıtulo 3. Las etapas que ser´an presentadas a continuaci´on mostrar´an la selecci´on de la estrategia de protecci´on, su descripci´on por medio de la metodolog´ıa IEC 62559-2 y finalmente el desarrollo de las capas de interoperabilidad dentro del marco SGAM.
4.1
Etapa 1: An´alisis y selecci´on de la estrategia de protecci´on A partir de la metodolog´ıa propuesta en el cap´ıtulo 3, en este cap´ıtulo se presenta la selecci´on de una estrategia de protecci´on que agrupe las caracter´ısticas descritas en las etapas de la secci´on 3.1. La t´ecnica seleccionada cuenta con protecciones adaptivas, basada en comunicaciones y con mandos centralizados. La estrategia presentada en (Hatziargyriou (2014)) describe un sistema adaptivo basado en ajustes calculados en tiempo real que se ilustra en la figura 4.1 El sistema de protecci´on cuenta con dos bloques: bloque en tiempo real y bloque en tiempo no real. El bloque en tiempo real permite el an´alisis del estado actual de la microrred a partir de mediciones peri´odicas entregadas por medidores inteligentes. Estas mediciones son comparadas con las condiciones predefinidas de la red por un rel´e multifuncional que act´ua como protecci´on centralizada.
Este rel´e detecta las perturbaciones mediante las caracter´ısticas de disparo ajustadas en los dispositivos de protecci´on y, cuando se detecta una condici´on de falla, env´ıa una se˜nal de disparo a los interruptores de la zona afectada.
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
22
Cuando ocurre una falla, el rel´e multifuncional se comporta como un rel´e convencional que tiene control sobre varios interruptores autom´aticos, pero limita su aplicaci´on a una zona espec´ıfica de la red.
Figura 4.1.
Diagrama de flujo del esquema de protecci´on seleccionado.
Tomado de (Hatziargyriou (2014)) www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
23
El bloque en tiempo no real utiliza los datos de predicci´on de disponibilidad de las fuentes de generaci´on distribuida (DER) a trav´es de un sistema de gesti´on de energ´ıa (EMS), el cual almacena la informaci´on en una base de datos (DB). Esta informaci´on se utiliza para conectar o desconectar DER que pueden generan un cambio en la topolog´ıa de la microrred, por lo tanto, es necesario realizar un control de selectividad. Este control es efectuado por el rel´e para verificar que las condiciones l´ımite predefinidas por el sistema no sean sobrepasadas cuando se presenta un cambio de topolog´ıa. La funci´on del rel´e multifuncional, en este caso, es adaptar las funciones de protecci´on para la nueva topolog´ıa de red y s´ı las condiciones l´ımites del sistema no se superan, entonces se acepta la nueva topolog´ıa. Cuando el cambio se realiza, la base de datos informa mediante sus servidores la informaci´on de los par´ametros de inter´es al rel´e multifuncional con los cuales se reajustan las protecciones donde sea necesario. Si no existe una forma de adaptar las protecciones sin violar las condiciones l´ımite, el rel´e env´ıa una se˜nal que proh´ıbe la acci´on prevista por el EMS. De manera similar se realiza el cambio de topolog´ıa cuando la red est´a conectada y entrar´a en operaci´on en modo isla, aqu´ı, la base de datos provee al rel´e las contribuciones de corrientes de cortocircuito cuando ocurre el cambio. Por lo tanto, el rel´e supervisa continuamente la disponibilidad de las DER y de la red principal para realizar el procedimiento cuando corresponda. Todo el proceso de adaptaci´on realizado por el rel´e y dem´as elementos que contribuyen en la actividad, est´a limitado por la probabilidad de que ocurra una falla durante el an´alisis, por lo tanto, el cambio debe tardar pocos segundos.
4.2
Etapa 2: Descripci´on de la estrategia de protecci´on Siguiendo la plantilla propuesta en el est´andar IEC 62559-2 desarrollada en la secci´on 3.2, se realiza la descripci´on detallada del caso de uso.
A continuaci´on, se muestran las tablas correspondientes al desarrollo del caso de uso llamado “Estrategia de protecci´on de microrredes basado en sistemas de comunicaci´on”. Estas tablas muestran los resultados que tienen m´as relevancia en el desarrollo de la arquitectura; por lo tanto, algunos elementos de la descripci´on detallada podr´an encontrarse en los anexos de este documento.
4.2.1
Paso 1: Describir de forma general el caso de uso En la secci´on 3.2 se definen los alcances, objetivos, los casos de negocio relacionados y las restricciones existentes para la implementaci´on de la estrategia de protecci´on mostrados en la tabla 4.1. El resto de los pasos que se desarrollan en esa secci´on estar´an ubicados en la secci´on A.1 de los anexos.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
24
Tabla 4.1. Alcance y objetivos del caso de uso
4.2.2
Paso 2: Realizar diagrama del caso de uso A partir de los actores y escenarios identificados en la descripci´on se realiza el diagrama de la estrategia de protecci´on que se ilustra en la figura 4.2. www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
25
Figura 4.2. Diagrama del caso de uso
4.2.3
Paso 3: Especificar detalles t´ecnicos Los actores fueron clasificados en cuatro grupos: medidores, sensores, actuadores y otros actores. Estas clasificaciones se mostrar´an de la tabla 4.2 a la 4.5, respectivamente. www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
26
Tabla 4.2. Actores: agrupaci´on de medidores Tabla 4.3. Actores: agrupaci´on de sensores Los grupos de medidores y sensores tienen un solo elemento dentro de su composici´on www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
27
debido a que son sistemas que est´an compuestos por varios dispositivos en la microrred. Tabla 4.4. Actores: agrupaci´on de actuadores Las referencias de utilidad para el desarrollo de la descripci´on de la estrategia de protecci´on estar´an tabuladas en la secci´on A.1 de los anexos. www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
28
Tabla 4.5. Actores: agrupaci´on de otros actores
4.2.4
Paso 4: Analizar paso a paso el caso de uso Una vez definidos los actores, se describen los escenarios de la estrategia de protecci´on de microrredes basada en sistemas de comunicaci´on. De la estrategia estudiada se enumeran dos escenarios posibles: cambio de topolog´ıa de la red y falla. Para el escenario de cambio de topolog´ıa el actor primario es el EMS debido a que en el momento en que recibe los datos de predicci´on de las DER, se inicia el proceso de cambio de topolog´ıa.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
29
Tabla 4.6. Visi´on general de escenarios: cambio de topolog´ıa de la red Por su parte el escenario de falla inicia la ejecuci´on del procedimiento cuando los transformadores de corriente y de potencial env´ıan una se˜nal, que inicia un an´alisis de verificaci´on si los datos se traducen en una falla.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
30
Tabla 4.7. Visi´on general de escenarios: falla Los escenarios se analizan son detallados a partir de la acci´on de un actor principal que desencadena una serie de eventos para cumplir el escenario totalmente. Para el escenario de cambio de topolog´ıa de la red se tienen nueve pasos, mientras que en el escenario de falla se identifican cinco eventos. Estos pasos se presentan en las tablas 4.8 y 4.9 para el cambio de topolog´ıa y en la tabla 4.10 para falla.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
31
Tabla 4.8. Pasos-escenarios: cambio de topolog´ıa de la red www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
32
Tabla 4.9. Pasos-escenarios: cambio de topolog´ıa de la red (continuaci´on) www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
33
Tabla 4.10. Pasos-escenarios: falla La segunda parte de las tablas, muestran el tipo de se˜nal que producen los actores para ambos escenarios y son de utilidad para identificar los elementos que est´an haciendo el www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
34
intercambio de informaci´on en cada evento. Por su parte, los requisitos que hacen parte de la ´ultima columna de la tabla son extra´ıdos de acuerdo con lo desarrollado en la secci´on
4.2.6.
Tabla 4.11. Pasos-escenarios: falla (segunda parte) Las tablas presentadas muestran el tipo de se˜nal enviada, especificando el actor que produce la informaci´on y el actor que la recibe. Estas tablas tendr´an la misma cantidad de pasos que se muestran en la primera parte.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
35
Tabla 4.12. Pasos-escenarios: cambio de topolog´ıa de la red (segunda parte) www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
36
4.2.5
Paso 5: Identificar la informaci´on que se intercambia Al tener claros los actores que interact´uan en cada evento del escenario, se caracteriza la informaci´on que intercambian en el paso siguiente. Dentro de la estrategia de protecci´on se realizan acciones como monitoreo de la red, comparaci´on y almacenamiento de datos, entre otras. Los requisitos para el intercambio de informaci´on tienen que ver con la protecci´on de datos y los tiempos de operaci´on para evitar que se presenten fallas durante los cambios de topolog´ıa. La informaci´on intercambiada es v´alida para ambos escenarios. Tabla 4.13. Informaci´on intercambiada www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
37
4.2.6
Paso 6: Definir los requisitos necesarios para hacer efectiva la comunicaci´on Los requisitos se definieron siguiendo las descripciones de la estrategia de protecci´on. Por ejemplo, se menciona que los tiempos de operaci´on cuando se est´a haciendo un cambio de topolog´ıa debe ser el m´ınimo posible para disminuir la posibilidad de que una falla ocurra mientras se conectan o desconectan fuentes de la microrred. Esa restricci´on da origen a una categor´ıa llamada tiempos de operaci´on (Ti-Op), que agrupa otros requisitos que tienen que ver con tiempos de operaci´on del sistema. Por otro lado, hay otra categor´ıa denominada protecci´on de datos (Pr-Da) que tiene que ver con la comunicaci´on y la seguridad de los datos que se almacenan para evitar el acceso de terceros. Estos requisitos ser´an mostrados en las tablas 4.14 y 4.15 respectivamente.
Tabla 4.14. Requisitos: tiempos de operaci´on.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
38
Tabla 4.15. Requisitos: protecci´on de datos. La tabla correspondiente a los t´erminos y definiciones comunes de la secci´on 3.2.7 estar´a incluida en la secci´on A.1 de los anexos.
4.3
Etapa 3: Desarrollo de la estrategia de protecci´on en una arquitectura de referencia
4.3.1
Paso 1: Desarrollo de la capa de componentes A partir del diagrama de la figura 4.2 y las tablas desde la 4.2 hasta la 4.7, donde se identifican actores y escenarios de la estrategia de protecci´on, se desarrolla la capa de componentes que se muestra en la figura 4.3. En esta capa se ilustran los actores y su ubicaci´on se realiza de acuerdo con lo definido en el cap´ıtulo 2. www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
39
Figura 4.3. Capa de componentes
4.3.2
Paso 2: Desarrollo de la capa de negocios Para la capa de negocios se utilizan los datos de la tabla 4.1 que menciona los casos de negocio relacionados y las restricciones posibles para implementar la estrategia de protecci´on. Los casos de negocio que permite la estrategia son: mejoramiento de los ´ındices de continuidad del suministro de energ´ıa, control de estabilidad, operaci´on y protecci´on de la microrred. Mientras que las regulaciones tendr´an relaci´on con las leyes nacionales o locales donde se vaya a implementar.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
40
Figura 4.4. Capa de negocios
4.3.3
Paso 3: Desarrollo de la capa de funci´on Para el desarrollo de la capa de funci´on se incluyen los escenarios de cambio de topolog´ıa y de falla, en los dominios y zonas donde tengan mayor interacci´on de los actores. Las l´ıneas rojas indican el intercambio de informaci´on de los actores que los afectan. Las tablas desde la 4.11 y 4.12 contienen la descripci´on necesaria sobre los actores que est´an intercambiando informaci´on para llevar a cabo los procesos de los escenarios de falla y cambio de topolog´ıa, respectivamente. Esta capa se ilustrar´a en la figura 4.5.
www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
41
Figura 4.5. Capa de funci´on www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
42
4.3.4
Paso 4: Desarrollo de la capa de informaci´on La tabla 4.13 entrega la informaci´on que se intercambia, como se presenta en la figura 4.6. Figura 4.6. Capa de informaci´on
4.3.5
Paso 5: Desarrollo de la capa de comunicaci´on En la estrategia de protecci´on descrita los protocolos de comunicaci´on no son tratados en detalle puesto que no est´a dentro del alcance de este trabajo, sin embargo, se menciona el www.utp.edu.co
Cap´ıtulo 4. Desarrollo de la arquitectura de protecci´on
43
est´andar IEC 61850 necesario para la comunicaci´on en tiempo real entre los elementos de medida y el rel´e multifuncional. Debido a esto, ser´a el ´unico protocolo descrito en la capa de comunicaci´on que ser´a mostrada en la figura 4.7. Figura 4.7. Capa de comunicaci´on www.utp.edu.co
Cap´ıtulo 5 Conclusiones y recomendaciones
5.1
Conclusiones La investigaci´on sobre estrategias de protecci´on de microrredes basadas en comunicaciones permite identificar que los sistemas que hacen uso de medios de comunicaci´on est´an basados en t´ecnicas adaptivas, es decir, utilizan dispositivos de protecci´on capaces de cambiar sus ajustes e intercambiar informaci´on entre ellos para proteger la red ante fallas. El uso de este tipo de esquemas presenta ventajas en cuanto a la rapidez para actuar ante contingencias, pero tiene desventajas en cuanto a la inversi´on, comparada con la de un sistema de protecci´on convencional.
Las estrategias adaptivas basadas en comunicaci´on pueden tener mandos centralizados o descentralizados, siendo m´as com´un el primero debido a que existen m´as protocolos de comunicaciones que lo soportan en comparaci´on a un mando descentralizado. Sin embargo, los sistemas descentralizados presentan ventajas en cuanto a fallas que se puedan presentar en uno o varios de sus dispositivos. En caso que ocurra una contingencia de este tipo, el sistema descentralizado no se afecta en la toma de decisiones, mientras que, en el mando centralizado, un problema en el elemento principal producir´a falla completa en el esquema de protecci´on.
En cuanto a la inversi´on para cada mando es relativo, por ejemplo, para el control centralizado existe un alto costo de inversi´on en el elemento principal pero los dem´as elementos pueden ser m´as sencillos. Por su parte los esquemas descentralizados necesitan dispositivos capaces de intercambiar y analizar la informaci´on, que se traducir´a en una gran inversi´on para todo el esquema. Por lo tanto, el uso de una estrategia de protecci´on de este tipo debe ser analizada desde el punto de vista de las ventajas operativas que ofrece y el
Cap´ıtulo 5. Conclusiones y recomendaciones
45
costo de inversi´on.
El uso del est´andar IEC 62559-2, el cual define una metodolog´ıa para describir un sistema y los elementos que lo componen, es ´util para definir y analizar el funcionamiento de cualquier estrategia de protecci´on de microrredes. Seguir la plantilla que propone el est´andar permite reconocer dispositivos, eventos y escenarios que son de utilidad para desarrollar la arquitectura de referencia, la cual requiere la especificaci´on de estos elementos. Al ser identificados, es posible definir la informaci´on que intercambian y algunos requisitos que dependen del funcionamiento del esquema de protecci´on para su implementaci´on. Describir una estrategia de protecci´on de microrredes requiere representar de forma precisa los actores que intervienen debido a que deben ubicarse en lugares espec´ıficos en los dominios y zonas del marco SGAM. Este marco que incluye los elementos de la cadena de generaci´on agregando el dominio de la generaci´on distribuida, permite estandarizar los procesos que all´ı se describen, haciendo interoperable un proceso y, por lo tanto, m´as controlable por los operadores. Al a˜nadir el dominio de las fuentes de generaci´on distribuida, la metodolog´ıa SGAM ampl´ıa su uso para redes inteligentes y procesos que incluyan este tipo de generaci´on en su funcionamiento.
A pesar de que el esquema de protecci´on descrito se desarrolla en dos dominios del marco SGAM: distribuci´on y DER; es posible establecer comunicaci´on con un proceso diferente que se encuentre en los mismos o diferentes dominios. El objetivo de la interoperabilidad, especificado en el est´andar estudiado, es establecer comunicaci´on a niveles tanto operativos como administrativos, por lo tanto, si se requiere comunicar un sistema con otro, es posible siempre y cuando se sigan protocolos adecuados para establecer el intercambio de informaci´on. Tambi´en es evidente la flexibilidad de la arquitectura de referencia en cuanto las nuevas funciones que se pueden agregar dentro del marco. Es decir, de igual forma como se incluy´o un nuevo dominio para permitir su funcionamiento sin afectar su descripci´on, es posible adicionar nuevos elementos. La literatura consultada demuestra que el marco SGAM ha evolucionado para aumentar los dominios que lo componen como:
veh´ıculos el´ectricos, arquitectura marina o la industria.
Finalmente, conocer e iniciar la investigaci´on sobre estas herramientas y sus utilidades abren un panorama sobre las restricciones y est´andares a tener en cuenta para implementar sistemas que emplean nuevas tecnolog´ıas. La arquitectura de referencia por medio de los pasos descritos en este trabajo pretende encontrar brechas o factores que impidan desarrollar completamente un sistema dentro de su arquitectura. No ser´a suficiente plantear un esquema www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
46
de protecci´on o cualquier otro esquema en alguno de los dominios, sin tener en cuenta las limitaciones, requisitos, protocolos o leyes nacionales que impidan su implementaci´on.
5.2
Recomendaciones Como se evidenci´o en el desarrollo de la arquitectura mostrada en el cap´ıtulo 4, los protocolos de comunicaci´on no hicieron parte del enfoque de este trabajo y, como consecuencia de ello, no fue posible realizar la descripci´on total de la capa de comunicaci´on mostrada en la secci´on
4.3.5. Por lo tanto, se recomienda como trabajo futuro que las investigaciones realizadas
sobre sistemas que involucren intercambio de informaci´on se extiendan hasta los est´andares que definen los protocolos necesarios para hacer efectiva la comunicaci´on. Adicionalmente en la bibliograf´ıa donde se estudian las aplicaciones de la arquitectura de red se manifiesta la posibilidad de expandir los dominios del marco SGAM. Estas expansiones se relacionan con las descripciones de funcionalidades de una ciudad inteligente, la inclusi´on de veh´ıculos el´ectricos, industria y arquitectura marina. Dichas expansiones pueden ser incluidas como nuevos dominios dentro del marco, demostrando la flexibilidad de la arquitectura. Por lo tanto, la profundizaci´on en estos nuevos campos pueden ser de inter´es para futuras investigaciones.
www.utp.edu.co
Anexos Algunas de las partes del desarrollo de la arquitectura propuesta, que no se presentan en el cap´ıtulo 4, debido a que no influyen para comprender lo realizado, se muestran en este documento de anexos. Estas partes son importantes para la descripci´on de la estrategia de protecci´on, y se presentan en orden de ejecuci´on en estos anexos. A.1. Describir de forma general el caso de uso.
Esta parte de la metodolog´ıa, desarrollada en la secci´on 4.2.1, presenta el nombre del caso de uso, administraci´on de versiones, narrativa del caso de uso, indicadores de rendimiento, condiciones del caso de uso y la informaci´on adicional sobre el caso de uso. A.1.1. Nombre del caso de uso.
Para identificar el caso de uso se le da el nombre “estrategia de protecci´on de microrredes basada en sistemas de comunicaci´on”, con un ID que agrupa las iniciales de las palabras que componen su nombre, presentada en la Tabla A.1.1.
Tabla A. 2.1. Identificaci´on del caso de uso A.1.2. Administraci´on de versiones.
Los cambios realizados mientras la descripci´on fue realizada est´an presentados en la tabla A.1.2.
Cap´ıtulo 5. Conclusiones y recomendaciones
48
Tabla A. 2.2. Gesti´on de versiones A.1.3. Narrativa del caso de uso. La tabla A.1.3 muestra las descripciones breve y completa de la estrategia de protecci´on basada en comunicaciones.
www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
49
Tabla A. 2.3. Narrativa del caso de uso www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
50
A.1.4. Indicadores clave de rendimiento. Los indicadores identificados para implementar la estrategia de protecci´on son: disminuci´on de la duraci´on y frecuencia de las interrupciones causadas por fallas, adem´as de la operaci´on y administraci´on de la red facilitada por la comunicaci´on entre los elementos. Tabla A. 2.4. Indicadores clave de rendimiento A.1.5. Condiciones del caso de uso. Las condiciones y sus respectivos prerrequisitos para que la estrategia de protecci´on funcione correctamente, se presentan en la Tabla A.1.5. www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
51
Tabla A. 2.5. Condiciones del caso de uso A.1.6. Informaci´on adicional sobre el caso de uso para clasificaci´on La relaci´on que tiene la estrategia de protecci´on seleccionada con otros casos de uso, el nivel de profundidad y las palabras clave para clasificarlo est´an mostrados en la Tabla A.1.6. www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
52
Tabla A. 2.6. Informaci´on de clasificaci´on A.1.7. Observaciones generales. La Tabla A.1.7 muestra algunas observaciones identificadas y que no est´an especificadas en otra secci´on de la descripci´on del caso de uso. www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
53
Tabla A. 2.7. Informaci´on de clasificaci´on A.1.8. Especificar detalles t´ecnicos.
En la secci´on 4.2.3 est´an definidos y agrupados los actores de la estrategia de protecci´on. Los detalles t´ecnicos requieren definir la bibliograf´ıa consultada y de utilidad para llevar a cabo la descripci´on.
Las referencias presentadas en las tablas siguientes tienen un impacto sobre el desarrollo de la descripci´on aportando conceptos ´utiles para lograrlo. www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
54
Tabla A. 2.8. Referencias www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
55
Tabla A. 2.9. Referencias (continuaci´on) www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
56
Tabla A. 2.10. Referencias (continuaci´on) A.1.9. Definir t´erminos y definiciones comunes. Los t´erminos y definiciones comunes utilizados para facilitar la comprensi´on del trabajo realizado se mostrar´an en la tabla A.1.11 a continuaci´on. www.utp.edu.co
Cap´ıtulo 5. Conclusiones y recomendaciones
57
Tabla A. 2.11. T´erminos y definiciones comunes www.utp.edu.co
Bibliograf´ıa Baghaee, H.
R., Mirsalim, M., Gharehpetian, G.
B.
& Talebi, H.
A.
(2018),
‘MOPSO/FDMT-based Pareto-optimal solution for coordination of overcurrent relays in interconnected networks and multi-DER microgrids’, IET Generation, Transmission & Distribution 12(12), 2871–2886.
URL: http://digital-library.theiet.org/content/journals/10.1049/iet-gtd.2018.0079 Behnke, R. P., Quero, D. O. & Mora, G. V. (2018), ‘FACULTAD DE CIENCIAS F´ISICAS
Y MATEM´ATICAS’.
Briefs, S. & Energy, I. N. (n.d.), Marion Gottschalk Mathias Uslar Christina Delfs. CEN, CENELEC & ETSI (2014), ‘Report on Smart Grid Coordination Group: Smart Grid Information Security’, (November), 1–107.
URL: ftp://ftp.cen.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/Security.pdf Enanv, S. I. S., Medical, H., Ab, S. & Bertling, S. (2010), ‘International Standard’, 2004. Energ´ıa El´ectrica - Ministerio de Minas y Energ´ıa (n.d.). URL: https://www.minminas.gov.co/energias-renovables-no-convencionales Gottschalk, M., Uslar, M. & Delfs, C. (2017), ‘The Use Case and Smart Grid Architecture Model Approach’.
URL: http://link.springer.com/10.1007/978-3-319-49229-2 Hatziargyriou, N. (2014), Microgrid: Architecture and Control, Vol. 1. IEC 60050 - International Electrotechnical Vocabulary - Welcome (n.d.). URL: http://www.electropedia.org/ Laaksonen, H., Ishchenko, D. & Oudalov, A. (2014), ‘Adaptive protection and microgrid control design for Hailuoto Island’, IEEE Transactions on Smart Grid 5(3), 1486–1493.
Bibliograf´ıa
59
Liu, Z., Su, C., Hoidalen, H. K. & Chen, Z. (2017), ‘A Multiagent System-Based Protection and Control Scheme for Distribution System with Distributed-Generation Integration’, IEEE Transactions on Power Delivery 32(1), 536–545.
Ma, J., Xiang, X., Zhang, R., Li, P., Liu, J. & Thorp, J. S. (2017), ‘Regional protection scheme for distribution network based on logical information’, IET Generation, Transmission & Distribution 11(17), 4314–4323.
URL: http://digital-library.theiet.org/content/journals/10.1049/iet-gtd.2017.0560 Microgrids, I.-b. M.-v. & Sidhu, T. S. (2012), ‘A Communication-Assisted Protection Strategy for’, IEEE Transactions on Smart ... 3(4), 2088–2099.
URL: http://ieeexplore.ieee.org/abstract/document/6295696/ Ministerio de Minas y Energ´ıa (2018), ‘Resoluci´on No. 030 de 2018’. URL: http://apolo.creg.gov.co/Publicac.nsf/1c09d18d2d5ffb5b05256eee00709c02/83b41035c2c4474f05 Muda, H. & Jena, P. (2017), ‘Superimposed Adaptive Sequence Current Based Microgrid Protection: A New Technique’, IEEE Transactions on Power Delivery 32(2), 757–767. URL: http://ieeexplore.ieee.org/document/7555387/ Piesciorovsky, E. C. & Schulz, N. N. (2017), ‘Fuse relay adaptive overcurrent protection scheme for microgrid with distributed generators’, IET Generation, Transmission & Distribution 11(2), 540–549.
URL: http://digital-library.theiet.org/content/journals/10.1049/iet-gtd.2016.1144 Quintanilla, R. & Yarza, J. M. (2010), ‘Nuevas exigencias y aplicaciones de comunicaciones para la protecci´on de microrredes’, VI Seminario Internacional: SMART GRID en Sistemas de Distribuci´on y Transmisi´on de Energ´ıa El´ectrica pp. 43–50. URL: http://sg.cier.org.uy/publicaciones/revista.nsf/0a293b20eacdf8a903257133003ea67d/38d5383c4 Rojas P´erez, G. T. (2018), ‘3.5% creci´o la demanda de energ´ıa en enero de 2018 en Colombia — El Mundo’.
URL: http://www.elmundo.com/noticia/3-5crecio-la-demanda-de-energia-en-enero-de-2018-en-Colom Saavedra, M. A. (2017), ‘Generaci´on el´ectrica en Colombia est´a holgada ante la demanda — El Mundo’.
URL: http://www.elmundo.com/noticia/Generacion-electrica-en-Colombia-esta-holgada-ante-la-dema Saleh, K. A., Zeineldin, H. H., Al-Hinai, A. & El-Saadany, E. F. (2015), ‘Optimal Coordination of Directional Overcurrent Relays Using a New Time–Current–Voltage Characteristic’, IEEE Transactions on Power Delivery 30(2), 537–544. URL: http://ieeexplore.ieee.org/document/6876231/ www.utp.edu.co
Bibliograf´ıa
60
Shiles, J., Wong, E., Rao, S., Sanden, C., Zamani, M. A., Davari, M. & Katiraei, F. (2018), ‘Microgrid protection: An overview of protection strategies in North American microgrid projects’, IEEE Power and Energy Society General Meeting 2018-January, 1–5. Specification, D. T. (2013), ‘Draft Technical Specification’.
Ustun, T. S. & Khan, R. H. (2015), ‘Multiterminal Hybrid Protection of Microgrids over Wireless Communications Network’, IEEE Transactions on Smart Grid 6(5), 2493–2500. Ustun, T. S., Ozansoy, C. & Zayegh, A. (2011), ‘A microgrid protection system with central protection unit and extensive communication’, 2011 10th International Conference on Environment and Electrical Engineering, EEEIC.EU 2011 - Conference Proceedings pp. 1–4.
Zamani, M. A., Sidhu, T. S. & Yazdani, A. (2013), ‘A communication-based strategy for protection of microgrids with looped configuration’, Electric Power Systems Research 104, 52–61.
URL: http://dx.doi.org/10.1016/j.epsr.2013.06.006 Zhang, F., Mu, L. & Guo, W. (2019), ‘An Integrated Wide-Area Protection Scheme for Active Distribution Networks Based on Fault Components Principle’, IEEE Transactions on Smart Grid 10(1), 392–402.
www.utp.edu.co
Cita: Orozco Álvarez, Juan David (2019), Formalización de una estrategia de protección de microrredes dentro de una arquitectura de red, Universidad Tecnológica de Pereira, p. N. https://hdl.handle.net/11059/10715