Programming models in pervasive spaces cnt 5517 5564
This presentation is the property of its rightful owner.
Sponsored Links
1 / 34

Programming Models in Pervasive Spaces CNT 5517-5564 PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Programming Models in Pervasive Spaces CNT 5517-5564

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Programming models in pervasive spaces cnt 5517 5564

Programming Models in Pervasive SpacesCNT 5517-5564

Dr. Sumi Helal

Computer & Information Science & Engineering Department

University of Florida, Gainesville, FL 32611

[email protected]


Reading materials

Reading Materials

  • 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)

  • 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)

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

  • 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)

  • 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

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

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

Emerging Models

  • Service Oriented Models

  • Reactive Models

  • Context Driven Models

  • Safety Oriented Models


Safety perspective

Safety Perspective

Safety

Mortar

& Brick

Safety

Oriented

Models

Context

Driven

Models

Service

Oriented

Models

Minimal Accepted Safety

Expressiveness


Service oriented model

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

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.


Programming models in pervasive spaces cnt 5517 5564

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

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

SOA Model:Critical Consequence

Ease of Integration via SOA

Fault-Tolerance due to SOA


Virtual sensors sustaining soa model in pervasive spaces

Virtual SensorsSustaining SOA Model in Pervasive Spaces

Service

Service

Service

Knowledge

Collection of Sensors


Virtual sensors classification

Virtual Sensors Classification

Singleton Virtual Sensor

Derived Virtual Sensor

Type of Phenomena

Measurement Unit

Location ....

Knowledge

Basic Virtual Sensor

Single Physical Sensor

Singleton Virtual Sensor

Physical Sensor


Virtual sensors classification1

Virtual Sensors Classification

Basic Virtual Sensor

Derived Virtual Sensor

Type of Phenomena

Aggregation Formula

DQI....

Knowledge

Basic Virtual Sensor

Collection of Singleton Virtual Sensors

Singleton Virtual Sensor

Physical Sensor


Virtual sensors classification2

Virtual Sensors Classification

Derived Virtual Sensor

Derived Virtual Sensor

Type of Phenomena

Aggregation Rules

Location ....

Knowledge

Basic Virtual Sensor

Collection of Basic and other Derived Virtual Sensors

Singleton Virtual Sensor

Physical Sensor


Virtual service composition

Virtual Service Composition

User Application

select ‘weather’ from location = ‘area51’

Framework Controller

Weather Sensor

(Derived VS)

Knowledge

Base

Temperature Sensor

(Basic VS)

Humidity Sensor

(Basic VS)

area51

area48

area50

area49


Extending availability

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

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

Comparison of Data Quality

Gain in Reliability

Data Quality Threshold

Gain in Availability


Context driven programming model

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

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

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

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) Entity View


Ide context model behavior view

IDE (Context Model) Behavior View


Safety oriented programming model

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

Divide by 0 Interrupt

Memory access violation

Fire Alarm

Impermissible Context

Out of Range Exception

Comparing Programming Safety Computer System vs. Pervasive Space


Four critical elements

Four Critical Elements

  • Devices: Sensor & Actuator

  • Services & Applications

  • User

  • Space


The auto scooter concept

The Auto scooter Concept

  • The all-around rubber bumper

  • The flat-out speed

  • The over-turning wheels

  • Corrective driving


Device safety

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

Service Safety

  • Define impermissible contexts

  • Map impermissible contexts to services (M-M)

  • On detecting impermissible contexts, deactivate corresponding services.


User safety

User Safety

  • Express user safety concerns in form of user profile

  • Device mechanisms that map and enact safety concerns (knowledge) into compile-time and run-time safeguards


Space safety

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 compile-time and run-time safeguards


Piecing space element safety

Piecing Space element Safety

Space

Space Safety

Device Safety

“SAFE” SPACE

Service Safety

User Safety


  • Login