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