A first application of the Operating System for Climate Action of the Carbon Accounting and Certification WG is an application to allow data centers to credibly prove that they're carbon neutral with trusted data and Renewable Energy Certificates (REC's) and carbon offsets.

We chose data centers as our first application because:

  • Data center have high energy use.  Energy is a data center's highest operating expense and could be about half of all its expenses.  (Uptime Institute's Simple Model for Determing True Total Cost of Ownership for Data Centers.) 
  • Globally, data centers use 103 terawatt hours of electricity (See Recalibrating global data center energy-use estimates), about 1% of the global electricity output.  This is equivalent to the energy use of 17 million American households (NYTimes.com) with a total carbon emissions footprint on par with those of airlines (BBC.com)
  • Data center energy use can obtained from utility energy bills, many of which are electronically available via the Green Button data standard.
  • Major cloud services providers are focused on improving data center energy efficiency, both as a competitive advantage and as a way to meet their climate goals.  Microsoft, for example, has committed to becoming carbon neutral, while Google has made both sigificant investments in data center efficiency and renewable energy.

The application would use several permissioned Hyperledger channels, as described in the the Operating System for Climate Action, on these inputs:

  • Data center meta-data, such as its name and location.
  • Data center activity metrics, such as the number of U-racks of servers or the amount of CPU compute units, storage, and bandwidth provided during a time period.
  • Utility bills for the data center.
  • CO2 emissions of the utilities, obtained from the Emissions & Generation Resource Integrated Database (eGRID) of the EPA.
  • Renewable Energy Certificates (REC's) purchased and retired by the data center.
  • Carbon offsets purchased by the data center.

The permissioned ledgers would include:

  • Energy use data, which could come from any combination of
    • Utility channel – This would be a ledger for the utility bills, set up by utility or its service provider, for its customers.  It would issue tokens for each customer based on the carbon footprint of their energy purchased, which would be calculated based on the utility bill for the customers and the utility's overall emissions.
    • UPS log data – Uninterrupted Power Supply (UPS) for the servers which could provide a log of power use by the servers.  This could then be used to estimate the HVAC costs for the servers based on models of cooling requirements for the server's space.  This method could be used when the data center does not have its own meter or utility bill and is instead aggregated with other building or campus utility bills.
    • Server utilization data – This could come directly from the servers themselves, which could report their up time and load levels.  This data could then be combined with models of energy use for the servers and their required HVAC to come up with energy usage.  This would be useful for determining the effects of software running on the servers.  
  • RECs and carbon offsets from the Emissions Tokens Network 

The data center would subscribe to all of the above channels and use the tokens to calculate its energy use with a smart contract which:

  1. Sum up the total energy (kWH of electricity) used by the data center,
  2. Subtract the REC's
  3. Calculate CO2 emissions from the difference of (1) - (2) using utility-specific emission data
  4. Subtract carbon offsets

The total carbon footprint could then be divided by the activity metric of the data center.  Initially, that could simply be the number of U-racks.  An added enhancement would be to break out the equipment of the data center by type, for example by compute servers, storage, and network switches.  We can then use their power ratings to allocate the carbon footprint to the different equipment and come up with the carbon footprint per compute units, storage, and bandwidth. 

Finally, a token or asset could be issued for each unit of activity to the customers of the data center, so that they could use it in their CO2 accounting.

Note that such a calculator is only calculating the carbon footprint of the existing equipment in a data center.  It could be expanded eventually to cover the full Greenhouse Gas Protocol for data center, so that it could be used to certify a "carbon neutral" data center.  That would require accounting for all the Scope 3 emissions, including the carbon footprint of new capital assets (servers), employee commuting and business travel, and other purchased supplies and equipment.

We could implement this MVP application using the True TCO Calculator for Data Centers, as described in this Uptime Institute white paper.      

References




  • No labels

2 Comments

  1. Robin Klemens

    Hi Si Chen, thank you very much for the effort in research you've accomplished to formulated this interesting use case. 

    I really like the idea of breaking down the greenhouse gas footprint to the services (U-racks or later compute units, storage, etc. )of the data center (smile) In the more advanced version of the prototype we could also include the carbon footprint of the product lifecycle of the U-racks, etc. which would lead to an even more holistic view of the greenhouse gas impact. I think this goes in hand with the last section of Si's proposal.

    Let's assume that the carbon-neutral certification would also cover all the Scope 3 emissions. Would the Scope 1 & 2 emissions of the data center (C-DataCenter) then be accounted for the customer's (C-Manufacturer) Scope 3 emissions if the customer buys services of the data center? E.g.: Company C-Manufacturer decides to move all it's on-premise computing operations to the cloud computing service provider C-DataCenter (lift-and-shift). Thus, C-Manufacturer reduces its Scope 1 & 2 emissions. However, C-Manufacturers Scope 3 emissions would increase as well as the Scope 1 and 2 emissions of C-DataCenter. Now we need to answer the question of which company is in charge of accounting for the emissions? At first, greenhouse gas emissions will be added to the greenhouse gas balance of C-DataCenter. But will the emissions be transferred to the greenhouse gas balance of C-Manufacturer at the end of each week/month/year and thereby removed from the greenhouse gas balance of C-DataCenter? The solution should definitely prevent double accounting.

    Maybe these questions can be addressed by the Standards - WG. 


    1. Si Chen

      Yes, that's exactly how it should work.  When the Manufacturer moves its data centers from its on premises to DataCenter, Manufacturer reduces its own Scope 1 & 2 emissions, while DataCenter increases its own Scope 1 & 2 emissions.  This should be offset when the Data Center's emissions are then counted as Manufacturer's Scope 3 emissions.  

      I think a publicly transferred token, such as on ethereum or some other public blockchain, would properly account for this.  The emissions of the DataCenter would transfer to the Manufacturer by a token to be counted in its Scope 3 emissions.