Transcript Sensor Platforms CNT5517 – Mobile Computing

Programming Models in
Pervasive Spaces
CNT 5517-5564
Dr. Sumi Helal
Computer & Information Science & Engineering Department
University of Florida, Gainesville, FL 32611
[email protected]
Reading Materials
1. H. Yang and A. Helal, "Safety Enhancing Mechanisms for Pervasive Computing
Systems in Intelligent Environment", In Proceedings of the Middleware Support for
Pervasive Computing Workshop, held in conjunction with IEEE PerCom 2008, Hong
Kong, March 2008. (pdf)
2. H. Yang, E. Jansen and A. Helal, "A Comparison of Two Programming Models for
Pervasive Computing," Proceedings of the Workshop on Ubiquitous Networking and
Enablers to Context Aware Services. In conjunction with the IEEE/IPSJ International
Symposium on Applications and the Internet (SAINT), Phoenix, Arizona, January
2006. (pdf)
3. C. Chen and A. Helal, "Device Integration in SODA using the Device Description
Language," Proceedings of the IEEE/IPSJ Symposium on Applications and the
Internet, July 2009, Seattle, Washington, USA.
4. Scott de Deugd, Randy Carroll, Kevin E. Kelly, Bill Millett, and Jeffrey Ricker, "SODA:
Service-Oriented Device Architecture," IEEE Pervasive Computing, vol. 5, no. 3,
2006, pp. 94-C3. (pdf)
5. R. Bose, A. Helal, V. Sivakumar and S. Lim, "Virtual Sensors for Service Oriented
Intelligent Environments," Proceedings of the Third IASTED International Conference
on Advances in Computer Science and Technology, Phuket, Thailand, April 2-4,
2007. (pdf)
The Need for Programming Models
• Development with ad-hoc strategy in integrated
environment is not scalable
• Programmability is essential if a full life-cycle of
the pervasive space is to be supported
• 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
What is Programmable?
•
•
•
•
•
•
•
•
User Safety
User Desires and Expectations
User Concerns and Frustrations
User Privacy
Space (Environment) Safety
Space Rules
Human Computer Interface
Availability of Service (AoS)
Emerging Models
•
•
•
•
Service Oriented Models
Reactive Models
Context Driven Models
Safety Oriented Models
Safety Perspective
Safety
Mortar
& Brick
Safety
Oriented
Models
Context
Driven
Models
Service
Oriented
Models
Minimal Accepted Safety
Expressiveness
Service Oriented Model
• Each sensor, actuator or device in the space is
represented by a service
– How? (See [3][4]) - Role of standards
• Software services
• Service composition into applications, also
represented as services
• Main Gain:
– Automatic Integration
– Openness
– Programmability using well-established model & tools
Automatic Integration
(Plug & Play into the Pervasive Space)
• A joining entity should be able to explore the
pervasive space to self-integrate itself as a service
and to possibly enable the activation of other
composite services
• A joining entity should be able to contribute
meaningful knowledge to the pervasive space to
enable powerful programming models.
• A leaving or failed entity is automatically and cleanly
removed from the pervasive space.
Openness
(Nov 22, 2007, Silicon Valley, CA: XYZ, Inc. “opens doors” with its
SmartKnob product for smart homes)
• The pervasive space is open and flexible
to embrace a variety of entities without any
special favor towards particular
participants or their underlying technology.
• Openness via the use of well-established
existing standards.
• Additional “needed” standards are
proposed.
Programmability
(Visual Studio/eclipse for Pervasive Spaces )
• Pervasive Space aware of its sensors, actuators,
contexts & applications (goals)
• Pervasive space able to map itself automatically into a
project in an IDE.
• Program the pervasive space via “logical wiring” within
the IDE.
• Notice IDE is used here as both a development tool and
a run-time control and information environment.
• Different IDE’s for different programmers:
– Computer scientist programmers
– Domain expert programmers.
SOA Model:
Critical Consequence
Ease of Integration via SOA
Fault-Tolerance due to SOA
Virtual Sensors
Sustaining SOA Model in Pervasive Spaces
Service
Service
Service
Knowledge
Collection of Sensors
Virtual Sensors Classification
Derived Virtual
Sensor
Singleton Virtual Sensor
Knowledge
Basic Virtual
Sensor
Type of Phenomena
Measurement Unit
Location ....
Single Physical Sensor
Singleton Virtual
Sensor
Physical Sensor
Virtual Sensors Classification
Derived Virtual
Sensor
Basic Virtual Sensor
Knowledge
Basic Virtual
Sensor
Type of Phenomena
Aggregation Formula
DQI....
Collection of Singleton
Virtual Sensors
Singleton Virtual
Sensor
Physical Sensor
Virtual Sensors Classification
Derived Virtual
Sensor
Derived Virtual Sensor
Knowledge
Basic Virtual
Sensor
Singleton Virtual
Sensor
Physical Sensor
Type of Phenomena
Aggregation Rules
Location ....
Collection of Basic and
other Derived Virtual
Sensors
Virtual Service Composition
User Application
select ‘weather’ from location = ‘area51’
Framework Controller
Knowledge
Weather Sensor
(Derived VS)
Temperature Sensor
(Basic VS)
area51
area50
Base
Humidity Sensor
(Basic VS)
area48
area49
Extending Availability
• Collect similarity statistics to determine groups of
sensors exhibiting similar behavior over time
• When a sensor fails, approximate its readings using
other live sensors
• Decision regarding which live sensor to choose is
made using similarity statistics such as Euclidean
distance
Measuring Data Quality [5]
• Data Quality Indicator (DQI) associated with reading
from each virtual sensor service
• Gives a quantitative measure of sensor data quality
• Takes into account whether sensor readings are
originating from live and intended sensors, or are
being approximated
• DQI = 100 * (NC + Σg(ts – Tstart)Ws) / N
s є SF
Comparison of Data Quality
Gain in Reliability
Data Quality Threshold
Gain in Availability
Context-Driven
Programming Model
• A formal framework for contexts and
action semantics, based on domain
ontology.
• Capable of evaluating potential actions
based on currently active context
• Capable of defining and detecting
conflicting actions
• Capable of defining and preventing
dangerous contexts
Context-Driven
Programming Model (cont’d)
• Simple programming procedure to
program the pervasive space
– Defines
– Mappings of Contexts to Actions
– Reporting
• Less expressive than the SOA model
– Limits by the procedure, which follows the
model (no time capture), simple logic.
Programming Procedure
•
Design the Context Graph:
–
•
Decide what the domains of interest are, and what the
contexts of interest within these domains are.
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?
• 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.
IDE (Context Model) Entity View
IDE (Context Model) Behavior View
Safety-Oriented Programming Model
• High expressive with explicit safety
guarantees / enforcements
• Expressiveness: relies on SOA (e.g. Atlas)
• Safety: No absolute safety guarantees
– Large safety net open for expansion
– Enforcement and guarantees throughout the
entire pervasive space life cycle.
Comparing Programming Safety
Computer System vs. Pervasive Space
Y = X/0
Memory
access
violation
Divide
by 0
Interrupt
Fire Alarm
Out of
Impermissible Range
Context
Exception
Four Critical Elements
1.Devices: Sensor
& Actuator
2.Services &
Applications
3.User
4.Space
The Auto scooter Concept
• The all-around
rubber bumper
• The flat-out speed
• The over-turning
wheels
• Corrective driving
Device Safety
• Ensure inclusion of device exception handling routine
• Avoid conflicting directives and unsafe/unacceptable
operations (utilizing context)
• Regulate the incoming commands and detect
abnormal command, access pattern (frequency) and
out of range setting (operational compliance)
Service Safety
• Define impermissible contexts
• Map impermissible contexts to services
(M-M)
• On detecting impermissible contexts,
deactivate corresponding services.
User Safety
• Express user safety concerns in form of
user profile
• Device mechanisms that map and enact
safety concerns (knowledge) into compiletime and run-time safeguards
Space Safety
• Similar to user safety, express space
safety concerns as a user profile
• Allow for space safety to integrate with
user safety (personalizing the space safety
concerns)
• Map and enact space safety into compiletime and run-time safeguards
Piecing Space element Safety
Space
“SAFE” SPACE