A Data Model for Energy Decision Support Systems for Smart Cities
The Case of BESOS Common Information Model
G. Anadiotis, E. Hatzoplaki, K. Tsatsakis and T. Tsitsanis
Hypertech Energy labs, Perikleous 32, Chalandri, 15232, Athens, Greece
Keywords: Energy Management System, Common Information Model, IEC 61970, Design, Methodology, Data.
Abstract: Integrating Energy Management Systems is a necessary task in order to be able to offer a range of services
for citizens and public authorities. This task requires integration at the data level in order to expose data
coming from different systems in a unified way. In this paper we describe the creation of a Common
Information Model to unify disparate Energy Management Systems in the context of the BESOS project.
We identify related work, describe design decisions and methodology and give an outline of the data model
itself, based on profiling and extending the IEC 61970 standard.
1 TOWARDS A CIM MODEL FOR
EMS MANAGEMENT
1.1 Integrating Energy Management
Systems
Energy Management Systems (EMS) deployed
today in typical districts that are consuming or
producing energy suffer from a major drawback: no
matter how well-thought or sophisticated they may
be, they lack integration. This drawback hampers
their usability for all potential classes of users, as the
development of end-user applications and decision
support solutions cannot be based on a holistic view
of underlying data.
BESOS (Building Energy Decision Support
Systems for Smart Cities) is an E.U. Research and
Development project (BESOS, 2014) that proposes
the development of an advanced integrated
management system which enables energy
efficiency in smart cities from a holistic perspective.
The goal for BESOS is to enable the integration of
disparate EMSs to share data and services among
themselves and with external third party applications
through an open trustworthy platform.
The BESOS CIM consists of the necessary data
models addressing different Smart Grid components
and respective information elements of varying
granularity that ensures the semantic and syntactic
interoperability between the various components
comprising the BESOS energy management
framework. In this paper, we give an account of the
work performed in order to deliver the BESOS CIM
as a critical aspect towards the interoperability of
diverse energy management sources.
The paper is structured as follows. In Section 1,
we introduce the domain and establish the need for a
common information model. In Section 2, we give
an overview of related work and examine its impact
on the design decisions made. In Section 3, we
outline the data modeling methodology used for the
development of BESOS Common Information
Model. Furthermore in Section 4, we present the
BESOS CIM itself while we finally conclude and
present a future outlook of the work in Section 5.
1.2 The Need for a Common
Information Model
The main goal of the BESOS project is to create a
centralized infrastructure to deliver services and
applications for Smart Cities. More specifically, the
project involves a number of Gateways collecting
and delivering Smart Grid data from EMSs, a
Middleware layer aggregating and exposing that
data via APIs and a services layer delivering end
user applications on top of the data (Figure 1). The
task of the Middleware layer is two-fold: on the one
hand, to integrate data coming from different
Gateway sources, and on the other to offer Services
to the application layer. The Middleware Layer
implementation uses a data meta-model for this,
based on simple classes: Entity, Metric, Attribute,
51
Anadiotis G., Hatzoplaki E., Tsatsakis K. and Tsitsanis T..
A Data Model for Energy Decision Support Systems for Smart Cities - The Case of BESOS Common Information Model.
DOI: 10.5220/0005422800510059
In Proceedings of the 4th International Conference on Smart Cities and Green ICT Systems (SMARTGREENS-2015), pages 51-59
ISBN: 978-989-758-105-2
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
Message and Strategy which are further adapted on
the different applications examined.
In mass scale applications though, we need to
weight the benefits and drawbacks for this option:
simplicity for Gateway systems integration vs.
transferability over applications development. In the
end, simplicity for application development
prevailed, as after it would be hard for a healthy
application ecosystem to be developed on top of this
Middleware if it only supported a meta model.
So the meta model is still used internally to
integrate Gateways, but on the upper layer the APIs
exposed to application developers use a fully blown
data model as defined in the BESOS CIM. Thus, the
existing meta model is mapped to the BESOS CIM
to provide a semantics-based model.
2 STATE OF THE ART ANALYSIS
AND IMPACT ON BESOS CIM
2.1 Introduction
In order to proceed with the design of the BESOS
CIM the approaches taken by other projects in the
domain as well as related standards were examined
and further summarized.
2.1.1 Relevant Data Modeling Work
As the main focus on the E.U. is the provision of an
interoperable operation of EMSs, different
approaches have been adopted. A set of indicative
projects from EE semantics Group (eeSemantics,
2013) was reviewed in terms of data modeling.
A first approach to the definition of a common
model among different components was defined as
part of FIEMSER project. FIEMSER introduces a
Data Model formalized in UML diagrams,
describing the object/relational mappings between
the data components, persisted using ORM
frameworks (Laresgoiti, 2011). The FIEMSER
approach informed BESOS methodologically and
the respective data model was considered as it has
been expressed in UML. In addition, concepts
related to User & Groups Permissions were adopted
from FIEMSER.
A framework conceptually similar to BESOS is
the one from SmartKye Project. It specifically
targets public authorities responsible for public
services demanding energy. The SmartKye data
model is defined as XSD models following a meta-
modeling approach and its main concepts are
Attribute, Entity, Message, Metric and Strategy
(García, 2013). In addition, concepts related to the
market operation were also defined in BESOS CIM.
A key project towards the incorporation of
heterogeneous energy assets in district level is
COOPERATE. For this purpose an open, scalable
neighbourhood service and management platform
was developed and a substantial part of it is the
Neighbourhood Information Model (NIM), as it
serves as a common information source for the
developed services (Look, 2013). The design of the
Figure 1: The BESOS project platform overview.
SMARTGREENS2015-4thInternationalConferenceonSmartCitiesandGreenICTSystems
52
NIM followed some basic principles that informed
the BESOS approach as well: reuse and extension of
existing Information Models from related projects
and design of a flexible and extensible NIM.
In addition to the common ground
methodological approach addressed in previous
references, the KnoholEM project focuses on
knowledge-based energy management for public
buildings and adopts an ontological modeling
approach (Häfner, 2013) which divides its data
model in 2 parts, namely the generic ontology (GO)
and the building-specific ontology (BSO).
KnoholEM was taken into account towards the
modeling of building from the links established
mainly with IFC (ISO 16739, 2013), but also with
gbXML. BuildingControl related concepts were
adopted from IEC 61970 and further included in
BESOS CIM.
2.1.2 Alignment with Standardization
A key objective for BESOS is the transferability of
the whole solution. Therefore, it is critical to define
common and reusable interfaces by adopting
common standards in the Smart Grids domain.
During the State of the Art analysis a list of
standards was reviewed (VDI, CityGML, IFC) while
IEC 61970 and IEC 61850 are presented as the most
important and close to BESOS approach.
The IEC 61970 series of standards (Alan, 2007)
deals with the application program interfaces for
energy management systems (EMS) and defines a
common vocabulary and basic ontology for aspects
of power industry. Since there is UML formalization
on IEC CIM it can set the basis for BESOS
concepts. Though IEC CIM is a well documented
and massively applied standard, is not adopted as-is
in its entirety. Firstly, it is a very extensive model
with many of its concepts not being relevant for
Smart-cities applications. On the other hand, there
are certain concepts (SLAs, Business roles,
Contracts), to be modelled in BESOS, that are
missing from IEC CIM, therefore the model needs to
be extended.
On the other hand, IEC 61850 (Mackiewicz,
2006) standard for the design of electrical substation
automation has raised special interest thought the
modeling of primary process objects as different
standard logical nodes which can be further grouped
under different logical devices. The IEC 61850-7-
420 (IEC 61850-7-420 ed1.0, 2011) has recently
been formalized by means of UML, covering some
types of DERs. Even though there are not
standardized (XMI) artifacts that can be reused for
modeling purposes, the details on assets modeling
offer a surplus towards the integration on the
proposed framework. On the other hand, it is well-
known that IEC 61850 and IEC 61970 have
inconsistencies (Ling, 2013), making the use of both
problematic. There have been efforts for the
harmonization of the two standards (EPRI, 2006)
(Kim, 2013) however differences in Configuration
and Run Time models mean that the result is not
fully harmonized or easy to use. Thus, we have
adopted IEC CIM as the anchor point for the BESOS
CIM while specific attributes coming from IEC
61850 are further adapted on BESOS framework.
2.2 BESOS Design Methodology
Following the need for a fine-grained information
model and taking into account the relevant work of a
multitude of related research projects and existing
standardization on the field of Smart Grids, a
common ground methodology has been devised for
the definition of BESOS CIM. The main points of
the approach are further provided.
2.2.1 Modular Design
For a domain that is extensive, as is the case for
BESOS and Smart Grid domain, a modular approach
(Schutte, 2011) “...helps organizing data model
concepts in more manageable chunks...” that are
easier both for modellers to process as well as for
users to comprehend.
While at times it may be convenient to have a
single point / file of reference for the entire data
model, for a model that is as extensive as the
BESOS CIM this becomes impractical. Thus the
modularization approach has also been adopted by
the data modeling work in BESOS to the definition
of the main concepts of interest.
2.2.2 Common Ground Modeling Approach
While the adoption of advanced domain modeling
techniques and formalisms such as ontologies seems
feasible for BESOS case, this approach is not
preferable for our case due to the requirement for the
transferability of BESOS solution. IEC CIM - a
UML based modeling approach- set the basis for the
proposed model while some performance concerns
lead us to adopt a combination of XML and UML
for the data modeling methodology.
2.2.3 Meta-modeling Approach
One of the main requirements on the modeling
ADataModelforEnergyDecisionSupportSystemsforSmartCities-TheCaseofBESOSCommonInformationModel
53
methodology is to proceed with models that are
easily adapted to existing software applications
towards the direct transferability of the framework.
This has in fact been one of the key decisions
shaping the data modeling work, as the contrast
between a compact meta-model (Apolinarski, 2014)
and an explicit data model was taken into account.
Towards this direction, BESOS CIM covers parts
of the domain that are deemed stable and universal
(e.g. instances of Power Generating Units) while the
ones that are more dynamic in nature (e.g. instances
of metrics) are dealt with by means of meta-
modeling. Considering the plus and cons for each
approach, the decision was reached to go for an
explicit data model , while adopting the meta-model
approach for parts of the model that are of a truly
dynamic nature.
2.2.4 Integration of Standards
As BESOS framework is proposed for the
management of assets on smart city level, it became
evident that BESOS would not proceed to model
Building structure in detail. Therefore, a great deal
of standards under consideration (VDI 3813
(Technical rule, 2013), CityGML (CityGML 2.0)
and IFC) became less relevant under this light, as
they focus on Building structure. In addition,
specific business aspects related to Demand
Response (e.g. OpenADR 2.0b) were not deemed to
be critical due to the need to proceed with generic
interfaces on application level.
Thus, the choice came down to the - supported
by IEC committee (IEC 62357, 2011) - IEC 61850 &
61970, as the standards that are more closely related
to the domain that is the focus of BESOS. However,
due to the fact that there is well-known semantic
incompatibility between them, and in order to avoid
getting entangled in the disproportionate effort
required to address this issue, the choice was made
to base our approach on IEC 61970 (IEC CIM)
while to further enhance our model with attributes
from IEC 61850-7. A number of important factors
(Adoption and community support, Tooling support,
Domain relevance) were also considered.
Therefore, the decision was reached to base the
BESOS CIM on the existing standards following the
tension for alignment of new applications with the
existing ones. Prior to the detailed presentation of
CIM, a beyond the State of the Art Section
summarizes the innovation of BESOS framework.
2.3 BESOS CIM beyond the State of
the Art
BESOS promotes the efficient integration of flexible
demand with distributed generation through a fully
fledged CIM that ensures the interoperability
(syntactic and semantic) between the applications
and the distributed EMS. This is the main innovation
of the proposed framework, standing on top of the
existing models towards the provision of a unified
approach for the management of diverse EMS. In
order to highlight the innovation impact of BESOS
CIM, we consider the Smart grids map
representation as proposed by IEC (IEC Smartgrids
map, 2014) and CEN / CENELEC (M490, 2013).
The following tables visualize how the different
models and standards adapt to the main domains
proposed by IEC covering different attributes from
EMS management to the prompt market &
enterprise operation on Smart-cities era.
Table 1: Domain based Comparative Overview.
Data Model
Domains
DER/
Customers
Generation Distribution Transmission
FIEMSER
x x
SmartKye
x x x
COOPERATE
x x
KnoholEM
x x
VDI 3813
x
IEC CIM
x x x
IEC 61850
x x
CityGML
x
BESOS
x x x
Table 2: Zone based Comparative Overview.
Data Model
Zones
Market Enterprise Operation Field/ Station
FIEMSER
x x x
SmartKye
x x
COOPERATE
x x x
KnoholEM
x x
VDI 3813
x
IEC CIM
x x x
IEC 61850
x x
CityGML
x
BESOS
x x x x
3 CIM MODELING APPROACH
Developing a data model for an integration project is
a complex task, not only because of the complexity
of the domain, but also due to the different views on
SMARTGREENS2015-4thInternationalConferenceonSmartCitiesandGreenICTSystems
54
data and business processes. The methodology used
to develop the BESOS Data Model was devised
taking into account best practices in the domain,
both in terms of techniques as well as in terms of
overall approach. The respective steps towards the
delivery of BESOS CIM are further analyzed setting
the overall modeling framework.
Consultation with Stakeholders: Following the
initial selection of assets, partners responsible for
managing EMSs were asked to define EMS
functionality (interfaces) and managed objects.
Modeling based on ΙΕC CIM: At this phase of the
methodology CIMTool (CIMTool, 2012) was
leveraged in order to browse the IEC CIM standard
and try to identify concepts that could be adopted by
the BESOS CIM.
Data Model Modularization and Sanitization: As
CIMTool produces a monolithic form (single XSD
file), we introduced a phase in the process in which
the contents of the resulting XSD file were divided
into a number of separate XSD files referencing
each other.
Additional Modeling Concepts: At the end of the
modularization and sanitization phase, a few
concepts needed to express the BESOS CIM that
were not part of the IEC CIM, had to be added
manually in the XSDs (work that distinguishes the
BESOS CIM from IEC CIM). The goal of this
process is to address the whole list of concepts
defined by users but still be in line with
standardization.
Information Model Visualization: We adopted an
approach in which we formalized the data model
using XSD and visualized it using UML.
4 BESOS COMMON
INFORMATION MODEL
BESOS CIM was developed using the methodology
introduced in the previous section. The data model
was broken down in 7 logical modules (Location,
Users, Assets/ Structure, Metrics, Documents,
Control) in order to facilitate cohesion and
reusability. In the following, we give an overview
for each module while also additional attributes that
define the role of each module within BESOS
framework are provided.
4.1 Location Module
This module includes concepts used to capture
information related to location, as well as general
concepts that are used throughout the data model
and have been included here for convenience.
Identified_Object: This is the concept adopted
from IEC CIM and is the high level generic object
inherited in all IEC CIM classes.
Status: introduced in the IEC CIM to be used as a
generic container to hold status-related information.
Additional attributes related to geographical
parameters (coordinates etc) are considered on
BESOS modeling framework.
Figure 2: Asset Structure. Blue-shaded classes are external to the module.
ADataModelforEnergyDecisionSupportSystemsforSmartCities-TheCaseofBESOSCommonInformationModel
55
4.2 Organization & Users Module
This module introduces concepts capturing
information about organisations as well as users.
The former have been adopted by the IEC CIM and
are further enhanced with additional properties to
accommodate BESOS needs. Within BESOS, assets
owners, Aggregators, ESCOs and residential users
are defined as the main stakeholders of the platform
and therefore incorporated in the respective data
model. The definition and further modeling of
Business Actors is one of the main innovations of
BESOS project towards the expansion of IEC CIM
modeling framework.
4.3 Asset Structure Module
This module (Figure 2) includes concepts capturing
information about Assets that are examined in
BESOS project while also covering generic assets in
a smart city level. Therefore this module is core for
BESOS CIM, defining the parameters to be
considered towards the specification of each asset
examined. Due to the core role of this module, a
detailed view of the main classes is further provided.
The Asset class has been adopted from IEC CIM
and is used to represent the logical manifestation of
a piece of equipment, as opposed to the physical one
for which the Power System Resource is used.
ActivityRecord class records activity for an entity at
a point in time; activity may be for an event that has
already occurred or for a planned activity. In
addition to activity record, a TimeSchedule is used
to describe anything that changes through time and
has been adopted from IEC CIM.
The PowerSystemResource class is used to
represent the physical manifestation of a piece of
equipment, as opposed to the logical one for which
the Asset is used. Power system resources can
generate Measurements and they have a list of
AllowedStatuses and a CurrentStatus associated
with them. Each asset defined is characterised by a
specific type and therefore a catalogue of generic
types of assets that may be used for design purposes
is also applied. Within BESOS project, a list of
different assets has been selected and therefore a
detailed analysis of each type is further presented as
part of the data model of the project.
4.4 Assets Representation Module
This module includes concepts capturing
information about specific types of Assets.
The
equipment class, adopted from IEC CIM and
extending Power System Resource, represents the
parts of a power system that are physical devices. It
has properties to record its NominalPower and
whether it is normally-In-Service and defines the
high level abstraction of each type of asset examined
in BESOS. Then, in order to provide an asset
specific data model, an overview of the main assets
represented in the scope of the project is given.
The GeneratingUnit class, adopted from IEC
CIM and extending Equipment, represents a single
machine or set of synchronous machines for
converting mechanical power into alternating-
current power. A point of light is defined as the
asset which is responsible for the management of
traffic and public lights. This asset is very important
in city level management and therefore is further
incorporated in the model. As the numbers of
electric vehicles has increased recently, these set a
typical asset to be examined in smart city level. In
addition to the electric vehicle as a single entity, a
charging station is defined as an aggregated type of
EV assets.
In addition to the general types of generation and
consumption, we need to address also building
assets that set the main type examined in a city level.
Α public building is characterized as an asset that
incorporates both consumption and generation
characteristics while a residential building type is
modelled as a piece of Equipment able to generate
Measurements and addresses the citizens also as end
users of BESOS platform.
4.5 Measurements & KPIs Module
This module incorporates concepts capturing
information that help keep track of dynamically
evolving attributes (metrics) as well as KPIs defined
utilizing these metrics. Both Measurements and
KPIs follow the same pattern: there is a definition, a
list of values and a source for each value.
More specifically, a measurement type
represents any measured, calculated or non-
measured non-calculated quantity. Measurement is
used as a metric definition while its evolving values
through time are captured using its Measurement
Value property. The Measurement Value class
represents the current state for a measurement. A
state value is an instance of a measurement from a
specific source.
Additionally to measurements a reference to Key
Performance Indicator class is defined, associated
with an EMS. KPIs follow the same pattern as
Measurements - i.e. they have definitions, values,
and sources, in order to help keep track of historical
SMARTGREENS2015-4thInternationalConferenceonSmartCitiesandGreenICTSystems
56
values and multiple sources. In addition KPIs are
linked to the Measurements used for their definition
via the Measurements property as well as to their
values via the KPI Values property.
The KPIValue class represents the current state
for a KPI. KPIs can be associated with many state
values, each representing a different instance for the
KPI. In order to proceed with the holistic
management framework, there is the need to
examine different types of metrics and indicators
either as snapshots or as time series. Thus, a
TimeSeries is used to define intervals over which
aggregated metrics are calculated.
Further to the time series definition, the Step
class defines a step for use while also the Datetime
defines the time granularity of the analysis.
Therefore the calculation of aggregated metrics and
indicators is dynamic towards the provision of a
meta-modeling framework that fully addresses the
end users diverse requirements.
4.6 Document Types Module
This module (Figure 3) includes concepts capturing
information related to the business – strategic
aspects of BESOS towards the identification of
different business services and models to be
provided by the business actors.
Adopted from IEC CIM, Document is a parent
class for different groupings of information collected
and managed as a part of a business process.
Therefore, this class defines the abstract layer for the
whole business layer. The SLA concept represents
the Agreements between 2 organizations as
examined in BESOS project, specifying related
terms (monitored via KPIs) and assets. It has
properties pointing to Assets for which the SLA has
been created, KPIs involved in SLA, the
organization and the priority. On the other hand, the
StrategyAction represents one request from a
municipality to end user – e.g. “Operate in eco-
mode”. It is modelled as a subclass of Agreement to
designate its semantics and inherit properties. It has
properties pointing to Strategy Constraints and
Strategy Goals applicable to this strategy action
(both of type Strategy Element) as well as a Priority.
The Strategy Element concept is used to model
specific strategic sub-objectives as part of the
strategy actions. It has properties pointing to target
value, Assets involved, a KPI or a Measurement the
desired value of which is within the goals of this
strategy and a Strategy Relation Type signifying the
relation with the specified KPI (greater, equal, etc).
As the Strategies and SLAs are defined for a
specific time period, an interval between two time
points, adopted from IEC Model, is defined pointing
to start/ end date of each business service.
4.7 Control Module
This module includes concepts capturing
information related to control commands as
delivered from the Application level to the EMS
level in order implement the control strategies
defined. As the type of message during a control
command is not of a unique type, a hybrid approach
Figure 3: Document Types. Blue-shaded classes are external to the module.
ADataModelforEnergyDecisionSupportSystemsforSmartCities-TheCaseofBESOSCommonInformationModel
57
has been followed within data model, addressing
both generic message types (to be further interpreted
in EMS level) while also asset specific control
commands towards the definition of the set point of
operation. The control types are aligned with assets
and strategies in order to provide a detailed view on
the definition of control commands.
The source (XSD) files for all modules can be
accessed through a dedicated link (BESOS XSDs,
2015) (a temporary location until they are
transferred to the BESOS project web site).
5 CONCLUSION AND OUTLOOK
We have introduced the rationale behind building a
data model used to integrate disparate EMSs and
examined the process through which it has been
constructed and the design choices that have driven
it. We have answered the most crucial dilemma in
terms of modeling (the use of an explicit data model
versus a minimal meta-model) by adopting a middle
ground based on lessons learned from other projects
and also addressing the main requirement needs.
When compared to other data models we took into
account in the state of the art, we can identify certain
points of differentiation for the BESOS CIM.
To begin with, BESOS CIM focuses on the
domain of energy management at the city level, as
opposed to IEC 61970 that covers a broad array of
domains. Furthermore, compared to IEC 61970 and
IEC 61850 BESOS CIM covers both the network
level and the EMS level connecting these distinct
layers of the smart grid. BESOS CIM also extends
the standards by adding new assets such as Electric
Vehicles and Point of Light, as well as covering
aspects of security and priority on assets (covered in
standardization by IEC 62351). Last but not least, as
opposed to IEC 61968 and other standardization
efforts, BESOS CIM introduces the role of ESCOs
and Aggregators as stakeholders in an open energy
domain. By making the modeling process and the
model itself publicly available we hope that they can
be of use to anyone facing a similar task. The goal of
BESOS platform is to provide a holistic solution for
energy and mobility management that will be easily
transferable and towards this direction, the BESOS
CIM is provided in a way that could be easily
adopted and further mapped in any part of
integration process.
ACKNOWLEDGEMENTS
This work has been carried out in the context of the
BESOS EU project (Grant Agreement 608723).
REFERENCES
BESOS - Building Energy Decision Support Systems for
Smart Cities -E.U. Project, http://besos-project.eu/
eeSemantics Wiki Home Page, https://
webgate.ec.europa.eu.
Laresgoiti, I., Perez, J., Tellado, B., Riano, S., Liu, X.,
Dragone, M., Haag, G., Marcel, J., Bourdeau, M.,
2011. FIEMSER Data Model, available from http://
www.fiemser.eu/?page_id=40#D5.
García, J., Karnouskos, S., Ilic, D., Cheng, W., Peris, R.,
Alacreu, 4. L., Sauter, R., Dimeas, A., Hatzoplaki, E.,
Saldaña, S., Pons, L., García-Casarrubios, D., 2013.
Reference Architecture and Energy Services.
Available from http://smartkye.eu/download/1025/
Look, M., Greifenberg, T., 2013. Report detailing
Neighbourhood Information Model Semantics
available from http://www.cooperate-fp7.eu/
Häfner, P., McGlinn, K., Gerdelan, A., Wicaksono, H.,
2013. Method development: building behavioural
model creation, building specific ontology creation.
http://www.knoholem.eu/filelibrary/KnoHoIEM_D2_
2.pdf.
ISO 16739:2013 Standard, Industry Foundation Classes,
http://www.ifcwiki.org/index.php/Main_Page.
Alan W. McMorran, 2007. An Introduction to IEC 61970-
301 & 61968-11: The Common Information Model.
Institute for Energy and Environment, University of
Strathclyde.
Mackiewicz, R. E., 2006. Overview of IEC 61850 and
benefits. Power Engineering Society General Meeting.
IEC 61850-7-420 ed1.0 Communication networks and
systems for power utility automation - Part 7-420:
Basic communication structure - Distributed energy
resources logical nodes.
Ling, L., Hongyong, Y., Xia, C., 2013. Model Differences
between IEC 61970/61968 and IEC 61850. In
Proceedings of the 2013 Third International
Conference on Intelligent System Design and
Engineering Applications (ISDEA '13). IEEE
Computer Society, Washington, DC, USA, 938-941.
EPRI Technical Report: Integration of Advanced
Automation and Enterprise Information.
Infrastructures: Harmonization of IEC 61850 and IEC
61970/61968 Models, EPRI, Palo Alto, CA, 2006.
Product ID 1013802.
Kim, Yang, Jang, Hong, Falk, Lee, 2013. A Meta
modeling Approach to Unifying IEC 61850 and IEC
61970, SISCO.
Schutte, S., Scherfke, S., Troschel, M., 2011. A
Framework for Modular Simulation of Active
Components in Smart Grids, OFFIS.
SMARTGREENS2015-4thInternationalConferenceonSmartCitiesandGreenICTSystems
58
Apolinarski,W., Iqbal, U., Parreira, J.X., 2014. The
GAMBAS middleware and SDK for smart city
applications. PerCom Workshops 2014: 117-122.
VDI 3813, Building automation and control systems
(BACS), Technical rule, 2013.
CityGML 2.0 open data model, Schema available on
http://www.citygml.org/index.php?id=1540.
OpenADR alliance, OpenADR 2.0a and the OpenADR
2.0b Profile Specification and schemas http://
openadr.org/
IEC 62357 Standard, 2011, to be developed by WG15 of
IEC TC57working group.
Smartgrids Standardization map, available (2014) on
http://smartgridstandardsmap.com/
M490 - Smart Grid Mandate Standardization Mandate,
CEN/CENELEC, 2013, access on
http://www.smartgrids.eu/CEN-CENELEC-ETSI.
CIMTool, an open source tool for IEC Common
Information Model (CIM), access on
http://wiki.cimtool.org/index.html.
BESOS Common Information Model, XSD Schemas,
https://www.dropbox.com/sh/w5vigzxhn4mw2pn/AA
Dac6yJ8ut5FojoOOKJK1J_a?dl=0.
ADataModelforEnergyDecisionSupportSystemsforSmartCities-TheCaseofBESOSCommonInformationModel
59
