Okay, this is a massive strain that's talking about demand and response.
If you have no idea what it is, they're going to explain that and open ADR as an open standard
and a rust implementation of that.
Wow.
Yeah.
Great.
Well, welcome everybody.
Thank you all for coming.
Today, we're going to be giving a presentation about open leader RS about demand response
and about open ADR, like we just said.
So, open ADR is a protocol and open source protocol.
It stands for open automated demand response.
We're going to get into what that is exactly in the next 50 minutes.
We're going to be giving you some background about the open leader RS project.
A primer on demand response.
We're going to be looking at a Dutch adoption of open ADR and Dutch use case.
And we'll be looking at future developments.
We don't have too much time.
So if you have questions, we'd love to answer them, but preferably at the end.
But first, let us introduce ourselves.
Yeah.
Hi, I'm Max.
I'm working for the Dutch software consultancy critical, specialized in rust and the tech lead
of the open leader RS implementation.
And I'm staying on howling and I am a specification writer and software developer at ALADNL.
We're going to be talking a bit about ALADL later on.
And I would call myself a powers user of open leader RS.
Right.
Before we start to talk about demand response, we need to get into grid congestion a bit.
So because this has a lot to do with demand response,
we're looking at the grid congestion map of the Netherlands as you can see it's quite red and red is not good.
It means that there's a capacity shortage.
So essentially, almost no new connections can be made, existing ones can't be expanded.
And this is a big impact on society.
The housing projects are being put and hold.
This is a scanning span.
So the government is looking for ways to solve this problem.
We could just build more transformers, but as you can imagine, this takes time.
It costs money.
So we're looking at other solutions to fix this.
And it might seem there's no capacity left at all, but this map doesn't really tell the whole story.
Because if you look at the day-to-day basis, we see something like this.
We see a waveform with two peaks and valleys all besides them.
And this kind of means that there's two peaks in which lots of people use electricity.
And in between, we've got a lot of space on the grid left.
So if you can make better use of them, we still have some capacity.
And we can do that with demand response programs.
The demand response is the idea that demands, so customer appliances, like washing machines, heat pumps, what have you?
Can respond to the status of the grid, so how busy is it on the grid?
And a demand response program is a grid operator communicating the sending signals and communicating the status of the grid to consumers, so you at home or companies.
So they can change the way to use electricity.
This can come into form of price signals or capacity limits, but the goal is to limit use during peak times either way.
This benefits the DSO because there's more capacity, so they can get people on the network faster or they have to build less transformers.
But as a customer, it's also nice because electricity in those valleys is most of the time cheaper and a lot cleaner.
And as works as the DSO predicts a peak, they send a signal to the customer and then a customer appliance preferably automatically shuts down or it shifts its use to another time of the day.
And that works exactly with Open80R is going to be explained by Max.
Yeah, so let's have a quick look at what Open80R is now. Open80R is a standard to solve the problems that's time just laid out and it stands for open automated demand response.
It originated back in 2009 from the Lawrence Berkeley National Laboratory and has quickly been taken over by the newly founded Open80R Alliance.
That still governs the spec maintenance and development.
And for us, most interesting are actually the versions 3.0 and 3.1 that have been released 2024, 2025 respectively.
Because what mainly changed from the 2.0 versions there is that they switched from XML and XMPP to JSON and HTTP, which makes development a lot easier as many can imagine, I guess.
In general, Open80R is a very high level messaging protocol, a very generic one that can be used for many use cases and supports many use cases.
And because of that, to have a very specific use case, you typically need to have an additional so-called profile, which further specifies how exactly to use these messages and how exactly to behave.
And one such profile is the grid where charging that a lot now is developing and maintaining, and I guess time will talk about that later a bit more detail.
So how does that work on a high level?
We do have two parties involved here, generally, that is the distribution system operator, basically the grid operator, and in the case of the grid where charging we have the charge point operators.
In the Open80R speech, they run a business logic and a customer logic, and they have a so-called virtual top note, I would just call it a server, and a virtual end note, basically the clients of that whole thing.
And communication, at least for the basic use case, happens over two message types that are so-called events and reports.
So the virtual top note, the VTN, will send out events to the customer logic, the customer logic will somehow react to that, and it may or may not send back reports.
That, for example, tell the DSO on how much energy JF used in the last hour, or what they possibly predict to use in the future maybe.
All these are possible use cases, how you could use that.
So our implementation, open leader RS, is then an implementation of that standard Open80R, and that's joined effort by Elatonell and Twirhov, and it was born out of the desire from Twirhov to add, or to use our expertise that we already gained in other internet protocols like the network time protocol to create a positive impact into the energy domain as well.
And that way, our ways we're crossing with Elat, that we're also planning to work with Open80R, and so we joined our forces to get open leader up and running.
Then we also sponsor this to the Elat Energy organization that now is housing this whole project.
So what does that actually, what can open leader do? We do have a well-tested Open80R 3.0 implementation already, that's used in production.
We'll talk about that in a second. We just released a better version of the Open80R 3.1 implementation, and we are currently implementing a so-called subscription feature, which basically lets you send real-time signals for the great.
We're working on a CLI that makes debugging and prototyping easier, and good news is we are already funded for 2026, so maintenance and development is going on.
Short notes on why we're using Rust, reasons are fairly simple, reliability is the biggest reason here, because for the energy grid we do need a reliable and preferably memory safe and efficient core code here.
The deployment is pretty easy, because you just get a single binary that you can just run, you don't need a job of virtual machine to be set up, you don't need a python into a return, the right version, something like that.
And growing Rust adoption across the infrastructure and embedded systems communities also shows us that we are on the right path here.
Don't get worried, enter our probability is easy, communication just happens over HTTP as I mentioned, so virtually any program language can interact with them, doesn't matter if you're implementing the business logic, the client logic, whatever you are, you can just interact with HTTP, you don't have to mess with the Rust code if you're not familiar with that.
Having said that, Stan will talk about how this is actually used in practice where we are and what's going on in the future.
Thank you, Max. So we just talked about Open Leader about Open ADR, but who's actually using these projects, these protocols.
One project is by the Dutch Research Institute ALAT, which I'm a part of.
It's a Dutch Research Institute funded by the district service operators or the grid operators in an Netherlands.
And the goal of the project or of this use case was making EV charges aware of the grid specifically, so the idea was that EV charges could be limited during those feet times to make sure the grid doesn't get overloaded.
It's part of the Dutch National Charging Infrastructure agenda, which is a government program to oversee the rollouts of EV charges in an Netherlands.
These how it works as a CPU pulse for data, it's a simple rest API so they do a get request, they get events and they see when their charges are limited and then they apply those limits via a protocol like OCPP on their charges.
As part of the project, we also made custom tooling, mainly for the DSO, so we can check that the events they put on the servers are actually correct.
So currently the use case of mainly public EV charges, charging stations of what we call slow charges, stages or 11 kilowatt charges.
We're also looking to broaden the scope to target homes via home energy management systems and because Open ADR is very high level, this is not actually that big of a problem.
We're also looking to define a model for grid congestion or multiple levels so we can make more efficient use of grid resources.
ALAT is also a created a few open source projects, we have a Python SDK for the EV inside, so if you want to connect to Open ADR you can do so in Python as well.
With the grid or charging compliance plugin, we're also making a grid graphical user interface, mainly also for our own pilots and test use case so we can more easily manage those.
There will open source so you can put them up on GitHub.
Looking ahead, ALAT and VedaRolf are committed to this project like Mark said the funding is secured for 2026.
Please go and talk to us after this talk or reach out to us via Slack.
There's a one-monthly technical steering committee meeting of Open ADR if you want to get involved.
You can also create a PR with good first issues, Max has made sure that there's a few of those.
And if you want to learn more about Open ADR, you can join us at ALAT for the European Flexibility Initiative in March, which will include a vehicle to grid demo using Open ADR in Unim.
That was a presentation if you have any questions, we will be happy to answer them. Thank you.
Right, yes.
So your question was if Open ADR implements the client side of the server side, I think Max can tell us something about that.
Yes, so as of now, we're mostly focused on the server side, the VTN.
We do also have a VEN client, though the thing is the VEN is mostly a very abstract project idea in Open ADR and so it's a very thin layer, which mainly is abstracting away the HTTP requests.
So we do have sort of rust SDK if you want to say so, but most of the work is the server side, the VTN.
Yes.
So would I invite, it already is some home appliances or something like that, or is it just some of the future right now, and it's your only working with new administration.
So the question was whether it's already in home appliances or at the moment still limited to public charging, and I guess that is something for you.
So Open ADR is not really targeting specific devices, so the idea is that it's very high level, it will send a signal or kind of a description of what a group of appliances need to do.
So what you could see in the future is a home energy management system, for instance, being able to ingest Open ADR signals and then going to your charger or your heat pump and then applying limits or the reading price is something like that.
Any other questions? Oh yes.
So the question was if this is mainly for Ethernet or Internet use or also for over power lines, if it will communicate over power lines, so Open ADR is very specifically arrest API, so it's very specifically Internet protocol.
Because it's so high level.
The idea is that if you want to apply Open ADR to a device, you can translate those and then you can use something like Zigbee, maybe, or a matter or whatever else as to, of course, if you want to.
Right. Yes.
So the question is if what a virtual power plant would use a server or a client, in that case, that would be a V and set it would be a client, so you would can be communicating with a grid operator and then getting signals from their server and then using those.
That's up.
Too bad.
Right. Thank you very much.
Thank you.