Maryam Zirak Master's Thesis May2015

Department of Civil, Geo and Environmental Engineering
Chair of Geoinformatics
A Model-driven Approach for Linking Building Thermal Energy

Assessment Standards and the CityGML Energy Application
Domain Extension (ADE) using UML
Master’s Thesis
Author: Maryam Zirak

Supervisors: Univ.-Prof. Dr. rer. nat. Thomas H. Kolbe
Prof. Volker Coors
Affiliation: Zafh.net
April 2015
Declaration of Authorship
English:
I hereby declare that the thesis submitted is my own unaided work. All direct or indirect sources used
are acknowledged as references. I am aware that the thesis in digital form can be examined for the use
of unauthorized aid and in order to determine whether the thesis as a whole or parts incorporated in it
may be deemed as plagiarism. For the comparison of my work with existing sources I agree that it shall
be entered in a database where it shall also remain after examination, to enable comparison with
future theses submitted. Further rights of reproduction and usage, however, are not granted here. This
paper was not previously presented to another examination board and has not been published.
German:
Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbständig angefertigt habe. Die aus
fremden Quellen direkt und indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Ich
weiß, dass die Arbeit in digitalisierter Form daraufhin überprüft werden kann, ob unerlaubte Hilfsmittel
verwendet wurden und ob es sich – insgesamt oder in Teilen – um ein Plagiat handelt. Zum Vergleich
meiner Arbeit mit existierenden Quellen darf sie in eine Datenbank eingestellt werden und nach der
Überprüfung zum Vergleich mit künftig eingehenden Arbeiten dort verbleiben. Weitere
Vervielfältigungs- und Verwertungsrechte werden dadurch nicht eingeräumt. Die Arbeit wurde weder
einer anderen Prüfungsbehörde vorgelegt noch veröffentlicht.
Maryam Zirak Place, Date

Acknowledgments
I thank the Chair of Geoinformatics at Technical University of Munich and Stuttgart University of
Applied Science for giving me the opportunity to research on this topic. I would like to express my
deepest gratitude to my advisor, Prof. Kolbe, for his excellent guidance, caring, and patience. I would
like to thank Romain Nouvel, who helped me to develop my background in building energy modeling,
and supported me with his advices. I would also like to thank Moritz Lauster and Marcel Bruse for their
advices, and guides. I also want to thank to Zaft.net for providing me an opportunity to take part at
the helpful workshops. Finally, a special thanks to my family, especially our new member, my Amir,
who always supported me, encouraged me and cheered me up.
Abstract
3D city models are recommended as a source of data provision for urban energy modeling. Using a
standardized data model for representing 3D city models prevent a disparity in data representation.
Although CityGML is a leader amongst data model standards, it does not model all the required data
for energy assessment. Therefore, CityGML Energy ADE, which is an extension of CityGML using
Application Domain Extension mechanism, is developed. However, compatibility of this extension to
building energy models has as far not been validated. The purpose of this thesis is a compatibility
investigation of CityGML Energy ADE with three standards for heating and cooling space energy
demand assessment, i.e., DIN 18599-2, ISO 13790, and VDI 6007. This purpose is met through an
extensive study of data representation in CityGML, the feature of ADE, and also the data requirement
and building decomposition method of the three standards. The Unified Modeling Language (UML) is
used for the development of data model standards. Finally, the data models are compared to CityGML
Energy ADE from two aspects, structure consistency and data coverage. Object Constraint Language
(OCL), as a formal language, is also applied for expressing computational algorithms of deriving
attributes defined in the data models and linking them to the corresponding attributes in CityGML
Energy ADE.
The thesis shows that the current version of CityGML Energy ADE does not completely meet the
requirements of the three standards, neither the building structure nor the building data
requirements. Changes in the structure and also easily addable data are recommended. It is shown
that adding these data improve the data coverage to more than 75%. In the end, further studies on
practically availability of data introduced in data models are recommended.
i
Table of Contents
Abstract ............................................................................................................................................. i
Table of Figures ................................................................................................................................. v
Acronyms .........................................................................................................................................vii
Chapter 1: Introduction ..................................................................................................................... 9
Chapter 2: Research Methods.......................................................................................................... 13
2.1. Limitations ................................................................................................................................... 13
Chapter 3: Literature Review ........................................................................................................... 15
3.1. Clarification of CityGML and Energy ADE .................................................................................... 15
3.2. Critical evaluation of three building thermal energy models...................................................... 19
3.2.1. DIN 18599-2, Energy efficiency of buildings — Calculation of the energy needs, delivered
energy and primary energy for heating, cooling, ventilation, domestic hot water and lighting —
Part 2: Energy needs for heating and cooling of building zones ...................................................... 19
3.2.2. ISO 13790, Energy performance of buildings — Calculation of energy use for space heating
and cooling ....................................................................................................................................... 21
3.2.3. ISO 13790- monthly method vs. DIN 18599-2........................................................................ 22
3.2.4. VDI 6007, Calculation of transient thermal response of rooms and buildings ...................... 24
3.3. Summary...................................................................................................................................... 26
Chapter 4: Data Model Development .............................................................................................. 29
4.1. DIN 18599-2 Data Model ............................................................................................................. 29
4.1.1. OCL’s Application in DIN 18599-2’s Data Model .................................................................... 35
4.2. ISO 13790 Data Model................................................................................................................. 35
4.3. VDI 6007 Data Model .................................................................................................................. 43
4.3.1. OCL’s Application in VDI 6007’s Data Model.......................................................................... 47
4.4. Summary...................................................................................................................................... 48
Chapter 5: Compatibility Analysis .................................................................................................... 49
5.1. CityGML Energy ADE Compatibility with DIN 18599-2 ................................................................ 49
5.1.1. Structure Analysis ................................................................................................................... 49
5.1.2. Attribute Analysis ................................................................................................................... 55
5.2. CityGML Energy ADE Compatibility with ISO 13790.................................................................... 58
5.3. CityGML Energy ADE Compatibility with VDI 6007 ..................................................................... 61
5.4. General Results............................................................................................................................ 67
iii
5.5. Summary ...................................................................................................................................... 68
Chapter 6: Conclusion and Outlook ..................................................................................................71
6.1. Sustainable management-oriented recommendations .............................................................. 73
References .......................................................................................................................................75
A. UML Class Diagram......................................................................................................................77
B. OCL .............................................................................................................................................81
C. Equivalent Names in Different Energy Standards ......................................................................... 83
D. Required Input Data for DIN 18599-2 ..........................................................................................85
E. Required Input Data for VDI 6007 ................................................................................................91
F. Attached CD ................................................................................................................................95
iv
Table of Figures
Figure 3-1: Building module in CityGML. Source: Open Geospatial Consortium ...................................................... 17
Figure 3-2: Determining parameters in heating or cooling energy demand based on DIN 18599-2 standard ........ 20
Figure 3-3: Determining parameters in heating or cooling energy demand based on ISO 13790 standard ............ 21
Figure 3-4: Room thermal response’s model in VDI 6007. Source: VDI 6007........................................................... 25
Figure 4-1: Energy Indicator model of DIN 18599-2 ................................................................................................. 30
Figure 4-2: Object-related model of DIN 18599-2 .................................................................................................... 33
Figure 4-3: Reference Object model of DIN 18599-2 ................................................................................................ 34
Figure 4-4: Energy Indicator of ISO 13790 ................................................................................................................ 36
Figure 4-5: Object-related model of ISO 13790 ....................................................................................................... 39
Figure 4-6: Reference Object model of ISO 13790 ................................................................................................... 41
Figure 4-7: Energy Indicator model of VDI 6007. ...................................................................................................... 43
Figure 4-8: Object-related model of VDI 6007 .......................................................................................................... 45
Figure 4-9: Reference Object model of VDI 6007 ..................................................................................................... 47
Figure 5-1: Structural coherence between DIN 18599-2 and CityGML Energy ADE ................................................. 53
Figure 5-2: Horizon angle, Overhang angle, Fin angle. Source: DIN 18599-2 ........................................................... 56
Figure 5-3: Structure coherent investigation between CityGML Energy ADE and VDI 6007's data model .............. 63
Figure 5-4: Missing attributes in three standards ..................................................................................................... 68
v
Acronyms
ADE Application Domain Extension

CityGML City Geographic Modeling Language
DIN Deutsches Institut für Normung
ISO International Organization for Standardization
LoD Level of Detail
OCL Object Constraint Language
OGC Open Geospatial Consortium
OMG Object Management Group
UML Unified Modeling Language
URI Uniform Resource Identifier
VDI Verein Deutscher Ingenieure
vii
Chapter 1: Introduction
Cities and in particular buildings are the leader of the primary energy consumers in the word.
According to Keirstead et al. (2012), modeling the energy flow of urban areas is a way of understanding
and improving energy system’s performance. In fact, urban energy model helps the energy policy
makers in foreseeing the probable consequences of ongoing-decisions in the future policies
(Mohammadi et al., 2013).
Urban energy modeling has many different methods. Swan and Ugursal (2009), Foucquier et al. (2013),
Zhao and Magoulès (2012), and Mohammadi et al. (2013) have reviewed the many urban energy
models and categorized them by discussing their pros and cons. There are different categorizations;
some categorize them into two main methods; top-down and bottom-up methods which include
engineering or physical and statistical methods using neural networks or support vector machines.
Foucquier et al. (2013) categorize them into white box equivalent to physical-based approaches, black
box including learning machinery tool-based approaches using statistics, and gray box which is a
combination of both. According to Zhao and Magoulès (2012), choosing between different models is a
trade-off between input data complexity and accuracy. Also Kavgic et al. (2010) states that different
building energy models vary in required input data, socio-technical assumptions, and scenario types.
Provision of all the required input data has challenges, from the geometric and physical characteristics
of buildings to occupancy-operation and meteorological profiles, in particular on the city scale. Strzalka
et al. (2010) proposed that a 3D city model, which is generated by airborne laser scanner, could
provide required building input data for energy simulation. Mohammadi et al. (2013) consider urban
energy modeling based on 3D city model as one of the three urban energy modeling methods, called
“spatial evaluation of energy demand”, and introduce it as a robust and quick method compared to the
other two methods. For many years virtual 3D city models have been employed mainly for visualization
and graphical exploration of cities. Nowadays, semantic 3D city models enhance their capabilities in
different urban applications with their ontological and thematic-based structure (Kolbe, 2009).
However, data disparity is still an issue in many projects using different sources and 3D city models. A
standardized data model representing city data, is inevitable for the use and exchange of data from
9
1
different sources (Gröger and Plümer, 2012). CityGML is an Open Geospatial Consortium (OGC)
standard for representing and exchange of semantics in 3D city models. Kaden and Kolbe (Kaden and
Kolbe, 2013) debate CityGML data model sufficiency in urban energy planning due to its capabilities in
thematic representation of any object with spatial reference in arbitrary Level of Detail (LoD). Gröger
and Plümer (2012), also discuss about the importance of CityGML, as 3D city data set for different
applications like energy modeling.
Nevertheless, taking Berlin Energy Atlas project as an example which applies CityGML for an urban
energy model (Kaden and Kolbe, 2013), CityGML does not cover all the energy-related entities. The
upside is that CityGML can be extended by a so-called Application Domain Extensions (ADE)
mechanism (Open Geospatial Consortium), to meet specific application requirements. Currently, an
extension to CityGML for energy applications called City GML Energy ADE is under development by a
committee of experts (SIG3D, 2014). However, in the expert group of Energy ADE development, no
study has yet been done to verify the Energy ADE compatibility with urban energy models. This is the
research gap which the thesis is focused.
However, urban energy modeling is a very broad topic and this research focuses on the three
standards for modeling buildings’ heating and cooling energy demand i.e. DIN 18599-2, ISO 13790, and
VDI 6007. These standards were chosen based on Corrado et al. (2007), like many other authors, belief
that heating and cooling space energy significantly contributes to energy demand of the building
sectors. Moreover, the three standards are based on physical calculation approach, as Zhao and
Magoulès (2012) state, an engineering or physical method is preferable since it can be an elaborate
and comprehensively modeled. These standards are interesting to many public authorities all around
the world. Making CityGML Energy ADE compatible with them would be essential for many
international energy assessment projects.
The aim of the thesis is to seek an improvement on the building space energy demand module of
current developed Energy ADE, version 0.5.0, to make it compatible with three space energy
assessment standards; i.e. DIN 18599-2, ISO 13790, and VDI 6007. The data model in CityGML Energy
ADE has been mapped to Unified Modeling Language (UML), and therefore the following objectives
have been identified of paramount importance in achieving the aforementioned aim:
- Clarifying CityGML data model and CityGML ADE

- Evaluating three different building thermal energy standards: DIN 18599-2, ISO 13790, and VDI
6007
- Developing a UML-based data model for the building energy standards
1
City Geography Markup Language, an encoding standard.
10
- Elaborating the correspondence between CityGML Energy ADE and the data model of the three
standards
It is expected that UML diagram of DIN, ISO, and VDI have different classes comparing to Energy ADE,
since classes in the data model of energy standards are energy-concept-orientated, whereas in Energy
ADE are building-component-oriented. For instance, Energy ADE has building, building component,
material and layer classes, VDI however has resistance, capacitances, external and internal load classes,
or ISO and DIN have transmission, ventilation, solar, and internal load classes. The hypothesis is that
attributes of the energy standards are covered by Energy ADE, as Energy ADE’s main purpose is
meeting the required input data of different building energy models.
This research is important in a number of reasons: improvement of Energy ADE can meet the urgent
need of a structured input data model for energy assessment or modeling projects, in particular on
urban scale. Moreover, it provides a coherent perspective on parameters of three energy assessment
standards and their differences which is in interest of building energy models for a comparison view.
Besides, the UML-based data model of energy demand standards paves the way for future
developments in energy modeling software development. As Bernardi et al. (2013) believe model-
driven verification approaches and definition of a proper model for a specific domain are largely
integrated to industrial processes and it provides a formal evidence of the requirements and leads to
implementing a unified approach for system development.
The thesis is structured in 5 chapters: chapter 2 explains the research method, chapter 3 covers the
first two objectives through literature review. Chapter 3 is dedicated to developing UML-based data
model of the three standards, Chapter 4 includes compatibility analysis of Energy ADE with three
standards, inconsistencies are explained and where possible, recommendations are given. The last
chapter is dedicated to conclusion and outlook. For the readers who are not familiar with UML and
OCL, it is recommended to read appendix A: UML Class Diagram and Appendix B: OCL before continue
with the next chapters.
11
Chapter 2: Research Methods
This chapter explains the research method that leads to the thesis’s aim and objectives, mentioned
in Chapter 1, and then discusses about the limitation.
The first two objectives are met by a literature study, in order to understand the concepts of CityGML
for representing a city, and in particular a building, and also input parameters, and method of energy
demand calculation in the three standards. For achieving the next objective, the UML data model of
each standard is developed. For development of data models a general rule has been adapted which is
driven from “General Indicator Model” concept explained in Elfouly et al. (2015). The data models are
divided into three domains: energy domain, building domain, and an interface domain. The energy-
related parameters and concepts are modeled in the energy domain, called Energy Indicator, and the
building-associated parameters and objects built a so-called Reference Object. The interface domain
which is called Object-related connects Energy Indicator to Reference-Object. According to Elfouly et
al. (2015), this indicator-based model makes it feasible for real-life applications, where modelers with
geodata generating viewpoints need to cooperate with energy modelers who want apply the
generated geodata in building energy modeling. Finally, the Reference Object part of each data model
is compared with model of Energy ADE which is developed by Energy ADE committee. The structure of
the building, its relation to other building-related objects and also the building parameters are
evaluated. The parameters of energy data model are linked to the corresponding parameter defined in
Energy ADE. The required computational algorithms are defined by the Object Constraint Language
(OCL). For instance, the algorithm for deriving a value from some parameters defended in the energy
data model.
2.1. Limitations
Some parameters for calculating the heating and cooling energy are not explicitly defined in the
studied standards, and are referred to other standards. It was beyond the thesis’s time to study them;
however it is tried to derived from the researches based on that standard.
13
Chapter 3: Literature Review
This chapter is a literature review on introducing CityGML and its capabilities, specifically Application
Domain extension, and challenging choosing CityGML as city data model in urban energy planning.
Then, it debates the energy assessment methods behind DIN 18599-2, ISO 13790, and VDI 6007, and
compares DIN 18599-2 and ISO 13790.
3.1. Clarification of CityGML and Energy ADE

As it is explained in Chapter 1, CityGML is promising for urban-associated applications such as noise
management, energy management, etc. Kolbe (2009) provides an overview on CityGML, and
introduces it as:” an international standard for the representation and exchange of semantic 3D city
and landscape models recently adopted by the Open Geospatial Consortium (OGC)”. CityGML
represents objects in city by four different points of view, i.e. semantics, geometry, topology, and
appearance. A semantic 3D city model decomposes objects into parts using logical criteria of their
structure in the real word and not graphical considerations (Kolbe, 2009).
CityGML includes a geometry model and a thematic model for city objects. The former leads to
consistency in definition of geometrical and topological properties of spatial objects, and the later
defines topographic objects in city by classes, their relation and attributes through one core module
and thirteen thematic extension modules:
1. Appearance
2. Bridge
3. Building
4. CityFurniture
5. CityObjectGroup
6. Generics
7. LandUse
8. Relief
9. Transportation
15
10. Tunnel
11. Vegetation
12. WaterBody
13. TexturedSurface [deprecated]
Objects can be simultaneously represented in five consecutive Levels of Detail (LoD) regarding to their
geometric and thematic details. (Open Geospatial Consortium) defines them: “The coarsest level LoD0
is essentially a two and a half dimensional Digital Terrain Model over which an aerial image or a map
may be draped. Buildings may be represented in LoD0 by footprint or roof edge polygons. LoD1 is the
well-known blocks model comprising prismatic buildings with flat roof structures. In contrast, a
building in LoD2 has differentiated roof structures and thematically differentiated boundary surfaces.
LoD3 denotes architectural models with detailed wall and roof structures potentially including doors
and windows. LoD4 completes a LoD3 model by adding interior structures for buildings. For example,
buildings in LoD4 are composed of rooms, interior doors, stairs, and furniture. In all LoDs appearance
information such as high resolution textures can be mapped onto the structures. “
Each thematic module represents the semantics of the respective objects in classes, attributes, and
their relations mapping to UML. A detailed explanation of each module can be found in (Open
Geospatial Consortium). In fact, each thematic module consists of classes which are defined for the
most important semantic aspects of respective objects, for example in Building module a class is
defined for openings of building including windows, and doors, or one class for interior furniture.
Moreover, the defined classes are either important or required in various application areas, e.g. energy
demand mapping, noise mapping, indoor navigation, etc. Spatial and non-spatial attributes are derived
from two basic classes i.e. _Feature, and –FeatureCollection. Geometric properties are defined in a set
of geometry classes. Mapping the thematic concepts and their semantics to UML, and GML3 1, results
in a standardized semantic interoperability between various applications.
The core module comprises of the basic concepts and components which have attributes common in
all city objects. It has an abstract class which is the base class of all thematic classes within CityGML’s
data model and is called _CityObject. City objects with different thematic area, e.g. Building,
Vegetation, WaterBody, inherit _CityObject’s properties; i.e. attributes and association.
1
Geographic Markup Language, the XML grammar defined by the Open Geospatial Consortium (OGC) to express
geographical features.
16
Figure 3-1: Building module in CityGML. Source: Open Geospatial Consortium
Since the thesis’s purpose is evaluating building energy assessment, Building module is explained here.
Building module has a fundamental class AbstractBuilding from which Building and BuildingPart inherit
its properties, like its function (e.g. residential, public, or industry), the usage, the year of construction,
the year of demolition, the roof type, the measured height, and the number and individual heights of
the stories above and below ground (Kolbe, 2009). CityGML specification document (Open Geospatial
17
Consortium) asserts that “This set of parameters is suited for roughly reconstructing the three-
dimensional shape of a building and can be provided by cadastral systems”. Figure 3-1 is a UML schema
depicting all classes, relations and attributes defined in Building module. The classes and relations
definition in the Building module is based on capability of CityGML in geometrically multi-scaled
resolution of city objects. For example, boundary surface of Buildings and Building-Parts are semantic
objects from LoD2, _Opening can be represented from LoD3, IntBuildingInstalation, BuildingFurniture
can be modeled in LoD4.
According to CityGML specification document (Open Geospatial Consortium) “Further properties not
explicitly covered by _AbstractBuilding may be modelled as generic attributes provided by the CityGML
Generics module or using the CityGML Application Domain Extension mechanism.” In the first concept,
the desired additional attributes can be augmented to existing classes, providing the existing classes
can provide its name, type, and value. Moreover, the features that are not covered by thematic classes
of CityGML can be defined in the thematic extension module called Generics. The second concept
introduces new properties to existing CityGML classes according to needs of a specific application such
as average storey height for energy assessment applications. The new defined attributes, associations,
and geometries in ADEs might be defined in classes which are subtype of existing classes. Using the
object-oriented concept of CityGML, each ADE can be extended by another ADE (ADE of ADE) so that
define different level of details (Gröger and Plümer, 2012). CityGML specification document (Open
Geospatial Consortium) points out advantages of ADE approach:
- “the extension is formally specified;

- ADEs can be defined (and even standardized) by information communities which are interested
in specific application fields;
- More than one ADE can be actively used in the same dataset.
- ADEs may be defined for one or even several CityGML modules providing a high flexibility in
adding addition-al information to the CityGML data model.”
Therefore, ADE suites defining objects and attributes which are specified for an application totally
freely, whereas Generic method is restricted to the CityGML class and attribute definitions. For different
applications an ADE has been developed, CityGML specification document (Open Geospatial
Consortium) provides CityGML Noise ADE.
To sum up, CityGML represent a data related to a city in an object-oriented concept using thematic
modules, like Buildings, WaterBody, Vegetation, etc., and a Core module which includes all the
attributes and object-oriented classes in the thematic modules. In addition it represents city data in 5
different Level of Details. For example a building can be represented as a two and a half dimensional
Digital Terrain Model in LoD0, as a block in LoD1, with roof shape in LoD2, with door and window
18
details in LoD3, and with interior details in LoD4. Although CityGML represent all topographic objects in
a city, some application might require other objects or attributes of a city, which can be added either
by Generic module or ADE mechanism.
3.2. Critical evaluation of three building thermal energy models

As it is explained in Chapter 1:, there are many different methods for modeling urban energy, however,
the advantages of engineering methods is debated. The most common engineering methods for
modeling space energy are quasi-steady state monthly heat balance and hourly dynamic algorithms.
This section introduces two standards using quasi-steady state algorithm, then they are compared, and
finally a standard based on hourly dynamic algorithm is explained.
3.2.1. DIN 18599-2, Energy efficiency of buildings — Calculation of the energy needs, delivered
energy and primary energy for heating, cooling, ventilation, domestic hot water and lighting —
Part 2: Energy needs for heating and cooling of building zones
In DIN 18599-2, energy needs for heating and cooling is calculated based on monthly balance method
which means that “the energy needs of a building zone for heating and cooling are the heat and cold
gains which are required to maintain the specified internal temperature of the building zone and which
are to be provided by the technical building installations within that zone” (DIN 18599-2). It
characterized a building zone as the spaces with same use, and mode of conditioning, where mode of
conditioning could be meeting a desired room temperature, fresh air supply, light, humidity and/or
domestic hot water. Therefore, energy need for heating and cooling in a building zone based on
monthly balance method is an interaction of building construction characteristics, and its technical
equipment for keeping a desired temperature in the zone.
Monthly balance method investigates the relation between heat sinks and sources. Assuming
consideration of only sensible heat, DIN 18599-2 introduces the effective heat sinks and sources as:
- Transmission heat sinks or sources due to thermal conduction through building components or
elements;
- Ventilation heat sinks or sources due to exchange of air either with external air (infiltration,
window airing), or with supply air from ventilation systems.
- Solar gain through entering solar radiation, or solar sinks or sources due to solar radiation
absorption and radiative heat transfer through external opaque elements.
- Internal heating or cooling due to equipment, e.g. lighting, computer, cold water storage, etc.,
and dissipation heat from occupants which is metabolic heat
- Escaping heat during unoccupied time like holiday or weekend which was stored in the building
components over operating time
DIN 18599-2 is a quasi-steady state method, means that the dynamic behavior of thermal energy in the
building is considered through utilization factor and the set-point temperature adjustments for the
19
unoccupied period. Since the contribution of heat sources differs over calculation time and only part of
heat sources (cold sources) contribute to heating up (cooling down) the zone to the desired
temperature, a utilization factor, which is based on thermal time constant of the building zone, is
defined. Moreover, the heating or cooling energy need over month is determined for usage or
occupied and non-usage or unoccupied days separately, considering the changes in the zone
temperature over non-usage days. (Equation 3-1 shows the requirements for calculating heat energy
need over usage days. The effective parameters in the cool energy need are the same, but the values
of cold sink and sources is different.
𝑄𝑄ℎ, 𝑏𝑏 = 𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄 − ƞ𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄 − ∆𝑄𝑄 𝑐𝑐, 𝑏𝑏 (Equation 3-1)
Therefore heat energy modeling is based on heat sources and sinks, the utilization factor (ƞ), and
escaping heat over non-occupied time (∆𝑄𝑄 𝑐𝑐, 𝑏𝑏). Figure 3-2 illustrates the parameters effecting heating
and cooling energy need based on DIN 18599-2 model.
Transmission
Ventilation
Total heat sinks
Radiation
Building energy need for heating or
Internal
Transmission
cooling
Ventilation
Total heat sources
Radiation
Utilization factor
Internal
Escaping heat over
unoccupied time
Figure 3-2: Determining parameters in heating or cooling energy demand based on DIN 18599-2 standard
Having determined the sinks, and sources, their values need to be assessed. Heat flow due to
transmission or ventilation can be identified as heat loss or gain depending on the temperature
difference between inside and outside air or supplied air by ventilation. Their value is a function of
transmission or ventilation heat transfer coefficient, and this temperature difference. Solar radiation
enters into the zone through glazing or is absorbed or transferred by opaque elements. When long
20
wave radiative heat transfer is greater than solar radiation absorption in the opaque elements, it is
considered as solar sink. Internal heat sinks or sources represent the heat flow from occupant or
appliances in a building zone, for instance boilers, heating pumps, and human are considered as
internal source, and cooling systems are internal sinks. The heat flow due to radiative sink or source
depends on the thermal, physical characteristics and orientation of glazing and opaque elements, as
well as solar irradiance and sky temperature. All the parameters required for determination of heat
flow of sinks and sources are represented in Appendix D: Required Input Data for DIN 18599-2.
3.2.2. ISO 13790, Energy performance of buildings — Calculation of energy use for space
heating and cooling
ISO 13790 is an international standard for building space heating and cooling calculation using three
different algorithms i.e. seasonal or monthly method, simple hourly method, and detailed simulation
method. The calculation time period is defined differently in these three methods. The monthly
method is very similar to the algorithm in DIN 18599-2; i.e. it classifies building to building zones, and
models its heating and cooling energy needs based on heat gains and losses, and utilization factor.
Figure 3-3 illustrates the parameters determining the building energy need for heating or cooling in ISO
13790. ISO 13790 describes a conditioned zone as part of building throughout which the temperature
can be assumed spatially homogenous, and which has same heating, cooling and ventilation systems
(Section 3.2.2).
Transmission
Total heat transfer

Building energy need for heating
Ventilation
Solar gains
Total heat gains
Internal heat
Gain utilization factor
Figure 3-3: Determining parameters in heating or cooling energy demand based on ISO 13790 standard
21
As Figure 3-3 indicates, the main differences between ISO 13790, and DIN 18599-2 are definition of
heat sinks and sources, as well as consideration of escaping heat during unoccupied time. The
differences between ISO 13790 and DIN 18599-2 are point out in the next subsection.
3.2.3. ISO 13790- monthly method vs. DIN 18599-2

As it is explained in the previous section, ISO 13790 is based on three methods; i.e. seasonal or
monthly method, simple hourly method, and detailed simulation method, and its monthly method is
very similar to DIN 18599-2. However, in addition to various names for the same concepts which are
listed in Appendix C, they have some differences in the energy concepts or assessment which are
pointed out below.
Heat gain (source) and transfer (sink)

Having compared Figure 3-2 and Figure 3-3, the definition of solar gain (source) and transfer (sink) is
various. DIN 18599-2 considers solar radiation, transmission, ventilation, and internal exchanges as
both heat sources and sinks, depending on the positive or negative temperature difference between
zone air and external or adjacent space air. Whereas, ISO 13790 categorizes heat flows to transfer and
gain according to their nature of heat release manner, i.e. transmission and ventilation are considered
as heat transfer, internal and solar exchanges as heat gain elements. However in case their value
returns to be negative, they are affecting the heat demand reversely. For example if the supplied air by
the ventilation system has temperature higher than internal set-point temperature, the negative value
of its heat flow behaves latently as heat gain.
Escaping heat during unoccupied time

DIN 18599-2 takes escaping heat from building’s elements during unoccupied or non-usage days into
account. In fact, this is the heat release from the buildings element during non-usage days which acts
as heat source and heats up the building. Therefore, it should be deducted from the building energy
need over month (Equation 3-1). On the other hand, during usage-day some part of the building
heating energy is stored in the elements which should be treated as heat sinks (see (DIN 18599-2), eq.
11). In fact, building energy need for space heating or cooling in a month period should be calculated
for usage-days and non-usage days separately. To sum up, during non-usage days the escaping heat
from building’s element plays a significant role as a heat source in building energy need and should be
deducted from the energy need for heating. While, during usage days, building’s element behaves like
a sink because they store some part of the released heat (see DIN 18599-2, section 6.6).
The set-point temperature adjustments for the unoccupied or intermittency conditions

ISO 13790 defines two kinds of non-usage modes, intermittency and unoccupied time. If some hours
of week the heating/cooling systems are switched off, the set-point temperature differs and leads to
22
different heat gain and transmission. ISO 13790 considers its effect on energy needs differently based
on the time constant and time of switching off:
1. Set-point temperature is the average of normal operation and switch off time temperature
over the calculation time, providing one of the following conditions is met:
- time constant is less than 20% of the shortest switched-off time,
- the set-point temperature variation between normal heating or cooling and switched-off
heating or cooling periods is less than 3 K;
2. The temperature of normal continuous operation is the set-point temperature, providing:
- Time constant is 3 times greater than the longest switch-off time.
3. The heat demand is directly adjusted in case the conditions of 1 and 2 are not met. The
adjustment factor is a function of building time constant and heat balance ratio.
The unoccupied mode is when the building is not used for some day in a month, and thus the thermal
energy demand should be adapted. In this case, the thermal energy demand is firstly determined
assuming the conditions of normal continuous use of building, and then it is adjusted for the number of
unoccupied days (see ISO 13790, section 13.2).
Transmission heat transfer coefficient

Generally, ISO 13790 calculates the transmission heat transfer coefficient the same as DIN 18599-2.
But, DIN 18599-2 introduces two alternatives for thermal bridge calculation: 1) through standard
allowance for thermal bridge and 2) using linear thermal transmittance. ISO 13790 uses just the second
method (see ISO 13790, section 8.3). Moreover, ISO 13790 introduces an adjustment factor for the
buildings with basement or partitions or unheated spaces, where the temperature is different.
Ventilation transmission heat coefficient

DIN 18599-2 differentiates ventilation from window airing, infiltration and mechanical ventilation. The
heat gain and loss through them requires the respective air change rate, and the net volume of the
space. In the other words, DIN 18599-2 distinguishes between different ventilation methods by the
corresponding air change rate, whereas ISO 13790 shows the differences by an adjustment factor,
which plays a role when ventilated air temperature is different from outside temperature. Moreover,
ISO 13790 takes the energy demand of pre-heating or cooling into account for which fraction time of
operation is required.
Internal heat source

For internal heat gain in the building zone, ISO 13790 takes the internal sources in the adjacent
unconditioned spaces also into account, and applies a reduction factor for it (ISO 13790, eq. 34).
Moreover, it represents the internal heat sources by their respective heat flow, whereas DIN 13790
23
applies the mean daily heat dissipation. Also, ISO 13790 differentiate the circulation hat water systems
from other hot water systems, and considers the waste water system as well. On the other hand, DIN
18599-2 takes the internal heat from artificial lighting into account through the mean daily electrical
energy input and lighting heat gain coefficient of the artificial lightings (see DIN 18599-2, section 6.5.5).
It also considers the specific heat capacity and the mass transport rate where material with
temperature significantly different from internal temperature is transported in the zone, like the
production facility (see ISO 13790; DIN 18599-2, section 6.5.4).
Solar Heat Gain

ISO 13790 considers the heat flow rate from solar heat source in the unconditioned adjacent space,
and take this heat flow into account by using a reduction factor or adjustment factor (ISO 13790, eq.
41). Although, the national level norms may ignore the heat gains from the unconditioned adjacent
spaces (ISO 13790, section 11.2). DIN 18599-2, however, suggests ignoring the solar heat gain via
unheated or uncooled sunspaces, because it is represented in the temperature increment of the
adjacent spaces (DIN 18599-2, section 6.4.3). Furthermore, ISO 13790 applies the shading factor and
form factor for both opaque and transparent elements (ISO 13790, eq. 43), whereas, DIN 18599-2
applies the shading factor for the transparent elements, and the form factor for the opaque surfaces
(DIN 18599-2, eq. 110-113). Also, DIN 18599-2 considers a correction factor and a dirt depreciation
factor for transparent elements, and opaque elements with transparent thermal insulation.
3.2.4. VDI 6007, Calculation of transient thermal response of rooms and buildings
This standard proposes a detailed analysis of the thermal properties of the building components and
their transient behavior (adiabatic/ non-adiabatic) in an hour step using lumped parameter modeling
method in order to assess building dynamic thermal response. Underwood (2014) reviewed lumped
parameter modeling method and categorizes them in two main models; i.e. lumped-parameter rooms’
construction model, and lumped-parameter entire room model. Lumped-parameter models represent
thermal response of a room or its construction by resistance-capacitance networks in electric circuit
analogy. Electric capacitances represent heat capacity of indoor air or a wall layer, for instance, the
corresponding voltages represent the temperature, electric resistances represent thermal resistance,
and the heat flow is equivalent to their electric current (Fux et al., 2014). Depending on the number of
the capacities in lumped-parameter room model, they are also called low-order and second-order
models (Lauster et al., 2014a).
VDI 6007 models room thermal response using both lumped-parameter construction and entire room
models (VDI 6007, Section 7.3 and 7.4). Like DIN 18599-2, and ISO 13790, it defines a zone spaces in
the building where has homogenous air temperature vertically and horizontally, and heat sources and
24
sinks are effective in the entire zone, therefore high ceilinged rooms like hall should be subdivided
vertically (VDI 6007, section 6.3 and 7.2).Then, it categorizes all the zone construction elements, e.g.
windows, walls, into two groups; i.e. symmetrically thermal loaded interior components (interior
walls), and asymmetrically thermal loaded exterior and interior components (exterior walls) (Lauster et
al., 2014a). In fact, it models the components with same temperature in both side as interior walls, and
those with different temperature in both side as exterior walls, even if they are topologically interior
walls. This is one of its differences with the last two standards, where define interior surfaces with
different temperature at both sides as adjacent unconditioned boundaries.
Asymmetry elements Symmetry elements
Figure 3-4: Room thermal response’s model in VDI 6007. Source: VDI 6007
Figure 3-4 illustrates room thermal response model defined in VDI 6007. Interior components are
represented by one capacity and resistance (RIW, CIW) 1, and the exterior components are represented
by one capacity and two resistances, one represents walls, and one models other exterior components
like winnows, roof, etc. (RAW, RRest,AW, CAW) 2. Convection between wall surface and indoor air, and
radiation between wall surfaces is modeled by two resistances, one representing interior walls and one
representing exterior walls (Rα,stern,AW, Rα,stern,AW) 3. Internal loads such as persons, appliances, and light
are categorized based on their heat release manner; i.e. convection or radiation, and are modeled by
electric currents (QIL;str;IW, QIL;str;AW, QIL;kon) 4, but ventilation is individually modeled as a resistance (RLue) 5
and its supply air temperature as voltage (∆ϑLue). Heating and cooling loads which are equivalent to
currents in the electric circuit, are also categorized to convection, and radiation (QHK;kon, QHK;str;IW,
1
IW stands for “Interior Wall”.
2
AW stands for „Außer Wand“ in German which means exterior wall.
3
Stren in German means star, and shows the star connection between resistances (see VDI 6007 , eq. 55-57)
4
IL stands for „Internal Load“, kon stands for „convective“, and str stands for “strahlung” in German which means
radiative.
5
Lue stands for „Lüftung“ in Gemran which means ventilation.
25
QHK;str;AW). The effect of external long-wave and short-wave radiation on building components with a
specific orientation, outdoor air and ground temperature is represented by equivalent outdoor
temperature which is weighted over all surfaces (∆ϑA;eq;gew) (VDI 6007, p. 24). Surface temperature of
interior wall and interior side of exterior wall are modeled as voltages of interior and exterior
capacities (ϑIW , ϑEW).As it is shown in the Figure 3-4, VDI 6007 distinguishes internal loads from heating
cooling systems, and categorize them into radiation and convection sources. The radiant sources in the
room are subdivided to those located in the room (e.g. lighting), and those located outside but have
effect inside the room (e.g. solar radiant).They are considered separately for each exterior building
component having transparent surface, and then are summed up. Contribution of each building
component to radiation exchange which corresponds to its surface area is crucial, but the angel is not
considered (VDI 6007, eq. 45-48, and Section 7.4). In addition to heating cooling systems which
contribute to building energy need, chilled or heated surfaces in the building zone are considered as a
heating cooling source or sink. However, convective contribution of chilled or heated surfaces is not
considered in VDI 6007 (VDI 6007, eq. 52-54).
Thermal resistance and capacity of a wall are a combination of thermal resistance and capacity of its
layers. Therefore, the layer-scale parameters are required (VDI 6007, Section 7.3). Capacities’ values
depend on activated thermal mass of the building elements, which is in relation of the thickness that
can store heat. This is called Periodic depth of penetration and corresponds to the periodical loading
behavior of the building elements (VDI 6007, eq. 1-9). Lauster et al. (2014a) asserts that “This time
period thus highly influences the model’s dynamic behavior and should be chosen carefully.” All the
required input data for determination of the influencing parameters shown on Figure 3-4 thermal
response, their unit, purposes, and sources are listed in Appendix E: Required Input Data for VDI 6007.
As an overview, Lauster et al. (2014b) categorizes the influencing building zone’s parameters on its
energy needs for space cooling or heating in three groups:
- Building physics-associated parameters; i.e. resistances, and capacities

- Internal loads; e.g. persons, machines, HVAC, light
- External loads; e.g. solar radiation, natural ventilation or infiltration, outside air temperature
3.3. Summary
This chapter firstly explained how CityGML represents city data by defining them in different thematic
modules, and in a combination of different Level of Details. Then the UML schema of Building module
was represented depicting its classes, relation and attributes. Later, the capability of CityGML for
defining new objects and attributes by using either Generic module or ADE mechanism was discussed.
26
Finally, in the next subsections, the three chosen standards for assessing space heating and cooling
energy were described, and their energy assessment concepts were explained.
27
Chapter 4: Data Model Development
This section is dedicated to UML-based data model development of the three standards. The climate-
related parameters are neglected, and only building-related parameters are modeled. As it is explained
in 0 each data model contains three parts; i.e. Energy Indicator, Object-related, and Reference Object.
Development of each part, and the reason or logic behind the defined relationships, or multiplicity is
explained in this chapter. Then the application of OCL in determination of the attributes which are
defined in the data model is stated in a sub-section for DIN 18599-2, and VDI 6007.
Since the complete data model of each standard is very large and is not possible to be presented in the
report, they are attached separately in A0 size. As a general rule, the classes in Object-related are a
subtype of corresponding attribute in Energy Indicator domain, and an association is established
between the object-related classes and the respective classes in reference objects. Where it is
required, multiplicity of the association is reasoning in this chapter.
4.1. DIN 18599-2 Data Model

As it is explained in 0, DIN 18599-2 data model comprises of three main parts; Energy Indicator model,
Object-related model, and Reference Object model. The influencing parameters in energy assessment
based on this standard can be found in section 3.2.1, Energy Indicator model has defined a class for
each influencing parameter, and they have an aggregation hierarchy to DINEnergyNeed class
(Figure 4-1). In other words, DINEnergyNeed needs these parameters to have a value. In general, the
relation of “needs” or “comprise of” is depicted by aggregation. Another example is the class defined
for escaping heat in reduced operation called EscapingHeatInReducedOperation which needs the value
of HeatSink, HeatSource, and UtilizationFactor classes (DIN 18599-2, eq. 126) .
The multiplicity of HeatSink, HeatSource and UtilizationFactor is [1.2], which means that occurrence of
HeatSink, HeatSource and UtilizationFactor for DINEnergyNeed is either 1 or 2 times. When one of
heating or cooling energy needs of the building is to be considered, it is 1, and if energy of both
conditions is needed, two different boundary conditions should be considered (2 times occur).
EscapingHeatInReducedOperation has a multiplicity of 0.4 for DINEnergyNeed, as it has 4 likely
29
occurrences for 5 different boundary conditions i.e. heating, cooling, holiday, weekend, and
continuous usage of building.
Figure 4-1: Energy Indicator model of DIN 18599-2
In the Energy Indicator model of DIN 18599-2, heat sources and sinks are integrated into one class,
since transmission, ventilation, internal, and radiation heat flows can act either as heat sink or source
(see section 3.2.1). All the classes are labeled by << abstract>> which implies they are not directly
instantiated and they are only a subtype of the corresponding classes in Object-related model.
Figure 4-2 depicts the Object-related model. The structure is like Energy Indicator model, but the
classes are assigned to building or building part, as a subtype of the corresponding class in Energy
Indicator model. For example, BuildingZoneDINEnergyNeed is a subtype of DINEnergyNeed.
BuildingZoneUtilizationFactor is associated with HeatSink and HeatSource, as it depends on the sum of
heat sinks and sources. Radiation and transmission heat gain or loss in a building zone occurs in its
boundaries, which is why BuildingZoneBoundaryTransmissionSinkSource and
BuildingZoneBoundaryRadiationSinkSource are aggregated to BuildingZoneTransmissionSinkSource and
BuildingZoneRadiationSinkSource, respectively. Solar gain through building zone boundary is optional,
since a building zone might have no transparent surface on its boundary, therefore multiplicity is [*].
But, transmission loss always occurs on all boundary surfaces, and a zone has at least 3 boundaries,
30
multiplicity is [3..*]. The reason of defining multiplicity of [0..2] for

BuildingZoneTransmissionHeatSinkSource, is three probable occurrences:
- It may occur 1 time for a building zone when transmission is a sink for either cooling or heating
conditions
- It may occur 2 times for a building zone when transmission is a sink for both cooling and
heating conditions
- It may not occur for a building zone when transmission heat exchange does not act like a sink
which is the result of temperature conditions inside and outside the zone.
This is the same for other sink/source classes.
The last part of the data model is Reference Object which shades the light on the building
decomposition vision of DIN 18599-2 (Figure 4-3). It decomposes a building into BuildingZone and
BuildingZoneBoundary. Definition of building zone can be found in section 3.2.1. Energy assessment of
a zone requires geometric or physical data about adjacent spaces, for instance, for determination of
transmission and ventilation heat loss through unconditioned spaces (DIN 18599-2, eq. 46-47, and 94).
Therefore, an association with role of adjacent is defined for both building zone and building. In case
the entire building is considered as one building zone, the adjacent zone is the adjacent building.
As it is illustrated in Figure 4-3, DIN 18599-2 does not have an interior-oriented vision necessarily.
Internal heat capacity of interior components, which is needed for time constant, is optional, since it
DIN 18599-2 has an alternative way for it. Multiplicity of the association between BuildingZone and
BuildingZoneBoundary is [3..*] and [2], since each building zone is bounded by at least 3 boundaries,
and each boundary belong to two building zones.
HeatTransferCharacteristics and SolarGainCharacteristics are a set of thematically different properties

of BuildingZoneBoundary, which is why they are classified as dataType. The reason for classifying them
separately is firstly to provide the opportunity of modifying the attributes in a specific theme easily
without the need of re-constructing the data model. Secondly, defining them as optional attributes in
case another aspect of energy calculation, e.g., internal heat gain, is demanded.
Ventilation sink and sources are also defined as a separate dataType, in addition to the explained
reasons; it makes it easier to define as many ventilation types as it is desired. In fact, a building zone
might have several ventilation sinks or sources i.e. infiltration from outside, from sunspace,
unconditioned adjacent space, or adjacent building, or mechanical ventilation. Each ventilation sink or
source is characterized by a specific air flow rate and supply air temp, which leads to different
ventilation transfer coefficient (ISO 13790, section 9.2).
31
All the building parameters require energy demand assessment according to DIN 18599-2 are defined
as the attributes of the corresponding classes. The optional attributes, which are distinguished by [0..1]
multiplicity, have either an alternative attribute e.g., effective heat capacity, or default value e.g.,
frame area fraction, or they might not occur for some buildings e.g. net volume of unheated/uncooled
zones. Usage Type in BuildingZone, which is either residential or non-residential, is needed for
determination of internal heat sink or sources (DIN 18599-2, eq. 117). normalOperationPerWeek is
defined for BuildingZone implies the day number per week that the building zone has a normal or
continuous heating cooling schedule.
As it is explained the complete data model of DIN 1859-2 is attached. In the attached data model, the
cardinality of the association between BuildingZone and BuildingZoneDINEnergyNeed is [1..2], since
each building zone might have cooling energy need or heating energy. Also, each
BuildingZoneBoundary has one boundaryTransmissionCoefficient which result in a cardinality of 1. Each
BuildingZoneBoundary has one radiation value either gain or loss, cardinality of [1..2]. Having explained
the data mode of DIN 18599-2, its relation with CityGML Energy ADE is discussed in section 5.1.
32
Figure 4-2: Object-related model of DIN 18599-2
33
Figure 4-3: Reference Object model of DIN 18599-2
34
4.1.1. OCL’s Application in DIN 18599-2’s Data Model

In Figure 4-1 and Figure 4-2, the attributes marked up with “/” in front of their name can be derived
from other attributes of the data model. OCL is used as a tool for expressing the computation
algorithm. As an example, derivation of “/valueSink” of TransmissionHeatSinkSource (Figure 4-1) is
expressed through 3 OCL rules.
I. The value of transmission loss of a building zone

context BuildingZoneTransmissionSinkSource
inv: buildingZoneTransmissionHeatLoss=
self: BuildingZoneBoundaryTrnasnmissionSinkSource.zoneBoundaryTransmissionLoss -> sum()
II. The value of transmission loss of a zone boundary

context BuildingZoneBoundaryTransmissionSinkSource
inv: zoneBoundary.isOutsided=True And (zoneBoundary.buildZone.setPointTemp> outsideTemp)
implies zoneBoundaryTransmissionLoss= zoneBoundaryTransmissionHeatTransferCoefficient* (
zoneBoundary.buildZone.setPointTemp - outsideTemp)
III. The value of transmission coefficient of a zone boundary

context BuildingZoneBoundaryTransmissionSinkSource
inv: zoneBoundary.isOutsided=True
implies
zoneBoundaryTransmissionHeatTransferCoefficient=zoneBoundary.heatTransferCharacteristics.thermal
Transmittance
*zoneBoundary.projectedArea)+(zoneBoundary.heatTransferCharacteristics.(linearThermalTransmittan
ceOfThermalBridge*thermalBridgeLength))
The first OCL expresses that transmission heat loss for a building zone is a sum of transmission heat
loss of all its boundaries. The second OCL shows that providing the zone boundary is adjacent to
outside, and set-Point temperature of the building zone is greater than outside temperature, zone
boundary behaves as a transmission sink and its transmission loss is a multiplication of its transmission
coefficient and temperature difference between and outside the zone (DIN 18599-2, eq. 42).
Moreover, its transmission coefficient value is expressed by last OCL, which is the product of its
thermal transmittance and projected area plus product of its linear thermal transmittance of thermal
bridge and its length (DIN 18599-2, eq. 44). All the attributes like, thermalTransmittance,
projectedArea, linearThermalTransmittanceOfThermalBridge, and thermalBridgeLength are navigated
to the hosting class.
4.2. ISO 13790 Data Model

Having explained in 3.2.2, the monthly balance method of ISO 13790 is quite similar to DIN 18599-2;
therefore their data model should be similar as well. Figure 4-4 represents the Energy Indicator part of
the data model.
35
Figure 4-4: Energy Indicator of ISO 13790
The only difference with DIN 18599’s data model, is IntermittencyAdjustment class and the
classification of heat transfers and gains. The reason is explained in see section 3.2.2. The logic or
reason behind all other classes, their attributes and relationships are the same as data model of DIN
18599-2 (see section 4.1).
Figure 4-5 illustrates the Object-related model of ISO 13790. Aside from
BuildingZoneIntermittencyAdjustment class, all other classes, relations and attributes are the same as
DIN 18599-2 (see section 4.1 for explanations). An association is established between
BuildingZoneIntermittencyAdjustment and BuildingZoneSpaceEnergyNeed with the role of energy need
adjustment.
Having a look at the attached complete data model of ISO 13790,

BuildingZoneIntermittencyAdjustment is associated to BuildingZone with multiplicity of [0..4], since it
has 5 different probability for occurrences:
- no adjustment
- set-point temperature of building zone is adjusted for heating or cooling energy assessment
- energy need of building zone is adjusted for heating or cooling energy assessment
36
- set-point temperature of building zone is adjusted for heating and cooling energy assessment
- energy need of building zone is adjusted for heating and cooling energy assessment
Figure 4-6 shows that the building decomposition of ISO 13790 is almost same as DIN 18599-2. The
reason of defining each class and relation can be found in section 4.1.
Data about having a partition wall, WallType, is needed for calculating adjustment factor for
transmission coefficient, as temperature in other side of partition walls might be different from
outside, and therefore the adjustment factor might be required (ISO 13790, eq. 18). Recognition of
Door as a specific type of BuildingZoneBoundary is defined according to ISO 13790, section 8.3.2.1
which introduces heat transfer coefficient for windows, and doors.
37
Figure 4-5: Object-related model of ISO 13790
39
Figure 4-6: Reference Object model of ISO 13790
41
4.3. VDI 6007 Data Model

Like the last two standards, VDI data model is divided into three main parts, Energy Indicator model,
Object-related model, and Reference Object model.
Figure 4-7: Energy Indicator model of VDI 6007.
As Figure 3-4 thermal model of VDI shows, calculation of space energy demand in VDI 6007 comprises
of temperature, thermal resistances, heat capacities, and heat flux, categorized into internal and
heating/cooling, which are represented in an aggregation hierarchy (Figure 4-7). The multiplicities
show the number of incidences of the classes for space energy assessment. For example, multiplicity of
Temperature class is [3..5], as in order to determine space energy demand, it occurs at least for 3
objects i.e. interior, exterior surface wall temperature, and equivalent outdoor temperature. Also, it
might be needed at most for two more objects; air temperature, and supply air temperature. In fact,
temperature of indoor air is not necessarily required since it can be derived from convective heat
fluxes generated by internal sources, and heating/cooling systems (Lauster et al., 2014a). The
multiplicity of HeatFlux is [0..6], as it is maximum 6 times required for energy assessment (see
Figure 3-4). All of the classes are abstract class, since they are not directly instantiated, and their sub-
classes in the Object-related model are instantiated (see the attached complete data model of VDI
6007).
43
Figure 4-8 illustrates the second part of the VDI 6007’s data model representing the semantic concept
behind the Energy Indicator section. VDI space energy demand is assigned to a building, which
comprises of BuildingZoneThermalResponse. Definition of zone can be found in section 3.2.4.
BuildingZoneThermalResponse has an aggregation hierarchy to all the parameters that thermal
response needs (see Figure 3-4). Thermal resistance and capacity of interior (or exterior) walls is a
combination of complex resistance of all interior walls. Complex resistance consists of resistance as
real particle, and capacity as imaginary particle (see VDI 6007, eq. 23-24). Therefore, an association is
established between BuildingComponentThermalResistance and BuildingComponentHeatCapacity.
Multiplicity of BuildingComponentHeatCapacity is [0..1], since thermal resistance which represents
convention and radiation does not need the incidence of heat capacity.
The Reference Object model (Figure 4-9) indicates building decomposition based on the VDI 6007
method. In spite of ISO 13790, and DIN 18599-2, in VDI 6007, all building surface components
contribute to the building zone’s thermal response and not only boundary surfaces. Each building
component is composed of different layers, as well, since as it is explained in section 3.2.4. Layer-scale
parameters are required for thermal resistances and capacities. ExteriorComponents includes building
components adjacent either to outside, such as roof, outside wall, or to an unconditioned space, like
cellar or attics (VDI 6007, sections 3 and 7.4).
VDI 6007 explicitly defines the surface area of exterior and interior components in section 3; surface
area of exterior component is “The dimensions of an exterior building component are determined from
its gross dimensions, whereat the width of an exterior building component results from the wall
centerline-to-centerline distance (grid size) and the height of an exterior building component is
measured from floor upper edge to floor upper edge.” And Surface area of interior component is
“Clear dimensions are to be used as the dimensions of interior building components.”
44
Figure 4-8: Object-related model of VDI 6007
45
Figure 4-9: Reference Object model of VDI 6007
The attached data model of VDI 6007 indicates the interconnection between the three models.
The association relation between BuildingZoneComponent and BuildingComponentThermalResistance

has cardinality of [1..3], as at least one and at most 3 objects can be instantiated as thermal resistance
of building component; one for either interior or exterior component, one for convection between
component and air, and one for radiation between components (Figure 3-4).
4.3.1. OCL’s Application in VDI 6007’s Data Model

As it is explained before, OCL is used to express the computation algorithm for derived attributes. The
attribute“/value” of HeatCapacity and Temperature modeled in the Energy Indicator inter-model
(Figure 4-7 ) are explained for instance:
• HeatCapacity
I. The value of heat capacity of interior components
context HeatCapacity
inv: BuildingComponentHeatCapacity.OCLIsKindOf (HeatCapacityOfInteriorComponent) implies
value= "combinedRule23” forAll (i | i.heatCapacityOfInteriorComponent &
i.thermalResistanceOfInteriorComponent)
II. The value of heat capacity of one interior component
context HeatCapacityOfInteriorComponent
47
inv: heatCapacityOfInteriorComponent->"combinedRule12"forAll (l|

l.heatCapacityOfInteriorComponentLayer & thernalResistanceOfInteriorComponentLayer)
III. The value of heat capacity of one layer

context HeatCapacityOfInteriorComponent
inv: heatCapacityOfInteriorComponentLayer=
componentLayer.(thickness*specifcHeatCapacity*density)
Based on OCL algorithm I, the value of HeatCapacityOfInteriorComponent is a so-called

combinationRule23, which is applied for heat capacity and thermal resistance of all interior
components. The combinationRule23 should model the equation 23 of VDI 6007. The heat capacity and
thermal resistance is derived from other attributes which is formulated by the two next OCLs. Heat
capacity of interior components is a combination of thermal resistance and heat capacity of all layers.
The combination rule is called combinedRule12, and models equation 12 to 14 in VDI 6007. In the last
OCL algorithm, the computation of heat capacity of each layer is represented.
• Temperature
context Temperature
inv: BuildingZoneTemperature.OCLIsKindOf(BuildingZoneSupplyAirTemp)
implies value= buildiingZone.supplyAir.supplyAirTemp
This OCL implies that the temperature value is equal to supply air temperature, providing
BuildingZoneSupplyAirTemp is considered as the source of building zone temperature. Supply air
temperature is navigated through associations with ending role name of buildingZoneTemperature and
supplyAir.
4.4. Summary
This chapter explained the development of data model for the three standards. The three part of the
data models, i.e. energy Indicator, Object-related, and Reference Object, represented, and the
controversial classes, relations, multiplicities, and attributes in each are clarified. Finally, an example of
OCL-based algorithm shaded a light on computation of the attributes in the data models.
48
Chapter 5: Compatibility Analysis
This chapter is allocated to investigation of the compatibility of CityGML Energy ADE with the data
model of the three standards. The Reference Object domain of each data model is compared with
Energy ADE from two aspects i.e., data structuring and data covering. The attribute analysis is sub-
divided to two subsections, one for giving an example of OCL’s application in linking matched attributes
in data models and Energy ADE, and one describing the miss-matched attributes, and a
recommendation for compensating it.
5.1. CityGML Energy ADE Compatibility with DIN 18599-2

5.1.1. Structure Analysis
The structure of two systems is consistence, when structural relationships between entities in two
different systems are preserved. McUmber and Cheng (2001) called it homomorphic mapping and
believe that “This property enables compositional, semantic-preserving mappings from one system to
another.” Therefore, the structure of DIN 18599-2 and Energy ADE are investigated from two aspects:
firstly, finding one-to-one corresponding classes in two models, and secondly, finding homomorphic
relation between classes.
Figure 5-1 shows the building decomposition classes in the DIN 18599-2 data model which are
associated to the corresponding classes in CityGML Energy ADE. Although a one-to-one relationship
has been found for all the building decomposition classes in DIN 18599-2 and a correspond class in
either CityGML or Energy ADE, their relation is not always preserved. The structural inconsistencies
are:
• BuildingZone vs. ThermalZone:

According to DIN 18599-2, a building should be divided into conditioned building zones, where energy
assessment is considered. However, physical and geometric data of unconditioned adjacent spaces
have effect on the energy need of conditioned zone (see section 4.1), thus an association to adjacent
ThermalZone is needed.
49
• Building, BuildingZone, and BuildingZoneBoundary vs. _AbstractBuilding, ThermalZone, and

ThermalBoundarySurface:
The relation between _AbstractBuilding and ThermalZone is recommended to be composition
hierarchy, since energy need of thermal zone is strongly dependent on the entire building (effects of
unconditioned spaces for example), and ThermalZone will destroy when _AbstractBuilding does not
exist. This is the same for relation between ThermalBoundarySurface and _AbstractBuilding.
• BuildingZoneVentilationSinkSource, and BuildingZoneInternalHeatSinkSource vs. UsageZone

Classification of UsageZone and ThermalZone might cause ambiguity in finding the corresponding
usage feature for a thermal zone. In fact, for building energy assessment recognition of the thermal
building zone is required, and the usage data is its characteristics (see definition of zone in
section 3.2.1). Therefore, the usage data can be defined as a dataType for ThermalZone, like the data
model of DIN 18599-2.
• BuildingZoneBoundary vs. Construction

Although they are not completely corresponding classes according to their names, construction
includes the attributes that are related to building zone boundary, like uValue (see the attached data
model of DIN 18599-2). However, it is recommended to define a ThermalZoneComponent class which
includes both interior and exterior components and integrate the Construction into it. Definition of a
ThermalZoneComponent class is important for VDI 6007’s data model as well (see section 5.3.1).
• OpaqueMaterial and Glazing

Recognition of opaque elements, transparent with non-scattering and transparent with solar
protection devices is required for energy assessment in DIN 18599-2 (see definition of zone in
section 3.2.1), but they should be assigned to ThermalBoundarySurface and not Construction class,
therefore a re-construction in Construction, Layer, LayerComponent, and AbstractMaterial is
recommended. Alternatively, a relation between Glazing and Window class defined in CityGML should
be established, so that the window’s features defined in Glazing can be assigned to the corresponding
window.
• SurfaceComponent
Each thermal boundary can be coupled to ground and not its component; therefor definition of
SurfaceComponent with these attributes (see the attached data model) is not practical.
• Window _Opening
As Figure 5-1 indicates, Window is a subclass of _Opening. In addition, according to the data model of
DIN 18599-2 (see definition of zone in section 3.2.1) window should inherit the BuildingZoneBoundary
50
properties. Thus, establishing an association between _Opening <<ADEElement>> and

ThermalBoundarySurface is recommended.
51
CityGML Energy ADE DIN 18599-2, Reference Object
Figure 5-1: Structural coherence between DIN 18599-2 and CityGML Energy ADE
53
5.1.2. Attribute Analysis

OCL’s Application in linking data model of DIN 18599-2 to Energy ADE
The attributes that are met by the CityGML or its Energy ADE are navigated to their corresponding
attribute by OCL. One of the OCLs navigating thermalTransmittance attribute is explained here as an
example:
context HeatTransferCharacteristics
inv: thermalTransmittance= zoneBoundary.construction.uValue
Based on this OCL, the value of thermalTransmittance, which is located in HeatTransferCharacteristics,

is equal to value of uValue. Two associations are established between HeatTransferCharacteristics and
uValue’s hosting class, with end name role of zoneBoundary and construction, respectively.
OCLs of other matched attribute can be found in the attached data model of DIN 18599-2.
Mismatched Attributes
The missing attributes in the CityGML Energy ADE are listed below, followed by the hosting class in
DIN’s data model. It is bolded where a hosting class in Energy ADE can be easily recommended, and it is
underlined where the attributes that might be obtained through a pre-processing stage using other
attributes.
1. id; BuildingZone, BuildingZoneBoundary

Identification of building zone component and component layers is important for tracing
building zone and its corresponding boundaries. It can be added directly to the classes.
2. isAdjacentToUnconditionedSpace; BuildingZoneBoundary and hasUnheatedUncooledSpace;
Building
Data about adjacent unconditioned spaces is needed for determination of transmission (DIN
18599-2, Table 6) and ventilation (DIN 18599-2, Table 6) heat loss through unconditioned
spaces. The attributes can be added to ThermalBoundarySurface and _AbstractBuilding,
respectively.
3. isAdjacentToJambWall; BuildingZoneBoundary
This is needed for determination of temperature correction factor which is required for
calculating the temperature of unheated/uncooled space (DIN 18599-2, Table 6). This can be
added to ThermalBoundarySurface and Wall Type.
4. hasSunspace; Building
It is needed for consideration of solar gain through unheated sunspace (DIN 18599-2, Table 6) .
This can be augmented to _AbstractBuilding.
5. hasPartialHeating; Building
It determines if this building has spaces that are indirectly heated by the spaces and heated up
to a specific set-point temperature different from set-point temperature (DIN 18599-2, Table
6) . The recommended hosting class is _AbstractBuilding <<ADEElement>>.
55
6. type; Wall/ Roof/Window/Floor/

SolarGainCharacteristicsOfTransparentWithSolarProtectionDevice:
According to (DIN 18599-2, Table 6) DIN 18599-2 eq. 106 to 108, type of Window and the solar
protection device should be clarified. Determination of jamb walls and floor types are needed
for temperature correction factor (DIN 18599-2, Table 6). Partition walls have effect on the
solar gains (DIN 18599-2, Table 6) , and also on transmission loss (DIN 18599-2, Table 6).
Because temperature in the two sides of partition walls might be different, and therefore an
adjustment factor might be required. All the types can be added to
ThermalBoundarySurfaceType. Roof Type is an optional attribute, and is needed in case of
unavailability of absorption coefficient of roofs. For each roof type, the corresponding
absorption coefficient can be derived from a table in DIN 18599-2. (DIN 18599-2, Table 6).
7. linearThermalTransmittanceOfThermalBridge; HeatTransferCharacteristics
It is an optional attribute, since there is an alternative way for thermal bridge consideration.
However, according to (DIN 18599-2, Table 6), eq. 45, this value might be available for each
zone boundary, and it is recommended to add it to ThermalBoundarySurface.
8. pointThermalTransmittanceOfPointThermalBridge; HeatTransferCharacteristics
According to (ISO 13789, eq.18), it is required for transmission coefficient. Recommended
hosting class is to ThermalBoundarySurface.
9. thermalBridgeLength; HeatTransferCharacteristics
It is needed for transmission heat transfer coefficient (DIN 18599-2, Table 6), however, it is an
optional attribute, as an alternative calculation method can be applied. This can be added to
ThermalBoundarySurface.
10. standardAllowanceForThermalBridges; HeatTransferCharacteristics
It is an optional attribute, because firstly DIN 18599-2 has an alternative way for transmission
heat transfer coefficient determination, secondly, it has default values (DIN 18599-2, Table 6).
This can be added to ThermalBoundarySurface.
11. dirtDepreciationFactor; TransparencyCharacteristics
This is required for determination of solar gain through transparent building component (DIN
18599-2, Table 6). But, it is defined as optional attribute, as is not crucial for energy analysis in
urban-scale, however, it can be easily added to Glazing.
12. obstacleAngle; SolarGainCharacteristics
This parameter is needed for determination of shading reduction factor (DIN 18599-2, Table
6), and depending on obstacle type, can be horizon, overhang, or fin angle (figure …). This
parameter can be clarified in –Opening <<ADEElemnt>>.
Figure 5-2: Horizon angle, Overhang angle, Fin angle. Source: DIN 18599-2
56
13. obstacleType, SolarGainCharacteristics

Differentiating obstacles is needed since horizon, overhang obstacles, or fins make different
angle with the building zone boundary (DIN 18599-2, 109). Horizon obstacle like buildings,
building parts, or topographic features such as trees, hills, and overhang obstacle such as
balconies or canopies. This parameter can be clarified in –Opening <<ADEElemnt>>.
14. specificHeatCapacityOfMovedMaterial; BuildingZoneInternalHeatSinkSource
It is needed for calculating the internal heat sources/heat sinks due to movement of materials
(DIN 18599-2, eq.121-122). It is not clearly define in Energy ADE as heating/cooling Schedule;
UsageZone. It can be added into UsageZone.
15. massTransportRate; BuildingZoneInternalHeatSinkSource
It is needed for calculating the internal heat sources/heat sinks due to movement of materials
(DIN-eq.121-122). It can be added into UsageZone.
16. fluorescentLampsExtractionType; BuildingZoneInternalHeatSinkSource
DIN 18599-2 specifies the heat gain of artificial lightings very in detail (DIN 18599-2 eq. 123).
However, it might be defined in ElectricalAppliances class in Energy ADE.
17. meanDailyHearDissipationFromMachinary; BuildingZoneInternalHeatSinkSource
it can be added to Facilities.
18. supplyAirTemp; BuildingZone
It is required for ventilation loss calculation, however is not in _Schedule explicitly defined.
19. frameFactor; TransparencyCharacteristics
This is the ratio of the transparent area to the total area of the element. Since DIN has
provided default values for some cases (DIN 18599-2, eq. 105,113,114), it is an optional
attribute. It is defined in the SolarGainCharacteristics class, as it is required for both type of
transparent elements, however it is optional, thus is not necessarily needed in case of opaque
elements. Moreover, it can be obtained in a pre-processing stage, or added to _Opening
<<ADEElement>>, after defining an association between _Opening <<ADEElement>> and
ThermalBoundarySurface, or directly in ThermalBoundarySurface.
20. thermalMassType; BuildingZone
DIN 18599-2 assumes the effective heat capacity of building according to thermal mass type of
low, medium, and high (DIN 18599-2, Table 6). This can be adjoined into ThermalZone, or can
be pre-processed based on material density.
21. setPointTemp; BuildingZone
This can be determined for ThermalZone. Nevertheless, this attribute might be determined in a
pre-processing stage based on the building usage type.
22. permittedSetBackTemp; BuildingZone
It is needed for modification of set-point temperature in the reduced operation modes (DIN
18599-2, eq.27 and 30). Energy ADE model does not explicitly define it, and a recommended
class is ThermalZone or UsageZone. Nevertheless, this attribute might be determined in a pre-
processing stage based on the building usage type.
23. uncontrolledHeat/coldInputFromDHW/HeatingSystem/CoolingSystem/MechanicalVentilatio
n; BuildingZoneInternalHeatSinkSource
57
Based on DIN 18599-2, section 6.5.6, they are needed for determination of internal heat sinks
and sources. It is recommended to add them in DHWFacilities and Facilities classes. This might
be determined in a pre-processing model using building usage type.
24. meanDailyHeatFlowThroughGround; HeatTransferCharacteristics
DIN has introduced this parameter for calculating the transmission heat transfer coefficient of
the buildings with a considerable heat flow through ground (DIN 18599-2, eq.55). This is can be
added to ThermalBoundarySurface as optional attribute, since it is not needed for all type of
thermal boundary, or can be calculated in a pre-processing model.
25. externalResistance; HeatTransferCharacteristics
According to DIN 18599-2, eq. 110-113 , external resistance is needed for obtaining solar gain
through opaque elements, however it is defined an optional attribute, since it can be derived
from opaque layers’ conductivity, and interior and exterior convective transfer coefficient in a
pre-processing calculations (Incropera and DeWitt, 2001). This can be augmented into
OpaqueMaterial as optional attribute.
26. netVolumeUnheatedUncooledAdjacentZone; BuildingZone
DIN considers the ventilation heat transfer coefficient of adjacent unheated or uncooled
building zones (DIN 18599-2, eq. 94). As explained in 5.1.1, definition of an adjacent
association might be the solution.
27. hasTransparentInsulation; Opaque
DIN 18599-2 considers the solar gain through opaque elements with transparent insulation
distinguishably (eq. 113), therefore, recognition of opaque elements with transparent
insulation is required. This can be introduced in OpaqueMaterial, however the relation of this
class with other classes should modified before.
28. emissivity; HeatTransferCharacteristics
CityGML Energy ADE defines it for glazing construction (see in the attached DIN data model,
normalIncidenceEmittance; Glazing), while DIN requires it for determination of solar gain
through opaque elements (DIN 18599-2, eq. 111-112). However, it is defined as an optional
attribute in DIN data model, since the default value can be applied. A re-construction of
Construction and its associated classes is needed before.
5.2. CityGML Energy ADE Compatibility with ISO 13790

As it is explained in section4.2, the data model of ISO 13790 and DIN 18599-2, in particular the
Reference Object model, are almost identical. Therefore, the structure analysis of the data model is the
same as section 5.1.1.

OCL’s Application in linking data model of DIN 13790 to Energy ADE
The attributes that can be derived from CityGML Energy ADE are navigated by OCL. The OCL rules for
navigating the matched attributes can be found in the attached data model of ISO 13790. Taking an
example, value derivation of two attributes is explained here:
58
• The value of occupant internal heat flow

context BuildingZoneInternalHeatFlow
inv: occupantInternalHeatFlow=usageZone.occupiedBy.internGains
According to this OCL rule, the value of occupant internal heat flow, which is located in a class in ISO
13790’s data model, is derived from the value of internGains which belongs to a class in Energy ADE
model. These two classes are connected by two associations with end name role of usageZone and
occupiedBy. (see the attached data model of ISO 13790).
• The value of air flow rate

context BuildingZoneVentilationElement
inv: ventilationType= infiltration
implies airFlowRate= buildZone.thermalZone.infiltrationRate
Based on this OCL rule, if ventilation type in BuildingZoneVentilationElement is infiltration, air flow rate
is equal to infiltration rate. Regarding to BuildingZoneVentilationElement class, infiltration is located
after two association relations with end name role of buildZone and ThermalZone, respectively.
The missing attributes in CityGML and Energy ADE are pointed out here, some of which can be
determined in a pre-processing stage are underlined and the ones that can be directly added to the
current version of Energy ADE are bolded. Attributes are followed by hosting classes in data model of
ISO 13790.
1. id; BuildingZone, BuildingZoneBoundary
Like section 5.1.2.
2. hasBasement; Building
It is needed for applying the adjustment factor for heat transfer coefficient (ISO 13790, eq. 18).
ISO 13790 applies this factor where temperature in other side of the boundary is not equal to
outside temperature like basement.
3. hasUnconditionedSpace; Building, isAdjacentToUnconditionedSpace; BuildingZoneBoundary
Geometrical and physical data of adjacent spaces e.g. the supply air temperature (ISO 13790,
section 9.3.3.6), are required for energy assessment of the conditioned zones, which is why an
unconditioned space in building should be recognized.
4. hasSunspace; Building
If a building has a sunspace, solar gain can be calculated differently (ISO 13790, section 11.2.1).
Asdrubali et al. (2012) characterizes a sunspace as a “a closed, southbound volume,
constituted by transparent surfaces, adjacent to a building, which reduces winter energy
demand thanks to the use of solar gains. This attribute can be added to _AbstractBuilding. In
DIN 18599-2, it is generalized as unconditioned space.
5. isAdjacentToSunspace; BuildingZoneBoundary
Transmission coefficient for the boundaries adjacent to sunspace is calculated variously (ISO
13790, section 8.3.2.5). It can be determined for ThermalSurfaceBoundary.
59
6. linearThermalTransmittanceOfThermalBridge; HeatTransferCharacteristics
This is required for transmission heat loss determination, and based on ISO 13790, can be
available for each zone boundary. It is recommended to add it to ThermalBoundarySurface.
7. thermalBridgeLength; HeatTransferCharacteristics
This can be added to ThermalBoundarySurface.
8. type; Wall /Window/ SolarGainCharacteristicsOfTransparentWithSolarProtectionDevice
Window type is required for determination of energy transmittance of normal incidence, in
case it is not available (ISO 13790, Table G.2). Wall type is helpful for determination of
transmission heat loss. All the types can be added to ThermalBoundarySurfaceType.
9. switchedOffTemperature; BuildingZone
As it is explained in section 3.2.2 , it is required for modification of set-point temperature or
energy need during intermittency. It can be clarified in the _Schedule.
10. supplyAirTemp; BuildingZone
It is required for ventilation loss calculation, however is not in _Schedule explicitly defined.
11. timeAveragedInternalHeatFlowPerSquareMeterHotWaterCirculationSystem;
BuildingZoneInternalHeatFlow
Internal heat gain from different type of Domestic Hot Water (DHW) systems is different (ISO
13790, section 10.4 ). It is recommended to add Type in to DHWFacilities.
12. lengthTubeHotWaterCirculationSystem; BuildingZoneInternalHeatFlow
Internal heat gain from water circulation system requires it (ISO 13790, eq. 38). It can be added
to DHWFacilities.
13. …InternalHeatFlow; BuildingZoneInternalHeatFlow
Internal heat gain determination requires data about internal heat flow from different systems,
e.g. cooling, heating, equipment, etc. (ISO 13790, section 10.4). It is recommended to add
Type, and internalHeatFlow in Facilities.
14. internalHeatCapacity; BuildingZoneInteriorComponen
It is required for time constant calculation (ISO 13790, eq. 66), however it is optional attribute,
since can be derived from an alternative methods (see thermalMassType).
15. unoccupiedDayPerMonth; BuildingZone
It is not explicitly defined, and can be clarified in UsageZone class.
16. orientationOfOutsideObstacles; SolarGainCharacteristics
This parameter is needed for determination of shading reduction factor, and can be clarified in
–Opening <<ADEElemnt>>.
17. thermalMassType; BuildingZone
This is an alternative method for determination of internal heat capacity of building zone (ISO
13790, table 12). However, it is optional, since it might be determined based on element
density and type in a pre-processing stage.
18. setPointTemp; BuildingZone
This can be determined for ThermalZone. Nevertheless, this attribute might be determined in a
pre-processing stage based on the building usage type.
60
19. externalResistance; HeatTransferCharacteristics: This is needed for determination of solar

gain through opaque elements, and can be augmented into OpaqueMaterial as optional
attribute.
20. frameAreaFraction; SolarGainCharacteristics
This parameter might be different for windows of a building, therefore might be needed for
each transparent element either with protection or not (ISO 13790, section 11.4.5), and can be
added to Windows class. This attribute can be derived for databases in pre-processing
algorithm, as well.
21. internalHeatFlowFromUncoditionedAdjacentSpace; BuildingZone
According to ISO 13790 eq. 34, time-average heat flow rate from internal heat source in the
adjacent unconditioned space is needed, however it can be calculated providing data of the
adjacent space are available. This is defined as an attribute in the ISO 13790 data model, since
might be found at national level databases. The Energy ADE model does not cover data about
adjacent spaces to the thermal zone which is recommended.
5.3. CityGML Energy ADE Compatibility with VDI 6007

Having explained in section 5.1.1, two aspects of structure coherence is investigated: one-to-one
correspond classes, and homomorphic relation. Figure 5-3 indicates that although all the classes of VDI
model, aside from InteriorComponentAndFurniture, have a one-to-one relation with a class in CityGML
Energy ADE, the structure of the classes in the VDI data model are not preserved in CityGML Energy
ADE. Here the inconsistent relationships are point out, and where possible an improvement is
recommended.
• InteriorComponentAndFurniture
Since area, convective/radiant heat transfer coefficient, and interior surface temperature of both
interior and exterior building zone component is required for thermal response calculation, definition
of a general ThermalZoneComponent which includes both interior and exterior thermal zone
component is recommended.
• Building and BuildingZone vs. _AbstractBuilding and ThermalZone:

Though, BuildingZone and Building in VDI model are in a relationship like _AbstractBuilding and
ThermalZone in Energy ADE, their relationship is not exactly the same. In the VDI model the concept is
composition, as space energy for a BuildingZone cannot exist on its own, and needs the data about
Building, for example data about unconditioned spaces. In fact definition of ThermalZone space needs
knowledge about all building spaces, and a composition hierarchy with _AbstractBuilding is
recommended.
• BuildingZoneComponent vs. Construction and SurfaceComponent
61
Space energy need determination for a BuildingZone requires data about its BuildingZoneComponent.
Even though SurfaceComponent plays this role in Energy ADE model, it cannot fulfill all the space
energy determination requirements. Because firstly it is not including interior component in the
thermal zone, secondly, it does not have all the data about SurfaceComponent, like orientation,
thermal Transmittance, etc. Therefore, integrating the SurfaceComponent to Construction is
recommended.
62
Energy ADE VDI 6007, Reference Object Model
Figure 5-3: Structure coherent investigation between CityGML Energy ADE and VDI 6007's data model
63
• ComponentLayer vs. LayerComponent

Based on VDI 6007, building’s space energy composes of data about component layer (Section 4.3),
and energy calculation for a component layer on its own does not make sense, which is resulted in a
composition relationship, whereas this relationship is not defined in Energy ADE.
• Transparent and Opaque vs. Glazing and OpaqueMaterial

In VDI 6007’s data model categorization of transparent and opaque is defined in a component scale,
but in Energy ADE it is in layer scale. Some of the attributes like solarProtectionCharacteristics, or
emission coefficient should be assigned to a general transparent element and not its layers. In fact,
VDI’s data model has a general ComponentLayer class which includes attributes for both transparent
and opaque component, and the attributes that are needed just for one of them are defined as
optional, e.g. specificHeatCapacity.
• Loads and SupplyAir vs. UsageZone

Integrating all the usage-related data in a class is considerable in Energy ADE; however according to
VDI 6007’s instruction, determination of space energy need of a BuildingZone requires strongly exact
usage data which belong to that zone (Find more explanation in section 5.1.1).

OCL’s Application in linking data model of VDI 6007 to Energy ADE
The attributes defined in VDI 6007’s data model, that are covered by CityGML Energy ADE are
navigated by OCL rules (see attached data model of VDI 6007). For instance:
• Thickness
context ComponentLayer
inv: thickness=layer.layerComponent.thickness
This OCL navigates through two classes which have thickness attribute, one in VDI 6007’s data model
and one in Energy ADE model. The first class is called ComponentLayer, and the other one can be found
after two association relations with end name role of: layer and layerComponent.
• Density
context ComponentLayer
inv: layer.layerComponent.material.OCLIsKindOf(SolidMaterial)
implies density= layer.layerComponent.material.density
According to this OCL, componentLayer class in VDI 6007’s data model contents a density attribute,
whose value is equal to density attributed defined in a class of Energy ADE model. The class in Energy
ADE is linked to componentLayer class with three associations. The last class has a inherit hierarchy
relation to several classes, and OCLIsKindOf choose the class hosting density.
65
CityGML along with its Energy ADE does not meet all the building-related parameters that are required
for space energy demand based on VDI 6007. Following the missing or not properly defined attributes
and their class name(s) in VDI 6007’s data model are listed. The attributes that can be easily added to a
corresponding class in CityGML Energy ADE or derived from other attributes in pre-processing model
are respectively bolded and underlined.
1) hasUnconditionedSpace; Building
This can help distinguishing building zone, where energy balance is established, from parts of
the building that temperature is different (VDI 6007, section 7.1 and 7.2). It can be added to
_AbstractBuilding.
2) id; BuildingZoneComponent, ComponentLayer
Identification of building zone component and component layers is important for tracing
corresponding layer and component’s attribute. This is recommended to add it to
ThermalZone, ThermalBoundarySurface, SurfaceComponent, and LayerComponent.
3) order; BuildingZoneComponent
For thermal response calculation of building component, the layers’ order is crucial (VDI 6007,
eq. 11), can be added it to LayerComponent.
4) airChangeRate; SupplyAir
CityGML Energy ADE has defined an infiltration rate (see ThermalZone), but it is not clarified
for the supply air from ventilation systems. It can be added in the schedule datatype.
“airChangeRate” is not explicitly introduced as an input requirement in VDI, but according to
(Underwood, 2014), thermal resistance representing ventilation (see Figure 3-4) is a function of
air change rate.
5) supplyAirTemp; SupplyAir
It is needed for establishing the thermal model (VDI 6007, P. 23), however ventilationSchedule
in Energy ADE does not explicitly define supply air temperature.
6) convective/radiantFraction; Loads
They are defined in Energy ADE in HeatExchangeType class, but is not associated to
heating/cooling and internal loads explicitly. According to VDI 6007 (p. 22) radiant and
convective fraction of internal loads are needed, which can be added to the Schedule datatype.
7) radiantHeatTransferCoefficient; BuildingZoneComponent
This is needed based on eq. 32-38 of VDI 6007 instruction and can be defined in Construction
class. However, it is an optional attribute in VDI model, since it can be derived from emissivity,
surface temperature (Incropera and DeWitt, 2001).
8) orientation; ExteriorComponent
It is defined in Construction class in CityGML Energy ADE (see ConstructionOrientation class in
the attached data model), but the concept behind Construction class is not clear whether it
includes both interior and exterior components. Construction class needs to be reconstructed.
9) InteriorSurfaceTemp; BuildingZoneComponent
66
It is needed for establishing the thermal model (VDI 6007, p. 24), and can be added to
SurfaceComponent, but this class should be re-constructed so that includes interior
components as well. Moreover, it can be assumed set-point temperature.
10) isHeatedChilled; BuildingZoneComponent
VDI 6007 considers chilled or heated surfaces as a heating cooling load source (VDI 6007, p.
24), which can be added to SurfaceComponent, but this class should include interior
component as well.
11) Interior/exteriorConvectiveHeatTransferCoefficient; BuildingZoneComponent
Convective heat transfer coefficient for interior and exterior side of building component can be
different (Incropera and DeWitt, 2001). In VDI this parameter is needed for thermal resistance
due to radiation and convection heat exchange between surfaces (VDI 6007, p. 24).
Nevertheless, it is not determined in CityGML Energy ADE. This attribute cannot be added
directly in the AbstractMaterial, since this class is layer-based.
12) emissionCoefficient; BuildingZoneComponent
According to equations 32, 33, and 39 in VDI 6007, emission coefficient is required for
calculating equivalent outdoor-air temperature for exterior transparent and opaque
components. But, CityGML Energy ADE defines it only for glazing construction (see
normalIncidenceEmittance; Glazing). Moreover, definition of emittance for each glazing layer
in Energy ADE is also controversial.
13) hourlyThermalTransmittance; TransparentComponent
VDI 6007 applies thermal transmittance for windows with variable shading schedule, e.g.
exhaust-air window (VDI 6007, eq. 120). Since glazing class is layer-scale based, it cannot be
easily augmented to this class.
5.4. General Results

The last three sections indicated that CityGML Energy ADE does not completely meet the requirements
of the three standards. This section evaluates CityGML Energy ADE with an overall view on the energy
standards. The structure miss-matches in the three standards are almost the same, namely they are:
- Adjacent spaces to ThermalZone are not modeled in Energy ADE.

- Thermal zone component, SurfaceComponent, does not clearly covering interior components.
- Distinguishing Construction from ThermalZone makes some confusion in attribute assigning.
- Distinguishing UsageZone and ThermalZone might cause ambiguity in assigning the respective
usage type to the thermal Zone.
Moreover, some required attributes in the standards are not modeled in CityGML Energy ADE. As
explained, some of these attributes are defined as optional, and some can be compensated easily by
adding to the current version of Energy ADE. Figure 5-4 illustrates the total percentages of three type
of missing attributes of DIN 18599-2, ISO 13790, and VDI 6007. Total missing attributes for the three
standards ranges from 43% to almost 60%. However, excluding the optional attributes, approximately
third of pivotal attributes are met, from which more than 75% are realized easily addable to the
current version of Energy ADE. The common miss-matched attributes which can be easily added are id
67
for thermal zone, zone boundary, and components, adjacent to unconditioned spaces for thermal
surface boundaries, and has sunspace, unconditioned space for thermal zone.
Figure 5-4: Missing attributes in three standards
In addition some part of missing attributes can be obtained through pre-processing algorithms.
However, pre-processed data reduces the accuracy of energy assessment, and it is a trade-off between
availability cost and energy assessment accuracy. The pre-processing algorithms need new attributes
which should be defined in Energy ADE. Development of the Energy ADE has taken benefit from
cooperating energy modeling projects so as to integrate practically-needed attributes. Some of them
are, namely, refurbishment year or construction year, and building type i.e. apartment block, multi-
family house, single family house, which are required for extracting the thermal characteristics of the
building. Building footprint area is required based on Energy Atlas Berlin project (Kaden and Kolbe,
2013). Story numbers, floor area, construction year and building volume are needed for obtaining
thermal resistances and heat storage capacities values of building. (Lauster et al., 2014a).
5.5. Summary
This chapter discussed about the compatibility of the three developed data model of the standards
with CityGML data model. The analysis was divided into aspects of structure coherence, and attribute
coverage. Homomorphic mapping was introduced as the basis of structure consistency analysis. For
this reason, the classes defend in the standards’ Reference Object models were compared with the
corresponding classes in Energy ADE. For the three standards, it is shown the structure consistency of
the three standards is limited to corresponding one-to-one classes and their relations are not
preserved in City GML Energy ADE. Construction class, UsageZone class, and ThermalBoundarySurface
cause the main inconsistencies, and a re-construction is recommended. Then OCL rules have been
68
used for expressing the computation algorithms of matched attributes, and later, miss matches are
explained. Finally, structure and attribute miss-matches of Energy ADE, version 0.5.0, is investigated in
an overview, and the general differences between Energy ADE and the energy assessment standards
debated.
69
Chapter 6: Conclusion and Outlook
The study was set out to verify the compatibility of the energy demand module of current version of
CityGML Energy ADE, version 0.5.0, with three thermal energy assessment standards; DIN 18599-2, ISO
13790, and VDI 6007. The specific research objectives were to:
- Clarify CityGML data model and CityGML ADE.

- Evaluate three different building thermal energy standards: DIN 18599-2, ISO 13790, and VDI
6007.
- Develop a formal data model for the building energy standards.
- Elaborate connections between the formal data model of the three standards and the model of
CityGML Energy ADE.
It was expected that UML diagram of DIN 18599-2, ISO 13790, and VDI 6007 have different classes
comparing to Energy ADE, and the hypothesis was that attributes of the energy standards are covered
by Energy ADE. This section will revisit the research objectives above, summarize the findings of this
research work and offer conclusions based on the findings.
The literature study identified CityGML as one of the most preferred data model for representing
virtual 3D cities models, since it maps city object representations into standardized languages i.e. UML
and GML3. It represents objects in a city through one core module and thirteen thematic extension
modules, one of which is Building. Each thematic module represents the semantics of the respective
objects in classes, attributes, and their relations mapping to UML. Building module, its classes,
attributes and their relations could not meet all the application specific parameters, and Application
domain Extension was introduces as a solution. Finally, the developed Energy ADE by (SIG3D, 2014)
was represented. In the second part of literature study, the three building energy assessment
standards were introduced. As a very first step, all three standards identify a building zone where the
energy assessment is applied. DIN 18599-2 and ISO 13790-monthly balance- were realized very similar,
basically establishing a relation between heat sinks and sources. They define different usage phases in
a building zone, which affect its energy need; continuous operation, intermittent operation during
night, and unoccupied operation in holidays or weekends. All the parameters playing a role in heat
sinks and sources values, or being affected in various operation types should be considered as energy
71
demand parameters for heating and cooling spaces. The third energy standard, however, assess energy
need differently. It is based on dynamic hourly method and represents parameters affecting energy
need in an electric circuit with resistances representing thermal resistances of building zone
component, capacities modeling heat storage capability of building component, voltage over capacities
representing temperature, and electric current which is equivalent to heat flux in the zone. It is
explained that resistances and capacities should be determined in a layer scale. Furthermore, the
building decomposition based on DIN 18599-2, ISO 13790, and VDI 6007 were investigated. One side-
achievement of this literature study was a table collecting divers names in standards used for a
specified energy concept. Moreover, the symbols used for different energy concepts are listed in
corresponding tables (Appendices D and E).
Having investigated the parameters required for determination of heat sinks and sources, or elements
of the equivalent electric circuit, and building decomposition concepts in different standards, the third
objective is achieved in the following chapter. Data model of the three standards is mapped to UML
diagrams. In order to have a more applicable data model, it is divided into three domain or Energy
Indicator representing energy concepts of the standard, Object-related linking energy concepts to real
word objects, building and building parts, and Reference-object depicting the object semantic behind
the energy concepts. Contrary to the expectation, this method of data modeling led to having both
energy-concept-orientated and building-component-oriented in the standards’ data model. This
indicator-based modeling paves the way for interdisciplinary projects linking an application-specific
model to geodata model.
Finally, the last objective has been met by compatibility analysis of CityGML Energy ADE, version 0.5.0.
This analysis elaborated that CityGML Energy ADE does currently meet neither required building
structure nor the parameters comprehensively. Therefore, the hypothesis is rejected. However, over
75% of the missing attributes can be easily added to the current structure. Some other parameters can
be compensated in a pre-processing algorithm, although it is a trade-off between energy demand
assessment accuracy and data availability cost. In addition, the application of OCL in linking
corresponding attributes in data models and CityGML Energy ADE, and also deriving an attribute from
other attributes in a data model is shown.
Specific recommendations for compatibility improvement of Energy ADE is explained for each attribute
or structure miss-matches. A further study of data availability considering each Level of Detail of
CityGML is recommended in order to makes the data model more practically implementable. In other
words, the recommended data models in this study is only dependent on the energy assessment
methods explained in the standards, and the feasibility of data availability in practice is not
72
investigated. In fact, availability of some of the attributes like dirt depreciation factor, might be not
costly feasible in urban-scale analyses. Moreover, study of the optimization methods of each standard
might be effective, since they might introduce some other building-related parameters which are
practically more important for energy assessment. For example, Lauster et al. (2014a) presents an
improvement in the consideration of indoor long-wave radiation in VDI 6007 model by considering
temperature dependency feature of long-wave radiation. Although the practical experience in energy
modeling could help for identifying the building-related parameters for each step of energy
assessment, the next step in improving the developed data models could be further detailed study on
identification of the parameters that are not explicitly defined in the studied standards, for instance,
adjustment factor for unconditioned adjacent spaces required (ISO 13790, eq. 34, 40).
Beside the main aim of this thesis research which is compatibility investigation, the developed data
model of the three standards provides the way for further studies on energy programming developers,
as well as compatibility analyses studies for other building information models, namely INSPIRE 8 or
IFC 9.
6.1. Sustainable management-oriented recommendations

The current CityGML Energy ADE supports energy need and supply appraisal, however, for a
comprehensive sustainable-ordinated urban energy management, consideration of life cycle
assessment of the insulation material, and energy suppliers is also interesting. Moreover, CityGML
Energy ADE can include data model of vegetation and habitat so that cover their interaction with urban
energy. Therefore, firstly the effect of vegetation, and habitat on environment’s temperature and
building energy needs can be analyzed, secondly environmentally friendly concepts can be discussed in
urban energy management strategies and policy ratifications.
8
Infrastructure for Spatial Information in the European
Community
9
Industry Foundation Classes
73
References
Asdrubali, F., Cotana, F. and Messineo, A. (2012), “On the Evaluation of Solar Greenhouse Efficiency in
Building Simulation during the Heating Period”, Energies, Vol. 5 No. 12, pp. 1864–1880.
Bernardi, S., Merseguer, J. and Petriu, D.C. (2013), Model-driven dependability assessment of software
systems, Springer, Berlin.
Corrado, V., Mechri, H.E. and Fabrizio, E. (2007), “Building Energy Performance Assessment Through
Simplified Models: Application Of The ISO 13790 Quasi-Steady State Method”.
DIN 18599-2, Energy efficiency of buildings — Calculation of the energy needs, delivered energy and
primary energy for heating, cooling, ventilation, domestic hot water and lighting — Part 2: Energy
needs for heating and cooling of building zones No. 18599-2, 2007-02.
Elfouly, M., Kutzner, T. and Kolbe, T.H. (2015), “General Indicator Modeling for Decision Support based
on 3D city and landscape models using Model Driven Engineering”.
Foucquier, A., Robert, S., Suard, F., Stéphan, L. and Jay, A. (2013), “State of the art in building modelling
and energy performances prediction: A review”, Renewable and Sustainable Energy Reviews,
Vol. 23, pp. 272–288.
Fux, S.F., Ashouri, A., Benz, M.J. and Guzzella, L. (2014), “EKF based self-adaptive thermal model for a
passive house”, Energy and Buildings, Vol. 68, pp. 811–817.
Gröger, G. and Plümer, L. (2012), “CityGML – Interoperable semantic 3D city models”, ISPRS Journal of
Photogrammetry and Remote Sensing, Vol. 71, pp. 12–33.
Incropera, F.P. and DeWitt, D.P. (2001), Fundamentals of heat and mass transfer, 5th ed, Wiley, New
York.
ISO 13790, Energy performance of buildings – Calculation of energy use for space heating and cooling
(ISO 13790:2008), 91.140.10 No. 13790, Berlin.
Kaden, R. and Kolbe, T. (2013), “City-Wide Total Energy Demand Estimation of Buildings using Semantic
3D City Models and Statistical Data”.
Kavgic, M., Mavrogianni, A., Mumovic, D., Summerfield, A., Stevanovic, Z. and Djurovic-Petrovic, M.
(2010), “A review of bottom-up building stock models for energy consumption in the residential
sector”, Building and Environment, Vol. 45 No. 7, pp. 1683–1697.
Keirstead, J., Jennings, M. and Sivakumar, A. (2012), “A review of urban energy system models:
Approaches, challenges and opportunities”, Renewable and Sustainable Energy Reviews, Vol. 16
No. 6, pp. 3847–3866.
Kolbe, T.H. (2009), “Representing and Exchanging 3D City Models with CityGML”.
75
References
Lauster, M., Brüntjen, M.-A., Leppmann, H., Fuchs, M., Teichmann, J., Streblow, R., van Treeck, C. and
Müller, D. (2014a), “Improving a Low Order Building Model for Urban Scale Applications”, in
BauSIM 2014, Aachen, Germany.
Lauster, M., Teichmann, J., Fuchs, M., Streblow, R. and Mueller, D. (2014b), “Low order thermal
network models for dynamic simulations of buildings on city district scale”, Building and
Environment, Vol. 73, pp. 223–231.
McUmber, W.E. and Cheng, B.H. (2001), “A General Framework for Formalizing UML with Formal
Languages”.
Mohammadi, S., Vries, B. de and Schaefer, W. (2013), “A Comprehensive Review of Existing Urban
Energy Models in the Built Environment”, in Geertman, S., Toppen, F. and Stillwell, J. (Eds.),
Planning Support Systems for Sustainable Urban Development, Lecture Notes in Geoinformation
and Cartography, Vol. 195, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 249–265.
Open Geospatial Consortium, OGC City Geography Markup Language (CityGML) Encoding Standard No.
08-007r1, Open Geospatial Consortium, available at: http://www.opengeospatial.org/.
SIG3D (2014), “Energy ADE development Wiki”, available at: http://en.wiki.energy.sig3d.org/.
Strzalka, A., Bogdahn, J., Coors, V. and Eicker, U. (2010), “3D City Modelling for Urban Scale Heating
Energy Demand Forecasting”, ASHRAE HVAC&r, Vol. 17 No. 4, pp. 526–539.
Swan, L.G. and Ugursal, V.I. (2009), “Modeling of end-use energy consumption in the residential sector:
A review of modeling techniques”, Renewable and Sustainable Energy Reviews, Vol. 13 No. 8, pp.
1819–1835.
Underwood, C.P. (2014), “An improved lumped parameter method for building thermal modelling”,
Energy and Buildings, Vol. 79, pp. 191–201.
VDI 6007, Wärmeschutz und Energie-Einsparung in Gebäuden: Vornorm, Deutsche Norm / Vornorm,
DIN V 4108-6 No. 6007, Vornorm, Beuth, Berlin.
Zhao, H.-x. and Magoulès, F. (2012), “A review on the prediction of building energy consumption”,
Renewable and Sustainable Energy Reviews, Vol. 16 No. 6, pp. 3586–3592.
76
A. UML Class Diagram
The data models of the standards in this thesis are representing by UML class diagrams. UML class
diagram explained in this thesis does not provide complete and very deep technical definitions. It is
just the basic knowledge for following the thesis, and is extracted from distilled book, and UML
organization 1.
Class Diagram:
A class diagram describes the types of objects in the system and various kinds of static relationships
that exist among them. In other words, class diagram is a static diagram describing system structure
through classes, properties, operations, their relation, and constraints to the way that objects are
connected. Each of these concepts is explained here.
Class:
A class is a classifier which describes a set of objects that share the same semantics, properties,
operation, and constraints.
NameOfClass
attribute (s): type
Operation(s): type
Figure a: Class representation in UML
Properties:
Properties are a single concept, showing structural features, but are depicted either as attributes or
associations.
Attributes:
Attribute notation describes a property as a line of text within the class box. Its full syntax is:
Visibility name: type multiplicity= default {property-string}
- Only name is necessary for defining an attribute.
1
http://www.uml-diagrams.org/
77
Appendix A: UML Class Diagram
- Visibility is shown with a marker which indicates whether the attribute is public (+) or private (-
)
- Type indicates a restriction on what kind of object may be placed.
Operation:
It is the action that a class knows to carry out. In other words, the signature of a Method of a Class;
consists of the Operation Name, Visibility, Parameter list, Return Type, and Property-string.
Abstract Class:
It is a class that cannot be directly instantiated. Instead, an instance of a subclass is instantiated.
Data type:
It is a classifier - similar to a class - whose instances are identified only by their value. Used to
represents value type. Like gender, date, time, address. The instances of a data type with same value
are considered as an equal instance. For example if data type has temperature values, e.g. outside and
set-point temperature, the values of 20 and 10 respectively is an instance. All other instances with
these values are considered as the first instance. For the structured data type, repetition of the order,
and values of the data is meant as equal instances.
Enumeration:
A set of constant values for a new data type.
Associations:
The other way to notate a property is an association. An association is a structural relationship that
species that the objects of one thing are connected with the objects of another. It is depicted by a solid
line between two classes. Each end is called a Role, and may have a role name, Multiplicity, and may be
Navigable.
Multiplicity or cardinality:
The multiplicity of a property is an indication of how many objects may fill the property. In other
words, It species how many objects may be connected across an instance of an association which is
written as a range of values (like 1..*).
- Mandatory - A required multiplicity, the lower bound is at least one, usually 1..1 or 1 - Optional - The
lower bound is at most zero, usually, 0..1 - Many - A multiplicity with no upper limit, either 0..* or *
Figure b: Association representation in UML
78
Appendix A: UML Class Diagram
Aggregation:
1. A special type of association used to represent a stronger relationship between two classes than a
regular association; typically read as "owns a", as in, "Class A owns a Class B". A hierarchy of classes
where the child object may or may not continue to exist if the parent object is destroyed; see
'composition'. 2. An aggregation is a structural relationship that species that one class represents a
large thing which constitute of smaller things and represents "has-a" relationship. To render
aggregation in a diagram, draw a line from the parent class to the child class with a diamond shape
near the parent class.
Composition:
A specific type of relationship describing how one Object is composed of another Object; a form of
Aggregation where the child object is destroyed if the parent object is destroyed. To depict a
composition relationship in a UML diagram, use a directional line connecting the two classes, with a
filled diamond shape adjacent to the container class and the directional arrow to the contained class.
Figure c: Aggregation (left), Composition (right). Representation in UML
Inheritance/Generalization:
It refers to a type of relationship wherein one associated class is a child of another by virtue of
assuming the same functionalities of the parent class. In other words, the child class is a
specific type of the parent class. To depict inheritance in a UML diagram, a solid line from the
child class to the parent class is drawn using an unfilled arrowhead.
Figure d: Generalization representation in UML
79
B. OCL
OCL is a specification language for object constraints, which is part of the official OMG standard for
UML. All detailed information can be found in the OMG specification.
Constraint:
A constraint is a packageable element which represents some condition, restriction or assertion related
to some element (that owns the constraint) or several elements. A constraint is formulated on the level
of classes, but its semantics is applied on the level of objects.
OCL:
A fundamental principle of OCL is that a Constraint is interpreted on a “snapshot” of an object
configuration. So OCL does not contain any “commands” to change the system state, but just
operations to observe the system state”
OCL formulation:
OCL text can be added in various ways to UML specifications, enhancing various diagrams. For class
diagrams, there are three possibilities to integrate OCL object constraints into the diagram:
- invariants
- Preconditions
- Postconditions
Invariant:
Invariants often represent rules that should hold for the real-life objects after which the software
objects are modeled. Invariant syntax is:
context <class name> inv: <Boolean OCL expression>
For example,
context Meeting inv: self.end > self.start
This constraint says that for each object of class Meeting the value of the end attribute has to be
greater than the value of the start attribute. The keyword “self” is used to refer to the actual object
reference corresponding to the context of the constraint. The keyword “self” can be even omitted for
81
Appendix B: OCL
shortness (as long as the referred object of the attributes is unique), so a shorter but equivalent
version of the above constraint is:
context Meeting inv: end > start
Navigation Expression:
Association ends (role names) are be used to „navigate“ from one object in the model to another
object.
Collection:
A navigation starting from a single object can result in a collection, or operations on collections may
result in new collections:
collection1->union(collection2)
Variable:
In OCL expressions, variables (local identifiers) can be used to refer to parameter values of an
operation or a locally introduced variable (see below).
Context Meeting :: shift (d: Integer) pre: d > 0
The “variable” refers to a value that is fixed throughout the interpretation of the expression (so it is
quite different from a variable in an imperative programming language). The actual value is
determined for operation parameters from the invocation and for locally introduced variables from
their declaration.
Result:
It is a keyword which refers to the result of the operation.
IsKindOf:
It is a keyword which is used when classes conform to super-classes. It is used in particular to pass the
reference of the meta type when invoking the operations.
ForAll:
Many times a constraint is needed on all elements of a collection. The forAll operation in OCL allows
specifying a Boolean expression, which must hold for all objects in a collection.
Implies:
It is a Boolean operation.
82
C. Equivalent Names in Different Energy Standards
Table A: Equivalent names in DIN 18599-2, ISO 13790, VDI 6007, and Energy ADE.
Name in Energy ADE Name in VDI 6007 Name in ISO 13790 Name in DIN 18599-2
uValue Thermal transmittance Thermal transmittance Thermal transmittance
--- (thermal response) Heat transfer Heat sink
--- (thermal response) Heat gain Heat source
--- --- Transmission transfer Transmission heat sink, Q
--- --- Ventilation transfer Ventilation heat sink
--- --- Solar gain Radiation heat
source/sink
--- --- Heat balance ratio Ratio of heat sources to
heat sinks
--- --- Unoccupied mode (for Holiday (for switched-off
switched-off mode) mode)
--- --- Intermittency (for set- Reduced heating at
back mode)) night/ weekend
--- --- Unconditioned Unheated or uncooled
--- --- Building’s component Building’s element
--- --- Corrected internal heat Effective heat capacity
capacity
--- --- Solar energy Energy transmittance for
transmittance normal perpendicular incidence
incidence
--- --- Frame area fraction Frame factor
--- --- Air volume flow Air change rate
Effective thermal --- Internal heat capacity Effective heat capacity
capacity
83
D. Required Input Data for DIN 18599-2
No. Attribute Unit Purposes Sources

1_1 Boundary Areas
- Area of an opaque element which
forms part of the boundary between
the building zone and the external
environment, A - Coefficient of heat transfer to
*Area of opaque elements with external environment
transparent insulation in a specific - Radiation heat sources and sinks,
orientation, A solar heat gains via opaque building
**If there is an unheated sunspace: elements
Area of each external surface of the *Radiation heat sources and sinks,
sunspace with a specific orientation, solar heat gains via opaque building
Aue elements with transparent thermal
- Remark: The dimensions of insulation
windows and doors shall be the clear **Heat flow into the unheated or
internal unfinished dimensions of uncooled sunspace (solar radiation
1_1_1 their openings m^2 entering the sunspace)
- Area of a transparent element

Geometric data
which forms part of the boundary

between the building zone and the
external environment, A - Coefficient of heat transfer to
- Remark: The dimensions of external environment
windows and doors shall be the clear - Radiation heat sources and sinks,
internal unfinished dimensions of entering through transparent
1_1_2 their openings m^2 surfaces
Area of a building element between

the building zones (Inner walls, and
intermediary floors), A
* If there is a unheated zone; area of
a building element between the - Transmission heat transfer
considered building zone and the coefficient (through adjacent zone)
unheated or uncooled space, A *Transmission heat transfer
** If there is a unheated sunspace: coefficient (through unheated
area of the element of the partition zones)
separating the building zone being ** Radiation heat sources and sinks,
considered from the unheated entering through transparent
1_1_3 sunspace, Aiu m^2 elements of the partitions
1_2 Space Area
85
Appendix D: Required Input Data for DIN 18599-2
Proportion of indirectly heated area

(Indirectly heated areas are separate
spaces which are heated
indirectly via the heated area, but in
which the temperature is allowed to DIN V 18599-10
remain below the internal set-point Reference internal temperature in (Default values
temperature) within the total area of the partial heating mode (correction for residential
1_2_1 the building zone, atb m^2 factor for partial heating ) building)
- Window airing heat transfer

coefficient (Usage-dependent
minimum air exchange with
external air)
- Internal heat sources due to
persons, machinery, equipment and
lighting
- Reference internal temperature in
Reference area of the building zone, the partial heating mode (correction
1_2_2 AB m^2 factor for partial heating )
- Infiltration and window airing
heat transfer coefficient
- Window airing heat transfer
coefficient
- Mechanical ventilation heat
1_3_1 Net volume of space, v m^3 transfer coefficient
- Ventilation heat transfer

net volume of the unheated or coefficient of adjacent unheated or
1_3_2 uncooled building zone, Vu m^3 uncooled building zones
Frame factor, corresponding to the

ratio of the transparent area to the
total area of the element, FF
*If there is a sunspace, so there is a
internal glazing: Frame factor
accounting for the proportion of
frame on the internal glazing, FF,iu
**If there is a sunspace, Frame factor
accounting for the proportion of
frame on the external glazing - Radiation heat sources and sinks, (If data not
(corresponding to the ratio of the entering through transparent available)
transparent area to the total area), surfaces Default value=
FF,ue */**Radiation heat sources and 0.7
***For opaque elements with sinks, entering through transparent * 0.7
1_4 transparent insulation — elements of the partitions **0.9
Form factor for the relationship Radiation heat sources and sinks,
between the building element and solar heat gains via opaque building Default Value=
1_5 the sky, Ff — elements 1(OR)0.5
Radiation heat sources and sinks,
entering through transparent
1_6 Orientation — surfaces
Radiation heat sources and sinks
(total area of element in a specific
1_7 Inclination — orientation)
- Transmission heat transfer

parameters
coefficient Opaque:DIN EN
Physical
- Radiation heat sources and sinks, ISO 6946

solar heat gains via opaque building Transparent: DIN
2_1 Thermal transmittance, U W/(m^2 · K) elements V 4108-4
86
Coefficient of heat transfer to

Length of two-dimensional thermal external environment (using linear
2_2a bridge, l m thermal transmittance)
DIN EN ISO
10211-1
Coefficient of heat transfer to Boundary
Linear thermal transmittance external environment (using linear condition: DIN
2_2a (thermal bridge loss coefficient), Ψj W/(m · K) thermal transmittance) 4108
Default value:
Coefficient of heat transfer to 0.10/ 0.15/0.5
Standard allowance for thermal external environment (standard (for different
2_2b bridge, ΔUWB W/(m^2 · K) allowance) conditions)
*If there is sunspace: Radiation heat sources and sinks,
(radiation)Transmittance of the entering through transparent
2_3 external glazing, τeu,e — elements of the partitions Table 5
Total energy transmittance of the
glazing (without solar protection), g⊥ Default values=
*If the glazing façade is with solar Radiation heat sources and sinks, Table 5
protection device: Total energy entering through transparent Or (DIN EN 410)
transmittance taking into surfaces
consideration the solar protection (effective total energy *Table 5
device, gtot transmittance, g eff) DIN EN 13363-1
**If there is transparent thermal **Radiation heat sources and sinks, DIN EN 13363-2
insulation: Total energy transmittance solar heat gains via opaque building
of the transparent thermal insulation, elements with transparent thermal ** Default
2_4 gTI — insulation Value= 0.35
Default value=
0.04
Radiation heat sources and sinks, DIN EN ISO 6946
solar heat gains via opaque building DIN EN ISO
2_5 External surface resistance, Rse (K·m^2)/W elements 10077-1
DIN EN ISO
Mean daily heat flow through the Heat flows through the ground 13370:1998-12
2_6a ground in the respective month, Φm W (Transmission heat through ground) , Annex B
DIN EN ISO
13370/ No data
on ground
characteristics:
Ground
Steady-state thermal coupling Coefficient for heat transfer conductivity= 2
2_6b coefficient, L s W/(m·K) through the ground W/(m · K)
Default value=
Ventilation heat transfer coefficient 0.34
Specific heat capacity of air * density Wh/(m^3. (infiltration, window airing, and (DIN EN ISO
2_7 of air (Multiply) K) mechanical) 13790)
- DIN ISO 13786
- Stored heat between days of - DIN V 18599-10
Effective heat capacity (thermal kJ/K, (or) usage and non-usage (simplified
2_8 mass), C eff Wh/K - (Thermal) time constant equation)
solar heat gains via opaque building
Emissivity for thermal radiation of the elements ( external radiative heat Default value=
external surface W/(m^2 · K) transfer coefficient) 0.9
87
- Radiation heat sources and sinks,

surfaces
( effective total energy
transmittance, g eff)
- Radiation heat sources and sinks,
solar heat gains via opaque building
Correction factor due to oblique elements with transparent thermal Default value=
2_9 incidence of radiation, Fw — insulation 0.9/ 1
surfaces
(effective total energy
2_10 Dirt depreciation factor, FV — transmittance, g eff) DIN V 18599-10
Partial shading correction factor, Ff

*Partial shading correction factor for
the horizon (e.g. by other buildings,
topography), Fh Radiation heat sources and sinks,
**Partial shading correction factor for entering through transparent Table A.3
overhangs (e.g. canopies, balconies surfaces *Table A.1
2_11 etc.), Fo — (shading correction factor, FS) **Table A.2
Solar radiation absorption coefficient solar heat gains via opaque building
2_12 of the element, α — elements Table 6
Default value=
Infiltration and window airing heat 0.07
transfer coefficient (through daily (DIN EN ISO
2_13 Wind shielding coefficient, ewind — mean infiltration air change rate) 13790)
Table 4, DIN
18599-2
*Residential
Building: DIN V
18599-10 / DIN V
Air change rate at a pressure 18599-6
difference of 50 Pa, n50 ** usage-
* If there is mechanical ventilation: dependent
Air change rate due to supply air, n Ventilation heat transfer coefficient, minimum
** If ventilation systems is designed infiltration, and window airing volume flow: DIN
to meet entire ventilation (through daily mean infiltration air V 18599-10
requirements: minimum volume change rate) minimum
flow required by the system as well as *Ventilation heat transfer volume flow
the minimum external air change coefficient, mechanical required by the
necessitated by the type of (through mean daily air change system:
2_14 usage shall be maintained. h–1 rate due to mechanical ventilation) DIN_Annex E
surfaces
Non, fixed, ( effective total energy
2_15 Type of solar protection device Movable transmittance, g eff)
Parameter for assessing the surfaces
activation of movable solar (effective total energy Table A.4
2_16 protection devices, a — transmittance, g eff) Table A.5
88
- Reference internal temp. for

reduced heating at night, and
Permitted internal set-back temp. for holiday, and weekend
reduced operation in heating mode, - Stored heat between days of
3_1 Δϑi,NA C˚ usage and non-usage DIN V 18599-10
Mean internal set-point temperature - Stored heat between days of
3_2 for heating mode, ϑi,h,soll C˚ usage and non-usage DIN V 18599-10
- Transmission through unheated
or uncooled spaces to the external
environment (mean temperature of
Temperature correction factor from, the unheated or uncooled building DIN V 18599
3_3 Fx — zone) Table 3
heat flow (from heat sources) into the - temperature in an unheated or

3_4 unheated or uncooled building zone uncooled building zone
Maximum heating power in building - Partial heating (spatially reduced DIN V 18599-
3_5 zone, heating operation) Annex B
Minimum supply air temperature of

the mechanical ventilation system,
Operation and Occupancy parameters
ϑV,mech Depending on
* For ventilation systems with the ventilation
temperature-controlled air handling system:
** For systems without cooling (Thermal) time constant *DIN V 18599-7
functions (temperature-weighted heat **DIN V 18599-3
***For ventilation systems of transfer coefficient of mechanical ***DIN V 18599-
3_6 residential buildings C˚ ventilation) 6
- Correction factor for reduced
night-time heating operation
3_7 Daily reduced heating time, tNA h reduced heating at night DIN V 18599-10
in the absence of
specific data,
Average number of days of non- Stored heat between days of usage αwe = (1 –
3_8 usage per week, αwe Day and non-usage dnutz/365) × 7
Ventilation heat transfer coefficient,

window airing (mean daily air
3_9 Daily usage time, tnutz h change rate due to window airing) DIN V 18599-10
Specific mean daily dissipation of
heat by persons, machinery,
equipment and Internal heat sources due to
lighting in residential buildings in persons, machinery, equipment and
3_10 relation to the reference area, q I lighting DIN V 18599-10
uncontrolled heat/ cold input into - DIN V 18599-8

the zone due to - DIN V 18599-5
- the domestic hot water system &18599-7
(heat) - DIN V 18599-6
- heating system (heat) Heat sources/sinks due to heating, &18599-7
- mechanical ventilation (heat & cold) cooling, domestic hot water supply - DIN V 18599-6
3_11 - cooling system (heat & cold) and ventilation & 18599-7
Air flow rate of an adjacent area for
3_12 design conditions
89
Temp. of an adjacent area for design

conditions
* design external temp. Reference internal temperature in */**DIN V
** internal temperature in an the partial heating mode (correction 18599-10
adjacent zone factor for partial heating, Maximum ***calculated
***temperature in an unheated heating/cooling power in the assuming ϑe,min
3_13 adjacent zone C˚ building zone, Q h,max ) and Φu=0
Temperature of the material or goods Internal heat sources/ sinks due to
3_14 leaving the building zone C˚ movement of materials
The mean mass of material Internal heat sources/ sinks due to
3_15 transported in a 24 h period, m movement of materials
Heat sources due to artificial
3_16 Lighting heat gain coefficient, μL lighting (air-handling luminaires) Table 7
Mean daily electrical energy input for Heat sources due to artificial
3_17 artificial lighting, Q i,L,elektr lighting (air-handling luminaires) DIN V 18599-4
Factor taking into account an increase Ventilation heat transfer coefficient,
or decrease in infiltration due to infiltration (through daily mean
3_18 mechanical ventilation, fV,mech — infiltration air change rate) DIN 18599-2

reduced heating at night/ holiday,
or partial use
Monthly average external - Heat flows due to ventilation heat
4_1 temperature, Ve C˚ sources
Weather and site data

Mean solar irradiance for the entire entering through transparent
4_2 month, Is W/m^2 surfaces DIN V 18599-10
Global solar irradiance for the entering through transparent
4_3 orientation of the element surface, Is W/m^2 surfaces DIN V 18599-10
Mean difference between the Radiation heat sources and sinks,
temperature of the ambient air and solar heat gains via opaque building Default value=
4_4 the apparent sky temperature K? elements 10K
Ventilation heat transfer coefficient,
window airing (Usage-dependent
Minimum external air volume flow minimum air exchange with
4_5 per unit, VA m^3/(hm^2) external air) DIN V 18599-10
90
E. Required Input Data for VDI 6007
No. Attribute Unit Purposes Sources

- Thermal resistance per unit area of
the wall layer
- Heat capacity per unit area of the
1_1 Thickness of the wall layers, s m wall layer
The equivalent resistances and

capacities of the exterior walls (R1; EW,
C1; EW)
_For calculation of the equivalent R and
C of the whole wall, the sequence of
the wall layers is important, because a
matrix which is direction-invariant is
1_2 Position of layer (index) used.
1_3 Boundary Area
- The equivalent resistances and

capacities of the exterior walls (R1; EW,
C1; EW)
- Total thermal resistance the
combined exterior building
Geometric data
components , R tot; EW
- `or” surfaces, ϑE;eq;Weight
- The part of the radiant heat sources/
sinks effecting the exterior walls, Q˙I IL;
rad; EW , also the radiant contribution
Area of exterior walls, envelopes, in the heating and cooling loads, Anteil
(opaque), A EW Q˙; HC;rad
*If considering the element direction and *The radiant heat source/sinks located
1_3_1 inclination, A v m^2 outside the room
- Total thermal resistance the

combined exterior building
components , R tot; EW (thermal
resistance of the exterior window)
- Equivalent outdoor temperature
weighted over all “exterior” surfaces,
ϑE;eq;Weight
*The radiant heat source/sinks located
outside the room
* outdoor temperature weighted over
Area of exterior windows (transparent), all “exterior” surfaces, ϑA;eq;gew, also
A EF thermal resistance for the combined
*If considering the element direction and exterior building components(Wall,
1_3_2 inclination, A v m^2 roof, window), Rtotal;EW
91
Appendix E: Required Input Data for VDI 6007
- The equivalent resistances and

capacities of the interior walls (R1; IW,
C1; IW)
- The part of the radiant heat sources/
sinks effecting the interior walls, Q˙I IL;
1_3_3 Area of interior walls/ceiling/floor, A IW m^2 rad; IW
- The radiant heat source/sinks effects

on the exterior or interior walls,
- the radiant contribution in the
1_4 Space area, A raum m^2 heating and cooling loads
- To find the buildings components in

the same direction and inclination
- Average equivalent outdoor
1_5 Horizontal elevation (inclination?), ϒ H temperature, ϑ A;eq
- To find the buildings components in

the same direction and inclination for
calculating the heat sources/sinks
located outside the
room and becoming effective inside the
room, QIL;rad;E
- Average equivalent outdoor
Inclination of the exterior surface with temperature, ϑ A;eq
1_6 respect to the horizontal, ϒ F - for 1_2_1 & 1_2_2 *
Thermal transmittance of exterior

surfaces and surfaces of a room adjacent
to a room with different temperature, Uv - Equivalent outdoor temperature
*Thermal transmittance of the window weighted over all “exterior” surfaces,
for the hour tx, U AFv (tx) ϑE;eq;Weight
(Note: Transparent components have */**Heating and cooling loads
variable thermal transmittance */**Room air temperature
Physical parameters
depending on its mode, e.g with/without **the thermal resistance of the exterior
exhaust-air or shutter.) window, R1;Afv
**Basic value of the thermal W/( **thermal resistance for the combined
transmittance of the window, U AFv m^2 exterior building components(Wall,
2_1 (Basis) · K) roof, window), Rtotal;EW
(W ⋅ Thermal resistance per unit area of the
2_2 Thermal conductivity of the wall layer, λ m)/K wall layer, R
J/
Thermal storage capacity of the wall m^3 Heat capacity per unit area of the wall
2_3 layer, c ⋅ ρ ⋅K layer, C
Thermal resistance taking into account

supply air, Rair
(infiltration, natural ventilation through
windows and air-conditioning and
2_4 ventilating installations) Active quantities of the 2-c model
92
Default
- Average equivalent outdoor values;
temperature, ϑ E;eq for R α;rad;
- Thermal resistance for radiation EW/IW= 5
between the wall surfaces, Rα;rad, and for ϑ E;eq,
W/( between exterior and interior surfaces, if
Radiant/convective heat transfer m^2. R α;rad; EW/IW, or convection between conditions
2_5 coefficient, α con/rad, αA K) wall surfaces and interior air, Rα;con met= 5
Absorption coefficient (short-wave) of

the exterior surface, aF
Note: According to eq. 39, transparent - Equivalent outdoor-air temperature
2_6 surfaces do not need this parameter. — owing to short-wave radiation
The equivalent resistances and
Characteristic values of solar protection capacities of windows with solar
2_7 (for glazing with solar protection) — protection, Rwindows, Rα
Emission coefficient (short-wave) of the Average equivalent outdoor
2_8 exterior surface, ε F temperature, ϑ A;eq
Default
values=
The equivalent resistances and For Build.
capacities of the building component
Day numbers that the building component/room, R1; IW & EW, C1; IW = 2 or 7,
component/room can store the heating & EW (through angular frequency For Room=
2_9 energy , TBT/TRA Days calculation) 5
Reactive/ Active quantities of the 2-c

3_1 Indoor (room) air temp., ϑI;air C˚ model
-Surface temp. of interior wall, ϑIW
- Surface temp. of interior side of
3_2 exterior wall, ϑEW C˚ Reactive quantities of the 2-c model
Supply air temperature for infiltration,
natural infiltration, air conditioning,
and ventilating installations (weighted by
Operation and Occupancy parameters
volume flow), ϑair

3_3 * it is equivalent with internal temp. C˚ Active quantities of the 2-c model
Heating and cooling loads provided by

an installation every hour, QHK;ges
- Convective contribution to total
heating and cooling loads
- radiant contribution of interior
surfaces
- Contribution of any heated or chilled
surface of or several interior building DIN V
components 18599 – 10
The heating and cooling installations - radiant contribution of exterior Lauster
3_4 schedule/ profile/characteristics surfaces (2013)
- Heating and cooling loads provided

Radiant/convective fraction of by an installation every hour
heating/cooling or internal loads — - Internal loads
Radiant heat sources/sinks located in
the room (such as lighting, etc.), SIA 2024
effective on the exterior and interior Lauster
3_5 Occupancy(daily schedule) walls, QIL; rad; I; IW/EW (2013)
93
Radiant heat sources/sinks located in DIN V

the room (such as lighting, etc.), 18599 – 10
3_6 Occupancy(max value) walls, QIL; rad; I; IW/EW (2013)
Radiant heat sources/sinks located in DIN V
the room (such as lighting, etc.), 18599 – 10
3_7 Lighting walls, QIL; rad; I; IW/EW (2013)
Outdoor air temp

Weather and site data
Equivalent outdoor temperature due to Average equivalent outdoor

4_1 long/short-wave radiation exchange C˚ temperature, ϑ A;eq TRY
4_2_1&2. Radiant heat transfer

coefficient,
4_2_1&2. Average equivalent outdoor
temperature, ϑ A;eq
4_2_1. radiant heat sources/sinks
4_2_1. Radiation from the environment, (W. located outside the room and
E Erd m^2) becoming effective inside the room,
4_2 4_2_1. Atmospheric radiation, E Atm /K QIL;rad;E TRY
94
F. Complete Data Model of DIN 18599-2
95
Appendix E: Complete Data Model of ISO 13790
G. Complete Data Model of ISO 13790
96
Appendix F: Complete Data Model of VDI 6007
H. Complete Data Model of VDI 6007
97
I. Attached CD
The complete data model of the three standards is presented in the attached compact disk (CD). This
CD also contains OCL rules for linking attributes in data models to Energy ADE.
98

Maryam Zirak Master&#39;s Thesis May2015

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Maryam Zirak Master&#39;s Thesis May2015

Hochgeladen von

Copyright:

Verfügbare Formate

Department of Civil, Geo and Environmental Engineering

A Model-driven Approach for Linking Building Thermal Energy

Author: Maryam Zirak

Maryam Zirak Place, Date

ADE Application Domain Extension

- Clarifying CityGML data model and CityGML ADE

3.1. Clarification of CityGML and Energy ADE

Figure 3-1: Building module in CityGML. Source: Open Geospatial Consortium

- “the extension is formally specified;

3.2. Critical evaluation of three building thermal energy models

𝑄𝑄ℎ, 𝑏𝑏 = 𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄 − ƞ𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄 − ∆𝑄𝑄 𝑐𝑐, 𝑏𝑏 (Equation 3-1)

Total heat transfer

Total heat gains

Gain utilization factor

3.2.3. ISO 13790- monthly method vs. DIN 18599-2

Heat gain (source) and transfer (sink)

Escaping heat during unoccupied time

The set-point temperature adjustments for the unoccupied or intermittency conditions

Transmission heat transfer coefficient

Ventilation transmission heat coefficient

Internal heat source

Solar Heat Gain

Asymmetry elements Symmetry elements

- Building physics-associated parameters; i.e. resistances, and capacities

4.1. DIN 18599-2 Data Model

Figure 4-1: Energy Indicator model of DIN 18599-2

multiplicity is [3..*]. The reason of defining multiplicity of [0..2] for

HeatTransferCharacteristics and SolarGainCharacteristics are a set of thematically different properties

Figure 4-2: Object-related model of DIN 18599-2

Figure 4-3: Reference Object model of DIN 18599-2

4.1.1. OCL’s Application in DIN 18599-2’s Data Model

I. The value of transmission loss of a building zone

II. The value of transmission loss of a zone boundary

III. The value of transmission coefficient of a zone boundary

4.2. ISO 13790 Data Model

Figure 4-4: Energy Indicator of ISO 13790

Having a look at the attached complete data model of ISO 13790,

Figure 4-5: Object-related model of ISO 13790

Figure 4-6: Reference Object model of ISO 13790

4.3. VDI 6007 Data Model

Figure 4-7: Energy Indicator model of VDI 6007.

Figure 4-8: Object-related model of VDI 6007

Figure 4-9: Reference Object model of VDI 6007

The association relation between BuildingZoneComponent and BuildingComponentThermalResistance

4.3.1. OCL’s Application in VDI 6007’s Data Model

II. The value of heat capacity of one interior component

inv: heatCapacityOfInteriorComponent->"combinedRule12"forAll (l|

III. The value of heat capacity of one layer

Based on OCL algorithm I, the value of HeatCapacityOfInteriorComponent is a so-called

5.1. CityGML Energy ADE Compatibility with DIN 18599-2

• BuildingZone vs. ThermalZone:

• Building, BuildingZone, and BuildingZoneBoundary vs. _AbstractBuilding, ThermalZone, and

• BuildingZoneVentilationSinkSource, and BuildingZoneInternalHeatSinkSource vs. UsageZone

• BuildingZoneBoundary vs. Construction

• OpaqueMaterial and Glazing

properties. Thus, establishing an association between _Opening <<ADEElement>> and

CityGML Energy ADE DIN 18599-2, Reference Object

5.1.2. Attribute Analysis

Based on this OCL, the value of thermalTransmittance, which is located in HeatTransferCharacteristics,

1. id; BuildingZone, BuildingZoneBoundary

6. type; Wall/ Roof/Window/Floor/

13. obstacleType, SolarGainCharacteristics

5.2. CityGML Energy ADE Compatibility with ISO 13790

5.2.2. Attribute Analysis

Maryam Zirak Master's Thesis May2015

Maryam Zirak Master's Thesis May2015