diff --git a/README.md b/README.md index 6a540bf..269469a 100644 --- a/README.md +++ b/README.md @@ -1,26 +1,63 @@ -# Welcome to WEATS - the WattCarbon Energy Attribute Tracking System +# Welcome to the OpenEAC Alliance Methodology Repository -This is the homepage for the current versions of the methodologies that allow WattCarbon to create EACs for clean energy resources. Each methodology category is contained in a separate folder. Individual methodologies are added by Pull Request ([step-by-step guide](https://github.com/wattcarbon/WEATS/blob/main/how-to-submit.md)). After the maintainers see the new Pull Request, it will be added to the queue below. Upon approval by the OpenEAC Alliance, these methodologies are merged into this repository and published here. +This is the homepage for the current versions of the methodologies that allow WattCarbon to create EACs for clean energy resources. Each methodology category is contained in a separate folder. +The [OpenEAC Alliance](https://www.openeac.org/) is a volunteer organization comprised of individuals and organizations with experience developing measurement and verification techniques. Each methodology is reviewed by members of the OpenEAC Alliance and each change to an approved methodology will require notification of all reviewers. -The OpenEAC Alliance is a volunteer organization comprised of individuals and organizations with experience developing measurement and verification techniques. Each methodology may be reviewed by one or more members of the OpenEAC Alliance and each change to a methodology will require notification of all reviewers. +For meeting updates and up-to-date communication, see our [substack](https://www.openeac.org/). -See the current [Pull Requests](https://github.com/wattcarbon/WEATS/pulls) list for what is being considered by the OpenEAC Alliance. +## Definitions -For meeting updates and up-to-date communication, see our [substack](https://www.openeac.org/). +TODO: This section will be updated with agreed upon terms and definitions that can be used across different methodologies. + +## Development Roadmap + +The development of methodologies will happen in several phases, to enable both fast initial progress and capitalisation on the learnings in a consolidation phase. + +- Phase 1 (Self-contained methodologies): Each methodology contains all of the components that are needed to define its use. Approvals are made on self-contained documents which then become immutable after signature. + +- Phase 2 (Modularized methodologies): Common components (such as valid carbon sources, resampling techniques, etc) are extracted and approved of separately and then referenced by individual methodologies. + +## Methodologies + +### Published Methodologies + +| Category | Methodology | Author | Approval Date | URL | +| ------------------ | ------------------------------------------------ | -------------- | ------------ | ------------ | +| (Pending) | | | | | + +### Submission +Individual methodologies are added by Pull Request ([step-by-step guide](https://github.com/wattcarbon/open-eac-alliance/blob/main/how-to-submit.md)). The methodology file should be added to the repo under the following naming structure: `methodologies/{category}/{methodology_title_snake_case}.md`. + +### Approval Process + +The approval process proceeds in several steps: + +1. A Pull Request is submitted to the WEATS repository with a new methodology. The methodology MUST contain at least 2 authors. +2. The Pull Request is reviewed by the maintainers and added to the queue for presentation at an OpenEAC Alliance meeting. +3. The authors present the methodology to the OpenEAC Alliance. +4. The authors update the methodology based on feedback. +5. At least 3 reviewers must approve the methodology Pull Request. +6. A static PDF copy of the methodology is created and sent to the reviewers for official electronic signature. +7. This signed PDF is uploaded to the repository (under [approved_documents/methodologies](https://github.com/wattcarbon/open-eac-alliance/blob/main/approved_documents/methodologies) ) and the Pull Request is merged. + +### Methodology Queue + +> [!NOTE] +> See the current [Pull Requests](https://github.com/wattcarbon/open-eac-alliance/pulls) for the latest list of proposed methodologies. -## Methodology Queue +The following methodologies are currently in the queue and will be incorporated into an upcoming OpenEAC Alliance meeting agenda. -| Category | Methodology | Developer | Pull Request | +| Category | Methodology | Developer | Pull Request | | ------------------ | ------------------------------------------------ | -------------- | ------------------ | -| Solar | Self-Consumed | PeerCo | wattcarbon/WEATS#2 | -| Energy Efficiency | Whole-building Metered Lighting | C3 | wattcarbon/WEATS#3 | -| Energy Efficiency | Existing Construction Whole-building Simulation | Auros Group | wattcarbon/WEATS#5 | -| Energy Efficiency | New Construction Whole-building Simulation | Auros Group | wattcarbon/WEATS#4 | -| Electrification | NREL ResStock Deemed Loadshapes | WattCarbon | wattcarbon/WEATS#6 | +| Solar | Self-Consumed solar PV generation | PeerCo | wattcarbon/open-eac-alliance#2 | +| Energy Efficiency | Whole-building Metered Lighting | C3 | wattcarbon/open-eac-alliance#3 | +| Energy Efficiency | Existing Construction Whole-building Simulation | Auros Group | wattcarbon/open-eac-alliance#5 | +| Energy Efficiency | New Construction Whole-building Simulation | Auros Group | wattcarbon/open-eac-alliance#4 | +| Electrification | NREL ResStock Deemed Loadshapes | WattCarbon | wattcarbon/open-eac-alliance#6 | -## Published Methodologies +## Participating Registries -| Category | Methodology | Developer | Approval Date | -| ------------------ | ------------------------------------------------ | -------------- | ------------ | -| (Pending) | | | | +| Name | Company | Description | +| ---------------------------------------- | -------------------| ------------------------------------------ | +|[WEATS](https://www.wattcarbon.com/weats) | WattCarbon | WattCarbon Energy Attribute Tracking System | diff --git a/approved_documents/methodologies/.gitkeep b/approved_documents/methodologies/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/hourly-grid-emissions.md b/hourly-grid-emissions.md deleted file mode 100644 index 9e5b045..0000000 --- a/hourly-grid-emissions.md +++ /dev/null @@ -1,99 +0,0 @@ -## **Calculating Hourly Emissions** - - -### **Overview of locational emissions methodology.** - -1.1. Model intuition. - -1.1.1. A site receives electricity from the grid to which it is interconnected. The source of this electricity comes from a variety of power plants that are dispatched according to contracts and bidding mechanisms established by the balancing authority. The site operator can choose to consume or not consume electricity during a particular period of time, but does not have control over the source of electricity provided by the grid operator. - -1.2. Foundations in literature. Modeling does not strictly adhere to these methods, but draws from them for inspiration. - -1.2.1. World Resources Institute GHG Emissions Scope 2 Emissions Protocol. - -1.2.2. Energy Tag. - -1.2.3. 24/7 Carbon Free Energy Compact. - -1.3. Annual emissions are calculated for the 365 days immediately prior to the reporting period end date, provided the data sufficiency criteria are met. - -1.4. Follow the process outlined below and detailed in subsequent sections: - -1.4.1. Select and qualify sites and assets. Emissions should be calculated on a site-level basis, but may be aggregated across sites in a subsequent process. - -1.4.2. Use hourly emissions factors from matched balancing authority. - -1.4.3. Align timestamps of site-level energy consumption to equivalent timestamps of power systems data. - -1.4.4. Compute all hourly emissions values by multiplying hourly consumption by the associated grid emissions value. - -1.4.5. Sum each hourly value. - -1.4.6. Aggregate across sites. - - -### **2. Portfolio aggregation.** - -2.1. In accordance with existing standards, all qualifying sites should be selected for inclusion in the aggregated portfolio. - -2.1.1. In cases where some site consumption is associated with an owner and other consumption is associated with a tenant (thus becoming a Scope 3 emission), it is reasonable to subdivide the emissions from a single site into multiple (exclusive) aggregations. - -2.1.2. If some sites that would be included in a portfolio lack the quality of data of other sites, all sites should be included, but the data limitations should be called out (see methods for estimating hourly consumption using data models). - -2.2. Constraints and qualification. - -2.2.1. Energy attribute purchases may be included in a portfolio aggregation. Non-energy attribute purchases should be accounted for elsewhere. - - -### **3. Use Hourly Emissions factors from matching balancing authority.** - -3.1. Basic structure applies to analysis using both actual and modeled energy consumption. - -3.1.1. Carbon emissions: weighted average of operational emissions from each fuel dispatched during a particular time period on a grid. - -3.1.2. Produced electricity mix: The aggregate amount of electricity dispatched onto a grid from power plants within a particular balancing authority. This number does not include imports or exports to/from neighboring balancing authorities. - -3.1.3. Consumed electricity mix: The aggregate amount of electricity consumed within a grid including power dispatched from power plants within the grid and any imported power from neighboring grids and excluding any power exported to neighboring grids. - -3.2. When calculating emissions for a site, the emissions factor of the Consumed electricity mix should be used. - -3.2.1. If calculating negative emissions from distributed generation, the Consumed electricity mix should be used. - -3.2.1. If calculating negative emissions from generation that is managed by the balancing authority, Produced electricity mix should be used. - -3.3. Equation: Annual emissions = sum of hourly energy use multiplied by emissions factor. - - -### **4. Align timestamps.** - -4.1. All time series data should be consistently formatted such that a time stamp indicates the beginning of a known length of time (e.g., 7:00 AM indicates the period between 7:00 and 8:00 AM). - -4.2. Time series data should be upsampled to create a consistent hourly time-series for both consumption and power systems data. - -4.3. If any data is in local time, it should be converted to UTC prior to computing hourly emissions. - -4.4. Upon calculating hourly emissions, time stamps should be converted to the local time of the site prior to aggregation with other sites. - -4.4.1. All aggregation should be done in the local time zone. For example, if there are two sites, one a site in Eastern Standard Time and the other a site in Pacific Standard time, they should have their noon (local time) carbon emissions aggregated. - - -### **5. Compute all Hourly Emissions.** - -5.1. For each hour, multiply the site consumption value by the appropriate emissions factor. - -5.1.1. Missing consumption grid emissions values should be filled in with average of non-missing values for the preceding and subsequent interval. - -5.1.2. If hourly grid emissions factors are calculated by averaging higher frequency data, no more than 50% of high-frequency values should be missing. - -5.1.3. Missing consumption values should be filled in with average of non-missing values for the preceding and subsequent interval. - -5.1.4. Data is considered missing if it is clearly marked by the data provider as NULL, NaN, or similar. - - -### **6. Annual Aggregation.** - -6.1. The product of each hour’s carbon emissions calculation should be summed for the reporting time period (typically annually). - -6.2. If data sufficiency requirements have been met (see 2.2), total emissions should be normalized to a full year (8,760 hours) for reporting purposes. - -6.2.1. Sum the total emissions of each hourly value. Divide by the number of valid hours in the dataset. Multiply by 8760. diff --git a/methodologies/solar/.gitkeep b/methodologies/solar/.gitkeep new file mode 100644 index 0000000..e69de29