System Software For Ubiquitous Computing

1
System Software For Ubiquitous Computing

• 2004.07.14
• Tae-Hoon Kang

2
Overview

• Introduction
• Two Key Characteristics of ubicomp systems
• Physical integration
• Spontaneous interoperation
• Software Challenges
• The semantic Rubicon
• Progress Report
• Discovery
• Interaction
• Adaptation
• Integration
• Programming Frameworks
• Robustness and routine failures
• Security.

3
Introduction

• Ubicomp software must deliver functionality in
  everyday world and must operate in conditions of
  radical change.
• Examine todays Ubiquitous systems, focusing on
  software infrastructure

4
Two Key Characteristics of ubicomp systems

• Physical integration
• Integration between computing nodes and the
  physical world
• Smart coffee cup
• Serves as a coffee cup
• Contains sensing, processing, and networking
  elements
• Smart meeting room
• Activate digital furniture from anywhere in the
  room using a PDA
• Ubicomp environment consists of multiple discrete
  ubiquitous systems rather than just one
• Boundary principle Ubicomp system designers
  should divide the ubicomp world into environments
  with boundaries that demarcate their content.

5
Two Key Characteristics of ubicomp systems

• Spontaneous interoperation
• Change both identity and functionality over time
  as its circumstances change.
• Change partners during its normal operation,
  without needing new software or parameters.
• E.g.) Visitor from another organization enters
  new organization and uses various devices without
  manually configuring it in any way
• Volatility principle Design ubicomp systems on
  the assumption that the set of participating
  users, hardware, and software is highly dynamic
  and unpredictable.

6
Boundaries and Components

• ??

7
Software Challenges

• Physical Integration -gt Resources sometimes
  highly constrained.
• Spontaneous Interoperation -gt Resources are
  highly dynamic.
• A ubicomp systems behavior must match users
  expectations of how the physical world behaves.
• Physical integration and Spontaneous
  interoperation have major implications for
  software infrastructure.

8
The semantic Rubicon

• Designers should make clear choices about what
  system software will not do but humans will.
• The semantic Rubicon the division between system
  and user for high level decision-making or
  physical world semantics processing.
• The division should be exposed in system design.
• The criteria and mechanisms for crossing it
  should be clearly indicated.

9
The semantic Rubicon
10
Progress Report - Discovery and interaction

• Service Discovery
• A newly arriving component needs address
  allocation and name resolution methods to use
  devices.
• Standard specification of services is needed for
  communication between user and devices
• ? Syntax and vocabulary for specifying services
  are performed several systems.
• Two opposite Problems
• attribute-value method
• Overspecification Must obey the same
  vocabulary and syntax.
• Lost opportunities Devices must contain
  specification of all services with which they can
  interact.
• Cooltown
• More abstract and much less detailed service
  specification, but can lead to ambiguity.
• System designers must decide the humans role
  resolve tension between interoperability and
  ambiguity.

11
Progress Report - Discovery and interaction

• Interaction
• How can the software on the device use the
  downloaded object without a priori knowledge of
  its methods?
• Event systems and tuple spaces.
• The system interface comprises a few fixed
  operations, and the data interactions are
  data-oriented.
• Event systems publish, subscribe, and handle.
• tuple spaces add tuples, take tuples, and read
  tuples.

12
Progress Report - Adaptation

• Limited and dynamically varying computational
  resource
• Calm computing-adaptation must often take place
  without human intervention.
• Transformation and adaptation for content and The
  human interface.
• Content
• Heterogeneity across the devices.
• Coda File System handling adaptation such as
  network disconnection in the operating system to
  enable application transparency.
• Odyssey Adapting web content for slow networks
  and small devices, shifted some responsibility to
  the application layer.

13
Progress Report - Adaptation

• Transformation and adaptation for content and The
  human interface.
• The human interface.
• To achieve ubiquitous scenario, requires
  separating user interfaces from their
  applications.
• For levels of client intelligence.
• VNC displays the bits and collects user input.
• LBX higher-level, using declarative description
  of the interface elements and render them itself.
• Tcl/Tk a client can generte its UI.
• Jini client download and excute arbitrary code
  or psedocode that implements the interfaced and
  communication with the service.

14
Progress Report - Integration with the physical
world

• Low-level APIs ? let software deal with physical
  sensors and actuators.
• Phidget a GUI widget element which controls
  physical sensor or actuators behavior directly.
• High-level software framework ? lets applications
  sense and interact with their environment.
• The Context Toolkit Framework provides
  applications with a context widget software
  abstraction, which hides how the information was
  sensed or collected.

15
Progress Report - Programming Frameworks

• How to write Hello World!
• Middleware meets requirements of incremental
  extensibility and legacy support

Application
Middleware
OS
16
Progress Report - Robustness and routine failures

• Radical increase of failure frequency.
• physical integration - failure due to battery
  exhaustion.
• spontaneous integration a devices suddenly
  leaves an environments
• Expiration-based schemes and soft state.
• Periodic advertisement persistently store and
  consider reconstructable soft state for the rest.
• Separating failure-free and failure-prone
  operations.
• Clearly indicate which ones are more likely to
  fail because of dynamism, so developers can
  provide more effective error handling.

17
Progress Report Security

• How to protect components from one another?
• Trust Humans can make judgments about
  trustworthiness
• Security for resource-poor devices No
  sufficient resource for encryption, limited
  battery life
• Access Control
• Problematic because devices can spontaneously
  appear or disappear ? we can use time-limited
  capabilities.
• Location
• Sometimes the only thing that matters is where,
  not who.
• Location authentication.
• New patterns of resource-sharing
• A more convenient and fine-grained model of
  protected sharing is required.

18
Conclusion

• Clearly define the two major characteristics of
  ubiquitous computing - physical integration and
  spontaneous integration.
• Contents-oriented programming Data-oriented
  programming using content that is standard across
  boundaries.
• The Semantic Rubicon must be specified during the
  development of system software.