Towards a LCA Database for the Planning and Design of Zero-Emissions Neighborhoods

Abstract

The integration of science-based knowledge on greenhouse gas (GHG) emissions into practice-based neighborhood design and planning is key to inform and implement climate mitigation strategies. LCA is a method that is commonly used to provide objective and science-based information on the environmental impacts of specified systems or products. To use a LCA methodology at neighborhood scale is in turn dependent on the development of a common structure for life cycle inventory data. Such a LCA database does not operate on its own, but functions as a structured source of relevant high-quality data inputs linked to other different analytical tools. The aim of this study is to analyze the needs and requirements and provide a foundation for a LCA database at neighborhood scale that can provide users with an interface to find and access life cycle data in the users’ preferred format. The result of this study is the outline of the foundations of a user-centric LCA database for neighborhoods, including several sub-systems (buildings, infrastructure, mobility, and energy supply). Recommendations are given in the Conclusions Section to provide harmonized decision support on reducing GHG emissions at local levels in the planning and design of urban development projects at the neighborhood scale.

1. Introduction

Drastic changes in all aspects of society are required to keep global warming within the 1.5 degrees target and avoid the most dangerous effects of global warming [1]. The greenhouse gas (GHG) emissions related to the fossil energy use in the building and transport sectors account for considerable shares in the quantity of global GHG emissions, with a share of 28%, and 23%, respectively. An additional 10% can be reallocated from the other industry sectors to the buildings’ sector to account for building construction materials such as steel, cement, and glass [2]. Thus, addressing the nexus of buildings, mobility, and energy supply by assessing life-cycle emissions at the neighborhood scale is a tremendous step towards drawing holistic and powerful climate mitigation strategies.

The neighborhood scale is crucial to enable the transition towards a decarbonized society. Neighborhoods can be assessed with a focus on different elements, such as buildings or infrastructure components, as well as their interplay and overall function, such as how they are a part of the larger energy supply system. Neighborhoods must clearly also be understood from beyond a technological perspective, including the cultural, political, and business perspectives, with regards to user preferences, policy alignment, innovation opportunities, and new business models.

How science-based knowledge on GHG emissions can be integrated more effectively at local levels, such as developing neighborhoods by use of practice-based design and planning instruments and tools, is a key challenge. Life Cycle Assessment (LCA) is a method that is today commonly used to provide objective and science-based information on the environmental impacts of a specified system, with a specified function or set of functions, and is well-suited for this task.

The Norwegian Research Center on Zero Emission Neighborhoods (ZEN) in smart cities (FME ZEN) [3] addresses exactly these aspects by offering knowledge for designing, building, transforming, and managing sustainable neighborhoods towards net-zero GHG emissions. Solutions are also tested through living labs and pilot projects in the research center, documenting these through Key Performance Indicators (KPIs), see also

Table 1. Key Performance Indicators (KPIs): Brief description. Reproduced with permission from Wiik, Fjellheim et al. [4]. GHG = greenhouse gas.

KPI	Brief Description
GHG emissions	Expressed in kg of CO2-eq. Calculated according to the national standard NS 3720.
Energy	In physics, energy is the potential to perform work, or the amount of work performed over a period of time. Mathematically, energy is the integral of power/load over time. In relation to an energy system (e.g., electricity or heat), energy is the load on the grid over time and is measured in (kWh).
Power/load	In physics, power/load is the instantaneous rate at which work is performed. Mathematically, power/load is the time derivative of energy. In relation to an energy system (e.g., electricity or heat), power is the instantaneous load on the grid and is measured in (kW). It may also refer to the average value of energy in one hour and should then be measured in (kWh/h).
Mobility	Refers to inhabitants’ and other users’ transport patterns within, to, and from the neighborhood.
Economy	Considered using a life cycle costing (LCC) approach for buildings, energy, and other infrastructure within the neighborhood over the period of assessment of 60 years.
Spatial Qualities	Refers to spatial structure, land use patterns, the shape of buildings and public spaces, the process, the stakeholder dialogue, and the use of local knowledge in planning and design.
Innovation	Defined as new or improved products, services, processes, organizational forms, and business models that are utilized to gain value creation or be useful to society.

[4].

One of the KPIs assesses the climate mitigation performance of the pilot projects by means of the potential for life cycle GHG emission reductions, measured in kgCO₂-eq. A key requirement for this GHG emissions’ KPI is the development of a common LCA methodology, that in turn depends on the development of a common structure for life cycle inventory (LCI) data and a common database that can be used in multiple analytical tools for the planning and design of ZEN projects, hereafter called the “ZEN toolbox”.

The purpose of a LCA database of this kind is to serve the LCA needs of multiple stakeholders who require LCA-based information. A LCA database does not operate on its own. It must be seen in its context in terms of the other tools that will feed it and the overall data architecture [5]. It is therefore necessary to develop a user-centric database that can generate data for other tools in the ZEN toolbox [6]. This type of structure can, in turn, be used to calculate the KPI for GHG emissions for the ZEN pilot projects at all project phases [4].

The specific purpose of this paper is to analyze the needs and requirements and provide a foundation for the development of a user-oriented LCA database at neighborhood level that includes the following sub-elements: buildings, mobility, infrastructure, and energy. Two essential criteria for the database are that it should be: (a) able to provide users with an interface to find and access life cycle data (LCI datasets) delivered—where possible—in the users’ preferred format, and (b) structured according to the other tools that will feed it and vice versa as part of a larger ZEN toolbox. Important to note is that, whereas this LCA database currently under development is developed for a Norwegian context, the principles and structure are not intrinsic to Norway but are exportable to other contexts addressing the planning and design of neighborhoods with high environmental ambitions in a life cycle perspective.

An outline of this study is given in this paragraph. The FME ZEN definition of Zero Emission Neighborhoods is given in Section 2. The needs and requirements of the database are discussed in Section 3, Section 4 and Section 5, from a user perspective (Section 3), data structure and standardization (Section 4), and data management and documentation (Section 5). Section 6 addresses methodological aspects in the LCA that need to be further developed to meet the needs and requirements presented in Section 3, Section 4 and Section 5. These gaps include parametrization, scenario development, temporal aspects, and regionalization. Section 7 concludes with recommendations for meeting the user needs in the short- and long-term perspective.

2. Zero Emission Neighborhoods

2.1. Definition

In the last few years, the focus has shifted from the building scale to larger urban scales, and assessing the environmental impact at the neighborhood/district/block scale is a vital step towards sustainable cities [7].

In the FME ZEN Center, a ZEN is defined as [8]:

“A group of interconnected buildings with distributed energy resources such as solar energy systems, electric vehicles, charging stations and heating systems, located within a confined geographical area and with a well-defined physical boundary to the electric and thermal grids. The neighborhood is not seen as a self-contained entity but is connected to the surrounding mobility and energy infrastructure and will be optimized in relation to larger city and community structures”.

A ZEN should:

• Plan, design and operate buildings and associated infrastructure components towards net-zero life cycle GHG emissions;
• Become highly energy efficient and powered by a high share of new renewable energy in the neighborhood energy supply system;
• Manage energy flows (within and between buildings) and exchanges with the surrounding energy system in a smart and flexible way);
• Promote sustainable transport patterns and smart mobility systems;
• Plan, design, and operate with respect to economic sustainability, by minimizing total life cycle costs;
• Plan and locate amenities in the neighborhood to provide good spatial qualities and stimulate sustainable behavior.

Important to note is that whilst the ZEN definition is intrinsically scalable, it should always be adapted to its local spatial, economic, technical, environmental, governance, and social contexts.

2.2. Key Performance Indicators

The aspects included in the ZEN definition are reflected throughout the different project phases (strategic planning phases, implementation phases, and operational phases) in a set of seven KPIs; GHG emissions, Energy, Power/load, Mobility, Economy, Spatial qualities, and Innovation. The KPIs are described in Table 1, according to Wiik, Fjellheim et al. [4].

The system boundaries may vary according to the scope and data resolution required to understand the assessment criteria and the KPI being assessed.

2.3. Pilot Projects

The purpose of the LCA database is to enable the calculation of the carbon footprint of the pilot projects. These are real life pilot projects located in Norwegian municipalities, as shown on Figure 1, providing an opportunity to test solutions developed in real life [9]. The pilot projects, or “innovation hubs”, are varied in type and size, ranging from large urban re-developments to smaller rural communities. In total, the pilot projects encompass more than 1 million m² of building mass and will have more than 30,000 inhabitants.

3. LCA Database for the Planning and Design of Neighborhoods

3.1. User-Centric

For a database to deploy its full potential, it shall be developed with its users in mind. According to Freeman [10], a stakeholder can be defined as “any group or individual that can affect or be affected by the realization of an organization’s purpose”.

For the context of the FME ZEN Research Center, stakeholders have been mapped by Baer [6] with three main categories:, those who can affect the project, are affected by the project, and are interested in the project. For the LCA database, the primary stakeholders will be the users that need LCA-based information. These may be in any of the three categories of stakeholders, and the LCA needs can be either in form of primary inventory data or overall performance results. However, the users of a LCA database are not limited to LCA practitioners. They can be found in a broad range of disciplines such as architects, engineers, environmental consultants, contractors, property developers, manufacturers, building products/components, urban planners, municipalities, and politicians. Interesting to note is that an indirect approach to mapping stakeholders’ needs and requirements is to identify tools that can be used and linked to the LCA database. Most probably, a vast majority of the users will only have indirect needs for the LCA data in terms of LCA-based results.

3.2. Overall Data Management and Architecture

A key aspect of the LCA database is how science-based knowledge on GHG emissions can be integrated more effectively into practice-based neighborhood design and planning instruments and tools that are being developed as part of the ZEN toolbox.

An overview of the ZEN toolbox and its use for planning and design purposes is displayed in Figure 2. The ZEN toolbox (red box) consists of the tools needed to assess a given ZEN pilot project at different project phases (grey box) according to the ZEN definition and the KPIs (yellow box), described in Table 1, to assess and benchmark (green box) their performance in relation to KPI reference and limit/target values, before visualizing this performance (blue box) such as with help of augmented reality (AR), virtual reality (VR), and geographic information system (GIS) visualization tools.

The minimum requirements for the LCA database—as part of the ZEN toolbox—are to provide data for the tools that are used for calculating the GHG emission KPIs in accordance with agreed-upon standards such as EN15804 [11] and NS3720 [12]. The most basic direct LCA need will be a database with GHG factors for the materials and energy that enter and leave the pilot projects system boundary. A more advanced need will be a database that can be used to assess the variability, sensitivity, and uncertainty of the results, including methodological choices. An advanced database must support parameter analysis, scenario analysis, and sensitivity analysis.

Ahlers and Krogstie [5] have outlined a high-level architecture for ZEN data management where the LCA database would be part of the external and/or internal data. A key challenge is that the solutions developed should be future proof, which means that they should be viable for the full eight years of the ZEN center and beyond. This could require that a business model is developed for the LCA database during the operation of the FME ZEN Center.

Such a business model should be based on the following quality aspects [5]: data sources, pathway from core/raw data sources to the platform, quality and context of data, data model, ownership of data, openness of data, terms and conditions of data usage, limitations on availability (security and privacy issues), versioning information, and mapping of which other tools in the ZEN toolbox utilize what data, to what purpose and fitness for use. Developing the LCA database requirements must be coordinated between LCA experts and ICT experts, with input from other involved stakeholders.

3.3. Existing Tools and Database Structures

Existing LCA software are many: SimaPro, GaBi, openLCA, Umberto, Brightway2, to name a few. These are developed to address LCA questions in general, thus requiring a high level of LCA knowledge as well as software training. In addition to the general LCA tools, several tools for specific applications exist as well. These have typically been developed to provide advantages such as simplified data entry, reduced time use, conformance to specific standards, and tailormade inventory.

Examples of such tools that are tailored for building level assessments are One Click LCA [13], LCAbyg [14], and Byggsektorens Miljöberäkningsverktyg [15]. One Click LCA, developed in Finland, is commonly used in Norway in BREEAM-NOR projects and in Statsbygg projects. Statsbygg is the Norwegian government’s building commissioner, property manager, and developer. OneClickLCA is compatible with the Norwegian standard NS3720:2018 “Method for greenhouse gas calculations for buildings” [12]. LCAbyg is a Danish LCA tool for buildings developed by the BUILD institute at Aalborg university and the Danish Agency for Housing and Planning (BPST). Byggsektorens Miljöberäkningsverktyg is a Swedish LCA tool for buildings that has been developed by the Swedish Environmental Research Institute (IVL). The “ZEB tool” was developed by SINTEF and NTNU in Norway through the Research Center on Zero Emission Buildings (ZEB Center) [16]. The purpose of these tools is to calculate and analyze the carbon footprint of buildings from a life cycle perspective. Common for all is a database with environmental profiles for materials and processes, often from Environmental Product Declarations (EPD) or with data based on LCA databases, such as ecoinvent [17] or GaBi [18].

3.4. Current Approaches

A number of LCA and GHG studies have been performed within FME ZEN, in particular in connection with pilot projects. Lausselet, Borgnes et al. [19] and Lausselet, Ellingsen et al. [20] propose, based on the ZEN definition, a modular LCA model, based on the following subsystems: (1) buildings, (2) mobility, (3) infrastructure, and (4) energy systems. The ambition level undertaken in their studies is “ZEB-OM” [21]. “O” refers to all operational energy, equipment, and appliances (module B6), and “M” to the embodied emissions from the materials’ production (modules A1–A3) and replacement (modules B1-B4), in accordance with NS 3720:2018 [12]. NS3720 is the Norwegian equivalent of the European standard EN15804+A2 [11], but with an additional module B8 that accounts for mobility-related emissions during operations over 60 years of neighborhood service life.

Thus, the total life-cycle GHG emissions of the neighborhood is the sum of the GHG emissions stemming from the building materials E_B,M, building operation E_B,O, PV production E_PV, mobility materials E_M,M, mobility operation E_M,O, infrastructure materials E_I,M, and infrastructure operation E_I,O, as shown in Equation (1):

E_tot = E_B,M + E_B,O + E_PV + E_M,M + E_M,O + E_I,M + E_I,O

(1)

A sensitivity analysis was performed by varying the functional unit, scenarios for the development of the neighborhood, and scenarios for the development of the background electricity system.

Resch, Lausselet et al. [22] have developed a database tool for the buildings in ZEN with strong illustrating features. The results can be displayed per building element (outer walls, outer roof, and the photovoltaic system), per material category, per emissions factors, and lifetime factors.

In those studies, it is possible to have several levels of dynamic modeling, e.g., material use, and production technology. A dynamic material use allows the modeling of the inputs over time, induced by a need for replacements at the end of the service life of materials or components. A dynamic production technology enables the modeling of the evolution of the production technology over time. The LCA database should be able to support these two, dynamic modeling approaches.

Another tool called “Område LCA” (Område = neighborhood in Norwegian) has been developed by a consultancy company with high knowledge of LCA and further described in Yttersian, Fuglseth et al. [23].

This shows that there is a multitude of LCA tools used in the assessment of ZEN projects, and an increased awareness about assessments at an interconnected area-level. It is unlikely that one single tool will be able to meet the needs of all users. A LCA database must therefore be able to serve multiple tools with relevant data.

4. LCA Database Structure

A high-level outline of a database structure that can serve the needs of the various stakeholders is illustrated in Figure 3. Three main levels are defined: system (foreground), life-cycle stages, and background data.

At the system (foreground) level, the different neighborhood sub-systems (buildings, infrastructure, mobility, and energy supply) are defined.

At the life-cycle stages level, the life-cycle stages of the different sub-systems of the neighborhood are further defined, according to EN15804 [11] and NS3720 [12]: product stage (A1–A3), construction and installation stage (A4–A5), use stage (B1–B8), end-of-life stage (C1–C4), and benefits and loads beyond the system boundary (D). Please observe that the B8 module for emissions due to transport in operations is included in the NS3720 standard, as an extension to the EN15804 standard.

At the background data level, the processes that are used to construct and maintain the different neighborhood elements defined at the system (foreground) level are stored as system processes (EPD or NS3720:2018), or as unit processes with full value chain resolution (Ecoinvent). This serves as a library of products and processes that can be used for assessing the pilot projects. The data covered include contextual information such as location, year of construction, areas and volumes, typology, construction type, contractor, LCA practitioner, and so on.

Feedback from the system level to the background level will also be possible. This top-down approach is useful when developing average or generic data based on case studies. In addition, the possibility of querying not only unit processes or aggregated LCA results at building level, but also something in between, can be valuable.

The LCA results are stored outside the LCA database at all database levels. LCA results, quantities, and emission factors of building elements and material categories separated into life cycle stages can be valuable in early-phase applications, as well as for benchmarking and validation purposes.

4.1. Mapping

Data in the LCA database need to be exportable in a format that matches the data structure of the tools in the ZEN toolbox. This requires a mapping scheme, where processes in the tools are matched with the relevant processes in the LCA database. Mapping can, for example, be between two specific processes when selecting a specific product in the tool and the data matching it with an EPD in the database. Mapping can also be used to match a generic choice (e.g., “concrete”) with a representative average or generic process, including data on the average value of the selection and the variability of the results.

Mapping is closely related to what Edelen and Ingwersen [24] have called “fitness for purpose”, ensuring that relevant LCA data are applied. Mapping schemes must evolve over time and will have to be updated for each new version of the LCA database and each new version of the tools using the mapping scheme.

4.2. Operation and Database Management

To avoid that the data degrade or lose their relevance over time it is necessary to develop a business model for maintenance of the database. It is also necessary to develop routines for data harvesting, data validation, and quality assurance. Finally, the management of the LCA database must be seen in the context of the ZEN toolbox data management and monitoring architecture [5].

At its simplest, the LCA database provides data for the tools in the ZEN toolbox, in a one-way (unidirectional) relationship. However, when the goal is interoperability, a two-way (bidirectional) relationship is required. Interoperability allows for the use of the results from the ZEN toolbox to, for example, build a library of components in the LCA database.

5. Data Management

This section outlines the key challenges of the methodological aspects which have implications for the structure of the LCA database—in a ZEN context but also valid for other contexts—providing guidelines for data management (interoperability, data documentation, and data quality).

5.1. Interoperability

Interoperability, defined [25] as the “ability for systems to exchange information and to use the exchanged information” is at the core of any database.

The LCA database must provide interoperability intrinsically and towards the other tools in the ZEN toolbox. The output of the ZEN toolbox should subsequently be able to feed back into the LCA database to continually expand the database contents. Interoperability is also required at a background level (see Figure 3) between multiple LCI formats.

The LCA database should also be seen in context with other LCA database harmonization approaches, for example, the InData network [26], the EU’s Life Cycle Data Network and the International Reference Life Cycle Data System (ILCD) nodes, [27] and the GLAD network [28].

5.2. Data Documentation

Data documentation is of key importance for the correct use (current and future) of the database because it allows the users to validate their data choices, make sure they are representative of the system they model, and that any comparisons are based on consistent system boundaries and assumptions. The minimum requirements for every dataset/process in the database are presented in

Table 2. Minimum requirements for data documentation.

Data Requirements	Comments
Data generator	Name of person and/or affiliation collecting, compiling, or publishing the original data
Author	Name of person entering the data
Referencing source	Publication, measurement, estimate, personal communication etc.
Data treatment	If adjusted from data in referencing source
Date	Dataset entry
Comment	Any relevant information complementing the above that further explains the origin and/or interpretation of the datasets and its relevant use
Unique identifier	(UID/GUID)

.

Many existing LCA data formats could suit the needs of the ZEN LCA database. The most commonly formats used in Europe are Ecospold and ILCD, in addition to proprietary formats used in SimaPro and GaBi. Ecospold is the data format used by ecoinvent [17,28]. The ILCD data format has been developed by the European Commission’s Joint Research Center [29]. It has been used in the pilot studies on EU’s Product Environmental Footprint (PEF) [30]. There is a quantity of freely accessible LCI data available in the ILCD format, e.g., through the EU’s soda4LCA nodes in the PEF pilots. The ILCD+EPD format is an extension of the ILCD format that accommodates Environmental Product Declarations (EPDs), especially in the building industry and in accordance with the EN15804 standard [11]. This format has been developed in a cooperation between European EPD programs in an initiative called “InData”. EPD-Norway has launched an online database using this format [31]. The ILCD+EPD format shows the flexibility of the ILCD+EPD format, and how it can be extended and adapted to accommodate additional requirements. An example of this can be found in Sweden, where what is termed as “Q metadata” has been added [32,33]. This additional metadata concerns topics such as if the LCI data are for one product or a group of products, for example, if there are significant underlying assumptions.

Two approaches for selecting a data format can be highlighted. The first is based on identifying a database software that best meets the needs and requirements of the database. The second is based on identifying which format best meets the needs and requirements of the project that the database serves (ZEN toolbox, in that case).

For the first approach, several available software may fulfil the requirements, including SimaPro, GaBi or Soda4LCA. For the second approach, based on an assessment of the needs and requirements identified for the ZEN toolbox, the ILCD format appears as the best match in terms of content. This is a data format that is extensively used both by the EU and by EPD programs (e.g., through the InData network and in EPD-Norway’s digital EPD database digi.epd-norge.no). For both approaches, the LCA database will therefore need to be able to use data based on the ILCD format.

A challenge with the ILCD format is that it has many fields with metadata. For most of the LCI datasets this will be time consuming without necessarily providing additional value from a ZEN perspective. To populate the database in a timely manner, it should be possible to add preliminary data without filling in all fields, e.g., as a separate part of the database (clearly identified as incomplete data sets).

5.3. Data Quality

Data quality has significance for quantifying uncertainty and variability of the data sets and needs to be addressed in the database. Data quality has been classified as intrinsic and contextual [24,34]. Intrinsic data quality is an inherent data property describing the data quality, whereas contextual data quality is an aspect of the data that is situationally dependent.

A dataset that has good intrinsic data quality can, for example, describe a production process very well, but not be used as input in another dataset where the contextual quality is low i.e., contextually wrong in terms of technology representation, geographical location, temporal representation, etc. The database will primarily relate to intrinsic data quality, but as datasets will build on each other, it will also involve situationally dependent choices that are important for the contextual quality of the resulting datasets. Contextual quality is important for the database since it is intended to be used by different users with different levels of LCA competence and for a variety of purposes. It is therefore important that the database guides the user in the selection of appropriate datasets for different contexts and purposes.

The most used approach for evaluation and documentation of data quality are the pedigree matrix approach used in Ecoinvent [17] and the ILCD approach by the European Commission [30]. An updated pedigree matrix has been proposed by the EPA in the USA [35].

The pedigree approach assesses data quality through five quality indicators: reliability (how data have been generated and validated), completeness (value chain coverage), temporal correlation (age of data), geographical correlation (location), and technological correlation (relevance of industry/technology assumption). The quality indicators are evaluated with a score between 1 and 5 (1—verified data based on measurements and 5—undocumented estimate). An estimated geometric standard deviation for datapoints in the inventory dataset can be computed.

The ILCD Handbook [30] lists the following six components of data quality: Technological representativeness, Geographical representativeness, Temporal representativeness, Completeness, Precision, and Methodological appropriateness. An advantage of the pedigree approach is that it allows implementation of uncertainty evaluation in the inventories. This feature is not directly possible in the ILCD approach. Implementation of the data quality indicators as described in the ILCD Handbook results in an overall data quality rating for the dataset.

A third approach is the European Commission’s Product Environmental Footprint methodology that applies data quality indicators such as ILCD. As in ILCD, the overall quality of the dataset is evaluated rather than individual datapoints, and equal weight is assigned to the six data quality categories [36].

For the ZEN LCA database we recommend relying on the pedigree approach due to its implementation of data quality indicators directly in the inventories for each data point.

6. LCA Modelling: Methodological Aspects

6.1. Parametrization

Parametric models are useful for creating representative scenarios for transportation (capacity utilization, car fleet composition, etc.), building stock development over time, sensitivity analysis, probability analysis, algorithmic optimization, etc. [37,38,39,40,41,42]. Parametrization can be done at all levels of the database to link the different database elements, as shown in Figure 4.

An overview of the key processes that should be parametrized, based on experiences from the pilot projects are given in

Table A1. List of parameters for the neighborhood sub-element building.

Life Cycle Stage	Parameter	Unit
Buildings (A1–A3)	ServiceLife_Building	year
Buildings (B4)	ServiceLife_Bitumen	year
	ServiceLife_Ceramics	year
	ServiceLife_Cladding	year
	ServiceLife_Covering	year
	ServiceLife_Door	year
	ServiceLife_Flooring	year
	ServiceLife_Furniture	year
	ServiceLife_Glass	year
	ServiceLife_Insulation	year
	ServiceLife_Metals	year
	ServiceLife_Paint	year
	ServiceLife_Plastics	year
	ServiceLife_Sealing	year
	ServiceLife_Technical	year
	ServiceLife_Ventilation	year
	ServiceLife_Window	year
	ServiceLife_Wood	year
Buildings (B6)		kWh/(m2·year)
		kWh/(m2·year)

,

Table A2. List of parameters for the neighborhood sub-element mobility.

Life Cycle Stage	Parameter	Unit
Mobility (A1–A3, B4)	PassengerLoad_Car	person/car
	ServiceLife_Car	km
	TravelDistance_Share_Foot	[-]
	TravelDistance_Share_Bike	[-]
	TravelDistance_Share_Car	[-]
	TravelDistance_Share_Bus	[-]
	TravelDistance_Share_Train	[-]
	Car_Electric_Share_2022	[-]
	Car_Diesel_Share_2022	[-]
	Car_Petrol_Share_2022	[-]
	Car_Electric_Share_2030	[-]
	Car_Diesel_Share_2030	[-]
	Car_Petrol_Share_2030	[-]
	Car_Electric_Share_2050	[-]
	Car_Diesel_Share_2050	[-]
	Car_Petrol_Share_2050	[-]
Mobility (B8)	Car_Electric_ElUse	kWh/(km·car)

and

Table A3. List of parameters for the neighborhood sub-element energy.

Life Cycle Stage	Parameter	Unit
Energy (A1–A3, B4)	PV_InstalledCapacity	m2/residential unit
	PV_Efficiency	kWh/(m2·year)
	ServiceLife_PV	year
	ElHydro_Share_NO_2022	[-]
	ElWind_Share_NO_2022	[-]
	ElVarmekraft_Share_NO_2022	[-]
	ElHydro_Share_NO_2050	[-]
	ElWind_Share_NO_2050	[-]
	ElVarmekraft_Share_NO_2050	[-]
	ElHydro_Share_EU_2022	[-]
	ElWind_Share_EU_2022	[-]
	ElVarmekraft_Share_EU_2022	[-]
	ElVarmekraft_Coal_Share_EU_2022	[-]
	ElPV_Share_EU_2022	[-]
	ElGeo_Share_EU_2022	[-]
	ElNuclear_Share_EU_2022	[-]
	ElHydro_Share_EU_2050	[-]
	ElWind_Share_EU_2050	[-]
	ElVarmekraft_Share_EU_2050	[-]
	ElVarmekraft_Coal_Share_EU_2050	[-]
	ElPV_Share_EU_2050	[-]
	ElGeo_Share_EU_2050	[-]
	ElNuclear_Share_EU_2050	[-]
	ElVarmekraftCCS_Share_EU_2050	[-]

in Appendix A.

6.2. Scenarios Development

Scenario development can be seen in the context of parametrization by using parameters that facilitate scenario creation. Typical scenarios could address and predict potential pathways for the repair and maintenance of products or components, development of the mobility fleet over time, production technology, energy scenarios (use and decarbonization rate), the inclusion or exclusion of biogenic carbon, land use, and land use changes, etc.

The LCA database is not intended to be a scenario generating tool but should support such tools with the necessary LCI data. When examining the emission performance of a project over time, we recommend that scenarios are initially developed outside of the LCA database. The parameters and results of scenario analysis can then be entered into the database to provide additional data for subsequent studies.

6.3. Temporal Aspects

Combining building, mobility, and the local and connected energy system over a given time frame of 60 years—as done when assessing neighborhoods according to EN15804 and NS3720—is about combining different subsystems that evolve or change at very different rates [20]. The change rate of buildings is slow. Once built, the dynamic or internal rate can be assumed constant until the next renovation or refurbishment event takes place. On the other hand, vehicles have much shorter lifetimes than buildings, and hence, the change rate of a neighborhood’s vehicle fleet and its fuel- or material-related emissions are considerably higher and must be carefully accounted for in scenario analyses.

Temporal aspects can be relevant for many product systems but are typically not addressed in LCA databases [43]. Studies of temporal effects are commonly done outside of LCA databases. This is the case in a study by [44] where a conventional and a dynamic LCA was performed with climate change, human toxicity, and ecotoxicity as target impact categories to determine the sensitivity of the LCA results to temporal parameters. In Temporalis, a free and open source software package developed by Cardellini, Mutel et al. [45], dynamic LCIs are developed to account for environmental interventions at their time of occurrence. However, those approaches are still experimental and not yet operationalized into a readily usable tool. Several approaches to integrate energy scenarios in LCA are summarized in a review by Vandepaer and Gibon [46]. Studies on temporal aspects can also done in combination with other methods such as extended environmental input output assessment [47].

In a neighborhood context, salient temporal aspects include developments in the building stock over time. This type of temporality can be accounted for with the help of general algorithms and probably functions [40] and the use of segmented building stock [48]. Other temporal aspects that have to be accounted for in a neighborhood context include aspects related to carbon sequestration, biogenic carbon [49,50,51], carbonation, and energy systems [52].

The emissions related to the production of materials as well as emissions from their transportation can be expected to decrease in the future due to technological improvements in material technology, production technology, transportation technology, and the electrification of those processes together with decarbonization of the energy grid. The future emissions from material replacements can thus not be based solely on today’s emission factors for production and transport. The LCA database must thus facilitate the use of time series. When possible, unit processes should be modeled to facilitate the use of temporal resolution. A first approach would be to model unit processes for different years (e.g., concrete production in 2020, 2030, 2050) that would be stored as a reference flow.

We recommend that the LCA database is developed to support the inclusion of temporal aspects in LCA, for example, by providing relevant unit processes for scenario development. An iterative approach can be used, addressing the most significant processes first. A key challenge will be processes that are inherently not possible to adjust for temporal aspects, for example, static data from EPDs, where such aspects must be addressed through assumptions (e.g., estimate of x% improvement per year, or similar). One way to implement these technological developments is to introduce “technological factors”, as suggested by Lausselet and Brattebo [53] and Resch, Lausselet et al. [22] based on an assumed development in emission reductions’ intensity of overall material production emission and transport emissions’ intensity for each year in the study period.

In addition to those LCA specificities, the development of on-site renewable energy production and demand management on a building and/or neighborhood scale calls for a deeper understanding of the interaction between building operation and the electricity grid. We suggest a further and better integration of the KPIs Power/load and Energy into the LCA database, in the direction taken by Roux, Schalbart et al. [54] or Clauß, Stinner et al. [55] that use energy profiles with an hourly resolution. By doing so, the temporal variation in use, production, storage, and import/export of electricity could be better considered. To use seasonal averages such as those used by Kristjansdottir, Heeren et al. [56] can also be an alternative. In addition to those LCA specificities, energy storage alternatives and the development of on-site renewables should also be included in the database.

6.4. Spatial Aspects (Regionalization)

Regional aspects and resolution are relevant both for inventory precision and impact assessment. Inventory precision is related to technology representation and corresponding emissions’ intensities, such as energy/electricity mix, industry production technology, mobility mix (transport means and vehicle fleet composition), all of which are relevant in neighborhood assessments. Different approaches to regionalization and aggregation levels exist. The most common regionalization is to distinguish on national or continental levels, or to some extent between markets or subsets of larger countries, e.g., the electricity markets in the USA, as in the ecoinvent database. The extent of regionalization to provide location-specific input data or impact assessment depends on the resolution of the life-cycle impact assessment method.

New approaches are under development, using geospatial information and linking geographical grid data information with, for example, precipitation statistics to provide location-specific subsets [47,57,58]. However, in many cases the specific location of the production or activity is not known, either because the purpose is to provide average or generic data or because the study is in an early stage where the specific location of activities is not determined yet.

Regional differences are also relevant from the impact assessment perspective [45,59,60]. The effect of a given emission can vary depending on location due to differences in background contamination levels, and ecosystem vulnerability. There is a general need for harmonization of how regionalization is defined and implemented [45,61]. This includes aspects related to nomenclature and hierarchies, geography with mixed watersheds, biomes etc., formatting (both two- and three-letter used), consistency in region codes, and more.

In the case of the ZEN LCA database, we consider temporal resolution to be a more pressing demand than spatial resolution. Regional aspects could be included iteratively, prioritizing the data that are most significant for the context of the database.

7. Conclusions and Recommendations for the Next Steps

This study outlines the foundations of a user-centric LCA database for neighborhoods including several sub-systems (buildings, infrastructure, mobility, and energy supply). The database does not operate on its own as it is part of a wider context, the ZEN toolbox. The following recommendations for the next steps are given as conclusive remarks:

• A key requirement for the database is that it must be able to provide users with timely and relevant LCA data in the context of the ZEN toolbox, the need of the pilot projects, and involved stakeholders;
• The minimum requirement is to provide the ZEN toolbox with the data that are required for calculating the GHG emission KPI in all project phases, and in accordance with agreed-upon standards;
• Additional requirements depend on the specific tools that are connected to the database, and their needs and requirements;
• Developing the LCA database requirements must be seen in relation with the ZEN toolbox and must be coordinated between LCA experts and ICT experts, with input from the stakeholders. This to ensure interoperability, consistency, harmonization between projects over time, and provision of relevant and timely LCA data to the users;
• The database is currently under development with its content being extended over time. In the initial stages, the focus is set on the parametrization, temporal aspects, regionality and scenario development, and coordination with the pilot projects to consider their data needs and requirements;
• A data management plan and business model are also developed to secure efficient operation of the database today and over time, and to ensure the operation of the LCA database in a broader perspective.

The recommendations above are specifically aimed at Zero Emission Neighborhoods, but they are also relevant and applicable for planning and design of neighborhoods with other types of environmental ambitions in a life cycle perspective. Key success factors are mapping the needs and requirements of users, connecting the database to the tools used by the stakeholders, to populate the database, to be able to adapt to methodological improvements over time, and to have a well-founded data management plan and business model.