Fig. 4: Event triggered Monitor template
Two Monitor behaviors are instantiated based on the event triggering approach to separate the logics of
the monitoring roles. A first behavior is in charge of monitoring the current activity requirements.
This behavior is triggered by signals (SAMVDReqChanged[Mid]?) sent by an external node
(an activity server). The knowledge base is updated (updateMVDReq()) upon this message.
This monitoring behavior can be located in the master node, which is in charge of the organization self-adaptation.
The Analyze behavior is expected to be triggered under a time triggering approach, therefore no signaling is required.
A second Monitor behavior is in charge of monitoring the current state of the nodes in the organization.
This behavior is therefore distributed among the nodes in the system (master and slave nodes).
The monitor behavior reacts upon changed applied by a first MAPE-K loop, that can enable/disable the
GPS resource in a mobile device. A probe behavior transfers these changes information to the Monitor
through the removePhone[Pid]? signal. This Monitor behavior, preprocesses this
new information to determine the relevant organization to report
(myMVD = determineMyMVD(Pid)) if any (myMVD != NOGROUP).
Fig. 5: Event triggered Monitor template to gather Activity requirements.
(Signal sent by a Activity Server)
Fig. 6: Event triggered Monitor template to gather organization deployment information.
(Signal sent by first MAPE-K loop)
Fig. 7: Event triggered Analyze template
The Analyze behavior for this MAPE-K loop is responsible to determine whether
an organization requires adaptation actions with respect to the number of
GPS resources in use (usedGPS) in the managed system
and the required GPS resources (requiredGPS)
to carry on with the activity at hand.
Concretely, under a period basis of 5 time-units (t<=5),
the Analyze behavior makes a numeric comparison (matchGPS()) to determine
whether the related organization (MVD) is Redundant,
Complete or Incomplete.
The Analyze behavior (indirectly) communicated with the Plan behavior by updating related knowledge
in the SAKnowledge structure (setPlan()).
Fig. 8: Event triggered Monitor template to gather Activity requirements.
(Signal sent by a Activity Server)
Fig. 9: Time triggered Plan template
The Plan behavior is responsible for creating a mitigation plan. Due to the
characteristics of the mobile learning scenario, Redundant states are not considered
Undesired states. Therefore, the mitigation plans are only
necessary when Incomplete
states are found, and consist on selecting a resource to
be included in the organization. Therefore, only the right side of the generic template
(marked under the Red square) has been used for the Plan instantiation.
Under a period of 2 time units, the Plan checks the need for mitigation actions.
If needed (getPlan() == incomplete), the Plan
looks for an available resource that can be integrated in the organization (LookForFreeGPS state).
The selection is determined by the getFreePhone()
If the Plan cannot succeed on its task of creating a mitigation plan
(found_phone == NOPHONE), the Plan repeats the search in a period
basis of 2 time units.
The creation of a mitigation plan can be interrupted if the organization is lead to a
complete or redundant state (getPlan() == complete || getPlan() == redundant).
Fig. 10: Time triggered Plan template for a Mobile learning application.
Fig.11: Event triggered Execute template
The Execute behavior is responsible of executing adaptation plans.
Similarly to the Plan behavior, the Execute behavior can be reduced to contemplate only
ExecuteAdd states (marked with the red area).
Under the signal from the Plan behavior (addPhone[Pid]),
an Execute behavior running in a phone Pid modifies
managed system information with respect to the current organization
Notice that Execute behaviors must be present in all the nodes in the platform, following the
Master-Slave pattern presented above.
Fig. 12: Time triggered Plan template for a Mobile learning application.
Adaptation Goal Specification Property
The adaptation goal specification property allows verifying that when the selfadaptative
system requires adaptation, eventually the adaptation will be realized by the
In the case of the mobile learning application, and under the concern of the organization
completeness, we derive the property P1
P1: Analyze(X).Unsatisfied --> Analyze(X).Satisfied || Analyze(X).Oversatisfied
G1 defines when an Analyse behavior at node X detects that the related organization is
in an incomplete state, the MAPE behaviors will eventually adapt the managed system
bringing it in the complete or redundant state. Property G1 is based on the assumption
that eventually GPS 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. One particular case can be derived from P2
for the mobile learning scenario.
P2: ConcernKnowledge[X].required_resources > ManagedSystemKnowledge[X].used_resources
G2: SAAnalyze(X).Complete &&
G2 defines that coming from a Complete state (first line of the property specification G3),
which means that an organization posses as many resources as GPS are required; and having
switched one of the GPS resources to an unavailable state (second line), the Analyze behavior
will eventually identify the organization in an incomplete state (third line).
ManagedSystemKnowledge[X].member[Y]==USED && EnvironmentKnowledge[X].GPS[Y].state=DOWN -->
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
G3 describes a property to verify the correct collaboration between the Analyze
and Plan behaviors. The property states that when Analyze detects an incomplete
state of the managed system (organization), eventually the Plan behavior will starts planning to find a
Last update: November 3, 2013 - feedback