1

What is the CIM lacking?Mathias Uslar, Sebastian Rohjans, Michael Specht, Jose Manuel Gonzalez Vazquez

Abstract—The IEC 61970/61968 Common Information Modelis undoubtedly one of the core standards of the future smart gridas pointed out by different organizations and recent standard-ization roadmaps. Its acceptance in the energy sector and theactive standardization work is very high and make it one of themost established standards worldwide in the energy domain. Butnot all requirements are met by the CIM to be the standard ofchoice in any possible situation. This work tries to specify someof the main gaps identified in different research projects like inthe German e-energy projects and in day-to-day business withelectric utility companies and the surrounding industry. There isalso the attempt to recommend some known approaches to thesegaps and to advise general solutions to encounter problems whileusing the Common Information Model.

I. INTRODUCTION

DUE to previous experiences as well as several nationaland international studies and roadmaps (e.g. [1], [2], [3])

it is generally accepted that an appropriate Information andCommunication Technologies (ICT) infrastructure is needed toenable the already started change in the utility sector - the socalled smart grid. Furthermore, current developments point outthat the use of standards within this process is indispensable.A lot of new functions, services and use cases arise and allstakeholders within the smart grid have to cope with newchallenges in terms of interoperability and integration issues.One important communication standard which provides apowerful data model as well as various interface specificationsand 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 thedynamic smart grid processes.

Hence, the following section II introduces the CIM andmotivates the overall use of standards, whereas section IIIshows the identified gaps for the CIM. Section IV gives generalrecommendations to encounter the problems and section Vfinally concludes the paper.

II. COMMON INFORMATION MODEL

A. Motivation of using Standards

The smart grid is the most important topic within theutility domain. One aspect is the agreement on the factthat a changing power infrastructure needs a new-style ICTinfrastructure. Such a radical and far-reaching process providesseveral opportunities - in this context the opportunity to reacha level regarding interoperability for the new system that isas high as possible. An established way to approach thischallenge is the application of standards. Accordingly, lotsof countries develop national standardization roadmaps (e.g.[4], [5], [6]) as well as organizations and companies specifytheir own standardization strategies (e.g. [7]). The Germanstandardization strategy [8], for example, defines amongst

TABLE IQUANTITATIVE COMPARISON OF CIM RELEASES 11 AND 13

Release 11 Release 13Packages 53 45Classes ≈ 800 ≈ 900

Associations ≈ 780 ≈ 870

Native attributes ≈ 2000 ≈ 2650

others the following goals which can be achieved by the useof standards:

• Standardization as a strategic instrument supports theeconomical and social success.

• Standardization relieves the regulatory activities of thegovernment.

• 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 smartgrid architectures is the Common Information Model (IEC (In-ternational Electrotechnical Commission) 61970/61968). TheCIM is an EMS-API standard containing a large data andinformation model for the energy domain. Overall, the CIMprovides a powerful integration framework which includesseveral technology mappings and interface specifications inaddition to the platform independent data model. Figure 1provides an overview on the important parts of the twostandard series IEC 61968 [9] and IEC 61970 [10]. Theyconsist of common parts (e.g. glossary), component inter-face specifications (e.g. common services or GDA (GenericData Access)), serializations (e.g. RDF (Resource DescriptionFramework)), an interface reference model and data models.

The CIM is maintained by four model managers, one fromeach related Working Group (WG) (13, 14, 16 and 19).Furthermore, many members of the WGs joint the work ofthe CIM user group1 (CIMug). The maintaining process isa continuously improvement of the model using the UnifiedModeling Language (UML) format. Once a year a new releaseis published, the current release is version 13. To emphasizethe development see table I which shows a quantitative com-parison of the releases 11 and 13 (see [12]).

In general, three main use cases for the CIM exist. Thefirst use case deals with the exchange of messages (e.g.Extensible Markup Language (XML)-based) among differentstakeholders. The messages are based on the syntax andsemantics of the domain ontology CIM. Within the second use

1http://cimug.ucaiug.org

2

Fig. 1. Overview on IEC 61970 and IEC 61968 [11].

case the CIM provides the basis for modeling topologies of thepower grid for both transmission and distribution grids. Thesetopologies are serialized in RDF and they will be exchangedamong utilities. The last use case takes standardized interfacesbetween systems and interface specifications into account.

C. Why using CIM?

Being a Common Information Model originally created forthe very purpose of a common exchange language for databetween different systems. Originally aiming at integratingvarious Energy Management Systems (EMS) with secondaryIT Systems, Electric Power Research Institute (EPRI) soonrealized that a pre-condition for meaningful system interfacesis a proper and sound semantic model for the data exchangedat interface level. Therefore, they started working at theCIM being a semantic data model for utility data exchange.Given the amount of data exchanged inter- and intra-utilitybetween systems, one can hardly argue that there is no use inusing common semantics to exchange data between systemsfrom different vendors and avoiding manual work-intenseintegration efforts. What is of highest importance is that thecommon semantics are used for interfaces and data exchangeonly, having no impact on the existing internal models andtherefore being less stressful to implement than what has beenmost of the times called an enterprise information model. Ifseveral systems have to exchange data bi-lateral, you can avoidthe dilemma of a highly meshed exchange grid of interfacesbetween systems.

D. Distribution of the CIM

Although one can easily argue, that being an internationalstandard agreed upon by hundreds of experts bringing in their

expertise on modeling the electric power grid, the CIM mustbe of highest relevance to all utilities having to integrate a highnumber of systems from different vendors. The CIM indeedhas a different impact in the different regions of the world.In the US; being a former EPRI project the CIM has a gooddegree of use within several utilities. The CIMug does regularmeetings giving updates which most of the time is hostedby important players like Microsoft, Oracle or PGE. Also,having a strong focus on data exchange on nodal markets anda different style of running the distribution grid with radialfeeders, it is more used in the US than in Europe due toregulation requirements. Within Asia, India and China arethe biggest players to look for. As they are changing theirinfrastructure right now, those nations can directly switch tothe CIM being an open standard and have their infrastructuredirectly updated to the latest trends. This is not true forEurope, where CIM has to deal with the existing SupervisoryControl and Data Acquisition (SCADA) systems which mostof the time have not yet reached the end of their expected lifespan. Also, within Europe, the focus on the automation ratherthan the IT part of the utility is pre-dominant. Most of theEuropean national mirror committees of IEC have within theirTechnical Committee (TC) 57 scope a focus of their expertson IEC 61850 for substation automation and communication.This, e.g. leads to the fact that though having the largestSCADA manufacturers around in the world, Germany hasno CIM working groups mirrors as of today although theyhave identified the CIM being the core element of the Germanstandardization smart grid roadmap [4].

III. IDENTIFIED GAPS

The following section describes some of the identified gapsin the CIM in detail. Several of these gaps are meant to be

3

handled in the near future so that designated approaches willbe pointed out or recommended possible actions are shown.This list of gaps is not exhaustive but gives an overview onexisting problems which a stakeholder of the smart grid whois using CIM will most probably come across.

A. Multi-Utility Support

The CIM is an undoubted standard in the electrical powersupply domain but several stakeholders of the future smartgrid share the vision of a multi-utility distribution systemresponsible for the transportation of gas, oil, water, long-distance heating and electric power similarly [2], [4]. Thesmart grid prosumer2 of the future has different energy sourcesfor his disposal to meet his own unique needs. Also someelectric power companies are already acting as multi-utilitydistributor and are delivering more than one energy resourceto the prosumer. The aforementioned resources share not onlythe properties concerning distributor and receiver but alsothe grid-bound infrastructure. The CIM already enables thepossibility to model a detailed energy network as well as tosupport the administration of customer- and billing-data. Theinterfaces to other systems are considered as well. To mergetwo or more currently different systems for various resourcesraises the potential benefits enormously. The resulting synergyimplies a gain to the CIM main objectives to reduce the timeand cost to integrate new applications to an EMS and toprotect investments that are already working effectively in anEMS. An extension to multi-utility seems reasonable but needsfurther examination in terms of necessity and feasibility.

B. Well-defined Interfaces to the Automation Layer

Component Interface Specifications (CIS) and Generic In-terface Definitions (GID) are core components of the CIM.Besides, the abstract data model the CIM provides technologymappings to specify how the data model can be used. The CIMdata model defines ”What” data can be exchanged and the CISand GID specifies ”How” these data can be exchanged. Onevery important interface is the one focusing on the automationlayer. Therefore, the following three sub-parts consider varioustypes of data exchange:

• IEC 61970-404 High speed data access (HSDA): OPCData Access (DA) defines an interface that can be usedto read and write real-time data.

• IEC 61970-405 Generic eventing and subscription (GES):OPC Alarm and Events (AE) defines an interface that canbe used to monitor events.

• IEC 61970-407 Time series data access (TSDA): OPCHistorical Data Access (HDA) defines an interface thatcan be used to access historical data.

The three interfaces are based on Classic OPC standardsDA, GES and HDA which are maintained by the OPCFoundation3. Unfortunately, the Classic OPC standards did

2The term prosumer denotes a combination of electricity consumer andelectricity producer, i.e. mostly households which not only consume powerbut also feed power into the grid, for instance with equipment subsidizedunder the provisions of the Renewable Energies Act [4]

3www.opcfoundation.org/

Fig. 2. Combining CIM and OPC UA.

not meet today’s requirements especially in terms of platformindependence and internet compatibility. Hence, the OPCFoundation started the development of a new standard whichshould be an evolution of Classic OPC standards. The resultis the OPC Unified Architecture (UA) that copes with the newrequirements. The UA is standardized as the IEC 62541 familyand 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 viewsof the IT and automation domain, because it intends to seta domain specific information model on top of the abstractUA information model. The CIM offers almost everything thatis basically needed to fulfill the requirements of an energydomain specific data model.

Figure 2 shows how the CIM could be combined with theOPC UA and how semantic web services could be used toannotate meta-data [13]. In this case, meta-data annotationhelps to find appropriate system services using a well definedOPC UA interface to the automation layer.

C. Support of Distributed Energy Resources and Electromo-bility

Due to the fact that the CIM was developed within theControl Center API (CCAPI) Research Project realized byEPRI in mid 90s [14], mainly focusing Control Center Appli-cation, Distributed Energy Resources (DER) as well as Plug-in(hybrid) Electric Vehicles (PEV/PHEV) were by no means afactor of this and were hereby handled second rate. Currently,it is possible to model only very basic replacement for DERassets with very few technical attributes and associations toother energy systems. The recent rise of DER due to theworldwide CO2 discussion and the will to more independentenergy supply and therefore the further expansion in the future,

4

lifts the topic of DER in a more central point in the meansof standardization and especially for the CIM. The standard-ization roadmaps [4] and [2] point out the rising meaning ofDER, especially in the field of Virtual Power Plants (VPP) andthe required EMS to operate those. The billing and weatherforecasting must also be taken into account for a economicallyadvantageous operation of VPP. The aforementioned topics gotlittle or no attention so far. The IEC TC 57 WG 14 aims todevelop a CIM for DER extension in the near future. A smallworking group for this was already formed. Target will bea CIM extension which tries to be most compatible to theIEC 61850-7-420 ”Communications systems for DistributedEnergy Resources” to enhance the communication-interfaceto the automation layer. In addition, an extension of the CIMregarding PEV/PHEV is also planned within this group.

Electromobility is gaining momentum regarding smart gridactivities and introduce new requirements and possibilitiesinto traditional electrical networks by for example providingmobile storage capabilities. This requires cooperation betweendifferent sectors of industry (like automotive and energy)and hence communication between energy market participantslike metering point operators and suppliers on the one handand the electric vehicle on the other hand. At the moment,business models and processes regarding electric vehicles aresubject of change and mainly experienced in field tests andpilot projects, see for example the BMWi4 programs ”ICTfor Electromobility”5. According to the National Institute ofStandards and Technology (NIST) roadmap extensions of theCIM are needed especially regarding price and tariff models[4]. Parts of these extensions are already in progress in theprograms of the German E-Energy and Electromobility modelregions.

D. Missing Multi-national Market Communication

Currently, the CIM doesn’t support German national marketcommunication. Market communication is subject of nationalregulation and legislation and therefore different specificationshave to be fulfilled. In Germany, the EDIFACT format ismandatory for several market communication processes, likecustomer switching as shown in [3] and [15]. The IEC 62325and its parts aim at addressing market communication via theCIM, but these series of standards are mainly still work inprogress, see for example [16]. In the past, CIM was onlymandatory for market communications regarding topologyexchange within the US.

Currently several liaisons exist between IEC TC 57 WGs(like 14 and 16) and ENTSO-E6 and ebIX7 at the Europeanlevel. ENTSO-E for example successfully established an ownCIM-based profile for the exchange of system operations andsystem studies [17].

The development of tailored profiles for different countriesbased on the CIM seems a feasible way to implement CIM-

4German federal ministry of economics.5http://www.ict-em.com.6European network of transmission system operators for electricity, see

http://www.entsoe.eu7The European forum for energy Business Information eXchange, see

http://www.ebix.org

based market communication and taking specific nationalrequirements into account.

Another important aspect is the lack of test facilities tosupport interoperability tests and checking of messages orcommunication regarding CIM or standard conformance. Thisis essential for supporting market participants to establishcommunication between them and enabling for conformancetest of information systems.

E. Social-economic Issues

One of the issues of creating CIM extensions and the generaldata model is the aspect that one has to agree upon a sharedunderstanding of the electric utility domain model. This isboth one of the strength and weaknesses of the CIM. Thework of agreeing on a certain definition has to do a lot withthe domain background of the participating experts. Beingan engineer or being from the utilities’ ICT does make adifference due to different backgrounds in education wherethe experts did not get a common definition model from theircorresponding curricula. Also, IT and automation tend to bedifferent fields and departments within an utility - therefore,there can be prejudices on both sides which make for a difficultunderstanding in the very standardization process and theprojects itself.

F. Model Driven Development

The CIM is provided electronically as UML model in En-terprise Architect and conceptual procedures exist to supportmodel driven development (MDD) of messages. Despite this,MDD is supported only partly by different tools for specificpurposes, like generation of Web Ontology Language (OWL)ontologies and validation of CIM XML files through the CIM-Tool8. Within the MDD framework of the Object ManagementGroup (OMG) building upon the Meta Object Facility (MOF)and a four-layer meta-model structure, the CIM can be seen asone of those layers being a UML model and implementationindependent. It should be a perfect natural fit to use the CIMfor a MDD approach lowering the manual efforts to create oneinterface or serialization from the corresponding domain datamodel. The idea is to use the CIM model (of course, with allthe aspects of versioning discussed within this contribution) togenerate directly a database layer, a custom payload schemawith different XML styles (flat, nested, typed) or a customWSDL (Web Services Description Language) interface forweb service descriptions. However the connection of model-driven development seems to be strong and powerful, MDDitself is not standardized (look at XML Metadata Interchange(XMI) being the UML interchange format) and tool chainsseems to be quite fragile and vendor-specific. Therefore, oneshould also focus on open formats for this process or, at leastprovide or use open source tools which make it possible forthe users to adopt changes if a new version of the CIM breaksthe old tool chain.

8www.cimtool.org

5

G. Versioning

The current version of the CIM is release 13, whereaswork has already been started for release 14 and release 15.In section II-B the dynamic development of the CIM wasmentioned. During the development process a lot of thingswithin the data model can be changed. New packages, classes,attributes and associations can be defined as well as old onescan be deleted. Furthermore, a lot of different revisions canbe made:

• Classes can be moved from one package to another, sothat the path changes.

• The status of single objects can be changed from infor-mative 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 61970-301 and IEC 61968-11 which standardize the data model. Thecurrent version of the IEC 61970-301, for example, is edition2 including the electronic data model release 11. But alsoall other parts of both standard series are under continuouslydevelopment and new editions of them are published everyfour to five years. In terms of versioning especially thefollowing sub-parts are of major interest:

• 61970-301: Common information model (CIM) base• 61970-453: CIM based graphics exchange• 61970-501: Common Information Model Resource De-

scription Framework (CIM RDF) schema• 61968-1-2: XML naming and design rules• 61968-9: Interfaces for meter reading and control• 61968-11: Common information model (CIM) extensions

for distribution• 61968-13: CIM RDF Model exchange format for distri-

butionA good example is the current development of the IEC

61968-9 edition 2 which includes major changes comparedto edition 1. The whole message structure for both headerand payload was changed. Furthermore, normative schemasare defined for the first time and semantic information is addedto attributes. These changes have great influence on other partsof the IEC 61968 series which address CIM-based messaging,because the second edition should be used as a reference.Hence, the complete CIM-based message exchange will bechanged in the near future.

That leads to the conclusion that a system or an applicationcan only be conform to one version of the electronic datamodel or to one edition of the sub-standards. To cope with thisproblem it is necessary to focus on the differences betweentwo versions. Changes regarding the data model are themost important ones, because they can affect existing andimplemented interfaces. In the case that new objects wereadded to the CIM all implemented interfaces will still beupward compatible with the new CIM version. If those newobjects 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 thetypical case for changes within the data model and it causesless migration costs. Changes concerning the basic modelstructure and basic data types are very seldom. Those changeshave a large impact on the CIM structure and lead to mayorinterface revisions. Hence, it has to be decided occasionallywhich migration strategy should be used and if it is reasonableto switch to a new CIM version. Another possibility tocope 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 buswhich knows which system expects which CIM version for itscommunication. In general, a model-maintenance process mustbe institutionalized und documented within each enterprise.

H. Participation in the Standardization

Taking part in the standardization requires time, work andknowledge to get the CIM extended or aligned to fit theneeded 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 totime consuming standardization procedures and maintenancecycles.

Regarding participation in the standardization several levelsof involvement and through different organizations exist. Onepossibility to directly take part is to join standardizationorganizations on national, European and/or international level.Figure 3 illustrates the different organizations from a Germanperspective. Joining the IEC TC 57 WG 13, 14, 16 or 19which are currently responsible for developing the CIM is agood way to actively engage but usually requires the mosteffort. On the other hand, involvement is recompensed throughfruitful discussions with experts.

A more indirect way is to join associations, organizationsor standardization bodies that have liaisons with the corre-sponding IEC TC 57 WGs and can influence the developmentof the CIM. Figure 4 shows some organizations which haveliaisons with the IEC TC 57 and its WGs. A good startingpoint is joining the CIMug which also hosts the electronicversion of the CIM and provides access to draft versionsof the standards. In addition, CIMug members can enter

6

Fig. 4. IEC/TC 57 in the context of other committees and organizations [4]

modeling issues through a website form and influence herebythe development of the CIM.

Speeding up these processes and providing means to allowfor early contribution of new proposals are needed. Smallcompanies or other organizations that can’t afford activeparticipation or membership in SDO should be enabled toprovide 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 onmethods and tools for enterprise integration (MTEI) [19]exists, integrated tool suites supporting the different aspectsof model driven development are still missing. Most of thetools provide special features addressing only specific parts,like validation (Mercury), generation of message schemas(CIMTool) or generation of documentation (jCleanCIM). TheCIM is maintained in Sparx Systems Enterprise Architect butthe tools are mostly based on other technological platforms andtherefore an installation of different tools is required. More andmore tools are developed (like CimConteXtor or CIMClipse)[20], but rather than providing more specialized tools a moreholistic approach is recommended, providing a managementenvironment for CIM-based enterprise integration as opensource to leverage the usage of CIM.

J. Multi-Technology Infrastructure in the Customer-Domain

The customer domain is now and in the future a multi-utility and multi-technology domain. Different standards fromdifferent 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 additionthe data privacy issues are momentarily out of scope, whichare definitely necessary for customers privacy. To furtherintegrate the home standards and data privacy at developingor extending the CIM would help to support the role of thecustomer in the future smart grid.

K. Documentation

Few documentation is publicly available for training on theCIM. Mostly documents are only accessible through participa-tion in user groups (like the CIMug) or SDOs (like the IEC).Even though several paper (e.g. [21]) and technical reportsexist describing the appliance of CIM in different fields, partof them are also publicly available like some reports of EPRI(e.g. [22], [23]). Their understanding requires already basicknowledge on the CIM.

More academic, educational and introduction material onCIM, like [24], should be published and stronger promoted tospeed up the dissemination as well as to support the usageof the CIM. Knowledge of the CIM is crucial for reducingintegration costs and enabling interoperability within the smartgrid.

IV. GENERAL APPROACHES

There are many types of problems which can arise duringthe work with the CIM. For many of them there are undoc-umented approaches. As mentioned in section III-K there arehardly any documentations on this, so the first contact pointshould be the CIM users group or alternatively the correspond-ing authors of the standards. To minimize the problems in thefuture participation in standardization is clearly recommendedas mentioned in section III-H.

7

Fig. 5. Overview of CIM Standards Methodology adopted from [25]

A brief description of general problems if involved inprojects using the CIM and recommendations regarding CIMas well as its evolution are provided in [25] and [26]. First ofall CIM standards are bit out of the ordinary standards whichusually freeze bits of technology and fix agreements aboutinterfaces between parties [26]. CIM is designed to achieveconsistent, high quality models across a large domain andtherefore might be subject of change when for example addingnew interfaces [25]. This is clearly different from normalsituations where standards are expected to be stable.

For problems with the data model related to missing orincomplete classes and associations it should be obvious thatit is impossible to offer a complete data model with all possibleobjects. The only possible way to encounter this problem is touse in-house extensions of the CIM. One should accept thatextensions are necessary and a natural and supported way towork with the CIM and clearly distinguish between the CIMand an holistic enterprise data model which has to cover more.One particular problem is how to deal with different XMLschemas based on different versions or profiles of the CIMwhich cannot be dealt with by the standard itself but must beincorporated 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 Methodol-ogy have to be considered, see figure 5. The methodologyconsists of four layers, the first ”Information” containing theCIM as well as related custom extensions and other datamodels. Next to the information layer two layers exist, the”Contextual” and ”Assembly Rule” layer providing profilesand rules for the profiles. At the bottom the ”Instance” layeris located containing the respective schemas. According to the

described methodology, profiles should address the require-ment on stability and be subject of tests for interfaces basedon a contextual model, not the CIM model itself. Contextualmodels are derived from a specific version of the CIM butdo not always require to be updated simply because CIMchanges. Source [25] recommends to use CIM as starting pointand minimize direct connections between exchanged data andinternal (e.g. not to hardwire CIM to application internals) andhereby avoiding costly changes.

V. CONCLUSION

The CIM has proven to be a good example on how tostandardize semantics for the better exchange of data betweenvarious systems and cope with different challenges when tointegrate on application level. It has largely spread and isconsidered to be one of the core standards of the futuresmart grid which is widely accepted by the most importantstandardization initiatives for the smart grid. However, despiteall its benefits and application, some flaws remain whichshould be dealt with. For one, a domain data model can onlybe as good as the expert’s input. There has to be constantparticipation by vendors, consultants and manufacturers tomake it meaningful. Furthermore, it should be consideredopening future extensions to multi-utility support which wouldthen lift the CIM to a utility domain model. This leads tothe integration of other models whereas the IEC 61850 is ofhighest importance. Integration of the IT layer and the fieldautomation layer is one crucial aspect of the upcoming smartgrid and has to be dealt with. Another fallacy includes theimproper use of IT techniques when dealing with the CIM.

8

Proper modeling using little cohesion, proper constrainingand versioning, proper serializations and tool chains must beapplied to get the most out of a shared domain ontology. Thetechnical aspects and the social aspects of developing mightnot be sufficient since the CIM has to be seen in context withthe IEC TC 57 Seamless Integration Architecture (SIA). It isvery important to take other domains like different business-to-business communication at market level as well as fieldautomation data models like IEC 61850 into account. Further-more, as the grid changes, new objects and relations come up.Integrating storage, electric vehicles, distributed generation,tariffing models and national market communications into themodel is of highest importance to get further asset and run-time views for the data exchanged in the utility.

REFERENCES

[1] “NIST Special Publication 1108 NIST Framework and Roadmap forSmart Grid Interoperability Standards”, 2010.

[2] SMB Smart Grid Strategic Group (SG3), “IEC Smart Grid Standardiza-tion Roadmap”, June 2010.

[3] OFFIS, SCC Consulting, and MPC management coaching, “Unter-suchung des Normungsumfeldes zum BMWi-Foerderschwerpunkt ”E-Energy - IKT-basiertes Energiesystem der Zukunft””, 2009.

[4] DKE, The German Standardization Roadmap E-Energy/Smart Grid.VDE, 2010. [Online]. Available: www.dke.de/de/std/KompetenzzentrumE-Energy/Seiten/Links.aspx

[5] Electricity Networks Strategy Group, “A Smart Grid Routemap,” 2010.[Online]. Available: www.ensg.gov.uk

[6] FutuRed, “Spanish Electrical Grid Platform, Strategic VisionDocument”, 2009. [Online]. Available: www.futured.es

[7] Microsoft, “Smart Energy Reference Architecture SERA”, 2009.[8] DIN, “Die deutsche Normungsstrategie aktuell”, 2009. [Online].

Available: www.din.de/sixcms upload/media/2896/DNS 2010d akt.pdf[9] 61968-11 Ed. 1: System Interfaces for Distribution Management - Part

11: Distribution Information Exchange Model, IEC Std., 2008.[10] 61970-301 Ed. 1: Energy management system application program

interface (EMS-API) - Part 301: Common information model (CIM)base, IEC Std., 2007.

[11] M. Uslar, “Ontologiebasierte Integration heterogener Standards in derEnergiewirtschaft”, Ph.D. dissertation, 2009.

[12] M. Uslar, F. Gruening and S. Rohjans, Cases on Semantic Interoper-ability for Information Systems Integration: Practices and Applications.IGI Global, 2009, ch. A Use Case for Ontology Evolution and Interop-erability: The IEC Utility Standards Reference Framework 62357, pp.187–209.

[13] S. Rohjans, M. Uslar, and H. J. Appelrath, “OPC UA and CIM: Seman-tics for the smart grid”, in Transmission and Distribution Conferenceand Exposition, 2010 IEEE PES, 2010, pp. 1–8.

[14] EPRI, “Guidlines for Control Center Application Program Interface”,EPRI, Tech. Rep., 1996.

[15] Bundesnetzagentur, “Anlage zum Beschluss BK6-06-009. Darstellungder Geschaeftsprozesse zur Anbahnung und Abwicklung der Net-znutzung bei der Belieferung von Kunden mit Elektrizitaet, GPKE”,2006.

[16] 62325-301 Ed. 1.0: Framework for energy market communications -Part 301: Common Information Model (CIM) Extensions for Markets,IEC Std., 2010.

[17] ENTSO-E, “COMMON INFORMATION MODEL (CIM) MODELEXCHANGE PROFILE”, 2009.

[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 2006.

[22] L. King, “The Common Information Model for Distribution”, EPRI,Tech. Rep., November 2008.

[23] P. Hirsch, “CIM Application Integration”, EPRI, Tech. Rep., February2004.

[24] A. McMorran. (2007) An Introduction to IEC 61970-301 & 61968-11: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 2005.

Mathias Uslar Since 2004, after having finished his studies of informaticswith a minor in legal informatics and business, Mathias Uslar joined theOFFIS - Institute in Oldenburg Germany where he is working in the UtilityInformatics branch. His main interests are standardization and utility EAI. Healso brings in his expertise to both national and international standardizationboards. He is also the director of the Center for IT Standards in the EnergyDomain, abbreviated CISE (www.ccise.de).

Sebastian Rohjans has joined the OFFIS - Institute for Information Systemsin late 2008. He holds a computer science degree from the University ofOldenburg with a minor in business and wrote his thesis about ontology basedintegration. He is now working in industrial setting projects having the samescope. His research interests include semantic web services, the OPC unifiedarchitecture and ontology based mediation.

Michael Specht works since August 2008 as a scientific assistant at the OFFISinstitute. He wrote his diploma thesis about ”Ontology based integration ofquality codes in the electricity domain”. His main working topics are CIMbased XML messaging and CIM topology modeling.

Jose Manuel Gonzalez Vazquez works since January 2008 as a scientificassistant and PhD candidate at the OFFIS institute, Oldenburg. His research ison reference models and IT systems in the utility domain (electricity and gas).Further on he is actively involved in national and international standardizationand is member of the IEC TC 57 Working Group 14, where he is part of theCommon Information Model (CIM) modeling team.