Fig. 1: Event triggered Monitor template
A Monitor behavior collects information from the managed system and possibly
the environment to update the Knowledge of the feedback loop. Before updating
the Knowledge, the Monitor behavior may preprocess the collected data.
Examples of preprocessing are standardization of data, filtering, data aggregation,
We provide Monitor behaviors both with event (top) and
time triggering (bottom).
Monitor resides in the Waiting state until it is triggered to act.
An event triggered Monitor is activated by a probe (either from the managed system or
via the Monitor[Node ID]? signal. A time triggered Monitor periodically
(t==Period) activates a probe via
monitor(). If necessary, the new
collected data is
preprocessed (if isPreprocessingRequired() then
Then the Knowledge is updated (updateKnowledge()).
Finally, the Analyze behavior is notified about the update
(Analyze[Node ID]! from the NewChange state).
This latter triggering is optional, as the Analyze behavior may use time triggering.
Fig. 2: Time triggered Monitor template
Fig. 3: Event triggered Analyze template
The Analyze behavior is responsible to determine whether adaptation actions
are required. To that end, the Analyze behavior matches the required resources
with the resources in use, taking into account the current context and working
data. Analysis can result in three primary conclusions. The current situation is
when the managed system possesses the resources it requires to realize its goals. The
situation is Undersatisfied when the system lacks resources, and
Oversatisfied when the system has redundant resources.
We provide behavior templates for an analyze
behavior with event triggering (Analyze[Node ID]?) and time triggering
To perform analysis, the Analysis behavior collects the required knowledge (getRequired(),
and getContext(), getWorking-Data())
and then matches resources (matchResources()).
of the analysis are then communicated to the Plan behavior
(Plan OverSatisfied[Node ID]!,Plan Satisfied[Node ID]!,
Plan UnSatisfied[Node ID]!). Analysis interacts with Plan through signals, but this is optional.
Fig. 4: Time triggered Analyze template
Fig. 5: Event triggered Plan template
The Plan behavior is responsible for planning mitigation actions when needed to
bring the managed system in a desired state (i.e. Satisfied).
There are two cases that require planning: either there is a need to add resources (i.e., the system state is in an unsatisfied situation),
or resources may be released (when the system is in an oversatisfied state).
We present two reusable templates for a Plan behavior.
With time triggering, the planner periodically checks what it needs to do
(x==planToDo() condition), and creates an appropriate plan
when needed (ReleaseResource or AddResource).
Planning the release of resources is specified in the left part of the figures of the Plan behavior
(releaseResource(dispensible_resource)). In case, a resource is
ready for release, a plan is generated, added to Knowledge and Execute is informed.
In case no resource is ready for release, Plan periodically re-checks.
Planning can be interrupted if conditions change and adaptation is no longer required
(satisfied == planToDo() or
add == planToDo()).
Planning the addition of resources is specified in the right part of the figure
findResource(). If Plan finds a suitable
resource (found_resource != NONE) it generates a plan,
adds it to the Knowledge, and communicates with Execute. Otherwise, Plan rechecks periodically
to see whether a resource is available. As for releasing resources, planning the addition of
a resource can be interrupted when adaptation is no longer required.
Fig. 6: Time triggered Plan template
Fig. 7: Event triggered Execute template
The Execute behavior is responsible of executing adaptation plans.
Plans an contain multiple actions to be invoked to the managed system.
We provide two reusable templates for the Execute behavior, respective with time and event triggering.
The left part of the figures with the templates specify the execution of plans to release resources.
Actions are only executed when the managed system is ready for it
Actions are executed sequentially by invoking an effector (
invokeNextAction()). When the complete plan is executed, the behavior
returns to wait for the next plan to be executed (PlanCompleted).
Fig. 8: Time triggered Execute template
Adaptation Goal Specification Property
The adaptation goal specification property allows to verify when the self-adaptative
system requires adaptation, eventually the adaptation will be realized by the
P1: Analyze(X).Unsatisfied --> Analyze(X).Satisfied || Analyze(X).Oversatisfied
P1 defines when an Analyse behavior at node X detects that the managed system is
in an unsatisfied state, the MAPE behaviors will eventually adapt the managed system
bringing it in the satisfied or oversatisfied state. Property P1 is based on the assumption
that eventually resources will become available to realize the adaptation goal.
Intra-Behavior Specification Properties
Intra-behavior properties allow verification of properties of individual MAPE behaviors,
independently of the other MAPE behaviors.
P2: ConcernKnowledge[X].required_resources > ManagedSystemKnowledge[X].used_resources
P2 defines that when resources used by the managed system are insufficient according
the requirements of the Knowledge, the Analyze behavior will eventually detect this
unsatisfied situation. The greater than symbol is an abstract operator to check whether
the used resources satisfy the required resources, and needs to be instantiated for the
domain at hand. Intra-process property verification becomes particularly interesting for
complex behaviors. E.g., it is important to verify that the Plan creates adequate plans on
how the managed system should be adapted. P3 and P4 are two specification properties
for a Plan behavior that allow to verify whether adding (P3) and releasing a resource
(P4) from the managed system leads to a Satisfied state. P5 and P6 specify properties
for an Execute behavior that allow to verify whether the plan for adding a resource (P5)
and releasing a resource (P6) from the managed system are properly executed.
P3: Plan(X).AddResource --> Plan(X).Satisfied
P4: Plan(X).ReleaseResource --> Plan(X).Satisfied
P5: Execute(X).ExecuteAdd --> Execute(X).PlanCompleted
P6: Execute(X).ExecuteRelease --> Execute(X).PlanCompleted
Inter-Behavior Specification Properties
Inter-behavior properties allow verification of properties about the interaction between
multiple behaviors of a MAPE-K loop.
P7: Analyze(X).Unsatisfied --> Plan(X).AddResource
P7 describes a property to verify the correct collaboration between the Analyze
and Plan behaviors. The property states that when Analyze detects an unsatisfactory
state of the managed system, eventually the Plan behavior will starts planning to find a
resource. P8 and P9 describe properties to verify the correct collaboration between Plan
and Execute behaviors. In particular, P8 allows to verify that when Plan has generated a
plan to release a resource, this plan is eventually executed by the Execute
P8: Plan(X).ReleasePlanReady --> Execute(X).ExecuteRelease
P9: Plan(X).AddPlanReady --> Execute(X).ExecuteAdd
Last update: November 2, 2013 - feedback