Bridge Processes: A Solution for LCI Datasets Independent of Background Databases

Abstract

Introduction.

New platforms are emerging that enable more data providers to publish life cycle inventory data.

Background.

Providing datasets that are not complete LCA models results in fragments that are difficult for practitioners to integrate and use for LCA modeling. Additionally, when proxies are used to provide a technosphere input to a process that was not originally intended by the process authors, in most LCA software this requires modifying the original process.

Results.

The use of a bridge process, which is a process created to link two existing processes, is proposed as a solution.

Discussion.

Benefits to bridge processes include increasing model transparency, facilitating dataset sharing and integration without compromising original dataset integrity and independence, providing a structure with which to make the data quality associated with process linkages explicit, and increasing model flexibility in the case that multiple bridges are provided. A drawback is that they add additional processes to existing LCA models which will increase their size.

Conclusion.

Bridge processes can be an enabler in allowing users to integrate new datasets without modifying them to link to background databases or other processes they have available. They may not be the ideal long-term solution, but provide a solution that works within the existing LCA data model.

1. Introduction

The LCA field is poised to witness an even greater plurality of data providers. Emerging efforts to allow more universal access to life cycle inventory (LCI) data, namely the Global LCA Data Access Initiative (UNEP 2017) and the guidance and training being given toward potential new data generators (UNEP/SETAC 2011), will enable wider scale data sharing. Other data sharing platforms and dataset publication outlets beyond the LCA domain have emerged (e.g. Springer Nature 2017). New outlets present a better opportunity for LCA practitioners to become data providers to share their LCI data. One of the challenges of connecting LCI data from distinct sources is to link processes from one dataset to a dataset from another source. In terms of life cycle inventory data, the fundamental datasets referred to here are individual unit (or system) processes or an interconnected set of unit processes, which has also been called a fragment (Kuczenski 2014). These datasets may need to be linked to other datasets, or a background database, to build complete LCA models for a product. But such dependent or supporting datasets (most commonly “upstream” processes) may not be provided by the new dataset publishers. A user should be able to use these new datasets and link them to supporting processes available to them in order to build LCA models without altering the new unit processes provided. This article presents a best practice for creating processes and a related method for linking the process that does not force an alteration to original processes published by data providers, allows the user more flexibility in selecting their linking processes, and increases transparency by making the choice of supporting/linked processes explicit. The method is supported, to a limited extent, by existing LCA data models and software.

2. Problem

A process is the basic building block of an LCA model (UNEP/SETAC 2011). Processes describe activities within the technosphere. Processes generally have requirements for other man-made products and services, also known as technosphere flow inputs. LCA models generally consist of many processes linked together by technosphere flow exchanges. When a technosphere flow input is not linked to another process, then there is a gap in a system that does not enable full cradle-to-grave analysis, because there are upstream activities (or downstream in the case of waste treatment services) that are excluded from the model.

Examples provide some clarification of this issue, where p1 is always the dataset demanding technosphere products and is typically a ‘foreground’ process, and p2 is a process providing a product that can serve as the input to p1, where p2 is typically an existing background process. For instance, say p1 is a process for mechanical sorting of post-consumer recyclables that demands electricity, and p2 is a process for electricity production/distribution that would be appropriate for serving as an input into the mechanical sorting process, p1. A user of p1 would not be able to create the full life cycle inventory without having a p2 process as well as the upstream processes supporting p2, but these processes could potentially be provided by a background database (Figure 1). When a unit process requires an input, but a providing process is not specified, this can be referred to as a “cut-off”. Cut-offs may be justified based on cut-off criteria (ISO 14044 2006), however, of interest here is the case when a data generator uses a cutoff because the generator does not provide the supporting process. In this case, the provider may use an explicit convention in the data generation, appending the label “CUTOFF” to the flow name for which no providing process is specified. This convention has been used in the US LCI database and the USDA Agricultural Data Commons (NREL 2017; USDA National Agricultural Library 2016). But a dataset with this convention does not provide an automated linkage to supporting datasets to enable full life cycle modeling.

Figure 1.

Example user-defined process with a cut-off along with candidate products from a background database that could be linked to the foreground model.

The common notion in the LCI community of using a “proxy” process for LCA modeling is also a case where a practitioner wishes to explore adapting an original dataset to another situation in which the linked datasets were not originally intended by the process authors. For instance, a user wishes to model p1 for which the p2 electricity process uses another technology to generate the electricity or comes from a different location. The current practice is generally to create a copy of the p1 process and modify the technosphere input flow to link to a p2 electricity process of the user’s choice. The problem with this operation is that the user has modified the process as provided by the original dataset provider and there is often no clear record of that modification, and furthermore sharing this user’s model can infringe on a license agreement that covers the original p1 process, because it would require sharing a slightly altered version of p1.

3. Solution

A bridge process is a process that connects a unit process, p1, from one dataset with a CUTOFF, to a process, p2, in another dataset or database to provide a given technosphere product to p1. Figure 2A illustrates a bridge process using an example of a steel can production process with a CUTOFF input of steel sheeting.

Figure 2.

(A) Example bridge process (center) linking an original steel can production process (p1) with a market for steel, unalloyed from ecoinvent v3.1 (p2). The bridge serves to replace an otherwise missing input of a steel sheet to complete a very simplified LCA model. (B) The same product system without the bridge. Screenshots from openlca 1.5.

Bridge processes (BPs) are constructs that do not describe any original activities but only serve to create connections to enable full life cycle modeling. These are similar constructs to what are called “market activities” in Ecoinvent v3 (Wernet et al. 2016) or “mix processes” in other databases in that they do not describe original activities, but distinct from these processes in that they explicitly connect processes from different sources.

Use of bridge processes may be considered an alternative to the modification of the original process p1, by replacing the CUTOFF flow input with the input of a technosphere flow output provided by a process p2 that is present in the same database being used by the practitioner (or software provider if the software provider makes this edit). Figure 2B demonstrates this case, in which case there is no bridge, and the original p1 process has been modified by the LCA practitioner (not the original data provider). Alternatively, bridge processes can be used to link a proxy process, p2, to p1, allowing for using p1 in a new circumstance, without having to modify the p1 process as provided by the dataset provider.

BPs are recommended to be noted as a distinct type of process, such as unit process or system process, so that software would be able to provide them with special treatment, and that it be clear what these processes are.

4. Discussion

A number of benefits of the bridge process approach are described along with a discussion of some notable drawbacks, and the responsibility for provision of bridge processes is discussed.

4.1. Benefit for transparency

Practitioners often create new LCA data within LCA software. When selecting product or service inputs to a process, practitioners may be restricted to selecting from names of existing product flows that are outputs from existing processes, rather than entering a new name that describes exactly what is intended in the process. This restriction may in turn limit the level of detail of the technosphere input name to the unit process to what analogous product is available in the background database. Unit process generators should be encouraged to provide a technosphere input name and description that described precisely the process requirement, using a nomenclature that is consistent with other technosphere inputs and outputs in their process. Using a bridge process makes it feasible to name the technosphere input in this way (in p1) and still connect to a process that provides a suitable product to serve as that input from a background database or other source.

4.2. Benefit for data integrity and independence

There are many challenges to integrating LCA data from disparate sources. One of those challenges is sharing LCA data that are not complete life cycle models and allowing a user to integrate those with their existing data. Providing and using bridge processes is a solution to connect these datasets to make them more useful without alteration of the data. And the new datasets have more independence such that they aren’t forced into using what can be provided by an existing LCI dataset or database.

4.3. Benefit for documenting models and data quality aspects of process linkage

Bridge processes provide a place to store metadata describing the process linkage, including the authors, purposes for the linkage, and associated data quality regarding the linkage. Model level data quality can be defined an aspect of LCA data quality related to how well the set of processes and the full model itself fit the intended use. It is an aspect of data quality in LCA that has not yet been quantified or addressed (Edelen and Ingwersen 2017). The appropriateness of linkages between processes in a model is an important aspect of model data quality – for instance, how geographically, technologically, and temporally relevant is the product from p2 for the process p1? Quality of such linkages is described in the IDEA database, but generally there is no place in an LCA dataset to describe that information (AIST and JEMAI 2017). Bridge processes provide a structure for which to carry such data quality information and make it more explicit that what is demanded in a unit process, and what is used from another process to satisfy that demand, are not always identical.

4.4. Benefit for model flexibility

Recent developments in LCA and tools to enable rapidly creating alternative LCA models like Ocelot (Bourgault et al. 2017) have emerged out of the need for increasing flexibility in the assembly of LCA models. Bridge processes lend this flexibility to modeling by making this linkage an explicit construct that can be easily replaced by another “bridge” to provide more than one alternative linking processes for a dataset. This is especially useful in modeling using proxy processes.

4.5. Drawbacks

Using a bridge process approach may inflate the size of life cycle inventory models. With a bridge required for each input to be linked to a background database, a bridge would be required for each input. For instance, for a process with 10 flows that require a bridge to 8 background processes (a more generic background process, say for ‘average organic chemical’ in a background database may be bridged to for more specific organic input chemicals in lieu of more precise background data), would require 10 bridge processes. In this case, a model with 8 processes before would expand to a model of 18 processes. This will inevitably expand the size of matrices used in LCA software for matrix inversion, and the size of data exported or imported in exchange formats (esp. if the bridge processes themselves are included). However, as algorithms have greatly improved the speed of LCA model computation, this is not expected to pose a significant issue.

Another possible drawback is the lack of ability to distinguish between a bridge process and a standard process in LCA software or in the data exchange formats. If bridge processes require unique metadata or data quality descriptors, this will be a limitation unless the software and formats are modified/expanded. However, as mentioned above, bridge processes share a common function with mix processes in that they convey a limited amount of unit process data, but make the best possible usage of the existing structure of LCA data to serve their end.

4.6. Responsibility for bridges

Who would be responsible for creating BP(s)? This is an open question. For data providers that do not provide full LCI databases, bridge processes could allow data providers to make their data easier to integrate with existing databases. There would be no need to limit bridge processes to a single set to bridge to one particular database (e.g., GaBi), but multiple sets of bridges could be provided. This however, would be a large additional commitment on behalf of the independent dataset provider. Alternatively, for maximal flexible and user control over a model, the LCA practitioner could construct the bridge processes. This may desirable by a practitioner that has a supporting process, p3, that is equivalent to p2 and that he or she would prefer to use because it better serves the goal of the LCA study, or provides better data quality for the LCA study, than the p2 process linked to in the bridge provided by the data provider, for the LCA goal at hand. In summary, there are reasons that both the data provider and practitioner might create the bridge processes, but ultimately it would be up to the practitioner to determine whether to use the bridge processes provided or create new bridges, based on the LCA goal and scope and on what supporting data they have available.

5. Conclusion

Data sharing platforms are emerging that data providers and users can utilize for LCA data sharing. There is a commensurate need to provide independent LCA data providers with a means of creating and sharing datasets that are independent of the large background databases that the LCA community relies on to compute full life cycle inventory results. Individual unit processes should include input technosphere flows that describe exactly the input that is demand for the process being modeling, rather than name the input based on the closed corresponding product from a background database. If the dataset provider does not provide a linked dataset (uses an explicit CUTOFF or the dependent dataset is just absent), bridge processes can be provided or created to link the processes to background data suitable for assembling an LCA model without modifying the original dataset. The use of bridge processes can be an enabler in allowing independent dataset creation and sharing, while still permitting full model creation and linkage for cradle-to-grave, life cycle inventory model creation and computation. Bridge processes could also benefit LCA model description, an issue being addressed by an ongoing SETAC North America Working Group (Kuczenski et al. 2017). As they in a sense are an artificial construct, there may be better solutions in the long-term, but they provide a way to distinguish and work with datasets with cut-offs provided by original providers, or ways of modeling using proxies without altering the original datasets, that works with in the current LCA data model.