eeembedded d5.1 interoperability and ontology...

This project has received funding from the European Union Seventh Framework Programme

under grant agreement n° 609349.

OPTIMISED DESIGN METHODOLOGIES FOR ENERGY-EFFICIENT

BUILDINGS INTEGRATED IN THE NEIGHBOURHOOD ENERGY SYSTEMS

eeEmbedded – D5.1

Interoperability and ontology framework

Author:

Mathias Kadolsky

Co-Authors:

Romy Guruz, Pit Stenzel, Arne Ton, Klaus Linhard,

Amrita Sukumar, Tuomas Laine, Peter Katranuschkov

Due date: 01.10.2015

Issue date: 26.01.2016

Nature: Other

Coordinator: R. J. Scherer, Institute for Construction Informatics, Technische Universität Dresden, Germany

5.1 Interoperability and ontology framework

Version 1.0

/52

© eeEmbedded Consortium www.eeEmbedded.eu

Start date of project: 01.10.2013 Duration: 48 months

Organisation name of lead contractor for this deliverable:

Technische Universität Dresden, Institute of construction informatics (CIB)

History

Version Description Lead Author Date

0.1 Initial document, Glossary structure Mathias Kadolsky (CIB) 16.03.2015

0.2 Input ISES Ontology, Input eeE Ontology framework

Mathias Kadolsky (CIB) 24.04.2015

0.3 Input Interoperability framework Mathias Kadolsky (CIB) 16.06.2015

0.4 Input Ontology Issues Romy Guruz (CIB) 27.09.2015

0.5 Restructuring document Romy Guruz, Mathias Kadolsky (CIB)

02.10.2015

0.6 Final Input/ pre-final version Mathias Kadolsky (CIB) 12.01.2016

1.0 Final Version CIB 27.01.2016

Copyright

This report is © eeEmbedded Consortium 2016. Its duplication is restricted to the personal use

within the consortium, the funding agency and the project reviewers. Its duplication is allowed

in its integral form only for anyone's personal use for the purposes of research or education.

Citation

Kadolsky M. (2016); eeEmbedded Deliverable 5.1: Interoperability and ontology framework © eeEmbedded Consortium, Brussels. Acknowledgements

The work presented in this document has been conducted in the context of the seventh

framework programme of the European community project eeEmbedded (n° 609349).

eeEmbedded is a 48 month project that started in October 2013 and is funded by the

European Commission as well as by the industrial partners. Their support is gratefully

appreciated. The partners in the project are Technische Universität Dresden (Germany),

Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung E.V (Germany),

NEMETSCHEK Slovensko, S.R.O. (Slovakia), Data Design System ASA (Norway), RIB

Information Technologies AG (Germany), Jotne EPM Technology AS (Norway), Granlund OY

(Finland), SOFISTIK HELLAS AE (Greece), Institute for applied Building Informatics IABI

(Germany), FR. SAUTER AG (Switzerland), , Obermeyer Planen + Beraten (Germany), Centro

de Estudios Materiales y Control de Obras S.A. (Spain), STRABAG AG (Austria) and Koninklijke

BAM Group NV (The Netherlands). This report owes to a collaborative effort of the above

organizations.


Version 1.0

/52


Project of SEVENTH FRAMEWORK PROGRAMME OF THE EUROPEAN COMMUNITY

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)


Version 1.0

/52


Abbreviations

BACS Building Automation and Control Systems

BIM Building Information Modelling

CFD Computational Fluid Dynamics

DACS District Automation and Control Systems

DV Decision Values

eeBIM Energy-enhanced BIM

eeeBIM Energy-enhanced embedded BIM

eeE eeEmbedded – EU project Optimised Design Methodologies For Energy-Efficient Buildings Integrated In The Neighbourhood Energy Systems

EPD Environmental Product Declaration

ESIM Energy System Information Model

EU European Union

FM Facility Management

HESMOS Holistic Energy Efficiency Simulation and Life Cycle Management of Public Use Facilities (EU research project, 2010-2013)

HVAC Heating Ventilation and Control Systems

IDM Information Delivery Manual

IFC Industry Foundation Classes

ISES Intelligent Services for Energy-Efficient Design and Life Cycle Simulation (EU research project 2011-2014)

KPI Key Performance Indicators

LCA Life Cycle Assessment

LCC Life Cycle Costing

LEED Leadership in Energy and Environmental Design

LOD Level of development


Version 1.0

/52


LoD Level of Detail

LoA Level of Approximations

MCDA Multi-Criteria Decision Analysis

MM Multi-Model

MMC Multi-Model Container

PPD Predicted Percentage of Dissatisfied

SOA Service Oriented Architecture

UC Use Case

VDL Virtual Design Laboratory

WP Work Package


Version 1.0

/52


TABLE OF CONTENTS

1. Introduction __________________________________________________________________ 8

2. Overview eeE Ontology Framework ______________________________________________ 10

2.1. Work Basis - Key Point Framework (D2.1) ________________________________________ 10

2.2. Ontology issues - Key Points from a Technical View ________________________________ 12

2.3. Definition of the eeE Ontology Framework ______________________________________ 14

2.4. eeE Ontology in Key Point Workflow ___________________________________________ 15

3. Interoperability between domain models _________________________________________ 25

3.1. eeBIM ___________________________________________________________________ 25

3.2. eBIM ____________________________________________________________________ 26

3.3. Integration Process _________________________________________________________ 28

4. Validated Processes with Key Points ______________________________________________ 30

4.1. To-Be values vs As-Is values __________________________________________________ 32

5. Ontology based Template Methods ______________________________________________ 34

6. Ontology Approach ___________________________________________________________ 37

6.1. Idea of the eeE ontology _____________________________________________________ 37

6.2. Structure of the eeE ontology _________________________________________________ 37

6.3. System Structure Module ____________________________________________________ 39

6.4. BIMOnto _________________________________________________________________ 40

6.5. eeBIMInterfaceOnto ________________________________________________________ 41

6.6. Environment ______________________________________________________________ 43

6.1. Simplified Link Model _______________________________________________________ 44

7. Ontology Platform ____________________________________________________________ 46

7.1. Static Model ______________________________________________________________ 46

7.2. Dynamic Model ____________________________________________________________ 48

8. Conclusion and Outlook _______________________________________________________ 51

References ______________________________________________________________________ 52


Version 1.0

/52


Executive Summary

The objective of the Deliverable 5.1 "Interoperability and ontology framework" is to provide a formal

conceptual specification of an open and extensible energy-enhanced ontology framework, to support

the synthesis and the interoperability for energy-related data necessary for efficient building design

and for supporting the collaboration of the different involved partners. It is mainly based upon

Deliverable 1.2 “Use case scenarios and requirements specification (technical report)” (Geißler,

Guruz, & Woudenberg, 2014) , Deliverable 1.4 “Requirements for knowledge-based design support

and templates” (Solvik & Kaiser, 2014) and Deliverable 2.1 „Holistic multi-disciplinary Key Point-

based design framework“ (Guruz, Rodriguez, & Geißler, 2015), which defines the eeEmbedded

workflow and the quality inspection done with Key Point method.

This deliverable is the initial deliverable in this work package and gives an overview of the ontology work to be done in this work package. It specifies the core structure of the framework and defines the connection points and the implementation work for the following deliverables, which are:

T5.2 Interoperability systems

T5.3 Ontology System

For integrating the different data coming from different sources and for providing a controlled

workflow based on Key Point inspection to come up to an energy efficient building a System Analysis

Ontology (SysOnto) was developed and embedded in an appropriate ontology platform.

Based on the eeE workflow specified in WP1 and WP2 the deliverable report is divided into six parts:

Part 1. The first part introduces the concept of the eeE Platform and Collaborative Work and the idea

of an ontology framework for linking issues. Additionally relevant rules like e.g. rule based model

checking are discussed.

Part 2. The second part discusses the integration of the different domain models and external data.

Thereby, the link concept of the ontology framework is focused.

Part 3. In this part the ontology validation process will be presented. This validation process is split

into two validation processes checking the prerequisites and checking the result quality.

Part 4. Next to the direct support of a specific project the ontology supports the reuse of project

results, so that a cross-project support is provided. This kind of support is mainly reached by an

appropriate template definition and management.

Part 5. The core structure and the basic concepts of the ontology will be presented in this part.

Part 6. The functionality of the ontology will be realized by a corresponding ontology platform. In this

chapter the architecture and the core services of the platform will be discussed.

All partners were involved and each partner has contributed from their expert viewpoint as follows:

CIB: Lead, all tasks from contractor and operator point of view.

ALL Partners: Input via discussions.


Version 1.0

/52


1. Introduction

Efficient reduction of Building Energy consumption needs to consider different phases in the Building

Life Cycle. Thereby, every phase is related to different partners and experts requiring different

models and data in different level of detail. Actual design and analysis software offering a controlled

workflow for checking the requirements before a process step will be executed and checking the

quality of the results, so that an alternative selection of building designs can be made in time or a

work around for improving the current design can be identified, are not existing.

Objectives

Based on the overall goal different objectives can be identified, which are specifically addressed to

knowledge management and ontology work:

Resource over spanning filtering and searching: Next to the uniform ontology schema the implementation in a standard ontology language and the use of a standard query language provides the search for different information. This means, energy relevant information can be explored in the process context, but energy enhanced BIM-information can be also filtered and selected without considering the process context and with the main focus on the integrated building information.

Controlling of collaborative processes: The process model of the platform ontology describes the different steps of a collaboration process defining the necessary input data and the required quality of the results. The description of processes offers the possibility to model alternative process steps, so that the ontology and an appropriate rule definition could control the process flow. In this sense, non-available software tools influences the selection of the next process step.

Pre-Inspection of the eeBIM-Model (energy-enhanced BIM-Model): The main goal of pre-inspection processes is to validate and verify the input data and their linking. This inspection is the sum of several inspection steps applied on the different sub models of the eeBIM and the analysis models. Here, the semantic model and its representation as OWL-ontology offers extensible inspection methods, so that next to the inspection of energy relevant dependencies further reasonable inspections like noise prevention can be considered for the building design. The inspection methods realized as rule sets in a standard rule language are software and platform independent and can be applied by the different involved partners. The quality of the inspection methods depends on the experience modeled as logical rules. So the ontology model can serve as a knowledge base, which can be used for different projects.

Auto-correction of missing or incorrect information: The first step of the rule-based implementations is to identify problems in the inputs and in the linking. Next to exactly localize the problem a further planed step of defining logical rules is to support the users by solving the detected problems. This could be achieved first by derivation rules setting or correcting values by combining and evaluating existing values (e.g. the missing are of a rectangle wall can be calculated by the given height and length) and second by standard setting rules accessing standard values for comparison or insertion. The auto-correction methods further extend the ontology application model containing the previous mentioned controlling and inspection methods. In ISES this step will not be realized, but the possibility for such an extension should be defined.

Key Point (KP) based inspection of workflow results: Before executing the next workflow step the quality of the current results will be checked. To do this the To-Be values are a priori defined and stored in the ontology will be compared with the As-Is values derived by


Version 1.0

/52


applying calculation rules or coming from the simulation tools. A negative check can lead to a warning or an error avoiding the execution of the next step. Furthermore, the consequence of a check could be the selection of different alternatives.

Template support for cross project applications: Some information developed in a project like linking information between different models or KP information can be generalized in such a way, that they are common for a certain workflow type or a certain project goal. This information will be stored as templates in a library for reliability. For improving the automation in the ontology framework data mining methods could be used to identify automatically such templates and their variables.

Within the report, the terms design “Alternatives” and “Variants” are not used as synonyms.

The term Alternative(s) is used to describe the result of a building design, created by leastwise one

planner. In this document, the term refers to the overall view of the building. A design alternative is

always the result of a design process after a working step and/or design phase that have been

completed by one or more planners. Therefore, a design alternative is determined unambiguously by

the totality of its attributes in relation with the respective state of design.

In contrast, the term Variants is used to describe an e.g. stochastically simulation result which offers

a new variant after modification of one attribute. A variant describes always a possibility result with

regard of optimisation, while an alternative is the entire proposed solution.


Version 1.0

/52


2. Overview eeE Ontology Framework

This section provides an overview of the envisaged eeE Ontology Framework. In a first step the Key

Point framework will be summarized with a special focus on the ontology usage and the

corresponding requirements. Next to the inspection of the Key Points (KP) in the workflow the KPs

will be analysed from a technical point of view. After the Key Point framework analysis the eeE

ontology will be defined. The definition of the eeE ontology will provide the key issues of the

ontology framework. In the following eeE ontology workflow thesis issues will be more detailed.

Since in the previous chapters common ideas and scenarios for ontology usage were described, this

chapter focuses the ontology usage which will be specialized regarding the eeE tasks and especially

the eeE Key Point Framework. Therefore, an ontology framework will be developed based on the

specification of the eeE Key Points and the outcomes from WP1 & WP2. Then the detailed ontology

usage will be depicted by extending the Key Point Workflow included in D2.1 (Guruz, Rodriguez, &

Geißler, 2015).

2.1. Work Basis - Key Point Framework (D2.1)

The ontology usage is mainly based on the different issues of the eeE KP process. As presented in

figure 1 the eeE KP process can be divided into three main issues: Requirements Specification,

Qualified Process Specification and Checking & Evaluating.

In the Key Point process requirements are defined firstly. They represent the targets, which the

different process steps and the overall process have to reach. Thereby, requirements are the sum of

Key Design Parameters (KDPs), Key Performance Indicators (KPIs) and Decision Values (DVs). The As-

Is values of the requirements can be identified by three methods, by simulation, by ontology rules or

they have to be entered manually. In the ontology framework all kind of requirements will be

considered to provide consistency. Requirements consist in general of the requirements To-Be value

like target energy consumption, the requirements As-Is value like an allowed energy consumption

range from 1500 to 1900 kWh/a, the requirements operator defining the kind of comparison should

be done between To-Be values and As-Is values, three kind of context links, a context link to the

domain referencing a building, building zone, building element, HVAC element, ESIM element or cost

element, a context link to the process/ task the requirement is formulated for, a context link to the

calculation method like a certain software describing how the AS-IS value is exactly calculated and

allowing the selection of a meaningful TO-BE value, a decomposition relation describing how much

another requirement is contained in the current requirement and dependencies relation formulating

dependencies between other requirements or the output events generating a warning or an error.

Cause of the fact, that at the beginning of defining requirements no certain model like the certain

building model exists, the requirements are formulated and related to the whole neighbourhood,

building or predefined object types like certain walls (e.g. walls with direction to the south).

So, before the building modelling starts a list of the certain object types, which will be used, has to be

formulated and can then be related to the requirements. Requirements can be added with

attributes. One of these attributes is considered for defining the order of the requirements. The first

ordering level is defining, whether the requirement is assigned to the category DV, KPI or KDP. On

the next ordering level, within the categories further priorities will be defined. One requirement can


Version 1.0

/52


exclude the other requirement or the satisfaction of one requirement can equalize the failing of

another requirement. These dependencies can be formulated by using certain derivation rules. These

rules can also be used for generating a warning or an error. The modelled requirements can be

checked regarding the related model level. Thereby, this check is split into two kinds of checking:

syntactic checks and semantic checks. As the term syntactic checks already says the syntax will be

checked like identifying possible loops generated by formulating dependencies. Semantic checks

check the requirements content against regulation or stored values based on experience.

The process specification consists of three sub-issues: 1) Process Formalization, 2) Process (De-)

Composition and 3) Process Dependencies.

1) In the process formalization step the process can be named and attributes like process responsibility attached. Next to this, existing processes can be selected and adapted. This kind of template support represents one of the main issues of the ontology usage and will be discussed later in the ontology workflow.

2) The decomposition of the process will be realized on three further detail levels: sub processes, tasks and subtasks. Thereby, the sub processes represent the defined design use cases and tasks the defined design tasks in D2.1 (Guruz, Rodriguez, & Geißler, 2015). All detailing steps include also an extension and detailing of the attributes of higher levels.

3) The last process specification step formulates dependencies between processes and the decompositions of processes. In contrast to process modelling languages like Business Process Model and Notation (BPMN), the ontology formulates process dependencies only in a light weight form. The focus of ontology based process modelling is to describe the possible successors of processes and is not to define the detailed dependencies like an “Or” or “And” relationship possible in BPMN. In the template management tasks a more detailed description in BPMN format will be provided and be linked with the ontology concepts.

To come up to a qualified process specification first the hierarchical structure of the DVs, KPIs and

KDPs will be defined. This includes also the composition description defining the weighting and

functional mapping how the requirements will be composed. The assignment of the KPs to the

processes takes in general place after the processes, sub processes, tasks and subtasks to ensure a

certain quality of the results. Next to this the KPs can also include requirements checking the input

for each process regarding completeness and correctness. Especially, for simulation tasks, which

requires a previous mapping and configuration step, a pre-checking done by ontology rules can save

time.

While the previous steps specified the KP process on the domain model schemas in the checking and

evaluation step the instantiated model is analysed. To come to an integrated model ready for As-Is

and To-Be analysis different integration steps have to be executed. These integration steps cover

filtering, mapping and integration checks. Next to providing integration checks the ontology offers

also methods for supporting filtering and mapping. Dependent on how the evaluation function

interprets the results, an error will be detected stopping the eeE workflow, or a warning will be

detected providing certain recommendations or a prioritization of results will be applied.


Version 1.0

/52


Figure 1: Ontology basis: eeE workflow

2.2. Ontology issues - Key Points from a Technical View

The realized KPs follow the idea of a controlled workflow establishing milestones, where the actual

results are compared with predefined objectives, which has to be fulfilled reaching the millstone. The

results are valuable in 3 levels 1) Designers via Key Design Parameter (KDPs) 2) Analysts via Key

Performance Indicators (KPIs) and 3) Decision makers via Decision Values (DVs). Thereby, the

comparison of As-Is values with To-Be values serves to provide the information of the current

progress state, the quality of the results and possible reworking steps as well as the information of

the best design variant at each KP.

The idea of a controlled workflow with predefined objectives, more precisely worked up and

formalized building requirements, seems to lead to a reduction of the flexibility in the design process.

Predefined objectives indicate that the workflow is also predefined to a certain level. This fact, which

is of course advantageous from perspective of the construction management, poses challenges to

the quality and significance of the KPs. To minimize the inflexibility, different KP specifications and KP

setting options are possible. These specifications address firstly the selection and abstraction of KDP,

KPI and DVs and secondly the interpretation of the selected and abstracted values.

2.1.1 Selection of Key Points

In the setup phase of KPs the requirements are formulated extracted from project related building

requirements. There exist different selection possibilities to improve the flexibility of the predefined

Requirements Formalization

Requirements Ordering

Requirements Dependencies

Model Checking

Assignment of KPs, DVs,

KPIs, KDPs

Assignment of KPs to

Processes

Integration of Model

Instances

Check AsIs vs. ToBe

Model

Process Formalization

Process Composition

Process Depencencies

RequirementsSpecification

Qualified ProcessSpecification

CheckingEvaluating

Evaluating & Ordering Results


Version 1.0

/52


KP workflow. These improvements influence the flexibility on three different levels, Definition

Domain, Target Area and Process Area:

Number of KDPs/KPIs (Definition Domain): A larger number of KDPs/KPIs increases the restriction of a design and based on this the test reliability increases too; the consequence is that the flexibility will be reduced.

Size of Valid Target Value Range (Target Area): The flexibility can be increased by larger ranges of target values, cause this can lead to larger set of alternatives.

Number of KPs (Process Area): Reducing the number of KPs will lead to more flexibility between two KPs and within the process. This means the process description is less predefined.

2.1.2 Abstraction of Key Points

Abstraction of Key Points got the effect, that more certain KPs are covered by this abstraction. This

reduces restrictions and increases the flexibility:

Topological Reduction (Definition Domain):Topological Reduction means that the KDP/KPI Definition is not directly formulated to certain building elements, but to their topology. So, the restriction to a wall could be formulated only to its axis of gravity.

Approximation Level of KDPs/KPIs (Target Area): KDP/KPI could be formulated more abstract and in sense on a higher approximation level to allow more flexibility. So, the height of a column could be defined for each column or formulated more implicit by defining the height of a certain floor.

2.1.3 Interpretation of Key Point Results

Next to the definition of Key Points the kind of their interpretation is another aspect for increasing or

decreasing the flexibility within the Key Point Framework:

Error Indication (Definition Domain): If the defined Quality of a KP is not reached and a corresponding check fails there are different reaction based on the level of the error possible. So, the reaction could be a

warning with recommendations for improvements or an error, which has to be corrected before the next workflow step can be executed.

Selection Methods (Result Domain):

The selection methods defines how the set of alternatives looks like. Increasing the number of alternatives in a key point means, that on the one side the probability to consider the best alternative will increase, but on the other side the analysis time will linearly grow up.

All methods show how flexibility can be improved, but it has to be mentioned that increasing

flexibility can reduce the quality and the force of expression of the KPs. This could finally lead to KP

checks, which are so generally formulated, that the user can identify the result of these checks

without starting a calculation.

2.1.4 Key Point Definition Methods

A further drawback is that the controlled workflow method follows the principle of a greedy

algorithm. A greedy algorithm follows the problem solving heuristic of making the locally optimal


Version 1.0

/52


choice at each stage with the hope of finding a global optimum. In many problems, a greedy strategy

does not in general produce an optimal solution, but nonetheless a greedy heuristic may yield locally

optimal solutions that approximate a global optimal solution in a reasonable time. (Black, 2012)

This means in our case that a selection of design alternatives in levels 1&2, design and simulation/

analysis will be directly made within each KP. The chronological order of a design process causes the

problem, which follows on the one hand mandatory tasks, each of them builds on the previous task,

and on the other hand has only little information in the beginning and only at the end of planning

lots of information. In consequence, design alternatives and their analysis results which show in the

first KPs of the earlier design phases less quality can have in sum (and/or later stage) the better

quality. Without scrutiny, the method would sort out these KPs. So, cause of the greedy selection in

the process the decision after the red marked KP would lead to the path KP A to KP AA and the

quality level 7 (4 + 3), but the higher quality (2+6 = 8) would be reached following the path KP B to KP

BB. The KP template selection and the connection of such templates will be done a priori. So, this

procedure is not based on a greedy algorithm and will lead to an optimal result.

Figure 2: Key Points Selection

Furthermore, not each KP is equally affected, the emphasis to be set in the right order:

1) Key Design Parameters are the most affected KPs. On the one side KDPs are used to check whether the design decision fulfils the regulatory, environmental, site and client requirements, on the other the design decisions are still in lower elaboration so that the values may be regarded only as a guide.

2) Regarding to the Key Performance Indicators the review is a bit different. Distinction should be made between values with high, middle and low influence.

3) Decision Values are the lowest affected KPs, only already weighted factors are assessed here.

2.3. Definition of the eeE Ontology Framework

The overall issue of the ontology is to support the approach of a controlled process workflow. So, for

each process step a certain model schema – the To-Be Model - has to be defined, which will be

referenced for the checking step. The actual instances of the multi model describing the current state

of building model and its connected external models. For the checking procedure, the instances have

to be transferred into the ontology multi model making the rule application possible. Cause of the

fact that not all instances and relationships could be checked or are interesting for checking an

KP KP

KP A

KP B

KP- Template 1

KP- Template 2 KP-

Template 3

KP AA

KP BB

4

2

3

6


Version 1.0

/52


abstraction step will reduce the ontology instances, so that the relevant instances set will be

generated and ready for checking.

Figure 3: Ontology Controlled Workflow

The ontology issues can be grouped into two types of main issues: Schema generation and instances

generation. In the first case the ontology supports the development of schemas like the formulation

of the process, the KDP/KPI definition or the link model specification. This is a template based issue

and is not only related to one project, but cross project related. The other issue type is a more

detailed issue and working on instance level. This ontology issue is a project specific issue and a

concretisation of the first issue.

2.4. eeE Ontology in Key Point Workflow

As mentioned in the previous section the main tasks of the ontology are project specific issues and

cross project issues. Both issues comprise:

Information Integration

Process Management

KP/ Integration Inspection

Ontology-based Evaluation

For the cross project issues and the task of storing information is additionally

Template/Type Management

considered.

2.1.5 Project specific ontology support

Requirements Specification

Requirements represent the target points within the workflow. As already mentioned requirements

consist of different parts: the term, the relational operator, the value or value range to be compared,

the link model connected with the context and requirement dependencies.


Version 1.0

/52


Figure 4: Requirements Specification

The different requirements parts can be more explained as follows:

Requirements Term The requirements term describes the content of the requirement and represents the As-Is value.

Requirements Operator The requirements operator of requirements representing is a relational operator defining if

the KDP, KPI or DV is “<, >, =, ≤, ≥, ≠, , ” a certain value or value range.

Context Link The context link is a 1 to N link considering different domains. In the building domain (for other domains it is similar) the link could be related to the whole building, types of building zones like room types, certain building zones, types of building elements like wall types and certain building elements. A context link could be also related to a calculation method to detail how the As-Is value will be calculated. If a KDP, KPI or DV is not fulfilled this could result in weaker condition concerning the context. So, a KPI firstly addressed to the whole building could be reduced to a certain type of rooms.

Decomposition Relation The decomposition relation of requirements is a weighted sum summing up a list of requirement values representing different KDPs, KPIs or DVs.

Requirements Dependencies The requirements dependencies describe the different dependencies between the KDPs, KPIs and DVs, which could influence the weighting of them, if the dependent requirement is not

Requirement

RequirementTerm„Max. Energy

Consumption Costs“

RequirementValue„1000 €/month“

Requirement Operator„<“

Context

„Rooms“ „Costs“

Context Link„1:N“

RequirementRequirementTerm„Comfort Level“

RequirementValue„Level B“

Relational Operator„>“

Requirement Dependencies

„Alternative“

RequirementDV, KPR and KDR

Decomposition Relation

„30%“

RequirementRulesValue Check

→ Value Range Adaption

→ Context Level Adaption

→ Value Distribution

Adaption → Requirement Adaption


Version 1.0

/52


fulfilled. The dependencies could also be directly related to system outputs generating warnings or errors. Errors are further related to the process avoiding executing the next process step.

As mentioned before, the pre-definition of KPs reduces the flexibility of the overall design process

and in finding alternative solutions. For improving the flexibility adaption rules are envisaged in case

of a failed value check:

Value Check/ Value Range Adaption The comparison between the As-Is value and the To-Be value will be executed by the value check. Before generating an error or warning the possibility is offered for an automatic value range adaption, which could be related to requirements dependencies. So, a value out of the previously defined range could be even accepted, if another requirement is overachieved.

Context Level Adaption A context level adaption is especially necessary in further detailing process of the building design. So, requirements formulated in the first step for a whole room type will be more detailed and concretized to a certain room.

Value Distribution Adaption Similarly to the value range adaption a value distribution adaption can be implemented realizing that the percentages distribution between DVs and KPIs is adapted, if one requirement is not fulfilled but another one is overachieved.

Requirement Adaption For improving the flexibility the dependencies between the requirements could be automatically adapted using ontology rules. So, if requirements are not fulfilled other requirements could become more restrictive to fulfill a DV.

Based on the requirement specification the resulting ontology workflow looks like follows:


Version 1.0

/52


Figure 5: KP Workflow (Guruz et al., 2015)

1. Key Point Setup: Via GUI Key Points could be defined and stored into the eeE ontology consisting of KP name and successor dependencies. The KPs could be structured in a Hierarchy.

2. Requirements Setup: Via GUI the requirements term can be defined and stored into the ontology. Next, the prioritization of the requirements will be specified by setting an attribute. First, the requirements type as prioritization type and then further detailed prioritization types could be set. If DV as prioritization type is set, the requirements operator is set to weighted sum and the requirements value is a list of KPPs. The procedure is similar with KPIs or KDPs as prioritization type. The context specification is on the first level related to a building type, on the second level to building zone types, on the third level to building element types, on the fourth level to certain building zones and on the last level to building elements. All other domain models follow this detailing. The specification of types and the linking of requirements to types can be done a priori by GUI support this means before a CAD drawing exists. When a CAD drawing exists, the requirements could be linked to certain zones or elements. Furthermore, the dependencies between other requirements and to the system output could be defined. Within this step also the reactions triggered if a requirement is not fulfilled can be defined. Using ontology rules is could be specified if a requirement is reduced by enlarging the range or by reducing the detail level (e.g. from room

BIM SERVER

Ontology

Management Services

1 KEY POINT Setup: Scenario Manager (CIB)

Check clashes

Prepare a set of DVs and process pattern

Related to DVs - prepare a set of KPIs, process pattern and choose participating domains

Related to KPIs - prepare a set of KDP process pattern and choose participating domains

2 Requirements Setup: Scenario Manager (CIB)

Check consistency

3 Requirements Decomposition: Scenario Manager (CIB)

4 Storage of Key Points: Scenario Manager (CIB)

5 Combine Key Points and Processes: Scenario Manager (CIB), Collaboration Server (IABI)

Central storage in Ontology.

Central Storage in Ontology and BIM Server


Version 1.0

/52


type to certain rooms). The reaction of a requirement can also influence other requirements by changing their context or value. In this way whole reaction chains could be formulated. The clash and consistency analysis checks, if all mandatory parts of a requirement are defined, if a detailing like a detailing from a room type to a certain room will not lead to conflicts, if dependencies does not lead to circles, and if the defined KPIs and KDPs don not hurt definitions coming from regulations.

3. Requirements Decomposition: The decomposition relation decomposes the requirements from DV to KPI and from KPI to KDP. The decomposition from DV to KPI is a relation, which is additionally attached with a weight for calculating the weighted sum. The decomposition relation from KPI to KDP can be attached with a weight to describe the influence of the KDP to the KPI. The weighting of both decomposition relations is interesting for KP template development and identifying the most relevant KP structure and in this sense it is also interesting for correction methods and finding the most appropriate solution.

4. Storage of Key Points: Key points can be stored as two different types, just as instances and more flexible and sustainable as template. The instances will be always stored within a project. The templates will be derived based on the instances.

Qualified Process Specification

Processes connect two Key Points. Thereby, the connection of two Key Points could be realized by more than one process; this is the case, if alternative processes are defined. In this project the focus is on the workflow and the different workflow steps. So, processes include no time information. Corresponding to the KP structure, processes are also hierarchically organized. While KPs contain the information, what has to be exchanged and in which quality, processes provide the information, how the necessary exchange output has to be generated. In this sense, the proper tool and service context information is related to the processes. In the early design stages some simplified calculation methods will be represented by description rules and the execution of these calculation methods will be done by invoking a rules engine service.

Figure 6: Qualified Process Hierarchy

DVPassive House

ProcessUrban Design

KP??

DVeeSV

Process-Alternative

Urban Design

Sub-Process??Sub-Process-

Alternative??

Task??Task-

Alternative??

KPI/KDR??

KPI/KDR??

KP FieldConstruction

Physics

KP??

ContextTool/Service ListRequirements ListDomain Model List

ContextTool/Service ListDomain ModelsLoD

ContextTools/ServicesERsLoD

ContextTools/ServicesDetailed ERsLoD

Process Hierarchy KP Hierarchy Context Hierarchy


Version 1.0

/52


The ontology describes the processes only on an abstract way. For a more detailed formulation

description formats like BPMN or EPC could be attached. In the ontology processes can be

formulated on three different detail levels:

Processes Processes are related to DVs. So, they describe how a DV like the DV for passive houses could be realized. Alternative processes are characterized by different sub processes. The DV has attached the information, which tool/service list is necessary. Furthermore, the Domain models and the LoD are known.

Sub processes Sub processes could be defined to realize KPIs as well as KDPs. The KP stores the information about the required tools/services and the ERs to be fulfilled.

Tasks Tasks specify the lowest level of process description. The KPs contain the detailed ERs. The proper tool/service information is directly related to the tasks.

Based on the process specification the following steps have to be realized:

1. Process specification and detailing: Via GUI processes could be defined and stored into the eeE ontology. This includes the definition of process dependencies. Furthermore, the mentioned detailing of processes and the addition of attributes like the related services/tools will be GUI supported.

2. KP assignment to processes: Via GUI the already defined KPs can be related to the processes. Thereby, each KP marks the position for an As-Is vs. To-Be check. After a step is completed an ontology service will be invoked checking the results against the requirements and the results of the check will be visualized.

Checking & Evaluating

The overall eeE workflow starts with generating the design models following the requirements

formulated as KDPs. Corresponding to optimization problems the KDPs define the feasible region and

the DVs the objective function consisting of different sub functions represented by KPIs….


Version 1.0

/52


Figure 7: Checking & Evaluating Workflow

Checking of As-Is values against To-Be values and evaluating the results requires the integration of

the information coming from different models and representing the As-Is values. This integration

process is a process consisting of different steps. Along with the information integration, also the KP

check is split into different smaller checks executed in such steps are pre-checks, checking if the

generated multi model is completed and correct for running a simulation, and quality checks,

checking if the results fulfill the expected quality. All results corresponding to a certain design

alternative will be collected and evaluated. The evaluating process is based on the already

mentioned sort and selection methods. So, the result of the evaluating process could be a single

result representing an accepted building design or a list with accepted results ordered by the degree

of fulfillment concerning a DV.

In detail the checking and evaluation process looks as follows:

Multi Model Generation: In this step the different domain model instances will be linked. The linking will be done manually supported by template usage. The template provides different linking types for different domain models on different level of detail (Linking between classes, linking between object types, etc.). The ontology stores the templates and selects the templates regarding the task and the models to be linked. The description of the linking will be done in OWL/RDF. The linking comprises also the linking of requirements to building zones, etc.

Multi Model Filtering: The multi model filtering follows directly the ER specifications. This means the task related ERs are stored as model views in SPARQL and the SPARQL query will be applied on the previous generated multi model to get the partial model required to execute the task. The ontology stores the SPARQL queries and selects them for each task.

BuildingModel

CostModel

Building Cost SimulationModel

Thermal SimulationModel

Building Energy DecisionModel

DVeeSV

KDRBuilding Volume

KDRBuilding Cost/Volume Coefficient

B1

B2

B3

C1

C2

C3

S2

S1

ERBuilding Cost Simulation

KPIBuilding

Volume Costs

D2

D1

Design ModelsBuilding Element B1:Building Volume Building Element B2:Building Volume < 6000m³Building Element B3:Building Volume < 6000m³Building linkedWith Cost Element C3Cost Element C1:Building Cost Cost/Volume Coefficient Cost Element C2:Building Cost Cost/Volume Coefficient < 1500 €/m³ Cost Element C3:Building Cost Cost/Volume Coefficient < 1500 €/m³Building Cost linkedWith Building Element B3

Simulation ModelsSimulation Element S1:Building Costs Volume Costs = Building Element B3 ´ Cost Element C3 Simulation Element S2:Building Costs Volume Costs = Building Element B3 × Cost Element C3 < 9 Mio €

Decision ModelDecision Element D1:Passive House Building Design DV = Weighting coefficient * related yearly energy consumption + related Simulation Element S2 + … < ??? Decision Element D2:eeSV Building Design DV = Weighting coefficient * related yearly energy consumption + related Simulation Element S2 + … < ???

KPIYearly Energy Consumption

Design ModificationKO SelectionList Selection Mixed Selection


Version 1.0

/52


Multi Model ER Checking: Since in the multi model generation step link types would be offered to support the user by finding the correct linking or finding missing links in this step the mandatory links and the mandatory attributes will be checked based on the ER specifications. Here, it is not checked if the attribute values make sense, but only the existence of values is checked. The existence check is realized as SPARQL query or as ontology rule. The queries and rules are attached to the tasks.

Multi Model to OWL Mapping: For mapping the instantiated Multi Models to OWL two core mapping methods will be applied. The first method realizes the mapping from IFC to OWL. Here, the existing mapping approach of Beetz (Beetz, van Leeuwen, & de Vries, 2009) is used. Next to the IFC mapping a mapping method for transforming XML documents into OWL will be offered. The XML2OWL mapping will be described in XMLT. The different XMLT mapping rules for the different XML documents will be managed by the ontology.

Deriving extended semantic concepts: For rule defining and checking and for easy filtering it is necessary to use the explicit given information for deriving new information existing previously only in implicit form. The new concepts could be new building elements, which usage is very specific and can be described in ontology rules. Furthermore, these new concepts defining new filter conditions the model could be filtered for.

Link quality control/ KDP Check: In the Multi Model Check step the mandatory links and the mandatory attributes were checked based on the ER specifications. Since this was just an existence check in this step the quality of the links and the attributes will be checked based on regulations and stored internal experience. So, it will be checked if the linked U-value range of coming from a material library fits to the related building element.

Partial model filtering: Since the Multi Model Filtering describes a filtering on the origin models, the partial model filtering operates on the semantically extended Multi Model. This means the temporary generated output model contains also the new derived concepts.

Process Input Transformation: In this step the certain calculation process will be invoked. This could be an external simulation triggered by the workflow manager or an internal simplified analysis method encoded in jena rules also triggered by the workflow manager.

Process Output Transformation: The results will be written back after the calculation. In general this means KPIs will be returned and a new link model will be generated with the KPIs linked to the building elements or spatial elements of the building model.

KPI/DV Check: Similarly to the ER check the returned As-Is values will be compared with the stored To-Be values.

KPI/DV Check Results Transformation: The results of the comparison are generated and the workflow manger will be informed, so that the results could be displayed and visually evaluated.

KPI/DV Evaluation: Based on the underlying evaluation methods alternatives could be deleted (KO Selection) and only the accepted results will be stored and provided for the next step. A list of the best alternatives could be generated (List Selection). This list has a predefined certain length. A Mixed Selection is selected, if only a certain number of the accepted alternatives is stored and provided for the next step. Furthermore these alternatives are also ordered by their quality.

KPI/DV Evaluation Results Transformation: The results of the evaluation are generated and the workflow manger will be informed, so that the results could be displayed and visually evaluated.

Error Handling: It exists the possibility, that design alternatives not fulfilled the KPI/DV check could be corrected. This could be done semi-automatically by ontology based correction methods or in an additional iterative step.


Version 1.0

/52


Figure 8: Ontology based KP Process

2.1.6 Cross-project ontology support

The knowledge of the ontology is coming from different sources and can be stored in different ways.

Sources for knowledge generation can be certain and uncertain. Thereby, uncertain sources are

sources, which are not verified and potentially doubtful or which contain not all required information

or which are not concrete enough for an unambiguous assignment. Sources for knowledge

generation are the domain models themselves, implicit information can be derived from the existing

models by derivation rules, the context information, the required information, and regulations

represented as ontology rules or queries and made experience encoded in ontology rules and

queries. These cross-project information are available and used before a certain building model with

its geometrical data exists. So, decision are made first on semantic information by identifying

conflicts in the requirements definition or proposing design templates based on the made

requirements. This top-down procedure exactly follows the idea of a BIM based design.

MM-Filtering

MM-Checking

MM2OWLMapping

UI-Based & Template Supported

Modifications

Service-Management

Deriving ExtendedConcepts

LinkQuality Control

Partial Model

Filtering

FailedCheck

Invoking External Services

Alternative Input

Method

Automatically deriving not

complete

MM-Generation

Link-Check failed

Automatical correction not

possible

Error-Handling

Alternative Input

Method

Manual MM-Modifications




Input Generation

for Qualified Process

Invoking Internal Services

Temporal Storing of

Partial Model

Calculation Process

Process Input Transformation

Process Output TransformationRewriting

of Partial Model

KP Check

KP-Check failed;

Process Iteration required

KP Evaluation

Pro

cess

iP

roce

ssi+1

Pro

cess

i-1

KP

KOSelection

List Selection

KP Check ResultsTransformation

KP Evaluation ResultsTransformation

Temporal Storing of

Partial ModelStoring

results of rule check

Deleting Designs

Prioritizing Designs

Mixed Selection

Prioritizing+ Deleting

Designs

Temporal Storing of

Partial Model


Version 1.0

/52


Knowledge, which could be stored in the ontology, can be distinguished into process/task specific

knowledge and process/task independent knowledge. Task independent knowledge contains

knowledge, which can be formulated on an abstract level. This could be additional common

information regarding the domain models, which could be easier described in ontologies like

restrictions or consistency checks. Furthermore, common descriptions regarding the linking will be

stored into the linking ontology. This could be common linking types or common link classes. Task

specific knowledge is, as the name said, related to a certain task or process and beside this also to

other attributes like the level of detail. The task specific knowledge is stored in an extra ontology the

interface ontology as classes, types, templates, instances, properties, property sets, relations as well

as queries and rules. When a certain task happens this specific knowledge will be added to the

common knowledge. While the first mentioned concepts represent the static structures in the

ontology, the queries and rules are dynamically used to select, connect and generate the relations

and concepts required for a certain task. The management of the interface ontology and the

templates will be detailed discussed in the following sections. Here, the application and support of

requirement templates will be exemplary described.

In the Requirements Templates the requirements can be selected by predefined requirements terms.

Connected with this terms are also pre-defined relational operators, context links and requirements

dependencies. Next to the selection method based on the terms the user has also the possibility to

start the selection of requirements by context links or requirements dependencies. If the term, the

operator and the dependencies are selected a decomposition and priority structure will be offered.

The definition of such templates can be done manually. Next to this a data mining method is

envisaged analysing the made requirements definitions and identifying for example the most used

relational operator related to a term for deriving certain templates.

Figure 9: Requirements Template Concept

Relational Operator„<“

Requirement Value„kWh“

Context Link

Context

Requirement Dependencies

Requirement Term„Climatic Comfort“

Requirement Term„Max. Energy Consumption“

Decomposition DV, KPI, KDI

Ordering Priorities

Requirement Term„Max. Energy Consumption“


Version 1.0

/52


3. Interoperability between domain models

The ontology framework forms the core approach for realizing the interoperability between the

different domain models and external data. Thereby, this approach comprises two level of data

integration. On the lower level only the linking information between the different models is

harmonized and represented in a uniform semantic, the origin models remain as they are. This

approach is very simplified and mostly made for data exchange. For a controlled data exchange the

semantic information of the origin models is mapped into ontology format offering the possibility for

deriving information, additional filtering methods, rule based calculation methods and quality checks

envisaged by the KP method.

3.1. eeBIM

Figure 10: Interface Ontology Concept

For the certain engineering analyses the use of one domain model is mostly not enough. Often,

additional information coming from other domains are required and have to be combined creating

an overall information basis and providing the input information for the envisaged external

simulation tools and their related simulation models. In particular, the focused energy performance

Information Basis

Data Basis

Non-BIM-Data

BIM-Data

IFC-Data

BIM-Ontology

Interface-Ontology

4 5

Non-BIM-Ontology

1

1

23

XML-Data

6

78

3


Version 1.0

/52


analysis of buildings needs next to the BIM information describing the architecture of the building,

information about the climate, the user behaviour, etc. To combine these different domain

information two core strategies can be distinguished: Centralized information integration and

decentralized information integration. By using the centralized approach only one domain model

representing the centre model is related to the other domain models. The decentralized approach is

characterized by domain models, which can be combined arbitrarily with each other. Caused by the

fact, that for building design issues the building and the corresponding BIM model is focused, the

ontology approach follows the centralized integration with the BIM model as centre model. BIM

model implementations like the IFC aim to provide general concepts to cover common building

design scenarios, but for specific engineer tasks additional BIM information are required to extend

the architecture model. This extended BIM (eBIM) (Kadolsky, Baumgärtel, & Scherer, An Ontology

Framework for Rule-Based Inspection of eeBIM-Systems, 2014) has to offer the connection points

needed to link the information of the non-BIM domain models and to complete the overall energy

enhanced BIM model (eeBIM).

In the ontology approach the BIM model is represented by the BIM ontology, the extension of the

BIM model is represented by the Interface ontology and for realizing the eeBIM model the non-BIM

ontologies have to be linked (Figure 10). To transform the raw data into ontology information they

have to be mapped and linked:

1. 1 to 1 mapping just transforms the data format into ontology format. In the most cases it is a XML to OWL or IFC to OWL transformation.

2. The reduced mapping does not map the complete data into the ontology. To achieve a lean ontology model not all data are integrated (e.g. geometry data are not considered). Instead of the whole geometry model only derived abstract data are included (e.g. the width or height of a room instead of the whole room geometry).

3. N to 1 mapping combines several data to get one ontology element. Vice versa 1 to N mapping splits one data element into several ontology elements.

4. Direct linking is done in the course of the element mapping operations or manually, if corresponding elements cannot be identified by algorithms.

5. Implicit linking is based on ontology rules used to interpret implicit information for generating explicit links. This is mainly done for linking the BIM- with the Interface-ontology.

6. External linking describes the linking between an ontology and a data element (mapping ops/manually).

In summary, the ontology allows the integration of data on three abstraction levels. On the lowest

level the external data are only linked by a certain URL. The content of the linked data file is

unknown. On the next level additionally to the URL link-address Meta data are integrated. On the

highest level the external data are completely integrated. The integration of the data is next to its

representation in different abstraction levels dependent on the data set, which is selected to be

integrated in the ontology.

3.2. eBIM

In order to come to energy interpretable BIM we defined a step-wise data extension so that energy-

related entities are explicitly given and forming the connection points to non-BIM data. For doing so,

we check the LoD the information is structured first. As an absolute requirement we suppose that

space boundaries are given where associated building elements can be considered geometrically as

external or internal. With such information we can consider if e.g. a wall is an outdoor or indoor wall


Version 1.0

/52


etc. Figure 11 presents an excerpt of our rule set for bringing the BIM entities to an extended BIM

representation which is more type-safe and tool interpretable. Rule number one checks if at least

one space boundary is described as “EXTERNAL” and if this is the case the whole window is inferred

as outdoor window. Rule number two checks if a building element is a façade element by analysing

the space boundaries in the same manner as in the orange rule. Rule number three expresses that all

façade elements are part of the building façade.

In another rule set we make a similar analysis where IfcSpace entities are evaluated. For example,

based on the name of the room and the definition given by a room book an IfcSpace is assigned to be

an office room (defined as OWL class “WorkRoom”) or a technical room (“TechnicalRoom”) which

both extends IfcSpace. With such an association heated rooms (e.g. office, living area etc.) can be

isolated from unheated rooms (e.g. cable funnel, elevator etc.) in a next step.

After the extended elements were generated and linked, a check is performed if all individuals were

inferred correctly. When rule sets which bring the BIM to an eBIM cannot be applied (and validated),

it indicates that there is a problem regarding the possibility to perform an energy analysis. The

checking against constraints and reasoning with rules are big advantages when working with BIM.

While there are many existing specifications how a well-modelled building should be provided (e.g.

through LoD), it is not explicitly defined in the model schema and therefore not mandatory. The way

of expressing model requirements through rules leads to a consistent workflow later and saves time

in the case, that an energy simulation fails or produces wrong results.

Figure 11: Rule based eBIM Generation

For filtering out partial models within the eBIM model also selection rules are specified allowing a

semantic selection of Building Zones and Building Elements (Figure 12). The checking process can

lead to a time-consuming analysis, if the linking will be validated on a more detail level and for the

whole building. Besides the existence checking step the following inspection steps are checking

content information, which requires the execution of several rules. The idea of the semantic

selection is now to find eBIM-elements interesting for a detailed inspection. These elements

represent the most critical elements in the energy related analysis. So, in the first selection the most

critical abstract elements will be identified by ontology rules. Abstract elements are Building Zones

like rooms or floors and critical rooms are rooms with a huge window-area for example. When the


Version 1.0

/52


critical abstract elements were identified the related concrete elements like walls or windows are

selected. This selection is also focused on elements, which are most critical with regard to the energy

analysis. After the selection is done and selection sets are generated, these sets can be related to the

different inspection steps. Next to the time saving effect this kind of inspection can save data space

by integrating the external data into the ontology only on the abstraction level necessary for the

selected inspection step.

Figure 12: Semantic Filtering

3.3. Integration Process

The ontology approach aims at integrating the background models on an abstract level. So, on the

one hand the ontology should create the basis for a better linking support than it was realised with

simple multi-model approach used for example in HESMOS and on the other hand the background

schemas specified in the ontology should be abstract and generic enough to avoid the need for

implementers to develop complex mappings on schema level. With the simple multi-model approach

as starting point the new integrating approach by using ontology structures should facilitate the

linking between different models. Therefore the linking between different domain models and the

data exchange is a priori defined on schema level to identify and to check the linking on instance

level. So, next to the specification of OWL-concepts for link-relations corresponding SWRL-rules are

defined checking the linking on instance level. With this schema linking pre-setting the sender is not

let alone by encoding the relations between the domain model instances. Furthermore, the receiver

is supported by interpreting the linking by his knowledge of context information given by the

ontology schema. As non-loose coupling of elementary models the ontology approach offers the

capability for change management. All instances are summarised under the ontology and its schema.

By giving the instances a certain timestamp and formulating an explicit relation between instances

representing different stages of development all information are specified to manage changes in the

project phase. Though instances can be added with such timestamps the described relationship and

the change management is not considered in eeEmbedded.

The idea of the ontology is to integrate not all data coming from the origin models. Following the

idea of the semantic web, only meta data should be integrated into the ontology and harmonized for


Version 1.0

/52


an uniform access. For the building model this means that the whole set of geometric data will be

dropped for ontology import. In order to offer a model containing the linking between all data and

not only between selected meta data an inter-model will be defined. The idea of this inter-approach

is that the origin models remain as they are and only the linking between these models will be

harmonized in a separate model. This means the IDs of the linked elements coming from different

models will be stored in the link model in uniform format and semantic. To improve filtering next to

the IDs also the corresponding classes are stored in the link model.

The transformation from the simplified link model to the ontology approach starts with

transformation of the origin models into the ontology. Cause of the fact, that only meta data will be

contained in the ontology this step includes an filtering procedure. In contrast to the link model

approach the linked classes are not contained in the interface ontology corresponding to the link

ontology, but in the domain models. The interface ontology contains the links between the instances

and as checking method on more abstract level the domain and range of the corresponding link type,

which is addressed by a certain link. Furthermore, additional concepts, shortcut relations or rules are

stored or referenced in the interface ontology.

Figure 13: Ontological Integration

Information Basis

Data Basis

Non-BIM-Data

BIM-Data

IFC-Data

BIM-Ontology

Interface-Ontology

Non-BIM-Ontology

XML-Data


Version 1.0

/52


4. Validated Processes with Key Points

The validation process in the eeE workflow is split into two validation processes: inspection of the

prerequisites of the envisaged process and the quality of the results of the envisaged process. The

prerequisites inspection comprises the inspection of the exchange requirements and the inspection

of the linking of the different domain models.

Figure 24: Prerequisite Validation

Thereby, the ontology description lays the focus on the static properties of a process. This means, the

ontology checks the correctness of the IO-models, but not the correctness of the process itself. For

the model checking each process is related to a set of logical rules specifying restrictions,

cardinalities, etc. for the domain model and environment model schemas (Figure 15, left). These

logical rules represent the requirements the given models and their instances have to fulfil for the

related process. The environment and domain models with their certain instances represent the

resources, which have to follow the given model schema and the related rules. Thereby, two

processes can be related to the same model-schemas, but to different logical rules. This would mean

that the processes are operating on the same domains and the same environment, but they need a

different view for the process execution. So, the process model comprises both the “To-be”

description represented by the model schemas and logical rules and the “As-is” description

represented by the model instances. As mentioned the eeEmbedded project focuses in the

prerequisite inspection on the inspection of the correctness of the exchange requirements and the

linking between the different domain models. Thereby, the developed inspection process allows the

linking validation on different levels and for different partial models of the domain models (Figure 14,

right). Concerning the ER inspection there are only three detail levels proposed: Class Existence

Check, Attribute Existence Check and Attribute Value Check. Since the first two checks are

responsible for checking if a required class/ attribute is existing the last check checks if the As-Is

values are fulfilling the value requirements like being within a certain range. The last check

corresponds to the KDP check and can be applied there. The more interesting case is the link

inspection, so that this inspection is divided into six levels. On the first level only the existence of a

link is checked. If the check is passed then on the next level the correctness of the links is validated

by inspecting the Meta data. For example, on this level it will be checked if the density of a certain

material corresponds to the linked wall. In the next step all Meta data will be analysed in a context.

LINK INSPECTION

LINK EXISTENCE

CHECK META-DATA ALLOCATION

CHECK META-DATA DEPENDENCY

CHECK CRITICAL VALUE RANGE

CHECK SIMPLIFIED ANALYTICAL

CHECKANALYTICAL

CHECK

LINK ERROR-HANDLING

ER INSPECTION

ER CLASS

EXISTENCE CHECK

ER ATTRIBUTE EXISTENCE

CHECK

ER ATTRIBUTE VALUE CHECK

(KDP)

ER ERROR-HANDLING


Version 1.0

/52


So, the link between the material and the building element might be generally correct, but not

encoded in a linked climate model for a certain climate and a certain region. Next to the

identification of certain errors the inspection rules allows to search for possible errors and to

generate warnings. This could happen, if for example the foreseen material for a certain building

element could not fulfil the requirements for the building energy analysis. The material values could

be within the allowed value range for the related building element, but also within the critical value

range identifying values and links, which will possibly lead to negative analysis results. The next two

steps belong to inspection methods strongly based on analysis methods of certain standard

regulations like the Eurocode. These regulations formulated in ontology rules are firstly applied on

the Meta-data and then in the final step on the complete integrated data.

The quality inspection could be a KDP check, if the process is a CAD process or a KPI check, if the

process is SIM or OVM process. This kind of checking is a comparison of predefined KDPs or KPIs with

the generated values. These parameters to be checked could be:

Total energy need, kWh/m2

Heating energy nned, kWh/m2

Electrical energy need, kWh/m2

Purchased energy need, kWh/m2

Primary energy (E-value), kWh/m2

Building envelope heat loss, W/m2

Heating space max, kW

Heating AC max, kW

Cooling total max, kW

Window U, W/(m2K)

Wall U, W/(m2K)

Space infiltr. 1/h

Blind shading %

HRU %

Building orientation

After the checking process the evaluation is executed in for of a selection step. This selection could

be a KO selection, a list selection or a mixed selection as already mentioned.

The encoding of inspection methods via ontology rules shows the focused application scenario for

the eeE ontology in this project. Next to the checking it is also planned to use the ontology and its

rule definitions for auto-corrections. In this sense the ontology could automatically identify missing

links or a listing of possible links supporting the user in the preparation phase. However, the

simultaneous use of model description and rule definitions shows the advantage of ontologies as

modeling technique, which allow specifying domains and interpreting these specifications by

applying common semantic tools.


Version 1.0

/52


Figure 3: Ontology Validation Concept

4.1. To-Be values vs. As-Is values

Next to the possibility of a holistic analysis system description the underlying rule-logic and the

ontology reasoning are the main reasons for using the ontology description method. Even though not

the complete input data are transferred into the ontology the considered concepts opens up enough

semantic for important linking pre-inspections and for correcting the input data at an early stage of

development.

As mentioned before rule-definitions are focused on inspecting the ERs and linking between the BIM-

model and the additional models. In eeE the rules were designed as linear rule chain, where each

following rule represents a more detailed rule (see Figure 14, right). The edges between the rules can be

seen as kind of “stop and go” edges allowing the execution of the next rule, if the current rule is evaluated

as true. Three kinds of rule-checks are exemplary presented here:

Link Existence Check: This inspection checks, if all background model were correctly instantiated and the relations between the instances follows the cardinality restrictions.

Meta-Data Check: This inspection checks, if all instances have the correct meta-data and if the meta-data of two related background model-instances are plausible.

Value Range Check: This inspection checks, if the data value ranges of two related background model-instances are plausible.

The Link Existence Check is the most abstract Link Check of the SysOnto and will be exemplary

described in this section. Figure 16 shows the specification of a SWRL-rule checking, if the IfcSite is

connected with a climate element and with a software input element. The process step will be

marked as passed, if this rule is fulfilled.

Processi

To-Be-Model As-Is-Model

Instantiation

Rule<B, C>

Rule<A, B>a

b

c

A

B

C

Model-Schema

Model-Instance

KDP/KPI COMPARISON

KO SELECTION

LIST SELECTION

MIXED SELECTION

As-IsCAD, SIM, OVS

To-BeOMS


Version 1.0

/52


Figure 4: Link Existence Check

Before this rule will be executed domain model specific rules are executed. These rules are defined

within the domain models or the interface models deriving implicit information. So, the rule defined

in Figure 17 means, if a façade is linked to a climate element than the building site is also linked to

this climate element. This previous rule application prevents negative Link Checks.

Figure 5: Allocation Check

PROCESSSTEP

LINK EXISTENCE CHECK

passed Rule

ENVIRONMENTELEMENT

SOFTWAREINPUT

ELEMENT

BIM

IFCSITE

CLIMATEELEMENT

OUTDOORCLIMATEELE

MENT

SoftwareInputElement(?x), IfcSite(?y), OutdoorClimateElement(?z), hasAssociatedClimate(?y,?z),

hasBIMelement(?x,?y), hasOutdoorElement(?x,z)-> LinkExistenceCheck(?w),hasPassed(?w,true)

Rule

BIM

IFCSITE

CLIMATEELEMENT

OUTDOORCLIMATEELE

MENT

FacadeStandardCase(?x), OutdoorClimateElement(?y), hasAssociatedClimate(?x,?y)-> IfcSite(?z),

OutdoorClimateElement(?y), hasAssociatedClimate(?z,?y)

EEBIMINTERFACEONTO

FACADESTANDARDCASE

CLIMATEELEMENT

OUTDOORCLIMATEELE

MENT


Version 1.0

/52


5. Ontology based Template Methods

As mentioned before the ontology will support cross-project usage of experience made in a project

or defined in regulations. Thereby, the support should start as early as possible in the eeE workflow.

So, the template support will start with defining the requirements for the planned building design. As

mentioned before the requirement templates allow a selection of different requirements with their

related requirement values etc. Based on the made selection KPs and process definition will be

proposed. The execution of this template selection and template providing will be done by the OMS

together with the ScM and the MMNav. After the selection of Requirements/Process templates was

done Integration, Analysis and Evaluation Templates will help to define the next steps:

Integration Templates:

Link Type Definition: Link Type Definitions will help to find the correct linking between classes of different domain models.

Link Model Filtering: For each task filtering queries will be defined filtering out the required information.

IFC to OWL Mapping: Specific mapping rules will help to filter out non semantic data, not required for ontology tasks.

XML To OWL mapping: Specific mapping rules provide mapping for different XML-documents to OWL.

eBIM Rule Definition. Specific Rule Definitions will operate on the building model and generate additional concepts, relations, shortcuts, etc.

ER/KDP Checking Rule: Specific Checking Rules for ER/KDP inspection.

Link Checking Rule: Specific Checking Rules for link inspection.

Analysis Templates:

Critical Zone Definition: SPARQL Query definitions for identifying critical zones in a building.

Partial Model Filtering: SPARQL Query definitions for filtering out partial models, maybe based on critical zone definitions.

Partial Model Transformation: Mapping rules for specific software tools.

Evaluation Templates:

Prioritization Definition: Indicator based method for semi-automatically prioritization of results.

Selection Definition: Indicator based method for selection method proposition.


Version 1.0

/52


Figure 68: Template Dependencies

Figure 19 shows exemplary how the critical zone/element identification will work. Certain indicators

like room position in the building or the window area of a room will be specified in the ontology. A

SPARQL query will access these indicators and compare the actual building with the stored values for

identifying critical rooms.

Next to manual methods for generating such templates data mining methods will be proposed for

identifying semi-automatically relevant indicators.

Prioritization Definition

Selection Type Defintion

Critical Zone Defintion

Partial Model Filtering

Partial Model Transformation

Link Type Defintion

Link Model Filtering

IFC->OWL Mapping

XML->OWL Mapping

eBIM Rule Definition

ER/KDP Checking Rule Definition

Link Checking Rule Definition

Requirements Defintion

KP Defintion

Process Definition

Requirements/Process Templates

Integration Templates

AnalysisTemplates

EvaluationTemplates


Version 1.0

/52


Figure 19: Identification of Critical Zones/Elements

Building

Building Zones (Floor, Room,...)

Building Elements (Wall, Slab,...)

Building Shape, Location,

Orientation

Building Neighborhood

Building Usage, Type

Geometry Environment Function

Det

aili

ng

Zone Geometry, Position,

Orientation

Zone Neighborhood,

Aggregate

Zone Usage, Type


Det

aili

ng

Element Geometry, Position,

Orientation

Neighbour Element, Layer,

Aggregate

Element Type, Material


Mo

nito

ring System

Ind

icators

Building Zone Criteria

Building Element Criteria

PlatformOntology

Platform Ontology : Formalization of Indicators


Version 1.0

/52


6. Ontology Approach

The idea of the eeEmbedded ontology is to harmonize the different data coming from the different

domain models and external sources to make them feasible for further use in simulation tools and

evaluation tools. This procedure includes the inspection of the information for checking if the input

and the output got a certain quality. Furthermore, the ontology is used to support the users by

developing building designs in an early stage. This means it should help the users by designing before

certain geometry models already exist.

6.1. Idea of the eeE ontology

Various definitions for systems were published. The International Council on Systems Engineering

(INCOSE), a not-for-profit membership organization founded in 1990 pursuing the goal to share,

promote and advance the best of systems engineering, favour the system definition of Rechtin

(Rechtin, 1999), a famous American systems engineer:

“A system is a construct or collection of different elements that together produce results not

obtainable by the elements alone. The elements, or parts, can include people, hardware, software,

facilities, policies, and documents; that is, all things required to produce systems-level results. The

results include system level qualities, properties, characteristics, functions, behavior and

performance. The value added by the system as a whole, beyond that contributed independently by

the parts, is primarily created by the relationship among the parts; that is, how they are

interconnected”

An exact definition of engineering systems and subsystems within a modelling language is still under

research, but with regard to Rechtin’s definition two main characteristics of systems can be

distinguished: the system structure and the system behaviour. Next to these characteristics the

system environment is often mentioned in the lecture. Based on these three characteristics and

based on the eeE platform architecture the system ontology approach will be used defining the

system structure model containing the reduced domain models, the system processes describing

ontology related processes and the system environment forming the interface layer to the eeE

platform architecture integrated analysing and auxiliary tools. In contrast to the ScM process

definitions the ontology process description is descriptive and used to structure the SysOnto towards

different level of detail and to formulate reasoning rules for deriving implicit information.

6.2. Structure of the eeE ontology

Based on the previous formulated ideas for a system ontology (SysOnto) the core structure of it was

designed containing the mentioned eeBIM-model as substructure. Here, in contrast to HESMOS the

goal was to formulate the background models in a relationship to the used software and the current

processes to concretize the ontology-based link inspection and the corresponding rule definitions. In

contrast to ISES the inspection process in eeE comprises not only the prerequisite checking to

identify missing or wrong information in an early state, but also the check for the quality of the

results and the connected evaluation with a certain selection of results. Furthermore, the eeE

SysOnto aims to support the user by defining a correct system and an energy efficient building

design, so that the template definition and management is next to the inspection task an important


Version 1.0

/52


issue of the ontology usage. The defined core structure of the ISES ontology (Kadolsky,

Katranuschkov, & Dolenc, 2014)is the same like for the eeE ontology, so that the SysOnto comprises

three modules: The Structure Module, the Control Module and the Environment Module (see Figure

20).

The Structure Module contains the information of the different background models and the linking

between them. Furthermore, in this module the To-Be values like exchange requirements, KDPs, KPIs

and DVs are stored. The BIM- ontology (BIMOnto) forms the center model of the structure layer. It is

realized in a separate ontology, which is linked into the SysOnto. Following the core idea of ontology

use as a method for semantic integration geometrical information as not meaningful information and

unsuitable for fast pre-checking were not mapped, but referenced to the ontology. The additional

models can be represented and stored in different detail levels. Therefore, for these data types a

complete model as well as a meta-data model implementation was realized allowing three detail level

representation forms. On the detail richest level the information contained in origin models is nearly

completely mapped into the ontology structures. This opens up the possibility for a more detailed pre-

checking in the sense of plausibility checks regarding the content. On the next lower detail level not the

complete information, but only meta-data-information like the information about the average

temperature of certain measurements is transferred into the ontology, so that in the same way the

inspection is restricted to meta-data-checks. The lowest detail level is formed by the simplified multi

model ontology. The origin data sets of the domain models, this includes the building information model

data, and external data are only referenced to the ontology. Only the linking model and the linked

elements with their class definition are as semantic data transferred into ontology schema. This

corresponds to the linking method used in the HESMOS-project.

Within the Environment Module the communication with platform components like the ScM and with

external tools like the MMNav or the simulation tools are considered as ontology concepts. Here, the data

exchange with the different tools or components and the required information are defined. So, triggering

the KP check with the OMS and how it looks like and also the information back to the ScM, if a check was

successful or not is described in this ontology module. An optional task of this module specification is to

describe and identify alternative tools or methods like rule based calculations for an ananalysis step, if

one tool or service is not available.

The context of the defined structure and environment is described by the process and process steps

within the Control Module. Processes specify in a more abstract view the application of the ontology

like “Specifying KPs” or “Linking in eeBIM“. Thereby, it can make a different, if the process step

“Linking in eeBIM” belongs to an process regarding to summerly energy saving or winterly energy

saving, which could be expressed in the allowed data value range of the temperature. The process

steps describe the process in more detail and link to a certain SWRL-rule-operation or SPARQL query

representing ERs or MVDs. Since, links were restricted in a more abstract way up to here, the process

step formulates more concrete requirements to the environment and the structure to be fulfilled.

The control module especially plays an important role by the template management, cause link types

and linking templates or ER rule checking is dependent on the process or task these mentioned

operations should be executed. So, for cross project experience storing the required template

management makes a common task description for defining and identifying appropriate templates

necessary.


Version 1.0

/52


Figure 70: Core Structure of the SysOnto

6.3. System Structure Module

The structure module of the Ontology is on the generic level organised as multi-model structure

managing coequal elementary models and their corresponding links. Elementary models aggregate

model instances of the transferred existing data sources of possibly orthogonal domain models. The

explicit relations between the instances are formulated by linking their instances following the

predefined linking schema in the interface model. So, in contrast to other ontology representations

for BIM-modelling like the IfcOWL a BIM-centred information management is not a priori defined.

Before continuing with the organisation of the structure module a definition of the already

mentioned concepts of Elementary Model, Interface Model, Meta-Data Model and Structure Model is

presented.

As defined in HESMOS D2.1 "an Elementary Model also called Domain Model is an exchangeable

instance of a data model with a delimited domain and an appointed semantic. In the Ontology the

Elementary Model is represented by the class concept ElementaryModelElement and the inherited

subclasses BIMModelElement, UsageModelElement and ClimateModelElement forming the domains

together with the connected root elements and the further schema elements derived from the

corresponding data model. So, in contrast to the origin definition of an Elementary Model, which

does not require an explicit schema, the ontology definition of an Elementary Model comprises the

schema definition and the related instances.

As defined in HESMOS D2.1 a Link Model is a serializable instance of a data model with a schema that

stores references between elements of different Elementary Models. In the ontology the Link Model

Structure

Sub-Module

Control

Sub-Module

Environment

Sub-Module

Analysis

System

Modul

DEFINING

STOCHASTIC VARIABLES

STOCHASTIC DATA TO

EETEMPLATES

EETEMPLATE MGMNT &

CHOICE

LINKING IN EEBIM

(EEBIMONTO)

eeTemplatesGENERATING

STOCH. SIMUL. MATRIX

GENERATING

ENERGY SOLVER INPUT

IFC TO BIMONTO

IFC-Model

EETEMPLATES TO ADDITIONAL

ONTO

LINKING TO BIMONTO

INSPECTING EEBIMONTO

FILTERING FOR SENSITIVE ANALYSIS

eeBIMOnto

LINK EXISTENCE

CHECK

META-DATA CHECK

VALUE RANGE CHECK

VALUE DEPENDENCY

CHECK

MODEL LINK CHECK

COMPLEX LINK CHECK

eeBIMOnto-Subset


Version 1.0

/52


is represented by the class concept InterfaceModelElement detailed by the

eeBIMInterfaceModelElement for enhancing the BIM ontology model to an appropriate overall

building model supporting the envisaged energy analysis. In general the Interface Model contains on

schema level additional classes extending an Elementary Model to define connection points and the

relationships for connecting different Elementary Models. Next to the Elementary Model to

Elementary Model relationship, the Interface Model also specifies relations between the elements of

an Elementary Model and its Meta-Data in a Meta-Data Model referencing the origin data by URI-

address.

A Meta-Data Model comprises the Meta-Data of data belonging to a certain domain model. For this

reason the class concept MetaDataModelElement is divided into domain specific Meta-Data

elements like ClimateMetaModelDataElement, etc. Thereby, Meta-Data Models can also represent

sub-domains like the Material Meta-Data Model representing a sub-domain of the BIM-Domain.

Meta-Data Models offer the possibility to integrate data with no appointed semantic like simple text

notes or pictures as well as data, where a complete semantic integration would lead to an

unmanageable complexity of the ontology insufficient for logical reasoning.

As defined in HESMOS D2.1 a Multi-Model is a serializable composite of a set of Elementary Models

EM and a possibly empty set of Link Models having elements of EM as subject. In the ontology the

Multi-Model MM is represented by a Structure Model and the class concept StructureModel.

Thereby, the Structure Model encapsulates Elementary Models, a possible defined Interface Model

and a possible defined Meta-Data Model. Due to the reason, that a Meta-Model as part of the

Structure Model is not restricted to semantic data the ontology defines a Structure Model as

extension to a Multi-Model.

In ISES and as well in eeEmbedded the data exchange runs in one direction. This means in detail, that

the BIM-Model forms the centre of the Structure Model and the other models and their content are

only added to the BIM-Model and extend it to the eeBIM-Model. So, for eeEmbedded the structure

module of the SysOnto is a BIM-centred approach. This means, that the other domain and meta-data

models are radiating arranged and connected with the BIM-model. Thereby, the links are not directly

defining a connection between the BIM-model and the additional models. As mediator the

eeBIMInterfaceOnto was developed and keeps the background models unchanged. The underlying

idea is to provide maximum reuse of the specified ontology models by separating the links from the

background models. Next to an interfaced relationship between the BIMModel and the additional

models, a relationship between the BIMModel and a meta-data model is considered enabling the

possibility of integrating the additional models on different detail levels.

6.4. BIMOnto

Similar to the HESMOS and ISES project the BIMOnto is a modified version of the IfcOnto developed

by Beetz (Beetz, van Leeuwen, & de Vries, 2009). For the use in eeEmbedded the schema was

reduced and only relevant elements like building elements or spatial elements were considered in

the BIM-ontology. The IfcOnto is nothing else than an OWL-representation of the IFC-standard.

Thereby, the IfcOnto is the result of a mapping tool and the general mapping from EXPRESS to OWL

allowing the OWL-transformation with any arbitrary EXPRESS-schema as starting point. Cause of the

increased availability of open standard interfaces IFC2×3 as opposed to IFC 2×4 was preferred.


Version 1.0

/52


6.5. eeBIMInterfaceOnto

The main task of the eeBIMInterfaceOnto is firstly to define the Interface between the BIMOnto and

the other Domain Model Ontologies. Therefore, it comprises the relationships between these

Ontologies as well as the relationships between the BIM-Ontology and the Met-Data Ontology for

Domain Models represented in a lower level of detail.

The IFC and the origin IfcOnto are designed for a widespread application and not for a specific

climate performance analysis of a building. Due to this fact elements like façade or thermal envelope

typical for climate applications are not considered. Cause of aggregating elements to a higher level

element a BIM-model extension with such elements would facilitate the navigation through the

model. Beside this, an easier navigating leads to a more efficient linking. Furthermore, these new

element definitions provide further rule implementations for link validation.

Next to the creation of connection points and relations, the interface ontology is used to reduce the

complexity of the IFC and the IfcOnto and to offer alternative and compact descriptions for energy

related issues. In eeEmbedded this holds mainly for the Space-Boundary Description as well as for

the Property-Definition Relation as mentioned in the previous section. The Space-Boundary

Description was reduced to an Adjacency Description express the adjacency between rooms. The

Property-Definition Relation in IFC is a relation entails several further relations needed to connect a

building element with a certain property. In the Interface Ontology this chain of relations was

reduced to one relation.

Third, the Interface Ontology formulates energy specific properties for the building elements and the

spatial elements. Here, the IFC pre-defined property-sets and quantity-sets were not used and

general and thermal material properties were specified.

All new considered elements are in an abstract or/and aggregation relationship to the origin IFC

elements. Thereby, the aggregation relationships are mostly defined on certain (co)domains with

certain cardinalities.

For connecting climate information outside the building the already mentioned façade was

introduced as new concept extending the BIM-Model. In climate performance analysis the façade,

which divides the building in new parts, is directly related to the orientation of a building side.

Thereby, the façade can be defined as follows:

A façade is the aggregation of walls, windows, doors or parts of them, which can be no-ambiguously

assigned to a building side.

So, a façade is not a spatial element, but a building element with a certain orientation. Next to the

façade and in a kind of an intermediate aggregation level façade elements were defined aggregating

a wall and its windows or doors. The resulting aggregation levels of the building side are presented in

figure 21.


Version 1.0

/52


Figure 8: Façade, Façade Elements and Walls of a Building

The definition of façade elements has also other reasons. In IFC the relation between a wall and its

installed door or window is realized by using the IfcOpeningElement and the Relations

IfcRelVoidsElement and IfcRelFillsElement. Though the IfcDoor and the IfcWall elements are also

connected with a spatial structure element (IfcBuildingStorey) using the relation

IfcRelContainedInSpatialStructure an unambiguous assignment is not possible by only considering

this relationship. So, one IfcRelContainedInSpatialStructure relation can connect more than one wall

and more than one window describing, that a storey consists of several walls and windows. Without

using IfcOpeningElements and the corresponding relations, it will be impossible to identify correct

assignment between the windows and the walls. For the ontology use and for the pre-checking of

linking, the openings in walls, roofs or slabs are not relevant, because Climate or Material data are

directly linked to the elements fills the openings. The introduction of façade elements still ensures

the identification of the assignment. Next to the more technical use of the façade elements, there

also exists an integration reason. Façade elements can represent prefabricated façade elements with

preinstalled windows. The complete description of such elements could be done in external source

files, which will not be integrated into the ontology, but only linked. A link between IfcWall and the

external source file would be incorrect cause of the combined description of wall and window in the

source file. So, to allow a correct linking the façade elements as connecting points were introduced,

considering the combined description.


Version 1.0

/52


The definition of additional elements like facades opens up the possibility, that for example material

data can be directly related to these elements and material data doesn’t have to be split into wall

material data and window material data and then added to these building elements. This especially

holds for KDPs or KPIs, which could then be defined for an aggregate element.

6.6. Environment

The Environment Module forms the boundary layer describing the dependencies between the

structural information base and the other platform components, external tools and models. So, this

module provides the information for invoking a KDP check and returning the results back to the

corresponding components or tools.

Figure 92: Checking KDPs

Another idea of this module definition is to find alternative tool support in case of unavailable planed

tools. Thereby, it is not aimed to capture all functionalities of a tool with the ontology specification.

So, the SystemEnvironmentOnto cannot be seen as product ontology covering several tool and tool

functionality descriptions of the AEC-field. More than that, the SystemEnvironmentOnto is used to

formulate the communication and the exchange requirements between the System Structure and

external infrastructures for a certain process or process step. Next to the software integration the

Environment Module serves also to describe the user and the role of the user. So, it offers the

possibility to formulate an ontology based access management.

ScM

OMS

OK or NOK

BIM+

Element + Colour Code

InvokesKDP Check


Version 1.0

/52


Figure 103: Identifying alternative tools/services

6.1. Simplified Link Model

The simplified ontology model is used to describe the complete linking between the different domain

models and the external data. In contrast to the semantic reached approach integrating semantic

data from the different domain models this simplified approach harmonizes only the link information

in an unified link model. So, the link model consist of three different components: the elements, the

element classes and the link element. The elements represent the elements from the different

domains which has to be linked with each other. They got the same ID as in the origin models. For

supporting the filtering the elements are also connected with their related classes. The actual link is

described with the link element. Link elements can be linked with different elements, so that n-ary

links can be realized.

MAPPING/COMBINER

TOOL

FILTER TOOL 2

SIMULATION MODEL

FILTER TOOL 1

COMBINED MODEL

SIMULATION SOFTWARE

STRUCTURE MODEL

BIM MODEL

EEBIMINTERFACE MODEL

CLIMATE MODEL


Version 1.0

/52


Figure 114: Simplified Link Model Approach

-ID-Description-Link to ext Model

Element

-ID-Description

LinkElement

0..*

-ID-Description

ElementClass instanceOf

-ID-Description

LinkModel

11 1


Version 1.0

/52


7. Ontology Platform

As core information infrastructure the ontology platform is responsible for storing the different multi

model information and offering a certain access to the information storage. Furthermore, it provides

services for checking the quality of the required information and generated results.

7.1. Static Model

The ontology platform consists of four main layers: Ontology Access Service Layer (OAS), Ontology

Management Services Layer (OMS), Ontology Verification Services (OVS) and the Ontology

Repository Layer.

The Access Service Layer provides the access to the ScM for receiving checking requests and sending

results back, to EDM/BIM+ for receiving IFC and Link Models and to the Simulation Tools for

generating simulation models and receiving simulation results.

The ontology management service layer provides:

Extending services for extending BIM to eBIM, etc.

Transformation services for mapping ifc step to ifcOWL, etc.

Filtering services for filtering out partial models with regard to the defined ERs, etc.

Linking services for ESIM data to BIM data, etc.

The verification service layer provides:

Prerequisite checking services for checking ERs to execute the next step, etc.

Result quality checking services for checking KPIs, etc.

Error handling services for correcting design parametrs with regard to the KDPs, etc.

The ontology repository layer contains the storage for the ontology schema, the instances and the

templates.


Version 1.0

/52


Figure 25: Ontology Platform

Each service comprises different subservices. So, the integration of ifc data into the ontology

addresses different services and will be exemplary described.

The combination of models and integration of the data in the ontologies is done with the following

approach:

Take the IFC2x3 schema and let Express2OWL (Beetz, van Leeuwen, & de Vries, 2009) create the whole OWL schema

Manually edit the OWL schema by deleting the classes and properties which are not needed

Use Jastor (Ben Szekely, Joe Betz, 2013) to create the Java classes from the OWL classes

Instantiate ontology by creating individuals with Apache Jena (Jena, 2010-2013)

To gain the OWL classes for IFC entities we use the Express2OWL tool from (Beetz, et al., 2009).

When generating the OWL classes and properties of the IFC2x3 schema with the Express2OWL tool it

creates per IFC one OWL class and for each attribute a corresponding owl:ObjectProperty which

connects the source and target class with each other. When a primitive type like String in Express is

linked it generates an owl:DatatypeProperty with a range of xsd:string. While it converts the whole

IFC schema to an appropriate OWL file there are many classes and properties which we don’t need

for the ISES project or we want to use another data representation instead of some properties and

classes e.g. to assign energy-related data to building entities. The deletion also leads to a higher

performance when querying or reasoning the data. The whole IFC representation in OWL is

generated in a 1.358KB data file. The stripped file has a size of circa 100KB. After preparing the

Ontology Access Services

Access to ScM Access to BIM+ Access to SIM

Ontology Management Services

Linking Services

Filtering Services

Transform. Services

Extending Services

Ontology Verification Services

Error Handling Services

Prerequisite Checking Services

Result Quality Checking Services

Ontology Repository

Schema/Instances Storage

Access to EDM


Version 1.0

/52


schema Jastor generates the corresponding Java classes of all ontologies (IFC, Energy, Meta) and

together with Apache Jena the instances can be mapped to OWL individuals.

This approach allows a type safe programming e.g. when the ontologies change the Java compiler

recognizes this. This leads to fewer errors when instantiating the individuals at runtime because the

errors can be seen at compile-time. Actually, Protégé (Protégé) also provides the export of Java

classes from OWL classes. But as mentioned before we are not using the OWL-API which is used for

the generated Java implementation classes by Protégé. Furthermore, Jastor uses Apache Jena which

does not fit with the OWL-API.

7.2. Dynamic Model

Exemplary for the key point setup scenario the usage of the ontology platform will be stepwise

demonstrated.

Figure 25: KP Workflow (Guruz et al., 2015)

BIM SERVER

Ontology

Management Services

1 KEY POINT Setup: Scenario Manager (CIB)

Check clashes

Prepare a set of DVs and process pattern

Related to DVs - prepare a set of KPIs, process pattern and choose participating domains

Related to KPIs - prepare a set of KDP process pattern and choose participating domains

2 Requirements Setup: Scenario Manager (CIB)

Check consistency

3 Requirements Decomposition: Scenario Manager (CIB)

4 Storage of Key Points: Scenario Manager (CIB)

5 Combine Key Points and Processes: Scenario Manager (CIB), Collaboration Server (IABI)

Central storage in Ontology.

Central Storage in Ontology and BIM Server


Version 1.0

/52


Storage of KPs

Activities ModelsSAve

Onto Repository

ScM

OMSSave

Save

ScM

OMS

KP Model

KP Setup

Onto Repository

KP Model

Activities ModelsKP Model Generation KP Model

Requirements Setup

Activities ModelsRequirements Setup BIM, Link Model, Requirements Model

ScM

MMNav

ReqSetUP

OMS Onto Repository

BIM, LinkModel, Req Model

BIM, LinkModel, Req Model

Consistency Check

Activities ModelsCheck, Return OK/NOK

Onto Repository

ScM

OMSCheck

OK/NOK

Check


Version 1.0

/52


Figure 26: KP Workflow (Detailed)

ScMBPMN Model

Process Definition

File Server

Activities ModelsBPMN Model Generation BPMN Model

Combining KPs with Processes

Activities ModelsCombining KPs & Processes

Onto Repository

ScM

OMS

BPMN Model,

LinkModel

BPMN Model,

LinkModel

BPMN Model, Link Model


Version 1.0

/52


8. Conclusion and Outlook

The main goal of Deliverable 5.1 was to provide the integration of different data coming from

different sources and to provide a controlled workflow based on Key Point inspection to come up to

an energy efficient building a System Analysis Ontology (SysOnto. To come up to such an overall

framework a system analysis ontology (SysOnto) embedded in an appropriate ontology platform

were realized as follows:

(1) First specification of a BIM Ontology containing the IFC-concepts necessary for the description of the building elements serving as input for the simulation tools.

(2) Specification of a link concept describing the links between the BIM Ontology and these additional ontology concepts, which results in an eeBIM ontology model (OntoBIM). This includes the specification of semantic links, as well as the extension of the BIM ontology with appropriate concepts serving as connection points.

(3) First specification of an Environment Ontology describing the used simulation software and the related simulation models as well as the mapping services creating the simulation models based on the ontology models. This includes the specification of the linking between simulation models and the eeBIM model and hence the definition of the input of the simulation software.

(4) Specification of a Process Ontology concept describing the context the eeBIM model and the simulation software will be used in, and defining the process steps and the related linking rules, which will operate on the ontology.

(5) Specification of a KP and Linking Rule concept enabling pre-checking the completeness and correctness of the linking between the BIM model and the mentioned external (non BIM) information and the inspection of the quality of the generated results. This comprises inspection/analysis of the existence of links, the meta-data of the linked elements and the data value ranges of certain elements in dependence of the focused task.

In this deliverable the core structure of the ontology framework was presented. This includes the

core specification of the domain models and of the envisaged linking concept. Furthermore, the

concept of the surrounding platform was presented. In the next steps and in the next deliverables

the ontology structures will be more detailed specified. Parallel to this the functionalities of the

platform will be developed to follow the idea of an controlled workflow framework for designing

energy efficient buildings.


Version 1.0

/52


References

Apache Software Foundation. (29. December 2013). The Apache Ant Project. (Apache Software

Foundation) Abgerufen am February 2014 von http://ant.apache.org/

Baumgärtel K., K. P. (2013). ISES Deliverable 5.1: Prototype of the multi-model integration services.

Brussels: ISES Consortium.

Beetz, J., van Leeuwen, J., & de Vries, B. (2009). IfcOWL: A case of transforming EXPRESS schemas

into ontologies. Artificial Intelligence for Engineering Design, analysis and Manufacturing.

Ben Szekely, Joe Betz. (4. June 2013). Jastor. (IBM) Abgerufen am 20. January 2014 von Jastor:

http://jastor.sourceforge.net/

Black, P. E. (2012). Greedy algorithm. Dictionary of Algorithms and Data Structures.

Geißler, M. C., Guruz, R., & Woudenberg, W. v. (2014). eeEmbedded Deliverable D1.2: Use case

scenarios and. Brussels: eeEmbedded Consortium .

Guruz, R., Rodriguez, G. C., & Geißler, M. C. (2015). eeEmbedded D2.1 Holistic multi-disciplinary Key

Point-based design framework. Brussels: eeEmbedded Consortium.

Jena, A. S. (2010-2013). http://jena.apache.org/. Abgerufen am June 2013 von

http://jena.apache.org/

Kadolsky, M., Baumgärtel, K., & Scherer, R. (2014). An Ontology Framework for Rule-Based

Inspection of eeBIM-Systems. Procedia Engineering, S. 293-301.

Kadolsky, M., Katranuschkov, P., & Dolenc, M. (2014). ISES Deliverable D3.1: Ontology specification.

Brussels: Ises Consortium.

Protégé. (kein Datum). Protégé, Stanford Center for Biomedical Informatics Research, Stanford

University School of Medicine, University, USA. (Stanford University School of Medicine)

Abgerufen am 23. August 2012 von http://protege.stanford.edu/

Rechtin, E. (1999). The Extension of Systems Architecting to the Architecting of Organisations.

Solvik, K., & Kaiser, J. (2014). Requirements for knowledge-based design support and templates.

Brussels: eeEmbedded Consortium.

eeembedded d5.1 interoperability and ontology...

Documents