A Context-Driven A Context-Driven Programming Model for Programming Model for

Pervasive SpacesPervasive SpacesHen-I Yang, Jeffrey King, Sumi Helal, Erwin JansenPervasive Computing Lab, University of Florida

www.icta.ufl.edu

The Need for Programming Model

• Development with ad-hoc strategy in integrated environment is not scalable

• Adjustment and adoption are not straight forward without programming model, which reduce configurability and usability

• Cost of deployment is high without proper programming model, preventing mass real-world deployments

• Proper programming model can incorporate and enforce critical features such as security, privacy and safety

Problem with Existing Models

• Prone to conflict, not effective in detecting or handling of conflicting instructions from multiple services

• Lack the capability of proving a real-time, at-a-glance “big-picture” of overall state

• Lack of the concept of emergency

handling routine

The Objectives

• Define a new formal framework for contexts

• Create an ontology based context-driven programming model– Resolve problems discussed in the

previous slide• Design a programming procedure to

assist in programming a pervasive computing space

The Promise of the Context-Driven Model

• A formal, in-depth understanding of contexts in pervasive computing

• Capable of evaluating potential actions based on currently active context

• Capable of detecting conflicting directives

• Capable of avoiding and handling dangerous emergency situations

Scenario

• Matilda is 85-year old, living alone in a free-standing smart home, and has mild dementia.

• The services in the smart house provides cognitive assistance.

• Matilda sears a rib eye steak on the stovetop for dinner and generates a lot of smoke as it cooks.

• The smoke clouds up the kitchen, and soon sensors detect that the air quality in the house is degrading.

• The services in the smart house alert her to the dangers, cue her for response, or even resolve the problems automatically.

• The development of these cognitive assistance services using our context-driven programming model is described.

Sensor

• Definition: SensorA sensor is a function that produces an output at a given time within the universe U in a particular domain D.

f i j : U Di

• ExampleThe air quality can be monitored using a Smoke Detector Sensor, represented in our model as the function:

qualityairectorsmoke DUf _det_ :

Actuator

• Definition: Intentional Effect of ActuatorAn intentional effect of an actuator a is the set of states that possibly can arise due to invocation of that actuator:ga : U 2 U

• Example“Open Window” can take us proactively from the Murky Air to Clean Air context, so the intentional effect is described in our model as:

:Murky air Clean air qualityairventg _

Context: Taxonomy and Interpretation

• Definition: TaxonomyContext descriptions in language L are formed using the following syntax rule, given C and D are two contexts:

C, D AC | ⊤| ⊥ | ¬C | C ⊓D | C ⊔D where AC denotes an atomic context.

• Definition: Interpretation FunctionWe define the interpretation I as follows:

ACI ⊆ U ⊤I = U ⊥I = ∅(¬C)I = U – CI (C ⊓D) I = CI∩DI (C ⊔D) I = CI∪DI

• Definition: Context RelationsInclusion and equality are defined as follows:

Inclusion: C ⊑ D, interpreted by CI ⊆ DI

Equality: C ≡D, interpreted by CI = DI.

Context: Taxonomy and Interpretation (Cont)

•ExampleTaxonomy:

Warm Indoor, Cold Indoor and Hot Indoor are temperature related atomic contexts.Interpretation:Indoor temperature reading:

18°C - 25°C: Warm Indoor < 18°C: Cold Indoor > 25°C: Hot Indoor

Active Context

• Definition: Active ContextThe active context of the space R: U 2 C is:

R = {C | u I ∈ C Ii}

• ExampleIf the current temperature reading from the indoor thermometer is 24°C then Warm Indoor is the current active context

Action

• Definition: Statement SequenceGiven a set of actuators A, a statement sequence S, also known as a sequence of actions, is defined as follows:S ::= ↑ai | ↓ai | S1; S2

Where ↑ai turns actuator ai ∈ A on, ↓ai turns actuator ai off,

and the symbol ‘;’ is used to indicate that we first perform statement S1 and after which we

execute the remaining statement S2.• Example

The statement S::= ↑vent; ↓stove depicts the sequence of action in which the vent is turn

ed on first, and then the stove is turned off

User and Intention

• Definition: UserA user can be denoted by a tupleB ::= <T ; I; D, X, I>Where

T and I are the taxonomy accompanied by the interpretation of the user,

D represents the specify desired contexts specified by user, X denotes extremely undesirable impermissible contexts,

and I : C S be a mapping from context to statements that shows possible intentions to transit away from context C.

• Definition: Active and Passive IntentionsAssume current active context is represented by R the following transitions defined the activeness and passiveness of intentions:Active Intention (I a):

Passive Intention (I p):

DRI aIa :

RDI pIp :

Programmable Pervasive Space

• Definition: Programmable Pervasive SpaceA programmable pervasive space can be denoted by a tuple consisting of:P ::= <B;R; S; 2A>Where B is the representation of the user,

R the currently active context, S the statements we are currently processing and 2A the set of actuators currently active.

(De)Activation and Environmental Effect

• Definition: Context Change<b; f (u); S; a> <b; f (u’); i (R(f (u’))); a>

where R(f (u’) ≠ R(f (u))• Definition: Activation and Deactivation of Actuators

The contexts of a space can be changed by activating or deactivating actuators within the space. These actions can be described as below:Activation: <b; u; ↑ai; a> <b; u; ε ; a ∪ ai>

Deactivation: <b; u; ↓ai; a> <b; u; ε; a \ ai>If the set of active contexts has changed, we obtain the intentions from the user and execute the desired sequence of actions.

• Definition: Environmental Effect<b; f (u); S; a> <b; f (u’); S; a> where f (u) ≠ f (u’)

Programming Procedure

• Design the Context Graph: – Decide what the domains of interest are, and what

the contexts of interest within these domains are. – Heavily influenced by availability of the sensors, the

services planned, and the users' belief and desires.

• Interpret Sensor Readings: – Define interpretation functions from ranges or

enumerated possible reading values from various sensors to atomic contexts appearing in the context graph.

• Describe Intended Behaviors: – Describe intended behaviors in terms of action

statements associated with each context in the context graph, so that smart space knows which actuators to manipulate when various contexts become active.

How does it work?

Murky air

Clean air

Open window

Turn on stove

Turn on vent

Context Intentional EffectPreferred Context Impermissible Context

Blown fuse

Medium power draw

Low power draw

Turn on stoveTurn on heater

Turn on ovenTurn on vent

Turn on stoveTurn on heater

Turn on ovenTurn on vent

Overcooked Steak

Turn on stove

Turn on stove Cooked Steak

Raw Steak

Warm Indoor

Open window

Hot Indoor

Cold Indoor

Open window

Turn on A/C

Turn on A/C

Turn on heater

Turn on heater

1. Design the Context Graph2. Interpret Sensor Readings3. Describe Intended Behaviors

Temp > 25°C

25°C ≥ Temp ≥ 18°C

18°C > Temp

Internal Temp > 59°C

49°C > Internal Temp

59°C ≥ Internal Temp ≥ 49°C

Concentration ≥ 200 ppm/min

Concentration < 200 ppm/min

PowerDraw > 300 W

PowerDraw < 70 W

300 W ≥ PowerDraw ≥ 70 W

Capabilities of Context-Driven Programming Model

• Evaluating Potential Actions

• Detecting Conflicting Directives

• Avoidance and Handling of Impermissible Contexts

Air Quality Control: S1 = {↑stove} Cooking: S2 = {↓stove} until R=cooked steak

S::=↑heater; ↑vent; ↑oven

Conflict! Notify User

R = blown fuseEmergency Handling Routine for “blown fuse”: prevent ↑oven and notify user

Conclusion

• Existing programming models for pervasive computing only focus on individual goals and lose sight of the overall picture, leading to conflicts and erroneous behaviors.

• Our proposed context-driven programming model uses contexts as the primary building blocks. – Build the context graph that captures all possible

states of interest in the smart space.– Contexts are marked as desirable, transitional, or

impermissible. – Programmers define the intentional effects of

actuators in terms of transitions from one context to another.

– The system identifies active contexts from sensor readings and choosing actions toward more desirable contexts.

Conclusion [cont]

• The benefits of context-driven programming model– Improved coordination using explicitly defined context-

based behaviors – Enhanced safety guarantees and real-time, at-a-glance

snapshots of the space’s status. – Allowed for detecting conflicting devices at compile time, – Better capable of evaluating multiple potential action

plans. – Easier to change services based on users’ varying

preferences. – Capable to detect conflicting or dangerous behaviors at

runtime. – Allows for programmers to define impermissible contexts

(extremely danger that must be avoided) and providing the support at runtime to avoid and handle them.

• The formalization of the model and the provided scenario demonstrate the practicality of this model.

Thank You