Bonus 1

Watt’s up with EEBUS: Interoperability and smart grids

Bonus 1
·
37 mins
·
September 24, 2024

Watt’s up with EEBUS: Interoperability and smart grids

In this bonus episode of “Watt’s up with energy?”, host Georgia Knapp delves into the vital role of interoperability in modern energy systems with Annike Abromeit, Innovation and Communication Manager at EEBUS. They explore how EEBUS is leading the way in creating a common language for energy management systems, facilitating seamless communication between devices in smart grids and enhancing energy efficiency. Annike shares insights on the evolution of EEBUS, its impact on integrating renewable energy and the challenges of achieving widespread interoperability across diverse energy platforms. This episode is essential listening for anyone interested in the future of energy management and smart grid innovation.
Listen on:

Georgia:

Hello, and welcome to “Watt's up with energy?”, a gridX podcast. I'm your host, Georgia Knapp. We're doing things a little bit different this season, and we're actually bringing you two special bonus episodes about interoperability, because as the bread and butter of energy management, we just can't get enough of it.

This is the first of the two bonus episodes, and I am speaking with Annike Abromeit, the Innovation and Communication Manager at EEBUS.

So, Annike, thank you for joining me today. And I believe you said you're joining me from Cologne?

Annike:

Yes, I'm joining from Cologne, our headquarter from the EEBUS. But temperatures are like the south of Spain, if you want to put it like that.

Georgia:

Okay. So, think of the Spanish part of Germany. So, actually, we can just start with you introducing yourself, telling our listeners a little bit about you, a little bit about EEBUS.

Annike:

Sure. Yeah, so, my name is Annike. I joined the EEBUS Initiative about three years ago, but I've been working in the field of, let's say, connectivity and energy management for more than six years now.

And well, to give you an idea about EEBUS, because sometimes it's quite confusing, we have the name EEBUS for the association, for the non-profit association that is developing the like-named communication protocol and standard, which is also EEBUS. And then we have the standard, which is EEBUS.

So, sometimes it's a bit confusing if we're talking about the association or if we're talking about the standard or the protocol itself. But let me talk or tell you something about the development. Maybe of how EEBUS was founded. Because that actually stems about 12 years from now.

So, 12 years ago, there was a research project actually, Smart Watt, in the program of the German government. They had a program called E-Energy, and this research project was one of these projects of this program, where the aim was to provide an internet-based information and control model for the energy system, where you can offer relevant market players like energy supplier or the grid operator with in-time or real-time generation and consumption data of flexibilities inside the building. And from this aim and goal of this research project, there was the need or the urge of a common communication protocol for all devices involved in the setup.

And present at that time in this project were providers of home appliances like white goods, washing machines and similar devices. PV, solar inverter and an IP-based approach, let's say, for smart energy management.

And coming or stemming from this constellation, the EEBUS Initiative was founded in 2012 with nowadays more than 60 members and an association joining our initiative. And they cover all relevant sectors, from electric heating, electric mobility, solar, PV, battery systems, home appliances, smart metering and energy management.

So, from all these sectors, we have companies and an association representing their specific devices and systems. And EEBUS Initiative, or we ourselves, see each as a partner for the digitalization of the energy transition.

So, with our solution, with our standard, we want to provide a way to connect devices or energy relevant devices to an energy management system by providing a common language, let's say, that devices and system can use to talk to each other about energy flows and how to align these energy flows inside a building, but also at the grid connection points and in actual interaction with the grid operator and the energy supplier.

Georgia:

Okay. And just a bit ago, you said that there is a non-profit section, like so EEBUS is split into two, you have the non-profit and then the for-profit one?

Annike:

Oh no. So, EEBUS is a non-profit organization.

Georgia:

Okay.

Annike:

And our, let's say, outcome or output is a protocol, a communication protocol or a standard that is named the same. So, the standard that we develop with our initiative is called EEBUS, and the initiative itself is called EEBUS. That's sometimes confusing. That's why I tried to mention it right at the beginning.

Georgia:

Got it. Okay. And how long have you guys been around?

Annike:

For more than 12 years now. So, within this research project in the energy program, in 2010, 2011, there was the need or there was an urge to create actually an ongoing association or let's say platform to create and further develop this language for energy.

And in 2012, the EEBUS initiative was officially founded.

Georgia:

Okay.

Annike:

And since then, more and more manufacturers and other great big associations such as the VDA, the main association for the German car manufacturers, and the BDH, the Association for Heating, they all become member and they since then continuously working with us on the, I'd say, further development of the language for energy.

Georgia:

Okay. And then in this season, I talked with one of our co-managing directors, Tim, about interoperability, what it means to him, to the energy transition.

But in your own words, how would you describe the concept of interoperability in the context of energy systems, and why is it becoming increasingly important in today's energy landscape?

Annike:

So, I think interoperability is key, because our energy system is becoming more and more complex due to the, we usually use the word all-electric society, which means or which leaves us, and if you just look at one building, like let's say a simple one-family house, when you include electric heating, when you include electric mobility, you have already two components.

Those two components have already have a sub-system, let's say of two or three enabler. Let's say for the electric part, there is a wall box.

For the electric heating, there is a system of three different parts to enable this electric-based or electricity-based heating. And all of them have to be integrated into whatever is already existing at the house.

So, if you have a PV installation, for example, to cover most of your own consumption, then you also have to integrate and connect those devices, like the new devices, such as the heat pump or the electric charging station for your EV car, kind of have to combine it and integrate it in whatever is there already.

So, you need, like with an increasing number of devices, you need a common language to make those devices talk to each other, to enable them to talk to each other and to understand what they're talking to each other, because of course they can talk in their own language, but then the other part doesn't know how to react upon or what information the other part needs so that the energy flows can be optimized.

And then what is really of great importance is a central unit that's kind of the brain of the energy set up in the house.

So, you need an energy management system that also is able to connect and to talk to all these devices. And if you don't have interoperability guaranteed or facilitated in these kind of ecosystems, they will talk about everything and nothing, or they don't talk at all, but energy flows can't be aligned and especially renewables can't be optimally integrated.

And that's why we see that interoperability is key.

Georgia:

What do you see being some of the biggest challenges in achieving interoperability across different energy management platforms and devices?

Annike:

The greatest challenges I see are basically to get everyone on board, like to get it to the right committees and groups and decision-maker processes that lead to a standard, because a standard is only a standard once it reaches a great amount of commitment in the market, but also in a regulatory setup and politics.

So, you really have to be aware of where decisions are made and what the need of the market actually is and how you can serve it, and how you can actually integrate the market to fulfill and identify the need. And this is something where EEBUS is really active.

So, we are present in several international and national standardization committees, such as Senelec, IEC, ESOR, Etsy, to actually align and provide those committees with what EEBUS is able to cover, and to make also clear in which interfaces in the overall standardization landscape, EEBUS is best of practice to then lead decision-makers in every layer to adapt to it.

Georgia:

When I talk about EEBUS, I usually think of it as one of those little translation devices that you see diplomats at the UN wear, like where they have a little earpiece that is kind of automatically translating what they're hearing into their own language.

Would you agree with that analogy or am I off base?

Annike:

Partly yes and partly no.

I mean, in the end, the purpose of your analogy is that each of those participants were involved in this UN conference, let's say, can understand what the other one is saying and maybe react upon it because there is a commitment or a disagreement.

But I see EEBUS not really as a converter of language or of things, but as a language itself.

So, for example, let's say English. I would rather compare it to English, actually. English doesn't have to be your native language, but if you speak it, you're able to communicate with a lot of other people on earth about things that both of them will understand.

So, it's kind of a tool, let's say, to make each other, or it's an agreement that both parties, let's say, or if you want to break it down, both devices can use.

And also in English, let's say EEBUS is like English, you also have not only the words or the language to talk about, but you also have the understanding of the words, which is pretty helpful and important to know what the word, if I say yes, and you say no, to know what it means and how to react upon.

So, that's my analogy, I would say. It's even simpler than yours, but I think it makes it pretty clear what EEBUS tries to provide.

Georgia:

Yeah, no, actually that is a better analogy. How, then, does EEBUS, I guess, maybe teach the different assets, English? Like kind of going off with that? Like how do they take these assets that speak, like German and Portuguese? How do they get them to start speaking an international language?

Annike:

This is basically by implementing the software that we were talking about beforehand, but not EEBUS who's providing the software, but EEBUS who's providing and defining the information that has to be developed or put into software beforehand.

And these kind of information, let's say the language that we create is defined on different layers.

So, I'm not sure if you're familiar with the Smart Grid Architecture Model, SGAM, but in the end, there are different layers.

One layer is responsible for the transport of information, let's say the communication layer.

Then there's one layer that is responsible or where the information that are to be exchanged are defined, and then there's one layer that is the function layer, where, let's say, the order or the instructions on how are these information exchanged in which scenario for which purpose are defined.

And on all these three layers, the EEBUS provides the specifications, like let's say a manual, on how to enable the communication protocol and the use cases.

And with this manual, let's say manufacturers or software providers can develop their software and integrate all of these specifications into the software, to then enable these devices to speak and understand and exchange this information.

Georgia:

Okay. And in terms of energy efficiency and optimization, what are the tangible benefits that interoperability via EEBUS can bring to end users and the industry as a whole?

Annike:

So, EEBUS is not just the language where you can speak about everything and nothing, but the information that I exchanged are compromised to certain scenarios or certain use cases, we say.

And these use cases, if you combine them in a way that we suggest, they can actually enable the end customer, let's say, who is the owner of those devices inside the building, to reduce their energy costs.

So, by integrating, for example, their own PV electricity or PV power in an optimal way, because devices can talk about their demand and their consumption, you can lower your, let's say, purchase electricity from the grid.

By offering dynamic tariffs or enabling the transmission and the exchange of dynamic tariffs that we enable with EEBUS, you can also optimize your energy consumption or your electricity bill in the end.

You're, as an end customer, you're able to participate in flex market or to provide system services for the electricity grid, while the energy provider or the aggregator, let's say, can send incentives or signals to your energy management system, for example.

And the energy management system coordinates all connected devices and can then adapt to whatever the incentive was and change or adjust the energy flow inside the building to fulfill the signals or the demands from the power grid.

So, there's a kind of remuneration of your service as an end customer.

If you understand the signals from the grid and from the aggregator or let's say the energy market, then you can react upon it and then you get paid for it.

So, these are the, let's say, use case and solution scenarios that we offer from EEBUS or that EEBUS as the language offers for the end customer and also for the power grid.

There is this example in Germany where we now have an obligation to react. So, with every new device that is installed from now on, to be able to react upon signals from the grid operator.

So, in times of grid instability, you as an end user have to take care and make sure that your device can react and receive and understand and react upon the signal of the grid operator. And this is kind of not even, I mean, you get a reduced grid fee in the end.

That's also kind of remuneration, but also it's just a regulatory obligation that you have to fulfill, and that is able to be fulfilled with EEBUS or when your device speaks to EEBUS.

So, there is certain incentives and certain measures of how EEBUS enables energy efficiency, cost optimization, and then actual remuneration whilst being compliant with, for example, regulatory obligations for law.

Georgia:

How would you say that EEBUS either aligns with or differs from other interoperability standards and protocols such as OpenADR or SEP or OCPP?

Annike:

Partly, or some of them are pretty much aligned with EEBUS. Others are just, let's say, coexisting in a similar field. So, for OpenADR and OCPP, we have cooperations with those alliances or the standards themselves.

OpenADR is rather focusing on the grid interaction and demand response and the integration of decentralized energy resources in, let's say, the market mechanism. It has a rather systemic approach. It's not really based on or focusing on the energy efficiency inside the building.

So, this is where it differs from EEBUS because EEBUS stems from the energy efficiency idea inside a building first, and now it's kind of evolving and also integrates the grid interaction.

But OpenADR and EEBUS work pretty well together. So, if you have the grid signals, let's say, that are approaching or that are transmitted to the grid connection point of a building, there it can be transferred to EEBUS, and EEBUS handles the information inside the building.

We have already done such a, let's say, end-to-end testing of OpenADR and EEBUS, and it works pretty well.

We think we did it with the case of power limitation, where a grid operator send a power consumption limit via OpenADR to the smart meter gateway and the control unit, and then it's mapped to EEBUS, and the signal is provided to the energy management system via EEBUS, and then the energy management system aligns all the connected devices like heat pump and wall box and battery storage, according to this signal that it has received from the grid connection point, which means from the grid operator.

So, there's a coexistence or a completion maybe of standards that we see here. Same for OCPP. OCPP is rather related to the electric vehicle equipment infrastructure or electric vehicle charging infrastructure.

So, here the main, let's say, goal or the main features are actually building and authentication functionalities, which is not covered by EEBUS and also not focused by EEBUS. But then again, the integration of, let's say, electric charging, electric vehicle charging infrastructure, such as a wall box inside the building.

The integration of a wall box into the energy maintenance system, this is handled or covered by EEBUS. So, there's, yeah, rather a coexistence again and a completion in terms of, yeah, the standardization landscape, if you want to see it in the big picture.

For the SEP, the Smart Energy Profile, there are actually quite some similarities. It is rather focusing on distributed energy resources again, not really on home energy management, but there are similarities in the use cases related to grid and market applications and interactions.

This kind of protocol is however widespread in the US and, yeah, applied and in use in the US.

I think it comes or has its origin in California. So, so far, we don't really see competition or anything comparable for EEBUS, but there are similarities.

Georgia:

And how do you guys ensure security and privacy while maintaining such open communication between devices?

Annike:

So, in general, our communication on the transport layer is highly secure. So, we use the transport layer security protocol, TLS, to make sure that the transmission of those information is on a higher security standard if possible. We are not collecting or interpreting data that are exchanged.

So, as we are not a software provider, and also especially not an energy management system provider, we only enable the, let's say, the communication protocol which is used to exchange information, but we are not the one who have a product that is able to collect these data.

So, the, let's say the...What is most important is the agreement of the customer and the product provider. So, if you're offering any product that is able to collect data and that is using these data, the end customer has to, or the end user has to be fine with whatever you're doing with their data.

This is really important, but this is nothing that can be covered by EEBUS because we are only the language. It's a little bit like we are recording something now. We are speaking or we talk in English, and someone has came up with the idea that English is a good language to talk to each other.

But the recording is not done by the person who has come up with the idea of how English could work. And whatever you do with the recording is also not defined by this person who has defined the language.

And this is a little bit how I try to answer to this, especially when it comes to KI and all this. We are an enabler in, let's say, in the infrastructure of exchanging information, but we are not the one who can make use of it or who can take care of how these information are used from being misused.

Georgia:

Yeah, okay. And how do you see interoperability impacting the future of smart grids and the development of a more resilient and responsive energy network?

Annike:

I think, again, it's kind of key, because if you, like, with an increase in renewables, we all know the grid is getting more and more volatile. With an increase of electric mobility and electric heating, also the demand is getting more volatile.

And to align those, let's say, curves of volatility, there has to be a communication between demand and supply.

And this is also something that makes grid grids or the energy system more stable. So, if you have a communication and if you have the ability to react upon signals, and if there's maybe an incentivization or renumeration, so a financial motivation for an end user to participate, then I guess it would make absolutely sense to align those volatile curves of demand and supply.

If you want to have it even resilient, so that's partly what we talked about before. It's a lot about IT security, but it's also about what if, and then worst-case scenarios.

What if the power, what if we face a blackout? What if there's something going wrong, a miscommunication, a misunderstanding, an offline duration, and there is no way of communicating?

Then it's really important that protocols, but also devices, maybe even more software level, have the ability to know how to react in the situation and to not make it worse than it already is.

So, for example, in the EEBUS communication, we have this concept of failsafe values. So, when you integrate a certain use case of the EEBUS, you always have a fallback value or fallback setting in the device that the device knows once there is no communication to the energy management system or to the grid connection point.

I know exactly in what kind of consumption behavior I can fall back and operate until I'm reconnected on a communication level.

And this is set in a way that it's not doing any harm to the electricity grid, for example.

Georgia:

And then looking ahead, are there any key trends or innovations in the energy field that maybe EEBUS is excited for, preparing for, anything like that?

Annike:

Yeah. So, I mean, cloud connectivity is a big topic. It's not too new, let's say, but it's still an ongoing trend. And EEBUS comes from an ecosystem that is operated locally, not really cloud based.

But we have collected some experience in different setups, such as research projects and working groups, with other partners who are already looking into this, where this might also be in the future a possibility to expand EEBUS and the data model towards the, let's say, yeah, cloud connectivity that is provided with aligned interfaces that we use in the local communication that might then also work for the cloud level.

And then another trend, of course, is, as I already mentioned before, the ongoing alignment of standards. So, we started in Europe. We want to become globally accepted. So, that requires a lot of work to align with all these developing and existing standards.

But it's key to actually enable true interoperability again, because in the end, if you have different standards and different interfaces, and then there's a, let's say, Chinese wallbox manufacturer who provides their devices to a German house or the end user, and then the energy management system is made in Sweden, and the grid operator is German, then how do they want to interact and want to work?

If you don't take care of, let's say, global alignment of these interfaces and standards, you might not be able to actually make it up and running and work.

So, that's something that we see as a focus activity or task for us.

And then, of course, AI and all these developments and products that are related to it is pretty intense or getting more intense.

However, as I already mentioned, EEBUS is the enabler or the provider of the data infrastructure, but not interested for us to expand to algorithms or anything that is related to learn about certain behaviors or to optimize based on a learning curve.

This is something that we see in pretty good hands in other alliances and manufacturers and providers and companies that are dealing with this, but it is not what we want to enable with EEBUS.

Georgia:

So, can you give any examples of where EEBUS has been successfully implemented?

Annike:

Yeah, sure. I mean, the same diversity that can be found in the member structure of EEBUS can also be found in the market.

So, implementations from EEBUS are to be found in all kinds of relevant sectors.

We have the automotive or EVSE, the electric vehicle charging infrastructure and equipment, where we see Bender, for example, Bender and EVBox, Catech, Manikness, is a big player who committed to EEBUS.

We have the automotive branch or sector, who work mostly with suppliers, but based on their suppliers, they also got EEBUS into their equipment.

So, basically, the VW group, like Audi, Porsche, all these charging infrastructures are related wall boxes to speak EEBUS.

We have the energy management system sector, where of course gridX explains one of the front runner roles, but also TQ or Hega, who have implemented their in-house EEBUS deck into their energy management system.

We have Consolino, Kiwi Grid. Regarding PV or solar inverters, we have big companies like SMA and Costa, or to mention a few.

For electric heating, the sector leaders like Fissman, Weiland, Wolf.

For the grid connection point, which includes Smart Meter Gateway and Control Unit, there's PPC, Tim, Vivares, Polan, and many more.

And from the distribution grid operators and utilities, let's say in Germany, we are working with EWE, Bayernwerk, Stadtwerke Nordarstädt, Stadtwerke Möncheng, but also on an international scale, we have collected several or many experience with, say, European grid operators that can also be found in our members.

Georgia:

Nice. So, a lot of success, it sounds like, in just 12 years, which isn't a super long time.

Annike:

Yeah, actually, it took quite a bit. The longest time it took to identify what use cases are really necessary and what really do have an impact on the local energy efficiency inside the building.

And then if we have this, we also need that. And then if we have this for this sector, we need the same kind of concept for this sector.

Like if we have a use case for the heat pump, we also need a similar use case for the electric car or wall box. So, sometimes you could use the same types of use cases, the same order or structure of information that are required.

Sometimes it's pretty device independent, what kind of use cases you can, or device category independent, what kind of use cases and what kind of sets of information you need to enable, maybe the same purpose.

So, yeah, that was really thought through, and it took some time, and now it's a pretty stable construct, let's say, and fundamental of a standard that is downward compatible. So, no matter if you have an old version, let's say, or a former version implemented in your device, and then there's an update in the other device that should connect to your device, they will always be able to, yeah, continue to speak on the same level as before.

And once the other one got a new version, because there were maybe changes in the specifications or in the use case description, then once both of those devices have an update, they are able to operate in the newest version.

Georgia:

Is there anything else you wanted to add that you think listeners should know?

Annike:

If device manufacturers listen, they, it's nice to know that once they have started implementing EEBUS on their own, they are always welcome to come and see us in our living lab here in Cologne.

Georgia:

Okay, and so that's what a company can do – you said if they've already implemented your protocol.

Annike:

So, once you've downloaded the specifications from our website and you have started to implement it, and let's say you have the ship communication up and running and you want to check or double check if that's really in conformity, let's say to our EEBUS standard, then you can come or if you have the entire stack already up and running, you can come with your device or your system and test it against other EEBUS devices in our lab.

Georgia:

Okay.

Annike:

And once you have tested it, especially for the Paragraph 14a, so the power limitation use cases, and the monitoring of power consumption use case, you can also qualify your device.

So, we started the whole qualification process, and we now are ready with the power limitation and monitoring of power consumption solution. So, I think it's an added value for a device manufacturer.

If you really want to make sure that your device fulfills, yeah, let's say the interoperability requirements that are given with EEBUS, you should come and double check not only in your own safe system on that, but also against other devices from different manufacturers who have already qualified in our qualification test process to make sure that whatever bugs might to be fixed are fixed before you enter the market with your device.

Georgia:

All right. Well, great. Well, thank you so much for taking part in the “Watt's up with energy?” podcast.

I think this has been a great bonus episode for listeners to learn more about EEBUS and interoperability and how both of them are contributing in the energy landscape.

Annike:

Yeah. It was a pleasure to be here with you and to talk about EEBUS. Thanks for your interest. And keep on going with this nice podcast. I think it brings a lot of light into the dark.

Georgia:

Thank you.

If you'd like to learn more about the world of renewable energy or energy management systems, be sure to check out our website, gridx.ai, where we produce regular blogs and glossaries about the subject.

You can also follow us on LinkedIn, or on Twitter and Instagram @getgridX.

Receive new episodes in your inbox
Tune in bi-weekly as we shine a spotlight on the different facets of smart energy technology.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Most recent episodes