diff --git a/website/index.md b/website/index.md index 461bb00..87055ba 100644 --- a/website/index.md +++ b/website/index.md @@ -8,25 +8,19 @@ meta_description: Linux Foundation Energy - Connected Data Specifications (CDS) # Customer Data Working Group (WG3) -This is the homepage of the [Customer Data Working Group (WG3)](https://github.com/lfe-cds/CDS-Customer-Data), -part of the -[Connected Data Specifications (CDS)](https://cds.lfenergy.org/), -an [LF Energy](https://www.lfenergy.org/) project. +This is the homepage of the [Customer Data Working Group (WG3)](https://github.com/lfe-cds/CDS-Customer-Data), part of the [Connected Data Specifications (CDS)](https://cds.lfenergy.org/), an [LF Energy](https://www.lfenergy.org/) project. ## Scope -This working group focuses on writing free, open specifications for providing utility customer data access, -in order to facilitate carbon emissions calculations and decarbonization efforts. +This working group focuses on writing free, open specifications for providing utility customer data access, in order to facilitate energy management, reporting, and projects. ## Use Cases -We have defined several broad categories of [use cases]({{ "/use-cases" | relative_url }}) we will focus on addressing, -along with what customer data types and functionalities will need to be specified to accommodate -those use cases. +We have defined several broad categories of [use cases]({{ "/use-cases" | relative_url }}) we will focus on addressing, along with what customer data types and functionalities will need to be specified to accommodate those use cases. -* `Use Case 1` - [Carbon Accounting]({{ "/use-cases" | relative_url }}#use-case-carbon-accounting) -* `Use Case 2` - [Decarbonization Projects]({{ "/use-cases" | relative_url }}#use-case-decarbonization-projects) -* `Use Case 3` - [Distributed Grid Flexibility]({{ "/use-cases" | relative_url }}#use-case-distributed-flexibility) +* `Use Case 1` - [Energy Management]({{ "/use-cases" | relative_url }}#use-case-energy-management) +* `Use Case 2` - [Energy Projects]({{ "/use-cases" | relative_url }}#use-case-energy-projects) +* `Use Case 3` - [Grid Flexibility]({{ "/use-cases" | relative_url }}#use-case-grid-flexibility) * `Use Case 4` - [Building Benchmarking]({{ "/use-cases" | relative_url }}#use-case-benchmarking) We've also made a list of what data and functionality is specifically [not in scope]({{ "/use-cases" | relative_url }}#not-in-scope). diff --git a/website/specs/design-principles.md b/website/specs/design-principles.md index 2beb829..f7fc194 100644 --- a/website/specs/design-principles.md +++ b/website/specs/design-principles.md @@ -34,52 +34,35 @@ principles that help guide our choices as a working group. ## Principle 1: Be Accessible -The carbon and energy transition sectors have and will, for the foreseeable -future, experience massive growth. This means those working on our target -[Use Cases]({{ '/use-cases' | relative_url }}) will generally always have -more new people than experienced people. +The energy ecosystem have and will, for the foreseeable future, experience massive growth. +This means those working on our target [Use Cases]({{ '/use-cases' | relative_url }}) will generally always have more new people than experienced people. -Given this bias towards new users, we must design our materials with a focus -on making it easy for new users to learn our specifications. This principle is -prioritized over following established precedents when those prior precedents -are not accessible to new users. +Given this bias towards new users, we must design our materials with a focus on making it easy for new users to learn our specifications. +This principle is prioritized over following established precedents when those prior precedents are not accessible to new users. -Below are some specific guidelines of how this principle manifests in our -working group: +Below are some specific guidelines of how this principle manifests in our working group: ### Make specifications free and easily referenced -Our [specifications]({{ '/specs' | relative_url }}) will be published online for -free and can be viewed by anyone without registration or payment. +Our [specifications]({{ '/specs' | relative_url }}) will be published online for free and can be viewed by anyone without registration or payment. -Additionally, each section of specifications and documentation will have permalinks, -so that users can directly link to the specific part that they want to reference. +Additionally, each section of specifications and documentation will have permalinks, so that users can directly link to the specific part that they want to reference. ### Make ample complementary documentation and materials By definition, our specifications must be comprehensive and, well, _specific_. -This unfortunately means that the specifications themselves are complex and are -probably not the most immediately readable thing for a new user. +This unfortunately means that the specifications themselves are complex and are probably not the most immediately readable thing for a new user. -So, in addition to publishing our official specifications, we must make an effort -to complement them with additional documentation and other materials that help -introduce new users to the specifications, answer common questions, and provide -examples and tutorials. +So, in addition to publishing our official specifications, we must make an effort to complement them with additional documentation and other materials that help introduce new users to the specifications, answer common questions, and provide examples and tutorials. ### Make APIs and data structures easily understood by humans -Before a new user writes any client integration, they will typically first -explore the documentation, examples, and tutorials to try to get familiar -with how the various APIs, data models, and behaviors are structured. We want -this initial exploring experience to be intuitive and require minimal time to -get a basic understanding of how things work. +Before a new user writes any client integration, they will typically first explore the documentation, examples, and tutorials to try to get familiar with how the various APIs, data models, and behaviors are structured. +We want this initial exploring experience to be intuitive and require minimal time to get a basic understanding of how things work. -To aid in that effort, we will be preferring simple, easy-to-understand, and -human-readable field names and enumerations in our data models and API endpoints. -This strategy prevents new users during their initial exploration from constantly -having to go back and look up what various values mean. A new user should not -have to write a line of code or install a mapping/lookup tool to achieve a basic -familiarity with our specifications. +To aid in that effort, we will be preferring simple, easy-to-understand, and human-readable field names and enumerations in our data models and API endpoints. +This strategy prevents new users during their initial exploration from constantly having to go back and look up what various values mean. +A new user should not have to write a line of code or install a mapping/lookup tool to achieve a basic familiarity with our specifications. Examples of preferred naming conventions: * `"id": "123456"` is preferred over `"objectEntryId": "123456"` (this is an unnecessarily complex field name) @@ -91,45 +74,27 @@ Examples of preferred naming conventions: ## Principle 2: Be Useful -Our goal is to have our specifications be adopted and used widely to address -our target [Use Cases]({{ "/use-cases" | relative_url }}). This means we must -write our specifications in such a way that when implmented will actually be -useful to the target organizations, communities, regulators, and stakeholders. +Our goal is to have our specifications be adopted and used widely to address our target [Use Cases]({{ "/use-cases" | relative_url }}). +This means we must write our specifications in such a way that when implmented will actually be useful to the target organizations, communities, regulators, and stakeholders. Below are some strategies we will be using to ensure our specifications are useful: ### Focus on end users -Our specifications will define how a server must operate so that a client user -can integrate with it to access customer data, as well as how customers will -interact with the server to review and approve data access requests from client -users. +Our specifications will define how a server must operate so that a client user can integrate with it to access customer data, as well as how customers will interact with the server to review and approve data access requests from client users. -In this situation, a common risk is to start losing track of the needs and -preferences of the end users and trend towards biasing design decisions towards -the preferences and conveniences of the server implementers and operators, -even when those decisions reduce the usefulness or user-friendliness to end -users (both third parties and utility customers). +In this situation, a common risk is to start losing track of the needs and preferences of the end users and trend towards biasing design decisions towards the preferences and conveniences of the server implementers and operators, even when those decisions reduce the usefulness or user-friendliness to end users (both third parties and utility customers). -To mitigate this risk we must structure our discussion and decision making -process with end user preferences as having priority over server implementer -preferences. As with many things, decisions will be a balancing act of -interests, but we must always evaluate our decisions with a preference to -accomodating the end users' needs wherever possible. +To mitigate this risk we must structure our discussion and decision making process with end user preferences as having priority over server implementer preferences. +As with many things, decisions will be a balancing act of interests, but we must always evaluate our decisions with a preference to accomodating the end users' needs wherever possible. ### Include sanity checks -Another common risk when writing specifications is losing track of the needs -and preferences of the majority of end users because much of the time in -writing specifications is thinking about how to handle edge cases. If we are -not careful, we could end up with specifications the overly focus on edge -cases and not the primary user stories. +Another common risk when writing specifications is losing track of the needs and preferences of the majority of end users because much of the time in writing specifications is thinking about how to handle edge cases. +If we are not careful, we could end up with specifications the overly focus on edge cases and not the primary user stories. -To mitigate this risk, we must include in our discussions and processes -"sanity checks" where we take a step back and re-evaluate our current drafts -and decisions against the common use cases and user stories we are trying -to address. These sanity checks can help us recognize when we are starting -to lose track of our main target users' experiences. +To mitigate this risk, we must include in our discussions and processes "sanity checks" where we take a step back and re-evaluate our current drafts and decisions against the common use cases and user stories we are trying to address. +These sanity checks can help us recognize when we are starting to lose track of our main target users' experiences. Sanity checks can include the following exercises: * Writing down a specific user story that is a target use case and evaluating it against our specifications @@ -138,105 +103,59 @@ Sanity checks can include the following exercises: ### Write open source test suites -In the same spirit of performing sanity checks for our specifications, -we must also remember that our specifications will be implemented in the -real world and used by real users. +In the same spirit of performing sanity checks for our specifications, we must also remember that our specifications will be implemented in the real world and used by real users. -To ensure that server implementations in the real world match our -specifications, we must additionally develop a suite of both automated -and manual tests that can be performed against demo and production -server implementations to evaluate how closely they follow our -specifications and how useful they are for end users. +To ensure that server implementations in the real world match our specifications, we must additionally develop a suite of both automated and manual tests that can be performed against demo and production server implementations to evaluate how closely they follow our specifications and how useful they are for end users. -These test suites must be freely available, including access to any source -code for automated test suites, under open source licenses. By being -transparent with our testing procedures, both end users and server -implementers can inspect and suggest improvements to the various test -suites that we will maintain. +These test suites must be freely available, including access to any source code for automated test suites, under open source licenses. +By being transparent with our testing procedures, both end users and server implementers can inspect and suggest improvements to the various test suites that we will maintain. --- ## Principle 3: Be Realistic -The carbon accounting and energy industries are huge, complicated, and -have a large diversity of regulatory constructs and business models. -Sometimes, major groups and incentives in these industries will not -necessarily align with our goals and [Use Cases]({{ '/use-cases' | relative_url }}). +The energy ecosystem is huge, complicated, and have a large diversity of regulatory constructs and business models. +Sometimes, major groups and incentives in these industries will not necessarily align with our goals and [Use Cases]({{ '/use-cases' | relative_url }}). -There could very well be significant resistance to implementations -of our specifications, because some organizations, utilities, and -potentially even entire sectors are incentivized in ways that are at odds -with our goals and use cases. +There could very well be significant resistance to implementations of our specifications, because some organizations, utilities, and potentially even entire sectors are incentivized in ways that are at odds with our goals and use cases. -Therefore, we must be realistic about the policy environment and real -world incentives when designing our specifications, so that they will still -be widely adopted and useful to our use cases. Below are some specific -actions we must take to successfully navigate the energy landscape. +Therefore, we must be realistic about the policy environment and real world incentives when designing our specifications, so that they will still be widely adopted and useful to our use cases. +Below are some specific actions we must take to successfully navigate the energy landscape. ### Don't assume a motivated implementer -In some jurisdictions, it is possible that a utility may be ordered -to implement our specifications by their regulator, despite the -utility's objections and resistance. +In some jurisdictions, it is possible that a utility may be ordered to implement our specifications by their regulator, despite the utility's objections and resistance. -In these situations, the server operator (e.g. the utility) will be -tasked with creating an implementation of our specifications even -though they are not strongly incentivized to make it highly useful. +In these situations, the server operator (e.g. the utility) will be tasked with creating an implementation of our specifications even though they are not strongly incentivized to make it highly useful. -We must design our specifications with the realistic point of view -that it may need to be implemented by organizations that are not -strongly motivated to create a highly useful implementation, or are -even "acting in bad faith" when implementing our specifications in -an attempt to, indirectly or actively, prevent the implementation -from gaining adoption or reaching its full potential. +We must design our specifications with the realistic point of view that it may need to be implemented by organizations that are not strongly motivated to create a highly useful implementation, or are even "acting in bad faith" when implementing our specifications in an attempt to, indirectly or actively, prevent the implementation from gaining adoption or reaching its full potential. ### Create materials and guidance for regulators -The energy utility sector is typically regulated by local, state, -and federal governments, which means that many server implementers -will be utilities or other central authorities who need to get -approval from their regulators before implementing our specifications. +The energy utility sector is typically regulated by local, state, and federal governments, which means that many server implementers will be utilities or other central authorities who need to get approval from their regulators before implementing our specifications. -To assist in educating, facilitating, and streamlining these -regulatory requests for implementing our specifications, we must -create regulatory informational and guidance materials the focus -on regulatory and governance bodies as the target audience. +To assist in educating, facilitating, and streamlining these regulatory requests for implementing our specifications, we must create regulatory informational and guidance materials the focus on regulatory and governance bodies as the target audience. -This category is similar the first design principle's guideline -of [creating ample complementary documentation](#ample-documentation), -only for the purpose of increasing accessibility for regulators and -policy makers. +This category is similar the first design principle's guideline of [creating ample complementary documentation](#ample-documentation), only for the purpose of increasing accessibility for regulators and policy makers. --- ## Principle 4: Be Adaptable -The energy and carbon accounting sectors are constantly evolving, -with new technologies, methods, and requirements emerging frequently. -To ensure the longevity and relevance of our specifications, we must -design them to be adaptable and responsive to changes in these sectors. +The energy ecosystem is constantly evolving, with new technologies, methods, and requirements emerging frequently. +To ensure the longevity and relevance of our specifications, we must design them to be adaptable and responsive to changes in these sectors. ### Build in flexibility -We must design our specifications to be flexible and extensible, allowing -for the addition of new features and functionality over time without -requiring significant changes to existing implementations (i.e. try -to be backwards compatible). This includes using modular designs and -providing clear guidance on how extensions can be integrated into -the core specifications. +We must design our specifications to be flexible and extensible, allowing for the addition of new features and functionality over time without requiring significant changes to existing implementations (i.e. try to be backwards compatible). +This includes using modular designs and providing clear guidance on how extensions can be integrated into the core specifications. ### Encourage feedback and contributions -We must promote an open and inclusive community that encourages -feedback and contributions from a wide range of stakeholders. By -actively soliciting input and engaging with different perspectives, -we can ensure that our specifications remain relevant and useful in -a changing landscape. +We must promote an open and inclusive community that encourages feedback and contributions from a wide range of stakeholders. +By actively soliciting input and engaging with different perspectives, we can ensure that our specifications remain relevant and useful in a changing landscape. ### Regularly review and update -We must establish a process for regular review and updates to the -specifications to ensure they remain aligned with the latest -developments in the energy and carbon accounting sectors. This -includes monitoring changes in related standards and best practices, -as well as incorporating feedback from the user community. +We must establish a process for regular review and updates to the specifications to ensure they remain aligned with the latest developments in the energy and carbon accounting sectors. +This includes monitoring changes in related standards and best practices, as well as incorporating feedback from the user community. diff --git a/website/use-cases.md b/website/use-cases.md index d56bdcf..25b58db 100644 --- a/website/use-cases.md +++ b/website/use-cases.md @@ -11,70 +11,42 @@ meta_description: What are the use cases that the CDS Customer Data specificatio These are the use cases that this working group is writing specifications to address. -## Use Case 1: Carbon Accounting +## Use Case 1: Energy Management -Many companies, organizations, and governments around the world are working to -measure and track their carbon emissions. This is called -[carbon accounting](https://en.wikipedia.org/wiki/Carbon_accounting). +Many companies, organizations, and governments around the world are working to measure and track their energy usage and costs. +This is called [energy management](https://en.wikipedia.org/wiki/Energy_management_system_(building_management)). -While carbon accounting analyses vary widely, most of these procedures -for calculating carbon emissions involve obtaining customer utility data, -such as electric and natural gas usage, meter locations, rate plans, etc. +While energy management analyses vary widely, most of these procedures for calculating results involve obtaining customer utility data, such as electric and natural gas usage, meter locations, rate plans, etc. #### Needs: * **Standardized Data Formats and Access Procedures:** -This data often needs to be gathered both as historical data -(e.g. getting the past year of usage data for a historical analysis) -and ongoing data (e.g. getting the past day's usage for real-time tracking -of emissions). To address this need, the specifications from this working -group will establish standardized data formats and access procedures so that -data can be easily obtained, analyzed, and combined from multiple sources -(e.g. companies with buildings in multiple utility territories). +This data often needs to be gathered both as historical data (e.g. getting the past year of usage data for a historical analysis) and ongoing data (e.g. getting the past day's usage for real-time tracking of energy usage). +To address this need, the specifications from this working group will establish standardized data formats and access procedures so that data can be easily obtained, analyzed, and combined from multiple sources (e.g. companies with buildings in multiple utility territories). * **Standardized Customer Datasets:** -In order to perform the needed calculations for carbon accounting and -other Use Cases, a comprehensive dataset with the appropriate data fields -must be provided. Which data fields, granularity, and time periods are -needed are highly use-case dependent, but without requirements to follow, -utilities may not provide access to adequate datasets to satisfy an intended -use case's needs. Thus, specifications to address this use case must consider -what specific datasets are required for common use cases in addition to how -the data should be formatted and accessed. +In order to perform the needed calculations for energy management and other Use Cases, a comprehensive dataset with the appropriate data fields must be provided. +Which data fields, granularity, and time periods are needed are highly use-case dependent, but without requirements to follow, utilities may not provide access to adequate datasets to satisfy an intended use case's needs. +Thus, specifications to address this use case must consider what specific datasets are required for common use cases in addition to how the data should be formatted and accessed. * **Granular Certification Data:** -Granular certificates are an important decarbonization tool for applications -such as tracking 24/7 carbon-free energy matching and creating market signals -to stimulate investment in new clean technologies. Granular certification -depends on streamlined and scalable access to granular generation data from -clean energy projects (for example, from wholesale power purchase agreements) -and charge / discharge data from in-front-of-the-meter storage assets. -To address this use case, the specifications must consider how to obtain -(revenue grade) metered generation data from individual asset owners in a -centralized and secure manner. +As a component energy management, carbon emissions is often monitored and reported in order to meet regulatory requirements or corporate policies. +As part of tracking emissions, granular certificates are an important tool for applications such as 24/7 energy matching and creating market signals to stimulate investment in new technologies. +Granular certification depends on streamlined and scalable access to granular generation data from clean energy projects (for example, from wholesale power purchase agreements) and charge / discharge data from in-front-of-the-meter storage assets. +To address this use case, the specifications must consider how to obtain (revenue grade) metered generation data from individual asset owners in a centralized and secure manner. * **Privacy, Consent, and Security:** -Since carbon accounting is typically for specific entities, -the actual utility data of that specific entity is required to perform -carbon accounting calculations (e.g. the actual kwh usage, meter locations, -and rate plans for the customer for the past 12 months). This data is -typcially considered private information, so specifications to address this -use case must consider privacy, consent, and security requirements as part -of the scope of work. +Since energy management is typically for specific entities, the actual utility data of that specific entity is required to perform calculations (e.g. the actual kwh usage, meter locations, and rate plans for the customer for the past 12 months). +This data is typcially considered private information, so specifications to address this use case must consider privacy, consent, and security requirements as part of the scope of work. * **Streamlined User Experience:** -Many organizations do not have dedicated staff or sufficient resources -to spend large amounts of time and effort gathering utility data needed -for carbon accounting calculations. This effectively creates a -"barrier to entry" that limits carbon accounting to only the most well-resourced -organizations and prevents widespread adoption of decarbonization goals. -Thus, in order to address this use case adequately, the specifications -for this working group must consider user experience and performance -to allow for easy, streamlined customer utility data access. +Many organizations do not have dedicated staff or sufficient resources to spend large amounts of time and effort gathering utility data needed for energy management. +This effectively creates a "barrier to entry" that limits energy management to only the most well-resourced organizations and prevents widespread completion of energy efficiency goals. +Thus, in order to address this use case adequately, the specifications for this working group must consider user experience and performance to allow for easy, streamlined customer utility data access. #### Examples of users in this use case: -* Platforms that assess carbon emissions for enterprises ( +* Platforms that perform energy analyses for enterprises ( [WattCarbon](https://www.wattcarbon.com/), [FlexiDAO](https://www.flexidao.com/), [Microsoft Cloud for Sustainability](https://www.microsoft.com/en-us/sustainability), @@ -83,93 +55,54 @@ etc.) * Organizations looking to adopt the [24/7 Carbon-free Energy Compact](https://gocarbonfree247.com/) and other [ESG](https://en.wikipedia.org/wiki/Environmental%2C_social_and_corporate_governance) pledges -* Organizations that have pledged to be carbon free ( -[Google](https://www.google.com/about/datacenters/cleanenergy/), -[Apple](https://www.apple.com/newsroom/2020/07/apple-commits-to-be-100-percent-carbon-neutral-for-its-supply-chain-and-products-by-2030/), -[Microsoft](https://www.microsoft.com/en-us/corporate-responsibility/sustainability/operations), -etc.) - * Consultants and advisors helping organizations that have climate and decarbonization targets -## Use Case 2: Decarbonization Projects +## Use Case 2: Energy Projects -Often, organizations with decarbonization targets (see [Use Case 1: Carbon Accounting](#use-case-carbon-accounting) above), -will evaluate projects that may positively impact their carbon emissions. These projects -can range from physical locally (e.g. installing solar or EV charging) and remote (e.g. -building renewable generation projects via wholesale power purchase agreements), to virtual -direct (e.g. avoided emissions by managing building usage dynamically) or financial -(e.g. switching rate plans to carbon free sources or community solar). +Often, organizations with energy management targets (see [Use Case 1: Energy Management](#use-case-energy-management) above), will evaluate projects that may optimize their energy usage or costs. +These projects can range from physical locally (e.g. installing solar or EV charging) and remote (e.g. building renewable generation projects via wholesale power purchase agreements), to virtual direct (e.g. avoided costs by managing building usage dynamically) or financial (e.g. switching rate plans to more beneficial rates or suppliers). #### Needs: * **Use Case 1 Needs:** -Like carbon accounting, the calculations for assessing decarbonization -projects typcially require the specific utility data for a specific entity. -So, all of the needs for carbon accounting often are needed for assessing -decarbonization projects, both for the initial feasibility analysis and -ongoing project measurement and verification ([M&V](https://en.wikipedia.org/wiki/Measurement_and_Verification)). +Like energy management, the calculations for assessing energy projects typcially require the specific utility data for a specific entity. +So, all of the needs for energy management often are needed for assessing energy projects, both for the initial feasibility analysis and ongoing project measurement and verification ([M&V](https://en.wikipedia.org/wiki/Measurement_and_Verification)). * **Utility Bill and Cost Breakdowns:** -Decarbonization projects are frequently analyzed based on financial -payback or savings calculations (e.g. converting a fleet of company -vehicles to EVs would remove gasoline costs while incurring more -electricity costs). Thus, to address this use case the specifications -must consider how to obtain customer utility bill and cost breakdown -information so that these complex financial analyses can be performed, -both for initial financial analysis and ongoing cost monitoring. +Energy projects are frequently analyzed based on financial payback or savings calculations (e.g. converting a fleet of company vehicles to EVs would remove gasoline costs while incurring more electricity costs). +Thus, to address this use case the specifications must consider how to obtain customer utility bill and cost breakdown information so that these complex financial analyses can be performed, both for initial financial analysis and ongoing cost monitoring. #### Examples of users in this use case: -* Property owners looking to install decarbonization projects on their properties (EV charging, -distributed solar, etc.) - -* Contractors, vendors, consultants, and advisors who work with property owners with decarbonization projects -(EV charging vendors, solar installers, ESCOs, etc.) +* Property owners looking to install smart energy components at their properties (EV charging, distributed solar, etc.) -* Building control and energy management systems that dynamically modify the behavior of equipment based -on carbon impact or customer savings (demand charge reduction via batteries, dynamic EV charging, HVAC controls, etc.) +* Contractors, vendors, consultants, and advisors who work with property owners on energy-related projects (EV charging vendors, solar installers, ESCOs, etc.) -* Platforms and firms that analyze customer rate plan options to maximize carbon impact (community solar, -direct power purchase agreements, etc.) +* Building control and energy management systems that dynamically modify the behavior of equipment based on energy use impact or customer savings (demand charge reduction via batteries, dynamic EV charging, HVAC controls, etc.) -* Negative emissions projects (e.g. direct air capture) that need to monitor and measure their customer's -net emissions related to the project. +* Platforms and firms that analyze customer rate plan options to maximize customer savings and goals (time-of-use, community solar, direct power purchase agreements, etc.) -## Use Case 3: Distributed Grid Flexibility +## Use Case 3: Grid Flexibility *"In the past, we would forecast load and deploy generation. In the future, we will forecast generation and deploy load." -overheard at utility conference* -While the first two use cases focus on individual entities' carbon impact, -as more and more non-dispatchable renewables get deployed, the grid will -increasingly need sources of dynamic load flexibility to partially address -the intermittency of solar and wind generation. Technologies to allow for -higher and higher penetration of renewables on the grid can often be installed -"behind the meter" as distributed energy resources (DERs). +While the first two use cases focus on individual entities' energy footprint, as more and more non-dispatchable renewables get deployed, the grid will increasingly need sources of dynamic load flexibility to partially address the intermittency of solar and wind generation. +Technologies to allow for higher and higher penetration of renewables on the grid can often be installed "behind the meter" as distributed energy resources (DERs). -While these technologies do not directly decarbonize the grid, they allow for -higher penetration of cheap, zero carbon renewables. Thus, this working group -considers grid flexibility and load management technologies a key use case -for bolstering decarbonization efforts. +While these technologies do not directly reduce emissions, they allow for higher penetration of new, clean energy technologies. +Thus, this working group considers grid flexibility and load management technologies a key use case for bolstering energy management efforts. #### Needs: * **Use Case 1 Needs:** -Like carbon accounting, the calculations for assessing the eligibility of -deploying or using a distributed grid flexibility or load management technology -typically requires the specific utility data for a specific entity. -So, all of the needs for carbon accounting often are needed for assessing -distributed grid flexibility technologies, both for the initial feasibility -analysis and ongoing measurement and verification ([M&V](https://en.wikipedia.org/wiki/Measurement_and_Verification)). +Like energy management, the calculations for assessing the eligibility of deploying or using a distributed grid flexibility or load management technology typically requires the specific utility data for a specific entity. +So, all of the needs for energy management often are needed for assessing distributed grid flexibility technologies, both for the initial feasibility analysis and ongoing measurement and verification ([M&V](https://en.wikipedia.org/wiki/Measurement_and_Verification)). * **Program Eligibility and Participation Information:** -Because distributed grid flexibility and load management technologies are active -participants in managing load on the electrical grid, they often are registered -as part of a utility or central operator program (e.g. demand response programs). -Thus, the specifications to address this use case must consider how to include -program eligibility and participation details as part of the standardized customer -dataset. +Because distributed grid flexibility and load management technologies are active participants in managing load on the electrical grid, they often are registered as part of a utility or central operator program (e.g. demand response programs). +Thus, the specifications to address this use case must consider how to include program eligibility and participation details as part of the standardized customer dataset. #### Examples of users in this use case: @@ -181,56 +114,34 @@ etc.) * DER aggregators that manage collections of distributed resources and participate in grid events and markets ( [OhmConnect](https://www.ohmconnect.com/), -[Enel X](https://www.enelx.com/n-a/en), +[Enel Demand Response](https://www.enelnorthamerica.com/solutions/energy-solutions/demand-response), etc.) -* Apps and devices that monitor grid conditions and control DERs and IoT prevent additional -carbon-intensive generation from coming online (e.g. avoided emissions). +* Apps and devices that monitor grid conditions and control DERs and IoT prevent additional generation resources from coming online (e.g. avoided emissions). -* Utilities needing to standardize customer data access and sharing across multiple divisions -within the utility itself, between internal vendors, or with utility program implementers -(energy efficiency rebate programs, building electrification initiatives, etc.). +* Utilities needing to standardize customer data access and sharing across multiple divisions within the utility itself, between internal vendors, or with utility program implementers (energy efficiency rebate programs, building electrification initiatives, etc.). ## Use Case 4: Building Benchmarking -Municipalities and governments are increasingly requiring that building owners submit -whole-building energy usage information in order to do carbon accounting and measure -building energy efficiency for their jurisdiction. +Municipalities and governments are increasingly requiring that building owners submit whole-building energy usage information in order to do regional energy reporting and measure building energy efficiency for their jurisdiction. #### Needs: * **Standardized Whole-Building Data Formats:** -Whole-building usage data needed to perform building benchmarking calculations -is similar to Use Case 1: Carbon Accounting, only usage can be aggregated over -multiple usage points and be provided as a single combined reading. Thus, -the specifications to address benchmarkings must consider how to appropriately -define how data is being aggregated, and where necessary provide meta data -on the underlying individual components that were used to create the whole-building -aggregate usage values. +Whole-building usage data needed to perform building benchmarking calculations is similar to Use Case 1: Energy Management, only usage can be aggregated over multiple usage points and be provided as a single combined reading. +Thus, the specifications to address benchmarkings must consider how to appropriately define how data is being aggregated, and where necessary provide meta data on the underlying individual components that were used to create the whole-building aggregate usage values. * **Streamlined Data Request and Access Procedures:** -Unlike individual customer data requests, which are typically sent to and -approved by individual customers, benchmarking data requests are typically -sent to and approved by the utility directly. This means the dynamics and requirements -of a "data request" changes for this Use Case. Thus, specifications that address -this use case must consider how to best structure user data requests submissions -directly to utilities rather than individual customers. Additionally, -specifications must consider that when a data request is approved, what -data access procedures will be used, and will they be different from data -access procedures from the other Use Cases. +Unlike individual customer data requests, which are typically sent to and approved by individual customers, benchmarking data requests are typically sent to and approved by the utility directly. +This means the dynamics and requirements of a "data request" changes for this Use Case. +Thus, specifications that address this use case must consider how to best structure user data requests submissions directly to utilities rather than individual customers. +Additionally, specifications must consider that when a data request is approved, what data access procedures will be used, and will they be different from data access procedures from the other Use Cases. * **Privacy and Consent Requirements:** -While individual customer data access frequently requires first obtaining -consent from the customer. Jurisdictions requiring whole-building data access -often specify thresholds over which individual customer consent is not -required to obtain whole-building usage data (e.g. if any individual -customer's usage is no more than 15% of the whole-building usage). If -whole-building usage is under these thresholds, however, individual customer -consent will still be required for each building tenant. Thus, specifications -addressing this use case must consider how to incorporate customer consent -thresholds for whole-building access, and like the other use cases, the -process by which users may request and obtain customer consent when required. +While individual customer data access frequently requires first obtaining consent from the customer, jurisdictions requiring whole-building data access often specify thresholds over which individual customer consent is not required to obtain whole-building usage data (e.g. if any individual customer's usage is no more than 15% of the whole-building usage). +If whole-building usage is under these thresholds, however, individual customer consent will still be required for each building tenant. +Thus, specifications addressing this use case must consider how to incorporate customer consent thresholds for whole-building access, and like the other use cases, the process by which users may request and obtain customer consent when required. #### Examples of users in this use case: