Georgia:

Hello and welcome to “Watt's up with energy?”, a gridX podcast. I'm your host, Georgia Knapp, and we are bringing you yet another bonus episode for our season about interoperability.

‍

And today I'm excited to introduce gridX's own Team Lead in Integrations, Daniel Makohin. Daniel, thank you so much for joining me.

‍

Daniel:

Hello, Georgia. Hello, everyone. Well, first of all, thanks for inviting me to have this conversation. I'm very pleased.

‍

As you have said, I'm Daniel Makohin, I'm Team Lead in Integrations team here at gridX. And well, basically, in my everyday life, I'm always handling about making things work together.

‍

That's what integration is about, right, in the end.

‍

We have our platform, we have our gridBox, and this has to talk with every sort of asset that we have in the field. And well, let me tell you a little bit of myself, right? How did I get here?

‍

That was not expected, to be honest, because when I first started working with energy, I had the task of working with microgrids, which is something...It's a very nice concept in the energy industry, but at the time, I had no idea what that was all about.

‍

I was invited to be an intern, and they said, did they give me this theme about microgrids, and I thought, Wow, what's that?

‍

I thought it was something to be like small networks for computers, because in the Portuguese language, that's what we translate to, so microgrids, the microrredes of Portuguese.

‍

And, but that made no sense at all in the end.

‍

So, what happened? I did some research, and I found out the concept was quite nice.

‍

A microgrid is like a small sample, a small word of our general energy grid.

‍

Like in the energy grid, you have big power plants, lots of industries and houses consuming power, and in a microgrid is everything like this, but in a small house, in a small building. This is what a microgrid is.

‍

You have generation, you have loads, you have storage, a control system that makes everything working together in a very constrained environment. Sometimes you can even isolate yourself from the main grid.

‍

That's what a microgrid is, and I thought, whoa, that's nice. I really like this idea, and it was very challenging as well, because here in gridX, for example, we do energy management, and it's not an easy thing to do. We have a lot of constraints that we have to work with as well.

‍

And by that time, I learned that microgrid and distributed energy generation in general, it's very efficient because you consume in the place that you generate.

‍

That's much more efficient for the whole grid. So, it was something challenging. It was something that gave me a purpose of life.

‍

Well, I decided to keep up with the energy industry in the end, and here I am.

‍

Georgia:

But the question that came to my mind while you were explaining that: a microgrid, because actually I had not heard of that either, despite having been here for a year. Is a microgrid what a prosumer uses then?

‍

Daniel:

No, microgrid is more like a concept, right? So the thing is, in the grid in general, as I mentioned, we have these big paw plants, which makes sense for some extension.

‍

So we're talking about megawatts, gigawatts. And when we go back to microgrids, we're talking about just some kilowatts of a generation, for example, isolated in just a small place.

‍

It varies a lot, but you can consider a microgrid in the end, right?

‍

But the main concept is that it's a miniature of the main grid.

‍

Georgia:

Ah, okay.

‍

Daniel:

So hard to say.

Georgia:

And so our listeners might not know this, but around the office, you are quite known for the presentation you gave about integrations at our Partner Days a few months ago, what it is, why it's important.

‍

And we actually ended up using a recording of you giving this presentation on our website, on our How to Integrations Guide.

‍

Now, people who have been following along this season have heard Tim and myself mention the word interoperability about 1,000 times, but not integrations yet.

‍

So, in my mind, interoperability and integrations are basically two sides of the same coin. Can you speak to this a bit? Are integrations and interoperability basically synonyms, or is there something differentiating them?

‍

Daniel:

Well, the first thought that comes to my mind is that I became famous, and that's nice. But well, to answer your question, integrations and interoperability are not actually the synonyms, but they are not the same thing. But they are really close.

‍

I would even say that the concepts are kind of entangled or something. And why is that?

‍

Because when you think about interoperability, this is the capability of some equipment or some devices to work together.

‍

We have requirements, we have specifications to make them work together in an easy way, or sometimes not that easy, but in the end is the capability, basically.

‍

We can call it like the interoperability part would be more like the blueprints for being able to work together.

‍

And integration is a little bit different, so it's making these things go out of the blueprint and actually come into the real world.

‍

So, we actually make the interoperability happen. Right? We implement it. So, this would be the biggest difference between both of them, actually.

‍

Georgia:

Okay. And during the course of this season, Tim and I also mentioned Ready for gridX a handful of times, which is a new label that we've put out that certifies whether an OEM or an asset is quote unquote ready for gridX, meaning it can be integrated into our system.

‍

Can you explain on a technical level how this integration actually happens? Because I think it's more than an OEM just saying, hey, integrate us, and then it's done.

Daniel:

Much more than that. If it was just something like free will of wanting to be integrated, that would be much easier for us, to be honest, right?

‍

But in simple terms, being ready for a gridX means that the OEM has assets or devices that comply to our interoperability requirements.

‍

So they have the capability to be compatible to us. And what does that means in the end? So we have the grid boxes, right?

‍

So probably our listeners already know about the concept of grid boxes. These small hardware that are in the field need to communicate with the devices, right?

‍

So if we have, for example, a battery, and we want to integrate a battery or a battery system with this inverter, there are requirements that we need for this integration to work.

‍

We need to know how much energy can be stored in that battery, how much power this battery system can provide to our system in the end.

‍

We need to be able to control it, to steer it with our own will. Otherwise, nothing is going to happen. And all this information about what we need is actually available for the OEMs to analyze and see if their systems actually comply to what we need for our use cases. Right?

‍

So this is the more the technical part, implementation part of things. But it's not only about the, technically about the integration itself, so writing code and putting it into the field, but it's also about process and all the cooperation that we have to make it happen with the OEMs.

‍

Because in the end, equipment gets updated. Our systems also get updated.

‍

So we need to collaborate in order to update things at the same pace so they're still in sync and they can still talk to each other.

‍

But we can also collaborate to create use cases. For example, right now, in the German market, we have everything with §14a going on, right? And this requires both us and the OEMs to adapt to a couple of things.

‍

And then if we work together to adapt together to these changes that the market pushes to us, everything gets much easier for us, for our customers, and also for the end users.

‍

Georgia:

Okay.

‍

Daniel:

So, I would say that it's not just about technically integrating things, it's about collaboration.

Georgia:

Do we then, it sounds like we have like minimum requirements for it? Because you were saying it's about like, it's about how much the battery can store, how much power it produces.

‍

So, we have like a minimum they have to meet.

‍

Daniel:

Yes, we have like a minimum set of requirements that they need to fulfill in order to integrate with us. And then we have some specific requirements for some use cases.

‍

For example, if they want to use the battery in time of use optimization scenario, for example. It's one thing we have extra requirements for this. Or if they have an EV charger and they want to use a feature that we call phase switching. There are also specific requirements for these use cases.

‍

So, it's like we have a baseline, and on top of the baseline, we have extra requirements for more complex use cases.

‍

Georgia:

And then, how exactly do we test this?

‍

Daniel:

Well, to test this, it's very tricky, to be honest. But lucky for us, we have a very equipped lab in Aachen that we can use to test many different scenarios that mirror the HEMS case, so the Home Energy Management System case there.

‍

And we try to reproduce what happens in real life with real equipment in the lab.

‍

So, basically, when we are integrating something, we get our hands on an inverter, we get our hands on an EV charger, we install it in our lab. Oh, there are some exceptions that I may come into later if you want, but this is the baseline.

‍

We install it in the lab, we look how this would work in real life, and we just put in this inverter, battery, PV system, whatever, we put it to work in the same way we would see that in real life.

‍

And then we connect it to a gridBox, and we run all the tests to see, first of all, if everything that the OEM claims to be true, everything that they say that is accordingly to our requirements is there, all the information, all the controlling set points and so on.

‍

And then we go on actually a step further to see if it behaves the way we want. For example, if we want to steer a battery, during peak time, to just to feed all the load that we have into our home, right? But if it takes like 30 minutes to get to the power set point that we sent, it's just too slow. It doesn't serve us, right?

‍

So we have to see if the behavior is actually quick enough for us that can be used together with our system and so on.

‍

Georgia:

What happens if a company doesn't meet our requirements? Are they able to go back and change something? Or is that kind of impossible?

‍

Like, if their battery works one way, there's no way for them to make the battery work a different way.

‍

Daniel:

Well, if change is totally impossible, well, there are times that we have to say, no, it's an integration. That can happen, right?

‍

Let's take this case of a battery being just too slow.

‍

I mean, if you look into the consumption of a household, it changes in a matter of seconds sometimes. If you turn on your heater, if you start plugging your car, it's not going to start in some minutes. It's going to start like in a second base.

‍

And if they can't adapt to it, if they say, no, my battery can only react in a 10 minutes time frame, that doesn't serve us any good. So we definitely wouldn't integrate that. We're going to say, no.

‍

But what happens usually with...We always work in collaboration with the OEMs, and they send us equipment for us to test. We run tests.

‍

If something doesn't suit us, we always get the information back to the OEM, and in most of cases, OEMs adapt their equipment to what we need.

‍

Georgia:

Okay.

‍

Daniel:

So if I have further more changes, firmer updates, so, again, that's why I said that Ready for gridX is about collaboration, right? Because we already do this collaboration in a daily basis with the regular OEMs, so to say.

‍

But in the Ready for gridX, we want to take one step further and be even closer to them. So we try to even avoid things coming and going between us and OEMs. We say, hey, fix this, and then they fix this.

‍

The firmware comes back, and, oh, we have to fix something else. We want to avoid this. That's why we need to collaborate even closer.

‍

Georgia:

And then what about with legacy systems?

‍

Daniel:

Oh, I don't like them.

‍

Legacy systems are always very tricky for us to actually work with, because sometimes there are implementations that are in the market for very long, and sometimes who made the implementations are not even there anymore.

‍

So dealing with legacy systems is really a big headache for us. Regardless, well, we have to deal with them. Let's be honest. There is no way we can just forget them exist, right? It would be just too good to be true.

‍

But the fact is that even though we wanted to forget those, sometimes we have to do it. Depend a lot on the scale of the market.

‍

If there's something that is really, really, really attractive for us and for our customers, of course, it can be made. But we try to make decisions that if this device that uses a legacy protocol, a legacy processor or anything legacy, if this doesn't match the scale that we await for assets, then we're probably not going to integrate that.

‍

It's a very gray area. We have to make decisions.

‍

But on the other hand, if we say the customer or the customer say, oh, we need to integrate this because we're going to put like 100,000 of these in the field, then we have scale, right?

‍

The economy has scale. It makes it economically feasible, right?

‍

Then we can think twice and say, okay, maybe this may be feasible.

‍

Then of course, we also look at if this legacy system is just too hard to implement or not, if it's really feasible, if we have, for example, libraries in our stack, our code stack that fit into this integration, this legacy integration.

‍

So it's a very gray area. We would like to forget them forever, but sometimes it just can't.

‍

Georgia:

A bit ago, when we were talking about the simulations that are run in the lab, like how long of a simulation are those for?

‍

Is it like how long it'll, again, with the battery, that's apparently the only asset I can call to mind right now. Are you trying to see how that battery performs for a full month, a quarter, a year?

‍

Daniel:

Well, in our case, we don't have a lab that testifies, for example, for safety of devices or for efficiency of devices. We are testing about the integration part of the devices with our systems.

‍

So we do not require these extremely long simulations that leaves the equipment running there for who knows how long. This is not what we do.

‍

Long or short, basically, we have some very short procedures that we do with the devices, just checking over the communication interfaces and see if that's working or not. Right? But when you go for more complex behavior, sometimes we leave the equipment running in there for like one, two days, I don't know.

‍

As long as we can verify that all behaviors match what we need, we don't need to leave it running for good.

‍

Sure, for the most important assets that we have, we usually leave them there, installed, sometimes even running, so we can catch up some bugs, some problem that we have to fix. But this is not the rule.

‍

What we need is enough time to see all the behaviors that we need. A battery, we need to see if it charges and discharges, and we can control all this cycle, for example.

‍

If we know that we can do it in different ways, if I want to make a big step towards the maximum charging power, then back to the maximum discharging power, for example. Or if I test if I can do that in steps, in a ramp, I can steer it in many different ways.

‍

If I can see these behaviors, that's fine. I don't need to leave it running forever, I can continuously. Especially because after systems go into the field, for example, the field is our most important source of data. So we're also looking into the field constantly, right?

‍

This is basically the paradigm of this century in terms of software development, right? Where we know the real test is the field.

‍

So we test everything, if everything is according to what we need in our requirements and so on.

‍

And then when we start rolling out into the field, that's where the real tests are. In the beginning, an asset is like an alpha stage or beta stage. It means that we are constantly looking at them to see if something can be wrong or not.

‍

Then after, and just when we're really, really confident after a couple of weeks or months of this device running the alpha, beta stage in the field, then we can say, okay, this is stable, we really can approve this.

‍

Georgia:

Okay, and that actually might answer my next question, which is, when an OEM contacts us and is like, hey, I want to become ready for Grid X, what is the general timeframe they can expect to either have a yes or a no?

‍

But it sounds like it might be anywhere between a couple of weeks to a couple of months?

‍

Daniel:

It can really vary a lot, to be honest, right? Because when an OEM comes to us and wants to be integrated with us, first of all, we have to assess if we have market potential for it, right?

‍

After all, we are driven by business, so we need to see if it's market compatible to our strategy.

‍

But let's assume it is, right? It's very interesting for us, it's an OEM that wants to grow into the European market and make sense.

‍

From this point onwards, then the process, as you mentioned, can take from weeks to months. It depends on how ready this interface is ready to work with us. Right?

‍

And also, it comes a lot into balancing our team efforts. Because we need to put time into this, we need to invest time into integration: laboratory personnel, need to use developers, we need to use some solution engineers work to also test things for us. They also do a lot of works together with us for testing. So it can really depend a lot.

‍

What we try to is always, when we get a request, our dream is like be able to allocate that for the next quarter or something. And we can already start collaborating with the OEM before that.

‍

So we get everything ready for the developers to really start working. What we don't like to is to start working, writing code before we at least test minimum requirements, because then it might come to developers will be stuck.

‍

And if the developers are stuck with something that is not solved by the OEM, for example, all of the work that they've done is lost. So we always try to avoid that.

‍

Georgia:

Okay. So between my talks with you, with Tim, with other people around the office, it seems like there are no disadvantages to promoting integration between energy assets and energy management systems. And yet there are still manufacturers whose assets aren't completely operable with other assets, with a variety of software. And it doesn't seem like they care to make them interoperable?

‍

I'm just kind of curious if you know why this is, because to me, I see nothing but the benefits.

‍

Daniel:

Okay. I cannot read the minds of the OEMs, especially because OEMs are not people. They are companies. But the best I can do here is guesstimating, right?

‍

But from my experience, but also from relationship and conversation with OEMs representatives and other people that work with me during these years in the energy industry, I can list some factors.

‍

The first one is cost. Interoperability is not cheap, right? It requires a lot of work, especially on the OEM side. Sometimes it might even require some more powerful hardware that you can imagine an inverter manufacturer produces thousands, sometimes millions of inverters.

‍

If you add like one extra dollar of cost into this production chain, in terms of hardware, it's millions of more of cost, right? And they have to turn it into revenue. So this is not easy.

‍

So the first thing, I think it's costs, right?

‍

The second one is about some designs are not from yesterday or from last year. Some designs that are produced and sold are still designed for a couple of years ago. And as you can imagine, this wasn't, perhaps this wasn't in their place before. They implemented some interfaces that could be used, but that are not perfect.

‍

And that's what they have, so to say.

‍

And now that there is this demand for more interoperability, they probably are taking that into more account when they are developing new generations of products, right?

‍

And then also about these things about hardware design and so on, you may think to yourself, why not they just make a firmware update and put it in there? Then it's mostly because of hardware capabilities.

‍

Maybe if you have some, for example, a sub-dollar processor that they wanted to use to be very cheap, and they don't have any memory left, they don't have any processing power left to actually update the firmware with some requirements that can come up.

‍

So this is some first reasons.

‍

Another reason that is very critical, also for us, it's critical for us as well, is the lack of standardization.

‍

You don't have a very, very solid standard for HEMS, for example, in the market today.

‍

We have EEBUS now also surfacing in Germany, trying to spread more in Europe.

‍

But overall, especially for houses and energy resources specifically, because we have some other protocols that are made for home automation or proposals that are more solid. But for our environment, the energy environment, there is not much standardization that we can access to. In an easy way, right?

‍

So this is also something very important.

‍

And why the fact of not being solid is so important? Imagine you're an OEM. You have to take a decision there of what to implement. And you want to be interoperable, and you have some standards, but none of them are really spread out to the market. Then you have to make a guess, which one are you going to use?

‍

So they sometimes go for cheaper approaches, like using some old protocols like Modbus, which is pretty much default, doesn't require a lot of hardware power. It's easy to implement, and just go for this option, make something very custom, but has lots of data points available.

‍

We can control lots of things. So it's like a safe route to take. It is pretty custom, especially for us that integrates them, but it works for the OEMs. Now I think this scenario is changing a little bit.

‍

And a last reason, and this is very pretty much a guess, but I would say that it's true for many cases, which is strategy. Imagine some OEMs do not want their equipment integrated by other, because they want to build their own environment, where they can only talk with their own equipment, which forces, for example, the user to acquire a pretty vertical solution, like an EVCS, battery, PV generator, everything from the same supplier.

‍

So strategy can also play a role in here.

‍

Georgia:

Okay. Since we announced Ready for gridX, do you find that more OEMs are contacting us to become Ready for gridX, or are we needing to contact more OEMs to even tell them about the initiative?

‍

Daniel:

Well, it was actually, it was not totally expected, but I would say that when we launched this concept, many OEMs started wanting to be part of our ecosystem.

‍

We even had to filter them a little bit, so we can take the most important ones first. So I would say that it was a big boost towards our, so to say, OEM lead generation.

‍

Georgia:

Nice.

‍

If Integrations was a superhero, which superhero do you think they'd be?

‍

Daniel:

Oh. I don't know specifically of a hero. Or maybe I can. If you guys know about X-Men, there is this mutant called Rogue, right? The woman that can steal other people's power with a touch.

‍

Georgia:

Is that the one who Jennifer Lawrence plays her in the movies?

‍

Daniel:

No idea. But, except-

‍

Georgia:

Do you know?

‍

Daniel:

Oh no, she played the Kitty Hawk.

‍

Producer:

I know Jennifer. She’s the one that can change the skin and the appearance.

‍

Daniel:

Mystica.

‍

Georgia:

Mystica. But this one's called Rogue?

‍

Daniel:

Oh yeah, but actually – you thought I'm a better superhero than I did, actually, because Rogue actually touches the people and gets their superpower for her.

‍

Georgia:

Okay.

‍

Daniel:

But actually, Mystic would be even better.

‍

Georgia:

Kind of like Kirby in Super Smash Brothers. That little pink ball thing.

‍

Daniel:

That's even better, actually. But for example, we don't eat the appliances. But I would say, actually, I was thinking even about Ditto, the Pokemon that transforms into other Pokemon as well.

‍

Georgia:

Oh, that one. Now you've gone too far past, and I don't know the Pokemon.

‍

Daniel:

To be honest, I think one that would fit us a lot would be any kind of shifting power, like Mystic from the X-Men, like it transforms into many different superheroes or people.

‍

In the end, our interface also has to transform itself into many different things to suit what the asset has to offer us.

‍

So that could be a good guess, I would say.

‍

Georgia:

Nice. Well, thank you again for coming all the way from Aachen to Munich just to be on the podcast.

‍

Daniel:

Yeah, this was specifically the reason I came here.

‍

Georgia:

I appreciate it.

‍

Daniel:

You're welcome.

‍

Georgia:

Thank you so much.

‍

Daniel:

Thanks, Georgia.

‍

Georgia:

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.

‍