Eeembedded – D10.400 Final Project Report

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 – D10.400 Final Project Report

Responsible Authors: Peter Katranuschkov and Raimar J. Scherer (eds.)

Contributions: All project partners

Due date: 30.09.2017 Issue date: 17.09.2017 Nature: OTHER

Coordinator: R. J. Scherer, Institute for Construction Informatics, Technische Universität Dresden, Germany D10.400 Final Project Report Version 1.0 Page 2/80

Start date of project: 01.10.2013 Duration: 48 months

Organisation name of lead contractor for this deliverable: Coordinator: TECHNISCHE UNIVERSITAET DRESDEN, Institute of construction informatics.

History

Version Description Lead Author Date 0.1 Deliverable Structure Peter Katranuschkov, Romy Guruz (CIB) 31.05.2017 0.2 Input Chapters 1, 2 and sect. 7.2.1 Romy Guruz (CIB) 14.06.2017 0.3 Contributions to Chapter 7 A. Ton (EPM) 21.06.2017 0.4 Contributions to Chapter 7 G. Dangl (IAB), A. Sukumar (RIB) 25.07.2017 0.5 Contributions to Chapters 4 and 7 M. Löffler (BAM), S. Poloczek (STA) 08.08.2017 0.5 Contributions to Chapter 7 P. Stenzel (EAS), F. Forns-Samso (GRA) 24.08.2017 0.6 Contributions to Chapter 7 R. Schär (SAR), J. Kaiser (IET) 01.09.2017 0.7 Contributions to Part 2 A. Navas (CEM) 01.09.2017 0.8 Contributions to Chapters 4, 5, 8 M. Löffler (BAM), S. Poloczek (STA) 04.09.2017 0.9 Contributions to Chapters 3, 6, 7 K. Baumgärtel, H. Pruvost, T. Grille, 05.09.2017 P. Katranuschkov (CIB) 1.0 First complete draft of the report P. Katranuschkov (CIB) 06.09.2017 1.1 Contributions to Chapter 7 E. Mrazek, R. Zellner (NEM), K. Solvik (DDS) 08.09.2017 1.2 Contributions to Chapter 3 G. Calleja-Rodriguez (CEM) 08.09.2017 1.3 Contributions to Part 2 B. Protopsaltis (SOF), P. Katranuschkov (CIB) 11.09.2017 1.4 Full text/gap check and editing P. Katranuschkov, R. Schülbe (CIB) 14.09.2017 1.5 Full final draft P. Katranuschkov, R. Scherer, R. Schülbe (CIB) 15.09.2017 2.0 Approved by Coordinator CIB 18.09.2017 and uploaded to ECAS

Copyright This report is © eeEmbedded Consortium 2017. 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 Katranuschkov P. & Scherer R. J. (eds.), (2017): eeEmbedded Deliverable D10.400 - Final Project Report; © eeEmbedded Consortium, TU Dresden, Dresden, Germany.

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

D10.400 Final Project Report Version 1.0 Page 3/80

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.

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)

D10.400 Final Project Report Version 1.0 Page 4/80

TABLE OF CONTENTS

Executive Summary ______5 1. The project on a page ______6 2. Vision, Mission and Goals of the Project ______7 3. Top 10 Project Achievements ______9 4. The eeEmbedded Holistic Design Methodology ______10 5. Pilot Demonstrators and Usage Scenarios ______15 6. The eeEmbedded Virtual Lab Platform ______20 6.1. Software Architecture ______20 6.2. Structure of the eeEmbedded Virtual Lab ______21 6.3. The eeEmbedded Multimodel Framework ______22 7. eeEmbedded Products and Findings ______24 7.1. Project Setup and Requirements Management Service ______24 7.2. Design Tools ______27 7.2.1. Architectural Design ______27 7.2.2. HVAC Design ______30 7.2.3. BACS Design ______31 7.2.4. Energy System Modelling (ESIM) ______32 7.3. Scenario Manager ______33 7.4. Multimodel Navigator ______35 7.5. Collaboration and Resource Management Services and Tools______38 7.5.1. BIM—It ______38 7.5.2. EDM Model Server ______39 7.5.3. Cloud Services ______41 7.6. Model Validation Services ______43 7.6.1. Ontology-based Exchange Requirement Checking and Visualisation ______43 7.6.2. Ontology-based Key Point Checking and Visualisation ______45 7.7. Energy Simulation and Analysis Services and Tools ______47 7.7.1. Input Preparation ______47 7.7.2. Thermal Simulations with TRNSYS______50 7.7.3. 3D Wind Analysis in Urban Design ______52 7.7.4. 3D Therm Analysis in Detailed Design ______54 7.8. LCA and LCC Analysis ______56 7.9. Risk Assessment Service ______58 7.10. Multi Key Point Analysis Tool for Decision Making ______61 8. Evaluation of the eeEmbedded Platform ______65 9. Exploitation of the eeEmbedded Platform ______71 10. Conclusions ______73 Appendix ______74 References ______74 Acronyms ______77 Partner Abbreviations ______80

D10.400 Final Project Report Version 1.0 Page 5/80

Executive Summary

This deliverable report describes the overall final findings and achievements of the eeEmbedded project. Publicly accessible via the project’s web site as well as via the EC web services, it gives an overview of the project, presents the initial vision, mission and goals at the project start and explains the developed new key point (KP) based holistic design methodology and the real pilot buildings used to validate, evaluate and demonstrate the project developments and findings. It lists in concise form the main project achievements and then goes into a more detailed presentation of the developed overall Virtual Energy Lab Platform and its underlying Multimodel Framework and the component services and tools integrated in the platform for the purpose of efficient energy-aware building design.

The report contains also a second part which is subject to confidentiality. It comprises a single Chapter “Potential Impact”, structured in accordance with the predefined FP7 rules and providing an overview of the project’s impact in terms of dissemination measures and activities, exploitable foreground and societal implications.

All partners have contributed to the report under the lead of TUD-CIB as follows:

TUD-CIB: Report structuring and overall editing, main input to Chapters 1-5 and 10 as well as contributions to Chapter 7 and Part 2 BAM: Main input to Chapters 6 and 8 and contributions to Chapter 3 CEM: Contributions to Chapters 3, 4, 7 and 8 and Part 2 SOF: Contributions to Chapters 7, 9 and Part 2 STA: Main input to Chapters 6 and 8 EAS, TUD-IET, NEM, DDS, RIB, EPM, GRA, IABI, SAR and OPB: Contributions to Chapter 7.

The partner abbreviations are shown in the Appendix to this report.

D10.400 Final Project Report Version 1.0 Page 6/80

1. The project on a page eeEmbedded is an European FP7 industry-driven project established under call EeB.NMP.2013-5 “Optimised design methodologies for energy-efficient buildings integrated in the neighbourhood energy systems”. . Project Budget: 11.388 M€ . Duration: 4 years [01.10.2013 – 30.09.2017] . Main product: Collaborative design and simulation platform and related design methodology

EC Contribution: 7.649 M€

Project Website: eeEmbedded.eu

Project Career: linkedin.com/company/eeEmbedded

Project YouTube Channel: youtube.com/channel/UCkgcav2Q9Zbh PzAY2a2sYwA

The eeEmbedded consortium features a mix of 15 partners from 9 European countries, covering the whole knowledge transfer chain and all key areas of research and development relevant to the project goals. They represent 4 types of market segments: . End-users including construction, architectural and engineering companies as well as control systems and equipment provider (Koninklijke BAM Groep NV, Netherlands; STRABAG AG, Austria; Centro de Estudios Materiales y Control de Obras S.A., Spain; Obermeyer Planen + Beraten GmbH, Germany; Fr. Sauter AG, Switzerland). . Software developers (Nemetschek ALLPLAN Slovensko SRO, Slovakia; Data Design System ASA, Norway; Jotne EPM Technology AS, Norway; Granlund Oy, Finland; SOFiSTiK Hellas, Greece; Fr. Sauter AG, Switzerland). . Research institutes with knowledge on BIM/IFC management and interoperability (Institute For Applied Building Informatics, Germany) and control system modelling, numerical analysis and user activity modelling (Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., Germany). . Academic organization (TU Dresden, Germany, with the institutes Construction Informatics and Power Engineering), specialized in BIM, SOA, ontologies, interoperability, cloud computing and related orchestration management and in energy system modelling and numerical simulation of any related system. Coordinator of the project is the Institute of Construction Informatics of the TU Dresden.

D10.400 Final Project Report Version 1.0 Page 7/80

2. Vision, Mission and Goals of the Project

Already at the outset, when the proposal was prepared, clear vision, mission and goals of the eeEmbedded project had been identified.

. VISION

The vision of eeEmbedded was to increase, by an order of magnitude, the quality of energy-efficiency in building design through the development of an In-Silico Energy Simulator Laboratory.

The project consortium set out to develop an open BIM-based holistic collaborative design and simulation platform, a related holistic design methodology, an energy system information model and an integrated information management framework for designing energy-efficient buildings and their optimal energetic embedding in the neighbourhood of surrounding buildings and energy systems. In this environment, a new design control and monitoring system based on hierarchical Key Performance Indicators (KPI) will support the complex design collaboration process. Knowledge-based detailing templates will allow energy simulations as soon as in the urban design phase, and BIM-enabled interoperability will provide for a seamless holistic design process with distributed experts, and a seamless integration of simulations in the virtual design office (energy performance, CO2, CFD, control system, energy system, climate change, user behaviour, construction, facility operation), thus extending it to a real virtual design lab.

. MISSION

The mission of eeEmbedded was to develop ICT products and services that will provide for an efficient, functional and easily configurable Virtual Energy Lab Platform based on an ontology-supported interoperable BIM implementing established information management standards. The main products eeEmbedded (eeE) develops are: . A holistic design methodology based on a hierarchically structured dynamically evolving KPI system which guides and monitors the progress of the multi-disciplinary, multi-model and multi-physics design process. . A collaborative, holistic design platform comprising a virtual energy design lab and a virtual multidisciplinary collaborative design office for the design and evaluation of new or retrofit buildings embedded in their energetic environment and covering their energetic performance, their constructa- bility and their energetic vulnerability on different levels of detail. . A new reference model schema for the Energy System Information Model (ESIM) structured according to BIM-IFC (ISO 16739) and incorporating the topography structure of the energetic environment in accordance with cityGML. This will complement BIM concerning the internal and external energy systems, built on and subsuming the various proprietary data structures existing for energy systems. . An ontology-based open interoperability system as the baseline for managing the information and cross- dependencies of the multi information models, BIM, ESIM and BACS, and the related multi-physics problems and their computational analyses.

D10.400 Final Project Report Version 1.0 Page 8/80

. A multi-model information management method and related management services enabling the integration of the separately maintained domain models, combining them to multi-models wherever needed, filtering out the right views with minimal amount of information, mapping the eeeBIM data to the appropriate computational models and taking care of the interactions and feedback cycles for the multi-physical interdependencies of the computational models with prototype implementation of the building thermal energy system, the neighbourhood energy systems, natural ventilation and building- wind interactions (cool out and wind tunnel effects). . A knowledge management system for fast and grounded design decision-making with characteristic design detailing templates enabling quantitative analyses and simulations as soon as in the early design phases.

. GOALS

The main objective of the project was to develop ICT building blocks based on standardised Building Information Models that will integrate, complement and empower existing tools for design and operation management to the envisaged Virtual Energy Lab.

Specifically, the project work was focused on the following 7 research and development objectives: . Interoperability of the design objectives as baseline for collaborative holistic design using a new KPI- based design methodology; the new developed Key Points (KPs) shall act as guidelines for milestones and control of the collaborative design process, providing the interoperability and monitoring the progress of the design during its different phases. . Interoperability of the information for heterogeneous distributed information resources and services on the basis of system and domain ontology schemas and tools . A knowledge structure over the information domain models providing the mapping information needed to transform the domain information models to computational engineering models, as well as the knowledge needed to decide on the necessary level of detail and the respective cross-model structure. . Holistic collaborative virtual design office based on collaborative and virtual enterprise methods to manage people, tools and information, including a change management component to properly handle the various changes arising during design and enabling to find, retrieve and compare multiple different design alternatives with the help of an advanced BIM-based visualization system. . Holistic virtual design lab providing quantitative computational support based on efficient cloud computing methods; the tools and services integrated in the virtual design lab will provide the computer power for the various required engineering analysis and simulation tasks and will support the feedback cycles for the interrelationships between the computational models, based on the interoperability of system information. . Stochastic approach as part of the overall virtual design lab approach, extending current deterministic models and approaches to cope with the uncertainties in the lifecycle concerning climate, energy provision, as well as the usage of the building and the human behaviour. . Knowledge-supported design methods enabling fast preliminary detailing in the early design phase. This is a mandatory issue to be able to carry out computational analysis and simulations and to obtain conclusive quantitative results about the energetic performance of the building and about the vulnerability of the energy systems already at the early design stages, when fundamental energetic design decisions have to be made that are hardly alterable later on.

D10.400 Final Project Report Version 1.0 Page 9/80

3. Top 10 Project Achievements

We consider the following results as Top 10 achievements of the eeEmbedded project:

. Key Point based design method supporting the control of the collaborative design work and the monitoring of the progress against the design objectives. . Open ICT platform incorporating the Scenario Manager for process management, the Multi-Model Navigator for checking the models and assigning templates, and an extensible number of simulation and analysis services and a KP analysis tool for decision making grouped in interlinked configurable Virtual Energy Labs for each role and domain in the design process. . Structured Key Point setup enabling definition of performance objectives and requirements in holistic and automated manner for verification and validation of the design objectives continuously, at all key points throughout the design process. . Scenario Manager (ScM): This brand new prototype application supports the collaborative project process by dynamically assigning and monitoring project tasks and attaching the required data and actions to them. In this way, project work can proceed in coordinated manner with clearly allocated responsibilities, work items and interdependencies for each member of the project team. . Project collaboration via consistent use of the BIM Collaboration Format (BCF): The integration of the BCF platform in the ScM ensures effective communication in the project team. The successor in the process is informed about the finalisation of the previous task and receives links to all the data necessary for his/her task. . Easy creation and evaluation of variants: The eeEmbedded platform incorporates generic climate, occupancy, construction, HVAC, BACS and maintenance templates which can be assigned to element types, to analyse the impact of various parameters on the sustainable performance of a building. . Multi-Model approach: For most of the simulation tools a Multi-Model Container (MMC) was implemented, which means that only one IFC file is needed per alternative, whereas various external information sources and various variants are linked to elements in the IFC file using a variation matrix. E.g. for 50 design variants there is no need to create 50 IFC models but only one model with 50 different variants linked to it. . Exchange Requirements (ER) checking: The Exchange Requirements which are crucial for collaboration in the project team can be checked via the Ontology Verification Service (OVS) and missing information highlighted in red in the BIM model. The service is directly integrated in the Scenario Manager, where ER are linked to the specific tasks in the process. . BIM-based Interoperability APIs: In the eeEmbedded platform simulations and analyses run as services. This means that the results of various variants are processed without interaction with the end user. Manual work is significantly reduced via the developed APIs. The coupling of data and tools becomes feasible and the pre-processing time for model preparation is brought to minimum, thereby enabling affordable variant examination. . Just-in-time result evaluation and decision-making: The developed new decision-making tool analyses the impact of Key Design Parameter (KDP) on sustainable Key Performance Indicators (KPI) such as energy, emissions, thermal comfort and Life Cycle Costs (LCC). In addition, the impact of risks can be analysed. The results are weighted based on the preferences and visualized in a decision value graph, which makes the comparison of alternatives and variants very efficient and transparent.

D10.400 Final Project Report Version 1.0 Page 10/80

4. The eeEmbedded Holistic Design Methodology eeEmbedded has developed a new ICT based intelligent methodology to design energy efficient buildings integrated in their neighbourhood. It extends existing BIM developments with a multi-model approach for modelling and analysing the building architecture and its systems (HVAC, BACS) considering facility management strategies and integrating sophisticated simulations to optimise energy, costs and environmental impact along the life-cycle of the building. The design methodology was specified by the end-users of eeEmbedded at the beginning of the project within the Deliverables D1.2 (Geissler et al., 2014), D2.1 (Guruz et al., 2015a, b). These specifications were used by eeEmbedded developers as basis to implement the supported tools and services integrated in the platform. After the implementation of the supported tools and services, the end-users have used them for the design of two pilot buildings (Sprenger & Poloczek, 2017a, b). Finally, the developed methodology for holistic energy efficient building design has been updated taking into account the implemented tools and services and the experience from the performed pilot projects where the implemented tools and services and the design methodology were used.

The eeEmbedded Methodology features a clear BIM-based approach. It uses Key Points to drive the design, and Templates to facilitate and accelerate the process. The Key Points are measurable target values that represent requirements coming from clients, regulations, site and designers. They are used as basis for taking informed decisions on design solutions. The Templates contain valuable information to speed-up and streamline the design process while sophisticated analysis methods are applied to a large number of design variants and alternatives making use of cloud technology. The major aspects of the developed methodology that distinguish it from state-of-the-art design work are as follows:

. Investing time on project setup A comprehensive project setup is required to ensure integrated process, information flow and software in BIM-based collaborative design and to avoid problems due to differences in working cultures, work processes and software applications. The more detailed the project setup is, the more straight forward the design process will be later on and the more problems can be avoided in advance. The project setup must precisely define: . Project Type in terms of building type, project address, contract type, budget and duration apart from the project name and its description. . Project structure, i.e. the teams that will be involved and their roles. . Project infrastructure including the software that will be used and the required format of inputs and outputs (IFC4, CSV, etc.). . Project requirements coming from sites, regulations and building owners; they must be described, classified and aligned per domain and cross-domain as well as prioritized. . Key Points. The requirements must be translated into four types of measurable target values, also known as Key Points: (1) Decision Values, (2) Key Performance Indicators, (3) Key Risk Indicators and (4) Key Design Parameters. After detailing the Key Points, they must be linked to specific instants or milestones of the design process (check points).

D10.400 Final Project Report Version 1.0 Page 11/80

. Process setup, i.e. the definition and interrelationship of the major design tasks and their sequences as well as the responsible actors. . Exchange Requirements, i.e. the information to be exchanged between the actors (inputs and outputs of tasks). The added value for AEC companies is the structured monitoring of all essential project requirements, which requirements are verified and by whom. In this way it is possible to know whether the project is progressing within the sustainable requirements and the budget which is an enormous support for quality control in complex projects. The added value for the client is that s/he has continuous and transparent proof that all the requirements are met in the project.

. Using Key Points in structured ICT supported manner The eeEmbedded methodology defines a comprehensive framework including rating scale and rules with the end targets in mind. The basis is translating requirements and design criteria into Key Points which provide verifiable design check points in form of target values. Key Points have two main missions. On the one hand, they integrate all design criteria and requirements. On the other hand, they guarantee easy and fast evaluation and comparison of design options based on relevant well-defined metrics.

Figure 1: Top down decomposition of requirements into Key Points and bottom up verification of Key Points

This means that already in the project brief of a project we need to develop the requirements and the major design criteria top down according to the following steps: . Choose a Decision Value (DV) and set a target; e.g. sustainable score 85 or Internal Rate of Return of 5 %. The Decision Value represents the preferences of the decision makers related to the project goals. It allows prioritizing Key Performance Indicators by means of weighting factors (e.g., Passive House). . Define Key Performance Indicators (KPI) influencing the DV in order to be able to comprehensively validate if the building is defined according to the clients’ needs. Prioritize those by weighting factors and set targets based on a requirements analysis. Key Performance Indicators (KPIs) are numeric metrics of building performance related to energy usage. They are influenced by Key Design Parameters and are additionally the basis values for evaluation via Decision Values (e.g. cooling demand ≤ 15 kWh/m2a).

D10.400 Final Project Report Version 1.0 Page 12/80

. Define Key Risk Indicators (KRI) and set target values that represent deviation of the building performance due to the stochastic nature of various parameters such as risks related to energy use or to the reliability of the energy system. . Define Key Design Parameters (KDP), and set targets based on a requirements analysis. Some Key Design Parameters are already defined and act as constraints in the design process, whilst other parameters can be adapted to optimise sustainable targets. Key Design Parameters (KDP) represent the required building 2 properties and usually have a limited value range (e.g. Uwall ≤0,15 W/m K).

Figure 2: Overall procedure for the use of Key Points

. Structured arrangement of processes, tasks, roles and information exchanges

Implementing the Building Information Modelling approach requires a clear arrangement of processes, tasks, roles and information exchanges. The following questions must thereby be answered. . Who needs the information extracted from the building information model? . At which point in time this information is needed? . Which minimal amount of data has to be exchanged? eeEmbedded recommends to digitally capture the information exchanges according to the IDM approach (ISO 29481) and to steer and track them during the project. To carry out this recommendation, exchange requirements are defined for the various BIM uses/phases and configured for the specific project at hand in its digital environment. The developed Scenario Manager (ScM) provides the functionality to setup and run the exchange requirements verification with the help of the integrated Ontology Verification Service (OVS) and/or the externally used IfcDoc tool from buildingSMART.

. Using Design Templates Speeding up and streamlining the design process while integrating sophisticated analysis methods applied to a higher number of design variants and alternatives within a shorter time works only when smart re-usable templates are integrated into the design process. These templates are dividable into two types, (1) design content templates and (2) process templates. Main target of the template usage is the higher level of formalisation and the reproducible quality of design and analysis results across projects and domains, the higher productivity of the involved design team, and the highly improved capability to define and examine different design variants.

D10.400 Final Project Report Version 1.0 Page 13/80

Integration of both template types into design process starts with the setup of the project while using process templates covering the step-by-step workflow including the targeted output quality and covering the related exchange requirements between the process steps. The project setup should also cover the agreement between the involved project partners about content templates. Typical examples for content templates are pre-defined construction templates for building elements (walls, slabs, windows) and equipment (HVAC, sensors and other building automation devices), and/or occupancy profiles as inputs for both, the design and the analysis steps.

Figure 3: Content templates

. Planning an urban design phase focused on energy Urban design is crucial to take advantage of energy saving potential by using passive heating, photovoltaic potential or natural ventilation. For example, it is widely known that the level of solar exposure which is strongly linked to orientation and surrounding shadows influences heating, cooling and artificial lighting needs of buildings. In this line, it is important to create a trend to incorporate urban design and planning concepts into the building design process in order to integrate them energy efficiently in their neighbourhood. That is why we recommend having a first design phase focus on the urban design that takes into account energy considerations. On the other hand, it is also crucial to include simulations and precise calculations as much as possible into this first phase to increase the reliability of the decisions taken in the early stage of the design, which are considered as the most influential decisions on the building performance (McArthur et al. 2014). The urban design phase should thereby be focused on the development and evaluation of several building cubature and energy supply concepts taking in consideration the integration into the neighbourhood and the use of renewable or conventional resource on site and on district level. To this end it should include: . CFD simulations related to the climatic conditions (wind) to optimise thermal comfort and analyse the integration of the building into the neighbourhood. . Energy building simulation to rank cubature variants in order to find the optimal energy demand . Taking into account uncertainties when ranking combinations of cubature and energy supply variants that optimise energy consumption and use renewable or conventional resources on site and district level. . Life Cycle Cost analyses to also compare building cubature variants in combination with energy system variants and the life cycle costs.

D10.400 Final Project Report Version 1.0 Page 14/80

. Involving FM experts in the early phases of design

Traditionally, facilities management and property management (FM/PM) has been regarded with a poor relation to the architecture, engineering and construction (AEC) industry. The eeEmbedded methodology acknowledges that the role of FM is much wider than being involved only in the operational phase. Therefore, FM/PM professionals’ involvement in the early phases of design and knowledge sharing strengthens the integrated design process developed in the eeEmbedded project. The involvement of FM professionals is perceived of high value for the entire facility lifecycle. Benefits are seen in ensuring less rework, emphasizing value for money by taking into consideration life cycle aspects such as LCC, LCA, investment costs, maintenance cost, flexibility, adaptability and environmental policies. To date the use of BIM is not common for FM/PM professionals. However BIM tools are capable of simulating and predicting different performance parameters that are very useful for the decision making process at a strategic and operational level. FM/PM professionals do not need to necessarily know how to perform the simulations but should be able to interpret and evaluate the results in form of key performance indicators (KPIs) for making informed decisions in the long term. Potential KPIs generated for FM are related to cost of maintenance and operation, revenue, space management, and environmental and safety issues. These KPIs are integrated in the decision making methodology and supportive decision making tools used during the design phases.

The methodology was elaborated for 3 design phases:

The urban design phase is focused on the development and evaluation of several building cubature and energy supply concepts taking in consideration the integration into the neighbourhood and the use of renewable or conventional resources on site and on district level. It comprises 7 tasks: project setup, design cubature, CFD wind simulation, energy concept, lifecycle costing, energy simulations and overall decision making. The early design phase is focused on the modelling and analysis of combinations of construction types - for rooms and building elements - and concepts for the HVAC system, the Building Automaton and Control Systems (BACS) and Facility Management to optimise energy, environmental impact and costs along the life cycle of the building. It encompasses 9 tasks: update project setup, develop construction types, develop HVAC types, develop BACS types, FM concept, energy simulation, Lifecycle assessment analysis, LCC calculation and overall decision making. The detailed design phase is focused on the accurate development and analysis of room layout, combined with the detailed design in terms of location and product features of HVAC systems, BACS systems and FM strategies to optimise energy, environmental impact and costs along the life cycle of the building. It encompasses 10 tasks: update project setup, create architecture product alternatives, create HVAC product and location alternatives, design sensor and actuators network, enrich product alternatives with FM information, energy simulation, CFD simulation, LCC calculation, LCA calculation and overall decision making.

A comprehensive description of the various aspects of the methodology and the developed design scenarios is presented in Deliverable D2.5 “New ways of holistic working for energy optimized and embedded building” (Calleja-Rodriguez et al. 2017).

D10.400 Final Project Report Version 1.0 Page 15/80

5. Pilot Demonstrators and Usage Scenarios

Two different pilot models of real buildings – W2 Leidsche Rijn (Figure 4) and Z3 (Figure 5) have been used to verify and validate the platform and the KP methodology. Both pilots are office buildings, but with different surroundings, architectural alignment with respect to other buildings and different working space inside as well as different energy demand. The prepared initial CAD models were exported in the standard Industry Foundation Classes (IFC) format and reflected as much as possible the necessary exchange requirements specified in the Project Setup. The surroundings were modelled for the purpose of wind analysis using computational fluid dynamics (CFD) and thermodynamic energy simulations.

Figure 4: eeEmbedded Pilot Demonstrator: W2 Building, Leidsche Rijn, BAM, Netherlands

Figure 5: eeEmbedded Pilot Demonstrator: Z3 Building, Züblin, Stuttgart, Germany)

D10.400 Final Project Report Version 1.0 Page 16/80

In accordance with the developed design methodology the two models were used to test and evaluate the eeEmbedded virtual lab platform for the three targeted design phases: Urban Design, Early Design and Detailed Design. Most comprehensive tests have thereby been performed for the Urban Design phase in order to verify the holistic design goal of combining architectural and energy system (neighbourhood) design and the use of energy and life cycle analyses and simulations as early as possible in order to facilitate optimal decision making.

. Urban Design

In the Urban Design phase, the models are prepared as simple shapes. They consist of simplified spaces as office, garage, staircase and slabs indicating the floors. The envelope is defined with external walls and a roof. The end users proposed also three geometrical alternatives for each model. These differ with regard to shape, orientation and/or size. Each of the alternatives was simulated with different variants of architecture and energy systems. The specified variants are shown in Figure 6 below. They ensure that the evaluation is done based on diverse configurations to have rich and diverse visual outcome demonstrating the flexibility, the efficiency and the added value of the eeEmbedded methodology and the implemented ICT platform. The result of the Urban Design phase reveals the best alternative to be further detailed and used for Early Design.

Alternatives-IFCs A1 (H Shape) WWR (NE & SW side) Heating System 40% District heating 60% Heat pump

U-Value Wall Heavy - Brick: 0,19 W/m2.K Leightweight - Steel: 0,15 W/m2.K

U-Value Window 2-pane: 1,10 W/m2.K 3-pane: 0,66 W/m2.K

A2 (U Shape) WWR (NE & SW side) Heating System 40% District heating 60% Heat pump

U-Value Wall Heavy - Brick: 0,19 W/m2.K Leightweight - Steel: 0,15 W/m2.K

Shell 2-pane: 1,10 W/m2.K 3-pane: 0,66 W/m2.K

A3 (Rectangular) WWR (NE & SW side) Heating System 40% District heating 60% Heat pump

U-Value Wall Heavy - Brick: 0,19 W/m2.K Leightweight - Steel: 0,15 W/m2.K

Shell 2-pane: 1,10 W/m2.K 3-pane: 0,66 W/m2.K

Figure 6: Urban design variants (Left: W2 Building Leidsche Rijn, Right: Z3 Building, Züblin, Stuttgart)

The design scenario for Urban Design is presented in Figure 7. During the first step of this scenario, setup for the particular project within the Scenario Manager (ScM) of the eeEmbedded platform is prepared. The project manager introduces information about the project, sets up the project process maps and assigns project partners to the particular tasks. Decision Values (DV), Key Performance Indicators (KPI) and Key

D10.400 Final Project Report Version 1.0 Page 17/80

Design Parameters (KDPs) are defined within the ScM. Architectural BIM models with alternatives are created and uploaded as IFC files to the ScM. An Ontology Verification Service (OVS) is used to verify the exchange requirements for the models and detect deviations. In addition, KDPs are checked visually in the Multimodel Navigator (MMNav) accessible to all design team members via the Internet. End users assign building occupancy and climate templates in MMNav and create variants by using construction and energy system templates. Such templates can be assigned automatically using OmniClass classification or manually to each building element. The next step is the CFD wind simulation, where wind flows are analysed and alternatives which do not meet the set KPIs are either discarded or a message is sent to the designer to optimise. Simulations are optionally done on stochastic scenarios in order to check design variable ranges and uncertainties. The results from this process are sent further to the energy expert using the platform’s services and the building collaboration format BCF (see Chapter 6 below).

Figure 7: Urban Design Scenario

Thermal simulation is performed using the same templates and variants as the CFD simulation. Energy systems are analysed in TRNSYS for each alternative, including uncertainty analysis. The results are transferred as BCF message with attached Multimodel Container (MMC) to the merging tool developed as add-on of the EDM model server where all the information from templates and simulations is incorporated into one BIM-IFC file. This file is transferred to the cost expert for the purpose of LCC calculation. In iTWO/LCC cost templates are respectively selected and results are automatically generated from the data in the IFC model. Finally, KPIs are checked and the information is forwarded for decision making. Granlund’s Key Point Analysis (KPA) tool compiles all the results and presents them in a graphical way which provides the designers with a clear overview of the best combination of a model alternative and a system or construction variants that are the most suitable to use for energy-efficient design of an embedded building.

D10.400 Final Project Report Version 1.0 Page 18/80

. Early Design

In the Early Design phase, the Level of Detail (LoD) of the selected best Urban Design alternative is increased. Detailing of rooms and windows, exterior and interior doors is done and the space use and names of the rooms as well as occupancy profiles are input. Materials of walls and floor construction are specified and more detailed variants for exterior wall insulation, construction, glazing, HVAC and BACS were defined with the aim to examine and evaluate the differences in energy performance, Life Cycle Costing (LCC) and Life Cycle Assessment (LCA).

Selected Alternative Selected Alternative

Alternatives-IFC Architecture HVAC BACS A3 Exterior Walls_Insulation Material Heating & Cooling System Classification Concrete block: 20 cm, Ceiling Induction A- High energy performance building automation Mineral wool: 26 cm - 0,15 W/m2.K and control system (BACS) and technical building

management (TBM)

External External

Finish

20 20 cm 26 26 cm

Concrete block 20 cm, Vacuum Concrete Core Activation B- Advanced BACS and TBM

panels + EPS: 8 cm - 0,15 W/m2.K

20 20 cm

8 8 cm

External External Finish

Exterior Walls_Cladding Ventilation System External cladding material: Stone Ceiling Induction Unit

(Granite)

6 cm Air gap Air 6 cm

20 20 cm

8 8 cm 4 cm 4 Granite cm

External cladding material: Metal Floor diffusors

cm Metal cm

20 20 cm

8 8 cm

6 cm Air gap Air 6 cm 0,50

Figure 8: Early design variants (Left: W2 Building Leidsche Rijn, Right: Z3 Building, Züblin, Stuttgart)

The design scenario is basically the same as for Urban Design (see Figure 9). However, after the thermal simulation with TRNSYS, the HVAC concept is elaborated with successive ER and KP checks. Consequently, in the MMNav, HVAC maintenance variants are set up and the eeBACS wizard is used to define the building

D10.400 Final Project Report Version 1.0 Page 19/80 automation and control systems. After that, energy simulations are performed, the results are merged by the EDM server and LCC and LCA calculations are undertaken. Ultimately, all results are compiled and evaluated with the help of Granlund’s KPA tool.

Figure 9: Early Design scenario

. Detailed Design

Detailed Design follows the same steps as Urban and Early Design. It includes additionally thermal comfort conditions estimation based on CFD simulation which follows the energy simulations. Comfort simulation is done by using the 3DThermCFD tool developed in the project. The detailed geometry data is imported from the enhanced BIM-IFC model. Operation points of the HVAC system and airflow conditions are specified taking into account the desired usage scenarios, e.g. hot day during summer or the coldest day in winter. Among others thermal and cooling loads are included from the templates. Energy simulation provides the wall temperatures and solar gains from glazing surfaces. Also, BACS aspects are included. Detailed results from the CFD simulation are presented via videos and 3D representations of suitable flow quantities are shown as stream lines. These can be further attached to the IFC model in the MMNav.

The next Chapter 6 gives an overview of the overall eeEmbedded Virtual Lab Platform and its underlying Multimodel Framework. Chapter 7 describes the integrated new or extended ICT services and tools and the related major project findings enabling the use of the developed methodology in the industry context.

D10.400 Final Project Report Version 1.0 Page 20/80

6. The eeEmbedded Virtual Lab Platform

The eeEmbedded ICT platform comprises many end-user applications and service components which support the design methodology in different ways. The combination of design tools, analysis tools, data tools and result evaluation tools together with data servers led to the concept of an eeE Virtual Laboratory that can be configured for the different goals and technical domains of the different members of the design team. Combining such laboratories in a flexible environment encompassing data and compute cloud servers linked together via a common service bus enables performing holistic energy studies about the designed buildings in different design phases, starting already from the urban and early design stage.

6.1. Software Architecture

Some tools and components of each Virtual Lab are local software applications which import and export data files like CAD or FM design. Some others are web components which provide REST-APIs. Therefore, the software architecture is arranged as a service-oriented architecture (SOA) as shown in Figure 10. It is divided in multiple layers: . User Layer: The eeEmbedded platform supports users from different domains. Each user has a specific view on her/his data. The data are created and prepared for further usage in such views. Therefore, on this layer role/domain specific tools are configured individually.

. Virtual Lab Layer: The Virtual Lab Layer is responsible for providing the data connection among the platform’s users, services and tools. This layer provides also interfaces to additional external tools which are currently not compliant with tools from the user layer. Advanced BIM Tools like the Scenario Manager (see Section 7.3) are aligned here to enable BIM workflows, data imports, file management and building analyses.

. Communication Layer: The communication layer provides the overall collaboration infrastructure. All information and data files are shared within a Multimodel Container with the BIM—it collaboration server via the Internet using the BCF approach (see Section 7.5.1).

. Shared Service Layer: This layer manages the BIM workflows with its messages, events and tasks. Workflow definitions created in the Scenario Manager are analysed by a workflow engine. This engine informs the users when they have to do their work and what they have to do.

. Service Component Layer: All external applications that help to handle data are aligned in that layer. They can be called within the Scenario Manager workflows. Furthermore, the clients to web data repositories and simulations are provided.

. Repository Layer: The repository layer includes all data servers like BIM servers and template repositories. While storage clouds are used to upload and download files to BIM servers, all simulations run in compute clouds (Section 7.5.3) in order to allow analysing and evaluating hundreds of design variants in parallel for the time of a little more than a single one.

The advantage of this layered SOA approach for the eeE Virtual Lab is the possibility to exchange components in each layer without affecting components of other layers. Therefore, it is possible to use e.g.

D10.400 Final Project Report Version 1.0 Page 21/80 other BIM servers than the EDM model server (Section 7.5.2), other simulation tools than TRNSYS (Section 7.7.2) or another BIM management server than BIM—it (Section 7.5.1). This guarantees a fully flexible system without relying on some special tools.

Figure 10: The eeE software architecture

6.2. Structure of the eeEmbedded Virtual Lab

As shown in Figure 10 the Virtual Lab Layer of the eeEmbedded platform comprises multiple virtual labs which can be configured specifically for the needs of the separate domains and roles in the holistic design process. In the scope of eeEmbedded the following views and virtual lab configurations have been implemented: . Project Manager / Decision Maker . Architect . HVAC Designer . BACS Designer . Energy System Expert . CFD Simulation Expert . LCC Expert

D10.400 Final Project Report Version 1.0 Page 22/80

Further roles can be added using the developed architecture and methodology. Therefore, as a whole a Virtual Design Office is established. One of its important features is that, while differently configured, all virtual lab instances follow the same principal structure which enables their seamless integration into a coherent overall platform. This unified structure comprises three layers: . User Layer, featuring general purpose or domain-specific authoring CAD tools, any other local domain tools that require user interaction and the mandatory Scenario Manager (ScM) and Multimodel Navigator (MMNav) . Analysis Layer, which bundles the interfaces to simulation and analysis services allocated on the compute cloud of the platform . Core Layer, encompassing the needed collaboration, model validation and model management services which are the same for all Virtual Lab instances and provide the functionality for their proper functioning and interoperability within a consistent overall system. This layer includes also the APIs enabling the interaction with the Service Bus and the underlying shared service layer of the platform (see Figure 10). The next Chapter 7 describes the individual services and tools in the current realisation of the eeEmbedded platform. With the exception of Section 7.5, which focuses on the infrastructure services “below” the service bus, it presents the major exploitable components of the implemented Virtual Labs comprising the eeEmbedded Virtual Design Office. The following Table 1 provides and overview.

Table 1: Implemented Virtual Lab tools and services by role and domain

Task / Tool / Service Virtual Lab Configurations Project/BIM Architect HVAC BACS Energy CFD Simul. LCC Manager Designer Designer Expert Expert Expert Project Setup Service + (+) (+) (+) (+) (+) (+) Arch. Design (Revit, Allplan … ) + HVAC Design (DDS-CAD … ) + BACS Design (eeBACS Wizard … ) + BIM Checking (FZK, EDM, Solibri Viewers … ) + + + + + ESIM Design Tools + Scenario Manager (ScM) + + + + + + + Multimodel Navigator (MMNav) + + + + + + + ER / KDP Checking Services + + (+) (+) + + + Thermal Simulation (TRNSYS) + CFD Wind Simulation (3D Wind) + CFD Thermal Simulation (3D Therm) + LCA / LCC Analysis (iTWO LCA/LCC Plugin) + Decision Making (Multi KPA Tool) + (+) (+) (+) (+) (+) (+)

6.3. The eeEmbedded Multimodel Framework

The outlined eeE Virtual Lab platform provides a flexible data concept, which allows sharing any needed information in any data format using a concept called Multimodel Container (see Figure 11). Such a container defines a structure that links different kinds of domain models via connections specified in Link Models. Domain models are treated as independent information resources with their potentially own application domain, data schema and data formalization. In this way Multimodels can be applied on any domain.

D10.400 Final Project Report Version 1.0 Page 23/80

There are several ways to realize the Multimodel Container (MMC). It can be implemented as compressed archive file which contains all models or as a Multimodel that contains only the links to the actual resources. In principal, Multimodel containers contain domain models from different domains and each model can be independently processed by the project partners and their respective domain tools. Each partner can thereby create or develop her/his own domain models and link them with existing models. This enables the design partners to recombine the Multimodels based on their demands and the requirements of the project. In eeEmbedded we have chosen this concept because of the many different proprietary data models the involved tools need. The advantage is that not all necessary data is added to a single data model. This prohibits redundant information in the overall workflow, reduces model complexity and minimizes the shared and stored data. Hence, the eeE concept is not to save all information in one huge overarching model, more precisely the building information model expressed via IFC. Figure 11: Multimodel container concept

We keep each file format as it is and interlink them with each other. Every user of such a Multimodel container selects the domain models which are needed for her/his work. The tool which consumes the Multimodel has to parse the link models to retrieve the expressed information space. Basically, in the context of eeEmbedded a MMC provides the following structure with directories and files: Multimodel [directory] - root directory o bpmn [directory] - directory for BPMN workflows . MetaProcess.bpmn - BPMN workflow for the eeEmbedded meta process . UrbanDesign.bpmn - BPMN workflow for the urban design phase . EarlyDesign.bpmn - BPMN workflow for the early design phase . DetailedDesign.bpmn - BPMN workflow for the detailed design phase o keypoints [directory] - directory including the key point setup files o links [directory] - directory including the link model files o models [directory] - directory for all domain model files (BIM-IFC alternatives templates, stochastic samples, occupancy profiles, climate profiles) o Multimodel.xml - meta information of all content in the Multimodel o VariationModel.xml - information about all defined variants of a specific task. The Multimodel is packed in ZIP format and attached as BIM snippet to BCF topics as explained in section 7.5.1. It is distributed via the ScM and most information is collected through services of the service component layer (see Figure 10) from user applications like the Multimodel Navigator (MMNav), presented in Section 7.4 below. The way how to retrieve information out of a MMC is described in more detail in Section 7.3. During the eeE workflow the Multimodel information is increasing and all data files are stored on BIM servers to be able to restore previous versions of BIM information.

D10.400 Final Project Report Version 1.0 Page 24/80

7. eeEmbedded Products and Findings

7.1. Project Setup and Requirements Management Service

The definition of all requirements is performed in accordance with the developed new design methodology. It is supported by a newly developed user interface providing a front-end to the underlying ontology framework of the eeEmbedded platform. Utilising VBA, XML, RDF/OWL and JAVA technologies, this Microsoft Excel based user interface functions as editor for the generation and management of the ontology models. The choice for Excel has as main reason that it is the best known and accessible spreadsheet tool people use in general in their working environment. In that way, any project manager, BIM manager, decision maker or owner can start using the interface and can easily and rapidly get into it. Figure 12 shows schematically the main parts of the interface and the main steps to follow for accomplishing a complete project setup. The interface is composed of several spreadsheets, each related to some requirement category and representing a specific setting. These categories decompose requirements into: . Qualitative requirements i. e. building functions defined and selected using the OmniClass classification system, . Selection of generic product libraries used conco- mitantly for both building design configuration and for simulations, . Quantitative requirements expressed in terms of Key Point TO-BE values, . Design process settings for establishing phases and tasks, . Exchange requirements for specification of mandatory eeBIM data exchanges. Figure 12: Workflow for the overall project requirement setup

Type categories, which are important for later automated template assignments and data filtering, are defined in a first step. They are organized in five abstraction levels: District, Site, Construction, Space and Element.

D10.400 Final Project Report Version 1.0 Page 25/80

. The District Level describes the available internal and external energy supply for the planned building. This includes power plants as well as energy storages and the related values for energy consumption and energy generation. . On the Site Level the building site of the planned building is described. The different areas, like parking areas and areas for energy generation (e.g. area for solar panels), are detailed on this level. . The Construction Level contains the description of the different construction types like the type of the building (e.g. High School, Police Station, Hospital, etc.) and other constructions. . On the Space Level the different spaces within the building are typified. This way certain Ifc space elements can be related to a Restroom, Office Room, Corridor, etc. . The Elements Level represents the lowest level and contains various building element types. By the definition of Key Point requirements the end user can address the four KP types introduced in the methodology, i.e. decision value (DV), key performance indicators (KPI), key design parameters (KDP) and key risk indicators (KRI). Figure 13 shows the DV setup view allowing to evaluate the designed building with regard to owner’s preferences or to targeted certification schemes like LEED, BREEAM, DGNB, etc. (Guruz et al. 2015b). More details about the DV definition are available in (Forns-Samso et al., 2015).

Figure 13: Spreadsheet dedicated to the configuration of the decision value (DV)

Figure 14 below shows the configuration sheet for the next setup level where all KPIs used in the project for assessing performance criteria can be configured. These KP definitions are commonly used by certification schemes and as usual metrics in civil engineering. For the pilots a fixed list of KP definitions was used, but it is foreseen that in other practical applications such definitions would be extended and used as part of companies’ knowledge. The same layout has been used for the three KP levels i.e. KPIs, KDPs and KRIs.

Figure 14: View of the sheet used for entering and setting KPI requirements.

D10.400 Final Project Report Version 1.0 Page 26/80

The specification of Exchange Requirements represents the last step of the overall project setup and is the basis for all later quality check and model validation services (see Section 7.6). Therefore, Exchange Requirements are specified for each domain as shown on the example in Figure 15. Once the domain-specific ERs and the check rules have been defined by a BIM expert, the end users (designers) can finish the ER setup for their project. As shown in Figure 16, a user can then (1) Load Selected Tasks from the preceding “Design process setup”, (2) Select for each task a related domain-specific ER that shall be checked with regard to the future eeBIM model, and (3) Load the corresponding check rules, so that during the design workflow all rules are ready for use for the ER check which are performed on demand.

Figure 15: Exchange Requirement Table for the architectural domain

Figure 16: 3-Step Exchange Requirement Setup

D10.400 Final Project Report Version 1.0 Page 27/80

7.2. Design Tools

Design tools integrated in the eeEmbedded platform are on the user layer of the Virtual Lab. They are either off-the-shelve CAD systems like Autodesk’s Revit®, or software products of the consortium partners that have been extended or developed during the project (DDS-CAD - for HVAC Design, and eeBACS Wizard – new tool developed for BACS design). Their purpose in the eeEmbedded methodology is to provide the initial design input for analysis at the respective steps of the urban, early and detail design phases.

7.2.1. Architectural Design Architectural design is accomplished by using a CAD tool that is certified to export standard BIM-IFC files. In eeEmbedded predominantly Revit® has been used but Nemetschek’s ALLPLAN® is another possible option. The emphasis of the project in that regard has been on the specific modelling and exchange requirements that need to be fulfilled to ensure correct energy and LCC analyses. Architecture Modelling and Exchange Requirements Ensuring the quality of the model is essential for a streamlined process and the delivery of the schedule analysis services and design steps. The most important factor for modelling is to use software which supports the open IFC standard and enables tool-neutral information validation. The IFC model is one of the main sources for analysing each step in the overall design workflow and it allows transferring different exchange information within and between the different design domains. The most important model investigations are as follows: IFC Object Structure The structure shown on Figure 17 needs to be observed for each IFC model as an input for all subsequent information exchanges and mappings to/from design, analysis and simulation services and tools.

Figure 17: Principal IFC model structure on the example of the W2 pilot

D10.400 Final Project Report Version 1.0 Page 28/80

The IFC Model includes project, site, topography, surrounding neighbourhood buildings, storeys, spaces and construction elements. The latter comprise walls, windows, doors, slabs, roofs etc. Terrain geometry and mass models of neighbourhood buildings are modelled as different object but connected to IfcSite. Normally, IfcSite means the construction site in closed sense. However, tor energy-related analysis the geometry of neighbourhood buildings should be available within the IFC model as mass models whereas the neighbourhood buildings are normally located outside the construction site in the closed project-specific sense.

Exchange information This comprises: . Project Information, such as postal address of the site, project attributes (ID, name etc.), units of measure, global measures (length, area etc.), decomposition type . Site Information, including site identification, spatial composition, spatial containment and various site-related quantities. If the existing terrain contains several types of land use, e.g. parking areas, streets, walkways etc., each of these types of land use should be modelled and named separately as special types of terrain. . Building Information, including the building identification (ID, name, description etc.), various building quantities, spatial composition and envelope geometry. Minimum one building per site has to be defined with its reference point, orientation and building classification according to the applicable national building codes. This data should be contained in instances of IfcClassificationReference, Pset_BuildingCommon and Pset_BuildingUse in the BIM-IFC model. . Building storeys, including storey identification, various quantities and the spatial composition of each storey. . Space related information including the space name, the space usage, specific space-related attributes and quantities, the space occupancy and the geometric second level space boundaries defining the complete physical or virtual delimiters of each space via instances of the IfcRelSpaceBoundary2ndLevel relationship class in IFC.

Exporting IFC with Revit Plugin For easier IFC export, a Revit plug-in called OneClickRevitToIFCExport has been developed by STRABAG. All relevant settings are configured in advance within IFC export settings as shown in Figure 18.

Figure 18: IFC 4 Coordination View 2.0 for IFC4 export

The user runs the plug-in with a single click, which provides a comfortable and time-saving approach for creating numerous IFC models with the same export settings. This solution minimizes errors which users may make during the export configuration.

D10.400 Final Project Report Version 1.0 Page 29/80

Figure 19: Revit IFC export plug-in developed by STRABAG

Quality Checks For the validation and quality check of IFC the following software tools can be used: . EDMmodelChecker/EDMstandAlone – stand-alone command line tool of partner EPM which validates a model according to the IFC schema and the exchange requirements . FZK Viewer 4.7 (KIT) – powerful IFC viewer which incorporates model validation functions according to the model schema . iTWO BIM Qualifier – validates the model specifically for iTWO requirements . Solibri Model Checker – established legacy tool for code checking of the model for different design domains (architecture, fire safety, fire escapes etc.) . The ER and KP checking and model validation services developed in eeEmbedded (see Section 7.6).

Figure 20: Screenshots from the validation of the IFC model of the Z3 pilot building using the FZK Viewer 4.7 (left)

Challenges in generating an IFC file Generating an IFC file that fits for all the software applications is not a straightforward task. Despite following the outlined modelling and exchange requirements and recommendations there are still a number of challenging issues regarding the correct generation of IFC data for the purpose of energy-related analyses and simulations, which are not yet fulfilled by legacy authoring tools. They are discussed in the project deliverable report D9.4 regarding the validation of the eeEmbedded platform on the example and experience obtained from the performed tests and pilot studies (Sprenger & Poloczek, 2017b). Furthermore, the possible specifications in the export functions of the legal CAD systems (even if they would work) are not sufficient for some of the IFC contents. The MVD approach of buildingSMART does not yet solve this issue.

D10.400 Final Project Report Version 1.0 Page 30/80

7.2.2. HVAC Design

HVAC design software (DDS-CAD) facilitates complete design and calculation of pipe and duct systems. Based on the intelligence information extracted from the architectural BIM-IFC, integrated calculations like air flow requirements, heat/cooling loads etc. enable developing optimal HVAC systems for the building and its usage. With DDS-CAD’s openBIM commitment, all types of available open construction library elements can be used, even though the components must be enriched with technical data. The role of HVAC design software in the early design stage is to import and analyse Space/Zone client requirements like occupancy, schedules, room temperature, activity, level of comfort etc. in addition to the spatial variants like area/volume, shape, location, glazing properties, sun blinds and so on. When these requirements are collected, and the external climatic conditions such as winter/summer temperature, humidity, solar radiation (ESIM) etc. are taken into account, a set of design criteria is applied to build up one or several variants of the HVAC systems. The different variants provide for comparing options with regard to to different building cost, physical space requirements, operating expenses and so on. All HVAC system variants will have enough information in itself to transfer operational demands to BACS. It is expected to read all Space/Zone requirements, except from the external climatic conditions, from an architectural BIM-IFC model, where object properties such as Pset_SpaceThermalRequirements, Pset_SpaceOccupancyRequrements etc. are correctly filled, and the design criteria like Pset_SpaceThermalDesign are either provided from energy or CFD simulation tools, or by the HVAC design tool itself, which will use this data to determine HVAC demands such as the size of air diffusers. All variants of the HVAC model should have a minimum of information contents for the BACS to use, and all components must be assigned to an IfcDistributionSystem with correct enumerated type. Components like Air Terminal, Damper, Air Handling Unit (AHU) etc., where there is a direct link to the BACS software must obligatorily contain this information. Using the knowledge obtained from the HVAC design allows meeting TO-BE KPIs and KDPs quicker and better. DDS-CAD’s approach to this information flow is to use standardized „openBIM“ knowledge templates to all disciplines.

Figure 21: Example of the pre-dimensioning and Figure 22: Example of the visualization of one alternative for modelling of one HVAC alternative with floor ventilation with AHUs and ceiling induction in the Multimodel heating (DDS Tool) Navigator of eeEmbedded (see Section 7.4)

D10.400 Final Project Report Version 1.0 Page 31/80

7.2.3. BACS Design Including building automation and control systems (BACS) design into the holistic eeEmbedded methodology is a new finding of the project which goes clearly beyond the current state-of-the-art process. It has been figured out that the energy efficiency classes according to EN15232 provide a suitable guideline for such a design because this beings different equipment such as AHUs, heating units etc. down to a formal, computer-interpretable categorisation. In order to perform the BACS design, several underlying steps have to be performed in advance: . Proper IFC based BIM model of all spaces/zones of interest . Definition of functional relationships within the HVAC design as well as the usage of proper IFC standard functional descriptions (such as IfcValve, IfcBoiler etc.) The first and most important added value by using this approach is that energy efficient solutions are designed in an early phase based on the provided models. In addition, the developed solutions are comparable with previous projects and templates can be reused in other projects. Figure 23 shows a screenshot of the developed eeBACS Wizard of the eeEmbedded project which supports designing BACS consistently using BIM-IFC data and interacting with architectural and HVAC design using the shared model data and the collaboration and resource management tools of the eeEmbedded platform. The beta version of the eeBACS Wizard developed during the project supports the user in creating energy efficient solutions from the beginning. It starts by analysing the available HVAC model and suggests a minimal setup of control strategies based on the desired energy efficiency class according to EN15232. The user can then customize the solution according to additional key points. The tool provides templates for products including costs and approximated energy usage over the life time.

Figure 23: Screenshot of the developed eeBACS Wizard

D10.400 Final Project Report Version 1.0 Page 32/80

7.2.4. Energy System Modelling (ESIM) Especially within the Urban Design stage architects and clients are interested in elaborating and comparing different system approaches of energy system concepts on a general systemic level. The analysis of current design steps involved in the creation of an energy system showed the informational gaps and the need for a unified description of energy systems. In that regard, the identification of core parts within the energy system in combination with a cross-domain-oriented set of properties was the starting point for a concept targeting the development of a unified modelling approach.

Systems Engineering with its related modelling languages UML and SysML is the approach used for the description of energy systems. A wide range of standards are available or currently under construction for this topic. The achieved project results have to be interpreted as a snapshot of the current cross-domain- driven movement towards the formalization of a common energy system description.

Figure 24: ESIM core parts and link model approach connecting related elementary models

Based on the analysis of existing approaches, a formal specification and conceptualization of the ESIM ontology was achieved. The development of that ontology comprised five main steps, namely (1) requirement analysis, (2) vocabulary definition, (3) ontology conceptualization, (4) ontology search, selection and reuse, and (5) ontology implementation.

Modelling environments supporting the system and requirement engineering approach by using the System Modelling Language (SysML) are predestined to support a formalized system-oriented modeling approach. In eeEmbedded, the need of different services for ESIM on knowledge level was clearly defined and the functional requirements and intention of a set of related services were identified. This includes: (1) Converter services, (2) Filter and query services, (3) Simulation mapper services as well as (4) Template management services.

D10.400 Final Project Report Version 1.0 Page 33/80

Currently experts of several different domains such as ‘Smart City’, ‘Smart Grid’, ‘Smart Home’, BIM and others are working intensively on the standardized modelling of several parts of the energy system as well as the more formulized description of buildings and their neighbourhood. Within this topic a highly dynamic development is recognisable resulting in completely new or re-worked standards and ‘best practice’ guidelines with high impact on the introduced approach of ESIM. Therefore, all findings regarding this topic have to be understood as a starting point. The work on ESIM - especially the implementation - is an ongoing task which goes beyond the timeframe of the eeEmbedded project while considering actual developments within the external standardization activities.

7.3. Scenario Manager

The Scenario Manager (ScM) is a new product developed within eeEmbedded following the holistic design methodology based on the IDM approach. It can support any BIM project in different design phases and it was developed as a general tool which supports team management, process management and data management for every project participant as mandatory part of the User Layer of every Virtual Lab configuration (see Figure 10). Its features comprise:

. Team management o Define BIM teams o Assign users to teams o Define team roles for users (BIM manager, architect, energy expert, …)

. Process management o Define workflows for different design phases (urban design, early design, detailed design) o Create tasks, gateways and flows following the BPMN standard o Specify control points and design loops o Assign users to tasks o Assign exchange requirements (ERs) to tasks o Issue notifications when users have to work on tasks

. Data management o Setup requirements for information levels, define target values and select possible building entities o Share files with other users using Multimodel Containers and BCF topics o Check data quality based on ERs o Automatically upload/download files to/from servers on the cloud o Merge data from different sources o Help to prepare data for analyses o Help to prepare results for KPI visualization.

Figure 25 shows the communication of multiple Scenario Managers within the eeEmbedded platform (ScM A & ScM B). The applications are connected with the central BCF server, BIM—it (see Section 7.5.1) and both are using the same workflow management engine (WFM Engine). This engine is responsible to load

D10.400 Final Project Report Version 1.0 Page 34/80 process models (BPMN diagrams) and to verify the status of the current running process. It notifies the Scenario Managers about changes in the workflow, for example when a task was completed or a problem like failed ER checks or failed key design parameter checks occur. Users can upload any file to the workspace and can download all files from other users where they have access rights. The workspaces are synchronized each time a handover to the next user in the workflow is done. The data which will be synchronized is held in Multimodel Containers (see Section 6.3). A receiving application of a Multimodel Container selects the domain models which are needed in its workspace and has to look into the Link Models to retrieve the information. The Multimodel Container is attached as BIM snippet to the communicated BCF topic. This is an enhanced approach for BIM—it (Section 7.5.1) which previously was focusing only on IFC data.

Figure 25: Communication between multiple ScMs on the eeEmbedded Virtual Lab platform

A BPMN editor included in the ScM supports the major BPMN elements like user task, flow, exclusive and parallel gateway, start event and end event. The project manager models the workflow and uses tasks which are specified in the key point setup table. S/he can assign to every task one user and some ERs. The ScM emphasizes in every task which actions are supported in that workflow stage. Figure 26 shows the task level view. User actions which are currently not possible are greyed out. Possible user actions are in bold black colour. Each button is connected to applications like the EDM model server, the KPA tool or the Multimodel Navigator. The data is transferred to and from those tools automatically. Hence, the user does not have to care about how to store the data. Task files can be imported in the ScM via Drag&Drop. Once the user has completed a task he can finish it and the handover to the next user will be done automatically as defined in the BPMN diagram.

D10.400 Final Project Report Version 1.0 Page 35/80

Figure 26: Task level view in the ScM with emphasized user task (red colour) and possible user actions

7.4. Multimodel Navigator

The Multimodel Navigator (MMNav) is the second mandatory tool in each Virtual Lab configuration on the User Layer of the eeEmbedded platform. It enables the user to check key design results arising in the various domains of the design process. It provides also advanced functionality to set up new construction conditions and to execute various simulations of proposed design variations and alternatives by the design team. The Multimodel Navigator was developed on top of the bim+ platform of Nemetschek. It is a multi-media- based navigation and visualization application that allows users combination of different graphical representations of results elaborated in the eeEmbedded design scenarios. The tool runs on standard Internet browsers and does not require software installation. For this reason, the MMNav is available everywhere and on any device, which could be decisive for decision makers. The following Figure 27 provides a graphical overview of the most relevant functional units of the MMNav. The application features: . Identification of graphical and numerical deviations, such as comparison of pre-set TO-BE design values with actual AS-IS Values . Assignment of new construction templates, space use templates, or other numerical settings such as climate data, latitude or longitude, north direction etc.; this allows users to run simulations as early as possible and to examine different materials and construction variants . Ordering the execution of different simulations under variant conditions - Energy, Wind, Life cycle costs etc. . Storing design decisions and corresponding construction conditions . Support of communication issues.

D10.400 Final Project Report Version 1.0 Page 36/80

Multimodel Navigator’s functional Units 1. ADMINISTRATION OF PROJECTS 5. ADMINISTRATION OF PROPERTIES  Project views  Definition of project/model/objects  Project selection properties sets  Filtering of projects

2. ADMINISTRATION OF BIM MODELS 6. MMNav VIEW CONTROL OPTIONS  Import of models via web service  Basic Visualization options  Creating model revisions  Federated Model views  Filtering of models  Object Explorer & Filtering by attributes  Information detail panel and attachments 3. ADMINISTERING PROJECT MEMBERS  Visualization of KPIs and KDPs  Inviting persons to projects  Definition of Multi-Model Structures  Managing member roles  Definition of construction variants  Collaboration in eeE Scenarios  Visualization of Simulation results 4. PROJECT ATTACHMENTS  Simulation attachments  Filtering of attachments  Attachment of properties to BIM objects

Figure 27: Functional Units of the MMNav (blue: developed or enhanced by eeE)

The following figures present some of the main features of the MMNav developed during the eeEmbedded project. Figure 28 shows the use of the MMNav during the verification of Key Design Parameters (KDP). The user is able to control the KDPs by opening and activating the nodes of the break-down structure. Each KDP is assigned a traffic-light colour which indicates the deviation of the AS-IS to TO-BE Value (fulfilled, critical, not fulfilled). In the presented example, all outer walls, which do not fulfil the Window-Wall-Ratio, are shown in red.

Figure 28: Verification of the Key Design Parameter “Window Wall Ratio (WWR)”.

D10.400 Final Project Report Version 1.0 Page 37/80

Figure 29 shows the construction templates break-down structure (left menu), which allows users to define different Construction Variants. The assignment of objects to specific construction templates is supported by the menu on the right. The navigation window is highlighting the walls in different colours, which corresponds to individually selected construction templates. The linking of objects to construction templates is stored on the cloud and can be easily recalled by the MMNav with the help of the Scenario Manager.

Figure 29: Assignment of objects having the same construction type for a given design variant

Figure 30 presents an example of the visualization of simulation results. Simulation results are automatically attached to respective individual objects via the ScM after the simulation service is run. These results are accessible for the user by clicking on the attachments in the menu on the right side.

Figure 30: Room simulation results attached to the related space object

D10.400 Final Project Report Version 1.0 Page 38/80

7.5. Collaboration and Resource Management Services and Tools

Collaboration and resource management services and tools are in the core of the Virtual Lab environment. They are responsible for the common use of the eeEmbedded service bus (Communication Layer) and for the intelligent access to the Repository Layer (Storage Cloud) and the analysis and simulation services (Compute Cloud). In the current eeEmbedded platform realisation these services include BIM–It, supporting the BCF- based communication, the EDM Model Server, providing a number of BIM-related data management services, and a set of Cloud Services facilitating the parallel analysis of multiple design variants.

7.5.1. BIM—It IABI’s BIM--It web application is a modern collaboration platform built for easy interoperability and exchange between partners in all project types of the AEC industry. While it is fully useable with any modern web browser, BIM--It is also built with an accessible API to allow the integration of external tools. In eeEmbedded, the Scenario Manager utilizes the developed BCF API to connect multiple platform services with BIM—It (see Figure 25). The platform was originally developed to be a BCF capable collaboration server but has since evolved into a tool that also offers services for project management and model analysis. It was the first available product to support the BCF API, shortly after it has been officially released by buildingSMART International in early 2015. Multiple software companies use BIM--It as a reference implementation for a BCF Server and have developed test suites against the platform. BIM--It is extensively described in the eeEmbedded Deliverable D8.2. Its main use case is to coordinate multiple project participants and to visualize building models for further checking and analysis. As a web application, BIM--It is hosted in the Microsoft Azure Cloud. It’s an Asp.Net Core web application backed by a relational SQL Server database. Some compute-intensive functionalities, such as converting building models, is outsourced to a micro service architecture accessed via http.

Figure 31: Detailed view of a single issue in BIM--it

D10.400 Final Project Report Version 1.0 Page 39/80

7.5.2. EDM Model Server The EDMmodelServer (EDM) provides a full featured repository for storing and manipulating ISO 10303 STEP EXPRESS based data, of which IFC 2x3 and IFC4 are two implementations. A fully featured EDM server provides services adapted to both thin clients like web browsers and smart phones, and fat clients like CAD systems and other full IFC data handling clients. Opposed to the more common file based storage for IFC BIM data, EDM stores data as models, where each model can logically refer to other models. While a model can be exported and imported in its entirety as a file, it is often necessary to export and import subsets of a model with operations like extraction and merging. The database system is designed to hold any number of models and each model has no size or instance number limit. EDM can also store as part of the model data files (BLOBs) in the same way as any other attribute. Supported file and transfer formats The EDM can natively import and export data in several formats, including: . ISO10303 Part 21 Step Physical File Format (SPFF) and Part 28 XML format (P28) . IfcXml, an implementation of P28 XML . For Web Services: SOAP xml (Simple Object Access Protocol) and JSON (JavaScript Object Notation). EDM supports any data defined by ISO10303 Part 11 EXPRESS Schema (P11) on full semantic level. Applications, services and utilities are available for several important industrial standards like ISO 12006-3 (used for BuildingSMART Data Dictionary bSDD) , IFC2x3 and IFC4. As long as data is defined according to a P11 Schema, import and export of this data are automatic processes. All data can be sent / received in the P21 and P28 (XML) format. In addition, any other data formats like e.g. Comma Separated Values (CSV) can also be accepted, but will require mapping. Traditionally, defining schema for and interfacing with such legacy data is called „adaptation” and is done by implementation of „adapters“. For simpler data structures, setting up an EXPRESS schema and adapters for the data is usually a relatively simple task.

Basic Functionality EDM supports validation and integrity checks against the employed EXPRESS schema, in case of eeEmbedded IFC4. The function layer checks automatically all data that are imported to the system against constraints defined by the target schema. Express-X can be used to add user-defined rules for additional checking. Merge / extract are powerful options for adding, replacing and extracting subsets of data, for example domain models (HVAC, BACS, EL) in an IFC file, or embedded “non-traditional” data like lease areas or maintenance data.

Extended Functionality In those cases where the XPX language is not sufficient for implementing the requested functionality, EDM supports the use of Server Side Plug-ins (SSPs) written in a generic programming language like C# or VB.NET. A typical scenario for use of SSPs occurs when data and services provided by other nodes need to be accessed, for example when: . Data validation requires the server to read ontology data from an external source . A workflow requires the server to send a mail to a particular user. Such functionality can be implemented using SSPs. The effect is that the EDMmodelServer will both act as a service provider and a service consumer on the service bus.

D10.400 Final Project Report Version 1.0 Page 40/80

Accessing server-side functionality in the EDMmodelServer There are two main approaches for accessing data and functions in the EDMmodelServer: . Using an API, utilizing a binary protocol between client and EDM. This implies that the client links to an EDM library for accessing the functions. The API functions hide the data transfer layer between client and server. APIs called language bindings are available for several programming languages like C# and Java. . Using a Web Service interface like http/SOAP or http/REST, utilizing a general “text based” protocol between client and EDM. In this case there is no direct software dependency between client and server. Access is provided via XPX queries. This means that as soon as a database query is defined using XPX, it is also available on the web, provided that the client has the necessary trust level. This mode is well adapted to “thin clients” like web browser applications.

Management of the EDMmodelServer-ifc and its data As a companion to the EDMmodelServer, EPM delivers also the EDMmodelServerManager (MSM), which provides access and user interface to a vast set of functions like . Model management (import and export, merge, extract, versioning etc.) . User and access management . Defining and running reports . Browsing and manipulating models (2D and 3D graphical viewer, user definable tree breakdowns, property filtering and editing and much more). Typical applications of EDM in the AEC industry are shown in Figure 32 below.

Figure 32: EDM Server Applications

D10.400 Final Project Report Version 1.0 Page 41/80

7.5.3. Cloud Services Calculations involved in energy simulations demand large computing resources and thus deployment in the cloud is an inevitable prerequisite for efficient exploration of design options towards achievement of optimal building performance. Development work on cloud services exploited prior availability of all analysis tools as cloud enabled applications and delivered a cloud framework abstraction that provides plug-ins for major existing cloud frameworks and can easily cope with future cloud frameworks with minimal developer effort. The resulting cloud services comprise: (1) a Broker Service that translates requests from the eeEmbedded service bus to various cloud frameworks, and (2) Plug-ins to implement different cloud engine interfaces.

Figure 33: The eeE Cloud Framework

The Cloud Broker Service encapsulates all the details of the underlying cloud infrastructure masking differences and implementation details (like hosting server location or specific cloud system details) thereby providing a uniform eeEmbedded Cloud API. To guarantee that the Cloud Broker Service is globally accessible, in the eeEmbedded service bus an advertisement/registration mechanism is used to publish service availability. In particular, the Broker Service has been used to perform energy simulations with TRNSYS (Section 7.7.2) and CFD simulations with the 3D Wind and 3D Therm applications (Sections 7.7.3, 7.7.4) using the developed API.

Figure 34: Energy Analysis running on a private cloud

D10.400 Final Project Report Version 1.0 Page 42/80

Figure 35: CFD Simulation Running on the HPC cloud system offered by a European Research Institute

The use of cloud based computing resources enables the management of simulations running in parallel. However, this leads also to certain requirements regarding the simulation management concept which are an inherent part of the overall simulation and optimization framework. The simulation management is enabled by a Simulation Model Mapper which is part of the analysis domain reflecting special needs of the used analysis tools as well as the used cloud environment.

The required capabilities can be differentiated into (1) non- functional, (2) functional and (3) workflow-related. . Non-functional capabilities are scalability, maintainability and adaptability . Functional capabilities are related to infrastructure and access management, self- management or health- control and information acquisition and delivery . Workflow-related capabilities are input management, job-analysis-tracking, output management and, as optional part, data archiving. Figure 36: Example showing the information flow

D10.400 Final Project Report Version 1.0 Page 43/80

7.6. Model Validation Services The model validation services are another important part of the core layer of the Virtual Lab environment. While not mandatory for the functioning of the overall system, they are crucial for the achievement of efficient high quality design because they ensure that modelling errors and gaps are largely avoided by the exchange of model data within the design team, requirements are met and key points are appropriately observed or deviations identified as early as possible. Therefore, the use of these services are highly recommended by all end user partners in the eeEmbedded consortium.

7.6.1. Ontology-based Exchange Requirement Checking and Visualisation The ontology-based Exchange Requirement Checking enables capturing the information exchanges according to the buildingSMART Information Delivery Manual (IDM) as well as steering and tracking them during the design process. It helps to systematize design tasks, level of information agreements and exchange requirements (ER) for the various BIM uses/phases and configure them for each specific project in a digital environment. Implemented as a service the ontology-based ER Checking is available via the Scenario Manager (ScM). It provides the functionality to setup and run ontology-based exchange requirements verification and visualization. The added value is in insuring the model quality and the compliance with the information requirements of the successor in the design process. The overall ER Checking approach is outlined on Figure 37 below. It comprises the following steps: (1) Exchange Requirement Setup: Exchange Requirement Specification as part of the Project Setup (2) Exchange Requirement Setup: Defining Multi-Model View Definitions regarding the exchange requirements by implementing ontology-based ER Checks using SPARQL queries (3) Exchange Requirement Checking: Preparing the ER Checking by selecting relevant data models (e.g. IFC and ESIM) as input data (4) Exchange Requirement Checking: Performing the ER Checking on the basis of the input data (5) Exchange Requirement Visualization: Generating a validation report for the end-user and result file for the following Key Point Checking.

Figure 37: Overview of the ontology-based ER Checking

D10.400 Final Project Report Version 1.0 Page 44/80

Exchange Requirement Setup (Steps 1 & 2) The specification of the Exchange Requirements and the corresponding mapping to a specific data schema is part of the overall project setup (see Section 7.1). The setup of the ontology-based Exchange Requirement Checking is also part of the project setup. However, in order to prepare for later ER checks some additional preparation work is necessary. The tables used for detailed ER specification shown in Section 7.1 are thereby extended by an additional column providing the links to the ER check definitions, which are specified separately in advance using SPARQL queries. Figure 38 shows as example the SPARQL query to check if an IFC model contains an IfcSite object which is decomposed by at least one IfcBuilding object.

Figure 38: Definition of an ER check based on the data schema mapping using SPARQL

Exchange Requirement Checking (Steps 3 & 4) In order to warrant the quality of the data models of a design alternative within the eeEmbedded design process, an iterative process of model creation (authoring tool) and ontology-based ER checking has to be performed. After each design task (e.g. Create Design Cubature Options) the ER checking service can be invoked through the ScM. By clicking the ER/LOD check button the task-related ER table including ontology- based ER check is started and validates the quality of the elaborated design (see Figure 39).

Figure 39: Screenshot of the Exchange Requirement Checking Service for ER-1.10 ARCH

D10.400 Final Project Report Version 1.0 Page 45/80

Exchange Requirement Visualization (Step 5) After the ER check has validated the data model input the result file highlights all information gaps in the provided design alternative. Depending on the Exchange Requirement specification the ER check validates a single data source or a multi-model. In the following Figure 40 the result of the ER check is visualized for the Exchange Requirements that specify the needed information from architectural design. The colours in the first column of the ER specification indicate whether information is available (green), not present (red) or calculated/derived from other information (orange).

Figure 40: Visualization of the ER Checking results indicates in the first column whether the required information is available (green), not present (red) or calculated/derived from other information (orange).

7.6.2. Ontology-based Key Point Checking and Visualisation While ER Checking is responsible for the quality of the input models, the KDP Check aims to check the quality of the results of a certain design task. The requirements for KDP checking are defined during the project set up phase (see Section 7.1). The KDPs can thereby be interpreted as extension of the ERs: ERs define that an entity and respective entity attribute(s) should exist in the input model, while KDPs define the ranges in which the attribute values are valid. Before the KDP check can be triggered, similar to the ER Checking, the Multimodel Container and its content has to be transferred to the KP ontology. This transformation is realized in several steps. In the first step the relevant element types are transformed into OWL. This is realized by transforming the types from the Excel sheets into SPARUL as an intermediate step. The SPARUL code is then interpreted by the Ontology Verification Service (OVS) and the types are then mapped into OWL and linked with the predefined Link

D10.400 Final Project Report Version 1.0 Page 46/80

Ontology. After this step, the predefined Ontology Schemas of the KP ontology and the IFC ontology are linked together with the types. The result is a linked schema of KPs, types and IFC elements.

Link Ontology

KP TYPE IFC OWL l ONTOLOGY ONTOLOGY e

SCHEMA v

L CHEMA CHEMA S S e s Q L e

l R y u A R P g S o l

KP TYPE o IFC OWL t

ONTOLOGY ONTOLOGY n INSTANCES INSTANCES INSTANCES O

l e v

KP Selected IFC Step e L Values Types Model a t a D

TARGET VALUES ASIS VALUES

Figure 41: OWL Representation of the Multimodel

After the schemata are created in OWL, the instances are generated. The target values of the KPs and the types are defined in the project setup (see Section 7.1) where the specific links between KPs and types are defined. Similar to the schema generation, instance generation also uses SPARUL code. For the comparison of the set TO-BE and the actual AS-IS Key Point values the IFC model is transformed into IfcOWL using the mapping tool from buildingSMART (http:// http://ifcowl.openbimstandards.org/IFC4_ADD1/index.html). The final result is a complete ontology consisting of KP, type and IFC schemata and instances. Figure 42 shows how the process is prompted within the project setup by a corresponding Excel-based GUI.

Configurations for Model Generation

Workspace Folder C:\Users\makad\Desktop\20170717_ScM_Project-Setup_MASTER-file_v24

Multi Model Selection

Select Multi Model C:\Users\makad\Desktop\20170502_eeE_Multimodel\20170502_eeE

Select Variant

OWL Model Generation Parameters

SPARUL for Generate Entity Types Yes

SPARUL for Entity Types to IFC Schema Yes

OWL for KP Ontology Yes

SPARUL for KPs to Entity Types Yes

OWL for IFC Yes

SPARUL for Entity Types to IFC Yes

Start Model Creation Figure 42: Multimodel generation in the project setup phase via the Excel-based GUI

D10.400 Final Project Report Version 1.0 Page 47/80

Both the TO-BE model and the AS-IS model are encoded in OWL. To check for the correct results, the relationship between both models is described via SPARUL. The checking can then be triggered by the Ontology Verification Service. In order to start the KP checking via the ScM the different SPARUL rules have to be related to the different tasks. This information is included in the KP spreadsheets. Figure 43 shows an example for the task/KP relation.

(1) Load KDPs and selected tasks (2) Setup KDP Check

KP ID KP type KP group KP sub-category Name Task-ID Task-Name KDP01 KDP design geometry Building Height 20-10 20 01 Create design cubature options KDP02 KDP design geometry Floor to floor height groundfloor 20-10 20 01 Create design cubature options KDP03 KDP design geometry Number of floors 20-10 20 01 Create design cubature options KDP04 KDP design geometry Gross floor area (GFA) 20-10 20 01 Create design cubature options KDP07 KDP design energy U-Value Wall 20-10 40 01 Create energy system concepts KDP08 KDP design energy U-Value Base Slab 20-10 40 01 Create energy system concepts KDP09 KDP design energy U-Value Roof 20-10 40 01 Create energy system concepts KDP12 KDP design energy Air tightness 20-10 40 01 Create energy system concepts KDP13 KDP design comfort temperatures winter (perimeter) 20-10 40 01 Create energy system concepts KDP14 KDP design comfort design temperatures winter (core) 20-10 40 01 Create energy system concepts KDP15 KDP design comfort design temperature summer 20-10 40 01 Create energy system concepts KDP16 KDP design geometry Window Wall Ratio (WWR) 20-10 40 01 Create energy system concepts KDP18 KDP design energy systems Energy system cooling 20-10 40 01 Create energy system concepts KDP19 KDP design daylight Area of regularly occupied spaces within 7.5m of exterior windows or atrium 20-10 40 01 Create energy system concepts Figure 43: KP – Task Relation

The KP checking itself produces tabular results in a similar manner as the ER check service. Additionally, the results can be visualised in the MMNav via automatically generated colour codes, which show the level of fulfilment of a selected design parameter for all BIM elements associated to it. This is a very useful feature since it allows quickly identifying gaps and critical points in the design. An example is shown in Section 7.4 which outlines the features of the MMNav (cf. Figure 28).

7.7. Energy Simulation and Analysis Services and Tools Energy simulation and analysis applications are required to properly assess energy performance and enable objective evaluation of various design variants. In the scope of eeEmbedded three such applications have been integrated: (1) TRNSYS, providing for comprehensive thermal analyses/simulations in all targeted design phases, (2) 3D Wind, providing for simulation of wind influence to assess building location and orientation with regard to the neighbourhood and verify key parameters already in the urban design phase, and (3) 3D Therm, providing for deep CFD simulation of selected critical zones/spaces to evaluate thermal comfort in the detailed design phase.

7.7.1. Input Preparation Typically, energy simulation analysis tools imply sophisticated mathematical models and therefore require complex preparation of the input models, which is mostly done manually by an energy expert to ensure that the simulation model reflects the design intent correctly. However, as energy performance is affected by a high number of design parameters, whose influence is not easy to predict, today’s design process calculate only a very few variants. This often leads to suboptimal solutions. The eeEmbedded methodology suggests an approach to improve that situation by re-engineering the simulation and analysis tools and thereby splitting the pre-processing, analysis/simulation and post- processing steps into separate processes. This enables preparing a large number of parameter variations by the end users (architect, HVAC designer or energy expert), which are then executed in parallel on a compute cloud and compared and evaluated on the basis of the computed KPIs by a specialised Multi KPA Tool.

D10.400 Final Project Report Version 1.0 Page 48/80

Crucial in that regard is the achievement of a high degree of automation in the input preparation. This involves the following steps: (1) Semi-automated assignment of design variants in the MMNav (2) Automated generation of stochastic parameter variations to enable optional uncertainty analysis in order to better estimate lifecycle risks (3) Automatic generation of a Variation Model, linking the defined parameter variations to the base BIM- IFC design model (4) Using BIM2SIM plug-ins for the simulation tools to perform the transformation of the data from the BIM model to the analytical simulation input models; here the most difficult part is the proper interpretation of the geometry and the topology of the building and the respective generation of 2nd level space boundaries, which are needed for the thermal simulations (5) Using the developed cloud API to provide for fast parallel computation of all generated variants. The first two of these steps are performed by tools embedded in the ScM on the User Layer, whereas the subsequent three are performed automatically with the help of the support services on the Core and the Analysis Virtual Lab layers. In Step (1) design variants are created on BIM level using the MMNav. The process is facilitated by the use of a library of templates for various climate and occupancy profiles as well as various element construction types (for walls, slabs, roofs, ground plates, windows, doors) and the associated materials. Essential in that regard is the association of element types to standard OmniClass items which can be done in the project setup phase and enables initial fully automatic template assignment (see Figure 44).

Figure 44: Automatic element-template assignment in the Multimodel Navigator

Using templates, parameter variations can be easily done in the MMNav user interface, shown schematically in the following Figure 45. Creating a design variant only requires the input of the desired parameter

D10.400 Final Project Report Version 1.0 Page 49/80 changes, whereas all other data is automatically interlinked to the new variant from the imported base BIM- IFC model.

Figure 45: The user interface for template assignment in the Multimodel Navigator

In Step (2), performed in the case of a desired Uncertainty Analysis, a special input preparation tool called Sampling Service is additionally used. It can be launched from the ScM. However, before the sampling can be performed, some parameters have to be configured. These are the chosen number of samples, the time interval for the output time series, the building location and the number of days each sample should comprise (see Figure 46).

Figure 46: Sampling Service GUI

When the sampling service is performed, it produces required occupancy and/or climate samples and saves the generated data in the multi-model. In addition, the Link Model is updated with the new stochastic variants.

D10.400 Final Project Report Version 1.0 Page 50/80

Thus, not only architectural and engineering design variants can be examined but also parameter ranges, reflecting the uncertainty of the design values at a certain project stage can be taken in consideration to enable better informed design decisions and better understanding of the designed building’s performance.

7.7.2. Thermal Simulations with TRNSYS Energy analysis is included in each part of the design process. Following the intended overall approach, sophisticated analysis tools modelling the thermal as well as operational behaviour of the building as well as main components of the energy systems need to be integrated into the workflow to support the decision-making process. In eeEmbedded, the software system TRNSYS-TUD is used for this kind of analysis. TRNSYS is the abbreviation for TRaNsient SYstem Simulation program which was initially developed by the University of Wisconsin in Madison, USA before approximately 35 years. The software is on sale as commercial software package targeting energy experts. It is continuously updated whereby parts of the software code are distributed in source form but the main core parts are available only as binaries. The project partner TUD-IET started the development of its own individual software modules for TRNSYS in 1994. Since this time more and more new simulation modules were added or existing modules were re-shaped respectively adapted to support the special tasks within research projects. Because of the high rate of newly developed software modules and approaches which are unique compared to the software setup which is available as commercial solution, the suffix TUD was added to the original trademark TRNSYS to indicate the difference between the commercial tool and the research-orientated solution TRNSYS-TUD. The additional or modified software modules developed by TUD-IET are not available for purchase or free distribution. The simulation package in eeEmbedded is adapted and configured for modelling energy systems and related buildings. It is based on a modularised concept which provides a high level of flexibility when analysing various kinds of energy systems while involving peripheral conditions and related phenomena. Because of the modularised approach of the software design experienced users have the possibility to add their own software code to the core software parts to process simulations according to their individual tasks. Overall role of TRNSYS-TUD In the eeEmbedded context TRNSYS-TUD acts as a common placeholder for similar software systems used for transient thermal building and energy system simulation. In a productive environment, a comparable tool with similar functionality such as EnergyPlus could be used too.

Figure 47: Workflow within the energy analysis domain, embedding the simulation tool into the Analysis Framework

D10.400 Final Project Report Version 1.0 Page 51/80

In general, the integration of the sophisticated analysis task on the eeEmbedded platform can be divided into three main sub-steps: (1) pre-processing, (2) analysis processing and (3) post-processing (see Figure 47 above). TRNSYS-TUD covers components which are designed for pre-processing purposes, e.g. to transfer the building model provided by the architectural domain into a simulation model covering the building geometry, energy system components (depending on the design stage) as well as user behaviour and climate conditions. This complements the assignment of design variants in the MMNav providing for BIM2SIM model transformation and some additional input features. On Figure 48 and Figure 49 the results of transferring the architectural model into the geometrical part of the simulation model is presented based on the level of detail used in the Early Design stage. In the Urban Design phase the whole analysis process covering pre- processing, processing and post-processing is almost fully automated.

Figure 48: Pilot building STR Z3: Architectural model (IFC, left) and simulation model (TRNSYS-TUD, right)

Figure 49: Pilot building BAM W2: Architectural model (IFC, left) and simulation model (TRNSYS-TUD, right)

Interdependencies and constraints with regard to other domains The quality of the geometrical model provided by the architectural domain plays an important role to automatically run the analysis process as a service. The analysis software benefits from the output of the architectural domain (Urban, Early and Detailed Design) as well as the HVAC and BACS domain (Early and

D10.400 Final Project Report Version 1.0 Page 52/80

Detailed design). Other inputs can be included as well like stochastic samples (see Section 7.7.1). If inputs are missing, default templates or default values can be used based on client requirements or an internal template library. However, with regard to the quality of the BIM models generated by authoring systems there are many challenges that have yet to be overcome as outlined in the eeEmbedded validation report – see Deliverable D9.4 (Sprenger & Poloczek, 2017).

7.7.3. 3D Wind Analysis in Urban Design 3DWind is an end-user application for the aerodynamic analysis of a building embedded in its urban environment to obtain the best building cubature (shape and orientation) regarding wind comfort indices, local wind potential for renewable energy use and natural ventilation design (as a result of the combination of solar radiation and wind flow). 3DWind can be used as complementary tool to Energy Simulation applications in the Urban Design phase. In the context of eeEmbedded, CFD analysis utilizes IFC files for the description of the neighborhood geometries (buildings and terrain), templates and Link Models that empower collaboration and coupling of CFD with other simulation applications critical to Urban Design phase. Architects continuously receive feedback from the CFD analysis and can easily make decisions about the building cubature which are critical for all the consequent design phases. Automations have been developed for the construction of suitable models for CFD simulations from IFC building model of any LoD and any design phase. The translation of weather wind data to proper boundary conditions for the atmospheric boundary layer has been developed and automated. For the wind analysis around the building at hand, wind-rose data are used which describe the mean wind velocities, the magnitude, the direction and the duration of the wind at a specific site within a typical year (see Figure 50 below for the sites of the two pilot projects used in the validation phase).

W2 Pilot, Utrecht, NL. Prevailing directions SW, SSW. Z3 Pilot, Stuttgart, DE. Prevailing directions WSW, SW. Prevailing wind speed 4.5m/s and significant time Prevailing wind speed 3.3m/s intervals with 6-7m/s

Figure 50: Wind rose data for the two pilot demonstrators

The wind speed distribution described by wind rose refers to mean hourly wind speeds measured at 10m above the ground. Radial distances indicate percentage of time (or exact number of hours) of wind events. In the context of eeEmbedded, a CFD analysis is conducted at Urban Design and Detailed Design phases. At UD phase, the CFD analysis provides wind comfort KPIs for KPA decision support process. The two predicted

D10.400 Final Project Report Version 1.0 Page 53/80

KPIs concern two representative wind velocities, the first one is the velocity at the building entrance and the second one the velocity at city canyons around the building (Figure 51 below).

m Wind Velocities 3 /sec

3.00

2.50

2.00

1.50 POINT 1 POINT 2 1.00 POINT 3

0.50 POINT 4 POINT 5 0.00 POINT 6 -3.00 -2.50 -2.00 -1.50 -1.00 -0.50 0.00 0.50 1.00 1.50 2.00 2.50 3.00 POINT 7 -0.50 POINT 8

-1.00

-1.50

-2.00

-2.50 -3.00

Figure 51: Wind speed at human height, resulting speeds at all points of interest organized in the form of wind rose and wind stream lines around the Z3 building (top) and around the W2 building (bottom).

According to site wind data, a number of significant directions and magnitudes of wind speeds are considered in order to compose a simulation matrix for the CFD analysis, (see Figure 52 below).

Rotation Wind Wind Velocities - Occurence Rotation Wind Wind Velocities - Occurence around Z Direction >60% <30% <10% around Z Direction >60% <30% <10% 0 N 3m/s 0 N 4.5m/s 45 NW 3m/s 45 NW 4.5m/s 6.5m/s 67.5 WNW 3m/s 67.5 WNW 4.5m/s 6.5m/s 90 W 3m/s 5m/s 7m/s 90 W 4.5m/s 6.5m/s 112.5 WSW 3m/s 5m/s 7m/s 112.5 WSW 4.5m/s 6.5m/s 9.5m/s 135 SW 4.5m/s 6.5m/s 9.5m/s 135 SW 3m/s 5m/s 7m/s 157.5 SSW 4.5m/s 6.5m/s 9.5m/s 180 S 3m/s 180 S 4.5m/s 6.5m/s 202.5 SSE 3m/s 202.5 SSE 4.5m/s 225 SE 3m/s 225 SE 4.5m/s 247.5 ESE 3m/s 247.5 ESE 4.5m/s 270 E 3m/s 270 E 4.5m/s 292.5 ENE 3m/s 5m/s 292.5 ENE 4.5m/s 6.5m/s 315 NE 3m/s 315 NE 4.5m/s

Figure 52: Simulation matrix for prevailing wind for the Z3 building, (left) and the W2 building (right)

Simulation results are synthesized by applying frequencies (fij) of occurrence to each of the wind directions and wind speed magnitudes, as weighting factors:

푛푢푚푏푒푟 표푓 푤푖푛푑 푑푖푟푒푐푡푖표푛푠 푛푢푚푏푒푟 표푓 푑푖푓푓푒푟푒푛푡 푤푖푛푑 푚푎푔푛푖푡푢푑푒푠 푉̅(푥, 푦, 푧) = ∑ ∑ 푉푖푗(푥, 푦, 푧) ∙ 푓푖푗 푗=1 푖=1

D10.400 Final Project Report Version 1.0 Page 54/80

CFD analysis workflow Separate IFC models for each cubature alternative and variant are received for the CFD analysis. The CFD analysis proceeds according to the following steps: . The global site coordinates are determined by the IfcSite entity of the IFC model and the wind rose data are consequently obtained for each location . Geometry extraction from IFC file (SOF’s application) . Model simplifications for reasonable CFD analysis (SOF’s modeler) . Imposition of CFD boundary conditions and definition of the KPIs to be estimated. Construction of a simulation matrix according to the prevailing wind directions and wind speeds (SOF’s modeler) . Assignment of CFD runs for execution in the HPC cloud or our private parallel cluster . Summing-up of the results for the estimation of suitable KPIs (2 KPIs per alternative per variant). The KPIs are delivered via CSV files to KPA tool. . CFD detailed analysis results presentation through videos and 3D representations of suitable flow quantities (stream lines, pressure isosurfaces etc.) attached to IFC model in MMNav.

7.7.4. 3D Therm Analysis in Detailed Design CFD analysis for the prediction of microclimate conditions inside buildings provides the capability for accurate estimation of thermal comfort conditions in buildings and the optimization of HVAC layouts ensuring that: . interrelated and dynamic aspects of building performance (passive and active elements – energy demand and supply reduction options) are adequately considered and reflected in the predictions of energy performance, finally resulting in indoor comfort . the building design performs as close as possible to what is anticipated . not only energy consumption needs are addressed but also the risk of overheating, peak loads and indoor air quality are assessed . improved decision making is provided so that designers can achieve the optimum and most cost- effective combination for reduced energy consumption and improved indoor comfort. 3DThermalCFD is a CFD application enhanced with heat transfer equation and buoyancy terms in Navier- Stokes equations. It is used coupled with Energy Simulations in order to provide detailed data in spaces of particular interest. Currently, the coupling of Energy Analysis with the CFD analysis algorithm is a subject of ongoing research work and a significant amount of manual work is required in order to exchange data/results between the two types of simulations. This manual work within eeEmbedded is significantly reduced and the coupling becomes feasible. The CFD model includes all the HVAC and BACS installation alternatives in order to evaluate the effectiveness of HVAC systems under both energy performance and thermal comfort criteria. The special characteristics and the installation of the chosen HVAC systems are taken into consideration and alternative scenarios can be examined.

D10.400 Final Project Report Version 1.0 Page 55/80

In the Detailed Design phase the thermal comfort KPIs concern the percentage of the occupied space where thermal comfort requirements are fulfilled. Examples of suitable KPIs are the Predicted mean vote (PMV), the percentage of people dissatisfied (PPD) due to discomfort, the percentage dissatisfied (PD) due to draft, and ventilation effectiveness (EN 7730:2005, EN 15251:2007). CFD detailed results provide answers for: . What parts of the room exposes occupants to the most uncomfortable conditions? . What parts of the room are responsible for wasteful heat gains or losses? . What parts of the room exposes occupants to the highest levels of CO2 and other harmful gases? . Users can easily follow path lines and flow mixing resulting from mechanical or natural ventilation in order to evaluate the effectiveness of natural or mechanical ventilation systems. Apart from spatial and temporal 3D representation of KPIs, results interpretation is based on 3D stream lines “coloured” with temperature (Figure 53 below), spatial distribution of air temperature and air speed and turbulence intensity distribution in 3D space or at levels of occupants head and legs.

Stream lines coloured with temperature and pressure

Figure 53: CFD results representation for evaluation of KPIs efficiency purposes (Z3 pilot, Stuttgart)

D10.400 Final Project Report Version 1.0 Page 56/80

CFD analysis workflow Separate IFC model for each alternative which concern the type and the installation of the HVAC systems, are received for the CFD analysis. The CFD analysis proceeds according to the following steps: . Data import:

i. Space/room geometry (from IFC file) ii. Operation point of HVAC systems and airflow conditions (flow rate, cross sectional area, point on the psychrometric diagram) for the scenario of interest (i.t. ｔhe coldest of winter or hottest fay in summer) iii. Thermal and cooling loads, such as occupant loads, infiltration loads, equipment and lighting loads from templates iv. Wall temperatures (from Energy Simulations) v. Solar gains from glazing surfaces (W/m2 from Energy Simulations) vi. BACS function . Model simplifications for reasonable CFD analysis (SOF’s modeler) . Imposition of CFD boundary conditions and definition of the KPIs to be estimated. Formulation of suitable boundary conditions according to HVAC type and operating point (SOF’s modeler) . Assignment of CFD runs for execution in the HPC cloud or our private parallel cluster . Summing-up of the results for the estimation of suitable KPIs. Examples of suitable KPIs are: Predicted mean vote (PMV), the percentage of people dissatisfied (PPD) due to discomfort, the percentage dissatisfied (PD) due to draft, and ventilation effectiveness. The KPIs are delivered via CSV files to KPA tool. . CFD detailed analysis results presentation through videos and 3D representations of suitable flow quantities (stream lines, pressure isosurfaces etc.) attached to IFC model in MMNav.

7.8. LCA and LCC Analysis The LCC/LCA tool using iTWO® helps in implementations of activity/time-based considerations for a sequence of alternatives in the project. The LCC/LCA workflow is processed within different modules in iTWO such as Element Planning; Bill of Quantities (BoQ), Job Estimation, Activity Model, thereby transferring results to each of these activities to generate the whole life cycle cost and assessment of different alternative within the project. TWO’s LCC/LCA process is important to identify the key performance indicators (KPI) at each stage over a period and providing practical guidance on the application of LCC for each use case. The LCC/LCA model is a link between the CAD model and cost accounting model. The BIM Qualifier provides users with functions that allow you to check the IFC4 data and correct it, if necessary, or to improve the quality of the data. Element planning calculates the quantity estimation for different CAD models. The Bill of Quantities (BoQ) a structured document, using a hierarchy for collecting and summarizing values at each level in the structure. The Bill of Quantities (BOQ) contains all the works to be cost/ecological assessment in project alternative. For a project, different BOQs can be defined, structure and referenced with respect to Model detailing. The job estimation model is used to produce the cost of the BOQ item using the cost code or commodities. Estimate details are parameterized so that detail resource quantities, productivities and cost factor are calculated. The activity model links the estimate or BOQ to activity schedule. This allows estimation using the time dependence variable by linking with the calendar catalogue. This transforms into activity schedule, which is an important tool for life cycle analysis. The activity model is interlinked with the resources, which is linked with the cost codes and commodities.

D10.400 Final Project Report Version 1.0 Page 57/80

Figure 54: BIM Qualifier for importing IFC4 files

Figure 55: Element Planning different IFC model

Figure 56: Job estimation for estimation of cost using resources (Cost code/ commodity)

D10.400 Final Project Report Version 1.0 Page 58/80

Figure 57: Activity model inside iTWO for time scheduling

Figure 58: LCC result for KPI Tool for decision making

7.9. Risk Assessment Service

The goal of the risk assessment service is to analyze the effects of uncertainty on a buildings performance. The focus in eeEmbedded was especially set on energy-related risks. In this context, main contributing uncertainties have been described in (Gnüchtel et al., 2015) and encompass categories of variables like thermo-physical properties (e.g. climate and material properties), occupancy and occupant behavior as well as energy system reliability. The assessment of the resulting energy risk has a large impact for the decision making process, as the risk has direct influence on the exploitation and maintenance costs. In the pilot projects and for the proof of concept, the focus has been on climate and occupancy uncertainty, but the developed approach can also be applied to other types of uncertainty.

In the context of the eeBIM framework, a crucial challenge was the integration of uncertainty information into the eeBIM Multimodel. The newly developed variation model described in (Pruvost et al., 2017) has been established with this purpose in mind. In addition to enabling the description of numerous design alternatives and variants, it also describes stochastic realizations thereof. Stochastic realizations are generated by the dedicated Sampling Service (SaS) and thus can be applied for each design variant. They describe several scenarios for the building life cycle that are dependent on aleatory uncertainties, e.g. climate conditions and occupancy. Unlike design variants, which are configured manually by an end user in the Multimodel Navigator (MMNav), the stochastic realizations and their respective data variations are generated automatically by the Sampling Service and are afterwards stored into the Multimodel Container (MMC). For the sake of the TRNSYS energy simulation, defined within the use case scenarios (Sukumar et al., 2015) and applied by the pilot projects, each stochastic realization consists of a data sample, which is

D10.400 Final Project Report Version 1.0 Page 59/80 constituted by time series of climate and occupancy variables and thus reflects varying climatic and building usage conditions over time. After the export of the Multimodel Container from the MMNav, the dedicated sampling service is functioning as an on-demand service for the preparation of samples for the energy simulation and can be started directly from the Scenario Manager (ScM). Once started the SaS imports the MMC and produces data samples. Finally, those are then exported back into the MMC. The samples are generated on the basis of the background stochastic models described in (Gnüchtel et al., 2015) and implemented via specific algorithms. In the following we are giving a brief explanation about the modeling approaches followed for the climate and occupancy variables. For occupancy sampling, a first-order Markov chain technique has been applied. This technique has been chosen for its flexibility as well as moderate computational cost. The sampling operates at zone level, where zone is a flexible term that can reflect a room, a storey or the whole building. As input data functions one transition matrix per zone type that consists of probabilities, which describe that at a certain point in time, the number of occupants changes from one amount to another (see Figure 59). The generation of this matrix is realized from the existing occupancy data of a comparable zone. The sampling itself generates a time series for each zone, consisting of an occupants number for each time step. Figure 60 shows a graphical representation of such an output of one day.

Figure 59: Transition matrix for occupancy sampling

Figure 60: Graphical representation of one output from occupancy sampling

For the eeE climate sampling method performed prior to the energy simulation, there were three challenges:

D10.400 Final Project Report Version 1.0 Page 60/80

The first was to generate realistic high-resolution climate samples, consisting of multiple parameters each (outdoor temperature, wind speed, solar radiation, etc.) and for a time span of up to 30 years. This disqualifies pure mathematical methods for time series prediction like ARIMA. Secondly, to use these samples for uncertainty analysis, they need to reflect the natural uncertainty of future weather events. This disqualifies the artificial averaged data sets typically used in energy simulation (e.g. TRY). Thirdly, computing time has to be in line with a workflow approach centered on information gain and possible reevaluation. This disqualifies complicated atmospheric models used by meteorologists for weather prediction. In view of that, the following approach satisfies all three demands: For locations of interest a database with the measured weather data of the last years is being created. It is important that the data sets comply with the requirement for fine resolution of all required parameters, which means that a time interval of 10 minutes is desired. Any missing data points are filled in with average values. Additionally, a compromise between high number of data sets and their actuality has to be made. When performing the targeted uncertainty analysis, each energy simulation run is supplemented with one of these data sets, chosen randomly from all available sets for the location. After the simulation of all samples in TRNSYS-TUD (Forns-Samso et al., 2015), the simulation engine provides a set of KPI values as required by the variation model. In the example of Figure 61 below, the computed KPI was the energy demand for heating (kWh/m2/year). The figure shows the uncertainty analysis view of the KPA tool in which the distribution of KPI values for three different design variants are plotted. For each variant a set of around fifty weather and occupancy samples were used. The figure shows substantial differences between the three variants, which differ in their energy system technology (district heating, natural gas boiler and biomass boiler respectively), window-to-wall ratio and other architectural properties. The second example shows less robustness with regard to uncertainty and has consequently a higher standard deviation. Despite higher mean energy consumption, the two other alternatives show less volatility in the yearly use of energy.

Figure 61: Visualization of simulation results from performed uncertainty analysis in terms of energy demand for heating by three different design variants (KPA tool)

D10.400 Final Project Report Version 1.0 Page 61/80

On the basis of such a KPI output data set, certain KRIs can be derived in post-processing on the basis of the value distribution of each KPI, which results from uncertainty for the simulation input. The KRI derived from the previous data set in the example above is the standard deviation of the heating energy demand. Following the same approach and using other specific input data and simulation tools, additional KRIs can be computed. Such KRI can be defined as statistical indicators, deduced from the value distribution of a KPI. Examples are energy system reliability, energy system maintainability, energy system availability, investment costs, revenue and so on.

7.10. Multi Key Point Analysis Tool for Decision Making

Decision making, broadly defined, is a combination of interconnected activities that include gathering, interpreting and exchanging information; creating and identifying alternative courses of action; choosing among alternatives by integrating the often differing perspectives and opinions of stakeholders; and implementing a choice and monitoring its consequences. In eeEmbedded we acknowledge the multidisciplinary nature of a construction project: it employs several experts performing different types of analyses, simulations and thus creating a large number of results to be explored and analysed. The most general case of decision-making within a building design process can be expressed as an end decision that is the product of a whole series of domain decisions (i.e. financial, environmental, functional and physical) and the interaction of the interested parties.

In construction projects, group decision making is always preferable compared with individual decision making for increased effectiveness. However, working in such inhomogeneous group/collaborative environments is not common and requires the use of methods, methodologies and tools that facilitate a holistic and collaborative design process. One of the main outcomes of the eeEmbedded project is the developed Key Point Methodology and the supporting software tools, such as the Scenario Manager, Multimodel Navigator and the Multi Key Point Analysis (KPA) tool. The combination of the methodologies and tools will allow project teams to work in a more collaborative and structured way and thus allow them to making better informed decisions during each the design phase. In the following we describe the developed Multi Key Point Analysis Tool used to support the decision making process. The Idea Due to the complexity of construction projects and the large amount of information created during a design process, the integration and visualization of data is critical for well-founded decision making. The intention is to develop a tool that supports multidisciplinary work and enhances collaboration between projects teams. Additionally, it should help the experts and decision makers in analyzing and evaluating the impacts of Key Performance Indicators (KPIs) from different design domains. A weighing factor can be added to each KPI or different KPIs, corresponding to the same evaluation criteria (e.g. environmental or financial), can be grouped together and receive a shared weighting factor. This process will result in the calculation and visualization of a Decision Value (DV). The process will give us a better understanding of the analyzed variants and present a more holistic view of the evaluated criteria as well as the involved variables. The KPA tool supports teams to work in a more structured way, while also enabling flexibility and interaction within the analysis of variants and thus facilitating the decision making process. The tool is critical for rapid comparison of different evaluation criteria.

D10.400 Final Project Report Version 1.0 Page 62/80

The Innovation The KPA tool is developed as a web-based decision making application that uses a graphical multi-attribute utility analysis to evaluate and compare alternatives based on Key Performance Indicators. Most of the calculations and all of the visualizations are computed and rendered in the browser, while only some minor touches are done on the server side. The tool contains three main modules: The first module is the simulation synthesis, which performs sensitivity and uncertainty analysis. The sensitivity analysis calculates and visualizes the standardized coefficients for each design parameter in relation to each KPI and is used to prioritize decisions for the design parameters that have stronger influence on the KPIs. Uncertainty analysis is used to visualize the fluctuation of the KPIs in the presence of uncertain parameters, such as weather data or user profiles. The employed sensitivity analysis was developed in the previously funded EU project ISES. In eeEmbedded we added the uncertainty analysis visualization as shown in Figure 61 in section 7.9. The second module is the KPI analysis, which uses advanced plotting graphics for multi-dimensional data visualization, such as hyper radial visualization, parallel coordinate plot and radar charts. All the plots are developed and used for analysis purposes, thus allowing the user to investigate the relationship between the various variables in depth. By using these plots the user has the option to thoroughly investigate a wide range of alternatives and data used to create those alternatives. Figure 62 shows the KPIs and design parameters in one plot, visualized as a parallel plot. Each polyline is the representation of one design variant. The example case shows a large number of variants represented by the polylines. However, the capability of the parallel coordinate plot in the tool allows for making a criteria selection based on different requirements for each KPI, reducing the number of alternatives based on these requirements. The bolded polylines on Figure 63 represent alternatives that could be analyzed in more detail as they fall within the project requirements and represent the most optimal solutions.

Figure 62: Parallel coordinate plot showing all possible alternatives and relationships between KPIs and design parameters

D10.400 Final Project Report Version 1.0 Page 63/80

Figure 63: Filtered parallel coordinate plot representing a reduced number of alternatives based on criteria selection and highlighting the better one (thick curves)

The third module is the Decision Value (DV) analysis which graphically represents the preferences of the decision makers related to the project goals. The Decision Value is calculated as a weighted sum of the results of fitness functions over each KPI. This allows prioritizing KPIs by means of a weighting factor. The user can set up their requirements and group the KPIs with a weighing factor within the Scenario Manager or through the requirements setup in the KPA tool. The main purpose of the tool is to reduce the wide range of variants to the ones that better represent the stakeholder preferences of the initial project setup. However, this does not mean that the highest DV alternative has to be chosen, stakeholders can choose a reduced number of alternatives that could be analyzed in further detail using an iterative process.

Figure 64: Decision value representation

D10.400 Final Project Report Version 1.0 Page 64/80

Benefits to end users

Integrating results from analysis and simulations from different software tools and having these results represented with advanced graphics facilitates the decision making process. Consequently, it creates better understanding of the influence of different design parameters towards the design variants and offers a comprehensive way to manage them. Calculating and visualizing the Decision Values benefits end users for having a holistic view of the project priorities.

D10.400 Final Project Report Version 1.0 Page 65/80

8. Evaluation of the eeEmbedded Platform

The platform is evaluated employing the validation and verification steps as has been detailed in the Deliverable D9.4 (Sprenger & Poloczek, 2017). The qualitative and quantitative parameters have been gathered during the assessment of the platform and the evaluation has is based on the developed prototypes, the availability of data, the working methods, the business and social impacts, the future perspectives as well as possible standardization steps. There are two methods used for the platform evaluation. The first method is the Cost Benefit Analysis (CBA) presented in Table 2 below. Its purpose is to investigate the integrity of the platform and the methodology with regard to their balance of costs against the provided benefits. The benefits from the development and application of the platform are compared to the potential risks, which may occur during a project using the eeEmbedded platform. The CBA focuses mainly on the efficiency and quality of the process and the quality and costs of the resulting design. To measure these, the targeted and design results, i.e. TO-BE and AS-IS KPIs, KDPs and DV, of the pilot projects are used. The improvements towards the processing time is measured by comparing the different phases of the design process and comparing them to the pilot projects’ results produced by the eeE platform. The second method is the Strength, Weaknesses, Opportunities, Threats (SWOT) analysis summarized in the Table 3. It investigates each component of the platform and is thereby helping to define the strengths and weaknesses that it offers to the platforms’ users as well as the opportunities to enhance each product and to give it a competitive value. Finally, an insight regarding possible threats involving the usage and development of the components is provided.

Table 2: Cost Benefit Analysis based on the performed scenario validation Note: steps marked with an asterisk and shown on green background are valid for all phases but were most thoroughly investigated in the Urban Design phase and are therefore shown within this part of the table

Process steps Difference to current practice Benefits Costs

Basis: Urban Design Validation Project setup Process management  Process time: No reduction in time regarding BEP  Development of templates and optimization setup, but time saved for coordination in later  Training for correct handling management* stages by elimination of ‘manual’ coordination. Achieves increased process efficiency.  Process quality: Clear roles, responsibilities and information exchanges are defined.  Building quality: Ensures building design quality at each milestone. The building fulfils the client and regulation requirements more closely.  Building costs: Ensures costs remain within budget.

Create Design One standard IFC model and  Process time: eeE workflow does not require  Depending on the complexity cubature setup for all BIM users, that is complicated model in early phases, since the of variants, not all exchange maintained throughout the templates are assigned to wall elements. If many requirements can currently be entire duration of the project variants shall be analysed, separate models have met. Models created in Revit to be created for each variant. Out of one variant, and exported to IFC4 tend to many alternatives can be generated. fail some ER checks due to  Process quality: One common IFC file per export quality. alternative for the entire process and shared by all tools ensures a smooth design process.  Building quality: IFC model is validated by using the ER checks. This provides excellent quality of an architectural 3D model at an early design stage ensuring the quality at the later design stages.  Building costs: The IFC model is used for LCC calculations within the cost estimation tool. Costs of the building and the materials can be predicted at an early stage of design.

D10.400 Final Project Report Version 1.0 Page 66/80

Process steps Difference to current practice Benefits Costs

Create Visual and immediate creation  Process time: The standard variant creation needs  A standard naming convention Variants* of building variants per element each element to be designed and therefore expert is needed type. knowledge is needed for creating the complete  Differences of the variants model in Revit. In eeE, predefined energy need to be tracked manually templates are ready for assignment for a simple  Libraries need constant model and automatic template assignment is refinement to be up-to-date possible. (for materials, countries, costs,  Process quality: Clear visualization of elements etc.) with variant data.  Building quality: Quick evaluation of building energy behaviours subjected to different energy settings.  Building costs: Best quality vs. cost building options can be evaluated by creating many variants. Quality check – Automated model-based  Process time: Compact verification of the model  As long as IFC standards are Exchange checking of the information and all variants saves time. Communication is developing and the software requirements* requirements and visual more efficient, due to automatically receiving tools used are changing their feedback of deviations. made-to-measure information in each task, requirements, ER Checks need instead of defining and requesting the needed to be updated. information.  A programmer is needed to  Process quality: Each variant is checked against formulate the ER checks (e.g. exchange requirements. ER checks make the SPARQL) process smoother since many errors are detected at an early stage.  Building quality: Ensures wholeness of the building’s BIM model for the purpose of the simulations. Increases the quality and reliability of simulations, which in turn assess building quality.  Building costs: Supports by providing a complete model for cost analysis. Quality check – Automated model-based  Process time: Quick setup and management of  Requires lots of initial input KDP check* requirements check. Visualises KDPs within one table. Variant management is before the design process the deviations from KDP. easier and faster: those that do not fulfil the starts. However, tables can be requirements are discarded and the time that reused. would be used to simulate them is saved.  Changes in the requirements  Process quality: Structured database and need changes in the setup. documentation with all KDPs, which can be  Extension for additional checks checked anytime during the design process. needs expert knowledge. Visualization of KDPs in the MMNav.  Building quality: Advanced and early management of the requirements towards the building. KDP check guarantees that requirements are fulfilled or that deviations are being flagged.  Building costs: Limitations can be introduced for KDPs that will later influence the LCC costs simulation. CFD Wind Continuous feedback from the  Process time: The pre-processing time for the  Extension and automation of simulation CFD analysis to the architect preparation of models for the CFD analysis is the coupling of CFD analysis and therefore easy decision- drastically reduced and becomes feasible even for with Energy simulation is making about the cubature, non-CFD-experts. CFD analysis becomes accessible needed for a more accurate which are critical for all the to architects from a very early design phase on. analysis and to render the consequent design phases. Computing time is also reduced by performing coupled analysis feasible for the simulation runs in the cloud. whole building.  Process quality: The accuracy of the results is improved due to the consideration of construction details and the building’s surrounding environment. The capability for automatic formulation of the CFD model via the incorporation of templates in the Detailed Design phase and the coupling with Energy Analysis significantly improves the quality and the efficiency of the simulation.

D10.400 Final Project Report Version 1.0 Page 67/80

Process steps Difference to current practice Benefits Costs  Building quality: Supports the decision for the best architectural alternative: CFD analysis in the Detailed Design phase incorporates the energy analysis detailed thermal comfort criteria. The selected KPIs will act as metrics to measure a building’s absolute energy use performance, in order to benchmark against similar buildings or with best-practices and assess energy efficiency measures within buildings.  Building costs: Improved decision making is provided and designers can achieve the optimum and most cost-effective combination for reduced energy consumption as well as improved indoor and outdoor comfort. Stochastic Currently the process is done as  Process time: One-click analysis.  The more samples are analysed, Sampling* a stand-alone. In the eeE  Process quality: Stochastic sampling covers (1) the longer the simulation takes. workflow the stochastic occupancy profiles related to the space types as sampling is based on and well as (2) weather data related to the location of transferred together with the the building. Because of the integration of the simulation results. It enables sampling service in the Scenario Manager the use of stochastic based accessing the sampling service is easy to handle. variable ranges to enhance The results of the sampling services will be design variant options. automatically integrated in the job description handed over via Multimodel Container. The preparation of the energy analysis will include the generated samplings.  Building quality: Thanks to the risk analysis, the influence of comfort and quality parameters can be evaluated.  Building costs: Risk analysis supports more reliable calculation of costs, thus better decision values can be achieved. Energy Currently the standard  Process time: Depends on the complexity of the  The Energy Simulation has simulation* approach is to develop a model and time intervals used within the simulation. specific demands toward ER completely new 3D energy The time is significantly shortened due to the cloud and therefore towards model. In the eeE workflow, environment. Simulation results are automatically modelling (e.g. 2nd level space energy simulation is based on incorporated. The results are summarized in KPIs boundaries are required). the existing IFC model provided making decision making easier and faster. The by an architect. utilization of an existing IFC model makes the process faster comparing to create an entirely new 3D energy model.  Process quality: No expert knowledge is required to develop the energy analysis model, since it is based on the IFC model and MMC content. In current practice the exchange between the architectural and simulation software are often not working very well, here the IFC model is transferred almost without a problem.  Building quality: Energy analysis is included at a very early design stage and applied for different variants. Many factors, e.g. wall construction materials, window-wall ratio, CFD simulation, are taken into account to provide the most reliable energy results for the building.  Building costs: Energy analysis enhances LCC calculations in predicting the best cost-efficient variant. Life Cycle Cost All chosen construction types,  Process time: LCC simulation results and domain  Initial iTWO template setup Analysis* energy system types and decisions are much quicker due to storing the requires lots of manual work simulation results for an results in KPIs. The automation saves time in inside the software. alternative-variant combination alternative-variant processing and comparison. are merged into one IFC, which  Process quality: Variants can be filtered. allows automation and inte-  Building quality: Supports identifying the gration of LCC in a very early alternative-variant combination meeting the design stage. sustainable criteria and the budget.

D10.400 Final Project Report Version 1.0 Page 68/80

Process steps Difference to current practice Benefits Costs  Building costs: Supports identifying the alternative- variant combination with the optimized LCC. Decision Weighted decisions from all the  Process time: Much faster and compact overview  Weighting needs to be checked making* analyses and simulations based of all the variants and their quality. Faster cross- to ensure the right priorities are on compiled Decision Values, domain analysis and cross-domain decisions. correctly represented which have been defined by the Increased cost-effectiveness of evaluation of the throughout the decision making decision maker at project start alternatives and variants. process. within the KP setup.  Process quality: All results are clearly visualized.  Building quality: Provides a clear indication of a building with best quality with regard to the integrated and prioritized design quality goals coming from all domains.  Building costs: Supports to identify a building with best quality and cost combination. Basis: Early Design Validation

HVAC Design Feasibility study of more va-  Process time: More variants can be analysed in the  Setup of generic HVAC riants can be made than in the same time. templates current practise possible.  Process quality: Design issues are easily communicated with the other design members via BCF.  Building quality: Energy and comfort optimisation by interactive consideration of building and systems variants.  Building costs: Balanced life cycle costs BACS Design BACS engineer is involved  Process time: Knowledge-based design support  Setup a database with control earlier in the design process. fastens the early concepts. strategies, components and  Process quality: Knowledge-based support for the costs or invest in the eeBACS BACS designer to comply with EN15232. Wizard once the product is  Building quality: Optimised energy efficiency and ready for the market. comfort based on early analysis of control strategies.  Building costs: Balanced LCC for the clients’ needs based on integrated costs. FM Strategy FM is involved earlier in the  Process time: Knowledge-based support allows for  Setup a generic database of design process. earlier analysis of maintenance strategies. maintenance cycles, service  Process quality: Integrated analysis of lives and maintenance maintenance strategy and LCC. strategies.  Building quality: Optimised quality over the whole life cycle.  Building costs: Optimised costs based on clients/users’ needs over the whole life cycle Basis: Detailed Design Validation Comfort In Detailed Design, currently the  Process time: The pre-processing time for the  Extension and automation of simulation coupling of Energy Analysis with preparation of models for the CFD analysis is the coupling of CFD analysis the CFD analysis algorithm is drastically reduced and becomes feasible even for with Energy simulation needs a subject of ongoing research and a non-CFD experts. CFD analysis becomes accessible more accurate analysis to significant amount of manual to architects in a very early design phase. render the coupled analysis work is required to exchange Computing time is reduced by assigning simulation feasible for the whole building results between the two types of runs in the cloud. The capability for automatic (Detailed Design). simulations. This manual work is formulation of the CFD model and the coupling significantly reduced within with Energy Analysis significantly improves the eeEmbedded and the coupling quality and the efficiency of the simulation becomes feasible.  Building quality: CFD analysis in the Detailed Design phase incorporates the energy analysis detailed thermal comfort criteria. Not only energy consumption needs are addressed but also the risk of overheating, peak loads and indoor air quality is assessed (Detailed Design).  Building costs: Improved decision making is provided: designers can achieve the optimum and most cost-effective combination for reduced energy consumption and improved indoor and outdoor comfort.

D10.400 Final Project Report Version 1.0 Page 69/80

Table 3: SWOT Analysis

SWOT / VDL Strengths Weaknesses Opportunities Threats components Basis: Urban and Early Design Validation

Scenario Well-structured set up of a BIM Lack of data exchange flexibi- Design a process with tasks that Security issues of the Manager Execution Plan. BIM process lity with the tools as it de- can be done in parallel can be software. Maintenance, coordination and information pends on the Project Setup. developed. Process templating administration and secu- management. Accessible for Once the process workflow is can be developed for the ability rity care is required. users at any time. The updating setup and the process is to reuse processes or sub- of the information occurs started, there is no possibility processes. automatically since all the tools to amend the process. are connected with ScM. The workflow is tracked across the design steps & analyses. Access to all project/task messages.

MMNav Graphical user interface for It is not possible for end users Reviewing the model in MMNav Large size projects require clear analysis of KDP. Quick to integrate new templates is flexible and clients have the a reliable and fast internet generation of variants based within MMNav. Not possible to possibility to access the model connection as well as fast on a single 3D model through instantly change properties at any time. It is possible to server. easy access to predefined within a template in MMNav. extend the template access to a templates. It is possible to template management system include and link external data for end users, which is to the model. Offers Web- integrated in the Project Setup. based presentation of a 3D This should allow for the model and automatic assign- creation and updating of ment of element types based templates. on Omni Classes defined within the Project Setup.

KDP and Automatic checks for KDPs and Without detailed IFC know- Setup can be improved to be Defining the wrong rules ER Checking exchange requirements, saves ledge, it is not possible to more user-friendly. The checks could lead to time and manual work. This specify the checks from scratch. for the geometry could be misinterpretation of the automatic check detects more User-friendliness needs to be expanded and further deve- results. errors than a manual analysis of improved loped. An appropriate graphical the model. user interface could be a solution to avoid using expert knowledge and setup KDPs and ERs can be reused.

TRNSYS Automated pre-processing IFC model does currently not Enhancing the capabilities of IFC standards are influ- covers the transfer of the IFC include construction templates the IFC model interpretation encing the interpretation model to the simulation model, chosen. They are loaded sepa- and thus, for example, omit the of the IFC model need to by enhancing the model with rately as a .csv file as an input additional .csv file. be adjusted to updates. additional information, inclu- of the analysis. ding assigned templates.

3DWind Completely integrated into Simulation takes a significant Enhanced automation of the Not suitable for cases of the workflow and uses the amount of time, which slows CFD model generation from the rapid urban development, shared BIM model. Produces the entire design process. IFC model in the CFD geome- where the topography simulation data as KPIs and Tool can only be used by a CFD trical modelling environment. changes drastically around returns those back to the expert. There is a lack of This includes geometry the building of interest. process workflow. Usage of visualisation of the results modifications in order to fulfil the KPI allows for easier within MMNav as results can the requirements for a feasible interpretation of the analysis be only attached in it. CFD analysis. results and the classification Improving the speed and of the building. robustness of CFD simulations Automatic import of IFC is an ongoing research field. model saves manual work for the preparation of the CFD model.

D10.400 Final Project Report Version 1.0 Page 70/80

SWOT / VDL Strengths Weaknesses Opportunities Threats components iTWO - Automated life cycle cost and With minor exceptions, the The generated data could be Shared data management LCC/LCA life cycle analysis for each data within iTWO cannot be provided using an open schema is considered to be the variant. reused with other BIM and be treated independently of ongoing trend in develop- software programs. the program’s functionalities, to ments, which the tool is The initial setup of iTWO enable back-end data com- lacking. templates is a complicated munication. Providing a user- No implementation of manual process. interface for the LCC and LCA LCC/LCA user interface is Until now, iTWO does not calculation would highly simplify foreseen in the immediate provide any user interface for the procedure for the end users. future. LCC and LCA calculation. The MMC approach should be integrated into the iTWO process to increase the automation of recognition of templates, variants, contents, materials etc.

Multi-KP Easy and transparent decision Since it is a web-based tool, For someone who is not aware The software has security tool making and visual analysis of there is no direct connection of KDPs, KPIs are a better guide issues. alternatives and variants. to the data or the results: It for result interpretation and User-friendly: supports cross- needs a connection to the could be added. Plotting and domain analysis, decision internet to function. analysis types can be expanded. making and multi-criteria The visualisation depends on Algorithms to automatically analysis. the accuracy of the data provided and the format optimize the selection of alternatives and narrow the specified. number of alternatives can be The tool is not BIM com- implemented. patible: Data is agnostic, which could also be a benefit. Basis: Early Design Validation

eeBACS Control strategies based on an There is no 3D representation Enhancing and expanding the Depends on a correct Wizard Early Design model. within the tool and it is limited database and involve the BACS HVAC model. Incorporates the IFC/HVAC to EN15252 energy efficiency designer early in the process IfcDistributionSystem, specific classes in the current proto- enumeration and relation of type. HVAC components to spaces. Proposes BACS equipment (sensors, actors) and their costs.

Basis: Detailed Design Validation

3DTherm Completely integrated into the Simulation takes a significant Increase automations for both New energy saving workflow and uses the shared amount of time that slows the the preparation of suitable technologies and zero BIM model. Produces simu- entire design process down. models for CFD analysis and the energy buildings require lation data as KPIs and returns In order to formulate a fea- knowledge-based interpretation continuous adaptation of these back to the design work- sible geometrical model and of analysis results to make it more the techniques for the flow. Automatic import of the boundary conditions, manual accessible for non-expert end generation of suitable CFD enhanced IFC model with leads work is needed for the proper users (architects, HVAC designers) models. to the saving of manual work. simplification of HVAC, BACS, The AEC market has continuously The most important strength of furniture and other devices increasing needs for a combined the CFD analysis lies in the that are considered for energy CFD and Energy Analysis. automatic coupling with energy balance of each space. analysis application, which provides a great technological and scientific advantage for the detailed energy analysis of buildings.

The results show that the workflow and most tools are very useful and beneficial for the process quality and help to shorten the time needed to perform such a process. Furthermore, most of them have an advantageous influence on the building costs and quality. The prototypical state of the tools means that many tools have the need to improve their user interface for easier access and that some may be only be operated by experts or after extensive training.

D10.400 Final Project Report Version 1.0 Page 71/80

9. Exploitation of the eeEmbedded Platform

The main goal of the eeEmbedded project was the development of a stochastic and model-based Virtual Energy Lab Platform and virtual design office for integrated engineering design and the development of new products and components facilitating energy-efficient planning. The developed ICT system is a modular platform, from which each eeEmbedded partner did develop and configured specific modules or combinations of modules, as required for their individual exploitation needs. The platform will therefore be the main exploitable prototype and each eeEmbedded partner and any other interested party can exploit the platform in their own configuration as well as with third-party software exploiting the eeEmbedded data models and interfaces, as long as the third-party software complies to the established BIM-related information management standards (IFC, BCF) and some specific energy-related modelling requirements.

The integrated eeEmbedded platform will be exploited: . as a technical Virtual Energy Lab to study new products (building components, technical components) and services before their realization and to perform an in-depth analysis of poor performance under lifecycle conditions in order to undertake the right tuning decisions, . as a holistic virtual engineering design office for the design and redesign of facilities and buildings to study alternatives in depth and under various life-cycle conditions, in order to come up with the best balanced design decision for the facility owner, . as a system analysis tool to analyze the energy and emission behavior of existing facilities and buildings, in order to find out their weak components or instances of degraded operation and to make suggestions to the owner for the redesign, retrofitting or reengineering of the operational processes. The individual components will be used as standalone tools or in a bundle with other tools providing BIM- based interoperability infrastructure. They will be exploited and marketed separately by each eeEmbedded partner as they deem suitable for their individual exploitation needs.

Achieved Commercially Exploitable Results

Open BIM Platform Services

User Interface and Workflow Management of the eeEmbedded Virtual Lab Platform enabling to assign tasks, actions and data, deadlines and dependencies; Scenario Manager and Navigation and control of all project variants and displaying the results from Multimodel Navigator all analysis tools, thereby supporting an informed decision making; Free of charge basic functionalities of MMNav including a SDK for 3rd parties and an open API.

Ontology (OVS), ER Fast validation of Key Point values and rules of standard design codes of an Check, KDP Check eeBIM Model according to pre-defined rule sets.

Construction types, Materials with physical properties, future integration of Libraries, definition of alternative sub-processes to the pre-defined scenarios Templates via Business Process Modelling Notations (BPMN) that may contain a lot of conflicts

D10.400 Final Project Report Version 1.0 Page 72/80

Commercial End User Applications or Plug-In Modules

Aerodynamic analysis of buildings to optimize shape and position of a 3D Wind building according to criteria such as energy consumption, wind comfort, CFD Analysis Tool wind potential, natural ventilation design

Detailed energy analysis in buildings for the prediction of indoor climate 3DThermal conditions toward the fulfilment of user-defined thermal comfort require- CFD Analysis Tool ments

Life cycle cost and analysis estimation for all investment and running costs iTWO LCC/LCA regarding even environmental impacts, like energy and CO2 consumption

Comparing different design alternatives to find the best solution; Multi KPA Tool Display of user-definable performance values (Key Points); Various visualizations within the tool or via the Multimodel Navigator

Energy simulation for calculation of the thermal behavior of buildings taking TRNSYS into account energy systems and HVAC components

Determining correct BACS variant(s) according to already calculated Key eeBACS Wizard Design Parameters

BIM server which can merge IFC Files from different disciplines with EDM Model Server application in energy analyses, HVAC design and lifecycle cost calculations

Extensions to existing Commercial Applications

General Architectural Design CAD Software, capable to manage multiple Allplan (NEM) configurations using parametric modelling

HVAC Design capable to generate multiple configurations using parametric DDS-CAD MEP (DDS) modelling and to produce domain BIM models according to various LOD/LoD agreements

Case Builder BACS Software for handling building automation projects; contains energy-efficient (SAR) strategies and methods

Granlund Designer Designing the MEP equipment in a construction project taking into (GRA) consideration FM requirements

D10.400 Final Project Report Version 1.0 Page 73/80

10. Conclusions

This report described the essential results of the eeEmbedded project which have been thoroughly validated and evaluated by end users from the design (architecture, HVAC, energy), construction and FM domains. The results showed that the goals of the project set up at the outset have been successfully achieved. A new design methodology building upon the use of a comprehensive hierarchy of Key Points (DVs, KDPs, KPIs, KRIs), advanced ICT technologies and standardised data models has been developed and a consistent adaptable and extensible Virtual Design Office platform has been implemented. Much of the realized software tools and services are thereby well prepared for short-term practical exploitation in AEC industry context. Through the use of both storage and compute cloud facilities scalability problems have been successfully solved. By applying templates, filtering and advanced multimodel techniques a possibility of investigating a large number of design variants has been found, which can be used not only by large companies but also by SMEs which are typical for the design landscape in the AEC domain.

However, while the results are overall positive, there is still research and development work needed to achieve even better design solutions with regard to optimal energy use (especially with regard to renewable energy), sustainability and cost effectiveness. Various modelling issues need yet to be solved as the related data standards and the respective market and academic tools have not yet reached full maturity. For example, the transformation of BIM data to the computational input models needed by analysis and simulation tools is still a challenging problem for many complex practical cases. Interoperability of tools and services also remains an issue, especially when detailed data is addressed, as for example by sophisticated simulations or in detailed design. Last but not least, issues related to the BIMification of the existing building stock need to be addressed to be able to apply the eeEmbedded methodology efficiently in retrofitting and refurbishment projects.

Concluding, it has to be noted that this report only provides an overview of the major project findings. Detailed results are documented in a rich set of public deliverable reports which will be available via the project’s web site (http://www.eeembedded.eu). More importantly, commercial exploitable results are expected to emerge soon as outlined shortly in the preceding chapter.

D10.400 Final Project Report Version 1.0 Page 74/80

Appendix

References

Aish R. & Woodbury R. (2005): Multi-level Interaction in Parametric Design. Lecture Notes in Computer Science, Springer Berlin / Heidelberg. Volume 3638/2005: 151-162 Alwaera H., Clements-Croomeb D.J. (2010): Key performance indicators (KPIs) and priority setting in using the multi-attribute approach for assessing sustainable intelligent buildings, Building and Environment 4(45), Pages 799–807, DOI:10.1016/j.buildenv.2009.08.019. Autodesk Inc. (2017): Autodesk Revit® 2017.2, San Rafael, USA. Baumgärtel K., Katranuschkov P. & Scherer R.J. (2017): An intelligent platform for thermal energy analyses, to appear in: Automation in Construction (2018), Elsevier Borrmann A., König M., Koch C. & Beetz J. (2015): Building Information Modeling: Technologische Grund- lagen und industrielle Praxis (Building Information Modelling: Technological Basis and Industrial Prac- tice), Springer Vieweg, DOI 10.1007/978-3-658-05606-3, ISBN 978-3-658-05606-3 (eBook) Brohus H., Frier C., Heiselberg P. & Haghighat F. (2012): Quantification of uncertainty in predicting building energy consumption: A stochastic approach. Energy and Buildings, Elsevier buildingSMART: BCF [Online], http://www.buildingsmart-tech.org/specifications/bcf-releases buildingSMART/ifcXML [Online], http://www.buildingsmart-tech.org/specifications/ifcxml-releases buildingSMART International Ltd. (2017): Industry Foundation Classes Release 4 (IFC4) [Online] http://www.buildingsmart-tech.org/ifc/IFC4/final/html/ buildingSMART/MMC [Online]: Multimodel Container to exchange combined models https://github.com/BuildingSMART/MMC. Calleja-Rodriguez G., Guruz R. & Loeffler M.-C. (2017): Automated Alternatives Analysis Procedure using Key Points Method for multidisciplinary energy efficient building design projects, to appear in: Automation in Construction (2018), Elsevier DDS-Viewer Version 10 Win32 build 8/5-2014 [Online], www.dds-cad-com, 2014. Demharter, J., Fuchs S., Schapke, S.-E. and Scherer, R. J. (2014): Multimodell und Multimodellcontainer, IN Informationssysteme im Bauwesen – Modelle, Methoden und Prozesse (information Systems in Building Construction – Models, Methods and Processes), Springer Vieweg, DOI 10.1007/978-3-642- 40883-0_2, 39 – 64 p. DIN EN 15232 - Energy performance of buildings – Impact of Building Automation, Controls and Building Management. German version FprEN 15232:2011. DIN EN ISO 16484 - Building automation and control systems (BACS) -- Part 3: Functions. eu.bac – Certifying Energy Efficiency of Building Automation and Control Systems, a first delivery and during the lifetime – Part 4: Specification of Key Performance Indicators. German BMBF project MEFISTO [Online], http://www.mefisto-bau.de Grierson D. E. (2008): Pareto multi-criteria decision making, Advanced Engineering Informatics 22(3), pp. 371- 384.

D10.400 Final Project Report Version 1.0 Page 75/80

Grille T, Pruvost H. & Scherer R.J. (2016): Stochastic Analysis for Design Space Exploration and Building Performance Optimisation, Proc. CESBP Central European Symposium on Building Physics and BauSIM 2016, pp. 369-375, http://www.cesbp2016.de/cesbp Gudnasson G., Balaras C., Dascalaki E., Katranuschkov P., Laine T., Grunewald J., Protopsaltis B., Mansperger T., (2012): ISES Deliverable D4.1: Technical specification of the overall framework and the principal energy profile and consumption patterns, © ISES Consortium, Brussels. Guruz R. & Scherer R.J. (2014): Sustainable energy entrepreneurship through architectural design: a key point controlled method, Entrepreneurship and sustainability issues, Vol. 2, pp. 60-73, Entrepreneurship and sustainability center, Lithuania, http://jssidoi.org/jesi/aims-and-scope-of- research/ Häfele, K.-H., Brenner, J., FZKViewer V 4.7 (Build 905, 2017-02-10), Karlsruhe, Germany. Hollingsworth D. (1994): The Workflow Reference Model, © Workflow Management Coalition. ifcDoc Tool [Online], http://www.buildingsmart-tech.org/specifications/specification-tools/ifcdoc-tool ISO 16739 (2013): Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries, International Organization for Standardization, Geneva. ISO 29481-1 (2016): Building information models -- Information delivery manual -- Part 1: Methodology and format, International Organization for Standardization, Geneva. ISO 29481-2 (2012): Building information models -- Information delivery manual -- Part 2: Interaction framework, International Organization for Standardization, Geneva. ISO/IEC 19510 (2013): Information technology -- Object Management Group Business Process Model and Notation, International Organization for Standardization, Geneva. Jaunzens D., Warriner D., Garner U. & Waterman A. (2001): Applying facilities expertise in building design, Construction Research Communications Ltd. by permission of Building Research Establishment Ltd., London, UK Jensen, P. A. (2009) Design Integration of Facilities Management: A Challenge of Knowledge Transfer. Architectural, Engineering and Design Management, 5, pp. 124-135. Laine T., Forns-Samso F. & Kukkonen V. (2016): Visual support for multi-criteria decision making, Proc. ECPPM 2016, pp. 371-376, CRC Press, UK McArthur J., Herrera N. & Mantha P. (2014): International Sustainability Systems Comparison - Key Inter- national Sustainability Systems: Energy and Water Conservation Requirements, CoreNet Global by Ove Arup & Partners Ltd., March 2014. OmniClass (2017): OmniClass, a strategy for classifying the built environment, http://www.omniclass.org/ Pruvost H., Grille T. & Scherer R.J. (2016): An IT-based holistic methodology for analysing and managing building lifecycle risk, Proc. ECPPM 2016, pp. 377-386, CRC Press, UK Pruvost H., Katranuschkov P. & Scherer R.J. (2017): Multimodel-based exploration of the building design space and its uncertainty, Proc. Sustainable Places 2017, Middlesborough, UK Scherer R.J., Katranuschkov P. & Baumgärtel K. (2016): Open eeBIM Platform for Energy-Efficient Building Design, Proc. ECPPM 2016, pp. 387-395, CRC Press, UK Scherer R.J., Katranuschkov P. & Guruz (2015): Energy-Efficient BIM Lab, Proc. Lake Constance 5D Conference, pp. 391-405, Hochschule Konstanz, Germany

D10.400 Final Project Report Version 1.0 Page 76/80

Scherer, R. J. & Schapke, S.-E. A distributed multi-model-based management information system for simulation and decision making on construction projects. In: Advanced Engineering Informatics, 25 (2011), pp. 582-599. Elsevier, The Netherlands, 2011. Shao Y., Geyer P., Lang W. (2014): Integrating requirement analysis and multi-objective optimization for office building energy retrofit strategies, http://dx.doi.org/10.1016/j.enbuild.2014.07.030, Elsevier. Solibri Model Viewer version 9.6.21 [Online], https://www.solibri.com/products/solibri-model-viewer/ Todinov M. T. (2006): Risk-based reliability analysis and generic principles for risk reduction, Elsevier Science.

Related eeEmbedded Deliverables

Calleja-Rodríguez G. (2017): eeEmbedded Deliverable D2.5: New ways of holistic working for energy optimized and embedded building, 100 p., © eeEmbedded Consortium, Brussels. Dangl G., Linhard K. & Katranuschkov, P. (2016): eeEmbedded D8.2: Collaborative Methods, 62 p., © eeEmbedded Consortium, Brussels. Forns-Samso, F., Sukumar, A., Kroner, M., Geissler, M.-C., Calleja-Rodríguez, G., Kaiser, J., Pruvost, H., Grille, T. & Schär, R. (2015): eeEmbedded D3.2: Sustainability prognosis, quality and ROI methods, 100 p., eeEmbedded Consortium, Brussels. Geißler M.-C., Guruz R. & van Woudenberg W. (2014): eeEmbedded D1.2: Use case scenarios and requirements specification, 78 p., © eeEmbedded Consortium, Brussels. Gnüchtel S., Kaiser J., Pruvost H., Stenzel P. Grille, T. & Schär R. (2015): eeEmbedded D3.1: Stochastic, risk and vulnerability models and control strategies, 127 p., © eeEmbedded Consortium, Brussels. Guruz R., Calleja-Rodriguez G. & Geißler M.-C. (2015a): eeEmbedded D2.1 Holistic multi-disciplinary Key Point-based design framework, 85 p., © eeEmbedded Consortium, Brussels. Guruz R., Calleja-Rodríguez G. & Geißler M.-C. (2015b): eeEmbedded D2.1 Holistic KPI-based design methodology, 87 p., © eeEmbedded Consortium, Brussels. Kaiser J. & Stenzel P. (2015): eeEmbedded D4.2: Energy System Information Model - ESIM, © eeEmbedded Consortium, Brussels. Pruvost, H., Grille, T., Baumgärtel, K., Schülbe, R. & Kadolsky, M. (2017): eeEmbedded D6.5: Optimization of multi-model criteria, © eeEmbedded Consortium, Brussels. Sprenger W. & Poloczek S. (2017a): eeEmbedded D9.2: Validation Test Sites Model, 34 p., © eeEmbedded Consortium, Brussels. Sprenger W. & Poloczek S. (2017b): eeEmbedded D9.4: Validation and verification of the KPI design methodology, 60 p., © eeEmbedded Consortium, Brussels. Sukumar A., Tøn A., Linhard K., Mrazek E., Mosch M. & Katranuschkov P. (2015): eeEmbedded D8.1: SOA Platform Architecture, © eeEmbedded Consortium, Brussels. Zellner R. & Kaiser J. (2015): eeEmbedded D2.2: Templates for fast semi-automatic detailing, 48 p., © eeEmbedded Consortium, Brussels. Zellner R. & Mrazek E. (2017): eeEmbedded D7.4: Multi‐model navigation and visualization service, 54 p., © eeEmbedded Consortium, Brussels.

D10.400 Final Project Report Version 1.0 Page 77/80

Acronyms

AEC Architecture, Engineering and Construction API Application Programming Interface – a set of clearly defined methods of communication between various software components ARCH Architectural – Most often used to shorten descriptions, i.e. ARCH model ARIMA Autoregressive integrated moving average – a statistic model to better understand the data or to predict future points in the series BACS Building Automation and Control System BCF BIM Collaboration Format, a data standard to exchange communications about building models BIM Building Information Modelling/Model – describes either the method of BIM, i.e. the all- encompassing workflows and processes for a digital design process, or the BIM model, i.e. all the files that make up the complete building model BoQ Bill of Quantities BPMN Business Process Model and Notation – a graphical representation for specifying business processes in a business process model BREEAM Building Research Establishment Environmental Assessment Methodology – a method of assessing, rating, and certifying the sustainability of buildings CAD Computer-Aided Design CBA Cost Benefit Analysis CFD Computational Fluid Dynamics – a branch of fluid mechanics that uses numerical analysis and data structures to solve and analyse problems that involve fluid flows CSV Comma-Separated Values DGNB Deutsche Gesellschaft für Nachhaltiges Bauen e.V. – The German Sustainable Building Council was founded to promote sustainable and economically efficient building DV Decision Value – subcategory of the eeEmbedded Key Points, relates to aggregated values, which support and facilitate a decision eeE eeEmbedded – official shortcut acronym for the project eeBIM energy enhanced BIM – either describes BIM data that has been enriched with energy data or the general modelling method, which includes energy considerations eeeBIM energy efficient enhanced BIM – either describes BIM data that has been enriched with energy data or the general modelling method, which includes energy considerations ER Exchange Requirement – defines data, values and attributes that are required to be available or to fulfil certain criteria, so that exchange between two software tools or actors can happen without errors ESIM Energy System Information Model – the newly developed system model in eeE for the energy systems FM Facility Management HPC High Performance Computing – describes computer or in general computing above the average computing power of personal computers

D10.400 Final Project Report Version 1.0 Page 78/80

HVAC Heating, Ventilation and Air Conditioning ICT Information and Communications Technology ID Identifier – mostly refers to identifiers within software IDM Information Delivery Manual – refers to ISO 29481-1:2010, specifying a methodology and format for the development of an information delivery manual (IDM) IFC Industry Foundation Classes JSON JavaScript Object Notation – an open-standard file format KDP Key Design Parameter – one subcategory of Key Point in the eeEmbedded framework, generally describes mandatory design features for a building KP Key Point – main aspect of the eeEmbedded design methodology, comprehensible and aggregated indicators for a buildings performance KPA Key Point Analysis tool – a software tool developed by the eeEmbedded partner GRA, provides features to visualize the performance (KP) of a building KPI Key Performance Indicator – one subcategory of Key Point in the eeEmbedded framework, generally depicts performance values of a building that are not explicitly visible, i.e. simulation results KRI Key Risk Indicator – a subcategory of Key Point in the eeEmbedded framework, generally depicts uncertainties and risks and is used for the stochastically expression of building performance LCA Life Cycle Assessment – the domain and process to assess the life cycle of a building LCC Life Cycle Costing – closely tied to LCA above; calculates the costs corresponding to the life cycle(s) of a building LEED Leadership in Energy and Environmental Design – a standard for green building design LoD Level of Detail LOD Level of Development MEP Mechanical, Electrical and Plumbing – a domain of a building and the building design process MMC Multimodel Container MMNav Multimodel Navigator – a software tool developed by the partner NEM, main purpose is the visualisation and navigation of the eeEmbedded Multimodel MSM EDMmodelServerManager – the management component of the EDM server MTTF Mean Time To Failure MTTR Mean Time To Repair MVD Model View Definition – MVD are subsets (subformats) of a BIM model format and do allow for certain “views” upon a BIM model OVS Ontology Verification Service – a software component and service of the eeEmbedded platform developed by TUD-CIB, the OVS validates the BIM model with regard to data integrity as well as calculates and checks the Key Points for a building design OWL Web Ontology Language – a family of knowledge representation languages PD Percentage Dissatisfied – a term used for comfort analysis within a building PM Property Management

D10.400 Final Project Report Version 1.0 Page 79/80

PMV Predicted Mean Vote PPD Percentage of People Dissatisfied RDF Resource Description Framework – a semantic web data model ScM Scenario Manager – a software tool of the eeEmbedded platform, which is orchestrating and managing the overall design process and the data transfer SDK Software Development Kit SOA Service Oriented Architecture – a set of principles and methodologies for designing and developing software in the form of interoperable services SOAP Simple Object Access Protocol – a protocol specification for exchanging structured information in the implementation of web services in computer networks SQL Structured Query Language – a domain-specific language designed for managing data held in a relational database management system or for stream processing in a relational data stream management system SPARQL SPARQL Protocol and RDF Query Language – a RDF query language SPARUL declarative data manipulation language that is an extension to SPARQL; it provides the ability to insert, delete and update RDF data held within a triple store or quad store. SPFF STEP Physical File Format – see STEP SSP Server Side Plug-in STEP Standard for the Exchange of Product model data – The ISO 10303 family of standards for the computer-interpretable representation and exchange of product manufacturing information SWOT Strengths, Weaknesses, Opportunities and Threats analysis – a structured planning method that evaluates those four elements of an organization, project or business venture SysML Systems Modelling Language – a general-purpose modelling language for systems engineering applications TRNSYS Transient System Simulation – a simulation program primarily used in the fields of renewable energy engineering and building simulation, here it refers to the development of the Technische Universität Dresden TRY Test Reference Year UML Unified Modelling Language – a widely spread software modelling language WWR Window(-to-)Wall Ratio – describes the ration between walls and the windows in it, most often relates to the (outer) surface area of the wall and window respectivly XML Extensible Markup Language XPX EXPRESS-X – query and mapping language for EXPRESS models (ISO 10303-11)

D10.400 Final Project Report Version 1.0 Page 80/80

Partner Abbreviations

TUD-CIB Technische Universität Dresden – Institute of Construction Informatics, Germany (coordinator) TUD-IEC Technische Universität Dresden – Institute of Power Engineering, Germany BAM Koninklijke BAM Groep NV, The Netherlands BDE BAM Deutschland AG, BAM subsidiary in Germany BNL BAM Utiliteitsbouw b.v., BAM subsidiary in the Netherlands CEM Centro de Estudios Materiales y Control de Obras S.A. (CEMOSA), Spain DDS Data Design System ASA, Norway / Germany EAS Fraunhofer Gesellschaft zur Förderung der Angewandten Forschung e.V. – Institute for Integrated Circuits, Germany EPM Jotne EPM Technology AS, Norway GRA Granlund Oy, Finland IAB iabi – Institute for Applied Building Informatics, Germany NEM Nemetschek Allplan Slovensko S.R.O., Slovakia OPB OBERMEYER Planen + Beraten GmbH, Germany RIB RIB Information Technologies AG, Germany SAR Fr. SAUTER AG, Switzerland SOF SOFiSTiK Hellas AE, Greece STA STRABAG AG, Austria ZUE Ed. Züblin AG, STA subsidiary in Germany