DUE to previous experiences as well as several national

Transcription

1 1 What is the CIM lacking? Mathias Uslar, Sebastian Rohjans, Michael Specht, José Manuel González Vázquez Abstract The IEC 61970/61968 Common Information Model is undoubtedly one of the core standards of the future smart grid as pointed out by different organizations and recent standardization roadmaps. Its acceptance in the energy sector and the active standardization work is very high and make it one of the most established standards worldwide in the energy domain. But not all requirements are met by the CIM to be the standard of choice in any possible situation. This work tries to specify some of the main gaps identified in different research projects like in the German e-energy projects and in day-to-day business with electric utility companies and the surrounding industry. There is also the attempt to recommend some known approaches to these gaps and to advise general solutions to encounter problems while using the Common Information Model. I. INTRODUCTION DUE to previous experiences as well as several national and international studies and roadmaps (e.g. [1], [2], [3]) it is generally accepted that an appropriate Information and Communication Technologies (ICT) infrastructure is needed to enable the already started change in the utility sector - the so called smart grid. Furthermore, current developments point out that the use of standards within this process is indispensable. A lot of new functions, services and use cases arise and all stakeholders within the smart grid have to cope with new challenges in terms of interoperability and integration issues. One important communication standard which provides a powerful data model as well as various interface specifications and technology mappings is the Common Information Model (CIM). Although the CIM is under continuously development, it lacks some capabilities to deal with all changes in the dynamic smart grid processes. Hence, the following section II introduces the CIM and motivates the overall use of standards, whereas section III shows the identified gaps for the CIM. Section IV gives general recommendations to encounter the problems and section V finally concludes the paper. II. COMMON INFORMATION MODEL A. Motivation of using Standards The smart grid is the most important topic within the utility domain. One aspect is the agreement on the fact that a changing power infrastructure needs a new-style ICT infrastructure. Such a radical and far-reaching process provides several opportunities - in this context the opportunity to reach a level regarding interoperability for the new system that is as high as possible. An established way to approach this challenge is the application of standards. Accordingly, lots of countries develop national standardization roadmaps (e.g. [4], [5], [6]) as well as organizations and companies specify their own standardization strategies (e.g. [7]). The German standardization strategy [8], for example, defines amongst TABLE I QUANTITATIVE COMPARISON OF CIM RELEASES 11 AND 13 Release 11 Release 13 Packages Classes Associations Native attributes others the following goals which can be achieved by the use of standards: Standardization as a strategic instrument supports the economical and social success. Standardization relieves the regulatory activities of the government. Standardization and Standard Developing Organization (SDOs) foster technology convergence. SDOs provide efficient processes and instruments. B. Common Information Model IEC (61970/61968) A standard which is unanimously recommended for smart grid architectures is the Common Information Model (IEC (International Electrotechnical Commission) 61970/61968). The CIM is an EMS-API standard containing a large data and information model for the energy domain. Overall, the CIM provides a powerful integration framework which includes several technology mappings and interface specifications in addition to the platform independent data model. Figure 1 provides an overview on the important parts of the two standard series IEC [9] and IEC [10]. They consist of common parts (e.g. glossary), component interface specifications (e.g. common services or GDA (Generic Data Access)), serializations (e.g. RDF (Resource Description Framework)), an interface reference model and data models. The CIM is maintained by four model managers, one from each related Working Group (WG) (13, 14, 16 and 19). Furthermore, many members of the WGs joint the work of the CIM user group 1 (CIMug). The maintaining process is a continuously improvement of the model using the Unified Modeling Language (UML) format. Once a year a new release is published, the current release is version 13. To emphasize the development see table I which shows a quantitative comparison of the releases 11 and 13 (see [12]). In general, three main use cases for the CIM exist. The first use case deals with the exchange of messages (e.g. Extensible Markup Language (XML)-based) among different stakeholders. The messages are based on the syntax and semantics of the domain ontology CIM. Within the second use 1

2 2 Fig. 1. Overview on IEC and IEC [11]. case the CIM provides the basis for modeling topologies of the power grid for both transmission and distribution grids. These topologies are serialized in RDF and they will be exchanged among utilities. The last use case takes standardized interfaces between systems and interface specifications into account. C. Why using CIM? Being a Common Information Model originally created for the very purpose of a common exchange language for data between different systems. Originally aiming at integrating various Energy Management Systems (EMS) with secondary IT Systems, Electric Power Research Institute (EPRI) soon realized that a pre-condition for meaningful system interfaces is a proper and sound semantic model for the data exchanged at interface level. Therefore, they started working at the CIM being a semantic data model for utility data exchange. Given the amount of data exchanged inter- and intra-utility between systems, one can hardly argue that there is no use in using common semantics to exchange data between systems from different vendors and avoiding manual work-intense integration efforts. What is of highest importance is that the common semantics are used for interfaces and data exchange only, having no impact on the existing internal models and therefore being less stressful to implement than what has been most of the times called an enterprise information model. If several systems have to exchange data bi-lateral, you can avoid the dilemma of a highly meshed exchange grid of interfaces between systems. D. Distribution of the CIM Although one can easily argue, that being an international standard agreed upon by hundreds of experts bringing in their expertise on modeling the electric power grid, the CIM must be of highest relevance to all utilities having to integrate a high number of systems from different vendors. The CIM indeed has a different impact in the different regions of the world. In the US; being a former EPRI project the CIM has a good degree of use within several utilities. The CIMug does regular meetings giving updates which most of the time is hosted by important players like Microsoft, Oracle or PGE. Also, having a strong focus on data exchange on nodal markets and a different style of running the distribution grid with radial feeders, it is more used in the US than in Europe due to regulation requirements. Within Asia, India and China are the biggest players to look for. As they are changing their infrastructure right now, those nations can directly switch to the CIM being an open standard and have their infrastructure directly updated to the latest trends. This is not true for Europe, where CIM has to deal with the existing Supervisory Control and Data Acquisition (SCADA) systems which most of the time have not yet reached the end of their expected life span. Also, within Europe, the focus on the automation rather than the IT part of the utility is pre-dominant. Most of the European national mirror committees of IEC have within their Technical Committee (TC) 57 scope a focus of their experts on IEC for substation automation and communication. This, e.g. leads to the fact that though having the largest SCADA manufacturers around in the world, Germany has no CIM working groups mirrors as of today although they have identified the CIM being the core element of the German standardization smart grid roadmap [4]. III. IDENTIFIED GAPS The following section describes some of the identified gaps in the CIM in detail. Several of these gaps are meant to be

3 3 handled in the near future so that designated approaches will be pointed out or recommended possible actions are shown. This list of gaps is not exhaustive but gives an overview on existing problems which a stakeholder of the smart grid who is using CIM will most probably come across. A. Multi-Utility Support The CIM is an undoubted standard in the electrical power supply domain but several stakeholders of the future smart grid share the vision of a multi-utility distribution system responsible for the transportation of gas, oil, water, longdistance heating and electric power similarly [2], [4]. The smart grid prosumer 2 of the future has different energy sources for his disposal to meet his own unique needs. Also some electric power companies are already acting as multi-utility distributor and are delivering more than one energy resource to the prosumer. The aforementioned resources share not only the properties concerning distributor and receiver but also the grid-bound infrastructure. The CIM already enables the possibility to model a detailed energy network as well as to support the administration of customer- and billing-data. The interfaces to other systems are considered as well. To merge two or more currently different systems for various resources raises the potential benefits enormously. The resulting synergy implies a gain to the CIM main objectives to reduce the time and cost to integrate new applications to an EMS and to protect investments that are already working effectively in an EMS. An extension to multi-utility seems reasonable but needs further examination in terms of necessity and feasibility. B. Well-defined Interfaces to the Automation Layer Component Interface Specifications (CIS) and Generic Interface Definitions (GID) are core components of the CIM. Besides, the abstract data model the CIM provides technology mappings to specify how the data model can be used. The CIM data model defines What data can be exchanged and the CIS and GID specifies How these data can be exchanged. One very important interface is the one focusing on the automation layer. Therefore, the following three sub-parts consider various types of data exchange: IEC High speed data access (HSDA): OPC Data Access (DA) defines an interface that can be used to read and write real-time data. IEC Generic eventing and subscription (GES): OPC Alarm and Events (AE) defines an interface that can be used to monitor events. IEC Time series data access (TSDA): OPC Historical Data Access (HDA) defines an interface that can be used to access historical data. The three interfaces are based on Classic OPC standards DA, GES and HDA which are maintained by the OPC Foundation 3. Unfortunately, the Classic OPC standards did 2 The term prosumer denotes a combination of electricity consumer and electricity producer, i.e. mostly households which not only consume power but also feed power into the grid, for instance with equipment subsidized under the provisions of the Renewable Energies Act [4] 3 Fig. 2. Combining CIM and OPC UA. not meet today s requirements especially in terms of platform independence and internet compatibility. Hence, the OPC Foundation started the development of a new standard which should be an evolution of Classic OPC standards. The result is the OPC Unified Architecture (UA) that copes with the new requirements. The UA is standardized as the IEC family and whereas Classic OPC is only focusing process automation, the UA also focuses on general data exchange. Furthermore, the UA provides an excellent possibility to match the views of the IT and automation domain, because it intends to set a domain specific information model on top of the abstract UA information model. The CIM offers almost everything that is basically needed to fulfill the requirements of an energy domain specific data model. Figure 2 shows how the CIM could be combined with the OPC UA and how semantic web services could be used to annotate meta-data [13]. In this case, meta-data annotation helps to find appropriate system services using a well defined OPC UA interface to the automation layer. C. Support of Distributed Energy Resources and Electromobility Due to the fact that the CIM was developed within the Control Center API (CCAPI) Research Project realized by EPRI in mid 90s [14], mainly focusing Control Center Application, Distributed Energy Resources (DER) as well as Plug-in (hybrid) Electric Vehicles (PEV/PHEV) were by no means a factor of this and were hereby handled second rate. Currently, it is possible to model only very basic replacement for DER assets with very few technical attributes and associations to other energy systems. The recent rise of DER due to the worldwide CO 2 discussion and the will to more independent energy supply and therefore the further expansion in the future,

4 4 lifts the topic of DER in a more central point in the means of standardization and especially for the CIM. The standardization roadmaps [4] and [2] point out the rising meaning of DER, especially in the field of Virtual Power Plants (VPP) and the required EMS to operate those. The billing and weather forecasting must also be taken into account for a economically advantageous operation of VPP. The aforementioned topics got little or no attention so far. The IEC TC 57 WG 14 aims to develop a CIM for DER extension in the near future. A small working group for this was already formed. Target will be a CIM extension which tries to be most compatible to the IEC Communications systems for Distributed Energy Resources to enhance the communication-interface to the automation layer. In addition, an extension of the CIM regarding PEV/PHEV is also planned within this group. Electromobility is gaining momentum regarding smart grid activities and introduce new requirements and possibilities into traditional electrical networks by for example providing mobile storage capabilities. This requires cooperation between different sectors of industry (like automotive and energy) and hence communication between energy market participants like metering point operators and suppliers on the one hand and the electric vehicle on the other hand. At the moment, business models and processes regarding electric vehicles are subject of change and mainly experienced in field tests and pilot projects, see for example the BMWi 4 programs ICT for Electromobility 5. According to the National Institute of Standards and Technology (NIST) roadmap extensions of the CIM are needed especially regarding price and tariff models [4]. Parts of these extensions are already in progress in the programs of the German E-Energy and Electromobility model regions. D. Missing Multi-national Market Communication Currently, the CIM doesn t support German national market communication. Market communication is subject of national regulation and legislation and therefore different specifications have to be fulfilled. In Germany, the EDIFACT format is mandatory for several market communication processes, like customer switching as shown in [3] and [15]. The IEC and its parts aim at addressing market communication via the CIM, but these series of standards are mainly still work in progress, see for example [16]. In the past, CIM was only mandatory for market communications regarding topology exchange within the US. Currently several liaisons exist between IEC TC 57 WGs (like 14 and 16) and ENTSO-E 6 and ebix 7 at the European level. ENTSO-E for example successfully established an own CIM-based profile for the exchange of system operations and system studies [17]. The development of tailored profiles for different countries based on the CIM seems a feasible way to implement CIM- 4 German federal ministry of economics European network of transmission system operators for electricity, see 7 The European forum for energy Business Information exchange, see based market communication and taking specific national requirements into account. Another important aspect is the lack of test facilities to support interoperability tests and checking of messages or communication regarding CIM or standard conformance. This is essential for supporting market participants to establish communication between them and enabling for conformance test of information systems. E. Social-economic Issues One of the issues of creating CIM extensions and the general data model is the aspect that one has to agree upon a shared understanding of the electric utility domain model. This is both one of the strength and weaknesses of the CIM. The work of agreeing on a certain definition has to do a lot with the domain background of the participating experts. Being an engineer or being from the utilities ICT does make a difference due to different backgrounds in education where the experts did not get a common definition model from their corresponding curricula. Also, IT and automation tend to be different fields and departments within an utility - therefore, there can be prejudices on both sides which make for a difficult understanding in the very standardization process and the projects itself. F. Model Driven Development The CIM is provided electronically as UML model in Enterprise Architect and conceptual procedures exist to support model driven development (MDD) of messages. Despite this, MDD is supported only partly by different tools for specific purposes, like generation of Web Ontology Language (OWL) ontologies and validation of CIM XML files through the CIM- Tool 8. Within the MDD framework of the Object Management Group (OMG) building upon the Meta Object Facility (MOF) and a four-layer meta-model structure, the CIM can be seen as one of those layers being a UML model and implementation independent. It should be a perfect natural fit to use the CIM for a MDD approach lowering the manual efforts to create one interface or serialization from the corresponding domain data model. The idea is to use the CIM model (of course, with all the aspects of versioning discussed within this contribution) to generate directly a database layer, a custom payload schema with different XML styles (flat, nested, typed) or a custom WSDL (Web Services Description Language) interface for web service descriptions. However the connection of modeldriven development seems to be strong and powerful, MDD itself is not standardized (look at XML Metadata Interchange (XMI) being the UML interchange format) and tool chains seems to be quite fragile and vendor-specific. Therefore, one should also focus on open formats for this process or, at least provide or use open source tools which make it possible for the users to adopt changes if a new version of the CIM breaks the old tool chain. 8

5 5 G. Versioning The current version of the CIM is release 13, whereas work has already been started for release 14 and release 15. In section II-B the dynamic development of the CIM was mentioned. During the development process a lot of things within the data model can be changed. New packages, classes, attributes and associations can be defined as well as old ones can be deleted. Furthermore, a lot of different revisions can be made: Classes can be moved from one package to another, so that the path changes. The status of single objects can be changed from informative to normative and vice versa. Association cardinalities can be changed. The status of attributes can be changed from optional to mandatory and vice versa (in the case of profiles). Semantics of objects can be changed. The inheritance structure can be changed. One advantage of the CIM is the electronic data model additionally to the analog paper-versions of the IEC and IEC which standardize the data model. The current version of the IEC , for example, is edition 2 including the electronic data model release 11. But also all other parts of both standard series are under continuously development and new editions of them are published every four to five years. In terms of versioning especially the following sub-parts are of major interest: : Common information model (CIM) base : CIM based graphics exchange : Common Information Model Resource Description Framework (CIM RDF) schema : XML naming and design rules : Interfaces for meter reading and control : Common information model (CIM) extensions for distribution : CIM RDF Model exchange format for distribution A good example is the current development of the IEC edition 2 which includes major changes compared to edition 1. The whole message structure for both header and payload was changed. Furthermore, normative schemas are defined for the first time and semantic information is added to attributes. These changes have great influence on other parts of the IEC series which address CIM-based messaging, because the second edition should be used as a reference. Hence, the complete CIM-based message exchange will be changed in the near future. That leads to the conclusion that a system or an application can only be conform to one version of the electronic data model or to one edition of the sub-standards. To cope with this problem it is necessary to focus on the differences between two versions. Changes regarding the data model are the most important ones, because they can affect existing and implemented interfaces. In the case that new objects were added to the CIM all implemented interfaces will still be upward compatible with the new CIM version. If those new objects could be used to replace objects of the own namespace, Fig. 3. Standardization organizations [4] messages and thus the interfaces can be migrated. This is the typical case for changes within the data model and it causes less migration costs. Changes concerning the basic model structure and basic data types are very seldom. Those changes have a large impact on the CIM structure and lead to mayor interface revisions. Hence, it has to be decided occasionally which migration strategy should be used and if it is reasonable to switch to a new CIM version. Another possibility to cope with the versioning is to let an Enterprise Service Bus (ESB) convert messages between different CIM versions. So, various CIM versions could be used simultaneously on a bus which knows which system expects which CIM version for its communication. In general, a model-maintenance process must be institutionalized und documented within each enterprise. H. Participation in the Standardization Taking part in the standardization requires time, work and knowledge to get the CIM extended or aligned to fit the needed requirements. Often the attendance of several meetings, workshops and discussions is needed to get things done. Publishing a new version of the standards requires sticking to time consuming standardization procedures and maintenance cycles. Regarding participation in the standardization several levels of involvement and through different organizations exist. One possibility to directly take part is to join standardization organizations on national, European and/or international level. Figure 3 illustrates the different organizations from a German perspective. Joining the IEC TC 57 WG 13, 14, 16 or 19 which are currently responsible for developing the CIM is a good way to actively engage but usually requires the most effort. On the other hand, involvement is recompensed through fruitful discussions with experts. A more indirect way is to join associations, organizations or standardization bodies that have liaisons with the corresponding IEC TC 57 WGs and can influence the development of the CIM. Figure 4 shows some organizations which have liaisons with the IEC TC 57 and its WGs. A good starting point is joining the CIMug which also hosts the electronic version of the CIM and provides access to draft versions of the standards. In addition, CIMug members can enter

6 6 Fig. 4. IEC/TC 57 in the context of other committees and organizations [4] modeling issues through a website form and influence hereby the development of the CIM. Speeding up these processes and providing means to allow for early contribution of new proposals are needed. Small companies or other organizations that can t afford active participation or membership in SDO should be enabled to provide their requirements. I. Tool Support Even though several tools support the work with the CIM [18] and a CIM users group working group is focusing on methods and tools for enterprise integration (MTEI) [19] exists, integrated tool suites supporting the different aspects of model driven development are still missing. Most of the tools provide special features addressing only specific parts, like validation (Mercury), generation of message schemas (CIMTool) or generation of documentation (jcleancim). The CIM is maintained in Sparx Systems Enterprise Architect but the tools are mostly based on other technological platforms and therefore an installation of different tools is required. More and more tools are developed (like CimConteXtor or CIMClipse) [20], but rather than providing more specialized tools a more holistic approach is recommended, providing a management environment for CIM-based enterprise integration as open source to leverage the usage of CIM. J. Multi-Technology Infrastructure in the Customer-Domain The customer domain is now and in the future a multiutility and multi-technology domain. Different standards from different domains are clashing together. As mentioned in III-A, the CIM is lacking the multi-utility support at this time. Furthermore, the CIM doesn t provide interfaces or mappings to all possible customer-communication standards. In addition the data privacy issues are momentarily out of scope, which are definitely necessary for customers privacy. To further integrate the home standards and data privacy at developing or extending the CIM would help to support the role of the customer in the future smart grid. K. Documentation Few documentation is publicly available for training on the CIM. Mostly documents are only accessible through participation in user groups (like the CIMug) or SDOs (like the IEC). Even though several paper (e.g. [21]) and technical reports exist describing the appliance of CIM in different fields, part of them are also publicly available like some reports of EPRI (e.g. [22], [23]). Their understanding requires already basic knowledge on the CIM. More academic, educational and introduction material on CIM, like [24], should be published and stronger promoted to speed up the dissemination as well as to support the usage of the CIM. Knowledge of the CIM is crucial for reducing integration costs and enabling interoperability within the smart grid. IV. GENERAL APPROACHES There are many types of problems which can arise during the work with the CIM. For many of them there are undocumented approaches. As mentioned in section III-K there are hardly any documentations on this, so the first contact point should be the CIM users group or alternatively the corresponding authors of the standards. To minimize the problems in the future participation in standardization is clearly recommended as mentioned in section III-H.

7 7 Fig. 5. Overview of CIM Standards Methodology adopted from [25] A brief description of general problems if involved in projects using the CIM and recommendations regarding CIM as well as its evolution are provided in [25] and [26]. First of all CIM standards are bit out of the ordinary standards which usually freeze bits of technology and fix agreements about interfaces between parties [26]. CIM is designed to achieve consistent, high quality models across a large domain and therefore might be subject of change when for example adding new interfaces [25]. This is clearly different from normal situations where standards are expected to be stable. For problems with the data model related to missing or incomplete classes and associations it should be obvious that it is impossible to offer a complete data model with all possible objects. The only possible way to encounter this problem is to use in-house extensions of the CIM. One should accept that extensions are necessary and a natural and supported way to work with the CIM and clearly distinguish between the CIM and an holistic enterprise data model which has to cover more. One particular problem is how to deal with different XML schemas based on different versions or profiles of the CIM which cannot be dealt with by the standard itself but must be incorporated into the design of the enterprise service bus used. Here, vendors already have solutions which should be used. Before using the CIM its scope and Standards Methodology have to be considered, see figure 5. The methodology consists of four layers, the first Information containing the CIM as well as related custom extensions and other data models. Next to the information layer two layers exist, the Contextual and Assembly Rule layer providing profiles and rules for the profiles. At the bottom the Instance layer is located containing the respective schemas. According to the described methodology, profiles should address the requirement on stability and be subject of tests for interfaces based on a contextual model, not the CIM model itself. Contextual models are derived from a specific version of the CIM but do not always require to be updated simply because CIM changes. Source [25] recommends to use CIM as starting point and minimize direct connections between exchanged data and internal (e.g. not to hardwire CIM to application internals) and hereby avoiding costly changes. V. CONCLUSION The CIM has proven to be a good example on how to standardize semantics for the better exchange of data between various systems and cope with different challenges when to integrate on application level. It has largely spread and is considered to be one of the core standards of the future smart grid which is widely accepted by the most important standardization initiatives for the smart grid. However, despite all its benefits and application, some flaws remain which should be dealt with. For one, a domain data model can only be as good as the expert s input. There has to be constant participation by vendors, consultants and manufacturers to make it meaningful. Furthermore, it should be considered opening future extensions to multi-utility support which would then lift the CIM to a utility domain model. This leads to the integration of other models whereas the IEC is of highest importance. Integration of the IT layer and the field automation layer is one crucial aspect of the upcoming smart grid and has to be dealt with. Another fallacy includes the improper use of IT techniques when dealing with the CIM.

8 8 Proper modeling using little cohesion, proper constraining and versioning, proper serializations and tool chains must be applied to get the most out of a shared domain ontology. The technical aspects and the social aspects of developing might not be sufficient since the CIM has to be seen in context with the IEC TC 57 Seamless Integration Architecture (SIA). It is very important to take other domains like different businessto-business communication at market level as well as field automation data models like IEC into account. Furthermore, as the grid changes, new objects and relations come up. Integrating storage, electric vehicles, distributed generation, tariffing models and national market communications into the model is of highest importance to get further asset and runtime views for the data exchanged in the utility. [24] A. McMorran. (2007) An Introduction to IEC & : The Common Information Model. [25] J. Britton. (2010, June) Doing a CIM Project. Milan, Italy. [26] J. Britton and A.N. devos, CIM-Based Standards and CIM Evolution, in IEEE Transactions on Power Systems, vol. 20, no. 2, May Mathias Uslar Since 2004, after having finished his studies of informatics with a minor in legal informatics and business, Mathias Uslar joined the OFFIS - Institute in Oldenburg Germany where he is working in the Utility Informatics branch. His main interests are standardization and utility EAI. He also brings in his expertise to both national and international standardization boards. He is also the director of the Center for IT Standards in the Energy Domain, abbreviated CISE ( REFERENCES [1] NIST Special Publication 1108 NIST Framework and Roadmap for Smart Grid Interoperability Standards, [2] SMB Smart Grid Strategic Group (SG3), IEC Smart Grid Standardization Roadmap, June [3] OFFIS, SCC Consulting, and MPC management coaching, Untersuchung des Normungsumfeldes zum BMWi-Foerderschwerpunkt E- Energy - IKT-basiertes Energiesystem der Zukunft, [4] DKE, The German Standardization Roadmap E-Energy/Smart Grid. VDE, [Online]. Available: E-Energy/Seiten/Links.aspx [5] Electricity Networks Strategy Group, A Smart Grid Routemap, [Online]. Available: [6] FutuRed, Spanish Electrical Grid Platform, Strategic Vision Document, [Online]. Available: [7] Microsoft, Smart Energy Reference Architecture SERA, [8] DIN, Die deutsche Normungsstrategie aktuell, [Online]. Available: upload/media/2896/dns 2010d akt.pdf [9] Ed. 1: System Interfaces for Distribution Management - Part 11: Distribution Information Exchange Model, IEC Std., [10] Ed. 1: Energy management system application program interface (EMS-API) - Part 301: Common information model (CIM) base, IEC Std., [11] M. Uslar, Ontologiebasierte Integration heterogener Standards in der Energiewirtschaft, Ph.D. dissertation, [12] M. Uslar, F. Gruening and S. Rohjans, Cases on Semantic Interoperability for Information Systems Integration: Practices and Applications. IGI Global, 2009, ch. A Use Case for Ontology Evolution and Interoperability: The IEC Utility Standards Reference Framework 62357, pp [13] S. Rohjans, M. Uslar, and H. J. Appelrath, OPC UA and CIM: Semantics for the smart grid, in Transmission and Distribution Conference and Exposition, 2010 IEEE PES, 2010, pp [14] EPRI, Guidlines for Control Center Application Program Interface, EPRI, Tech. Rep., [15] Bundesnetzagentur, Anlage zum Beschluss BK Darstellung der Geschaeftsprozesse zur Anbahnung und Abwicklung der Netznutzung bei der Belieferung von Kunden mit Elektrizitaet, GPKE, [16] Ed. 1.0: Framework for energy market communications - Part 301: Common Information Model (CIM) Extensions for Markets, IEC Std., [17] ENTSO-E, COMMON INFORMATION MODEL (CIM) MODEL EXCHANGE PROFILE, [18] CIM users group. (2010, May) CIM Tools List. [19] CIM users group. (2010, June) CIM Methods & Tools for Enterprise Integration. [20] C. Effantin and A. McMorran. (2010, June) MTEI Report Methods & Tools for Enterprise Integration. Milan, Italy. [21] S. Neumann, J. Britton, A. DeVos and S. Widergren, Use of the CIM Ontology, in Conference Proceedings of DistribuTech 2006, Tampa, Florida, Februar [22] L. King, The Common Information Model for Distribution, EPRI, Tech. Rep., November [23] P. Hirsch, CIM Application Integration, EPRI, Tech. Rep., February Sebastian Rohjans has joined the OFFIS - Institute for Information Systems in late He holds a computer science degree from the University of Oldenburg with a minor in business and wrote his thesis about ontology based integration. He is now working in industrial setting projects having the same scope. His research interests include semantic web services, the OPC unified architecture and ontology based mediation. Michael Specht works since August 2008 as a scientific assistant at the OFFIS institute. He wrote his diploma thesis about Ontology based integration of quality codes in the electricity domain. His main working topics are CIM based XML messaging and CIM topology modeling. José Manuel González Vázquez works since January 2008 as a scientific assistant and PhD candidate at the OFFIS institute, Oldenburg. His research is on reference models and IT systems in the utility domain (electricity and gas). Further on he is actively involved in national and international standardization and is member of the IEC TC 57 Working Group 14, where he is part of the Common Information Model (CIM) modeling team.