Futura: A new tool for transparent and shareable scenario analysis in prospective life cycle assessment

While it may be impossible to accurately predict what the world will look like in the future, we can be certain that it will be different from the world of today. By extension, we know that using today's data in life cycle assessment (LCA) studies claiming to represent future scenarios is problematic. For the future impact of products to be estimated in a consistent and meaningful manner in LCA, the background system, most commonly the ecoinvent database, needs to be projected into the future alongside the foreground system modeled in a given study. Futura is a new piece of open‐source software which allows LCA practitioners to create and share novel background databases representing arbitrary scenarios. It allows users to import a base database and then start making targeted changes. These changes take three main forms—adding new technologies, regionalizing new or existing technologies, and altering market compositions. All changes made are automatically added to a "recipe." This recipe file can be shared publicly. This recipe can be imported by other users and used to exactly recreate the modified database. The additive and transparent nature of this system means that initially simple scenarios can be built upon by others to progress toward more comprehensive scenarios in a stepwise manner. The inability to build on the work of others is a serious barrier to the progress of the LCA field. Futura goes some way to reduce this barrier in the field of prospective LCA.

industrial economy which provides life cycle inventory (LCI) data for all of the external inputs to the foreground model from the technosphere 1 .
Typically this includes inputs of electricity and fuels, raw material inputs, and process chemicals. The background system of a given model will consist of data from one or more LCI databases. The most widely used of these is the ecoinvent database (Wernet et al., 2016), however a wide range of other databases are available, including those broad in scope (e.g., Sphera (Sphera, 2020), EU LCDN (European Commission, 2020)) and specific to industrial sectors (AgriFootprint (Durlinger et al., 2014), World Food Life Cycle Database (Quantis, 2020)). These background databases provide a snapshot of global production systems representative of a time period close to the present day. This is an important, but often overlooked limitation, particularly in the field of prospective (or ex ante) LCA (Bergerson et al., 2020). Changes to the background system may manifest themselves as big changes to important processes, such as major switches in electricity generation technologies, or as small changes to a wide range of different processes, such as gradual efficiency improvements across all sectors. Given the higly interconnected nature of LCA models, both of these mechanisms have the potential to have significant effects on the outcomes of LCA studies.
Generating and assessing alternative scenarios within the foreground model is a relatively trivial task. Consistently applying these same scenarios to the entirety of the background system is, however, much more challenging. Nevertheless, it is vitally important for the results of prosepective LCA analyses to be meaningful. To return to the iceberg analogy, when the visible part of the iceberg moves it does not leave the submerged part behind, it moves as one coherent unit. The same should be the case with LCA models.
Overlooking background system changes in forward looking assessments means that the effects of external system changes cannot be taken into account when drawing conclusions (Ambrose & Kendall, 2020). This implicitly favors processes, technologies, and scenarios more closely associated with the status quo, at the expense of more transformative and ambitious alternatives. For example, Beltran et al. (2020) show that in some impact categories, including particulate matter formation, electric vehicles currently have a higher life cycle environmental impact per vehicle km than internal combustion engine vehicles, but outperform internal combustion engine vehicles under ambitious mitigation scenarios for the background energy system.
There are two major problems associated with enabling the coherent and consistent projection of background models into the future. The first is that it is difficult to make systematic changes to LCA background databases. The sheer number of datasets they contain, the degree to which these datasets are interlinked, and the complex structure of the networks which emerge from these links means that making broad scale edits to these databases is not a trivial task. The second is that if you do manage to overcome this first problem, the proprietary nature of many LCI databases mean that it can be impossible to share the updated background system with other practitioners. The approach set out in this paper aims to tacke both of these problems. A simple foreground model will consist of somewhere between one and a handful of connected unit processes, meaning manual changes to reflect new assumptions is a practical option. The current version of the ecoinvent database (version 3.6 cut-off system model) on the other hand consists of over 18,000 individual interlinked processes (ecoinvent database, 2020). Altering assumptions surrounding, for example, energy systems, new technology adoption, trade patterns has the potential to impact each and every one of these processes. Manually updating these datasets is not a feasible option, however programatically applying such changes is an option. Gibon et al. (2015) implemented a matrix multiplication approach for ecoinvent 2.2 (THEMIS), directly altering the technosphere matrix derived from the preallocated datasets. More recently, a suite of open-source, Python-based tools, building on the Brightway2 advanced LCA platform (Mutel, 2017), have been (and continue to be) developed which allow the datasets themselves to be targeted. Primary among these are wurst (Beltran et al., 2020;Vandepaer & Gibon, 2018) and Ocelot (Ocelot Project, 2017). These powerful tools allow database wide changes to be made to LCA background systems, and have opened the door to the future development of prospective LCA. For example, the package rmnd-lca 2 utilizes the functionality of wurst to automatically apply energy scenarios from the REMIND integrated assessment model to the ecoinvent database. They are limited in their broader application however by a requirement to be able to code in Python. For those lucky few in the center of the Venn diagram encompassing LCA practitioners and Python coders, they provide an excellent platform for the development of advanced LCA models. For the broader LCA community a simplified, user-friendly approach is required.
A standardized and extensible approach may also be a productivity boon to those who are currently capable of developing such models. A consistent background system, or at the very least a consistent way to refer to shared elements of a background system, is vital for interoperability and reproducability in LCA (Kuczenski et al., 2019). Giving LCA practitioners the ability to make arbitrary database wide changes to background datasets has the potential to break this consistency. In a worst-case scenario this could lead to the spawning of multiple divergent versions of resources which are already hard to uniquely identify, and make reproducing any given study increasingly difficult. The simplest solution for this would be for practitioners to provide their background datasets alongside their foreground model to allow other members of the LCA community to exactly replicate their calculations. This is not possible for practical and licensing reasons-you cannot simply make a large proprietory database available to anyone who wishes to replicate your study. An alternative approach to sharing altered background databases is required.

F I G U R E 1 Sharing altered background databases using Futura recipes
In this paper we introduce Futura, a potential solution to the two problems outlined above, namely the lack of a user-friendly and broadly applicable way to systematically alter background LCI databases; and the lack of a transparent and reproducible way to share these altered background databases.

FUTURA
Futura is a piece of freely available open-source research software. It is written in Python but includes an intuitive graphical user interface allowing LCA practitioners with no knowledge of Python to use it effectively. This is supported by a scripting interface allowing Python proficient practitioners to integrate it with other Python-based LCA packages, including Brightway2 (Mutel, 2017), the Activity Browser (Steubing et al., 2020) and lcopt (Joyce, 2017). It is also plugin ready, allowing anyone in the LCA community who wants to add specific features to Futura to create and release their own plugin without it having to be incorporated into the main codebase. The codebase itself is open source and hosted on github 3 . Members of the LCA community are invited to contribute to its continuing development, via suggestions, discussions, or the direct contribution of code.

Approach
The underlying approach to Futura is based on the concept of recipes. In the culinary world, thousands of cookbooks and websites exist on the basis that given a well-defined and unambiguous list of ingredients and a set of explicit instructions, it is possible to share food in time and space with no physical interaction or passing of materials between the creator of the original dish and the person who wants to eat it. While this is perhaps an overly complex way to describe something as simple as a recipe, it echoes the problem of sharing LCA background datasets outlined above. Here there is not necessarily a temporal or physical barrier to sharing the fruits of your labors when generating an altered background system, rather a legal barrier in relation to licensing agreements.
If an LCA practitioner starts with a certain set of background datasets (ingredients) and applies a well-defined set of transformations to them (method) the resulting background database will be the same every time. It is only the ingredients in this analogy which are held under license. The method can be freely shared. Provided a second LCA practitioner has the ingredients required by the recipe available to them, and is able to follow the method correctly, the result will be an altered background database identical to the one created by the first practitioner ( Figure 1).
The second practitioner in this scenario may decide to build upon the changes made by the first to generate a more specific scenario they require.
They are then able to share the amended recipe to allow a third practitioner to generate the background datasets for this scenario, and thus benefit from the efforts of the first and second practitioner. In this way scenarios can be cumulatively refined by the LCA community rather than every LCA practitioner starting from scratch, as is the case currently.
Futura provides a platform for writing and implementing these recipes. For each step in the workflow described in Section 2.3, an entry is automatically generated in the recipe telling Futura how to reproduce this action. Once the user is happy with the changes they have made, the recipe can be exported as a text file. This recipe file can be opened in Futura and run to automatically reproduce the original outputs.

Foundations
Full technical documentation and a user manual for Futura are available online (https://futura.readthedocs.io/). A brief, high-level overview of the foundations and the functionality is provided here.
Futura takes advantage of the growing library of open-source, Python-based tools available for LCA. In particular. it utilizes functions from the wurst library (Beltran et al., 2020) and integrates with the Brightway2 framework (Mutel, 2017).
In the absence of a single unambiguous system for referencing LCI datasets (as advocated by Kuczenski et al. (2019), Futura uses the filtering method implemented in wurst. Under this approach, single datasets or groups of datasets are identified by a filtering term based on combination of their attributes. Within the Futura user interface, datasets can be filtered using their name, location, unit, reference product, database, or identifier code 4 . For example, a filter asking for datasets in the ecoinvent 3.6 database (Wernet et al., 2016) where the name starts with "market," the reference product is "electricity, medium voltage" and the unit is "kWh" would return all markets and market groups for medium voltage electricity.
Adding a location attribute to the same filter would narrow the number of datasets returned. For example, adding a constraint that the location must contain "US" would return all of the subgrid datasets for the United States. Similarly adding a constraint that the location is equal to "DE" would return the specific dataset representing the market for medium voltage electricity in Germany.
Whenever a filter is used in Futura it generates a human readable text description of the filter which is added to the recipe. In reverse, whenever a filter description is given to Futura via a recipe, it generates the necessary code to implement the filter and find the required dataset(s). Using filters rather than unique identifying codes allows recipes to be flexible and future proofed against minor changes to LCI datasets. For example, the filters described above for ecoinvent 3.6 will work for ecoinvent 3.5, and will in all likelihood work for ecoinvent 3.7 when it is released, even if the internal identifying codes for these processes change, or if new datasets which fit the filter are added. It also allows a user to add their own technologies to the database they are creating in such a way that they are either deliberately picked up by a given filter, or deliberately excluded from a given filter, depending on their use case.

Workflow
The basic Futura workflow for creating an updated background system can be broken down into three main steps: setup, implementation, and export. The setup step includes defining your scenario, and then identifying the specific changes you want to make as a result. The implementation step is where you select your base database(s) and implement your changes within Futura. Finally the export step is where you export your database for use in your study and export your recipe file to share with others.

Setup
The setup step takes place outside Futura. Your scenario can be anything you like, from simple to complex and from realistic to entirely imagined. For example, for a specific sensitivity analysis you may develop a scenario where coal combustion for electricity generation has been banned in Europe.
Alternatively, you may be conducting a forecasting study for 2050 and create a scenario using International Energy Agency (IEA) projections for all grid mixes worldwide. You may even decide to explore what would happen if China no longer traded with the United States. The choice of scenario is only limited by the ability to translate it into concrete changes which could be applied to an LCI database, thus specific and well-defined scenarios are preferable.
The next stage is to plan out what changes your scenario implies for the datasets in question. For example, in the first example above, inputs of electricity generated from coal to markets for electricity in Europe either need to be removed or replaced. Planning and documenting the specific changes which are needed to achieve the specified scenario makes it easier to implement them in Futura, and easier to describe when publishing the results or sharing the recipe file.

Implementation
When beginning from scratch, the first part of the implementation step is to choose your base database or databases. The Futura GUI integrates directly with the ecoinvent.org website (via the eidl package 5 ) to download and extract the correct version and system model of the ecoinvent database. The cut-off system model is used in the examples in this paper, however the allocation at the point of substitution (apos) and consequential system models can also be used. Users are simply prompted for their username and password. Other databases can be added from Brightway2, or as a BW2Package file.
At this stage you are also prompted to enter a description of the scenario you are modeling and the edits you are making. This description will be stored within the recipe file. This provides a useful place to transparently document changes which will be described in the recipe file, and comment on the data sources and assumptions used in the preparation of the altered database.
Alternatively, it is possible to open an existing recipe file and add additional changes to an already altered database. In this case the recipe file should be placed in a folder alongside any supporting files (e.g., technology files or database files) and selected using the "Open recipe" function.
Futura will load and run the recipe. The background system can then be further augmented using the functions described below. "Work in progress" Futura workspaces can also be saved and reloaded, although the files created will be larger and will contain licensed information.
Once the workspace has been created or loaded, the changes outlined in the setup step can be applied. Futura provides three basic functions to achieve this, described below: adding technologies, regionalizing datasets, and altering markets.
The first function allows LCI data describing new technologies to be added to the background database. This allows specific technologies for which no data currently exist or are available to be added into the background database and linked into existing markets. The aim of this function is to allow potentially transformational technologies that could become commonplace in a theoretical, more sustainable future and that could have an effect on a significant number of other, linked processes, to be included in future scenarios. Examples include electricity generation utilizing carbon capture and storage (CCS) (Volkart et al., 2013), steel production using hydrogen instead of carbon as a reducing agent (Vogl et al., 2018), or construction materials derived from waste valorization (Joyce et al., 2018).
Currently, this LCI data should be in the form of the Excel file format for importing datasets into Brightway2 6 . This additional file should be provided alongside the recipe if it is to be shared.
For new technologies which have been added to a database to affect other processes, they need to be linked to them. Futura utilizes geographybased linking algorithms to create the correct links between processes, based on the constructive geometries 7 and wurst libraries. In brief, each process in the database has a location attribute. When linking processes, for each input from the technosphere Futura will search for processes providing the product required, beginning with the same location then expanding the geographical scope until it finds a suitable process, finally defaulting to a "Rest-of-World" (RoW) or global (GLO) process where no more specific data is available. For example, a process taking place in Germany and requiring natural gas would first search for a provider of natural gas in Germany, then Europe, then the world.
The ability to automatically make links to local markets for inputs allows new technologies to be defined at a global level, and subsequently regionalized within Futura, using its regionalization function. For example, if we assume that a novel manufacturing process will be similar in all geographies, a single, global LCI dataset can be added to Futura and regionalized to create market specific versions for any country where it is implemented. These new processes would utilize specific local sources of electricity, materials, and all other inputs, where available, defaulting to broader markets where local sources do not exist.
This function can be used for both for processes added in a previous step, or for processes found in the base database. This means that for studies in geographies where data coverage in LCI databases is poor, a "read-across" approach can be taken to borrow processes from areas where data coverage is greater (e.g., Europe) and create regional versions with the same input values, but with local materials and grid mixes, utilizing wurst's linking algorithms.
The third major function of Futura is the ability to alter market mixes. This is both an important step in integrating new, regionalized technologies into the wider database, and for altering existing technology mixes, for example, electricity grid mixes. Inputs to market processes in Futura are allocated on the basis of production volume. Futura provides tools to alter these production volumes, either to known values (e.g., setting the production volume of electricity by different fuels and technologies based on projected IEA figures), or by transferring production volume between technologies either by a given value or by a percentage.
The complexity of the implementation step will depend on the scenario being modeled and may require all or just a selection of the available functions. Figure 2 shows three sample implementation workflows of differing complexity. In scenario 1, simply altering a single market will achieve the stated goal. In scenario 2, an existing process within the ecoinvent database must be regionalized, before the market can be altered in a similar fashion to scenario 1. In scenario 3, a new technology must be added, then the same process as in scenario 2 is used. More involved scenario implementation exercises will require several iterations of these steps, but the underlying process will be similar.

F I G U R E 2 Example implementation workflows for three different scenarios
A detailed description of a simple implementation workflow using all three functions in the Futura interface is provided in Supporting Information S1.

Export
The final step is to export the new database for use in analysis, and recipe file to allow the new database to be shared. This is achieved via the "export" buttons in the Futura interface. The database can be exported directly to Brightway2. The recipe file is exported as a plain text file (in yaml format).
Any other files used to prepare the database, for example, excel files used to import additional data, are automatically copied to the same directory as the recipe file so that they can be shared at the same time.

EXAMPLES
In this section we present two simple examples of how the Futura workflow is implemented.

Technology drop-in
The first is a simple example of a technology drop-in, specifically; adding a new technology, regionalizing the technology to specific markets, and altering the relevant markets to include the new technologies.

Define scenario and identify changes
As a simple scenario we shall assume that CCS has become mandatory for coal-fired power stations in Germany. We shall assume that the proportion of coal energy in the grid mix remains the same (as do the proportions of all other generation technologies).
In order to model this scenario we shall add new LCI data to the database for CCS technologies for coal power. For this we use the CARMA datasets, as implemented in Beltran et al. (2020). We will use these CCS datasets as a template to create regionalized versions for power generation from hard coal and lignite for Germany. We will then add these regional versions to the market mix for high voltage electricity by transferring 100% of the production volume of hard coal and lignite powered electricity generation from the existing technology to the new technology.

F I G U R E 3
Effect of adding coal CCS to German electricity mixes on global warming impact. Underlying data used to create this figure can be found in Supporting Information S3

Select base databases
The ecoinvent 3.6 cut-off database is used as the base database with the addition of CARMA datasets via an excel spreadsheet. The use of ecoinvent 3.6 requires some minor updates to process names in the CARMA datasets from Beltran et al. A link to the updated version is supplied in Supporting Information S2.
3.1.3 Implement changes, export database, and recipe file The changes described above can be implemented using the Futura GUI. Detailed instructions are provided in Supporting Information S1, along with the final recipe file (Supporting Information S2). The database is exported to Brightway2 for analysis.

Results
Changing the grid mix for Germany to include CCS results in a 56-58% decrease the global warming impact of the German electricity mixes at all voltage levels (Intergovernmental Panel on Climate Change 2014, 100a characterization factors). This is to be expected, as the high voltage mix has been directly changed and the medium and low voltage mixes are linked to the high voltage mix (Figure 3). As a result, the global warming impacts of manufacturing processes in the ecoinvent database which take place in Germany are also markedly decreased, for example, global warming impact of the production of silicon in Germany decreases by 43%.
Electricity grids in the ecoinvent database are linked to a certain degree by imports. For example, German electricity is imported to (among others) the French, Danish, and Swedish grid. These grids in turn may be imported by other countries which do not directly import German electricity.
As a result we see differences in global warming impact of the grid mixes for other countries which reflect their linkage to the German grid ( Figure 4).
In addition, the German grid is part of a number of market groups in the ecoinvent database (e.g., ENTSO-E, RER, GLO). The global warming impact of these market groups is also affected in relation to the proportion Germany represents within that group (Table 1). Conversely, grids which have no link to Germany, for example, the Australian grid, show a negligible change in global warming impact (<0.01%) 8 .

F I G U R E 4
Top 20 most altered grid mixes by global warming impact as a result of the addition of coal CCS in Germany. Underlying data used to create this figure can be found in Supporting Information S3

TA B L E 1 Difference in global warming impact of market groups containing Germany as a result of the addition of coal CCS in Germany
Global warming impact (kg CO 2 -eq/kWh)

Automatic IEA grid mixes
The second example uses publicly available data from the IEA to update the grid mixes for 33 countries 9 . This process makes use of a "plugin," specifically the futura_iea plugin (https://github.com/pjamesjoyce/futura_iea). This is an additional piece of software which can be used to add domain specific functionality only useful to some users to the more general functionality of Futura.
Specifically, this plugin downloads the latest monthly average electricity generation statistics from the IEA website (https://www.iea.org/reports/ monthly-electricity-statistics) and calculates the average mix for the latest 12 months of data (at the time of writing in July 2020 the latest data is for April 2020). The broader generation categories in this dataset (e.g., coal, natural gas, wind) are mapped to the existing mix of more specific generation technologies in the ecoinvent electricity markets, maintaining the relative split within those categories 10 . For example, ecoinvent 3.6 has 45% of German electricity generation coming from coal, of which 56% is lignite powered electricity generation, 37% is hard coal powered electricity generation, 5% is hard coal co-generation, and 2% is lignite co-generation. The latest IEA figures have only 24% of German electricity generation coming from coal, with no further breakdown by fuel or technology type. The plugin alters the German grid mix such that 24% × 56% = 13% of the total mix comes from lignite, 24% × 37% = 9% comes from hard coal, etc. This stratified resampling is carried out for all energy sources.
Updating the technology mix of this subset of electricity grids can have substantial effects on the global warming impact of electricity in these countries and in linked regions ( Figure 5). Of particular note are Estonia (EE) where a much higher proportion of imports and a much lower proportion of energy from coal (peat) drive a large reduction in impact, and Denmark (DK) where a higher proportion of wind energy and biomass, and a lower proportion of coal leads to a substantial reduction over the ecoinvent 3.6 estimate.

DISCUSSION AND CONCLUSIONS
From a qualitative perspective, the importance of external factors in influencing the sustainability of future processes is widely acknowledged.
Topics such as grid decarbonization, the circular economy, the hydrogen economy are promoted as solutions to today's environmental problems with ever increasing regularity. The importance of capturing these external elements in forward looking quantitative studies can therefore not be underestimated. For low Technology Readiness Level (TRL) processes in particular, such considerations may be vital. Decarbonised grids, abundant sources of "green" hydrogen and other external enablers which may be need to be in place for a given emerging technology to be feasible from a sustainability perspective may well exist by the time that technology is ready for market. The ability to devise and implement coherent external scenarios across background datasets therefore allows the future sustainability of these emerging technologies to be assessed more comprehensively, and ultimately for better decisions to be made.
Similarly, the sustainability profile of long-lived projects or infrastructure may change over time depending on these same kinds of external changes. From a planning perspective, an option with a slightly worse current environmental profile, but with the a high potential and a high likelihood of a substantially lower future environmental profile may be better over its lifetime than a process or system designed for the status quo.
For example, heating systems based on electricity rather than natural gas may look worse today in areas with carbon intensive grids, but given the relative trajectories of grid decarbonization and renewable sources of combustible fuels this pattern may be reversed in the near future.
While the proximate aim of Futura is to allow the systematic editing and sharing of altered background datasets in LCA, the ultimate aim is to support better decision-making of this kind. While the focus of the examples presented here has been on electricity, the framework provided by Futura and the extensibility though plugins of the functionality is such that a whole host of other scenarios could be created and shared using the same workflow.
While Futura can be a useful tool used in isolation, a collaborative approach to its implementation may yield further benefits. One potential limitation to a stepwise approach is the issue of path dependency-that decisions made upstream by one practitioner can limit the options available to other practitioners. For example, results from integrated assessment models, such as IMAGE, aggregate electricity grids at a coarser geographical resolution than is present in the ecoinvent database. Implementing grid scenarios based on this data has an indirect "aggregation" effect, where all grids in, for example, "Western Europe" become essentially the same. A downstream practitioner investigating, for example, steel production scenarios in Scandinavia may find this aggregation a hindrance. Clear and transparent documentation of the assumptions and transformations applied can help avoid these issues, but requires the second practitioner to start again from the beginning. A collaborative platform where steel experts can discuss potential requirements with energy modelers to establish a geographical resolution that works in both cases would be of benefit to both parties. Calls for greater collaboration, transparency, and data sharing within industrial ecology (IE) are becoming increasingly common and increasingly loud (e.g., Hertwich et al., 2018;Kuczenski, 2019;Pauliuk et al., 2019) and as Pauliuk et al. (2019) point out, the benefits of establishing a common data sharing platform for the IE community would be immense.
Clear and transparent documentation of the transformations applied in Futura and, importantly, the data these transformations are based on will be important in its application. Data transparency and accessibility is an important topic within the field of IE (Hertwich et al., 2018), and is of particular importance where variability and uncertainty are likely to be important factors, for example, in the kinds of broad scale future projections that underpin the scenario generation for Futura. There are challenges ahead, however, the open-source ethos of collaborative improvement which pervades the LCA and IE community, alongside the ability to share and iterate scenarios and approaches places Futura as a useful tool and framework for enhancing the field of LCA.