Implementación del Modelo de Información Común – CIM …

Implementación del Modelo de Información Común – CIM para la interoperabilidad entre aplicativos

utilizados para el análisis, modelado y caracterización de un sistema de

trasmisión eléctrica de potencia

Angie Zoila Palencia Torres

Universidad Nacional de Colombia

Facultad de Minas, Departamento de Energía Eléctrica y Automática

Medellín, Colombia

2020

Implementación del Modelo de Información Común – CIM para la interoperabilidad entre aplicativos

utilizados para el análisis, modelado y caracterización de un sistema de

trasmisión eléctrica de potencia

Angie Zoila Palencia Torres

Tesis de profundización presentado como requisito parcial para optar al título de:

Magíster en Ingeniería - Ingeniería Eléctrica

Director:

Doctor Ernesto Pérez González

Línea de Investigación:

Sistemas Eléctricos de Potencia

Universidad Nacional de Colombia

Facultad de Minas, Departamento de Energía Eléctrica y Automática

Medellín, Colombia

2020

Dedicatoria

A mis padres y hermano

Angelita Torres, Osvaldo Palencia Gil y

Osvaldo Palencia Torres, quienes me han

acompañado y apoyado en mi desarrollo como

persona y profesional. Siempre han estado

presente para brindarme un consejo, una

palabra de apoyo, un oído y una oración para

acompañarme en este proceso.

A mis compañeros de trabajo, amigos y seres

queridos

Quienes de una u otra forma hicieron parte de

este logro con sus palabras, permisos,

confianza, orientación, escucha, comprensión,

transferencia de conocimientos, entre otras

formas y expresiones de afecto que me

motivaron a seguir adelante con este objetivo.

Agradecimientos

Un agradecimiento especial a:

Las empresas XM Compañía De Expertos En Mercados S A E S P y Siemens Sociedad

Anónima que, por medio de la experiencia, se obtuvo el conocimiento e inspiración para el

desarrollo de este trabajo.

Ernesto Pérez González, Doctor en Ingeniería Eléctrica, docente de la Universidad

Nacional de Colombia, por su orientación, asesoría, seguimiento constante y disponibilidad

como director para el desarrollo de este trabajo de profundización.

Victor Manuel Meza Jiménez, MSc. en Ingeniería – Automatización Industrial de la

Universidad Nacional de Colombia, por su apoyo, orientación y aportes para la selección y

planteamiento del problema de este trabajo.

Jason Edwin Molina Vargas, Ingeniero Electricista de la Universidad Tecnológica de

Pereira, por su orientación, transferencia de conocimiento y aportes para el desarrollo de

este trabajo.

Brayan Andrés Arboleda Tabares, Ingeniero Electricista de la Universidad Nacional de

Colombia, por su apoyo entorno a algunos desafíos en la programación en Python, por su

motivación, escucha, compresión y perspectiva.

Resumen y Abstract IX

Resumen

En este documento, se evalúa la interoperabilidad entre aplicativos con el Modelo de

Información Común – CIM, el cual es comúnmente utilizado para el análisis, modelado y

caracterización de un sistema de transmisión eléctrica de potencia. La evaluación del

estándar CIM se realiza por medio de un modelo de un sistema de transmisión eléctrica

de potencia en estructura CIM y la descripción del proceso realizado para el intercambio y

actualización de la información a través de diferentes proveedores de aplicativos.

El intercambio y actualización de la información a través del modelo CIM se evalúa por

medio de la interacción entre 3 aplicativos diferentes, en el cual se evidencian los retos

para una correcta interoperabilidad, la independencia existente entre los aplicativos y la

dependencia frente a la interpretación de la norma del modelo CIM para la estructura de

intercambio información.

Palabras clave: Modelo de Información Común, IEC 61970, Interoperabilidad,

Sistemas de Potencia, DIgSILENT Power Factory.

X Implementación del Modelo de Información Común – CIM para la interoperabilidad

entre aplicativos utilizados para el análisis, modelado y caracterización de un

sistema de trasmisión eléctrica de potencia

Abstract

Implementation of Commun Information Model – CIM for interoperability between applications used for the analysis, modeling and characterization of an electrical

power transmission system

In this document, is evaluated the interoperability between Common Information Model –

CIM applications, mostly used for analysis, modeling, and characterization of a power

transmission system. The evaluation of the CIM standard is performed through a power

transmission system modeling using CIM structure, and the process description carried out

to the information exchanging and updating through different application providers.

The information exchanging and updating through the CIM model is assessed through the

interaction between 3 different applications, where is highlighting the challenges for true

interoperability, independence between applications, and interpretation’s dependence of

the CIM standard model for the exchange of information.

Keywords: Commun Information Model, IEC 61970, Interoperability, Power Systems,

DIgSILENT Power Factory.

Contenido XI

Contenido

Pág.

Resumen ........................................................................................................................ IX

Lista de figuras ............................................................................................................ XIII

Lista de tablas ............................................................................................................. XVI

Lista de símbolos y abreviaturas .............................................................................. XVII

Introducción .................................................................................................................... 1

1. Estado del arte.......................................................................................................... 5 1.1 Antecedentes ..................................................................................................... 6 1.2 Modelo CIM ........................................................................................................ 7

1.2.1 Lenguaje de modelo unificado – UML .............................................................. 8 1.2.2 Estructura de clases del modelo CIM ............................................................. 11 1.2.3 Conversión de un circuito a objetos CIM ........................................................ 15 1.2.4 Principales paquetes del IEC 61970 -301 ...................................................... 18

1.3 Aplicaciones del modelo CIM desarrolladas a nivel mundial ............................. 21 1.3.1 Seguridad y protección de la red eléctrica de potencia .................................. 21 1.3.2 Micro-Grid y Smart Grid ................................................................................. 23 1.3.3 Información centralizada ................................................................................ 24 1.3.4 Grandes volúmenes de datos ........................................................................ 25

2. Metodología ............................................................................................................ 29 2.1 Interoperabilidad CIM – Python ........................................................................ 31

2.1.1 Selección del versionamiento modelo CIM .................................................... 32 2.1.2 Selección de librería en Python ..................................................................... 34

2.2 Interoperabilidad CIM – Excel........................................................................... 41 2.2.1 Tabulación de CIM/XML con Excel ................................................................ 42 2.2.2 Exportar información a XML con Developer – Excel ...................................... 46 2.2.3 Exportar información con Macro – Excel ........................................................ 48

2.3 Lectura de archivos XML generados por Excel en Python ................................ 52 2.4 Actualización de la información en Python ....................................................... 53

3. Evaluación de la funcionalidad ............................................................................. 59 3.1 Evaluación del sistema consolidado exportado desde Python .......................... 59 3.2 Evaluación de la estructura del sistema CIM exportado desde otro aplicativo en desarrollo. ................................................................................................................... 64

XII Título de la tesis o trabajo de investigación

4. Conclusiones y recomendaciones ........................................................................ 73 4.1 Conclusiones .................................................................................................... 73 4.2 Recomendaciones ............................................................................................ 74

A. Anexo: Datos Importados desde XML con la herramienta de Excel ................... 75

Bibliografía .................................................................................................................... 77

Contenido XIII

Lista de figuras

Pág.

Figura 1-1: Clase UML, tomado de [5]. ...................................................................... 9

Figura 1-2: Herencia en un diagrama de Clase, tomado de [5]. ................................. 9

Figura 1-3: Asociación en un diagrama de clase, tomado de [5]. ............................. 10

Figura 1-4: Agregación en un diagrama de clase, tomado de [5]. ............................ 10

Figura 1-5: Composición en un diagrama de clase, tomado de [5]. .......................... 11

Figura 1-6: Ejemplo diagrama de clase para el Breaker, tomado de [5]. .................. 12

Figura 1-7: Ejemplo diagrama de clase para la conectividad, tomado de [5]. ........... 13

Figura 1-8: Ejemplo de conectividad, tomado de [5]. ............................................... 14

Figura 1-9: Ejemplo circuito con identificación de componente CIM, tomado de [5]. 16

Figura 1-10: Ejemplo de la instancia del transformador del CIM v15, tomado de [5]. . 17

Figura 1-11: Relacionamiento de paquetes del modelo CIM [5]. ................................ 19

Figura 2-1: Aplicación del modelo CIM. ................................................................... 29

Figura 2-2: Diagrama de metodología. ..................................................................... 30

Figura 2-3: Exportar CIM – DIgSILENT. ................................................................... 33

Figura 2-4: Exportación modelo CIM v15 fallida. ...................................................... 33

Figura 2-5: Lectura con PyCIM – Código. ................................................................ 34

Figura 2-6: Lectura PyCIM modelo CIM v14 advertencias. ...................................... 35

Figura 2-7: Resultado de lectura modelo CIM v14 con PyCIM. ................................ 35

Figura 2-8: Escritura PyCIM – Código. ..................................................................... 35

Figura 2-9: Resultado de escritura modelo CIM v15 PyCIM. .................................... 36

Figura 2-10: Archivo creado en modelo CIM v15 por PyCIM – Código. ..................... 36

Figura 2-11: Archivo modelo CIM v14 por DIgSILENT – Código. ............................... 37

Figura 2-12: Archivo modelo CIM v15 creado PyCIM. ............................................... 37

Figura 2-13: Lectura modelo CIM v15 creado por PyCIM en DIgSILENT. .................. 38

XIV Título de la tesis o trabajo de investigación

Figura 2-14: Comparación CIM v14 con CIM v15 - PyCIM para los

TransformerWinding. ...................................................................................................... 39

Figura 2-15: Lectura con xml.dom.minidom – Código. ............................................... 39

Figura 2-16: Lectura elementos con xml.dom.minidom – Código. .............................. 40

Figura 2-17: Resultado de lectura de elementos con xml.dom.minidom. ................... 40

Figura 2-18: Esquema Interoperabilidad CIM- Excel. ................................................. 42

Figura 2-19: Elementos Generating Unit en XML – Excel. ......................................... 42

Figura 2-20: Class cim:GeneratingUnit, tomado de [23]. ............................................ 43

Figura 2-21: Developer – Excel. ................................................................................. 43

Figura 2-22: Advertencia esquema de datos XML – Excel. ........................................ 44

Figura 2-23: Visualizador del esquema fuente XML – Excel. ..................................... 45

Figura 2-24: Visualización de datos XML – Excel. ..................................................... 47

Figura 2-25: Esquema para macro Generating Units XML – Excel. ........................... 48

Figura 2-26: Visualización de herramienta para exportar XML – Excel. ..................... 49

Figura 2-27: Visualización archivo XML exportado con macro – Excel. ..................... 50

Figura 2-28: Detalle archivo XML exportado con macro – Excel. ............................... 51

Figura 2-29: Lectura de archivos con xml.dom.minidom – Código. ............................ 52

Figura 2-30: Lectura de XML (Developer) – Código. .................................................. 52

Figura 2-31: Lectura de XML (Macro) – Código. ........................................................ 53

Figura 2-32: Lectura elementos con xml.dom.minidom – Código. .............................. 54

Figura 2-33: Lectura elementos con xml.dom.minidom del nuevo XML– Código. ...... 54

Figura 2-34: Identificación de los elementos a analizar – Código. .............................. 55

Figura 2-35: Identificación y lectura de atributos-parámetros del elemento – Código. 55

Figura 2-36: Actualización de la información identificada– Código. ............................ 55

Figura 2-37: Escritura XML – Código. ........................................................................ 56

Figura 2-38: Consola de salida – Código. .................................................................. 56

Figura 2-39: Mapa de ruta. ........................................................................................ 57

Figura 3-1: Consola de salida – DIgSILENT. ........................................................... 60

Figura 3-2: Editor de Objetos Relevantes – DIgSILENT. .......................................... 60

Figura 3-3: Editor de Objetos Relevantes Generadores – DIgSILENT. .................... 61

Figura 3-4: Sistema inicial vs sistema actualizado – Código. ................................... 61

Figura 3-5: Validación de parámetros de elementos analizados. ............................. 62

Figura 3-6: Validación de ausencia de parámetros de elementos analizados. ......... 63

Figura 3-7: Representación de elementos básicos – Editor de Modelo CIM. ........... 65

Contenido XV

Figura 3-8: Error importar archivo XML del Editor de Modelo CIM en DIgSILENT. .. 66

Figura 3-9: Mensajes al importar archivo del Editor de Modelo CIM - DIgSILENT. .. 67

Figura 3-10: Estructura Terminal – DIgSILENT. ......................................................... 69

Figura 3-11: Estructura Terminal – Editor de Modelo CIM. ........................................ 70

Figura 3-12: Validación de parámetros elemento Terminal – Editor de Modelo CIM. . 71

Contenido XVI

Lista de tablas

Pág.

Tabla 1-1: IdentifieldObject modelo CIM [5]. .............................................................. 11

Tabla 1-2: ConductingEquipment CIM [5]. ................................................................. 14

Tabla 1-3: Ejemplo circuito clase CIM [5]. ................................................................. 15

Tabla 1-4: Equipment Containment CIM [5]. .............................................................. 17

Tabla 1-5: Características generales de las aplicaciones del modelo CIM

desarrolladas a nivel mundial. ........................................................................................ 27

Contenido XVII

Lista de símbolos y abreviaturas

Abreviaturas Abreviatura Término

BPMN Business Process Modeling Notation

CIM Common Information Model

DAM Day-Ahead Market

DMS Distribution Management System

DOM Document Object Model

EMS Energy Management System

EPRI Electric Power Research Institute

ERCOT Electric Reliability Council of Texas

FNCER Fuentes No Convencionales de Energía Renovable

ICCP Inter-control Center Communications Protocol

ICT Information and Communication Technology

IEC International Electrotechnical Commission

NERC North American Electric Reliability Council

OPC Open Platform Communication

OPC UA OPC Unified Architecture

PMU Phasor Measurement Units

RDF Resource Description Framework

SCADA Supervisory Control And Data Acquisition

SCL Substation Configuration description Language

SDO Standards Development Organizations

SIN Sistema Interconectado Nacional

UML Unified Modeling Language

VPP Virtual Power Plant

XML Extensible Markup Language

Introducción

La gestión del sistema eléctrico de potencia cada vez es más compleja, debido a que la

red se va expandiendo, se integran nuevas fuentes de generación, tales como las Fuentes

No Convencionales de Energía Renovable (FNCER), las cuales generan nuevas

dinámicas en el sistema eléctrico de potencia y los desarrollos tecnológicos en los equipos

de medidas y software brindan una mayor cantidad de información en menor tiempo, lo

que hace que exista una diversidad de aplicativos que gestionen la información recibida

del estado del sistema eléctrico de potencia.

Debido a que la mayoría de las herramientas y aplicativos que los proveedores de equipos

y sistemas desarrollan su propia semántica como alternativa de solución o mejora a un

problema en específico, hace que los sistemas de información que proporcionan

información sobre las condiciones y estados de la red eléctrica de potencia no compartan

la misma semántica, ni la misma estructura de datos que se intercambia en una plataforma

de comunicación, supervisión y control para que pueda ser contenida y procesada por otra

diversidad de aplicativos que interactúan dentro de una misma plataforma de Supervisión,

Control y Adquisición de Datos (SCADA - Supervisory Control And Data Acquisition) de un

sistema eléctrico de potencia. Esto hace que muchos de los aplicativos trabajen de forma

independiente y se presente el problema de interoperabilidad entre estos [1].

La variedad de aplicativos y herramientas que se requieren para la gestión y supervisión

de un sistema eléctrico de potencia que recolectan la información de los equipos de

medida, mediciones en tiempo real, parámetros técnicos de los elementos de la red

eléctrica, restricciones, entre otros, brindan información que se utiliza para la supervisión,

modelado y control que permiten conocer en detalle y precisión las condiciones de la red

[2], lo cual ayuda a tomar decisiones y medidas preventivas para una operación segura y

confiable.

Por otro lado, a medida que las empresas del sector eléctrico implementan más equipos

para recopilar datos y los desarrollos tecnológicos avanzan mejorando la resolución,

2 Introducción

velocidad de procesamiento, recepción y envío de información, se incrementa la cantidad

de datos generados. Por lo anterior, se convierte en un reto adicional para la

interoperabilidad entre aplicativos tener que manejar grandes volúmenes de datos (Big

Data). Como es el caso, de los medidores últimamente implementados conocidos como

PMU (Phasor Measurement Units) donde la velocidad de muestreo es de 30 veces por

segundo el cual incrementa la cantidad de información a intercambiar [3].

Dentro de la gran cantidad de información que se intercambia existen las de carácter

pública y privada, por este último, el intercambio se debe realizar de forma segura según

sea requerido por el usuario o las políticas de seguridad de la información que se maneje

en las organizaciones [4].

La Comisión Electrotécnica Internacional (IEC - International Electrotechnical Commission)

convierten el modelo CIM como Norma Internacional con el propósito de facilitar la

interoperabilidad entre aplicativos o software implementados en el sector eléctrico para

que la transferencia de la información pueda ser manejada como fuentes independientes

de la arquitectura de software o de su plataforma operativa [5]. Este modelo es

implementado en los sistemas de gestión de energía (EMSs - Energy Management

Systems) debido a que produce una interfaz estándar desarrollada en forma de un

Lenguaje de Modelado Unificado (UML - Unified Modeling Language) que promueve el

intercambio de información independiente del lenguaje [3], [6].

A pesar del desarrollo y existencia de los estándares IEC 61970, el IEC 61968, y el IEC

62325 conocidos como modelos de información común (CIM – Common Information

Model), el cual, inicialmente fue desarrollado por la EPRI (Electric Power Research

Institute) y ahora hacen parte de una serie de estándares bajo la Comisión Electrotécnica

Internacional (IEC - International Electrotechnical Commission) que facilitan el intercambio

de información e interoperabilidad entre aplicativos al implementar un único tipo de

lenguaje, aún existen vacíos que dificultan la armonización entre aplicativos para el envío

y/o recepción de datos entre estos [4], [7], [5].

Como alternativa de mejora para la interoperabilidad entre aplicativos y el manejo de

grandes volúmenes de información como se presenta en la operación del Sistema

Interconectado Nacional (SIN), se tiene una cantidad significativa de datos proveniente de

diferentes fuentes y proveedores, que con lleva a un problema de interoperabilidad entre

Introducción 3

los aplicativos involucrados para la gestión del sistema eléctrico de potencia. Por lo

anterior, este trabajo implementará una arquitectura con formato CIM que contenga un

esquema y un conjunto de reglas para el modelado del sistema eléctrico de potencia, el

cual sea repetible y escalable [8].

El objetivo de este documento es analizar las características de interoperabilidad del

modelo CIM para sistemas de transmisión, mediante la implementación y comunicación de

aplicativos asociados a la parametrización, modelado y actualización de los parámetros de

los equipos y medidas en parte de un sistema de trasmisión eléctrica de potencia.

Inicialmente se tendrá la revisión de la literatura sobre el modelo CIM con el fin de

contextualizar y tener un mayor conocimiento del estado, aplicaciones y avances de esta

estructura de lenguaje unificado para la representación de un sistema de transmisión

eléctrica para su modelado y análisis. Luego, se muestran los hallazgos y se representa el

intercambio de la información entre aplicativos provenientes de fuentes diferentes de

información basado en el modelo CIM y por último se valida la funcionalidad en el uso de

una extensión del modelo CIM, con fines de facilitar el intercambio de información entre

aplicativos.

1. Estado del arte

La integración de las fuentes de energía renovable tiene cada vez más un mayor impacto

sobre la dinámica del sistema eléctrico de potencia en los niveles de alta tensión. Éstas al

estar conectadas a las redes de media y baja tensión, al considerar el mercado de energía

y las restricciones por parte de las infraestructuras de las redes de transmisión eléctrica,

aumentan las condiciones de inestabilidad del sistema eléctrico de potencia [9].

Adicionalmente, someten a los equipos a operar en sus límites físicos comprometiendo la

seguridad pública [8]. Esto lleva a buscar métodos que permitan obtener información

detallada y actualizada del sistema por medio de estándares que faciliten la comunicación

y la interacción entre aplicativos, para tener los parámetros técnicos actualizados e

integrados de un sistema eléctrico de potencia [10].

Enfocado en la necesidad de una interoperabilidad entre aplicativos, el presente trabajo

analiza el modelo CIM (Common Information Model) como herramienta para el intercambio

de información entre aplicativos, el cual es un modelo estándar descrito en UML (Unified

Modeling Language) que presenta una propuesta de intercambio de información necesaria

para la gestión de los sistemas eléctricos de potencia de forma organizada y estandarizada

[5].

El uso de un Modelo de Información Común – CIM facilita el intercambio de información

entre distintos fabricantes, simplificando la complejidad y los costos que implican los

sistemas de gestión de los sistemas eléctricos de potencia, en el cual se maneja los

dominios de interoperabilidad a nivel semántico y sintáctico. Estos dos dominios de

interoperabilidad hacen referencia a:

• Semántico: se encarga del significado en específico de los elementos, con el fin

que sean comprendidos por todas las aplicaciones que interactúen en el

intercambio de información, evitando los errores de interpretación al momento de

6 Implementación del Modelo de Información Común – CIM para la

interoperabilidad entre aplicativos utilizados para el análisis, modelado y

caracterización de un sistema de trasmisión eléctrica de potencia.

combinar información de diferentes fuentes. Es decir que cada elemento sea

nombrado igual independiente del aplicativo.

• Sintáctico: se encarga de la estructura y formato de los datos a intercambiar.

Debido a que la gestión de los sistemas eléctricos de potencia es realizada desde puestos

remotos, conformados por distintos aplicativos o desarrollos con funciones específicas

para la gestión, supervisión o control de estos, tales como el flujo de cargas, el análisis de

eventos transitorios, el estimador de estados, el análisis de los sistemas de protección, la

gestión de activos, el software SCADA utilizado para el control y supervisión de la red en

tiempo real, entre otros [11]. Existen diversos formatos o estructuras de almacenamiento,

recepción y envío de información que en la mayoría de las ocasiones los diferentes

aplicativos operan de manera individual, debido a que la tecnología desarrollada por los

fabricantes son muy propietarios, lo cual hace que exista información desactualizada,

inconsistente, dispersa y/o errada. En ese sentido, es preciso contextualizar el origen del

modelo CIM.

1.1 Antecedentes

El desarrollo del estándar del modelo CIM se originó principalmente en América del Norte,

de la mano del Consejo de Fiabilidad Eléctrica de América del Norte (NERC por sus siglas

en inglés), quien adoptó el modelo CIM para el intercambio de la información entre las

empresas de transmisión. El modelo CIM ha sido adoptado por la Red Europea de

Operadores de Sistemas de Transmisión Eléctrica (ENTSOE) y por muchas de las

empresas de servicios públicos de Europa, Asia y América del Norte [5]. Donde la mayoría

de las empresas de los servicios públicos de América del Norte eran quienes desarrollaban

actividades de integración entre aplicativos. Dada la desregularización de la industria del

sector eléctrico, la utilidad y necesidad de intercambiar información fue incrementando, por

lo que se promueve una operación confiable.

Por todo el desarrollo tecnológico, el crecimiento de la red eléctrica, los diferentes

softwares y arquitecturas disponibles para el manejo e intercambio de datos, esto se ha

convertido en un problema para el sector energético, y como alternativa de solución se

Capítulo 1 7

buscó un estándar que fuese abierto para la descripción de los datos del sistema de

energía, con el fin de ayudar a la interoperabilidad entre los aplicativos.

La aparición del estándar comenzó como parte del proyecto de Interfaz de Programación

de Aplicaciones del Centro de Control (CCAPI) en EPRI, para crear una definición común

de los elementos del sistema de energía para usar la Interfaz de Programación de

Aplicaciones del Sistema de Gestión de Energía (EMS).

Actualmente, el estándar es mantenido por el Comité Técnico de IEC 57, el cual es el

encargado de desarrollar estándares para la “Gestión de sistemas de energía e

intercambio de información asociado”. Este comité, está conformado por diferentes grupos

de trabajo que desarrollan y mantiene actualizado los estándares como:

• Modelo CIM

• IEC 61850

• IEC 60870-6 /TASE.2

El modelo CIM es mantenido por el Grupo de Trabajo 13 del comité técnico 57 como el

estándar IEC 61970-301 [5].

A continuación, se realiza una descripción más detallada sobre el modelo CIM, de

acuerdo con su estructura y aplicaciones encontradas en la literatura.

1.2 Modelo CIM

El modelo CIM elaborado por la EPRI (Electric Power Research Institute) propone un

modelo de información único, común a todas las aplicaciones encargadas de la gestión de

las redes eléctricas, denominado modelo CIM (Common Information Model) como un

modelo semántico para la descripción y organización de los componentes de un sistema

eléctrico, las cuales son necesarias para las aplicaciones involucradas en la gestión de la

red eléctrica. Luego la IEC (International Electrotechnical Commission) lo adoptó como un

modelo estándar para la gestión de los sistemas eléctricos [5], [12].

Las normas IEC 61970-301, IEC 61968-11 e IEC 62325-301 de forma colectiva definen el

modelo CIM. La norma IEC 61970-301 está definida para los sistemas de gestión de redes

de transporte o EMS (Energy Management System) y la norma IEC 61968-11 para los




sistemas de gestión de redes de distribución o DMS (Distribution Management System)

dirigida a la integración de los sistemas de información dentro de una compañía utilizado

para el seguimiento de activos, la programación del trabajo y la facturación hacia el cliente,

y por otro lado, para las comunicaciones del mercado de energía, se extendió ambos

modelos antes mencionados con el IEC 62325-301 para el intercambio de información

entre los principales participantes del mercado [12] [11] [10].

El modelo CIM viene descrito mediante diagramas de clases y diagramas de paquetes

UML, estos diagramas, permiten tener una visión general del sistema, indicando qué tipo

de elementos lo componen y cómo se relacionan entre sí logrando normalizar la forma en

que los datos se deben transmitir, reenviar y gestionar. A medida que se ha desarrollado

el estándar, se han definido diferentes formatos para el intercambio de grandes cantidades

de información como lo son el CIM/XML, CIM/XSD o el CIM/SVG [3] [13].

El estándar IEC 61970 conocido como modelo CIM mantenido por comité tecnológico TC

57 del grupo de trabajo 13 ha actualizado el estándar por medio de versiones, para el

correcto manejo y unicidad del lenguaje de modelo unificado CIM, el cual hace que el

mantenimiento y el intercambio de información entre aplicativos se dificulte al tener que

considerar los diferentes versionamientos para una estructura de la información [6] [5].

Este estándar está enfocado en las interfases de los sistemas de gestión de energía, como

la principal herramienta que provee un modelo de datos para el intercambio de datos

complejos que representen información sobre el sistema eléctrico de potencia, desde la

topología de la red simple y activos hasta los aspectos económicos. Como el estándar IEC

61968 que extiende el IEC 61970 hasta los sistemas de distribución [14].

1.2.1 Lenguaje de modelo unificado – UML

Para entender en detalle la estructura del modelo CIM, es preciso entender los diagramas

de clases UML y las entidades dentro de este. A continuación, se proporciona una

descripción de los elementos clave para el diseño del sistema con el lenguaje de modelo

unificado (UML) que son:

Capítulo 1 9

• Clases

Las clases son consideradas como la representación de un elemento u objeto que esté

modelado, el cual define cada tipo de componente dentro de un sistema y que puede tener

atributos y relaciones con otras clases. Para el CIM, estos corresponden a los elementos

físicos.

Figura 1-1: Clase UML, tomado de [5].

Nombre de la fuente: Basado en Common Information Model Primer, Third Edit. Palo Alto, 2015.

• Herencia

La herencia, define una clase como una subclase de otra clase. Es decir, se pueden crear

subclases y estas ser hijos de otra clase “padre”. Luego, todas las subclases pueden

heredar los atributos de la clase principal (padre).

Figura 1-2: Herencia en un diagrama de Clase, tomado de [5].


• Asociación

La asociación, son las relaciones que exista entre una clase y otra. Puede existir otras

relaciones además de la relación “padre-hijo”, como la relación con otro tipo de clase que

me brinde otra caracterización del elemento.




Figura 1-3: Asociación en un diagrama de clase, tomado de [5].


• Agregación

La agregación, es un tipo de asociación especial, que permite agrupar varias clases como

un contenedor de varias clases.

Figura 1-4: Agregación en un diagrama de clase, tomado de [5].


• Composición

La composición, hace referencia a otro tipo de agregación, donde se hace relevante para

la clase tipo contenedor, la existencia de al menos una clase o elemento asociado a este

para que pueda existir y que si se elimina la clase tipo contenedor, todos los elementos

asociados a este también son eliminados.

Capítulo 1 11

Figura 1-5: Composición en un diagrama de clase, tomado de [5].


Con las descripciones anteriores, se puede comprender mejor el Lenguaje de Modelo

Unificado (UML por sus siglas en inglés) para la representación de un sistema eléctrico de

potencia por medio de la estructura del modelo CIM.

1.2.2 Estructura de clases del modelo CIM

El modelo CIM tiene una estructura de clases, a pesar de que actualmente no tiene una

clase general que sea heredada por cada componente del sistema, es decir una super

clase. Sin embargo, existe la clase IdentifiedObject que es un tipo de clase base que puede

ser heredada, el cual su principal atributo, es permitir identificar el elemento, como un

identificador universal único llamado en el modelo CIM el MRID (Master Resource

Identifier) y un nombre común que sea reconocido para las personas del área.

El IdentifiedObject puede contener los siguientes atributos:

Tabla 1-1: IdentifieldObject modelo CIM [5].

Nombre Tipo Descripción

MRID String Identificación única

Name String Texto libre, podría no ser único

LocalName String El nombre debe ser único en su región

PathName String Identificación del nombre a través de sus padres

AliasName String Nombre alternativo, puede no ser único

Description String Descripción, puede no ser única

A continuación, un ejemplo del uso de la estructura de clases para definir un componente

del sistema eléctrico de potencia es el interruptor o Breaker en inglés, que es el utilizado

en la literatura por la EPRI en [5]. El Breaker por ser uno de los componentes más comunes

en un sistema eléctrico, permite ser detallado y clasificado por medio de la estructura de

clases facilitando la comprensión de las clases en el modelo CIM.




• Ejemplo de la definición del Breaker usando la estructura de clase

Por ejemplo, un Breaker es un tipo de Switch que puede ser operado por los equipos de

protección de (Protection Equipment), también, un Switch hace parte de la red física que

conduce electricidad, por esto es considerado como un elemento de conducción

(Conducting Equipment), dado que dentro del sistema puede existir equipos que no

conducen electricidad entonces, un elemento de conducción puede considerarse como un

tipo de equipo (Equipment) y un equipo puede ser considerado como un recurso del

sistema de energía (Power System Resource). Si se clasifica el Breaker con una estructura

jerárquica como la anterior descrita, se puede decir que: un recurso del sistema de energía

(Power System Resource) contiene equipos (Equipment), que dentro de los equipos se

encuentran los equipos de conducción (Conducting Equipment), dentro de los equipos de

conducción, están los interruptores (Switch), dentro de los interruptores, están los

interruptores de protección (Protected Switch) y dentro de los interruptores de protección

están los Breaker. Lo anterior se puede ver de forma gráfica en la Figura 1-6.

Figura 1-6: Ejemplo diagrama de clase para el Breaker, tomado de [5].


Capítulo 1 13

• Subclases

Siguiendo con el ejemplo anterior, el modelo CIM permite flexibilizar la clasificación o

caracterización de los elementos por medio de las subclases, donde se agrega

asociaciones a una clase que permite agrupar un conjunto de clases. Por ejemplo, existe

más tipos de interruptores de protección además del Breaker, que puede ser asociado a

la clase interruptores de protección (Protected Switch) y que estas nuevas clases

asociadas a los interruptores de protección heredan atributos de este. Este tipo de

jerarquías de clases permite hacer extensiones del estándar al permitir ampliar las clases

existentes.

• Conectividad de los elementos

La conexión dentro de los elementos de un sistema de potencia dentro del modelo CIM

está dado por medio de terminales y nodos de conectividad, como se puede ver en la

siguiente Figura 1-7. El modelo CIM no modela las interconexiones asociando cada

componente con los otros componentes a los que se encuentre conectado. Por su lado,

implementa un nodo de conectividad para representar con precisión el número de

elementos que se encuentren interconectados, y la definición de terminales hace relación

a que cada equipo de conducción tiene uno o más terminales asociados que a su vez están

asociados con un solo nodo de conectividad. Mediante este mecanismo de conectividad,

se define un nodo de interconexión de impedancia cero.

Figura 1-7: Ejemplo diagrama de clase para la conectividad, tomado de [5].





La relación de conectividad entre los terminales, los equipos conductivos y los nodos de

conectividad, se muestra a continuación en la Figura 1-8 con la representación gráfica de

pequeño circuito eléctrico que contiene un Interruptor, una carga y un segmento de línea.

Figura 1-8: Ejemplo de conectividad, tomado de [5].


Dentro del modelo CIM los equipos conductivos no están directamente relacionados con

los nodos de conectividad, sin embargo, si con los terminales. Es decir, un equipo

conductivo debe tener asociado uno o más terminales y estos terminales deben estar

asociados a un solo nodo de conectividad.

A continuación, se menciona los equipos conductivos de dos terminales dentro de la

estructura CIM:

Tabla 1-2: ConductingEquipment CIM [5].

Nombre Descripción

ACLineSegment Segmento de línea AC

DCLineSegment Segmento de línea DC

Jumper Puente

Fuse Fusible

Breaker Interruptor

Disconnector Seccionador

LoadBreakSwitch Interruptor de ruptura de carga

SeriesCompensator Compensador en serie

Capítulo 1 15

El resto de los equipos tienen un solo terminal, como es el caso de las cargas.

En general, el modelo CIM consiste en clases, las cuales están asociadas unas a otras y

representa prototipos para los objetos que necesitan ser caracterizados o agrupados. Esto

consiste en que las clases especificas tiene atributos y que estas pueden ser heredadas.

También, existen las asociaciones entre las clases y la facilidad de agrupar las clases en

paquetes que pueden describir las características básicas de la red, la topología de la red,

los aspectos de medición, los activos, entre otras [14].

1.2.3 Conversión de un circuito a objetos CIM

Como ya se ha descrito parte de la jerarquía de las clases para describir los componentes

de una red en CIM, como las terminales y los nodos de conexión, la idea es mostrar otros

componentes que hacen parte del sistema eléctrico de potencia en CIM.

• Generalidades de los componentes a objeto CIM

Cada elemento o componente dentro de un circuito tiene asignado una clase en el modelo

CIM. Por ejemplo, las cargas, líneas e interruptores, algunos mencionados en la Tabla 1-3

como sus asignaciones dentro de un circuito como se muestra en la Figura 1-9.

Tabla 1-3: Ejemplo circuito clase CIM [5].

Clase CIM Componente EnergyConsumer Carga

ACLineSegment Línea

Breaker Interruptor

BusbarSection Barra

SynchronousMachine Dispositivo electromecánico

GeneratingUnit Dispositivo electromecánico tipo generador




Figura 1-9: Ejemplo circuito con identificación de componente CIM, tomado de [5].


De la anterior representación queda faltando el trasformador de potencia, el cual ha tenido

unas variaciones desde la primera versión desarrollada. Sin embargo, en la Figura 1-10 se

encuentra la representación de un transformador con dos devanados, el cual consiste en

un trasformador con dos terminales, donde los terminales se encuentran asociados al

transformador, el cual también se encuentra asociado a las terminales de cada devanado

(representado con la línea continua y punteada). También contamos con una impedancia

y una admitancia del transformador. Este modelado correspondiente a la versión 15 del

modelo CIM incluye el paso del Tap, el cual está definido como asociaciones separadas

que puede incluir múltiples subclases para una mejor representación del equipo con sus

terminales y asociaciones que le permiten realizar un modelado más complejo para la

representación más realista de los diferentes transformadores existentes.

Capítulo 1 17

Figura 1-10: Ejemplo de la instancia del transformador del CIM v15, tomado de [5].

Nombre de la fuente: Basado en Common Information Model Primer, Third Edit., 2015.

• Contenedores de equipos

El modelo CIM cuenta con clases definidas para agrupar los elementos que son eléctricos

y no eléctricos como:

Tabla 1-4: Equipment Containment CIM [5].

Contenedor

de equipos Clase Descripción

Niveles de

tensión VoltageLevel

• VoltageLevel es subclase de EquipmentContainer.

• Los equipos no tienen un atributo en específico para

definir el nivel de voltaje, por ello están asociados a una

clase VoltageLevel.

• Está asociada con una instancia llamada BaseVoltage

(Define el voltaje nominal).

• Contiene solo los equipos interconectados al mismo nivel

de voltaje.

Subestaciones Substation

• Substation es subclase de EquipmentContainer

• Puede contener diferentes niveles de voltaje.

• Define una colección de equipos conductivos con el fin de

cambiar o modificar la energía eléctrica.

• Puede contener otras instancias o equipos que están

físicamente agrupados, pero no necesariamente

conectadas eléctricamente.

Líneas Line • Line es subclase de EquipmentContainer.

• Contiene la clase ACLineSegment.




Tabla 1-4: (Continuación)

Contenedor

de equipos Clase Descripción

Líneas Line

• Define parte de un componente que se extiende desde una

subestación, hasta un punto de interconexión adyacente.

• Puede contener varios segmentos de línea tipo AC o DC.

• No representa por si sola una pieza de equipo de conducción

física.

• Para los modelos de transmisión sólo contiene las clases

ACLineSegment y DCLineSegment.

• Para los modelos de distribución, puede contener todos los

equipos considerados dentro de un alimentador como

interruptores y transformadores.

• Unidades y lenguaje

El modelo CIM se ha desarrollado con el fin de tener un estándar abierto para la descripción

de los datos del sistema de energía, teniendo así, una representación de forma

generalizada dentro de la industria. Es por esto, que se considera de forma generalizada

el tipo de datos para las unidades, las enumeraciones y el lenguaje como sigue:

o Las unidades: son definidas de acuerdo con el sistema internacional de

medida, por ello las medidas de distancia y volumen son métricas, la

temperatura es medida en Celsius, entre otras.

o Las enumeraciones: corresponde a un listado de valores predefinidos, el

cual a un atributo se le asigna uno de estos valores.

o El idioma: todos los términos se definen en términos de inglés británico a

pesar de que el estándar se originó en América del norte.

1.2.4 Principales paquetes del IEC 61970 -301

El modelo CIM siendo parte de otra estructura compleja, cuenta con un grupo de paquetes

que consiste en agrupaciones de clases, el cual un paquete puede contener otros paquetes

Capítulo 1 19

y proveer una estructura jerárquica de los elementos en UML [5]. En la Figura 1-11 se

puede observar una representación de los paquetes del modelo CIM.

Figura 1-11: Relacionamiento de paquetes del modelo CIM [5].

Nombre de la fuente: Basado en Common Information Model Primer, Third Edit., 2015.

Las clases del modelo CIM completo, agrupa 29 paquetes, que dependen de su rol dentro

de la utilidad. Sin embargo, en esta sección se hace enfoque en los paquetes del estándar

IEC 61970-301, que contiene 8 paquetes principales y un paquete de dominio global para

definir lo tipos de datos [11].

Las características eléctricas básicas de una red eléctrica física están contenidas en los

paquetes Core, Wires y Topology, exceptuando la clase Measurement. Sin embargo, no

detalla las características de una red a nivel operativo y características adicionales de los

equipos. A continuación, se encontrará una breve descripción de los 8 paquetes

principales:

1. Core: contiene la clase padre PowerSystemResource, la cual es heredada por las

demás clases relacionadas con los elementos físicos de la red, así como los

contenedores de los equipos implementados para organizar los equipos en grupos,

niveles de tensión o equipos específicos contenidos dentro de una subestación.

2. Wires: contiene los componentes eléctricos de una red como transformadores,

líneas y conmutadores, así como las clases que detallan la disposición y la




configuración de los transformadores, las propiedades de las líneas, los equipos

conductores y equipos reguladores de conducción como los compensadores.

3. Generation: está compuesto por dos subpaquetes; Production, utilizado para definir

los diferentes tipos de generadores, incluyendo una jerarquía de clases para los

generadores térmicos e hidroeléctricos, para definir una unidad de generación de

energía se requiere una asociación con un objeto de clase SynchronousMachine,

clase contenida dentro del paquete Wires. GenerationDynamics incluye la

descripción de los motores principales, como las turbinas y las clases de varios

tipos de suministros de vapor y los diferentes tipos de calderas de combustibles

fósiles para calderas de carbón y gas.

4. LoadModel: contiene los modelos de carga o los modelos de consumidores de

energía por medio de curvas y datos asociados. La clase y subclases de

EnergyConsumer en Wires define el punto de conexión física en la red y el cliente,

como las asociaciones con modelos de demanda de carga para cargas no

conformes.

5. Topology: contiene los nodos de conectividad y terminales, que proporcionan

información de cómo están conectados los equipos. La clase de Nodo Topológico

se compone de nodos de conectividad conectados por interruptores cerrados. La

clase isla topológica contiene todos los nodos topológicos conectados

eléctricamente y como resultado una red eléctrica interconectada, este debe

contener una sola isla topológica.

6. Measurement: contiene la forma en que se toman las medidas de un recurso de

sistema eléctrico de potencia, para esto, se tiene dos formas de conectar las

mediciones, una es asociar la medición con algún terminal y la otra forma es asociar

una instancia de medición con un recurso del sistema de alimentación, que puede

incluir mediciones que no están relacionadas con la conectividad eléctrica como la

temperatura y peso, esta no representa un equipo físico.

7. Outage: contiene clases que permiten configurar la red de forma planificadas e

incluye clases para asociar con un Switch, con el fin de definir su estado en un

momento determinado. Esto, puede usarse para modificar la configuración de la

red en momentos específicos para realizar simulaciones.

Capítulo 1 21

8. Protection: permite definir la configuración y parámetros de los equipos de

protección como su límite actual, el retraso desde la detección del evento hasta la

operación, límites máximos y mínimo.

Adicionalmente, el modelo CIM también es implementado para el intercambio de

información que se utilizan en procesos de negocio y no solamente para la definición y el

intercambio de información de un modelo de un sistema eléctrico de potencia. Debido a

que el alcance del modelo CIM hoy en día es muy amplio, con la facilidad de implementar

extensiones, que faciliten la interoperabilidad. Aún el modelo CIM, se encuentra

constantemente en evolución y desarrollo en función de los requisitos que van emergiendo

en la actualidad del sistema eléctrico de potencia. Por esto, aun no es considerado un

modelo completo [5] [13].

1.3 Aplicaciones del modelo CIM desarrolladas a nivel mundial

En esta sección se describen las principales aplicaciones del modelo CIM a referenciadas

a nivel internacional, ilustrando las características y esquemas de operación.

1.3.1 Seguridad y protección de la red eléctrica de potencia

Ante la necesidad de favorecer la interoperabilidad que permitiera desarrollar y validar

acciones a implementar en la práctica, se realizó la simulación de sistemas ciber-físicos

que requirieron integrar distintos dominios de simulación [2]. En este, se presentó un

novedoso entorno de co-simulación usando la Integración de Sistemas de Potencia y

Tecnología de la Información y Comunicación (TIC) o por sus siglas en ingles ICT -

Information and Communication Technology, para la Evaluación en Tiempo Real -

INSPIRE (INtegrated coSimulation of Power and ICT systems for Real-time Evaluation).

En este, se planteó la integración de los sistemas de potencia y las TIC utilizando una

arquitectura de alto nivel HLA – High Level Architecture (IEEE Std. 1516-2010)

implementando los estándares industriales como el IEC 61850, la vinculación e

incrustación de objetos para los procesos de control (OPC - OLE for Process Control) y el

modelo de información común CIM, con el fin de mejorar la interoperabilidad, desarrollar y

validar soluciones próximas a la realidad. Los resultados de las simulaciones lograron

resaltar la complejidad que existe en la interacción de los sistemas de potencia y las TIC,




así mismo como la interdependencia que existe entre las herramientas utilizadas para la

representación del sistema eléctrico de potencia y las TIC evidenciando la necesidad de

un análisis integrado y de una interoperabilidad dentro de un sistema que cuente con

diferentes módulos como fuentes de información tanto para detectar un estado crítico del

sistema eléctrico de potencia, como para mandar las acciones de control para recuperar

el estado de la red después de una perturbación.

Con fines de aportar a la solución del problema de interoperabilidad dentro de un sistema

eléctrico de potencia en sus diferentes aplicaciones, varios autores han propuesto diversas

alternativas y necesidades de implementar una solución para la comunicación entre

aplicativos. Ejemplo de esto, en [14] se propuso desarrollar protecciones automatizadas

por medio de los estándares IEC 61850 y el IEC 61970 o también llamado modelo CIM, el

cual contribuyó a la interoperabilidad entre los diferentes tipos de protecciones para

aumentar la confiabilidad y seguridad de la red. Sin embargo, se evidenció que el CIM

cuenta con un número específico de modelos para las protecciones, lo cual limitaba la

representación de todas ellas y que la implementación solamente del estándar IEC6150

no es suficiente, debido a que este estándar es manejado principalmente para los

parámetros que están asociados directamente con el proceso. Una evidencia de esto es

que el estándar IEC 61850 no cuenta con los campos para guardar la información

relacionada con la impedancia de un transformador, lo que para el modelo CIM le es fácil,

dado que tiene la capacidad de guardar más detalles del sistema eléctrico de potencia.

Este desarrollo fue probado en dos ejemplos sencillos de protección contra sobrecorriente,

identificando los parámetros necesarios para la implementación del modelo CIM y

evidenciando las necesidades de comunicación entre el modelo CIM y el estándar IEC

61850 para la automatización de las protecciones avanzadas, al demostrar que aún se

presentan obstáculos al momento de poner los estándares IEC 61850 y al IEC 61970 a

funcionar juntos. Otro ejemplo de esto, se presenta en [17] donde se implementó el modelo

CIM como mejora al tiempo y precisión de la información para el estimador de estados.

Además de la implementación del modelo CIM se utiliza un modelo MASE (Multiárea SE)

el cual redujo la cantidad de información a intercambiar entre las subáreas de control y el

Coordinador Central (CC), utilizando XML/CIM para el intercambio de información. Como

una de las ventajas que se evidenciaron de este último, es que la implementación no

Capítulo 1 23

requirió cambio en los softwares de los propietarios y las bases de datos de las subáreas

y el CC.

1.3.2 Micro-Grid y Smart Grid

En [7] con el propósito de mejorar la interoperabilidad entre los aplicativos o módulos, se

propuso una arquitectura SCADA (Supervisory Control And Data Acquisition) basada en el

modelo de nube híbrida y una plataforma de servicio para la entrega y recepción de

información del estado de la Microred basado en un entorno de simulación donde se utilizó

el modelo de información común (IEC 61970 e IEC 61968, CIM / XML / RDF) para el

intercambio de información dentro de las plataformas de las micro redes. La arquitectura

propuesta cuenta con un modelo de entrega basado en SCADA y PaaS en conjunto con

los modelos de comunicación CIM para asegurar el intercambio de los datos de forma

confiable. Sin embargo, para implementar esta arquitectura se requirió de un conocimiento

detallado del sistema eléctrico, el cual contribuyó a la implementación del CIM sobre OPC

Unified Architecture (OPC UA). Por otro lado, en [6] se desarrolló un sistema de gestión

distribuida (DMS – Distribution Management System) donde se modeló el comportamiento

eléctrico, la configuración de la red con un módulo intermediario para el envío y recepción

de mensajes y una interfaz que permitió la visualización del sistema; todo esto, fue

implementado con tecnología de información y comunicación abierta. De esta manera, al

implementar el modelo CIM se logró integrar fácilmente a la red varios subsistemas lo que

facilitó la interoperabilidad dentro de la plataforma para la red inteligente. Adicionalmente,

En [6] se presentó un nuevo estándar internacional IEC 62656-3 que permite descomponer

un conjunto de datos en forma tabular llamado Parcellized-CIM el cual consiste en expresar

el modelo CIM en un conjunto de hojas de cálculo. Para lo anterior, los autores lo expresan

como una función que facilita la transformación de los metamodelos de CIM con forma de

un UML a los Parcellized-CIM donde la función de mapeo es el estándar IEC 62656-3, el

cual facilitó el tratamiento de los datos y la identificación de la versión de la aplicación del

CIM. Esto ayudó a mejorar la compatibilidad entre los modelos CIM con un UML de

diferentes versiones. Este aporte se ve limitado por el tamaño y complejidad de la red

debido que impacta el tiempo de respuesta de los análisis.




1.3.3 Información centralizada

En los sistemas eléctricos de potencia se ha implementado un tipo de base de datos común

que contiene la información necesaria para las aplicaciones de red, con el fin de respaldar

la confiabilidad de la operación en tiempo real. Ejemplo de esto, en [8] donde se

implementaron extensiones para el modelo CIM básico, debido a la carencia de algunas

de las herramientas que permitían implementar en sus aplicaciones información para el

sistema centralizado del Consejo de Confiabilidad Eléctrica de Texas (ERCOT - Electric

Reliability Council of Texas). En este, buscaban el intercambio de datos de forma confiable

para aprovechar efectivamente los limites dinámicos de los equipos cuando operan en sus

límites físicos y permitir así su clasificación dinámica. Esto, debido a las corrientes

económicas y las restricciones ambientales para la construcción de infraestructura

adicional de transmisión eléctrica, hace que los equipos existentes se vean en la obligación

de operar cerca de sus limitaciones físicas. Estos autores sólo se enfocaron en las

clasificaciones de las mediciones telemétricas e insumos para los cálculos basados en la

temperatura para el modelo del sistema de potencia trifásico balanceado y aunque los

ejemplos solo usaban segmentos de línea, aclaran que los desarrollos de las extensiones

del modelo CIM relacionadas con SCADA, ICCP, cálculos de funciones y clasificación de

equipos las metodologías implementadas son los flexibles para poderse aplicar a cualquier

otro problema relacionado con una extensión del modelo CIM basado en datos y que

cualquier equipo puede ser clasificado dinámicamente con el método propuesto.

Por otro lado, en [1] se presentó un sistema de correspondencia ontológica, el cual se

basaba en encontrar correspondencias complejas mediante el uso de nuevos métodos de

coincidencia realizando pruebas dentro de una red inteligente. Esto con el fin de obtener

alineaciones complejas que no fueron posibles de hallar con los igualadores genéricos.

Esta prueba fue realizada para obtener las alineaciones necesarias para realizar una

transferencia de la información bidireccional entre las ontologías del CIM y el SCL

(Substation Configuration description Language), archivos que contenían la representación

de 5 arquitecturas de subestaciones. Adicionalmente, en [15] se planteó un Modelo de

Información de Procesos por sus siglas en ingles PIM integrado con el modelo CIM para

modelar las operaciones relacionadas con el proceso la programación de la energía

desarrollando una nueva ontología que facilitó el intercambio continuo de información del

Capítulo 1 25

proceso. En este, se utilizó la ontología adoptando el modelo CIM para representar eventos

y la secuencia cronológica de las tareas modeladas para los procesos del sistema de

potencia, mejorando la trazabilidad de las ejecuciones de tareas, la trazabilidad de

mensajes y la validación de las operaciones de las utilidades.

Por otro lado, parte de la información que se maneja para la operación del sistema eléctrico

de potencia es de carácter privado. Por ello, se habla de ciberseguridad y del cómo el

desarrollo de extensiones en el modelo CIM permite el intercambio de información de forma

segura proponiendo perfiles de acceso y una arquitectura de mensaje seguro multi – SDO

(Standards Development Organizations) como mecanismo de seguridad para compartir

información. El modelo CIM permite definiciones estandarizadas del contenido del mensaje

relacionado con la ciberseguridad para la red y un modelo fiable para la red eléctrica física,

al estar en conjunto con otros modelos de dominio como la ciberseguridad mencionado en

[4].

1.3.4 Grandes volúmenes de datos

A medida que los desarrollos tecnológicos facilitan la recopilación de información a grandes

escalas se refleja la necesidad de manejar grandes volúmenes de datos (Big Data) como

lo manifiestan en [3], donde las empresas del sector eléctrico ahora cuentan con mucha

más información que antes. Debido a esto, se crea la necesidad de buscar más

herramientas que faciliten el procesamiento de datos que ayude a promover la eficiencia,

optimización, ahorro de costos, y la toma de decisiones, entre otros. Por ello, como

herramienta para la interoperabilidad entre softwares, en [3] implementaron el modelo CIM

como “un modelo de información estándar independiente del proveedor” el cual

proporciona un lenguaje único que permite que diferentes fuentes se puedan integrar,

facilitando el uso de la información recopilada.

También en [10] se propuso el uso del modelo CIM para mejorar la interoperabilidad

principalmente para el intercambio de información entre aplicaciones que facilitan la

administración de energía, operación y gestión de activos como las plantas de energía

virtual por sus siglas en ingles VPP – Virtual Power Plant. Las plantas de energía virtual

consisten en integrar varias fuentes de energía renovable el cual los autores de [10]

propusieron una arquitectura de comunicación y control para su supervisión y adquisición

de datos (SCADA). En este fue implementado el estándar IEC 61850 como protocolo de




comunicación en sitio para la comunicación entre dispositivos, y el modelo CIM como

protocolo de comunicación entre las plantas de energía virtual, las empresas de servicios

públicos y los comerciantes del mercado, logrando la comunicación entre los estándares

IEC 61850 y el IEC 61970 implementando extensiones y verificando que estos estándares

pueden contribuir sin problema a la integración de las DER a una VPP y facilitar la

interacción con los aplicativos del mercado.

En [16] implementaron un tipo de procesador utilizando los estándares de notación de

modelado de procesos de negocios (BPMN - Business Process Modeling Notation) para

representar los requisitos necesarios para la interoperabilidad en los procesos comerciales

y a partir de esta identificación realizar la representación de objetos UML en el modelo CIM

el cual facilitaba la reutilización de datos. Esta propuesta fue aplicada para derivar el

modelo CIM de la transacción del mercado diario (DAM - Day-Ahead Market) de la empresa

de distribución de la India por medio de la representación realizada del proceso comercial.

El método propuesto implicó identificar objetos de BPMN en función del proceso comercial,

para luego correlacionar los objetos en un lenguaje unificado creando un perfil en formato

CIM que facilitó el intercambio de información de un sistema de compras basado en DAM.

Este desarrollo no requiere de una nueva clase de objeto UML, sin embargo, se propuso

cuatro atributos de extensión para ser incorporado dentro del estándar IEC 62325, por la

necesidad de representar la identificación del tipo de roles de negocios realizadas por las

utilidades.

Tabla 1-5: Características generales de las aplicaciones del modelo CIM desarrolladas a nivel mundial.

Artículo Región o Pais Tipo de aplicación Características de aplicación

[2]Analyzing Cyber-Physical Energy Systems The INSPIRE cosimulation of

Power and ICT Systems Using HLA

Europa,

Alemania

Simulación

combinada de

sismas de potencia

y TIC

Dos casos de prueba:

- Estudios basados en una versión modificada del

sistema de prueba de Nueva Inglaterra (NETS) (IEEE 39-bus 10-machine)

- Presenta las interdependencias de sistemas de energía y TIC en un escenario que analiza las

PMU para monitoreando el estado en tiempo real del sistema de energía.

[14] Smart grid automation using IEC 61850 and CIM standardsEuropa,

AlemaniaSimulación

Por medio de la simulación y el uso de los protocolos de comunicación, se muestra la

automatización de la protección basada en la tecnología de las TIC de la red inteligente, y se

discuten los obstáculos que deben superarse para la realización de la automatización de la red

inteligente.

[7] SCADA as a service approach for interoperability of micro-grid platformsGrenoble,

FranciaSimulación

Simulación, donde se demuestra el problema de la interoperabilidad entre las infraestructuras de

investigación y las infraestructuras industriales.

[6] A multi-version CIM-based database platform for smart grid JapónDesarrollo e

implementación

- Permite diseñar y crear CIM Parcelada.

- Admite un sistema para el cambio de verisonamiento Parcellized-CIM.

- Proporciona una interfaz estándar para generar e intercambiar archivos CIM RDF / XML con los

usuarios de Parcellized-CIM independiente de la versión.

- Mejora la usabilidad del modelo CIM y proporciona una plataforma fácil de usar para los

usuarios del modelo CIM.

[8]Extending CIM standards to support exchange of ratings on dynamically

rated equipment

Texas,

Estados

Unidos

Simulación,

desarrollo e

implementación

- Toma el formato de intercambio de modelos CIM y lo implementa como un depósito de datos

común

- Permite la integración tanto de la nueva tecnología como del "fork-lifting" de las aplicaciones

existentes en ERCOT.

- Proceso repetible y escalable.

- Desarrollo y adición de las clases necesarias para las calificaciones dinámicas de los elementos

modelados.

[1] Ontology matching system for future energy smart grids EspañaDesarrollo y

simulación

- Desarrollo de un sistema de correspondencia ontológica.

- Alineamiento entre las ontologías el CIM y el SCL para la transferencia de la información de

forma bidireccional.

[15]Integration of Process Model and CIM to Represent Events and Chronology

in Power System ProcessesIndia

Modelado -

Simulación

- Adaptación del modelo CIM para la representación de eventos y cronología en la ejecución de

actividades.

-Semántica en la ontología de proceso, capacidad de seguimiento de tiempo, transparencia y

trazabilidad.

- Modelado de un proceso de negocio de programación de energía dentro del contexto de una

red eléctrica de la india.

- Integración de los sistemas de información, integración de los socios, la automatización de

procesos comerciales, flujo de trabajo y visibilidad en tiempo real de las operaciones.

[3] A Framework-Based Approach to Utility Big Data AnalyticsEstados

Unidos

Modelado y

desarrollo

- Modelado y desarrollo de software para abordar los problemas claves y análisis de Big Data.

- Promover la eficiencia, optimización, ahorro de costos, entre otros; con la recopilación masiva

de datos.

- Desarrollo de un marco de software basado en estándares para facilitar el desarrollo de

aplicaciones de analíticas de Big Data.

[10] Virtual Power Plant for Grid Services using IEC 61850Europa,

Suecia

Desarrollo e

implementación

- Evalúa la comunicación, la información y los requisitos funcionales de las plantas de energía

virtual (VPP).

- Se presenta una formulación conceptual de los requisitos de interoperabilidad.

- Se realiza la implementación en una en una red existente de 50 kV.

[16]Business Process Model for Deriving CIM Profile : A Case Study for Indian

UtilityIndia

Desarrollo y

simulación

- Creación de un perfil CIM a través de la identificación de los objetos comerciales BPMN.

- Se proponen cuatro atributos de extensión para ser incorporados con el paquete CIM IEC 62325

MarketsOperations para construir una aplicación de software CIM-compatible para

DAMpurchase.

- Resalta el beneficio del BPMN como mejora para la aplicación del CIM

[17]An Extension of Common Information Model for Power System Multiarea

State EstimationIndia

Desarrollo y

simulación

- Propone una extensión del Modelo CIM para cumplir con los requisitos de interoperabilidad para

la estimación de estados del sistema de energía.

- El método propuesto utiliza un enfoque SE (MASE) multiárea que se puede dividir en varias

subáreas controladas independientemente.

- Se amplía el modelo CIM para el intercambio de información entre el SE del MASE y el

coordinador central (CC).

[4]In the Face of Cybersecurity: How the Common Information Model Can Be

Used

Washington,

Estados

Unidos

Simulación

- Permitir el intercambio de información pública y privada de forma segura.

- Proporcionamos una arquitectura de ejemplo que podría beneficiarse de este enfoque de

mensaje seguro multi-SDO.

- Se identifica que el modelo CIM permite definiciones estandarizadas de contenido de mensaje

relacionado con la ciberseguridad para la red inteligente y proporciona un modelo de alta

fidelidad de la red eléctrica física.

2. Metodología

Para la administración de un sistema eléctrico de potencia, se requiere de información

confiable y consistente entre los diferentes aplicativos que se ven involucrados para una

operación segura y confiable de la red. Para esto, se plantea una interoperabilidad entre

los aplicativos DIgSILENT Power Factory, Python y Excel, que tienen la facilidad de

manejar el Lenguaje de modelado unificado – UML.

El aplicativo DIgSILENT Power Factory 15.1.7 (x86) Copyright by DIgSILENT GmbH ©

1986-2014 4011/24690 tiene la posibilidad de exportar e importar el sistema eléctrico de

potencia en formato CIM, el aplicativo Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020,

23:03:10) [MSC v.1916 64 bit (AMD64)] on win32, que brinda un lenguaje simplificado,

abierto y rápido, con posibilidades de integrar librerías que facilita la interacción con otros

formatos [18] y el Microsoft ® Excel ® for Office 365, cuya herramienta suele ser utilizada

como almacenador de información organizada de forma tabular.

En este documento se plantea la interacción entre estas 3 aplicaciones como se muestra

en la siguiente Figura 2-1.

Figura 2-1: Aplicación del modelo CIM.

Nombre de la fuente: Propio



caracterización de un sistema de trasmisión eléctrica de potencia

Primero, se toma como referencia el sistema eléctrico de potencia de 39 barras del cual se

exporta en formato CIM desde el aplicativo DIgSILENT [19] [20]. Luego, desde el aplicativo

de Python, se lee la información en formato CIM del sistema eléctrico de potencia de 39

barras con el fin, de tener una mayor flexibilidad en el manejo de los datos. Por otro lado,

se tiene de forma tabular en Excel la información de los parámetros técnicos del sistema

eléctrico de potencia con la facilidad de ser modificada, para que por medio de una macro

se pueda convertir la información de forma tabular a un archivo XML y, por último, ser

importado en Python. Esto con el fin, de actualizar la información del sistema eléctrico de

potencia y podamos tener una información consistente entre la parametrización de los

datos del sistema de potencia en curso y la nueva parametrización que se designe de

forma tabular.

Dentro de la interoperabilidad que involucra el modelo CIM que son a nivel semántico y

sintáctico. En la siguiente Figura 2-2 se presenta el diagrama de la metodología que se

desarrolló en este trabajo dadas las alternativas o posibilidades que brindan una

confiabilidad o soporte por parte de los aplicativos implementados, señalando las

dificultades que afectan la confiabilidad de la información en el desarrollo de la

interoperabilidad entre los aplicativos DIgSILENT, Python y Excel.

Figura 2-2: Diagrama de metodología.


Capítulo 2 31

Como elementos críticos dentro del modelo CIM, se consideran algunos que no hacen

parte de un equipo o elemento físico, sin embargo son necesarios para la correcta

simulación y representación del sistema. Algunos de estos son los voltages bases, la

región geográfica, la subregión geográfica, el área de control, entre otros, y a nivel de

interacción o relación entre los elementos o equipos se considera relevante que exista una

conectividad consistente entre estos, ya sea por medio de una conectividad o por medio

de una asociación.

A continuación, se realiza la descripción de los procesos realizados, los hallazgos y las

interacciones entre las aplicaciones implementadas, para la interoperabilidad y la

consistencia de la información intercambiada entre los aplicativos antes mencionados.

2.1 Interoperabilidad CIM – Python

Para la interoperabilidad entre los aplicativos DIgSILENT y Python se exporta el sistema

de ejemplo de 39 barras en formato CIM desde el aplicativo DIgSILENT, anotando que

este aplicativo utiliza el formato PFD por defecto para sus cálculos y manejo de la

información.

Luego, se procede a verificar con un lector de código la correcta exportación del archivo

tipo XML y su versionamiento desde DIgSILENT. Una vez teniendo el sistema de 39 barras

y verificado el versionamiento, el cual corresponde al formato CIM v14 (CIM/XML), se

importa el mismo sistema de donde se exportó en formato CIM, para validar que

DIgSILENT permite importar y exportar el sistema eléctrico de potencia en formato CIM

v14, el cual fue realizado con éxito [20].

Por otro lado, se implementa en Python un código que permita importar el archivo XML

correspondiente al sistema de 39 Barras en formato CIM. Para ello, se prueba dos

herramientas:

• Librería PyCIM [21]

• Librería xml.dom.minidom [22]

La librería PyCIM corresponde a una implementación desarrollada y mantenida por la

comunidad Python. El cual, corresponde a una implementación para la lectura y escritura




del modelo CIM de libre uso y de fácil instalación. Las características y descripción de esta

librería se puede ver en [21].

La librería xml.dom.minidom “es una implementación mínima de la interfaz DOM

(Document Object Model)” extraído de la biblioteca estándar de Python para el

procesamiento de datos estructurados. El modelo DOM es un “modelo de objetos”, es decir

basado en el diseño orientado a objetos, el cual permite la lectura de documentos XML.

En [22] se encuentra información sobre la implementación mínima de DOM, algunos

ejemplos y recomendaciones para su uso.

2.1.1 Selección del versionamiento modelo CIM

Debido a los diferentes versionamientos existentes del modelo CIM que brinda DIgSILENT

para la importación y exportación de archivos en formato CIM, se selecciona el modelo

CIM v14, por el soporte que DIgSILENT 15.1.7 le brinda a esta versión, de acuerdo con el

manual de usuario [20] y dado a otras pruebas que se desarrollaron como validación de la

selección de la versión a implementar, la cual estará descrita más adelante en el capítulo

2.1.2.

DIgSILENT 15.1.7 ofrece el versionamiento del modelo CIM por la ENTSO-2009 y la

ENTSO-2010, correspondiente al modelo CIM v14 y v15 respectivamente para la

exportación del sistema eléctrico de potencia que se encuentre activado como proyecto,

como se muestra en la Figura 2-3. Sin embargo, al momento de realizar la exportación del

ejemplo del sistema de 39 barras en formato CIM v15, el aplicativo muestra en la ventana

de salida errores al momento de ejecutar la exportación como se muestra en la Figura 2-4.

Donde en uno de los mensajes de error aparece que el aplicativo no cuenta con el formato

correcto para uno de los elementos del sistema debido al formato en el que se encuentra

representado y por ello no puede ser mapeado a la estructura en formato CIM v15.

Capítulo 2 33

Figura 2-3: Exportar CIM – DIgSILENT.

Nombre de la fuente: Tomada de DIgSILENT Power Factory 15.1.7

Figura 2-4: Exportación modelo CIM v15 fallida.

Nombre de la fuente: Tomada de DIgSILENT Power Factory 15.1.7

Por lo anterior, se genera la primera duda con respecto a la posibilidad que DIgSILENT

15.1.7 soporte la versión 15 del modelo CIM, siendo el modelo de 39 barras un sistema

eléctrico de potencia que se encuentra dentro de sus librerías de ejemplo.




Dado esta inconsistencia para la exportación de la estructura del sistema de 39 barras en

PDF a la estructura en formato CIM V15, se toma el sistema eléctrico de potencia de 39

barras en formato CIM v14.

2.1.2 Selección de librería en Python

La selección de una librería de Python se basó en la confiabilidad y el manejo del

versionamiento del sistema eléctrico de potencia de 39 barras en formato CIM v14. En

este, se pusieron a prueba dos librerías antes mencionadas PyCIM y xml.dom.minidom.

• Librería PyCIM [21]

La librería PyCIM ofrece la opción de lectura del formato CIM/XML como se muestra en la

Figura 2-5, donde la función “cimread” es utilizado para la lectura de un archivo XML. Esta

función, asigna una identificación única a los objetos CIM y serializa la estructura en un

diccionario de datos en Python.

Figura 2-5: Lectura con PyCIM – Código.

Nombre de la fuente: Propio.

Como resultado de la ejecución de la función “cimread”, el aplicativo arroja una serie de

mensajes de advertencias correspondientes a algunos atributos configurados dentro del

archivo XML en estructura CIM v14 importado, los cuales no son considerados como

atributos dentro del nuevo directorio creado en Python a través de la función “cimread”,

como se muestra en la Figura 2-6.

Capítulo 2 35

Figura 2-6: Lectura PyCIM modelo CIM v14 advertencias.


Adicionalmente, a los mensajes de advertencia, se arroja el número total de objetos

creados en la estructura CIM y el tiempo que tomó la función en crear este directorio con

los objetos correspondientes al sistema eléctrico de potencia de 39 barras importado. Ver

Figura 2-7.

Figura 2-7: Resultado de lectura modelo CIM v14 con PyCIM.


Con el anterior resultado, se comprueba que esta librería PyCIM soporta el modelo CIM

v14, a pesar de arrojar algunas advertencias sobre la interpretación del sistema eléctrico

de potencia, indicando que no considera algunos atributos para algunos elementos del

sistema.

Por otro lado, la librería PyCIM cuenta con una función que brinda la opción de escritura

en estructura CIM como se muestra en la Figura 2-9. Sin embargo, esta librería “cimwrite”

crea un archivo XML en formato CIM con versión 15 de forma serializada.

Figura 2-8: Escritura PyCIM – Código.





Al ejecutar la función “cimwrite”, el aplicativo arroja como salida el número de elementos

en formato CIM serializados y el tiempo que se tomó para realizarlo, como se muestra en

la Figura 2-9.

Figura 2-9: Resultado de escritura modelo CIM v15 PyCIM.


Adicionalmente, crea un archivo XML con el formato CIM en forma serializada y de

versionamiento número 15, como se puede ver la Figura 2-10. Esta estructura serializada

dificulta su interpretación dentro de un lector de código, lo cual implicaría otros desarrollos

o alternativas para la manipulación de los datos.

Figura 2-10: Archivo creado en modelo CIM v15 por PyCIM – Código.

Nombre de la fuente: Tomada del archivo exportado por “cimwrite”.

Por otro lado, se pueden comparar los resultados de lectura y escritura de la librería PyCIM,

al ver que durante el proceso de lectura (ver Figura 2-7) se obtienen un total 721 objetos

CIM en 0.48s para el sistema de 39 barras [19] y con la función de escritura de obtienen el

mismo número 721 de objetos serializados en un tiempo menor de 0.19s, indicando que

no hubo elementos perdidos en el proceso de lectura y escritura.

Relacionando el archivo inicial exportado en formato CIM v14 de DIgSILENT (Ver Figura

2-11) y el archivo creado por la librería PyCIM (Ver Figura 2-12), se evidencia la diferencia

del número de atributos configurados en el modelo CIM v14 y el modelo CIM v15, en el

que el modelo CIM v15 omite escribir los atributos con valores iguales a cero “0”, los cuales

toma por defecto iguales a cero “0”. También, se puede observar la diferencia de la versión

inicial del archivo XML del sistema de 39 barras que se importó a Python con modelo CIM

v14 y la versión del archivo XML creado la librería PyCIM con la función “cimwrite” como

el modelo CIM v15.

Capítulo 2 37

Figura 2-11: Archivo modelo CIM v14 por DIgSILENT – Código.

Nombre de la fuente: Tomada del archivo exportado por DIgSILENT.

Figura 2-12: Archivo modelo CIM v15 creado PyCIM.

Nombre de la fuente: Tomada del archivo exportado PyCIM.

Una vez teniendo el modelo del sistema eléctrico de potencia de 39 barras creado por la

librería PyCIM de Python como modelo CIM v15, se decidió importar este archivo XML

formato CIM v15 en DIgSILENT. Con el fin de validar el soporte de la lectura de la versión

15, con el sistema de DIgSILENT.

Al importar el archivo tipo CIM con el versionamiento número 15 en DIgSILENT, aparecen

varios mensajes de advertencias relacionados con la conectividad de los elementos y otros

mensajes de error asociados con la relación “padre – hijo” de los devanados de los

transformadores con los transformadores de potencia, como se puede ver en la Figura

2-13.




Figura 2-13: Lectura modelo CIM v15 creado por PyCIM en DIgSILENT.

Nombre de la fuente: DIgSILENT.

Como es conocido por el reporte técnico 2015 del Common Information Model Primer 3era

edición, donde se manifiestan cambios significativos en la estructura u organización del

modelo del transformador propuesto en la versión 14 con la versión 15 del transformador

[5], con los mensajes de advertencia de la Figura 2-6, donde se expresa que los

TransformerWinding no fueron considerados como miembros o hijos del

PowerTransformery. Comparando las dos estructuras XML se evidenció que la relación o

la asociación entre los devanados del transformador y el transformador de potencia no

fueron considerados. Por ello, los 12 mensajes de error asociados a los 12 transformadores

de potencia, ya que es una inconsistencia que el transformador de potencia no tenga

devanados asociados, a pesar de que cada uno de los devanados sí se encuentran

definidos, pero sin la relación TransformerWinding.MemberOf_PowerTransformer dentro

de la estructura CIM/XML indicando que no se encuentra asociado a ningún otro elemento.

En la siguiente Figura 2-14 se compara la estructura de la clase TransformerWinding para

el modelo CIMv14 implementado por DIgSILENT del lado izquierdo, con el exportado con

la librería PyCIM del lado derecho.

Capítulo 2 39

Figura 2-14: Comparación CIM v14 con CIM v15 - PyCIM para los TransformerWinding.

Nombre de la fuente: Tomada del archivo exportado PyCIM.

Adicionalmente, aparecen los 24 mensajes de error relacionados con la organización o la

estructura de los nodos topológicos del sistema, donde manifiesta que es incapaz de

conectar una terminal como objeto de cada uno de los devanados del transformador.

Por lo anterior, al presentar estas inconsistencias del manejo de las versiones con la

librería PyCIM se decidió buscar otra alternativa para la manipulación de los datos en XML.

Para esto se prueba con la librería xml.dom.minidom.

• Librería xml.dom.minidom

La librería xml.dom.minidom ofrece la opción de lectura de archivos XML en general, a

partir de la implementación mínima de la interfaz de Document Objet Model (DOM) con la

característica de ser una estructura más simple que un DOM completo una interfaz de

programación de aplicaciones (API). El análisis del archivo XML se realiza con la

importación de xml.dom.minidom y el uso de las funciones de análisis [22], como se

muestra en la Figura 2-15 donde la función parce toma el nombre del archivo XML para su

análisis.

Figura 2-15: Lectura con xml.dom.minidom – Código.





Una vez teniendo la lectura del archivo XML se puede realizar la identificación de los

elementos del sistema a través de la estructura del modelo CIM v14, como se muestra en

la siguiente Figura 2-16.

Figura 2-16: Lectura elementos con xml.dom.minidom – Código.


Con lo anterior, se obtiene el número único de identificación de cada uno de los elementos

por medio del “rdf:ID” y la cantidad de elementos contenidos en ello como se ve en la

siguiente Figura 2-17. Con el fin de ilustrar, se toma como ejemplo las 34 líneas y los 12

trasformadores que hacen parte del sistema eléctrico de potencia de 39 barras [19]. Sin

embargo, esto es escalable para todos los elementos del sistema modelados con el modelo

CIM v14 para nuestro caso.

Figura 2-17: Resultado de lectura de elementos con xml.dom.minidom.


Capítulo 2 41

Dado que la librería xml.dom.minidom no altera la estructura y el versionamiento del

archivo XML, se evidencia la facilidad que tiene para la manipulación de los datos, la

confianza en la identificación de los elementos dentro de la estructura del modelo CIM, y

su practicidad, se implementa la librería xml.dom.minidom como la herramienta para la

lectura del archivo XML con estructura del modelo CIM para el sistema eléctrico de

potencia a analizar correspondiente al sistema de 39 barras dentro del entorno de Python

[19].

2.2 Interoperabilidad CIM – Excel

Para la interoperabilidad entre los aplicativos Excel y Python, se procede a implementar y

analizar dos formas para exportar la información desde el aplicativo Excel como

herramienta que facilita contener y analizar información de forma tabular a un formato

CIM/XML. Para esto, se selecciona una parte del sistema eléctrico de potencia de 39

barras de prueba en forma tabular, para exportarlo a un archivo XML. Con el fin, que el

archivo XML exportado desde el aplicativo Excel, pueda ser analizado por el aplicativo

Python por la facilidad y ventajas de maniobra que se tiene de la información dentro de

este lenguaje de programación.

Primero, se toman los elementos Generating Unit del sistema de 39 barras del ejemplo en

formato CIM v14 exportado desde el aplicativo DIgSILENT como información de prueba en

XML para que sea manipulada de forma tabular. Luego, se prueba como primera opción

las funcionalidades de configuración y recopilación de datos rápidas y fáciles que brinda

Excel para la importación y exportación de archivos XML con la herramienta Developer,

como segunda opción, se desarrolla una tabla, que por medio de las entradas del modelo

CIM v14 de los elementos Generating Unit y el desarrollo de una macro, permite leer los

valores de los parámetros técnico de estos elementos y exportarlo en la estructura

CIM/XML.

Por último, una vez teniendo la información en XML, sea con la estructura generada por la

herramienta directa de Excel o por la generada por la macro desarrollada, el archivo XML

puede ser leído desde Python, para generar una actualización de o los parámetros técnicos

modificados desde la tabla de Excel al sistema de 39 barras CIM v14 base o principal

contenido en Python.




Figura 2-18: Esquema Interoperabilidad CIM- Excel.


2.2.1 Tabulación de CIM/XML con Excel

La información de forma tabular que contiene los parámetros técnicos se puede obtener a

través de la importación desde una estructura XML a Excel o a través de la construcción

manual de la información. Para este caso, se importa a Excel un segmento de la estructura

completa del sistema de 39 barras correspondiente a los elementos Generating Units de

la estructura CIM del archivo XML (Figura 2-19), el cual se utiliza como elementos que

contienen una identificación y unos parámetros técnico que pueden ser modificados dentro

de un sistema de potencia, cuya visualización de forma tabular facilita el análisis y

modificación de los valores contenidos en este.

Figura 2-19: Elementos Generating Unit en XML – Excel.


Según la estructura definida para los elementos GeneratingUnit dentro de su ontología

mostrada en [23], se identifican algunos parámetros de lo que puede contener esta clase

GeneratingUnit con sus equivalentClass y sus características en cuanto a su asociación.

Capítulo 2 43

Figura 2-20: Class cim:GeneratingUnit, tomado de [23].

Nombre de la fuente: Class cim:GeneratingUnit [23].

La importación de estos elementos contenidos en CIM/XML, se realizará con la

herramienta que brinda Excel desde la barra de herramienta Developer, opción Import

(Figura 2-21); el cual, se encarga de utilizar el esquema del archivo importado y asociarlo

con un esquema interno de Excel para conseguir la mejor representación de la información

contenida en XML a una forma tabular y así lograr tener la información como recurso para

su configuración o modificación [24].

Figura 2-21: Developer – Excel.

Nombre de la fuente: Tomado de Microsoft ® Excel ® for Office 365




Una vez se selecciona el archivo XML de prueba que contiene los Generating Units, la

herramienta arroja un mensaje de advertencia, el cual manifiesta que el recurso no está

referenciado a un esquema conocido, por ello Excel le asignará uno basado en la fuente

de datos XML (ver Figura 2-22). Lo anterior indica que el programa no reconoce la

estructura CIM y que implementara un esquema basado en XML como fuente de

información.

Figura 2-22: Advertencia esquema de datos XML – Excel.


Luego, al dar clic en Ok, la herramienta permite seleccionar la ubicación en la que se desea

colocar la información dentro de una hoja de trabajo existente o dentro de una nueva hoja.

Una vez seleccionada la ubicación deseada para la importación de los datos de forma

tabular, se despliega la información correspondiente a los Generating Units contenidos en

estructura CIM de un archivo XML, ahora en la hoja de cálculo.

Con la opción Devoloper – Source (Figura 2-21) se puede visualizar el esquema

implementado por Excel para la importación de los datos desde un XML. En la siguiente

Figura 2-23, se muestra de forma jerárquica el esquema inferido del archivo de datos XML

a el mapa en Excel, el cual implementa un esquema generalizado de “niveles” ns1, ns2,

ns# (namespaces), que corresponde a los nombres de espacios creados de forma ficticia

para la creación de casos de prueba [25]. Además, por medio de la opción Map Properties

dentro de la misma herramienta Developer se puede manipular el comportamiento de los

datos XML como: el enlace, el formato y el diseño.

Capítulo 2 45

Figura 2-23: Visualizador del esquema fuente XML – Excel.


Adicionalmente, con esta herramienta brindada por Excel, se puede modificar, agregar o

eliminar información de la estructura de datos de forma tabular. Una de las ventajas de

esta herramienta, es que permite actualizar los datos desde el archivo XML a Excel por

medio de la opción Refresh Data (ver Figura 2-21). Es decir, si algún valor del archivo XML

es modificado directamente en el XML, por medio del Refresh Data se puede actualizar

este valor en de la tabla de Excel de acuerdo con lo modificado en el XML. Los datos

Importados pueden visualizarse en el Anexo 1.

Por otro lado, con la información de forma tabular, se analiza la opción de poder exportar

esta información a un archivo XML, con el fin de tener en CIM/XML la información que haya

sido actualizada o modificada desde tablas. Esto debido a que la mayoría de los agentes

o entidades manejan con mayor facilidad la información de sus activos y parametrizaciones

de forma tabular. Para ello, se realiza la exportación de dos formas, la primera es la

evaluación de la misma herramienta brindada por Excel con el Developer opción Export y

la segunda es la implementación de una macro que permita exportar la información de

forma tabular a la estructura CIM a partir de un esquema base.




2.2.2 Exportar información a XML con Developer – Excel

Para la exportación de la información desde una hoja de Excel a un XML, se realiza primero

por la misma herramienta brindada por Excel que se utilizó para la importación de un

documento XML a una tabla en Excel analizada en el subcapítulo anterior 2.2.1.

Por medio de la pestaña Developer, opción Export (Figura 2-21) brindada por Excel se

exporta la información de forma tabular a una estructura XML, esta herramienta requiere

de un esquema (Source), que utiliza la aplicación como guía para la estructura que se

desee obtener la información en el archivo XML. Esto quiere decir, si contamos con una

información de forma tabular sin un esquema, la opción Export se encontrará deshabilitado

hasta que no se agregue un esquema por medio de Developer – Source y sea asignado a

la información de forma tabular que deseamos exportar a un archivo XML, una vez

asignado el esquema correctamente se habilita la opción de exportación del Developer.

Para este caso utilizamos la misma estructura del modelo CIM con el segmento

correspondiente a los Generating Units del sistema de 39 barras como esquema (Source)

como archivo XML (ver Figura 2-19). El cual, el sistema arroja el mismo mensaje

visualizado en la Figura 2-22, debido a que Excel no reconoce este esquema o estructura

del archivo seleccionado. Por ello al darle clic en Ok, Excel utiliza un esquema de su librería

que le permita representar la estructura del archivo XML propuesto, para utilizarlo como

guía para la estructura XML que se va a generar a partir de la tabla que contiene la

información y parametrización de los elementos Generating Units, el esquema

implementado por Excel se puede ver en la Figura 2-23.

Una vez asociado el esquema a la tabla con la información a exportar, podemos dar clic

en Export desde la herramienta Developer, permitiendo seleccionar la ubicación en la que

deseamos guardar el nuevo archivo creado en XML.

Luego de exportar la información tabular en formato XML, se verifica la estructura y

confiablidad de los datos con respecto a la información y estructura requerida. En la

siguiente Figura 2-24 podemos evidenciar la diferencia entre la estructura CIM (imagen

superior) y el esquema implementado por Excel por niveles “ns1, ns2” (namespaces)

(imagen inferior) y la consistencia de los datos. Adicionalmente, se resaltan las diferencias

encontradas a nivel de estructura debido a que el programa no identifica el esquema CIM

Capítulo 2 47

del archivo seleccionado como recurso para su análisis y estructuración de los datos

deseados. Sin embargo, implementa una representación genérica basada en Espacio de

Nombres (namespaces), como un contenedor abstracto que contiene a uno o más de uno

de los identificadores únicos que pueda existir [25].

Figura 2-24: Visualización de datos XML – Excel.


A pesar de que, la estructura utilizada por Excel para la exportación de datos no es la

misma CIM deseada para el archivo XML, existe una consistencia de los datos, el cual

depende del buen relacionamiento entre la estructura propuesta y la información

encontrada en la tabla; brindando así, confiabilidad de los datos en su transformación y se

logra la exportación de forma exitosa de la información en forma tabular con un formato

XML legible.

Como se pudo evidenciar, esta herramienta propuesta por Excel permite exportar los datos

de una tabla a un archivo XML de forma consistente, a pesar de que la herramienta de

Developer implementó un esquema sobre el espacio de nombres ns1, ns2, ns#

(namespaces).

Por otro lado, se debe considerar que, esta herramienta cuenta con algunas limitaciones

como: que la herramienta sólo permite exportar la información contenida en no más de

65.635 filas en total de la hoja de trabajo de Excel. Esto y algunas recomendaciones




sugeridas para la exportación en XML desde la herramienta Developer se encuentra en

[26].

2.2.3 Exportar información con Macro – Excel

Por otro lado, se implementa una macro cuya funcionalidad consiste en replicar un modelo

que con tenga una estructura en XML a partir de las entradas, atributos y valores que se

designen a estos elementos dentro de la tabla. Es decir, a partir de la identificación de las

entradas indicadas en la tabla, que coinciden con la estructura del archivo esquema XML,

modifica, reescribe o crea un elemento en el archivo nuevo exportado.

Para esta aplicación, se requiere de un esquema base de los elementos, atributos y valores

que se quiere modificar o reescribir con la información contenida en la tabla, para que

pueda ser exportada de acuerdo con el esquema propuesto en un archivo XML. En este

caso, se utiliza un segmento correspondiente a un Generating Unit que conforma el

sistema de prueba de 39 barras como se observa en la Figura 2-25, donde sólo se requiere

la información de la clase, los atributos y parámetros del elemento a modificar o reescribir

que se desee. Este esquema solo debe contener aquellos atributos o elementos que se

quieren modificar o reescribir. En caso de que se deje un valor dentro del modelo que no

se encuentre dentro de los atributos o parámetros a modificar o reescribir en la hoja de

Excel, este se sobre escribirá con el mismo valor que se encuentre en el esquema XML

seleccionado.

Figura 2-25: Esquema para macro Generating Units XML – Excel.


Capítulo 2 49

Se deben tener las siguientes recomendaciones para el esquema base, especialmente con

el contenido del archivo XML que utilizará la macro para realizar la transformación de los

datos de forma tabular a un archivo XML. Las consideraciones son:

• No se requieren las dos primeras líneas y la última línea de la estructura XML ya

que se encuentran programadas dentro de la macro para mantener el esquema,

versión y la estructura deseada.

• Dentro de los valores no puede existir espacios.

• El esquema sólo debe contener los elementos a modificar o reescribir.

La estructura de la hoja de Excel contiene un botón que solicita seleccionar el esquema

como un archivo XML que se desea implementar para el nuevo archivo XML que desea

exportar y ejecuta la macro, dentro de la hoja de cálculo se encuentran las aperturas o

entradas de los elementos o parámetros del archivo XML a modificar, el atributo a modificar

que corresponde a la apertura de la línea o del elemento del esquema, una enumeración

de los elementos a crear y una señalización “X” a cada una de las columnas activas que

contenga información que se desea utilizar o modificar para la creación del nuevo archivo.

Lo anterior, se puede ver en la siguiente Figura 2-26.

Figura 2-26: Visualización de herramienta para exportar XML – Excel.

Nombre de la fuente: Propio tomado de Microsoft ® Excel ® for Office 365

Para probar la funcionalidad de la macro, se implementa como estructura o esquema guía

uno de los Generating Units (ver Figura 2-25), se completa la información requerida por la

tabla y se asignan los valores a modificar con un texto de forma genérica que permita

validar la estructura, la modificación y creación de los elementos de los Generating Units

que se va a exportar en la estructura CIM/XML.




Al ejecutar la macro desde el botón y se le asigne el esquema a utilizar, se genera un

nuevo archivo XML con la información contenida en la tabla exportada como se muestra


Figura 2-27: Visualización archivo XML exportado con macro – Excel.


Como se puede observar en la anterior Figura 2-27, el nuevo archivo XML generado

mantuvo la estructura propuesta CIM para los Generating Units de las 10 unidades

deseadas y configuró el archivo XML con las aperturas y cierres correspondientes al

esquema utilizado para esta prueba.

Por otro lado, como se había mencionado, el esquema debe contener el o los elementos,

atributos y parámetros a modificar o reescribir que contendrá el nuevo el archivo XML que

se generará. Dado que dentro de las columnas configuradas en la tabla solo se

configuraron 5 entradas de las 12 para los 10 generadores creados, como se ve en la

Figura 2-26, y el esquema propuesto para un Generating Unit (ver Figura 2-25) contiene

los 10 parámetros del elemento Generating Unit perteneciente al sistema de 39 barras de

prueba, el nuevo archivo generado solo incluirá los nuevos valores modificados

correspondientes a las entradas asignadas dentro de la tabla. Sin embargo, aquellas

entradas que no estaban asignadas pero que se encontraban en el esquema, se reescribirá

con los valores existentes para todos los elementos creados. Esto se puede observar en

la siguiente Figura 2-28, donde los valores asignados para los atributos “rdf:ID” y

“rdf:resource” resaltados de azul y los valores correspondientes a los tipos

DatatypeProperty que fueron modificados dentro de la tabla, resaltadas en color naranjado

fueron asignados correctamente según lo parametrizado en la tabla. Pero, para los valores

Capítulo 2 51

de las entradas que no fueron referenciadas dentro de la tabla, se reescribieron para cada

una de las unidades “Unit#” que se crearon resaltadas en amarillo.

Figura 2-28: Detalle archivo XML exportado con macro – Excel.


Por lo anterior se recomienda dejar solamente en el esquema a representar las entradas

deseadas a modificar o crear, a menos que el objetivo sea replicar el mismo valor de un

parámetro en específico a todos los elementos.

Como resultado de esta prueba, se observa que hay consistencia de los datos que se

decidieron modificar, se conserva la estructura CIMv14 y que el archivo XML generado es

legible.

Luego de verificar la consistencia de los datos entre lo tabulado y lo generado, se genera

un XML a partir de los datos tabulados con una información realista, para que pueda ser

analizado dentro del aplicativo de Python para su interpretación y manipulación dentro de

este entorno de programación.




2.3 Lectura de archivos XML generados por Excel en Python

Con los archivos exportados de Excel, uno desde la herramienta Developer que ofrece

Excel en el subcapítulo 2.2.2 y el segundo desde el desarrollo realizado con la macro en

el subcapítulo 2.2.3, se procede a realizar su lectura dentro del entorno de Python para

realizar la modificación de los posibles valores o parámetros que pudieron ser modificados

de forma tabular y así ser manipulados y actualizados en el sistema eléctrico de 39 barras

de prueba.

Para la lectura desde Python del archivo XML generado desde Excel, ya sea por medio de

la herramienta Developer o a través de la macro, se utiliza la misma librería

xml.dom.minidom como se observa en la siguiente Figura 2-29 con “docExcel”, el cual

almacena la información de este nuevo XML como elementos tipo documents.

Figura 2-29: Lectura de archivos con xml.dom.minidom – Código.


Para la identificación de los elementos de los archivos XML se implementa

“.getElementsByTagName”. Dado que el archivo exportado por la herramienta Developer

realiza la estructuración de la información a partir de namespaces se debe cambiar este

tipo de nombrado dentro del código a diferencia del implementado como “cim” realizado

para la lectura del sistema de 39 barras de prueba ya implementado, así como se muestra


Figura 2-30: Lectura de XML (Developer) – Código.


Capítulo 2 53

Por otro lado, al realizar la lectura del archivo XML exportado desde Excel por medio de la

macro, existe una unicidad para la lectura de los elementos tal como se muestra en la

siguiente Figura 2-31 lo que puede evitar errores al momento de tener que adaptar el

código para la identificación de los elementos deseado dentro de este nuevo XML, que

puede contener modificaciones que se quiera ver reflejado en el sistema eléctrico de

potencia de 39 barras seleccionado como prueba.

Figura 2-31: Lectura de XML (Macro) – Código.


Debido que para leer el archivo XML exportado con la herramienta Developer de Excel se

requiere identificar el namespace asignado dentro el archivo XML generado para poder

identificar los atributos, elementos o parámetros, se procede a continuar con el XML

generado por la macro desarrollada en Excel, con el fin de tener unicidad de la información

manejada dentro del mismo entorno de programación Python.

2.4 Actualización de la información en Python

Con la correcta lectura del archivo XML exportado de forma tabular a un XML. Se realiza

por medio de la librería xml.dom.minidom en Python, la lectura de los elementos. Para este

caso, realizaremos la modificación de la información con los elementos Generating Units,

el cual, una vez se realiza la lectura del sistema completo de 39 barra de prueba, se

procede a realizar la lectura de la información contenida en el nuevo documento XML que

contiene la información de los parámetros técnicos de los elementos Generating Units y

los valores o parámetros que pudieron ser modificados por el usuario de forma tabular,

para que pueda ser contrastado con la información existente y se permita la actualización

de la información en el sistema eléctrico de potencia de 39 barras principal.

Una forma de representación del objetivo de esta sección se puede ver en la siguiente

Figura 2-32.




Figura 2-32: Lectura elementos con xml.dom.minidom – Código.


Una vez se ejecute el programa en Python, primero se realiza la lectura del archivo XML y

de todos los elementos (Figura 2-33), segundo se valida el elemento a modificar o los tipo

de elementos o la información que se encuentra en el nuevo documento de XML exportado

desde Excel (Figura 2-34), tercero se hace una comparación entre el elemento existente y

el ingresado por el nuevo documento (Figura 2-35), cuarto si se encuentra alguna

diferencia entre el valor existente y el nuevo valor, se actualiza el valor encontrado, para

el elemento y parámetro en específico (Figura 2-36) y por último se exporta un nuevo

documento XML con los parámetros y/o valores actualizados en la misma estructura CIM

del archivo de origen CIMv14.

Figura 2-33: Lectura elementos con xml.dom.minidom del nuevo XML– Código.


Capítulo 2 55

Figura 2-34: Identificación de los elementos a analizar – Código.


Figura 2-35: Identificación y lectura de atributos-parámetros del elemento – Código.


Figura 2-36: Actualización de la información identificada– Código.


Para la exportación del nuevo archivo XML con la información actualizada se implementa

la librería writexml, el cual permite crear un nuevo archivo XML sin que se pierda la

información del sistema original de prueba de 39 barras y para conocer el tiempo que tomó

el programa en ejecutarse se importa la librería “import logging”, se realiza la inicialización

y al finalizar el código, se imprime el tiempo de ejecución como se ve en la siguiente Figura

2-37.




Figura 2-37: Escritura XML – Código.


En la consola de salida, se realiza la extracción de la información de la cantidad de

elementos a analizar. Si se encuentra alguna diferencia entre los valores de los parámetros

existentes y los ingresados, se muestra el elemento con el valor previo y nuevo del

parámetro al cual se le realizará el cambio, luego se confirma el elemento y el valor

asignado del parámetro modificado y el tiempo que se tomó el programa para su ejecución

y exportación del archivo con la información actualizada en XML. Lo anterior se muestra


Figura 2-38: Consola de salida – Código.


Dado los marcos de interoperabilidad que involucra el modelo CIM que son a nivel

semántico y sintáctico, se presenta resaltado en color verde el camino de ruta que se

desarrolló en este trabajo dadas las alternativas que brindaban una confiabilidad y soporte

por parte de los aplicativos y en color rojo las alternativas brindadas por los aplicativos en

los cuales se encontraron inconsistencias o dificultades que afectan a la confiabilidad de

la información en el desarrollo de la interoperabilidad entre los aplicativos DIgSILENT,

Python y Excel.

Capítulo 2 57

Figura 2-39: Mapa de ruta.


3. Evaluación de la funcionalidad

Para evaluar la funcionalidad en el intercambio de información entre la lectura y escritura

realizado desde los diferentes aplicativos se evalúan dos casos. El primero validar que el

archivo exportado desde Python con la información consolidada y actualizada pueda ser

interpretado por el aplicativo de DIgSILENT y que a su vez los cambios se vean reflejados,

validando la diferencia o perdida de parámetros correspondiente a los elementos que se

encuentre actualizando. El segundo es evaluar un aplicativo computacional en desarrollo

que, a partir de la creación de una representación gráfica de un modelo de un sistema

eléctrico y la definición de su parametrización de manera dinámica dentro del aplicativo,

permite exportar la información del sistema eléctrico de potencia en una estructura

CIM/XML, al verificar si el documento generado puede ser interpretado por el aplicativo de

DIgSILENT y la validación de la pérdida o diferencias relacionadas con los parámetros de

los elementos dentro de la estructura CIM en relación con la estructura del modelo CIM

v14 referencial que puede interpretado por DIgSILENT.

3.1 Evaluación del sistema consolidado exportado desde Python

Para validar que la información y estructura del archivo generado por Python, es legible y

se evidencie los cambios o actualizaciones de la información realizadas, se importa el

nuevo archivo CIM/XML generado desde Python con la información actualizada y

consolidada, desde el aplicativo DIgSILENT.

Al importar el nuevo archivo XML “NewXML_39Bars.xml” desde DIgSILENT, el aplicativo

muestra por medio de ventana de salida que la importación se realizó de forma exitosa,

como se muestra en la siguiente Figura 3-1.




Figura 3-1: Consola de salida – DIgSILENT.


Luego, se valida que la información que fue actualizada por medio del aplicativo de Python

se vea reflejado en DIgSILENT. Para esto, se utiliza la herramienta del Editor de Objetos

Relevantes y se selecciona el elemento a visualizar que para este caso corresponde a las

unidades de generación, ver Figura 3-2.

Figura 3-2: Editor de Objetos Relevantes – DIgSILENT.


Esta herramienta, despliega en forma de lista todas las unidades de generación y por

medio de la pestaña Load Flow se puede visualizar la parametrización de estos elementos,

el cual permite de una forma práctica evidenciar que el cambio se vea reflejado en este

aplicativo y que el intercambio de información no se haya visto afectado por la

manipulación e interacción entre los diferentes aplicativos, conservando la estructura CIM

v14 y la consistencia de los datos. En la siguiente Figura 3-3 se puede evidenciar que el

parámetro de la potencia activa máxima operativa para la unidad de generación 1 (G 01)

ha sido modificada con el nuevo valor de 8000 MW, cuyo previo valor era de 8500 MW.

Capítulo 3 61

Figura 3-3: Editor de Objetos Relevantes Generadores – DIgSILENT.


Por otro lado, se puede hacer la validación por medio de un visualizador de código la

modificación del parámetro dentro del sistema de potencia de 39 Barras de prueba inicial

en CIM/XML en el lado izquierdo, con respecto al nuevo XML generado con la información

actualizada y consolidada desde Python en el lado derecho, como se muestra en la

siguiente Figura 3-4.

Figura 3-4: Sistema inicial vs sistema actualizado – Código.


Adicionalmente, por medio del aplicativo de Python se corrobora que todas unas unidades

de generación cuenten con todos los parámetros y en caso de que este faltando alguno, a

través de la ventana de salida aparece las unidades de generación totales que se analizan,

la o las unidades de generación que presente alguna inconsistencia, indicando qué




unidades presentan consistencias o inconsistencias en la cantidad de parámetros

encontrados en entre el documento original y el comparado.

Dentro de la ventana de salida del aplicativo de Python se despliega el resultado de los

Generadores analizados, indicando la consistencia en el número de parámetros de los

elementos analizados como se muestran en la siguiente Figura 3-5.

Figura 3-5: Validación de parámetros de elementos analizados.


Capítulo 3 63

A modo de prueba, se realizaron modificaciones en el número de parámetros para las

unidades de generación 09 y 07 con el fin de validar la correcta detección de las unidades

que conservan la consistencia en el número de los parámetros y de las unidades que

presentan inconsistencias. Como resultado, en la siguiente Figura 3-6 se puede evidenciar

la correcta identificación de los de las unidades que presentan inconsistencias en la

diferencia del número de parámetros entre el documento inicial y el puesto a prueba.

Figura 3-6: Validación de ausencia de parámetros de elementos analizados.





Con lo anterior, se puede corroborar que la actualización e intercambio de la información

entre los aplicativos se realizó de forma exitosa manteniendo la estructura CIM y la

consistencia de la información. Adicionalmente, se valida la posibilidad de encontrar

inconsistencias o perdidas de información en el número de parámetros de los elementos

analizados dentro de la estructura del Modelo CIM.

3.2 Evaluación de la estructura del sistema CIM exportado desde otro aplicativo en desarrollo.

Para evaluar la estructura CIM/XML que genera el aplicativo en desarrollo, el cual permite

por medio de la creación de una representación gráfica de un modelo de un sistema

eléctrico y la parametrización de manera dinámica de sus elementos dentro del aplicativo,

se procede a crear un pequeño sistema eléctrico con los elementos básicos como

generador, barra, carga, transformador, línea, seccionador e interruptor para validar la

estructura CIM dentro del archivo XML generado al momento de exportar la información

desde el aplicativo. Una vez dibujados y parametrizados los elementos básicos, se deben

parametrizar los elementos lógicos de la estructura del sistema como lo son: regiones

geográficas, subregiones geográficas, subestaciones y niveles de voltaje y voltajes base,

los cuales son esenciales dentro de la estructura CIM. El sistema eléctrico representado

de forma gráfica se muestra en la siguiente Figura 3-7.

Capítulo 3 65

Figura 3-7: Representación de elementos básicos – Editor de Modelo CIM.

Nombre de la fuente: Editor de Modelo.

Una vez dibujado y parametrizado el sistema, se procede a exportar la información en

formato CIM/XML. Luego, con un visualizador de código, se abre el archivo en formato

CIM/XML para validar la estructura y versionamiento del archivo el cual corresponde al

CIM v14.

Dado que el archivo corresponde al versionamiento CIM v14 soportado por DIgSILENT, se

importa este archivo CIM/XML en DIgSILENT, para validar si este aplicativo puede leer

esta estructura CIM v14 generado por este Editor de Modelo CIM. Sin embargo, una vez

se importa el archivo en DIgSILENT, se despliega unos mensajes de error como se

muestra en la siguiente Figura 3-8, indicando que el reporte completo se encuentra en la

ventana de salida y que la importación CIM falló.




Figura 3-8: Error importar archivo XML del Editor de Modelo CIM en DIgSILENT.


Para evaluar el motivo de la falla al momento de importar el archivo se analiza los mensajes

desplegados en la ventana de salida, el cual se resalta algunos de ellos como se muestra

en la siguiente Figura 3-9, donde se muestran 3 segmentos. La primera con unos mensajes

de advertencia indicando, que no soporta algunas de las clases empleadas dentro de este

nuevo archivo, como las unidades Unit, los interruptores Breakers, la carga empleada

NonConfromLoad, los seccionadores Disconnector, la clase análogo Analog y la línea Line,

la segunda con unos mensajes de error, el cual están relacionados con la clase Terminal

indicando que no puede crear el cubículo de conexión como “Terminal.TopologicalNode”

dado que el ID del Terminal no se encuentra, tercero unos mensajes de advertencia en la

configuración de la unidad de generación y del transformador de potencia, y finalmente, el

mensaje de error indicando que la importación ha fallado. Se debe considerar que los

mensajes de alerta o Warnings (wrng) no son críticos para la lectura de un sistema.

Capítulo 3 67

Figura 3-9: Mensajes al importar archivo del Editor de Modelo CIM - DIgSILENT.


Con lo anterior, y la relevancia que tiene los mensajes de error relacionados con la clase

Terminal, debido a que son los encargados de realizar la conectividad entre los elementos

del sistema eléctrico de potencia, se realiza un análisis al detalle de la estructura CIM para

evaluar las asociaciones, el reconocimiento y estructura implementada por los aplicativos

para a clase Terminal, es decir:

• Como la clase Terminal es reconocida en DIgSILENT

• Como el Editor de Modelo CIM como aplicativo generador de un archivo con

estructura CIM/XML realiza la conectividad entre sus elementos con la clase

Terminal.

Para ambos casos, se realiza un análisis y seguimiento de las asociaciones utilizadas entre

las diferentes clases que involucra el elemento, el terminal y el nodo de conexión. Para la

estructura CIM v14 implementada en DIgSILENT se tiene las siguientes clases relevantes

dentro de las asociaciones implementadas entre el elemento (equipo conductivo) y el nodo

de conectividad mostrando la definición basado en [27] desde su ontología como sigue:

• cim:TopologicalNode: Corresponde a un conjunto de nodos de conectividad

(ConnectivityNode) para un modelo de subestación detallado, el cual se encuentran

conectados entre sí a través de cualquier equipo de conmutación cerrado,

incluyendo los puentes (Jumpers). Los nodos topológicos (TopologicalNode)




cambian de acuerdo con los cambios de estados de la red actual; por ejemplo,

cuando los conmutadores, interruptores, entre otros, cambian de estado. La

implementación de los nodos topológicos de esta manera, también son

denominados “buses” (busses).

• cim: ConnectivityNodeContainer: Corresponde a una clase base para los objetos

que puede contener nodos de conectividad o nodos topológicos.

• cim:Terminal: Corresponde a un punto de conexión eléctrica en AC para una pieza

de un equipo conductor. Los Terminales (Terminals) son conectados a unos puntos

de conexión físicos llamados Nodos de Conectividad (ConnectivityNode).

• cim:ConductingEquipment: Corresponde a las partes de un sistema de potencia

AC que están diseñadas para transportar corriente o que se encuentran conectados

conductivamente a través de terminales (Terminals). Es decir, equipos conductivos.

• cim:EnergyConsumer: Corresponde a un usuario genérico de energía como un

punto de consumo dentro del modelo del sistema de potencia.

• cim:EquipmentContainer: Corresponde a una construcción del modelamiento

para proporcionar una clase raíz para contener los equipos. Un contenedor de

equipos.

• cim:VoltageLevel: Corresponde a un grupo de equipos que comparte un nivel de

voltaje en común dentro del sistema eléctrico que conforman un aparellaje (equipo

eléctrico de maniobra, equipos que permiten conmutar y variar el estado de la red).

En la siguiente Figura 3-10 se puede observar la relación entre el terminal y el contenedor

de nodos de conexión, y entre el terminal y el equipo conductivo considerado en la

estructura CIM v14 encontrada en DIgSILEN. Para esta representación se seleccionó la

conectividad que existe para una carga del sistema eléctrico de potencia interpretado por

DIgSILENT, el cual el terminal (Terminal) se asocia con un nodo topológico

(TopologicalNode) y a su vez con un equipo conductivo (ConductingEquipment) con la

carga de consumo (EnergyConsumer).

Capítulo 3 69

Figura 3-10: Estructura Terminal – DIgSILENT.


Sin embargo, para la estructura CIMv14 implementada por el Editor de Modelo CIM en

desarrollo, se tiene algunas clases y asociaciones adicionales que se implementada dentro

de las asociaciones entre el elemento (equipo conductivo) y el nodo de conectividad. Para

estas clases adicionales se muestra la definición basado [27] desde su ontología como

sigue:

• cim:ConnectivityNode: Corresponde a puntos donde los terminales de los

equipos conductores de AC están conectados entre sí con impedancia cero.

• cim:BusbarSection: Corresponde a un conductor o un grupo de conductores

implementado para conectar otros equipos conductores dentro de una sola

subestación con impedancia insignificante.

• cim:NonConformLoad: Corresponde a la representación de cargas que no siguen

un patrón de cambio, ni están relacionados con un patrón de carga diaria.

En la siguiente Figura 3-11 se puede observar en letras verdes aquellas clases y

asociaciones adicionales o diferentes implementadas por el Editor de Modelo, para la

relación entre el terminal y el contenedor de nodos de conexión, y entre el terminal y el

equipo conductivo. Para hacer la analogía con el tipo de conectividad evaluado con

DIgSILENT, se selecciona la conexión para la carga del sistema eléctrico de potencia

interpretado por el aplicativo Editor de Modelo, donde el terminal (Terminal) es asociado

con un nodo de conectividad (ConnectivityNode) y a su vez con un segmento de barra




(BusbarSection), donde el segmento de barra y el elemento carga (NonConformLoad) se

encuentran incluidos en el contenedor de equipos (EquipmentContainer).

Figura 3-11: Estructura Terminal – Editor de Modelo CIM.


Con lo anterior, se puede evidenciar la diferencia que existe en las asociaciones

implementadas para realizar la conectividad de los elementos, entre los aplicativos

DIgSILENT y el Editor de Modelo.

Por otro lado, por medio del aplicativo de Python se detecta la diferencia entre el número

de parámetros para el elemento Terminal implementado por la estructura del modelo CIM

v14 de DIgSILENT y por el implementado por el Editor de Modelo. Como se muestra en la

siguiente Figura 3-12.

Capítulo 3 71

Figura 3-12: Validación de parámetros elemento Terminal – Editor de Modelo CIM.


Con esto, se identifica dentro de la estructura CIM generado por el editor de modelo el total

de Terminales analizadas y la diferencia del número de parámetros que implementa la

estructura CIM v14 reconocido por el aplicativo de DIgSILENT y el generado por el Editor

de Modelo.

A pesar de que ambos aplicativos implementan el modelo CIM como protocolo de

comunicación y el mismo versionamiento CIM v14, el aplicativo de DIgSILENT no soporta

algunas de las clases implementadas por el Editor del Modelo CIM para la representación

del sistema eléctrico de potencia y no identifica el uso de algunas asociaciones para el

relacionamiento entre las clases utilizadas, existe diferencias significativas que se

convierte en un reto para la lograr una interoperabilidad entre aplicativos.

4. Conclusiones y recomendaciones

4.1 Conclusiones

En este documento se implementa el Modelo de Información Común – CIM para la

interoperabilidad entre aplicativos utilizados para el análisis, modelado y caracterización

de un sistema de transmisión eléctrica de potencia, en el cual por medio de un modelo de

un sistema de transmisión eléctrica de potencia basado en la estructura del modelo CIM

se evalúa el intercambio y actualización de la información provenientes de diferentes

aplicativos y se verifica la funcionalidad del uso del modelo CIM para el intercambio de

información entre aplicativos.

En el desarrollo de este trabajo se evidencian las limitantes que existen entre los diferentes

aplicativos dado a que cada proveedor desarrolla sus herramientas y maneja su propia

semántica para la manipulación e intercambio de información.

Adicionalmente, en los casos de estudio se muestra que, dado la evolución continua para

cumplir con los requisitos cambiantes para el intercambio de información de los estándares

del modelo CIM, se deben tener en cuenta el versionamiento de la estructura CIM

implementada, la interpretación que se tenga por parte de la norma IEC 61970 y la

flexibilidad que cuente los aplicativos, para que exista una buena interoperabilidad entre

estos. Con el fin de generar confiabilidad de la información, unicidad y consistencia de los

datos.

Por otro lado, la estructura propuesta en el modelo CIM para la representación de un

sistema eléctrico de potencia da un orden y caracterización del sistema eléctrico, el cual

facilita la interpretación y relación que existe entre los elementos que componen el sistema

eléctrico de potencia brindando una consistencia de los datos al momento de su

identificación y manipulación de la información.




A pesar de los múltiples desarrollos, avances y actualizaciones que ha tenido la norma,

aún puede existir dificultades para la interoperabilidad entre los aplicativos o limitantes los

cuales se requieren de herramientas adicionales o interpretadores que faciliten el

intercambio de información.

4.2 Recomendaciones

Como complemento y crecimiento de lo evaluado y desarrollado se recomienda identificar

la versión del esquema CIM soportados por las aplicativos y la diferencia que existe entre

estas en cuanto a la estructura implementada.

Se propone generar un código más robusto para los desarrollos en Excel y Python que

facilite la detección del esquema y la versión de la estructura CIM de los archivos XML

para mejorar la interoperabilidad y manejo de los datos.

Para futuros trabajos se puede ampliar la información y desarrollo para los sistemas que

se involucren las Fuentes No Convencionales de Energía Renovable (FNCER), debido a

su rápida penetración en los sistemas eléctricos potencia, se considera interesante evaluar

su clasificación y asociaciones dentro de su modelamiento en la estructura del modelo

CIM.

Por otro lado, se encontraría tentador desarrollar una herramienta que facilite el cambio de

versionamiento de los modelos CIM, el cual facilitaría tener la información desde diferentes

aplicativos sin la limitante del versionamiento.

A. Anexo: Datos Importados desde XML con la herramienta de Excel

ns1:ID ns1:resource ns2:Equipment.equivalentns2:GeneratingUnit.governorSCDns2:GeneratingUnit.maxOperatingPns2:GeneratingUnit.maximumAllowableSpinningReservens2:GeneratingUnit.minOperatingPns2:GeneratingUnit.nominalPns2:GeneratingUnit.normalPFns2:GeneratingUnit.startupCostns2:GeneratingUnit.variableCostns2:IdentifiedObject.name

_0882DDE8-53BF-4650-8A77-32FE2C27118A #_07FE574D-9A04-4FB7-A811-1255CCC16889 FALSE 0 680 0 200 680 0 0 0 G 03

_2357F4DA-58F5-4C51-97E1-931DF8715E95 #_C29D6665-09A6-4742-8AB7-7E1690C936F3 FALSE 0 850 0 250 850 0 0 0 G 09

_36295703-300C-4ABB-883B-B4FBE8925681 #_D9656342-639C-4B2B-A9F2-4163D7B48D53 FALSE 0 850 0 0 850 0 0 0 G 10

_36E49BBD-322B-445F-B6F5-9C34CA41F663 #_3D5BBD50-D254-4DE6-9869-7F4FD9BA33A2 FALSE 0 680 0 200 680 0 0 0 G 06

_3A65D8C4-6E31-4F3D-8918-0C49F23C5B7D #_542BEC7A-1C0E-498A-A413-27FB907849BB FALSE 0 255 0 70 255 0 0 0 G 05

_46F17088-C238-459E-8154-2F0D88E3770C #_DCE87E5F-BD4B-4787-BB51-761E646024E2 FALSE 0 8500 0 0 8500 0 0 0 G 01

_74EB62AD-3ED6-48C4-B381-178330A84176 #_7AF5D15D-6976-4F67-B6BE-C4D20484FBE9 FALSE 0 595 0 150 595 0 0 0 G 08

_813F3735-0862-4879-95CE-D607C81E7F11 #_A9015C5E-BA88-4441-AE80-E272C4D829A8 FALSE 0 680 0 200 680 0 0 0 G 04

_C0C2B26A-30F3-4C7A-B68B-BA0E0F7C1A43 #_2DD29A7F-349A-47BF-B84E-CD283E90F816 FALSE 0 595 0 150 595 1 0 0 G 02

_C1532DB1-6BE2-4C09-AE62-447B2E0B47FE #_396449B1-61BC-4CA5-A8A8-D10746399F38 FALSE 0 595 0 150 595 0 0 0 G 07

Bibliografía

[1] R. Santodomingo, S. Rohjans, M. Uslar, J. A. Rodríguez-Mondéjar, and M. A. Sanz-Bobi, “Ontology matching system for future energy smart grids,” Eng. Appl. Artif. Intell., vol. 32, pp. 242–257, 2014.

[2] H. Georg, S. C. Müller, C. Rehtanz, and C. Wietfeld, “Analyzing cyber-physical energy systems: The INSPIRE cosimulation of power and ICT systems using HLA,” IEEE Trans. Ind. Informatics, vol. 10, no. 4, pp. 2364–2373, 2014.

[3] J. Zhu, E. Zhuang, J. Fu, J. Baranowski, A. Ford, and J. Shen, “A Framework-Based Approach to Utility Big Data Analytics,” IEEE Trans. Power Syst., vol. 31, no. 3, pp. 2455–2462, 2015.

[4] P. Skare, H. Falk, M. Rice, and J. Winkel, “In the Face of Cybersecurity: How the Common Information Model Can Be Used,” IEEE Power Energy Mag., vol. 14, no. 1, pp. 94–104, 2016.

[5] EPRI, Common Information Model Primer, Third Edit. Palo Alto, CA, 2015.

[6] L. Wang and H. Murayama, “A multi-version CIM-based database platform for smart grid,” IEEJ Trans. Electr. Electron. Eng., vol. 10, no. 3, pp. 330–339, 2015.

[7] V. H. Nguyen, Q. T. Tran, and Y. Besanger, “SCADA as a service approach for interoperability of micro-grid platforms,” Sustain. Energy, Grids Networks, vol. 8, pp. 26–36, 2016.

[8] J. D. Moseley, N. V. Mago, N. D. R. Sarma, W. M. K. Grady, and S. Santoso, “Extending CIM standards to support exchange of ratings on dynamically rated equipment,” IEEE Trans. Power Syst., vol. 31, no. 1, pp. 296–303, 2016.

[9] L. Fiaschetti et al., “Monitoring and controlling energy distribution: Implementation of a distribution management system based on Common Information Model,” Int. J. Electr. Power Energy Syst., vol. 94, pp. 67–76, 2018.

[10] N. Etherden, V. Vyatkin, and M. Bollen, “Virtual Power Plant for Grid Services using IEC 61850,” IEEE Trans. Ind. Informatics, vol. 12, no. 1, pp. 1–1, 2016.

[11] A. W. McMorran, “An Introduction to IEC 61970-301 & 61968-11 : The




Common Information Model,” Power, vol. 1, no. January, pp. 1–42, 2007.

[12] E. Pilo, R. Santodomingo, J. A. Rodríguez, and E. Pilo de la Fuente, “Introducción al modelo CIM de los sistemas de energía eléctrica,” Anales de mecánica y electricidad, Revista de la Asociación de Ingenieros del ICAI, vol. Vol. 86, F, no. Septiembre-Octubre, pp. 31–38, 2009.

[13] A. Sharma, S. Member, S. C. Srivastava, S. Member, S. Chakrabarti, and S. Member, “An Extension of Common Information Model for Power System Multiarea State Estimation,” IEEE Syst. J., vol. 11, no. 3, pp. 1692–1701, 2017.

[14] A. Naumann, I. Bielchev, N. Voropai, and Z. Styczynski, “Smart grid automation using IEC 61850 and CIM standards,” Control Eng. Pract., vol. 25, no. 1, pp. 102–111, 2014.

[15] G. Ravikumar, S. Member, S. A. Khaparde, S. Member, and R. K. Joshi, “Integration of Process Model and CIM to Represent Events and Chronology in Power System Processes,” vol. 12, no. 1, pp. 149–160, 2018.

[16] L. S. Chandramohan, G. Ravikumar, and S. Member, “Business Process Model for Deriving CIM Profile : A Case Study for Indian Utility,” Ieee Trans. Power Syst., vol. 30, no. 1, pp. 132–141, 2015.

[17] A. Sharma, S. S. Member, S. C. Srivastava, S. S. Member, S. Chakrabarti, and S. S. Member, “An Extension of Common Information Model for Power System Multiarea State Estimation,” IEEE Syst. J., vol. 11, no. 3, pp. 1–10, 2014.

[18] “Applications for Python | Python.org.” [Online]. Available: https://www.python.org/about/apps/. [Accessed: 20-Mar-2020].

[19] DIgSILENT GmbH, “39 Bus New England System,” vol. V15,2, pp. 1–18, 2018.

[20] I. Netzberechnungssoftware, “PowerFactory 15,” pp. 0–26, 2012.

[21] Richard Lincoln, “PyCIM · PyPI.” [Online]. Available: https://pypi.org/project/PyCIM/. [Accessed: 22-Mar-2020].

[22] “xml.dom.minidom: implementación mínima de DOM: documentación de Python 3.8.2.” [Online]. Available: https://docs.python.org/3/library/xml.dom.minidom.html. [Accessed: 25-Mar-2020].

[23] “cim:GeneratingUnit.” [Online]. Available: https://ontology.tno.nl/IEC_CIM/cim_GeneratingUnit.html. [Accessed: 13-Apr-2020].

Bibliografía 79

[24] © Microsoft 2020, “Import XML data - Excel,” Excel for Office 365 Excel 2019 Excel 2016 Excel 2013 Excel 2010 Excel 2007. [Online]. Available: https://support.office.com/en-us/article/import-xml-data-6eca3906-d6c9-4f0d-b911-c736da817fa4?ns=EXCEL&version=90&ui=en-US&rs=en-US&ad=US. [Accessed: 08-Apr-2020].

[25] for the W. X. S. W. G. C. M. Sperberg-McQueen, “Namespaces ns1, ns2, ns3,” Date: 2008/01/03 04:36:55 , 02-Jan-2008. [Online]. Available: https://www.w3.org/XML/2008/xsdl-exx/ns1. [Accessed: 09-Apr-2020].

[26] © Microsoft 2020, “Exportar datos XML - Excel.” [Online]. Available: https://support.office.com/es-es/article/exportar-datos-xml-0b21f51b-56d6-48f0-83d9-a89637cd4360. [Accessed: 08-Apr-2020].

[27] © TNO Innovation for Live, “Glossary - IEC CIM Ontology.” [Online]. Available: https://ontology.tno.nl/IEC_CIM/all-Glossary.html. [Accessed: 13-Apr-2020].

Date post:	10-Nov-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Implementación del Modelo de Información Común – CIM …

Documents