Embodied Carbon (`M`) Needs Detail

[will-iamalpine]

Flagging this to work with @arexub (Alex Bitukov) from MSFT around the latest embodied carbon work.

There's significant ambiguity around two key areas

• we can provide guidelines for what's expected when calculating embodied carbon, but going beyond is not worthwhile
• variability: same product can produce different results

Goal: generalize enough around key variables (@arexub (Alex Bitukov) from MSFT:

• sourced materials
• MFG overhead
• transportation/packaging
• use phase (energy consumption * useful life)
• end of life
• the actual rack you're running your workload on (not even accounting for datacenter infrastructure (e.g. concrete/wires/etc))

Electronics: some specific standards we can reference

Key unknown: how to amortize embodied carbon over lifespan (demoninator) of equipment? total carbon / lifespan

[atg-abhishek]

Would be great to have some more details from you @arexub so that we can bring it up for discussion once we have a bit more substantial detail and then explore how we can account for that in the SCI.

[jawache]

This is a rabbit hole, you can spend 30 mins on this or a whole year :) I think we need to insist on a very simple method that everyone can do and encourage a more involved method that only some orgs will be able to invest in.

Level one of this I believe should be cost-based, most people use a cost-based multiplier most carbon accounting tooling uses a cost-based multiplier. They are directionally accurate and fast to calculate. So for the cloud, you look at your cloud bill and multiple by a number, something that one person could calculate in 30 mins.

Level two we might explore a more involved approach where people figure out the exact specs of the hardware they used and reference that against a database of emissions factors. That gives you a more accurate number but takes a lot longer and those emissions factor databases sometimes cost a lot of money.

[atg-abhishek]

@buchananwp can transfer to @arexub once he joins?

[jawache]

I was reminded of this article by Benjamin Davy: https://medium.com/teads-engineering/evaluating-the-carbon-footprint-of-a-software-platform-hosted-in-the-cloud-e716e14e060c

He goes into a lot of detail about how to calculate the embodied carbon emissions. To cut a long story short:

1. Use cost as a proxy, it's fast and is directionally accurate at least. A simple solution here would be to create a single coefficient carbon per $. Some sort of global average, I imagine several carbon accounting services have already calculated this since they give you a carbon number simply by looking at the cost of your cloud bills. There are more accurate methods, but this would be fastest.

2. Use emission factor databases there is a lack of these databases for digital products and as far as I know all the good ones cost money or are in-house.

I think we need to branch off an innovation projects to calculate the embodied carbon coefficients of hardware which the GSF publishes for free. The SCI can reference our free database in the spec.

[atg-abhishek]

This is a great article @jawache and I think we can definitely take some cues from it and based on the discussion today, we can add some details about this in our SCI spec.

[will-iamalpine]

• [ ] incorporate lifespan (e.g. how do we amortize embodied carbon?) From our studies, it's shown that lifespan can be highly variable and hard to estimate.

[navveenb]

@jawache "I think we need to branch off an innovation projects to calculate the embodied carbon coefficients of hardware which the GSF publishes for free. The SCI can reference our free database in the spec." - This is a good project to have for the community.

On the cost point, using the cost as a proxy, might not work in all cases, but provide reasonable value to start with - for instance - cloud cost can depends on variability like region, managed services, architecture style like server-less (can have high usage, but low cost) or sustained discounts on yearly commits on VMs. So we need more insights. For an on-premise environment, the inventory is usually known, but its not tracked from emission perspective, like racks, tape drives, modems etc and end of lifecycle (waste etc..) and you want to extend to supporting assets to run your infrastructure..

I think, we can provision for the "Embodied carbon" parameter, while calculating the overall carbon footprint and provide suggestive guidelines on what to include for calculation.

[atg-abhishek]

Would the preset list that we have in the SCI be a good venue for this @navveenb ?

[vaughanknight]

@navveenb Agree on cost not being a good measure. Cloud costs or on prem costs can vary based simply on exchange rate, and internal business factors, price increases and competitor pressure. The costs of items in a data centre, or the data centre itself, can be a lot more expensive because of levels of physical security, legislation, downside risk etc, and have little to do with the hardware itself.

[vaughanknight]

@navveenb @jawache "I think we need to branch off an innovation projects to calculate the embodied carbon coefficients of hardware which the GSF publishes for free. The SCI can reference our free database in the spec." - This is a good project to have for the community.

100% agree. We should also have guidance on the site as to other references that exist. Some already do exist but this will evolve over time as the world gets a bit wiser in relation to supply chain and understands the full emissions impact. It will also get standardized and regulated as governments move towards emissions targets and accountability across countries.

@buchananwp One area we need to make note of is I assume (and this is a big assumption) that carbon offsets in the supply chain of the hardware is included in SCI for embodied carbon, but not the companies own hardware emissions (building, transport, setting up), and not for the software itself.

[navveenb]

preset list

@atg-abhishek can you point me to the preset list values, i only see a place holder in the spec

[atg-abhishek]

@vaughanknight re:

@buchananwp One area we need to make note of is I assume (and this is a big assumption) that carbon offsets in the supply chain of the hardware is included in SCI for embodied carbon, but not the companies own hardware emissions (building, transport, setting up), and not for the software itself.

I don't think we want to include the offsets in any part of the SCI calculation unless I'm mistaken on what this is referring to?

[atg-abhishek]

@navveenb yes we only have a placeholder for now and it needs to be populated

[jawache]

@navveenb After seeing some of the work by Benjamin Davy I'm now leaning more towards a very simple model for estimating embodied emissions based on some coefficients for high level components rather than cost so happy to move away from cost as a proxy.

I'm thinking more and more that to support the SCI the Innovation WG needs to launch the "SCI Open Data" project, to make all the data needed to execute the SCI, including rough emission factors, freely available.

[atg-abhishek]

Agreed on this!

On Thu, Sep 23, 2021, 6:58 PM Asim Hussain @.***> wrote:

@navveenb https://github.com/navveenb After seeing some of the work by Benjamin Davy I'm now leaning more towards a very simple model for estimating embodied emissions based on some coefficients for high level components rather than cost so happy to move away from cost as a proxy.

I'm thinking more and more that to support the SCI the Innovation WG needs to launch the "SCI Open Data" project, to make all the data needed to execute the SCI, including rough emission factors, freely available.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Green-Software-Foundation/software_carbon_intensity/issues/31#issuecomment-925816995, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6CZPG5YEOYWDEAFFML4ZTUDMTQBANCNFSM5CMPTZXQ .

[navveenb]

@navveenb After seeing some of the work by Benjamin Davy I'm now leaning more towards a very simple model for estimating embodied emissions based on some coefficients for high level components rather than cost so happy to move away from cost as a proxy.

I'm thinking more and more that to support the SCI the Innovation WG needs to launch the "SCI Open Data" project, to make all the data needed to execute the SCI, including rough emission factors, freely available.

Agreed @jawache , we should stay away from cost as it could be misleading.. I saw some of the inputs for SCI Open Data as part of SCI Core Library innovation project, which can be extended and make this data available for all.

[atg-abhishek]

reminder for @jawache @Henry-WattTime and others to add in thoughts based on the call from last week with Benjamin Davy. Thanks!

[Henry-WattTime]

Based on the presentation from Benjamin, I think we landed on:

(Total embodied emissions/expected lifespan * reserved usage)/(system utilization)

where: total embodied emissions is the sum of LCA emissions for all components Expected lifespan is the anticipated time that the equipment will be installed reserved usage is the time the equipment has been reserved for use of the software and system utilization is the anticipated total time the equipment is reserved divided by the total installed lifespan (if available). (Could be datacenter utilization percentage or something similar, like the percentage of time that equipment is reserved in the datacenter)

Is this recollection correct? Are the bones right? Any modifications?

[jawache]

That feels correct to me but we can leave off the /(system utilization) the actual amount something is used doesn't matter. E.g. The embodied carbon you are responsible for doesn't change whether you use your phone every day or once a month, however it does change if you share your phone equally with your partner (your reserved usage would go from 1 to 0.5).

[jawache]

Some phrasing for discussion:

You MAY use simple models to estimate embodied emissions; however, we RECOMMEND using the most granular data possible and ideally emissions data from a devices life cycle analysis when calculating your embodied carbon.

And

You MUST include an estimate of all the embodied emissions for the hardware used within your software boundary.

[jawache]

Actually perhaps more like this M = Total embodied emissions * time reserved/expected lifespan * reserved usage

So for a server that has 40vCPUs that you rented 4vCPUs for 1 hr and has 4000kg of embodied emissions assuming a 4 year lifespan.

M = 4000 * 1h/4years * 4/40

For a laptop, you might choose a different way to calculate reserved usage? Laptops are usually limited by memory in my experience, you don't start killing apps until you need to free up mem.

So for a laptop that has 16gb RAM and 1000kg of embodied emissions assuming a 5 year lifespan, you're app ran for 20 mins and took up 4gb RAM.

M = 1000 * 20mins/5years * 4/16

[atg-abhishek]

You MAY use simple models to estimate embodied emissions; however, we RECOMMEND using the most granular data possible and ideally emissions data from a devices life cycle analysis when calculating your embodied carbon.

Since RECOMMEND isn't on RFC2119, maybe we can rephrase this as follows: (RECOMMENDED is in RFC2119, but I'd rather keep everything in the sentence for the same subject, i.e. "you")

You MAY use simple models to estimate embodied emissions; however, you SHOULD use the most granular data possible and ideally emissions data from a devices life cycle analysis when calculating your embodied carbon.

[atg-abhishek]

thanks @Henry-WattTime and @jawache for capturing this here :)

[Sealjay]

We discussed this relating to #94 - the group had nothing to add. But Daniel will be adding an issue/PR relating to hardware emissions.

[atg-abhishek]

Sounds good @Sealjay - thanks!

[will-iamalpine]

@tgogoi for context