Appel (Adaptable and Programmable Policy Environment and Language)

Appel Logo
Cyan Dot Introduction
Cyan Dot Approach
Cyan Dot Examples
Cyan Dot Tool Support
Cyan Dot Future Plans
Cyan Dot Publications

Introduction

Appel (Adaptable and Programmable Policy Environment and Language) was originally developed on the Accent project for control of Internet telephony. The acronym therefore originally stood for 'Accent Project Policy Environment/Language'. The name also derives from the French word for a call, so the stress is on the second syllable: Appel. Subsequently, Appel has been extended into new domains: home care management (Match project) and sensor network/wind farm management (Prosen project).

The development of Appel and its supporting tools is currently being undertaken by Ken Turner. Previous contributors have included Lynne Blair, Gavin Campbell, Tingxue Huang, Stephan Reiff-Marganiec and Feng Wang.

Approach

Appel is a language for defining goals (i.e. high-level objectives) and policies (i.e. rules) for how a system should automatically react to certain stimuli in certain situations. It is an example of a general class of policy languages called ECA (Event-Condition-Action). Appel differs from other policy languages in a number of distinctive ways:

So far, Appel has been demonstrated in the following application areas: call control for telephony, management of sensor networks, management of wind farms, and managing technical aspects of home care services.

The following diagram shows how Appel is extended for new domains. The core language is domain-independent and defines common aspects such as goal, policies, variables, timers and histories. This is then extended for regular policies (that perform actions in response to events) and resolution policies (that detect and resolve conflicts among policy actions). Each of these is then specified for some application domain such as call control.

Appel is defined through XML schemas supported by OWL ontologies. The latter are also defined in a modular and hierarchical fashion, allowing ready extension into new application domains. See the online schemas and ontologies for more details.

The key structural elements of Appel are as follows:

Policy Document
This is the highest level at which one or more goals, prototype policies, regular policies, resolution policies or policy variables may be defined.
Goal
A goal is a high-level, declarative objective. Syntactically a goal resembles a policy, but has no trigger (as goals always apply) and has just one action (to maximise or minimise a goal measure). The degree to which a goal is achieved is assessed by a numerical measure. This is defined in terms of controlled variables (managed by the policy system), uncontrolled variables (external and environmental), and derived variables (defined in terms of other variables). Since there are usually multiple (and often conflicting) goals, an overall evaluation function is defined in terms of individual goal measures.
Prototype
A prototype is a predefined policy that contributes towards goals by affecting variables (and therefore affecting goal measures). When goals and prototypes are defined, the relationship among goals and prototypes is statically determined. At run time, when triggers occur, the prototypes that best contribute to the goals are selected dynamically. Prototypes may also have parameters that are optimised dynamically. The result is a flexible and completely dynamic approach to refinement of goals into policies (or, more precisely, the selection of policies to achieve goals). The numerical approach means that goals are achieved as far as possible (and not in some absolute sense). The dynamic approach means that refinement takes account of current circumstances (which may change as the system and its environment evolve).
Policy
A policy is the main element in Appel.
Policy Modality
A policy may contain a modality in the form of a preference, principally for use by the conflict resolution engine.
Policy Rules
A policy rule group is either a single policy rule or a composite of subsidiary policy rules. Policy rules can optionally be combined in pairs with a number of operators.
Triggers
A trigger group is either a single trigger or a composite of subsidiary triggers. A trigger has a name and optional arguments. One or more triggers might enable a policy. The and and or combinations require both or either of the triggers to be active. If the combination of actual trigger events permits the policy rule, then its condition is considered. Goals (which have no triggers) are always implicitly activated.
Conditions
A condition group is either a single condition or a composite of subsidiary conditions. A composite list of conditions is normally used when an operator governs these conditions. However groups with just one condition may be nested within each other if desired. Conditions may be combined with the usual boolean and, or and not operators.
Actions
An action group is either a single action or a composite of subsidiary actions. An action has a name and optional arguments. Operators can be used to define the order in which pairs of actions are applied.
Variables
A policy variable is just a name for a value. Policy variables can be defined by a policy document, can be defined implicitly when an external trigger occurs, and can be defined by a policy action. Variables may hold boolean, numeric (integer, floating point) or string values. Within certain policy elements, variable names can appear individually, in ranges or in lists. The value of a variable is substituted when a policy is executed, not when it is defined. When used in an expression, the name of a variable is prefixed by ':' to obtain its value.
Expressions
Expression may be used as a value or when setting a variable. Variable names inside an expression are replaced by their current values.
Timers
Policies may make use of interval (count-down) timers. A timer becomes active when it is started, and ceases to exist when it counts down to zero. At this point, an expiry event occurs for the timer identifier. An active timer may be restarted or stopped. In addition to explicit timers, policies with time conditions imply internal timer triggers.
History
External triggers are automatically recorded by the policy server as they are received. Similarly, external actions are also automatically recorded. This allows policies to depend on past inputs and outputs.

Examples

The following examples illustrate the use of Appel in various domains. (Although XML is used here, a policy wizard allows a non-technical user to express goals and policies in a natural way.)

Call Control - Regular Policy
The following policy states that calls to ken@cs.stir.ac.uk should be forwarded to bob@cs.stir.ac.uk if there is an incoming call while Ken is busy. The empty argument for unavailable means the current user is unavailable, i.e. busy.
      <policy owner="ken@cs.stir.ac.uk" applies_to="ken@cs.stir.ac.uk"
       id="Forward if busy" enabled="true" changed="2004-08-02T11:20:05">
	<policy_rule>
	  <triggers>
	    <and/>
	    <trigger>connect_incoming</trigger>
	    <trigger arg1="">unavailable(arg1)</trigger>
	  </triggers>
	  <action arg1="bob@cs.stir.ac.uk">forward_to(arg1)</action>
	</policy_rule>
      </policy>
    
Call Control - Regular Policy
The following policy states that incoming calls should be forwarded to voicemail when I am busy or don't answer within 5 rings. This policy has two combinations of trigger events but does not specify any conditions.
      <policy owner="ken@cs.stir.ac.uk" applies_to="ken@cs.stir.ac.uk"
       id="Voicemail on Busy or No Answer" enabled="true"
       changed="2004-08-02T11:19:00">
	<policy_rule>
	  <triggers>
	    <or/>
	    <trigger arg1="">unavailable(arg1)</trigger>
	    <trigger arg1="5">no_answer_incoming(arg1)</trigger>
	  </triggers>
	  <action arg1="http://voicemail.co.uk/~ken">forward_to(arg1)</action>
	</policy_rule>
      </policy>
    
Home Care - Regular Policy
Logging everyday activity in the home can be valuable to determine long-term trends. However, the nature of the logging should vary according to the circumstances and preferences of the individual. The following policy receives a logging request that specifies two lists of sensors: those whose logging should be started (parameter_values[0]), and those whose logging should be stopped (parameter_values[1]). These values are obtained implicitly from the trigger through the parameter_values environment variable.
      <policy owner="admin" applies_to="@raploch.org.uk"
       id="Logging of everyday activity" enabled="true"
       changed="2007-12-19T22:12:00">
	<policy_rule>
	  <trigger arg1="logging_request">device_in(arg1)</trigger>
	  <actions>
	    <and/>
	    <action arg1="start" arg2="logging_service" arg5=":parameter_values[0]">
	      device_out(arg1,arg2,,,arg5)
	    </action>
	    <action arg1="stop" arg2="logging_service" arg5=":parameter_values[1]">
	      device_out(arg1,arg2,,,arg5)
	    </action>
	  </actions>
	</policy_rule>
      </policy>
    
Home Care - Regular Policy
Older people, especially those with dementia, are prone to waking in the middle of the night and leaving the house. The following policy advises the user to return to bed using synthesised speech (say, of a family member). It applies to domain house3.match-project.org.uk, i.e. house 3 in the trial area of the Match project. When the front door is opened, if the time is 11PM-7AM and the master bed is unoccupied, the message 'It is night time, go back to bed' is synthesised on the hallway loudspeaker. To avoid having to hard-code the policy for the entity instance corresponding to the front door, the policy variable front is used instead. Similarly, master_bed is a policy variable that identifies the master bed occupancy sensor. These are defined separately for the house (whether manually through the policy wizard or automatically through a configuration system). Since parameter values in general take the form of a list, the trigger input carries the list '[open]'. The message period is omitted for both the trigger (i.e. 'trigger just occurred') and the action (i.e. 'perform action now').
      <policy owner="admin" applies_to="@house3.match-project.org.uk"
       id="Night wandering reminder" enabled="true"
       changed="2007-12-19T22:12:00">
	<policy_rule>
	  <trigger arg1="door_status" arg2="door" arg3=":front" arg5="[open]">
	    device_in(arg1,arg2,arg3,,arg5)
	  </trigger>
	  <conditions>
	    <and/>
	    <condition>
	      <parameter>time</parameter>
	      <operator>in</operator>
	      <value>23:00:00..07:00:00</value>
	    </condition>
	    <condition>
	      <parameter>:master_bed</parameter>
	      <operator>eq</operator>
	      <value>unoccupied</value>
	    </condition>
	  </conditions>
	  <action arg1="speak" arg2="loudspeaker"
		  arg3=":hallway" arg5="It is night time, go back to bed">
	    device_out(arg1,arg2,arg3,,arg5)
	  </action>
	</policy_rule>
      </policy>
    
Sensor Networks - Regular Policy
The following policy applies to the myers_hill domain. It deals with a low battery warning from any sensor node. It logs the event and sends a message to 07779-123-456. Note the use of environment variables in the actions.
      <policy owner="admin" applies_to="@myers_hill"
       id="Low battery alert" enabled="true" changed="2007-09-21T11:05:16">
	<policy_rule>
	  <trigger arg1="low_battery" arg2="sensor_node">
	    device_in(arg1,arg2)
	  </trigger>
	  <actions>
	    <and/>
	    <action arg1="Low battery at sensor :entity_instance">
	      log_event(arg1)
	    </action>
	    <action arg1="sms:07779-432-020"
		    arg2="Low battery warning from :entity_name/:entity_instance">
	      send_message(arg1,arg2)
	    </action>
	  </actions>
	</policy_rule>
      </policy>
    
Sensor Networks - Regular Policy
The following policy is triggered by operator input from the default operator console, asking that the power curve agent be retrained. It asks the external agent system to retrain this agent in ten minutes using value 30.
      <policy owner="admin" applies_to="@3.wind_farm"
       id="Retrain power agent" enabled="true" changed="2007-09-22T01:42:17">
	<policy_rule>
	  <trigger arg1="operator_input" arg5="retrain_power_curve">
	    device_in(arg1,,,,arg5)
	  </trigger>
	  <action arg1="retrain_agent" arg2="policy_agent" arg3="power_curve"
		  arg4="10" arg5="30">
	    device_out(arg1,arg2,arg3,arg4,arg5)
	  </action>
	</policy_rule>
      </policy>
    
Call Control - Resolution Policy
Suppose that one party wishes to add video to a call, while the other wishes include a third party in the call (add_caller). This might be considered undesirable, since the third party would be able to view the call parties and their workplaces. The resolution is to allow both actions, but to conference in bob@cs.stir.ac.uk to oversee the call (add_party). Note that the triggers and actions are all of different types. This resolution explicitly deals with only the equal/similar case. Other cases are handled by default.
      <resolution id="Medium add-add conflict"
       owner="admin@cs.stir.ac.uk" applies_to="@cs.stir.ac.uk" enabled="true"
       changed="2007-12-13T20:40:00">
	<policy_rule>
	  <triggers>
	    <and/>
	    <trigger arg1="variable0">add_medium(arg1)</trigger>
	    <trigger arg1="variable1">add_medium(arg1)</trigger>
	  </triggers>
	  <conditions>
	    <and/>
	    <condition>
	      <parameter>variable0</parameter>
	      <operator>eq</operator>
	      <parameter>variable1</parameter>
	    </condition>
	    <condition>
	     <parameter>preference0</parameter>
	     <operator>out</operator>
	     <value>preference1</value>
	    </condition>
	  </conditions>
	  <action>apply_negative</action>
	</policy_rule>
      </resolution>
    
Home Care - Goal
An older person living at home may need encouragement to stay active. The following goal states that user activity should be maximised during weekdays. User activity is defined in terms of factors such as how long the user is awake for, how much television they watch, and how much contact they have with other people. The user_activity measures is defined in terms of these variables, using weights determined by a domain expert (or learned values).
      <goal owner="admin@cs.stir.ac.uk" applies_to="@cs.stir.ac.uk"
       id="Maximise user activity" enabled="true" changed="2009-01-16T17:45:00">
	<policy_rule>
	  <condition>
	    <parameter>day</parameter>
	    <operator>in</operator>
	    <value>1..5</value>
	  </condition>
	  <action arg1="user_activity">maximise(arg1)</action>
	</policy_rule>
      </goal>
    

Tool Support

Appel is supported by a set of tools that allow goals and policies to be defined offline and to be realised in real time:

Managed System
The system under control (e.g. a call control system)
Policy Store
An XML database that stores information about goals and policies
Policy Server
The heart of the policy system. The policy server receives goals and policies from the policy wizard, and also information from the context manager. When goals or prototypes are modified, the goal server is called to statically analyse them. When an event occurs in the managed system, it selects relevant policies (i.e. those associated with this trigger and whose conditions are met). If any triggered policies derive from goals, the goal server is asked to find the optimal set. Conflicts among policies are then automatically detected and resolved. Finally, an optimal and compatible set of actions is sent to the managed system.
Policy Wizard
A user-friendly interface for defining and editing goals and policies
Context Manager
An interface for providing additional information about the managed system (e.g. the home configuration).
Conflict Analyser
A tool to analyse policies offline for possible conflicts
Ontology Server
A generic interface to ontology-based information about an application domain (e.g. call control). Domain-specific ontologies are used by the policy wizard, the conflict analyser and the goal server.
Goal Server
The heart of the goal system. The static goal analyser is invoked when goals or prototypes are altered. The dynamic goal analyser is invoked when goal-derived policies are triggered.

Future Plans

The goal server is currently being integrated more fully into the rest of the policy system. It is planned to develop techniques for capturing stakeholder viewpoints as goals and policies, and for handling conflicts among these.

Publications

The following papers give the technical basis for Appel:

The following papers illustrate the use of Appel in various domains:


Up Arrow Up one level to Ken Turner - Research Projects

Web Ken Turner Home   Email    Search Search Web Pages


URL: http://www.cs.stir.ac.uk/appel.html