Beam: Ending Monolithic Applications for Connected Devices Chenguang Shen (UCLA)∗ Rayman Preet Singh (Samsung Research)∗ Amar Phanishayee Aman Kansal Ratul Mahajan Microsoft Research Abstract— 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 required 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 required 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 Introduction errors. We posit that inference logic, traditionally left up to applications, ought to be abstracted out as a system Connected sensing devices, such as cameras, ther- service, 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 Consequently, 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 Device 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 requires each application to implement application’s inference request (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 Efficiency: For inferences that are computationally ex- 1 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- × 75 curacy is 3 higher due to Beam’s ability to select de- 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 Figure 1: Improvement in occupancy and activity in- matches hand-optimized versions for the applications. ference accuracy by combining multiple devices in a lab deployment. For occupancy, sensor set 1 = 2 Beam Overview fcamera, microphoneg in one room and set 2 =fPC In this section, we first describe two representative interactivity detectiong in a second room. For physi- classes of applications and distill the challenges an infer- cal activity, set 1 = fphone accelerometerg and set 2 = ence framework should address. Next, we describe the fwrist worn FitBit [5]g. 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 2.1 Example Applications 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], Disconnection tolerance: 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- Rules: 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 inference graph 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. Quantified Self (QS) [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 2.2 Beam Abstractions inference graph by selecting suitable devices and assign- 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 Inference Graphs 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 Quantified Self App Fitness Activity