Autonomic Aspects of IoT Based Systems: A Logistics Domain Scheduling Example - Interoperability and Open-Source Solutions for the Internet of Things - page 152

- Analysis: The analysis function is responsible for processing the information
captured by the monitoring component and for generating high level events.
For instance, it may combine the values of calls on a service and memory
utilization to signal an overload condition in the platform.
- Planning: The planning component is responsible for selecting the actions that
need to be applied in order to correct some deviation from the desired oper-
ational envelope. The planning component relies on a high level policy that
describes an adaptation plan for the system. These policies may be described,
for example, using Event Condition Action (ECA) rules that are defined by
a high level language. An ECA rule describes for a specific event and a given
condition what action should be executed. In the context of IoT, the actions
may affect the usage of virtualized things and the bindings among these ones
in terms of use.
- Execution: The execution component applies the actions selected by the plan-
ning component to the target components.
Additionally, the shared knowledge includes information to support the
remaining components. In the context of logistics, it maintains information about
managed elements both related to transport infrastructure and relevant goods.
2.1 Where and How Was Used
When systems are large, complex, and heterogeneous (the case of logistics fits in
this category), a single MAPE loop may not be su cient for managing adapta-
tion. In such cases, multiple MAPE loops may be employed that manage parts of
the system. In self-adaptive systems with multiple MAPE loops, the functions for
monitoring, analyzing, planning and executing may be made by multiple compo-
nents that coordinate with one another. Various patterns of interacting control
loops have been used in practice by centralizing and decentralizing the func-
tions of self-adaption in multiple ways. For example, in the Rainbow framework
monitoring and execution are delegated to the various nodes of the controlled
system, whereas analyzing and planning are centralized. The IBM architectural
blueprint organizes MAPE loops hierarchically, where each level of the hierar-
chy contains instances of all four MAPE components. In this setting, higher
level MAPE loops determine the set values for the subordinate MAPE loops.
In fully decentralized settings, relatively independent MAPE components coor-
dinate with one another and adapt the system when needed. The On Patterns
for Decentralized Control in Self-Adaptive Systems paper presents a selection
of MAPE patterns that model deferent types of interacting MAPE loops with
multiple degrees of decentralization (like Coordinated Control Pattern, Infor-
mation Sharing Pattern, Master/Slave Pattern, Regional Planning Pattern, and
Hierarchical Control Pattern).
The application of the centralized control loop pattern to a large-scale soft-
ware system may suffer from scalability problems. There is a pressing need for
decentralized, but still manageable, effective, and predictable techniques for con-
structing self-adaptive software systems. A major challenge is to accommodate