Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Programming Abstractions in Wireless Sensor Networks PowerPoint Presentation
Download Presentation
Programming Abstractions in Wireless Sensor Networks

Programming Abstractions in Wireless Sensor Networks

150 Vues Download Presentation
Télécharger la présentation

Programming Abstractions in Wireless Sensor Networks

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Programming AbstractionsinWireless Sensor Networks Professor Jack Stankovic Department of Computer Science University of Virginia

  2. Importance • Raise the level of abstraction • Move out of the domain of HW and embedded systems programmer • Amplify the applications addressed – programmed by domain experts • More reliable • One of the most important areas of research to make WSN widely used

  3. Context System Development Environment Analysis/Tools Use of System SQL/Queries Actual Programming Applications prog. Systems prog.

  4. Programming Models (9) • Environmental (domain specific -> tracking, monitoring environment, medical…) • EnviroSuite • Data/Database Centric - Queries • SQL, TinyBD, Cougar • Statistical and range queries • Middleware APIs and Services • Group Management, Token machine language (Regiment), Milan (QoS based), Agilla • Support for other models • Components • Database • Event • Agent

  5. Programming Models (9) • Components • nesC • Virtual Machines • Mate • Functional Macro-programming • Regiment (regions, streams) • (Mobile) Scripts • SensorWare • Extend TCL interpreter with support for commands such as query, send, wait, replicate, … • Provides execution environment for Scripts • Events • Publish/subscribe • DSWare, SNEDL, Impala

  6. Programming Models (9) • Networks of Networks • Across the Internet

  7. Abstractions • Program as a whole – not individual nodes • Hide details (which ones, expose what) • Single node decisions • Asynchrony • Race conditions • False alarms • Retries • Physical details (e.g., location, sensor characteristics, …) • Faults • Scale • Storage locations

  8. Environmental Paradigm • Current Paradigms • Single node abstractions • Explicit interactions between nodes • Read sensor data; fuse data; move data • Set actuators • Environmental Paradigm • Reflect the physical world directly • Virtual world of entities (fire, people, vehicles, pesticide, velocity, location, areas, …)

  9. EnviroSuite • Way to think • Events – measurable environmental activities • Events mapped to programming objects • Computation is attached to these objects • Report location, compute velocity, … • Library provides protocols for sensor data processing, object maintenance, inter-object coordination, aggregation mechanisms, etc.

  10. EnviroSuite

  11. EnviroSuite event-object VEHICLE { object_creation_condition = ferrous object && background sound object_resolution = 6; // minimal distance between // two events object_function = report.Location; object_function = report.Speed; } This statement is supported by drivers in a library: ferrous object && background sound

  12. Level of Knowledge Required • Ferrous object • Which signal processing module? • What parameter specifications need to be made? • We are programming in an application that interacts with the environment – how divorced from that fact can the programmer be?

  13. Programming Model Context Type: Car Context Label Context Type: Person Context Label Tracking Objects Tracking Objects Aggregate State Variables Aggregate State Variables External Entity Network Abstraction Layer

  14. Contexts and Objects • Contexts: Encapsulate entity state and tracking objects • Tracking objects: Perform entity-specific computation, communication and sensing Attached Tracking Objects Context State Programmer’s View Entity History ID

  15. Communication • Objects may export methods for remote invocation Attached Tracking Objects Attached Tracking Objects Context Context State Programmer’s View

  16. Attaching Objects begin contexttracker sense: magnetic() + motion(); state: location = avg (position,3,2); end begin objectreporter send (state, home); end begin objectmic turn-on microphone send (sound, home); end Attach Statee( ) = average position Programmer’s View Entity History Members ID Leader Sensee( ) = TRUE

  17. Summary • Program in C++ or Java – like language • Library supports domain specific abstractions • E.g., Java Swing supports programming GUIs • Pre-compiler maps programming abstractions to underlying “system” • E.g., could map to nesC and TinyOS

  18. Middleware

  19. Middleware APIs • Group Management • Create • Terminate • Merge • Join/Leave • Assign function • Track target • Classify target • Map temperature region • Consensus

  20. Group Management IR Camera Leader Follower Member Node

  21. Group Management IR Camera Leader Follower Member Node

  22. Examples: Tracking andMap Regions Base Station

  23. Group Management - API • Create_Group(name,function,criterion,atleast,accuracy) - implicit and explicit • Destroy_Group(name) • Join() • Leave() • Merge() • Move_COG() • Expand() -- to gain sensing confidence • Shrink() -- to save power • Commit(grp_ID) - to synchronize group re-configurations

  24. API for Other Services • Naming • Directory • Location • Monitor • Configure • …

  25. Virtual Machine - Mate 24 Instruction Programs Each instruction executes as task (slow) Code capsules Mate VM (interprets) TinyOS

  26. Code Capsules • One capsule = 24 instructions • Fits into single TOS packet • Energy efficient • Atomic reception • Code Capsule • Type and version information • Types: send, receive, timer, subroutine • Larger programs – use several capsules

  27. Value • Re-programmability • Re-task a network • Parameter adjustment • Self-replication • One of the special instructions on the VM is forward (which supports a viral-like infection of the entire network) • Incremental addition of new nodes

  28. Propagation Example

  29. Node Enters the Network

  30. Instruction Set • One byte per instruction • Three classes: basic, s-type, x-type • basic: arithmetic, halting, LED operation • s-type: messaging system • x-type: pushc, blez • 8 instructions reserved for users to define • Instruction polymorphism • Example: add(data, message, sensing)

  31. User Defined Instructions 24 Instruction Programs 1 3 Instructions Understood by Mate User defined Code capsules Mate VM (interprets) - Sound alarm TinyOS 3 1 2 3 4 - Write to flash 1

  32. Mate Architecture • Stack based architecture • Operand stack • Return address stack • Three events/execution contexts: • Clock timer • Message reception • Message send

  33. Code Example(1) • Display Counter to LED

  34. Code Example(2) • Sense and Send

  35. TinyOS Sense and Send event result_t Timer.fired() { if (state == IDLE && call Photo.sense()) {state = SENSE;} return SUCCESS; } event result_t Photo.dataReady(uint16_t data) { if (state == SENSE) { packet->reading = data; if (call SendMsg.send(packet, sizeof(DataBuf)) { state = SENDING; } else {state = IDLE;} } return SUCCESS; } event result_t SendMsg.sendDone(TOS_MsgPtr msg) { if (state == SENDING) {state = IDLE;} return SUCCESS; }

  36. Component Breakdown • 7286 bytes code, 603 bytes RAM

  37. Summary • Layer of software that can interpret programs • Easy to download new programs • Power of VM will relate to ease of programming • E.g., Java versus Mate

  38. Networks of Networks Road and Street Networks Environmental Networks Industrial Networks Heterogeneous Networks with Sensors and Actuators (HNSAs) Battlefield Networks Building Networks Vehicle Networks Body Networks

  39. Motivating Applications Home Home Application 1: Musical Tracking Home Application 2: Alarm System

  40. Motivating Applications Forest Home Forest Application 1: Temperature Monitoring Forest Application 2: Animal Tracking

  41. Motivating Applications Forest Home Road Application 1: Traffic Monitoring Road Application 2: Traffic Law Enforcement Road MESSAGE

  42. Motivating Applications Forest Home Road Cross Network Application 1: Protection Against Wild Animals

  43. Motivating Applications Forest Home Cross Network Application 2: Wild Animal & Automobile Protection Road MESSAGE

  44. System Architecture Programming Station Internet Server Server Local Transport Protocol Local Transport Protocol Nodes Nodes

  45. System Architecture Programming Station Internet Server Server Local Transport Protocol Local Transport Protocol Nodes Nodes Information about Services, Interfaces Location

  46. System Architecture High level Programming Language Programming Station EXE Internet High Level Virtual Machine High Level Virtual Machine Server Server Local Transport Protocol Local Transport Protocol Nodes Nodes Low Level Virtual Machine Low Level Virtual Machine

  47. System Architecture Programming Station Internet Server Server Local Transport Protocol Local Transport Protocol Responsible for Resource management User access rights Nodes Nodes

  48. System Architecture Programming Station The Physicalnet Omnix Physical Network Internet Server Server Local Transport Protocol Local Transport Protocol Nodes Nodes Omnix Physical Network

  49. Summary • Future Problem • Java-like language with different levels of VMs

  50. Questions • What should a programmer see? • New language • New middleware • Services • Components • Abstract models • All the above • None of the above