1. No category

1
What is the CIM lacking?
Mathias Uslar, Sebastian Rohjans, Michael Specht, Jos´e Manuel Gonz´alez V´azquez
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. I NTRODUCTION
D
UE 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. C OMMON I NFORMATION M ODEL
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
Q UANTITATIVE COMPARISON OF CIM RELEASES 11 AND 13
Packages
Classes
Associations
Native attributes
Release 11
Release 13
53
≈ 800
≈ 780
≈ 2000
45
≈ 900
≈ 870
≈ 2650
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 61968 [9] and IEC 61970 [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 group1 (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 http://cimug.ucaiug.org
2
Fig. 1.
Overview on IEC 61970 and IEC 61968 [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 61850 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. I DENTIFIED G APS
The following section describes some of the identified gaps
in the CIM in detail. Several of these gaps are meant to be
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 prosumer2 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 61970-404 High speed data access (HSDA): OPC
Data Access (DA) defines an interface that can be used
to read and write real-time data.
• IEC 61970-405 Generic eventing and subscription (GES):
OPC Alarm and Events (AE) defines an interface that can
be used to monitor events.
• IEC 61970-407 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
Foundation3 . 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 www.opcfoundation.org/
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 62541 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 CO2 discussion and the will to more independent
energy supply and therefore the further expansion in the future,
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 61850-7-420 ”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 BMWi4 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 62325
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-E6 and ebIX7 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 CIM4 German
federal ministry of economics.
5 http://www.ict-em.com.
6 European network of transmission system operators for electricity, see
http://www.entsoe.eu
7 The European forum for energy Business Information eXchange, see
http://www.ebix.org
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 CIMTool8 . 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 www.cimtool.org
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 61970301 and IEC 61968-11 which standardize the data model. The
current version of the IEC 61970-301, 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:
• 61970-301: Common information model (CIM) base
• 61970-453: CIM based graphics exchange
• 61970-501: Common Information Model Resource Description 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 distribution
A good example is the current development of the IEC
61968-9 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 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 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
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.
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
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
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. G ENERAL A PPROACHES
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
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. C ONCLUSION
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 61850 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
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 61850 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 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.
R EFERENCES
Sebastian Rohjans has joined the OFFIS - Institute for Information Systems
in late 2008. 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.
[1] “NIST Special Publication 1108 NIST Framework and Roadmap for
Smart Grid Interoperability Standards”, 2010.
[2] SMB Smart Grid Strategic Group (SG3), “IEC Smart Grid Standardization Roadmap”, June 2010.
[3] OFFIS, SCC Consulting, and MPC management coaching, “Untersuchung des Normungsumfeldes zum BMWi-Foerderschwerpunkt ”EEnergy - 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/Kompetenzzentrum
E-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 Vision
Document”, 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 der
Energiewirtschaft”, Ph.D. dissertation, 2009.
[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.
187–209.
[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. 1–8.
[14] EPRI, “Guidlines for Control Center Application Program Interface”,
EPRI, Tech. Rep., 1996.
[15] Bundesnetzagentur, “Anlage zum Beschluss BK6-06-009. Darstellung
der Geschaeftsprozesse zur Anbahnung und Abwicklung der Netznutzung 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) MODEL
EXCHANGE 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., February
2004.
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 (www.ccise.de).
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´e Manuel Gonz´alez V´azquez 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.