MAPE-K Templates:
Instance for a Mobile Learning application

Home - ActivFORMS - MAPE-K Templates



    Here we present concrete models and properties based on the MAPE-K Templates for the specification of self-adaptation in a mobile learning application.

    Download: models for Uppaal.

    The mobile learning application supports outdoor learning activities, where students use GPS-enabled mobile devices. A learning activity takes place in the context of a lecture (of 1 or 1.5 hour) and is composed of a set of tasks (typically 4 to 8 tasks). An example of a learning activity is to measure and calculate properties of triangles, and one concrete task is to use triangulation techniques to find locations on the field given the three side measurements of a triangle, and having two of the triangle locations already marked on the field. Fig. 1 shows a use case scenario, where three groups of students (represented by MVDs) perform tasks of a learning activity.


Fig. 1: Use case scenario of the mobile learning application


    The application is conceived as a distributed agent-based system. A Device Agent deployed on each mobile phone provides the learning services to the student (gathering locations, calculating distances, etc.). The device agents of a group that work on the same tasks form an Mobile Virtual DeviceMVD. Within an MVD, one of the agents is elected as master, while the others serve as slaves. Task management is the responsibility fo the Activity Agent that resides at a server. Master agents communicate via 3G with the activity agent using a Communication Infrastructure. Master agents receive new tasks from the activity agent and report the results back when a task is completed.
    Changing conditions in the environment may affect the quality of GPS services. Consequently, the number of devices in a MVD may become insufficient to realize the activity requirements. Hence, it becomes crucial to provide self-adaptation mechanisms to enable robustness of the application.
    The managed system, which compromises the software to support the application functionality, has been extended with two MAPE-K loops that deal with two complementary concerns. A first MAPE-K is concerned with managing the availability of the GPS service based on the actual GPS service quality. The second loop deals with managing the required number of GPS services of the current task for the MVD. We will focus on the behaviors of the second MAPE-K loop.

Fig. 2: Structural architecture of the Mobile Learning application.
Two MAPE-K loops are present to deal with two concerns: GPS quality (left loop), Organization (right loop)

     

    The second MAPE loop (MVD Concern) is distributed over the devices of the MVD. This MAPE loop uses a master-slave pattern. If the master detects that the number of GPS services in the MVD is not sufficient for the current task, it looks for an additional service. If there is a free GPS service available, the device that provides that service is dynamically added to the MVD, if not, the master periodically re-checks. For additional information, we refer to the SEAMS 2013 paper.

Fig. 3: Structural architecture of the Mobile Learning application.
Two MAPE-K loops are present to deal with two concerns: GPS quality (left loop), Organization (right loop)


    Templates for a Mobile Learning scenario

     We use the following color conventions for the description of the behaviors:

    • States of behaviors are annotated in red.
    • Invariants that need to be satisfied in certain states are annotated in purple.
    • Conditions to enable firing of transitions between states are annotated in green.
    • Signals used for communication between behaviors are annotated dark blue.
    • Functions associated with behaviors are annotated in light blue.

      Monitor

    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)
     

      Analysis

    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)
     

      Plan

    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() function. 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.
     

      Execute

    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 (putPhone(Pid,Mid)) managed system information with respect to the current organization (Mid) deployment.

      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.
     

  Properties

    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 MAPE-K loop. 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

      into G1:

    G1: SAAnalyze(X).Incomplete-->SAAnalyze(X).Complete||SAAnalyze(X).Redundant

    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 --> Analyze(X).Unsatisfied

      into G2:

    G2: SAAnalyze(X).Complete &&
          ManagedSystemKnowledge[X].member[Y]==USED && EnvironmentKnowledge[X].GPS[Y].state=DOWN -->
          SAAnalyze(X).Incomplete

    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).

    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

      into G3:

    G3: SAAnalyze(X).Incomplete-->SAPlan(X).LookForFreeGPS

    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 GPS resource.

Last update: November 3, 2013 - feedback