WEBVTT

00:00.760 --> 00:01.440
Okay.

00:04.700 --> 00:12.820
Welcome to another session of this course, which is, well, not

00:12.820 --> 00:16.680
following a fixed schedule as normal courses, but we had several

00:16.680 --> 00:17.780
times.

00:17.940 --> 00:24.840
Now we are, we moved to Monday afternoon, and I'm glad that some

00:24.840 --> 00:29.120
people are back, who said last time, before we moved to Monday, that

00:29.120 --> 00:31.800
Monday would be much better, and when we had it the first time on

00:31.800 --> 00:33.580
Monday, they were not there.

00:36.260 --> 00:43.200
And so it's good that more of you are here again, and I'm glad that

00:43.200 --> 00:45.460
you also filled in these evaluation forms.

00:45.740 --> 00:46.740
I hope that you all did that.

00:47.220 --> 00:51.400
If somebody did not do that, you're welcome to do that afterward.

00:51.620 --> 00:53.880
Somebody agreed to take it to the...

00:54.560 --> 00:55.920
You take it?

00:56.060 --> 00:56.260
Okay.

00:56.560 --> 00:56.940
Perfect.

00:57.200 --> 00:57.580
Thank you.

00:58.320 --> 01:03.940
So, last time, we looked at, certainly, smart energy distribution, and

01:03.940 --> 01:14.520
we had looked at the self-organized balancing systems, and also, we

01:14.520 --> 01:19.120
also looked at smart home energy management, and we had looked at

01:19.120 --> 01:22.360
quite a few different topics here.

01:22.440 --> 01:27.720
I had shown you, again, briefly our projects, Meragio, Meragio Mobile,

01:28.100 --> 01:32.200
that we had worked on, like the first results here on flexibility in

01:32.200 --> 01:38.140
the Meragio scenario, where we have looked at possibilities of

01:38.140 --> 01:44.240
residents in normal homes, how they would actually respond to price

01:44.240 --> 01:44.760
signals.

01:45.800 --> 01:49.260
We had Meragio Mobile, where we looked at how we can integrate

01:49.260 --> 01:54.900
electric vehicles into the energy management, in particular, the

01:54.900 --> 01:55.340
batteries.

01:55.520 --> 01:57.060
We saw that there's quite some potential.

01:57.800 --> 02:01.220
I showed you our energy smart home at least on slides.

02:02.040 --> 02:03.700
You can go there sometime.

02:03.900 --> 02:06.780
We have to talk about that, when we'll actually go there.

02:07.380 --> 02:11.520
I told you something about the aspect of smart homes in general that's

02:11.520 --> 02:17.360
normally associated with home automation, and so comfort, security,

02:17.440 --> 02:17.980
and health.

02:18.100 --> 02:22.120
And we are looking at energy, extending the standard focus of smart

02:22.120 --> 02:24.820
homes with respect to the energy aspect.

02:25.880 --> 02:31.720
We discussed a few possible scenarios of those homes.

02:31.720 --> 02:38.820
I showed you the ingredients of our energy smart home lab on campus,

02:39.840 --> 02:43.060
where we have all kinds of different components installed in order to

02:43.060 --> 02:48.480
be able to use that as some kind of power hardware in the loop, where

02:48.480 --> 02:55.600
we have some possibility to actually test the way we can influence the

02:55.600 --> 02:58.360
system by controlling all the devices there.

02:59.260 --> 03:03.180
We looked briefly at that scenario.

03:03.900 --> 03:11.600
I showed you what kind of vehicles we have there, and then we looked

03:11.600 --> 03:16.660
at possibilities to classify appliances in these houses, like there

03:16.660 --> 03:18.700
are observable and controllable appliances.

03:19.460 --> 03:23.400
Observable appliances are important because it can observe them, and

03:23.400 --> 03:27.520
we know that they have some fixed ways of reoccurring, and we can

03:27.520 --> 03:34.200
predict a load profile for the next day, and can try to establish a

03:34.200 --> 03:38.920
good schedule for those devices which we can control and find the best

03:38.920 --> 03:41.180
possible time slot for running.

03:41.940 --> 03:46.360
This was shown in this example here on the...

03:47.600 --> 03:49.060
Here it is.

03:49.640 --> 03:54.600
We looked at this schedule where we have different devices which could

03:54.600 --> 04:01.760
be moved according to the price signal, forwards or backwards in time.

04:02.700 --> 04:07.680
And then I showed you a little bit more about the smart home, the

04:07.680 --> 04:14.280
interface we have there, and showed you our ways of displaying

04:14.280 --> 04:18.180
actually the degrees of freedom of the different components.

04:18.380 --> 04:23.760
For example, a dishwasher, or this was a tumble dryer actually, and an

04:23.760 --> 04:30.180
important point is that the residents of a house can easily specify

04:30.180 --> 04:32.980
their degrees of freedom for using such an appliance.

04:33.660 --> 04:37.480
The system would respond with the automatic start, and if the user

04:37.480 --> 04:43.860
doesn't like that, you can always just click on the start button or

04:43.860 --> 04:46.220
this end button and just switch it on.

04:47.400 --> 04:54.360
I showed that was the... this was the last slide, last time I think.

04:54.700 --> 04:56.080
Yes, that was the last slide.

04:56.860 --> 05:04.140
So here I showed you the interface for the electric vehicles, and in

05:04.140 --> 05:07.800
our smart home, where... I hope you can see that actually.

05:08.000 --> 05:10.220
Maybe I have to move this a little bit to the side.

05:11.420 --> 05:12.360
Can all see it?

05:12.920 --> 05:14.960
Okay, somehow it's moved over here.

05:15.100 --> 05:19.200
I cannot... don't want to move that projector really.

05:20.160 --> 05:24.760
Okay, so here we have the interface showing the energy flows in the

05:24.760 --> 05:30.620
smart home, which is important to actually show what's happening in

05:30.620 --> 05:31.080
the house.

05:31.080 --> 05:34.580
Some simple ideas are implemented here.

05:34.600 --> 05:41.980
For example, this green line here indicates that currently there's a

05:41.980 --> 05:45.680
surplus of energy feeding back energy into the grid.

05:46.240 --> 05:50.280
Otherwise, if we would get energy from the grid, it would be painted

05:50.280 --> 05:50.780
in red.

05:51.640 --> 05:56.040
And so you'd see just easily what the current situation of the house

05:56.040 --> 06:00.060
is, and you also see the flows of power in the house.

06:00.620 --> 06:04.100
And with respect to the electric vehicle, what you see there is the

06:04.100 --> 06:09.160
interface, which allows actually to easily specify the next departure

06:09.160 --> 06:13.240
time, because you would like to have a fully charged battery at that

06:13.240 --> 06:14.460
point in time.

06:14.920 --> 06:18.220
You specify the minimum range that you would like to have all the

06:18.220 --> 06:18.560
time.

06:18.860 --> 06:22.740
Maybe 15 kilometers is a little bit too low, but you can just specify

06:22.740 --> 06:28.740
any range there, and make sure that you always can rely on having this

06:28.740 --> 06:34.260
range if you are going on a spontaneous trip before the initially

06:34.260 --> 06:35.700
indicated departure time.

06:37.000 --> 06:41.880
All this is actually implemented using all kinds of devices that we

06:41.880 --> 06:42.780
got off the shelf.

06:43.380 --> 06:47.240
Some standard components, which we use for controlling all the

06:47.240 --> 06:50.680
different components in there, so it's real implemented.

06:50.940 --> 06:54.460
You can see it when we will have a look at that house.

06:55.780 --> 07:01.420
And in the background, we have this energy management system, which is

07:01.420 --> 07:04.480
performing all these optimizations in the background.

07:04.700 --> 07:05.800
Now, how can we do that?

07:06.440 --> 07:10.120
We have all our components, which are in the house.

07:10.540 --> 07:14.320
The washing machine, the fridge, or whatever you have there.

07:14.320 --> 07:19.540
And then we have to know what these devices actually are currently

07:19.540 --> 07:19.960
doing.

07:20.020 --> 07:23.100
We have to observe them, and maybe we have to send some activation

07:23.100 --> 07:23.620
signal.

07:24.060 --> 07:28.920
So we need some kind of observer, that's the O, and controller, and we

07:28.920 --> 07:30.300
need an interface for that.

07:30.760 --> 07:38.380
And we have to abstract from the detailed features of these devices.

07:39.140 --> 07:44.800
I underline this H-A-L, because H-A-L is not the computer you know

07:44.800 --> 07:53.060
from some story, some novel, but it's the hardware abstraction layer.

07:53.820 --> 07:58.460
The hardware abstraction layer is just abstracting from certain

07:58.460 --> 08:03.180
details of those devices, and then you can get the appropriate

08:03.180 --> 08:06.960
information for observing those systems, and for controlling them.

08:06.960 --> 08:08.920
Now, you have all the individual devices.

08:09.540 --> 08:14.580
You have also some interface to communicate with the user.

08:14.960 --> 08:17.660
You saw this energy management panel.

08:18.180 --> 08:22.160
So you can communicate with the user in the house, and you get some

08:22.160 --> 08:27.420
information from the energy provider about prices.

08:27.760 --> 08:32.080
You might get some information from the distribution system operator

08:32.080 --> 08:39.620
with respect to some potential constraints for power, so some

08:39.620 --> 08:41.280
preferred power profile.

08:42.120 --> 08:47.680
And then this information is actually collected into some larger

08:47.680 --> 08:54.820
observer and controller, where all this information is accumulated,

08:55.820 --> 09:00.380
used to generate some kind of load profile to show the current

09:00.380 --> 09:07.560
situation, to learn something about, well, potential loads in the

09:07.560 --> 09:07.880
future.

09:08.580 --> 09:12.620
And then this is combined in order to actually be able to control the

09:12.620 --> 09:13.640
house appropriately.

09:14.160 --> 09:19.520
To control the house appropriately means do it in the best possible

09:19.520 --> 09:23.340
way, where best possible way has to be specified by some user.

09:23.500 --> 09:27.660
Usually he wants to just reduce the cost.

09:27.660 --> 09:33.380
So you would like to get a cost-efficient schedule, or maybe you would

09:33.380 --> 09:37.800
like to just use as much renewable energies as possible.

09:38.000 --> 09:39.600
Then you would have a slightly different objective.

09:40.120 --> 09:42.140
So this can be integrated in there.

09:42.500 --> 09:46.860
And then you have all these different features in there.

09:47.340 --> 09:52.000
You have the possibility to observe and control individual units.

09:52.460 --> 09:56.800
You can observe and predict what's happening in the house.

09:56.800 --> 10:00.920
You can learn and control what should be done in the house.

10:01.120 --> 10:04.940
And then this is sent back again to those devices in order to behave

10:04.940 --> 10:05.580
appropriately.

10:06.100 --> 10:09.760
And what you need certainly is also information from communicating

10:09.760 --> 10:15.160
with the user inside the house, and with some external entities who

10:15.160 --> 10:17.860
would provide prices, constraints, and so on.

10:17.860 --> 10:24.920
Now this is an architecture that has been designed actually in a

10:24.920 --> 10:28.560
certain research program that was the Organic Computing Research

10:28.560 --> 10:36.020
Program, which has run from 2005 to 2011, actually organized by

10:36.020 --> 10:36.940
myself.

10:37.460 --> 10:39.440
It was a large research program in Germany.

10:40.180 --> 10:46.340
And it was about distributed, decentralized systems, which communicate

10:46.340 --> 10:49.020
with each other to provide a certain functionality.

10:49.660 --> 10:52.960
We have designed this observer-controller architecture in that

10:52.960 --> 10:59.300
environment, in that framework, and actually designed it with respect

10:59.300 --> 11:04.400
to traffic control scenarios, and then extended it for this energy

11:04.400 --> 11:05.880
control system.

11:06.780 --> 11:09.940
And I would like to briefly tell you a little bit about organic

11:09.940 --> 11:10.420
computing.

11:10.420 --> 11:17.580
What I'm just showing you here is the cover of a book that we have

11:17.580 --> 11:21.780
provided as a result of that six-year program.

11:22.580 --> 11:27.160
So quite a thick book on all kinds of aspects that were treated in

11:27.160 --> 11:31.120
that priority program of the German Research Foundation.

11:33.200 --> 11:35.920
So organic computing, what is it about?

11:35.920 --> 11:43.960
As I said, it is about a world of components which are more and more

11:43.960 --> 11:50.000
getting intelligent, and components which can communicate.

11:50.860 --> 11:54.840
It is something which is sometimes called the ubiquitous network

11:54.840 --> 11:55.240
computer.

11:55.900 --> 12:00.700
That means a computer consisting of many, many, many different

12:00.700 --> 12:07.860
information processing units, which are almost always somewhere in our

12:07.860 --> 12:08.420
environment.

12:09.500 --> 12:13.320
So if you have all kinds of intelligent devices, you would like to

12:13.320 --> 12:15.740
make sure that you don't get lost in that network.

12:16.580 --> 12:21.000
And so they should be designed such that human needs are respected.

12:22.880 --> 12:25.680
The question is how do I actually know the human needs?

12:25.820 --> 12:28.860
Do you have some ideas of what human needs might be?

12:28.860 --> 12:33.200
Maybe you have to get the ideas of humans directly.

12:33.420 --> 12:35.620
I showed you this energy management panel briefly.

12:36.060 --> 12:39.760
That is a way of getting information on the human needs.

12:40.320 --> 12:43.320
Then they have to be robust, adaptive, and flexible.

12:45.160 --> 12:49.860
Robust usually means that there may be some disturbances.

12:51.040 --> 12:58.540
So for example, power supply can drop down because there is a cloud,

12:58.940 --> 13:03.000
and the PV panel does not work anymore or does not produce energy

13:03.000 --> 13:03.420
anymore.

13:03.780 --> 13:06.920
The system should still provide you with power.

13:07.620 --> 13:08.480
How can it do that?

13:08.520 --> 13:10.800
It has to be robust against disturbances.

13:12.100 --> 13:18.020
Or if you know the notion of robustness from other areas, usually it

13:18.020 --> 13:21.660
is the case that you have a certain disturbance or some attack on the

13:21.660 --> 13:26.160
system, some damage, or you do something to the system, but it still

13:26.160 --> 13:27.460
provides its functionality.

13:27.800 --> 13:28.420
It doesn't break.

13:30.020 --> 13:31.480
Then it has to be adaptive.

13:31.680 --> 13:34.300
It should be able to actually adapt to different situations.

13:34.740 --> 13:39.580
So for example, your mobile phone should be able to adapt to different

13:39.580 --> 13:46.260
environments, sometimes using 3G networks, and then maybe use WaveLAN,

13:46.900 --> 13:50.260
and then maybe just some edge functionality.

13:50.620 --> 13:56.420
So very different protocols that are used for communication, depending

13:56.420 --> 13:58.520
on the availability of services.

13:59.360 --> 14:02.500
Adaptiveness is the notion.

14:03.180 --> 14:07.420
Flexibility would mean that you might have different goals.

14:07.420 --> 14:13.840
On one day, you might want to have cost-efficient usage of energy.

14:14.440 --> 14:19.160
The other day, you would like to optimize for renewable energies that

14:19.160 --> 14:22.120
might be different from each other.

14:22.200 --> 14:25.340
Or in traffic, you could optimize for...

14:25.340 --> 14:29.360
like if you optimize traffic scenarios, street network with many

14:29.360 --> 14:32.560
different traffic lights, you might optimize for number of stops, or

14:32.560 --> 14:38.680
you might optimize for waiting time, for reducing the waiting time, or

14:38.680 --> 14:43.120
you might optimize for maybe just energy consumption, to reduce the

14:43.120 --> 14:43.780
energy consumption.

14:44.860 --> 14:47.380
So many different ways you could actually use that.

14:47.660 --> 14:52.720
And then you would like to have certainly the notion that this would

14:52.720 --> 14:56.540
be self-organized, so they should be able to do some things on their

14:56.540 --> 15:02.740
own, because there are so many devices that you would not like to

15:02.740 --> 15:07.620
actually reprogram them whenever some change is necessary, but they

15:07.620 --> 15:10.040
should be able to do that on their own.

15:10.920 --> 15:12.820
And so you need some kind of self-organization.

15:13.540 --> 15:18.420
And if you have a self-organizing system, you would like to have a

15:18.420 --> 15:23.140
situation where if this is the desired behavior, you know that my

15:23.140 --> 15:27.280
system will always stay inside those desired behaviors, it will not go

15:27.280 --> 15:30.960
outside and do something which is unwanted, and so it should be

15:30.960 --> 15:36.580
trustworthy, also perform the desired functionality in the way that

15:36.580 --> 15:39.040
you expect them to actually perform that.

15:40.340 --> 15:46.740
Trustworthiness is another topic which can be treated in a very formal

15:46.740 --> 15:51.500
way, in a very systematic way, which we will not address in this

15:51.500 --> 15:54.980
course, but which is addressed in, for example, courses on organic

15:54.980 --> 15:55.400
computing.

15:55.400 --> 16:00.720
Now, if we have systems which are robust, adaptive, flexible, self

16:00.720 --> 16:06.960
-organized, they have some kind of lifelike behavior, and so we just

16:06.960 --> 16:12.440
said, okay, we will call them organic computer systems.

16:12.700 --> 16:17.720
We, in this sense, is the community of computer engineering in

16:17.720 --> 16:18.060
Germany.

16:18.280 --> 16:22.120
We had a series of workshops, so we looked for what is our roadmap,

16:22.120 --> 16:30.060
what are the challenges for systems in 5, 10, 15 years ahead, so that

16:30.060 --> 16:35.800
was in 2002, and we said what kind of systems would we need, and so

16:35.800 --> 16:39.860
that was the challenges that we saw, and we said what we need is a

16:39.860 --> 16:45.900
system having some kind of organic behavior, and so for that we need

16:45.900 --> 16:47.320
the appropriate architectures.

16:48.100 --> 16:54.000
And this certainly did not come just out of the air, but there were

16:54.000 --> 17:00.820
quite a few similar initiatives, quite a few of them completely

17:00.820 --> 17:04.740
independent of what we did, but to some extent also we were influenced

17:04.740 --> 17:08.060
by those things like ubiquitous computing, autonomic computing,

17:08.620 --> 17:15.400
pervasive computing, all kinds of notions for collections of devices,

17:15.400 --> 17:20.420
which we get more and more intelligent, and can actually coordinate

17:20.420 --> 17:23.780
their activities in a reasonable way.

17:24.900 --> 17:29.820
So when we talk about organic computing, it is not that we have

17:29.820 --> 17:33.980
designed there a research program, we say, oh, we have a nice idea, we

17:33.980 --> 17:37.900
would like to have systems which are actually self-organizing and have

17:37.900 --> 17:42.240
some organic behavior, maybe influenced by things we see in nature,

17:43.000 --> 17:50.940
but it is inevitable that we will be in a situation where we are

17:50.940 --> 17:56.040
surrounded by all kinds of adaptive and self-organizing systems, but

17:56.040 --> 18:00.560
we have to make sure that they are designed in a reasonable way, that

18:00.560 --> 18:07.660
we can actually be satisfied with those systems, and don't get afraid

18:07.660 --> 18:11.940
and try to abolish them, get rid of them, but that we see it's a

18:11.940 --> 18:14.500
benefit to have these kinds of systems around.

18:15.160 --> 18:20.440
And for that, we have to think about appropriate architectures and

18:20.440 --> 18:25.920
approaches to control those systems, control a system which we assume

18:25.920 --> 18:30.500
to be self-organizing, self-controlled, so there's some kind of

18:30.500 --> 18:36.480
contradiction, but we need appropriate interfaces to still transfer

18:36.480 --> 18:41.460
our expectations to those systems.

18:42.140 --> 18:46.240
So questions are how we can actually design them, all kinds of

18:46.240 --> 18:51.540
different design questions that are popping up here, which could be

18:51.540 --> 18:57.960
looked at, so what actually does self-organized mean, adaptivity, do

18:57.960 --> 19:03.900
we just have feed-forward control or feedback control, so there are

19:03.900 --> 19:08.260
some approaches to talk about model-based systems, model-predictive

19:08.260 --> 19:15.800
control is a standard approach to control systems, technical systems,

19:16.140 --> 19:20.640
so you see all kinds of different topics which are mentioned here, and

19:20.640 --> 19:25.360
that's what we worked on in this priority program of the German

19:25.360 --> 19:33.000
Research Foundation, where we, if I say we, it is first of all these

19:33.000 --> 19:37.080
three names, so two more people than myself, Kirsten Müller-Schlörer

19:37.080 --> 19:42.740
and Theo Ungerer, who worked on, we were the core team, and then we

19:42.740 --> 19:50.520
had 18 projects all over Germany, with about 25 colleagues who were

19:50.520 --> 19:56.320
active in there, and we were working on principles of organic

19:56.320 --> 20:06.920
computing, looking at self-organization, self-optimizing, self

20:06.920 --> 20:12.240
-healing, self-protection properties and emergent phenomena from self

20:12.240 --> 20:17.480
-organization, we looked at nature to see what kind of structures and

20:17.480 --> 20:21.960
behaviors and behavioral patterns we can see there, which might be

20:21.960 --> 20:26.540
helpful for designing technical systems, our goal was to establish a

20:26.540 --> 20:33.020
toolbox for organic computing, and we always had in mind applications

20:33.020 --> 20:36.800
where we actually need those self-organization aspects.

20:37.620 --> 20:41.920
So that was our projects, range of projects, I don't want to go into

20:41.920 --> 20:45.000
all these projects, but I would like to tell you something about the

20:45.000 --> 20:49.220
kind of architecture that we designed from that, and what sense that

20:49.220 --> 20:54.140
is generic, and I would like to start by telling you something about,

20:54.300 --> 20:58.580
very briefly, about an alternative architecture, which was designed in

20:58.580 --> 21:01.520
the Autonomic Computing Framework.

21:02.580 --> 21:12.520
Autonomic Computing was mainly initiated by IBM, and they had in mind

21:12.520 --> 21:18.680
that large enterprise server systems should have more and more self

21:18.680 --> 21:23.460
-organizing features, self-x properties, because the manual effort was

21:23.460 --> 21:29.400
too high, and many things could be automated easily, and so they also

21:29.400 --> 21:33.580
thought about how they can actually automate that, and so they have

21:33.580 --> 21:36.720
some kind of productive system, for example, an enterprise server

21:36.720 --> 21:41.540
system, and then you have to monitor that, that's the M, you have to

21:41.540 --> 21:45.380
analyze what's happening, what you're seeing there, you have to plan

21:45.380 --> 21:49.660
how to respond to that, and then execute the planned action

21:49.660 --> 21:55.560
appropriately on the system, and then, in this way, you can control

21:55.560 --> 21:56.120
the system.

21:56.240 --> 22:00.360
The K in the middle here stands for knowledge, which you accumulate

22:00.360 --> 22:07.160
over time based on experience, and so you can improve the behavior of

22:07.160 --> 22:07.680
that system.

22:08.420 --> 22:12.800
So this is called an autonomic element, and the idea is that many of

22:12.800 --> 22:15.000
those can communicate appropriately.

22:16.140 --> 22:22.040
And what we came up with in organic computing was in some way similar.

22:23.260 --> 22:26.800
There are a few different names, but not just names, but also the

22:26.800 --> 22:30.580
concepts were slightly different, so we talked not about a productive

22:30.580 --> 22:34.880
system, but about a system under observation and control, which has to

22:34.880 --> 22:40.200
run just on its own, its functionality does not depend on the

22:40.200 --> 22:43.340
existence of any control element on top of that.

22:44.300 --> 22:49.060
It may be some set of agents which are communicating and interacting

22:49.060 --> 22:53.700
to perform a certain functionality, and then we designed that observer

22:53.700 --> 22:57.460
-controller architecture on top of it, which was meant to actually

22:57.460 --> 23:02.500
improve the performance of these systems and turn them into such an

23:02.500 --> 23:03.340
organic system.

23:03.340 --> 23:09.320
And this can have many different instances, can be designed in very

23:09.320 --> 23:16.000
different ways, but there is this pattern of the observer-controller

23:16.000 --> 23:21.100
which can be looked at as some kind of generic system, and I will show

23:21.100 --> 23:26.260
you what the ingredients of that should be in order to have integrated

23:26.260 --> 23:30.080
or looked at all the different components that are necessary.

23:30.720 --> 23:34.160
It can also be a multi-level organization, maybe that on top of that

23:34.160 --> 23:38.740
you have the next entity, so here I have drawn a user, maybe a human

23:38.740 --> 23:45.200
user, maybe some next layer entity which is providing information

23:45.200 --> 23:50.480
towards those agents, so maybe that in here those agents by itself

23:50.480 --> 23:55.800
again are those instances of a system having an observer and a

23:55.800 --> 23:56.180
controller.

23:57.200 --> 23:58.640
So what do we have in there?

23:58.740 --> 24:02.900
We have the system and observation and control, we have all these

24:02.900 --> 24:11.300
different parts in here, I will in a moment show you that again, but I

24:11.300 --> 24:14.260
wanted to just briefly show you the overview picture.

24:14.960 --> 24:19.880
We have an architecture where we have this observer and we have a

24:19.880 --> 24:20.340
controller.

24:21.380 --> 24:25.120
And in the observer we have several components to monitor, to filter,

24:25.380 --> 24:29.460
to store what we have seen, to analyze, to predict, to aggregate.

24:30.060 --> 24:33.900
That information is sent into the controller where we can map that

24:33.900 --> 24:39.080
onto actions, evaluate, maybe adapt what's happening there, and this

24:39.080 --> 24:41.540
is directed by user goals.

24:42.020 --> 24:48.300
And I would like to briefly show you that again and go into a few of

24:48.300 --> 24:49.900
those things that are necessary there.

24:51.120 --> 24:55.040
So when we monitor, we are just getting some data.

24:55.040 --> 24:57.500
This is something you can design.

24:58.420 --> 25:03.000
At some point in time you can design such a...

25:03.000 --> 25:06.900
you decide which parameters you actually look at.

25:08.940 --> 25:15.400
If you have not designed a certain sensor to look at a certain

25:15.400 --> 25:19.360
parameter, you will never be able to get information on that

25:19.360 --> 25:19.760
parameter.

25:20.380 --> 25:23.500
This is something which has to be done at design time and sometimes

25:23.500 --> 25:31.800
you will just install more sensors or more possibilities to monitor

25:31.800 --> 25:37.040
something on that system and observation and control than what you

25:37.040 --> 25:42.240
actually would need at all times while you are running the system.

25:42.360 --> 25:45.160
So maybe you have more sensors available and you are just looking at

25:45.160 --> 25:46.500
some subset of that.

25:47.360 --> 25:50.220
So you have also a certain model of observation.

25:50.400 --> 25:51.560
I think it should pop up there.

25:51.560 --> 25:53.200
Yes, there's the model of observation.

25:53.800 --> 25:58.520
Maybe you have to select by some model of observation which kind of

25:58.520 --> 26:00.440
parameters you actually want to look at.

26:01.260 --> 26:06.300
It's certainly reasonable to store what you have seen there because

26:06.300 --> 26:13.420
you would like to have some history available of the development of a

26:13.420 --> 26:13.740
system.

26:15.000 --> 26:18.280
And then maybe you have to filter what you have seen.

26:18.280 --> 26:23.640
Maybe you have some time series and all of a sudden you have some very

26:23.640 --> 26:24.640
high value.

26:24.980 --> 26:26.160
Maybe you have a low value.

26:26.260 --> 26:27.320
You have no values.

26:28.200 --> 26:30.380
So maybe you have to repair what you have seen.

26:31.180 --> 26:37.740
You have to delete certain outliers assuming that such an outlier is

26:37.740 --> 26:42.680
not a real value but some kind of erroneous value.

26:43.640 --> 26:46.820
So certain things you might do there and then you would like to

26:46.820 --> 26:48.000
analyze what's happening.

26:48.460 --> 26:49.960
Now what would you like to analyze?

26:50.380 --> 26:54.220
Here on that slide you see that something like emergence detector.

26:54.360 --> 26:54.980
What is emergence?

26:55.960 --> 27:05.220
So what we could see is if we have, for example, an artificial example

27:05.220 --> 27:10.440
we have certain elements which are distributed over like in a two

27:10.440 --> 27:15.340
-dimensional space and the normal situation would be that they are

27:15.340 --> 27:17.240
just distributed quite evenly.

27:18.260 --> 27:23.620
And then maybe all of a sudden you notice oh, they are all arranged in

27:23.620 --> 27:25.480
those lines.

27:26.360 --> 27:28.780
This looks like a different situation.

27:29.940 --> 27:35.300
Maybe you can notice that it's a different situation by looking at the

27:35.300 --> 27:41.340
distribution of the values of, for example, the x and y values so if

27:41.340 --> 27:45.700
you have x and y, look at the x and y coordinates and you will notice

27:45.700 --> 27:51.960
that all of a sudden certain y coordinates appear more often than

27:51.960 --> 27:57.180
others and this can be measured by looking at the entropy.

27:58.140 --> 28:05.780
So, for example, you could look at the entropy with respect to the y

28:05.780 --> 28:19.180
coordinates and that is minus the sum of all frequencies pi log pi and

28:19.180 --> 28:25.640
pi is the frequency of the potential values of y.

28:25.800 --> 28:31.020
So if you have here many different values you look at how often each

28:31.020 --> 28:40.240
value occurs so if these are n different values that you might have

28:40.240 --> 28:45.200
you have a sum i equals one to n you have the frequency, how often

28:45.200 --> 28:49.200
each y coordinate that you have actually looked at is occurring and

28:49.200 --> 28:54.600
then this is the entropy of such a parameter.

28:55.380 --> 29:02.580
You could also look at the x parameter or the x entropy in a similar

29:02.580 --> 29:07.460
way and you can look at whatever parameter you might be interested in

29:07.460 --> 29:12.940
and see how it is distributed in your system that you're looking at.

29:13.400 --> 29:21.300
Now if you notice that this value here is very large then you have a

29:21.300 --> 29:24.880
very uniform distribution of those values.

29:25.460 --> 29:30.300
It may be that this value is going down that it's getting smaller.

29:30.660 --> 29:36.160
If it's getting smaller you have a system which is more or less which

29:36.160 --> 29:37.960
is showing a higher degree of order.

29:38.600 --> 29:42.320
So in this situation here we have a higher degree of order and for

29:42.320 --> 29:47.600
that the h y value would be much less than the h x value.

29:48.540 --> 29:52.200
And so you would notice just by looking at the entropy values that you

29:52.200 --> 29:56.340
have a change in the degree of order of the system and this might be

29:56.340 --> 29:59.760
an indicator of an interesting effect in your system.

30:01.240 --> 30:05.140
And so this is what you can do for example to notice, oh something

30:05.140 --> 30:10.300
happens in my system it's deviating from standard behavior the degree

30:10.300 --> 30:13.280
of order has changed and so I have to do something.

30:14.480 --> 30:20.420
Or you can transfer that easily to energy situations where you have

30:20.420 --> 30:23.900
all kinds, for example, meter readings and you see a standard

30:23.900 --> 30:27.160
situation of different values there and then all of a sudden you have

30:27.160 --> 30:30.780
deviations from that and you would like to notice those deviations.

30:31.540 --> 30:35.400
And as soon as you have noticed such a deviation you have to tell that

30:35.400 --> 30:39.000
in a reasonable way to the controller which has to get the appropriate

30:39.000 --> 30:41.740
actions depending on what you have just observed.

30:42.340 --> 30:47.820
So we have the entropy and actually what we define as the emergence is

30:47.820 --> 30:57.100
the Hmax value minus the current for example, for the Y variable that

30:57.100 --> 31:03.720
would be the emergence of the Y variable which would be Hmax minus Hy

31:03.720 --> 31:08.080
or Hmax, I have to write that in a different way

31:12.860 --> 31:22.600
Hymax minus Hy so the maximum value of that actually is the logarithm

31:22.600 --> 31:26.960
of the number of values that you have here so it would be in that case

31:26.960 --> 31:35.340
log N minus the current entropy value and that is the emergence value

31:35.340 --> 31:37.280
of that situation.

31:37.560 --> 31:42.440
That's how we define that in our projects and notice that in this way

31:42.440 --> 31:48.660
we can find out or detect certain interesting changes in behavior of

31:48.660 --> 31:49.480
such a system.

31:50.040 --> 31:53.600
So this is what we do or one example of what you can do in the

31:53.600 --> 31:59.540
analysis maybe you can just write or compute certain variances or

31:59.540 --> 32:03.520
perform all kinds of standard functions that you would like to get

32:03.520 --> 32:03.740
there.

32:04.920 --> 32:09.500
Another component here is the predictor we would like to be able to

32:09.500 --> 32:15.060
predict what should be happening depending on or with respect to what

32:15.060 --> 32:21.300
we have seen in the past so if you are or if you have observed a

32:21.300 --> 32:26.620
certain system and now you are at this point in time, T and then you

32:26.620 --> 32:33.300
predict how that will perform in the future if you would predict like

32:33.300 --> 32:36.980
depending on what you have just seen you predict a certain behavior

32:36.980 --> 32:43.140
and then you can decide on what you should do whether you should

32:43.140 --> 32:46.360
influence your system to behave differently or whether that is okay

32:46.360 --> 32:51.900
you can also find out whether the next time you visit that is it

32:51.900 --> 32:55.360
actually that behavior that you predicted or is it something different

32:55.360 --> 32:59.140
if it's different, something must have happened or maybe your model is

32:59.140 --> 33:05.860
different is incorrect so prediction is an important point to check

33:05.860 --> 33:09.800
whether your system, your model of the system that you use for

33:09.800 --> 33:15.400
evaluating the current situation actually is still correct so this has

33:15.400 --> 33:20.780
to be or could be integrated into such a generic architecture and then

33:20.780 --> 33:23.800
we have to aggregate what we have seen maybe we just transfer

33:23.800 --> 33:29.820
everything that we have seen maybe we just transfer those entropy

33:29.820 --> 33:35.080
values or whatever you might like to have as results of your analysis

33:35.080 --> 33:41.800
so some derived values might also be included in that aggregated value

33:42.400 --> 33:50.000
and then you go over to that controller and in that controller we, as

33:50.000 --> 33:55.360
I said, we have all we have these different components we have a

33:55.360 --> 33:59.080
mapping and the mapping, what would it do?

33:59.180 --> 34:05.340
you have some kind, as you see here, some kind of table or mapping, as

34:05.340 --> 34:11.580
I said certain situations that are indicated by your observer and then

34:12.600 --> 34:18.780
maybe that you have here some conditions you just check for a certain

34:18.780 --> 34:22.600
property of the current situation maybe that you have different

34:22.600 --> 34:26.660
conditions which fire and then you might have different actions that

34:26.660 --> 34:32.660
would actually be activated which could be selected and it's not

34:32.660 --> 34:38.420
necessarily just one activity that should be performed there or just

34:38.420 --> 34:43.160
one control action maybe there is a choice of different actions and

34:43.160 --> 34:48.600
then you need some kind of decision mechanism to decide which action

34:48.600 --> 34:54.000
should be chosen as a response to the currently observed situation so

34:54.000 --> 34:57.900
you have here this action selector And you will perform a certain

34:57.900 --> 34:59.340
action on your system.

35:00.940 --> 35:06.500
In a traffic scenario, you might increase or decrease speed limits or

35:06.500 --> 35:06.940
whatever.

35:07.200 --> 35:11.960
Like if you have a traffic jam control on a highway, you would just

35:11.960 --> 35:16.340
enforce a traffic speed limit.

35:16.960 --> 35:23.880
In the energy system, you might notice some bottleneck situation and

35:23.880 --> 35:30.020
you might impose some power constraint that you tell the houses in

35:30.020 --> 35:36.000
your distribution system, you should not go over a certain limit in

35:36.000 --> 35:37.140
the power that you use.

35:38.000 --> 35:44.880
Okay, then you have executed that action, you store it into some

35:44.880 --> 35:52.020
history mechanism, where the next time you actually get a situation

35:52.020 --> 35:58.200
description, you look at the impact that this execution of that action

35:58.200 --> 35:58.580
had.

35:59.280 --> 36:02.880
Now to looking at the impact means you look at what actually changed,

36:03.440 --> 36:07.260
you had some intended change, that's why you selected that action.

36:07.740 --> 36:14.220
And then you can notice whether that impact actually was according to

36:14.220 --> 36:15.000
what you expected.

36:15.680 --> 36:21.060
And you can evaluate the appropriateness of the action that you had

36:21.060 --> 36:22.080
selected previously.

36:22.900 --> 36:27.980
If you notice it is perfect, it does exactly what you wanted, you

36:27.980 --> 36:33.320
would give it a high fitness, maybe a real value, maybe some other

36:33.320 --> 36:35.560
value that you just decide to use.

36:36.060 --> 36:38.160
But in any case, you need some evaluation.

36:39.100 --> 36:44.700
If it's performing differently from what we expected, you would give

36:44.700 --> 36:45.400
it a low fitness.

36:46.420 --> 36:50.580
And then this adaptation module here would actually send that

36:50.580 --> 36:55.500
information back into that mapping process, and in some way indicate

36:55.500 --> 37:02.060
that this action that was chosen as a response to that activated

37:02.060 --> 37:04.580
condition was not really adequate.

37:05.420 --> 37:09.100
And the fitness should be reduced or the some kind of expected

37:09.100 --> 37:10.800
performance should be reduced.

37:11.660 --> 37:14.540
Or maybe you should delete a certain action from that.

37:15.440 --> 37:20.260
Or maybe you notice, oh, I really don't have an appropriate action

37:20.260 --> 37:20.700
available.

37:21.220 --> 37:25.720
And if I don't have an appropriate action available in that mapping

37:25.720 --> 37:30.920
mechanism, then I would need a new action.

37:31.460 --> 37:38.820
Now, how do I determine what I have to do if I have no appropriate

37:38.820 --> 37:39.680
action available?

37:41.260 --> 37:46.920
You could certainly just test an arbitrary activity, arbitrary action,

37:47.080 --> 37:51.780
just arbitrarily modify the control parameters that you have for that

37:51.780 --> 37:52.200
system.

37:53.040 --> 37:56.660
That might be feasible in some situations, but not if you have an

37:56.660 --> 37:58.440
energy system or a traffic system.

37:59.240 --> 38:03.960
And so for that, you would need some simulation model, modeling the

38:03.960 --> 38:07.740
environment that you are actually controlling, modeling the system

38:07.740 --> 38:09.560
under observation and control.

38:10.360 --> 38:19.180
And then by some planning process, plan or generate a new action with

38:19.180 --> 38:26.880
respect to the situation that you had observed and where you had only

38:26.880 --> 38:28.580
inappropriate responses.

38:29.580 --> 38:34.740
So generate something, some kind of in an offline simulation model,

38:34.860 --> 38:38.960
look at how it performs with respect to that model of the environment.

38:40.240 --> 38:44.680
And if it's performing well, then you would send that action down

38:44.680 --> 38:47.620
again into that system.

38:47.680 --> 38:51.000
Now I said it should perform well, or maybe some things don't perform

38:51.000 --> 38:51.380
well.

38:51.760 --> 38:55.520
Whether it performs well or not is determined by the goals that you

38:55.520 --> 38:59.720
have, the objectives that you have in your system, how you decide this

38:59.720 --> 39:00.940
is good, this is bad.

39:01.260 --> 39:06.080
And these objectives are given by some external entity, which may be a

39:06.080 --> 39:11.840
human user, maybe just some next level entity which is providing that.

39:12.200 --> 39:14.760
So it can be a hierarchical system.

39:15.280 --> 39:19.540
And it's important that this human user has an interface to actually

39:19.540 --> 39:22.120
tell the system what its objectives are.

39:23.400 --> 39:27.220
And that it can, that maybe can also interfere directly.

39:28.040 --> 39:31.700
So these are more or less the components that we have in that generic

39:31.700 --> 39:32.300
architecture.

39:33.680 --> 39:37.140
And it does not mean that in every organic system, you need all these

39:37.140 --> 39:37.640
components.

39:38.580 --> 39:41.760
If you look at that, you could say it's more or less the same as the

39:41.760 --> 39:42.000
MAPE.

39:42.880 --> 39:46.740
But I talked much longer about this architecture than I talked about

39:46.740 --> 39:50.220
the MAPE architecture, not because it's the one we have designed, but

39:50.220 --> 39:54.820
it's just addresses a larger variety of topics.

39:54.820 --> 40:01.940
And it in particular addresses the topics of learning, what the impact

40:01.940 --> 40:06.660
of a certain situation or a certain action is, and being able to

40:06.660 --> 40:13.360
actually generate something independent of the current system based on

40:13.360 --> 40:14.220
a simulation model.

40:15.060 --> 40:20.520
So this is an important point to have learning, how the performance of

40:20.520 --> 40:23.180
the system actually is and modifying what you're doing.

40:23.360 --> 40:30.040
So learning always means you would like to improve your situation.

40:30.720 --> 40:34.440
So we talked about learning, just to write it down here.

40:34.800 --> 40:38.760
We talked about improving your performance the next time you see a

40:38.760 --> 40:39.540
certain situation.

40:40.900 --> 40:45.620
And you can do that either by modifying the mapping here, because

40:45.620 --> 40:49.980
you've seen a certain activity is not appropriate, or by getting new

40:49.980 --> 40:51.880
actions from that generation mechanism.

40:53.200 --> 40:58.040
Okay, now, this was the observer-controller architecture.

40:58.260 --> 41:00.920
And we can look at that in a slightly different way.

41:01.580 --> 41:06.860
We have some kind of basic system, the system of observation and

41:06.860 --> 41:11.180
control, for example, a traffic controller or an energy management

41:11.180 --> 41:13.580
system being controlled by certain parameters.

41:14.800 --> 41:15.600
And this is running.

41:16.380 --> 41:22.880
And then we have the possibility to modify the control system by

41:22.880 --> 41:25.220
performing a certain change of parameters.

41:25.500 --> 41:26.400
That's the action.

41:27.100 --> 41:30.540
We perform with respect to a certain rule set.

41:31.220 --> 41:34.580
This is the observer of the first level here.

41:34.660 --> 41:37.460
This is the online action selection.

41:38.020 --> 41:41.120
And we get feedback, look at what's happening.

41:41.360 --> 41:44.020
We can modify the selection of those rules.

41:45.120 --> 41:51.360
And then we have also this next layer, where we have to generate new

41:51.360 --> 41:58.740
actions if we are not satisfied with the available action from that

41:58.740 --> 41:59.300
rule set.

41:59.760 --> 42:03.260
And for that, we have some mechanism, for example, in the evolutionary

42:03.260 --> 42:10.280
algorithm to generate new settings of parameters, setting of control

42:10.280 --> 42:13.280
parameters, or whatever you would have to do down there in that

42:13.280 --> 42:13.620
system.

42:14.420 --> 42:21.000
So in this way, we can have a two-level learning mechanism, online

42:21.000 --> 42:24.140
learning loop, by waiting for responses from the system.

42:25.600 --> 42:28.860
That's here, this loop down there.

42:29.400 --> 42:35.520
And then we have the offline learning system being done over here,

42:35.880 --> 42:40.120
where we just generate new activities based on the simulation model,

42:40.280 --> 42:45.180
evaluating the appropriateness of those generated actions with respect

42:45.180 --> 42:48.120
to the simulation model, which hopefully is adequate.

42:48.980 --> 42:55.280
And then those actions which are performing the best after a certain

42:55.280 --> 42:59.940
time, we are satisfied with the quality, we move them down into the

42:59.940 --> 43:04.860
rule set and then can use them more or less in real time, or in soft

43:04.860 --> 43:05.420
real time.

43:05.520 --> 43:09.880
Because this year, the offline loop or the online loop is very fast,

43:10.020 --> 43:11.960
the offline loop takes some time.

43:12.760 --> 43:15.320
So this is a slightly different view of that architecture.

43:15.840 --> 43:17.320
It's a three-layered architecture.

43:18.000 --> 43:22.520
And if you look at similar parameters or similar architectures for

43:22.520 --> 43:30.580
other scenarios, for example, there is an architecture called sense

43:30.580 --> 43:42.640
-learn -act, or there is the viable systems architecture, or there are

43:42.640 --> 43:47.620
other architectures for self-organizing systems.

43:48.520 --> 43:50.680
They usually have these three layers.

43:51.780 --> 43:56.400
And there's also an operator, not an observer controller, but an

43:56.400 --> 44:02.860
operator control mechanism.

44:08.070 --> 44:09.350
No, not mechanism, module.

44:10.490 --> 44:12.130
Operator control module.

44:14.130 --> 44:16.530
And we have the main architecture.

44:16.750 --> 44:20.070
Essentially, they are very similar.

44:20.710 --> 44:25.190
But here, like we have this specific way of looking at that.

44:25.530 --> 44:32.310
And we have transformed that into these architectures for managing

44:32.310 --> 44:33.350
energy systems.

44:33.930 --> 44:40.930
Just because energy systems are actually very much looking like those

44:42.050 --> 44:44.510
components where we have all these systems, where we have many

44:44.510 --> 44:47.030
components interacting with each other.

44:48.130 --> 44:54.710
And we have to sometimes do or influence them in order to provide the

44:54.710 --> 44:58.790
desired functionality, which means the appropriate balancing between

44:58.790 --> 45:00.710
demand and supply.

45:02.010 --> 45:02.270
Okay.

45:02.970 --> 45:07.390
As I said, when I started to tell you something about this observer

45:07.390 --> 45:10.530
controller architecture, they can be designed in many different ways.

45:11.370 --> 45:13.830
They could be designed in a centralized way.

45:13.970 --> 45:18.410
You have just one system and observation and control, larger one with

45:18.410 --> 45:19.170
many components.

45:19.350 --> 45:22.610
You have one observer, one controller, and that's it.

45:23.130 --> 45:27.370
A centralized system, looking at that, that's not really self

45:27.370 --> 45:28.010
-organizing.

45:28.190 --> 45:33.850
It is maybe adaptive due to that mechanism, but it is a very top-down

45:33.850 --> 45:34.430
approach.

45:34.710 --> 45:38.630
It's not really what we call a self-organizing system.

45:39.690 --> 45:43.050
There could be a very distributed system, distributed architecture,

45:43.790 --> 45:49.550
where we have many of those devices all having an observer controller,

45:50.110 --> 45:56.250
which would actually communicate in some way with each other.

45:57.410 --> 46:04.610
And then, as a result of their interaction, they might develop some

46:04.610 --> 46:07.190
kind of emergent control mechanism.

46:08.110 --> 46:12.290
This is something which is the result of the bottom-up communication

46:12.290 --> 46:15.910
and interaction between all those components, and that's what we

46:15.910 --> 46:18.910
normally call typical self-organizing systems.

46:18.990 --> 46:23.250
No central authority, just these intelligent agents communicating.

46:24.190 --> 46:28.610
What we have in organic computing is rather such a multi-level system

46:28.610 --> 46:36.050
where we have definitely many intelligent individual systems, but then

46:36.050 --> 46:41.910
another layer where we actually observe what's happening there and

46:41.910 --> 46:43.450
influence it whenever necessary.

46:44.170 --> 46:48.990
And this may be that this is not just one of those next-layer systems,

46:49.110 --> 46:50.970
but there may be several of them.

46:51.030 --> 46:55.790
So we might have some hierarchical system, and that's what we call a

46:55.790 --> 46:57.850
controlled self-organizing system.

46:58.370 --> 47:03.030
There are certain self-organizing features already in there, and then

47:03.030 --> 47:07.570
we have the observer controller on top of that.

47:07.670 --> 47:11.510
So we have a combination of the bottom-up architecture, as shown here

47:11.510 --> 47:14.810
in the middle, and the top-down architecture, as shown on the left,

47:15.390 --> 47:20.270
which is combined into such a controlled self-organizing system, which

47:20.270 --> 47:26.090
sounds like a contradiction, but it just shows that it has the ability

47:26.090 --> 47:35.170
to be controlled by some external entity, which tells what to do, but

47:35.170 --> 47:39.970
it will only influence what's happening here, if necessary, if some

47:39.970 --> 47:41.730
undesired behavior is detected.

47:42.530 --> 47:48.030
And so this is something which can, on demand, control a system, but

47:48.030 --> 47:50.230
normally it will be self-organizing.

47:50.530 --> 47:54.470
So that was very brief, the philosophy of organic computing

47:54.470 --> 47:59.190
methodologies that we designed in that program, and we have used that

47:59.190 --> 48:02.430
in many different application scenarios.

48:03.150 --> 48:06.810
So I mentioned several times already traffic control.

48:07.390 --> 48:11.270
We actually have designed there such an architecture where we start,

48:11.270 --> 48:15.750
like we had here, this system of operational control, and then this

48:15.750 --> 48:19.290
rule set in there, in this example.

48:19.910 --> 48:27.050
That rule set actually was completely empty when we start such a

48:27.050 --> 48:27.910
traffic controller.

48:28.490 --> 48:31.990
We just look at the traffic flows, we give it the objective to reduce

48:31.990 --> 48:35.470
waiting times, reduce number of stops, or reduce energy consumption.

48:35.930 --> 48:39.750
You certainly need appropriate models of such an intersection.

48:40.250 --> 48:47.170
So if you have a certain intersection, and you would like to determine

48:47.170 --> 48:51.250
what's the best possible flow in the different directions here, maybe

48:51.250 --> 48:53.790
some flow wanting to go that way.

48:55.050 --> 48:58.970
So different traffic flows, you look at the current strength of those

48:58.970 --> 49:05.710
traffic flows, and then the system has to determine on these traffic

49:05.710 --> 49:10.830
lights, has to decide on the length of the green phases, allowing

49:10.830 --> 49:12.690
traffic flow to actually proceed.

49:13.870 --> 49:16.730
How long, how do I determine those green phases?

49:17.930 --> 49:22.710
And this is done by that system, and it's actually generated by an

49:22.710 --> 49:23.790
evolutionary algorithm.

49:24.710 --> 49:29.210
And so very fast, with this system, we were actually capable to

49:29.210 --> 49:32.630
outperform a system that was designed by traffic engineers.

49:33.010 --> 49:35.450
We did that in several different example situations.

49:36.350 --> 49:42.090
So this system is able to actually self-optimize and get some good

49:42.090 --> 49:42.650
behavior.

49:43.830 --> 49:48.590
It could also, if you have the next intersection here, coordinate with

49:48.590 --> 49:52.490
the neighboring intersection to have some green wave, so that self

49:52.490 --> 49:53.550
-organizing feature.

49:54.350 --> 49:59.330
And some regional controller would look at that, would say, okay,

49:59.470 --> 50:05.390
maybe certain certain coordination between neighboring sections would

50:05.390 --> 50:10.550
be desirable or not desirable, or we change certain objectives.

50:11.270 --> 50:15.210
This regional controller could also be integrated adequately in there.

50:15.530 --> 50:21.850
So we really had this organic system, which was by itself generating

50:21.850 --> 50:24.850
an intelligent behavior or an adaptive behavior.

50:26.390 --> 50:31.310
And so that's where we actually developed this observer-controller

50:31.310 --> 50:31.930
architecture.

50:32.490 --> 50:36.590
We had other projects like production systems, industrial production

50:36.590 --> 50:42.770
systems, where the idea was to be able to tolerate breakdowns of

50:42.770 --> 50:48.190
certain tools and then get around certain broken tools and try to

50:48.190 --> 50:54.810
still produce adequate products by reconfiguration of the system.

50:55.570 --> 50:59.070
We looked at smart camera systems, where you have a certain

50:59.070 --> 51:01.110
environment that you would like to supervise.

51:01.190 --> 51:05.790
You have cameras, which would always all have some angle which they

51:05.790 --> 51:06.510
can view.

51:06.930 --> 51:11.710
And then you would like to have some information on what's happening

51:11.710 --> 51:19.070
on your system by combining the information from the different cameras

51:19.070 --> 51:23.570
and respond to something you have seen on one camera.

51:23.950 --> 51:28.650
Maybe follow if somebody is walking through here, you can follow that

51:28.650 --> 51:29.850
person appropriately.

51:30.070 --> 51:32.790
You would like to detect whether he's doing something which is bad or

51:32.790 --> 51:33.010
not.

51:33.930 --> 51:38.830
So smart camera systems are important for supervisory applications.

51:40.530 --> 51:43.610
We looked at network control applications, system-on-chip

51:43.610 --> 51:49.350
applications, and what we did in particular in my group is, like in

51:49.350 --> 51:51.350
recent years, energy management and control.

51:52.150 --> 51:53.890
And now we come back to the energy topic.

51:55.230 --> 52:00.010
And I just wanted to give you some idea of what's the background of

52:00.010 --> 52:00.950
those architectures.

52:01.630 --> 52:02.290
Any questions?

52:04.030 --> 52:04.250
No?

52:05.070 --> 52:05.330
Okay.

52:06.510 --> 52:08.270
So now we are back to the energy system.

52:08.390 --> 52:08.890
Yes, the question.

52:08.890 --> 52:12.170
The traffic control picture you drew before, do you mean that it's

52:12.170 --> 52:16.230
controlling traffic in real time or it learns how it flows and adapts

52:16.230 --> 52:19.270
itself or in real time it changes the light?

52:19.270 --> 52:23.510
Well, yes.

52:26.190 --> 52:28.270
So what does it do?

52:28.370 --> 52:32.570
I said it would control the length of the green phase.

52:33.270 --> 52:38.290
Now there are certain traffic light controllers which would respond to

52:38.290 --> 52:42.390
the number of cars that are standing in line here in front of the

52:42.390 --> 52:49.050
traffic light and would just, if it's a long line of cars, then it

52:49.050 --> 52:52.050
would automatically extend the green phase.

52:52.830 --> 52:53.990
We did not do that.

52:54.650 --> 53:00.170
So that would be adaptive or traffic responsive traffic light control.

53:01.780 --> 53:09.130
What we did is we just had fixed times for the green phase, but we

53:09.130 --> 53:14.990
would notice what the traffic flow is and adjust those green times for

53:14.990 --> 53:22.910
the next round of, for the next iteration of the different phases, we

53:22.910 --> 53:24.250
would adjust the green phase.

53:25.210 --> 53:31.030
Select a different parameter setting appropriate to that situation

53:31.030 --> 53:31.770
that we had observed.

53:32.690 --> 53:40.490
So it is not exactly adaptive change of the green phase while the

53:40.490 --> 53:44.630
green phase is still on, but it would modify it the next time we get

53:44.630 --> 53:45.390
to that situation.

53:46.390 --> 53:49.430
So it would notice, oh, what I've done here is not really appropriate.

53:49.930 --> 53:51.090
I have to change that.

53:51.210 --> 53:52.410
I get to my rule set.

53:52.530 --> 53:53.890
The situation is like this.

53:54.570 --> 53:56.590
And then you get a new parameter setting.

53:57.490 --> 53:59.950
And this can be done very often.

54:00.610 --> 54:04.190
And so we have almost the same effect as an adaptive traffic light

54:04.190 --> 54:10.150
controller, but even better than that, although also these adaptive

54:10.150 --> 54:14.910
traffic light controllers, which are traffic responsive, have fixed

54:14.910 --> 54:15.510
parameters.

54:15.870 --> 54:20.350
So the degree to which they can actually modify the green phases are

54:20.350 --> 54:21.370
more or less fixed.

54:21.890 --> 54:29.130
There's a certain range of values, but it's just a limited range of

54:29.130 --> 54:29.650
flexibility.

54:29.650 --> 54:34.730
Whereas here in our system, we can arbitrarily modify that if it's

54:34.730 --> 54:35.190
appropriate.

54:37.290 --> 54:39.330
And as I said, it was actually

54:43.690 --> 54:48.770
outperforming systems engineered by or designed by traffic engineers,

54:48.870 --> 54:49.690
so it's not that bad.

54:51.490 --> 54:55.090
Initially, it was not really our goal, our ambitious goal to say,

54:55.250 --> 54:57.410
okay, we would like to outperform traffic engineers.

54:57.730 --> 55:01.250
We just said we would like to see whether we can actually generate

55:01.250 --> 55:04.550
something which is more or less reasonable in such a situation.

55:04.770 --> 55:07.890
And we actually noticed that we can do quite well there.

55:08.530 --> 55:12.950
And in particular, we can also design those traffic adaptive green

55:12.950 --> 55:17.730
phases, progressive signal systems, which normally are fixed.

55:17.930 --> 55:23.210
You have a certain street, a sequence of intersections, which are

55:23.210 --> 55:27.110
having this progressive signal system synchronized green phases.

55:28.370 --> 55:31.750
Sometimes this is done because we want to regulate the traffic in some

55:31.750 --> 55:32.050
way.

55:32.410 --> 55:35.190
But usually you should have a green phase where you have the maximum

55:35.190 --> 55:38.770
traffic flow, because it should be beneficial for the most number of

55:38.770 --> 55:39.190
cars.

55:39.570 --> 55:42.970
And this can be detected by the intersections and then they can

55:42.970 --> 55:50.710
reorganize and provide the best sequence or the best green phase or

55:50.710 --> 55:57.250
the best green wave to those intersection sequence, which is the most

55:57.250 --> 55:59.430
appropriate for the most number of cars.

56:00.730 --> 56:02.450
So this is what we did there.

56:02.950 --> 56:04.530
But now back to the energy system.

56:05.090 --> 56:10.410
So in there, as I showed you just before, before I started telling you

56:10.410 --> 56:14.890
something about organic computing, we have this architecture where we

56:14.890 --> 56:19.790
have drivers for the individual components, for vehicles, for washing

56:19.790 --> 56:21.910
machines, or whatever you have in a house.

56:22.650 --> 56:25.090
And you have those local observers and controllers.

56:25.830 --> 56:30.490
And you have a controller, a global controller inside the house.

56:32.890 --> 56:35.910
And so this is all implemented in Java.

56:36.130 --> 56:39.850
It's actually available under a GNU license.

56:40.250 --> 56:43.670
So it's open source, can be freely used.

56:44.790 --> 56:47.370
And then there are other approaches to that.

56:47.590 --> 56:49.370
For example, there is the EEbus.

56:49.970 --> 56:57.070
EEbus is EE for e-energy, some architecture which is an alternative to

56:57.070 --> 57:01.390
our hardware protection layer, which would look at all kinds of

57:01.390 --> 57:04.030
different communication protocols.

57:04.650 --> 57:10.510
The problem is that those devices that we have here, different devices

57:10.510 --> 57:14.210
in a household, would speak different languages.

57:15.990 --> 57:24.810
And so some speak KNX, some use ZigBee for communication, some use

57:24.810 --> 57:28.690
just standard web service standards.

57:29.410 --> 57:32.750
Then there is universal plug and play systems.

57:32.750 --> 57:36.090
So different types of communication protocols.

57:37.350 --> 57:40.850
And the system that you provide for energy management should be able

57:40.850 --> 57:42.570
to communicate with all those devices.

57:43.350 --> 57:47.750
And the EEbus is one approach to unifying all those different

57:47.750 --> 57:54.190
protocols by having some kind of standard format for all those data

57:54.190 --> 57:55.330
packets that are sent.

57:56.270 --> 58:02.250
So essentially, the EEbus is providing an XML interface, an XML

58:02.250 --> 58:09.170
standard for the information that is sent to the different services or

58:09.170 --> 58:14.230
applications that are trying to manage the energy system.

58:15.290 --> 58:18.830
Now, who of you does not know what XML is about?

58:20.790 --> 58:21.690
Several of you.

58:22.010 --> 58:22.190
Okay.

58:22.810 --> 58:24.010
So what is XML about?

58:25.010 --> 58:28.050
Now, I did not provide that as an extra slide.

58:28.210 --> 58:29.170
Next time I should do that.

58:29.590 --> 58:31.490
So I have to draw it on this slide here.

58:32.130 --> 58:33.430
It's not that difficult.

58:33.770 --> 58:47.310
XML is the Extendable Markup Language.

58:53.400 --> 59:05.200
The Extendable Markup Language, XML, is a way of providing a structure

59:05.200 --> 59:08.400
to a document by providing markups.

59:09.620 --> 59:13.440
So, for example, I could say this here is a heading.

59:18.270 --> 59:20.630
That's a heading, Architecture of Management System.

59:21.310 --> 59:24.750
And after that, I could say, okay, that was the heading.

59:25.990 --> 59:27.290
That's the end of the heading.

59:29.490 --> 59:36.710
And so I would have, like in a document, if I have a document here, I

59:36.710 --> 59:41.030
could say, okay, here in the beginning I write heading or whatever,

59:41.310 --> 59:45.350
and then I have a certain sequence of text, and that's the end of the

59:45.350 --> 59:45.610
heading.

59:46.370 --> 59:48.930
And I notice that, okay, this is a heading.

59:49.810 --> 59:51.710
And then I might have certain other elements.

59:51.850 --> 59:56.770
So I might have a certain, maybe I have a paragraph.

01:00:00.960 --> 01:00:04.180
Then I have certain text, and I have the end of the paragraph.

01:00:06.600 --> 01:00:09.480
And maybe I have some address.

01:00:12.180 --> 01:00:18.720
And inside that address, I may have some name, and this name maybe is

01:00:18.720 --> 01:00:23.980
KIT, and that's the end of the name.

01:00:25.940 --> 01:00:33.740
And maybe I have some, let me just say location, or whatever you like

01:00:33.740 --> 01:00:36.280
to have here, let's say a password.

01:00:38.420 --> 01:00:40.960
And that's the end of location.

01:00:42.340 --> 01:00:42.520
Oops.

01:00:42.860 --> 01:00:45.940
And then you would have the end of the address.

01:00:48.700 --> 01:00:49.760
And so on.

01:00:50.320 --> 01:00:51.460
So what does this provide?

01:00:51.740 --> 01:00:56.640
This provides structural information on the content, on some content

01:00:56.640 --> 01:00:58.720
you would like to present somewhere.

01:00:59.280 --> 01:01:02.160
You want to communicate certain information to somebody else.

01:01:03.600 --> 01:01:07.740
And here I just wrote, okay, there's a certain paragraph, although

01:01:07.740 --> 01:01:12.320
that's a different type of markup that I use here, different type of

01:01:12.320 --> 01:01:17.220
tag, because paragraph is more some structural thing without reference

01:01:17.220 --> 01:01:17.760
to the content.

01:01:18.700 --> 01:01:23.680
Here I said an address contains a name and a location, and the name is

01:01:23.680 --> 01:01:24.920
just a sequence of text.

01:01:25.200 --> 01:01:26.940
Here also just a sequence of text.

01:01:27.600 --> 01:01:31.420
Now I can have more sophisticated types of tags like that.

01:01:32.280 --> 01:01:36.260
And essentially I get something which is a tree structured document.

01:01:37.640 --> 01:01:40.720
So I always have a start and an end of that.

01:01:41.120 --> 01:01:43.600
I have nested, this was a nested structure.

01:01:44.520 --> 01:01:47.600
This is some kind of a tree structure.

01:01:47.800 --> 01:01:49.380
And so I have a structured document.

01:01:51.080 --> 01:01:58.100
And I can define a certain scheme, how I would like to structure a

01:01:58.100 --> 01:01:58.520
document.

01:01:59.020 --> 01:02:05.160
If, for example, I provide information on, let's say, what the washing

01:02:05.160 --> 01:02:06.860
machine would like to do.

01:02:07.720 --> 01:02:13.100
I would like to send information on what the washing machine just or

01:02:13.100 --> 01:02:15.540
is just doing the current state of the washing machine.

01:02:15.920 --> 01:02:20.180
I just send that information somewhere upwards.

01:02:20.860 --> 01:02:23.980
Now I can structure that into a specific parameter, some kind of

01:02:23.980 --> 01:02:25.660
schema, some kind of template.

01:02:27.100 --> 01:02:28.020
So this is XML.

01:02:28.820 --> 01:02:34.680
And now XML has another feature which is called XSLT.

01:02:35.640 --> 01:02:51.840
That's the XSL, the style language, the XML style language translator.

01:02:53.780 --> 01:02:58.860
And this is important because this here, this XSLT, provides us with

01:02:58.860 --> 01:03:03.240
the possibility to present the information in some way.

01:03:04.340 --> 01:03:13.600
So you know, for example, HTML, a language similar to XML, actually a

01:03:13.600 --> 01:03:19.060
special case of XML, where you know if you have a certain markup of

01:03:19.060 --> 01:03:25.680
that, of a document conforming to the HTML standard, the browser

01:03:25.680 --> 01:03:27.680
immediately knows how to present that.

01:03:29.200 --> 01:03:33.140
And the way you present that is defined by some kind of style sheet.

01:03:34.260 --> 01:03:41.440
And this style sheet actually is similar to this XSLT, a way of

01:03:41.440 --> 01:03:46.880
transforming a structured document into some other form, maybe in a

01:03:46.880 --> 01:03:51.560
way that you can actually present it on the screen or on a slide.

01:03:51.560 --> 01:03:55.920
So the contents of that slide here could be defined in an XML document

01:03:55.920 --> 01:03:59.960
in combination with some kind of style sheet definition.

01:04:00.720 --> 01:04:05.200
And then you have the arrangement of elements on such a slide.

01:04:07.120 --> 01:04:08.880
Okay, so what is this about?

01:04:09.000 --> 01:04:12.520
You can define the format of a certain document.

01:04:13.300 --> 01:04:20.840
This is actually called an... oops, where do I have some... that's an

01:04:20.840 --> 01:04:28.480
XML schema, or a document type definition.

01:04:28.760 --> 01:04:34.160
But XML schema is the most more flexible way of doing that.

01:04:34.600 --> 01:04:38.320
And this XML schema is something similar to some kind of grammar

01:04:38.320 --> 01:04:41.200
describing a certain class of documents.

01:04:41.560 --> 01:04:46.000
So you will have an XML schema for energy data, you will have an XML

01:04:46.000 --> 01:04:52.900
schema for traffic data, you will have something for whatever you

01:04:52.900 --> 01:04:58.060
like, for books, for all kinds of different applications.

01:04:59.180 --> 01:05:03.820
And if you have defined that schema, you get some document and it

01:05:03.820 --> 01:05:07.640
tells, okay, this is designed to a certain schema, you can access the

01:05:07.640 --> 01:05:11.240
schema, you can check whether the document has the appropriate

01:05:11.240 --> 01:05:17.240
content, and you can automatically transform that information into

01:05:17.240 --> 01:05:21.000
some other form that is needed, for example, by that application.

01:05:21.520 --> 01:05:27.200
So if that application knows that schema that is the basis for that

01:05:27.200 --> 01:05:32.680
XML document there, then you can systematically process the

01:05:32.680 --> 01:05:34.780
information from that record.

01:05:36.020 --> 01:05:39.600
And so that's more or less what the E-Bus is about.

01:05:40.060 --> 01:05:46.460
You have an XML format for describing the content that is provided

01:05:46.460 --> 01:05:48.500
from different communication protocols.

01:05:49.300 --> 01:05:55.080
They all are transformed into a standard schema, into a standard way

01:05:55.080 --> 01:05:56.500
of structuring a document.

01:05:57.140 --> 01:06:01.660
Then you can process that by applications in a systematic way.

01:06:02.760 --> 01:06:07.740
That's what XML is about, structuring a document such that you can

01:06:07.740 --> 01:06:11.860
understand what's in there and that you can process it in a reasonable

01:06:11.860 --> 01:06:16.880
way using, for example, XSLT transformation definitions.

01:06:18.460 --> 01:06:25.840
Okay, to show you XML in a sufficient depth, I would need several

01:06:25.840 --> 01:06:31.100
lectures, three to four, four, five hours, something like that.

01:06:31.660 --> 01:06:34.540
This was just a very brief indication of what that's about.

01:06:36.480 --> 01:06:41.400
And it just shows that in order to be able to understand what's going

01:06:41.400 --> 01:06:47.480
on in, like if we talk about big data for energy systems, smart data

01:06:47.480 --> 01:06:51.560
for energy systems, you have to know about those ways of describing

01:06:51.560 --> 01:06:55.640
the data in flexible ways depending on the needs you have in those

01:06:55.640 --> 01:06:56.160
situations.

01:06:57.160 --> 01:07:02.940
And so for modern energy systems, engineering those systems, you

01:07:02.940 --> 01:07:05.360
should know something about these technologies also.

01:07:06.400 --> 01:07:08.960
Okay, very brief introduction to XML.

01:07:09.280 --> 01:07:09.380
Yes?

01:07:09.540 --> 01:07:12.720
How can I transfer those scripts into the application?

01:07:13.620 --> 01:07:15.060
So is there some sort of medium?

01:07:15.400 --> 01:07:18.480
The application, okay, the medium is just data transfer.

01:07:18.820 --> 01:07:24.700
You get a sequence of ASCII numbers, so ASCII is just the codings of

01:07:24.700 --> 01:07:26.120
different symbols.

01:07:26.600 --> 01:07:28.700
And then you have to interpret that appropriately.

01:07:29.260 --> 01:07:34.580
And if you know the schema you have, like for the EWA, for example,

01:07:34.840 --> 01:07:36.720
then you can process that appropriately.

01:07:36.860 --> 01:07:40.660
You just write your Java program here, and you know the packets that I

01:07:40.660 --> 01:07:43.120
get are built according to that schema.

01:07:43.360 --> 01:07:48.920
And then I can extract the information from that document and do

01:07:48.920 --> 01:07:52.520
whatever is intended to be the functionality of that application.

01:07:53.400 --> 01:08:05.780
Okay, so that is the EWAS stack, something defined independently of

01:08:05.780 --> 01:08:10.100
what we did, and we combine that into an architecture where we have

01:08:10.100 --> 01:08:17.520
the EWAS in between our components and our architecture here for the

01:08:17.520 --> 01:08:21.760
organic smart home, the OC architecture.

01:08:22.680 --> 01:08:30.040
Okay, now we use that component of that energy management system, this

01:08:30.040 --> 01:08:35.920
observer controller architecture, to optimize what's happening in the

01:08:35.920 --> 01:08:36.180
house.

01:08:36.680 --> 01:08:41.000
Now, what are the objectives for optimizing what's happening in the

01:08:41.000 --> 01:08:41.360
house?

01:08:42.180 --> 01:08:45.420
The objectives are or can be manifold.

01:08:46.980 --> 01:08:52.260
A potential objective can be to increase the degree of self

01:08:52.260 --> 01:08:56.120
-consumption or the degree of self-supply.

01:08:57.140 --> 01:09:00.400
What is self-consumption, self-supply, what does that mean?

01:09:01.140 --> 01:09:08.060
You have local generation of power from your PV cells or combined heat

01:09:08.060 --> 01:09:09.560
and power plant or whatever you have.

01:09:10.560 --> 01:09:14.100
And you have a certain local consumption.

01:09:15.120 --> 01:09:23.620
Now, if your total local consumption, which is all that, is larger or

01:09:23.620 --> 01:09:29.360
at least as large as what you have generated locally, you can 100%

01:09:30.240 --> 01:09:34.660
utilize, self-consume the power you have generated.

01:09:35.800 --> 01:09:44.760
If your consumption is less than what you have generated locally, you

01:09:44.760 --> 01:09:50.860
have a smaller degree of self-consumption, but you have a 100% self

01:09:50.860 --> 01:09:51.400
-supply.

01:09:52.020 --> 01:09:57.200
In this situation where you have larger consumption locally, you need

01:09:57.200 --> 01:09:59.060
a certain amount of power from the grid.

01:09:59.900 --> 01:10:05.200
So you have a lower degree of self-supply, just here, 80% self-supply.

01:10:06.000 --> 01:10:10.340
Here you have 100% self-supply, but only 80% self-consumption.

01:10:11.940 --> 01:10:16.340
You know, or you may have noticed that just recently, our government

01:10:16.340 --> 01:10:23.240
has said that if you actually self-consume power from photovoltaic

01:10:23.240 --> 01:10:28.740
panels, locally generated power, you have to pay half the EE fee

01:10:28.740 --> 01:10:38.280
extra, the EEG fee, which is some way of getting all the costs of the

01:10:38.280 --> 01:10:40.320
grid paid by everybody.

01:10:40.940 --> 01:10:47.000
But it is similar to, maybe I mentioned that before, if you would grow

01:10:47.000 --> 01:10:50.760
your own cabbage in your garden, and to eat that cabbage, you would

01:10:50.760 --> 01:10:54.520
have to pay something for that, because the farmer on the market can

01:10:54.520 --> 01:10:55.840
no longer sell you his cabbage.

01:10:57.540 --> 01:11:03.600
Yeah, it is somehow weird that you have to pay for something you've

01:11:03.600 --> 01:11:08.560
generated on your own premises, just by using the sunlight, it's more

01:11:08.560 --> 01:11:09.700
or less taxing the sun.

01:11:11.340 --> 01:11:12.600
Very strange.

01:11:13.660 --> 01:11:20.700
So this is definitely not appropriate for an incentive to generate

01:11:20.700 --> 01:11:24.260
more power locally, what we actually should do.

01:11:25.460 --> 01:11:31.220
Yeah, but self-consumption currently is something which is not in the

01:11:31.220 --> 01:11:37.500
interest of the energy companies, utility companies, and the grid

01:11:37.500 --> 01:11:38.060
operators.

01:11:38.720 --> 01:11:45.420
They have to get some some money for operating the grid.

01:11:46.300 --> 01:11:52.740
So it has to come from somewhere, if everybody would self supply with

01:11:52.740 --> 01:11:58.100
power, nobody would need the grid, and then who would pay for the

01:11:58.100 --> 01:11:58.360
grid.

01:11:58.580 --> 01:12:05.340
And so this is a way of actually letting those pay, who are just self

01:12:05.340 --> 01:12:07.060
-supplying themselves.

01:12:09.340 --> 01:12:14.260
But the more appropriate way would be to say that I need some kind of

01:12:14.260 --> 01:12:19.840
insurance for covering the risk of not having sufficient amount of

01:12:19.840 --> 01:12:20.620
power locally.

01:12:21.040 --> 01:12:28.760
And then I would need some extra back off or some backup power, and I

01:12:28.760 --> 01:12:30.280
have to pay insurance fee for that.

01:12:30.460 --> 01:12:31.780
But that's different.

01:12:32.480 --> 01:12:36.700
It may come up to the same thing, because if you have a large demand

01:12:36.700 --> 01:12:41.300
locally, and would need a large amount of power, you would have to pay

01:12:41.300 --> 01:12:48.120
more as insurance rate than if you have less self-consumption or local

01:12:48.120 --> 01:12:48.580
consumption.

01:12:48.880 --> 01:12:50.460
Okay, but this is a different topic.

01:12:50.940 --> 01:12:56.040
The topic that I wanted to address is, we would like to optimize, we

01:12:56.040 --> 01:12:59.380
could optimize for self-consumption and self-supply.

01:13:00.760 --> 01:13:07.100
You could also optimize for, for example, doing the best possible

01:13:07.100 --> 01:13:09.180
thing to stabilize the grid.

01:13:09.980 --> 01:13:11.840
Those would be external objectives.

01:13:12.540 --> 01:13:14.640
These are complete internal objectives.

01:13:15.400 --> 01:13:18.180
But if you just look at that, what can we do?

01:13:19.660 --> 01:13:22.600
We simulated that, or we ran examples.

01:13:22.600 --> 01:13:26.120
We ran examples in our energy smart home lab on campus.

01:13:27.340 --> 01:13:32.400
And from the experiences we had there, we put that into a simulation.

01:13:32.760 --> 01:13:39.560
We can run our control architecture also with respect to simulation.

01:13:40.280 --> 01:13:43.720
And there we simulated a system where you have locally some

01:13:43.720 --> 01:13:45.300
photovoltaic system.

01:13:45.300 --> 01:13:49.320
We have a micro combined heat and power plant.

01:13:50.460 --> 01:13:55.180
And assuming the consumption patterns of a five person household, with

01:13:55.180 --> 01:14:01.180
typical appliances, fridges, washing machines, dishwashers, and so on.

01:14:01.920 --> 01:14:06.580
But without any possibilities to store electricity locally, no

01:14:06.580 --> 01:14:06.980
battery.

01:14:08.300 --> 01:14:12.880
We noticed that if it's, if we look at all the weeks of a year, that

01:14:12.880 --> 01:14:18.560
what is shown here, it shows in this case, the degree of self-supply.

01:14:19.480 --> 01:14:25.120
So the red curves shows the self-supply in that situation without

01:14:25.820 --> 01:14:26.940
optimizing anything.

01:14:27.520 --> 01:14:32.460
Just using the combined heat and power plant, heat controlled, not

01:14:32.460 --> 01:14:34.480
power controlled, but heat controlled.

01:14:34.640 --> 01:14:37.540
Whenever you need heat, you would just use a combined heat and power

01:14:37.540 --> 01:14:41.060
plant and generate power as a side product.

01:14:42.680 --> 01:14:46.440
And you would not influence the schedule of your appliances.

01:14:48.120 --> 01:14:50.720
Certainly you cannot control the photovoltaic panels.

01:14:51.600 --> 01:14:57.220
And then this was optimized, optimizing the use of the combined heat

01:14:57.220 --> 01:15:01.460
and power plant and optimizing the use of those appliances in the

01:15:01.460 --> 01:15:03.960
house, which are observable and controllable.

01:15:04.620 --> 01:15:07.760
And this actually led to an improvement, which is quite significant.

01:15:08.380 --> 01:15:13.800
So just by reshuffling, rearranging the use of those devices, the

01:15:13.800 --> 01:15:18.080
degree of self-supply was increased here from 40 percent to 60 percent

01:15:18.080 --> 01:15:21.740
or here from 50 to 70 percent.

01:15:21.940 --> 01:15:23.540
So this is quite significant.

01:15:24.560 --> 01:15:27.940
That was stable over all the weeks of a year.

01:15:28.500 --> 01:15:34.780
So it shows we can do something to improve self-supply even without

01:15:34.780 --> 01:15:35.700
having batteries.

01:15:36.440 --> 01:15:41.020
The same was done for the aspect of self-consumption.

01:15:42.020 --> 01:15:44.960
So how much can we actually self-consume?

01:15:45.620 --> 01:15:47.260
And here you see those patterns.

01:15:48.060 --> 01:15:53.440
Certainly what you see or you might wonder why the degree, for

01:15:53.440 --> 01:15:55.760
example, of self-consumption is that low.

01:15:56.380 --> 01:16:00.020
The problem certainly is that you might have a situation where you

01:16:00.020 --> 01:16:07.080
have a lot of power generation and you just cannot consume all that

01:16:07.080 --> 01:16:08.340
because it's just a surplus.

01:16:08.500 --> 01:16:10.280
You have to provide it to the system.

01:16:10.580 --> 01:16:14.680
Although later in the day, you might have been able to use that, but

01:16:14.680 --> 01:16:15.880
you couldn't store it in between.

01:16:16.780 --> 01:16:23.860
Yeah, so the degree of self-consumption here again is not that large,

01:16:24.120 --> 01:16:28.080
but optimized it was significantly larger.

01:16:29.320 --> 01:16:32.120
And so how do we actually optimize?

01:16:33.840 --> 01:16:36.580
That's a question I will answer after the break.

01:16:36.960 --> 01:16:42.420
Yeah, we have the first part now just finished, 90 minutes.

01:16:42.960 --> 01:16:43.760
So I will