Lecture XVI: Mobile and Ubiquitous Computing

1. Lecture XVI: Mobile and Ubiquitous Computing CMPT 401 Summer 2007 Dr. Alexandra Fedorova

2. Mobile and Ubiquitous Computing • Mobile computing – computers that users can carry • Laptops, handhelds, cell phones • Wearable computers • Heart monitors used by athletes (Tour de France: team manager monitors heart rates, give recommendations on tactics) • Health monitors used by elderly • Ubiquitous computing • Computers are everywhere • Each person uses more than one computer • PC, laptop, cell phone, watch, car computer (100+ microprocessors in some cars)

3. Enables New Cool Applications • Object tracking • Track location of a child, parent, dog, car (lojack) • Parents watch their babies in the daycare • Health monitoring • Monitor child breathing (prevent SIDS – sudden infant death syndrome) • Heart stimulation: embed hearth sensors in the elderly. If pulse goes too low, stimulate the pulse • Replace physicians visits (Neuromancer project at Sun Microsystems, Jim Waldo) • People wear health monitors • They collect health data normally measured by doctors/nurses • Eliminates the need for doctor visits – sensors can alert of dangerous health conditions • Massive data available – a chance to carry out longitudinal studies in medicine

4. Some Challenges • Limited power • Wearable devices and sensors have low battery power • To be interesting, sensors must transmit data • Data transmission uses power • How to minimize power consumption and maximize transmission of useful data? • Limited network bandwidth • Applications must communicate to sensors exactly what data they need, so sensors don’t transmit useless data • Limited connectivity • Mobile devices often operate in disconnected mode • How to associate to a new network seamlessly? • How to form a network without an infrastructure (ad-hoc networking)?

5. More Challenges • Sensor deployment • Sensors have limited lifetime, at some point they become useless • In ecologically sensitive environments – this means a bunch of silicon scattered around • Example: deploy sensors for forest fire detection. Scatter sensors around the forest (from a helicopter) • After a while you have a whole lot of improperly disposed batteries • Handling data • Once all these super-apps get implemented, we’ll have massive amounts of data collected by all imaginable sensors • Much of this data will be kept around for historical analysis • Where do we store this data? (P2P? – addressed by Neuromancer) • How do we make sure it’s safe (replication?) • How do we make sure it’s secure?

6. Case Studies of Sensor Networks • Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea, Krishnamurthy et al. • IrisNet: An Architecture for a Worldwide Sensor Web, Gibbons et al.

7. Industrial Sensor Networks • Sensor networks used for predictive equipment maintenance • Monitor industrial equipment • Detect oncoming failures • Alert humans of potential failures • We will talk about • Motivation • System architecture • System issues specific to wireless sensor networks • Two case studies • Semiconductor fabrication plan • Oil tanker in the North Sea

8. Predictive Equipment Maintenance (PdM) • Monitor and assess the health status of a piece of equipment (e.g., a motor, chiller, or cooler) • PdM allows to detect most failures in advance • But analysis has to be performed with sufficient frequency • Equipment has sensors attached to it • Sensors monitor conditions of the equipment • Report results to the operator’s computer • Operator analyses data, detects any unusual patterns, decides if failure is imminent • Takes action to replace the equipment

9. Types of Sensor Data • Vibration (used in this study) – analyze frequency and amplitude of vibrations over time • Identify unexpected changes – suggest repair or replacement • Source of vibrations must be identified and assigned to a specific component • Oil analysis – analysis of wear particles, viscosity, acidity and raw elements • Capture a small sample, compare to baseline samples – detect potential problems • Infrared Thermography– sense heat at frequencies below visible light • Detect abnormal heat sources, cold areas, liquid levels in vessels, escaping gases • Ultrasonic detection – detect wall thickness, corrosion, erosion, flow dynaics, wear patterns • Compare data to standard change rates, project equipment lifeime

10. Importance of PdM • Reduce catastrophic equipment failures • Save human lives • Reduce associated repair and replacement cost • Save money – switch from calendar-based maintenance to indicator driven maintenance • Calendar-based maintenance: may do maintenance when you don’t need to • May fail to do the maintenance when you really have to • Quantify the value of a new system within the warranty period • Meet factory uptime and reliability requirements

11. Existing PdM Technologies: Manual Data Collection Data is collected into a hand-held device A human operator visits the equipment under surveillance Sensors are installed in the equipment or brought by the operator Data is transported to the lab for analysis

12. Existing PdM Technologies: Online Surveillance Data acquisition unit Sensor Central repository Sensors are connected to equipment, hardwired to data acquisition unit Data acquisition unit processes the data and delivers it across a wired network to a central repository

13. Disadvantages of Existing Technologies • Manual data collection: • Potential for user error • High cost to train and keep experts • Cost of manpower for frequent data collection • Most users of manual data collection are not happy with the level of prediction and correlation • Online systems: • Cost of hardware and network infrastructure • Only appropriate for equipment with cost impact of over $250K in case of failure • Online systems are used in only 10% of the market (due to cost)

14. Wireless Sensor Networks for PdM • Provide frequency of monitoring comparable to online systems • Lower cost of deployment – network is wireless • Just drop the sensors and you are ready to go • Data acquisition unit needs not be specialized hardware • Just any computer that can listen for radio signals from sensors

15. Challenges in Deployment of Wireless Sensor Networks • Determine requirements for industrial environments: • How often does data need to be sampled? • In what form to transmit and organize the data? • How long will the sensor battery survive? • Effect of environment on deployment • What is the signal quality in the current environment? Lots of thick walls is bad for the signal • How often will the network be disconnected – i.e., in the ship the compartment containing sensors is periodically shut off • How to ensure the required quality • Sensors will fail, how do you ensure that sufficient data collection rates are achieved?

16. Setup for Vibration Analysis • Accelerometer – a device used to measure vibrations or accelerations due to gravity change or inclination • Measures its own acceleration, so it must be hard-mounted to the monitored equipment • In the experiment, an off-the-shelf accelerometer was used; it interfaces with the rest of the sensor board (radio, etc.) • Sensor network interfaces with an off-the-shelf software application – provides long term data storage, trend analysis, fault alarms

17. Site Planning • How/where to install the sensors given the particularities of a given site? • Sensors must be safe for the equipment they monitor • Radio Frequency (RF) coverage – are there walls and equipment preventing good RF coverage? Must relay nodes or gateways be installed? • RF interference – is there RF noise that will prevent good transmission? RF interference may come from other radios used on the site. • To assess these factors, a site survey is needed

18. Site Survey • Place test sensors near sensing points (where actual sensors will be mounted in the future) • Place test gateways (the machines that will receive data from sensors and transmit it further) at locations where actual gateways would be placed • Near power outlets and Ethernet jacks • Using test setup, evaluate wireless connectivity, RF coverage and interference

19. Site Survey Results • Sensor nodes with more powerful radios worked better in conditions with RF interference • Less powerful radios were not able to transmit through a door on the oil tanker • It had to be ensured that sensor node frequencies did not overlap with critical radio frequencies used on the oil tanker • Witnessed better RF performance on the oil tanker than was initially expected: • Attributed to use of steel materials on the ship • Steel materials reflect, rather than attenuate RF energy (unlike office and home environments)

20. Application Specific Requirements • Data must be accurate, acquired and transmitted in a timely manner • Challenge: sensors and data acquisition units will fail due to operation in a harsh environment • Solution: system must be designed with expectation for failure and with ability to quickly recover from failures • Long-lived battery powered operation • Sensor networks should not use plant power • Should be battery operated: must operate for a long time on one set of batteries, to avoid the need for frequent redeployment

21. Hardware Architecture Sensor node (Mica2 mote) • Two types of sensor nodes : • Mica2 Mote • Intel Mote • Mote: • Composed of a small, low powered computer • Radio transmitter • Connected to several sensors • The node’s sensor board is connected to vibration sensors

22. Hardware Architecture Comparison • Mica2 • Less powerful radio • No on-board storage for sensor data, so you need to attach additional storage to it • Intel • Very powerful radio: 10x throughput of the Mica2 mote • Uses more power

23. Network Architecture • Hierarchical architecture • Sensor clusters (sensor mesh) • Cluster head (connected to the gateway) • Stargate Gateway • mote radio • 802.11 radio • 802.11 backbone • Root Stargate • Bridge Stargate • Enterprise server

24. Data Collection and Transfer • Cluster head schedules data capture/transfer for every sensor connected to each node • When a node has captured data it initiates a connection to the Stargate gateway • Data is transferred using a reliable transport protocol • Sensor data is time-stamped and put in a file • There is a separate file for each collection of a sensor channel • Each Stargate gateway periodically copies file to the root gateway • Root gateway transfers data to Bridge gateway via serial cable – this is done to isolate wireless network from the corporate network • Bridge gateway transfers data to the enterprise server

25. Hierarchical Network Structure • Tier 1 – lowest level • Networks of sensor nodes • They form clusters: may be pre-assigned to a cluster or choose the cluster dynamically • Lowest compute capability, limitations on bandwidth and battery capaciry • Tier 2 – middle level • Sensor network backbone • Individual cluster gateways • Higher compute and power capacity – offload computational burden from Tier 1 • Tier 3 – highest level • Interface to the enterprise • Abstracts application needs from the sensor network

26. Sleep/Wakeup Schedule • Sensor nodes form a cluster around a gateway • Nodes in a cluster follow a sleep/wakeup protocol • When nodes wake up they acquire data from sensors and transmit it to the gateway • Then they go to sleep until the next data collection is scheduled • Sleep/wake-up operation saves battery power • Sleep/wake-up schedule is coordinated by a cluster head – a device connected to the gateway via a serial port

27. Power Management Protocol • Cluster head schedules sleep periods based on application-level sampling requirement • Upon initial discovery of nodes in the cluster, cluster head sends the first request for data collection • At the end of each data collection it sends a message indicating start time and duration of next sleep phase • Sensor nodes go to sleep and then wake up all together • When nodes are asleep they are not completely turned off, but they operate in a low power mode • Nodes’ clocks are not perfectly synchronized, so the cluster head waits for some “skew” period until beginning next data collection • Sleep periods in the oil tanker installation were set to 7 and 18 hours

28. Fault Tolerance • Sensor networks must operate in harsh environments for long periods of time • Failures are common and should be expected

29. Fault Tolerant Design • Four design features to increase fault tolerance: • Watchdog timers – a node resets itself upon encountering unexpected behavior • Cluster heads store network state – nodes can return to operation quickly after being reset • Intentional re-initialization of sensor nodes after each collection period • Non-volatile storage of critical state at cluster head – cluster head could be (and was) reset after each wake-up period

30. Watchdog Timers • Each node monitors events: • How much time has passed since last packet reception (in the wake state) • Events signifying radio lockups • Protocol events – e.g., receipt of new data send request before the previous one was finished • The node resets itself if any of these unexpected events was detected

31. Comparing Power Consumption • Active power – power when the network is awake • Similar usage of active power per unit of time • But Intel motes spent less time being awake, because they had faster radios • So Intel-based network used less power overall • Power during the sleep phase • Intel network implemented a connected sleep mode • You can still access the network while the nodes are asleep, albeit at a higher latency • So it used more power in the sleep mode • If Intel-based network were completely disconnected, it would use only slightly more power as Mica2-based network • Using an external real-time clock can enable completely turning off the network during the sleep mode – even more power would be saved

32. Battery Life • On the oil tanker, two lengths of sleep mode were used: • 18 hour sleep period • 5 hour sleep period • Resultant battery lives are: • 18-hour period: 82 days • 5-hour period: 21 days

33. Case Studies of Sensor Networks • Design and Deployment of Industrial Sensor Networks: Experiences from a Semiconductor Plant and the North Sea, Krishnamurthy et al. • IrisNet: An Architecture for a Worldwide Sensor Web, Gibbons et al.

34. IrisNet • A slightly different environment than conventional sensor networks • Many devices: PCs, hand-helds, cameras • Good connectivity, no power limitations • Provide useful data • Question: • How do we access and integrate this data to enable interesting applications? • Solution: • Architecture for a Worldwide Sensor Web

35. IrisNet Vision • A user will query, as a single unit, vast quantities of data from thousands of widely distributed sensors • Many possible uses: • Epidemic Early Warning System - monitor water quality, oil spills • Homeland Security • Computer Network Monitoring – gather (sense) data on bandwidth/CPU usage; answer queries such as “What’s the least loaded node at SFU?” • Traffic / Parking Assistance – help me find hockey game parking in Vancouver

36. IrisNet Goals • Planet-wide local data collection and storage • Massive amounts of data • Retain data near its source, transmit to the Internet only as needed • Ease of service authorship • Vision: when sensors are deployed, we don’t know all potential users • Different service providers might want to collect different data and different rates and apply different filters depending on the service • Real-time adaptation of collection and processing • Reconfigure data collection and data filtering processes, change sampling rates • Data as a single queriable unit • Global sensing device network is a single unit that supports a high-level query language • Users make complex queries: “Tell me the location of my grandmother at the time when the oil spill in the Baltic sea was first detected”. • Data integrity and privacy • No one should be able to query my health data except my doctor

37. Query User OA XML database OA XML database OA XML database . . . SA SA SA . . . senselet senselet senselet senselet senselet senselet Sensor Sensor Sensor Sensor IrisNet Architecture Two components: SAs: sensor feed processing OAs: distributed database Web Server for the url . . . From slides of P. Gibbons

38. IrisNet Architecture • Sensing Agents (SA) • Generic data acquisition interface: ask sensor to collect data X at frequency Y, filter data according to parameter Z • A service configures sensing agent according to its needs • Configuration is done via execution of service-specific code senslet • A single SA can execute one or more senslets • Organizing Agents (OA) • Service specific sensing data is stored in a database • This database is queried by users

39. Organization of SA

40. OA Architecture • XML-based database • Hard to design rich schema for all possible service • XML allows the use of self-describing tags • Database is partitioned and distributed • Replicate parts of the database • Primary replicas: strong consistency • Secondary replicas: weak consistency

41. Querying the IrisNet • Each node has a human readable name • Each such name is registered in the DNS with associated IP address • Query is routed to the IP address neighbourhood-Shadyside.city-Pittsburgh.state-PA.usRegion-NE.intel-iris.net

42. Example Services • Parking space finder • Uses cameras throughout a metropolitan area to track parking space availability • Users fill out a Web form to specify destination and any constraints on a desired parking space • Parking space finder identifies the parking space satisfying constraints • Network and host monitor (IrisLog) • Collects data from computer and network monitoring tools • Those tools act like sensors • They report data, such as CPU and memory load, network bandwidth • Answer queries such as “find the least loaded node on the network” • Coastal imaging service • Uses camera installed at Oregon coastline • Uses live feed from cameras to identify signatures of phenomena such as riptides and sandbar formations

43. Summary • Variety and quantity of small computers is exploding • These computers are mobile, wearable, provide a variety of cool functions/sensing abilities, and are affordable! • One can imagine a multitude of useful “killer apps” using those devices • Many challenges need to be overcome to make these applications really work: • Limited power and network bandwidth • Formation of ad-hoc networks • Querying the available data • Handling and storing massive amounts of data