Software Architecture Design Document (SADD)

Intelligent Lifestyle

Team Daedalus (s440gf)

Carol Sin Yi Poon - (csypoon)Dominic Xavier Mendonca - (dxm)

Jian Alan Huang - (jhua)Kieran James Simpson - (kieranjs)

Masyuri Jaya Tjhandana - (masyurit)Mei Ling Leong - (mlleong)

Revision: 1.0.025 October 2004

Maintained by: Dominic Xavier Mendonca - (dxm)

Abstract

This document formally describes the architectural design of the Intelligent Lifestyle system.

Contents

1 Introduction 61.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Document Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.6.1 Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6.2 Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6.3 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.7 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.7.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.7.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.8.1 Reference Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.8.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Methodology 112.1 Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Specification and Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Design Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Design goals 143.1 High Priority Design Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Medium Priority Design Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Low Priority Design Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Not Applicable Design Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Description of Hardware 164.1 Devices Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Architecture Design 185.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Context Tier 206.1 Context Information Considered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1.1 Base-context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.1.2 Meta-context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.2 Desired Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.3 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.3.1 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3.2 Cues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3.3 Context Soup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3.4 Context Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4 Role Hierarchy for Context Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.4.1 Sensor Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2

6.4.2 Cue Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4.3 Context Soup Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.4.4 Context Resolution Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Application Tier 307.1 Desired Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307.2 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.2.1 Situation Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.2.2 Response Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327.2.3 Execution and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.3 Role Hierarchy for Application Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Reflections on the methodology 43

9 Appendices 449.1 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3

List of Figures

1 The ROADMAP models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Centralized Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Context Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Context Tier Role Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Application Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Sequence Diagram of an Agent in Action . . . . . . . . . . . . . . . . . . . . . . . . . 358 Application Tier Role Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Response Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4

List of Tables

1 Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Design Goals Priority Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Advantages and Disadvantages of Centralized architecture . . . . . . . . . . . . . . . 224 Description of the Communicator Role in the Application Tier . . . . . . . . . . . . 385 Description of the Greeter Role in the Application Tier . . . . . . . . . . . . . . . . 396 Description of the Guider Role in the Application Tier . . . . . . . . . . . . . . . . . 407 Description of the Recorder Role in the Application Tier . . . . . . . . . . . . . . . . 418 Description of the Scheduler Role in the Application Tier . . . . . . . . . . . . . . . 429 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5

1 Introduction

1.1 Purpose

This document describes an architecture within which all of the core scenarios stated in the SoftwareRequirements Specification (SRS) can be implemented. It also aims to fit as many of the non-corescenarios into the architecture as possible while fulfilling quality goals listed in this document.

1.2 Scope

This document describes the high level architecture of the Intelligent Lifestyle Project. It will beused in detailed design to design individual modules of the system, and may be used after theproject by other teams to extend the system. This document does not include any detailed designinformation or any implementation details of any modules. Any algorithms or data structures willalso not be included in this document.

1.3 Intended Audience

The intended audiences of the SADD are as follows:

1. Developers of the project

2. Clients

3. Supervisor

1.4 Project Overview

The aim of the Intelligent Lifestyle project is:

To design and build a system via the ROADMAP methodology comprising of some intelligentagents, for the explicit purpose of providing demonstrations of Intelligent Agents.

This aim is an attempt to balance the two requirements from the Clients. This is necessary asmeeting both fully would be impossible with current time constraints. The individual aims of theClients are shown below.

1. To provide a demonstration of intelligent agents.

The Clients wish to have something that can demonstrate agents, agent behaviour and intel-ligence. Scenarios will be used to demonstrate these features.

2. To implement the ROADMAP methodology and create an intelligent agent system.

The Clients wish to test out ROADMAP and produce an example of an intelligent agentsystem. They believe this methodology will be useful in implementing the project.

6

1.5 Document Overview

This document will be structured as follows.

1. Section 2: Design Methodology describes the methodology employed in designing thesystem and introduces the concepts of goals and roles.

2. Section 3: Design Goals enumerates the design goals that will be fulfilled by the design.

3. Section 4: Description of Hardware describes the deployment of hardware that will takeplace and the physical distribution of the system. It describes the system from an operatingsystem standpoint.

4. Section 5: Architecture Design explains the overall architecture that will be followed andreviews previous work done by other researchers on systems of this nature.

5. Section 6: Context Tier describes the context tier of our architecture.

6. Section 7: Application Tier describes the application tier of our architecture.

7. Section 8: Reflections on the Methodology details the reflections on the methodologyused in creating this document.

1.6 Personnel

1.6.1 Development Team

Name Login Phone no.Carol Poon cyspoon 0401-959-660Dominic Mendonca dxm 0411-093-253Glenn Fry gmfr 0418-372-176Simon Youn hjsy 0403-438-830Jian Alan Huang jhua 0402-001-910Kieran Simpson kieranjs 0412-821-128Masyuri Tjhandana masyurit 0413-150-311Mei Ling Leong mlleong 0413-689-314Nathaporn Eiamvittayakorn neiam 0407-565-824Quyen Quach qlq 0412-122-031Shirley Soon sasoon 0407-552-338Wendy Tsang wwttsang 0411-199-822Ivan Wong ywong 0411-863-261

Table 1: Development Team

Email addresses of team members can be derived from the user’s login name by appending ”@stu-dents.cs.mu.oz.au”.

7

1.6.2 Supervisor

Kendall ListerDepartment of Computer Science and Software EngineeringUniversity of Melbournekrl@cs.mu.oz.au

1.6.3 Clients

Leon SterlingDepartment of Computer Science and Software EngineeringUniversity of Melbourneleon@cs.mu.oz.au

Thomas JuanDepartment of Computer Science and Software EngineeringUniversity of Melbournetlj@cs.mu.oz.au

1.7 Definitions and Acronyms

This section describes all definitions and acronyms used by Team Daedalus in this document.

1.7.1 Definitions

AgentAn encapsulated computer system, situated in some environment, and capable of flexible au-tonomous action in that environment to meet its design objectives.

BluetoothA short-range radio technology for Internet and mobile devices.

LabletA room with one or at most two computers.

OpenCV libraryOpen Source Computer Vision library created by Intel.

WidCommSoftware which provides bluetooth connectivity solutions.

Wi-FiWireless local area network technology providing short-range, high-speed data connections betweenmobile data devices and nearby Wi-Fi access points.

$GROUP/home/se440/s440gf/

$GROUPCVS

8

/home/se440/s440gf/Respository

$GROUPWWWhttp://www.cs.mu.oz.au/SE-projects/s440gf

1.7.2 Acronyms

API Application Programming InterfaceHTTP Hypertext Transfer ProtocolICT Information and Communications TechnologyPC Personal ComputerPDA Personal Digital AssistantRF Radio FrequencyROADMAP Role-Oriented Analysis and Design Methodology for Multi-Agent ProgrammingSADD Software Architecture Design DocumentSRS Software Requirements SpecificationsUSB Universal Serial BusWi-Fi Wireless FidelityXML Extensible Markup Language

1.8 References

1.8.1 Reference Documents

The documents referenced in the SADD are as follows:

1. Team Daedalus Software Requirements Specification (SRS)

1.8.2 References

This section specifies the IEEE standards, text books and other documents that are referenced andused as background materials to create this document.

1. C. Ciavarella, F. Paterno, The design of a handheld, location-aware guide for indoor environ-ments, 27 April 2004.

2. K. P. Sycara, Multiagent Systems, Summer 1998.

3. M. Bauer, C. Becker, K. Rothermel, Location Models from the Perspective of Context-AwareApplications and Mobile Ad Hoc Networks, 2002.

4. P. J. Brown, G. J. F. Jones, Context-aware Retrieval: Exploring a New Environment forInformation Retrieval and Information Filtering, 2001.

5. A. K. Dey, G. D. Abowd, Towards a Better Understanding of Context and Context-Awareness.

6. C. K. Hess, R. H. Campbell, An Application of a Context-aware File System, 14 November2003.

7. P. Amann, G. Quirchmayr, Foundation of a Framework to Support Knowledge Managementin the Field of Context-Aware and Pervasive Computing.

9

8. A. Dey, J. Mankoff, G. Abowd, S. Carter, Distributed Mediation of Ambiguous Context inAware Environments, October 2002.

9. J. E. Bardram, Applications of Context-Aware Computing in Hospital Work - Examples andDesign Principles, March 2004.

10. K. Fujinami, T. Yamabe, T. Nakajima, “Take me with you!”: A Case Study of Context-awareApplication integrating Cyber and Physical Spaces, March 2004.

11. A. Harter, A. Hopper, P. Steggles, A. Ward, P. Webster, The Anatomy of a Context-AwareApplication, 2002.

12. R. Power, Topic Maps for Context Management, 16 July 2003.

13. K. Cheverst, N. Daview, K. Mitchell, A. Friday, Experiences of Developing and Deploying aContest-Aware Tourist Guide: The GUIDE Project, 2000.

14. O. Conlan, R. Power, K. Barrett, Next Generation Context Aware Adaptive Services.

15. H. W. Gellersen, A. Schmidt, M. Beigl, Multi-Sensor Context-Awareness in Mobile Devicesand Smart Artifacts, 2002.

16. W. G. Griswold, R. Boyer, S. W. Brown, T. M. Truong, A Component Architecture for anExtensible, Highly Integrated Context-Aware Computing Infrastructure, 2003.

17. B. MacIntyre, E. D. Mynatt, S. Voida, K. M. Hansen, J. Tullio, G. M. Corso, Support ForMultitasking and Background Awareness Using Interactive Peripheral Displays, 2001.

18. J. I. Hong, The Context Fabric: An Infrastructure for Context-Aware Computing, April 2002.

19. K. Z. Haigh, J. Phelps, C. W. Geib, An Open Agent Architecture for Assisting Elder Inde-pendence, July 2002.

20. S. Klein, A. Vengerov, EQAL Approach to the Design of Learning Technology in DynamicInformation Contexts, May 2000.

21. A. Ranganathan, R. H. Campbell, An Infrastructure for Context-Awareness Based on FirstOrder Logic, 9 November 2002.

10

2 Methodology

2.1 Design Methodology

Software has traditionally been developed under the assumptions that all system requirementsmust be determined and frozen during the analysis stage. This requires any factors accounted forat run-time to be anticipated and designed for during the design phase. There are two problemsdeveloping an agent system this method:

• It unnecessarily constrains complex open systems; and

• It is difficult to enforce during all development stages.

To reduce the complexity of developing a Multi-Agent System we have chosen the ROADMAPmethodology which allows a far more realistic approach to specification, analysis, and design.ROADMAP is an acronym for Role-Oriented Analysis and Design for Multi-Agent Programming.

Using the ROADMAP approach we have designed the system using the following steps:

1. Construct the Goal Hierarchy of the system based on the Goal Models in the SRS.

2. Based on the Goal Hierarchy, identify the roles needed to achieve the goals.

3. Choose an architecture for the system based on the design goals.

4. Fit the roles identified in step 2 into the architecture and construct the Role Hierarchy.

5. Identify agents based on the Role Hierarchy and construct the Agent Models and ServiceModels.

6. Identify the interactions between agents and construct the Interaction Models.

Figure 1: The ROADMAP models

Figure 1 shows the structure of the ROADMAP methodology. As can be seen from the diagramROADMAP consists of two phases: “Specification and Analysis” and “Design”. Each phase isdescribed in detail in the following sections.

11

2.2 Specification and Analysis Phase

Goal ModelThe goal model describes the logical processes of the system to achieve a particular task. Itincludes generalised graphical diagrams and specialised text scenarios. A goal is composed ofsoft goals relating to different quality attributes, for example “secure accounts”. The scenariosoutline the detail of the system response such as a feature decision: “use RSA encryption”.

Environment ModelThe environment model is used to provide a holistic description of the system environment. Indescribing the environment a knowledge foundation on which changes are handled consistently.It is made up of a tree hierarchy of zones in the environment, and a set of zone schema todescribe each zone in the hierarchy. The schema includes a text description and the followingattributes: static objects, objects, constraints, sources of uncertainty and assumptions. Theenvironment model is derived from the goal model.

Knowledge ModelThe knowledge model provides a description of the domain of knowledge in the system.The model consists of a hierarchy of components and a description for each. Knowledge isidentified from the goal and environment models and is used to deliver agent behaviours inthe appropriate zones. The knowledge model connects the role model with the previous twomodels.

Role ModelThe role model describes the characteristics of individual agents. It consists of a hierarchyand schema describing each role within the hierarchy. The hierarchical nature of roles allowsfor aggregation of properties and composition.

Protocol ModelThe protocol model describes the interaction between roles in the system by using sequencediagrams. It is developed from the role model.

Interaction ModelThe interaction model is also developed from the initial role model. It contains a protocoldefinition for each protocol of each role in the system and details the roles and zones in aclear graphical manner.

2.3 Design Phase

As can be seen in Figure 1, the Design phase consists of all the models implemented in the Spec-ification and Analysis phase with the addition of two extra models: Agent model and Servicemodel.

Agent ModelThe agent model describe the structure of the agent. It is created in parallel (with rolemodel) by assigning roles to agent classes. The role assignments are also subject to change atruntime. For every agent class, a number of associated services are named. For each service,we can specify whether it implements a protocol or activity from the assigned roles. For eachprotocol or activity, there must be a least one implementing service. These allow the correctservice be invoked at run-time.

12

Service ModelThe services model outlines the services required by the roles assigned to the agent types.The model lists services that agent types provide. They are derived from the activities andprotocols of the roles. For each service, four attributes must be specified: inputs, outputs,pre-conditions and post-conditions.

Due to the dynamic nature of development, the Specification and Analysis phase and Design phaseare iterative. This allows changes realised in later parts to be reflected in earlier stages as well.These phases are considered complete when all requirements in the SRS have been captured.

13

3 Design goals

This section describes the properties that we consider to be vital to the system. The developmentteam will use these properties as criteria against which to measure the quality of the architecture.Each criteria can be categorized into one of four priority levels: High, Medium, Low and NotApplicable. The table below explains each of the levels.

Level DescriptionHigh Quality goals that our design MUST meet. Unless these goals are met, the

design will be deemed not fit for use and we will not move to the next phase.Medium Quality goals that are optional - it will be good to have them. We can still

move on to the next phase if not all of them are met.Low Quality goals that we will keep at the back of our minds while designing the

system. We can still move on to the next phase if not all of them are met.Not Applicable Quality goals that are usually important in design, but are not important

for our system

Table 2: Design Goals Priority Level

3.1 High Priority Design Criteria

The properties which are considered to have a high level of importance are:

1. Adaptability in Dynamic EnvironmentAgents must be able to be aware of context and adapt to changes. They should be ableto change their plans during execution if the environment changes. This should be done asseamlessly to the human eyes as possible.

2. ReliabilityThe architecture must behave consistently as the system will be used by the Client for demon-stration purposes. There shouldn’t be a single point of failure in the system.

3. Multi-agent Collaborative SystemAgents must share information and work collaboratively to make correct deductions whileachieving goals.

3.2 Medium Priority Design Criteria

The properties which are considered to have a medium level of importance are:

1. ScalabilityThe system will be improved and new functionalities will be integrated in the future. There-fore, new agents should be able to be inserted into the community of agents at any timewithout changing the architecture of the system.

2. Response TimeSystem must provide quick discernable response to any input from the sensors. Some of theinput may be processed and found to be not useful in the end, but some will be used ascontext information for the agents to achieve their goals.

14

3. AccuracyAgents must be accurate both when obtaining context information and making deductionsof its own. For example, if Leon walks into the room, he should be recognized as Leon, andnot someone else. In another example, if Leon has a meeting at 9am, it is 8:45am now, heis sleeping and he likes to be woken up 15 minutes before a meeting, then the agent shoulddeduce that he needs to be woken up now.

3.3 Low Priority Design Criteria

The properties which are considered to have a low level of importance are:

1. LearningAgents must be able to learn new things and appear to behave more intelligently over time.They must be able to learn that certain things did not work out well and hence will updatetheir knowledge base.

2. MaintainabilityThe effort needed to maintain the system should be minimal. This can be done by hav-ing adequate and clear documentation, which can be read and understood by any externaldevelopers. Having a highly modular design also increases maintainability.

3.4 Not Applicable Design Criteria

The following property is usually a main concern in systems with a huge number of users. However,it is not considered to have an impact on our system and hence, will not be considered as designgoal of our architecture.

1. SecurityThe system does not have to be password protected. Authentication is a non-issue here. Asspecified by the Client, we do not have to worry about data in the system being stolen ormanipulated.

15

4 Description of Hardware

This section describes the physical distribution of the system. It defines the devices required in thesystem and their distribution.

Figure 2: Network Architecture

As we can see in Figure 2, the system is distributed across two main zones - the lablet and theoffice. In addition, points of presence located around the ICT building - probably at intersections- communicate with a web-server via HTTP. These points of presence communicate with PDAsvia bluetooth. Within each zone, a range of input and output devices, including a microphone,speakers, web-camera and display, are connected to a zone PC. A modem is also attached to thezone PC, thus connecting it to a telephone network.Each zone PC has a network (probably fast Ethernet) connection to a central PC. We anticipatethat system-wide information such as context information and user preferences will be stored here.The central PC communicates with the web-server via HTTP.

4.1 Devices Used

In this section we describe in detail the hardware devices we will use in our system.

16

• Cameras We will use two standard USB web-cameras / webcams (one for each zone). The re-quirement for the camera is that it is supported by Windows and the OpenCV library. We usea resolution of 640 x 480 pixel webcams. However, better resolution webcams may be needed,depending on the outcome of prototyping face recognition. We require face recognition to beachievable where the people to be recognized are 2 metres away from the camera.

• Speaker We will use standard 100 Watt PC speakers. The speakers will be used in everyopen or closed environment. This will include rooms, lablets, and etc. The speakers will beused for the purpose of communication, as well as system enquiries to the users. The speakerswill have to be loud enough to be heard within a 2 metres radius.

• PDAs We will use 2 Hewlett Packard Ipaq 5450s. They support Wi-Fi and bluetooth, anduse the WidComm bluetooth stack. They also support the .NET Compact Framework. Inorder to be detected by the system, they will need to have bluetooth discovery enabled. Inorder to be used as part of a messaging system, they will need to be running an applicationthat we provide.

• Web Server The webserver is a PC that is connected to the Internet and is able to functionas a server. It must have the Java 2 runtime environment installed. Note that we will notuse the web server to allow external access to the system from online.

• Microphone We will use an array microphone in every zone for the purpose of being able tocapture any audio input. We choose to use an array microphone for its unobtrusiveness andreasonable accuracy. Depending on voice recognition accuracy discovered during prototyping,we may use a headset instead. If using an array microphone, we will require it to captureaccurately voice input from a distance of up to 2 metres.

• Clarinox Devices We use two USB Clarinox devices, provided by the firm Clarinox withan API. These devices can discover bluetooth enabled devices and send information via blue-tooth.

• Displays In each zone is a display. We anticipate this to simply be a desktop monitor.However, we may use a display whiteboard.

• Modem We use a 56 K modem for each zone. The modem is connected to a landlinetelephone network.

• Zone PCs In each zone is a PC to which is connected a display, microphone, camera, modemand speakers. This PC also has an ethernet connection to the central broker PC describedbelow. Software that uses the hardware connected to this PC is running on the PC.

• Central Broker PC We also have a central PC which manages service requests betweensoftware entities in each zone. This PC has Internet access and the blackboard (to be describedin Section 5) is here.

17

5 Architecture Design

In this section we present the overall architecture of the system. We also review previous work onsimilar systems.

5.1 Literature Review

The requirements for our system are for it to be “context-aware”. What does this mean? The firstdefinition of “context-aware” was coined by Schilit and Theimer and defined it as “location, iden-tities of the people around the user, the time of day, weather information, etc.” (Schilit, Theimer1994). Anind Dey in “Towards a better understanding of Context and Context- Awareness” definescontext as:

“Context is any information that can be used to characterize the situation of an entity. An en-tity is a person, place, or object that is considered relevant to the interaction between a user and anapplication, including the user and application themselves.” (Anind K. Dey and Gregory D. Abowd).

We believe that this definition is accurate and complete. However we require for our system a morespecific definition of the types of context. Connor Graham and Jesper Kjelkskov have come upwith eight specific types of context. These are:

• Time

• Absolute location

• Relative location

• Objects present

• Activity

• Social setting

• Environment

• Culture

These definitions assume that context information is always accurate. However, this is not alwaysthe case. Fujinami’s “Context Distillery” recognizes two different types of context, namely base-context information and meta-context information. Base-context information is simply a subsetof Graham and Kjelkskov’s list. Meta-context information provides extra data about the contextinformation itself: the quality of context information (precision and accuracy) and the sensor (inputdevice) specifications. Fujinami explains that ‘no matter how much accuracy is improved in usingstate-of-the-art sensors, there is always some uncertainty involved in determining context. Thisshould be modelled explicitly as meta-context’ (Kaori Fujinami, Tetsuo Yamabe, Tatsuo Nakajima2004).

Among all architectural views of relational agents, one of those designs, which have been well recog-nized, views the agent as having the mental attitudes of Beliefs (B), Desires (D) and Intentions (I).These mental attitudes determine the system’s behaviour and are critical for achieving adequate

18

or optimal performance.

The BDI architecture theories and formalisms treat ‘intentions’ as being reducible to beliefs anddesires, or as partial plans of action that the agent is committed to execute to fulfill its goals (Brat-man 1987). Formalized definition of ‘intention’ are provided by Cohen and Levesque in terms oftemporal sequences of agent’s beliefs and desires. Alternative formalization has been provided byRao and Georgeff that integrates the theoretical foundations of BDI agents from both a quantitativedecision-theoretic perspective and a symbolic reasoning perspective (Rao and Georgeff 1991, 1995).Practical implementation of such architecture is also provided by them that integrates the imple-mentations of BDI agents from an ideal theoretical perspective and a more practical perspective.(Rao and Georgeff 1995)

5.2 Overall Architecture

We have identified two immediately obvious ways to design a system like ours. One way is to usea vertical layered architecture whereby information is passed up from low-level input devices, thento upper layers where that information is added to and converted to high-level representations, andfinally ending up being used by applications.

A second way is to use a horizontal design whereby agents provide information relating to theirinterests to other agents. In this way agents provide data as well as services to other agents and soagents can access situational context from the variety of agents dealing with specific context. Thisstyle of architecture supports both polling and subscription of information, and also distributedcomputation. It is also relatively easy to design. However there is not much control over contextualinformation. It is difficult to see how ideas such as conflicting information or information accuracycould be allowed for. History of information also seems difficult to add to the system. In addition,the design cannot handle large (for example, more than a hundred) numbers of agents as it isdifficult to produce a hierarchy of agents. Thus a large proportion of agents would be on the samelevel and use the same blackboard. This is not scalable.

Considering our two options, therefore, we decided on a vertical, two-tiered architecture consistingof an application tier (described fully in 7) tier and a context tier (described fully in 6). The contexttier provides a broad base of information both directly gathered from input devices and interpretedthrough the analysis of multiple other context information to be used by the application tier.The application tier comprises the usage of that information to provide services to users and inter-act with users through output devices. The context tier does not have any access to output devices.

We believe that this separation of information gathering and usage of that information allows forfreer application design. The application tier does not have to worry about the specifics of discov-ering where someone is - the information is provided for it already.

We will describe each tier separately in the following sections.

19

6 Context Tier

The context tier does all the work of noticing changes in environment and interpreting that datato determine context information.

In this section we describe firstly the context information we will be considering (which correspondsto Section 6.1). We then describe the desired properties of the context tier (which corresponds toSection 6.2. After that, we describe the overall framework we will be operating within (whichcorresponds to Section 6.3). Finally we enumerate the specific roles that we will design for thatexist in each layer (which corresponds to Section 6.4).

6.1 Context Information Considered

We recognize two different types of context information that need to be modelled. These are:

• Base context or simply context

• Meta-context

6.1.1 Base-context

We recognize the following types of base context:

• Identity - consists of a person. The attributes of identity are:

– Name the name of that person– Mood what mood the person is in.

• Location - is a (usually physical) location such as a building, street or town. Its attributesare:

– Name an identifier for the location– Weather the location’s weather

• Activity - consists of an occupation occurring over a time period such as a meeting, exercise,etc. Can involve one or more people. The following attributes of activity must be specified:

– Name the name of the activity– Starting Time - when the activity starts– Ending Time - when the activity ends

• Command - this represents a directive from a person or agent for the system to do something.By placing desires in the context tier we allow for multi-modal input (whereby directives canbe issued using many input devices and the application tier need not worry about which wayit was issued).

• Raw Data - we use this field for the context provider to specify extra raw data that it maylike to also send. The context provider would probably insert a reference to a place wherethe raw data is stored.

Contextual information consists of the relations of these context types. This is likely to be expressedin XML format and will be determined in detailed design.

20

6.1.2 Meta-context

We also recognize that there is information that refers to the context information. We specify thefollowing attributes of meta-context :.

• Accuracy

• Precision

• Time this context information was determined

• Time this context information expires

• Information about the context provider

6.2 Desired Properties

We wish the context tier architecture to have the following properties in addition to the design goalsspecified earlier (see Section 3). We can use this list to evaluate our design. The more propertiesthat the design supports, the better it is. However, note that these properties are not mandatory.

1. Support for history storage We would like a history of context information to be stored.This history could be used to predict future context information or to “seed” a learningapplication thus reducing its learning time. Without a history stored within the contexttier itself, applications interested in the history of a particular piece of context are forced tostore it themselves, which could involve duplication if multiple applications require the samehistory.

2. Support for meta-context We regard this as a highly important consideration. Meta-context allows for a much richer range of system behaviour. It supports conflict resolutionand learning to occur over that resolution. It gives the applications that use the contextinformation far more precise descriptions of the information the context tier provides. Forinstance, a voice identification role might provide context of identifying a person within alocation. However, it cannot provide complete accuracy in all conditions. One solution tothis problem is simply to only put up context information when the accuracy is above acertain threshold. However, we find this unsatisfactory as the threshold is hard-coded intothe system. In addition, the applications that use the context information may have beenhappy with the lower accuracy data. We believe the context architecture should allow passingpossibly incorrect information to the application layer with appropriate values set to indicatethe accuracy. For example, the voice identification role will send context information such as:Identity = MeilingLocation = 2.13Accuracy = 75 % to the blackboard.

3. Conflict resolution We want to support multiple sources of context information, all ofwhich could provide different answers with differing levels of certainty. Going back to ourexample, a voice identification role might provide context of identifying a person within alocation and a (visual) face recognition role might do the same. In the case that they bothprovide contradictory information, there should be an entity that takes both pieces of dataand decides on which is correct. In this case it might decide that since it is dark and the facerecognition role information had an accuracy of just 40%, compared to the voice identification

21

of 45%, the information supplied by the voice identification role is more likely to be correct.It might however downgrade the accuracy meta-context due to the conflict.

4. Feedback from application tier We would like to support learning within the contexttier itself. Applications that use contextual information have the option of informing thecontext tier of the accuracy of its information. For instance, an application might use contextinformation to perform an action. After the action is performed it may receive errors or abusefrom users which it interprets as meaning that the contextual information provided was infact wrong. It should then have the facility to inform the context tier of this state of affairs.The context tier might then use this information to downgrade the accuracy rating from aparticular sensor if it notes that the sensor is consistently producing wrong information. Notethat this is a separate issue from an application performing the wrong action with correctcontextual information.

5. Support for simulator We wish to support a context simulator. The simulator wouldproduce context information to simulate “scenarios”. This will be very useful in testing anddevelopment. It also allows the system to be used as a demonstration system where someevents are simulated in order to display a particular feature of the system.

6. Avoid context tier bloat It is quite easy to put too many components into the context tierand recognize too many things as context. We wish to avoid this by using only the types ofcontext specified in Section 6.1.

6.3 Overall Description

There are three main ways to describe contextual information, namely:

1. Centralised (Blackboard) - a blackboard represents a knowledge store of context that canbe added to and taken off by context providers and users. All context is stored here. Somepoints about the centralized system:

Advantages DisadvantagesIt is easy conceptually It is a single point of failure and a bottle-

neckIt allows for history storage It is not scalableIt has predictable access timesIt easily allows for conflict resolution andaccuracy feedbackIt is modifiable

Table 3: Advantages and Disadvantages of Centralized architecture

22

Figure 3: Centralized Architecture

2. Decentralized (Yellow pages, discoverer) - a completely decentralized context architec-ture. It consists of independent components that provide contextual data to context usersthat ask for it. A yellow pages or discoverer is used to list the context providers and the typeof context they provide. Context providers contact the discoverer and ask to be listed. Thecontext user then asks the discoverer to find it a context provider that will give it the contextit requires. The discoverer passes the context user the address of the context provider andthe context user can then ask the context provider for information using the poll or subscribedesign patterns.

3. Hybrid - a hybrid context system uses a combination of the above methods.

We have decided to use the “Blackboard” architecture because we feel that the benefits of itsrelative simplicity, allowance for conflict resolution and accuracy feedback outweigh its lack of scal-ability as our system is just a demonstration system that does not require much context information.

The context tier follows a layered architecture, whereby entities within a layer are aware only oflayers above and below them. We believe that such a separation allows for a cleaner design andsimplifies the later programming. It also satisfies our design goal of modifiability as changes to onelayer affects only the layer above it.

There are four layers in the architecture. These are:

1. Sensors

2. Cues

3. Context soup

4. Context resolution

23

The context tier architecture is depicted in the following diagram (Figure 4). Data flows up thediagram and is stored as knowledge in the blackboard.

Figure 4: Context Tier Architecture

Each layer will be described separately in the following sections.

6.3.1 Sensors

Sensors represent sources of information. They are generally physical devices attached to a PC,although they could also be virtual sources of information such as the Internet.

24

6.3.2 Cues

Cues are introduced to decouple the source of general information from specific and interpretedinformation. Cues extract specific information streams from sensors. For example, a microphonesensor may contain pitch, loudness, frequency as well as language information. Cues extract thatinformation and frequently convert it into more accessible formats.

6.3.3 Context Soup

The Context Soup consists of context providers that post context information (with associatedmeta-context) to a blackboard. We consider the blackboard to be a black box in this document.Context providers send information to the blackboard, where it is stored and a history maintained.In the detailed design phase we will determine the exact nature of the blackboard and the storagemechanism.

6.3.4 Context Resolution

The context resolution layer comprises the interface to the application tier. There are two mainentities in this layer. The first is a Resolver, which takes context information provided by ContextProviders (which could be conflicting since it is gathered from multiple sources) and adds or mod-ifies the meta-context data. In the case of multiple sources of the same context information, theResolver mediates between them to resolve conflicting data. It might, for instance, take locationinformation from a face recognition Context Provider and also from a bluetooth point of presenceContext Provider. In certain circumstances (such as rainy weather, dark outside), the Resolver maydecide that the bluetooth point of presence is a more reliable source of information as compared toface recognition and may judge in its favour. It might also, with respect to the conflict, lower theaccuracy rating of the data provided by the context provider. The Resolver also has a feedbackfunction whereby agents from the application tier can send information on the accuracy of pastinformation provided to it. The Resolver could then learn from past mistakes and produce bettermeta-contextual information.

The second entity in this layer is a Context Gateway. This acts as a portal into the context tierfor the application tier. Applications ask the Context Gateway for contextual information and ittakes it from the blackboard and passes it to the applications.

6.4 Role Hierarchy for Context Tier

In this section we describe the roles that the context tier could have. We anticipate doing a detaileddesign and implementation of all of these roles, however in the detailed design phase we reserve theright to not do a detailed design and implementation of all roles.

25

Figure 5: Context Tier Role Hierarchy

The above diagram (Figure 5) is a slightly simplified representation of all the roles in the contexttier. As we can see, information from sensors is separated into specific cues, which are used bycontext providers. These context providers post context information to the bottom layer of a two-layered blackboard. In the context resolution layer, context resolvers take the context informationposted by the context providers and ensure that non-conflicting context information is posted tothe upper layer of the blackboard. Not shown in the diagram is that all the context posted ontothe bottom layer of the blackboard is reposted (with possible alterations of meta-context) onto the

26

upper layer.

6.4.1 Sensor Layer

The sensors we have currently are:

1. Web-cams (one for each zone)

2. Microphones (one for each zone)

3. Clarinox devices

Some other sensors we are considering using are:

1. Thermometer

2. Motion sensor

3. Radio Frequency (RF) sensor

6.4.2 Cue Layer

Roles in the cue layer have the responsibility of converting an input stream to an output stream.We identify seven cues for our system. These are:

1. SpeechToTextCueRole.Description: This cue extracts the information stream of the words “heard” by the micro-phone. It converts speech into text.Input: MicrophoneOutput: Text

2. NoiseIntensityCueRole.Description: This cue extracts the loudness of the environment being listened to by themicrophone.Input: MicrophoneOutput: Amplitude of noise (i.e. decibel rating or similar).

3. AudioCueRole.Description: This cue still needs to be decided based on prototyping. The cue is designed forthe voice identification function and will extract whatever the voice identification requires.Input: MicrophoneOutput: still to be decided - whatever voice id requires

4. BrightnessCueRole.Description: This cue extracts the brightness of the environment from the web-camera.Input: Web-cameraOutput: Brightness rating

5. VideoCueRole.Description: This cue provides a simple video stream from the web-camera.Input: Web-cameraOutput: Video stream

27

6. BluetoothDiscovererPoPCueRole.Description: This cue uses a clarinox device to discover nearby bluetooth-enabled devices. Itoutputs lists of the devices discovered (their bluetooth addresses and friendly names).Input: Clarinox deviceOutput: List of devices discovered

7. BluetoothPDADataCueRole.Description: This cue extracts the data sent to the Clarinox device by PDAs using bluetoothtransmission.Input: Clarinox deviceOutput: Data sent to device.

6.4.3 Context Soup Layer

As described earlier in Section 6.3.3, this layer contains context providers and context interpreters.Context providers take cue input and post context information onto the blackboard. We haveidentified eight context providers for our system.

1. FaceIdentifierRole.Description: This context provider is a face recognition program that knows what room it islooking at. Therefore once it recognises a face from the video input it is able to specify thatthe person it recognised is in that room.Input: VideoCueRoleOutput: (identity, location)

2. VoiceIdentifierRole.Description: Similar to the FaceIdentifierRole but uses audio input to determine who a personis.Input: AudioCueRoleOutput: (identity, location)

3. BluetoothLocatorRole.Description: This context provider uses the information about the devices discovered by theBluetoothPoPCueRole and its knowledge of the location of each Clarinox device to specifythat the owner of the device discovered by the Clarinox device is in that location.Input: BluetoothDiscovererPoPCueRoleOutput: (identity, location)

4. CommandInterpreterPDARole.Description: This context provider uses the data sent from a PDA to a Clarinox device todetermine if the owner of the device is sending a command to the system. If so, it posts thecommand to the blackboard.Input: BluetoothPDADataCueRoleOutput: (identity, command)

5. CommandInterpreterVoiceRole.Description: This context provider is analogous to the CommandInterpreterPDARole. Ittakes spoken text from the SpeechToTextCueRole and analyzes it to determine what, if any,commands have been given. It posts those commands to the blackboard.Input: SpeechToTextCueRoleOutput: (identity, command)

28

6. ContextSimulatorRole.Description: This context provider is used for testing purposes and to do “scenarios” wherebywe can simulate the existence of certain context information and display features of the system.It can post all context information.Input: NoneOutput: All context

7. MotionAnalyzerRole.Description: This context provider determines the current motion state of people by analyzingvideo input.Input: VideoCueRoleOutput: (identity, motion, location)

8. MoodAnalyzerRole.Description: This context provider determines the current mood of people by analyzing howloudly they are speaking.Input: NoiseIntensityCueRoleOutput: (identity, motion, location)

6.4.4 Context Resolution Layer

In this layer context is determined through the synthesis of other context information. This layerprovides an interface for the application layer. As specified in Section 6.3.4, a context resolverand context gateway are components in this layer. The context gateway is a gateway to the black-board for the application tier. It retrieves context information (and history if requested) from theblackboard when asked by applications. The context resolver performs two major functions for oursystem, specified below:

1. IdentityResolverRole.Description: Synthesizes the (identity, location) information produced by the three identitycontext providers.Input: FaceIdentifierRole, VoiceIdentifierRole, BluetoothLocatorRoleOutput: (identity, location)

2. CommandResolverRole.Description: Synthesizes the (identity, command) information produced by the two commandcontext providers.Input: CommandInterpreterVoiceRole, CommandInterpreterPDARoleOutput: (identity, command).

In addition the context gateway is in this layer.

• Context Gateway.Description: Is an entity which can be used by the application tier agents to retrieve contextinformation.

29

7 Application Tier

This sections describes the upper layer of the system, namely the Application Tier, where systemlevel services are provided.

7.1 Desired Properties

We wish the Application Tier architecture to have the following properties in addition to the designgoals specified earlier. We can use this list to evaluate our design.

1. Context awareness: We would like our agents to be able to provide services in a contextadaptive manner, i.e. what the agent actually does depend a lot on the current environmentit believes it is in.

2. Intent inferences: We would like our agents to be able to deduce new beliefs themselvesbased on the context information (retrieved from the context tier). For example, upon re-ceiving the following context information:

• Person A is someone ‘new’

• Person A walks into room A

• Person A walks out of room A and into the next room, room B

• Person A walks out of room B and into room A again

our guiding agent can infer that person A needs to be guided. Intent inferences make agentsmore intelligent by allowing agents to be able to deduce new beliefs itself without having toprovide more context information to the agents.

3. User preferences: We would like our agents to be able to deduce new beliefs from the userpreferences previously learnt. For example, upon receiving the following context information:

• Person A is sleeping

• Person A has a schedule at 9am

• The current time is 8am

the wake-up agent, given the three context information and from the user preferences, knowsthat person A prefers to be waken up thirty minutes before a schedule. Hence, it shoulddeduce a new belief that ‘Person A needs to be waken up at 8.30am’. Agents including userpreferences to deduce new beliefs makes them more intelligent and will usually produce moresatisfying outcomes from the user.

4. Trending: We would like our agents to be able to deduce new beliefs from trends, i.e. usualbehaviour. For example, person A always wakes up at 9am. From the usual trend (usualbehaviour of person A), the wake up agent should deduce a new belief that ‘Person A needsto be waken up at 9am’. Agents deduce new beliefs from the user’s usual behaviour, withoutthe needs to provide all the information to agents, this makes the agents more intelligent.

5. Learning: We wish the performance of our system to be improved over time, i.e. a certainlevel of learning needs to be designed into the Application Tier. Therefore all actions needto be evaluated for effectiveness, typically through user’s feedback. Learning comes into play

30

when it has been identified that something has gone wrong, in which case the agent needs tofigure out the likely cause of the mistake and either correct the mistake directly or store it asa piece of new knowledge.

6. Interactions with other agents: We would like our agents to be able to interact with eachother. Agents should be able to receive information from other agents and to provide servicesrequested by other agents. For example, the communicate agent may receive a request fromthe security agent to send a message to person A’s PDA. This allows agents to help eachother out and so provides a more efficient system. More importantly, this allows us to achieveour high level goals.

7. Modifications of intentions over time: It is desirable that the intentions of agents canbe modified over time. For example, an intention of the communicate agent is ‘To send amessage to person A by SMS’. However, it may fail to perform this action as person A hasswitched off his/her mobile phone. Because of that, the communicate agent should modify itsintention to find an alternative way to send the message to person A, e.g. ‘To send a messageto person A’s PDA’ instead.

8. Prioritise intentions: We wish that the intentions of agents are prioritised so that intentionsthat are more critical or have no other alternatives would be able to use the device(s) requiredand to perform the action first. For example, both the wake up agent and the communicateagent are required to use the speaker device to carry out the intention. An intention resolvershould prioritise the intentions from the agents. If the intention of the wake up agent has ahigher priority, this may be because it is more critical or there are no other alternative waysto carry out the intention, then it should be performed before the one of the communicateagent.

7.2 Overall Description

The Application Tier consists of two types of agents. There are actuator agents that receiverequests from other agents to perform an action using an actuator (output device). These agentsare quite simple and will not be described further. There are also BDI agents that are responsiblefor completing a specific high level task, such as guiding a user from one location to another. Theoverall design of these individual agents adopts the Belief-Desire-Intention (BDI) architecture. Seesection 5.1 for the description of the BDI architecture. The following sections explain the keycomponents that constitute each agent.

• Beliefs: The beliefs of an agent in our system describe the situation the agent is in. Thebeliefs contain information the agent believes about the environment it is in (the contextinformation) and they also contain information that is internal to the agent.

• Desires: Desires are the situations that an agent wants to realize. The desires describe a setof intentions the agent is supposed to achieve once certain beliefs of the environment or itselfare met. The desires may potentially be conflicting to each other, and based on the agent’scurrent beliefs at a particular moment, they may give rise to intentions, which are morespecific goals, to be carried out in order to achieve the desire. See below for the descriptionof Intention.

• Obligations: Obligations for an agent in the system are the services that the agent providesto other agents. They could be imagined as intentions that are imposed by external parties

31

instead of internal beliefs. For example, the communicate agent may receive a request fromthe security agent to send a message to person A’s PDA. From the obligation of the securityagent, the communicate agent should now have an intention of ‘To send a message to personA’s PDA’ and subsequently produce a plan to carry out the intention. The obligations mayor may not be carried out depending on the agent’s current situation.

• Intentions: Intentions are actions to be taken to fulfill a certain desire once certain beliefsare present. The actions may not be specific enough and are often too abstracted to beexecuted by the physical system.

• Plans: In order to carry out its intentions, an agent constructs plans, which are sequencesof instruction or commands to be taken by the system. Because plans consist of actions tobe taken that will affect the external environment, they need to be checked against all otheragents’ plans to make sure no conflict will result from trying to affect the same environment.(Refer to section 7.2.2 for description on Intention Resolver)

Figure 61 details the architecture of the Application Tier in a graphical representation. Thereare three layers in the Application Tier, i.e. Situation Assessment, Response Planner and Executorand Evaluator. Each layer is described in the following sections. For a more concise description ofthe execution of the BDI agents in the system, we order the execution into a number of phases asdescribed below.

7.2.1 Situation Assessment

The main purpose of the Situation Assessment phase is to produce the correct and complete set ofbeliefs, which is achieved by:

1. Context Retriever: The Context Retriever is responsible for constantly retrieving contextinformation that is useful for the agent from the Context Tier and stores them into theagent’s belief base. These form the beliefs that are directly available from the environment.

2. User Preferences Processor: Based on the current knowledge of the user’s preferences pre-viously stored, the agent brings up additional beliefs that are user-specific. E.g., ‘Thomasprefers being woken up thirty minutes before meeting’.

3. Intent Inference Processor: The agent performs logic deductions on the beliefs that are cur-rently stored in the belief base and deduces more beliefs that are not directly available fromthe environment. E.g., ‘Thomas wants to cook, because he has turned on the stove andopened the fridge’.

4. Trending Processor: Based on context history and the results of statistical analysis, theagent ‘guesses’ about the things that are likely to be true without being told explicitly. E.g.,‘Thomas will eat pasta today, because statistics show that he eats this every Thursday’.

7.2.2 Response Planning

There are three main objectives for the Response Planning phase:

1. Maintain current desires and generate new desires;1The ovals in the diagrams represent processes, and the cylinders represent storages.

32

Figure 6: Application Tier Architecture

33

2. Identify and decide to pursue the realizable intentions;

3. Produce detailed step-by-step plan to carry out its intention.

These objectives are to be achieved by:

1. Intention Maintainer: Based on the current beliefs and desires, the Intention Maintainerdecides whether to pursue, drop or generate additional desires depending on its feasibility.It also consider if there is any external obligations requested. Upon deciding which desire orobligation service is to be pursued, it forms intentions based on priority.

2. Plan Maintainer: Once an intention has been formed by the Intention Maintainer, the PlanMaintainer generates a detailed step-by-step execution plan consisting the actual actions tobe taken to realize the intention and also the current plan.

3. Plan Resolver: In order to make sure that no two agents’ plans will lead to affecting thephysical world in a conflicting way, the plans are first submitted to an (external) Plan Resolverbefore being carried out. Upon conflict, the agent with lower priority, deemed by the PlanResolver, will need to revisit the process of formulating and submitting its plan again untilthe plan is conflict free.

7.2.3 Execution and Evaluation

The Executor is responsible for interfacing with the physical actuators by generating and send-ing out correct command to different devices. Before the whole execution process gets started, theExecutor also has to notify the Evaluator requesting for evaluating the effectiveness of the execution.

The Evaluator is responsible for monitoring the effectiveness of the execution for the ultimate aimof improving performance over time. Upon realizing something goes wrong, by examining thecontext information after execution, it needs to figure out what exactly needs to be improved. Itthen needs to either fix the erroneous context information straight away (by sending informationto the Context Resolver) or store the knowledge learnt into the knowledge base for increasing theperformance next time.

Figure 7 describes the architecture of the Application Tier in action.

34

Figure 7: Sequence Diagram of an Agent in Action

35

7.3 Role Hierarchy for Application Tier

The following diagram shows the role hierarchy for the Application Tier.

Figure 8: Application Tier Role Hierarchy

36

This role hierarchy can be described as follows. The Communicator Role will be used as an examplehere.

1. Initially, the CommBeliefProducer produces the belief that a one way communication needsto be set up.

2. This belief is sent to the CommunicationPlanner.

3. The CommunicationPlanner has the capability to establish a one way or two way connection.Since the belief is that a one way communication needs to be set up, it will then have thedesire to establish communication and send message.

4. If there is no information on what medium to use from its beliefs, it will get this informationfrom User Preference.

5. From Figure 9, CommunicationPlanner consists of the IntentionMaintainer and the Plan-Maintainer. If there are both desire and request from other agents to achieve, the Intention-Maintainer will have to resolve this contention and choose one to execute. Once an intentionis chosen, the PlanMaintainer will form the plan. In the Commmunicator’s case, the planformed will have to include the medium of transmission (the device).

Figure 9: Response Planner

6. This plan will be forwarded to the PlanResolver.

7. The PlanResolver will check with the device controller. If that device only allows one agentto access it at a point, then it will send a message back to the PlanMaintainer, saying howlong the PlanMaintainer has to wait.

8. Based on this information, the PlanMaintainer can either wait, or form another plan. Steps4 and 5 are repeated until PlanResolver gives the green light.

9. If that device can allow more than one agent to access it at the same time (for example, Mo-bileController allows more than one SMS to be sent at the same time), then the PlanResolverwill always give the green light.

10. Once the plan has been approved, the PlanMaintainer will forward the plan to the Device-Controller, e.g. PDAController or MobileController.

11. These device controllers will get the message sent.

37

1. Communicator Agent

As can be seen from Figure 8, the Communicator Agent can implement the functionalities ofthe following roles:

(a) CommBeliefProducer Role

(b) CommunicationPlanner Role

The Communicator Agent needs to interact with the following roles:

(a) PlanResolver Role

(b) CommEvaluator Role

(c) Either SpeakerController, DisplayController, MobileController, PDAController and Modem-Controller Role

The table below describes the Communicator Agent.

Role CommunicatorBeliefs

(a) Context Information Command to establish communicationsCommand to send messageLocation of recipientLocation of sender

(b) Intent Inference Scheduling a meeting with others who are not present sug-gests that subject will want to communicate the meeting timeto the attendees.

(c) User Preferences Preferred medium for communicationLength of time preferred for communication

Desires When commanded by people, establish communications orsend message to another party

Obligations When requested by agents, establish communications or sendmessage

Execution components SpeakersDisplaysModemMobile PhonePDA

Table 4: Description of the Communicator Role in the Application Tier

38

2. Greeter Agent

As can be seen from Figure 8, the Greeter Agent can implement the following roles:

(a) GreetBeliefProducer Role

(b) GreetPlanner Role

The Greeter Agent needs to interact with the following roles:

(a) PlanResolver Role

(b) GreetingEvaluator Role

(c) Either DisplayController or SpeakerController Role

The table below shows the architecture of the Greeter Agent.

Role GreeterBeliefs

(a) Context Information The identity of the person who walked into the roomThe time of the dayThe date

(b) Intent Inference If someone walks into a room, and this person has never beengreeted before, then this person needs to be greeted (is thisconsidered as Intent Inference? not very sure)If the schedule says there is a meeting soon, and the personis still sleeping, then this suggests the greeting agent needsto wake the person up

(c) Trending When does this person usually come to work (first time en-tering the zone) and hence need to be greeted

(d) User Preferences Preferred name to be calledPreferred tone of greetingPreferred words to use (e.g. Good morning vs Goodday)Preferred volume and voice (male or female)Preferred type of greeting (voice or display. E.g. if thatperson is deaf, then cannot greet using voice)

Desire When someone walks into the room or a closed zone, greetthe person(s)

Obligation When requested by other agents, greetExecution components Speakers

LightsDisplay

Table 5: Description of the Greeter Role in the Application Tier

39

3. Guider Agent

As can be seen from Figure 8, the Guider Agent can implement the following roles:

(a) GuidingBeliefProducer Role

(b) GuidePlanner Role

The Guider Agent needs to interact with the following roles:

(a) PlanResolver Role

(b) GuidingEvaluator Role

(c) Either PDAController or SpeakerController Role

The table below shows the architecture of the Guider Agent.

Role GuiderBeliefs

(a) Context Information Command to guide a person to a destinationSomeone unknown just entered the building (or level 3)This person looks lost

(b) Intent Inference If a person walks into the building, and its a fresh face, thenthis suggests there may be a need to guideWhen the communicator role sends a message like ”PersonX is coming, but he is unfamiliar with the building”, thissuggests that person X needs to be guided. (unfamiliar is akeyword here)

(c) Trending Current context says that there is a unknown person in thisroom; statistic says that every second unknown person needsto be guided; context history says that this is the secondunknown person. Therefore, this person needs to be guided.

(d) User Preferences Certain places that he prefers not to pass throughIs this person handicapped? (voice vs display)If a person needs to be guided, then he is likely to be a guest.Therefore, it is unlikely there is information on him in thedatabase.

Desire When commanded by people, guide subject from startingpoint to destinationWhen there is a belief that subject needs to be guided, guidesubject from starting point to destination

Obligation When requested by other agents, guide the subject fromstarting point to destination

Execution components Environment speakersPDA speakersPDA display screen

Table 6: Description of the Guider Role in the Application Tier

40

4. Recorder Agent

As can be seen from Figure 8, the Recorder Agent can implement the following roles:

(a) RecordingBeliefProducer Role

(b) RecordingPlanner Role

The Recorder Agent needs to interact with the following roles:

(a) PlanResolver Role

(b) RecordEvaluator Role

(c) Either CameraController or MicController Role

The table below shows the architecture of the Recorder Agent.

Role RecorderBeliefs

(a) Context Information Command to recordType of recording: voice or image?If voice recording is to be done, then need to know locationof recordingIf image recording is to be done, then need to know subjector event to record

(b) Intent Inference If a meeting is taking place in a room, and the secretary isabsent from the meeting, this suggests that the meeting willneed to be recorded

(c) Trending Current context says that there is a meeting of type X goingon in room Y; trending says that this type of meeting in thisroom almost always requires to be recorded. Therefore, thismeeting will be recorded.

(d) User Preference: Preferred format of recordingDesire When commanded by people, start voice recording of a par-

ticular meetingWhen commanded by people, start image recording of a par-ticular event (e.g. demonstration or presentation)

Obligation When requested by other agents, record an event (either voiceor image recording)

Execution components MicrophoneCameraMobile phone

Table 7: Description of the Recorder Role in the Application Tier

41

5. Scheduler Agent

The Scheduler Agent is responsible to achieve the ‘To Schedule’ goal. It will take care ofscheduling meetings at a particular room, and also keep track of the users’ schedule. TheScheduler Agent also collaborates with the Greeter Agent to wake a person up. As can beseen from Figure 8, the Scheduler Agent can implement the following roles:

(a) SchedulingBeliefProducer Role

(b) ScheduleConflictResolver Role

The Scheduler Agent needs to interact with the following roles:

(a) PlanResolver Role

(b) ScheduleEvaluator Role

The table below shows the architecture of the Scheduler Agent.

Role SchedulerBeliefs

(a) Context Information Command to schedule an activityTime and date of activityLocation of activityRequired attendees of the activityType of activity

(b) Intent Inference If the communicator role is sending a message that says “I’llmeet you tomorrow at 2pm in my office.”, then this suggeststhat a meeting at the sender’s office will need to be scheduled.

(c) Trending None(d) User Preference Preferred time to be reminded of event (X hours/day before)

Preferred method of reminder (e.g. email, PDA, voice ordisplay)Whether this activity needs to be recorded or not

Desire When commanded by people, schedule an event for a partic-ular time and date at a particular location for either user orroom.

Obligation When requested by other agents, schedule an event for eitherthe user or the location

Execution Components ModemPDASpeakerDisplay

Table 8: Description of the Scheduler Role in the Application Tier

42

8 Reflections on the methodology

In this section we detail some reflections on the methodology we used in creating this document.

We found that the delineation of SRS and SADD was not well defined and that a lot of theinformation contained within the SRS was not useful in creating the SADD. We attribute this toa lack of an overall description of the system in terms of functional requirements or even a holisticgoal description. We found that the first step for the design team was to create a goal hierarchy inwhich we fit the goals described in the SRS. We felt that this step would have been better achievedby the requirements team and placed in the SRS. The goals depicted in the SRS were quite detailedbut were quite disconnected and did not seem to fit together into one structure.

We also found that the role hierarchy and the architecture needed to be written up concurrently- you need to know what architecture you will be using to put the roles into place. They both feedinto each other. This however was not provided for by the methodology.

A major shortcoming of the ROADMAP methodology, we thought, was that the idea of rolesdid not seem to be a natural way to describe the system in the way that we used them. We felt thatthe granularity inherent in identifying all the roles of the system at the start of the process wasvery difficult to accomplish. According to the methodology, only then are those roles aggregatedinto agents. A more natural way to design the system would have been a top-down approach wherewe identified the agents required and from them determined the roles required. However, we didfind a benefit of flexibility in the ROADMAP way, in that roles could be handed out very late inthe design process to agents on the basis of design criteria such as response time, etc. Perhaps anadditional step before the construction of the role hierarchy where broad categories of functionality(not necessarily agents) are determined may be useful.

43

9 Appendices

9.1 Change Log

Date Section DescriptionsDD/MM/YY Section number Description of the changes.

Table 9: Change Log

44