Beam: Ending Monolithic Applications for Connected Devices Chenguang Shen, University of California, Los Angeles; Rayman Preet Singh, Samsung Research; Amar Phanishayee, Aman Kansal, and Ratul Mahajan, Microsoft Research https://www.usenix.org/conference/atc16/technical-sessions/presentation/shen
This paper is included in the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16). June 22–24, 2016 • Denver, CO, USA 978-1-931971-30-0
Open access to the Proceedings of the 2016 USENIX Annual Technical Conference (USENIX ATC ’16) is sponsored by USENIX. Beam: nding onolithic Applications for Connected e ices
Chenguang Shen (UCLA)∗ ayman Preet Singh (Samsung Research)∗ Amar Phanishayee Aman ansal atul Maha an Microsoft Research
A stract The proliferation of connected sensing de- broad distribution of their applications because the cost vices (or Internet of Things) can in theory enable a range of deploying their specific hardware limits user adoption. of applications that make rich inferences about users and Second, for end users, each sensing device they install is their environment. But in practice developing such appli- limited to a small set of applications, even though the cations today is arduous because they must implement all hardware capabilities may be useful for a broader set of data sensing and inference logic, even as devices move applications. How do we break free from this monolithic or are temporarily disconnected. We develop Beam, a and restrictive setting Can we enable applications to be framework that simplifies IoT applications by letting programmed to work seamlessly in heterogeneous envi- them specify what should be sensed or inferred, with- ronments with different types of connected sensors and out worrying about how it is sensed or inferred. Beam devices, while leveraging devices that may only be avail- introduces the key abstraction of an inference graph to able opportunistically, such as smartphones and tablets decouple applications from the mechanics of sensing and To address this problem, we start from an insight that drawing inferences. The inference graph allows Beam to many inferences re uired by applications can be drawn address three important challenges: (1) device selection using multiple types of connected devices. For instance, in heterogeneous environments, (2) efficient resource us- home occupancy can be inferred by either detecting mo- age, and (3) handling device disconnections. Using Beam tion or recognizing people in images, with data sampled we develop two diverse applications that use several dif- from motion sensors (such as those in security systems or ferent types of devices and show that their implementa- Nest [12]), cameras (e.g. Dropcam [4], Simplicam [18]), tions re uired up to 12 fewer source lines of code while × microphone, smartphone GPS, or using a combination of resulting in up to 3 higher inference accuracy. × these sensors, since each may have different sources of 1 ntroduction errors. e posit that inference logic traditionally left up to applications ought to e a stracted out as a system Connected sensing devices, such as cameras, ther- ser ice thus decoupling what is sensed and inferred mostats, in-home motion, door-window, energy, wa- from how it is sensed and inferred . Such decoupling ter sensors [2], collectively dubbed as the Internet of enables applications to work in heterogeneous environ- Things (IoT), are rapidly permeating our living environ- ments with different sensing devices while at the same ments [3], with an estimated 50 billion such devices in time benefiting from shared and well trained inferences. use by 2020 [34]. In theory, they enable a wide variety Conse uently, there are three key challenges in design- of applications spanning security, efficiency, healthcare, ing such a service: and others. But in practice, developing IoT applications e ice selection: The service must be able to select the is arduous because the tight coupling of applications to appropriate devices in a deployment that can satisfy an specific hardware re uires each application to implement application s inference re uest (including inference ac- the data collection logic from these devices and the logic curacy). Device selection helps applications to run in het- to draw inferences about the environment or the user. erogeneous deployments. It also helps applications to op- Unfortunately, this monolithic approach where appli- erate in settings with user mobility where the set of us- cations are tightly coupled to the hardware, is limiting able devices may change over time. Moreover, applica- in two important ways. First, for application developers, tions can leverage multiple available devices to improve this complicates the development process, and hinders inference accuracy, as shown in Figure 1. ∗Work done during an internship at Microsoft Research fficiency: For inferences that are computationally ex-
1 USENIX Association 2016 USENIX Annual Technical Conference 143 100 Set 1 HomeOS [33], thus enabling the development of a vari- 95 Set 2 ety of inference modules. We find that for these applica- Set 1 ∪ Set 2 90 tions: 1) using Beam’s abstractions results in up to 4.5 × 85 fewer development tasks and 12 fewer source lines of × 80 code with negligible runtime overhead; 2) inference ac- curacy is 3 higher due to Beam’s ability to select de- 75 × vices in the presence of user mobility; and 3) network re- Average Inference Accuracy (%) 70 Occupancy Activity source usage due to Beam’s dynamic graph partitioning re r e en n cc nc n c n matches hand-optimized versions for the applications. ference cc r c c n n e e ces n e en r cc nc sens r se e er e c er cr ne n ne r n se In this section, we first describe two representative { } { n er c e ec n n sec n r r s classes of applications and distill the challenges an infer- } c c se ne cce er e er n se ence framework should address. Next, we describe the { } r s rn key abstractions central to Beam’s design in addressing { } pensive to run locally on user devices, or to support de- the identified challenges. ployments that span geographical boundaries, the service e c ns should be able to offload computation to remote servers. In doing so, the service should partition computation Our motivation for designing Beam are data-driven- while efficiently using network bandwidth. inference based applications, aimed at homes [12, 19], sc nnec n er nce The service should be able to individual users [11, 14, 59, 69, 72] and enterprises [8, handle dynamics that can arise due to device disconnec- 16, 24, 46, 60]. We identify the challenges of building tions and user mobility. an inference framework by analyzing two popular appli- To address these challenges concretely, we propose cation classes in detail, one that infers environmental at- Beam, an application framework and associated runtime tributes and another that senses an individual user. which provides applications with inference-based pro- ules: A large class of popular applications is based on gramming abstractions. It introduces the key abstraction the ‘If This Then That (IFTTT)’ pattern [9, 67]. IFTTT of an nference r to not only decouple applications enables users to create their own rules connecting sensed from the mechanics of sensing and drawing inferences, attributes to desired actions. We consider a particular but also directly aid in addressing the challenges iden- rules application which alerts a user if a high risk appli- tified above. Applications simply specify their inference ance, e.g., electric oven, is left on when the home is un- requirements, while the Beam runtime bears the onus of occupied [64]. This application uses the appliance-state identifying the required sensors in the given deployment and home occupancy inferences. and constructing an appropriate inference graph. uantified Self ( S) [11, 14, 23, 35, 53] disaggregates Inference graphs are made up of modules which are a user’s daily routine by tracking her physical activity processing units that encapsulate inference algorithms; (walking, running, etc), social interactions (loneliness), modules can use the output of other modules for their mood (bored, focused), computer use, and more. processing logic. Beam introduces three simple building Using these two popular classes of applications we ad- blocks that are key to constructing and maintaining the dress three important challenges they pose: device selec- inference graph: typed inference data units (IDUs) which tion, efficiency, and disconnection tolerance, as detailed guide module composability, channels that abstract all in Section 1. Next, we explain the key abstractions in inter-module communications, and coverage tags that aid Beam aimed at tackling these challenges. in device selection. The Beam runtime instantiates the inference graph by selecting suitable devices and assign- e s r c ns ing computational hosts for each module. Beam also mu- In Beam, application developers only specify their de- tates this assignment by partitioning the graph at runtime sired inferences. To satisfy the request, Beam bears the for efficient resource usage. Beam’s abstractions and run- onus of identifying the required sensors and inference time together provide disconnection tolerance. algorithms in the given deployment and constructing an Our implementation of the Beam runtime works inference graph. across Windows PCs, tablets, and phones. Using the nference r s are directed acyclic graphs that con- framework, we develop two realistic applications, eight nect devices to applications. The nodes in this graph cor- different types of inference modules, and add native respond to inference modules and edges correspond to support for many different types of sensors. Further, channels that facilitate the transmission of inference data Beam supports all device abstractions provided by units (IDUs) between modules. While these abstractions
2 144 2016 USENIX Annual Technical Conference USENIX Association Quantified Self App
Fitness Activity
Social Interaction PC Activity Social Interaction PC Activity FitBit Activity Phone Activity
Mic Camera PC Event Mic Camera PC Event Fitbit Acc./GPS Adapter Adapter Adapter Adapter Adapter Adapter Adapter Adapter
Phone GPS, Home Mic Home Camera Home PC Work Mic Work Camera Work PC Fitbit Accelerometer
Figure : nference graph of modules for the uantified Self S app. Adapters are de ice dri er modules. are described in more detail below, Figure 2 shows an type such as a double (e.g., inferred energy consump- example inference graph for the S application that we tion), or an enumerated type such as high, medium, or later build and evaluate. The graph uses eight different low. Similarly, error e may specify a confidence measure devices spread across the user s home and workplace, (e.g., standard deviation), probability distribution, or er- and includes mobile and wearable devices. The applica- ror margin (e.g., radius). IDUs abstract away what is tion re uests a top-level inference as an IDU and Beam inferred from how it is inferred . The latter is handled dynamically selects the modules that can satisfy this in- by inference modules, which we describe next. ference based on the devices available. For example, in Figure 2, to satisfy the application s re uest for infer- nference odules: Beam encapsulates inference algo- ences pertaining to fitness activities Beam uses a mod- rithms into modules. Inference modules consume IDUs ule that combines inferences drawn separately from a from one or more modules, perform certain compu- user s smartphone GPS, accelerometer, and Fitbit device, tation using IDU data and pertinent in-memory state, thus forming part of the inference graph for S. Figure 3 and output IDUs. Special modules called adapters inter- shows the inference graph for the Rules application. face with underlying sensors and output sensor data as IDUs. Adapters are device drivers that decouple what Composing an inference as a directed graph enables is sensed from how it is sensed . Inference de elopers sharing of data processing modules across applications specify (i) a module s input dependencies (either as IDU and other modules that re uire the same input. In Beam, types or as modules), (ii) the IDU type it generates, and each computing device associated with a user, such as a (iii) its configuration parameters. Modules have complete tablet, phone, PC, or home hub, has a part of the runtime, autonomy over how and when to output an IDU, and can called the ngine. Engines are computational hosts for maintain arbitrary internal states. Listing 1 shows a spec- inference graphs. Figure 4 shows two engines, one on the ification for the Home Occupancy inference module in user s home hub and another on her phone the inference the Rules inference graph (Figure 3). It lists (i) input de- graph for S (shown in Figure 2) is split across these pendencies of PC Activity O Mic Occupancy O Cam- engines, while the S application runs on a cloud server. era Occupancy, (ii) HomeOccupancyIDU to be the type For simplicity, we do not show another engine that may of output it generates, and (iii) a control parameter, sam run on the user s work PC. pleSi e, that specifies the temporal size of input samples : An Inference data unit (IDU) is a typed inference, (in seconds) to consider in the inference logic. Applica- and in its general form is a tuple
Adapter Adapter Adapter Adapter 18 19 Figure : nference graph for the Rules application. isting 1: odule specification of ome Occupancy.
3 USENIX Association 2016 USENIX Annual Technical Conference 145 Fitness Quantified Activity Self App Social PC FitBit Phone Interaction Activity Activity Activity Engine, Inference Fitbit Acc./GPS Mic Camera PC Event Persistent Graph, and Coverage Persistent Adapter Adapter Adapter Adapter Adapter WebSocket Managers WebSocket Connection Remote Channel Connection Manger Home Home Home PC Fitbit Smartphone GPS Mic Camera Inference Graph Optimizers Subgraph Manager Subgraph Manager Clock Sync/Skew Engine Profiler Engine Profiler Manager Coverage Tracking Service Coverage Tracking Service Inference Engine 1 Coordinator Inference Engine 2 (Home Hub) (Cloud Server) (Phone)