Context Acquisition - PowerPoint PPT Presentation

Loading...

PPT – Context Acquisition PowerPoint presentation | free to download - id: 6c5e74-ZWE0Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Context Acquisition

Description:

Context Acquisition Chen & Kotz: context awareness1\survey of CAMobileC.pdf – PowerPoint PPT presentation

Number of Views:37
Avg rating:3.0/5.0
Slides: 278
Provided by: kuo80
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Context Acquisition


1
Context Acquisition
  • Chen Kotz context awareness1\survey of
    CAMobileC.pdf
  • Albrecht_SchmidtG\context awareness1\Albrecht_Sc
    hmidt_PhD-Thesis_Ubiquitous-Computing_ebook1.pdf
  • SchmidtG\context awareness1\Schmidt-how to
    build smart appliances.pdf
  • ChenG\context awareness1\intelligent broker.pdf
  • Gellersencontext awareness1\monet.pdf

2
Sensing the Context (1/3)
  • Location
  • Outdoors GPS
  • Indoors IR, RF, ultrasonic, camera(cellular and
    non-cellular)
  • Hybrid IEEE 802.11, Mobile-IP

3
Sensing the Context (1/3)
  • Issues
  • Heterogeneous sensors with uncertainty and
    conflicts (sensor fusion)
  • Data networks vs sensor networks
  • communication and positioning may be combined or
    independent. (Active Badge ParcTab use the same
    wireless infrared link for both purpose and the
    RF link of the GUIDE and RADAR systems has the
    same role)
  • it is necessary to decouple the positioning and
    communication channels.

4
Sensing the Context (1/3)
  • Making mobile devices location-aware
  • the system tracks the location by monitoring
    beacons from mobile devices and the mobile device
    queries a central database to get the current
    location
  • the mobile device passively listens to beacons
    from the cell basestation and queries a local
    database for its current location.
  • In the latter case, if the mobile device only
    queries a local database for location, it has
    complete privacy and it can choose to advertise
    its current location to the world or only to
    selected third parties.

5
Sensing the Context (2/3)
  • Low-level contexts beyond location
  • Time time-of-day (with calendar)
  • Nearby objects
  • Network bandwidth
  • Orientation
  • Others photodiode (light), accelerometer (tilt,
    vibration), microphone, sensors for temperature,
    pressure, gas, etc.
  • Issue sensors in mobile devices or
    infrastructure gt direct vs. indirect awareness

6
Sensing the Context (3/3)
  • High-level contexts users activity
  • Camera technology and image processing
  • Consult calendar for what user is to do
  • Combine low-level sensors, e.g., using rules
  • How about emotional contexts?
  • Context changes subscription-notification
  • Polling rate?

7
Quality of Contexts
  • What context is important? Always and in
    different situations?
  • Quality
  • Coverage, resolution, accuracy, confidence,
    reliability, frequency, timeliness
  • Self-contained vs. infrastructure-supported
  • PDA doesn't need location sensors if it can ask
    nearby sensors to approximate
  • Need standards for sharing components?

8
Context vs. Situation
  • In a certain situation, specific sensor data is
    frequently similar to sensor data of the same
    situation at different times.
  • Situation the state of the real world at a
    certain moment or during an interval in time at a
    certain location.
  • Context identified by a name and includes a
    description of a type of situation by its
    characteristic features.
  • Situation S belongs to a Context C A situation S
    belongs to a context C when all conditions in the
    description of C evaluate to true in a given
    situation S.

9
Requirements on Sensing in a Ubiquitous Computing
Environment
  • Design and Usability
  • Energy Consumption
  • Calibration
  • Start-up Time
  • Robustness and Reliability
  • Portability, Size and Weight
  • Unobtrusiveness, Social Acceptance and User
    Concern
  • Price and Introduced Cost
  • Precision and Openness

10
Sensing Technologies and Systems for Data Capture
  • Light and Vision
  • Audio
  • Movement and Acceleration
  • Location and Position
  • Magnetic Field and Orientation
  • Proximity, Touch and User Interaction
  • Temperature, Humidity and Air Pressure
  • Weight
  • Motion Detection
  • Gas-Sensors and Electronic Noses
  • Bio-Sensors
  • Zero-Power Sensors

11
Composition of Sensing Systems
All sensors at same position Sensors distributed
Homogeneous sensing system e.g. orientation aware PDA, Schmidt,98 e.g. load sensing system, Schmidt,02
Heterogeneous sensing system e.g. context-aware mobile phone, Schmidt,99c e.g. distributed sensing boards, SMART,02
12
Homogeneous sensing system
  • Microphone array
  • light sensors in a handheld device to avoid
    users finger put on top of the sensor resulting
    in a false reading.
  • multiple sensors of the same type placed at
    different physical positions. Especially when
    there are little restrictions in the way a device
    is held or carried

13
Placement of sensors
  • Placement of sensors is of major importance and
    has a great influence on the quality of the data
    that is gathered.
  • putting all sensors together in one place,
    perception of contexts becomes much harder than
    for a case where sensors are physically
    distributed and placed at an optimal point
    especially true for applications in wearable
    computing.
  • Finding and selecting the right position for a
    sensor is very much dependent on the contexts
    that should be recognised.
  • In most case, there is no prior knowledge about
    sensor placement ? try and error ?
    simulation/emulation tools

14
Perception Methods
  • Basic Statistical Functions average, median,
    standard deviation, max-min range, interquartile
    range, the amount of change
  • Time Domain Analysis data from accelerometers,
    light sensors and audio
  • Derivatives of interest to find information
    about the change rather than about the absolute
    values
  • Neural Networks to provide abstract or symbolic
    information (cues)
  • Rule Based Systemsparticularly simple when
    sensors map well to contexts of interest and the
    number of contexts is small

15
A Perception Architecture
  • Albrecht_SchmidtG\context awareness1\Albrecht_Sc
    hmidt_PhD-Thesis_Ubiquitous-Computing_ebook1.pdf
  • Sensor layer
  • Cue layer
  • Context layer

16
Context Acquisition Design Method
  • Step 1. Identifying contexts that matter
  • Is the application or artefact used in changing
    situations?
  • Vary the expectations of the user towards the
    application or artefact with the situation?
  • Is the human computer interaction pattern
    different in various situations?
  • Does the users interaction with the real world
    environment offer information that is valuable to
    the application?

17
Context Acquisition Design Method
  • Step 2. Determine variables that distinguish
    contexts selected.
  • Such variables may be of informational, physical
    and social nature (e.g. location, temperature,
    relationship with people near by, interaction
    with the device)
  • For the minimal set of variables that make it
    possible to discriminate the selected context the
    values (e.g. ranges, sets) for variables are
    specified.

18
Context Acquisition Design Method
  • Step 3. Finding appropriate sensors to cover all
    variables at minimum cost.
  • accuracy of the sensor in relation to the
    variable
  • the cost to provide the information
  • feasibility and appropriateness
  • The resulting selection of sensors should be done
    in a way that the sensors cover all variables
    with sufficient accuracy at a minimal cost.

19
Context Acquisition Design Method
  • Step 3a. Building and assessing a prototypical
    sensing device. (optional)
  • when there is little knowledge about the sensors
    in question or the contexts to recognise.
  • can experiment with the positions of the sensors
    on the device.
  • the recorded data is analyzed to identify whether
    the raw data differs significantly for the
    different situations or not.
  • If the data differs not significantly different
    sensors have to be selected or even different
    contexts have to be identified or in some case it
    may turn out that it is not feasible to recognise
    the contexts at all.

20
Context Acquisition Design Method
  • Step 4. Selecting recognition and abstraction
    technologies.
  • Step 5. Specification of a context acquisition
    system
  • After all components, the physical design and the
    algorithms are assessed the overall architecture
    of the system is determined.
  • Centralized vs. distributed
  • Build applications.

21
Context Acquisition Design Method
  • Context Acquisition Library G\context
    awareness1\Albrecht_Schmidt_PhD-Thesis_Ubiquitous-
    Computing_ebook1.pdf
  • Rapid Prototyping Platform for Context
    Acquisition Smart-Its
  • Cost function
  • Power Consumption?Size and Weight?Price of
    Components?Robustness and Reliability

22
Context Acquisition methoddirect access to
hardware sensors
  • ChenG\context awareness1\intelligent broker.pdf
  • A key benefit of this approach is that the
    high-level applications can have great controls
    over the operations of the low-level sensors, and
    can have better knowledge about how different
    data is collected and computed.

23
Context Acquisition methoddirect access to
hardware sensors
  • Shortcomings To communicate with different
    sensors means an application must maintain the
    implementation to communicate with different
    sensors. As the number of context used by the
    application increases, the amount of
    implementation for sensor communications also
    increases. For this reason, the applications
    overall implementation becomes difficult to
    maintain.

24
Facilitated by Middleware
  • Using middleware, context-aware applications
    implementations can focus on how to use context
    but not on how to acquire context.
  • middleware is typically built into the hosting
    devices or platform on which the context-aware
    applications operate.
  • Odyssey project context aware agents are built
    on a middleware to acquire status about the
    communication network demonstrating three
    different context-aware agents that can adapt
    their behaviors according to the network
    bandwidth changes.
  • Context Toolkit aimed to provide a general
    solution for building scalable and reusable
    context acquisition modules built on the widget
    concept in the graphical user interface design.

25
Facilitated by Middleware
  • Problem imposes additional computation burden on
    the hosting devices. A middleware design trades
    computation resources for development
    convenience.
  • In order to maintain a generic programming
    interface between the high-level applications and
    low-level sensors, certain amount of computation
    resources (e.g., CPU power, memory, network
    bandwidths) must be allocated for the middleware
    operations. While this might not create a problem
    for devices that have rich computing resources,
    however, it will lead to resource contention
    problem in devices that have less resources
    (e.g., cellphones and embedded devices).

26
Acquiring Context from a Context Server
  • For the case that the hosting device has limited
    computing resource
  • context server a computing entity that provides
    contextual information to different context-aware
    applications in a distributed environment.
  • to shift the context acquisition procedures into
    the implementation of a server entity that runs
    on a resource-rich device.
  • applications that do not have built-in sensing
    capability can acquire context and become
    context-aware.

27
Acquiring Context from a Context Server
  • Me-Centric Domain Server Perich
  • the physical world is divided into a set of
    micro-worlds. Each micro-world represents a
    particular domain in the physical world. A domain
    might be an office room, a meeting room, etc.
    Each micro-world has context. The role of a
    Domain Server is to maintain the context of the
    individual micro-worlds and share this
    information with the computing entities of a
    Me-Centric application.
  • CoBrA
  • Similarity a server entity is responsible to
    share contextual information with other agents in
    the space use knowledge representation languages
    to express contextual information (i.e., CoBrA
    uses OWL, and Me-Centric Domain Server uses RDF).

28
Acquiring Context from a Context Server
  • Differences
  • the CoBrA is not only to share contextual
    information but also to maintain a consistent
    model of the context to detect and resolve
    inconsistent information that may have been
    acquired from unreliable sensors and agents.
  • Using OWL to represent context as ontologies,
    CoBrA allows independently developed agents to
    share knowledge and provides a means for context
    reasoning.
  • CoBrA addresses the privacy issue by providing
    users with a policy language for controlling the
    sharing of their contextual information. Privacy
    was not addressed in the Me-Centric Domain Server.

29
Multi-Sensor Context-Awareness in Mobile Devices
and Smart Artefacts
  • Gellersencontext awareness1\monet.pdf
  • Position Sensing and Location-based Context
  • Auditory and Visual Context
  • Other Sensors bio-sensors, tilt sensors
  • Integration of Diverse Sensors

30
Multi-Sensor Context-Awareness in Mobile Devices
and Smart Artefacts
  • TEA Technology Enabling Awareness investigated
    the realization of multi-sensor context-awareness
    in a self-contained device that would be
    available as peripheral or plug-in for mobile
    host devices. The general application perspective
    was to supply situational context to a mobile
    host device to improve the devices service to
    its user. We explored this perspective in the
    application domain of mobile telephony.

31
Multi-Sensor Context-Awareness in Mobile Devices
and Smart Artefacts
  • Mediacup looked at how non-computational
    artifacts can be augmented with awareness
    technology. The application perspective is
    entirely different from that underlying TEA.
    Awareness is not employed to improve the
    immediate function of the augmented device, but
    to create a digital presence for it. New
    functionality is not expected to emerge in the
    device itself but in the surrounding system
    environment.
  • Smart-Its toward platforms for aware mobile
    devices. With this project we also shift our
    attention from individual devices to ad hoc
    networking of aware devices, and scenarios of
    collective awareness.

32
Manipulating Multiple Contexts
  • Source
  • Multi-Sensor Context-Awareness in Mobile Devices
    and Smart Artefacts
  • H.W. Gellersen, A. Schmidt, M. Beigl
  • Lancaster University and University of Karlsruhe

Situation
sensor(s)
perceived
Context
33
Direct/Indirect Context-Awareness
  • Indirect context awareness
  • Direct context awareness

Situation
device A
Infrastructure
device B
Context
communicate
sensor(s)
perceived
device C
device A
Situation
S(s)
Built-in sensors, context processing
device B
perceived
S(s)
Context
device C
S(s)
34
Single Sensor vs. Multiple Sensors
  • Single but powerful sensor
  • Position sensor, video sensor (camera)
  • Useful information is inferred from what is
    perceived
  • Prior knowledge is needed for information useful
  • Simple but cheap sensors
  • Each sensor captures one facet of the context

35
Take Multiple-Sensor Approach
  • Need to combine multiple simple sensors vs. one
    camera with powerful recognition capability
  • Gain rich data to infer useful context with
    little computation
  • Real world situations situations and sensors

36
Example TEA
  • Technology EnablingAwareness
  • Motivation make personalmobile devices smarter
  • Specs
  • CPU PIC16F877
  • Storage 8K EEPROM
  • RAM 200 Byte
  • Use serial line tocommunicate with the host

host
TEA
37
TEA Architecture
  • Cue abstraction of raw data
  • For example, an acceleration sensor can infer
    cues like pattern of movement and current speed
  • Rules from cue to context can be pre-defined or
    use supervised/unsupervised learning

38
Initial Exploration
  • Tried on both PDA and mobile phone, and found it
    more useful on mobile telephony
  • Two analysis strategies
  • Analyze how well a sensor contributes to a given
    context
  • Analyze which sensors relate to which context
  • Finding audio, motion and light are useful
    globally, and other sensors are only useful in
    specific contexts

39
Implementation
  • Some data are directly analyzed and not stored
    (audio)
  • Some data are stored and processed (acceleration,
    light)
  • Some data are cues itself no need to process
    (temperature, skin conductance)
  • Rules from cue to context are extracted offline
    and hardwired

40
Application
  • Profile activation
  • A user can have many profiles
  • Activate profiles according to the situation
    (in-hand, on-table, in-pocket, outdoors)
  • 87 certainty, 30 sec to calculate (not yet
    optimized)
  • Context sharing (and privacy invasion)

Ask to call B
Request Bs context
A
Provide context
Inform A
Make decision
(Voice or short message)
As phone
Bs phone
41
Mediacup An Active Artifact
  • Spec
  • 1Mhz CPU, 15K storage,384 byte RAM
  • Digital temperature sensor
  • 3-ball switch
  • Detect movement
  • A switch
  • Detect whether placedon surface
  • Infrared diode for comm.
  • Capacitors charged wirelessly

3mm high
42
Identified Contexts
  • Movement context
  • Cup is stationary, drinking out of the cup, cup
    is played with, cup is carried around
  • Computed by rule based heuristics with a short
    history of movements
  • Temperature context
  • Filled up, cooled off, current temperature
  • Updated every 2 seconds
  • The cups broadcast their context to an overhead
    transceiver using the infrared diode

43
Design Issues
  • Power management
  • System kept very low-end
  • Motion detection uses interrupt instead of
    polling to enable sleep mode in 99 of the time
  • Put the cup on the saucer to recharge wirelessly
    (15 minute for 12 hour)
  • Transparency
  • Hiding the technology does not suffice
  • In the battery-charged prototype, users forget to
    replace the battery because the effect of
    technology is invisible!

44
Design Issues (Contd)
  • Region of impact
  • No context-aware application in the environment
  • Context as a common resource

Inside
MEETING
available
Outside
45
Context-aware System Design
  • Matthias Baldauf context awareness1\ijahuc2007.pd
    f
  • Deycontext awareness1\dey-thesis.pdf

46
Design principles
  • context acquisition method
  • predefines the CASs architecture to some extent.
  • direct sensor access?middleware
    infrastructure?context server (Chen)
  • Context management method for coordinating
    multiple processes and components (Winograd)
  • Widgets. a widget is a software component that
    provides a public interface for a hardware
    sensor. Widgets hide low-level details of sensing
    and ease application development due to their
    reusability. Because of the encapsulation in
    widgets it is possible to exchange widgets which
    provide the same kind of context data (e.g.,
    exchange a radio frequency widget by a camera
    widget to collect location data). Widgets are
    usually controlled by some kind of a widget
    manager.

47
Design principles
  • Networked services. This more flexible approach
    resembles the context server architecture.
    Instead of a global widget manager discovery
    techniques are used to find networked services.
    This service based approach is not as efficient
    as a widget architecture due to complex network
    based components but provides robustness.
  • Blackboard model. a data-centric view (vs.
    process-centric) processes post messages to the
    blackboard, and subscribe to it to be notified
    when some specified event occurs. Advantages the
    simplicity of adding new context sources and the
    easy configuration. Drawback needs a centralized
    server to host the blackboard and the lack in
    communication efficiency as two hops per
    communication are needed.

48
Layered conceptual framework
application
storage/management
preprocessing
raw data retrieval
sensors
49
Layered conceptual framework
  • Sensor layer
  • physical sensors
  • virtual sensors source context data from
    software applications or services. E.g.,
    determine an employees location not only by
    tracking, but also by browsing an electronic
    calendar
  • logical sensors combine physical and virtual
    sensors with additional information from various
    other sources in order to solve higher tasks.
    E.g., a logical sensor can be constructed to
    detect an employees current position by
    analyzing logins at desktop PCs and a database
    mapping of devices to location information.

50
Layered conceptual framework
  • Raw data retrieval layer
  • makes use of appropriate drivers for physical
    sensors and APIs for virtual and logical sensors.
  • often implemented in reusable software components
    which make low-level details of hardware access
    transparent
  • For instance, it is possible to replace a RFID
    system by a GPS system without any major
    modification in the current and upper layers.

51
Layered conceptual framework
  • Preprocessing layer
  • is not implemented in every context-aware system
    but may offer useful information if the raw data
    are too coarse grained.
  • responsible for reasoning and interpreting
    contextual information
  • raises the results of layer two to a higher
    abstraction level to meet the use of
    applications E.g., the exact GPS position of a
    person might not be of value for an application
    but the name of the room the person is in, may be.

52
Layered conceptual framework
  • aggregation/composition of context data for
    several different context data sources
  • this abstraction functionality could be
    implemented directly by the application. This
    task should better be encapsulated and moved to
    the context server. And by making such
    aggregators remotely accessible the network
    performance increases (as clients have to send
    only one request to gain high-level data instead
    of connecting to various sensors) and limited
    client resources are saved.
  • sensing conflicts that might occur when using
    several data sources. E.g., when a system is
    notified about a persons location by the
    coordinates of her mobile phone and by a camera
    spotting this person.

53
Layered conceptual framework
  • storage and management layer
  • Organizes the gathered data and offers them via a
    public interface to the client
  • synchronous the client is polling the server for
    changes via remote method calls.
  • Asynchronous works via subscriptions the client
    is either simply notified or a clients method is
    directly involved using a call back
  • Asynchronous approach is more suitable due to
    rapid changes in the underlying context. The
    polling technique is more resource intensive

54
Layered conceptual framework
  • Application layer
  • actual reaction on different events and
    context-instances is implemented here.
  • Sometimes information retrieval and application
    specific context management and reasoning is
    encapsulated in form of agents, which communicate
    with the context server and act as an additional
    layer between the preprocessing and the
    application layer

55
Design principles
  • Context model
  • Key-Value?Markup scheme?Graphical?Object
    oriented?Logic based?Ontology based
  • requirements for designing a context ontology
  • simplicity as simple as possible to simplify the
    work of applications developers
  • flexibility and extensibility support the simple
    addition of new context elements and relations
  • genericity not be limited to special kind of
    context atoms but rather support different types
    of context
  • Expressiveness. allow to describe as much context
    states as possible in arbitrary detail.

56
Design principles
  • Context attributes
  • Context type
  • Context value
  • Time stamp a date/time-value describing when the
    context was sensed. It is needed to create a
    context history and deal with sensing conflicts.
  • Source about how the information was gathered.
  • Confidence describes the uncertainty of this
    context type.

57
Context-aware frameworks
  • architecture, resource discovery, sensing,
    context model, context processing historical
    context data, security and privacy
  • Architectures context awareness1\ijahuc2007.pdf
  • Context Managing Framework Korpipää (2003)
  • Service-Oriented Context-Aware Middleware
    (SOCAM) Gu et al. (2004a, 2004b)
  • Context-Awareness Sub-Structure (CASS) Fahy and
    Clarke (2004)
  • Context Broker Architecture (CoBrA) Chen (2003)
  • The Context Toolkit Salber Dey (1999 2001)
  • Hydrogen project (Hofer et al., 2002) context
    sharing
  • CORTEX Sentient Object Model (Biegel and Cahill,
    2004)
  • Gaia (Roman et al., 2002 Gaia Project,2005)

58
Context-aware frameworks
  • Resource discovery context awareness1\ijahuc2007.
    pdf
  • Context Toolkit offers discoverer which works as
    registry component which interpreters,
    aggregators and widgets have to notify about
    their presence and their contact possibilities.
    After registration the components are pinged to
    ensure that they are operating. If a component
    does not respond to a specified number of
    consecutive pings, the discoverer determines that
    the component is unavailable and removes it from
    its registry list. Customers may find appropriate
    components querying the discoverer either via a
    white page lookup (a search for the components
    name) or a yellow page lookup (a search for
    specific attributes). In case the lookup was
    successful the discoverer returns a handle to
    contact the context component.
  • SOCAM Service Locating Service.
  • Gaia context providers are stored in a registry
    component.
  • Hydrogen (pure peer-to-peer) only uses local
    built-in sensors no discovery mechanism is
    involved.

59
Context-aware frameworks
  • sensing context awareness1\ijahuc2007.pdf
  • Context Toolkit context widgets to separate
    applications from context acquisition concerns
    permits a simple exchange of widgets since.
  • This manner of building reusable sensor units
    that make the action of sensing transparent to
    the customer became widely accepted in
    distributed context-aware systems
  • CASS sensor nodes
  • SOCAM context providers
  • Context Managing Framework resource servers
  • CoBrA context acquisition components.

60
Context-aware frameworks
  • Context processing context awareness1\ijahuc2007.
    pdf
  • Context Toolkit offers facilities for both
    context aggregation and context interpretation.
  • Context Managing Framework The resource servers
    tasks are complex. First they gather raw context
    information from various data sources. After the
    preprocessing and feature abstraction, the data
    are delivered by posting it to the context
    managers blackboard. The context recognition
    services are used by the context manager to
    create higher-level context object out of context
    atoms. In this vein new recognition services are
    easy to add.

61
Context-aware frameworks
  • SOCAM Context Reasoning Engine reasons over the
    knowledge base its tasks include inferring
    deduced contexts, resolving context conflicts and
    maintaining the consistency of the context
    knowledge base. Different inference rules can be
    specified. The interpreter is implemented by
    using Jena2, a semantic web toolkit.
  • CoBrA Inference Engine processes context data.
    The engine contains the Context Reasoning Module
    responsible for aggregating context information.
    It reasons over the Context Knowledge Base and
    deduces additional knowledge from information
    acquired from external sources.

62
Context-aware frameworks
  • CASS based on an inference engine and a
    knowledge base. The knowledge base contains rules
    queried by the inference engine to find goals
    using the so-called forward chaining technique.
    As these rules are stored in a database separated
    from the interpreter neither recompiling nor
    restarting of components is necessary when rules
    change.
  • CORTEX the whole context processing is
    encapsulated in Sentient Objects. The sensory
    capture unit performs sensor fusion to manage
    uncertainty of sensor data (sensing conflicts)
    and to build higher-level context objects.
    Different contexts are represented in a so-called
    context hierarchy together with specific actions
    to be undertaken in each context. Since only one
    context is active at any point in time (concept
    of the active context) the number of rules that
    have to be evaluated are limited. Thus efficiency
    of the inference process is increased. The
    inference engine component is based on C Language
    Integrated Production System (CLIPS).

63
Context-aware frameworks
  • Gaia hidden in the Context Service Module
    allowing the creation of high-level context
    objects by performing first order logic
    operations such as quantification, implication,
    conjunction, disjunction, and negation of context
    predicates.
  • Hydrogen higher-level abstractions are handled
    by the application layer.

64
Context-aware frameworks
  • historical context data context
    awareness1\ijahuc2007.pdf
  • Context Toolkit, CoBrA, CASS, SOCAM and CORTEX
    save context data persistently in a database. A
    further advantage of using a database is the use
    of SQL which enables to read and to manipulate
    operations at a high abstraction level.
  • CoBrA and CASS the persistent storage is called
    Context Knowledge Base. Additionally a set of
    APIs is offered to assert, delete, modify and
    query the stored knowledge. CASS uses its
    database not only to save context data but also
    to store domain knowledge and inference rules
    needed for creating high-level context.
  • Due to limited memory resources a peer-to-peer
    network of mobile devices like Hydrogen is not
    able to offer persistent storage possibilities.

65
Context-aware frameworks
  • Security and privacy context awareness1\ijahuc200
    7.pdf
  • Context Toolkit introduces the concept of
    context ownership. Users are assigned to sensed
    context data as their respective owners. They are
    allowed to control the other users access.
  • CoBrA includes an own flexible policy language to
    control context access, called Rei (Kagal et al.,
    2003). This policy language is modeled on deontic
    concepts of rights, prohibitions, obligations and
    dispensations and controls data access through
    dynamically modifiable domain dependent policy
    rules.

66
Context-aware frameworks
  • Summary context awareness1\ijahuc2007.pdf

67
Design Process of Context-aware Applications
  • The designer does not want to worry about the
    middle three steps, but instead would like to
    concentrate on the specifying and performing the
    actual context-aware behaviors.
  • 1. Specification Specify the problem being
    addressed and a high-level solution.
  • 1.1. Specify the context-aware behaviors to
    implement.
  • 1.2. Determine what collection of context is
    required for these behaviors to be executed,
    using any context-acquisition mechanisms that
    already exist.

68
Context Specification
  • Need to express context about and relationships
    between People, Places, Things
  • Predicates
  • Identity (Who is? What is? Is with?)
  • Location (Near? Nearest? Distance? Path?)
  • Activity (Is busy? Is in meeting? Current task?)
  • Time (In past? In present? In future? On date?)

69
Context Specification
  • Common parameters
  • Max number of results wanted
  • Return name
  • Return data type (e.g. String, List, Table)
  • Minimal probability of correctness desired
  • Relevant sensor input requestor has
  • Event parameters
  • Event rate (e.g. at most 1 event per second)
  • Event callback (e.g. RPC, socket port)
  • Max number of events desired
  • Granularity of change (e.g. 1 meter)

70
Design Process of Context-aware Applications
  • 2. Acquisition Determine what new hardware or
    sensors is needed to provide that context.
  • 2.1. Install the sensor on the platform it
    requires.
  • 2.2. Understand exactly what kind of data the
    sensor provides.
  • 2.3. If no application programming interface
    (API) is available, write software that speaks
    the protocol used by the sensor.
  • 2.4. If there is an API, learn to use the API to
    communicate with the sensor.
  • 2.5. Determine how to query the sensor and how to
    be notified when changes occur.
  • 2.6. Store the context.
  • 2.7. Interpret the context, if applicable.

71
Design Process of Context-aware Applications
  • 3. Delivery Provide methods to support the
    delivery of context to one or more, possibly
    remote, applications.
  • 4. Reception Acquire and work with the context.
  • 4.1. Determine where the relevant sensors are and
    how to communicate with each other
  • 4.2. Request and receive the context.
  • 4.3. Convert it to a useable form through
    interpretation.
  • 4.4. Analyze the information to determine
    usefulness.
  • 5. Action If context is useful, perform
    context-aware behavior.
  • 5.1. Analyze the context treating it as an
    independent variable or by combining it with
    other information collected in the past or
    present.
  • 5.2. Choose context-aware behavior to perform.

72
Design Process Delivery/Distribution
  • Contexts typically captured remotely from
    applications at different time
  • Context captured in sensor-rich environment or
    device may need to serve multiple applications
  • gt Need to deliver and distribute context to
    multiple, remote applications
  • Infrastructure or middleware support
  • App/network-level delivery/routing models and
    transport mechanism

73
Design Process Reception
  • Application locates relevant sensors/contexts
  • Service discovery
  • Requests contexts via queries, polls,
    notifications
  • Query language, event-notification mechanism
  • How often to request?
  • Additional interpretation/abstraction/processing
  • Collection, aggregation, filtering, correlation,
    fusion,...

74
Context Interpretation
  • Sophisticated applications require higher level
    forms of context
  • Fusion
  • Ambiguity
  • Sensors not 100 reliable, e.g. confidence value
  • Precision / Accuracy / Granularity
  • Different ways to deal
  • Improve inference
  • Probability/fuzzy model
  • Bring the user into the loop

75
Design Process Action
  • Combine received contexts with previous contexts
    and system/application states for further
    analysis
  • Perform actions based on the analysis results
  • May treat context collection/processing as a
    separate service

76
Using the Design Process In/Out Board
  • 1.1 Specify the context-aware behaviors to
    implement.
  • to display whether occupants of a building are in
    or out of the building and when they were last
    seen
  • 1.2 Determine what collection of context is
    required and if any context-acquisition
    mechanisms that already exist.
  • the relevant context types are location, identity
    and time there is no existing support in the
    building to provide this context, so a new sensor
    has to be used.
  • 2.1 Install the sensor on the platform it
    requires.
  • Java iButtons are chosen to provide the location
    and identity context. An iButton is a
    microprocessor that contains a unique identity.
    This identity can be read when the iButton is
    docked with a reader. A reader is installed on a
    computer, at the entrance to the research lab.

77
Using the Design Process In/Out Board
  • 2.2 Understand exactly what kind of data the
    sensor provides.
  • The reader combined with the iButton provides an
    abstract identity rather than providing a name,
    which is what the developer wants, the iButton
    provides a 16 character hexadecimal value.
  • 2.3/2.4 If no API is available, write software
    that speaks the protocol used by the sensor If
    there is an API, learn to use the API to
    communicate with the sensor.
  • The location context is simply the location of
    the installed reader, and time context is
    determined from the computer being used.The
    iButton and reader come with an API, so the
    developer writes supporting code that reads the
    abstract identity when an iButton is docked with
    a reader.
  • 2.5 Determine how to query the sensor and how to
    be notified when changes occur.
  • This code must support both querying and
    notification of events, where, informally, an
    event is a timely difference that makes a
    difference.

78
Using the Design Process In/Out Board
  • 2.6 Store the context.
  • The context information acquired from the sensor
    must be stored so additional code is required.
  • 2.7 Interpret the context, if applicable.
  • While the abstract identity does need
    interpretation into an actual user name, the
    interpretation is usually left to the
    application.
  • 3 Provide methods to support the delivery of
    context to one or more, possibly remote,
    applications.
  • design and implement a communications protocol
    for allowing applications to access the acquired
    context, including both querying and notification
    schemes must be able to interact with the code
    that actually acquires the context. Finally, a
    communications mechanism must be developed to
    support the protocol, allowing the application to
    actually communicate with the sensor.

79
Using the Design Process In/Out Board
  • 4.1 Determine where the relevant sensors are and
    how to communicate with each other
  • The developer begins to work on the application
    side of the problem, determining where the
    sensors are and how to communicate with them. The
    In/Out Board needs to acquire current state
    information for who is in and who is out of the
    building, so it first locates the sensor and then
    queries it. It also subscribes to the iButton
    asking to be notified of relevant changes.
  • 4.2 Request and receive the context.
  • The communications is written to specifically
    deal with the iButton and accompanying code. Once
    the application receives context information
    (location of the reader, abstract identity and
    time of docking), it must convert the abstract
    identity to a usable form.

80
Using the Design Process In/Out Board
  • 4.3/4.4 Convert it to a useable form through
    interpretation.
  • It can use a simple hash table that has an
    associated user name for each abstract identity.
    After this interpretation, it analyzes the
    information to see if the context is useful. In
    this case, it means whether the iButton user was
    a registered user of the In/Out Board.
  • 5.1 Analyze the context treating it as an
    independent variable or by combining it with
    other information collected in the past or
    present.
  • The application must determine if the context it
    received was for a user arriving or leaving the
    building. When new useful context arrives for a
    given user, that users state is toggled from in
    to out, or vice-versa.
  • 5.2 Choose context-aware behavior to perform.
  • The developer can act on the context, and display
    the users new state on the In/Out Board.

81
Essential and Accidental Activities
  • Specification essential for without it, there
    can be no use of context. This step is the focal
    point of modeling and designing CASs, and
    typically impacts the rest of the application
    design.
  • Acquisition essential or accidental, depending
    on the sensor chosen. If the sensor has been used
    before? accidental, reusable by the application
    designer.
  • If the sensor has not been used before, then all
    of the difficult sub-steps must be completed.
    Installation of a sensor can be particularly
    troublesome when the platform required by the
    sensor does not match the platforms available or
    being used by the application.
  • Storage accidental it is common across all
    sensors and is not strictly dependent on the
    sensor being used.

82
Essential and Accidental Activities
  • Delivery The delivery of context is an
    accidental step. The designer merely wants to
    acquire the context and should not be concerned
    about these types of low-level details.
  • Reception accidental the designer most likely
    does not care about the details of context
    reception and determining usefulness, and is
    concerned only with receiving useful context.
  • Action The analysis from analyzing the types and
    values of context received is accidental and
    should be automatically provided by the
    supporting infrastructure. The determination of
    actions is application-specific and is essential.

83
Revised Design Process
  • Specification Specify the problem being
    addressed and a high-level solution.
  • 1.1. Specify the context-aware behaviors to
    implement.
  • 1.2. Determine what context is required for these
    behaviors (with a knowledge of what is available
    from the environment) and request it.
  • Acquisition Determine what hardware or sensors
    are available to provide that context and install
    them.
  • 3. Action Choose and perform context-aware
    behavior.

84
Revised Design Process
  • If all necessary context acquisition components
    are already available for use by applications,
    then step 2 is not required.
  • To use this reduced design process. we must
    provide infrastructure level support.
  • Connecting application design too tightly to
    sensors used has resulted from the use of the
    longer, more complex design process.
  • 3 basic problems emerged due to this trend the
    lack of variety in sensors used, the lack of
    variety in the types of context used and the
    inability to evolve context-aware applications.

85
required features for a supporting framework
  • library programmers, toolkit programmers (may add
    something new to the architecture)
  • context specification need a mechanism (
    specification language) that allows application
    builders to specify what context an application
    requires along a number of dimensions
  • single piece of context vs. multiple pieces of
    context.
  • if multiple, related context vs. unrelated
    context.
  • unfiltered context vs. filtered context.
  • uninterpreted context vs. interpreted context.

86
required features for a supporting framework
  • the mechanism must support multiple
    specifications from multiple applications that
    may be requesting the same or different set of
    context.
  • This mechanism makes it easier for application
    designers to specify what context their
    applications require. It helps remove the
    accidental design process steps of reception
    (receiving the context, interpretation and
    analysis) and the first step of action (further
    analysis with additional context to determine
    usefulness).

87
required features for a supporting framework
  • Separation of Concerns and Context Handling
  • there is no common way to acquire and handle
    context.
  • Application developers choose whichever technique
    is easiest to implement, at the expense of
    generality and reuse.
  • common ways in which context is handled
    connecting sensor drivers directly into
    applications and using servers to hide sensor
    details ? applications are difficult to build
    and evolve.

88
required features for a supporting framework
  • handle context in the same manner as we handle
    user input. User interface toolkits provide an
    important abstraction to enable designers to use
    input without worrying about how the input was
    collected. This abstraction is called a widget,
    or an interactor.
  • By separating how context is acquired from how it
    is used, the acquisition step is able to greatly
    reduced. Applications can now use contextual
    information without worrying about the details of
    a sensor and how to acquire context from it.

89
required features for a supporting framework
  • Context Interpretation
  • There may be multiple layers that context data go
    through before reaching an application, due to
    the need for additional abstraction.
  • The use of these multiple layers should be
    transparent. In order to support this
    transparency, context must often be interpreted
    before it can be used by an application.
  • E.g., an application wants to be notified when
    meetings occur. At the lowest level, location
    information can be interpreted to determine where
    various users are and identity information is
    used to check co-location. At the next level,
    this information could be combined with sound
    level information to determine if a meeting is
    taking place.

90
required features for a supporting framework
  • In order for the interpretation to be easily
    reusable by multiple applications, it needs to be
    provided by the framework. Otherwise, each
    application would have to re-implement the
    necessary implementation.
  • The interpretation mechanism removes the
    interpretation sub-steps found in both the
    acquisition and reception steps of the design
    process. Combined with the specification
    mechanism, it allows applications to simply
    request the context they want, regardless of
    whether interpretation is required or not, and
    for the applications to receive the requested
    context.

91
required features for a supporting framework
  • Transparent Distributed Communications
  • As environments and computers are becoming more
    instrumented, more context can be sensed, but
    this context will be coming from multiple,
    distributed machines connected via a computer
    network. The fact that communication is
    distributed should be transparent to both sensors
    and applications. This simplifies the design and
    building of both sensors and applications,
    relieving the designer of having to build a
    communications framework. Without it, the
    designer would have to design and implement a
    communications protocol and design and implement
    an encoding scheme (and accompanying decoder) for
    passing context information.

92
required features for a supporting framework
  • A related requirement is the need for a global
    timeclock mechanism.
  • Transparent communication allows the delivery
    step of the design process to be removed
    completely along with the first step of the
    reception step, and is an integral part of the
    context specification mechanism. The provision of
    a global timeclock makes complex analysis of
    context possible by allowing context data to be
    compared on a temporal basis.

93
required features for a supporting framework
  • Constant Availability of Context Acquisition
  • CASs should not instantiate individual sensor
    components, but must be able to access existing
    ones. Furthermore, multiple applications may need
    to access the same piece of context. ?requirement
    that the components that acquire context must be
    executing independently from the applications
    that use them.
  • This eases the programming burden on the
    application designer by not requiring her to
    instantiate, maintain or keep track of components
    that acquire context, while allowing her to
    easily communicate with them, as needed.

94
required features for a supporting framework
  • Because these components run independently of
    applications, there is a need for them to be
    persistent, available all the time.
  • Constant availability of context acquisition
    components facilitates the ability to locate
    existing context sensing components found in the
    specification step. Because these components are
    persistent and are independent from applications,
    they can be found and used by any application. If
    existing components can be found, the need for
    the acquisition step is removed.

95
required features for a supporting framework
  • Context Storage
  • A requirement linked to the need for constant
    availability is the desire to maintain historical
    information.
  • A component that acquires context information,
    should maintain a history of all the context it
    obtains.
  • this feature removes the substep dealing with the
    storing of context in the acquisition step of the
    design process. It also allows complex analysis
    to be performed by providing a source of
    historical/past context.

96
required features for a supporting framework
  • Resource Discovery
  • With a resource discovery mechanism, when an
    application is started, it could specify the type
    of context information required. The mechanism
    would be responsible for finding any applicable
    components and for providing the application with
    ways to access them.
  • For example, in the In/Out Board, rather than
    hard-coding the location of the iButton reader
    being used, the developer can indicate that the
    application is to be notified whenever any user
    of the In/Out Board enters or leaves the building.

97
required features for a supporting framework
  • This resource discovery feature would not only be
    useful at runtime, but also at design-time. An
    application designer could use the resource
    discovery mechanism to determine whether the
    context she requires is already available in the
    environment or in combination with the
    specification mechanism and the constant
    availability of context components to determine
    what situations can be sensed and whether a given
    context request can be fulfilled by the currently
    executing infrastructure. If the current
    infrastructure does not provide the needed
    context, the designer will know what components
    need to be added.

98
required features for a supporting framework
  • A resource discovery feature allows us to remove
    the first part of the reception step in the
    design process. With this feature, applications
    do not need to explicitly or a priori know where
    specific sensors are. Instead, in combination
    with the specification mechanism, they can
    request a certain type of context and be
    automatically connected to the sensor or
    interpreter that can satisfy the request.
  • at design time, a developer can locate what
    components already exist in the environment,
    allowing her to determine what components, if
    any, need to be added, simplifying the
    specification step.

99
System Issues (1/2)
  • Programming model
  • Programming the physical world
  • Unreliable sensors, recognition algorithms, plus
    standard distributed computing issues
  • Interoperability
  • Sensors, services, and devices
  • Useless if everyone has proprietary / custom
    systems
  • Need standard data formats, protocols, and
    frameworks
  • Varying capabilities of sensors, services, and
    devices
  • Evaluation

100
System Issues (2/2)
  • May need a middleware layer to decouple
    applications and context sensing
  • Collect raw context, translate to
    application-understandable format, disseminate it
  • Centralized context server
  • Distributed architecture

101
Intelligence
  • Who is smart? User or system or both
  • Who makes the decisions on what actions to take?
  • Tradeoff between user cognitive load and effort
    to make system smart

102
People Issues
  • Avoiding embarrassing situations
  • Active Badges bathrooms
  • Inconvenient phone forwarding
  • Avoiding dangerous situations
  • Need to take into consideration cost of mistake
  • Smoke alarms when cooking
  • Lights that turn off when you're still there
  • Woman locked in "smart toilet stall"
  • Will adding more context really h
About PowerShow.com