1. A Context-Driven Programming Model for Pervasive Spaces Hen-I Yang, Jeffrey King, Sumi Helal, Erwin Jansen Pervasive Computing Lab, University of Florida www.icta.ufl.edu

2. 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

3. 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

4. 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

5. 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

6. 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.

7. Sensor Definition: Sensor A 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  D i Example The air quality can be monitored using a Smoke Detector Sensor, represented in our model as the function:

8. Actuator Definition: Intentional Effect of Actuator An intentional effect of an actuator a is the set of states that possibly can arise due to invocation of that actuator: g a : 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

9. Context: Taxonomy and Interpretation Definition: Taxonomy Context 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 Function We define the interpretation I as follows: AC I ⊆ U ⊤ I = U ⊥ I = ∅ ( ¬ C) I = U – C I (C ⊓ D) I = C I ∩ D I (C ⊔ D) I = C I ∪ D I Definition: Context Relations Inclusion and equality are defined as follows: Inclusion: C ⊑ D, interpreted by C I ⊆ D I Equality: C ≡ D, interpreted by C I = D I.

10. Context: Taxonomy and Interpretation (Cont) Example Taxonomy: 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

11. Active Context Definition: Active Context The active context of the space R: U  2 C is: R = {C | u I ∈ C I i} Example If the current temperature reading from the indoor thermometer is 24°C then Warm Indoor is the current active context

12. Action Definition: Statement Sequence Given a set of actuators A, a statement sequence S, also known as a sequence of actions, is defined as follows: S ::= ↑ a i | ↓ a i | S 1 ; S 2 Where ↑ a i turns actuator a i ∈ A on, ↓ a i turns actuator a i off, and the symbol ‘ ; ’ is used to indicate that we first perform statement S 1 and after which we execute the remaining statement S 2. Example The statement S::= ↑ vent; ↓ stove depicts the sequence of action in which the vent is turned on first, and then the stove is turned off

13. User and Intention Definition: User A user can be denoted by a tuple B ::= 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 Intentions Assume 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 ):

14. Programmable Pervasive Space Definition: Programmable Pervasive Space A programmable pervasive space can be denoted by a tuple consisting of: P ::= Where B is the representation of the user, R the currently active context, S the statements we are currently processing and 2 A the set of actuators currently active.

15. (De)Activation and Environmental Effect Definition: Context Change  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:  Deactivation:  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  where f (u) ≠ f (u ’ )

16. 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.

17. How does it work? Murky air Clean air Open windowTurn on stoveTurn on vent ContextIntentional EffectPreferred ContextImpermissible Context Blown fuse Medium power draw Low power draw Turn on stove Turn on heater Turn on oven Turn on vent Turn on stove Turn on heater Turn on oven Turn on vent Overcooked Steak Turn on stove Cooked Steak Raw Steak Warm Indoor Open window Hot Indoor Cold Indoor Open window Turn on A/C Turn on heater 1. Design the Context Graph2. Interpret Sensor Readings 3. 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

18. 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 fuse Emergency Handling Routine for “ blown fuse ” : prevent ↑ oven and notify user

19. 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.

20. 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.

21. Thank You