Okay.
Welcome to another session of this course, which is, well, not
following a fixed schedule as normal courses, but we had several
times.
Now we are, we moved to Monday afternoon, and I'm glad that some
people are back, who said last time, before we moved to Monday, that
Monday would be much better, and when we had it the first time on
Monday, they were not there.
And so it's good that more of you are here again, and I'm glad that
you also filled in these evaluation forms.
I hope that you all did that.
If somebody did not do that, you're welcome to do that afterward.
Somebody agreed to take it to the...
You take it?
Okay.
Perfect.
Thank you.
So, last time, we looked at, certainly, smart energy distribution, and
we had looked at the self-organized balancing systems, and also, we
also looked at smart home energy management, and we had looked at
quite a few different topics here.
I had shown you, again, briefly our projects, Meragio, Meragio Mobile,
that we had worked on, like the first results here on flexibility in
the Meragio scenario, where we have looked at possibilities of
residents in normal homes, how they would actually respond to price
signals.
We had Meragio Mobile, where we looked at how we can integrate
electric vehicles into the energy management, in particular, the
batteries.
We saw that there's quite some potential.
I showed you our energy smart home at least on slides.
You can go there sometime.
We have to talk about that, when we'll actually go there.
I told you something about the aspect of smart homes in general that's
normally associated with home automation, and so comfort, security,
and health.
And we are looking at energy, extending the standard focus of smart
homes with respect to the energy aspect.
We discussed a few possible scenarios of those homes.
I showed you the ingredients of our energy smart home lab on campus,
where we have all kinds of different components installed in order to
be able to use that as some kind of power hardware in the loop, where
we have some possibility to actually test the way we can influence the
system by controlling all the devices there.
We looked briefly at that scenario.
I showed you what kind of vehicles we have there, and then we looked
at possibilities to classify appliances in these houses, like there
are observable and controllable appliances.
Observable appliances are important because it can observe them, and
we know that they have some fixed ways of reoccurring, and we can
predict a load profile for the next day, and can try to establish a
good schedule for those devices which we can control and find the best
possible time slot for running.
This was shown in this example here on the...
Here it is.
We looked at this schedule where we have different devices which could
be moved according to the price signal, forwards or backwards in time.
And then I showed you a little bit more about the smart home, the
interface we have there, and showed you our ways of displaying
actually the degrees of freedom of the different components.
For example, a dishwasher, or this was a tumble dryer actually, and an
important point is that the residents of a house can easily specify
their degrees of freedom for using such an appliance.
The system would respond with the automatic start, and if the user
doesn't like that, you can always just click on the start button or
this end button and just switch it on.
I showed that was the... this was the last slide, last time I think.
Yes, that was the last slide.
So here I showed you the interface for the electric vehicles, and in
our smart home, where... I hope you can see that actually.
Maybe I have to move this a little bit to the side.
Can all see it?
Okay, somehow it's moved over here.
I cannot... don't want to move that projector really.
Okay, so here we have the interface showing the energy flows in the
smart home, which is important to actually show what's happening in
the house.
Some simple ideas are implemented here.
For example, this green line here indicates that currently there's a
surplus of energy feeding back energy into the grid.
Otherwise, if we would get energy from the grid, it would be painted
in red.
And so you'd see just easily what the current situation of the house
is, and you also see the flows of power in the house.
And with respect to the electric vehicle, what you see there is the
interface, which allows actually to easily specify the next departure
time, because you would like to have a fully charged battery at that
point in time.
You specify the minimum range that you would like to have all the
time.
Maybe 15 kilometers is a little bit too low, but you can just specify
any range there, and make sure that you always can rely on having this
range if you are going on a spontaneous trip before the initially
indicated departure time.
All this is actually implemented using all kinds of devices that we
got off the shelf.
Some standard components, which we use for controlling all the
different components in there, so it's real implemented.
You can see it when we will have a look at that house.
And in the background, we have this energy management system, which is
performing all these optimizations in the background.
Now, how can we do that?
We have all our components, which are in the house.
The washing machine, the fridge, or whatever you have there.
And then we have to know what these devices actually are currently
doing.
We have to observe them, and maybe we have to send some activation
signal.
So we need some kind of observer, that's the O, and controller, and we
need an interface for that.
And we have to abstract from the detailed features of these devices.
I underline this H-A-L, because H-A-L is not the computer you know
from some story, some novel, but it's the hardware abstraction layer.
The hardware abstraction layer is just abstracting from certain
details of those devices, and then you can get the appropriate
information for observing those systems, and for controlling them.
Now, you have all the individual devices.
You have also some interface to communicate with the user.
You saw this energy management panel.
So you can communicate with the user in the house, and you get some
information from the energy provider about prices.
You might get some information from the distribution system operator
with respect to some potential constraints for power, so some
preferred power profile.
And then this information is actually collected into some larger
observer and controller, where all this information is accumulated,
used to generate some kind of load profile to show the current
situation, to learn something about, well, potential loads in the
future.
And then this is combined in order to actually be able to control the
house appropriately.
To control the house appropriately means do it in the best possible
way, where best possible way has to be specified by some user.
Usually he wants to just reduce the cost.
So you would like to get a cost-efficient schedule, or maybe you would
like to just use as much renewable energies as possible.
Then you would have a slightly different objective.
So this can be integrated in there.
And then you have all these different features in there.
You have the possibility to observe and control individual units.
You can observe and predict what's happening in the house.
You can learn and control what should be done in the house.
And then this is sent back again to those devices in order to behave
appropriately.
And what you need certainly is also information from communicating
with the user inside the house, and with some external entities who
would provide prices, constraints, and so on.
Now this is an architecture that has been designed actually in a
certain research program that was the Organic Computing Research
Program, which has run from 2005 to 2011, actually organized by
myself.
It was a large research program in Germany.
And it was about distributed, decentralized systems, which communicate
with each other to provide a certain functionality.
We have designed this observer-controller architecture in that
environment, in that framework, and actually designed it with respect
to traffic control scenarios, and then extended it for this energy
control system.
And I would like to briefly tell you a little bit about organic
computing.
What I'm just showing you here is the cover of a book that we have
provided as a result of that six-year program.
So quite a thick book on all kinds of aspects that were treated in
that priority program of the German Research Foundation.
So organic computing, what is it about?
As I said, it is about a world of components which are more and more
getting intelligent, and components which can communicate.
It is something which is sometimes called the ubiquitous network
computer.
That means a computer consisting of many, many, many different
information processing units, which are almost always somewhere in our
environment.
So if you have all kinds of intelligent devices, you would like to
make sure that you don't get lost in that network.
And so they should be designed such that human needs are respected.
The question is how do I actually know the human needs?
Do you have some ideas of what human needs might be?
Maybe you have to get the ideas of humans directly.
I showed you this energy management panel briefly.
That is a way of getting information on the human needs.
Then they have to be robust, adaptive, and flexible.
Robust usually means that there may be some disturbances.
So for example, power supply can drop down because there is a cloud,
and the PV panel does not work anymore or does not produce energy
anymore.
The system should still provide you with power.
How can it do that?
It has to be robust against disturbances.
Or if you know the notion of robustness from other areas, usually it
is the case that you have a certain disturbance or some attack on the
system, some damage, or you do something to the system, but it still
provides its functionality.
It doesn't break.
Then it has to be adaptive.
It should be able to actually adapt to different situations.
So for example, your mobile phone should be able to adapt to different
environments, sometimes using 3G networks, and then maybe use WaveLAN,
and then maybe just some edge functionality.
So very different protocols that are used for communication, depending
on the availability of services.
Adaptiveness is the notion.
Flexibility would mean that you might have different goals.
On one day, you might want to have cost-efficient usage of energy.
The other day, you would like to optimize for renewable energies that
might be different from each other.
Or in traffic, you could optimize for...
like if you optimize traffic scenarios, street network with many
different traffic lights, you might optimize for number of stops, or
you might optimize for waiting time, for reducing the waiting time, or
you might optimize for maybe just energy consumption, to reduce the
energy consumption.
So many different ways you could actually use that.
And then you would like to have certainly the notion that this would
be self-organized, so they should be able to do some things on their
own, because there are so many devices that you would not like to
actually reprogram them whenever some change is necessary, but they
should be able to do that on their own.
And so you need some kind of self-organization.
And if you have a self-organizing system, you would like to have a
situation where if this is the desired behavior, you know that my
system will always stay inside those desired behaviors, it will not go
outside and do something which is unwanted, and so it should be
trustworthy, also perform the desired functionality in the way that
you expect them to actually perform that.
Trustworthiness is another topic which can be treated in a very formal
way, in a very systematic way, which we will not address in this
course, but which is addressed in, for example, courses on organic
computing.
Now, if we have systems which are robust, adaptive, flexible, self
-organized, they have some kind of lifelike behavior, and so we just
said, okay, we will call them organic computer systems.
We, in this sense, is the community of computer engineering in
Germany.
We had a series of workshops, so we looked for what is our roadmap,
what are the challenges for systems in 5, 10, 15 years ahead, so that
was in 2002, and we said what kind of systems would we need, and so
that was the challenges that we saw, and we said what we need is a
system having some kind of organic behavior, and so for that we need
the appropriate architectures.
And this certainly did not come just out of the air, but there were
quite a few similar initiatives, quite a few of them completely
independent of what we did, but to some extent also we were influenced
by those things like ubiquitous computing, autonomic computing,
pervasive computing, all kinds of notions for collections of devices,
which we get more and more intelligent, and can actually coordinate
their activities in a reasonable way.
So when we talk about organic computing, it is not that we have
designed there a research program, we say, oh, we have a nice idea, we
would like to have systems which are actually self-organizing and have
some organic behavior, maybe influenced by things we see in nature,
but it is inevitable that we will be in a situation where we are
surrounded by all kinds of adaptive and self-organizing systems, but
we have to make sure that they are designed in a reasonable way, that
we can actually be satisfied with those systems, and don't get afraid
and try to abolish them, get rid of them, but that we see it's a
benefit to have these kinds of systems around.
And for that, we have to think about appropriate architectures and
approaches to control those systems, control a system which we assume
to be self-organizing, self-controlled, so there's some kind of
contradiction, but we need appropriate interfaces to still transfer
our expectations to those systems.
So questions are how we can actually design them, all kinds of
different design questions that are popping up here, which could be
looked at, so what actually does self-organized mean, adaptivity, do
we just have feed-forward control or feedback control, so there are
some approaches to talk about model-based systems, model-predictive
control is a standard approach to control systems, technical systems,
so you see all kinds of different topics which are mentioned here, and
that's what we worked on in this priority program of the German
Research Foundation, where we, if I say we, it is first of all these
three names, so two more people than myself, Kirsten Müller-Schlörer
and Theo Ungerer, who worked on, we were the core team, and then we
had 18 projects all over Germany, with about 25 colleagues who were
active in there, and we were working on principles of organic
computing, looking at self-organization, self-optimizing, self
-healing, self-protection properties and emergent phenomena from self
-organization, we looked at nature to see what kind of structures and
behaviors and behavioral patterns we can see there, which might be
helpful for designing technical systems, our goal was to establish a
toolbox for organic computing, and we always had in mind applications
where we actually need those self-organization aspects.
So that was our projects, range of projects, I don't want to go into
all these projects, but I would like to tell you something about the
kind of architecture that we designed from that, and what sense that
is generic, and I would like to start by telling you something about,
very briefly, about an alternative architecture, which was designed in
the Autonomic Computing Framework.
Autonomic Computing was mainly initiated by IBM, and they had in mind
that large enterprise server systems should have more and more self
-organizing features, self-x properties, because the manual effort was
too high, and many things could be automated easily, and so they also
thought about how they can actually automate that, and so they have
some kind of productive system, for example, an enterprise server
system, and then you have to monitor that, that's the M, you have to
analyze what's happening, what you're seeing there, you have to plan
how to respond to that, and then execute the planned action
appropriately on the system, and then, in this way, you can control
the system.
The K in the middle here stands for knowledge, which you accumulate
over time based on experience, and so you can improve the behavior of
that system.
So this is called an autonomic element, and the idea is that many of
those can communicate appropriately.
And what we came up with in organic computing was in some way similar.
There are a few different names, but not just names, but also the
concepts were slightly different, so we talked not about a productive
system, but about a system under observation and control, which has to
run just on its own, its functionality does not depend on the
existence of any control element on top of that.
It may be some set of agents which are communicating and interacting
to perform a certain functionality, and then we designed that observer
-controller architecture on top of it, which was meant to actually
improve the performance of these systems and turn them into such an
organic system.
And this can have many different instances, can be designed in very
different ways, but there is this pattern of the observer-controller
which can be looked at as some kind of generic system, and I will show
you what the ingredients of that should be in order to have integrated
or looked at all the different components that are necessary.
It can also be a multi-level organization, maybe that on top of that
you have the next entity, so here I have drawn a user, maybe a human
user, maybe some next layer entity which is providing information
towards those agents, so maybe that in here those agents by itself
again are those instances of a system having an observer and a
controller.
So what do we have in there?
We have the system and observation and control, we have all these
different parts in here, I will in a moment show you that again, but I
wanted to just briefly show you the overview picture.
We have an architecture where we have this observer and we have a
controller.
And in the observer we have several components to monitor, to filter,
to store what we have seen, to analyze, to predict, to aggregate.
That information is sent into the controller where we can map that
onto actions, evaluate, maybe adapt what's happening there, and this
is directed by user goals.
And I would like to briefly show you that again and go into a few of
those things that are necessary there.
So when we monitor, we are just getting some data.
This is something you can design.
At some point in time you can design such a...
you decide which parameters you actually look at.
If you have not designed a certain sensor to look at a certain
parameter, you will never be able to get information on that
parameter.
This is something which has to be done at design time and sometimes
you will just install more sensors or more possibilities to monitor
something on that system and observation and control than what you
actually would need at all times while you are running the system.
So maybe you have more sensors available and you are just looking at
some subset of that.
So you have also a certain model of observation.
I think it should pop up there.
Yes, there's the model of observation.
Maybe you have to select by some model of observation which kind of
parameters you actually want to look at.
It's certainly reasonable to store what you have seen there because
you would like to have some history available of the development of a
system.
And then maybe you have to filter what you have seen.
Maybe you have some time series and all of a sudden you have some very
high value.
Maybe you have a low value.
You have no values.
So maybe you have to repair what you have seen.
You have to delete certain outliers assuming that such an outlier is
not a real value but some kind of erroneous value.
So certain things you might do there and then you would like to
analyze what's happening.
Now what would you like to analyze?
Here on that slide you see that something like emergence detector.
What is emergence?
So what we could see is if we have, for example, an artificial example
we have certain elements which are distributed over like in a two
-dimensional space and the normal situation would be that they are
just distributed quite evenly.
And then maybe all of a sudden you notice oh, they are all arranged in
those lines.
This looks like a different situation.
Maybe you can notice that it's a different situation by looking at the
distribution of the values of, for example, the x and y values so if
you have x and y, look at the x and y coordinates and you will notice
that all of a sudden certain y coordinates appear more often than
others and this can be measured by looking at the entropy.
So, for example, you could look at the entropy with respect to the y
coordinates and that is minus the sum of all frequencies pi log pi and
pi is the frequency of the potential values of y.
So if you have here many different values you look at how often each
value occurs so if these are n different values that you might have
you have a sum i equals one to n you have the frequency, how often
each y coordinate that you have actually looked at is occurring and
then this is the entropy of such a parameter.
You could also look at the x parameter or the x entropy in a similar
way and you can look at whatever parameter you might be interested in
and see how it is distributed in your system that you're looking at.
Now if you notice that this value here is very large then you have a
very uniform distribution of those values.
It may be that this value is going down that it's getting smaller.
If it's getting smaller you have a system which is more or less which
is showing a higher degree of order.
So in this situation here we have a higher degree of order and for
that the h y value would be much less than the h x value.
And so you would notice just by looking at the entropy values that you
have a change in the degree of order of the system and this might be
an indicator of an interesting effect in your system.
And so this is what you can do for example to notice, oh something
happens in my system it's deviating from standard behavior the degree
of order has changed and so I have to do something.
Or you can transfer that easily to energy situations where you have
all kinds, for example, meter readings and you see a standard
situation of different values there and then all of a sudden you have
deviations from that and you would like to notice those deviations.
And as soon as you have noticed such a deviation you have to tell that
in a reasonable way to the controller which has to get the appropriate
actions depending on what you have just observed.
So we have the entropy and actually what we define as the emergence is
the Hmax value minus the current for example, for the Y variable that
would be the emergence of the Y variable which would be Hmax minus Hy
or Hmax, I have to write that in a different way
Hymax minus Hy so the maximum value of that actually is the logarithm
of the number of values that you have here so it would be in that case
log N minus the current entropy value and that is the emergence value
of that situation.
That's how we define that in our projects and notice that in this way
we can find out or detect certain interesting changes in behavior of
such a system.
So this is what we do or one example of what you can do in the
analysis maybe you can just write or compute certain variances or
perform all kinds of standard functions that you would like to get
there.
Another component here is the predictor we would like to be able to
predict what should be happening depending on or with respect to what
we have seen in the past so if you are or if you have observed a
certain system and now you are at this point in time, T and then you
predict how that will perform in the future if you would predict like
depending on what you have just seen you predict a certain behavior
and then you can decide on what you should do whether you should
influence your system to behave differently or whether that is okay
you can also find out whether the next time you visit that is it
actually that behavior that you predicted or is it something different
if it's different, something must have happened or maybe your model is
different is incorrect so prediction is an important point to check
whether your system, your model of the system that you use for
evaluating the current situation actually is still correct so this has
to be or could be integrated into such a generic architecture and then
we have to aggregate what we have seen maybe we just transfer
everything that we have seen maybe we just transfer those entropy
values or whatever you might like to have as results of your analysis
so some derived values might also be included in that aggregated value
and then you go over to that controller and in that controller we, as
I said, we have all we have these different components we have a
mapping and the mapping, what would it do?
you have some kind, as you see here, some kind of table or mapping, as
I said certain situations that are indicated by your observer and then
maybe that you have here some conditions you just check for a certain
property of the current situation maybe that you have different
conditions which fire and then you might have different actions that
would actually be activated which could be selected and it's not
necessarily just one activity that should be performed there or just
one control action maybe there is a choice of different actions and
then you need some kind of decision mechanism to decide which action
should be chosen as a response to the currently observed situation so
you have here this action selector And you will perform a certain
action on your system.
In a traffic scenario, you might increase or decrease speed limits or
whatever.
Like if you have a traffic jam control on a highway, you would just
enforce a traffic speed limit.
In the energy system, you might notice some bottleneck situation and
you might impose some power constraint that you tell the houses in
your distribution system, you should not go over a certain limit in
the power that you use.
Okay, then you have executed that action, you store it into some
history mechanism, where the next time you actually get a situation
description, you look at the impact that this execution of that action
had.
Now to looking at the impact means you look at what actually changed,
you had some intended change, that's why you selected that action.
And then you can notice whether that impact actually was according to
what you expected.
And you can evaluate the appropriateness of the action that you had
selected previously.
If you notice it is perfect, it does exactly what you wanted, you
would give it a high fitness, maybe a real value, maybe some other
value that you just decide to use.
But in any case, you need some evaluation.
If it's performing differently from what we expected, you would give
it a low fitness.
And then this adaptation module here would actually send that
information back into that mapping process, and in some way indicate
that this action that was chosen as a response to that activated
condition was not really adequate.
And the fitness should be reduced or the some kind of expected
performance should be reduced.
Or maybe you should delete a certain action from that.
Or maybe you notice, oh, I really don't have an appropriate action
available.
And if I don't have an appropriate action available in that mapping
mechanism, then I would need a new action.
Now, how do I determine what I have to do if I have no appropriate
action available?
You could certainly just test an arbitrary activity, arbitrary action,
just arbitrarily modify the control parameters that you have for that
system.
That might be feasible in some situations, but not if you have an
energy system or a traffic system.
And so for that, you would need some simulation model, modeling the
environment that you are actually controlling, modeling the system
under observation and control.
And then by some planning process, plan or generate a new action with
respect to the situation that you had observed and where you had only
inappropriate responses.
So generate something, some kind of in an offline simulation model,
look at how it performs with respect to that model of the environment.
And if it's performing well, then you would send that action down
again into that system.
Now I said it should perform well, or maybe some things don't perform
well.
Whether it performs well or not is determined by the goals that you
have, the objectives that you have in your system, how you decide this
is good, this is bad.
And these objectives are given by some external entity, which may be a
human user, maybe just some next level entity which is providing that.
So it can be a hierarchical system.
And it's important that this human user has an interface to actually
tell the system what its objectives are.
And that it can, that maybe can also interfere directly.
So these are more or less the components that we have in that generic
architecture.
And it does not mean that in every organic system, you need all these
components.
If you look at that, you could say it's more or less the same as the
MAPE.
But I talked much longer about this architecture than I talked about
the MAPE architecture, not because it's the one we have designed, but
it's just addresses a larger variety of topics.
And it in particular addresses the topics of learning, what the impact
of a certain situation or a certain action is, and being able to
actually generate something independent of the current system based on
a simulation model.
So this is an important point to have learning, how the performance of
the system actually is and modifying what you're doing.
So learning always means you would like to improve your situation.
So we talked about learning, just to write it down here.
We talked about improving your performance the next time you see a
certain situation.
And you can do that either by modifying the mapping here, because
you've seen a certain activity is not appropriate, or by getting new
actions from that generation mechanism.
Okay, now, this was the observer-controller architecture.
And we can look at that in a slightly different way.
We have some kind of basic system, the system of observation and
control, for example, a traffic controller or an energy management
system being controlled by certain parameters.
And this is running.
And then we have the possibility to modify the control system by
performing a certain change of parameters.
That's the action.
We perform with respect to a certain rule set.
This is the observer of the first level here.
This is the online action selection.
And we get feedback, look at what's happening.
We can modify the selection of those rules.
And then we have also this next layer, where we have to generate new
actions if we are not satisfied with the available action from that
rule set.
And for that, we have some mechanism, for example, in the evolutionary
algorithm to generate new settings of parameters, setting of control
parameters, or whatever you would have to do down there in that
system.
So in this way, we can have a two-level learning mechanism, online
learning loop, by waiting for responses from the system.
That's here, this loop down there.
And then we have the offline learning system being done over here,
where we just generate new activities based on the simulation model,
evaluating the appropriateness of those generated actions with respect
to the simulation model, which hopefully is adequate.
And then those actions which are performing the best after a certain
time, we are satisfied with the quality, we move them down into the
rule set and then can use them more or less in real time, or in soft
real time.
Because this year, the offline loop or the online loop is very fast,
the offline loop takes some time.
So this is a slightly different view of that architecture.
It's a three-layered architecture.
And if you look at similar parameters or similar architectures for
other scenarios, for example, there is an architecture called sense
-learn -act, or there is the viable systems architecture, or there are
other architectures for self-organizing systems.
They usually have these three layers.
And there's also an operator, not an observer controller, but an
operator control mechanism.
No, not mechanism, module.
Operator control module.
And we have the main architecture.
Essentially, they are very similar.
But here, like we have this specific way of looking at that.
And we have transformed that into these architectures for managing
energy systems.
Just because energy systems are actually very much looking like those
components where we have all these systems, where we have many
components interacting with each other.
And we have to sometimes do or influence them in order to provide the
desired functionality, which means the appropriate balancing between
demand and supply.
Okay.
As I said, when I started to tell you something about this observer
controller architecture, they can be designed in many different ways.
They could be designed in a centralized way.
You have just one system and observation and control, larger one with
many components.
You have one observer, one controller, and that's it.
A centralized system, looking at that, that's not really self
-organizing.
It is maybe adaptive due to that mechanism, but it is a very top-down
approach.
It's not really what we call a self-organizing system.
There could be a very distributed system, distributed architecture,
where we have many of those devices all having an observer controller,
which would actually communicate in some way with each other.
And then, as a result of their interaction, they might develop some
kind of emergent control mechanism.
This is something which is the result of the bottom-up communication
and interaction between all those components, and that's what we
normally call typical self-organizing systems.
No central authority, just these intelligent agents communicating.
What we have in organic computing is rather such a multi-level system
where we have definitely many intelligent individual systems, but then
another layer where we actually observe what's happening there and
influence it whenever necessary.
And this may be that this is not just one of those next-layer systems,
but there may be several of them.
So we might have some hierarchical system, and that's what we call a
controlled self-organizing system.
There are certain self-organizing features already in there, and then
we have the observer controller on top of that.
So we have a combination of the bottom-up architecture, as shown here
in the middle, and the top-down architecture, as shown on the left,
which is combined into such a controlled self-organizing system, which
sounds like a contradiction, but it just shows that it has the ability
to be controlled by some external entity, which tells what to do, but
it will only influence what's happening here, if necessary, if some
undesired behavior is detected.
And so this is something which can, on demand, control a system, but
normally it will be self-organizing.
So that was very brief, the philosophy of organic computing
methodologies that we designed in that program, and we have used that
in many different application scenarios.
So I mentioned several times already traffic control.
We actually have designed there such an architecture where we start,
like we had here, this system of operational control, and then this
rule set in there, in this example.
That rule set actually was completely empty when we start such a
traffic controller.
We just look at the traffic flows, we give it the objective to reduce
waiting times, reduce number of stops, or reduce energy consumption.
You certainly need appropriate models of such an intersection.
So if you have a certain intersection, and you would like to determine
what's the best possible flow in the different directions here, maybe
some flow wanting to go that way.
So different traffic flows, you look at the current strength of those
traffic flows, and then the system has to determine on these traffic
lights, has to decide on the length of the green phases, allowing
traffic flow to actually proceed.
How long, how do I determine those green phases?
And this is done by that system, and it's actually generated by an
evolutionary algorithm.
And so very fast, with this system, we were actually capable to
outperform a system that was designed by traffic engineers.
We did that in several different example situations.
So this system is able to actually self-optimize and get some good
behavior.
It could also, if you have the next intersection here, coordinate with
the neighboring intersection to have some green wave, so that self
-organizing feature.
And some regional controller would look at that, would say, okay,
maybe certain certain coordination between neighboring sections would
be desirable or not desirable, or we change certain objectives.
This regional controller could also be integrated adequately in there.
So we really had this organic system, which was by itself generating
an intelligent behavior or an adaptive behavior.
And so that's where we actually developed this observer-controller
architecture.
We had other projects like production systems, industrial production
systems, where the idea was to be able to tolerate breakdowns of
certain tools and then get around certain broken tools and try to
still produce adequate products by reconfiguration of the system.
We looked at smart camera systems, where you have a certain
environment that you would like to supervise.
You have cameras, which would always all have some angle which they
can view.
And then you would like to have some information on what's happening
on your system by combining the information from the different cameras
and respond to something you have seen on one camera.
Maybe follow if somebody is walking through here, you can follow that
person appropriately.
You would like to detect whether he's doing something which is bad or
not.
So smart camera systems are important for supervisory applications.
We looked at network control applications, system-on-chip
applications, and what we did in particular in my group is, like in
recent years, energy management and control.
And now we come back to the energy topic.
And I just wanted to give you some idea of what's the background of
those architectures.
Any questions?
No?
Okay.
So now we are back to the energy system.
Yes, the question.
The traffic control picture you drew before, do you mean that it's
controlling traffic in real time or it learns how it flows and adapts
itself or in real time it changes the light?
Well, yes.
So what does it do?
I said it would control the length of the green phase.
Now there are certain traffic light controllers which would respond to
the number of cars that are standing in line here in front of the
traffic light and would just, if it's a long line of cars, then it
would automatically extend the green phase.
We did not do that.
So that would be adaptive or traffic responsive traffic light control.
What we did is we just had fixed times for the green phase, but we
would notice what the traffic flow is and adjust those green times for
the next round of, for the next iteration of the different phases, we
would adjust the green phase.
Select a different parameter setting appropriate to that situation
that we had observed.
So it is not exactly adaptive change of the green phase while the
green phase is still on, but it would modify it the next time we get
to that situation.
So it would notice, oh, what I've done here is not really appropriate.
I have to change that.
I get to my rule set.
The situation is like this.
And then you get a new parameter setting.
And this can be done very often.
And so we have almost the same effect as an adaptive traffic light
controller, but even better than that, although also these adaptive
traffic light controllers, which are traffic responsive, have fixed
parameters.
So the degree to which they can actually modify the green phases are
more or less fixed.
There's a certain range of values, but it's just a limited range of
flexibility.
Whereas here in our system, we can arbitrarily modify that if it's
appropriate.
And as I said, it was actually
outperforming systems engineered by or designed by traffic engineers,
so it's not that bad.
Initially, it was not really our goal, our ambitious goal to say,
okay, we would like to outperform traffic engineers.
We just said we would like to see whether we can actually generate
something which is more or less reasonable in such a situation.
And we actually noticed that we can do quite well there.
And in particular, we can also design those traffic adaptive green
phases, progressive signal systems, which normally are fixed.
You have a certain street, a sequence of intersections, which are
having this progressive signal system synchronized green phases.
Sometimes this is done because we want to regulate the traffic in some
way.
But usually you should have a green phase where you have the maximum
traffic flow, because it should be beneficial for the most number of
cars.
And this can be detected by the intersections and then they can
reorganize and provide the best sequence or the best green phase or
the best green wave to those intersection sequence, which is the most
appropriate for the most number of cars.
So this is what we did there.
But now back to the energy system.
So in there, as I showed you just before, before I started telling you
something about organic computing, we have this architecture where we
have drivers for the individual components, for vehicles, for washing
machines, or whatever you have in a house.
And you have those local observers and controllers.
And you have a controller, a global controller inside the house.
And so this is all implemented in Java.
It's actually available under a GNU license.
So it's open source, can be freely used.
And then there are other approaches to that.
For example, there is the EEbus.
EEbus is EE for e-energy, some architecture which is an alternative to
our hardware protection layer, which would look at all kinds of
different communication protocols.
The problem is that those devices that we have here, different devices
in a household, would speak different languages.
And so some speak KNX, some use ZigBee for communication, some use
just standard web service standards.
Then there is universal plug and play systems.
So different types of communication protocols.
And the system that you provide for energy management should be able
to communicate with all those devices.
And the EEbus is one approach to unifying all those different
protocols by having some kind of standard format for all those data
packets that are sent.
So essentially, the EEbus is providing an XML interface, an XML
standard for the information that is sent to the different services or
applications that are trying to manage the energy system.
Now, who of you does not know what XML is about?
Several of you.
Okay.
So what is XML about?
Now, I did not provide that as an extra slide.
Next time I should do that.
So I have to draw it on this slide here.
It's not that difficult.
XML is the Extendable Markup Language.
The Extendable Markup Language, XML, is a way of providing a structure
to a document by providing markups.
So, for example, I could say this here is a heading.
That's a heading, Architecture of Management System.
And after that, I could say, okay, that was the heading.
That's the end of the heading.
And so I would have, like in a document, if I have a document here, I
could say, okay, here in the beginning I write heading or whatever,
and then I have a certain sequence of text, and that's the end of the
heading.
And I notice that, okay, this is a heading.
And then I might have certain other elements.
So I might have a certain, maybe I have a paragraph.
Then I have certain text, and I have the end of the paragraph.
And maybe I have some address.
And inside that address, I may have some name, and this name maybe is
KIT, and that's the end of the name.
And maybe I have some, let me just say location, or whatever you like
to have here, let's say a password.
And that's the end of location.
Oops.
And then you would have the end of the address.
And so on.
So what does this provide?
This provides structural information on the content, on some content
you would like to present somewhere.
You want to communicate certain information to somebody else.
And here I just wrote, okay, there's a certain paragraph, although
that's a different type of markup that I use here, different type of
tag, because paragraph is more some structural thing without reference
to the content.
Here I said an address contains a name and a location, and the name is
just a sequence of text.
Here also just a sequence of text.
Now I can have more sophisticated types of tags like that.
And essentially I get something which is a tree structured document.
So I always have a start and an end of that.
I have nested, this was a nested structure.
This is some kind of a tree structure.
And so I have a structured document.
And I can define a certain scheme, how I would like to structure a
document.
If, for example, I provide information on, let's say, what the washing
machine would like to do.
I would like to send information on what the washing machine just or
is just doing the current state of the washing machine.
I just send that information somewhere upwards.
Now I can structure that into a specific parameter, some kind of
schema, some kind of template.
So this is XML.
And now XML has another feature which is called XSLT.
That's the XSL, the style language, the XML style language translator.
And this is important because this here, this XSLT, provides us with
the possibility to present the information in some way.
So you know, for example, HTML, a language similar to XML, actually a
special case of XML, where you know if you have a certain markup of
that, of a document conforming to the HTML standard, the browser
immediately knows how to present that.
And the way you present that is defined by some kind of style sheet.
And this style sheet actually is similar to this XSLT, a way of
transforming a structured document into some other form, maybe in a
way that you can actually present it on the screen or on a slide.
So the contents of that slide here could be defined in an XML document
in combination with some kind of style sheet definition.
And then you have the arrangement of elements on such a slide.
Okay, so what is this about?
You can define the format of a certain document.
This is actually called an... oops, where do I have some... that's an
XML schema, or a document type definition.
But XML schema is the most more flexible way of doing that.
And this XML schema is something similar to some kind of grammar
describing a certain class of documents.
So you will have an XML schema for energy data, you will have an XML
schema for traffic data, you will have something for whatever you
like, for books, for all kinds of different applications.
And if you have defined that schema, you get some document and it
tells, okay, this is designed to a certain schema, you can access the
schema, you can check whether the document has the appropriate
content, and you can automatically transform that information into
some other form that is needed, for example, by that application.
So if that application knows that schema that is the basis for that
XML document there, then you can systematically process the
information from that record.
And so that's more or less what the E-Bus is about.
You have an XML format for describing the content that is provided
from different communication protocols.
They all are transformed into a standard schema, into a standard way
of structuring a document.
Then you can process that by applications in a systematic way.
That's what XML is about, structuring a document such that you can
understand what's in there and that you can process it in a reasonable
way using, for example, XSLT transformation definitions.
Okay, to show you XML in a sufficient depth, I would need several
lectures, three to four, four, five hours, something like that.
This was just a very brief indication of what that's about.
And it just shows that in order to be able to understand what's going
on in, like if we talk about big data for energy systems, smart data
for energy systems, you have to know about those ways of describing
the data in flexible ways depending on the needs you have in those
situations.
And so for modern energy systems, engineering those systems, you
should know something about these technologies also.
Okay, very brief introduction to XML.
Yes?
How can I transfer those scripts into the application?
So is there some sort of medium?
The application, okay, the medium is just data transfer.
You get a sequence of ASCII numbers, so ASCII is just the codings of
different symbols.
And then you have to interpret that appropriately.
And if you know the schema you have, like for the EWA, for example,
then you can process that appropriately.
You just write your Java program here, and you know the packets that I
get are built according to that schema.
And then I can extract the information from that document and do
whatever is intended to be the functionality of that application.
Okay, so that is the EWAS stack, something defined independently of
what we did, and we combine that into an architecture where we have
the EWAS in between our components and our architecture here for the
organic smart home, the OC architecture.
Okay, now we use that component of that energy management system, this
observer controller architecture, to optimize what's happening in the
house.
Now, what are the objectives for optimizing what's happening in the
house?
The objectives are or can be manifold.
A potential objective can be to increase the degree of self
-consumption or the degree of self-supply.
What is self-consumption, self-supply, what does that mean?
You have local generation of power from your PV cells or combined heat
and power plant or whatever you have.
And you have a certain local consumption.
Now, if your total local consumption, which is all that, is larger or
at least as large as what you have generated locally, you can 100%
utilize, self-consume the power you have generated.
If your consumption is less than what you have generated locally, you
have a smaller degree of self-consumption, but you have a 100% self
-supply.
In this situation where you have larger consumption locally, you need
a certain amount of power from the grid.
So you have a lower degree of self-supply, just here, 80% self-supply.
Here you have 100% self-supply, but only 80% self-consumption.
You know, or you may have noticed that just recently, our government
has said that if you actually self-consume power from photovoltaic
panels, locally generated power, you have to pay half the EE fee
extra, the EEG fee, which is some way of getting all the costs of the
grid paid by everybody.
But it is similar to, maybe I mentioned that before, if you would grow
your own cabbage in your garden, and to eat that cabbage, you would
have to pay something for that, because the farmer on the market can
no longer sell you his cabbage.
Yeah, it is somehow weird that you have to pay for something you've
generated on your own premises, just by using the sunlight, it's more
or less taxing the sun.
Very strange.
So this is definitely not appropriate for an incentive to generate
more power locally, what we actually should do.
Yeah, but self-consumption currently is something which is not in the
interest of the energy companies, utility companies, and the grid
operators.
They have to get some some money for operating the grid.
So it has to come from somewhere, if everybody would self supply with
power, nobody would need the grid, and then who would pay for the
grid.
And so this is a way of actually letting those pay, who are just self
-supplying themselves.
But the more appropriate way would be to say that I need some kind of
insurance for covering the risk of not having sufficient amount of
power locally.
And then I would need some extra back off or some backup power, and I
have to pay insurance fee for that.
But that's different.
It may come up to the same thing, because if you have a large demand
locally, and would need a large amount of power, you would have to pay
more as insurance rate than if you have less self-consumption or local
consumption.
Okay, but this is a different topic.
The topic that I wanted to address is, we would like to optimize, we
could optimize for self-consumption and self-supply.
You could also optimize for, for example, doing the best possible
thing to stabilize the grid.
Those would be external objectives.
These are complete internal objectives.
But if you just look at that, what can we do?
We simulated that, or we ran examples.
We ran examples in our energy smart home lab on campus.
And from the experiences we had there, we put that into a simulation.
We can run our control architecture also with respect to simulation.
And there we simulated a system where you have locally some
photovoltaic system.
We have a micro combined heat and power plant.
And assuming the consumption patterns of a five person household, with
typical appliances, fridges, washing machines, dishwashers, and so on.
But without any possibilities to store electricity locally, no
battery.
We noticed that if it's, if we look at all the weeks of a year, that
what is shown here, it shows in this case, the degree of self-supply.
So the red curves shows the self-supply in that situation without
optimizing anything.
Just using the combined heat and power plant, heat controlled, not
power controlled, but heat controlled.
Whenever you need heat, you would just use a combined heat and power
plant and generate power as a side product.
And you would not influence the schedule of your appliances.
Certainly you cannot control the photovoltaic panels.
And then this was optimized, optimizing the use of the combined heat
and power plant and optimizing the use of those appliances in the
house, which are observable and controllable.
And this actually led to an improvement, which is quite significant.
So just by reshuffling, rearranging the use of those devices, the
degree of self-supply was increased here from 40 percent to 60 percent
or here from 50 to 70 percent.
So this is quite significant.
That was stable over all the weeks of a year.
So it shows we can do something to improve self-supply even without
having batteries.
The same was done for the aspect of self-consumption.
So how much can we actually self-consume?
And here you see those patterns.
Certainly what you see or you might wonder why the degree, for
example, of self-consumption is that low.
The problem certainly is that you might have a situation where you
have a lot of power generation and you just cannot consume all that
because it's just a surplus.
You have to provide it to the system.
Although later in the day, you might have been able to use that, but
you couldn't store it in between.
Yeah, so the degree of self-consumption here again is not that large,
but optimized it was significantly larger.
And so how do we actually optimize?
That's a question I will answer after the break.
Yeah, we have the first part now just finished, 90 minutes.
So I will