Post on 06-Aug-2020
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 – D2.3
Holistic KPI based design methodology
Responsible Authors:
Romy Guruz, Gloria Calleja-Rodríguez, Marie-Christine Geißler
Co-Authors:
Jens Kaiser, Pit Stenzel, Raimund Zellner, Theodora Pappou, Francisco Forns-Samso,
Tuomas Laine, Raphael Schär, Stefan Bürgin, Kenneth Solvik & Robert Schülbe.
Due date: 31.03.2015
Issue date: 31.03.2015
Nature: Other
Coordinator: R. J. Scherer, Institute for Construction Informatics, Technische Universität Dresden, Germany
D2.3 Holistic KPI based design methodology
Version 1.0
Page 2/87
© eeEmbedded Consortium www.eeEmbedded.eu
Start date of project: 01.10.2013 Duration: 48 months
Organisation name of lead contractor for this deliverable:
Institute for Construction Informatics, Technische Universität Dresden, Germany
History
Version Description Lead Author Date
0.1 Initial document and structure Guruz (CIB) 28.08.2014 0.2 Extended Structure Guruz (CIB) & Calleja (CEM) 17.09.2014
0.3 Content, Tables and Data Structure Guruz (CIB) & Calleja (CEM) 11.10.2014
0.4 Refining Part A Guruz (CIB) 24.11.2014 0.5 Refining Part B Calleja (CEM), Geißler (BAM) 25.11.2014
0.6 Discussion/ Restructuring/ Revised version with comments
Guruz (CIB) & Calleja (CEM) 02.02.2015
07 Partner Input EAS, IET, DDS; NEM, SOF, CEM chapter 2, 3, 4
EAS, IET, DDS, NEM, SOF, CEM 11.12.2014
0.8 Restructuring/ Revise/ Prefinal version with comments
Guruz (CIB) & Calleja (CEM) 05.01.2015
0.9 Matrix development Guruz (CIB) & Calleja (CEM) Geißler (BAM)
16.02.2015
1.0 Final Revise Guruz, Schülbe (CIB) & Calleja (CEM) Geißler (BAM)
23.03.2015
Copyright
This report is © eeEmbedded Consortium 2015. 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
Guruz, R., Calleja-Rodríguez, G. & Geißler, M.-C. (2015): eeEmbedded Deliverable D2.3: Holistic KPI
based design methodology © 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.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 3/87
© 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)
D2.3 Holistic KPI based design methodology
Version 1.0
Page 4/87
© eeEmbedded Consortium www.eeEmbedded.eu
Abbreviations
BACS Building Automation and Control Systems
BIM Building Information Modelling
CFD Computational Fluid Dynamics
DV Decision Value
eeE eeEmbedded
ESIM Energy System Information Model
ER Exchange Requirement
FM Facility Management
GUID Globally Unique Identifier
HVAC Heating Ventilation and Air Conditioning
IDM Information Delivery Manual
IFC Industry Foundation Classes
KP Key Point
KDP Key Design Parameter
KPI Key Performance Indicator
LCC Life Cycle Costing
LCA Life Cycle Assessment
LoD Level of Detail
LOD Level of Development
TEB Thermal Energy Building Simulation
TES Thermal Energy System Simulation
TBM Technical Building Management
UML Unified Modelling Language
D2.3 Holistic KPI based design methodology
Version 1.0
Page 5/87
© eeEmbedded Consortium www.eeEmbedded.eu
TABLE OF CONTENTS
Part A ............................................................................................................................................................................ 7
1. eeE Design Methodology Specifications beyond Implementation .................................................................... 8
1.1 Used Techniques - from Decision Pattern to specified Workflows ______________________________8
1.2 Workflow Urban Design ______________________________________________________________10
1.3 Workflow Early Design _______________________________________________________________18
1.4 Workflow Detailed Design ____________________________________________________________28
Part B .......................................................................................................................................................................... 39
2. Template Specifications beyond Implementations .......................................................................................... 40
2.1 Libraries structure __________________________________________________________________41
2.1.1 Architecture domain ....................................................................................................................43
2.1.2 ESIM domain ................................................................................................................................44
2.1.3 HVAC domain ...............................................................................................................................48
2.1.4 BACS domain ................................................................................................................................51
2.1.5 FM domain ...................................................................................................................................55
2.1.6 Simulation domain .......................................................................................................................56
2.1.7 Life Cycle Assessment domain .....................................................................................................58
2.1.8 Life Cycle Cost domain .................................................................................................................59
2.1.9 eeE cross-domain templates ........................................................................................................60
2.2 Templates content __________________________________________________________________65
2.2.1 Architecture domain ....................................................................................................................66
2.2.2 ESIM/HVAC domain .....................................................................................................................67
2.2.3 BACS domain ................................................................................................................................68
2.2.4 FM domain ...................................................................................................................................72
2.2.5 Simulation domain .......................................................................................................................73
2.2.6 LCA domain ..................................................................................................................................74
2.2.7 LCC domain ..................................................................................................................................74
3. Key Point Specifications beyond Implementations .......................................................................................... 75
3.1 Preliminary Concepts and Roadmap ____________________________________________________75
3.2 Sustainable Score - Certification Systems in eeE ___________________________________________76
3.2.1 Standardized certifications ..........................................................................................................76
3.2.2 eeE Sustainable Value (eeSV).......................................................................................................77
3.3 eeE Key Point Formalisation___________________________________________________________78
3.3.1 Level 1: Decision Value (DV) ........................................................................................................78
3.3.2 Level 2: Key Performance Indicators (KPI) ...................................................................................78
3.3.3 Level 3: Key Design Parameter (KDP) ...........................................................................................79
3.4 eeE Sustainable Value Example ________________________________________________________80
Conclusions ................................................................................................................................................................. 82
References ______________________________________________________________________________83
Annex __________________________________________________________________________________84
D2.3 Holistic KPI based design methodology
Version 1.0
Page 6/87
© eeEmbedded Consortium www.eeEmbedded.eu
Executive Summary
The objective of D2.3: Holistic KPI based design Methodology is to go forward from conceptual
specifications to implementation specifications. For that purpose, conceptual outcomes and
approaches of the first and a half year of the project have been collected and their IT implementation
has been envisioned in order to identify and describe in further detail the implementation
requirements and steps.
Therefore, this document addresses firstly the overall specifications of eeE Methodology
implementation, secondly it provides implementation specifications for Templates and thirdly it
describes Key Point specifications beyond implementation. The current deliverable is a bridge
between end-users concepts and developers work, it provides reference information for Virtual Lab
IT developing.
D2.3 is structured into 2 Parts, Part A provides the complete eeE workflow (T2.7) regarding to
functional requirements based on detailed process task steps and as well including the reference to
the, in Part B specified, Template and Key Point specifications (T2.3-T2.6).
The first chapter collects and summarizes the specifications steps from the beginning of the
project till the current point. Specifically, outcomes from T1.1, T1.2 and T1.5 are merged and
updated after partners discussions. The results are detail implementation specifications for
the eeE Use Cases which include links to design tasks, information exchanges and UML
workflows. It also includes the references to specified templates (see 3.) and specified Key
Points (see 4.)
The second chapter is focused on eeE Templates. It presents the library structure and the
content of eeTemplates as a premise step for implementation.
The third chapter is discussing the Key Point formalization for the eeE Sustainable Value. The
Key Points are specified as basis for the development of the eeE ontology to support the
design process of energy-efficient and sustainable buildings optimally embedded in their
neighbourhood.
The forth chapter of this report will explain the conclusions, the work done and the
upcoming work to be done
Following partners were involved and each partner has contributed from their expert viewpoint:
This deliverable was led by CIB with a great support of CEM and BAM.
The content of this deliverable was elaborated and discussed in frequent web conferences between
all project partners. CIB and CEM were leading discussions and have contributed in all tasks.
EAS/IET/GRA/DDS/SOF/SAR/STA/RIB contributes to Part B.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 7/87
© eeEmbedded Consortium www.eeEmbedded.eu
Part A
D2.3 Holistic KPI based design methodology
Version 1.0
Page 8/87
© eeEmbedded Consortium www.eeEmbedded.eu
1. eeE Design Methodology Specifications beyond Implementation
This report can be viewed as the final specification report by the end user. Here, all previously
developed concepts and specifications flowing together. D2.3 provides the basis for future work in
WP3-W8. Based on WP1, D2.1, D2.2 and the results of T 2.1-2.6 were synthesizing in a holistic,
hierarchically structured design methodology.
Controlling on design process and monitoring with the help of Key Points in 3 decision making levels,
as well as support of domain related detailing knowledge templates. The methodology was built
upon best practice experience and is further elaborated and enhanced to incorporate the new ways
of BIM working and include massively simulation techniques based on computational engineering as
well as on cost, energy and CO2 prognosis simulation in order to estimate the whole life-cycle picture
of a building already in the urban, early and detailed design phases.
Forthcoming Part A provides the complete eeE workflow (T2.7) regarding to functional requirements
based on detailed process task steps and as well including the reference to the, in Part B specified,
Template and Key Point specifications (T2.3-T2.6).
1.1 Used Techniques - from Decision Pattern to specified Workflows
To get approaching implementation plan, 4 different specification steps and much more iterations
were necessary. This shall give a short overview on how we came up to this result:
Step 1: Decision Pattern & High Level Use Cases (Deliverable 1.1)
At the beginning of our discussions we developed the high level use cases as a means to explore the
scope of the project and also to determine which kind of decision was to be made by which actor. As
a result of this analysis, we developed 3 process patterns which define the 3 level decision making.
Step2: Project Use Cases (Deliverable 1.2)
From the decision patterns the Key Points were evolved and in this step, the identified eeE use cases
have been thoroughly investigated to also identify every subtask of the actors. Out of the Key Point
classification the appropriate Key Points then have been assigned to the different tasks respectively
the decision domains of the use cases.
Step3: Generic Workflows (Deliverable 1.5)
Within the project use cases we searched for commonalities regarding the workflow. We extracted 4
different, possible workflows: the Key Point setup, Designers’, Analysts’ and Decision making’ views,
to technically specify all required components for our eeE system architecture.
Step4: Detailed Workflow for Key Points (Deliverable 2.1)
In this step the workflows have been greatly elaborated, refurbished and afterwards presented in the
direction of Key Points. The goal of this was to identify those components that are important to solve
the new developed Key Point design methodology. The findings of this were later incorporated into
the already existing eeE System Architecture.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 9/87
© eeEmbedded Consortium www.eeEmbedded.eu
Step5: … & now in upcoming implementation roadmap (Deliverable 2.3)
The following sequences are a combination of task information as well as a further development and
adaption to individual tasks, via UML sequence diagrams. The architecture components described in
D1.5 and D2.1 are already assigned to the corresponding steps.
The UML diagrams are refined for each single task we had defined in use cases and are combined
with the following table: please note that the grey field is reference to the BPMN use cases [in this:
1.0 (BPMN task number), UD (Urban Design) : <Name of the task>]. Project tools, services and
responsible project partners are set.
Actors1: <> 1.0 UD: Project Set Up Pattern 42: DECISION MAKER
1 Detailed task < tasks to be fulfil >
2 Information Exchange IN
Information source < information received >
Sender actor < actors >
3 Information Exchange OUT
Information delivery < information to be send >
Receiver actor < actors >
4 Specifications < Templates > < Key Point >
Specified Workflow on this task (UML)
In the 4 Specifications, the later in Part B specified task related TEMPLATES and can be found in
chapter XXX and KEY POINTS are referenced directly to the tables in Chapter 4.3.
1 All involved actors in the Use Case.
2 Pattern 4: is the reference of generic workflow structure, this workflow was worked out.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 10/87
© eeEmbedded Consortium www.eeEmbedded.eu
1.2 Workflow Urban Design
General Information:
During Urban Design Phase, design and energy concepts have to be created embedded in the existing
environment. Therefore, information about topography, neighbouring buildings and available energy
systems as well as the KDP to-be which define constraints are needed as input. In eeE an Energy
System Information Model (ESIM) data structure will be developed, which enables the energy
system engineer to create the energy system concepts including generation/storing/distribution,
exchange and energy recovery, to consider supply routes and rules from existing energy
infrastructure and interactions with other buildings and/or energy storage systems. Detailing
templates with knowledge-based information, information from catalogues or norms/standards and
assumptions can be used to enrich roughly designed building and energy system models for fast
generation of design alternatives. To select/discard design alternatives by verification with Key
Design Parameters (KDP) such as size/volume of the building to fulfil the local restrictions, required
gross floor area per function or technical qualities of the core and shell, the Level of Detail (LoD) 100
of the models and templates defined by the Exchange Requirements (ER) for the Urban Design Phase
in D1.3 Interoperability and collaboration requirements [Calleja et al. 2014] has to be fulfilled.
For reliable analysis of alternatives, at this stage, combined Computational Fluid Dynamics (CFD) and
energy calculations as well as Life Cycle Costing (LCC) have to be performed with basis accuracy
which is defined by the Level of Approximation (LoA) 100. Therefore, stochastic scenarios to study
the influence of uncertainties such as climate conditions, energy provision, price developments etc.
on energy, emission and Life Cycle Cost Key Performance Indicators (KPI) are created and
interpreted by the CFD, energy and LCC experts.
At the end of Urban Design Phase at Level of Development (LOD) 100, decision about the
orientation, the form of the building, the thermal standard of the shell, the window-to-wall area
ratio, the zones and the energy systems, has to be taken, to fulfil best the clients’ needs which are
represented by the Decision Value (DV) and to embed the building optimally in its neighbourhood.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 11/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: All Task 1.0 Project Set Up Task 1.1 Check consistency
Pattern 1: PROJECT SETUP View
Detailed task
- Set up Project (Infrastructure) - Set up Project Key Points (all levels) - Set up workflow(s) including participating partners (roles)… - Specify phases and model development (LOD, LoD) - Set up and manage Templates
Information Exchange IN
Information source All Requirements (Client, Regulations etc.)
Sender actor ---
Information Exchange OUT
Information delivery - Key Design Parameter to-be - Key Performance Indicators to-be - Decision Values to-be - Working processes/involved actors
Receiver actor - Planners Domain - Simulation Domain - Decision-Making Domain - All
Specifications - -
DECISION SUPPORT
User incl. Navigator& Scenario Browser
1 Project setup/ settings
2 Setup KEY POINT framework
4 LOD, LoD, ER specification
3 Workflow setup
Resource Mgmt. Service/ Data Storage (BIM Server)
see KEY POINT workflow
see KEY POINT workflow
5 Set up and manage templates
Collaboration Services (see KP workflow)
Resource Mgmt. Service (Template Server)
Open GUI Decision Maker View
Collaboration Bus - BIM--it (Manager)
Handover Achitecture Domain
Send message to Architecture Domain
+ all services register with the central BCF server to set up the project infrastructure (BIM Manager)
Ontology
Management Services
BIM SERVER
D2.3 Holistic KPI based design methodology
Version 1.0
Page 12/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: 1 Architectural Domain
Task 1.2 Create design cubature options
Pattern 2: DESIGNERs’ View
Detailed task - Create cubature options - Develop stories - Define verticals and architectural zones/spaces
Key Point Does the design variant(s) meet the Key Design Parameter to-be? If so: Hand over the variant to the Simulation Domain, ESIM Domain and LCC Domain. If not: Improve the design variant.
Information Exchange IN
Information source City GML (not yet decided)
Sender actor ---
Information Exchange OUT
Information delivery - BIMUDP=BIM (Allplan IFC 2x4)
Receiver actor - Simulation Domain - ESIM Domain - LCC Domain
Specifications Templates 2.2.1 Key Point UD 3.0 - 3.3
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create Design in specified LoD and LOD
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
1 ALLPLAN
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
OR
ok, ready for SIM/ANA
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)SIM/ANA domain
Handover SIM/ANA domain
1 ALLPLAN
D2.3 Holistic KPI based design methodology
Version 1.0
Page 13/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: 6 Simulation Dom.
Task 1.3 CFD Simulation (3D Wind)
Pattern 3: SIMULATION ANALYSIS View
Detailed task - Create stochastic scenarios / parametric simulations - Run simulation - Interpretation of results
Key Point Does the design variant meet the Key Performance Indicators to-be? If so: Approve the results for the ESIM Domain. If not: Send an optimization request to the Architects e.g. to optimize the orientation.
Information Exchange IN
Information source
eeeBIMUDP=BIM
Sender actor Architectural Domain
Information Exchange OUT
Information delivery Simulation results I
Receiver actor Simulation Domain
Specifications Templates 2.2.5 Key Point 2.4
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Template Configuration (BIM Server)
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
6 3D Wind
Preprocessing
Get results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Template configuration
Parameter Definition
Simulation & Analysis Mgmt. Services
Preprocessing
Simulation & Analysis Mgmt. Services
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to eSIM
Handover eSIM
D2.3 Holistic KPI based design methodology
Version 1.0
Page 14/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: 2 eSIM Domain
Task 1.4 Create energy supply options (eSIM)
Pattern 2: DESIGNERs’ View
Detailed task
- Create energy supply concepts including generation / storing / distribution, exchange and energy recovery. - Consider supply routes and rules from existing energy infrastructure - Create interactions with other buildings and/or energy storage systems - Develop distribution route - Develop controller algorithms to minimize energy consumption.
Key Point Does the design variant meet the Key Design Parameter? If so: Hand over the variant to Simulation Domain and LCC Domain. If not: Improve the energy system design variant.
Information Exchange IN
Information source eeeBIMUDP=BIM
Simulation results I
Sender actor Architectural Domain
Simulation Domain
Information Exchange OUT
Information delivery eeeBIMUDP=ESIM (ES+DACS)
Receiver actor Simulation Domain LCC Domain
Specifications Templates 2.2.2 Key Point UD 3.4 – 3.7
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create eSIM Design
Upload eSIM Model
KEY POINT check KDP
Send KDP and model to next design domain
eS Designer/ eSIM GUI
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload eSIM model
KEY POINT check KDPnot ok
OR
ok, ready for SIM/ANA
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)SIM/ANA domain
Handover SIM/ANA domain
eS Designer/ eSIM GUI
D2.3 Holistic KPI based design methodology
Version 1.0
Page 15/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: 6 Simulation Dom.
Task 1.5 Energy Simulation Pattern 3: SIMULATION ANALYSIS View
Detailed task
- Create stochastic scenarios / parameterisation (pre-processing) - Risk analysis is missing as a part of the analysis tool - Run Simulation - Interpretation of results
Key Point
Does the design variant meet the Key Performance Requirements? If so: Approve the results for the LCC and Decision-Making Domain. If not: Send an optimization request to the Architectural Domain e.g. to optimise the A/V ratio should be in the range [x - y] or e.g. to the ESIM Domain e.g. to optimize the distribution system length.
Information Exchange IN
Information source eeeBIMUDP=BIM+ESIM CFD simulation results
Sender actor Architectural Domain ESIM Domain Simulation Domain
Information Exchange OUT
Information delivery Simulation Results I
Receiver actor LCC Domain Decision-Making Domain
Specifications Templates 2.2.5 Key Point 2.0 – 2.2
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
Energy Simulation
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Stochastic pre-processing
Parameter Definition
Preprocessing
Risk analysis
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to LCC domain
Handover LCC check
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 16/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: 8 Life Cycle Costing Domain
Task 1.6 Life Cycle Costing Pattern 3: SIMULATION ANALYSIS View
Detailed task - Create stochastic scenarios / parameterization - Life Cycle Cost Estimation - Interpretation of results
Key Point
Does the design variant meet the Key Performance Requirements? If so: Approve the results for the Decision-Making Domain. If not: Send an optimization request to the Architectural Domain or ESIM Domain e.g. to optimize the concept.
Information Exchange IN
Information source
eeeBIMUDP=BIM+ESIM
Simulation Results
Sender actor
Architectural Domain
Energy System Domain
Simulation Domain
Information Exchange OUT
Information delivery LCC results
Receiver actor Decision-Making Domain
Specifications Templates 2.2.7 Key Point 2.6
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
iTWO
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Preprocessing
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to DM domain
Handover Decision maker
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 17/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Decision-making domain
Task 1.7 Decision-making (for Phase)
Pattern 4: DECISION MAKERs’ View
Detailed task - Balance Advantages/Disadvantages - Prepare Design Feedback
Key Point
Does a design variant meet the Decision Requirements? If so: Send feedback to the domains about the chosen variant to continue with the next design phase. If not: Send request to the domains for optimization.
Information Exchange IN
Information source
Simulation results
LCC results
Sender actor
Simulation Domain
LCC Domain
Information Exchange OUT
Information delivery Decision Values
Receiver actor -
Specifications - Key Point 1.1
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services
9 Multi-KPI AnalysisPrepare for decision making
Template Configuration (BIM Server)
KEY POINT check DVs (prepared results)
Select charts
Get results (charts)
link and save KPR, KDP, KPI and DV
results ok?
Open GUI Decision Maker View
Select Process Pattern incl. DVs
Upload DVs Process Mgmt. Service (Ontology)
Simulation & Analysis Mgmt. Services
Collecting data for weighted evaluation
Generate Charts
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM ServerAll results available
repeat or next LOD
Select best variant/ alternative(s) based on DVs
Send information to consistency check all following requirements
Collaboration Service (BCF Server )
not ok, back to Design Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Next Set up decision making domain
Set Up next Phase
D2.3 Holistic KPI based design methodology
Version 1.0
Page 18/87
© eeEmbedded Consortium www.eeEmbedded.eu
1.3 Workflow Early Design
During Early Design Phase, concepts are created based on the selected concept of the urban design
phase by detailing the room structure and geometry as well as by generating HVAC system diagrams.
To select/discard design alternatives by verification with Key Design Parameters (KDP) such as
size/volume of zones, functional relations, qualities of construction type and dimensions, ventilation
flows, heat recovery coefficient etc., the Level of Detail (LoD) 200 of the models and templates
defined by the Exchange Requirements (ER) for the Early Design Phase in D1.3 Interoperability and
collaboration requirements [Calleja et al. 2014] has to be fulfilled.
With the help of detailing templates, construction type, HVAC type, BACS alternatives and their
influence on energy, emission, thermal comfort, air quality and LCC Key Performance Indicators (KPI)
are analysed. For reliable analysis of alternatives, at this stage, energy simulations, Life Cycle
Assessment (LCA) as well as Life Cycle Costing (LCC) have to be performed with a medium accuracy
which is defined by the Level of Approximation (LoA) 200.
Figure 1: Detailing Templates for elements and components
At the end of Early Design Phase at Level of Development (LOD) 200, decision about the space
layout, building elements (layer thickness and materials), HVAC systems and BACS strategies, has to
be taken, to fulfil best the clients’ needs which are represented by the Decision Value (DV).
D2.3 Holistic KPI based design methodology
Version 1.0
Page 19/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: All Domains
Task 2.0 Project check;
Task 2.1 Check Consistency Pattern 1: Project Setup View
Detailed task - Review and share Decision Requirements. - Review and share Key Performance Requirements. - Review and share Key Design Parameter (shape, quality, quantity, etc.)
Information Exchange IN
Information source
Requirements
Sender actor
Client
Information Exchange OUT
Information delivery Decision Requirements
Key Performance Requirements
Key Design Parameter
Receiver actor All Domains
Specifications - -
DECISION SUPPORT
User incl. Navigator& Scenario Browser
1 Open variants previous phase
2 Setup current KEY POINT framework
3 Workflow check/setup
Resource Mgmt. Service/ Data Storage (BIM Server)
see KEY POINT workflow
see KEY POINT workflow
5 Check (set-up) and manage templates
Resource Mgmt. Service (Template Server)
Open GUI Decision Maker View
Collaboration Bus - BIM--it (Manager)
Handover Achitecture Domain
Send message to Architecture Domain
+ all services register with the central BCF server to set up the project infrastructure (BIM Manager)
Ontology
Management Services
BIM SERVER
D2.3 Holistic KPI based design methodology
Version 1.0
Page 20/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Architectural Domain
Task 2.2 Create construction type alternatives
Pattern 2: DESIGNERs’ View
Detailed task
- Create building shell alternatives (outer walls, windows, baseplate, roof) - Create layout alternatives - Create fit-out alternatives (inner walls, floors, ceilings) - Create shading alternatives
Key Point Does the design alternative meet the Key Design Parameter? If so: Hand over the alternative the HVAC Domain. If not: Improve the design alternative.
Information Exchange IN
Information source
-
Sender actor
-
Information Exchange OUT
Information delivery BIMEDP=BIM
Receiver actor HVAC Domain (and following: BACS, FM, Simulation, LCA and LCC Domain)
Specifications Templates 2.2.1 Key Point ED 3.0
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create construction type alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
1 ALLPLAN
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)HVAC domain
Handover HVACdomain
1 ALLPLAN
D2.3 Holistic KPI based design methodology
Version 1.0
Page 21/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: HVAC Domain
Task 2.3 Create HVAC type alternatives
Pattern 2: DESIGNERs’ View
Detailed task
- Thermal zones identification/definition + Loads calculation - HVAC system type alternatives such as chiller + boiler + fancoils, air-water heat pump + fancoils, splits, VRV, etc. taking into account the type of building, schedules, loads, etc. - Pre-location idea: production equipment /terminal units/ distribution system - Pre-sizing of production equipment such as boiler, terminal units such as fancoils, distributions system (fans and pumps) taking into account the loads calculation - Pre-location idea: production/terminal units/ distribution system.
Key Point Does the design alternative meet the Key Design Parameter? If so: Hand over the alternative the BACS Domain. If not: Improve the design alternative.
Information Exchange IN
Information source
eeeBIMEDP=BIM
Sender actor
Architectural Domain
Information Exchange OUT
Information delivery eeeBIMEDP=ESIM (HVAC)
Receiver actor BACS Domain (and following: FM, Simulation, LCA and LCC Domain)
Specifications Templates 2.2.2 Key Point ED 3.1
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create HVAC type alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
2 DDS CAD
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance HVAC design
Upload IFC model
KEY POINT check KDPnot ok
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)send Message to BACS domain
Handover BACS domain
2 DDS CAD
D2.3 Holistic KPI based design methodology
Version 1.0
Page 22/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: BACS Domain
Task 2.4 Create Control Strategy Alternatives
Pattern 2: DESIGNERs’ View
Detailed task - Review construction type and HVAC type alternatives - Create BACS alternatives (sensors, controllers, actuators etc.) based on EN 15232.
Key Point Does the design alternative meet the Key Design Parameter? If so: Hand over the alternative the FM Domain. If not: Improve the design alternative.
Information Exchange IN
Information source
eeeBIMEDP= BIM+ESIM (HVAC)
Sender actor
Architectural Domain HVAC Domain
Information Exchange OUT
Information delivery eeeBIMEDP= ESIM (BACS)
Receiver actor FM Domain (and following: Simulation, LCA and LCC Domain)
Specifications Templates 2.2.3 Key Point ED 3.2
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create Control Strategy Alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
3 eeBACS Wizard
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)send Message to FM domain
Handover FM domain
3 eeBACS Wizard
D2.3 Holistic KPI based design methodology
Version 1.0
Page 23/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: FM Domain
Task 2.5 Enrich alternatives with O&M information
Pattern 2: DESIGNERs’ View
Detailed task - Maintainability check (service lifes, schedules from FM data base) - Cleaning intensity check / accessibility check - Flexibility check / exchangeability of building components
Key Point Does the design alternative meet the Key Design Parameter? If so: Hand over the alternative the Simulation / LCA and LCC Domain. If not: Send feedback to the Architectural Domain, HVAC Domain or BACS Domain.
Information Exchange IN
Information source
eeeBIMEDP= BIM + ESIM (HVAC+BACS)
Sender actor
Architectural Domain
HVAC Domain
BACS Domain
Information Exchange OUT
Information delivery eeeBIMEDP=BIM+ESIM(HVAC+BACS)+FM
Receiver actor Simulation Domain (LCA +LCC Domain)
Specifications Templates 2.2.4 Key Point ED 3.3 – 3.4
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create Control Strategy Alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model
4 Granlund Designer
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
ok, ready for SIM/ANA
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)send Message to SIM/ANA domain
Handover SIM/ANA domain
4 Granlund Designer
D2.3 Holistic KPI based design methodology
Version 1.0
Page 24/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Simulation Domain (Energy Expert)
Task 2.6 Simulation Pattern 3: SIMULATION ANALYSIS View
Detailed task - Create stochastic scenarios - Run Simulation - Interpretation of results
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the LCA Domain, LCC Domain and Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific components.
Information Exchange IN
Information source
eeeBIMEDP=BIM+ESIM (HVAC+BACS)+FM
Sender actor
Architectural, HVAC, BACS & FM Domain
Information Exchange OUT
Information delivery Simulation Results
Receiver actor LCA, LCC &Decision-Making Domain
Specifications Templates 2.2.5 Key Point 2.0 – 2.2
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
Energy Simulation
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Stochastic pre-processing
Parameter Definition
Preprocessing
Risk analysis
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to LCA domain
Handover LCA check
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 25/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Construction Domain
Task 2.7 Life Cycle Assessment Pattern 3: SIMULATION ANALYSIS View
Detailed task
- Preparing of cost scenarios (stochastics). - Perform Life Cycle Assessment (LCA) on BIM-based QTO, simulation results, service life planning and activity category results. - Review LCA Results.
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific components.
Information Exchange IN
Information source
eeeBIMEDP= BIM+ESIM (HVAC+BACS)+FM +Simulation Results
Sender actor
Architectural, HVAC, BACS, FM & Simulation Domain
Information Exchange OUT
Information delivery LCA results
Receiver actor Decision-Making Domain
Specifications Templates 2.1.7 Key Point 2.3
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
iTWO
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Preprocessing
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for LCC
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to LCC domain
Handover LCC Domain
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 26/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Life Cycle Costing Domain (LCC expert)
Task 2.8 Life Cycle Cost estimation Pattern 3: SIMULATION ANALYSIS View
Detailed task - Create stochastic scenarios - Life Cycle Cost estimation - Interpretation of results
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific components.
Information Exchange IN
Information source
eeeBIMEDP= BIM+ESIM(HVAC+BACS)+FM
Sender actor
Architectural, HVAC, BACS, FM & Simulation Domain
Information Exchange OUT
Information delivery LCC results
Receiver actor Decision-Making Domain
Specifications Templates 2.2.7 Key Point 2.6
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
iTWO
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Preprocessing
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to DM domain
Handover Decision maker
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 27/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Decision-Making Domain
Task 2.9 Decision-making Pattern 4: DECISION MAKERs’ View
Detailed task - Create stochastic scenarios - Life Cycle Cost estimation - Interpretation of results
Key Point Does a design variant meet the Decision Requirements? If so: Send feedback to the domains to continue with the next design phase. If not: Send request to the domains for optimization.
Information Exchange IN
Information source
Simulation, LCA & LCC Results
Sender actor
Simulation, LCA &LCC Domain
Information Exchange OUT
Information delivery Decision Values
Receiver actor -
Specifications - Key Point 1.1
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services
9 Multi-KPI AnalysisPrepare for decision making
Template Configuration (BIM Server)
KEY POINT check DVs (prepared results)
Select charts
Get results (charts)
link and save KPR, KDP, KPI and DV
results ok?
Open GUI Decision Maker View
Select Process Pattern incl. DVs
Upload DVs Process Mgmt. Service (Ontology)
Simulation & Analysis Mgmt. Services
Collecting data for weighted evaluation
Generate Charts
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM ServerAll results available
repeat or next LOD
Select best variant/ alternative(s) based on DVs
Send information to consistency check all following requirements
Collaboration Service (BCF Server )
not ok, back to Design Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Next Set up decision making domain
Set Up next Phase
D2.3 Holistic KPI based design methodology
Version 1.0
Page 28/87
© eeEmbedded Consortium www.eeEmbedded.eu
1.4 Workflow Detailed Design
During Detailed Design Phase, the chosen building and HVAC design concept is detailed with regard
to product qualities of the materials and components. The operational concept is detailed to an
operational plan.
To select/discard design alternatives by verification with Key Design Parameters (KDP) such clear
height, material product qualities, HVAC product qualities and BACS product qualities as well as
dimensions, the Level of Detail (LoD) 300 of the models and templates defined by the Exchange
Requirements (ER) for the Detailed Design Phase in D1.3 Interoperability and collaboration
requirements [Calleja et al. 2014] has to be fulfilled.
With the help of product catalogues, materials, HVAC components, BACS components
alternatives and their influence on energy, emission, thermal comfort, air quality and LCC
Key Performance Indicators (KPI) are analysed. For reliable analysis of alternatives, at this
stage, energy simulations, Life Cycle Assessment (LCA) as well as Life Cycle Costing (LCC)
have to be performed with a high accuracy which is defined by the Level of Approximation
(LoA) 300.
At the end of Detailed Design Phase at Level of Development (LOD) 300, decision about the products
and detailed geometries as well as about optimal positions e.g. of the air outlets and
heating/cooling surfaces, has to be taken, to fulfil best the clients’ needs which are represented by
the Decision Value (DV).
D2.3 Holistic KPI based design methodology
Version 1.0
Page 29/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: All Domains
Task 3.0 Project check Task 3.1 Check Consistency
Pattern 1: PROJECT SETUP View
Detailed task
- Review and share Decision Requirements. - Review and share Key Performance Requirements. - Review and share Key Design Requirements (shape, quality, quantity, etc.). - Check consistency.
Information Exchange IN
Information source
- Requirements
Sender actor
- Client
Information Exchange OUT
Information delivery - Decision Requirements
- Key Performance Requirements
- Key Design Requirements
Receiver actor - All Domains
Specifications - -
DECISION SUPPORT
User incl. Navigator& Scenario Browser
1 Open variants previous phase
2 Setup current KEY POINT framework
3 Workflow check/setup
Resource Mgmt. Service/ Data Storage (BIM Server)
see KEY POINT workflow
see KEY POINT workflow
5 Check (set-up) and manage templates
Resource Mgmt. Service (Template Server)
Open GUI Decision Maker View
Collaboration Bus - BIM--it (Manager)
Handover Achitecture Domain
Send message to Architecture Domain
+ all services register with the central BCF server to set up the project infrastructure (BIM Manager)
Ontology
Management Services
BIM SERVER
D2.3 Holistic KPI based design methodology
Version 1.0
Page 30/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Architectural Domain
Task 3.2 Create architecture product alternatives
Pattern 2: DESIGNERs’ View
Detailed task - Create material supplier options - Detail the layout
Key Point Does the product alternative meet the Key Design Requirements? If so: Hand over the product alternative to the HVAC Domain. If not: Improve the product design alternative.
Information Exchange IN
Information source
- BIMDDP=BIM
Sender actor
- HVAC, BACS, FM, Simulation, LCA & LCC Domain
Information Exchange OUT
Information delivery - Key Design Requirements
Receiver actor - Material
Specifications Templates 2.2.1 Key Point DD 3.0
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create construction type alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
1 ALLPLAN
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)HVAC domain
Handover HVACdomain
1 ALLPLAN
D2.3 Holistic KPI based design methodology
Version 1.0
Page 31/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: HVAC Domain
Task 3.3 Create HVAC product alternatives
Pattern 2: DESIGNERs’ View
Detailed task
- Final selection and sizing according to manufactures Products - Location: production equipment / terminal units / distribution system - Final sizing of distribution system: ducts, pipes, fans, valves, pumps, heat exchangers etc.
Key Point Does the product alternative meet the Key Design Requirements? If so: Hand over the product alternative to the BACS Domain. If not: Improve the product alternative.
Information Exchange IN
Information source
- eeeBIMDDP =ESIM (HVAC)
Sender actor
- BACS, FM, Simulation, LCA & LCC Domain
Information Exchange OUT
Information delivery - Key Design Requirements
Receiver actor - HVAC component
Specifications Templates 2.2.2 Key Point DD 3.1
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create HVAC type alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
2 DDS CAD
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance HVAC design
Upload IFC model
KEY POINT check KDPnot ok
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)send Message to BACS domain
Handover BACS domain
2 DDS CAD
D2.3 Holistic KPI based design methodology
Version 1.0
Page 32/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: BACS Domain
Task 3.4 Design Sensor and Actor Network
Pattern 2: DESIGNERs’ View
Detailed task
- Final selection and sizing according to manufactures Products - Location: production equipment / terminal units / distribution system - Final sizing of distribution system: ducts, pipes, fans, valves, pumps, heat exchangers etc.
Key Point Does the product alternative meet the Key Design Requirements? If so: Hand over the product alternative to the BACS Domain. If not: Improve the product alternative.
Information Exchange IN
Information source
- eeeBIMDDP=BIM+ESIM(HVAC)
Sender actor
- Architectural & HVAC Domain
Information Exchange OUT
Information delivery - eeeBIMDDP=ESIM (BACS)
Receiver actor - FM Domain - Simulation Domain - LCC Domain - LCA Domain
Specifications Templates 2.2.3 Key Point DD 3.2
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create Control Strategy Alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model to next design domain
3 eeBACS Wizard
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Process Mgmt. Service
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)send Message to FM domain
Handover FM domain
3 eeBACS Wizard
D2.3 Holistic KPI based design methodology
Version 1.0
Page 33/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: FM Domain
Task 3.5 Enrich product alternatives with operational information
Pattern 2: DESIGNERs’ View
Detailed task
- Final selection and sizing according to manufactures Products - Location: production equipment / terminal units / distribution system - Final sizing of distribution system: ducts, pipes, fans, valves, pumps, heat exchangers etc.
Key Point Does the product alternative meet the Key Design Requirements? If so: Hand over the product alternative to the Simulation / LCA / LCC Domain. If not: Improve the product alternative.
Information Exchange IN
Information source
- eeeBIMDDP= BIM+ESIM (HVAC+BACS)
Sender actor
- Architect, HVAC & BACS engineer
Information Exchange OUT
Information delivery - eeeBIMDDP= FM
Receiver actor - Simulation Domain - LCA Domain - LCC Domain
Specifications Templates 2.2.4 Key Point DD 3.3 – 3.4
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario BrowserDesign Module Management Services
results ok?
Create Control Strategy Alternatives
Upload IFC Model
KEY POINT check KDP
Send KDP and model
4 Granlund Designer
Open GUI Designer View
KEY POINT Verification with KDP
Graphical representation results
link and save KPR and KDP
Make variance design
Upload IFC model
KEY POINT check KDPnot ok
ok, ready for SIM/ANA
Select Process Pattern / Workflow control
Upload KPR in LOD and LoD
Check LOD and LoD
see KEY POINT workflow
Request for Templates
Templates Configuration Interface Resource Mgmt. Service/ Template Manager
Modify Templates
Service Bus (BCF REST API) / Process Mgmt. Service (Ontology)
Check LOD and LoD
ok. or not ok. Multi Model Mgmt. Service (Validator)
not ok
Multi Model Mgmt. Service (Validator)ok. or not ok.
KEY POINT Verification with KDP
Graphical representation results see KEY POINT workflow
results ok?
see KEY POINT workflow
Collaboration Bus - BIM--it (Manager)send Message to SIM/ANA domain
Handover SIM/ANA domain
4 Granlund Designer
D2.3 Holistic KPI based design methodology
Version 1.0
Page 34/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Simulation Domain
Task 3.6 a) CFD simulation Pattern 3: SIMULATION ANALYSIS View
Detailed task - Create stochastic scenarios - Run simulation - Interpretation of results
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the LCA Domain, LCC Domain and Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific products.
Information Exchange IN
Information source
- eeeBIMDDP=BIM+ESIM(HVAC+BACS)+FM
Sender actor
- Architectural, HVAC, BACS & FM Domain
Information Exchange OUT
Information delivery - Simulation results
Receiver actor - Decision-Making Domain
Specifications Templates 2.2.5 Key Point 2.4 – 2.5
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Template Configuration (BIM Server)
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
6 3D Wind
Preprocessing
Get results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Template configuration
Parameter Definition
Simulation & Analysis Mgmt. Services
Preprocessing
Simulation & Analysis Mgmt. Services
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to SIM Energy
Handover SIM Energy
D2.3 Holistic KPI based design methodology
Version 1.0
Page 35/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Simulation Domain
Task 3.6 b) Energy Simulation Pattern 3: SIMULATION ANALYSIS View
Detailed task - Prepare simulations - Run simulation - Interpretation of results
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the LCA Domain, LCC Domain and Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific products.
Information Exchange IN
Information source
- eeeBIMDDP=BIM+ESIM(HVAC+BACS)+FM
Sender actor
- Architectural, HVAC, BACS & FM Domain
Information Exchange OUT
Information delivery - Simulation results
Receiver actor - LCA,- LCC Domain - Decision-Making Domain
Specifications Templates 2.2.5 Key Point 2.0 – 2.2
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
Energy Simulation
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Stochastic pre-processing
Parameter Definition
Preprocessing
Risk analysis
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to LCA domain
Handover LCA check
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 36/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Construction Domain
Task 3.7 Life Cycle Assessment Pattern 3: SIMULATION ANALYSIS View
Detailed task - Preparing of cost scenarios (stochastics). - Perform Life Cycle Assessment (LCA) - Review LCA Results.
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific components.
Information Exchange IN
Information source
- eeeBIMDDP=BIM+ESIM(HVAC+BACS)+FM
- Simulation Results
Sender actor
- Architectural domain
- HVAC domain
- BACS domain
- FM Domain
- Simulation Domain
Information Exchange OUT
Information delivery - LCA results
Receiver actor - Decision-Making Domain
Specifications - Key Point 2.3
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
iTWO
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Preprocessing
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for LCC
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to LCC domain
Handover LCC Domain
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 37/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Life Cycle Costing Domain
Task 3.8 Life Cycle Cost estimation Pattern 3: SIMULATION ANALYSIS View
Detailed task - Create stochastic scenarios / parameterisation - Life Cycle Cost Estimation - Interpretation of results
Key Point
Does the design alternative meet the Key Performance Requirements? If so: Approve the results for the Decision-Making Domain. If not: Send an optimization request to the Architecture, HVAC or BACS domain e.g. to optimize the quality of specific components.
Information Exchange IN
Information source
- eeBIMDDP=BIM+ESIM(HVAC+BACS)+FM
- Simulation Results
Sender actor
- Architectural, HVAC, BACS, FM &- Simulation Domain
Information Exchange OUT
Information delivery - LCA results
Receiver actor - Decision-Making Domain
Specifications Templates 2.2.7 Key Point 2.6
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services Simulation/ Analysis
Prepare for Simulation/ Analysis
Run Simulation
KEY POINT check KPI (prepared results)
Prepare results based on predefined KPIs
Prepare for Evaluation
iTWO
Preprocessing
Get Post-Processing results
link and save KPR, KDP and KPI
results ok?
not ok
ok, select suitable variants / alternatives
Open GUI SIM/ Analysist View: Select and upload variants
Select Process Pattern incl. KPI
Upload KPI see Key Point Workflow
Preprocessing
Processing
Postprocessing
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM Server
All results available
ok, ready for Decision Making
not ok, back to architectural domain Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Message to DM domain
Handover Decision maker
Simulation & Analysis Mgmt. Services
D2.3 Holistic KPI based design methodology
Version 1.0
Page 38/87
© eeEmbedded Consortium www.eeEmbedded.eu
Actors: Decision-Making Domain
Task 3.9 Decision-making Pattern 4: DECISION MAKERs’ View
Detailed task - Balance advantages / disadvantages - Prepare Design Feedback
Key Point Does a design variant meet the Decision Requirements? If so: Send feedback to the domains to continue with construction. If not: Send request to the domains for optimization.
Information Exchange IN
Information source
- Simulation Results
- LCA Results
- LCC Results
Sender actor
- Simulation Domain
- LCA Domain
- LCC Domain
Information Exchange OUT
Information delivery - Decision Values
Receiver actor -
Specifications Templates X.X Key Point 1.1
DECISION SUPPORT
BIM SERVER
OntologyUser incl. Navigator& Scenario Browser Management Services
9 Multi-KPI AnalysisPrepare for decision making
Template Configuration (BIM Server)
KEY POINT check DVs (prepared results)
Select charts
Get results (charts)
link and save KPR, KDP, KPI and DV
results ok?
Open GUI Decision Maker View
Select Process Pattern incl. DVs
Upload DVs Process Mgmt. Service (Ontology)
Simulation & Analysis Mgmt. Services
Collecting data for weighted evaluation
Generate Charts
Save Variants and Alternatives
Data storage on BIM Server
Version Managment via BIM ServerAll results available
repeat or next LOD
Select best variant/ alternative(s) based on DVs
Send information to consistency check all following requirements
Collaboration Service (BCF Server )
not ok, back to Design Domain(s)
Process Mgmt. Service
Collaboration Bus - BIM--it (Manager)Send final Alternative
Set Up next Phase
D2.3 Holistic KPI based design methodology
Version 1.0
Page 39/87
© eeEmbedded Consortium www.eeEmbedded.eu
Part B
D2.3 Holistic KPI based design methodology
Version 1.0
Page 40/87
© eeEmbedded Consortium www.eeEmbedded.eu
2. Template Specifications beyond Implementations
eeTemplates used in eeEmbedded project should be preliminarily understood as a data file, which
includes all relevant details to enrich BIM models or other sub-processes with additional information,
before they are used in the authoring- , simulations-, or analysis tools. These tools require a
minimum input of information, which is usually not known at the time of early design.
eeTemplates allow semi-automatic detailing which enable significant improvement in the planning
and they shorten the time of the design process which is one of the main facts to achieve better and
faster planning results [Zellner et al., 2015].
The objective of the present deliverable with regard to templates is to specify (1) templates library
structure, which shows their organization, and (2) templates content as a premise step for
implementation.
The starting point of the work that is shown in this deliverable is described in Deliverable 1.4
[Kenneth et al, 2014] and Deliverable 2.2 [Zellner et al., 2015]. The objective of the “D2.2-Templates
for fast semi-automatic detailing" is to elaborate, a generic eeTemplate format structure and it’s
individual syntax components. The outputs of Deliverable 2.2 [Zellner et al., 2015] provide a
technical eeTemplate definition, which serves the creation of eeTemplates used by the Software
applications integrated into the eeEmbedded System Architecture. This deliverable is based on the
research of the eeTemplates and on the results demonstrated in the “D1.4 – Requirements for
knowledge-based design support and templates”, where profound insight was outlined into the
eeTemplate and its usage in elaborated use cases scenarios of the design phase.
It should be noted that the end-users of virtual lab can choose whether use native authoring tools
templates or eeTemplates. Figure 2 shows this approach. The templates are organized (1) within a
project-specific repository which is situated inside the storage cloud and (2) as application integrated
and/or domain-specific template repository. The access for the software applications into the cloud
based repository is organized via a communication layer and collaboration services. This chapter will
be focused on eeTemplates (stored in cloud).
D2.3 Holistic KPI based design methodology
Version 1.0
Page 41/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 2: Centralized template repository within the repository layer and application-specific decentralized repository as part of the virtual lab layer (Zellner et al., 2015)
One of the main advantages of eeTemplates is that they are cross-domain. This approach will ensure
that software applications are able to access templates without barriers. The main advantage of a
separation of application and template data organized in a centralized manner is not only the
accessibility of template content for all software applications but also the ability to store and sort
template data used across different domains without the need of redundant data values and
management functions. Each software application which connects to the virtual lab will provide
access to all publicly available template data.
Figure 3: TO-BE situation, cross- domain and cross-application perspective (Zellner et al., 2015)
2.1 Libraries structure
The library structure of templates will be described in this section. A library is an organized collection
of information sources, in this case of templates. The purpose is to show how the different types of
templates are related. Figure 4 shows the eeEmbedded library structure and introduces the
templates as domain-related templates rather than cross-domain templates. It must be noted that
the picture is not complete (some domains such as FM domain and simulation domain are not
included in it) but it shows the approach.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 42/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 4: eeE Template Library Structure
In the following sections, the library description has been split into domains in order to ease its
comprehension. However, the influence of cross-domain templates in the library will be explained
with an example (see 3.1.9).
D2.3 Holistic KPI based design methodology
Version 1.0
Page 43/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.1 Architecture domain
Figure 5: Construction library
Figure 6: Building usage templates
D2.3 Holistic KPI based design methodology
Version 1.0
Page 44/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.2 ESIM domain
Structure and content of the library of the ESIM is based on the identified main aspects of energy
systems: (1) energy sources, (2) transformation facilities, (3) distribution systems, (4) storage
systems, (5) consumption / usage information and (6) weather / climate data but also (7) automation
and control systems. The following figures explain the content related structure of templates in a
high-level manner not expecting the complete picture within all several structures.
Figure 7: Library structure ESIM Energy Sources
D2.3 Holistic KPI based design methodology
Version 1.0
Page 45/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 8: Library structure ESIM Transformation Facilities
Figure 9: Library structure ESIM Distribution Systems
D2.3 Holistic KPI based design methodology
Version 1.0
Page 46/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 10: Library structure ESIM Storage Systems
Figure 11: Library structure ESIM Consumption/Usage
D2.3 Holistic KPI based design methodology
Version 1.0
Page 47/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 12: Library structure ESIM Weather/Climate
Figure 13: Library structure ESIM Automation control system
D2.3 Holistic KPI based design methodology
Version 1.0
Page 48/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.3 HVAC domain
The important knowledge in the HVAC domain is to be able to build HVAC systems in the building and
zones that meet the buildings Key Performance Indicators to-be (KPI to-be) and Key Design
Parameters to-be (KDP to-be), outside and inside. Present time local projects template experience is
often stored in a software proprietary format and reused when constructing new similar projects – to
speed the planning process.
The HVAC domain knowledge approach is to break down building types into to zone types to enable
semi-automate construction of HVAC devices or subsystems to meet the KPI/KDP to-be faster.
Figure 14: Library Illustration of building and related zone templates with key HVAC input parameters
The eeE approach is to share “openBIM” knowledge templates in a repository accessible to all
disciplines, and build the knowledge templates. Sample: In the exchange of information, the
Architecture domain provides some key attributers to enable HVAC domain to select Templates,
primary:
• Site location • Types of Building (incl. number of floors, area, volume…) • Types of zones (incl. area, volume…) • Outside and Inside interconnecting zones input
Based on the key input the HVAC engineer can determine the schematic design by using the KPI to-be
and KDP to-be input and define the zones and building templates. Defining the knowledge template
may also be done on a management level to quality assure that all disciplines uses one source of
D2.3 Holistic KPI based design methodology
Version 1.0
Page 49/87
© eeEmbedded Consortium www.eeEmbedded.eu
template as design input. Energy analysis of a building to construct required HVAC system is similar
to the eeE defining template approach:
Analyses of energy-conserving designs shall include all relevant facets of the building
envelope; lighting energy input, domestic water heating, efficient use of local ambient
weather conditions, building zoning, efficient part load performance of all major HVAC
equipment and the ability of building automation equipment to automatically adjust for
building partial occupancies, optimized start-stop times and systems resets.
(http://www.gsa.gov/portal/content/101231)
HVAC domain experts depends on the Building and Zone input templates and all levels of space
boundary information to energy analysis and calculate choose of system type, sizing and exhaust and
supply to semi-automate a suitable HVAC construction.
Generic HVAC (sub) systems and devices may also be stored as templates:
• Related to specific building type • Related to zone/space/room type • Standalone devices • System/group of devices.
Figure 15: Complete HVAC knowledge library structure
The same applies for this library; to be shared for the purpose of uniform HVAC device selection and
to speed the construction of HVAC sustainable system, by choosing from projects HVAC template
library.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 50/87
© eeEmbedded Consortium www.eeEmbedded.eu
The eeE success of fast semi-automate the design of HVAC domains is based on the
knowledge of breaking down similar projects into generic building blocks needed to construct
Early phase HVAC by use of knowledge template.
(http://www.gsa.gov/portal/content/101231)
D2.3 Holistic KPI based design methodology
Version 1.0
Page 51/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.4 BACS domain
Knowledge-based templates from BACS point of view facilitate a fast semi-automated design of
different BACS solutions. Therefore, a BACS Template Library structured according to the Automation
Pyramid was elaborated (Figure 16). In detail it is structure in (1) Management Level, the supervision
of the building automation with a global building controller for monitoring and optimization across
several technical building systems, (2) Automation Level, the room automation and plant
automation, and (3) Field Level, the sensors and actuators with its specific control.
Figure 16: Automation Pyramid [Solvik et al., 2014]
Each BACS knowledge template is characterized by a specific set of BACS Key Design Parameters
(KDP). Hence, possible BACS design concepts fulfilling a specific set of KDRs can be filtered and
elaborated by means of the structured BACS Template Library in an easy manner. An overview of the
basic BACS Template Library structure according to Automation Pyramid is given in Figure 17.
In general the BACS Template Library comprises sets of BACS Management Templates, BACS
Automation Templates and BACS Field Templates. As illustrated in Figure 17 several combinations of
all specified BACS Templates are possible. Using the generic eeTemplate approach, elaborated in
[Zellner et al. 2015], the interlinkages of different BACS Templates to even more complex BACS
Templates is enabled. The interlinkage possibilities are applicable to create cross-domain templates
as well, as described in section 3.1.9. From BACS point of view there are strong interdependencies to
other domains like ESIM and HVAC. Considering this aspect the creation of complex cross-domain
templates is aimed.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 52/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 17: Basic BACS Template Library structure according to Automation Pyramid
Whereas Figure 17 illustrates the basic BACS Template Library structure according to Automation
Pyramid the following figures will explain the content of some selected complex BACS templates in a
high-level manner not expecting the complete picture within the template structure.
The Figure 18 presents the BACS Management Template Office Building Control and its interlinkages
to other BACS templates. The interlinkages can be seen as a kind of composition too. The Office
Building Control covers all information to plan, simulate and later to operate a building in an energy
efficient manner whilst maintaining the user comfort. Therefore, the Management Template
comprises several Automation Templates that cover control strategies for thermal comfort control
on energy consumer side and control strategies for heating and cooling plants on energy producer
side. Besides the control strategy the corresponding room automation (RA) functions and building
automation and control (BAC) functions including functional interface description are covered.
Further Office Building Control Template comprises BACS equipment information for controller,
sensors and actuators. In order to validate the BACS design solution, based on the Office Building
Control Template, information about building usage as well as weather and climate conditions are
provided.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 53/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 18: BACS Management Template – Office Building Control
The Figure 19 presents the BACS Automation Template Thermal Control and its interlinkages to other
BACS templates. The illustrated template in high-level manner is also part of the BACS Management
Template above. The Thermal Control template comprises BACS Field Templates covering sensor-
related information (Temperature Sensor) and data structures covering the local controls of the
technical system (Fan-Coil Control). Further the control strategy covering the RA functions to fulfil the
thermal control of a spatial structure is described by the template content. The presented
Automation Template also covers domain-independent information like space usage, weather or
lifecycle cost.
Figure 19: BACS Automation Template – Thermal Control
D2.3 Holistic KPI based design methodology
Version 1.0
Page 54/87
© eeEmbedded Consortium www.eeEmbedded.eu
The Figure 20 presents the BACS Field Template Temperature Sensor and its interlinkages to other
templates. The illustrated template in high-level manner is also part of the BACS Management
Template and the BACS Automation Template above. The Temperature Sensor template comprises
functional information including functional interface description as well as BACS equipment
information including physical interface description. To fulfil the information requirements of the
Simulation and Analysis domain for a proper validation of different design alternatives the Field
Template also covers maintenance, risk, LCC and LCA related information.
Figure 20: BACS Field Template – Temperature Sensor
D2.3 Holistic KPI based design methodology
Version 1.0
Page 55/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.5 FM domain
Figure 21: Template library. Facility Management
D2.3 Holistic KPI based design methodology
Version 1.0
Page 56/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.6 Simulation domain
Following the competences within the project consortium the library for the simulation domain could
be divided into the thermal building energy and system aspect (TEB & TES) and the CFD related
analysis aspect.
Energy Simulation Templates
In general the library contains information about the simulation modules and pre-defined sets
describing the work flow strategy.
The TEB / TES library covers both, (1) references to the single simulation modules and (2) pre-defined
subsets and combination of references to simulation modules. Energy Simulation and CFD simulation
can be coupled in a sophisticated manner. A more detailed view of the CFD simulation templates will
be given in the following section.
Figure 22: Library structure Energy Analysis System
CFD Simulation Templates
CFD simulations are carried out for TEB and TES simulation coupled with Energy Simulations in order
to obtain the detailed indoor climate, e.g. for the optimal design of the building envelope, the
prediction of thermal comfort conditions, the evaluation of the HVAC performance, the optimization
of HVAC systems (size of diffusers and location in the zone) and the design of natural ventilation.
CFD simulation templates cover predefined data sets required for the construction of the CFD
numerical model as part of a coupled simulation procedure between ES and detailed CFD analyses.
Referencing in data contained in libraries ensures standard configurations of data resulting in fewer
problems in simulation runs than a less rigid approach.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 57/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 23: Library structure for CFD Analysis
D2.3 Holistic KPI based design methodology
Version 1.0
Page 58/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.7 Life Cycle Assessment domain
LCA-based templates facilitate a fast design of different project alternative solutions. According to
the obtained information input from the user a LCA Template Library is automatically loaded from
the related Master Projects. These are structured according to related building types. In general the
libraries contain all ecological relevant information that arise in the whole life cycle of a building such
as “Total use of renewable primary energy resources”, “Total use of non-renewable primary energy
resources”, “Global warming potential” etc.
Figure 24: Library structure Life Cycle Assessment
D2.3 Holistic KPI based design methodology
Version 1.0
Page 59/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.8 Life Cycle Cost domain
As with the LCA-based templates, the LCC-based templates allow for a quick design of various project
alternative solutions. Thereby from the information input of a user a LCC Template Library, which is
structured according to the related building types, is automatically loaded from the Master Projects.
All ecological relevant information, which arise in the life cycle of a building such as costs/cost codes
for labor, equipment, materials, etc., are generally contained in the library.
Figure 25: Library structure Life Cycle Costs
D2.3 Holistic KPI based design methodology
Version 1.0
Page 60/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.1.9 eeE cross-domain templates
A building design process unites different experts with their different software tools & processing
tasks within one or more domains. Working in a cross-domain approach is becoming more and more
important. To ensure that software applications that are used within the design process are able to
access cross-domain templates without barriers a new generic data structure was introduced in
Deliverable 2.2 [Zellner et al, 2015]. The generic eeTemplate approach eases the usage of templates
in several software applications and across domains (Figure 3).
Design and production concepts which are based on a modularization and cross-domain work
became key success factors on a broad range of engineering disciplines. The eeE cross-domain
template has adapted this concept to provide flexible usage scenarios, low effort of maintaining the
templates and fast template generation by re-using existing structures and knowledge. The
differentiation between simple and complex templates and the ability to link them but also the
parameter-based instantiation of the templates provide a flexible basis for the support of semi-
automatic detailing.
Figure 26: Illustration of an eeE cross-domain template
As mentioned the eeE cross-domain template approach provides the possibility to carry various data
from different domains and aspects. In the following the abilities to interlink templates of the
introduced domain-specific template libraries are explained with the help of a standard office room
template within a building. In Figure 26 it can be seen the composition of construction material to
construction element up to a template representing the standard office room including HVAC
component and user behaviour.
The different types of templates were already described in the Deliverables D1.4 [Solvik et al., 2015]
and D2.2 [Zellner et al., 2015]; two different types of templates can be differentiated in general:
Simple Template Complex Template
Since the template’s properties can be inherited, a hierarchy is constructed automatically with an
increasing degree of complexity.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 61/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 27: Concept that provide linking capabilities
The concept in Figure 27 shows the interlinking capabilities of the generic eeTemplate approach, the
composition of simple templates to complex templates, developed in D2.2. By means of this concept
the standard office room example above can be described in an eeE cross-domain template. Due to
the generic eeTemplate approach templates that are assigned to a specific domain or belong to a
domain library (e.g. BACS Template Library) can be used in cross-domain templates too.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 62/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 28: eeE Cross-domain Template - Standard Office Room
Figure 28 illustrates a Standard Office Room template and its embedding in a more complex cross-
domain template representing an Office Building. The Standard Office Room template comprises
templates of several domains that in turn comprise either templates belonging to the same domain
or to another. In detail the room template example reuses templates of the Architecture
(Construction Element), HVAC (Fan-Coil), and BACS (Thermal Control) domain as well as non-domain-
related (Room Usage) templates specified in libraries above.
To explain the example more in detail the BACS template Thermal Control will be used. The template
provides information about the room automation (RA) to maintain the user comfort whilst
minimizing the energy consumption of the office room. It comprises information about the thermal
control function including functional interface description (inputs, outputs and parameter). Further it
comprises information about BACS equipment, including energy properties and physical interface
description, and Set Point information like user comfort temperature. In general the template
content can be provided either (1) directly in content data section or (2) by template interlinkage. For
case (2) the Thermal Control has a link to the Temperature Sensor template. This kind of template is a
Field Template in the BACS Template Library and provides detail information about a generic
temperature sensor, including functional, physical and manufacturer information.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 63/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 29: eeE Cross-domain Template - Mapping of generalized structure for a Standard Office Room
The whole power of eeTemplates approach in creating large and complex eeE cross-domain
templates can be seen in Figure 30. The eeE Cross-domain template covers 1) the building and its
space including the user behavior, 2) the energy system, including energy sources, energy storages,
energy distribution, etc. as well as the building automation and control system and 3) the climate and
weather information. The eeE cross-domain template provides a proper dataset that forms the basis
for an Energy Simulation (ES) and energy performance validation for a design alternative already in
very early design stages. One of the main advantage of such an eeE cross-domain templates is that it
can be used as it is, on the other hand it can be customized by the end-user in the project set up or
while elaborating different design alternatives [Zellner et al., 2015].
D2.3 Holistic KPI based design methodology
Version 1.0
Page 64/87
© eeEmbedded Consortium www.eeEmbedded.eu
Figure 30: eeE Cross-domain Template - General approach covering for example energy (sub-)systems, building / space type including usage and weather
D2.3 Holistic KPI based design methodology
Version 1.0
Page 65/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.2 Templates content
The content of the templates mentioned in the library described above will be specified in this
section. For that objective, the templates have been defined by means of tables with the following
information:
Template: this row references the name of the template type which is used in the library as well.
Meta data: Meta Data is structured data, which describes the template itself in terms of information
resources to capture, find, organize and use the content information easier. The Meta data block
contains information about the type of template, source of template data, Level-of-data and links the
other sources and templates to build up complex templates including a hierarchical tree structure.
Other additional information are data about the usage of the template, restrictions, version and
license information and log data about the editing respective mutation (Figure 17). Metadata helps
to identify unambiguously and precisely each template [Zellner et al., 2015].
Content data is refered to the properties and attributes contained in the template [Zellner et al.,
2015].
Format of the properties and attributes
Tools with access to the template.
Figure 31: structure of Template Meta Data and examples (Zellner et al., 2015)
Figure 32: General description of the content data section (left) and a simple example (right) (Zellner et al., 2015)
The LoD will be assigned to every property. This way, the templates will be customized for every Use
Case according to the LoD agreed by the end-user and client.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 66/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.2.1 Architecture domain
Template Metadata Content data Format Tools
Opaque construction
a. Available for ARCH/HVAC/ESIM/SIM
a. Name (Code) b.Type (exterior wall) c. Layer 1 (name/code) d. Layer n (name/code) e. Costs (euros/m
2)
f. MJ of primary energy/ m2
g. kg CO2 eq./m2
a. IFC b. IFC c. IFC d. IFC e.IFC f. IFC
a. ALLPLAN b. DDS c. TRNSYS-TUD d. iTWO
Opaque Layer a. Available for ARCH/HVAC/ESIM/SIM b. Linked to opaque construction
a. Name/code b. Thickness (m) c. Density (kg/m3) d. Layer n (name) e. Thermal conductivity (W/mK) f. Specific Heat Capacity (J/kgK) g. MJ of primary energy/ m
2
h. kg CO2 eq./m2
a. IFC b. IFC c. IFC d. IFC e. IFC f. IFC g. IFC h.IFC
a. ALLPLAN b. DDS c. TRNSYS-TUD d. iTWO
Semitransparent construction
a. Available for ARCH/HVAC/ESIM/SIM
a. Name/code b. Layer 1 (name) c. Layer n (name) d. Frame material e. Frame ratio f. Costs (euros/m
2)
g. MJ of primary energy/ m2
h. kg CO2 eq./m2
a. IFC b. IFC c. IFC d. IFC e. IFC f. IFC g. IFC
a. ALLPLAN b. DDS c. TRNSYS-TUD d. iTWO
Transparent layer
a. Available for ARCH/HVAC/ESIM/SIM b. Linked to semitransparent construction
Glass layer – Name/code a. Thickness (m) b. SHGC c. U (W/m
2K)
Gass layer – Name/code d. U (W/m
2K)
e. Thickness (m) e. Costs (euros/m
2)
f. MJ of primary energy/ m2
g. kg CO2 eq./m2
Frame - Name h. U (W/m2K) i. Thickness j. Costs (euros/m
2)
k. MJ of primary energy/ m2
l. kg CO2 eq./m2
a. IFC b. IFC c. IFC d. IFC e. IFC f. IFC g. IFC h. IFC i. IFC j. IFC k. IFC l. IFC
a. ALLPLAN b. DDS c. TRNSYS-TUD d. iTWO
Building use profile
a. Available for ARCH/HVAC/ESIM/SIM
People a. Number of persons (person/m
2)
b. Gain (W/m) c. Schedule Lighting d. Power (W/m
2)
e. Schedule Comfort conditions f.Cooling setpoint g. Heating setpoint h. Cooling Schedule i. Heating schedule j. Air quaility
a.IFC b.IFC c.IFC d.IFC e.IFC f.IFC g.IFC h.IFC i.IFC j.IFC
a. ALLPLAN b. DDS c. TRNSYS-TUD
D2.3 Holistic KPI based design methodology
Version 1.0
Page 67/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.2.2 ESIM/HVAC domain
Template Metadata Content data Format Tools
Site location a. Available for ARCH/HVAC/ ESIM
a. Longitude (grd, min, sec E/W) b. Latitude (grd, min, sec E/W) c. Altitude (m) d. Site address (-)
a. IFC b. IFC c. IFC d. IFC
a. ALLPLAN b. DDS c. TRNSYS-TUD …
Building usage / Energy Consumption
a. Available for ARCH/HVAC/ ESIM
a. Name b. Type c. Quality d. Time profile
a. ESIM b. ESIM c. ESIM d. ESIM
a. ALLPLAN b. TRNSYS-TUD
Energy Source a. Available for HVAC/ ESIM
a. Name b. Type c. COP (min, max, part load) d. Behavioural characteristic e: Interface information f. Media output / yield g. Media input / effort h. Cost (Inv./ operation) i. Administrative data
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM h. ESIM i. ESIM
a. – i. TRNSYS-TUD
Transformation Facilities
a. Available for HVAC/ ESIM
a. Name b. Type c. COP (min, max, part load) d. Behavioural characteristic e: Interface information f. Media output / yield g. Media input / effort h. Cost (Inv./ operation) i. Administrative data
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM h. ESIM i. ESIM
a. – i. TRNSYS-TUD
Distribution System
a. Available for HVAC/ ESIM
a. Name b. Type c. COP (min, max, part load) d. Behavioural characteristic e: Interface information f. Media output / yield g. Media input / effort h. Cost (Inv./ operation) i. Administrative data
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM h. ESIM i. ESIM
a. – i. TRNSYS-TUD
Storage Systems
a. Available for HVAC/ ESIM
a. Name b. Type c. COP (min, max, part load) d. Behavioural characteristic e: Interface information f. Cost (Inv./ operation) g. Administrative data
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM
a. – g. TRNSYS-TUD
Automation and Control Systems
a. Available for HVAC/ ESIM
a. Name b. Type c. Facility d. Behavioural characteristic e: Interface information f. Cost (Inv./ operation) g. Administrative data
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM
a. – g. TRNSYS-TUD
Information Exchange
a. Available for HVAC/ ESIM
a. Name b. Type c. Content d. Protocol e: Security f. Cost (Inv./ operation) g. Administrative data
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM
a. – i. TRNSYS-TUD
D2.3 Holistic KPI based design methodology
Version 1.0
Page 68/87
© eeEmbedded Consortium www.eeEmbedded.eu
2.2.3 BACS domain
Template Metadata Content data Format Tools
Office Building Control 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Thermal Control d. Heating Plant Control e. Cooling Plant Control f. Thermal Distribution g. Building Control Strategy h. Building Control Equipment i. Build. Identifier Description j. Building Use k. …
General Template Information a. UID b. Name c. Description Key Design Parameter d. Efficiency Class e. Efficiency factor f. Covered Functional Requirements … Further content is provided either (1) by template interlinkage (see links meta data column) or (2) directly in content data section. For case (2) the content data section covers the following information: BACS Equipment g. Sensors h. Actuators i. Controller BACS System View j. Heating Control System k. Cooling Control System l. … Functional Description m. BAC function 1...n n. TBM function 1…n o. … Identifier Descriptions p. Data Point Identifier 1 …n
a. IFC / ESIM b. IFC / ESIM c. IFC / ESIM d. IFC / ESIM e. IFC / ESIM f. IFC / ESIM g. IFC / ESIM h. IFC / ESIM i. IFC / ESIM j. IFC / ESIM k.IFC / ESIM l. IFC / ESIM m. ESIM n. ESIM o. ESIM p. ESIM
a. eeBACS Wizard b. TRNSYS
Thermal Control 001
a. Available for All Domains b. Available for BACS, ESIM, HVAC) c. Last edition: A.A – D/M/A Links to other templates: d. Fan-Coil Control e. Temperature Sensor f. ...
General Template Information a. UID b. Name c. Description Key Design Parameter d. Efficiency Class e. Efficiency factor f. Covered Functional Requirements … Further content is provided either (1) by template interlinkage (see links meta data column) or (2) directly in content data section. For case (2) the content data section covers the following information: BACS Equipment g. Sensors h. Actuators i. Controller Thermal Control System View
a. IFC / ESIM b. IFC / ESIM c. IFC / ESIM d. IFC / ESIM e. IFC / ESIM f. IFC / ESIM g. IFC / ESIM h. IFC / ESIM i. IFC / ESIM j. IFC / ESIM k.IFC / ESIM l. IFC / ESIM m. ESIM n. ESIM o. ESIM p. ESIM
a. eeBACS Wizard b. TRNSYS
D2.3 Holistic KPI based design methodology
Version 1.0
Page 69/87
© eeEmbedded Consortium www.eeEmbedded.eu
Template Metadata Content data Format Tools
j. Air Conditioning Control System k. Fan-Coil Control System l. … Functional Description m. BAC function 1...n n. TBM function 1…n o. … Identifier Descriptions p. Data Point Identifier 1 …n
Fan-Coil Control 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. … (depends on LoD)
General Template Information a. UID b. Name c. Description Key Design Parameter d. Efficiency Class e. Efficiency factor f. Covered Functional Requirements … Further content is provided either (1) by template interlinkage (see links meta data column) or (2) directly in content data section. For case (2) the content data section covers the following information: BACS Equipment g. Sensors h. Actuators i. Controller Fan-Coil Control System View j. Valve Control System k. … Functional Description l. BAC function 1...n m. TBM function 1…n n. … Identifier Descriptions o. Data Point Identifier 1 …n
a. IFC / ESIM b. IFC / ESIM c. IFC / ESIM d. IFC / ESIM e. IFC / ESIM f. IFC / ESIM g. IFC / ESIM h. IFC / ESIM i. IFC / ESIM j. IFC / ESIM k.IFC / ESIM l. IFC / ESIM m. ESIM n. ESIM o. ESIM
a. eeBACS Wizard b. TRNSYS-TUD
Temperature Sensor 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Temperature Measurement Function d. Temperature Sensor Equipment e. LCC/LCA Information f. Risk Information g. Maintenance Information
General Template Information a. UID b. Name c. Description Key Design Parameter d. Efficiency Class e. Covered Functional Requirements … Further content is provided either (1) by template interlinkage (see links meta data column) or (2) directly in content data section. For case (2) the content data section covers the following information:
a. IFC / ESIM b. IFC / ESIM c. IFC / ESIM d. IFC / ESIM e. IFC / ESIM f. ESIM g. ESIM h. IFC / ESIM i. ESIM j. IFC / ESIM k.IFC / ESIM l. IFC / ESIM m. ESIM n. ESIM o. ESIM
a. eeBACS Wizard b. TRNSYS
D2.3 Holistic KPI based design methodology
Version 1.0
Page 70/87
© eeEmbedded Consortium www.eeEmbedded.eu
Template Metadata Content data Format Tools
f. Sensor Component Functional Description g. Temperature Measurement Function Identifier Descriptions h. Data Point Identifier 1 …n Risk Information i. Mean Time to Failure (MTTF) LCC Information j. Device Costs (€) k. Labor Price (€) LCA Information l. Power Consumption m. Packaging n. Synthetics o. Metal
Heating Plant Control 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Temperature Sensor 003 d. … (depends on LoD)
See Template - Thermal Control 001
a. eeBACS Wizard b. TRNSYS
Temperature Sensor 003
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. … (depends on LoD)
See Template – Temperature Sensor 001
a. eeBACS Wizard b. TRNSYS
Cooling Plant Control 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Temperature Sensor 003 d. … (depends on LoD)
See Template - Thermal Control 001
a. eeBACS Wizard b. TRNSYS
Thermal Distribution Control 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Flow Sensor 001 d. … (depends on LoD)
See Template - Thermal Control 001
a. eeBACS Wizard b. TRNSYS
Flow Sensor 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. … (depends on LoD)
See Template – Temperature Sensor 001
a. eeBACS Wizard b. TRNSYS
Building Control Strategy 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. BAC function 001 d. BAC function xyz e. TBM function 001 f. TBM function xyz g. …
a. Type of Control Strategy (Operational, Short-term, mid-term, long-term) b. Efficiency Class – A, B, C, D c. Complexity BAC Functions d. Function 1 (name or algorithm) e. Function 1 (name or algorithm) TBM Functions
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM
a. eeBACS Wizard b. TRNSYS
D2.3 Holistic KPI based design methodology
Version 1.0
Page 71/87
© eeEmbedded Consortium www.eeEmbedded.eu
Template Metadata Content data Format Tools
f. Function 1 (name or algorithm) g. Function 1 (name or algorithm)
BAC function 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Functional Interface 001
a. Type of BAC function b. Efficiency Class – A, B, C, D c. Complexity d. Functional description (text) Functional Interface e. Input 1 (name, type, unit) f. Input n (name, type, unit) g. Output 1 (name, type, unit) h. Output n (name, type, unit) i. Parameter 1 (name, type, unit) j. Parameter n (name, type, unit)
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM h. ESIM i. ESIM j. ESIM
a. eeBACS Wizard b. TRNSYS
TBM function 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Functional Interface 001
a. Type of BAC function b. Efficiency Class – A, B, C, D c. Complexity d. Functional description (text) Functional Interface e. Input 1 (name, type, unit) f. Input n (name, type, unit) g. Output 1 (name, type, unit) h. Output n (name, type, unit) i. Parameter 1 (name, type, unit) j. Parameter n (name, type, unit)
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM h. ESIM i. ESIM j. ESIM
a. eeBACS Wizard b. TRNSYS
Building Control Equipment 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Physical Interface 001 d. Manufacturer Information e. Risk Information f. LCC/LCA Information
Manufacturer Information a. Manufacturer b. Model name c. Article/Product/Model number d. Year of Production e. etc. Risk Information f. Mean Time to Failure (MTTF) LCC Information g. Device Costs (€) h. Labor Price (€) Technical Properties i. Supply Power (W) j. Weight (kg) k. …
a. IFC b. IFC c. IFC d. IFC e. IFC f. IFC g. IFC h. IFC i. IFC j. IFC k. IFC
a. eeBACS Wizard b. TRNSYS
Physical Interface 001
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A Links to other templates: c. Physical Port 1 d. Physical Port n
a. Type of Connection b. Wired/Wireless b. Protocol (BACnet, EnOcean…) c. Bandwidth (number) d. Latency (number) e. Reliability f. Security level (high, low) g. …
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM
a. eeBACS Wizard b. TRNSYS
D2.3 Holistic KPI based design methodology
Version 1.0
Page 72/87
© eeEmbedded Consortium www.eeEmbedded.eu
Template Metadata Content data Format Tools
Building Control Identifier Description
a. Available for All Domains (Available for BACS, ESIM, HVAC) b. Last edition: A.A – D/M/A
a. Component (name) b. Component Type (e.g. SENSOR) b. Data Point (e.g. TEMPERATURE) c. Medium(e.g. AIR) d. Kind (e.g. FORECAST) e. Unit (SI Units) f. Value Range g. Link to other Identifiers
a. ESIM b. ESIM c. ESIM d. ESIM e. ESIM f. ESIM g. ESIM
a. eeBACS Wizard b. TRNSYS
Building use a. Available for ARCH&HVAC b. Last edition: A.A – D/M/A …
People a. Number of persons (person/m
2)
b. Gain (W/m) c. Schedule Lighting d. Power (W/m
2)
e. Schedule Comfort conditions f. Cooling set point g. Heating set point h. Cooling Schedule i. Heating schedule j. Air quality
a. IFC b. IFC c. IFC d. IFC e. IFC f. IFC g. IFC h. IFC i. IFC j. IFC
a. ALLPLAN b. DDS c. TRNSYS d. eeBACS Wizard
2.2.4 FM domain
Template Metadata Content data Format Tools
Equipment Type Data Sheet
a. Available for FM&HVAC
a. Equipment Type Name
b. Manufacturer
c. Model Number
d. Warranty Guarantor Parts
e. Warranty Duration Parts
f. Warranty Guarantor Labor
g. Warranty Duration Labor
h. IOM Instructions GUID
i. Spare/Repair Parts List
j. Preventive Maintenance actions and time required
k. Scheduled Routine O&M actions and time required
a. IFC
b. IFC
c. IFC
d. IFC
e. IFC
f. IFC
g. IFC
h.IFC
i. IFC
j. IFC
k.IFC
a. Granlund Designer
b. DDS
Equipment Component Data Sheet
a. Available for FM&HVAC&LCC
a. Equipment Component Name
b. Equipment Type Name Reference
c. Designation
d. Location
e. Associated System
f. Serial Number
g. Purchase Order Number
h. Purchase Order Date
i. New or Rebuilt
j. Installation Date
k. Warranty Start Date
a. IFC
b. IFC
c. IFC
d. IFC
e. IFC
f. IFC
g. IFC
h.IFC
a. Granlund Designer
b. DDS
D2.3 Holistic KPI based design methodology
Version 1.0
Page 73/87
© eeEmbedded Consortium www.eeEmbedded.eu
Maintenance task a. Available for FM&HVAC&LCC
…
a. Description
b. Maintenance Type
c. Technician Category
d. Required Time
e. Required Tools
f. Required Supplies
g. Frequency
h. Overhaul Basis
a. IFC
b. IFC
c. IFC
d. IFC
e. IFC
f. IFC
g. IFC
h. IFC
a. Granlund Designer
b. DDS
2.2.5 Simulation domain
Energy simulation
Template Metadata Content data Format Tools Simulation pre-processing
a. Available for SIM
a. Job matrix b. Sim tool setup c. Computational resource mgmt. d. Set up of standard outputs
a. tbd b. tbd c. tbd d. tbd
a. SIM b. SIM c. SIM d. SIM
Simulation processing
a. Available for SIM
a. Job matrix b. Simulation management
a. tbd b. tbd
a. SIM b. SIM
Simulation post-processing
a. Available for SIM
a. Standard output value setup b. Standard graphical output setup
a. tbd b. tbd
a. SIM b. SIM
CFD simulation
Template Metadata Content data Format Tools
Simulation pre-processing
a. Available for SIM, HVAC, BACS, ESIM
a. Job matrix. Coupling Between CFD and Energy Simulations. b. Sim tool setup. Translation of template data sets to CFD domain boundary conditions (inlet wind profile, proposed HVAC system installation, type of diffusers for HVAC, velocity profiles on airflow inlets etc.). c. Computational resource mgmt. d. Set up of standard outputs and KPIs user defined interpretations.
a. tbd b. tbd c. tbd d. tbd
a. ALLPLAN b. DDS c. TRNSYS d. eeBACS
Simulation processing
a. Available for SIM, HVAC, BACS, ESIM
a. Job matrix b. Simulation management
a. tbd b. tbd
a. SIM b. SIM
Simulation post-processing
a. Available for SIM, HVAC, BACS, ESIM
a. Standard output value setup b. Standard graphical output setup c. Output of results needed for ES-CFD iterations. d. Detailed results for HVAC optimum installation. e. Optimized openings for
a. tbd b. tbd c. tbd d. tbd e. tbd f. tbd
a. ALLPLAN b. DDS c. TRNSYS d. eeBACS
D2.3 Holistic KPI based design methodology
Version 1.0
Page 74/87
© eeEmbedded Consortium www.eeEmbedded.eu
Template Metadata Content data Format Tools
natural ventilation design. f. Allowable limits for ventilation parameters (ACH) or thermal comfort KPIs per space and per use.
2.2.6 LCA domain
Template Metadata Content data Format Tools
LCA a. Project Phase b. Last Modified c. Links to other Templates d. Building Type e. Use Case Type …
Project Alternatives: a. Element Planning b. BoQ c. Job Estimate d. BIM Qualifier … Catalogues: e. Commodity f. Currencies … Configurations: i. Sytem Characteristics …
a. rpz
a. iTWO
2.2.7 LCC domain
Template Metadata Content data Format Tools
LCC a. Project Phase b. Last Modified c. Links to other Templates d. Building Type e. Use Case Type …
Project Alternatives: a. Element Planning b. BoQ c. Job Estimate d. BIM Qualifier … Catalogues: e. Assemblies f. Commodity g. Cost Codes h. Plants … Configurations: i. Sytem Characteristics …
a. rpz
a. iTWO
D2.3 Holistic KPI based design methodology
Version 1.0
Page 75/87
© eeEmbedded Consortium www.eeEmbedded.eu
3. Key Point Specifications beyond Implementations
This chapter is focussed on the Key Point formalisation for the eeE sustainable value introduced in
D2.1. The three identified Key Point Groups (1) Decision Value (DV), (2) Key Performance Indicators
(KPIs), and (3) Key Design Parameters (KDPs) are specified and will be basis for the development of
the eeE ontology to support the design process of energy-efficient and sustainable buildings optimally
embedded in their neighbourhood.
3.1 Preliminary Concepts and Roadmap
First visions and concepts of the eeE Key Point (KP) approach were developed in Deliverable 1.1
[Geißler et. al, 2014] to guide the multi-disciplinary design process and to focus on reaching the
optimum value for the client as fast as possible. In Deliverable 1.2 [Geißler et. al, 2014] the Key Points
were defined for verification, validation as well as decision making and described as gateways in the
Information Delivery Manual (IDM) for the three eeE design phases. Deliverable 2.1 [Guruz et. al,
2015] defines and specifies concepts, procedures and software solutions which constitute the
fundamental structure of the eeE Key Point Framework.
Key Points are energy related verifiable design check points, which are providing domain
related requirements in form of target values, which can be checked after common design
steps. These Key Points will also allow planners to easily structure the design process in
individual evaluable parts and will thus help them to concentrate on high-level strategic
decision making tasks. The eeE Key Point driven design process is expected to lead to greater
efficiency in the planning procedure to get final design results of higher quality. At the same
time, it will provide an opportunity of weighing up many more alternatives than currently
possible. [Guruz et. al, 2015]
Figure 33: Key Points – Requirements Decomposition and Result Aggregation
The procedures to evaluate requirements and setup Key Points, procedures to evaluate design
alternatives and procedures for the overall Key Point Methodology have been identified, the
D2.3 Holistic KPI based design methodology
Version 1.0
Page 76/87
© eeEmbedded Consortium www.eeEmbedded.eu
sequences of the steps of the Key Point Workflow have been specified via Unified Modelling
Language (UML) and implementation plans for the required S/W components have been developed.
Figure xy shows the concept of decomposing requirements, to set up Key Points, as well as the
aggregation of design results. This will be the basis for the formalisation and development of an eeE
ontology.
3.2 Sustainable Score - Certification Systems in eeE
First of all a study of different certification systems (German Sustainable Building Certificate (DGNB),
Leadership in Energy and Environmental Design (LEED), Building Research Establishment
Environmental Assessment Method (BREEAM) etc.) and building valuation techniques is done to
identify how to set up a Key Point (KP) Framework for sustainable buildings.
3.2.1 Standardized certifications
In the commonly used certification systems such as German Sustainability Standard (DGNB),
Leadership in Energy and Environmental Design (LEED), Building Research Establishment
Environmental Assessment Method (BREEAM) etc. the sustainable value of the building is expressed
as a sustainable score.
Figure 34: Example of an assessment matrix according to DGNB [Green Building Council Denmark]
At the beginning of the project the client specifies which score he wants to achieve. Within the
certification systems the weighting factor of the value drivers (ecologic, socio-cultural and economic
value) as well as the impact factor of each Key Performance Indicator (KPI) is pre-defined. Because
D2.3 Holistic KPI based design methodology
Version 1.0
Page 77/87
© eeEmbedded Consortium www.eeEmbedded.eu
the KPIs have different properties, there is the need to introduce a rating scale based on points or
percentage fulfilment. A rating scale is defined by the KPIs and the compliance specification.
3.2.2 eeE Sustainable Value (eeSV)
In this section, the eeE Sustainable Value (eeSV) as project related example is introduced. This “test
energy certification” is used to specify main values and helps us to concentrate and verify on eeE
approach and not on completeness of a high level energy certifications. The method is always
possible to existing certificates.
The eeSV is developed as a “test certification”. We would like to explain in more detail what this
means: in this project we have limited number of actors, tools and budgets. The developed method is
planned to be proofed by our test cases. The idea is, commonly accepted certification systems are
adapted for the eeE Sustainable Value (eeSV) formalisation based on our project resources. The most
relevant KPI which influence the eeSV and can be processed by the eeE integrated energy simulation
and cost analysis tools, have been identified in D2.1 chapter 6 to be final energy, primary energy,
emissions, thermal comfort, air quality and life cycle costs. Table 1 shows an overview of Key
Performance Indicators as well as their importance for different sustainability certification.
Table 1: Sustainable Key Performance Indicators used in certification systems [extended Luft, 2013]
high requirement
medium requirement
low requirement
not included
eeSV Passive house DGNB LEED BREEAM
Ecologic Indicators Primary energy
Emissions - Life Cycle Assessment
Risks to the regional environment
Other impacts on the global environment
Fresh water usage
Land use
Socio-cultural Indicators Thermal comfort
Indoor air quality
Acoustical comfort
Visual comfort
Economic Indicators Building-related life cycle costs
Value stability
D2.3 Holistic KPI based design methodology
Version 1.0
Page 78/87
© eeEmbedded Consortium www.eeEmbedded.eu
3.3 eeE Key Point Formalisation
For eeE Key Point Formalisation a matrix was developed (see 1). In this matrix the Key Points are
specified at each level - Level 1 Decision Value (DV), Level 2 Key Performance Indicators (KPI), Level 3
Key Design Parameters (KDP). Figure 34 shows the structure, the bright coloured frames are set, the
dark coloured are to fulfil by users.
3.3.1 Level 1: Decision Value (DV)
The Key Point Formalisation begins with the specification to assess the value which can be defined as
a sustainable score to be achieved for comparison of different alternatives. See Annex 1.
a) Domain The decision making domain is responsible for the specification and decision making with Decision Value. This is fixed.
b) Weighting factor [%] The decision making domain can set weighting factors for prioritization of the different sustainability aspects regarding his preferences.
Figure 35: Decision Value 1.1b to enter by users
3.3.2 Level 2: Key Performance Indicators (KPI)
In the next step, all Key Performance Indicators (KPI) which influence the sustainable score have to
be derived. Figure 35 shows the structure, again the bright coloured frames are set, the dark
coloured are to fulfil by users. See Annex 1.
a) Domain
The Simulation, Life Cycle Assessment (LCA), Life Cycle Cost (LCC) domains are responsible for
the specification and validation with KPIs.
b) c) d) KPI to-be (incl. range values) The responsible domains can set KPI to-be target values, which can be found in the predefined list of DV’s (they are combined).
D2.3 Holistic KPI based design methodology
Version 1.0
Page 79/87
© eeEmbedded Consortium www.eeEmbedded.eu
e) Compliance target value
The responsible domains can define the compliance with target value (KPI to-be) e.g. 0 %, 25
%, 50 %,75 %, 100 % fulfilment.
Figure 36: Compliance scale for KPI
3.3.3 Level 3: Key Design Parameter (KDP)
In the last step, all building components and their respective Key Design Parameter (KDP) with
impact to the specific KPI, have to be determined and formalised. Some KDP are already defined and
act as constraints in the design process, whilst other parameters can be adapted to optimise primary
energy, minimize emissions, maximise comfort and minimize the life cycle costs. Figure 37 shows the
structure, the bright coloured frames are set, the dark coloured are to fulfil by users. See Annex 2-5.
a-c) Domain The Key design Parameter, its’ unit and the domain which is responsible for the specification and verification with KDP can be found here and are set.
d) IFC Exchange Requirement Describes the data source in IFC.
KDP to-be The responsible domains can set KDP target values.
e) Target value [Y/N]
f) Target value [number]
g) Target value [unit]
Figure 37: Compliance scale for KPI
D2.3 Holistic KPI based design methodology
Version 1.0
Page 80/87
© eeEmbedded Consortium www.eeEmbedded.eu
3.4 eeE Sustainable Value Example
An example is given in this section to show the method how to set up the Key Point Framework per
project and how the eeE Sustainable Value (eeSV) is calculated. The compliance target value function
is close to the functions used by the German Sustainability Certification Standard (DGNB). Of course
this will be specified and detailed with the pilot projects when the eeE BIM Lab is running.
Key Point Set up
The Decision Making Domain sets up the project by defining the targeted eeSV, e.g. expressed in a
gold medal. All Key Performance Indicators (KPI) which influence the eeSV are listed. The decision
maker can choose the ones which are of most importance for him and weight them by a weighting
factor [%]. In the following example the KPIs are equally important for him (25 % for every KPI).
However, the decision maker can choose another weighting as well.
Figure 38: Key Point Set Up - Decision Value (DV)
In the next step, the Simulation, LCA and LCC domains set their KPI to-be and the compliance with
target value function.
Figure 39: Key Point Set Up - Key Performance Indicators (KPI)
Level 1: Decision Value a) Domain b) Weighting
factor [%]
2.2.1 Fossil fuels [kWh/(m2 x a)]
2.2.2 Renewables [kWh/(m2 x a)]
2.2.3 Electricity [kWh/(m2 x a)]
2.3.1 Manufacturing [kg CO2 equivalent / (m2 x a)]
2.3.2 Operation [kg CO2 equivalent / (m2 x a)]
2.3.3 Renewal [kg CO2 equivalent / (m2 x a)]
2.4.1 Temperature over- / underuns [Kh]
2.4.2 Predicted Mean Vote [-]
2.4.3 Predicted Percentage of Dissatisfied [%]
2.6.1 Investment costs *€/(m2]
2.6.2 Operation costs *€/(m2]
2.6.3 Maintenance costs *€/(m2]
Level 2: Key Performance Indicator
1.1 ee Sustainable
Value (eeSV)DM
25% 2.6 Life Cycle Costs
25% 2.3 Emissions
25% 2.4 Thermal Comfort
25% 2.2 Primary Energy
a) Domain c) KPI to be:
Lower bound
d) KPI to-be:
Upper bound
e) Compliance target value [%]
2.2.1 Fossil fuels [kWh/(m2 x a)]
2.2.2 Renewables [kWh/(m2 x a)]
2.2.3 Electricity [kWh/(m2 x a)]
2.3.1 Manufacturing [kg CO2 equivalent / (m2 x a)]
2.3.2 Operation [kg CO2 equivalent / (m2 x a)]
2.3.3 Renewal [kg CO2 equivalent / (m2 x a)]
2.4.1 Temperature over- / underuns [Kh]
2.4.2 Predicted Mean Vote [-]
2.4.3 Predicted Percentage of Dissatisfied [%]
2.6.1 Investment costs *€/(m2]
2.6.2 Operation costs *€/(m2]
2.6.3 Maintenance costs *€/(m2]
120
0 % is > 230
25 % is 230
50 % is 170
75 % is 140
100 % is 120
> 3.720 < 2.100
0 % is > 3.720
25 % is < 3.360
50 % is < 3.000
75 % is < 2.640
100 % is < 2.100
0 % is 50
25 % is 45
50 % is 35
75 % is 30
100 % is 24
Indoor climate class S1
0 % is Indoor climate class S3
50 % is Indoor climate class S2
100 % is indoor climate class S1
50 24
SIM 230
Indoor climate class S3
LCC
Level 2: Key Performance Indicator
2.6 Life Cycle Costs
2.3 Emissions LCA
2.4 Thermal Comfort SIM
2.2 Primary Energy
D2.3 Holistic KPI based design methodology
Version 1.0
Page 81/87
© eeEmbedded Consortium www.eeEmbedded.eu
In the last step, the Architectural and Energy System (ESIM) domain set their KDP to-be. The
following example is for the Urban Design. In the other phases also additional domains are involved.
For example, the Architect, defines KDP to-be based on the client requirements and the restrictions
by the master plan. And the ESIM domain sets KDP to-be to meet the national regulations e.g. on-site
renewable solar energy of 15 %.
…
…
Figure 40: Key Point Set Up - Key Design Parameter (KDP)
Key Point Evaluation
The Architectural and Energy System (ESIM) domain and the respective other design domains can
verify the KDP in the Multi-Model Navigator.
After the models are verified, simulation and analysis are performed, the results post-processed and
the Simulation, LCA and LCC domains can evaluate based on the Alternative, Sensitivity and
Uncertainty Analysis Results.
After validation of the KPI per domain, the KPI are transferred with the compliance target function,
that they can be aggregated and weighted regarding the preferences of the decision maker to a total
score used for decision making.
In figure xy the calculation of the total score is exemplified.
Figure 41: Calculation of the total score
Level 3: Key Design Parameter
(Urban Design LoD 100)Unit
Domain IFC Exchange requirement Target
value
[Y/N]
Target
value
[number]
Target
value
[unit] Building shape Arch
Compactness A/V [m-1] NForm l/w/h [m] Y 60/120 m
Size of the zone [m2, m3] Y 8.000 m2
Window Wal l area Ratio (WWR) [%] NNumber of s tories [-] NBui lding height [m] Y 10 m
Renewable energy ESIMOn-site renewables thermal energy [%] Y 15 %
Analysis results Compliance target Weighting factor Total Score
Primary energy 120 100% x 25% 25%
Emissions 35 50% x 25% 13%
Indoor climate class S2 50% x 25% 13%
Cost 2.500 75% x 25% 19%
69%
D2.3 Holistic KPI based design methodology
Version 1.0
Page 82/87
© eeEmbedded Consortium www.eeEmbedded.eu
Conclusions
This deliverable marks the conclusion of the first part by end users in eeE. Synthesizing the results of
T 2.1-2.6, a holistic, hierarchically structured design methodology has been developed.
All previously developed concepts and procedures were gathered, fleshed out and thoroughly
analysed in Part A: from this examination we developed detailed process steps (based on eeE use
cases) of the envisaged Key Point driven design process. In this tables (1.2-1.4) in-depth information
on fields such as which actors work on which process step, what are their goals, the flow of
information (input/output) and each subtask have been developed and have been disclosed
thoroughly. As a result for each process step a complete updated workflow was devised and in Part B
we worked on the exact specifications for Templates and Key Points of those workflows.
The outcomes are a specified template library structure (2.1) and template content (2.2) as a premise
for implementation as well as the Key Point specification tables (3.3).
For the next step we envision a development process that involves working out, testing and
implementing the technical specifications of the workflow. This will be achieved in the coming WPs.
Further fields of work include:
As part of D3.2 “Sustainability prognosis, quality and ROI methods.” methods for aggregation of Key Points and prototypes of mathematical methods based on link model information as well as the ontology model for multi-criteria optimization will be developed,
A first idea of Key Point Ontology will be part of D5.1 “Interoperability and ontology framework”,
An implementation of the Key Point Ontology will be done in D5.2 “Interoperability System”, The eeE ontology for decomposition of Key Points will be further specified and developed in
D6.5 “Optimization of multi-model criteria”.
D2.3 Holistic KPI based design methodology
Version 1.0
Page 83/87
© eeEmbedded Consortium www.eeEmbedded.eu
References
Baumgärtel, K., Katranuschkov, P., Hollmann, A., Laine, T., Protopsaltis, B., Dolenc, M., Klinc, R.,
Guðnason, G. & Balaras, C. (2013): ISES Deliverable D2.2: Architecture and components of the
Virtual Lab Platform, © ISES Consortium, Brussels.
Calleja Rodriguez, G., Guruz, R., (2014): eeEmbedded Deliverable 1.3: Interoperability and
collaboration requirements, © eeEmbedded Consortium, Brussels.
eeEmbedded 2013-17, EU FP7 Project No. 609349. eeEmbedded [online],
http://www.eeEmbedded.eu.
eeEmbedded (2013); EU FP7 Project No.: 609349, Annex I of Grant agreement: Description of
Work, Grant agreement, © eeEmbedded Consortium, Brussels.
Geißler, M.C., Guruz, R., van Woudenberg, W. (2014); eeEmbedded Deliverable D1.1: Vision and
requirements for a KPI-based holistic multi-disciplinary design, © eeEmbedded Consortium,
Brussels.
Geißler, M.C., Guruz, R., van Woudenberg, W. (2014); eeEmbedded Deliverable D1.2: Use case scenarios and requirements specification, © eeEmbedded Consortium, Brussels.
Green Building Council Denmark, An introduction to DGNB - Ensure the quality of your sustainable
buildings in planning, construction, and operation. The DGNB system helps you get there,
http://www.dk-gbc.dk/media/67284/dgnb_dk-gbc_oct_2012.pdf
Guruz, R., Calleja-Rodríguez, G. Geißler, M.-C., (2015): eeEmbedded D2.1 Holistic multi-disciplinary
Key Point-based design framework, © eeEmbedded Consortium, Brussels.
Katranuschkov P., Baumgärtel K., Guruz R., Scherer R. J., Kaiser J., Grunewald J., Hensel B., Steinmann R., Zellner R., Laine T., Hänninnen R. (2011): HESMOS Deliverable D2.2: The HESMOS Architecture, © HESMOS Consortium, Brussels.
Liebich, T., Stuhlmacher, K., Guruz R., Baumgärtel K., Geißler M.C., van Woudenberg W., Kaiser J.,
Hensel B., Zellner R., Laine T., Jonas F. 2011. D2.1 BIM enhancement specification. 2011. Christian Luft, Das DGNB System im internationalen Vergleich, http://www.dgnb.de/fileadmin/de/dgnb_ev/Veranstaltungen/eigene_veranstaltungen/dgnb -impuls/Vortraege_Impuls/Praesentation_Impuls_System_im_intern_Vergleich.pdf Solvik, K., Kaiser, J. (2014); eeEmbedded D1.4: Requirements for knowledge-based design support and templates, © eeEmbedded Consortium, Brussels. Zellner, R., Guruz, R., Mosch, M., Katranuschkov, P., Tøn, A. & Kaiser, J. (2015): eeEmbedded Deliverable D1.5: System Architecture of the virtual holistic design lab and office © eeEmbedded Consortium, Brussels.
Annex
Level 1: Decision Value (DV) and combined Level 2: Key Performance Indicators (KPI)
D2.3 Holistic KPI based design methodology
Version 1.0
Page 85/87
© eeEmbedded Consortium www.eeEmbedded.eu
Level 3: Key Design Parameter (KDP) – Urban Design
D2.3 Holistic KPI based design methodology
Version 1.0
Page 86/87
© eeEmbedded Consortium www.eeEmbedded.eu
Level 2: Key Design Parameter (KDP) – Early Design
D2.3 Holistic KPI based design methodology
Version 1.0
Page 87/87
© eeEmbedded Consortium www.eeEmbedded.eu
Level 3: Key Design Parameter (KDP) – Detailed Design