Jim Frazer
Welcome, again to another episode of the sustainability Podcast. Today, I'm thrilled to be joined by Rolf Bienert, Managing Director of the open ADR Alliance. Welcome Rolf, how are you today?
Rolf Bienert
Thank you, Jim, it's great to be here, I'm doing really well. The sun is out here where I am. So that's always a positive, right, and the solar is powering on the roof.
Jim Frazer
That's, that's, that's great. Now, we've known each other for quite a while. But for many of our audience, they may not know your organization, the open ADR Alliance, or how it came to be or how you came to become the managing director. So can you give us a little background about who was rolled beaner? And how did your path navigate you towards leaving the open ADR Alliance?
Rolf Bienert
Yeah, that's actually a follow up and kind of an interesting, sort of full circle that I did there. As you can hear, I'm German, born born back in Germany, and then I live 21 years in California. And in fact, about three years ago, I moved back to Europe. So I'm now back back in Europe, in Portugal, actually, so did a bit of a round trip there. But still, of course, very involved in the US stuff. But since you met since you're asked where I'm coming from, I'm actually originally a telecom person. And I think many of us in the standards world right are coming more from, you know, technology controls, and so on, and not necessarily from the utility side of things. So, it my first kind of, you know, touch point with utility stuff was early on, when I moved to the United States, I went there for a test house to do ISDN, testing DSL testing all these kinds of testing services back in the 2000s.
And very quickly, we started the test house in ZigBee, Wi Fi, Bluetooth, you know, these kinds of industry standards. And in fact, just before that, I was part of a team that worked on some of the first Bluetooth testing stuff, but only briefly really in the late 90s. Anyhow, so I was in the in a Silicon Valley, northeast edge of the Silicon Valley, and all of a sudden, 2000 2001 we had rolling blackouts, you know, I coming from Germany, you know, I never really experienced a longer blackout. You know, maybe there was like, yeah, there may be a little blip. But that's it right. And all of a sudden, we had an hour long, semi scheduled blackout. Right. And, and we all had no idea what's going on, of course at the time. But later on, then we heard about, you know, you heard about Enron, and all these these stories, right? Where it was simply a mismanagement of available capacity. Right. So the way I understand it, and I could be wrong with a long time ago, is that a bet some available? reserves were sold multiple times, right. And then when we had a hot, or hot summer day, and multiple states needed those reserves, all of a sudden, it was, you know, we only have this one scenario. So not everybody can have it at the same time. And the utility had no way of really counteracting that. So they had to literally turn off cities.
And I'm saying this, because this is kind of important leading into what open ADR does, right. Anyhow, I worked for a few more years at the test house, getting getting the testing services started for a number of these industry standards. And I was then eventually asked in 2005, to join a management consulting firm. Their business was to actually manage these industry alliances, that's when I liked it. That's when I got a good, you know, look behind the scenes of how this all works. And then in 2010, late 2010, the open ADR Alliance was started and I knew a number of the people that were on the board. So they approached me and asked me to initially become the technical lead of the group. So but back maybe briefly then to open ADR and those power outages, right because that's when everything started. The California Energy Commission. After these these, these problems, said well, we cannot have that of course we cannot just turn off things. So we need to have a mechanism between the utility and the customer side to convey signals about available resources or prices or whatever it is. And at that time, it was just basically Resource Management shaving off the peak, right? If you have these, these these afternoon peaks of consumption that simply, you know, threatened to poke through the production curve, we would try and flatten that that up. So it stays under the production curve. So open ADR was conceived then as the protocol to communicate these types of informational and motivational messages to the customer side.
Jim Frazer
Very good. And that started in 2010.
Rolf Bienert
Yes, so the Alliance started then. So before that already, as I mentioned, after the energy crisis, everything kind of kicked into gear, and the energy commission put out a grant. So a number of companies and organizations participated, and created the open adl 1.0, a very California specific standard, which has been used in California since the mid 2000s, basically, but then you might recall, with the economic problems we were facing in 2008, nine and that area, the government put a lot of means and money forward to really accelerate the SmartCode efforts, right. And that's where a lot more requirements came to us. And basically, a group from NIST and the SGIP, the smart grid, interoperability panels, some some listeners may remember that put together this framework for demand response. And out of that, then the requirements and all the functions for open area 2.0 came out. And that's when the alliance was started. Because there was a need for testing, certification, branding, and so on and so forth. So
Jim Frazer
So Ralph, let's let's talk about, you know, for those that are uninitiated into this, before there was standards and interoperability between different sources and loads and different generators. How was that data communicated? Yeah,
Rolf Bienert
so a demand response? Or, in a sense, managing the demand side, if you will, is not a new concept, right? If we look at it, I think in the US, we have seen that done in particular, with larger consumers, factories, things like that, since, I don't know 2030, or maybe even longer than the years. But, of course, the communication to those customers, was appropriate to the times, right, it started with simple phone calls, right? Where a utility operator would literally call a small number of larger consumers and and back them, basically, hey, could you today, shift the user search and things like that, right? Of course, this is not scalable. But then later on, we had faxes, right fax machines came out. So okay, it was a mass fax later on pager messages.
But as you already noticed, right, this was all very much a one way here, I throw you a piece of information, and we hope for the best kind of system. And then I think what probably came next to some extent, likely driven by aggregators is that they had proprietary interfaces. So an aggregator would would maybe gather certain resources and maybe for some of the listeners that are not so familiar with that. So we call a resource, any kind of power consumer or producer on the customer side. So could be anything from a pool pump. Because a pool pump may be consuming two kilowatt, 1.5 kilowatt or something like that. If we turn that off, it basically becomes this 1.5 kilowatt resource, right, it runs, it loads the grid, but if it stops, it gives that power back, if you will, you know, it's a bit of a bit of a strange concept to wrap your mind around but essentially, so turning off consumers that are permanent usually running will create a dip in the usage profile right.
And with that, give the utility something to play with. Same on the other end of the scale, you have a solar system, right or a battery when you start discharging lead or using that. So obviously, much more of an active participant here, not just a passive, decoupling, but rather, okay, we increase the capacity that we push into the grid. So any of this is a resource here, really. So what the aggregators did was, essentially, they go out and try to recruit these resources, right. So they might go to, I don't know, a conference center, right, or a school or small medium business park, you know, office buildings, you know, they would probably rarely go to two private households, right, this is just for them. That would be way too much too much work or, and we can, we can talk about that in a second.
But so they would go out to those, you know, low hanging fruit, as you say, right, where, let's say an office building, or a conference center has already some automation built in. But they of course, not connected to the grid, right? So they go there, and they look and they say, Okay, if we add here, a little interface point, like a gateway to our, to our control center, we can ask you to, for instance, change the air conditioning, change the lighting, but deletion, you name it, right? Anything that's that's, that's there. Or, for instance, a big target for a while was refrigeration units, you know, like food chains, and things like that with huge refrigeration units, if they knew that the afternoon power was either short or expensive, depends on what the programs are, they could start pre cooling, these refrigerators, bring the temperature down a few degrees, right. And then, okay, at, let's say, 2pm, sun is up, it's hot outside, we turn off the compressors and let the refrigerators or freezers slowly come back to to the actual temperature temperature and with that, basically have a couple of hours two or three hours window, right? Where they don't use energy. So these aggregators would gather these resources, but they are typically then connected with some proprietary interface, right? Which is all good and fine. Unless, of course, the aggregator goes out of business or, you know, what, as some changes and things like that, right, then it becomes problematic.
Jim Frazer
Right? So the aggregators had a standardized way of doing this, but it wasn't open nor wasn't published, they had their internal processes,
Rolf Bienert
exactly, that their internal processes. And they would also neglected to mention that, you know, so I was talking about the downstream to the resources, right, but also to the utilities, they would basically communicate with some proprietary system or even phone calls still, or things like that, you know, because it's a different animal here, right? You haven't you have an aggregator that maybe has a, I don't know, the numbers, let's just say a tunnel, what right? Might be a bit high, but still. So that's an easy thing for the utility to literally call, right? Or send the message. So it again, if you, however, communicate with 1000s of resources, for solar inverters, batteries, you know, pull pumps, thermostats, things like that, then that doesn't work anymore, right? Then you need you need a you need a standardized system to be able to onboard all of these.
Jim Frazer
So Rolf, that, thank you for that. That background. I think that's a that's a great illustration for our listeners. And for myself, as well. So can you move on to, you know, what the the list of objects in in open ADR 1.0 or 2.0. I know that it's a substantial list when I looked at it even 10 years ago, and I can imagine it's only grown given given all of the distributed resources we have today. So, can you walk us through particularly what was 1.0? What What was 2.0? What are perhaps the most important objects in the standard or feel free to respond? Absolutely. What's important there Oh,
Rolf Bienert
yeah, absolutely happy to do that. And in fact, we even have now a 3.0 version of the standard, so I can quickly shed light on that as well. So, as I mentioned, OpenIndiana, 1.0 was a very California focused standard, with very simple signaling. You know, I wouldn't even necessarily call it a standard, per se, yes, it was written down. But it was really only created by one company with a number of partners in California. So So yes, it was it was a standard there, it was published through Lawrence Berkeley National Lab, but, you know, there was no other, you know, compliance system or anything there it was, it was then a company called a cooler, calm, later Honeywell, that just sort of managed all these partners.
But anyhow, the idea here was really to only flatten those peaks, as I mentioned, right? So the sickness in there, were very simple, you know, you would, and that's still the same to this day, you would send what we call an event. And that is one of the services or objects as you as you say. So that's really the most important structure that we have is this event. And you can picture that very similar to a calendar invitation. So if you look at, for instance, our discussion here today, right, so we send out a calendar invite, you know, hopefully compatible, right, if it's from Outlook to Outlook, or, you know, iMac, things like that, there's some compatibility issues. So hopefully, we're talking about interoperable messages. But anyhow, it's like a calendar, notice it has a start time and run time, or start time and an end time. So let's just use an example. You know, similar to what we said before, so the utility knows, today between, let's say, in the early afternoon, is going to be really, really hot outside very typical California use case, of course, it will be really, really hot outside, right, so we know that all the air conditionings will be running full power, and so on and so forth.
So, we, they want to reduce the load at that time. So what they would say is they would send an event that starts at 2pm ends, let's, let's call it 4pm, right? So you have a two hour window, and in there, they would send a different they could send different intervals at the minimum one interval, so to the full two hours, and let's say they think okay, we might need a little bit of power back nothing major, right. So, so, the very original system in open area 1.0 which a sense of a level one, also really in open at one point or everything was limited to just a few numbers 1234 So as you know, you have basically or in fact, it was normally if we talk to engineers here, I can say that the levels were actually zero or one, two or three, so for different levels, but starting at zero, so zero of them would be compared to normal operation, right. So a fallback number number one would be seen as a moderate shet. Okay, so like, Okay, we need some power back please, you know, do something in thermostats, it might mean, okay, like, increase the temperature temporarily, one or two degrees or something like that, right? Then number two, like hi shit, so, okay, give us maybe a little more, you know, whatever you can, and then again, this is often already preset, in some in some functions, you know, again, maybe maybe a few more degrees on the air conditioning, maybe now we turn off the pool pump or whatever it is. And then number three, typically was something like an emergency, okay. So, we will have, you know, a state, you know, great emergency, save as much as you can, right. So, so these were sort of the these conventions that we saw in 1.0.
And later, in 2.0, we added a lot of different different signals there. So pricing, specific pricing, discrete numbers, you know, you could set everything you could set even offsets, temperature offsets for thermostats, even though I mentioned it earlier already in open ADR we don't really like to control a customer equipment directly rather give them you know, information messages so, so the customer through pre settings and things like that can determine what they want to do at anyhow. setbacks. For thermostats do direct energy requests maybe capacity, you know, very important. For instance, for EB charging networks these days, right, we might give a, a capacity message to a certain area, right? Where the operator of chargers would know, okay, I have at this point only x megawatts X kilowatts available for my chargers, right. So this could go then to the control system of a charging network.
And they can make them the decisions, okay, who can keep charging? Who do we throw back maybe from three to level one or you know, whatever it is that they want to do. Or maybe somebody's already at 80%, it turned them off, and so on, and so forth. So a lot of lot of options. So as you can see, the idea is still the same. So that event, that calendar invitation here, is still is still there, but just with way more functionalities built in, then there's of course, also feedback, you know, where, where the resources can consent back information elements, yes, I'm I'm cycling, I can cycle off or if they have submetering, they might even send back current energy consumption and what they can do and things like that. So all depends on the on the programs. But to be honest, typically, most of these programs, even today, have been fairly straightforward. You know, either they give you a price, or sort of a request for some energy increases or decreases.
Jim Frazer
You mentioned that the Vert version 3.0 is underway. So what enhancements I mean, a 2.0, I think came out a few years ago, maybe a decade
Rolf Bienert
ago, even actually looking looking at the date here, G and os 11 years ago that we published 2.0 Be kind of crazy to think about that. But yeah, thanks for bringing me back to the topic. Yeah, yes. 3.0 is, you know, we mean, really, the standard is done, we're just finalizing now the certification program for it. And to explain a little better, why we did it, I have to quickly step back to 2.0 B. So 2.0, as I mentioned, came out of this collective AI, or the collection of ideas, I should basically say that we had doing that smartcard interoperability kind of work. And you know, it was all very closely connected to the people that work on the IEC standards, the IEC data models, and so on. This is of course, all XML code. So 2.0 B was basically an XML schema, and communicated in a soap exchange model. So that would be basically a, a soap based message over the internet, communicated to the client device from the server, which we call the virtual top node, or BTN.
And the client for us as the virtual end node, or B, E N, and so that that sub message was being either pushed down or pulled from the server. And then the client responded and went back and forth. And this still works perfectly fine today. But honestly, it's not really what most developers do these days, right? You know, you have the, you know, the phone apps and everything. Everything is web services these days. So since several years, people were nagging on us, Hey, can you do a JSON version instead of XML, for instance, because you know, all the young programmers, they might not even really do much with XML these days. So they want to JSON. And we were sort of saying, Yeah, it's a good idea. But we were reluctant to say, we transpose to conceive or B into a JSON schema, that's actually even translate. So it would have been easy, but but how do we manage interoperability, right? So all of a sudden, we have two times the same standard, but it doesn't, it cannot really communicate, right? Because it's a different different message. And then there were also a number of other comments that we collected over the years. So eventually, we said, Okay, we need to start looking at the future. And think about maybe something like a 2.0 C or or new version, right, maybe we swing that around to JSON and so on.
And then It, you know, in the discussions, it really kind of came out that a lot of people were really interested in having this a real RESTful API. Right. So because everything today is restful, right, with, with a, you know, common and modern security mechanism, you know, open a theatrical NCLB uses a perfectly valid security scheme with TLS, TLS, 1.2, security certificates and stuff like that. But anything you do these days on the internet, right, this is all RESTful services using using like auth to authentication, right. So even if you, you know, you connect one app to another, and it asks you to really pull something from your LinkedIn into your into the other subscription, right?
So these are all like rest implementations, and they use, you know, await for two different spelling as different pronunciations for that. But anyways, so we said, Okay, if we already do a new version, we do the full step, right. So we kept the ideas, again, the event is still there, right? The feedback are still there, all of that is still there, we threw out a few, few things that nobody ever used. And we added some more specific signal types. For instance, for specific grid interconnect management of inverters. In some areas, this is a concern, even though I haven't really seen it used much. But they're gonna help to control the grid, grid facing Parga are made up of an inverter, you know, Bolvar curves and things like that, to keep the power quality stable.
Australia asked us to add signal types for that non dynamic operating envelopes. Kind of an interesting concept they use in, in Australia to, to, to kind of limit what a household can export and consume. So they're kind of limiting the these two, you know, ends of the scale, so to speak, or because they are concerned, interesting segue here, they are concerned that this, this delta can get very, very big, let's say a house has 10 kilowatts of solar, which is not uncommon in Australia, due to incentives and so on. And then at the same time, they have, let's say, a 24 kilowatt charger. And so, so at the best of times, they might export up to 10 kilowatts. And then when the sun is down, and the cars blocked in, they might draw, basically, negative 24 kilowatt. So there's a huge envelope between these two red, which, which gave them gray hair over there. So they wanted to kind of kind of adjust these envelopes, right. So they're, they're trying to send the signals to
Jim Frazer
interesting Rolf, one of my questions, as you were speaking, was, there is this energy transition of all these distributed resources of vehicles that are mobile energy storage that might charge here, but discharge there, when photovoltaic? How has that changed? Or added to the standard? And I think you've talked a little bit about it there.
Rolf Bienert
Yeah, absolutely. And I mean, it's really, actually a very important component here, right? Because what one one doesn't work without the other really, I mean, as we just said, Right? Australia, is not necessarily the only country where this is happening, right? We're seeing in Germany, also, not big, big solar rooftop solar installation numbers, and we see it everywhere in the US and in other other countries as well.
And really, somewhere in that loop needs to be this connection between the customer equipment and the utility so that that we can balance this this out right and open API actually, kind of without knowing it really happens to be right there. Right. Because we came originally as I mentioned, just from curtailment, right let's be safe, let flattening that curve. That was the main idea. But of course, it you know, we can up and down regulate for us and for us, it makes no difference. Whether we tell the resource to Okay, protect more power or take more power. All right, so it's for us exactly the same.
Jim Frazer
Well, so I mean, it might be a very simple analogy, but I view it almost as if we're going from a world that was a master slave scenario, with a generator at one end, and then I counted electrons at the other to get my bill to now really a peer to peer network. And granted, there's some huge peers on the network, but those peers are getting smaller and an overtime of being removed. So it will be a plethora of smaller peers that need to have some kind of electronic traffic management system, let's call
Rolf Bienert
it that you're hitting. Really like, also, the main challenge here. And that challenge have has multiple facets, you know, number one is that, as you just mentioned, the utilities are very much used to onboarding the customer, giving them a cable, selling them energy, taking that money, period, right. And we still see that, you know, and I'm, I mean, I'm German, so I don't want to talk down in the Germans. But I noticed that a lot in for instance, some German utilities that they don't want to, they don't want to talk to the customer, you know. So as long as they can avoid that, they're, they're happy, right, so much easier to regulate the consumption by adjusting the overall price. Right? If you if you tell the customer, your energy gets 50% more expensive, they'll save some money now, or maybe not charge their car.
Of course, in the long run, that's, that's not gonna, that's not gonna work. Right. And I think, I think we will see more and more. Also other states in the United in the US noticing this, right, because we have a lot of the states, especially like, Midwest and so on, where energy traditionally is very inexpensive, due to low taxes and other regulation or lack thereof. And they are, you know, there is still this challenge that there is very little incentive to get the customer to participate. Right? If you pay, if you pay a very, very low rate 24/7. What's, you know, what, what's your incentive to, to shift? You know, you're charging or any other other stuff, right, so. So that's, that's, that's one thing there to, you know, first of all, get the utility to really embrace that idea of what you just mentioned, right? That you're working with a peer, right, that peer can help you. Right, not only by installing solar or something like that, but also, as we say, by simply turning off consumption.
Right, and we see it with a few new consumers that are coming online. Evie charging, we already mentioned, but also things like heat pumps, right, we've seen more heat pumps coming, whether we play standard air conditioning, or problems, actually probably less power, but Washington state, Oregon, they have seen this transition from gas water heaters to heat pump water heaters, right? And all of the sudden, you have a completely new energy by electricity, I should say consumer there that you didn't have before, right? So Washington state, and Oregon. And slowly also California has been struggling to bring out some requirements, for instance, to make the more modern heat pump water heaters also communicating to the grid. So there's another standard downstream from open ADR equal par to an implementation of CTA 2045, which would be a module that just goes onto the onto the water heater, for instance, you know, so that we're are
Jim Frazer
waiting in the effort to have a I think much of this would be driven by real time, energy pricing, and even the smallest consumers. And I'll just give an analogy that and I thought about this yesterday. I'm in South Florida. I have a sprinkler. I put in a new sprinkler controller to water my lawn. I don't use it that often. But this new one, of course was Wi Fi connected. And it goes out to a weather to some weather app and If it finds out if it's raining in my neighborhood and doesn't run, if it rained in the last 24 hours. I would love my air conditioner if if the utility if the rate went sky high at 3pm. Okay, give me three minutes of downtime, or half an hour. But we seem to be in much of the developed world a long way away from that.
Rolf Bienert
You know, you're hitting on something that's a little bit of a pet peeve of mine. And even though I'm not in the IoT industry, and probably No, way less than I should about all the technology, I am always kind of bashing on them a little bit. Right. You know, we've been talking about IoT for I don't know, how long right? Is it? 10 years? 20 years? thing since early, early ZigBee times, right. So sort of the idea there. And, you know, I always like to say, cynically, I guess that, you know, if I have six apps on my phone, to control six systems in my house, that's not IoT, right? That's an expensive remote control. Right? And that's exactly as you say, you know, you might have a, you might have the controller of your sprinkler system on here. And I have I have the controller of, I have my inverter, my solar inverter on here, right, and I have my heat pumps on here. But currently, I still have no app that connects them. All.
Right, where I say, okay, my, the temperature in my house is going up, I have solar running, and I don't need the solar power anywhere else. So turn on the AC, do that automatically. Right? If the, if the sun goes down, have less solar, turn it off, right, things like that. But, Jim, the interesting thing is, we do start to see these kind of energy management platforms just I think they are not as, as well known by many consumers, I think, you know, there is, there is platforms, like, I don't want to do any commercials here, per se, but, you know, for instance, energy hub, rainforest, you know, up in Canada and a few others, right, that specifically do that, right.
They, they build, they build a I believe cloud based platform, which they then create partnerships with all the individual, home automation people, right? So maybe with the with, with your sprinkler system, right with my air conditioning system with the and everything, right, so, so that over time, they built all these API's to these individual apps, right? So that when the consumer really locks on to that platform, they see their house, right, and they just say what they want the house to do. Right? be energy efficient. So they eat my car, charged 75%, minimum by 730 in the morning, right? Here's my sprinkler system, here's everything, optimize it for me. And I don't really want to hear about it, you know, sent me a message once a week that tells me how much I saved this week by doing that, Ralph,
Jim Frazer
I think we are. I mean, we're one of my questions were what do we see for the future? And I think we're already going down that that road? Yeah. Um, you know, in, oh, you know, quite a few years ago. For example, traffic signals in the US have, oh, I don't know, eight or 10. Well, there's probably now 20 different standards of device terminal devices. They each have their own application, and their own API. They were standalone. But I've lost track of the of the effort. So I can't speak to its recency. But even a few even five or 710 years ago, there were efforts to make a traffic signal. Now they are Linux. And they run all those applications together using an integrated data repository. So the the industrial world can call that a data fabric or digital backbone. But I think the root of all of this of all we're what we're discussing here is we need one trusted source of truth. And then the applications that run on it might be different based on our Prasanna big because you've got solar inverters, I've got a sprinkler. I think that's, that's really, really in a nutshell.
Rolf Bienert
Yeah. Yeah. I don't quite see that yet. Right? I mean, of course, the, you know, where, where we saw an effort on that is with CSA, right? The what is it called consumer Standards Association or Alliance, where where the ZigBee, Alliance basically transformed into this new organization, including then ZigBee and ZigBee. Transport with with matter, right, and other building automation. So at least we saw a little bit of a consolidation there. So that was a good, good, you know, idea or is, I should say, a good idea. And in fact, we have a member in the UK, that is looking at also building, for instance, a bridge between open API in particular 3.0, because it's web services to a matter gateway, you know, so that, for instance, a, a home automation system could easily get, let's say, price sickness, you know, dynamic prices, as you mentioned, into the building, right, and then that home automation system could then manage the refrigerator might know the price, right? And again, you know, I think it's really important to, to, for any, any of the listeners here that is in the business of making these consumer facing applications, you know, energy is not Twitter, right, or, you know, whatever we call it these days, or Facebook, or Instagram, or Snapchat, or some point, it's boring, right, the customer doesn't really want to know about it, you know, the customer just wants to know, it works. Right, and it gives them benefits. And I think that's, that's, you know, a challenge for for, you know, all these manufacturers there to make that to make that work.
Jim Frazer
So let me bring it back to some of that dry, boring engineering talk. So, open ADR 2.0, or 3.0 is a, an API data standard. Talk to us a little bit about you know, when I think of interoperability, I often think of the seven layer OSI model. And in layman's term, for those of you who don't know it, the there are seven layers. The bottom one for me, is Oh, does the connector match? So is it an Ethernet plug or an RJ 45 or USB 2.0 or something like that? At the highest level, level seven, it's the application layer, where? Well, you need to speak exactly the same language. And just because, you know, French, English and Spanish use the same character sets mostly doesn't mean you can talk to each other, because the applications are exactly aren't the same. So Rolf, where does open ADR 2.0 reside in that interoperability stack?
Rolf Bienert
Yeah. And I think I wonder, Is that dating us? When we talk about the seven layer model?
Jim Frazer
Gray hair? Yeah,
Rolf Bienert
totally. And also, you know, one of those things that we still learned in the university, right. But anyways, I think these days, I think the the layers are kind of washing into each other a little bit, but it is really in the in the application on the application side, because we don't necessarily care. You know, what communication medium you use, we just use the internet. So, roughly speaking, we run over IP, and we don't care if that IP is over. Powerline even or you know, wireless, Wi Fi, cellular, cable, DSL, fiber mean, you name it, in fact, interesting. Lee, in the UK, in one in a demonstration project that they are building right now they're even running it now over the Smart Meter network, or the AMI network. Because they can also send basically IP packages, they're often just a little hacked up. And but we are sitting on top of IP. So if we take all these lower these lower layers, our physical right and networking and so on So, application layer and maybe a little bit, I'm not even sure exactly where you would where you would put security here, right if we put that a little bit in the networking side or also right, so so we do a define, obviously, there's this REST API. So we are not only defining the messages that are being sent, but we are defining the REST API. So I guess arguably, it kind of is application with the hooks, the Hogan and
Jim Frazer
in fact rolls I'm not sure you're aware of this, but back Oh, I don't know back in 2012 2013. I was I was contracted to do a lot of standards work for the US Department transportation and the intelligent transport in the NT CIP Intelligent Transportation Systems standards. And one of them that I was most intimately involved with was the 1213 electrical and lighting management systems, which started with simply turning LED streetlights on and off some wrathful issues. But that standard was walked over to the Department of Energy embraced as one of the initial draft standards to be included in the s gip. smart grid city series of standards. And as a result of that, funding came through to the Department of Transportation to include Evie charging, and automated demand response and connected vehicle support. The the Eevee charging portion, the the team there of which I was part of looked at the Evie charging standard from Europe ocpp 2.0. At the time, it wasn't mature enough, it was a bit ambiguous. So we had to back up and and map to and use the Modbus objects that were actually in the hardware for the vehicle to grid piece, the 802 11 P and connected vehicles, not autonomous vehicles work very nicely. And I'm saving the best for last. Because when we looked around for any kind of automated demand response standards, we used open ADR 2.0 took the major objects and map them to SNM P O IDs cause the the US do T's NT CIP effort, the National Transportation IDs communications protocol, which is used worldwide, Brazil, India throughout the Caribbean started a very long time ago. And it's still SNMP. So the major objects at the time we mapped so that you could tunnel it legally on a piece of critical infrastructure, the dot private fiber backbone that's on a road and then open it up back at the traffic management center and send it on to utility in a format that utility would recognize.
Rolf Bienert
Interesting. Yep. And you know, crazy, right that you think it's 12 years ago. So
Jim Frazer
yeah, it took a while it took a while to get published. Because as soon as that as that work was finishing, we had a change in US administration, who was not so enamored by standards, and more of the free market. But it didn't get published when that when the administration changed again.
Rolf Bienert
Funny how that goes through.
Jim Frazer
Yeah. So um, Ralph, this has been a fascinating almost an hour. What haven't we touched upon? What else would you like? What do you see for the future?
Rolf Bienert
You know, yeah, yeah. Good, good. Good question. I think really, you know, one of the big topics that we have been discussing even a little bit behind half closed doors, you know, if you weren't, is that there's still more need of harmonization, as you already said, you know, with building automation into integrating everything, right, but, but sort of, I think that's, that's again for the IoT people you know, we would want to shake them awake and you know, really take that into account but, but there's a lot of people working on that but where we also see A need for some additional harmonization is now with the whole electric vehicle system. And I specifically tried to keep this vague here a little bit what is that system right? But I'm talking about the car that charge Shara the utility and the owner, you know, integrating this all together, we have good standards. You mentioned ocpp. Right for the charger, open ADR, we have you know, IEEE 20 30.5 for Ebola management, things like that. So we have good standards, but we don't really have yet a, a quantifiable, or I should say a quantifiable framework for all of these things working together, right, so that the customer can take advantage of that. Knowing if I buy a bagel XYZ. I know I can, you know, get a better tariff from my utility, maybe if they manage my charging. You know, what's, what's the interaction? Right? At this point, buying an electric vehicle is still a novelty, I guess for people, right? They don't really think about you know, what, what do I have to do with my utility to charge it, you know, what implications are there. But sooner rather than later, it will become not buying an Eevee. Right, but just buying a car?
Jim Frazer
Which I agree with you across across the continuum. First off, myself, and my two neighbors, cannot all charge our EVs at the same time when we're all on the same transformer. Yep. Who's going to broker that? Am I going to have a micro grid where I broker my needs against my neighbors? Or is utility going to do something and manage that or some third party? But and that's at one end of the continuum? On the other end of the continuum is, oh, I'm a school district. And I'd like to charge my 300 buses. And what substation do I need? Or is the approval process so long? In terms of years? Yeah, that now I want to build a PV and battery storage network to charge my buses? I think we're all we're getting faced with questions that we just never, never had before. To make the school buses take home vehicles for the bus drivers. Right.
Rolf Bienert
And, you know, I think I think, and maybe we are getting a little philosophical now, but you already basically said it, that with all of this, there needs to be a bit of a change of mentality, right? I mean, we know that right? We realize that it's, you know, it's easy. You hop in the car and wanting to drive a few 100 miles away, and you realize, oh, my gas is low, no problem. I go to the gas station, fill it up, right. And then I go, right, no, no big deal. But everybody kind of used to that. But okay, now you have to maybe think about that the day before, right? So oh, I need to go further tomorrow than just to work. So I need to have my battery fully charged. So maybe I need to go in my app, right and tap the i need a full charge button. Right to uh, to leave. And you know, a charger on the way are there or whatever it is, right. So they there is a certain certain change there. Whether this is good or bad, you know, it's always it's always a good question, right? Any any change is good and bad, right? So you have to change your behavior, but there might be other
Jim Frazer
roles. This has been an enjoyable hour. Thank you for educating myself and and our audience. Lastly, if someone if anyone in our audience would like to reach out and contact you, can you share some contact information? Absolutely.
Rolf Bienert
My email address is very simple. It's Rolf at open adr.org. So that's R O L F. At Open ADR dot orc. Or you know, just go to our website, open ADR dot O R g.org. And that is a contact form or info at open adr.org. If you forget my my first name, all of these come to me one way or the other. But of course I'm also on LinkedIn if you search For off peanut, and that's probably the the most the most common place I hang out here and there. So that would be the easiest through these two means.
Jim Frazer
We'll roll. Thank thank you for joining us today.
Rolf Bienert
Thank you for having me, Jim.
Jim Frazer
Once again, our guest today has been Rolf Bienert of the open ADR Alliance. He's the managing director over there. And we hope to see all of you again on the next episode of the sustainability podcast. Thank you for joining us today.
