eeembedded d2.3 holistic kpi based design...

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

/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.


Version 1.0

/87


Project of SEVENTH FRAMEWORK PROGRAMME OF THE EUROPEAN COMMUNITY

Dissemination Level

PU Public X

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

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

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


Version 1.0

/87


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


Version 1.0

/87


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


Version 1.0

/87


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.


Version 1.0

/87


Part A


Version 1.0

/87


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.


Version 1.0

/87


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.


Version 1.0

/87


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.


Version 1.0

/87


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


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


Version 1.0

/87


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 source City GML (not yet decided)

Sender actor ---


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


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.


Graphical representation results see KEY POINT workflow

results ok?


Collaboration Bus - BIM--it (Manager)SIM/ANA domain

Handover SIM/ANA domain

1 ALLPLAN


Version 1.0

/87


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 source

eeeBIMUDP=BIM

Sender actor Architectural Domain


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


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)


Collaboration Bus - BIM--it (Manager)Message to eSIM

Handover eSIM


Version 1.0

/87


Actors: 2 eSIM Domain

Task 1.4 Create energy supply options (eSIM)


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 source eeeBIMUDP=BIM

Simulation results I

Sender actor Architectural Domain

Simulation Domain


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


results ok?

Create eSIM Design

Upload eSIM Model

KEY POINT check KDP


eS Designer/ eSIM GUI






Upload eSIM model


OR




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)SIM/ANA domain


eS Designer/ eSIM GUI


Version 1.0

/87


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 source eeeBIMUDP=BIM+ESIM CFD simulation results

Sender actor Architectural Domain ESIM Domain Simulation Domain


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



Run Simulation




Energy Simulation

Preprocessing

Get Post-Processing results


results ok?

not ok


Open GUI SIM/ Analysist View: Select and upload variants



Stochastic pre-processing


Preprocessing

Risk analysis

Processing

Postprocessing








Collaboration Bus - BIM--it (Manager)Message to LCC domain

Handover LCC check



Version 1.0

/87


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 source

eeeBIMUDP=BIM+ESIM

Simulation Results

Sender actor

Architectural Domain

Energy System Domain

Simulation Domain


Information delivery LCC results

Receiver actor Decision-Making Domain


DECISION SUPPORT

BIM SERVER



Run Simulation




iTWO

Preprocessing



results ok?

not ok





Preprocessing

Processing

Postprocessing








Collaboration Bus - BIM--it (Manager)Message to DM domain

Handover Decision maker



Version 1.0

/87


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 source

Simulation results

LCC results

Sender actor

Simulation Domain

LCC Domain


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


KEY POINT check DVs (prepared results)

Select charts

Get results (charts)

link and save KPR, KDP, KPI and DV

results ok?


Select Process Pattern incl. DVs

Upload DVs Process Mgmt. Service (Ontology)


Collecting data for weighted evaluation

Generate Charts



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)


Collaboration Bus - BIM--it (Manager)Next Set up decision making domain

Set Up next Phase


Version 1.0

/87


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).


Version 1.0

/87


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 source

Requirements

Sender actor

Client


Information delivery Decision Requirements

Key Performance Requirements

Key Design Parameter

Receiver actor All Domains

Specifications - -

DECISION SUPPORT


1 Open variants previous phase

2 Setup current KEY POINT framework

3 Workflow check/setup




5 Check (set-up) and manage templates







Ontology

Management Services

BIM SERVER


Version 1.0

/87


Actors: Architectural Domain

Task 2.2 Create construction type alternatives


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 source

-

Sender actor

-


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


results ok?

Create construction type alternatives

Upload IFC Model

KEY POINT check KDP


1 ALLPLAN






Upload IFC model




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)HVAC domain

Handover HVACdomain

1 ALLPLAN


Version 1.0

/87


Actors: HVAC Domain

Task 2.3 Create HVAC type alternatives


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 source

eeeBIMEDP=BIM

Sender actor



Information delivery eeeBIMEDP=ESIM (HVAC)

Receiver actor BACS Domain (and following: FM, Simulation, LCA and LCC Domain)


DECISION SUPPORT

BIM SERVER


results ok?

Create HVAC type alternatives

Upload IFC Model

KEY POINT check KDP


2 DDS CAD





Make variance HVAC design

Upload IFC model




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)send Message to BACS domain

Handover BACS domain

2 DDS CAD


Version 1.0

/87


Actors: BACS Domain

Task 2.4 Create Control Strategy Alternatives


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 source

eeeBIMEDP= BIM+ESIM (HVAC)

Sender actor

Architectural Domain HVAC Domain


Information delivery eeeBIMEDP= ESIM (BACS)

Receiver actor FM Domain (and following: Simulation, LCA and LCC Domain)


DECISION SUPPORT

BIM SERVER


results ok?

Create Control Strategy Alternatives

Upload IFC Model

KEY POINT check KDP


3 eeBACS Wizard






Upload IFC model




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)send Message to FM domain

Handover FM domain

3 eeBACS Wizard


Version 1.0

/87


Actors: FM Domain

Task 2.5 Enrich alternatives with O&M information


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 source

eeeBIMEDP= BIM + ESIM (HVAC+BACS)

Sender actor


HVAC Domain

BACS Domain


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


results ok?


Upload IFC Model

KEY POINT check KDP

Send KDP and model

4 Granlund Designer






Upload IFC model





Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok




results ok?


Collaboration Bus - BIM--it (Manager)send Message to SIM/ANA domain


4 Granlund Designer


Version 1.0

/87


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 source

eeeBIMEDP=BIM+ESIM (HVAC+BACS)+FM

Sender actor

Architectural, HVAC, BACS & FM Domain


Information delivery Simulation Results

Receiver actor LCA, LCC &Decision-Making Domain


DECISION SUPPORT

BIM SERVER



Run Simulation




Energy Simulation

Preprocessing



results ok?

not ok







Preprocessing

Risk analysis

Processing

Postprocessing








Collaboration Bus - BIM--it (Manager)Message to LCA domain

Handover LCA check



Version 1.0

/87


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 source

eeeBIMEDP= BIM+ESIM (HVAC+BACS)+FM +Simulation Results

Sender actor

Architectural, HVAC, BACS, FM & Simulation Domain


Information delivery LCA results



DECISION SUPPORT

BIM SERVER



Run Simulation




iTWO

Preprocessing



results ok?

not ok





Preprocessing

Processing

Postprocessing





ok, ready for LCC




Handover LCC Domain



Version 1.0

/87


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



Information source

eeeBIMEDP= BIM+ESIM(HVAC+BACS)+FM

Sender actor

Architectural, HVAC, BACS, FM & Simulation Domain


Information delivery LCC results



DECISION SUPPORT

BIM SERVER



Run Simulation




iTWO

Preprocessing



results ok?

not ok





Preprocessing

Processing

Postprocessing












Version 1.0

/87


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 source

Simulation, LCA & LCC Results

Sender actor

Simulation, LCA &LCC Domain


Information delivery Decision Values

Receiver actor -


DECISION SUPPORT

BIM SERVER





Select charts



results ok?






Generate Charts




repeat or next LOD






Collaboration Bus - BIM--it (Manager)Next Set up decision making domain

Set Up next Phase


Version 1.0

/87


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).


Version 1.0

/87


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 source

- Requirements

Sender actor

- Client


Information delivery - Decision Requirements

- Key Performance Requirements

- Key Design Requirements

Receiver actor - All Domains

Specifications - -

DECISION SUPPORT


1 Open variants previous phase

2 Setup current KEY POINT framework

3 Workflow check/setup




5 Check (set-up) and manage templates







Ontology

Management Services

BIM SERVER


Version 1.0

/87


Actors: Architectural Domain

Task 3.2 Create architecture product alternatives


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 source

- BIMDDP=BIM

Sender actor

- HVAC, BACS, FM, Simulation, LCA & LCC Domain


Information delivery - Key Design Requirements

Receiver actor - Material

Specifications Templates 2.2.1 Key Point DD 3.0

DECISION SUPPORT

BIM SERVER


results ok?

Create construction type alternatives

Upload IFC Model

KEY POINT check KDP


1 ALLPLAN






Upload IFC model




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)HVAC domain

Handover HVACdomain

1 ALLPLAN


Version 1.0

/87


Actors: HVAC Domain

Task 3.3 Create HVAC product alternatives


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 source

- eeeBIMDDP =ESIM (HVAC)

Sender actor

- BACS, FM, Simulation, LCA & LCC Domain


Information delivery - Key Design Requirements

Receiver actor - HVAC component


DECISION SUPPORT

BIM SERVER


results ok?

Create HVAC type alternatives

Upload IFC Model

KEY POINT check KDP


2 DDS CAD





Make variance HVAC design

Upload IFC model




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)send Message to BACS domain

Handover BACS domain

2 DDS CAD


Version 1.0

/87


Actors: BACS Domain

Task 3.4 Design Sensor and Actor Network


Detailed task


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 source

- eeeBIMDDP=BIM+ESIM(HVAC)

Sender actor

- Architectural & HVAC Domain


Information delivery - eeeBIMDDP=ESIM (BACS)

Receiver actor - FM Domain - Simulation Domain - LCC Domain - LCA Domain


DECISION SUPPORT

BIM SERVER


results ok?


Upload IFC Model

KEY POINT check KDP


3 eeBACS Wizard






Upload IFC model




Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok





results ok?


Collaboration Bus - BIM--it (Manager)send Message to FM domain

Handover FM domain

3 eeBACS Wizard


Version 1.0

/87


Actors: FM Domain

Task 3.5 Enrich product alternatives with operational information


Detailed task


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 source

- eeeBIMDDP= BIM+ESIM (HVAC+BACS)

Sender actor

- Architect, HVAC & BACS engineer


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


results ok?


Upload IFC Model

KEY POINT check KDP

Send KDP and model

4 Granlund Designer






Upload IFC model





Check LOD and LoD




Modify Templates


Check LOD and LoD


not ok




results ok?


Collaboration Bus - BIM--it (Manager)send Message to SIM/ANA domain


4 Granlund Designer


Version 1.0

/87


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 source

- eeeBIMDDP=BIM+ESIM(HVAC+BACS)+FM

Sender actor

- Architectural, HVAC, BACS & FM Domain


Information delivery - Simulation results

Receiver actor - Decision-Making Domain


DECISION SUPPORT

BIM SERVER




Run Simulation




6 3D Wind

Preprocessing

Get results


results ok?

not ok


Open GUI SIM/ Analysist View



Template configuration



Preprocessing


Processing

Postprocessing








Collaboration Bus - BIM--it (Manager)Message to SIM Energy

Handover SIM Energy


Version 1.0

/87


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 source


Sender actor

- Architectural, HVAC, BACS & FM Domain


Information delivery - Simulation results

Receiver actor - LCA,- LCC Domain - Decision-Making Domain


DECISION SUPPORT

BIM SERVER



Run Simulation




Energy Simulation

Preprocessing



results ok?

not ok







Preprocessing

Risk analysis

Processing

Postprocessing








Collaboration Bus - BIM--it (Manager)Message to LCA domain

Handover LCA check



Version 1.0

/87


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



Information source


- Simulation Results

Sender actor

- Architectural domain

- HVAC domain

- BACS domain

- FM Domain

- Simulation Domain


Information delivery - LCA results



DECISION SUPPORT

BIM SERVER



Run Simulation




iTWO

Preprocessing



results ok?

not ok





Preprocessing

Processing

Postprocessing





ok, ready for LCC




Handover LCC Domain



Version 1.0

/87


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



Information source

- eeBIMDDP=BIM+ESIM(HVAC+BACS)+FM


Sender actor

- Architectural, HVAC, BACS, FM &- Simulation Domain


Information delivery - LCA results



DECISION SUPPORT

BIM SERVER



Run Simulation




iTWO

Preprocessing



results ok?

not ok





Preprocessing

Processing

Postprocessing












Version 1.0

/87


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 source


- LCA Results

- LCC Results

Sender actor

- Simulation Domain

- LCA Domain

- LCC Domain


Information delivery - Decision Values

Receiver actor -

Specifications Templates X.X Key Point 1.1

DECISION SUPPORT

BIM SERVER





Select charts



results ok?






Generate Charts




repeat or next LOD






Collaboration Bus - BIM--it (Manager)Send final Alternative

Set Up next Phase


Version 1.0

/87


Part B


Version 1.0

/87


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).


Version 1.0

/87


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.


Version 1.0

/87


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).


Version 1.0

/87


2.1.1 Architecture domain

Figure 5: Construction library

Figure 6: Building usage templates


Version 1.0

/87


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


Version 1.0

/87


Figure 8: Library structure ESIM Transformation Facilities

Figure 9: Library structure ESIM Distribution Systems


Version 1.0

/87


Figure 10: Library structure ESIM Storage Systems

Figure 11: Library structure ESIM Consumption/Usage


Version 1.0

/87


Figure 12: Library structure ESIM Weather/Climate

Figure 13: Library structure ESIM Automation control system


Version 1.0

/87


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


Version 1.0

/87


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.


Version 1.0

/87


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)


Version 1.0

/87


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.


Version 1.0

/87


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.


Version 1.0

/87


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


Version 1.0

/87


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


Version 1.0

/87


2.1.5 FM domain

Figure 21: Template library. Facility Management


Version 1.0

/87


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.


Version 1.0

/87


Figure 23: Library structure for CFD Analysis


Version 1.0

/87


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


Version 1.0

/87


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


Version 1.0

/87


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.


Version 1.0

/87


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.


Version 1.0

/87


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.


Version 1.0

/87


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].


Version 1.0

/87


Figure 30: eeE Cross-domain Template - General approach covering for example energy (sub-)systems, building / space type including usage and weather


Version 1.0

/87


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.


Version 1.0

/87


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


Semitransparent construction


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


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


Building use profile


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


Version 1.0

/87


2.2.2 ESIM/HVAC domain


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




Distribution System





Storage Systems


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. Name b. Type c. Facility d. Behavioural characteristic e: Interface information f. Cost (Inv./ operation) g. Administrative data


a. – g. TRNSYS-TUD

Information Exchange


a. Name b. Type c. Content d. Protocol e: Security f. Cost (Inv./ operation) g. Administrative data




Version 1.0

/87


2.2.3 BACS domain


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



Version 1.0

/87



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



Version 1.0

/87



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


Temperature Sensor 003


See Template – Temperature Sensor 001


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)



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)



Flow Sensor 001


See Template – Temperature Sensor 001


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




Version 1.0

/87



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


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


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


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. …




Version 1.0

/87



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



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


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


b. DDS


Version 1.0

/87


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


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. Job matrix b. Simulation management

a. tbd b. tbd

a. SIM b. SIM

Simulation post-processing


a. Standard output value setup b. Standard graphical output setup

a. tbd b. tbd

a. SIM b. SIM

CFD simulation


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. Job matrix b. Simulation management

a. tbd b. tbd

a. SIM b. SIM

Simulation post-processing


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


Version 1.0

/87



natural ventilation design. f. Allowable limits for ventilation parameters (ACH) or thermal comfort KPIs per space and per use.

2.2.6 LCA domain


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


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


Version 1.0

/87


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


Version 1.0

/87


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


Version 1.0

/87


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


Version 1.0

/87


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).


Version 1.0

/87


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


Version 1.0

/87


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


Version 1.0

/87


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%


Version 1.0

/87


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”.


Version 1.0

/87


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.

http://www.eeembedded.eu/

http://www.dk-gbc.dk/media/67284/dgnb_dk-gbc_oct_2012.pdf

http://www.dgnb.de/fileadmin/de/dgnb_ev/Veranstaltungen/eigene_veranstaltungen/dgnb

http://www.dgnb.de/fileadmin/de/dgnb_ev/Veranstaltungen/eigene_veranstaltungen/dgnb

Annex

Level 1: Decision Value (DV) and combined Level 2: Key Performance Indicators (KPI)


Version 1.0

/87


Level 3: Key Design Parameter (KDP) – Urban Design


Version 1.0

/87


Level 2: Key Design Parameter (KDP) – Early Design


Version 1.0

/87


Level 3: Key Design Parameter (KDP) – Detailed Design

eeembedded d2.3 holistic kpi based design...

Documents