1 / 35

Lecture 23: The Case for HomeOS

Lecture 23: The Case for HomeOS. Xiaowei Yang. Today’s Plan. HomeOS Why & How Final Review We’ve learned a lot! Course Evaluation. S mart homes. Capability to automate and control multiple, disparate systems within the home [ABI Research]

liseli
Download Presentation

Lecture 23: The Case for HomeOS

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 23: The Case for HomeOS Xiaowei Yang

  2. Today’s Plan • HomeOS • Why & How • Final Review • We’ve learned a lot! • Course Evaluation

  3. Smart homes • Capability to automate and control multiple, disparate systems within the home [ABI Research] • Today, only the super rich and super geeks have it

  4. Why don’t you have it? • You have the basic ingredients • But composition is difficult

  5. A quick example Unlock? Yes No

  6. Why is device composition in the home hard? • Users • Developers • Vendors

  7. Home users are not administrators • Management Nightmare

  8. Why developers are not helping: heterogeneity

  9. Vendors prefer vertical integration • Vertically integrate hardware and software • Seldom make use of other vendors’ devices • No single vendor comes close to providing all the devices a home needs

  10. Interoperability is not sufficient • Many standards exist for interoperability • Media: DLNA (Digital Living Network Alliance), AirTunes, etc. • Devices: UPnP, SpeakEasy, mDNS, etc. • Home Auto: ZwaveZigBee, X10, etc. • Handles device heterogeneity, not topology, user preferences, and coordination heterogeneity Video Recording Climate Control Camera-Based Entry Remote Lock

  11. Monolithic systems are inextensible • Security: ADT, Brinks, etc. • Academic: EasyLiving, House_n, etc. • Commercial: Control4, Elk M1, Leviton, etc. Home Media Security

  12. An alternative approach: A home-wide operating system HomeStore Video Rec. Remote Unlock Climate Operating System

  13. Goals of HomeOS • Simplify application development • Enable innovation and device differentiation • Simplify user management

  14. Core Features of HomeOS • Driver and application modules • A “port” abstraction for exposing functionality and communication • Access control for users and modules

  15. Simplify development App A App B … …

  16. Simplify development App A App B … Mgmt UI Access Control Port Port Driver Driver … … …

  17. Modules • Driver and application modules are isolated • A poorly written module can’t impact HomeOS or other modules • Application modules belong to application domain • Communication cross domains is through pre-defined entry points

  18. A port example • A port is functionally described in terms of roles and controls • Roles: express a functionality • Controls: typed points of sensing and actuation within a port • < roles=“lightswitch”, “dimmerswitch” > , < controls=(“on-off”, binary, readable, writable), (“intensity”, range:1-100, readable, writable) > .

  19. Roles in HomeOS • Roles are functional descriptions of ports • lightswitch, television, display, speakers, etc. • App developers program against roles • Enable vendors to innovate/differentiate • Anyone can create a new role • e.g., SonyBraviaTV vs. television • Allows new functionality to be rapidly exposed • Commodity vendors can still participate

  20. Simplify user management • Conducted a field study • Modern homes with automation & other tech • 14 homes, 31 people • Users’ needs for access control • Applications as security principals • Time in access control decisions • Confidence in their configuration

  21. Management primitives • Datalog access control rules • (port, group, module, time-start, time-end, day, priority, access-mode) • Reliable reverse perspectives help users confidently configure access control • User accounts • Can be restricted by time (guests) • Application manifests • Specify role requirements for compatibility testing • Simplifies rule setup (only when roles match)

  22. Implementation status • Built on the .NET CLR • ~15,000 lines of C# • ~2,500 kernel • 11 Applications • Average ~300 lines/app • Music Follows the Lights • Play, pause & transfer music where lights are on/off • Two-factor Authentication • Based on spoken password and face recognition

  23. Open questions/Ongoing work • Additional evaluation • Is it easy to write apps and drivers? • Is it easy to manage? • Does it scale to large homes? • Deploy & support application development • Explore business/economic issues

  24. Conclusion • A home-wide OS can make home technology manageable and programmable • HomeOS balances stakeholder desires • Developers: abstracts four sources of heterogeneity • Vendors: enables innovation and differentiation • Users: provides mgmt. primitives match mental models http://research.microsoft.com/homeos

  25. Discussion • Do homes need an OS? • Is HomeOS the right solution? • Why would vendors comply?

  26. Course Summary • A broad range of topics • Cloud computing and its challenges • Cloud inner working • Datacenter networking • Social networks • Privacy • Web, Wireless, Mobile devices • Home Networking

  27. Cloud Computing: Opportunities • Opportunities • Elastic computing: on-demand scaling • Pay-as-you-go • No upfront investment cost • New applications • Mobile & Cloud • Energy saving • Disaster recovery • Group collaboration

  28. Cloud Computing: Challenges • Security • Placement • Co-location • Inference • Performance • Sharing impacts computation, network

  29. Cloud Inner Workings • MapReduce • A powerful framework for parallel computation • Map()‏ • Process a key/value pair to generate intermediate key/value pairs • map (in_key, in_value) -> (out_key, intermediate_value) list • Reduce()‏ • Merge all intermediate values associated with the same key • reduce (out_key, intermediate_value list) -> out_valuelist • MapReduce online for interactive applications • Reining outliers

  30. Example: word counting • Map()‏ • Input <filename, file text> • Parses file and emits <word, count> pairs • eg. <”hello”, 1> • Reduce()‏ • Sums all values for the same key and emits <word, TotalCount> • eg. <”hello”, (1 1 1 1)> => <”hello”, 4>

  31. Datacenter Networking • FatTree • Multi-rooted trees to provide abundant bisection bandwidth • Adaptive routing • Valiant routing: picking a random redirection point works • Datacenter congestion control • InCast: synchronized replies lead to congestion • DCTCP • Reduce cwnd proportionally to congestion • Small queue size in routers

  32. Social network storage • Haystack • Write once • Read many • Using a needle to hold many files • Cache metadata in memory for high access speed

  33. Privacy • Social networks • Personal identifiable information leaks to unauthorized third parties • Cookies, referrer header, Request-URI • User browsing behavior is linkable • Online advertising • Behavior targeting in social networks • Ads exclusively sent to users in certain groups • Not obvious for search and web ads • Mostly keyword based

  34. Wireless • Mobility pattern linkable • Anything over http spoofable • SlyFi • TaintDroid • Private information leaks to unauthorized 3rd party

  35. The End • It’s really the beginning • Take the ideas • Apply the skills • Critical and creative thinking • Turn your course project into a research paper • I hope you enjoyed it as much as I do

More Related