An Assisted Workflow for the Early Design of Nearly Zero Emission Healthcare Buildings

Abstract

Energy efficiency in buildings is one of the main goals of many governmental policies due to their high impact on the carbon dioxide emissions in Europe. One of these targets is to reduce the energy consumption in healthcare buildings, which are known to be among the most energy-demanding building types. Although design decisions made at early design phases have a significant impact on the energy performance of the realized buildings, only a small portion of possible early designs is analyzed, which does not ensure an optimal building design. We propose an automated early design support workflow, accompanied by a set of tools, for achieving nearly zero emission healthcare buildings. It is intended to be used by decision makers during the early design phase. It starts with the user-defined brief and the design rules, which are the input for the Early Design Configurator (EDC). The EDC generates multiple design alternatives following an evolutionary algorithm while trying to satisfy user requirements and geometric constraints. The generated alternatives are then validated by means of an Early Design Validator (EDV), and then, early energy and cost assessments are made using two early assessment tools. A user-friendly dashboard is used to guide the user and to illustrate the workflow results, whereas the chosen alternative at the end of the workflow is considered as the starting point for the next design phases. Our proposal has been implemented using Building Information Models (BIM) and validated by means of a case study on a healthcare building and several real demonstrations from different countries in the context of the European project STREAMER.

1. Introduction

Energy efficiency in buildings is gaining more attention due to the high impact of buildings on the energy use and carbon dioxide (CO${}_2$) emissions [1,2]. As a result, nearly Zero Emission Buildings (nZEBs) are becoming a part of several countries’ legislation and policies due to the promising potential of nZEB to reduce the energy use and the share of renewable energy [3,4,5,6]. Healthcare facilities, being intensive energy consumers due to their special characteristics, are the focus of many studies due to their substantial fraction of the total energy consumed [7,8].

Generally speaking, an nZEB is an energy-efficient building that has a high energy performance [1]. Nearly zero energy buildings have gained much interest during recent years and are now regarded as real and integral solutions for energy savings [1,5]. Due to its ambiguity, many proposals have focused on the definition of a framework for defining nZEBs and to provide the metrics necessary to assess the building’s impact on the environment [3,9,10,11]. The different approaches were surveyed by Marszal et al. [5].

Decisions made at early design stages have a significant influence on the energy performance during the operating stage of a building [12,13,14]. Furthermore, the increasing number of requirements, stakeholders and regulations during the building design process are complicating the tasks of decision makers [15,16]; i.e., it is not easy to design a zero emission building that satisfies all of the constraints; additionally, many variables and parameters have to be analyzed to find an optimal trade-off between the user requirements and the nZEB constraints [5,17].

Designing buildings from scratch amounts to much work; i.e., the combination of parameters and variables to be considered may generate a vast amount of different designs, which can be assessed and compared side by side to identify the optimal design [17]. Furthermore, the lack of decision support systems at early stages is causing designers to hesitate in their search for optimal energy-efficient buildings [18]. Counting on automated processes and on recent technological advances shall help decision making towards devising nZEBs more easily [17,19,20].

We propose a workflow, supported by a collection of BIM-based tools [21,22], to assist decision making during the early design phases of healthcare buildings. Our proposal is intended to assist architects and designers, allowing them to consider informed decisions towards nZEBs. This framework considers the aspects that are available during the early design phase and that have an impact on the overall energy efficiency of the building [23], namely: its services, geometry, orientation and its building elements.

The proposed workflow, which makes use of the labeling system for healthcare buildings defined in [24,25], is accompanied by a set of tools. It is composed of the following steps: (i) briefing, where the user requirements are defined in a table-based sheet; (ii) design rules’ definition, where further user requirements are defined using a domain-specific language; (iii) design configuration, in which different design alternatives are automatically generated based on the user requirements and rules; (iv) model checking, in which user requirements and some rules of the building code are checked; (v) energy performance assessment, where an early energy performance estimation is calculated; and (vi) life cycle cost assessment, where early financial aspects of the building are calculated. Our proposal includes the use of a dashboard, where user-friendly results are shown, allowing the designers to easily make informed decisions during the early phases. The proposal is validated by means of a running example, which is described during the article. Furthermore, it is being validated in the context of the European project called STREAMER (http://www.streamer-project.eu/).

The need for such a workflow is illustrated by the findings of Kohler and Moffatt [26], which indicated that the early design phase is where decisions have the greatest impact, while the costs of such decision are much smaller than when these are made during later phases of the design or building phase. Furthermore, Bragança et al. [27] also indicated that the difficulty with making decisions in the early design phase is that data to base such decisions on often have a very low level of detail, if data are present at all. The workflow as proposed in this article aims to increase this amount of data available to base decisions on in the early design phase, as is illustrated by Figure 1, which has been created based on Kohler and Moffatt’s [26] and Bragança et al.’s [27] findings.

The rest of the article is organized as follows: Section 2 describes the methodology followed to prepare this article; Section 3 briefly reports on the closely-related proposals in the literature; Section 4 presents our proposal and describes the steps on which it relies; Section 5 reports on the validation of our proposal and on our experimental results; and finally, Section 6 concludes our work and our future work.

2. Methodology

The goal of our work is to create an aligned workflow for assisting the stakeholders in a building project during the early design phases. We have followed a methodology similar to the one used by Attia et al. [28]. The methodology started by collecting information on the current workflows and methodologies for designing healthcare buildings and on the aspects that are specific for such a kind of buildings. Then, we prepared the first version of the workflow, which was updated and polished based on the interviews with the architects and engineers involved in the design and building of healthcare buildings. Then, we compared our workflow with the most related approaches in the literature and checked that the important aspects and particularities of healthcare buildings were considered in our approach.

The validation of the workflow and the accompanying Information and Communication Technology (ICT) tools was first tested by means of synthetic tests to check its performance and to tune the tools for an optimized configuration. Then, the workflow and its tools were tested on real cases in the STREAMER project to evaluate if the workflow and its tools are aligned and support the early design process. In this article, we used a running example throughout the paper, which shows the input and output of each step of the workflow.

3. Related Work

Modeling nZEBs is a challenging research issue, which can be reflected in the increasing number of proposals and approaches in the literature focusing on this field. It requires the combination and optimization of many design aspects (energy, cost and comfort), which results in a time-consuming and computationally-expensive task. In the following, we summarize the most important approaches in the literature that provide: (i) methodologies and recommendations for achieving nZEBs; (ii) life cycle cost models for achieving economic efficient designs of nZEBs; (iii) tools that are intended to assist building designers for achieving high energy performance nZEBs; and (iv) models for achieving user comfort in nZEBs. In the first approaches, we briefly describe the difference between our proposal and existing methodologies, whereas for the others, the main difference resides in the holistic representation of our proposed workflow for nZEBs; i.e., very few publications focus on defining an approach that considers the different aspects (brief, rules, energy and cost) together during the early phases of the project.

3.1. Methodologies and Recommendations

The process for designing nZEBs differs from conventional building projects [29]. Few proposals in the literature provided methodologies and recommendations to achieve nZEBs [28,30], whereas many proposals have focused on designing nZEBs for a specific climate and on reporting on the methodology used and on the different alternatives recommended for this climate.

Attia et al. [28] identified, modeled and proposed an integrated design process for achieving high energy performance buildings. The authors focused on three main aspects, namely: the process phases, the user roles and responsibilities in the building, the tools that are used for this purpose and the metrics used to identify high energy performance buildings. This proposal reported on an ongoing work that had to be refined, validated and needed to be supported by software. However, our approach is more complete; i.e., the fact that we focus only on healthcare buildings, the accompanying software tools and the validation on the real demonstration sites provides a more complete and validated proposal.

A three-step methodology was proposed by Visa et al. [30] for transforming buildings with implemented renewable energy systems into nZEBs. These steps are as follows: (i) evaluate the current building status by studying the building parameters, site characteristics, implemented renewable systems and standardized indicators for renewable energy systems; (ii) identify tailored measures for reducing energy demand, such as changing the building envelop and equipment; and (iii) develop new on-site optimized renewable energy mixes and extending the existent ones, based on on-site technical and economic data. This proposal was later extended to a four-step method by the same authors [31], which are similar to the previous steps, but that include studying the current building demand and the evaluation of the energy produced by already implemented renewable energy systems. Compared to our proposal, both proposals are quite different since they are oriented towards the refurbishment of general buildings until achieving nZEBs, whereas our proposals focuses on defining a workflow for creating new nZEB healthcare buildings.

Since different nZEB solutions are needed for different climate zones, many researchers have also studied how nZEBs can be achieved in different climate zones and regions [32,33,34,35,36,37,38]. Such studies are intended to provide guidelines and optimal solutions that shall help designers, in the studied climate zones, to make decisions during their design process to achieve nZEBs. Compared to our proposal, each of these approaches is set on a single case study and a specific climate zone, whereas our workflow can be used for healthcare buildings, without a predetermined climate zone.

3.2. Cost

Many researchers have focused on providing economical assessment tools and frameworks for nZEBs by providing models and methodologies for providing cost-optimized models and economically-efficient designs for nZEBs [18,37,39,40,41].

Hamdy et al. [40] provided a so-called multi-aid optimization scheme, which aims at supporting robust cost-optimal decisions on energy-performance levels of buildings. Kapsalaki et al. [39] proposed a methodology, accompanied by a calculation platform, that is intended to identify the economically-efficient design solutions for residential nZEB design, considering the local climate, the energy resources and the economic conditions.

Ferrara et al. [41] provided a cost-optimal model for a single-family building typology in France. This model was created and calibrated using simulation tools and an optimization algorithm for minimizing the objective function and finding the cost-optimal building configuration. Kang [18] proposed a Life Cycle Cost (LCC) evaluation tool, including an optimization algorithm, for the early design phase. The authors intended to provide an idea about the economic benefits of the given nZEB during the early design phase and to guide the designer towards more effective design decisions, without spending much time and effort.

A more complete survey was performed by Sesana and Salvalai [42], in which the authors studied the different research approaches for performing the economic assessment of nZEBs.

3.3. Energy

Researchers have also worked on providing decision-support software tools for nZEBs that try to choose the nZEB alternative with the most optimized energy [17,43].

Attia et al. [17] proposed a so-called, ZEBO toolkit, which is a simulation-based design support tool that is intended to allow informed decision making for nZEBs during early design phases in Egypt. ZEBO allows users to test the energy performance of different building configurations by using EnergyPlus [44] as a simulation engine. The results of evaluating the different building design configurations are reported by means of energy performance graphs, which shall help the designer make informed decisions.

Lin and Gerber [43] proposed the so-called EEPFD (Evolutionary Energy Performance Feedback for Design), which is a framework that is intended to generate design alternatives, perform an energy evaluation of these alternatives, optimize them, choose the ones that have better energy performance and, finally, provide a trade-off study of all of the generated results for design decision makers.

3.4. Comfort

User satisfaction is also one of the main indicators for accepting a given nZEB design. Some researchers have studied the comfort parameters and provided some approaches and lists of factors to be addressed to improve user satisfaction in nZEBs [45,46,47].

Sartori et al. [45] briefly presented some comfort and energy performance recommendations and guidelines for nZEBs. Mlecnik et al. [46] studied the end-user satisfaction in nZEBs and provided some recommendations for the improvement of the quality and comfort of such buildings. Finally, Carlucci and Pagliano [47] proposed a modeling and optimization approach for designing comfort-optimized nZEBs.

4. Our Proposed Methodology

Our proposal goes beyond the approaches reported in the previous section by proposing an early design workflow, accompanied by a set of tools for early design decision support. The workflow allows using the advances in the Information and Communication Technology (ICT) field by creating and proposing different alternatives that match the initial requirements, validating these alternatives, performing energy calculations and estimating lifecycle costs. The workflow is accompanied by a set of tools that are prepared for working during the early design phases, which allows the designers to make informed decisions and not starting from scratch.

Figure 2 shows an overview of the proposed workflow and tools: (i) it starts from the user requirements (brief) and constraints; then, (ii) preliminary design alternatives are automatically generated; these alternatives are then (iii) checked to detect inconsistent designs and issues; then (iv) an energy assessment is then performed to check if the buildings comply with nZEBs; and finally, (v) a cost analysis is performed for the validated alternatives. When the current design does not fulfil the given rules or the designer’s expectation, the previous steps can be run again to create different designs. When it is not possible to find a solution that fulfills all of the given information, the initial steps should be repeated (dotted arrows). The resulting indicators are shown in a dashboard, and the designer can choose the design that best fits as an initial design for the next design steps. The whole proposal is developed using Building Information Models (BIM), which allow the interoperability among the tools.

In the following subsections, we first describe the running example, which will be used throughout the article to show the input and output of each step of our proposal. Then, we briefly describe the labeling system and the labels used, which is an essential step for the proposed workflow and tools. Later, we describe each of the steps in our workflow reported in Figure 2, namely: briefing, creating early design rules, creating early design alternatives, checking the early design, performing early energy calculation and performing early cost estimation. In each subsection, we provide a description of the step, the proposed tool and how the running example is processed.

4.1. Running Example

In order to show how our proposal works, we consider a hypothetical running example of a small, but representative healthcare building. This example will be considered throughout our proposal and detailed at each step of the proposed workflow, whereas the obtained results will be discussed in the validation section. Our proposal shall help us define the optimal building location, orientation, geometry, envelope, spaces distribution and layout, to fulfil the user requirements, and some of the existing regulations for healthcare. These building configurations shall be optimized for achieving the most energy- and financially-efficient healthcare building during the early design phase.

We assume that this healthcare building is intended to be built in Paris, France, and that this building is expected to be a two-story building, with a net and useful story area of approximately 1000 m${}^2$ (excluding the area of the constructed walls and the corridors). In the next section, for each step of our proposed workflow, we provide the input and the output for this running example.

4.2. Labeling

Choices made during the early design phase heavily influence the final energy performance of the building [12,14]. Unfortunately, early phases of a construction project generally have to deal with information on a high level of abstraction. It is not easy to perform energy calculations and cost estimation, during the early design phases, due to the fact that most of the commercially available energy calculation and simulation tools require a higher level of design details to perform these assessments, such as the building envelope material, Heating, Ventilation and Air Conditioning systems (HVAC) and lighting devices [17,48].

Defining semantic labels provides a strong theoretical basis for enriching space-related elements in the design and shall help to cope with the previous issues; i.e., defining semantic labels allows designers to assign additional properties and values to building elements. Using semantic labels during the whole project allows sharing the vocabulary, not only between stakeholders, but also among the tools and the existing projects [25]. Furthermore, semantic labels allow performing energy and cost assessment of the early designs based on the labels’ values and their associated properties. Please notice that creating semantic labels is largely based on the knowledge acquired from previous projects [49].

The labels used depend on the building type, whereas the label values and the information and knowledge linked to them are obtained from the knowledge acquired from previous projects; i.e., previous projects provide the value ranges and needs for the different properties against which early designs can be checked and compared. The same label may have different values depending on the space’s function.

Labels can be assigned at different levels, i.e., district level, building level, functional area level and space level [24,25], whereas assigning label values to spaces is not a simple task and needs experienced and specialized designers and a knowledge base containing the results from many previous projects [50]. The values for the different labels assigned to a given space allow calculating the energy demand at an early design phase and to perform an early cost estimation, without performing an in-depth analysis of the whole building and without performing complex simulations.

In our proposal, we use the healthcare labels defined in the STREAMER project [24,25,51]. STREAMER defines five types of labels, namely: access and security, comfort class, construction equipment, hygienic class and user profile. These labels and their value ranges are briefly described in

Table 1. Healthcare labels defined in the STREAMER project.

Streamer Label	Description	Values
Access and security	The access control level for a given space or area; example: who can access the given area	A1–A5
Comfort class	Level of comfort in a space; example: width of a corridor, story of a given space	CT1–CT8
Construction	Typology of the construction; example: story height and space width	C1–C6
Equipment	The electric power needed for a given area: office equipment or medical equipment	EQ1–EQ6
Hygienic class	The cleanliness level of a given area; example: sterilized operating theater or office	H1–H5
User profile	The period of the day during which a given area is used; example: all days from 8:00 a.m. to 14:00 p.m.	U1–U4

. The labels used can be extended by defining new labels and values, however, it is not advised to use a large set of labels to ensure their manageability [24]. An example of the label assignment is shown in

Table 2. An example of a hospital’s space labeling.

Space	Description	Assigned Labels
Operating theater	The space where operations take place	A1, CT3, C1, EQ1, H1, U2
Waiting space	The space where patients can wait to be attended to	A2, CT2, C1, EQ1, H1, U2
Medical archive	The space where medical archive files are stored	A5, CT5, C1, EQ4, H5, U3

.

At the implementation level, including labels when using BIM and sharing them among the different BIM tools are not issues due to the openness of the Industry Foundation Classes standard (IFC); i.e., it allows adding new properties to the building model by using property sets [52].

4.3. Briefing

Construction projects start with the planning stage, in which the clients have to examine their quantitative and qualitative wishes and needs and to translate them into a written document [53,54,55,56,57]. This process, which is iterative and takes place at the very early stages of the project, is called briefing. It involves different stakeholders from the project, including the client and the designers. Briefing is generally performed by means of face-to-face meetings, supported by collaborative ICT toolkits [54,58]. ICT has also found its way into briefing, and this can be noticed by the increasing number of software packages dedicated exclusively to construction projects’ briefing. An extended comparison of briefing tools can be found in [59].

The output of briefing is stored in a so-called brief, or Program of Requirements (PoR). A brief has the form of a report and is generally expressed as a fact sheet accompanied by some natural text and notes. Briefs use a dictionary including the terms to be used for defining the spaces and further concepts in the construction project. A high-quality brief is essential for the effective delivery of the project [54].

We propose to use the labels and their values in the briefing step; i.e., given the previous labels and their range of values, the clients, with the help of the building designers, shall use these terms and values to define their needs. In this step of the workflow, we focus on the quantitative requirements expressed in the brief by only analyzing the facts sheet defined using a Comma-Separated Values (CSV) file. The client is asked to express the natural text by using a domain-specific language, which is described in the following step of our workflow.

Table 3. Brief and assigned labels in our validation example.

Space Name	Space Type	Amount	Area	HC	AS	UP	EQ	CO	CC	Functional Area
Administration	Office	1	30	H2	A4	U2	EQ2	C1	CT3	Admission
Desk	Reception	1	12	H1	A1	U2	EQ2	C1	CT3	Admission
Patients records	StoreRoom	1	15	H1	A4	U3	EQ1	C1	CT1	Admission
Doctor’s office	Office	6	12	H2	A4	U2	EQ2	C1	CT3	LowCareWard
Meeting rooms	GroupRoom	3	35	H2	A2	U2	EQ2	C1	CT3	Admission
On-call staff room	OnCallStaffRoom	1	13	H2	A5	U4	EQ2	C1	CT4	LowCareWard
Waiting room	WaitingRoom	1	30	H1	A2	U2	EQ1	C1	CT2	Admission
Nursing station	NursingStation	3	20	H2	A5	U4	EQ2	C1	CT3	LowCareWard
Toilet Visitors	Toilet	10	6	H2	A2	U4	EQ1	C1	CT1	Admission
Toilet Patients	Toilet	10	6	H2	A2	U4	EQ1	C1	CT1	LowCareWard
Toilet (staff)	Toilet	10	6	H2	A2	U4	EQ1	C1	CT1	LowCareWard
Toilet (disabled)	ToiletDisabled	4	6	H2	A2	U4	EQ1	C1	CT1	LowCareWard
Patient room with one bed and bathroom	PatientRoom	10	18	H2	A2	U4	EQ3	C1	CT4	LowCareWard
Consultation room (anesthetic)	Consultation ExaminationRoom	5	18	H3	A2	U1	EQ4	C1	CT3	Outpatient Department
Operating theater	OperationTheatre	2	36	H1	A1	U2	EQ1	C1	CT3	Operating Theaters
Pharmacy	Pharmacy	3	12	H5	A5	U3	EQ4	C1	CT5	LowCareWard
Store room	StoreRoom	3	15	H1	A4	U3	EQ1	C1	CT1	Admission
Waste room	WasteRoom	1	14	H1	A5	U4	EQ1	C1	CT1	LowCareWard
Dirty linen room	StoreRoom	3	5	H1	A4	U3	EQ1	C1	CT1	LowCareWard
Medical Archive	Archives	1	25	H5	A5	U3	EQ4	C1	CT5	MedicalArchive
Total		79 spaces	1018 m${}^2$

HC: Hygienic Class; AS: Access Security; UP: User Profile; EQ: Equipment; CO: Construction; CC: Comfort Class.

shows the brief for the running example, including the number of spaces, their surfaces and their assigned labels. The planned healthcare building is expected to have a total of 79 spaces and a net area of 1018 m${}^2$. The space type column indicates the type of space, and its values are defined in the briefing dictionary. The amount column and the area define the quantity and surface for each space, whereas the columns HC (Hygienic Class), AS (Access Security) , UP (User Profile), EQ (Equipment), CO (Construction) and CC (Comfort Class) define the values of the labels used. The functional area column indicates to which functional area a space belongs, whereas its values are already defined in the briefing dictionary.

4.4. Early Design Rules

The next step in our proposed workflow is to complete the design brief by adding the requirements usually expressed in natural language. Unfortunately, processing natural language is still an open research problem, whereas none of the existing proposals is universal [60,61].

To cope with the issue of automatically processing texts expressed in natural language, a Domain-Specific Language (DSL) is used for defining the user requirements that cannot be expressed in the brief. DSLs are small high-level languages that focus on a particular aspect of a software system, tailored to specific tasks and intended to define a level of abstraction that helps end users be more effective in a specific domain [62,63]. They represent a more natural, high fidelity, robust and maintainable means of encoding a problem [64].

This DSL is intended to allow the users to express their requirements by means of rules that use enriched objects and relationships. The expressiveness of such rules in the Architecture, Engineering and Construction sector (AEC) is still an open research issue [65,66].

BIM provides a huge amount of objects and properties, which can be extended by user-defined properties [66]. Our DSL is based on the BIM objects and their properties and the labels used in the previous subsection, which enables users to handle a high detailed level of data and to express the quantitative and qualitative construction requirements in a user-friendly language. Furthermore, it supports the definition of different relationships between the spatial objects, which allows users define their requirements more easily.

Since the detailed description of our DSL falls beyond the scope of this paper, we only provide a brief description of the rules that focus on circulation paths, their properties and the spatial relationship between spaces. The DSL can be extended by new definitions and can be adapted to the new properties that are added to the new versions of BIM. A similar DSL, called BERA (Building Environment Rule and Analysis language), was provided by Lee et al. [66].

The rule editor contains a semantic analyzer that is responsible for converting the inputs text rules, which are processed by the lexical and syntactic analyzer, into XML (Extensible Markup Language [67]). ANTLR (Another Tool For Language Recognition) [68,69] was used to implement the DSL and to create the parser that converts the rules into a machine-readable file; i.e., rules written using our DSL are parsed, and an XML file is created. This XML file is used as input for the Early Design Configurator (EDC), which is described in the following subsection. The whole solution has been packaged under a so-called rule editor, which provides an editor to create the user rules and to create the XML file for the next step in the workflow.

Table 4. Example of rules implemented in the DSL.

Rules
priority = 9 Rule “Admission story rule”: Functional area with (name equals “Admission”) must be contained in the lowest story;
priority = 3 Rule “testing rule 14”: Functional area with (name equals “MedicalArchive”) must be contained in the highest story;
priority = 8 Rule “LowCareWard grouping rule”: functional area with (name equals “LowCareWard”) must be clustered horizontally and vertically;
priority = 5 Rule “Traveling distance between PatientRoom and NursingStation”: Traveling distance between space with (name equals “PatientRoom”) and space with (name equals “NursingStation”) is less than 20.0 m;
priority = 6 Rule “testing rule 17”: Space with (HygienicClass equals “H5”) must be clustered horizontally and vertically;

shows an example of a set of rules, which are defined for our running example. The first three rules in the table are more related to the functional area, whereas the last two are related to the healthcare spaces. As mentioned before, such rules allow defining spatial constraints and restrictions related to the layout of the spaces and the functional area. For instance, the first rule in the given table tries to fix the “admission” space in the lowest story. On the other hand, a priority has been also added to the DSL in order to be able to calculate a fitness function when a rule is not fulfilled in a given design. The priority value has a range between the value of zero, which is the lowest, to denote a recommended or an optional rule, and the value of nine, which is the highest and which denotes that the given rule should be strictly fulfilled by the current design.

4.5. Early Design Configurator: EDC

Attia et al. [15] showed in a recent study for how the use of evolutionary algorithm has allowed resolving highly constrained optimization problems for building design and how the use of such algorithms shall be required in the nZEB design process. However, the authors mentioned that integrating these algorithms in the design process is still a research issue. We propose to integrate the Early Design Configurator (EDC) in our process, which shall fill in the gap between the building designers and the building performance optimization algorithms [15,70]. The EDC is a software tool that is based on an evolutionary algorithm and that is intended to automatically generate design alternatives starting from the building requirements. The different alternatives can be exported into IFC format, which allows importing these from further tools as a starting point for the next design phases.

The EDC takes the previously-defined requirements as input data, namely: the brief with a tabular list of project-specific space specifications and their labels and the design rules. Then, the designer is asked to create the building geometry by using an editor that allows creating the outer shell of the building. The user can choose where the building shall be placed on a graphical map, which is rendered with tile data from OpenStreetMap (https://www.openstreetmap.org). This allows defining the building size, geometry, orientation and checking the different services (power plants, public transport) and the availability of spaces for installing renewable energy plants near the construction site.

At the core of the EDC lies an evolutionary algorithm, which is used to generate the layout alternatives. The current best layout is visually represented to the designer. An example of the different alternatives, created by the EDC, for our running example with different geometries and space distributions, is shown in Figure 3. The rectangles are the rooms inside the current story and building. The algorithm runs iteratively, where in each iteration, a room is randomly moved to a new position in the layout. If the resulting layout has a lower rating than the layout of the previous iteration, then the change is undone. The EDC works on several layouts in parallel, and the worst layout is regularly reset completely and restarted from scratch.

Each layout is rated by calculating a rating value with a fitness function, which gives a score, based on the constraints weight, on how close a given layout is to the optimal solution. The value itself is calculated from the sum of the output values from different constraints, which are either built-in functions or created from the imported design rules. In the case of constraints created from the design rules, the output value of a constraint is weighted by the priority of the design rule. Each constraint contributes to the fitness of the whole layout with a value between zero (best) and ∞ (worst), but in the default case, normalized values between zero and one are used. There are three types of constraints, namely:

• A hard constraint is a Boolean condition that can be true or false; i.e., the violation of such a constraint results in an unacceptable value, which may be either one or even a higher value for cases where a layout should be discarded since the constraint is violated. An examples of these kinds of constraints is:
  • Space A must be within 20 m of Space B.
• A soft constraint results in a value that gets increasingly worse the more the constraint is violated. This kind of constraint requires a border value to normalize the output value, which in most cases is the maximum value of the input value. In special cases, where the border value is not the maximum value, the satisfaction may be above one. Examples for soft constraints are:
  • Space A needs to be as close as possible to Space B
  • The walking distance between Space A and Space B must be as short as possible.
• A combined constraint combines both previous constraint calculation methods such that either a soft constraint is used inside the range of the border value or the result of the constraint is a bad value. Here are some examples cases:
  • Space A needs to be at least within 10 m of Space B.
  • There need to be at least five spaces of Type C within N meters from Space A.

Using weighted values according to the importance of the constraint allows defining design goals by preferring constraints that accommodate the goal.

The evolutionary algorithm is run until it is interrupted either by the user or by meeting the termination criteria (maximum number of iterations). The next step is to either manually edit the layout or to change the priorities of the constraints and then continue to run the optimization algorithm. This can be repeated until the designer considers that one of the created designs is a good solution. However, the designer is also able to choose to continue the development of a given layout in two different directions, by cloning the layout and working with the copy. The copy can again be manually edited or its design rule priorities can be changed again.

To forward the chosen alternative to the following steps in the early design workflow, the created model needs to be exported into an IFC file. An example of how such a file looks can be seen in Figure 4.

4.6. Early Design Validation: EDV

The increasing number of stakeholders that participate in the design and construction of a building project and the high number of changing requirements may increase the number of conflicts and may violate the requirements, constraints and the building code of the project [71,72]. It is essential to detect, as early as possible, inconsistencies and conflicts in the current design [73].

Eastman et al. [74] has recently provided a survey and a framework for comparing rule-checking systems. The authors proposed a structure for implementing a rule-checking and reporting system, in which the authors included the following four stages, namely: (i) rule interpretation where rules are structured for their application; (ii) building model preparation where the necessary information for checking is prepared; (iii) the rule execution stage where checking is carried out; and (iv) the reporting stage where the checking results are created and reported.

The next step of our workflow performs a design validation by checking that the current building designs fulfill the user requirements and the building code. Since the EDC may violate some of the rules, this step shows the designer which of the rules and requirements are not fulfilled and performs an early check to see if any of the building codes are violated. For this step, we propose an Early Design Validation tool (EDV), based on a reasoning rule engine, for validating the early design. Since code checking requires much more detail, we only include the building codes that can be verified at early phases of the building.

We have followed the stages proposed by Eastman et al. [74] for developing our system. In the following, we provide the modules in the EDV that implement these stages (cf. Figure 5).

The first stage is the rule interpretation, in which the Early Design Validator (EDV) reads the user-defined rules, written in different formats (tables and text) and converts them into machine-processable format. The EDV takes the brief (table-based format) and the design rules (XML format) and translates them into an object-oriented language that can be interpreted by the rule engine. Furthermore, we included a part of the building code for healthcare buildings (may changes between different countries) to check that the building fulfills the legislation. This stage is done by the rule importer module that creates the validation rules, which can be interpreted by the rule engine in the third stage.

The second stage works on preparing the building model for its checking [75]. During this stage, unknown design parameters are deduced from valid and known properties of the design objects in the model. This stage is essential since it allows inferring missing data and at the same time avoids inconsistencies [74]; i.e., it is possible to ask users to include all of the information for checking a given model, such as windows’ surfaces, but this would cause erroneous data in the model. Furthermore, at early design stages, the information in the model is limited, which makes this stage necessary. The model importer reads the building model in IFC, the enriching rules and the labels and tries to derive new information and to extend the existing building model with further information. To summarize, enriching rules calculate implicit properties such as volume and size, derive new models and relationships such as spatial and graph models and add information from the label definition to the spaces with assigned labels. At the end of this stage, an enriched building model, ready for validation, is created.

The third stage brings together the enriched building model with the validation rules that are applied to it. This stage is performed by an object-oriented rule engine [76], which is the core of the EDV. Since the rules have been created in a computable format and the model is already prepared, the rule execution is straightforward. However, only the rules with sufficient information available for their preconditions are run; i.e., the rule engine runs a rule when the existing information fulfills the rule’s preconditions.

The last stage reports on the validation results. The EDV reports on the building objects or conditions that did not pass the given rules, whereas the building objects that satisfy the validation rules are discarded from the final report. For reporting, we have chosen the Open BIM Collaboration Format (BCF) [77,78], proposed by BuildingSmart (http://buildingsmart.org/), which is an open file XML format that supports workflow communication in BIM processes. BCF allows reporting on the conflicting objects, addressing the conditions (rules) that are not fulfilled and adding a viewing camera at a given location describing the issue, which allows one to effectively communicate the detected issues to end users.

Table 5. An example of the healthcare code to be checked in the validation step.

Rules
The single patient room area is between 14 m${}^2$ and 18 m${}^2$.
The minimum width of doors is 1.10 m.
The minimum width of pathways is 1.40 m.
The distance between any point in the building and an emergency exit or a staircase is less than 40 m.

lists some of the rules extracted from the healthcare building code in France. For demonstration purposes, we have considered a list of similar rules, which have been then codified using the DSL proposed in the previous section. Please notice that we have only considered the rules that can be validated at the early design phase, with the limited level of details.

4.7. Early Simulation: TECT

Once the design has been validated, the next step in our workflow performs an energy performance assessment of the validated designs. Despite the importance of counting on an informative decision support tool during the early design, current design and decision support tools are inadequate to support and inform the design of nZEBs, especially during early design phases, where the level of detail is still very low [79].

To overcome the shortcomings of the existing tools, we have created an early design energy calculation tool, called TECT (TNO Energy Calculation Tool), to be used in this step. TECT allows calculating the energy demand and consumption of a given building in the early design phase. It takes as input a building design enriched with the defined labels, a configuration file containing default, but configurable values and climate conditions, following the EN ISO 16798-1 [80] standard. This standard defines how to establish and define the main parameters to be used as input for building energy calculation and short- and long-term evaluation of the indoor environment.

The energy calculations in TECT are based on the standards related to the Energy Performance of Buildings Directive 2010/31/EU (EPBD) [6] and using the harmonized ISO standards: EN ISO 52016-1 [81] and EN ISO 52010-1 [82], recommended by the European legislation. These calculations are performed at an hourly base and at space level. Its added value resides in its ability to provide an estimation of the energy consumption for a given building, counting on a very limited amount of information in its BIM model, applying European and standardized methods, and in integrating the results in the building IFC model, which allows its importation and viewing in further BIM tools. Figure 6 briefly describes the input and output of our simulation tool TECT.

The input for the energy calculation tool is a BIM model (in IFC), created by the EDC or another early design tool, with the necessary information at the space level. Besides using the geometric information, TECT is able to use the labels, such as ComfortClass, UserProfile and Equipment, for energy calculation. These labels are used to infer the missing semantic information that is necessary for energy calculations; i.e., based on the given labels to the building spaces, missing information in the early design model is added to the model, which allows performing the energy calculations. If the labels are not available in the input model, configurable default values are used. The default values used in the energy calculation tool can be changed in a configuration file and are then used for all of the spaces with missing labels. Figure 7 illustrates how labels can be assigned to the different spaces and integrated with the IFC file as the property set.

The building installations are characterized by an overall efficiency of the emission system, the distribution system and the generation system for heating and cooling. The characterization of the installations is defined in the IFC by a property set at the space level. For the characterization of the facade for spaces connected to the outside environment, the same approach is used. The property set contains an identifier for the selected system used for (i) generating heat; (ii) emitting heat; (iii) generating cold; (iv) emitting cold; (v) ventilating and the (vi) facade. For the efficiency of the distribution systems for heating and cooling, a default value (100%) is used. Each identified system represents one or more properties used as input to the calculation. The energy demand is the net amount of energy needed for heating and cooling of the space, whereas the energy consumption is the energy input to the heating and cooling generation system. In the early design phase, this is the minimum level of information needed to perform the energy calculations.

The results of the energy calculations are integrated into the BIM file (cf. Figure 8). To do so, a new property set is created where the following properties are available: Heat demand, cold demand, energy consumption by cooling system and energy consumption by the heating system (all values in MJ/year). Furthermore, the properties Max Power Heat Demand and Max Power Cold Demand in Megawatts (MW) are available in this property set. The needed power for heating and cooling of the spaces is not limited in the energy calculation tool; i.e., the temperature requirements (set points) are fulfilled by the system immediately. This way, no delay, undershoot or overshoots of the desired temperature will occur. In practice, however, there will be an offset caused by the dynamics and power limitations of the system. This can result in an overestimation of the needed power related to the power required in the detailed design.

Table 6. Energy calculations for both alternatives created by TECT.

Energy in MJ per Year	Design Alternative
	1 (MJ/Year)	2 (MJ/Year)	Alternative 1/Alternative 2
Heat demand	57,478.7	55,287.3	1.04
Cold demand	10,405.1	18,318.8	0.57
Energy consumption cooling system	12,241.3	21,551.5	1.04
Energy consumption heating system	63,865.3	61,430.3	0.57
Energy consumption system (heating and cooling)	76,106.6	82,981.8	1.08
Story area (m${}^2$)	1484.8	1373.3	1.04
Energy consumption (MJ/m${}^2$)	51.3	60.4	0.85

shows the simulation results for the two alternatives in our running example calculated by TECT. These values have been obtained based on the created designs from the EDC, the space assigned labels and using weather data from Paris, to perform the energy performance calculations.

4.8. Early LCC

Performing an economic analysis of a construction project is essential to evaluate the financial feasibility and performance of the project [42]. This is performed by assessing the Life Cycle Cost (LCC) of the current design. LCC is a commonly-deployed method for finding a cost-optimal design, where its results are critical for choosing one design or another; i.e., its analysis provides the investor with more realistic information about the investment and the return on investment by the current project [18].

LCC is a method of assessing all costs that are expected to take place, during the entire life of the building, aiming at providing an overview of the economic performance of a building over its entire life, as well as a year-by-year financial performance and balance. This includes costs of design, construction, operation, maintenance and the disposal of the building, to mention a few.

Our proposed workflow includes an LCC step in which the provided alternatives from the previous steps can be assessed economically. Since the design alternatives are compared among each other, the LCC-calculations are tailored towards this specific purpose: some factors of an LCC-calculation can be left out when the comparison is performed on a level playing field; i.e., the same method of LCC-calculation is used for all alternatives that are to be compared. An overview of the factors that are included and excluded is provided below.

We propose to use the following costs:

• Investment costs (also known as CAPEX): initial and capital costs. This is the amount of money that is initially invested and is capitalized on the financial balance.
• Operational costs (also known as OPEX): the costs in the operation and maintenance phase of the building, including: energy, water, cleaning, maintenance, security, general management and technical support. These costs are based on the ISO 15686-5:2008 [83].

The CAPEX (Capital Expenditure) and OPEX (Operational Expenditure) are standard components in accounting, and both are needed in order to be able to execute an LCC calculation. However, the following costs have been excluded in this LCC calculation step:

• Demolition and major renovation costs, since it is not easy to predict these costs in the early design phase, especially since they depend on other factors not related to the building itself.
• Financing costs (the financing of investments, for example interest on loans), since they vary per organization, country and economic climate.
• Revenue (the income the building generates), since it strongly depends on the way a healthcare building is exploited.
• Residual value (it is assumed that the building has no residual value at the end of its life).

To calculate the LCC for early designs, we propose the use of the Decision Support Tool (DST), which is based on BIM and allows performing LCC for different designs. DST supports three different methods for calculating the LCC, including the factors described before. These calculation methods depend on the Level Of Detail (LOD) and are explained below.

The LCC with the lowest LOD is calculated by combining data that can be derived from the BIMs generated by the EDC and ballpark cost figures. From the BIM, the gross story area of all spaces is multiplied with a cost figure per square meter to attain a first indication of the investment costs, while the operational costs are based on square meter data from practice based on empirical studies [84]. The empirical studies depend on the country, and default values are used in this method.

The second method allows using country-specific indices for both investment and operational costs to adjust the ballpark figures and make them suitable for usage in different countries’ contexts. Such a method allows having more realistic data for the country where the project is being planned.

The third LCC calculation method is more precise since it allows one to perform a calculation based on types or components instead of ballpark figures. The labels, described earlier, provide the foundation for such a system, where each label corresponds with both an investment and operational cost figure. However, such an approach requires counting on a large and complete dataset of cost figures, which cannot be easily acquired.

The DST allows the users to supply their own cost library to be used within the LCC-calculations, which makes it possible to use it in different construction projects and under different conditions.

Table 7. LCC calculation results for the running example.

Design Alternative	Investment Cost (Euros)	CAPEX (Euros)	OPEX (Euros)	Net Present Value (Euros)
Alternative 1	2,869,954	169,327	124,121	16,632,272
Alternative 2	2,997,190	176,834	129,624	17,369,646

shows the LCC calculation for the two design alternatives created by the EDC for our running example.

4.9. Dashboard

It is essential to count on a user-friendly tool for displaying assessment results [18,79]. A dashboard is a possible solution for showing these results. Such a dashboard allows one, in a user-friendly interface, to view and manage the information and design alternatives created during the proposed workflow, as well as to choose the design that best fits [85]. We propose to use a dashboard, which is part of the DST, to complete our workflow.

The dashboard is the platform where the previous steps and the data that have been generated within those steps come together and are reflected upon. Aligned with the purpose of the software tools discussed in this paper, the following definition is applied: a dashboard is a visual representation of the most important information captured on one single screen, which enables a person to understand the required information at a glance in order to control the information or to achieve other goals.

The key principle behind the dashboard is to present this increased amount of available data transformed into user-friendly information to thereby facilitate a comparison between design alternatives and decision making. This is done through a two-part process, which is described below:

• First, the BIM that is associated with each design alternative can be displayed in an integrated BIM viewer (cf. Figure 9). This BIM viewer is configured for the evaluation of the buildings generated by the EDC; i.e., it contains functionalities to visualize and filter spaces in the building according to the labels exported to the BIM by the EDC. These functionalities will help stakeholders to (functionally) evaluate the spaces and the relations between them for each design alternative.
• Secondly, the design alternatives with their generated data during the workflow are evaluated by the dashboard; i.e., the data that are generated during the proposed workflow are retrieved from the associated BIMs and are visualized in the dashboard through Key Performance Indicators (KPIs). A KPI is a method of transforming (multiple sources of) data and normalizing them to a uniform scale. This facilitates the weighting and aggregation of multiple sources of data and the easy visualization of such data to the user by rating a KPI from one to 10. These KPIs are displayed in the dashboard as gauges, as can be seen in Figure 10.

After the design proposals are evaluated in the dashboard, it is possible that a clear best solution (design alternative) has arisen from the assessment. In this case, the transition towards a detailed design can be made, where the chosen design alternative will be able to function as a blueprint, a foundation, to build upon.

However, it is also possible that none of the analyzed design alternatives comply with the wishes and requirements of the user. In this case, more design alternatives can be generated, but the fact that the requirements were not met could also lead to a more extensive re-evaluation of the choices made in previous steps; it could for example lead to changes in the brief or the application of different design rules. This illustrates that by using a dashboard, an active feedback mechanism is created in the proposed workflow.

5. Results Discussion

In order to test the validity and usability of the workflow and the tools, we took two measures: (i) we used a case study based on the running example as a hypothetical design project to discuss our proposal and the obtained results in this article, and (ii) we tested our proposal on four real demonstration cases within the STREAMER project.

For the running example, the EDC has generated many alternatives based on the brief and user-defined rules, of which we have only kept the ones with the highest fitness value. Then, the EDV has allowed us to discard further designs and to only keep two alternatives (cf. Figure 3) and to discard other ones generated.

The energy calculations of the two design alternatives at the building level are given in Figure 11, whereas the LCC results have been shown in the dashboard section (cf.

Table 8. KPI values for the running example.

Alternative	Energy KPI	LCC KPI
Alternative 1	7.7	5.0
Alternative 2	2.5	4.8

). Based on the results of the energy calculations (energy consumption per m${}^2$), it can be noticed that the early design Alternative 1 is more energy efficient ($15.2$%) than the early design Alternative 2. The total energy consumption of Alternative 1 is also $8.3$% lower than Alternative 2. This is mainly caused by the much higher energy demand end consumption (43%) for cooling. The results shown in Figure 11 are at the building level; however, this information is also available at the space level in the enriched IFC file, as previously shown in Figure 8.

Table 8 lists both the energy KPI (obtained by TECT) and the LCC KPI, calculated by the LCC module in the DST.

When analyzing the results of the LCC-calculation (cf. Table 7), we can conclude that the design Alternative 1 is also less expensive ($4.2$%) over its entire life cycle. This can be attributed to the more compact building layout with a smaller total story area, which is reflected in the lower investment costs and lower maintenance costs. Additionally, the superior energy performance of the design Alternative 1 is also a cause of the lower operational costs. However, the LCC difference between both design alternatives is relatively small when compared to the differences in energy performance.

The proposal has also been validated in the context of the European project STREAMER by means of four real demonstration sites in four different countries. The final results, which are currently being prepared, are promising, but have not been published, yet. However, an analysis of one of the demonstration sites and the validation scenarios has already been published [51,86].

6. Conclusions and Limitations

Much effort is being spent for achieving nZEBs, including healthcare buildings, which are being targeted due to their high energy consumption. Designing such buildings is still challenging due to their special conditions and to the increasing number of parameters to be considered to optimize the energy, cost and comfort. Furthermore, assessing early design decisions is essential for achieving optimal building designs due to the impact of the decisions made at early design stages on the final building performance.

We propose an early design workflow for healthcare buildings, accompanied by early design software tools, to guide designers towards optimizing different objectives and towards achieving energy- and cost-optimal early designs. Our proposal allows making informed early decisions and avoids starting new healthcare building designs from scratch.

The workflow starts with the building brief and rules, where user requirements and constraints are defined. Then, these requirements are used to create different design alternatives using an evolutionary algorithm, which tries to satisfy all of them. Code checking and design validation are then performed on the best alternatives, and only the ones that satisfy all of the rules are forwarded for the next steps. Then, energy and cost assessments are performed, and the obtained data are shown in the dashboard, which allows the designer to make informed decisions at the early design phases and to start the next design phases from an optimal design.

There are some limitations in our proposed workflow that need to be investigated in future work, namely: (i) adapting the workflow for different kinds of buildings, and not only healthcare buildings; (ii) the user comfort indicators are not being evaluated in this workflow, and this could be a step to be added just after the cost assessment and after analyzing the user comfort indicators; and finally; (iii) because of the freedom IFC offers, the open standard digital representation of a building that is used in this proposed workflow, all stakeholders in the workflow need to be aware of which information resides where in this building model. However, for the last limitation, this places an emphasis on coordination, which can be achieved by using Model View Definitions (MVD). MVDs can define which information, for each step of the workflow, is required to be present within the IFC file.