Desarrollo de una herramienta de software para asistir la restauración de Sistemas Eléctricos de Potencia

Texto completo

(1)Ministerio de Educación Superior Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática, Física y Computación.. Desarrollo de una herramienta de software para asistir la restauración de Sistemas Eléctricos de Potencia.. Autores:. Omar Arturo García Zamora Eniel Rodríguez Machado. Tutores:. Dr. Carlos Morell Pérez M.Sc. Leonel F. Aleaga Loaiza. Santa Clara 2014.

(2) Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingeniería en Informática, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. Firma del Autor. Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del Autor. Firma del Jefe de Departamento donde se defiende el trabajo. Firma del Responsable de Información Científico-Técnica.

(3) Agradecimientos. A nuestra familia por el apoyo y amor brindados. A nuestros amigos por su compañía y por estar siempre en el momento preciso. A los profesores que contribuyeron en nuestra formación. A nuestro tutor Francisco por sus consejos y ayuda en la realización de la tesis. A nuestro oponente Gálvez por sus fuertes y constructivas críticas.. Gracias. I.

(4) Resumen El problema de la restauración de sistemas eléctricos de potencia ha sido tratado desde hace tres décadas, pero debido a la complejidad del mismo se hace difícil establecer un método general de solución. Por tanto se ha utilizado varios métodos de inteligencia artificial para encontrar una secuencia de acciones que lo lleve desde una condición de colapso al estado normal de operación. En la actualidad existen pocas herramientas de soporte que asistan al personal en las tareas de planificación de la restauración. En este trabajo se utiliza la planificación automatizada y varias técnicas de integración para la construcción automáticas de los planes de restauración. Se desarrolla una herramienta de software que ofrece un marco de trabajo para asistir la restauración de estos sistemas eléctricos, permitiendo la utilización de las instancias (CIM XML) de los modelos de sistemas de potencia según la ontología CIM (Modelo de Información Común) para la construcción automática de instancias de problemas de planificación en PDDL (Lenguaje de Descripción de Dominios de Planificación). La herramienta brinda una interface amigable al usuario, y un desempeño eficiente en los procesos involucrados, garantizando la interoperabilidad (transparente al usuario) entre diferentes sistemas en el proceso de planificación de la restauración.. II.

(5) Abstract The electric power system restoration problem has been handled for three decades, but because of its complexity is difficult to establish a general method of solution. Therefore it has been used several methods of artificial intelligence to find a sequence of actions that bring it back from a state of collapse to normal operation. At present there are few support tools that assist the operators in the restoration planning tasks. In this paper several automated planning and integration techniques for the automatic construction of restoration plans are used. A software tool that provides a framework to assist the restoration of these power systems is developed, allowing the use of instances (CIM XML) of power systems models according to CIM (Common Information Model) ontology for automatic construction of instances of planning problems in PDDL (Planning Domain Description Language). The software tool provides a user friendly interface and efficient performance in the processes involved, ensuring interoperability (transparent to the user) between different systems in the restoration planning process.. III.

(6) Índice Introducción..................................................................................................................... 1 Capítulo 1 Sistemas Eléctricos de Potencia, estándares y modelos. ........................... 9 1.1. Sistema Eléctrico de Potencia............................................................................ 9. 1.2. Principales componentes de un SEP ................................................................. 9. 1.3. Modelo CIM ...................................................................................................... 10. 1.4. Estándar IEC 61970-301 .................................................................................. 12. 1.5. Estándar IEC 61970-405 .................................................................................. 13. 1.6. Sistemas automatizados existentes vinculados al campo de acción ............... 13. 1.7. Tendencias y Tecnologías Actuales ................................................................. 14. 1.7.1. ¿Por qué utilizar Software Libre? .............................................................. 15. 1.7.2. Lenguaje Java ........................................................................................... 16. 1.7.3. Plataforma de Cliente Enriquecida ............................................................ 16. 1.7.4. Plataforma NetBeans ................................................................................ 17. Capítulo 2 Modelo del Negocio y Requisitos .............................................................. 19 2.1. Modelo del Negocio actual ............................................................................... 19. 2.2. Reglas de Negocio ........................................................................................... 25. 2.3. Actores y trabajadores del Negocio ................................................................. 26. 2.4. Diagrama de Casos de Uso del Negocio ......................................................... 26. 2.5. Requisitos funcionales ..................................................................................... 28. 2.6. Requisitos no funcionales ................................................................................ 30. 2.7. Diagrama de Casos de Uso del Sistema ......................................................... 30. 2.8. Descripción de los casos de uso del Sistema .................................................. 32. Capítulo 3 Descripción de la propuesta de solución ................................................... 37 3.1. Arquitectura del sistema ................................................................................... 37 IV.

(7) 3.2. Vista de Casos de Uso ..................................................................................... 39. 3.3. Diagrama de Clases del Sistema ..................................................................... 41. 3.4. Diagrama de Secuencia ................................................................................... 44. 3.5. Principios de Diseño ........................................................................................ 46. 3.6. Modelo de Componentes ................................................................................. 49. 3.7. Diagrama de Despliegue .................................................................................. 50. Capítulo 4 Pruebas y análisis de factibilidad ............................................................... 51 4.1. Análisis de factibilidad ...................................................................................... 51. 4.2. Pruebas de funcionalidad ................................................................................. 52. Conclusiones ................................................................................................................. 56 Recomendaciones......................................................................................................... 57 Bibliografía ....................................................................... ¡Error! Marcador no definido. Anexos ............................................................................. ¡Error! Marcador no definido.. V.

(8) Introducción. Introducción La moderna sociedad tal como existe en la actualidad no existiría sin el uso de la energía en general y sin el uso de la energía eléctrica en particular. La electricidad es una entrada clave en el proceso de desarrollo de la sociedad. Es una parte vital de la infraestructura de la economía de un país. Con el uso de la corriente alterna y el transformador se extendió su aplicación y cada ciudad de importancia dispuso de una planta. Las necesidades de contar con reserva para los casos de averías o mantenimientos, así como la posibilidad de traer hacia los centros de consumo la energía generada en las lejanas fuentes de energía primaria (fundamentalmente la de las hidroeléctricas) estimularon la interconexión de las plantas y de esta forma se formaron los sistemas eléctricos actuales. Estos sistemas se denominan Sistemas Eléctricos de Potencia (SEP), cuyos niveles de tensión son iguales o superiores a los 132 KV. La gestión de un sistema eléctrico de potencia es una de las tareas más importantes para una generación eficiente de energía eléctrica a gran escala, que desde el comienzo de la industria se ha mantenido en perfeccionamiento y estudio, los resultados obtenidos, apuntan al uso de la computación para asistir al proceso de gestión. Un apagón eléctrico tiene un efecto negativo inmediato sobre la seguridad y economía de un país. Los sistemas de potencia están en una creciente expansión cada año, y conforme más se modernizan las infraestructuras de la sociedad, más complejos se vuelven estos, alcanzando con frecuencia sus límites operativos, incrementando el riesgo de colapso. Cada año los grandes apagones provocan impactos severos sobre la sociedad. Estos impactos se incrementan exponencialmente conforme aumenta el tiempo total de la restauración del sistema de potencia colapsado. Los impactos son principalmente sobre la economía, la seguridad, los servicios básicos, vida, el medio ambiente, etc.. 1.

(9) Introducción Por lo tanto, es de principal importancia restaurar el sistema de potencia de manera confiable y rápida. Los sistemas de potencia son supervisados y controlados telemáticamente por el personal de operación altamente entrenado haciendo uso de los sistemas de control computarizados en los centros de control. Bajo una condición normal de operación, los sistemas de potencia operan bajo un ambiente casi automatizado, y los operadores se preocupan especialmente de supervisar el proceso. Los operadores en un centro de control de sistemas de potencia intervienen manualmente en muy pocas tareas, estos intervienen cuando encuentran una situación fuera de lo normal como es el caso de restablecer el sistema eléctrico de potencia y deben enfrentar problemas desafiantes que normalmente una situación normal de operación no son comunes. El problema de restaurar un sistema eléctrico de potencia después de un apagón total o parcial es tan viejo como la propia industria eléctrica. Las tareas de restauración que deben desarrollar los operadores en su mayoría son manuales haciendo uso de herramientas de software de simulación numérica que los ayudan a tomar decisiones antes de ejecutar las acciones sobre el sistema de potencia. El desarrollo de la informática ha permitido crear aplicaciones para simplificar el trabajo de varias actividades importantes como la operación y planificación del sistema de potencia. Antecedentes Muchas compañías en el mundo hacen uso de software que ayudan a realizar las tareas de planificación de operaciones en los sistemas de potencia, sin embargo, estos software son comerciales y las licencias suelen ser muy costosas, a tal punto que solo compañías de gran capital pueden permitirse la utilización de tales herramientas. Estos sistemas trabajan con toda la información obtenida de la red eléctrica, por lo que suelen necesitar grandes infraestructuras de cómputo para procesar toda la estructura que puede representar una central eléctrica moderna, teniendo como resultado un gasto adicional.. 2.

(10) Introducción Comúnmente estas herramientas se encuentran por separado, en dependencia de las acciones que realizan sea de supervisión y control, planificación, simulación, etc., provocando trabajo extra al interactuar entre aplicaciones, pues es frecuente que trabajen con esquemas y lenguajes diferentes. Problema Científico. Una de las tareas importantes y críticas en un centro de control en las redes eléctricas es la planificación de operaciones para la restauración de los sistemas de potencia cuando sucede un colapso total o parcial. En la actualidad existen muy pocas herramientas de soporte que asistan al personal en las tareas de planificación de la restauración. Se han propuesto herramientas de soporte en la decisión para la restauración de sistemas de potencia (Shanshan, Podmore et al.), en las cuales para formular el estado inicial de las situaciones de colapso, se utiliza datos de flujo de potencia como entrada y las demás características del equipamiento primario del sistema de potencia (tales como unidades de generación, cargas, líneas de transmisión y transformadores) que no tienen la mayoría de formatos de simulación y que son necesarios en la restauración, deben ser configurados manualmente de antemano extraídos desde modelos prefigurados (también manualmente) en algún sistema de simulación. Este proceso manual es poco práctico en ambientes de tiempo real. Sería deseable que una herramienta brinde mecanismos para configurar automáticamente el estado inicial del sistema a partir de la información almacenada en los diferentes sistemas SCADA/EMS, tomando ventaja de las facilidades que brinda los estándares de modelación de sistemas de potencia para la interoperabilidad entre sistemas y aplicaciones. Existen nuevas propuestas de utilizar técnicas de Planificación Automatizada a la solución de problemas de planificación de operaciones donde se utilizan algoritmos de Inteligencia Artificial muy eficientes que están ganando terreno en la solución de problemas reales en los sistemas de potencia para llevar a un sistema cualquiera desde un estado inicial a un estado objetivo. Estos algoritmos de planificación requieren de dos archivos como entrada; un dominio de planificación y un problema de planificación. El “dominio” de planificación es el 3.

(11) Introducción archivo donde se describe el “conocimiento” en la forma de acciones de planificación que son las que transforman el estado inicial del ambiente al estado objetivo deseado. El problema de planificación es el archivo donde se representa el “estado inicial” del ambiente (instancia actual del modelo del sistema de potencia) y los objetivos a alcanzar. Estos dos archivos deben ser codificados en un lenguaje de descripción de dominios de planificación. Hoy en día PDDL del inglés Planning Domain Description Languaje (en español: “Lenguaje de descripción del dominio de planificación”) es el lenguaje estándar aceptado mundialmente para la especificación de dominios y problemas de planificación automatizada. En PDDL se utiliza la lógica proposicional para especificar las instancias de los problemas de planificación. Pero en la actualidad no existe una solución para la recolección de los datos desde las infraestructuras de cómputo de los sistemas de potencia y llevarlo hasta una formulación en el lenguaje PDDL para representar el estado actual sin perder la semántica asociada de los modelos utilizados. Se ha adoptado una ontología para la representación de los modelos de sistemas de potencia denominada CIM. Esta ontología es un modelo ampliamente aceptado en la comunidad mundial que ofrece un alto nivel de detalle del mundo pero que necesita ser transformado a un nivel abstracto mejorando la eficiencia de los algoritmos de planificación y simulación de sistemas de potencia para la solución del problema de restauración. Los algoritmos de planificación trabajan con el lenguaje de planificación denominado PDDL. CIM y PDDL persiguen objetivos diferentes. CIM es una ontología creada para representar los modelos de sistemas de potencia, en el cual se representa el conocimiento estático para describir fragmentos de la realidad de manera reutilizable por los programas de cómputo, además, prioriza la expresividad sobre la complejidad computacional de los procesos. PDDL, por el contrario, se crea inicialmente para poder comparar los algoritmos de búsqueda de varios planificadores. Los problemas de la planificación se desarrollan en dominios con una estructura abstracta muy sencilla, por lo que PDDL asume una representación muy sencilla del vocabulario y del estado, y no presta atención a los problemas relativos al detalle de los sistemas complejos.. 4.

(12) Introducción Históricamente la comunidad de planificación ha concentrado sus esfuerzos en la creación de potentes algoritmos de búsqueda para resolver problemas en dominios muy sencillos en los que se usa el conocimiento primario de operaciones para resolver los problemas de alto nivel de decisión. El conocimiento codificado en los dominios de planificación es muy pequeño en comparación con los modelos de la vida real, esto se la ha hecho para minimizar la complejidad temporal y espacial en la obtención de las soluciones. Sin embargo, cuando intentamos utilizar técnicas de planificación para resolver problemas de la industria nos encontrarnos con ontologías ricas en conocimiento estático. Tal es el caso del modelo de información común (CIM IEC 61970) (McMorran) para modelar sistemas de potencia en donde se tiene una gran cantidad de información asociada y que es difícil de manejar directamente por los algoritmos de planificación actuales. En este tipo de dominios surgen nuevos problemas relacionados con la adquisición, abstracción y traducción de grandes bases de conocimiento existentes en los centros de control de los sistemas de potencia, ya que el conocimiento estático de la ontologías CIM nos brindaría el estado actual del sistema de potencia para que el algoritmo de planificación pueda encontrar la solución al sistema de potencia según su estado actual. Pero desafortunadamente, los mecanismos que proporciona PDDL para representar este tipo de conocimiento son demasiado abstractos. Por consiguiente, el trabajo de traducir de manera automática el conocimiento estático de la ontología CIM a PDDL de forma tal que se mantenga la semántica original es todo un desafío, ya que se necesita de expertos que conozcan de ambos lenguajes y le dediquen el tiempo necesario para seleccionar y representar de manera adecuada el conocimiento que el planificador necesita. Para que los algoritmos de planificación puedan razonar en base a datos reales extraídos de los centros de control de los sistemas de potencia, se necesita de herramientas de software que realicen la traducción desde los formatos CIM XML a un problema de planificación PDDL en donde se representen el estado actual del modelo de un sistema de potencia en particular. De esta forma se tendría el modelo del sistema de potencia disponible para poder ser traducido y utilizado directamente por los algoritmos de Planificación Automatizada y de esa forma poder realizar las tareas de planificación de la restauración del sistema de potencia luego de un colapso haciendo 5.

(13) Introducción uso del conocimiento operativo codificado en el dominio PDDL. Pero utilizar a los planificadores en un ambiente computacional independiente del centro de control y del sistema de potencia en cuestión involucra un reto de integración ya que los lenguajes, modelos de representación (nivel de abstracción), y plataformas sobre las cuales los planificadores sobreviven son sui géneris. En realidad en un mismo centro de control, la representación del sistema de potencia las actividades de operación (despacho) y planificación se utilizan normalmente dos modelos distintos tales como: Node-Breaker y Bus-Branch respectivamente. El modelo Node-Breaker es un modelo diseñado para el nivel táctico y utilizado para ejecutar las tareas de monitoreo y control del sistema de potencia directamente sobre los elementos de la red a través del SCADA/EMS. Por otro lado el modelo Bus-Branch es un modelo utilizado en el nivel estratégico en las tareas de planificación off-line con la ayuda de los algoritmos analíticos que trabajan en un nivel alto de abstracción. Históricamente los modelos Node-Breaker y Bus-Branch han estado separados tanto en la forma de sus estructuras de datos como en la forma de implementación de los formatos de descripción de los modelos. En inteligencia artificial normalmente se utiliza un modelo con un alto nivel de abstracción adecuado para el tratamiento de las soluciones de forma eficiente a través de los algoritmos de búsqueda. Por el contrario, el nivel de abstracción del enfoque Node-Breaker en el que CIM se basa, es muy concreto y difícil de tratar en los problemas de planificación automatizada incluso con problemas muy pequeños, ya que en el modelo CIM Node-Breaker se incluye un sin número clases, atributos y relaciones entre clases que en su mayoría son irrelevantes para los problemas de planificación estratégica, como es el caso de la planificación de la restauración de sistemas de potencia. Los algoritmos de planificación basados en el lenguaje PDDL trabajan mejor sobre un modelo abstracto al nivel Bus-Branch para buscar soluciones planteadas a las tareas de planificación de una manera eficiente, ya que se reduce el espacio de búsqueda, y el tiempo computacional. Por lo tanto se hace necesario representar el modelo Bus-. 6.

(14) Introducción Branch de sistemas de potencia en un problema de planificación PDDL a partir de los modelos existentes en CIM XML. Esta es una tarea que se torna difícil ya que primeramente para obtener el modelo abstracto Bus-Branch se debe razonar sobre el modelo Node-Breaker original especificado en el formato CIM XML. El razonamiento se ha estado haciendo con el uso de algoritmos de procesamiento topológico del modelo Node-Breaker para que conviertan de manera dinámica el modelo de topología Node-Breaker completo en un modelo Bus-Branch reducido siguiendo el estándar CIM, identificando la información primaria para luego producir un modelo que imite al modelo de la red original. Este modelo Bus-Branch resultante servirá como una plantilla sobre la cual se pueda generar los problemas de planificación PDDL donde se represente el estado inicial del sistema de potencia para que los algoritmos de planificación puedan deben ser capaces de tomar ventaja de las estructuras lógicas del problema a resolver. Esto provoca una necesidad de tener una herramienta disponible que brinde las siguientes funcionalidades: . La posibilidad de importar y validar instancias de los modelos de sistemas de potencia desde un archivo CIM XML que sigue el modelo CIM versión 14 según la norma IEC 61970.. . La interfaz gráfica para la exploración visual de los modelos CIM XML de sistemas de potencia.. . La construcción automática de esquemas eléctricos de potencia simplificados en la representación Bus-Branch a partir de una instancia de un archivo CIM XML.. . La traducción de una instancia del modelo de sistemas de potencia en formato CIM XML a la definición del problema de planificación PDDL.. . La integración con un algoritmo de planificación (Planificador) que puede estar en otra plataforma.. Objetivo general Desarrollar una herramienta de software para asistir a la gestión de la restauración de Sistemas Eléctricos de Potencia. 7.

(15) Introducción Objetivos específicos . Implementar un modelo basado en CIM (Modelo de Información Común) de acuerdo al estándar IEC 61970.. . Implementar un modelo abstracto denominado Bus-Branch dentro del modelo CIM.. . Construir diagramas mono-lineales del sistema eléctrico de potencia a partir de instancias del modelo CIM descritas en formato XML/RDF.. . Utilizar el conocimiento representado en las instancias CIM de los modelos de sistemas de potencia para construir instancias de los problemas de planificación utilizando el lenguaje PDDL.. . Diseñar e implementar un sistema de comunicación entre la aplicación y un planificador externo, para la ejecución, procesamiento y almacenamiento de la salida.. . Construir un gráfico de la curva de capacidad de generación en base al plan de restauración calculado.. Como Trabajo de Diploma, esta investigación se estructuró en cuatro capítulos. En el primer capítulo se realiza una descripción de la investigación que este trabajo apoya, así como los conceptos necesarios para su entendimiento, sus principales flujos de procesos y tecnologías actuales. En el segundo capítulo se desarrolla la modelación del negocio y del sistema, actores y trabajadores, se identifican las reglas de negocio y se definen los requisitos funcionales y no funcionales del sistema. En el tercer capítulo se describen los diagramas de clases y de secuencia más significativos, la concepción del sistema en la etapa de diseño e implementación. Así como las principales vistas de la propuesta de solución obtenida. En el cuarto capítulo se describe el análisis para determinar la factibilidad y las pruebas realizadas al sistema.. 8.

(16) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos. Capítulo 1. Sistemas Eléctricos de Potencia, estándares y modelos.. Durante el desarrollo de la humanidad se ha dedicado estudio, tiempo y recursos, para aprovechar al máximo la generación de energía eléctrica, siendo los Sistemas Eléctricos de Potencia el eslabón principal de este objetivo. En este capítulo se describen los estándares, modelos, comparaciones entre sistemas automatizados que actualmente existen y las tecnologías de implementación, que permiten el desarrollo de este trabajo. 1.1. Sistema Eléctrico de Potencia. Un sistema eléctrico de potencia (SEP) comprende el conjunto de medios y elementos útiles para la generación, el transporte y la distribución de la energía eléctrica. Este conjunto está dotado de mecanismos de control, seguridad y protección. Constituye un sistema integrado que además de disponer de sistemas de control distribuido, está regulado por un sistema de control centralizado que garantiza una explotación racional de los recursos de generación y una calidad de servicio acorde con la demanda de los usuarios, compensando las posibles incidencias y fallas producidas. 1.2. Principales componentes de un SEP. A continuación se describen algunos de los elementos más importantes que conforman un SEP. Generador: dispositivo capaz de mantener una diferencia de potencial eléctrico entre dos de sus puntos (llamados polos, terminales o bornes) transformando la energía mecánica en eléctrica. Interruptor: dispositivo utilizado para desviar o interrumpir el curso de una corriente eléctrica. Existen dos tipos fundamentales, seccionadores y disyuntores, los primeros son operados manualmente, mientras que los segundos están diseñados para cortar el flujo eléctrico automáticamente ante anomalías.. 9.

(17) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos Transformador: dispositivo que convierte la energía eléctrica alterna de un cierto nivel de tensión, en energía alterna de otro nivel de tensión, por medio de interacción electromagnética. Línea de transporte de energía eléctrica o línea de alta tensión: medio físico mediante el cual se realiza la transmisión de la energía eléctrica a grandes distancias. Está constituida tanto por el elemento conductor, usualmente cables de acero, cobre o aluminio, como por sus elementos de soporte, las torres de alta tensión. Carga: representa un punto de consumo de energía, entiéndase ciudades, fábricas, etc. 1.3. Modelo CIM. Con el fin de optimizar su funcionamiento, los sistemas de energía eléctrica son controlados desde puestos remotos. Estos sistemas de gestión remotos están formados por distintas aplicaciones. Cada una de estas aplicaciones permite la realización de una funcionalidad de gestión determinada: cálculo de flujo de cargas óptimo, análisis de los eventos transitorios en la red, configuración de los sistemas de protecciones, gestión de activos, software SCADA1 para el control y supervisión de la red en tiempo real, etc. A pesar de que cada aplicación se centra en una funcionalidad concreta, muchas de ellas, en ocasiones, comparten una misma información de entrada. Así, por ejemplo, la mayor parte de las aplicaciones de un sistema de gestión remoto deben importar la información acerca de la topología de la red eléctrica que van a gestionar. También puede ocurrir que la información de salida que genere una determinada aplicación tras haber realizado sus cálculos sirva como información de entrada para otra aplicación. Estas situaciones también se pueden dar entre aplicaciones de distintos sistemas de gestión. En definitiva, hay información relacionada con el sistema eléctrico que se repite en distintas aplicaciones de un mismo o de diferentes sistemas de gestión remotos. Ante este hecho, se podría optar por introducir varias veces esta información en el sistema. Sin embargo, esta opción no es nada eficiente, ya que supone un trabajo. 1. SCADA del inglés: Supervisory Control And Data Acquisition. Es un software para ordenadores que permite controlar y supervisar procesos industriales a distancia.. 10.

(18) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos extra. innecesario,. aumenta. las. probabilidades. de. introducir. la. información. erróneamente y, por tanto, puede dar lugar a incongruencias. Por este motivo, lo más lógico es que exista un intercambio de información entre las aplicaciones de software de gestión de las redes eléctricas. El problema es que, en general, dichas aplicaciones son desarrolladas por distintos fabricantes y los esquemas de modelamiento de los datos son a discreción de los requerimientos la empresa. Esto implica que cada aplicación tiene su propia manera de organizar la información y además cuenta con un formato propio para intercambiarla. De este modo, para cada dos aplicaciones que deban intercambiar información es necesario un convertidor de formato. La existencia de convertidores incrementa el costo computacional y la complejidad de los sistemas de gestión de las redes eléctricas. A finales de los 90, en vista de este problema, EPRI 2comenzó a elaborar un modelo de información único, común a todas las aplicaciones encargadas de la gestión de las redes eléctricas. A principios de esta década, la Comisión Electrotécnica Internacional (CEI o IEC por sus siglas en inglés, International Electrotechnical Commission) lo adoptó como el modelo de información internacional estándar para la gestión de los sistemas eléctricos (IEC, 2007). Es decir, con el modelo CIM se estandariza la manera de organizar toda la información que pueda ser necesaria en las aplicaciones dedicadas a la gestión de las redes eléctricas. Basándose en este modelo, la IEC también define un formato estándar en el lenguaje de marcado extensible (XML) para el intercambio de información entre las aplicaciones de software de gestión. Este formato se denomina CIM XML. Realmente, el CIM XML no es el único formato estándar basado en el CIM que ha definido la IEC. Este formato está dirigido únicamente al intercambio de grandes cantidades de información acerca de la topología de las redes eléctricas a gestionar. La definición de un modelo de información único y unos formatos estándar para el intercambio de información basados en dicho modelo reduce de manera considerable la complejidad y costo computacional de los sistemas de gestión remoto. Así, en un 2. EPRI del inglés: Electric Power Research Institute (en español: "Instituto de Investigación de Potencia Eléctrica") realiza investigaciones sobre temas de interés de la Industria de la energía eléctrica en Estados Unidos.. 11.

(19) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos sistema de n aplicaciones, en el peor de los casos (si ninguna de las aplicaciones tuviese implantado el CIM), serían necesarios n convertidores de formato. Por el contrario sin la intervención de CIM XML como un formato común de intercambio, se necesitarían n(n-1) convertidores para la interacción entre las n aplicaciones. Minimizar la complejidad de los sistemas implica una mejoría en su funcionamiento y fiabilidad. En este apartado introductorio se ha explicado el origen y utilidad del modelo CIM. 1.4. Estándar IEC 61970-301. Las. empresas. eléctricas. utilizan. una. variedad. de. formatos. diferentes. de. almacenamiento de datos, ya sea de activos, información de despacho del trabajo, en un esquema propietario interno dentro de una base de datos, datos topológicos de la red del sistema eléctrico dentro de un sistema de control, o archivos estáticos del modelo utilizados por las herramientas de software de simulación. Si bien algunas empresas todavía no disponen de sistemas o aplicaciones para la gestión del sistema de transmisión, las empresas dentro de las cuales ya se encuentran actualmente implementados estos sistemas poseen datos que requieren ser intercambiados dentro de las mismas aplicaciones de la empresa, a menudo hay una necesidad de intercambio de datos con otras empresas. El gran número de formatos propietarios utilizados por estas aplicaciones requiere un gran número de adaptadores, que conviertan los formatos de datos de aplicaciones legadas para importar y exportar datos entre múltiples sistemas. Este crecimiento exponencial de la complejidad en la integración de un número creciente de aplicaciones y el intercambio de información entre múltiples empresas ha llevado a la exigencia de un formato común que abarque todos los ámbitos de intercambio de datos en el campo de la energía eléctrica. La norma IEC 61970 se centra en los sistemas de gestión de las redes de transmisión. Define el modelo CIM, y además: describe una arquitectura de referencia para la integración entre las aplicaciones que forman parte de un sistema de gestión y los requisitos generales de las mismas, especifica los mecanismos (servicios) de comunicación por los cuales se puede acceder a la información de una aplicación y, por. 12.

(20) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos último, especifican formatos (como el CIM XML) empleados para el intercambio de información. 1.5. Estándar IEC 61970-405. Las técnicas de visualización de los esquemas eléctricos que resumen la información mostrada en una pantalla de ordenador simplifican el análisis de un conjunto de datos, que en su estado original serian incomprensibles por una persona, o su complejidad haría poco factible su análisis. Basado en el desarrollo de estas técnicas surge el estándar IEC 61970-453, el cual describe la forma de representar gráficamente la información de los componentes de un SEP. Plantea además un modelo (basado en el modelo CIM) para el almacenamiento e intercambio de los datos relacionados con la representación. gráfica,. persiguiendo. como. objetivo. principal. garantizar. la. interoperabilidad entre aplicaciones. 1.6. Sistemas automatizados existentes vinculados al campo de acción. Existen dos sistemas pioneros vinculados al trabajo con los SEP, InterPSS y CIMphony, siendo este último el más reciente. InterPSS (tecnología de Internet Power System basado en Simulador) es un proyecto de desarrollo de software libre y abierto, aunque la licencia bajo la cual se distribuye solo permite el trabajo con 25000 objetos. Entre sus funcionalidades se encuentran: el diseño del sistema de alimentación, el análisis, el diagnóstico y la operación. Se distingue por su arquitectura de sistema abierto y de acoplamiento flexible. Esta arquitectura permite que los componentes desarrollados por otros para ser fácilmente conectados a InterPSS para aumentar su funcionalidad, e igualmente importante, permite que sus componentes se integren en otro sistema de software. El proyecto se encuentra actualmente en fase de desarrollo por un equipo de desarrolladores que viven en Estados Unidos y China. CIMPHONY comenzó como un proyecto de investigación en la Universidad de Strathcly, anteriormente fue utilizado en un número de EPRI y pruebas de interoperabilidad para la validación del modelo. La nueva versión está totalmente re-. 13.

(21) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos diseñada, basada en software de código abierto y utiliza el sistema modular OSGi3 y una interfaz de usuario basada en Eclipse para proporcionar un marco multi-plataforma de herramientas de gestión de datos y análisis de sistemas de potencia. Los módulos CIMPHONY centrales prestan servicios independientes del modelo para: Gestión y edición de datos. 1.7. . Validación impulsada por la línea aérea de contacto. . Transformación manejada por Modelo. . Persistencia distribuida de base de datos. . Visualización gráfica. . Exportación geográfica utilizando KML Tendencias y Tecnologías Actuales. En la actualidad no existen herramientas de software que involucren métodos ampliamente aceptados para guiar a los operadores en la restauración. En las tres últimas décadas, este problema ha sido ampliamente investigado por la comunidad de Potencia y Energía. La investigación principalmente se ha enfocado en buscar herramientas de software que asistan al operador en la toma de decisiones para establecer la estrategia de restauración más apropiada para el caso del colapso en particular (Yunhe, Chen-Ching et al.) (Fink, Liou et al.) (Chen-Ching, Liou et al.) (Wei, Chen-Ching et al.) (Wei, Chen-Ching et al.) (Yunhe, Chen-Ching et al.). Estas herramientas informáticas permitirían guiar de forma eficiente el proceso de restauración, respectando las restricciones que impone el sistema de potencia. La planificación completa de la restauración de un SEP podría ser uno de los problemas más difíciles de la ciencia de ingeniería. Como consecuencia, existe un creciente interés en establecer procedimientos sistemáticos, herramientas y modelos para la planificación de la restauración bajo un ambiente en línea. Es importante destacar que ninguna de las herramientas de software citadas anteriormente soporta la importación directa de los datos desde un formato CIM XML, 3. OSGI del inglés Open Services Gateway Initiative. Define las especificaciones abiertas de software que permita diseñar plataformas compatibles que puedan proporcionar múltiples servicios.. 14.

(22) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos utilizan un esquema propietario que dificulta su integración, haciendo necesario el desarrollo de un adaptador que realice un profundo y complejo mapeo de conceptos en función de los esquemas de interés de la empresa, incluso si la empresa modela los datos según el modelo de información común CIM para sistemas de potencia. 1.7.1 ¿Por qué utilizar Software Libre? En la ética El software no debe tener dueños, es un asunto de libertad: la gente debería ser libre de usarlo en todas las formas que sean socialmente útiles. De esta forma, el movimiento del Software Libre pone lo que es beneficioso para la sociedad por encima de los intereses económicos o políticos. Entre los beneficios que percibe la sociedad podemos mencionar: . Tecnologías transparentes, confiables y seguras.. . Tecnologías como bien público.. . Promoción del espíritu cooperativo, en el que el principal objetivo es ayudar a su vecino.. . Precios justos.. En la práctica El Software Libre ofrece a las personas la posibilidad de utilizar, estudiar, modificar, copiar y redistribuir el software. Para hacer efectivas estas libertades, el código fuente de los programas debe estar disponible. Gracias a estas libertades obtenemos muchos beneficios prácticos: . Podemos ejecutar el software cuando queramos y para lo que queramos.. . Podemos aprender de los programas existentes.. . Podemos mejorarlos.. . Podemos adaptarlos para que se ajusten a nuestras necesidades.. . Podemos basarnos en ellos, de forma que evitamos los costos adicionales de empezar un programa desde cero. 15.

(23) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos . Podemos formar negocios alrededor de la creación, distribución, soporte y capacitación de programas libres.. Y el efecto de todos estos beneficios es la formación de Comunidades enormes alrededor de proyectos de software libre, gracias a las cuales tenemos acceso a desarrolladores, documentadores y probadores de todo el mundo. 1.7.2 Lenguaje Java Java es el lenguaje utilizado para la implementación de este trabajo por dos razones importantes; en primer lugar es un lenguaje orientado a objetos, ideal para representar cada componente del circuito eléctrico y tratarlo como si fuera un objeto físico. En segundo lugar; al utilizar Java, contamos con el beneficio de la plataforma NetBeans, la cual constituye una plataforma de cliente enriquecida, permitiendo una rápida implementación de software. 1.7.3 Plataforma de Cliente Enriquecida RCP del inglés Rich Client Platforms (en español: “Plataforma de Cliente Enriquecida”) es un entorno de administración del ciclo de vida de una aplicación, la cual constituye una base para el desarrollo de aplicaciones de escritorio. Esta se encarga de proveer un framework que brinda al desarrollador un conjunto de características presentes en este tipo de aplicaciones, tales como: menús, barras de herramienta, barras de estado, barras de progreso, persistencia de datos de configuración de la aplicación e internacionalización, entre otras, las cuales pueden ser utilizadas con mucha facilidad. También, es la Plataforma quien determina un aspecto fundamental de las aplicaciones como lo es la arquitectura. Las aplicaciones desarrolladas sobre una RCP son implementadas en forma de Módulos, lo cual conlleva a numerosas ventajas, entre las cuales podemos mencionar que cada módulo resuelve un problema en particular con o sin ayuda de otros, y el mismo puede ser utilizado por otros módulos para llevar a cabo sus tareas, contribuyendo a la facilidad de integración, un alto grado de cohesión y coherencia, y un muy reducido (o tal vez nulo) nivel de acoplamiento entre los diferentes componentes de nuestra aplicación.. 16.

(24) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos Debido a todo esto, desarrollar sobre una RCP incrementa la productividad del desarrollador, liberándolo de preocuparse por tareas que tienen poca incidencia sobre la resolución de los requerimientos del dominio del problema y ayudándolo a enfocar sus energías en realizar tareas relacionadas con la lógica del negocio de la aplicación. Entre otras características ventajosas que motivan su uso encontramos: . Optimización del tiempo de desarrollo.. . Interfaz de usuario consistente (Usabilidad).. . Facilidad de actualización de la aplicación incluso en tiempo de ejecución.. . Independencia de la plataforma.. . Reusabilidad y fiabilidad.. 1.7.4 Plataforma NetBeans La Plataforma Netbeans es una base para desarrollar aplicaciones de escritorio complejas con un enfoque modular y pensando en características como la extensibilidad y la escalabilidad (Bock). Aparte de las ventajas comunes a toda Plataforma de Cliente Enriquecida, la Plataforma Netbeans ofrece numerosos frameworks y muchas características que pueden ser de gran utilidad a la hora de desarrollar nuestras aplicaciones, entre las cuales podemos resaltar: . Framework para la creación de interfaces de usuario.. . El editor de datos de Netbeans IDE.. . Interfaz de usuario para la personalización de la aplicación.. . Framework para la creación de asistentes (Wizards).. . Sistema de datos que permite obtener información de diferentes orígenes de datos (FTP, CVS, XML o de una Base de Datos).. . Internacionalización.. . Ayudas del sistema.. . Ayudas contextuales del sistema.. 17.

(25) Capítulo 1: Sistemas Eléctricos de Potencia, estándares y modelos Además de estas existen otras inherentes al uso de la Plataforma, como son: un mejor aprovechamiento del tiempo de desarrollo, una mejor organización de la aplicación basada en estándares y patrones estructurales y de diseño, una arquitectura consistente y robusta, y un mejor rendimiento en cuanto a tiempo de ejecución y optimización de recursos.. 18.

(26) Capítulo 2: Modelo de Negocio y Requisitos. Capítulo 2. Modelo del Negocio y Requisitos. Antes de desarrollar un sistema informático se debe detectar y analizar los procesos que están presentes en la organización. Durante el transcurso del capítulo se abordan los temas relacionados con la modelación del negocio, se realiza un estudio detallado con el objetivo de definir los casos de uso y actores del negocio, requisitos funcionales y no funcionales. 2.1. Modelo del Negocio actual. A continuación se describen los procesos sustantivos del negocio, estos procesos son los que dan un resultado de valor para el cliente, lo que los convierte en el eje fundamental del negocio. Para esta labor se utilizará la notación BPMN4, así como el lenguaje natural para ofrecer una descripción del flujo de los procesos y sus actividades. Proceso Restaurar el SEP.. Ilustración 1: Proceso de negocio Restaurar el SEP.. 4. BPMN del inglés: Business Process Modeling Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio) es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo.. 19.

(27) Capítulo 2: Modelo de Negocio y Requisitos La restauración de un Sistema Eléctrico de Potencia es el proceso fundamental que se lleva a cabo en este negocio. Para su correcto desarrollo se necesita, como punto de partida, la información del SEP a restaurar, además, de la descripción del problema de aplicación en el lenguaje PDDL. Por lo general, este proceso se lleva a cabo cuando el sistema, o parte de este, se encuentra colapsado de manera parcial o total. Inicialmente se procede a realizar su representación gráfica, lo que permite tener una visión general del estado de los componentes del sistema, visualizando con relativa facilidad el estado actual del sistema de potencia en base a la información del archivo CIM XML de entrada. Seguidamente se efectúa la descripción del problema en PDDL para el sistema de potencia en particular, donde se define el estado actual del sistema y el estado objetivo deseado que puede ser por defecto (todo el sistema de potencia restaurado) o personalizado (solo ciertos elementos del sistema de potencia a ser restaurados). Auxiliados de un algoritmo de planificación automatizada, con la descripción del dominio de planificación en PDDL y la descripción del problema en PDDL, se procede a obtener el plan de restauración, el cual es una secuencia de acciones a ejecutarse sobre el sistema para llevarlo desde el estado inicial de colapso hasta el estado normal de operación objetivo. Para comprobar la eficacia de este plan, es necesario utilizar herramientas de software para la simulación de sistemas de potencia y verificar por cada paso descrito en el plan, que se cumplan varias restricciones numéricas no-lineales (de los sistemas de potencia) que el algoritmo de planificación es incapaz de abordar actualmente en tiempo de ejecución. Si todas las restricciones no-lineales en el plan de restauración son cumplidas, el plan está apto para ser ejecutado físicamente por los operadores. En el proceso de comprobación del plan, es necesario actualizar en el modelo inicial cargado los cambios en la información sobre los componentes afectados por las acciones del plan de restauración, para ello se analiza cada acción descrita en el plan y sobre qué elementos esta acción manipula la información, tales como variables booleanas, numéricas, etc. Los cambios en los parámetros de varios elementos de la red de potencia producen un cambio en la topología de la misma, estos cambios deben ser actualizados en la representación gráfica.. 20.

(28) Capítulo 2: Modelo de Negocio y Requisitos Proceso Representar gráficamente el SEP.. Ilustración 2: Proceso de negocio Representar gráficamente el SEP. La información relacionada con los componentes de un SEP se puede encontrar en varios formatos, pero su complejidad estructural y dimensional le impide al usuario tener una visión del estado general del SEP en un periodo de tiempo y exactitud razonables. Para enfrentar esto se aprovechan los avances en las técnicas de visualización científica mediante ordenador, las cuales simplifican el estudio de un conjunto de datos, que en su estado original serian incomprensibles por una persona, o su complejidad haría poco factible su análisis. El objetivo es mostrar los diferentes componentes del SEP de manera simple y con pictogramas denominados diagramas “mono-lineales” en la comunidad eléctrica de sistemas de potencia, que representan las conexiones entre los distintos dispositivos de la red de potencia. La distribución de los componentes e interconexiones en el esquema no tiene que corresponder con sus ubicaciones físicas en el terreno sino más bien es una representación abstracta de la topología total de la red. Esta representación gráfica del SEP comienza con la realización de un análisis topológico del mismo, teniendo en cuenta las relaciones detalladas de conexión entre los componentes físicos. Posteriormente se debe decidir el tipo de diagrama mono-lineal a dibujar, estos pueden ser de dos tipos:. 21.

(29) Capítulo 2: Modelo de Negocio y Requisitos . Bus-Branch: Solo incluyen los equipos primarios y las interconexiones entre estos, ignorando los dispositivos de conmutación de red.. . Node-Breaker: Incluye todo los dispositivos de conmutación.. Actualmente el trazado de los diagramas anteriormente descritos se hace con el uso de herramientas tipo CAD tales como Autocad, ElectricCad, etc., y software de simulación de sistemas de potencia especializados tales como PSS/E, PowerWold, etc. Es importante destacar que el proceso actual de construcción de los diagramas monolineales es puramente manual, utilizando herramientas de edición gráfica brindadas por las aplicaciones. Estos diagramas son de tipo estáticos e imposibles de actualizar de manera automática por medios externos (ejemplo: plan de restauración calculado por un algoritmo de planificación) en caso de algún cambio sobre el estado de los elementos en el modelo. Proceso Formular problema.. Ilustración 3: Proceso de negocio Formular problema En este contexto cuando se habla de la descripción del problema de planificación se hace referencia a la definición, en lenguaje PDDL, del estado actual de cada componente que integra el SEP y del estado objetivo que se pretende al final del periodo de restauración en cada uno de ellos. Para describir el problema en PDDL es necesario analizar y extraer la información de los componentes físicos del SEP, declarando el estado y las relaciones entre ellos. De igual forma en el problema PDDL se define el estado objetivo para cada uno de estos componentes que el planificador debe alcanzar al final de la búsqueda de la solución. Todo esto debe quedar resumido en la forma de declaraciones PDDL principalmente en. 22.

(30) Capítulo 2: Modelo de Negocio y Requisitos la forma de triplas del tipo (predicado, sujeto, objeto) en un archivo con extensión *.pddl (por ejemplo problem.pddl). Proceso Obtener plan de restauración.. Ilustración 4: Proceso de negocio Obtener plan de restauración. El plan de restauración no es más que una secuencia de acciones (operadores) a ejecutarse sobre determinados dispositivos del SEP con el objetivo de modificar su estado, de forma tal que permita llevar al SEP a las condiciones objetivo deseadas a partir del estado actual. Esto lo convierte en un punto crítico para la evolución satisfactoria del proceso de restauración de un SEP. Este procedimiento se realiza utilizando el planificador de propósito general denominado POPF2 (Amanda Coles), el cual está diseñado para ejecutarse sobre distribuciones Linux. En el momento que este algoritmo de planificación solo puede ser corrido bajo el SO Linux, se hace necesario dedicar un ordenador (virtual o físico) con un sistema operativo de este tipo, solamente para el desarrollo de la tarea de la planificación automática. POPF2 no presenta una interfaz gráfica de usuario, por lo que su utilización debe ser mediante un terminal. Para ello el usuario debe abrir un terminal y desplazarse hasta el directorio donde está ubicado el planificador. Su ejecución se realiza mediante una llamada paramétrica, en la forma de un comando que requiere una serie de argumentos, siendo obligatorios el archivo del dominio y el problema, ambos son 23.

(31) Capítulo 2: Modelo de Negocio y Requisitos archivos de tipo PDDL. Al concluir el procedimiento, si no ocurren errores de planificación u otro tipo, se mostrará en el terminal un conjunto de datos que detallan el proceso de ejecución del planificador. Para extraer el plan de restauración de dichos datos es necesario localizar la línea con la cadena de caracteres “;;;; SolutionFound” y seleccionar de ahí en adelante el texto restante y copiarlo a un archivo de texto plano, creado previamente, llamado plan.pddl. Proceso Simular ejecución del plan de restauración. Ilustración 5: Proceso de negocio Simular ejecución del plan de restauración. El proceso de simulación es sumamente importante para la restauración de un SEP pues en este proceso se verifica el cumplimiento de varias restricciones (principalmente no-lineales) para asegurar la confiabilidad del plan de restauración, tal como lo haría un operador en la actualidad. Esto se debe a que los métodos de planificación utilizados son novedosos para este campo, y por ende, no están exentos de fallos. De esta forma se tiene la posibilidad de observar el posible comportamiento que tendría la ejecución del plan sobre el SEP y prevenir costosos errores. Existe varias herramientas de software para la simulación de sistemas de potencia que se pueden utilizar para esta tarea, pero lo imprescindible para el funcionamiento de ellos es un formato de entrada donde se especifica la información asociada al SEP, la cual es inservible en su estado original, siendo necesario aplicar una transformación a esta, obteniéndose como resultado un archivo en la forma de varios formatos, por 24.

(32) Capítulo 2: Modelo de Negocio y Requisitos ejemplo .RAW (PSS/E) y últimamente se ha estado utilizando un formato XML bajo un esquema denominado ODM, orientado a brindar un formato común exclusivamente para la simulación (Milano, Zhou et al.). Una vez obtenidos el plan de restauración y la información del SEP en el formato .RAW (opcionalmente ODM) se procede a simular el proceso de restauración. Esto se realiza enviando al simulador de forma secuencial, instantáneas del estado del sistema de potencia en la forma de un archivo .RAW para el cálculo numérico de las restricciones no-lineales (tales como cálculo de flujo de potencia, voltaje en barras, ángulo de fase en barras, etc.) de cada estado del sistema de potencia en función de los cambios de estado del sistema de potencia producido por las acciones descritas en el plan. Si en una instantánea (.RAW) existe una violación sobre las restricciones en el proceso de simulación (por ejemplo sobre voltajes en barras), el simulador es capaz de notificarlas en el reporte de resultados. Procesos a Automatizar Luego de un análisis en conjunto con el cliente para determinar las posibilidades de automatización de los procesos descritos anteriormente, se llegó a la conclusión de que todos son automatizables. No obstante, se decidió excluir el proceso de simulación, dándole seguimiento solamente hasta el diagrama de Casos de Uso del Negocio. Esto se debe fundamentalmente al poco tiempo disponible para el desarrollo de este proyecto. 2.2. Reglas de Negocio. Para este negocio fueron identificadas las siguientes reglas: 1. La información del SEP debe cumplir con la ontología CIM según el estándar IEC 61970 -301. 2. En la información del SEP no pueden existir componentes cuyas propiedades tengan valor nulo. 3. El desarrollo de todas las actividades requiere de la existencia de la información del SEP.. 25.

(33) Capítulo 2: Modelo de Negocio y Requisitos 4. El planificador POPF2 debe ser ejecutado en una distribución Linux. 5. Para ejecutar el planificador debe contarse con la definición del dominio y del problema de planificación. 6. Al concluir el proceso de planificación automatizada, el usuario puede obtener un plan solución o un mensaje indicando que no existe una solución al problema. 7. Para proceder a la simulación de la restauración del sistema es necesario contar con la información del estado del sistema de potencia en un formato de simulación. 8. Al ocurrir un error de planificación debe abortarse el proceso de restauración. 9. La información original (CIM XML) de los elementos del sistema de potencia afectados por el plan debe conservarse. 10. Al cambiar el estado de un componente del SEP por una acción(es) del plan debe actualizarse su representación gráfica. 2.3. Actores y trabajadores del Negocio. En este negocio fueron identificados los siguientes actores: Usuario, Planificador y Simulador. El primero es la persona encargada de ejecutar la restauración del SEP. Este debe poseer conocimientos avanzados sobre los SEP y el uso de herramientas informáticas destinadas a este campo. Los actores Planificador y Simulador son sistemas informáticos y tienen las responsabilidades de construir el plan de restauración y comprobar el cumplimiento de las restricciones del sistema por el plan de restauración respectivamente. 2.4. Diagrama de Casos de Uso del Negocio. En esta sección se muestran el diagrama de Casos de Uso del Negocio (CUN) y una breve descripción de cada uno de ellos.. 26.

(34) Capítulo 2: Modelo de Negocio y Requisitos. Ilustración 6: Diagrama de Casos de Uso del Negocio. CUN1: Representación gráfica del SEP El objetivo de este CUN es ofrecer un diagrama que permita al Usuario visualizar el estado del SEP. Para ello debe realizar un análisis de la información del SEP con el fin de determinar las relaciones entre sus componentes, posteriormente debe trazar el diagrama auxiliado de una herramienta de software de dibujo de diagramas monolineales. Como resultado de este caso de uso se obtiene un diagrama de componentes del SEP. CUN2: Obtener plan de restauración Inicialmente el Usuario debe contar con la definición del dominio y del problema. Esta última se obtiene al desarrollar el CUN3. Posteriormente debe ejecutar en un terminal el proceso de planificación automática, pasándole como parámetros el dominio y el. 27.

(35) Capítulo 2: Modelo de Negocio y Requisitos problema en el orden en que se mencionan. Como resultado se obtiene el plan de restauración, el cual es imprescindible para el cumplimiento del CUN4. CUN3: Describir problema Para la realización de este caso de uso es aconsejable que el Usuario haya realizado un análisis previo de la información del SEP, esto lo logra efectuando el CUN1. Este caso de uso comienza cuando el Usuario desea obtener el plan de restauración (CUN2), con el objetivo de definir el problema en el lenguaje PDDL, obligatorio para la ejecución del planificador. Para ello debe abrir el archivo CIM XML que contiene la información del estado actual del modelo del SEP y luego se procede a definir el estado de sus componentes y el estado objetivo utilizando el PDDL. Como resultado se obtiene la descripción del problema en el lenguaje PDDL. CUN4: Simular el plan de restauración Este caso de uso tiene como objetivo simular el comportamiento del SEP ante la ejecución del plan de restauración obtenido en el caso de uso CUN2. Para ello el Usuario debe transformar la información bajo el estándar CIM XML al formato .RAW. Por cada acción del plan ejecutada se requiere actualizar el archivo .RAW y enviarlo al simulador para validar los cambios efectuados sobre el SEP. Si el simulador detecta errores se debe notificar al usuario para que adopte las medidas pertinentes. Al ejecutar la última acción del plan de restauración, si no ocurren errores, se obtiene la validación de las restricciones. 2.5. Requisitos funcionales. Luego de un análisis para determinar el alcance del proyecto se determinó que el proceso de simulación no se tendría en cuenta para la captura de requisitos, y por tanto tampoco para la fase de implementación. Esto se debe fundamentalmente al poco tiempo disponible para el desarrollo del proyecto. Su funcionalidad será suplida por el requisito número 6. A continuación se ofrece una especificación de los requisitos funcionales identificados. 1. Cargar la información del SEP almacenada en un archivo CIM XML. 28.

(36) Capítulo 2: Modelo de Negocio y Requisitos El Usuario debe tener la posibilidad de navegar por el sistema de archivos y seleccionar aquel que contiene los datos del SEP en el formato establecido por la empresa. Estos datos pueden estar almacenados en diferentes formatos, pero para el desarrollo de este negocio solo se utilizará el formato estándar CIM XML. 2. Construir diagramas mono-lineales interactivos de los componentes del SEP. El Usuario deberá ser capaz de representar gráficamente la información del SEP, e interactuar con los componentes gráficos, entiéndase seleccionar (uno o varios) y cambiar su posición, con el objetivo de personalizar la distribución en el área de trabajo del diagrama. 3. Editar propiedades de los componentes del SEP. Es necesario brindar la posibilidad de editar los parámetros de los componentes del SEP. 4. Describir el problema para planificación. La descripción del problema es imprescindible para la obtención del plan de restauración, por lo que es una utilidad que debe ser garantizada al Usuario. Como resultado debe obtener un archivo con la descripción del problema en el lenguaje PDDL. 5. Obtener plan para la restauración del SEP. Para esto el Usuario debe tener definidos el archivo del dominio y el problema de planificación, procediendo a ejecutar el proceso de planificación automática con una llamada paramétrica tendiendo a estos dos archivos como argumentos y obteniendo como resultado un archivo que especifica el plan de restauración. 6. Aplicar transformaciones al SEP según el plan de restauración. Una vez obtenido el plan de restauración el usuario debe tener la posibilidad de ejecutarlo sobre el modelo original del SEP para simular los cambios que ocurrirían con la aplicación de las acciones en los distintos pasos descritos en el plan. 7. Trazar el gráfico de la capacidad de generación total y el grafico de la capacidad de generación por cada uno de los generadores.. 29.

(37) Capítulo 2: Modelo de Negocio y Requisitos Con el objetivo de analizar el comportamiento de la potencia producida en función del tiempo por la posible ejecución del plan, el usuario debe poder visualizar dichos gráficos. 8. Exportar como imágenes el diagrama mono-lineal de componentes y los gráficos de capacidad de generación. Para facilitar el intercambio y el análisis de información, debe brindarse la posibilidad al Usuario de guardar el diagrama y/o el grafico capacidad de generación como imágenes. 2.6. Requisitos no funcionales. Una vez especificados los requisitos funcionales, se procede a especificar los no funcionales según su categoría: Portabilidad . El sistema debe ser ejecutable tanto en plataformas Windows, Linux como Unix.. . Existe una limitante en cuanto a la ejecución del planificador POPF2, está desarrollado solo para distribuciones Linux.. Tiempo de respuesta . Es importante reducir al máximo el consumo de tiempo durante operaciones secundarias,. entiéndase. actividades. complementarias. que. permiten. la. realización de los procesos fundamentales del negocio. 2.7. Diagrama de Casos de Uso del Sistema. En este apartado se expondrá el diagrama de los Casos de Uso del Sistema (CUS). Un aspecto importante a destacar es el uso de dos diagramas, esto se debe a que se desarrollaran dos aplicaciones: una aplicación principal, y otra secundaria que se encargará de gestionar la ejecución del planificador. El objetivo perseguido con esta estrategia es aislar al planificador de la aplicación, ya que este es un elemento que impide la portabilidad total del sistema.. 30.

(38) Capítulo 2: Modelo de Negocio y Requisitos. Ilustración 7: Diagrama de Casos de Uso del Sistema 1. Para una mejor comprensión del diagrama de Casos de Uso del Sistema es necesario aclarar algunos aspectos. Las relaciones expresadas mediante las líneas discontinuas que no poseen el estereotipo de inclusión indican una dependencia total de la realización del caso de uso al que están dirigidas. Además, al observar detenidamente el diagrama se puede apreciar una falta de trazabilidad con los Casos de Uso del Negocio, específicamente con el CUN Simular el plan de restauración. A este tema ya se hacía alusión en el análisis de los procesos a automatizar, pero se considera necesario reiterarlo para evitar confusiones.. 31.

(39) Capítulo 2: Modelo de Negocio y Requisitos Como se mencionaba al inicio de esta sección, el próximo diagrama está dirigido al desarrollo de una pequeña aplicación complementaria para manipular el planificador. En este se puede apreciar un actor llamado Cliente, este no es más que el sistema principal.. Ilustración 8: Diagrama de Casos de Uso del Sistema 2. 2.8. Descripción de los casos de uso del Sistema 1.. Caso de uso del sistema. Generar modelos. Actores. Usuario. Propósito. Obtener los modelos base para la realización del resto. 32.

(40) Capítulo 2: Modelo de Negocio y Requisitos de los casos de uso. Resumen. El caso de uso comienza al concluir el CUS Validar Archivo. El sistema procede a realizar un análisis topológico para generar el modelo Node-Breaker. El siguiente paso tiene como base el modelo mencionado anteriormente y consiste en otro análisis topológico que culmina con la generación del modelo Bus-Branch.. Responsabilidades. Generar los modelos Node-Breaker y Bus-Branch.. Casos de uso asociados. Abrir archivo CIM XML, Validar archivo, Representar gráficamente el SEP, Formular problema. Precondiciones. La información del SEP debe estar cargada.. Descripción Este caso de uso no es desarrollado directamente por el Usuario, sino que forma parte de la realización del caso de uso Abrir archivo. Además, este depende del resultado del CUS Validar archivo. Como objetivo se tiene la obtención de sendos modelos que serán la base para la realización del resto de los casos de uso, estos son: Node-Braker y Bus-Branch. Para la confección de estos modelos se utilizan dos algoritmos de procesamiento topológico que básicamente lo que hacen es recorrer la información del SEP y determinar las interconexiones lógicas y físicas que existen entre sus componentes. Es importante esclarecer que el modelo Bus-Branch es creado a partir del NodeBreaker. Post condiciones. Quedan generados los modelos Node-Breaker y BusBranch.. Caso de uso del sistema. Representar gráficamente el SEP. Actores. Usuario. 33.

(41) Capítulo 2: Modelo de Negocio y Requisitos Propósito. Obtener. una. visión. general. del. estado. de. los. componentes del SEP. Resumen. Este caso de uso ofrece la posibilidad de trazar dos diagramas de forma alterna, y comienza cuando el usuario selecciona el que desea visualizar. Para trazar el esquema seleccionado el sistema procede a realizar un análisis sobre el modelo correspondiente con el fin de distribuir gráficamente los componentes del SEP.. Responsabilidades. Dibujar un diagrama para cada modelo.. Casos de uso asociados. Generar modelos. Precondiciones. Los modelos Node-Breaker y Bus-Branch deben estar generados.. Descripción El Usuario es el actor responsable de la realización de este caso de uso, siendo su propósito obtener una visión del estado del SEP apoyado en los diagramas de la red eléctrica. El objetivo de este caso de uso es generar estos esquemas, exactamente uno por cada modelo, obteniéndose un diagrama Node-Braker y un diagrama BusBranch. Para realizar estos dibujos se utilizan dos algoritmos, uno para cada tipo de modelo, que se encargan de construir la representación gráfica de cada componente del SEP, así como de su distribución en un sistema de coordenadas cartesianas plano. Cada componente gráfico reflejará el estado de su correspondiente en la red eléctrica haciendo uso de una escala de colores. La actualización de los diagramas se ejecutará automáticamente ante cualquier cambio en la información del SEP. Post condiciones. Queda trazado el diagrama Node-Breaker o el diagrama Bus-Branch.. 34.