K  n  o  w  L  a  n  g
Framework for Knowledge Representation and Reasoning for Self-Adaptive Systems


U s e r    G u i d e

Home
Running KnowLang
Knowledge Model
Concepts
Objects
States
Metrics
Self-Adaptive Behavior
Goals
Situations
Policies
Reasoner
Contact Info
Description

In KnowLang, POLICIES are meant to handle situations as part of the self-adaptive behavior. Policies provide predefined behavior as a sequence of actions to be realized by the system.

Policies are triggered by situations and therefore, while specifying policies, we need to think of important situations that may trigger those policies. A single policy requires to be associated with (or related to) at least one situation, but for polices handling self-adaptation we eventually will need more situations. A single situation may need more policies, those providing alternative behaviors or execution paths departing from that situation.

According to the KnowLang semantics, in order to achieve specified goals, we need to specify policies triggering actions that will eventually change the system states, so the desired ones, required by the goals, will become effective. As a rule, we need to specify at least one policy per single goal, i.e., a policy that will provide the necessary behavior to achieve that goal. Of course, we may specify multiple policies handling same goal and let the system decides which policy to apply taking into consideration the current situation and conditions.

The following is a specification sample showing a simple policy called ReduceCPUOverhead - as the name says, this policy is intended to reduce the CPU overhead. As shown, the policy is specified to handle the goal Self-Opimizing_1 and is triggered by the situation HighCPUUsage. Further, the policy conditionally triggers (the CONDITONS directive requires that an SCPi is executing an application) an execution of a sequence of actions.

CONCEPT_POLICY ReduceCPUOverhead {
  CHILDREN {}
  PARENTS { ScCl.ScCloud.CONCEPT_TREES.Policy}
  SPEC {
    POLICY_GOAL { ScCl.ScCloud.CONCEPT_TREES.Self_Optimizing_1 }
    POLICY_SITUATIONS { ScCl.ScCloud.CONCEPT_TREES.HighCPUUsage }
    POLICY_RELATIONS { ScCl.ScCloud.RELATIONS.Policy_Situation_1 }
    POLICY_ACTIONS {ScCl.ScCloud.CONCEPT_TREES.StartCommunication,
      ScCl.ScCloud.CONCEPT_TREES.TransferApplication,
      ScCl.ScCloud.CONCEPT_TREES.StopCommunication }
    POLICY_MAPPINGS {
      MAPPING {
        CONDITIONS { ScCl.ScCloud.CONCEPT_TREES.SCP.STATES.Executing }
        DO_ACTIONS { ScCl.ScCloud.CONCEPT_TREES.StartCommunication,
          ScCl.ScCloud.CONCEPT_TREES.TransferApplication,
          ScCl.ScCloud.CONCEPT_TREES.StopCommunication }
      }
    }
  }
}

When specifying a policy with multiple MAPPING sections (i.e., multiple possibilities for actions to be realized), we may introduce a probability distribution among the MAPPING sections. This gives our initial designer's preference about what actions should be realized if the system ends up applying that policy (see the example below).

Situations are related to policies via relations. The following code demonstrates how we relate the HighCPUUsage situation to two different policies.

RELATIONS {
  RELATION Policy_Situation_1 {
    RELATION_PAIR {
      ScCl.ScCloud.CONCEPT_TREES.HighCPUUsage, ScCl.ScCloud.CONCEPT_TREES.ReduceCPUOverhead}
    PROBABILITY {0.6}
  }

  RELATION Policy_Situation_2 {
    RELATION_PAIR {
      ScCl.ScCloud.CONCEPT_TREES.HighCPUUsage, ScCl.ScCloud.CONCEPT_TREES.AIReduceCPUOverhead}
    PROBABILITY {0.4}
  }
}

Similarly to the policy’s MAPPING sections, the probability distribution gives initial designer's preference about what policy should be applied if the system ends up in the HighCPUUsage situation. Note that at runtime, the KnowLang Reasoner maintains a record of all the action executions and re-computes the probability rates every time when a policy has been applied.

Example
CONCEPT_POLICY ReduceRouteTraffic {
  CHILDREN {}
  PARENTS {eMobility.eCars.CONCEPT_TREES.Policy}
  SPEC {
    POLICY_GOAL {eMobility.eCars.CONCEPT_TREES.LowRouteTraffic}
    POLICY_SITUATIONS {eMobility.eCars.CONCEPT_TREES.RouteTrafficIncreased}
    POLICY_RELATIONS {eMobility.eCars.RELATIONS.Situation_Policy_1}
    POLICY_ACTIONS {eMobility.eCars.CONCEPT_TREES.TakeAlternativeRoad,
      eMobility.eCars.CONCEPT_TREES.RecomputeRoads}
    POLICY_MAPPINGS {
      MAPPING {
        CONDITIONS {eMobility.eCars.CONCEPT_TREES.Route.STATES.OnRoute}
        DO_ACTIONS {eMobility.eCars.CONCEPT_TREES.Route.FUNCS.takeAlternativeRoad}
        PROBABILITY {0.7}
      }
      MAPPING {
        CONDITIONS { eMobility.eCars.CONCEPT_TREES.Route.STATES.OnRoute}
        DO_ACTIONS { eMobility.eCars.CONCEPT_TREES.Route.FUNCS.recomputeRoads,
          eMobility.eCars.CONCEPT_TREES.Route.FUNCS.takeAlternativeRoad}
        PROBABILITY {0.3}
      }
      MAPPING {
        CONDITIONS { eMobility.eCars.CONCEPT_TREES.Route.STATES.AtBeginning}
        DO_ACTIONS { eMobility.eCars.CONCEPT_TREES.Route.FUNCS.recomputeRoads,
          eMobility.eCars.CONCEPT_TREES.Route.FUNCS.takeAlternativeRoad}
      }
    }
  }
}

top
User Guide Curator - Emil Vassev
Last modified on January 28, 2014