 Hi, this is Yoho Sapin Bhartia and welcome to a brand new episode of the State of Energy. And today we have with us Daniel Restler, maintainer of the Customer Data Working Group at ElefEnergy and also his CTO at Utility API. Daniel, it's great to have you on the show. Howdy. It's great to be here. Let's talk about this working group. ElefEnergy, like many other Linux foundation projects, has many different working groups. What is the focus of this specific working group? The Customer Data Working Group at ElefEnergy focuses on specifying a streamlined process for requesting and obtaining customer utility usage data. That data is needed in order to calculate the carbon impact of a customer. So if you are a business and you're looking to measure your carbon footprint for your own reporting purposes or for government mandated carbon reporting, you need to obtain the usage information from your utility account in order to calculate that. And this Customer Data Working Group is specifying the methods by which utilities can provide that information. Can you talk a bit about what exactly is the carbon data specification and how is it being used across industries? So the carbon data specification is an initiative by ElefEnergy to have an open set of specifications and procedures and methods to further accelerate the calculation of carbon intensity for various customers. And so if you are a company and you are looking to do what is called carbon accounting where you're keeping track of your carbon emissions, for example your Scope 2 or Scope 3 emissions, the carbon data specification is a set of open specifications that can be used to facilitate tabulating those calculations. And so for example, if you need to get the grid information for how carbon intensive the grid is at a particular time, you can obtain that information via this set of specifications and if you need to get your own data or the data of a client, you can get that using the customer data specifications. And so it's really helping facilitate and foster the environment for more wide scale adoption of carbon accounting practices. What was the need for this project? What was missing from the ecosystem that there was a need for this project? So the origin of the project is that up to now there has not been a set of open specifications around carbon accounting. It's been generally proprietary implementations and specifications and calculation methodologies to tabulate carbon intensity and carbon emissions for things like Scope 2 and Scope 3 emissions, for ESG reporting and for other sorts of carbon intensity and carbon mitigation practices. And so the LF Energy, the Linux Foundation started as part of the LF Energy organization to basically create a set of open specifications that anybody can use and work with to start to harden or better have more mature practices around Scope 2 emissions and Scope 3 emissions reporting. And so that's where this started is from the need of starting to move away from individual proprietary calculation methodologies and move into the practice of having an open set of specifications for carbon accounting. Let's talk about the origin of the project, who all were involved, how this project came to exist. I was originally brought into the project with a couple of industry players, accompanied by the name of Wat Carbon. It initially reached out to me and invited Utility API, my company to the project. And so we joined about a year ago in order to help specify the customer data part of the specifications. Utility API has a huge amount of experience in providing authorization driven customer data access in the US and Canada. And so we are kind of, we have participated in multiple regulatory proceedings, as well as developing the customer data access solutions for multiple utilities in the United States. LF Energy is an international organization. And so there's quite a few participants from Europe and other parts of the world that are kind of coming together. And so we're contributing from the perspective of North America. However, we do see quite a bit of participation from Europe as well. LF Energy is a new but growing community. It's a very diverse community. Can you talk about what kind of communities are on this specific project? So the exciting thing about being a part of the LF Energy community is because there are a significant amount of fairly large participants in the development of these specifications. Organizations like Google and Microsoft are participating in helping foster the development of these specifications because they not only are interested in these open standards, they're also interested in facilitating the carbon accounting growth in the marketplace. For example, Google has an initiative where they are focused on providing carbon-free products with a 24 by 7 timescale, which means that for every moment in the day, they are producing as far as using the power from their data centers, that sort of thing, in a carbon-free manner. And Microsoft has, for example, platforms around companies using scope two and scope three emissions to tagulate their own carbon intensity as part of the Microsoft offerings to large corporations. And so there is a significant amount of tech involvement in the community, in addition to the utility software community like Utility API by company. We all know that LF Energy is playing a very critical role in helping organizations cut down their carbon footprint, their own kind of strategy to solve a much bigger problem of climate change. What role do you think this project is playing in there? The key thing about carbon accounting and carbon mitigation is that there's not one solution that will fit all of the needs. There will be thousands of companies and thousands of vendors and thousands of different solution types. So for example, electric vehicles versus rooftop solar versus utility scale wind and solar versus storage, grid storage, the big batteries in order to shift when the sun doesn't shine and when the wind doesn't blow, all of these things have an enormous impact on the transition away from fossil-based generation and on to clean energy sources and being able to operate the grid in a more resilient and reliable manner. And so all of that effort involves the coordination and participation of many, many, many different organizations all across the world and these specifications will allow for interoperability and more streamlined adoption of clean energy solutions. And so what that means is we'll be able to more quickly accelerate the energy transition rather than relying on individual one-off connections between the various actors. As you rightly said, it's more about collaboration and working together than individual efforts. What is the importance of establishing such a standard for underlying measure or raw data usage to calculate energy and carbon-related metrics? As a little bit of background, this is actually where my company utility API started was we were, I was working with a commercial solar company and we would go to clients say, for example, a city or a school district and we would need to pull their utility data to measure how much they were currently using in energy in order to calculate the financial feasibility of a solar project or of an energy efficiency project. And one of the major issues was that for every utility that we went to, the data format was different because each individual utility didn't have a specification that dictated, hey, this is how you should provide this information in this format. And so the problem was we were spending a ton of time tracking down, getting that information, tabulating it into as common format so that we could run our calculations. And there's no way that we would be able to make the energy transition happen in the goals that are laid out by the various governments and treaties. And so what we have settled on is we need to create a common set of specifications that can be deployed by the various utilities and the various organizations that are controlling that access to data so that we can massively accelerate these sort of calculations and massively accelerate the adoption of clean energy reporting standards. For example, the SEC is starting to move towards in the US, move towards carbon accounting requirements for publicly traded organizations. There's not really a it's highly cost ineffective if you're doing having to do one off integrations or one off data tabulations with various utilities. We need a common set of specifications in order to significantly scale up the adoption of these practices. Is it possible for you to share some use cases of this project? The specifications that the customer data working group is working on has three major categories of use cases. The first is, as I mentioned before, a carbon accounting. So carbon accounting is the practice of you getting access to both your and your vendor's usage information and then comparing that to the carbon intensity of the grid or the particular tariff that you're on and then calculating what your carbon footprint is. And so it's basically just carbon footprint and doing it in an automated and streamlined and standardized manner is one of the first major use cases that we're addressing. The second is oftentimes when you're looking at your carbon footprint, you're looking to see if, hey, could I add EV charging? Could I add energy efficiency? Could I add some sort of distributed generation or smart grid or micro grid solutions to my facility? And that is the second category is the deployment of clean energy technologies. It's facilitating the deployment of clean energy technologies in a more streamlined fashion. And then lastly, a lot of those what we call distributed energy resources or DERs is allowing those DERs to participate in grid flexibility or load management processes. And so if, for example, I have an EV charging fleet, I have a delivery company and I have a bunch of electric vehicle vans that I'm charging all at once, it would be very beneficial for the grid to know that and to be able to say, hey, we want you to charge it these certain hours because that's when the renewable energy is the best for solar, for example, or wind. And so it allows that sort of grid flexibility and load management is the third major use case category for these specifications. Now, let's talk about what kind of folks should get involved with this project and how they can get involved. The audience that we are looking to participate in in our specifications are anybody who is working on scope two or scope three emissions, especially around ESG reporting or carbon accounting. In addition to that, anybody who is deploying DER solutions, so things like microgrids, electric vehicles, energy efficiency, distributed storage, all of those folks, we highly encourage to get involved, utilities as well, since the specifications are going to be about how they can provide access to customer data. And all of those people can go to carbondataspec.org. And that is the main website for both the customer data working group and the power systems data working group. Daniel, thank you so much for joining me today and share your insights. And I would love to have you back on the show. Thank you. Thank you.