Many processes in real life have more than one output. When you produce cheese you also produce whey. When you produce sugar you also produce molasses. When you produce flour you also produce bran. It’s all around us.
So how do we account for that in LCA? ISO 14044 gives us some guidance by providing us with a hierarchy of most-preferred approaches. Ideally, it tells us, we should avoid allocation. If we can’t, we should find physical phenomena to justify our allocation. If that’s also not possible, we should find a parameter to act as a proxy to allocate (e.g. the value of each of the output streams).
If you’re reading this, we can assume you weren’t able to avoid allocation. In such a case, for the part that can’t be allocated from a process, you have to decide one (or more) allocation parameters. Ideally, as per the ISO hierarchy, it’s something physical or proportional to the function of the product (e.g. mass, energy). If outputs are very different, you can also allocate based on economic value.
What’s behind allocation
Let’s look at an example of allocation from the production of soy oil. When we produce soy oil, the same process also has soy meal as a co-product. Let’s assume for the sake of the example that the environmental impact of the process is 1 kgCO2eq, and the outputs follow the values below:
Outputs | Amount | Unit | Mass share | Price ($/kg) | Value ($) | Value share |
Soy oil | 0.6 | kg | 60% | $2.60 | $1.56 | 80% |
Soy meal | 0.4 | kg | 40% | $1.00 | $0.40 | 20% |
Total | 1 | kg |
|
| $1.96 |
|
Allocating the impacts of the process means defining how much of the 1 kgCO2eq we should attribute as the impact of soy oil, and how much to the soy meal. We do so by selecting allocation factors, that is, the percentage of impact assigned to each. Obviously, the sum of those impacts should add up to that 1 kgCO2 eq, so the sum of the allocation factors should be 100%.
Depending on the allocation strategy selected, we would use Mass share or Value share as the allocation factor. If we selected mass allocation, 60% of the impact would be assigned to the soy oil (0.6 kgCO2 eq). If we would be using economic allocation instead, it would be 80% of the total impact (0.8 kgCO2eq). Those are the figures we should be comparing with alternatives.
Modeling co-product allocation in a single Earthster model
The most straightforward (and easiest) way to do co-product allocation in Earthster is through scale units.
In Earthster, every model is connected to the rest of the world through its scale. It has a number of equivalent scale units (production or functional units) that define how much output comes out of the modeled cycle. Read more about a cycle’s scale here.
That means that if a cycle has an impact on climate change of 20 kgCO2eq, and the cycle represents the production of 100 kg of a material, the impact will be 20 / 100 = 0.2 kgCO2eq. The cycle impact is always divided by the selected scale (on consumption or comparison), and it always assumes the scale units to be equivalent.
Based on this, we can get Earthster to allocate impacts for us by applying the allocation factor in the scale unit (inversely). In other words, we would guarantee that the impact is divided by the scale unit and multiplied by the allocation factor.
In the example for soy oil presented above, let’s assume we want mass (kg) as scale units, and we want them economically allocated. Then we would need to add as scale units:
mass output / economic allocation factor = 0.6 kg / 80% = 0.75 kg (economically allocated)
Maintaining allocated models with parameters
The formula above is best defined in Earthster through a calculation (whenever you type =, Earthster will open the formula editor). But one of the additional advantages of using calculations is that you can also use parameters in their calculations.
The formula above could be written just as
0.6 / 0.8
And there’s nothing wrong with that. Next time we need to deal with allocation on this process, we’ll just have to go into that formula. But we can take it one step further by parameterizing the allocation factor:
0.6 / allocation_factor
Now we can run scenarios for different allocation factors, and see what effect that would have. But we can go one step further and write:
oil_mass / (oil_price * oil_mass / (oil_price * oil_mass + meal_price * meal_mass)
That is a bit more of a mouthful, but let’s dive in and see what it really means. It’s nothing more than the table you saw before. The numerator is the oil mass (that is now a parameter, so you can adjust it in scenarios to see the effect). The denominator on the other hand is still the allocation factor, but now the formula has been spelled out. It’s calculated as the value of the oil fraction (price times mass), divided by the total value (sum of the soy oil value and the soy meal value, both calculated the same way). Now you have a more complex formula, but you also have all the moving parts there for you to run scenarios on, or update next time you receive new information (or the prices change, which is quite often).
The database approach: keeping allocation in different cycles
The suggestion above is very good if you want to have one sophisticated model to handle as many cases as possible. But in some cases, what you want is to just have a cycle that represents a given process, already allocated based on an allocation strategy (e.g. soy oil, economically allocated).
In such a case, you can have cycles for each of the outputs, that consume the allocated amount of the original process.
For the example above, we would model one cycle that has the scale 1kg of soy refining (unallocated). Its output is not particularly useful, so we create two other cycles, one for soy oil, economically allocated (consuming 0.8kg of unallocated soy refining, per 1kg of output), and another one for soy meal (consuming 0.2kg of unallocated soy refining, per 1kg of output).
This has the disadvantage of the allocation process being separate (you could accidentally add allocation factors that add up to more than one), but it has the advantage that you can just pick those processes from the background data without having to understand allocation at all.
Conclusion: which one should I use
Both methods have pros and cons. In general terms, if a cycle is a core part of your LCA study, and you want to run complex scenarios on it, it’s most recommended to maintain a single model with the allocation factors, since it will be much more powerful. And if you build the whole formula, it will be even more versatile.
On the other hand, if you’re setting up allocation for other people in the organization to use (e.g. building background data for the organization, uploading in bulk, or definite material for your R&D department to use in their decision-making), you’re more likely to benefit from the one-cycle-per-output approach.
You might even benefit from doing both (have a complex model for the experts, and a very shallow one (just consuming the other) for the rest of the organization! If you’re in doubt, don’t hesitate to contact our support team, and we’ll help you in the most scalable and efficient way.