Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microsoft HOmeOS Whitepaper 2012


Published on

Microsoft HOmeOS Whitepaper 2012

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Microsoft HOmeOS Whitepaper 2012

  1. 1. An Operating System for the Home Colin Dixon (IBM Research) Ratul Mahajan Sharad Agarwal A.J. Brush Bongshin Lee Stefan Saroiu Paramvir Bahl Microsoft Research Abstract—Network devices for the home such as re- that is compatible with existing home technology is er-motely controllable locks, lights, thermostats, cameras, ror prone at best. This is problematic as users prefer toand motion sensors are now readily available and inex- organically add a few devices or applications at a time.pensive. In theory, this enables scenarios like remotely We argue that this state of affairs stems directly frommonitoring cameras from a smartphone or customizing the abstractions that home technology presents to usersclimate control based on occupancy patterns. However, and developers. There are two prevalent abstractions to-in practice today, such smarthome scenarios are limited day: an appliance and a network-of-devices. The appli-to expert hobbyists and the rich because of the high over- ance abstraction is that of a closed, monolithic systemhead of managing and extending current technology. supporting a fixed set of tasks over a fixed set of devices. We present HomeOS, a platform that bridges this gap Commercial security and automation systems [1, 12] andby presenting users and developers with a PC-like ab- many research efforts [29, 43] present this abstraction.straction for technology in the home. It presents network The closed nature of such systems means that end usersdevices as peripherals with abstract interfaces, enables and third-party developers typically cannot extend them,cross-device tasks via applications written against these making it a poor fit for an environment where incremen-interfaces, and gives users a management interface de- tal extensions are desired.signed for the home environment. HomeOS already has The second abstraction is a decentralized network-of-tens of applications and supports a wide range of devices. devices. Interoperability protocols such as DLNA [14],It has been running in 12 real homes for 4–8 months, and Z-Wave [46] and SpeakEasy [16] provide this abstrac-42 students have built new applications and added sup- tion. It is also a poor fit for the home because it providesport for additional devices independent of our efforts. limited or no support for users to manage their technol- ogy or for developers to build portable applications that1 Introduction span multiple devices. In this paper, we advocate for a PC-like abstractionPop culture, research prototypes and corporate demos for technology in the home—all devices in the homehave all envisioned a smart, connected home where mul- appear as peripherals connected to a single logical PC.tiple devices cooperate to cater to users’ wishes with lit- Users and applications can find, access and manage thesetle or no effort. For instance, in a home with remotely devices via a centralized operating system. The op-controllable lights, cameras and locks, it should be easy erating system also simplifies the development of ap-to automatically adjust lights based on the weather and plications by abstracting differences across devices andtime of day as well as remotely view who is at the door homes. Further, it provides a central location to extendbefore unlocking it. But such seamless home-wide tasks the home by adding new devices and applications.are conspicuously absent from the mainstream despite We present an architecture to provide the PC abstrac-the fact that the needed hardware devices are reasonably tion for home technology and its instantiation in the formpriced—wireless lightswitches, door locks, and cameras of a system called HomeOS. Its design is based on usercan each be bought for (US) $50–100. interviews and feedback from a community of real users Studies of technology use in the home help explain and developers. It has been under development for overthe gap between the longstanding vision of connected two and its reality [7, 8, 15, 22, 34]. They find that it HomeOS uses (i) Datalog-based access control andis increasingly difficult for users to manage the growing other primitives that simplify the task of managing tech-number of devices in their homes. Further, application nology in the home, (ii) protocol-independent servicessoftware that can compose the functionality of these de- to provide developers with simple abstractions to accessvices is hard to develop because of extreme heterogeneity devices and (iii) a kernel that is agnostic to the devicesacross homes, in terms of devices, interconnectivity, and to which it provides access, allowing easy incorporationuser preferences. Finally, finding hardware and software
  2. 2. of new devices and applications. HomeOS runs on a ded- 1. Management Unlike other contexts (e.g., enterpriseicated computer in the home (e.g., the gateway) and does or ISP networks), the intended administrators are non-not require any modifications to commodity devices. expert users. But the management primitives available to Our current prototype supports several device proto- users today were originally designed for experts. As acols (e.g., Z-Wave and DLNA) and many kinds of de- result, most users find them hard to use. Worse, devicesvices (e.g., lights, media renderers and door/window sen- often need to be individually managed and each comessors). It runs in 12 real homes and 42 students have with its own interface and semantics, rather than havingdeveloped applications using it. These homes run ap- a single, unified interface for the home.plications varying from getting e-mail notifications with The management challenge is particularly noteworthyphotos when the front or back door is opened at unex- when it comes to security and access control where userspected times, to seamlessly migrating video around the are frequently forced to choose between inconveniencehouse. Students have built applications ranging from us- and insecurity [7, 22]. When they are unable to eas-ing Kinect cameras to control devices via gestures to per- ily and securely configure guest access for devices (e.g.,sonalized, face-recognition-based reminder systems. printers) on their home networks, they either deny access to guests or completely open up their networks. The experiences of these users and developers, alongwith our controlled experiments, help validate the use- 2. Application development Users want to composefulness of the PC abstraction and our design. Users were their devices in various ways [34] and software shouldable to easily manage HomeOS and particularly liked be able to do just that, but heterogeneity across homesthe ability to organically add devices and applications makes it difficult to develop such application their deployments. Developers appreciated the ease We identify four primary sources of heterogeneity.with which they could implement desired functionality • Topology: Devices are interconnected in differentin HomeOS, without worrying about low-level details of ways across homes. Some homes have a Wi-Fi-onlydevices and protocols. These experiences also point to- network while others have a mix of Wi-Fi, Ether-ward avenues for future work where we could not pro- net and Z-Wave. Further, some devices use mul-vide a clean PC abstraction. For instance, connectivity tiple connectivity modes (e.g., smartphones switchto network devices, especially wireless ones, is harder to between home Wi-Fi and 3G).diagnose than for directly connected PC peripherals. • Devices: Different devices, even of the same type, In summary, we make three main contributions. First, support different standards. For example, lightwe propose using a PC abstraction for technology in the switches may use Z-Wave, ZigBee or X10; and TVshome to improve manageability and extensibility. Sec- use DLNA, UPnP A/V or custom protocols.ond, we implement this abstraction in HomeOS. While • User control: Different homes have different re-we do not claim the pieces of our design are novel, to our quirements as to how activities should occur [22].knowledge, their use in addressing the challenges of the Some homes want the Xbox off after 9 PM andhome environment is novel. Third, we validate the PC some want security cameras to record only at night.abstraction and our design with both controlled experi- • Coordination: If multiple tasks are running, simul-ments and real users and developers. taneous accesses to devices will inevitably arise. Such accesses may be undesirable. For instance, a climate control application may want the window2 A new abstraction for home technology open when a security application wants it closed. 3. Incremental growth Users frequently want toOur proposal to use a PC-like abstraction for technol- grow their technology incrementally, as their preferencesogy in the home is motivated by our own recent study evolve [7, 22]. Such growth is difficult today becauseof home technology [7] as well as the work of oth- users cannot tell if a given piece of technology will beers [8, 15, 22, 34]. We first summarize the challenges compatible with what they currently have. This difficultyuncovered by this work, then explain why existing ab- corners them into buying from one vendor (creating lock-stractions for home technology cannot meet those chal- in), seeking expensive professional help, and making sig-lenges, and finally present the PC abstraction. nificant upfront investments (e.g., buying a home-wide automation system with many features before knowing which features fit their lifestyle). Supporting incremen-2.1 Challenges tal growth is further complicated by the rapid innovation in hardware and software; users’ existing systems fre-Home technology faces three main challenges today. quently do not support these new technologies.
  3. 3. 2.2 Prevalent abstractions Challenge Heterogeneity addressed src. handledToday, home technology can be seen as presenting one Application layer Incremental growthof two abstractions to users and developers. The first is Management layer App development User control Management Coordinationthe appliance abstraction that provides the same inter- App development Device functionality layer Deviceface that a monolithic, fixed-function device would. It is Incremental growthused for most home security and home automation sys- Device connectivity layer Incremental growth Topologytems where the set of devices and tasks are both closed.This has the advantage of offering (potentially) simpleruser interfaces and simpler integration across the set ofinvolved devices. However, it inhibits extensibility and Figure 1: Layers in HomeOS and their considerationsapplication development because integration with third-party devices and software is typically not possible. As a current PC OSes that make some network devices (e.g.,result, the security, audio-video, and automation systems printers) appear local. We take this design to its logicalare mutually isolated in many homes [7, 22]. extreme, making all network devices appear local, while tackling other challenges of the home environment. The second abstraction is a network-of-devices,which arises from interoperability protocols offeringstandardized interfaces to devices. This means that, in 3 HomeOS architecturetheory, applications can remotely control devices and de-vices can be integrated to accomplish tasks. For instance, HomeOS uses a layered architecture (Figure 1) to bri-DLNA allows some TVs to play media content from a dle the complexity of the home environment and addresscomputer. In practice, it leaves too much for users and the challenges mentioned in the previous section. Be-developers to do for themselves. Users interact with each low, we describe each of the four layers in detail, butdevice’s own management interface and application de- briefly, the key elements of our approach are: (i) pro-velopers must deal with all the sources of heterogeneity viding users with management primitives and interfacesmentioned above. that align with how they want to manage and secure their home technology, (ii) providing application developers with high-level APIs that are independent of low-level2.3 The PC abstraction details of devices, and (iii) having a kernel that is inde- pendent of specific devices and their functionality. OurThe abstractions prevalent today demonstrate the inher- design borrows heavily from traditional OSes but alsoent tension between ease of management on one side differs from them in a few key ways.and extensibility (for both applications and devices) onthe other. The appliance abstraction can provide simpleuser management (at least for the included devices), but 3.1 Device connectivity layertypically does not accommodate new devices and appli-cations. On the other hand, the network-of-devices ab- The Device Connectivity Layer (DCL) solves the prob-straction readily incorporates new devices, but does not lems of discovering and associating with devices. This includes dealing with issues arising from protocols de-provide the needed support for developing cross-deviceapplications or simple management tools. signed to operate only on one subnet (e.g., UPnP) as well as connecting to devices with multiple connectivity We propose to resolve this tension by presenting the paradigms (e.g., a smartphone on WiFi vs. 3G).abstraction of a PC. Network devices appear as con- The DCL provides higher layers with handles for ex-nected peripherals, and tasks over these devices are akinto applications that run on a PC. Users extend their home changing messages with devices, but it attempts to be astechnology by adding new devices or installing new ap- thin as possible, avoiding any understanding of device semantics. There is one software module in the DCL forplications without any guesswork with respect to com-patibility. They implement desired access control poli- each protocol (e.g., DLNA and Z-Wave). This modulecies by interacting with the operating system, rather than is also responsible for device discovery, using protocol- specific methods (e.g., UPnP probes). If it finds an un-with individual devices and applications. Finally, appli-cations are written against higher-level APIs, akin to ab- known device it passes that up to the management layerstract PC driver interfaces, where developers do not have where the proper action can be worry about low-level details of heterogeneous de- The DCL frees developers from worrying about somevices and their connectivity. Our proposal is inspired by of the most pernicious issues in using distributed hard-
  4. 4. Pan, Tilt and Zoom Camera DLNA Media Renderer DFL GetImage() → bitmap Play(uri) GetVideo()† → bitmaps PlayAt(uri, time) DCL Up() Stop() Down() Status() → uri, time (a) (b) (c) Left() Right() Dimmer Switch ZoomIn() Get()† → percent Figure 3: The organization of software modules in HomeOS ZoomOut() Set(percent) (a) and two alternative organizations (b) and (c); Solid regions represent protocol-specific code and hatched regions representFigure 2: Example HomeOS roles and their operations. ‘† ’ protocol-independent codeindicates that the operation can be subscribed to XML and TCP/IP. As technology changes or new con- cerns arise (e.g., low-energy, low-bandwidth), new pro-ware by having a different layer take care of discovering tocols emerge to meet engineering needs.and maintaining connectivity to devices. 3.2.2 Extensibility3.2 Device functionality layer Introducing new devices in HomeOS is straightforward.The Device Functionality Layer (DFL) takes the handles A new device can either use an existing role or, if it is aprovided by the DCL and turns them into APIs that de- new type of device, a new role can be registered for itsvelopers can easily use. These APIs are services that are functionality. Applications can then be written againstindependent of device interoperability protocols (§3.2.1), this new role, without the need to upgrade HomeOS itselfand the DFL is architected to allow easy incorporation of because the kernel is completely agnostic to the servicesnew devices and interfaces whether they are similar to spoken across it. This behavior is different from periph-existing ones or not (§3.2.2). eral APIs in current PC OSes which typically require OS updates to provide common support for new peripher- als to application developers. Simplifying the introduc-3.2.1 Protocol-independent services tion of new functionality is important in the home whereDFL modules provide device functionality to applica- new devices arrive frequently. Just in the last five years,tions using a service abstraction. We refer to service in- devices like depth cameras (Kinect), Internet connectedterfaces as roles, and each role contains a list operations DVRs, and digital photo frames have gone from nearlythat can be invoked. For instance, the “lightswitch” role non-existent to commonplace.has two operations, “turnOn” and “turnOff,” each tak- Similarly, if a new capability for an existing device ising no arguments. Role names are unique with seman- developed, a new role that exposes the capability can betics; “lightswitch” implies functionality that is the same registered. The DFL module for this device can exportacross device vendors and homes. Operations may return both the old and new roles for backward compatibility.results immediately and/or allow subscription to events Currently, each role in HomeOS is independent; we areof interest (e.g., when a light switch is physically tog- considering arranging them in a class hierarchy in whichgled). Figure 2 shows a few example roles in HomeOS. subclasses correspond to more specialized functionality. In HomeOS, DFL specifications only capture devicefunctionality (and no other detail), and thus the applica- 3.2.3 Alternative architecturestions that use them do not require changes unless device The HomeOS architecture splits device interactions intofunctionality itself evolves. (We describe below how we two separate layers—a device-agnostic layer (DCL) forhandle changing device functionality.) In contrast, the basic connectivity and device-specific layer (DFL) thatcommon method today for applications to use network builds on this basic connectivity to mediate between ap-devices is to use a device protocol. For instance, an ap- plications and devices. Figure 3(a) illustrates the soft-plication might use DLNA to play videos on a remote ware organization for three devices that share the sameTV. Using device protocols is problematic because there underlying protocol. It is similar to what occurs in PCare many such protocols and they continue to evolve. OSes for USB devices, with a USB-specific module and We believe that continuous evolution of device pro- a device-specific module. However, for network devices,tocols is inevitable because they tend to be fat, spanning where no universal device protocol exists, this organiza-many layers and concerns. For instance, Z-Wave speci- tion may appear ill-advised. The knowledge of a devicefies not only device functionality but also MAC and PHY protocol is spread across two layers, and incorporating alayer details, and UPnP requires the use of HTTP, SOAP, new protocol requires changes to both.
  5. 5. In the home setting, this design has important advan- give us insight into their experience with current tech-tages over alternatives. Figure 3(b) shows one alterna- nology as well as how they would like to manage hometive that follows a “one driver per protocol” architecture. technology in the future. We present results on the for-It is convenient if there are one or a small number of mer elsewhere [7] and focus here on the latter aspect.supported devices in the protocol, but quickly becomes We interviewed 31 people across 14 homes (1 in the UK,cumbersome to maintain as the number of devices in the rest in the USA), with different systems such as Elk M1,protocol grows. A more traditional “one driver per de- Control4 and Leviton.vice” architecture produces the software organization in Our visits revealed that households want access con-Figure 3(c) where both connectivity and functionality are trol primitives that differ from those present in traditionalmediated by a single piece of software for each device. OSes. We summarize four important differences below.This not only results in DCL functionality being repli-cated if multiple devices use the same protocol, but also 1. Time-based access control Our participants wantednecessitates coordination among modules communicat- to control access to devices based on time. Parents men-ing to different devices. For instance, Z-Wave only al- tioned restricting children from using certain devices af-lows one live message in the Z-Wave network at a time ter certain times (e.g., “If my daughter wanted watchrequiring coordination among any software modules that [Curious] George at 11 o’clock at night, I wouldn’t wantmight send Z-Wave messages. Thus, after experimenting to do that”). While social interaction suffices to addresswith these alternatives, we chose to split device commu- some of these concerns, many parents asked for technicalnication across DCL and DFL as shown in Figure 3(a). means as well. Time-based access control is also needed to give households an ability to grant a variety of access durations for guests (e.g., a few hours to babysitters and3.3 Management layer a few days to house guests).The management layer in HomeOS provides two key Current commodity OSes provide coarse-grainedfunctionalities. First, it provides a central place to add parental controls that can limit whole accounts to certainand remove applications, devices, and users as well as times of the day, but they lack flexible controls that canto specify access control policies. Second, it mediates easily implement policies such as those above.potentially conflicting accesses to devices ensuring that 2. Applications as security principals Users high-applications do not need to build their own mechanisms lighted a desire to be able to limit applications’ abilitiesto handle shared devices. to access devices. One participant said “I don’t want to We provide both functionalities using the same prim- grant it [the application] access to everything, just myitives. A key goal for their design is that they be sim- laptop.” A participant in a different home commentedple and translate into management interfaces with which about another application: “if it said my DVR and my TVusers can easily implement desired policies. Otherwise, I would say fine, ... if it had my phone or my computer Iwe risk not only user frustration but also misconfigu- would want to be able to choose [what it can access].”rations with serious security and privacy consequences, This observation requires treating applications asgiven the sensitive nature of many devices (e.g., cameras first-order security principals, in addition to users. Inand locks). To gain insights on the design requirements, current PC OSes, users alone are the primary securitywe conduct a study of households with existing automa- principals (with some exceptions such as firewall rulestion. We describe the study in §3.3.1 and the primitives in Windows), and applications simply inherit users’ priv-in §3.3.2. While these primitives do not extend the state ileges. While smartphone OSes treat applications as se-of the art beyond what researchers have proposed in the curity principals, they are solving the simpler problem ofpast, their simplicity and universal application across an regulating single-user, self-contained resources.OS goes beyond commodity OSes. 3. Easy-to-understand, queryable settings As ex- pected, users complained about complicated interfaces3.3.1 Understanding management requirements to configure devices (and especially security), but theyUsers have complex needs of home technology. While also bemoaned the lack of a simple way to verify secu-different than those of experts, their own mental mod- rity settings. They had no way convince themselves thatels are often refined. To understand these mental models they had correctly configured their settings. For exam-and common user activities, we visited households with ple, to ask if guests can access security devices or if ahome automation already installed (e.g., remote lighting given application cannot unlock the door after 10 PM.and locks, security cameras). While we expect HomeOS Providing reliable answers to such questions is diffi-to enable tasks not possible today, these households can
  6. 6. cult in current OSes due to issues such as dynamic dele- views is straightforward because they can be formulatedgation [10]. In the home, the consequences of incorrect as Datalog queries. Answering these queries is fast de-configurations can be severe, requiring even more con- spite there being many dimensions per rule. Because thefidence in security. The lack of such a capability can policies are straightforward, as we show later, even non-scare users away from the idea of using new or poten- experts can configure and understand them.tially dangerous capabilities, even if it is possible they The main advantage of Datalog over ACLs is its sim-are correctly configured. For instance, a participant with plicity. ACLs can be more expressive, assuming we ex-electronic door locks said he had not hooked up remote tend them to include time and applications. But they areaccess because he was not “100% certain of its security.” hard for users to program [33] and hard to aggregate and4. Extra sensitive devices Our users showed height- summarize. We are not the first to propose the use ofened sensitivity for the security and use of certain devices Datalog for access control, but its use can require major(e.g., locks and cameras). They wanted support to ensure extensions to accommodate policies of complex environ-accidentally granting access to such devices was difficult. ments [32]. We find that the needs of the home environ- ment can be met without such extensions.3.3.2 Primitives Past systems looking to simplify access control haveThe requirements for security and access control out- explored using a simple table [38] with the principalslined above are in conflict. The first two call for primi- along one axis and the objects along the other withtives that are richer than those in current OSes. However, each cell specifying if access should be allowed. Whilenon-experts find it hard to configure and understand even promising, this approach does not scale well beyond twothose primitives [10, 33]. We reconcile the conflict by dimensions and our interviews indicated that time andnoting that the home is a much simpler environment that application were both required dimensions.does not need much of the complexity motivated by en- Time-based user accounts In addition to the use ofterprise environments (e.g., dynamic delegation, highly- time in access rules, user accounts in HomeOS can havecustomizable ACLs and exceptions). an associated time window of validity. This window isDatalog access control rules We formulate access used to simplify guest access, which studies have showncontrol policies as Datalog [9] rules of the form (r, g, m, to be both common and particularly problematic [22, 33].Ts , Te , d, pri, a), which states that resource r can be ac- Home owners can start access for a user at a certain timecessed by users in group g, using module m, in the time (e.g., for a future guest) and terminate access at a certainwindow from Ts to Te , on day of the week d, with prior- time (e.g., when the guest is expected to leave). The dataity pri and access mode a. Time window and day of the corresponding to the guest (e.g., access privileges) areweek lets users specify policies by which something is not deleted automatically after the validity window, toallowed, for instance, on Sundays 7–9 PM. Groups such simplify reinstating access at a later “kids” and “adults” are configured separately. Prior- Hierarchical user and device groups Groups inities are used to resolve conflicting access to the same HomeOS are arranged in a tree hierarchy. In contrast,resource. Access mode is one of “allow” or “ask.” With groups in current OSes can be independent sets. Wethe latter, the users have the option to permit or deny ac- picked the tree organization because of its simplicity.cess interactively when the access is attempted. Studies When a user group is given access, it enables an easiershow that users prefer this flexibility rather than having determination of which users are given access. A userto specify all possible legal accesses a priori [5, 33]. Any who is not part of this group will not inadvertently gainaccess that is not in the rule database is denied. While access because she is part of another group.these rules may seem complex for users at first, they areamenable to visualization and English sentences like “Al- For devices, we use a tree hierarchy that is rooted inlow residents to access the living room speakers using the space because that matches how users think of resourcesmusic player from 8 AM to 10 PM.” in the home. It also aligns well with physical access as it is delineated by rooms. To our knowledge, current OSes Expressing access control as Datalog rules meets our do not support such device groups. We find that devicerequirements. Users can configure time-based policies as groups simplify management; users can specify policieswell as restrict an application to accessing only certain for groups rather than individual devices.devices. They can also easily understand their config-uration by queries such as “Which applications can ac- Orthogonal to spatial grouping, HomeOS has a high-cess the door?”, “Which devices can be accessed after security group. Users can deem certain devices as high-10 PM?” or “Can a user ever access the back door lock?” security to avoid accidental access to such devices andto fully understand their risk. Reliably providing such simplify the task of keeping the home network secure.
  7. 7. Applications are not given access to secure devices by central to the platform is implemented by software com-default, and the user must explicitly provide access to ponents called modules. Modules that sit in the applica-such devices. We add some common classes of devices tion layer are applications, and those that sit in the DCL(e.g., cameras, locks) automatically to this group; users and DFL are drivers.can later add or remove devices to or from this group. Access control also forms the basis for privacy in our 4.1 Modulesdesign. Applications cannot access sensor data unlessthey are granted access to those devices. Further, net- Modules are the basic unit of functionality in HomeOSwork access is disabled by default, so they cannot leak in- and, whether applications or drivers, they implement theformation externally. (Software updates are downloaded API described in Figure 4(a).and applied by HomeOS.) Thus, we coarsely control pri-vacy at the granularity of applications and devices. In the Before a module can be run, it must be installed.future, we will consider finer-grained control [42, 44]. Driver modules are installed when new devices are dis- covered on the home network; applications are installed in response to explicit user directives. Modules are in-3.4 Application layer stalled by copying the binaries and accompanying meta- data (e.g., manifests) to a specific directory. InstallationThe application layer is where developer-written code is carried out only if the module is deemed compatibleruns. The key feature this layer provides, beyond the with the devices in the home. This check is also per-ability to use and compose devices, is the ability to de- formed each time the application is run to deal with con-termine if an application is compatible with the home and figuration changes. During installation, users specify ifwhat services and/or devices are missing if it is not. the module should be started automatically upon system (re)start or only upon explicit user request. Module up- Today, users have little assurance that a given piece dates and uninstallation are carried out by HomeOS andof software will work in their home. To address this not by the module itself.uncertainty, HomeOS requires that applications providea manifest describing what services they need. This Running modules are isolated to prevent any interac-enables it to determine if an application will function tion except via the APIs to the HomeOS platform and thewith the current device services in the home. (A simi- service interface. By default modules are denied accesslar approach is being used to manage handset diversity to the network. DCL modules are the exception as somein smartphones today.) If the manifest indicates an ap- must use the network to control their associated devices.plication is not compatible, HomeOS can also determine Even then, when possible we limit connectivity to onlywhat additional devices or services are needed. those devices. A module’s file system access is limited to its own working directory where it can store its data A manifest has mandatory and optional features. and configuration.Each feature is a set of roles, at least one of which isneeded. For instance, an application may specify {“TV”, HomeOS relies on DCL modules to discover new de-“SonyTV”}, {“MediaServer”} as mandatory features, vices on the home network by running protocol-specificindicating that it needs a service with at least one of the discovery protocols. (We also support a mode wheretwo TV roles and a service that exports a media server. It users can also manually add a device if HomeOS is un-might have {“Speaker”} as an optional feature if it offers able to do so automatically.) Once a new device is dis-enhanced functionality with that role. covered, HomeOS installs a DFL module for it based on a database of device type to driver mappings. The de- Our current manifest descriptions cannot encode vice type is reported by the DCL module and is protocol-complex requirements (e.g., if an application needs de- specific. The DFL module is granted access to the ser-vices to be in the same room). They handle what we vice that the DCL module exports for this device.deem to be the common case. Should the need arise, itwould be straightforward for us to enhance manifest de-scriptions. 4.2 Services Services are the only way that modules are allowed to4 Design and implementation interact with each other. They do so using a standard- ized API described in Figure 4(b). Modules advertise theHomeOS is an implementation of the above architecture services they offer to HomeOS which keeps a history ofas a component-based OS. All functionality that is not offered services to enable future compatibility testing.
  8. 8. Start: Called to start a module; modules are garbage InitSvcAndCapability: Creates a service and a capability to access it; returns the collected when it returns service handle back Stop: Called to request a module to stop; where state RegisterSvc: Registers the service as active advertising it to other modules can be cleaned up before exit DeregisterSvc: Marks a service as being inactive and notifies other modules SvcRegistered: Called when a new service becomes GetAllSvcs: Returns a list of all active services active; used to listen for services of interest GetCapbility: Requests a capability to access a given service SvcDeregistered: Called when a service becomes in IsMySvc: Returns whether a given service belongs to this module active; used to avoid using inactive services Invoke: Used to call an operation either synchronously or asynchronously AsyncReturn: Called whenever a subscription gener- Subscribe: Subscribe to notifications from an operation ates an event or asynchronous call returns SpawnSafeThread: Create new thread which safely propagate its failures (a) API for HomeOS modules (b) API For finding and interacting with HomeOS services Figure 4: The APIs for modules (a) and services (b) in HomeOS Modules inform HomeOS about services of interest coupled with HomeStore which hosts all HomeOS appli-to them using role names and/or locations. (Note that ex- cations and drivers. It indexes application manifests aspressing interest does not grant access to a service other well as drivers’ associated devices and exported services.than to know of its existence and description.) When a It helps users find applications that are compatible withservice is registered, modules that have expressed inter- their homes, by matching manifests against services inest in it are notified. A module can then query the service their home. If an application is not compatible, it can rec-for its description as well as its location. Querying for the ommend additional devices that meet the requirements.existence of a service does not require access privileges. When a module needs to invoke an operation on a ser- 4.4 Management tasksvice, it requests a capability [31] from HomeOS. As partof the request, the module passes the credentials of the To explain how users manage their homes usinguser it is running on behalf of. Without valid credentials, HomeOS we describe four important management tasks.the request is successful only if the access is legal for all 1. Adding a new application Users can browse appli-users. Drivers are handled slightly differently and typi- cations and view their compatibility within HomeStore.cally have rules that give them access to their correspond- Upon installing an application, HomeOS walks the usering devices regardless of the user. User-controlled policy through setting up access control rules for the applica-is applied when applications access the driver rather than tion. The core of this task is specifying which devices (orwhen the driver accesses the device. services1 ) the application should be allowed to access. The legality of the requested access is evaluated by Since there may be hundreds of devices, we use theHomeOS based on the user, module, service, and time of application manifest and service descriptions to showday, by formulating the check as a Datalog query over only compatible, non-secure services. Once the user se-the users table and access rules. If legal, a capability lects which services the application can access, HomeOSis generated and returned. A copy of the capability is uses the Datalog rule database to detect if the new appli-then passed to the target service; this makes it easier for cation could access a device at the same time as other ap-HomeOS to revoke the capability later if needed. Subse- plications. If so, it asks the user which application shouldquently, the requesting module can use the capability to have a higher priority.make calls directly to the service. HomeOS capabilitieshave an expiration time based on access rules. 2. Adding a new device Once a new device is reg- istered, users need to specify its location and whether An operation’s callers must also include input param- it should be marked secure. They also need to config-eters of the right type. HomeOS supports both primitive ure which existing applications should have access to theand complex types, which are passed by reference across device. This task is again simplified using applicationisolation boundaries to avoid the overhead of serializa- manifests, as only applications compatible with the newtion. Finally, operation invocations include a timeout. device are presented as valid options.Unless the called service responds within this time limit,a timeout error code is returned. 3. Verifying access rules To verify access con- trol configuration, HomeOS allows users to view the rules from different vantage points using faceted brows-4.3 HomeStore ing [25] (found on shopping Web sites to filter contentTo simplify the process of finding new applications and 1 HomeOS devices are exposed as services, as are features like no-devices, inspired by smartphone app stores, HomeOS is tification and face recognition. To ease exposition, we refer to devices.
  9. 9. Room 1 Intermatic PC3lab lamp module Wi-Fi power cable Z-wave Windows7 laptop with Z-wave Aeon door/window sensor Windows Media Player Z-wave HomeOS Aeon Internet ethernet Z-stick sw it ch Wi-Fi 3G HTC Fuze smartphone Sony Bravia TV Axis 213 PTZ camera (KDL-32EX40B) Z-wave Room 2 Wi-Fi Intermatic PC3lab lamp module Windows7 laptop with power cable Windows Media Player Figure 6: Our implementation testbedFigure 5: A GUI screen capture showing how applications are access control. As our evaluation shows, the overhead ofgiven access to devices this isolation mechanism is low enough to support inter- active applications. However, it does not provide perfor-along multiple dimensions). This enables users to pose mance or memory pressure isolation; these are subjectsquestions such as what devices an application can access of future work. For Datalog query evaluation, we useor what devices can be accessed at night by a user group. Security Policy Assertion Language (SecPAL) [40], af-The questions are answered using Datalog queries. ter modifying it to support time comparisons.4. Adding new users When a new user account is In addition to the HomeOS kernel, we devel-added, the administrator must specify their group (e.g., oped drivers to interact with a diverse set of off-the-guest) and the time window of account validity. shelf devices that includes Z-Wave lighting controls, We have built a complete user interface (UI) to sup- door/window sensors, smartphones, network cameras,port these tasks. An example screenshot is shown in Fig- TVs capable of receiving DLNA streams, Windows PCs,ure 5 which occurs during the course of adding applica- and IR (infra-red) transmitters. Figure 6 shows one oftions. We omit detailed description of the UI for space our testbeds with some of these devices.constraints, but note that it closely mirrors our system Interoperability protocols greatly simplified the taskprimitives and includes heuristics designed to minimize of making these devices work with HomeOS because athe exposure to risk even if users click OK repeatedly module corresponding to the protocol can communicateduring configuration activities. Evaluation of its usabil- with different devices. For instance, the same DLNAity, which we discuss later, also evaluates the manage- module works with both Windows 7 computers and theability of our primitives. Sony TV; and the Z-Wave lightswitch module works with both Aeon and Intermatic devices. Greater adoption of interoperability protocols will make it easier to integrate4.5 Implementation devices with HomeOS. See below, however, for someWe implemented HomeOS in C# using the .NET 4.0 shortcomings of current interoperability protocols.Framework. We use the System.AddIn model which al- We developed 18 applications that use these deviceslows dynamic loading and unloading modules. It also of- and run on our testbeds. While some applications requirefers module version control allowing the HomeOS kernel access to only one device (e.g., turn on or off a light), oth-and individual modules to evolve independently. We iso- ers are quite complex. For example, a media applicationlate modules using AppDomains, a lightweight sandbox- transparently redirects a music stream from one room toing mechanism [2]. Each module runs inside a domain. another, depending on how lights are turned on or off inDirect manipulation is not allowed across domains. In- each room (using lights as a proxy human presence instead, communication is done only through typed objects the room). We also implemented a two-factor authenti-exchanged through defined entry points and subject to cation application that triggers a configured action (e.g.,
  10. 10. open a lock) when the same person authenticates withtheir voice on the phone (speech recognition) and withtheir face on the camera (face recognition). Each of the 18 applications is less than 300 lines ofC# code and took only a few hours to develop. Becauseapplications are written against high-level abstractions,most of the effort went toward application-specific logic.As we report below, other developers also found applica-tion development in HomeOS to be easy. Figure 7: A student demonstrating how to turn on and off5 Experience lights via gestures with a Kinect with existing devices. Another group built an applica-HomeOS currently runs in 12 real homes and 42 develop- tion that plays audio reminders based on who is rec-ers have written modules for it. These field experiences ognized on cameras. This works with webcams, secu-validate key aspects of the HomeOS architecture. They rity cameras, Kinect or IP cameras and with any devicealso evaluate the utility of the PC-like abstraction for HomeOS can play audio through (right now PCs, DLNAhome technology as well as situations in which HomeOS TVs, and Windows Phones). This underlines the powerwas more or less able to preserve that abstraction. Gen- HomeOS gives to application developers to easily spanerally, the experiences were positive even for people with multiple types of devices (security, PC, phone, entertain-no prior home automation experiences. However, the ex- ment, etc.). Commercial systems today support only aperiences did reveal some rough edges of our prototype subset of devices related to their target scenario (e.g., se-and limitations of current interoperability protocols. curity systems focus on cameras and motion sensors). We describe the main findings below, based on infor- Layering and programmability Developers whomal surveys of our users and developers. The next sec- wrote applications found the protocol independence oftion presents results from controlled experiments. the APIs appealing. Developers who wrote new drivers for devices with existing DCL modules (e.g., a Z-Wave appliance controller) liked that they did not have to con-5.1 Developers cern themselves with the low-level connectivity details and could instead focus exclusively on device semantics.We gave the HomeOS prototype to ten academic researchgroups, for use as a platform for both teaching and re- Interestingly, developers who extended HomeOS tosearch on home applications. As part of this program, devices without an existing DCL module (e.g., ENVI en-42 undergraduate and graduate students developed tens ergy meters [19]) started by building one module thatof HomeOS applications and drivers. spanned both the DCL and DFL. For them, the split was They extended HomeOS in several directions [3, 4, unnecessary overhead as only one device used the con-26, 27]. They wrote drivers for new devices including en- nectivity protocol. However, in one case a group had to support multiple devices with the same connectivityergy meters, different network cameras, appliance con-trollers and IM communication. They wrote new appli- protocol based on IP to Z-Wave translation. This groupcations such as energy monitoring, remote surveillance, found value in separating functionality across two layers indicating it was not just an artifact or our experience.and reminders based on face recognition. The PC-likeabstractions of drivers and applications enabled them to Hardware-software coupling Our developers some-build software quickly and in reusable modules. More- times wanted to use device features that were not ex-over, as a testament to the flexibility and extensibility of posed to third-parties over the network. For instance,its architecture, we were not required to—and did not— one developer wanted to insert a text notification on amodify HomeOS to support these development efforts. TV without otherwise interrupting the on-screen video. As an example, one group extended HomeOS to sup- Today, some set-top boxes have this capability (e.g., for cable TV operators to signal caller identity of incomingport the Kinect RGB-D camera and built an applicationwhich allowed users to control lights via gestures (Fig- calls), but they do not expose it to third-party software.ure 7). They were able to do this without having to This points to an inherent advantage of vertically in-wait for Kinect integration with a large commercial sys- tegrated software—being able to better exploit devicetem (e.g., Control4) and were able to get it to interact capabilities—that open systems like HomeOS lack. This
  11. 11. is unsurprising in retrospect as the closed nature of cur- Indeed, all users employed an organic growth strat-rent solutions and devices is what HomeOS attempts to egy. One user started running HomeOS with only onecombat. However, the systematic way vendors can ex- network camera to view his front yard on a smart-pose device capabilities in HomeOS should encourage phone while away from home. He later added two morethem to make their capabilities available to applications. cameras—a webcam and a network camera from a differ-Media applications and decentralized data plane A ent vendor—and was able to continue using the same ap-few developers had difficulty in writing media applica- plication without modification. He then added two sen-tions. HomeOS centralizes the control plane but not the sors to detect when doors were opened so that he coulddata plane to avoid creating a performance bottleneck. be notified when unexpected activity occurred. This usedIf two devices use the same protocol, we assume that our door-window monitoring application sends email no-they can directly exchange data. Thus, we assume that tifications, which can contain images from any camerasa DLNA renderer can get data directly from a DLNA in the home. The user later added two light controllersserver once provided with a media URI. The DLNA pro- and another application to control them. What startedtocol turns out to not guarantee this because of video off as simply wanting to see his front yard from workencoding and/or resolution incompatibilities. While we evolved into a notification system and lighting control.currently use heuristics to provide compatible formats Diagnostic support in interoperability protocols Onwhen transcoding is available, they are not perfect. the negative side, at least two homes had problems di- agnosing their deployments. For instance, when appli- For reliable operation, we also plan to use HomeOS asa transcoding relay (thus, centralizing the data plane and cations that use Z-Wave devices behaved unexpectedly,more closely mirroring the PC abstraction) when data users could not easily tell if it was due to code bugs, de- vice malfunctions or poor signal strength to the device.plane compatibility between nodes is not guaranteed. Ashigh-quality open source transcoders exist [21], the main Disambiguation requires effort and technical expertisetechnical challenge is to generate profiles of what input (e.g., unmount the device, bring it close to the controller,and output formats devices support. This requires pars- and then observe application behavior).ing device protocols like DLNA. Although this means vi- This difficulty is an instance where the added com-olating HomeOS’s agnostic kernel, we believe that media plexity of network devices, in contrast to directly con-applications are common and important enough to justify nected peripherals, becomes apparent. Countering it re-an exception. quires diagnostic tools but they are hard to build today because interoperability protocols have limited diagnos- tic support. We thus recommend that device protocols be5.2 Users extended to provide diagnostic information. Even some- thing akin to ICMP would be a step forward.Twelve homes have been running HomeOS for 4–8months. We did not actively recruit homes but many ap-proached us after becoming aware of the system. We lim- 6 Evaluationited our initial deployment to 12 homes. Ten of them hadno prior experience with home automation. Beyond pro- In addition to our experience with real homes and de-viding the software and documentation, we did not assist velopers, we evaluate HomeOS through controlled ex-users in running or managing HomeOS. These homes are periments, focusing on its ease of programming, ease ofusing a range of devices including network cameras, we- managing and system performance. This gives us quan-bcams, appliance and light controllers, motion sensors, titative validation to confirm our real-world experiencesdoor-window sensors and media servers and renderers. above. We find that developers can write realistic appli-Organic growth What our users found most attractive cations within 2 hours, that users can use our manage-was being able to start small and then expand the sys- ment interfaces with similar success to other carefullytem themselves as desired. At first, they typically did not designed systems and that system performance is goodknow what they wanted and only discovered what they enough to easily support rich, interactive applications.found valuable over time. HomeOS let them start small(at low cost) and extend as needed. It thus provided a sys- 6.1 Ease of programmingtem that was much more approachable than commercialsystems today that require thousands of dollars upfront. To evaluate how easy it is to write a HomeOS applica-It was also more likely to satisfy users by allowing them tion, we conducted a study where we recruited studentto evolve it to meet their needs rather than requiring them and researcher volunteers to develop HomeOS applica-to make all decisions during initial installation [7]. tions. (Different from the students mentioned in §5.)
  12. 12. We provided our participants with a brief introduction to and could have been avoided with clearer instructions.HomeOS, some basic documentation on our abstractions, In the exit interview, almost all participants (evenall the drivers, and four simple applications that use only those who did not finish) reported that HomeOS wasone driver each—image recognition, camera snapshot, “very programmable” and the APIs were “natural.”DLNA music player, and light-switch controller. Each However, they also expected more syntactic support inparticipant got a total of five-minutes of verbal instruc- the IDE for invoking operations. We are addressing thistions (with no demonstration of code) on the goal of the issue by defining a C# interface for each and pointers to these resources. We left the par-ticipant and the testbed, with the HomeOS server con- These results suggest that it is easy to develop appli-sole running an IDE (Visual Studio) configured to use cations for HomeOS. Even without prior experience, de-HomeOS binaries. We provided little assistance beyond velopers were able to implement realistic applications inthe initial training, though on three occasions the partic- just a couple of hours. We do not mean to suggest thatipants uncovered bugs in our system that we had to fix all HomeOS applications can be developed in two hours.before they could proceed. Our study emphasized the use of HomeOS’s basic ab- stractions and did not require the developers to focus on We gave each participant the task of writing one of consumer-facing issues such as a richer GUI. However,two applications for our testbed. “Custom Lights Per- it does provide evidence that the base programming ab-User” (CLU) will adjust the lights in any room based on stractions are a good fit for applications in the home.its occupant’s preferences. This application needs to findcameras in the house to which it has access, continuouslypoll them, use the image recognition service to identify 6.2 Ease of managingthe occupant (if any), and set the “dimmers” in the cam-era’s room to the occupant’s preferences. For testing, Our second study evaluates whether our managementwe gave each participant two photographs on which the primitives and interfaces are easy enough for non-expertimage recognition service was trained and the user-to- home users to use. We find that with no training, typi-lighting preference chart. cal home users are able to complete typical management The second application—“Music Follows the Lights” tasks correctly around 80% of the time.(MFL)—was one we previously built but did not pro- Methodology We began each session by explaining thevide to participants. This application finds all lights and background and goals of the study and the three securitymedia devices in the house, registers for changes to the principals—users, devices and applications. We askedlights’ status and plays music (from a media server) on participants to pretend to be a member of the followingan audio device in rooms with lights that are on. imaginary family. Jeff and Amy are husband and wife. We recruited ten participants for this study via a mail- Dave and Rob are their eight-year and seven-month olding list within our organization. Seven were graduate stu- kids. Jeff’s brother Sam, who visits occasionally, has adents and three were researchers. Only one had prior ex- guest account. The house has 29 devices of nine differentperience with home automation, and none had significant types. Three of the devices—camera and microphone inprior experience with programming service-based ab- Rob’s room, and the front door lock—are high-security.stractions (e.g., WSDL or SOAP). This level of expertise The family has four applications for lighting, monitoring,is at the low-end of what we expect of future HomeOS and temperature control, and fourteen rules specifyingdevelopers. We gave each participant two hours to write access controls policies. We assigned the male partici-an application. Half of the participants were given the pants to play Jeff and females to play Amy.first application and half were given the second. We then asked them to perform the 7 management Figure 8(a) summarizes the results of our study. The tasks show in Figure 8(b) using our UI. These tasks re-time reported was computed from the end of verbal flect what we expect users to do with HomeOS and spaninstructions until the participant was done, minus any key management tasks (§4.4). Tasks 1, 2 and 6 requirebreaks the participant took and the time we spent correct- configuring applications, including restricting their useing bugs. Eight participants developed complete appli- to certain users, devices and times of day. Task 3 requirescations within approximately two hours (126 minutes). configuring a new device with group and application ac-Of the two who did not finish, one spent the bulk of cess. Task 4 requires adding a new guest. Tasks 5 and 7the time developing a “slick GUI” for the application in- require verifying policies based on specific concerns.stead of its core logic and the other did not realize that At the same time, our tasks stress the ability of primi-HomeOS drivers were not running by default. This prob- tives in HomeOS to simplify management. For instance,lem stemmed from a misinterpretation of instructions Tasks 1 and 2 use application manifests, Datalog rules,
  13. 13. app LoC mins Task 1 CLU 183 84 1. Configure your new EcoMonitor app. Let it access all but high-security devices for everyone. 11 2 CLU 193 62 2. Configure your new MusicFollowsMe app. Let it access all motion detectors and speakers but no 9 3 CLU 156 66 high-security devices. All residents can use it but kids cannot not play music in the parents’ bedroom 4 CLU 172 113 3. Configure your new kitchen security camera. Mark it high-security and let HomeMonitor access it. 11 5 CLU 221 107 4. Give guest access to Jane, who will be visiting until September 6th. Place her in the Guests group 12 6 MFL 224 95 so that she can use appropriate apps during her visit. 7 MFL 244 126 5. Check the rules and tell the facilitator which apps can access high security devices. 1 8 MFL 239 102 6. Configure your new OpenFrontDoor app. Residents can use it any time. Sam (guest) cannot use it 11 9 MFL 303 93* at all. Jane (guest) can use it only during the day (8 AM to 8 PM). 10 MFL 130 100* 7. Check if only adults can access the camera in Rob’s room and only using HomeMonitor. 10 (a) Programming study (b) Management studyFigure 8: Results of our two studies: (a) The application developed and time taken by each participant, ‘*’ implies an incompleteprogram; (b) Assigned management tasks and the number of participants (of 12) that completed each accuratelyand user and device groups, whereas Task 4 uses time- the HomeMonitor application was using the camera, butbased user accounts and user groups. Ideally, we would did not realize that so was another application. We planevaluate each primitive separately but we found manage- to address this by augmenting the UI to reduce the workment tasks that stress only one primitive to be unrealistic. needed to detect things that are unexpected or the ab- We simulated a real-world setting by not training our sence of use by other applications. We believe that theparticipants in using the technology they are required to underlying primitives do not need modification.manage. Instead we provided manuals for each task type In the exit interview, we asked the participants howand told them that reading the manuals was not required easy HomeOS was to use and learn, on a 7-pt. Likertbut they could refer to them anytime if they wanted. scale from “Strongly Disagree” (1) to “Strongly Agree”Participants We had twelve participants (eight male, (7). The participants found the system easy to learn (avg. 6.0), easy to use (avg. 6.0), and intuitive (avg. 5.5).four female) from the Greater Puget Sound region inWashington state. We recruited the participants through aprofessional recruiting service. We screened them to en- 6.3 System performancesure they are somewhat familiar with home technology.They were required to own at least one TV, one com- In addition to easy programming and management,puter, and three types of electronic devices (e.g., wireless HomeOS must have acceptable performance. Our goalsrouter, security camera, smartphone, etc.). They were are to have latency that is low enough to run respon-also required to be able to conduct basic administrative sive, interactive applications and to offer scalability andtasks (e.g., set up an account on a computer)2 . throughput that can handle large, complex homes. ToResults Figure 8(b) shows the number of participants quantify the overhead of layering in HomeOS, we com-that completed each task correctly. We see that the ac- pare against a hypothetical, monolithic system withoutcuracy rate is high. Overall, it is 77%; ignoring Task layering and isolation.5 (discussed below), it is 89%. This result is encour- Experimental setup To gather performance data aboutaging because it was obtained without any training and HomeOS, we ran a simple benchmarking application us-many participants did not use the manual. For reference, ing a virtual device on a quad-core Intel Xeon 2.67 GHzwe note that our accuracy rate is similar to that obtained PC. Unless otherwise specified, there is one applicationwith careful design of system semantics and interfaces and one driver running. The application generates loadfor file system access control [38] and firewall configu- by creating ten continuous tasks that attempt to invoke anration [37]. Our participants took one to four minutes to operation on the device at a fixed rate, but are scheduledcomplete individual tasks. by .NET ThreadPool which dynamically picks a number While the errors in most tasks were simply forgetting of threads to execute based on current performance.a single click, Task 5 was particularly problematic. Only Latency of operation invocation Figure 9 shows theone participant was able to complete it correctly. Others latency of an operation invocation with no arguments un-had difficulty forming the correct query for the task us- der different loads. While we incur higher overhead thaning our faceted browsing interface. (Forming the query without isolation, the difference is approximately onlyfor Task 7, which also used the same interface, was not 25% or a few hundred microseconds. Even under heavyas problematic.) They could correctly and easily tell that load, we are able to keep latencies below 2 ms. This is 2 While this may seem to exclude typical home users, homes typi- two orders of magnitude lower than the interactive re-cally have at least one experienced tech guru [36]. sponse time guideline of 100 ms [18], which means that
  14. 14. Figure 9: Operation invocation latency as a function of of-fered load with and without Application Domain isolation Figure 11: Cumulative fraction of operation invocations com- pleted within a given latency for varying numbers of applica- tions and devices Scalability To understand how HomeOS scales to a large home with many devices and applications, we ex- amine the latency of operation invocation in an extreme setting. We emulate a large home with a varying num- ber of rooms, each room containing 4 devices and one highly-active application querying each device 10 times per second. Figure 11 shows the operation invocation latency in this setting. As we increased the number of rooms from 25 to 50 to 100 (1,000, 2,000 and 4,000 total operations per second), we see a median latency of 3–5.5 ms depending on the number of applications. The latencyFigure 10: Operation invocation throughput as a function ofoffered load with and without Application Domain isolation in this experiment is higher than those presented earlier at the same total load because of the added overheadapplications can compose several services and allow for of having 125–500 modules running rather than delays before responding to the user. The threads across modules are not managed as part of the same ThreadPool. Despite this additional overhead, The odd increase in latency when the offered load is the vast majority of operations complete within 10 ms,low (between 100 and 3000 operations per second, re- which is an order of magnitude below the interactivespectively) is an artifact of the ThreadPool scheduling guideline of 100 ms. This result suggests that HomeOSrapidly switching between threads when each thread of- can easily scale to large, well-connected homes.fers substantially lower load than what the machine canhandle. We found it to persist across other microbench-marks as well. 7 Related workThroughput of operations To evaluate the load thatHomeOS can handle, we tracked the throughput of thesystem at different offered loads both with and without While we draw on many strands of existing work, we areAppDomain isolation. Figure 10 shows that the through- unaware of a system similar to HomeOS that provides a PC abstraction for home technology to simplify man-put of the two modes mirror each other until the systemis driven near peak throughput. With AppDomain iso- agement and application development while remaininglation, HomeOS handles approximately 8,250 operation extensible. We categorize related work into five groups.invocations per second, while with no isolation the sys- 1. Device interoperability Many systems and stan-tem can handle nearly 11,300 operation invocations per dards for providing device-to-device interoperability insecond. Beyond that load, ThreadPool scheduling backs the home exist. They include DLNA [14], UPnP [41], Z-off. If an application does not use this or a similar mech- Wave [46], ZigBee [45], and Speakeasy [16]. HomeOSanism, latencies climb substantially when the system is is agnostic to what interoperability standards are useddriven past the load it can handle as one would expect. and can incorporate any of these. But, as discussed ear-This level of performance has been well-beyond what lier, while interoperability is helpful, it does not providewas required for any of our current deployments. enough support for users and developers.
  15. 15. 2. Multi-device systems Many commercial home au- iROS aims to simplify programming devices such as dis-tomation and security systems integrate multiple devices plays and white-boards in collaborative workspaces [6].in the homes. Like HomeOS, they centralize control, but NOX aims to simplify managing switches in enterprisesuch systems tend to be monolithic and hard for users networks [23]. While conceptually similar, HomeOSto extend. For instance, Control4 [11]—one of the most handles complexities specific to the home environment.extensible automation systems—allows for only its owndevices and a limited set of ZigBee devices; and offersonly a limited form of programming based on rules of 8 Conclusions and future workthe form “upon Event E, do Task T .” Further, the tech-nical complexity of installing and configuring Control4 HomeOS simplifies the task of managing and extendingand other systems (e.g., HomeSeer [28], Elk M1 [17] technology in the home by providing a PC-like abstrac-and Leviton [30]) can be handled only by professional tion for network devices to users and developers. Its de-installers (which is expensive) or expert hobbyists. In sign is based on management primitives that map to howthe research community, EasyLiving [29] was a mono- users want to manage their homes, protocol-independentlithic system with a fixed set of applications integrated services that provide simple APIs to applications and ainto the platform. In contrast to such systems, we focus kernel that is agnostic of the functionality and protocolson building a system that can be extended easily with of specific devices. Experience with real users and de-new devices and applications by non-experts. velopers, in addition to controlled experiments, help val-3. Programmability for the home We proposed the idate the usefulness of the abstraction and our design.idea of a home-wide OS in a position paper [13]. This This experience also reveals gaps where we could notpaper presents an architecture based on our experiences, cleanly implement the abstraction due to limitations ofa more complete system, and its evaluation. device protocols (e.g., little support for diagnosis and in- Newman proposes using “recipes,” [34] which are compatible implementations across vendors) or due toprograms in a domain-specific language that compose limited features being exposed by devices over the net-devices in the home. He also advocates using market- work. We plan to address these limitations in the future.places to disseminate recipes. With HomeOS applica- More broadly, our hope is that this work spurs the re-tions, our vision is similar. Newman does not discuss search community to further explore the home as a futurehow recipes can be realized in practice, which requires computing platform. While we cannot outline a completetackling challenges similar to those we address. agenda for work in this area, we point out two fruitful di- Previous work also advocates using a central con- rections based on our experience:troller to simplify integration [20, 39]. They have a 1. Foundational services Over the years PC appli-different scope than HomeOS. For instance, Rosen et cations have come to expect some essential services thatal. [39] (incidentally, also called HomeOS), focus on the OS provides (e.g., a file system). Are there simi-providing context such as user location to applications. lar services for the home environment? Such servicesThese works offer little detail about their design and im- should not only be broadly useful but also almost uni-plementation. versally implementable. For instance, consider occu- Other systems have employed services in the home pancy information—which rooms are currently occupiedenvironment. iCrafter is a system for UI programma- by people. It can benefit many applications (e.g., lightingbility [35]. ubiHome aims to program ubiquitous com- control, thermostat control, and security), but dependingputing devices inside the home using Web services [24]. on the devices in the home, it may be difficult to inferWhile our use of the service abstraction is similar to these reliably (e.g., motion sensors can be triggered by pets;systems, we engineer a more complete system for pro- cameras are more reliable). Making occupancy an essen-gramming and managing devices in the home. tial service requires each home to possess the necessary devices, thus increasing the cost of a basic HomeOS in-4. Management challenges in the home Calvert et al. stallation. (This is akin to PC or smartphone OSes speci-outline the various management challenges in the home fying minimum hardware requirements.) Thus, carefulnetwork [8], and like us, argue for centralization. We go consideration is needed to determine which services abeyond management issues and also focus on simplify- system like HomeOS should provide in all application development. Further, in contrast to theirproposal, we do not require device modifications. 2. Identity inference Some desired reactions to phys- ical actions in the home depend on the identity of the5. OSes for network devices Researchers have user or who else is around. For instance, users may wantdesigned OSes over multiple devices in other domains. to play different music based on who entered and turned