Time-explicit LCA of an electric vehicle¶

This notebook shows how to use bw_timex with a cradle-to-grave case study of an electric vehicle (ev). The case study is simplified, not meant to reflect the complexity of electric mobility but to demonstrate how to use bw_timex.

Note: This is the "premise" version of this notebook that works with ecoinvent and premise data. If you don't have access to that, please check out the "standalone" version of this notebook.

Prospective background databases¶

The bw_timex package itself does not provide any data - specifying prospective and dynamic information is up to the user. In this example, we use data from ecoinvent v3.10, and create a set of prospective databases with premise. We applied projections for the future electricity sectors using the SSP2-RCP19 pathway from the IAM IMAGE. We selected this pathway to simply demonstrate some future development in this case study, and many other models and pathways are available. In the premise documentation you can find instructions for the creation of prospective background databases.

Case study setup¶

In this study, we consider the following production system for our ev. Purple boxes are foreground, cyan boxes are background (i.e., ecoinvent/premise).

{mermaid}
flowchart LR
    glider_production(glider production):::ei-->ev_production
    powertrain_production(powertrain production):::ei-->ev_production
    battery_production(battery production):::ei-->ev_production
    ev_production(ev production):::fg-->driving
    electricity_generation(electricity generation):::ei-->driving
    driving(driving):::fg-->used_ev
    used_ev(used ev):::fg-->glider_eol(glider eol):::ei
    used_ev-->powertrain_eol(powertrain eol):::ei
    used_ev-->battery_eol(battery eol):::ei

    classDef ei color:#222832, fill:#3fb1c5, stroke:none;
    classDef fg color:#222832, fill:#9c5ffd, stroke:none;

Modeling the production system¶

Now, we need to build this with brightway. If you are not interested in the modeling details, feel free to skip this section.

For our ev model we make the following assumptions:

First, we create a new foreground database:

Now, let's creating the foreground activities:

We take the actual process data from ecoinvent. However, the ecoinvent processes for the ev part production contain exchanges for the end of life treatment in the production processes already, which we want to separate. So let's fix that first by creating new activities without the eol processes:

Now, let's build the exchanges, starting with the ev production:

... the end of life:

...and, finally, driving:

Adding temporal information¶

Now that the production system is modelled, we can add temporal distributions at the exchange level. The temporal information we want to embed in our product system looks somewhat like this:

{mermaid}
flowchart LR
    glider_production(glider production):::ei-->|0-2 years prior|ev_production
    powertrain_production(powertrain production):::ei-->|1 year prior|ev_production
    battery_production(battery production):::ei-->|1 year prior|ev_production
    ev_production(ev production):::fg-->|0-3 months prior|driving
    electricity_generation(electricity generation):::ei-->|uniformly distributed \n over lifetime|driving
    driving(driving):::fg-->|after ev lifetime|used_ev
    used_ev(used ev):::fg-->|3 months after \n ev lifetime|glider_eol(glider eol):::ei
    used_ev-->|3 months after \n ev lifetime|powertrain_eol(powertrain eol):::ei
    used_ev-->|3 months after \n ev lifetime|battery_eol(battery eol):::ei

    classDef ei color:#222832, fill:#3fb1c5, stroke:none;
    classDef fg color:#222832, fill:#9c5ffd, stroke:none;

To include this temopral information, we use the TemporalDistribution class from bw_temporalis. For more info, take a look at the bw_temporalis documentation.

Notably, in addition to the timestamp of the occurence of the process (which is shown in the flowchart above), we also need to specify the amount share of the exchange that happens at that time to fully define a TemporalDistribution.

Let's explore what a TemporalDistribution looks like:

Starting from the functional unit in our supply chain graph, the temporal distributions of consecutive edges get "multiplied", or more specifically, convoluted. Let's look at an example to clarify this. The assembly and delivery of our ev happens either 2 or 3 months before we can start using it. Each of these occurences of this process demands a glider, which also has a temporal distribution that then gets convoluted "back in time". Also pay attention to how the amounts get scaled.

We now add the temporal information to the exchanges of our EV. We add temporal distributions to all (technosphere) exchanges, but you don't have to.

LCA using bw_timex¶

As usual, we need to select an impact assessment method:

bw_timex also needs to know the representative time of the databases:

Now, we can instantiate a TimexLCA. It's structure is similar to a normal bw2calc.LCA, but with the additional argument database_date_dict.

Not sure about the required inputs? Check the documentation using ?. All our classes and methods have docstrings!

Let's instantiate a TimexLCA object for our "driving" activity:

Next, we build a timeline of the exchanges. To do this, we can call the build_timeline() method, which does the graph traversal and creates a timeline dataframe from the results. The exchanges (rows of the dataframe) are aggregated to the resolution specified in the argument temporal_grouping. There are also many more options to specify the timeline creation and graph traversal process. Here are the most important ones:

• temporal_grouping: temporal resolution to which processes will be aggregated,"year" (default), "month", "day" or "hour"
• interpolation_type: How the best fitting background database is selected: "linear"(default), "closest"
• edge_filter_function: Custom filter function specifying when to stop the graph traversal.
• cutoff: stops graph traversal for nodes below this contribution to the static impact score.
• max_calc: stops graph traversal if this number of nodes has been traversed

For all these options, we provide sensible default values. Of course you can always just check the docstrings to see all your options and our assumptions for default values.

So, let's build the timeline. We choose a monthly temporal grouping here because we use that resolution in our temporal distributions.

The interpolation weights in the timeline (right most column above) specify the share of the amount of an exchange to be sourced from the respective database. None means that the exchange is in the foreground supply chain, and not at the intersection with the background system.

Next, we calculate the time-explicit LCI. The TimexLCA.lci() function takes care of all the relinking, based on the information from the timeline.

Taking a look at the dynamic_inventory that was now created, we can see that it has more rows (emissions) than our usual biosphere3 flows. Instead of one row for each emission in the biosphere database we now get one row for each emission at each point in time.

The standard, non-dynamic inventory has far less rows because the temporal resolution is missing. Looking at the timeline again, we see that we have processes at 23 different points in time (only counting the ones that actually directly produce emissions), which exactly matches the ratio of the dimensions of our two inventories:

While under the hood, the dynamic inventory is calculated as a sparse matrix, there is also a more human-friendly version as a pandas DataFrame:

If we are only interested in the new overall time-explicit scores and don't care about the timing of the emissions, we can set build_dynamic_biosphere=False (default is True), which saves time and memory. In that case, you only get the TimexLCA.inventory, but not the TimexLCA.dynamic_inventory.

In case the timing of emissions is not important, one can directly calculate the LCIA the "standard way" using static characterization factors. Per default, the following calculates the static lcia score based on the impact method chosen in the very beginning:

At this point, we can already compare these time-explicit results to the results of an "ordinary", completely static LCA. These already exist within the TimexLCA class, originally to set the priorities for the graph traversal:

Dynamic Characterization¶

In addition to the standard static characterization, the time-explicit, dynamic inventory generated by a TimexLCA allows for dynamic characterization. Users can provide their own dynamic characterization functions and link them to corresponding biosphere flows (see example on dynamic characterization).

Alternatively, you can use the functions from our separate (but fully compatible) package dynamic_characterization. We provide two different metrics for dynamic LCIA of Climate Change: Radiative forcing [W/m2] and Global Warming Potential (GWP) [kg CO2-eq]. For both of these metrics, we have parameterized dynamic characterization functions for all GHG's that IPCC AR6 provides data for.

For the dynamic characterization, users can also choose the length of the considered time horizon (time_horizon) and whether it is a fixed time horizon (fixed_time_horizon). Fixed means that the time horizon for all emissions (no matter when they occur) starts counting at the time of the functional unit, resulting in shorter time horizons for emissions occuring later. If the time horizon is not fixed (this is what conventional impact assessment factors assume), it starts counting from the timing of the emission.

Radiative forcing¶

Let's characterize our dynamic inventory, regarding radiative forcing with a fixed time horizon and the default time horizon length of 100 years:

The method call returns a dataframe of all the individual emissions at their respective timesteps (tlca.characterized_inventory), but we can also just look at the overall score:

To visualize the results, we provide a simple plotting functions:

This can be a bit messy, though, because all the individual impacts caused by individual emissions (e.g., CO2, CH4, N2O, ...) appear. Luckily, there is also an option to sum the emissions within each activity:

There is also a flag to plot the cumulative score over time:

GWP¶

Similar options are available for the metric GWP, which compares the radiative forcing of a GHG to that of CO2 over a certain time horizon (commonly 100 years, but it can be set flexibly in time_horizon).

Plotting the GWP results over time:

Cumulative:

Comparison of time-explicit results to static results¶

It's helpful to understand how the time-explicit results differ from those using static assessments.

We compare the time-explicit results with those of an LCA for the year 2020 and 2040 for the standard GWP100 metric (time horizon=100 and no fixed time horizon). This means we neglect the additional differences of the time-explicit results that would arise from using dynamic LCIA.

Time-explicit scores:

The 2020 (static) score has already been calculated by TimexLCA in the beginning, but we can still access the score:

However, further down we also want to look at what part of the life cycle has what contribution. To get this info, we need some more calculations:

Similarly, we calculate the 2040 (prospective) scores by just changing the database the exchanges point to:

Lets compare the overall scores:

To better understand what's going on, let's plot the scores as a waterfall chart based on timing of emission. Also, we can look at the "first-level contributions":

One can see that the time-explicit results (in the middle) are somewhere in between the static and the prospective results. This makes sense as at each timestep, the underlying processes are sourced from progressively "cleaner" background databases, reaching a lower impact than if they are only sourced from the current database, but not so low as the prospective results, which are fully sourced from the most decarbonized database. Notably, the electricity consumption in the use-phase, modelled uniformly over the lifetime of the EV, contributes less and less to the score in the later years, since the electricity becomes cleaner in the future databases.