Planner System Design

There are two main challenges for the proposed planner framework. The first challenge is to identify the user goal following the user activity and the second challenge is to create a plan that manages a number of services in order to reach the user goal.

Figure 4-7 presents a diagram showing the flow of information between the main proposed planner components. The user produces some actions (user activity) that are captured by the home sensors. The user actions are modelled and are compared with predefined action models until the goal is identified (see next section). When the goal has been identified, a forward chain planner creates a plan to reach that goal considering the state of the home environment (context). Finally, the plan actions are sent to the OSGi gateway that takes care of the service management.

Figure 4-7: The two phases in proposed planner framework: Goal Identification and Plan Creation.

4.5.1.1 Phase 1- Goal Identification

User activities are sensed by a number of sensors located in the house environment and also carried by the user (e.g. RFID tags, Sun SPOTs, etc.). When the user performs an action, this action is captured and compared with the set of predefined actions from an action database. If this action is mapped to only one goal, then this goal description is sent to the Phase 2 of the planner framework. If an action cannot determine a goal, or the action determines more than one goal, a user is asked to select a goal out of a number of determined goals.

User Action to Goal Mapping User

Activity

Goal Found

Have Goal Backward

Chaining planner OSGi

Context

Hardware

Figure 4-8: The structure of a Hierarchical Goal Determination Process based on action mapping. (a) Action maps to a single goal, (b) action maps to multiple goals until a third action is performed.

In Figure 4-8, the goal “Watch movie” in (a) consists of the simple sequence of two actions: “sit on couch” and “point to the movie player”. The action “sit on couch”

may lead to a number of possible actions such as watch movie, listen to the radio, read a book, just relax, make a phone call, etc. These actions are not listed on the diagram of Figure 4-8 in order to simplify the diagram.

In (b) the goal determination process is more complicated because on the second user action: “point to the TV” the action-to-goal structure cannot map to a single goal and needs another user action to identify the goal. The third action: “Points to window”

triggers the goal determination process to identify the goal as “watch the weather forecast”.

4.5.1.2 Phase 2- Plan Creation

The plan creation and execution takes place inside a rule engine mechanism. Rule engines implement a forward, backward or bi-directional chaining mechanism.

User sits on couch

Forward chaining: When one or more conditions are shared between rules, they are considered "chained." Chaining refers to sharing conditions between rules, so that the same condition is evaluated once for all rules.

Backward chaining: Backward chaining is very similar to forward chaining with one difference. Backward chaining engines query for new facts, whereas forward chaining relies on the application asserting facts to the rule engine. Backward chaining rule engines implicitly create sub-goals and use those sub-goals to execute queries.

Bi-directional chaining: When rule processing operates in both modes, it is considered to be bi-directional.

In this proposed planner framework version, a number of predefined plans have been modelled and stored. Each of these plan models contains a number of paths and nodes with service control information (e.g. service LIGHTS_ROOM1:TURN_ON).

Each node can have two states: satisfied or unsatisfied based on the outcome of its control information and service availability. When a node of a predefined plan can be satisfied then the route to this node and the node is copied to the current (new) plan. If a node of the predefined plan cannot be satisfied then the planner mechanism moves to the next node. The following example describes this planning process.

A goal is identified from the previous process and a predefined plan (see Figure 4-9) is queried from the predefined plan database. The planner mechanism moves to the first node of the predefined plan (Service 1). This service is available thus this node can be set to a satisfied state. It is copied to the current plan and the planner mechanism moves to the next set of nodes (Service 3, Service 4). Service 3 is not available and returns an unsatisfied state result. The planner moves to the next node (Service 4) which is available and is copied to the current plan. This process continues until all the nodes of the predefined plan have been checked and a new plan, the current plan, has been created. The created plan then is sent to the OSGi gateway that will process every plan’s node in order to manage the plan’s services based on the plan.

Figure 4-10: Forward chain plan for the Watch Weather Forecast goal

Figure 4-10 shows the plan created based on the activity-to-goal mapping of Figure 4-8 (b). The goal “Watch Weather Forecast” triggers the weather service to take weather information from the Internet and from the local weather sensors. The weather service formats this information and selects Television as the output method for the weather data.

Watch Weather Forecast

Weather Service Internet

Forecast

Input

Local Weather Station

Input

PDA Television Desktop

PC

Output Goal

Service 1 Service 2

Service 3 Service 4 Service 5

Service 8

Service 7 Service 6

Figure 4-9: Forward chain plan