Introducción al modelo CIM de los sistemas de energía eléctrica

Resumen
El Common Information Model (CIM) es un modelo estándar descrito en UML que organiza toda la información que puede ser necesaria en la gestión de los sistemas de energía eléctrica. El modelo, debido a su facilidad para extenderse, será válido tanto en los sistemas de energía actuales, como en los futuros. Su
empleo simplificará el intercambio de información entre aplicaciones de distintos fabricantes, lo que supone una reducción de costes y complejidad en los sistemas de gestión de las redes eléctricas. El artículo proporciona una visión general del CIM, destaca las aplicaciones que se le están dando en la actualidad y apunta los principales retos futuros en relación al modelo.

Origen y utilidad del modelo CIM
Con el fin de optimizar su funcionamiento, los sistemas de energía eléctrica son controlados desde puestos remotos. Estos sistemas de gestión remotos están formados por distintas aplicaciones. Cada una de estas aplicaciones permite la realización de una funcionalidad de gestión determinada: cálculo de flujo de cargas óptimo, análisis de los eventos transitorios en la red, configuración de los sistemas de protecciones, gestión de activos, software SCADA para el control y supervisión de la red en tiempo real, etc.
A pesar de que cada aplicación se centra en una funcionalidad concreta, muchas de ellas, en ocasiones, compar ten una misma información de entrada. Así, por ejemplo, la mayor par te de las aplicaciones de un sistema de gestión remoto deben importar la información acerca de la topología de la red eléctrica que van a gestionar. También puede ocurrir que la información de salida que genere una determinada aplicación
tras haber realizado sus cálculos sirva como información de entrada para otra aplicación. Estas situaciones también se pueden dar entre aplicaciones de distintos sistemas de gestión. En definitiva, hay información
relacionada con el sistema eléctrico que se repite en distintas aplicaciones de un mismo o de diferentes sistemas de gestión remotos.
Ante este hecho, se podría optar por introducir varias veces esta información en el sistema. Sin embargo, esta opción no es nada eficiente, ya que supone un trabajo extra innecesario, aumenta las probabilidades
de introducir la información erróneamente y, por tanto, puede dar lugar a incongruencias.
Por este motivo, lo más lógico es que exista un intercambio de información entre las aplicaciones de gestión de las redes eléctricas.
El problema es que, en general, dichas aplicaciones son desarrolladas por distintos fabricantes. Esto implica que cada aplicación tiene su propia manera de organizar la información y que cuenta con un formato propio
para intercambiarla. De este modo, para cada dos aplicaciones que deban intercambiarse información es necesario un convertidor de formato. La existencia de conver tidores incrementa el coste y la complejidad de los sistemas de gestión de las redes eléctricas. En el caso extremo, en un sistema de gestión en el que existen  aplicaciones podrían ser necesarios convertidores de formato de tipo bidireccional (Figura 1).

A finales de los 90, en vista de este problema, el principal organismo encargado de realizar investigaciones en relación a los sistemas eléctricos de potencia en los Estados Unidos de América, el EPRI (Electric Power Research Institute), comenzó a elaborar un modelo de información único, común a todas las aplicaciones
encargadas de la gestión de las redes eléctricas. Este modelo se denominó Common Information Model (CIM). Pronto, a principios de esta década, la IEC (International Electrotechnical Commission) lo adoptó
como el modelo de información internacional estándar para la gestión de los sistemas eléctricos [1]. Es decir, con el modelo CIM se estandariza la manera de organizar toda la información que pueda ser necesaria en las
aplicaciones dedicadas a la gestión de las redes eléctricas.
Basándose en este modelo, la IEC también define un formato estándar en XML [2] para el intercambio de información entre las aplicaciones de gestión. Este formato se denomina CIM/XML. Realmente, el CIM/XML no es el único formato estándar basado en el CIM que ha definido la IEC. Este formato está
dirigido únicamente al intercambio de grandes cantidades de información acerca de la topología de las redes eléctricas a gestionar.  Otro tipo de intercambio de información se puede dar mediante formatos como CIM/XSD [3] o CIM/SVG [4]. En cualquier caso, la definición de un modelo de información único (CIM) y unos formatos estándar para el intercambio de información basados en dicho modelo reduce de manera considerable la complejidad y coste de los sistemas de gestión remoto.
Así, en un sistema de n aplicaciones, en el peor de los casos (si ninguna de las aplicaciones tuviese implantado el CIM), serían necesarios n conver tidores de formato. La reducción del coste y la complejidad de los
sistemas implican una mejoría en su funcionamiento y fiabilidad.
En este apartado introductorio se ha explicado el origen y utilidad del modelo CIM. En los siguientes se procederá a realizar una breve descripción del mismo. Para ello, se seguirán los siguientes puntos:
• El CIM viene descrito en las normas IEC mediante diagramas de clases y diagramas de paquetes UML. Por este motivo, en primer lugar, se proporcionarán unos conceptos básicos que facilitarán al lector la
interpretación de estos diagramas.  En segundo lugar, se dará una visión general del CIM. Así, se hará referencia a las normas que lo definen, se mostrará la estructura global del modelo y se presentará
un diagrama de clases del CIM, en el que se podrán apreciar algunas de las clases definidas en el modelo, así como las relaciones que existen entre ellas.
• En tercer lugar, se explicará el sencillo procedimiento de extensión del modelo.
• Por último, se detallarán las aplicaciones del modelo CIM en la actualidad, así como los retos futuros en relación al mismo y las conclusiones finales del artículo.

Diagramas de clases y diagramas de paquetes UML
El UML (Unified Modeling Language) [5] es un lenguaje muy extendido en la actualidad en el mundo informático que permite representar todo tipo de sistemas mediante el empleo de notación gráfica. Este lenguaje define distintos tipos de diagramas, los cuales se pueden clasificar en dinámicos y estáticos.
Los diagramas UML dinámicos permiten describir, entre otras cosas, los eventos que pueden ocurrir en el sistema a medida que avanza el tiempo (diagramas de secuencias), o los distintos estados por los que
puede pasar un objeto (diagrama de estados). Por su par te, los diagramas estáticos  permiten dar una visión general del sistema, indicando qué tipos de elementos lo componen y cómo se relacionan entre sí. En este
último grupo de diagramas UML se encuentran los diagramas de clases y los diagramas de paquetes, que son los dos tipos de diagramas que se emplean en la normas IEC para describir el modelo CIM. Por
este motivo, a continuación se procede a explicar cada uno de ellos.

Diagramas de clases UML
Para representar un sistema de cierta complejidad, de manera que dicha representación sea fácilmente interpretable para el  usuario, es necesario seguir una metodología que permita organizar todos los conceptos
del sistema de manera sencilla y, a la vez, lo más precisa posible. Actualmente, para este cometido se emplea frecuentemente la filosofía orientada a objetos.
Los modelos orientados a objetos representan sistemas reales empleando principalmente dos conceptos: las clases y las relaciones entre clases. Una clase es la representación de un tipo de objetos existentes en el sistema. Por ejemplo, al describir el “sistema biblioteca”, se definirá, entre otras, la clase Libro, que representará cualquier libro que se encuentre en la biblioteca. Cada clase contendrá una serie de atributos.
Estos atributos permitirán describir las características par ticulares de cada uno de los objetos que pertenezcan a esa clase.
Continuando con el ejemplo, la clase Libro contendrá atributos como: númeroPáginas, que permitirá indicar cuántas páginas tiene un libro en concreto, o grosor, que permitirá indicar cuál es el grosor de un libro  determinado. La Figura 2 muestra la representación de la clase Libro en un diagrama de clases UML.

Las clases estarán relacionadas con otras clases dentro del modelo. Estas relaciones podrán ser de distintos tipos.A continuación, se explican los principales tipos de relaciones que se pueden describir en los diagramas de clases UML:

• La relación de agregación es aquella que describe el hecho de que los objetos de una clase contienen, o pueden contener, objetos de otra. Esta relación es la que existe, por ejemplo, entre la clase Biblioteca, que representa una biblioteca, y la clase Libro. Así, como las bibliotecas contienen libros, un objeto de la clase Biblioteca contiene objetos de la clase Libro. En la Figura 3 se puede observar cómo se representa este tipo de relación entre clases en UML. Obsérvese que en la clase Biblioteca se ha incluido un atributo que permitirá indicar la localización de cada biblioteca.

• La herencia, por su parte, describe la relación que existe entre una clase y otra que representa un tipo par ticular de objetos de aquella. A la primera se le denomina clase padre o superclase y a la segunda,
  clase derivada o subclase. Anteriormente, se explicó que la clase Libro representa cualquier tipo de libro. Sin embargo, puede ser interesante diferenciar qué tipo de libro se está representando en cada caso. De este modo, se podrían incluir en el modelo las clases Novela y Diccionario, por ejemplo. Ambas clases representan tipos distintos de objetos de la clase Libro. Esto es, la clase Libro se relaciona mediante herencia con las clases Novela y Diccionario, o dicho de otra forma, las clases Novela y Diccionario derivan de la clase Libro. Como se puede apreciar en la Figura 4, en una relación de herencia, las clases derivadas heredan, de ahí el nombre de la relación, los atributos y relaciones de la clase padre. Así, ambas clases derivadas contienen los atributos numeroPáginas y grosor. Además, cada subclase, puede añadir nuevos atributos (personajePrincipal, idioma), aunque no es obligatorio que lo haga. Estos nuevos atributos permitirán describir en mayor detalle los objetos de las clases derivadas.

• Las relaciones entre clases que no describan ni agregación, ni herencia, ni composición (relación similar a la de agregación, pero más restrictiva y que no se emplea en el modelo CIM) se denominan asociaciones. Es la relación que se podría dar entre la clase Libro y la clase Autor, que representa los autores que escriben los libros.

 Diagramas de paquetes UML
Los modelos orientados a objetos que tienen cierta extensión, agrupan sus clases y relaciones entre clases en distintas categorías o paquetes (packages). Así, en el ejemplo del modelo “biblioteca”, si se hubiesen definido
muchas clases, sería aconsejable agruparlas en paquetes como, por ejemplo, Personas y Material. En el primer paquete se incluirían todas las clases relacionadas con el personal que trabaja en la biblioteca y los autores de los libros: Autor, Bibliotecaria, etc. En el segundo, se incluirían las clases relacionadas con el
material que se encuentra en una biblioteca: Libro, Novela, Diccionario, Mesa, etc. La representación de este ejemplo en diagramas de paquetes UML se muestra en la Figura 6.

Modelo CIM.
Una vez presentados los diagramas de clases y diagramas de paquetes UML, en este apartado se proporciona una visión general del modelo CIM, el cual representa, mediante estos tipos de diagramas, todos los conceptos necesarios en la gestión de los sistemas eléctricos. En esta visión general: en primer lugar, se presentan las normas que definen el modelo, en segundo lugar, se describen brevemente los paquetes en los
que se agrupan los conceptos descritos en dicho modelo y, por último, a modo de ejemplo, se muestra un diagrama de clases CIM.


Normas CIM (IEC 61970 e IEC 61968)
 El CIM se define dentro de las series de normas IEC 61970 e IEC 61968. Las primeras, se centran en los sistemas de gestión de las redes de transporte, también llamados en la literatura EMS (Energy Management
System). Por su par te, las segundas se centran en los sistemas de gestión de las redes de distribución, o DMS (Distribution Management System).Tanto las normas IEC 61970, como las IEC 61968, no solo definen el modelo CIM, sino que además: describen una arquitectura de referencia para la integración
entre las aplicaciones que forman par te de un sistema de gestión y los requisitos generales de las mismas ([6] y [7]), especifican los mecanismos (servicios) de comunicación por los cuales se puede acceder a la información de una aplicación ([8] y [9]) y, por último, especifican formatos (como el CIM/XML) empleados
para el intercambio de información ([10], [2], [3] y [11]).
Las normas IEC 61970 e IEC 61968 en las que se define el modelo CIM, son respectivamente, la IEC 61970-301 ([1]) y la 61968- 11. Los diagramas de clases y diagramas de paquetes UML empleados en estas normas se incluyen también en el modelo combinado CIM, descrito en una herramienta llamada
Rational Rose, desarrollada por IBM y que se puede descargar desde la página web oficial de los usuarios del CIM [12]. Esta herramienta permite al usuario navegar a través de los distintos diagramas definidos en la
norma, facilitando la búsqueda de clases, atributos y relaciones entre clases en el modelo.
Modelo CIM. Organización en paquetes Como se ha comentado anteriormente, el modelo CIM representa todos los conceptos necesarios en la gestión de las redes eléctricas, lo que implica que se tratará de un modelo de gran extensión. Para llevar a cabo su misión, el CIM sigue la filosofía orientada a objetos. Esto es, define clases que representan conceptos reales de los sistemas eléctricos y establece relaciones entre ellas.
Como todo modelo orientado a objetos de gran tamaño, el CIM agrupa todas sus clases en distintos paquetes. La Figura 7

muestra el diagrama UML en el que se representan los paquetes que se incluían en las primeras versiones de la IEC 61970-301. En la figura, las flechas que unen dos paquetes indican que existe dependencia entre ellos, es decir, una modificación en uno de los paquetes puede propiciar cambios en el otro.
A continuación, se describen brevemente los paquetes que aparecen en la Figura 7.

• En el paquete Wires se encuentran las clases que representan los equipos físicos que pueden formar par te de un sistema eléctrico de potencia. Un ejemplo de clase incluida en este paquete es Breaker,
  que representa los interruptores.
• El paquete Topology proporciona las clases necesarias para poder describir las conexiones entre los equipos.Así, define, entre otras, la clase ConnectivityNode, que se explicará posteriormente en este artículo.
• El paquete central Core incluye una serie de clases, como IdentifiedObject, que serán padres (superclases) de la mayoría del resto de clases del modelo.
• Generation incluye las clases necesarias para representar la información referente a la generación de energía eléctrica, como por ejemplo: GeneratingUnit o HydroTurbine.
• Meas comprende casi todas las clases relacionadas con la representación de las medidas en los sistemas eléctricos:Measurement, MeasurementType, etc.
• LoadModel incluye las clases necesarias para describir todo lo referente al consumo de energía eléctrica. Contiene, entre otras, a la clase EnergyConsumer, que permite representar todo tipo de consumidores de energía eléctrica. 
• Outage permite describir programas de planificación para la operación y mantenimiento de los sistemas eléctricos de potencia para la prevención y actuación ante apagones. Incluye, entre otras, la clase OutageSchedule, que permite describir la información acerca de los periodos programados
  en los que un equipo determinado está fuera de servicio, por mantenimiento o realización de algún test.
• Protection proporciona las clases necesarias para representar los equipos de protección (clase ProtectionEquipment) y las secuencias de cierre automático (clase RecloseSequence).
• SCADA incluye, entre otras, la clase RemoteUnit, que representa los dispositivos electrónicos situados en la instalación eléctrica y que intercambian información con la aplicación SCADA localizada en el
  sistema de gestión.También permite describir los enlaces de comunicación con estas unidades remotas mediante la clase CommunicationLink.
• Domain es el paquete que incluye las definiciones de todos los tipos de datos que se asignan a los valores de los atributos descritos en el resto del modelo: desde tipos primitivos como Float, hasta tipos como Temperature, por ejemplo.

En la actualidad, el modelo CIM es más amplio. Así, en la norma IEC 61968-11 (para sistemas
DMS) se añaden nuevos paquetes al modelo original. Por ejemplo, el paquete Assets contiene la información necesaria para llevar a cabo la gestión de los activos en un sistema eléctrico de potencia. Por su parte, Consumers define las clases que permiten describir en mayor detalle cierta información acerca de los
consumidores (necesidades especiales, información de facturación, etc.) y Work abarca toda la información acerca de cualquier tipo de obra o trabajo en una instalación eléctrica. Por último, las versiones más recientes del modelo CIM (modelo CIM combinado) añaden además otros paquetes adicionales, como por ejemplo, el paquete 61850, en el que se incluyen una serie de clases que permiten representar información propia del modelo IEC 61850 en el modelo CIM. El modelo IEC, 61850 [13], también definido por la IEC, se ha
ido desarrollando paralelamente con el CIM y describe toda la información necesaria en los sistemas de automatización local de las instalaciones eléctricas.

Diagrama de clases CIM para la representación.
de los elementos de corte Los elementos de cor te son equipos de los sistemas eléctricos capaces de abrir y/o cerrar los circuitos en los que se encuentran. Para representarlos, el CIM define la clase Switch, que contará con una serie de atributos como, por ejemplo, normalOpen, con el que se podrá indicar si un elemento de corte está normalmente abierto o cerrado. Existen distintos tipos de elementos de corte. Cada
uno de esos tipos se representará en CIM mediante una clase que derivará de la clase Switch. Así, la clase ProtectedSwitch representa a los elementos de corte que pueden ser accionados por dispositivos de protección. De esta clase derivan a su vez las clases Breaker y LoadBreakSwitch. Breaker representa los interruptores, que son elementos de corte que tienen capacidad de abrir una corriente de cortocircuito. Esta clase contará con el atributo ampRating para indicar la cantidad de Amperios que es capaz de abrir un interruptor. Por su parte, LoadBreakSwitch representa los elementos de corte con capacidad de apertura
en carga nominal. Por último, los seccionadores, elementos de cor te sin capacidad de apertura en carga, se representan en CIM mediante la clase Disconnector, que deriva directamente de Switch. En la Figura 8 se muestra el diagrama UML del CIM en el que se incluyen todas las clases y relaciones entre clases explicadas anteriormente. En este artículo no se ha descrito todo el diagrama UML del CIM para la representación de los elementos de corte, sino únicamente un pequeño fragmento en el que se encuentran las clases más características. 

Proceso de extensión en el modelo CIM
Como se comentó anteriormente, el CIM es un modelo muy amplio que abarca la mayor par te de la información necesaria para gestionar un sistema eléctrico. A pesar de ello, en algunas ocasiones, puede resultar que al intentar representar en el modelo CIM determinadas instalaciones eléctricas con ciertas particularidades, o determinados conceptos relacionados con la gestión de los sistemas eléctricos, las clases proporcionadas por el modelo sean insuficientes. Es decir, las clases que se incluyen en el modelo pueden
no satisfacer completamente las necesidades del usuario.
Sin embargo, la organización del modelo según la filosofía orientada a objetos, basada, principalmente, en las relaciones de herencia entre clases, proporciona al mismo la posibilidad de extenderse con gran facilidad. Además, el proceso de extensión del CIM no implica necesariamente cambios drásticos en las aplicaciones que manejen versiones no actualizadas del modelo. Para explicar el proceso de extensión, se propone el siguiente ejemplo. Se desea representar en CIM una instalación que cuenta con unos elementos de corte especiales. Resulta, además, que en ciertas aplicaciones se desea distinguir esos elementos de corte especiales del resto. En ese caso, lo único que sería necesario hacer, tal y como muestra la Figura 9, es crear una nueva clase (NuevoSwitch) que derive de la clase Switch, existente en el modelo. Esta nueva clase heredará los atributos de Switch, como normalOpen, y podrá añadir nuevos atributos, como, por ejemplo, nuevoAtributo. Si una aplicación conoce la versión extendida del modelo CIM (aquella que incluya a esta nueva clase) será capaz de procesar toda la información de la clase NuevoSwitch. Sin embargo, una aplicación que conozca únicamente la versión original del CIM (sin las nuevas extensiones) tratará a los objetos NuevoSwitch como objetos de la clase Switch, procesando únicamente la información referente
a esta última, es decir, la información que es común a todos los elementos de corte. Este hecho permite que, incluso las aplicaciones que no estén actualizadas conforme a las nuevas extensiones del modelo, puedan
procesar la información de las mismas, aunque, lógicamente, en menor detalle que las aplicaciones que están actualizadas [14].

Aplicaciones del CIM en la actualidad
Como se comentó en el primer apartado del presente artículo, las normas que definen el CIM fueron desarrolladas hace unos pocos años. Es más, las normas IEC 61970 e IEC 61968 se están completando todavía en la actualidad: se añaden nuevas clases al modelo, se definen nuevos formatos de intercambio
de información entre aplicaciones, etc. Sin embargo, pese ser bastante reciente, el CIM se está asentando rápidamente en los sistemas de gestión de los sistemas eléctricos. A continuación, se describe el estado actual dela aplicación del CIM en tres campos: sistemas EMS, sistemas DMS y otros sistemas. La aplicación original del CIM se dio en los sistemas de gestión de redes de transpor te (EMS).Tal es así, que a principios de esta década, el NERC (Nor th American Electric Reliability Council) impuso el empleo del modelo CIM en las aplicaciones de los EMS en los Estados Unidos de América. Las ventajas obtenidas en estos sistemas a raíz del empleo del CIM no pasaron desapercibidas en Europa. Así, en 2004 la RAO UES (sistema energético de Rusia), al renovar los sistemas de gestión de sus redes  eléctricas, entendió la conveniencia de utilizar el CIM como mecanismo principal para facilitar el intercambio de información entre  las aplicaciones de dichos sistemas. En la actualidad, ya existe un perfil del CIM para la UCTE, organismo que coordina la
operación y desarrollo de la red de transpor te en Europa Occidental.También existen distintos trabajos de investigación relacionados con el CIM en los que este organismo y otros organismos europeos, como EDF (Électricité de France), colaboran con el EPRI. La aplicación en los sistemas de gestión de redes de distribución (DMS) es más reciente. Las normas IEC 61968 se desarrollaron, precisamente, para aplicar el CIM en los sistemas DMS. Sin embargo, el mayor impulso en esta dirección se ha dado en los últimos 4 ó 5 años. En este periodo, han comenzado distintos proyectos en todo el mundo, en los que participan distintas empresas, universidades e institutos de investigación, cuyo objetivo es el desarrollo de las redes de distribución del futuro: Intelligrid (USA), Address (Unión Europea), CENIT DENISE [16] (España), etc. En la mayoría de ellos, se propone el CIM como modelo de información a emplear en los sistemas de gestión.
Por último, la facilidad para extender el modelo (mediante creación de nuevas clases derivadas de otras ya existentes), permite aplicar el CIM en instalaciones eléctricas con ciertas particularidades. Así, recientemente, se han desarrollado trabajos para aplicar el CIM en instalaciones ferroviarias. Este proyecto ha sido realizado por el IIT para ADIF con el fin de facilitar el intercambio de información entre telemandos de control de distintos fabricantes [17]. Existen también otras investigaciones en esta dirección, como, por ejemplo, la aplicación del CIM a los sistemas eléctricos de los barcos [18].  

Conclusiones y retos futuros
El Common Information Model (CIM) fue creado por el EPRI y adoptado posteriormente por la IEC, con el fin de facilitar la interoperabilidad entre aplicaciones de distintos fabricantes en los sistemas que gestionan las redes eléctricas. Las normas que definen el modelo son la IEC 61970-301 y la IEC 61968-11. El resto de normas de las series IEC 61970 e IEC 61968 especifican: estructuras generales que deben seguir las aplicaciones que forman parte de los sistemas de gestión, servicios de comunicación generales que deben proporcionar y formatos concretos para el intercambio de información. El modelo CIM viene descrito en el lenguaje formal UML. En este artículo se han proporcionado una serie de conceptos básicos para facilitar al lector la interpretación de los diagramas UML que se emplean en la descripción del modelo. Además, se ha aportado una visión general del mismo presentando los distintos paquetes en los que se agrupan las clases CIM. Las relaciones de herencia entre clases y, en general, la organización orientada a objetos del modelo, proporciona al CIM una gran capacidad para ampliarse fácilmente. Así, se consigue que las aplicaciones antiguas sean capaces de procesar correctamente, aunque no en todo detalle, la información de las extensiones. En un principio, el CIM se aplicó en los sistemas de gestión de las redes de transporte. En la actualidad, las extensiones realizadas en el modelo original, permiten su aplicación en los  sistemas de gestión de las redes de distribución y en instalacioneseléctricas especiales, como, por ejemplo, las ferroviarias.
Como retos presentes y futuros en relación al modelo CIM, cabe destacar tres, principalmente:

• Extensión del modelo para recoger todas las necesidades de las redes de distribución del futuro (con gestión de las plantas de generación distribuida, consumo activo, etc.).  Aplicación del modelo en nuevos tipos de instalaciones: instalaciones ferroviarias en líneas de alta velocidad, por ejemplo. De nuevo, el trabajo de aplicación del CIM a este tipo de instalaciones está siendo desarrollado por el IIT para ADIF.

• Armonización del modelo con otros modelos de información del sistema eléctrico, principalmente el modelo definido en la norma IEC 61850 para los sistemas de automatización de las instalaciones eléctricas. El IIT, en colaboración con Everis y otras empresas del sector, está trabajando en esta línea de investigación dentro del proyecto CENIT DENISE, enmarcado en el programa INGENIO 2010 del Ministerio de Industria, Comercio yTurismo.

Bibliografía.

• [1] IEC_61970-301,“Energy management system application program interface
  (EMS-API) - Common information model (CIM) base,” 2007.
• [2] IEC_61970-552-4, “Energy management system application program
  interface (EMS-API) - CIM XML Model Exchange Format,” 2005.
• [3] IEC_61968-3/10, “Application integration at electric utilities - System
  interfaces for distribution management,” 2007.
• [4] IEC_61970-453, “Energy Management System Application Program
  Interface (EMS-API) - CIM Based Graphics Exchange,” 2007.
• [5] http://www.uml.org/.
• [6] IEC_61970-1,“Energy Management SystemApplication Program Interface
  (EMS-API) - Guidelines and general requirements,” 2005.
• [7] IEC_61968-1, “Application integration at electric utilities - System interfaces
  for distribution management - Interface architecture and general
  requirements,” 2003.
• [8] IEC_61970-402, “Energy management system application program interface
  (EMS-API) - Component interface specification (CIS) - Common
  services,” 2006.
• [9] IEC_61968-3, “Application integration at electric utilities - System interfaces
  for distribution management - Interface for network operations,” 2004.
• [10] IEC_61970-501,“Energy management system application program interface
  (EMS-API) - Common Information Model Resource Description
  Framework (CIM RDF) Schema,” 2006.
• [11] IEC_61968-13, "System interfaces for distribution management - CIM
  RDF Model Exchange Format for Distribution,” 2005.
• [12] http://cimug.ucaiug.org/.
• [13] IEC_61850-1, “Communication Networks and Systems in Substations -
  Introduction and Overview,” 2001.
• [14] A.W. McMorran, “An Introduction to IEC 61970-301 & 61968-11:The
  Common Information Model,” Glasgow, 2007.
• [15] http://www.w3.org/XML/.
• [16] http://www.cenit-denise.org.
• [17] R. Santodomingo, E. Pilo, J. A. Rodríguez Mondéjar, and M. Á. García-
  Vaquero, “Adapting the CIM model to describe electrified railway
  systems,” presented at XI International Conference on COMPRAIL2008
  - Computer System Design and Operation in the Railway and Other
  Transit Systems, Universidad Castilla-La Mancha.Toledo, Spain, 2008.
• [18] J.Wu,Y. Cheng, N. N. Shulz, and H. L. Ginn, “The Impact of Standardized
  Models, Programming Interfaces, and Protocols on a Shipboard Power
  System,” IEEE Transactions on Industry Applications, vol. 44, no. 2, 2008.