OK, welcome. This talk is about flex measures. It's in a Linux-NG foundation project. It's about
optimizing the use of flexible assets, so it's really related to the talk we just heard
as well. And I'm glad that we had an introduction about what you need to optimize in the
different time horizons, so that's really set to sing. I'll be talking a little bit of flex
measures, but I have talked about earlier. Today I'll talk about something we're working
on, which is expanding the use of flex measures past optimizing sites and going to the
community level. So flex measures briefly what it is. It is a smart planning layer. The
goal is that anybody, any organization that is offering energy services, where flexibility
of the assets, heat pumps, batteries, and so on, or industry processes, plays a role that
they can adapt, whatever they're doing to add something smart on top. Yeah, we've also
really thought about the developer in that, so there's lots of tooling, so developers can
use CLIs, APIs, Docker, and so on to make it work for them. As I said, I talked earlier
about flex measures and various things we did, so check that out.
Flex measures is meant to be a live platform, so you have UI and we can use what your structure
of your assets is that you're optimizing. You can really talk about the way that it should handle
flexibility in the UI now. That's something we did last year. I was basically hidden in
models in the API, and we also added just as a good doctor, we have a, of course, Sregner
Docs and really interact. It's a status page, what's happening now. But I also want to highlight
today that it's also very scriptable, so there's a flex measures client, and then you
don't have to think about the API. You're basically right functions like here at the top.
I want to create a structure, please make me some assets. These should be the dashboards
that I want to see for this kind of site. And very importantly, this is how you should handle
flexibility for that site, so this is how the constraints, but also the way I want flexibility
to be treated. And scripting sites can be very nice if you have basically something that
you want to repeat. Maybe you're a business organization. You want to bring up the same kind
of sites, again and again, and you've clicked it together. You see it works. You can now script
it and have maybe 50 or 100 sites like that. Of course, it's also usable for simulations.
And it's an example dashboard that is then made by just running that script. We have an example
in the flex measures client repository where then something like this appears. This is actually
a little simulation. We see two weeks of data that has been loaded in and then some optimization
happens. Okay. But community energy management system, that's a new term. I think this term
is quite established so I didn't make it up. What is it? It is the case of several sites
of several houses, homes, buildings, but also business parks that want to operate on some
level together. So the energy consumption needs to be coordinated in some way. The motivation
is, in the Netherlands, for instance, often that the reconnection is limited and there can
be no new companies registered at the business park or a new neighborhood cannot be planned.
Certainly not with new modern energy devices like electric cars or so, because actually for
five plus years out there will be no bigger connection. Energy, there are pooling your energy
capacities together is one way out of this. Of course, you can also pool the flexibility you
have and actually maybe have a joint business case. And you want to share your local energy
maybe solar panels locally and the intention is that you don't push that to the grid and then
let's have now later get someone else's energy from the grid again. All that would be part of
this community energy management system. And I want to briefly talk about two ways you can look at that.
So this, what I'm calling the fleet design, would be that you have these sites and they all
transmit some data and maybe some forecast and preferences to this community energy management system
and that would be in charge of looking at all the assets like a big fleet and then say,
well, I think I'm making a big plan for all of you. This is a big optimization problem.
Here you go, you do this, you do this. A different design might be and that's what we have
decided to go for in an ongoing project actually here that I mentioned it also is together with TNO who
had a talk just earlier. Is that at each site actually makes its own schedule just as before and just in
the top we had before. But then on a high level, we look at that schedule aggregate of all the
schedules and say, well, this would work or it wouldn't work because maybe at 4 p.m. that would
create a peak that an aggregated peak that the DSO doesn't allow us to do for instance. And then
give feedback and ask the local energy management systems to adjust what they were planning to do.
We see some advantages with that. So in that research project, we actually had a discussion,
we looked at that and talked, had a couple meetings or what should we be doing. Each approach has
some advantages and drawbacks. We decided this one is the one we're going for for these kind of
advantages. We like that it preserves the autonomy for each of the sites to do things their way,
to add assets and don't necessarily have to tell everybody about it, to have maybe even their
own energy contract, to keep things autonomous for themselves. Might also be a bit more skatable
if you're really doing these optimizations and doing it if they're worried about adding more.
Okay, I have a short talk, so I can't go into how we did that within lectures a lot,
I'll just do two slides like this. Here I want to show how in the development we're currently
doing, so we're going to prototyping this. We've added a community scheduler and in flex measures,
we have schedulers, we have algorithms, not genetic algorithms, but more in the linear programming
into what's corrected programming. But you can add your own schedulers, so you flex nurses are
very extensible system, that's the point I'm making here. This is a bit the code that we're doing.
So this is basically registering a new scheduler. Now in this case the community scheduler
and you see a bit the logic was just highlighting. Computing the aggregates from the schedules,
we look if there are breaches, so if at 4 p.m. for instance, there would be all together,
but it's not allowed. And the way we're doing it is creating a feedback that is actually nudging
all the local EMSs to adjust their schedule around that time. That's what we call it in peak
price approach. The second course slide, this will be how we actually scripting basically to run
that. So there's a async call for all the EMS schedulers to make the schedule and once they're all
there, then we decide does the community can the community run for the next 25 hours like this?
It's all all the plans, okay? Or do we need to tell them to do a iteration period in adjust them?
That's what's not rocket science over here. It's the actual
optimization still being made by the EMSs. How much time do I have?
All right. This is how this looks in the flex measures UI. If we create this community with two homes
actually and they all have some devices. And each of these devices has this own little flex
configuration, how should I be treated and so on and so on. And then here this will be the dashboard.
I have enough time to switch and also show how in the flex measures UI you can
click on by play button up there. So we should work again. And you can see how this
flows develop. So this is the whole dashboard we made for the community. And here we're stepping a
bit through time to really see what are these plans that we know? Well that's the dotted lines.
And while we go through time, how are the plans that we have developing?
So here we there's a little button that we can hit to just do one step at a time.
All right going back. And well I'm of course here to show the first results. So this would be
what happens if we don't have that community EMS layer on top of the flex measures EMS is doing
their thing not being aware of the shared problem of the capacity, limit capacity. So the limit
capacity here would be that orange line. And for the first hours we're way above that.
And then here is the outcome that has happened after the community EMS found out there's
problem applied some peak pricing so that they all adjust their own flexibility optimizations.
And we're coming up pretty okay. I think there's a realization error because as we also discussed
in the talk earlier, if you don't have perfect forecasts. So you cannot be sure that your
plan will actually be exactly happening like that and optimization planning is
making the best of all the forecasts you have. And then there's still the task of course for
a more direct time loop to fix these errors as well. But what we need to do in energy
optimization planning is to bring the system plan to very close state or better state.
Well that's the end of this talk. So the community EMS management system prototype that we're building
has this first design decision right no fleet control but this federated control.
In the first prototype shows that it's working. There's a few things we can talk about.
I have some other slides here about for instance the waterbed effect. What happens if they all move
they all make the very same decision to move let's say from 4 p.m. and they all move to 5 p.m.
And very interesting problem and then we have a few ideas to work on that.
But of course there's also more that the community management management system can do.
As I said earlier not only preventing that there's peaks above certain limit on the
substation but there's even, you know, nudging towards self consumption nudging towards
maybe even making money as a community because there's flexibility options from the grid
where you can make increase of profits. I'll stop there. Thank you for listening.
Any question?
Yes please. How does this the community EMS communicate with the different sides with
only the pricing or in this way like the cuts of sides or cuts of the
the question is how the communication between the community EMS and the local EMS is
actually looks like. Right. So yeah at this moment we have decided that it's price signals
or even capacity signals. So that's the first level is prices and that's basically nudging
approach. You could also call it penalties. The community EMS is not actually charging money at
the end but using the because it's an economic optimization at the end using prices as a nudging.
But if a few iterations have passed and the solution isn't there then a second level can be
capacity. So I will your please stay within this, within this kilowatt limit. You're not allowed to go above it
for instance. There's a question from the internet. How does EMS integrate with those SES?
Yeah so the question is how the C EMS integrates with the SES. That question might be
regarding how we actually control SES and the answer to that would be that flex measures itself
is not it's just a planning layer so it doesn't actually talk to any SES specifically.
We have also some homocystid integrations. There isn't homocystid administration for flex measures
itself so that's similar to the talk we had earlier. We also integrating with some smart gateway
companies who are actually experts to really talk to specific SES. That's a big topic that we're
not focusing on. What types of organisations are using this and what's the scale of the SES?
The question is what type of organisations and what scale are using this? This research project
what's happening is the focus would be on residential neighborhoods and so that was that motivation
came from but we also think that is equally useful for business parks and then you're looking at
S&Es I would say. Certainly if they have higher energy consumption then the same principle
can be applied. This doesn't happen at every country yet but certainly the Netherlands
businesses can't actually electrify or even grow their business because the DSLs have to tell
them that their capacity isn't growing so the motivation is there on that level to find solutions
like this. We're looking at the technical solution here but the main bottleneck actually is more
organisational for all of them to come together and agree to give up their individual contracts
and go into collective contracts and so on. All right, that's it. Thank you very much.