eeembedded d5.1 interoperability and ontology...
Post on 14-Jul-2020
1 Views
Preview:
TRANSCRIPT
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
Page 2/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.
5.1 Interoperability and ontology framework
Version 1.0
Page 3/52
© eeEmbedded Consortium www.eeEmbedded.eu
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)
5.1 Interoperability and ontology framework
Version 1.0
Page 4/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 5/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 6/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 7/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 8/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 9/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 10/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 11/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 12/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 13/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 14/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 15/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 16/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 17/52
© eeEmbedded Consortium www.eeEmbedded.eu
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:
5.1 Interoperability and ontology framework
Version 1.0
Page 18/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 19/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 20/52
© eeEmbedded Consortium www.eeEmbedded.eu
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….
5.1 Interoperability and ontology framework
Version 1.0
Page 21/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 22/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 23/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
Invoking External Services
Invoking External Services
Invoking External Services
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
5.1 Interoperability and ontology framework
Version 1.0
Page 24/52
© eeEmbedded Consortium www.eeEmbedded.eu
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“
5.1 Interoperability and ontology framework
Version 1.0
Page 25/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 26/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 27/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 28/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 29/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 30/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 31/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 32/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 33/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 34/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 35/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 36/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
Geometry Environment Function
Det
aili
ng
Element Geometry, Position,
Orientation
Neighbour Element, Layer,
Aggregate
Element Type, Material
Geometry Environment Function
Mo
nito
ring System
Ind
icators
Building Zone Criteria
Building Element Criteria
PlatformOntology
Platform Ontology : Formalization of Indicators
5.1 Interoperability and ontology framework
Version 1.0
Page 37/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 38/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 39/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 40/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 41/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 42/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 43/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 44/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 45/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 46/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 47/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 48/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 49/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 50/52
© eeEmbedded Consortium www.eeEmbedded.eu
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
5.1 Interoperability and ontology framework
Version 1.0
Page 51/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
5.1 Interoperability and ontology framework
Version 1.0
Page 52/52
© eeEmbedded Consortium www.eeEmbedded.eu
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.
top related