Accent Tool Suite
(Advanced Component Control Enhancing Network Technologies)

See the download page to obtain this program

Accent Overview
Accent Licence
Accent Capabilities
Goal and Policy Language
Goal and Policy Examples
Accent Software
Associated Hardware
System Installation
Related Projects
Accent Publications

Accent Overview

Accent (Advanced Component Control Enhancing Network Technologies) is a comprehensive tool suite that provides interfaces to a variety of communications systems, but more importantly allows these systems to be controlled through goals (high-level user aims) and policies (lower-level rules for how a system should behave). Accent has so far been applied to the domains of:

• Call Control: this is for telecommunications, particularly for call control in Internet telephony
• Home Care: this is for home automation and telecare, particularly for interacting with domestic appliances and devices to support home care
• Sensor Networks: this is for sensor networks, particularly for managing wind farms

However, the approach is designed to be generic and extensible for managing other kinds of systems. The three domains above show that the Accent approach can be adapted for different applications.

Accent is essentially software. As most of Accent in written in Java, it needs at least a JRE (Java Runtime Environment) but more likely a Java SDK (Software Development Kit) such as Oracle JDK or OpenJDK. However, to interact with the real world Accent needs relevant hardware such as a communications server (softswitch) or home automation equipment.

Accent Licence

The Accent Tool Suite is is free software. You can redistribute it and/or modify it under the terms of the Gnu General Public Licence, either version 3 or (at your option) any later version.

This program is distributed in the hope that it will be useful, but without any warranty and without even the implied warranty of merchantability or fitness for a particular purpose.

Accent Capabilities

From one point of view, Accent offers interfaces to the following kinds of systems. These interfaces may be useful in their own right, irrespective of the support for goals and policies:

• Call Control: A generic interface was developed by the Accent Project between the policy server and various kinds of communications servers. This interface was then instantiated for specific communications servers: SER (SIP Express Router, now incorporated into Kamailio), Mitel 7000 ICS (proprietary, no longer manufactured), and GNU GK (GNU Gatekeeper). The interface code provided as part of Accent should be adaptable for similar communications server, especially ones that support H.323 (Packet-Based Multimedia Communications Systems) or SIP (Session Initiation Protocol).
• Home Care: An interface was developed by the Match Project for monitoring and controlling home appliances and devices in the context of telecare. As this interface was particular to Match, it is likely to be of limited value except as a further example of how to adapt Accent for new domains. However, an interface was also developed to "bundles" (modules) running under OSGi (originally Open Services Gateway Initiative). In addition a large number of bundles was created to interface a wide variety of devices used in home automation and telecare such barcode readers, fitness monitors, GPRS modems, infrared controllers, Internet buddies, mains-operated appliances, RFID readers, telecare devices, and wireless home sensors. These bundles should be fairly usable in their own right, or could be readily adapted for other purposes.
• Sensor Networks: An interface was developed for the SCADA system (Supervisory Control And Data Acquisition) created by the Prosen Project for monitoring and controlling wind farms. As this interface was particular to Prosen, it is likely to be of limited value except as a further example of how to adapt Accent for new domains.

From another point of view, Accent offers a comprehensive approach for controlling systems through goals and policies. Since policy support was developed before goal support, some subsystems are named after policies though they also apply to goals. The overall architecture of the system is as follows:

• Conflict Analyser: a subsystem for detecting and resolving conflicts among goals or policies, both offline (at definition time) and online (at runtime); the Accent policy language supports special resolution policies for this purpose.
• Context Manager: a subsystem for providing additional contextual information that affects goals and policies (e.g. a user's availability from a digital diary, or the configuration of home devices).
• End User: the person who makes use of the underlying managed system.
• Goal Server: a separate subsystem for dealing with the definition and optimisation of goals.
• Managed System: the underlying system to be managed through goals and policies (e.g. an Internet telephony service or a home care system).
• Ontology Server: a separate subsystem for maintaining information about the policy language in the form of ontologies (policy concepts and their relationships).
• Policy Server: the heart of the Accent system, responsible for implementing goals and policies as well as interfacing these to the underlying system.
• Policy Store: a database for holding policies and related user information; for historical reasons this is actually two databases (a relational one for static information and a tuple-based one for dynamic information).
• Policy Wizard: a web-based interface for defining goals and policies.
• System Admin: the person who manages the overall system and defines goals and policies for this.

Goal and Policy Language

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. Subsequently, Appel was extended into new domains: sensor network and wind farm management on the Prosen Project, home automation and telecare on the Match project. Initially Appel supported only policies. Capabilities were later added for supporting policy variables, resolution policies and goals so Appel is not limited to plain policies.

The development of Appel and its supporting tools was undertaken by Jason Adair, Lynne Blair, Gavin Campbell, Tingxue Huang, Stephan Reiff-Marganiec and Ken Turner of Computing Science (University of Stirling).

Appel is an XML-based language for defining goals (high-level user aims) and policies (lower-level rules for how a system should behave) 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:

• user-oriented goals and their automatic refinement into policies
• best-effort selection of policies to achieve goals, rather than achievement of goals in some absolute sense
• use by less technical users, rather than by developers or system administrators
• extensible for new application domains by defining new schemas and ontologies
• intended for novel application domains where policy-based management has not previously been used
• template policies that are instantiated at definition time
• policy variables that are instantiated at run-time
• use of resolution policies to detect and resolve conflicts among policies
• use of prototype policies to contribute towards optimisation of goals
• fuzzy and probabilistic values in policies
• time-based goals and policies.

Appel has been applied to call control for Internet telephony, management of sensor networks and wind farms, and managing home automation and telecare.

The following diagram shows how Appel can be 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 particularised for an application domain such as call control or home care.

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

The key structural elements of Appel are as follows:

• Action: 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.
• Condition: 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.
• Expression: An expression may be used as a value or when setting a variable. Variable names inside an expression are replaced by their current values.
• 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.
• 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 the history of inputs and outputs.
• Policy: A policy dictates show the system should react to new events and to changes in the environment.
• Policy Document: This is the highest level at which one or more goals, prototype policies, regular policies, resolution policies and policy variables may be defined.
• Policy Modality: A policy may contain a modality in the form of a preference, principally for use by the conflict resolution engine.
• Policy Rule: 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.
• 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 runtime, 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).
• Timer: 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.
• Trigger: 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.
• Variable: 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.

Goal and Policy Examples

The following will give a feel for Appel. Although Appel uses XML internally, in practice it is defined and edited with a user-friendly policy wizard to render policies in a much more readable form. The examples below illustrate regular policies, resolution policies and goals for call control. Each example has a textual explanation, then its typical representation in a policy wizard, and finally its raw XML form.

Regular Policy: Forward Incoming if Busy

Forward a call to bob@cs.stir.ac.uk if there is an incoming connection to ken@cs.stir.ac.uk while the latter is busy. The empty argument for unavailable means the current user is busy.

    Applicability (label, owner, ...):
      label		Forward incoming if busy
      owner		ken@cs.stir.ac.uk
      applies to	ken@cs.stir.ac.uk
      status		enabled

    Preference (must, prefer, ...):
      don't care

    Rules (combinations, triggers, conditions, actions):
	when I am called
      and
	when unavailable
	if unconditionally
	do forward the call to bob@cs.stir.ac.uk
  

    <policy owner="ken@cs.stir.ac.uk" applies_to="ken@cs.stir.ac.uk"
     id="Forward incoming if busy" enabled="true"
     changed="2018-02-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>
  

Resolution Policy: Timer Start-Stop

Timer actions can give rise to conflicts. The following checks whether a timer with the same identifier is being asked to start and also stop by different policies. It is also checked whether the associated policy preferences are similar ('in' means 'in keeping with'). If so, the resolution of this conflict is to start the timer identified by variable0. The resolution applies to all users in cs.stir.ac.uk. Variable names are prefixed with ':'.

    Applicability (label, owner, ...):
      label		Timer start-stop
      owner		@cs.stir.ac.uk
      applies to	@cs.stir.ac.uk
      status		enabled

    Rules (combinations, triggers, conditions, actions):
	when start a timer called variable0 with value variable2
      and
	when stop a timer called variable1
	if variable0 is variable1
      and
	if preference0 is in :preference1
	do start a timer called :variable0 with value :variable2
  

    <resolution id="Timer start-stop"
     owner="admin@cs.stir.ac.uk" applies_to="@cs.stir.ac.uk" enabled="true"
     changed="2018-02-10T20:40:00">
      <policy_rule>
	<triggers>
	  <and/>
	  <trigger arg1="variable0" arg2="variable2">
	   start_timer(arg1,arg2)</trigger>
	  <trigger arg1="variable1">stop_timer(arg1)</trigger>
	</triggers>
	<conditions>
	  <and/>
	  <condition>
	    <parameter>variable0</parameter>
	    <operator>eq</operator>
	    <parameter>variable1</parameter>
	  </condition>
	  <condition>
	    <parameter>preference0</parameter>
	    <operator>in</operator>
	    <value>:preference1</value>
	  </condition>
	</conditions>
	<action arg1=":variable0" arg2=":variable2">
	 start_timer(arg1,arg2)</action>
      </policy_rule>
    </resolution>
  

Goal: Minimise Call Bandwidth

If the day is 1 to 5 (Monday to Friday), call bandwidth is minimised: literally, its negative value is maximised. Goals are associated with weights so that more important goals can be given higher priority; in this case the weight is 1.0. The policy wizard allows weights to be set by the user.

    Applicability (label, owner, ...):
      label		Minimise call bandwidth
      owner		@cs.stir.ac.uk
      applies to	@cs.stir.ac.uk
      status		enabled

    Rules (combinations, triggers, conditions, actions):
      if day is in 1..5
      do optimise
	call bandwidth as negative
  

    <goal owner="admin@cs.stir.ac.uk" applies_to="@cs.stir.ac.uk"
     id="Minimise call bandwidth" enabled="true"
     changed="2018-02-03T17:18:00">
      <policy_rule>
	<condition>
	  <parameter>day</parameter>
	  <operator>in</operator>
	  <value>1..5</value>
	</condition>
	<action arg1="-1.0*call_bandwidth">maximise(arg1)</action>
      </policy_rule>
    </goal>
      

Accent Software

The Accent tool suite supports a wide variety of subsystems, nearly all written in Java. Some files use additional languages such as scripts for Unix shell, SQL or JSP. Accent will run on standard systems (Apple Macintosh, Linux, Microsoft Windows) as well as on the Raspberry Pi credit card sized computer.

Accent provides a comprehensive set of software subsystems:

• Domain-Specific: interfaces to communications servers and devices in various domains (notably for Internet telephony, home automation and telecare)
• Ogre (Optimising Goal Refinement Engine): the goal server, integrated with the policy server
• PolServ (Policy Server): the policy server at the heart of Accent
• PolWiz (Policy Wizard): the web-based interface for defining and editing goals and policies
• Poppet (Policy Ontology Parser Program Extensible Translation): an ontology server used to retrieve generic and domain-specific concepts for goals and policies
• Recap (Rigorously Evaluated Conflicts Among Policies): an offline analyser for conflicts among policies
• Support: sundry other packages, such as a context system to interface to a user's diary stored using Microsoft Outlook

Various subsystems rely on external packages that are not part of Accent:

• Communications Servers: external communications servers such as Kamailio and GNU GK (GNU Gatekeeper) for Internet telephony
• Drivers: operating system-specific drivers for specialised hardware
• Java Development Kit: a Java SDK such as Oracle JDK or OpenJDK
• Java Serial Ports: a driver to support serial ports in Java such as SerialPort or RxTx
• Ontology Editor: an OWL (Web Ontology Language) editor such as Protégé
• OSGi Container: an OSGi SDK and container such as Knopflerfish
• Relational Database: an SQL-based database such as MySQL
• Servlet Engine: a server for JSP (Java Server Pages) such as Tomcat or Jetty
• Tuple Server: a tuple-based database such as TSpaces

Many external devices are connected via USB and appear as serial ports. This simplifies the need for device-specific drivers.

Associated Hardware

The Accent Tool Suite just needs a computer to run the software. To interface with the real world requires dedicated hardware such the following that have been used with Accent:

• ACS ACR122U RFID reader
• Cipherlab 1070 bar code reader
• Domia X10 computer modules for mains appliance control
• FitBit fitness band
• Eston GPRS609 GPRS modem
• i-Buddy Internet buddy
• IRTrans infrared transceiver
• Mitel 7000 ICS digital PABX
• Nabaztag Internet rabbit
• Oregon Scientific wireless sensors
• Plugwise energy monitors
• RFXCOM wireless receivers
• Tunstall telecare devices
• TuxDroid Internet penguin
• Visonic wireless sensor

System Installation

The Accent distribution provides the following files:

• bin: This contains shell scripts to start/stop Accent subsystems from the command line. (On Microsoft Windows, Cygwin can be used for a Unix-like environment.) Ideally, place the bin directory in the shell PATH. Shell scripts must be set executable. The main scripts are accent-start and accent-stop to allow Accent to be run from the command line without OSGi bundles. Absolute paths in a number of scripts will need to be adjusted for the local setup.
• doc: This contains documentation files.
  • pdf: This contains PDF versions of key technical reports.
• lib: This contains library files for setting up Accent.
  • appel: This contains example files for Appel, with subdirectories for various categories.
  • knopflerfish: This contains property files for the OSGi bundles. Some bundles create logs or temporary files in subdirectories of the same name as the bundle. Since some bundles need to be authorised, values such as IDENTIFIER, KEY, PASSWORD or USER in the property files need to be set to specific values. This will require registering with the relevant service. Usernames such as admin@cs.stir.ac.uk also need to be adjusted according to local circumstances. Note that a bundle finds the directory for its property file through the system property uk.ac.stir.cs.accent. This needs to be defined in, say, the Knopflerfish file restart.xargs as something like -Duk.ac.stir.cs.accent=C:/usr/local/knopflerfish/accent.
  • schemas: This contains schema and ontology files for Appel. In theory this directory needs to be placed in a web-accessible folder (e.g. using the required servlet engine if a web server is not otherwise available). In practice it should be sufficient to use the existing online schema and ontology files.
  • sql: This contains sample SQL files for setting up the database. In several files, PASSWORD needs to be set to an appropriate value for the local installation. Usernames might also be changed.
• [A-Z]*: These are OSGi bundles. The directories are projects for Eclipse with the Knopflerfish plugin. Because of the way Eclipse works, projects have absolute paths (e.g. for Knopflerfish JARs). These will have to be corrected (unless Knopflerfish has been installed in C:/usr/local/knopflerfish).

External software described under Software also needs to be installed as required. A Java Development Kit or Java Runtime Environment is essential, as is a relational database and a tuple server. The relational database would normally be permanently active; unlike the tuple server it is not started by Accent but this could be added to the startup script.

A servlet container is also essential if policies are to be created and edited using the policy wizard. In Tomcat, for example, install the policy wizard in the Tomcat webapps directory. Alternatively a context file could be created in conf/Catalina/localhost/wizard.xml, say, that points to the policy wizard directory, e.g. <Context docBase="C:/usr/local/accent//PolicyWizard" path="/wizard" reloadable="true"/>. Although the policy wizard has been localised in a few languages, the French is approximate and the German is rather incomplete.

Most of the external software can be downloaded and used without cost. However, the TSpaces tuple server is available initially only on an evaluation basis and cannot be provided with the Accent distribution. It may be possible to obtain TSpaces 2 without charge as it is now quite old but is sufficient for Accent. Although there are a number of open-source tuple spaces, changes would be necessary for Accent to work with these. To help with portability, the policy server uses the tuple server through a fairly narrow interface.

When Accent is run from the command line (e.g. with the accent-start script), the normal startup sequence is: servlet container (e.g. Tomcat), Accent ontology server (Poppet), tuple server (e.g. TSpaces), policy server. The policy server will open its own control window. The policy wizard can be accessed as, say, localhost:8080/wizard/home_care/ (the trailing '/' may be necessary depending on the servlet container). Things are shut down in the reverse order (e.g. with the accent-stop script).

If Accent is run under OSGi, startup is more automatic. However, bundles then need to be installed in the OSGi container and given an appropriate start level (see the policy system for home care). The policy wizard is accessed as above, though the servlet container is Jetty.

Once Accent is running, goals and policies can be edited using the policy wizard. Normally these would be created by modifying an existing template (though blank templates are provided for a clean start). Identifiers starting with '?' are template variables that need to be filled in before the policy can be stored. Other features of the wizard include creating policy variables, creating users of the policy system, and changing user status. The history of policy execution can also be checked. Policy variables can be defined as textual values or audio clips. The latter uses a Java applet that may well not run in recent browsers due to security restrictions (though it may be possible to work round these).

Related Projects

As the original project, Accent gave its name to the overall approach that was extended through further projects.

Accent (Advanced Call Control Enhancing Network Technologies)

The original work on managing call control was carried out by the Accent Project (Advanced Call Control Enhancing Network Technologies). This project was undertaken by Computing Science (University of Stirling) from September 2001 to March 2005. It was supported by EPSRC (Engineering and Physical Sciences Research Council) under grant R31263. Mitel Networks Corporation also supported the project financially and technically.

The project was coordinated by Ken Turner as Principal Investigator, with Evan Magill as Co-Investigator. The project researchers were Stephan Reiff-Marganiec, Lynne Blair and Jianxiong Pang. The project also benefited from collaboration with Luigi Logrippo at the University of Ottawa (Canada) and Joanne Atlee at the University of Waterloo (Canada).

The aim of the Accent Project was to develop a comprehensive but practical policy system. This was designed to achieve greater flexibility than CPL (Call Processing Language). The project worked on an advanced language and supporting mechanisms for enterprises and individuals to specify their policies and preferences for call processing - particularly for Internet telephony. The project developed a call control language for defining user policies, for analysing conflicts in these, and for supporting policies in an operational environment. The methods and tools were designed for user-friendly description of call control using a policy language called Appel (Adaptable and Programmable Policy Environment and Language). Accent also supplemented call control of Internet telephony with offline and online analysis of policy conflicts.

Interfaces were developed between the Accent policy system and communications servers supporting a variety of protocols. The Accent Project itself focused on servers supporting SIP (Session Initiation Protocol) such as the proprietary Mitel 7000 ICS, a digital PBX (Private Branch Exchange). In complementary work, the Pith Project extended this to servers supporting H.323.

Pith (Policies for Internet Telephony over H.323)

Related work was carried out on managing call control in H.323 by the Pith Project (Policies for Internet Telephony over H.323). This project was undertaken by Computing Science (University of Stirling) from April 2003 to April 2004. It was supported by the Sino-British Fellowship Trust. The project was undertaken by Huang Tingxue under the supervision of Ken Turner and Stephan Reiff-Marganiec.

Whereas the Accent Project focused mostly on a SIP environment, Pith complemented this using H.323 (Packet-Based Multimedia Communications Systems) as the communications mechanism. The aim was to allow SIP and H.323 calls to use a common policy framework that applied to any type of underlying Internet telephony device. Pith developed an interface for H.323 support from GNU GK (GNU Gatekeeper), though this is not actually included in the distribution.

Prosen (Proactive Condition Monitoring of Sensor Networks)

Separate work was carried out on managing sensors networks by the Prosen Project (Proactive Condition Monitoring of Sensor Networks). This project was undertaken by Environmental Informatics (Lancaster University), Computer Science (University of Essex), Computing Science (University of Stirling) and Electrical Engineering (University of Strathclyde) from October 2005 to September 2008. It was supported by EPSRC (Engineering and Physical Sciences Research Council) under grants C014790, C014804 and C014790. A number of external partners also supported the work.

The Stirling contribution to Prosen focused on the use of goals and policies to manage wind farms. This was achieved by extending the goal/policy language and related ontologies to handle the requirements of this domain. Although an interface was created between the Accent policy system and the Prosen control system, this is not included in the distribution as it would be of limited interest.

Match (Mobilising Advanced Technologies for Care at Home)

Separate work was carried out on managing home automation and telecare by the Match Project (Mobilising Advanced Technologies for Care at Home). This project was undertaken by Computing Science (University of Stirling), Computing (University of Dundee), Informatics (University of Edinburgh) and Computing Science (University of Glasgow) from November 2005 to October 2013. It was supported by SFC (Scottish Funding Council) under grant HR04016. A large number of external partners also supported the work.

The Stirling contribution to Match included the use of goals and policies to manage home automation and telecare. This was achieved by extending the goal/policy language and related ontologies to handle the requirements of this domain. Interfaces were also created to support a wide range of home automation and telecare devices.

Accent Publications

The main reference documentation for Accent is contained in the following technical reports that are part of the distribution:

• Tingxue Huang. Policies for H.323 Internet Telephony. Technical Report CSM-165, Computing Science and Mathematics, University of Stirling, May 2004.

• Stephan Reiff-Marganiec, Kenneth J. Turner and Lynne Blair. Appel: An Adaptable and Programmable Policy Environment and Language. Technical Report CSM-161, Computing Science and Mathematics, University of Stirling, April 2014.

• Stephan Reiff-Marganiec and Kenneth J. Turner. The Accent Project Policy Server. Technical Report CSM-164, Computing Science and Mathematics, University of Stirling, August 2013.

• Kenneth J. Turner. The Accent Project Policy Systemfor Home Care. Technical Report CSM-188, Computing Science and Mathematics, University of Stirling, January 2017.

• Kenneth J. Turner. Handling Conflict-Prone Policies in Multiple Domains. Technical Report CSM-199, Computing Science and Mathematics, University of Stirling, July 2014.

• Kenneth J. Turner and Gavin A. Campbell. The Accent Policy Wizard. Technical Report CSM-166, Computing Science and Mathematics, University of Stirling, April 2014.

In addition, the following external papers describe work on the Accent policy system:

• Lynne Blair and Kenneth J. Turner. Handling Policy Conflicts in Call Control. In Stephan Reiff-Marganiec and Mark D. Ryan, editors, Proc. 8th. International Conference on Feature Interaction, pages 39-57, IOS Press, Amsterdam, June 2005.

• Gavin A. Campbell and Kenneth J. Turner. Policy Conflict Filtering for Call Control, in Lydie du Bousquet and Jean-Luc Richier (eds.), Proc. 9th Int. Conf. on Feature Interactions in Software and Communications Systems, pp. 83-98, IOS Press, Amsterdam, May 2008.

• Gavin A. Campbell and Kenneth J. Turner. Goals and Policies for Sensor Network Management. In M. Benveniste, B. Braem, C. Dini, G. Fortino, R. Karnapke, J. L. Mauri and M. S. H. Monsi, editors, Proc. 2nd International Conference on Sensor Technologies and Applications (SENSORCOMM'08), pages 354-359, IEEE Computer Society, Los Alamitos, California, August 2008.

• Julia S. Clark and Kenneth J. Turner. Evaluating Automated Goals for Home Care Support, Assistive Technologies, 10(2):79-91, http://dx.doi.org/10.1108/JAT-01-2016-0001, Copyright Emerald Group Publishing, June 2016.

• Tingxue Huang and Kenneth J. Turner. Policy Support for H.323 Call Handling, Computer Standards and Interfaces, 28(2):204-217, November 2005 (pre-publication version, copyright Elsevier Science).

• Stephan Reiff-Marganiec and Kenneth J. Turner. Use of Logic to describe Enhanced Communications Services. In Moshe Vardi and Doron Peled, editors, Proc. Formal Techniques for Networked and Distributed Systems (FORTE XV), Lecture Notes in Computer Science 2529, pages 130-145, Copyright Springer, Berlin, November 2002.

• Stephan Reiff-Marganiec and Kenneth J. Turner. A Policy Architecture for Enhancing and Controlling Features. In Daniel Amyot and Luigi Logrippo, editors, Proc. Feature Interactions in Telecommunication Networks VII, 239-246, IOS Press, Amsterdam, June 2003.

• Stephan Reiff-Marganiec and Kenneth J. Turner. Feature Interaction in Policies, Computer Networks, 45(5):569-584, Copyright Elsevier Science Publishers, Amsterdam, March 2004.

• Stephan Reiff-Marganiec. Policies: Giving Users Control over Calls. In Mark D. Ryan, John-Jules Ch. Meyer and Hans-Dieter Ehrich, editors, Proc. Objects, Agents and Features, Lecture Notes in Computer Science 2975, pages 189-208, Springer, Berlin, May 2004.

• Kenneth J. Turner and Lynne Blair. Policies and Conflicts in Call Control, Computer Networks, 51(2):496-514, February 2007 (pre-publication version, copyright Elsevier Science).

• Kenneth J. Turner and Gavin A. Campbell. Goals and Conflicts in Telephony, in Masahide Nakamura and Stephan Reiff-Marganiec (eds.), Proc. 10th Int. Conf. on Feature Interactions in Software and Communications Systems, pp. 3-18, IOS Press, Amsterdam, June 2009.

• Kenneth J. Turner and Gavin A. Campbell. Goals for Telecare Networks, in Abdel Obaid (ed.), Proc. 9th Int. Conf. on New Technologies for Distributed Systems, pp. 270-275, Montreal, ISBN 978-1-60750-014-8, July 2009.

• Kenneth J. Turner, Liam S. Docherty, Feng Wang and Gavin A. Campbell. Managing Home Care Networks, in Robert Bestak, Laurent George, Vladimir S. Zaborovsky and Cosmin Dini (eds.), Proc. 8th Int. Conf. on Networks, pp. 354-359, (C) IEEE Computer Society, ISBN 978-0-7695-3552-4, March 2009.

• Kenneth J. Turner, Stephan Reiff-Marganiec, Lynne Blair, Jianxiong Pang, Tom Gray, Peter Perry and Joe Ireland. Policy Support for Call Control, Computer Standards and Interfaces, 28(6):635-649, June 2006 (pre-publication version, copyright Elsevier Science).

• Feng Wang and Kenneth J. Turner. Policy Conflicts in Home Care Systems, in Lydie du Bousquet and Jean-Luc Richier (eds.), Proc. 9th Int. Conf. on Feature Interactions in Software and Communications Systems, pp. 54-65, IOS Press, Amsterdam, May 2008.