Sensor Networks. Dr. Sumi Helal & Jeff King CEN 5531

Transcription

1 Sensor Networks CEN 5531 Slides adopted from presentations by Kirill Mechitov, David Culler, Joseph Polastre, Robert Szewczyk, Cory Sharp. Dr. Sumi Helal & Jeff King Computer & Information Science & Engineering Department University of Florida, Gainesville, FL Phone: (352) MobileIP 1

2 Outline What are Sensors and Sensor Networks? Motivation The Berkeley MOTE TinyOS & NesC The UF Sensor Platform Lab Demo MobileIP 2

3 Wireless Smart Sensors Ref: Kirill Mechitov MobileIP 3

4 Network Embedded Systems Ref: Kirill Mechitov Embedded systems are the future of computing Low-cost hardware Many application areas Already more embedded processors than desktops, and the gap is increasing Most embedded processors act independently Industrial control systems, u-controllers in cars, etc. Connecting embedded systems into networks enables new class of applications MobileIP 4

5 Network Embedded Systems Low-power, inexpensive embedded processors cannot perform very complex tasks But a network of such systems can be very powerful Example: sensor networks Each processor is equipped with a sensor Becomes a smart sensor node Ref: Kirill Mechitov MobileIP 5

6 Sensor Networks Data from multiple sensors is processed and combined into big picture Sensor coverage Sensors can be deployed to cover a large area Reliability Redundant sensor readings Resiliency to failure of individual sensors Cost Many inexpensive sensors can be cheaper than one powerful sensor Ref: Kirill Mechitov MobileIP 6

7 Wireless Sensor Networks Sensor networks where nodes communicate over wireless channels Ease of deployment No infrastructure required Once placed in the area of interest, sensors automatically assemble into an ad hoc network Reliability No wires that can be damaged or cut Ref: Kirill Mechitov MobileIP 7

8 WSN in the lab Ref: Kirill Mechitov MobileIP 8

9 WSN in the Field Ref: Kirill Mechitov MobileIP 9

10 WSN Environment Large-scale systems where: Nodes and links have limited capabilities. Real-time requirements must be met in the absence of a predefined global clock. Faults are common. Delays failures Ref: Kirill Mechitov MobileIP 10

11 Challenges Distributed processing Need algorithms that are not centralized, i.e., do not require all of the data Low bandwidth communication Efficiently move large amounts of sensor data for processing Large scale coordination Many independent sensor nodes need to act in concert with one another Real-time computation Ref: Kirill Mechitov New data is always coming, so it must be processed faster than it is generated MobileIP 11

12 Routing and Group Communication Routing delivers messages to a specific node in the network Multi-hop, ad hoc Old problem, but needs new approach in the sensor network environment Group communication (multicast) delivers messages to a subset of nodes in the network Needed to communicate to groups of sensors Parameters: reliability, efficiency, power consumption Ref: Kirill Mechitov MobileIP 12

13 Data Aggregation Combines data from many sensors into a more compact form before forwarding to a location for processing Needed to handle the large amount of data generated in sensor networks Parameters: efficiency, speed Ref: Kirill Mechitov Forwarding vs. Aggregation traffic vs. distance from sink without data aggregation MobileIP 13

14 Clock Synchronization Sensors clocks drift slightly over time Need to periodically adjust the local clocks so that time is consistent throughout the network Especially important for sensors around same joint to detect failures Parameters: precision, update frequency beacon exchange time of beacon & adjust clocks Ref: Kirill Mechitov MobileIP 14

15 Localization Determine the physical locations of the sensors If thousands of sensors are deployed, don t want to enter their locations by hand Use sensing or network connectivity to infer physical location Parameters: precision, efficiency Ref: Kirill Mechitov proximity triangulation MobileIP 15

16 Fault Tolerance Some sensors may fail Due to the large number of sensors in WSNs, faults are common: not an exception but the rule The network needs to keep working, even if with diminished capacity Parameters: resiliency, response time Ref: Kirill Mechitov MobileIP 16

17 The Berkeley MOTE MobileIP 17

18

19

20 Open Experimental Platform WeC 99 Smart Rock Rene 11/00 Dot 9/01 TinyOS Networking Mica 1/02 Services Telos 4/04 Robust Low Power 250kbps Easy to use Small microcontroller 8 kb code 512 B data Simple, low-power radio 10 kbps ASK EEPROM (32 KB) Simple sensors Designed for experimentation -sensor boards -power boards Demonstrate scale NEST open exp. Platform 128 kb code, 4 kb data 40kbps OOK/ASK radio 512 kb Flash Mica2 12/ kbps radio FSK Spec 6/03 Mote on a chip Commercial Off The Shelf Components (COTS) MobileIP 20 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

21 Mote Evolution MobileIP 21 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

22 Low Power Operation Efficient Hardware Integration and Isolation Complementary functionality (DMA, USART, etc) Selectable Power States (Off, Sleep, Standby) Operate at low voltages and low current Run to cut-off voltage of power source Efficient Software Fine grained control of hardware Utilize wireless broadcast medium Aggregate MobileIP 22 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

23 Typical WSN Application Periodic Data Collection Network Maintenance Majority of operation Triggered Events Detection/Notification Infrequently occurs But must be reported quickly and reliably Long Lifetime Months to Years without changing batteries Power management is the key to WSN success Power sleep MobileIP 23 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler wakeup Time processing data acquisition communication

24 Design Principles Key to Low Duty Cycle Operation: Sleep majority of the time Wakeup quickly start processing Active minimize work & return to sleep MobileIP 24 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

25 Sleep Majority of time, node is asleep >99% Minimize sleep current through Isolating and shutting down individual circuits Using low power hardware Need RAM retention Run auxiliary hardware components from low speed oscillators (typically 32kHz) Perform ADC conversions, DMA transfers, and bus operations while microcontroller core is stopped MobileIP 25 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

26 Wakeup Overhead of switching from Sleep to Active Mode Microcontroller Radio (FSK) 292 ns 10ns 4ms typical 2.5 ms 1 10 ms typical MobileIP 26 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

27 Active Microcontroller Fast processing, low active power Avoid external oscillators Radio High data rate, low power tradeoffs Narrowband radios Low power, lower data rate, simple channel encoding, faster startup Wideband radios More robust to noise, higher power, high data rates External Flash (stable storage) Data logging, network code reprogramming, aggregation High power consumption Long writes Radio vs. Flash 250kbps radio sending 1 byte Energy : 1.5µJ Duration : 32µs Atmel flash writing 1 byte Energy : 3µJ3 Duration : 78µs MobileIP 27 Joseph Polastre, Robert Szewczyk & Cory Sharp, David Culler

28 Crossbow (Berkeley) Motes Crossbow Mica2 motes: a representative WSN platform Small size <16 cubic centimeters Multi-modal sensing Acceleration, magnetic field, sound, light, temperature Low bandwidth radio transceiver Up to 80m range Low power consumption 2 AA batteries last for months with low duty cycle Limited storage capacity 4KB of fast data memory, 512KB of slower permanent storage, 128KB of program memory Ref: Kirill Mechitov MobileIP 28

29 TinyOS & NesC TinyOS Operating system for motes Lightweight Event-driven NesC Ref: Kirill Mechitov Programming language for motes C-based Low-level Modular MobileIP 29

30 A Operating System for Tiny Devices? Traditional approaches command processing loop (wait request, act, respond) monolithic event processing bring full thread/socket posix regime to platform Alternative provide framework for concurrency and modularity never poll, never block interleaving flows, events, energy management => allow appropriate abstractions to emerge 5/5/2003 MobiSys Tutorial, San Francisco 30 Ref: David Culler, et al.

31 Tiny OS Concepts Scheduler + Graph of Components constrained two-level scheduling model: threads + events Component: Commands, Event Handlers Frame (storage) Tasks (concurrency) Constrained Storage Model frame per component, shared stack, no heap Very lean multithreading Efficient Layering init Commands init Power(mode) TX_packet(buf) power(mode) send_msg (addr, type, data) Messaging Component internal thread Events msg_rec(type, data) Internal State msg_sen d_done) TX_pack et_done (success RX_pack ) et_done (buffer) 5/5/2003 MobiSys Tutorial, San Francisco 31 Ref: David Culler, et al.

32 Application = Graph of Components application Route map router sensor appln Active Messages bit byte packet Radio Packet Radio byte RFM Serial Packet UART Temp ADC photo clocks MobileIP 32 SW HW Example: ad hoc, multi-hop routing of photo sensor readings 3450 B code 226 B data Graph of cooperating state machines on shared stack Ref: David Culler, et al.

33 TOS Execution Model commands request action ack/nack at every boundary call cmd or post task events notify occurrence HW intrpt at lowest level may signal events call cmds post tasks Tasks provide logical concurrency preempted by events Migration of HW/SW boundary bit byte packet application comp active message Radio Packet Radio byte RFM event-driven message-event packet-pump driven crc data processing event-driven byte-pump encode/decode event-driven bit-pump MobileIP 33 Ref: David Culler, et al.

34 Programming TinyOS TinyOS 1.0 is written in an extension of C, called nesc Applications are too! just additional components composed with the OS components Provides syntax for TinyOS concurrency and storage model commands, events, tasks local frame variable Rich Compositional Support separation of definition and linkage robustness through narrow interfaces and reuse interpositioning Whole system analysis and optimization MobileIP 34 Ref: David Culler, et al.

35 Event-Driven Sensor Access Pattern command result_t StdControl.start() { } return call Timer.start(TIMER_REPEAT, 200); event result_t Timer.fired() { } return call sensor.getdata(); event result_t sensor.dataready(uint16_t data) { } display(data) return SUCCESS; clock event handler initiates data collection sensor signals data ready event data event handler calls output command device sleeps or handles other activity while waiting conservative send/ack at component boundary SENSE Timer Photo LED MobileIP 35 Ref: David Culler, et al.

36 TinyOS Commands and Events {... status = call CmdName(args)... } event EvtName)(args) {... return status; } command CmdName(args) {... return status; } {... status = signal EvtName(args)... } MobileIP 36 Ref: David Culler, et al.

37 TinyOS Execution Contexts Tasks events commands Interrupts Hardware Events generated by interrupts preempt tasks Tasks do not preempt tasks Both essential process state transitions MobileIP 37 Ref: David Culler, et al.

38 TinyOS Tutorial Tutorial: MobileIP 38

39 Other Commercial Platforms Cube University College Cork, Ireland Stackable design Tiny OS Stalled, No middleware Phidgets University of Calgary, Canada Cheap, lots of available sensors Used in the GTSH Limited to USB, small networks, not scalable MobileIP 39

40 Problems with Sensor Platforms From DCOSS 2005 Panel Almost all focus on wireless Almost all focus on battery power Almost all focus on miniaturization Not designed for pervasive computing spaces MobileIP 40

41 MobileIP 41

42 UF Sensor Platform Combination of hardware and middleware Modular, flexible, stackable design Supports virtually any kind of sensor or actuator Support for large-scale pervasive environments MobileIP 42

43 What s Different? Plug-and-play development Support for large-scale pervasive computing environments Uniform software interface to heterogeneous Supports various types and numbers of devices Flexibility of swappable components Inexpensive MobileIP 43

44 Sensor Platform Hardware Power Wired power option for use with indoor applications. Layered Design For flexible configuration of processing, power, communication, and sensor/actuator needs. Sensors / Actuators Interface layer supports up to 8 analog sensors or actuators. Quick Connect For easy and reliable stacking. IP Networking Swappable communication layers to support different mediums. Full TCP/IP stack using µip. More Power Daisy-chain sensor platforms to create large networks without tying up all outlets. Processor ATmega128 provides low-cost and low-power processing. Runs OS that monitors sensor connections and communicates with server. Internal storage MobileIP 44 for sensor/actuator OSGi bundles and data accumulation for on-node processing.

45

46 Middleware Foundation - OSGi Tries to solve maintenance problem. Many components, many configurations. Standardized, component oriented, computing environment for networked services. Provides adds the capability to manage the life cycle of the software components in the device from anywhere in the network MobileIP 46

47 Scope of OSGi Standard software component model. Life cycle control. A secure sandbox environment. Dynamic discovery and use of services. Remote management architecture. Standardized, optional services. MobileIP 47

48 Middleware Architecture MobileIP 48

49 Programming the Hardware C code compiled by avr-gcc Driver bundle compiled and packaged by Java AVR Studio connects to JTAG and programs device MobileIP 49

50 What is the C code? uip network stack at the bottom Provides functions to encapsulate an application Hardware portion of the sensor platform middleware MobileIP 50

51 The C Code App.c Sensorplatform_init Init_connection Sensorplatform_app Sensorplatform_conf.h Sensorplatform_debug.h Main.c MobileIP 51

52 What is the driver/bundle? Implements PacketListener Interface Implements device-specific methods for its host device Manifest contains details of the bundles, which sensor platform ID, exported methods, vendor info, etc. MobileIP 52

53 Case Study: NILE PDT Application Level Nile-PDT Server Level Sensor Platform Sensor-network Level UFL Sensor Platform MobileIP 53

54 Nile-PDT Application MobileIP 54

55 Case Study: Gator Tech Smart House Smart Floor Smart Plugs Foundation of all systems MobileIP 55

56 On-going Research Increasing Plug-and-Playability Creating new communication layers Developing a smarter platform On-platform filtering and processing of data Secure and authorized transactions Privacy protections / localization of data MobileIP 56

57 Project Ideas Application using platforms Robotics Detection Monitoring and action Platform-level work Designing performance metrics & improving platform Improve uip MobileIP 57