The Atlas Sensor Platform Architecture - Part II CNT Dr. Sumi Helal Computer & Information Science & Engineering Department University of Florida, Gainesville, FL

Reading List Two papers will be provided via .

Main Aspect of Atlas Architecture A Service Oriented Device Architecture (SODA) that enabled use of SOA as a Programming Model for Pervasive Spaces –Device Description Language (DDL) –Atlas Sensor Platform –Atlas Middleware

Atlas Limitations The Ant, the Elephant, the Monkey and the Giraffe The over-promise of the Service Oriented Device Architecture (SODA) SODA too powerful to be safe as a programming model for pervasive spaces

Addressing the Over-promise Limitation Sensor Virtualization Phenomena Clouds

Virtual Sensors Singleton Virtual Sensor Basic Virtual Sensor Derived Virtual Sensor Collection of Basic and other Derived Virtual Sensors Type of Phenomena Aggregation Rules Location.... Knowledge Physical Sensor Data Quality Indicator

Phenomena Detection and Tracking Instead of relying on a sensor reading, detect a phenomena cloud Example: Walking Effect of a Footstep on the Smart Floor

Detection and Tracking of Phenomena Clouds Contemporary systems such as Nile-PDT use a streaming approach where processing is done in a central query processor executing on a powerful backend server. We utilize in-network, localized algorithms where detection and tracking processes are executed on sensor nodes clustered in the region where phenomena clouds are present at any given time.

Phenomena Cloud Definition A phenomenon cloud P is expressed as a 5-tuple: P = ; where: [a, b] defines the range of magnitude of the phenomenon, pT defines threshold probability, m defines sliding window size and, n defines minimum quorum.

Steps in the Detection & Tracking Process Initial Selection & Monitoring Initial Occurrence Growth of Phenomenon Cloud Idle SensorPotential Candidate Candidate Tracking Shrinking of Phenomenon Cloud

Phenomena Detection Optimizer Full Density Algorithm (FDA) Optimized Density Algorithm (ODA) Edge Algorithm (EA) For Full Density tracking, StreamPDT uses 4.66 times and 6.24 times more than that of our algorithms in term of update message and energy. For edge tracking, the number of update message and energy consumption used by TOCOB are 2.94 times and 8.38 times more than that of our EA respectively.

Addressing the Safety Limitation Domain-Independent Safety Ontology Program –Wide Safety System Wide Safety

Elements and Space Safety Identify stakeholders who possess various concerns and safety knowledge. Device Safety Service Safety Space Safety User Safety “SAFE” PERVASAIVE SPACE Space Device manufacturer Space domain expert User Service developer Device specs & operation protocols Space-specific safety knowledge & concerns Customized safety preferences & profiles Constraints imposed by services / applications

Overarching Safety Architecture

DiOS: Ontology Overview Severe Context Impermissible Context Permissible Context Desirable Context Guarded Context Risky Context is-a Context Entity Entity Attribute is-a Situation Context Entity Set Situation Attribute Set Attribute Context is-a member of has Pervasive Space User Physical Space has-a has Service has Device Service Service Method has Environment Attribute has is-a Pre-condition Effect has is-a DiOS Core DiOS Periphery