9/9/11
1
Computer Science and Engineering -‐ University of Notre Dame
Pervasive/Ubiquitous Compu@ng
Context Awareness
What is Context-‐Aware Compu@ng?
• “SoHware that examines and reacts to an individual’s changing context.” [Schilit, Adams, Want 1994]
• “…aware of its user’s state and surroundings, and help it adapt its behavior” [Satyanarayanan 2002]
• Systems that are able to adapt their opera@ons to the current context without explicit user interven@on
• Aim at increasing usability and effec@veness by taking environmental context into account
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
2
What is Context?
• “… any informa@on that can be used to characterize the situa@on of an en@ty.” [Dey et al. 2000]
• Places, People, Things
– Loca@on (where?) – Iden@ty (who?) – Time (when?) – Ac@vity (what?)
Computer Science and Engineering -‐ University of Notre Dame
why?
Tradi@onal Computer View
Computer Science and Engineering -‐ University of Notre Dame
Computer System input output
Context independent: acts exactly the same
Human in the loop
9/9/11
3
From Abstrac@on to Context Sensi@vity
• Tradi@onal black box view comes from the desire for abstrac@on
• This is based on several assump@ons: – Explicit input/output: slow, intrusive, requiring user a`en@on
– Sequen@al input-‐output loop • Move away from the black box model and into context-‐sensi@vity – human out-‐of-‐the-‐loop (as much as possible) – reduce explicit interac@on (as much as possible)
Computer Science and Engineering -‐ University of Notre Dame
Context as Implicit Input/Output
Computer Science and Engineering -‐ University of Notre Dame
explicit input
explicit output
Context: • state of the user • state of the physical environment • state of the computing system • history of user-computer interaction • ...
9/9/11
4
Context
• Iden@ty (user, others, objects) • Loca@on • Date/Time • Environment • Emo@onal state • Focus of a`en@on • Orienta@on • User preferences • Calendar (events) • Browsing history • Behavioral pa`erns • Rela@onships (phonebook, call history) • … the elements of the user’s environment that the computer knows
about…
Computer Science and Engineering -‐ University of Notre Dame
Classifica@on
• External (physical) – Context that can be measured by hardware sensors – Examples: loca@on, light, sound, movement, touch, temperature, air pressure, etc.
• Internal (logical) – Mostly specified by the user or captured monitoring the user’s interac@on
– Examples: the user’s goal, tasks, work context, business processes, the user’s emo@onal state, etc.
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
5
Why Context-‐Aware Compu@ng?
Computer Science and Engineering -‐ University of Notre Dame
Context Types Exis@ng Examples Human Concern
Room Ac@vity Smoke Alarm Safety
Room Ac@vity Auto Lights On / Off Convenience
Object Iden@ty Barcode Scanners Efficiency
Personal Iden@ty & Time File Systems Finding Info
Time Calendar Reminders Memory
Why Context-‐Aware Compu@ng?
Computer Science and Engineering -‐ University of Notre Dame
Exis@ng Examples Context Types Poten@al Examples Human Concern
Ac@vity Convenience
Ac@vity Finding Info
Iden@ty Memory
Iden@ty & Time Safety
Time Efficiency
Iden@ty
Time
Loca@on
Proximity
Ac@vity
History
…
Smoke Alarm
Auto Lights On / Off
Barcode Scanners
File Systems
Calendar Reminders
Health Alert
Auto Cell Phone Off In Mee@ngs
Service Fleet Dispatching
Tag Photos
Proximal Reminders
9/9/11
6
Categories of CA Applica@ons
Manual Automa@c
Gemng Informa@on Proximate Selec@on & Contextual Informa@on
Automa@c Contextual Reconfigura@on
Execu@ng Command Contextual Commands Context-‐Triggered Ac@ons
Computer Science and Engineering -‐ University of Notre Dame
Proximate Selec@on/Contextual Informa@on
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
7
Proximate Selec@on/Contextual Informa@on
Computer Science and Engineering -‐ University of Notre Dame
Proximate Selec@on/Contextual Informa@on
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
8
Automa@c Contextual Reconfigura@on
• Add, remove, or alter components based on context • SenSay project: context-‐aware mobile phone
Computer Science and Engineering -‐ University of Notre Dame
Automa@c Contextual Reconfigura@on
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
9
Contextual Commands
• Users can parameterize commands with context-‐filtered values; execu@on changes based on context
• Example: universal remote control
Computer Science and Engineering -‐ University of Notre Dame
Context-‐Triggered Ac@ons
• Simple if-‐then condi@on-‐ac@on rules, automa@cally invoked
• Reminder: if I step into the car on weekday morning and don’t have suitcase with me, remind me to get it
• CybreMinder:
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
10
Context-‐Triggered Ac@ons
• Challenges: – Expressiveness of language for rules – Accuracy of context informa@on
• Siren:
Computer Science and Engineering -‐ University of Notre Dame
Context-‐Awareness
• Context-‐awareness helps technology to “get it right” • But context is hard to sense (quan@ty, subtleness) • Computers are not self-‐aware like humans
• Problems: – When the system does the wrong thing
• auto-‐locking car doors • screen saver during presenta@on • microphone amplifying a whisper
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
11
Context-‐Awareness
• Context data must be coupled with the ability to interpret it, but computers are bad at “common sense”.
• More rules ≠ intelligence • More rules = more complexity, harder to understand
• “Human in the Loop”: – computers can detect, aggregate, portray informa@on – allow human users to interpret and act on it – Is this a good strategy for all context-‐aware systems?
Computer Science and Engineering -‐ University of Notre Dame
Encourage Healthy Dietary Behaviors
Computer Science and Engineering -‐ University of Notre Dame
• Interac@ve game to assist teachers to improve dietary behaviors of kindergarten children (“smart lunch tray”)
9/9/11
12
AudioIndex
• Allowing visually impaired to browse and search audio books. Main device around neck, earpiece with audio feedback, poin@ng device on index finger.
Computer Science and Engineering -‐ University of Notre Dame
Emergency Medical Response
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
13
Protech Parolee Monitor
Parent Pager
• A “child safety product” • Ac@vates an alarm when a child wanders more than 15 feet from the adult “base” unit
• Also alarms if submerged in water
9/9/11
14
5 Design Considera@ons
1. Improving relevance – Deciding when a communica@on is relevant to the person’s
current (or near future) situa@on. – For example, gemng no@fica@on about an email from your
travel agent regarding i@nerary changes while packing to leave for the airport.
2. Minimizing disrup@on 3. Improving awareness 4. Reducing overload 5. Selec@ng channels
5 Design Considera@ons
1. Improving relevance 2. Minimizing disrup@on
– Deciding when and how to no@fy people that they have a communica@on.
– For example, your phone should vibrate and not ring, when you are at the symphony (unless it is truly urgent).
3. Improving awareness 4. Reducing overload 5. Selec@ng channels
9/9/11
15
5 Design Considera@ons
1. Improving relevance 2. Minimizing disrup@on 3. Improving awareness
– Deciding what informa@on and mechanisms can help people make intelligent communica@on decisions.
– For example, the caller should be told you are at the movies before the call goes through.
4. Reducing overload 5. Selec@ng channels
5 Design Considera@ons
1. Improving relevance 2. Minimizing disrup@on 3. Improving awareness 4. Reducing overload
– Deciding how to reduce the number of communica@ons that don’t apply given your context.
– For example, filtering out emails about going to lunch when you are away from the office (or already at lunch).
5. Selec@ng channels
9/9/11
16
5 Design Considera@ons
1. Improving relevance 2. Minimizing disrup@on 3. Improving awareness 4. Reducing overload 5. Selec@ng channels
– Deciding which communica@on device should be used to get in touch with somebody.
– For example, rou@ng calls to your home phone instead of your cell phone when you are at home and cellular recep@on is poor.
The “research context” of “context-‐awareness compu@ng in health care”
• Context-‐aware medical applica@ons – Vocera communica@on system (St.Vincent hospital, USA)
• Communicator badge system for mobile user – Push-‐to-‐call bu`on, small text screen, voice dialing, hand-‐free conversa@on – Biometrically secured with speaker verifica@on
• Hospital-‐based prototypes – Hospital of the future (Centre for Pervasive Healthcare, Denmark)
• Hospital bed with a built-‐in display – Bed “knows” who is using it, and what and who is near it
• A context-‐aware pill container that is “aware of the pa@ent” • A context-‐aware Electronic Pa@ent Record
– Medica@on scheme or pa@ent record
– Intelligent hospital soHware (University of Cambridge, UK) • Scenarios of use
– Remote consulta@on, tracking of pa@ents and equipment, no@fica@on of awareness and pa@ent data • Implemen@ng a prototype
– QoS DREAM : middleware plauorm
9/9/11
17
Research in health care domain
The “research context” of “context-‐awareness compu@ng in health care”
• Hospital-‐based prototypes (cont’d) – Context-‐aware mobile communica@on (CICESE, Mexico)
• Mobile devices to recognize the context in which hospital workers perform their tasks. – Instance messaging with context such as circumstances
» Loca@on, delivery @ming, role reliance, an so on – MobileWARD (Mobile Electronic Pa@ent Record, Denmark)
• Suppor@ng morning procedure tasks in a hospital ward – Informa@on and func@onali@es according to the loca@on of the nurse and the @me
• Other prototypes – medica@on consump@on, distant monitoring and new assistants
• Scenario – Representa@on of context for a hospital informa@on system that uses PDAs to deliver pa@ent
informa@on to doctors (Ins@tute of Design, Chicago) • How context could be described by combining contextual informa@on from the environment,
person and ac@vity
9/9/11
18
Hospital-‐based Projects
• M : model, P: prototype, A: applica@on, S: scenario • Pi: presenta@on of informa@on, ES: Execu@on of services, SI: Storage of contextual info.
Diabetes Self-‐Care
• Eat the right foods • Get and log daily physical activity • Take medications as prescribed • Test blood glucose regularly
• Diabetes self-care with mobile phones: – People forget or don’t keep a detailed log – Recalling similar previous situations becomes difficult – Create a context-driven recommender application
• Benefits of the application – Time and location monitoring – User input on food consumption and insulin dosage – Find correlations between time/location and activities – Augment blood glucose level logs with contextual data – Use context to find similar situations in the past
Computer Science and Engineering -‐ University of Notre Dame
9/9/11
19
Diabetes Self-‐Care
Computer Science and Engineering -‐ University of Notre Dame
Diabetes Self-‐Care
• Declarative event-condition-action rules that govern application behavior • If (battery.load < 30 %) Then disableComponent(‘BluetoothDiscovery’) • If (battery.load < 15 %) Then invoke(‘UserInterface.warning()’)
• Application specific behavior: • Normal blood glucose: 80 – 150 mg/dL • < 50 mg/dL: hypoglycemic diabetic coma • > 500 mg/dL: hyperglycemic diabetic coma
Computer Science and Engineering -‐ University of Notre Dame