WEBVTT 00:00.000 --> 00:15.720 OK, welcome. This talk is about flex measures. It's in a Linux-NG foundation project. It's about 00:15.720 --> 00:20.480 optimizing the use of flexible assets, so it's really related to the talk we just heard 00:20.480 --> 00:26.040 as well. And I'm glad that we had an introduction about what you need to optimize in the 00:26.040 --> 00:32.840 different time horizons, so that's really set to sing. I'll be talking a little bit of flex 00:32.840 --> 00:37.240 measures, but I have talked about earlier. Today I'll talk about something we're working 00:37.240 --> 00:42.880 on, which is expanding the use of flex measures past optimizing sites and going to the 00:42.880 --> 00:50.840 community level. So flex measures briefly what it is. It is a smart planning layer. The 00:50.840 --> 00:56.880 goal is that anybody, any organization that is offering energy services, where flexibility 00:56.880 --> 01:01.760 of the assets, heat pumps, batteries, and so on, or industry processes, plays a role that 01:01.760 --> 01:09.320 they can adapt, whatever they're doing to add something smart on top. Yeah, we've also 01:09.320 --> 01:14.680 really thought about the developer in that, so there's lots of tooling, so developers can 01:14.760 --> 01:22.880 use CLIs, APIs, Docker, and so on to make it work for them. As I said, I talked earlier 01:22.880 --> 01:28.000 about flex measures and various things we did, so check that out. 01:28.000 --> 01:35.760 Flex measures is meant to be a live platform, so you have UI and we can use what your structure 01:35.760 --> 01:43.200 of your assets is that you're optimizing. You can really talk about the way that it should handle 01:43.240 --> 01:48.240 flexibility in the UI now. That's something we did last year. I was basically hidden in 01:48.240 --> 01:54.720 models in the API, and we also added just as a good doctor, we have a, of course, Sregner 01:54.720 --> 02:01.320 Docs and really interact. It's a status page, what's happening now. But I also want to highlight 02:01.320 --> 02:07.240 today that it's also very scriptable, so there's a flex measures client, and then you 02:07.240 --> 02:12.520 don't have to think about the API. You're basically right functions like here at the top. 02:12.520 --> 02:18.760 I want to create a structure, please make me some assets. These should be the dashboards 02:18.760 --> 02:23.600 that I want to see for this kind of site. And very importantly, this is how you should handle 02:23.600 --> 02:31.600 flexibility for that site, so this is how the constraints, but also the way I want flexibility 02:31.600 --> 02:40.560 to be treated. And scripting sites can be very nice if you have basically something that 02:40.560 --> 02:46.000 you want to repeat. Maybe you're a business organization. You want to bring up the same kind 02:46.000 --> 02:50.760 of sites, again and again, and you've clicked it together. You see it works. You can now script 02:50.760 --> 02:59.760 it and have maybe 50 or 100 sites like that. Of course, it's also usable for simulations. 02:59.760 --> 03:04.880 And it's an example dashboard that is then made by just running that script. We have an example 03:04.880 --> 03:10.520 in the flex measures client repository where then something like this appears. This is actually 03:10.520 --> 03:15.920 a little simulation. We see two weeks of data that has been loaded in and then some optimization 03:15.920 --> 03:24.640 happens. Okay. But community energy management system, that's a new term. I think this term 03:24.640 --> 03:32.840 is quite established so I didn't make it up. What is it? It is the case of several sites 03:32.920 --> 03:40.680 of several houses, homes, buildings, but also business parks that want to operate on some 03:40.680 --> 03:46.440 level together. So the energy consumption needs to be coordinated in some way. The motivation 03:46.440 --> 03:52.840 is, in the Netherlands, for instance, often that the reconnection is limited and there can 03:52.840 --> 03:59.480 be no new companies registered at the business park or a new neighborhood cannot be planned. 03:59.560 --> 04:04.680 Certainly not with new modern energy devices like electric cars or so, because actually for 04:06.120 --> 04:12.440 five plus years out there will be no bigger connection. Energy, there are pooling your energy 04:12.440 --> 04:19.320 capacities together is one way out of this. Of course, you can also pool the flexibility you 04:19.320 --> 04:25.480 have and actually maybe have a joint business case. And you want to share your local energy 04:25.480 --> 04:32.520 maybe solar panels locally and the intention is that you don't push that to the grid and then 04:32.520 --> 04:39.640 let's have now later get someone else's energy from the grid again. All that would be part of 04:39.640 --> 04:45.320 this community energy management system. And I want to briefly talk about two ways you can look at that. 04:45.320 --> 04:52.200 So this, what I'm calling the fleet design, would be that you have these sites and they all 04:52.360 --> 04:59.400 transmit some data and maybe some forecast and preferences to this community energy management system 04:59.400 --> 05:03.640 and that would be in charge of looking at all the assets like a big fleet and then say, 05:03.640 --> 05:09.000 well, I think I'm making a big plan for all of you. This is a big optimization problem. 05:09.640 --> 05:16.280 Here you go, you do this, you do this. A different design might be and that's what we have 05:17.240 --> 05:24.440 decided to go for in an ongoing project actually here that I mentioned it also is together with TNO who 05:24.440 --> 05:32.760 had a talk just earlier. Is that at each site actually makes its own schedule just as before and just in 05:32.760 --> 05:41.160 the top we had before. But then on a high level, we look at that schedule aggregate of all the 05:41.160 --> 05:46.760 schedules and say, well, this would work or it wouldn't work because maybe at 4 p.m. that would 05:46.760 --> 05:54.200 create a peak that an aggregated peak that the DSO doesn't allow us to do for instance. And then 05:54.840 --> 06:01.160 give feedback and ask the local energy management systems to adjust what they were planning to do. 06:03.320 --> 06:08.440 We see some advantages with that. So in that research project, we actually had a discussion, 06:08.440 --> 06:14.920 we looked at that and talked, had a couple meetings or what should we be doing. Each approach has 06:14.920 --> 06:19.720 some advantages and drawbacks. We decided this one is the one we're going for for these kind of 06:20.520 --> 06:27.480 advantages. We like that it preserves the autonomy for each of the sites to do things their way, 06:27.480 --> 06:35.000 to add assets and don't necessarily have to tell everybody about it, to have maybe even their 06:35.000 --> 06:42.120 own energy contract, to keep things autonomous for themselves. Might also be a bit more skatable 06:43.720 --> 06:47.400 if you're really doing these optimizations and doing it if they're worried about adding more. 06:49.880 --> 06:57.160 Okay, I have a short talk, so I can't go into how we did that within lectures a lot, 06:57.160 --> 07:04.600 I'll just do two slides like this. Here I want to show how in the development we're currently 07:04.600 --> 07:12.200 doing, so we're going to prototyping this. We've added a community scheduler and in flex measures, 07:12.200 --> 07:19.640 we have schedulers, we have algorithms, not genetic algorithms, but more in the linear programming 07:19.640 --> 07:25.880 into what's corrected programming. But you can add your own schedulers, so you flex nurses are 07:25.960 --> 07:31.800 very extensible system, that's the point I'm making here. This is a bit the code that we're doing. 07:32.840 --> 07:39.320 So this is basically registering a new scheduler. Now in this case the community scheduler 07:40.680 --> 07:47.000 and you see a bit the logic was just highlighting. Computing the aggregates from the schedules, 07:47.000 --> 07:53.080 we look if there are breaches, so if at 4 p.m. for instance, there would be all together, 07:53.080 --> 08:02.280 but it's not allowed. And the way we're doing it is creating a feedback that is actually nudging 08:02.280 --> 08:08.760 all the local EMSs to adjust their schedule around that time. That's what we call it in peak 08:08.760 --> 08:21.160 price approach. The second course slide, this will be how we actually scripting basically to run 08:21.160 --> 08:27.320 that. So there's a async call for all the EMS schedulers to make the schedule and once they're all 08:27.320 --> 08:33.240 there, then we decide does the community can the community run for the next 25 hours like this? 08:33.240 --> 08:39.080 It's all all the plans, okay? Or do we need to tell them to do a iteration period in adjust them? 08:41.000 --> 08:43.640 That's what's not rocket science over here. It's the actual 08:44.040 --> 08:49.320 optimization still being made by the EMSs. How much time do I have? 08:52.600 --> 09:02.600 All right. This is how this looks in the flex measures UI. If we create this community with two homes 09:02.600 --> 09:08.360 actually and they all have some devices. And each of these devices has this own little flex 09:08.360 --> 09:17.480 configuration, how should I be treated and so on and so on. And then here this will be the dashboard. 09:17.480 --> 09:23.640 I have enough time to switch and also show how in the flex measures UI you can 09:26.840 --> 09:37.640 click on by play button up there. So we should work again. And you can see how this 09:37.720 --> 09:42.600 flows develop. So this is the whole dashboard we made for the community. And here we're stepping a 09:42.600 --> 09:49.640 bit through time to really see what are these plans that we know? Well that's the dotted lines. 09:49.640 --> 09:54.120 And while we go through time, how are the plans that we have developing? 09:55.960 --> 10:00.600 So here we there's a little button that we can hit to just do one step at a time. 10:01.320 --> 10:12.520 All right going back. And well I'm of course here to show the first results. So this would be 10:14.040 --> 10:20.200 what happens if we don't have that community EMS layer on top of the flex measures EMS is doing 10:20.200 --> 10:28.040 their thing not being aware of the shared problem of the capacity, limit capacity. So the limit 10:28.040 --> 10:33.480 capacity here would be that orange line. And for the first hours we're way above that. 10:34.440 --> 10:41.960 And then here is the outcome that has happened after the community EMS found out there's 10:41.960 --> 10:47.640 problem applied some peak pricing so that they all adjust their own flexibility optimizations. 10:48.280 --> 10:53.640 And we're coming up pretty okay. I think there's a realization error because as we also discussed 10:53.720 --> 11:00.040 in the talk earlier, if you don't have perfect forecasts. So you cannot be sure that your 11:00.040 --> 11:04.520 plan will actually be exactly happening like that and optimization planning is 11:05.320 --> 11:11.880 making the best of all the forecasts you have. And then there's still the task of course for 11:13.400 --> 11:20.440 a more direct time loop to fix these errors as well. But what we need to do in energy 11:20.440 --> 11:28.520 optimization planning is to bring the system plan to very close state or better state. 11:31.800 --> 11:37.640 Well that's the end of this talk. So the community EMS management system prototype that we're building 11:39.000 --> 11:45.880 has this first design decision right no fleet control but this federated control. 11:46.840 --> 11:52.520 In the first prototype shows that it's working. There's a few things we can talk about. 11:52.520 --> 11:59.320 I have some other slides here about for instance the waterbed effect. What happens if they all move 11:59.320 --> 12:04.200 they all make the very same decision to move let's say from 4 p.m. and they all move to 5 p.m. 12:06.280 --> 12:10.520 And very interesting problem and then we have a few ideas to work on that. 12:10.760 --> 12:18.280 But of course there's also more that the community management management system can do. 12:18.280 --> 12:24.360 As I said earlier not only preventing that there's peaks above certain limit on the 12:24.360 --> 12:30.920 substation but there's even, you know, nudging towards self consumption nudging towards 12:30.920 --> 12:36.920 maybe even making money as a community because there's flexibility options from the grid 12:37.000 --> 12:42.280 where you can make increase of profits. I'll stop there. Thank you for listening. 12:51.160 --> 12:51.880 Any question? 12:51.880 --> 13:06.920 Yes please. How does this the community EMS communicate with the different sides with 13:06.920 --> 13:13.880 only the pricing or in this way like the cuts of sides or cuts of the 13:14.840 --> 13:21.800 the question is how the communication between the community EMS and the local EMS is 13:21.800 --> 13:30.200 actually looks like. Right. So yeah at this moment we have decided that it's price signals 13:30.200 --> 13:35.880 or even capacity signals. So that's the first level is prices and that's basically nudging 13:35.880 --> 13:42.280 approach. You could also call it penalties. The community EMS is not actually charging money at 13:42.280 --> 13:50.120 the end but using the because it's an economic optimization at the end using prices as a nudging. 13:50.120 --> 13:56.280 But if a few iterations have passed and the solution isn't there then a second level can be 13:56.280 --> 14:02.840 capacity. So I will your please stay within this, within this kilowatt limit. You're not allowed to go above it 14:02.840 --> 14:09.320 for instance. There's a question from the internet. How does EMS integrate with those SES? 14:09.960 --> 14:18.440 Yeah so the question is how the C EMS integrates with the SES. That question might be 14:19.800 --> 14:27.400 regarding how we actually control SES and the answer to that would be that flex measures itself 14:27.400 --> 14:32.360 is not it's just a planning layer so it doesn't actually talk to any SES specifically. 14:33.400 --> 14:38.760 We have also some homocystid integrations. There isn't homocystid administration for flex measures 14:38.760 --> 14:45.400 itself so that's similar to the talk we had earlier. We also integrating with some smart gateway 14:45.400 --> 14:51.880 companies who are actually experts to really talk to specific SES. That's a big topic that we're 14:51.880 --> 15:02.200 not focusing on. What types of organisations are using this and what's the scale of the SES? 15:02.840 --> 15:11.960 The question is what type of organisations and what scale are using this? This research project 15:11.960 --> 15:18.760 what's happening is the focus would be on residential neighborhoods and so that was that motivation 15:18.760 --> 15:28.200 came from but we also think that is equally useful for business parks and then you're looking at 15:28.200 --> 15:35.400 S&Es I would say. Certainly if they have higher energy consumption then the same principle 15:35.400 --> 15:40.120 can be applied. This doesn't happen at every country yet but certainly the Netherlands 15:41.800 --> 15:51.080 businesses can't actually electrify or even grow their business because the DSLs have to tell 15:51.080 --> 15:58.200 them that their capacity isn't growing so the motivation is there on that level to find solutions 15:58.200 --> 16:03.400 like this. We're looking at the technical solution here but the main bottleneck actually is more 16:03.400 --> 16:09.640 organisational for all of them to come together and agree to give up their individual contracts 16:09.640 --> 16:16.280 and go into collective contracts and so on. All right, that's it. Thank you very much.