Detecting Emergent Interference in Integration of Multiple
Self-Adaptive Systems
Somayeh Malakuti
Software Technology Group
Technische Universität Dresden, Germany
somayeh.malakuti@tu-dresden.de
ABSTRACT
A system of systems (SoS) is a large-scale concurrent and
distributed system whose components are complex systems.
An example of SoS is in the domain of self-adaptive sys-
tems, where multiple self-adaptive systems must be inte-
grated with each other. As for any other kind of SoS, we
face the following question: is there any emergent interfer-
ence as the result of such integration, which prevents the
constituent self-adaptive systems to achieve their goals? Due
to the inherent complexity of an SoS, it is not easy to de-
tect emergent interference manually, if possible at all. We
study the suitability of formal modeling and verification for
detecting emergent interference in an example of SoS, i.e. in-
tegration of multiple self-adaptive systems. Model checking
reveals that although constituent systems behave correctly
when executed individually, they fail to provide correct be-
havior in an SoS context due to unforeseen interference that
emerges.
Categories and Subject Descriptors
D.2.4 [Software/Program verification]: Formal Meth-
ods, Model Checking
Keywords
emergent behavior, systems of systems, self-adaptive sys-
tems, model checking, UPPAAL
1. INTRODUCTION
Self-adaptive systems are characterized by their ability to
adapt according to changes in their environment. Usually, a
self-adaptive system (SAS) comprises two main parts: man-
aged subsystem and managing subsystem. The former is the
subsystem that is the target of self adaptation; the latter is
∗
The work is supported by the German Research Foundation
(DFG) in the Collaborative Research Center 912 ”Highly
Adaptive Energy-Efficient Computing”.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
ECSAW August 25 - 29, 2014, Vienna, Austria.
Copyright 2014 ACM 978-1-4503-2778-7/14/08
http://dx.doi.org/10.1145/2642803.2642826 ...$15.00.
∗
the subsystem implementing the self-adaptation functional-
ity [20].
A novel application of self adaptation is in the domain of
green computing. Within the context of the HAEC (Highly
Adaptive Energy-efficient Computing) project1 , different re-
search teams are investigating various kinds of SAS at differ-
ent layers such as operating systems, database management
systems, application software and virtual machines [9]. The
common goal of these SAS’s is to improve the energy-utility
of the system: the system must serve the requests of users
in an energy efficient way while fulfilling the desired utility
objectives of the users.
Where each SAS autonomously improves the energy-utility
of the system, the final goal of the HAEC project is to in-
tegrate these SAS’s as one system, such that the overall
energy-utility is optimized via the joint behavior of these
SAS’s.
During past years, there has been an increasing atten-
tion toward engineering systems of systems in various do-
mains. A system of systems (SoS) is a large-scale concur-
rent and distributed system whose components are complex
systems [15, 14]. The constituent systems are operationally
and managerially independent, evolve in due time, and their
interactions expose emergent properties [11, 13].
Integrating multiple SAS’s, which are developed and man-
aged independently, is a novel example of SoS. As for any
other kind of SoS, we face the following question: ”is there
any emergent interference as the result of such integration,
which may negatively influence the overall energy-utility of
the system?”
Detecting emergent interference among multiple SAS’s re-
quires extensive knowledge about the behavior of each indi-
vidual SAS, the parts of the system that it adapts, and the
impacts of such adaptations on other SAS’s. This implies
that manual detection of emergent interference can easily be-
come an error-prone and time-consuming task in large-scale
projects, which may be carried out in an ad-hoc manner.
Therefore, we claim that suitable methodological and tool
support must be provided to software engineers for this mat-
ter. Formal modeling and verification can be regarded a
suitable candidate. As it has been studied in the literature,
although formal methods can play a significant role in the
verification of SAS’s, the use of formal methods in SAS is
still very limited [19]. Especially, the use of formal methods
in detecting emergent interference among multiple SAS’s is
not widely studied.
In this paper, we report on our current work in adopting
1
http://www.tu-dresden.de/sfb912
formal modeling and model checking to identify emergent
interference among multiple SAS’s, which negatively influ-
ence the behavior of individual SAS’s. We make use of two
SAS’s, which perform adaptation at the level of applica-
tions and virtual machines (VM), as illustrative examples.
We adopt the UPPAAL model checker to model each sys-
tem as timed automata, and to model the integration of the
systems.
In our approach, each SAS is modeled separately, and is
verified to ensure its correct behavior when executed indi-
vidually. The models of individual SAS’s are integrated with
each other to form the target SoS. The properties of each in-
dividual SAS is verified on the target SoS. If the properties
do not hold, there might be emergent interference among
multiple SAS’s. The description of the emergent interfer-
ence can be extracted from the diagnosis trace provided by
the model checker.
The rest of this paper is organized as follows. Section 2
provides background information about the illustrative ex-
amples and the UPPAAL model checker. Section 3 explains
our approach for modeling and verifying SAS’s; section 4
explains our approach for integrating multiple SAS’s as one Figure 1: The application-level and VM-level SAS’s
SoS and for detecting emergent interference in the target
SoS. Section 5 discusses the related work, and section 6 pro-
vides conclusion and outlines our future work. functionality.

2. BACKGROUND 2.2 UPPAAL

2.1 Illustrative Examples
Within the context of the HAEC project, we aim at pro-
viding multiple SAS’s that operate at different layers to im-
prove the energy-utility of the system. As shown in Figure 1,
we focus on two SAS’s, which operate at the level of virtual
machines (VM) [8] and applications [12] with the objectives
of reducing response time and energy consumption. We as-
sume that there is an application that receives video files
along with the requests to transcode videos, and performs
the transcoding.
The VM-level SAS aims at balancing the load between
multiple servers by an intelligent distribution of virtual ma-
chines. To this aim, it frequently checks the load of a server,
and if it detects that a server is underutilized, it tries to mi-
grate the VMs running on the server to another server that
can accommodate these VMs, and turns off the underuti-
lized server.
The application-level SAS and the application are execut-
ing in a VM. The application-level SAS assumes that there
are multiple implementations of an application, which offer
the same functionality but with different quality of service
such as performance and resolution of the transcoded video.
Depending on the offered quality of service, these imple-
mentations require different amount of resources (e.g. CPU
frequency, network bandwidth, RAM) to perform their func-
tionality.
The application-level SAS assumes that each request to
transcode a video is augmented with user’s desired qual-
ity of service. Whenever a request is issued by a user, the
application-level SAS tries to select an implementation of
the application, which can fulfill user’s desired quality of
service based on the resources that are currently available
in the server. If it cannot find any implementation, it per-
forms graceful degradation by selecting an implementation
that requires least amount of resources by providing reduced
Model-checking is a technique for verifying a given model
with respect to formally expressed properties of the model.
UPPAAL is a toolset that facilitates formal modeling, sim-
ulation and model checking of behavioral properties [1]. In
UPPAAL, a system is modeled as a network of timed au-
tomata, called processes. A timed automaton is a finite-
state machine extended with clocks. A clock is a variable
which evaluates to a real number, and whose value increases
at the same rate as time.
A process is an instance of a parameterized template. A
template can have local declared variables, functions, and
labeled locations. Processes communicate with each other
through channels. The sender c! synchronizes with the
receiver c? through a state transition.
In UPPAAL, the state of the system is defined by locations
of the automata, clocks, and variables values. UPPAAL uses
a subset of TCTL for defining properties to be verified. The
query language consists of state formulae and path formulae.
3. MODELING SELF-ADAPTIVE SYSTEMS
Detecting emergent interference among multiple SAS’s re-
quires extensive knowledge about the behavior of each SAS,
the parts of the system that it adapts, and the impacts
of such adaptations on other SAS’s. As these systems are
subject to frequent evolution demands, manual detection of
emergent interference can easily become an error-prone and
time-consuming task in large-scale projects, which may be
carried out in an ad-hoc manner.
Therefore, suitable methodological and tool support must
be provided to software engineers for this matter. Formal
modeling and verification, for example via model checking,
can be regarded as suitable means for this matter; via model
checking it is possible to generate the state space for individ-
ual behavior of each SAS, as well as the integrated behavior
of multiple SAS’s.
Before reasoning whether there is any undesired emergent
interference due to the integration of multiple SAS’s, we
must ensure that each SAS has a correct behavior when ex-
ecuted individually. For this matter, we first model each
SAS, define its properties, and verify that specified proper-
ties hold in the models. In the following, we illustrate these
steps in UPPAAL for our illustrative examples.
Figure 2 summarizes the list of variables that are defined
in UPPAAL for our illustrative example. The methodology
that we adopt is explained below by means of our illustrative
example.
Figure 2: The set of UPPAAL variables
3.1 Modeling the execution environment
There may be emergent interference among multiple SAS’s
because they are operating in one common environment, and
may utilize and influence a common set of resources. There-
fore, as an initial step, we model the environment in which
SAS’s will be executed as well as the possible changes that
are supported by the environment.
For our example, we assume that there are two servers;
one supports the CPU frequency of 2GHz and the network
bandwidth of 100MB/s, the other supports the CPU fre-
quency of 1GHz and the network bandwidth of 10MB/s.
Figure 3 represents the model of servers as a parametric
template in UPPAAL; s id is the model parameter, which
represents the unique identifier of a sever. In the location
Start, the requests to turn on a server are received via the
channel synchronization turn on[s id]?. If the server is al-
ready on, on == 1, the request will be ignored. Otherwise,
a transition takes place to the location Turning On. This is
followed by a request to turn on the corresponding CPU via
the channel CPU on[s id]!. The desired value for the CPU
frequency is determined by the function getFrequency.
Likewise, there will be a request to turn on the network
card via the channel synchronization NIC on[s id]!. After-
wards, there will be a transition to the location Turned on,
in which it is informed that the server is successfully turned
on via the channel synchronization turned on[s id]!. The re-
quests to turning off a server are modeled in a similar way.
Figure 4 represents the model of CPU for each server. We
consider three main operational states for CPU, i.e. Off, On
and Changing. The transitions between Off and On takes
place via the requests CPU on[s id]? and CPU off[s id]?.
When the CPU is on, its frequency may change. This is
modeled via CPU frequency change[s id]?, which results in
changing the variable cpu frequency with the new value. The
application of the requested change is announced via the
channel synchronization CPU frequency changed[s id]!.
CPU_frequency_changed[s_id]!
CPU_frequency_change[s_id]?
CPU_on[s_id]?
cpu_frequency = new_cpu_frequency
On
Changing
CPU_off[s_id]?
cpu_frequency = 0
CPU_on[s_id]? Off
cpu_frequency = new_cpu_frequency
Figure 4: A model of CPUs
Likewise, Figure 5 represents the model of network card,
and the requests to change the network bandwidth.
BW_changed[s_id]!
NIC_on[s_id]? BW_change[s_id]?
bw = new_bw
On
Changing
NIC_off[s_id]?
bw = 0
NIC_on[s_id]?
bw = new_bw Off
Figure 5: A model of network interface cards
3.2 Modeling SAS’s
Separate models must be provided for each SAS to repre-
sent the fact that the SAS’s are developed separately. Fig-
ure 6 represents a model of for the application-level SAS.
Here, a request to transcode a video on the current server
is received via the channel receive request[current server]?,
and the information about the request is updated in the
variable request.
The current CPU frequency and network bandwidth of
current server are stored in the variables cur cpu and cur bw
to be used for selecting the best configuration of the applica-
tion that can be executed in the current setting. If there is
no such a configuration, graceful degradation is performed,
in which the implementation that requires least amount of
resources is selected. We assume that this implementation
requires the minimum CPU frequency of 1 GHz and network
bandwidth of 10 MB/s, where the other implementations re-
quire the minimum CPU frequency of 2 GHz and network
bandwidth of 100 MB/s.
After selecting and applying the selected configuration,
the request is being served by the application in the location
Serving Request. A time-consuming computation for serving
the request is modeled via the invariant clk <= 30 over
 turned_on[s_id]!
Turned_On
on = 1
NIC_on[s_id]!
new_bw = getBandwidth(s_id)
CPU_on[s_id]!
turn_on[s_id]? new_cpu_frequency = getFrequency(s_id)
turn_on[s_id]? on == 0 Turning_On
on == 1
on == 0 turn_off[s_id]? CPU_off[s_id]! NIC_off[s_id]!
on == 1
Start Turned_Off
Turning_Off
turn_off[s_id]?
turned_off[s_id]!
on = 0

Figure 3: A model of servers

Start

receive_request[current_server]?
request = getRequestInfo()

request != VALIDREQUEST
request == VALIDREQUEST
cur_cpu = getCurrentCPU(),
cur_bw = getCurrentBW(),
clk = 0
Finding_Configuration
clk <= 20
config = getConfig(),
clk = 0
config == -1 config != -1
req_cpu_frequency = 1, req_cpu_frequency = 2,
Gracefully_Degrade req_bw = 10 req_bw = 100 Applying_Configuration
clk <= 10 clk <= 20

Configuration_Ready
clk = 0

Serving_Request
request_served[current_server]! clk <= 30

Figure 6: A model of the application-level SAS

the clock variable clk. When the request is served, it is
announced via request served[current server]!.
Figure 7 represents a model of the VM-level SAS. As soon
as the VM-level SAS starts executing, it constantly checks
the load of current server, to detect whether the server is
underutilized. If the load is below MINLOAD, it finds a
new server, and starts migrating the VMs to the new server.
Afterwards, it turns off the current server.
3.3 Modeling the runtime scenarios
To be able to simulate and/or verify the behavior of SAS’s,
we require to model the actual usage scenarios for the SAS’s.
Figure 8 represents an example model that we provide for
our illustrative example.
Here, two servers are turned on, and the request to start
the VM-level SAS is issued via start!. Afterwards, five re-
quests are issued to the application-level SAS, which are
served sequentially. These requests are modeled via the
channel synchronizations receive request[current server]! re-
quest served[current server]?.
3.4 Verifying SAS’s
To ensure that each SAS has a correct behavior when ex-
ecuted individually, we define the following set of properties
for each SAS and verify them on the corresponding models.
E<> (ApplicationLevelSAS.request == VALID REQUEST
and ApplicationLevelSAS.Serving Request)
(1)
The property 1 specifies that if there is a valid request from
user, the request will eventually be served by the application.
A[] not (ApplicationLevelSAS.Applying Configuration and
(CPU(current server).cpu frequency < cur cpu
or NIC(current server).bw < cur bw))
(2)
The safety property 2 specifies that it will never be the case
that while configuring the application with a new implemen-
tation, the CPU frequency and network bandwidth goes be-
low the amount being used for selecting the implementation.
 !(load >0 && load <= MINLOAD)

Start start? load = getLoad(current_server)

Checking_Load
load > 0 && load <= MINLOAD

turned_off[tmp]?
Finding_Server
new_server = getNewServer()

new_server != current_server
turn_off[tmp]!
Start_Migrating
tmp = current_server,
End_Migrating current_server = new_server

new_server == current_server

Figure 7: A model of the VM-level SAS

turn_on[1]! turned_on[1]? turn_on[2]! turned_on[2]?

new_cpu_frequency = 2, new_cpu_frequency = 1,
new_bw = 100 new_bw = 10
start!
current_server = 1

receive_request[current_server]!
cnt >= 5
cnt ++ cnt < 5

request_served[current_server]?

Figure 8: A model of runtime scenarios

If this property is violated, the selected implementation is timed automata with each other. The specification of a SoS
not a valid one, because it requires more resources than what that is composed of the application-level and the VM-level
is currently available. SAS’s running in a shared server is shown below:

system
A[] not (ApplicationLevelSAS.Serving Request and CPU, NIC, Server, ApplicationLevelSAS, VMLevelSAS, Run-
(CPU(current server).cpu frequency < req cpu frequency timeScenario;
or NIC(current server).bw < req bw))

(3) We consider that there is emergent interference if the

property ρ holds in a constituent system, say A, but it does
The safety property 3 specifies that it will never be the case not hold in the SoS comprising other constituent systems:
that while serving a request, the CPU frequency and net-
work bandwidth goes below the amount required for serving
the request.
A |= ρ and (A ⊗ B ⊗ . . . ) 6|= ρ

E<> (load >=0 and load <= MINLOAD and (5)

new server ! = current server and
To check for the existence of emergent interference, we ver-
(VMLevelSAS.Start Migrating imply
VMLevelSAS.End Migrating)) ify the properties of each constituent systems in the target
SoS. For our running example, the verification revealed that
(4) the properties 2 and 3 do not hold in the SoS. This indicates
that there might be some emergent interference between the
The property 4 specifies that if a server is underutilized,
application-level and the VM-level SAS’s that prevents the
and if a new server is found to migrate the VMs to, the
application-level SAS to fulfill its specified properties.
migration will take place.
If a property does not hold in the models, UPPAAL re-
turns a diagnosis trace. Each trace represents a set of state-
4. DETECTING INTERFERENCE transitions in each automata, which caused the violation of
To be able to detect emergent interference, we first need the specified property. The diagnosis traces can be adopted
to integrate multiple SAS’s and form an SoS. UPPAAL fa- as the source for identifying the emergent interference in the
cilitates defining an SoS via integrating multiple concurrent SoS.
 The analysis of the diagnosis traces for the properties 2
and 3 let us identify the following emergent interference in
integration of the application-level and the VM-level SAS’s.
• Emergent interference (1): If the VM-level SAS
migrates a VM while application-level SAS is selecting
an implementation of the application, there may be a
case that the available resources in the new server is
below the amount of resources that the application-
level SAS is considering for selecting the best imple-
mentation. Therefore, the implementation that will
be selected by the application-level SAS may not be a
valid choice for the new server.
• Emergent interference (2): If the VM-level SAS
migrates a VM while a selected implementation is serv-
ing a request, there may be a case that the available
resources in the new server is below the amount of re-
sources that is required by the implementation.
These two have the following negative impacts on the over-
all energy-utility of the SoS. First, if the application-level
SAS continues selecting an implementation, which requires
more resources than what is available in the new server, the
selected implementation will take more time and power to
execute. Second, if the process of selecting an implemen-
tation is restarted so that the new server can be taken into
account, this repetition will also increase the overall response
time and power consumption of the system.
5. RELATED WORK
Nowadays, it is becoming more popular to adopt formal
methods in the development of SAS’s. However, the major
use of formal methods has been for the purpose of specify-
ing and reasoning about the design of an SAS [19]. There
have been various attempts to adopt formal methods for the
verification of SAS’s [21, 3, 5, 4]; however, these approaches
are limited to one SAS, and mainly focus on ensuring cer-
tain properties of the SAS such as safety and consistency.
In contrary to these approaches, we studied the inevitable
benefit of formal methods to detect emergent interference
among multiple SAS’s.
Various model-based frameworks have been introduced to
uniformly model SAS’s and validate various properties of the
models [2, 17]. Where adopting uniform models to describe
multiple SAS’s can be beneficial, it has two shortcomings.
First, such frameworks may not be expressive enough to
support various kinds of SAS that perform adaptation at
different levels of granularity such as applications and VMs.
Second, by definition, each constituent system of an SoS is
developed and managed independently by different teams.
Each team usually have different expertise and preferences
in the technologies that they adopt for implementing their
system, which negates the idea of adopting a uniform model-
based framework.
Detecting emergent behavior is being studied in the design
and implementation of SoS. In [18], a grammar-based set-
theoretic approach to formalize and verify the existence and
extent of emergence without prior knowledge or definition of
emergent properties. Kubik [16] proposed a method for for-
malizing emergence without prior knowledge of emergence.
The approach adopts a set-based view on the world, where
emergence is seen as the difference between a calculated and
an observed behavior. Another approach to identify emer-
gence proposes to look at a measure of the interaction be-
tween agents in an agent-based model [6]. The interaction
metric is an agent-specific counter that increases as the agent
interacts with other agents in the environment. Emergence
is said to appear if the interaction measure deviates from
normality. This approach provides a straightforward mea-
sure of emergence.
These approaches consider the constituent systems of an
SoS to be represented as agents. This is a limiting factor to
apply these approaches to the systems that are not defined
as agents, such as our illustrative application-level and VM-
level SAS’s. On one hand, our proposed approach is more
generic, and assumes that the constituent systems can be
any kind of system whose behavior is modeled as a set of
automata. On the other hand, our approach only focuses on
one special case of emergent behavior, i.e. interference.
The existing methods to detect emergent behavior can
be classified into three categories [18]: variable-based [10],
event-based [7], and grammar-based methods [16]. In the
variable-based methods, a set of variables are chosen to rep-
resent emergence. In the event-based methods, the behavior
of constituent systems are defined as a set of events; emer-
gent behavior is defined as a complex event that can be re-
duced to a sequence of simpler events. In the variable-based
and event-based methods, a priori definition of variables,
event types and emergence is required. To overcome the
problem of a prior definition of emergence, in the grammar-
based methods, an extended cooperating array grammar sys-
tem is used to formalize the environment, agents and the
corporations among the agents.
Adopting formal modeling and model checking to detect
emergent behavior can be regarded as a combination of the
variable-based and event-based methods. Here, the behav-
ior of each constituent system is modeled as an event-based
automaton, and the states of each automaton is represented
via a set of variables. A specific global state of the sys-
tem, which is automatically detected by a model checker, is
regarded as emergent behavior.
6. CONCLUSION AND FUTURE WORK
Design and implementation of SoS are being studied in
various domains. A novel example of such systems is in the
area of self-adaptive systems, where the constituent systems
are self-adaptive. The integration of these systems as one
SoS may lead to various emergent interference, which pre-
vents these constituent systems fulfill their goals.
Suitable methodological and tool support must be pro-
vided to software engineers to detect such emergent inter-
ference among multiple SAS’s. In this paper, we illustrated
the suitability of formal modeling and verification for this
matter.
The major issue in detecting emergent interference is the
abstraction level in which each constituent system and the
final SoS are represented. Coarse-grained architectural mod-
els may be regarded more suitable for this matter; otherwise,
state-space explosion may be experienced due to large num-
ber of automata and their states. As future work, we would
like to investigate more on the granularity of the models that
must be adopted for detecting emergent interference.
To cope with emergent interference, it is necessary to
break the autonomic behavior of each constituent SAS, and
provide means to coordinate their interactions. As future
work, we would like to study suitable coordination proto- Proceedings of the 2007 Spring Simulation
cols for the application-level and VM-level SAS’s, and verify Multiconference - Volume 2 (2007), Society for
their correctness using model checking. Computer Simulation International.
In the literature, four categories of emergent behavior are [14] Jamshidi, M. System of Systems Engineering:
distinguished [13]: a) expected and desirable emergent be- Innovations for the Twenty-First Century. Wiley,
havior, which is the reason for building a system of systems; 2008.
b) expected and undesirable negative emergent behavior, [15] Jamshidi, M. Systems of Systems Engineering:
which is a consequence of the design, the environment or Principles and Applications. CRC Press, 2008.
the operational conditions of a system of systems; c) unex- [16] Kubı́k, A. Toward a Formalization of Emergence.
pected and (however, quite rarely) desirable behaviour; and Artif. Life 9, 1 (Dec. 2002), 41–65.
d) unexpected and undesirable emergent behavior, which is [17] Luckey, M., and Engels, G. High-quality
one of the critical risks of most systems of systems. In this Specification of Self-adaptive Software Systems. In
paper, we only focused on adopting model checking for de- SEAMS ’13 (2013).
tecting unexpected and undesirable emergent behavior (i.e.
[18] Teo, Y. M., Luong, B. L., and Szabo, C.
interference). In future, we would like to extend our study
Formalization of Emergence in Multi-agent Systems.
to other kinds of emergent behavior.
In Proceedings of the ACM SIGSIM Conference on
Principles of Advanced Discrete Simulation (2013),
7. REFERENCES SIGSIM-PADS ’13, ACM.
[1] UPPAAL. http://www.uppaal.org/. [19] Weyns, D., Iftikhar, M. U., de la Iglesia, D. G.,
and Ahmad, T. A Survey of Formal Methods in
[2] Adler, R., Schaefer, I., Schuele, T., and
Self-adaptive Systems. In Proceedings of the Fifth
VecchiÃl’, E. From Model-Based Design to Formal International C* Conference on Computer Science
Verification of Adaptive Embedded Systems. In and Software Engineering (2012), C3S2E ’12, ACM.
Formal Methods and Software Engineering, vol. 4789
[20] Weyns, D., Malek, S., and Andersson, J.
of Lecture Notes in Computer Science. Springer Berlin
FORMS: A Formal Reference Model for
Heidelberg, 2007.
Self-Adaptation. In ICAC (2010), ACM.
[3] Bartels, B., and Kleine, M. A CSP-based
[21] Zhang, J., Goldsby, H. J., and Cheng, B. H.
Framework for the Specification, Verification, and
Modular Verification of Dynamically Adaptive
Implementation of Adaptive Systems. In Proceedings
Systems. In Proceedings of AOSD ’9 (2009), ACM.
of SEAMS ’11 (2011), ACM.
[4] Becker, B., Beyer, D., Giese, H., Klein, F., and
Schilling, D. Symbolic Invariant Verification for
Systems with Dynamic Structural Adaptation. In
Proceedings of ICSE’ 06 (2006), ACM.
[5] Bucchiarone, A., Pelliccione, P., Vattani, C.,
and Runge, O. Self-Repairing Systems Modeling and
Verification using AGG. In Proceedings of
WICSA/ECSA 2009 (2009).
[6] Chan, W. K. V. Interaction Metric of Emergent
Behaviors in Agent-based Simulation. In Proceedings
of the Winter Simulation Conference (2011), WSC
’11, Winter Simulation Conference.
[7] Chen, C.-C. Complex Event Types for Agent-based
Simulation. Phd thesis, University College London,
2009.
[8] Dargie, W., and Wen, J. Power-Latency Trade-offs
in Virtualized Environments. In Proceedings of FINA
’14 (2014), IEEE.
[9] Fettweis, G., Nagel, W., and Lehner, W.
Pathways to Servers of the Future. In Proceedings
DATE 2012 (March 2012).
[10] Fisch, D., JaÌĹnicke, M., Sick, B., and
MuÌĹller-Schloer, C. Quantitative Emergence – A
Refined Approach Based on Divergence Measures. In
SASO ’10 (Sept 2010), pp. 94–103.
[11] Fromm, J. Types and Forms of Emergence.
[12] Götz, S., Wilke, C., Cech, S., and Aßmann, U.
Sustainable ICTs and Management Systems for Green
Computing. 2012, ch. Architecture and Mechanisms
for Energy Auto Tuning, pp. 45–73.
[13] Holland, O. T. Taxonomy for the Modeling and
Simulation of Emergent Behavior Systems. In