Engineering the Smarts

An Illustration of the Disconnect between Control Engineering and AI

Michael Borth

Martijn Hendriks

Embedded Systems Innovation by TNO

Eindhoven, The Netherlands
Michael.Borth@tno.nl

Embedded Systems Innovation by TNO

Eindhoven, The Netherlands

AbstractThe design and analysis of smart system behavior

needs to bridge between worlds both with regard to engineering
methods and to the technologies central to adaptivity and thus a
core functionality of smart systems-of-systems. We illustrate this
in our domain, smart buildings, where AI technologies like rule
based or probabilistic reasoning set the strategies that define the
buildings adaptive behavior, but control loops firmly set in
control engineering implement it. However, we observe an
apparent disconnect between these approaches. Using demand
response (DR, the change of consumption patterns in response to
global demand) as an example, we illustrate consequences of such
mono-disciplinary thinking that both academic researchers and
engineering practitioners are prone to. Specifically, we show how
adaptive behavior couples previously independent dynamics and
how reacting to these dynamics may lead to emerging unintended
system state changes and non-acceptable performance. We argue
for stringent links between system design and analysis based on
probabilistics and simulation, as adaptivity in cyber physical
systems needs the best from both AI and control engineering.
KeywordsSoSE; CPS; control; AI; model-driven engineering;
adaptive systems; system analysis; simulation; emergence

I. SOSE FOR ADAPTIVITY

With the rollout of cyber physical systems of systems (SoS)
in more and more domains, we face the introduction of socalled smart systems on a large scale. While this term is used
inflationary, it aptly describes adaptive systems set to recognize
and adapt to their operational context and configuration as well
as their situation, and to enact smart strategies to reach their
goals in the best possible way. In most cases, such smart
behavior will cross system boundaries, e.g., in smart buildings,
where we encounter both the cooperation of different types of
systems, e.g., the lighting system that collects presence data
which is also used by heating, ventilation, air conditioning for
adjustments, and the distributed realization of systems like
lighting as system of systems that span multiple organizational
units (rooms, floors, etc.). In conjunction with energy efficient
design, LED lighting, passive temperature control etc., the
adaptive behavior of such smart buildings supports unpreceded
levels of sustainability, e.g., visible in the Edge, Deloitte's new
corporate headquarters in Amsterdam [1]. One behavioral
component of this adaptivity is demand response (DR), i.e., the
change of local consumption in response to global demand [2].
This work was partly funded via the EU FP7 ICT project SCUBA Selforganising, Co-operative and robust Building Automation.

DR is realized to stabilize power grids and to reduce energy

consumption and serves therefore global and a local goals. One
typical way to realize it is to raise energy grid prices in times of
high demand, which generates an incentive to locally reduce
consumption. The latter is achieved by implementing (sometimes mandatory) building management systems (BMS) set to
reduce the power consumption such that the actual costs rate
determined by grid price*load are pushed below a costs ceiling
if necessary. Fig. 1 depicts an example of this for lighting.
A. The Control Perspective
From the point of view of control engineering, DR sets the
reference, i.e., the desired value, within the feedback loop that
controls the dynamic behavior of the system(s) managed by the
BMS. Should the measured system output, in this case the
actual costs rate, be too high, the controller takes action and
reduces energy consumption according to pre-determined rules.
In the example of a lighting system one of the few with rapid
switch behavior and thus immediate effects such rules may
kill ornamental lights and reduce luminance in offices.
While control engineering traditionally excels in realizing
predictable systems, it is pushed at (or beyond) its limits with
adaptive behavior like DR if the latter acts in conjunction with
other dynamic behaviors. The design principle that light is
active only in occupied rooms leads to, e.g., an effect overlay:
DR must achieve its savings on a changing set of luminaires. A
set of pre-determined control rules is ill suited to accomplish
this, as it either needs to detail every possible situation, i.e., all
possible consumption scenarios with all possible DR settings,
or to cover lots of situations with few but overbearing rules.

Fig. 1. Demand response for a managed lighting system (example).

B. The AI Perspective
With the notion of smart systems, we saw the introduction
of AI technologies to solve the dilemma described for control
engineering. Runtime reasoning or search and optimization for
a sound solution, i.e., in the example, a set for energy saving
actions that are efficient given the current situation, was shown
to realize the wanted adaptive behavior in research projects
demonstrations, e.g., Scuba [3]. With approaches like these, the
leading concepts of control engineering, i.e., a direct feedback
loop between controller, system, and sensor, are replaced by an
awareness step that determines both the current situation as
well as possible or necessary actions, a selection of the actions
that fulfill the managed SoS high-level goals in the best way,
and the execution of those actions. An important difference to
control engineering is that it is not necessary to determine the
executed solution in advance. It is even possible that a smart
system executes behavior never foreseen by its designers, as
goals, causal relationships between actions and their effects,
the contribution of those effects to the goals, and the reasoning
or search mechanisms are designed rather independently with
an understanding limited to a local scope.
Nonetheless, the engineering step to design a controller has
often a match within the AI perspective of engineering smart
system adaptivity: the design of a utility and costs function that
is used to set the systems strategy or to direct the search for
the set of actions that fulfill all stakeholders requirements best
in the given situation. The design of such a function together
with strategies and the architecture of the smart SoSs decision
making (e.g., centralized vs. cooperative smart rooms) is a
topic in itself (we detail our approach based on probabilistic
reasoning [4] in [5]). In any case, this function encodes the core
of DR or other adaptive behavior but it is usually expressed
in terms of higher abstraction levels (consumption, comfort of
users, etc.) than its counterpart in control engineering.
C. The Disconnect between Control Engineering and AI
In the remainder of this article we illustrate how the gap
between engineering methods based on control theory and the
contributions of AI allows for the emergence of unintended and
not desirable behavior in cyber physical systems (CPS). This is
potentially fatal for smart SoS, e.g., if they are not accepted by
their intended users. It must therefore be addressed by SoSE,
e.g., with stringent links between system design and analysis.

Fig. 2. Trade-off space for a number of DR configurations.

II. SYSTEM BEHAVIOR AND EMERGENT EFFECTS

The dynamic behavior of the lighting SoS follows from
both its configuration which includes the parametrization of
DR and the environment, e.g., the occupancy of rooms and
outside light levels. As we laid out, the behavior cannot be
determined and optimized at design time, as it was the case for
systems without adaptivity. Instead, DR sets lighting levels that
pursue the required energy savings given the environmental
situation according to high-level principles and goals.
The DR algorithm we use for illustration has two inputs: i1
the occupancy of the building per room, and i2 the current grid
price. It has one output: o a global lighting priority level that
changes the lighting settings (implemented per room) and
thereby the energy consumption and cost. Furthermore, it has
two parameters: p1 the time between invocations, and p2 a cost
rate ceiling. The occupancy, the grid price and the priority level
determine the actual cost rate which, during a run of the DR
algorithm, is compared to the ceiling in order to decide whether
to change the priority level (see [6] for more details).
We need to point out the importance of the parameter p1
together with the fact that it did not show in the higher-level
descriptions of DR and indeed is of a type often overlooked in
the AI perspective. As Lee pointed out in [7], time-aspects of
computation (and thus AI) are crucial to system behavior, but
they are typically not visible in the design of decision making.
To illustrate the system dynamics that result from p1 and p2, we
have evaluated 35 configurations of the DR algorithm within
an experimentation site of the Scuba project (five ceiling values
combined with seven invocation periods: 1, 5, 10, 15, 30, 60
and 90 minutes). Some metrics of interest are (i) the cost
saving, (ii) the number of changes in the lighting perceived by
the occupants, and (iii) the time spent in the various priority
levels. The latter two affect the comfort of the occupants.
Fig. 2 depicts the trade-off space with the number of visible
changes over the observation period on the x-axis and the cost
savings on the y-axis. Each bubble is a DR configuration. The
size of the bubble relates to the % of time spent in the highest
priority level (most comfortable). The color of bubbles encodes
the ceiling value; a label for the invocation period is only
shown for a ceiling of 150 for readability (see III B for more
details). The figure shows that a low ceiling is more energy
efficient but implies less time spent in comfortable lighting
conditions. That is as expected. It also shows that fast reactions
to environmental dynamics, i.e., to changes to the occupancy of
rooms that are realized via short invocation periods p1, are in
effect more energy efficient, but imply more visible changes in
the ambient lighting, which in turn decreases user comfort.
The latter effect, the number of perceived light changes, is
emergent [8]. It cannot be pre-determined in system design, as
it follows from two independent dynamics, changes in the
environment (especially room occupancy), and the grid price,
that become coupled via the effects of DR. Given that control
engineering cannot account for this due to the sheer number of
possible behaviors of the environment and AI developments
are typically not concerned with this, especially if driven by
academic concerns, such an emerging effect often falls into the
gap between the techniques that we perceive. If that is the case,
it will harm the field of SoSE as smart systems will disappoint.

III. SIMULATION OF SOS IN THEIR CONTEXT

The notion that an unpredictable environment together with
smart, adaptive behavior of systems within a SoS pushes
traditional control engineering to its limits opens a requirement
to SoSE: either devise engineering methods that capture these
aspects together with their emerging effects or, at least, offer
techniques to analyze a design in regard to them. This section
firstly addresses the latter, as we argue that simulations can be
used for a validation of the control algorithm at design-time.
A. Validation at Design Time by Means of Simulation
Coming back to our example for adaptive behavior, we
already described that DR affects operational costs but also, via
changes to the light levels, the (dis-) comfort for the users. It is
therefore important for building owners and operators who
commission and run DR to predict the (financial) benefits but
also the costs incl. discomfort of the adaptive behavior. In
other terms, the design and parametrization of DR must be
validated against stakeholder goals at design time. In the Scuba
project, we have used the Uppaal toolset [9] for this purpose. It
supports modeling with finite state automata, extended with
real-valued clocks, discrete variables and a C-like data
manipulation language. Non-deterministic and probabilistic
transitions are allowed, and analysis is done by modelchecking (for a restricted set of models) and simulation.
The Uppaal model of the DR case consists of three parts: (i)
the DR algorithm, (ii) the grid, (iii) the building (occupancy),
plus a monitor for the metrics of interest. Each of the main
parts is modeled independently in a template-based manner for
which Uppaal offers ample abstract and concise means. For
instance, Fig. 3 shows the template for a room in the building.
Initially, the lights are off, and every 5 minutes the state of the
lights can toggle with a probability specified by the parameters
E and F, thus displaying occupancy. Instantiations of this
template are brought into the simulation environment for each
room of the building together with the other parts.
Validation of a DR design including emerging effects like
changes to visible light levels consists then of a large series of
automated Uppaal simulations that cover the sensible range of
inbuilt probabilistic parameters together with the parameters of
the design. This is available on all levels of agglomeration, e.g.,
for the building or per room. Fig. 4 illustrates this with the
trade-off space of a single room, similar to Fig. 2 (the values
for the ceilings and number of changes are smaller due to the
limited scope.) A comparison of the figures provides an
example that it is indeed possible to explore emerging effects
with simulations at design time to validate adaptive behavior.

Fig. 3. Uppaal room template; E, F probabilities for switching lights on/off.

Fig. 4. Trade-off space for a room as predicted by Uppaal.

B. In-context Simulation with Real World Data

Our investigations are based on occupancy data collected
from an office building and grid price data from a publicly
available source [10]. The simulation of various DR algorithms
that we described above are, on the other hand, based on
discrete-event simulation (DES) techniques [11]. Given that
such techniques fit well to time-stamped event sequences and
thus the type of our historical data we can easily combine our
analysis based on simulation with real world data. (This is how
Fig. 2 was obtained.) For this purpose, we have built a custom
simulator that takes both event data streams and feeds these to
the actual DR implementation, see Fig. 5. The output of the DR
algorithm, together with the occupancy and grid data are input
for an Observer component that tracks the metrics of interest.
A key feature of our approach to couple DES with real
world data, e.g., from a (building) data warehouse, is that it
allows us to replay real scenarios from either the past or from
comparable SoS with different implementations and parameters
for adaptive behavior, like DR. This helps to answer what-if
questions such as what happens if one extends the invocation
period. Moreover, it offers a powerful tool to optimize SoS
operations, especially if used in-the-loop with run-time AI
approaches that realize proper adaptive behavior by tuning the
parameters of the smart behavior algorithms. However, in the
context of our investigation of the link between AI and control
engineering, we can also derive possible sources and likelihood
of emerging effects. We will elaborate this in the next section.

Fig. 5. Custom discrete-event simulation with historical data.

IV. ENGINEERING THE SMARTS

Simulations of adaptive SoS within their dynamic context
allows us to gain insights about their performance including
on higher-order goals like user comfort impacted by emerging
effects. Is it important to see that such insights stem from a
directed investigation based on expert understanding; in our
example the understanding that DR couples two independent
dynamics which leads to an emerging effect affecting comfort.
Phrased differently, there is knowledge about a causal chain
and simulations are run to discern the likelihood of unintended
effects at the end of that chain in order to optimize the systems
design towards acceptable levels of this probability. As our
example shows, SoSE benefits from such investigations.
Yet, we believe that stronger support for SoS engineers is
necessary and possible especially in situations where either
real world data on the environments dynamics is available or
simulations of those exists and model-based design details
cause-effect relationships between actions and reactions within
the SoS. Here, we address the first issue we raised in the
introduction of Section III, i.e., the need to devise engineering
methods to capture interactions between dynamic environments
and systems with adaptive behavior plus the emerging effects.
In this, our work is guided by the understanding that adaptivity
based on AI methods is realized in cyber physical systems
(CPS) which inner workings are firmly rooted on information
flows and that these flows adhere to different rules than
functional flows within the domain of control engineering. We
see that this difference manifests primarily in variances w.r.t.
two principles: locality and timeliness. We elaborate this in the
next section before we present how simulation techniques as
described above or other methods may be used to bridge the
corresponding disconnect between AI and control engineering.
A. Variances in Locality and Timeliness
The scope of a cause-effect relationship is typically well
understood in control engineering for functional flows, defined
either via (signal) interfaces or physical effects. In principle,
they are immediate in the sense that functional flows are not
mediated by independent systems or effects (Fig. 6 a). Shutting
down the lights within a room after detecting that the room is
empty is such a functional flow. It is local within a well defined
scope (one specific room) and timely (even with delays within
the realization or an execution of the actuation that depends on
unreliable communication channels). This notion of timeliness
and locality is usually echoed in design principles like message
passing, but also in the expectation of determinism.

The unintended merging effects that our experiments and

simulations show within our adaptive SoS setup result from the
fact that the scope of DR is different: it responds to global data
coming from an environment that has its own dynamics (which
in itself is not an issue) based on calculations that are timed in
its own internal rhythm and that take both global and local data
into account. The latter breaks the locality of cause-and-effect:
in situations with a tight energy budget we observe that a local
cause like people entering or leaving a room changes global
decisions (as an energy budget is required or released) which in
turn sets new local control parameters that effect local changes,
in this case light levels in various rooms. The timeliness in the
sense of an immediate effect is also broken. In fact, both local
and global dynamics are not even ensured to trigger an effect if
their timing is just right (or wrong), e.g., if a demand to save
energy indicated by price is fulfilled by people leaving rooms.
DR and other adaptive behaviors can transgress local and
timely scopes as they are based on information flows and not
on functional flows. Especially CPS including data warehouse
infrastructures and functionalities illustrate this difference, as
they disconnect observations about the system or environment
like sensor measurements from the mechanisms of making and
actuating decisions. We illustrate this in Fig. 6 b. Both an
understanding of a broken locality or timeliness and of a move
between functional flows and information flows may be
exploited to safeguard against unintended emerging effects
during the engineering of smart, adaptive SoS.
B. Transgression Detection using Simulations
An in-context simulation as laid out in Section III is usable
to explore the boundaries of effects. To do this, we propose to
start with simulation models or data sources that detail all
dynamic processes that impact behavior of a SoS. We then
attach the responding functional flows to these processes and,
using simulation or other suitable means, capture the dynamics
of the outcome of those. Next, we investigate if the resulting
tree-like structures merge into a system variable that is used to
control behavior, like a limited resource, as this indicates that
the principle of local cause-effect will not hold. Finding such
connections then triggers an investigation of possible effects by
simulation for the purpose of design validation, but this is the
added value there was no need for an expert to think of a
potential unintended effect in advance. Instead, the existence of
the connection indicated a coupling that warrants attention. In
our example, the sought after connection is the available
budget for energy that is impacted by independent dynamics.

Fig. 6. Locality and timeliness of causal effects in functional flows and in information flows.

We would like to point out that notion carried in the focus

on the impact of dynamics is key to this approach. It is, e.g., not
significant that a complex functional flow uses inputs with
independent underlying processes as long as their dynamics do
not become linked. Simulation techniques like DES allow us to
track the range of effects, thus determining their local area, and
look for transgression and thus potential emergence in overlap
areas based on an analysis of behavior over time.
C. Functional Flows versus Information Flows
The approach described in the previous section is based on
the availability of historical data and / or simulation models. It
thus assumes so-called white box, a.k.a. glass box, knowledge
for at least parts of the SoS and grey box knowledge otherwise.
Given that we are discussing engineering tasks, this is a fair
assumption, but SoSE, especially with regard to CPS, needs to
cope with more limited access to the inner workings of the
involved systems as well, as this will often be the case. It is an
open research question for us how to safeguard the engineering
of smart, adaptive behavior against unintended emergence
under such limitations. Nonetheless, we would like to discuss
an initial approach, which we infer from the observed delta
between information flows and functional flows that we
perceive at the heart of the illustrated disconnect between AI
and control engineering.
Functional flows are characteristically seen as forward
directed push/pull mechanisms: a measurement is taken or a
function computed and the output is send onward, either
routinely or on request [12]. Information flows offer different
mechanisms as well, e.g., publish-subscribe [13] within data
distribution services. Complex SoS behavior is often realized
with a combination of mechanisms of different types, as we,
e.g., illustrated for maritime awareness systems in [14]. As we
illustrate in the latter work, buffers like short term memories
provide the necessary means to connect the different flow
mechanisms technically and semantically. We believe that such
connection points which realize the hand-over between flows
of different nature are an alternate entry point in our endeavor
to bridge between AI and control engineering. We propose to
investigate the effects of the possible states of such connections
between flows in conjunction with the happenstances that may
lead to them, thus running an analysis that literally bridges the
disconnect. From the point of computer science methodologies,
this proposed approach requires both predictive reasoning or
simulation and diagnostic reasoning or learning from data in a
joint calculation to ensure the stated in conjunction. Recently
developed probabilistic programming systems [15] like Figaro
[16] offer this and might therefore allow us to discover which
behaviors might emerge from possible interactions between
dynamic processes and the introduction of smart behavior.
This, however, is future work based on advances in techniques,
where even pioneers like A. Pfeffer, the author of [16], claim
that the possibilities are not yet explored.
V. FROM ACADEMIA TO APPLICATION AND BACK
Academia, with the advances in AI, rose to the challenge of
building a brave new world with smart, adaptive systems that
are, in fact, cyber physical SoS. However, we illustrated that
proposed solutions often make assumptions that do not hold,

e.g., that effects of decisions and system dynamics do not

interfere or ripple beyond their intended scope and thus create
unintended effects. A reason for this lack of understanding for
complex interactions between systems in a SoS and between
the data-driven parts of a CPS and its physical manifestation
may be found in the focus and approach of computer science
investigations of adaptivity, as it centers on algorithms. At the
same time, the application experts are ill equipped to handle the
contributions of AI, as information processing adheres to roles
very different from control engineering, e.g., by transgressing
principles of locality and timeliness of cause-effect relations.
We hope that the needed meeting of minds on this happens
more strongly in the future. Our own work is suited to identify
system-level effects that emerge from the gap between the
disciplines. However, this is just a first step and we must retake the journey from academia to application and back.
ACKNOWLEDGMENT
We thank our peers from Philips R&D, especially Sjir van
Loo, for providing the industrial use case and details on DR.
REFERENCES
[1]

[2]

[3]
[4]
[5]
[6]
[7]
[8]

[9]
[10]

[11]
[12]

[13]
[14]

[15]

[16]

Dutch Green Building Council. (2014). Sustainability certification of the

Edge Available: http://www.breeam.nl/projecten/edge-amsterdam-0
OVG Real Estate. (2015). General information on the Edge. Available:
http://ovgrealestate.com/project-development/the-edge
M. H. Albadi and E. F. El-Saadany, A summary of demand response in
electricity markets, Electr. Power Syst. Res., vol. 78, no. 11, pp. 19891996, 2008.
D. Pesch. Scuba. 2014. Available at: http://www.aws.cit.ie/scuba/
Finn Verner Jensen and T. D. Nielsen, Bayesian networks and decision
graphs, Springer Science & Business Media, 2013.
M. Borth, Probabilistic system summaries for behavior architecting in
Complex Systems Design & Management, Paris, 2014, pp. 347
S. Lesecq et al., Results from the proof of concept evaluation on pilot
site, Scuba deliverable D6.1, available at: [3], 2014.
E. A. Lee, Computation needs time, Communications of the ACM, vol.
52, no. 5, pp. 70-79, 2009.
H. Kopetz, O. Hftberger, B. Frmel, F. Brancati, and A. Bondavalli,
Towards an understanding of emergence in systems-of-systems, in
System of Systems Engineering Conference, San Antonio, TX, 2015, pp.
214-219
G. Behrmann et al. Uppaal 4.0, Proceedings of the 3rd International
Conference on the Quantitative Evaluation of Systems, IEEE CS, 2006.
New York Independent System Operator. Markets and Operations:
Pricing Data. 2016. Available at: http://www.nyiso.com/public/
markets_operations/market_data/ pricing_data/index.jsp
G.S. Fishman, Discrete-event simulation modeling, programming and
analysis, Spinger-Verlag New York, 2001.
Y. Zhao, A model of computation with push and pull processing,
Technical Memorandum UCB/ERL M03/51, University of California,
Berkeley, CA 94720, December 16, 2003.
G. Pardo-Castellote, OMG data distribution service: real-time
publish/subscribe becomes a standard, RTC Magazine, January 2005.
M. Borth, On the architecture of systems for situation awareness, in
Situation Awareness with Systems of Systems, Spinger-Verlag New
York, 2013, pp 39-53
A. D. Gordon, T. A. Henzinger, A. V. Nori, and S. K. Rajamani,
Probabilistic programming, in Future of Software Engineering at Int.
Conference on Software Engineering, Hyderabad, 2014, pp. 167-181
A. Pfeffer, Figaro: An object-oriented probabilistic programming
language, Charles River Analytics Technical Report 137, 2009.