A Case for Ending Monolithic Apps for Connected Devices ?· A Case for Ending Monolithic Apps for Connected…

  • Published on

  • View

  • Download

Embed Size (px)


<ul><li><p>A Case for Ending Monolithic Apps for Connected Devices</p><p>Rayman Preet Singh (Univ. of Waterloo) Chenguang Shen (UCLA)</p><p>Amar Phanishayee Aman Kansal Ratul Mahajan</p><p>Microsoft Research</p><p>1 IntroductionConnected sensing devices, such as cameras, ther-mostats, in-home motion, door-window, energy, wa-ter sensors [1], collectively dubbed as the Internet ofThings (IoT), are rapidly permeating our living environ-ments [2], with an estimated 50 billion such devices inuse by 2020 [8]. They enable a wide variety of applica-tions spanning security, efficiency, healthcare, and oth-ers. Typically, these applications collect data using sens-ing devices to draw inferences about the environment orthe user, and use the inferences to perform certain ac-tions. For example, Nest [10] uses motion sensor data toinfer home occupancy and adjusts the thermostat.</p><p>Most applications that use connected devices today arebuilt in a monolithic way. That is, applications are tightlycoupled to the hardware, and need to implement all thedata collection, inferencing, and user functionality re-lated logic. For application developers, this complicatesthe development process, and hinders broad distributionof their applications because the cost of deploying theirspecific hardware limits user adoption. For end users,each sensing device they install is limited to a small set ofapplications, even though the hardware capabilities maybe useful for a broader set of applications. How do webreak free from this monolithic and restrictive setting?Can we enable applications to be programmed to workseamlessly in heterogeneous environments with differenttypes of connected sensors and devices, while leverag-ing devices that may only be available opportunistically,such as smartphones and tablets?</p><p>To address this problem, we start from an insight thatmany inferences required by applications can be drawnusing multiple types of connected devices. For instance,home occupancy can be inferred using motion sensors(such as those in security systems or Nest [10]), cameras(e.g. Dropcam [3], Simplicam [14]), microphone, smart-phone GPS, or using a combination of these, since eachmay have different sources of errors. We posit that in-ference logic, traditionally left up to applications, oughtto be abstracted out as a system service. Such a serviceshould relieve application developers of the burden of</p><p>implementing and training commonly used inferences.It should enable applications to work using any of thesensing devices that the shared inference logic supports.</p><p>This paper discusses the key challenges in designingthe proposed service. First, the service must decouple i)what is sensed from how it is sensed, and ii) what isinferred from how it is inferred. In doing so, it shouldensure inference extensibility, and provide a uniform in-terface to inferences which hides sensor-specific intrica-cies (e.g., camera frame rate, motion sensitivity level).Second, the service should enable seamless use of sen-sors on mobile devices by handling environmental dy-namics resulting from device and user mobility. Third,while serving required inferences to applications, the ser-vice should ensure efficient use of resources, e.g., by se-lecting the optimal subset of sensors to serve active ap-plications, sharing overlapping inference computations,and hosting computations on suitable devices.</p><p>To explore these challenges concretely, we proposeBeam, an application framework and runtime for in-ference driven applications. Beam provides applicationswith inference-based abstractions. Applications simplyspecify their inference requirements, while Beam bearsthe onus of identifying the required sensors, initiatingdata processing on suitable devices, handling environ-mental dynamics, and using resources efficiently.</p><p>2 Key Design RequirementsOur motivation for designing Beam are data-driven-inference based applications, aimed at homes [10, 16],individual users [9, 11, 41, 48, 50] and enterprises [6, 13,20, 33, 42]. We identify three key challenges for Beamby analyzing two popular application classes in detail,one that infers environmental attributes and another thatsenses an individual user.</p><p>Rules: A large class of popular applications is based onthe If This Then That (IFTTT) pattern [7, 47]. IFTTTenables users to create their own rules connecting sensedattributes to desired actions. We consider a particularrules application which alerts a user if a high risk ap-pliance, e.g., electric oven, is left on when the home isunoccupied [15, 44]. This application uses the appliance-</p><p>1</p></li><li><p> 70</p><p> 75</p><p> 80</p><p> 85</p><p> 90</p><p> 95</p><p> 100</p><p>Occupancy Activity</p><p>Aver</p><p>age </p><p>Infe</p><p>rence</p><p> Acc</p><p>ura</p><p>cy (</p><p>%)</p><p>Set 1Set 2</p><p>Set 1 Set 2</p><p>Figure 1: Improvement in occupancy and activity in-ference accuracy by combining multiple devices. Foroccupancy, sensor set 1 = {camera, microphone} inone room and set 2 ={PC interactivity detection} ina second room. For physical activity, set 1 = {phoneaccelerometer} and set 2 = {wrist worn FitBit [4]}.</p><p>state and home occupancy inferences.Quantified Self (QS) [9, 11, 19, 25, 38, 46] which dis-</p><p>aggregates a users daily routine, by tracking her physicalactivity (walking, running, etc), social interactions (lone-liness), mood (bored, focused), computer use, and more.</p><p>In analyzing these two popular classes of applications,we identify the following three key design requirementsfor an inference framework:</p><p>R1) Decouple applications, inference algorithms, anddevices. Data driven inferences can often be derivedusing data from multiple devices. Combining inputs frommultiple devices, when available, generally leads to im-proved inference accuracy (often overlooked by develop-ers [10]). In Figure 1 we illustrate the improvement in in-ference accuracy for the occupancy and physical activityinferences, used in the Rules and Quantified Self appli-cations respectively; 100% accuracy maps to manuallylogged ground truth over 28 hours.</p><p>Hence, applications should not be restricted to usinga single sensor, or a single inference algorithm. At thesame time, applications should not be required to in-corporate device discovery, handle the challenges of po-tentially using devices over the wide area (e.g., remoteI/O and tolerating disconnections), use disparate deviceAPIs, and instantiate and combine multiple inferencesdepending on available devices. Therefore an inferenceframework should require an application to only spec-ify the desired inference, e.g., occupancy (in addition toinference parameters like sampling rate and coverage),while handling the complexity of configuring the rightdevices and inference algorithms.</p><p>R2) Handle environmental dynamics. Applicationsare often interested in tracking user and device mobil-ity, and in adapting their processing accordingly. Forinstance, the QS applications needs to track which lo-cations a user frequents (e.g., home, office, car, gym,meeting room, etc), handle intermittent connectivity, and</p><p>Category R1 R2 R3Device [24] [5] abstractions [12] [18]</p><p>Mobile sensing[23] [40] [34] [29] [30][31] [32] </p><p>Cross-device [49] [45] Macro-programming [22] [26] [35] </p><p>Table 1: Categorization of prior work. denotes par-tial fulfillment.</p><p>more. Application development stands to be greatly sim-plified if the framework were to seamlessly handle suchenvironmental dynamics, e.g., automatically update theselection of devices used for drawing inferences based onuser location. Hence the QS application, potentially run-ning on a cloud server, could simply subscribe to the ac-tivity inference, which would be dynamically composedof sub-inferences from various devices tracking a user.</p><p>R3) Optimize resource usage. Applications often in-volve continuous sensing and inferring, and hence con-sume varying amounts of system resources across multi-ple devices over time. Such an application must structureits sensing and inference processing across multiple de-vices, in keeping with the devices resource constraints.This adds undue burden on developers. For instance, inthe QS application, wide area bandwidth constraints mayprevent backhaulling of high rate sensor data. Moreover,whenever possible, inferences should be shared acrossmultiple applications to prevent redundant resource con-sumption. Therefore an inference framework must notonly facilitate sharing of inferences, but in doing so mustoptimize for efficient resource use (e.g., network, battery,CPU, memory, etc) while meeting resource constraints.</p><p>3 Related WorkBeam is the first framework that (i) decouples appli-cations, inference algorithms, and devices, (ii) handlesenvironmental dynamics, and (iii) automatically splitssensing and inference logic across devices while opti-mizing resource usage. We classify prior work into fourcategories, and compare them based on the requirementsabove (Table 1).</p><p>Device abstraction frameworks: HomeOS [24] andother platforms [5, 12], provide homogeneous program-ming abstractions to communicate with devices. For in-stance, HomeOS applications can use a generic motionsensor role, regardless of the sensors vendor and proto-col. Similarly, Rio [18] provides smartphone applicationswith a uniform device API, regardless of the devicesbeing local or remote. These approaches only decoupledevice-specific logic from applications, but are unable todecouple inference algorithms from applications. More-over, they do not address handling of environmental dy-</p><p>2</p></li><li><p>PC Activity</p><p>PC Event Adapter</p><p>Fitness Activity</p><p>Fitbit Adapter</p><p>Quantified Self App</p><p>Mic Adapter</p><p>Social Interaction</p><p>Camera Adapter</p><p>FitBit Activity</p><p>Acc./GPS Adapter</p><p>Phone Activity</p><p>PC Activity</p><p>PC Event Adapter</p><p> Mic </p><p>Adapter</p><p>Social Interaction</p><p>Camera Adapter</p><p>Home PC Work PCSmartphone GPS, </p><p>AccelerometerHome</p><p>CameraHome</p><p>MicWork</p><p>CameraWorkMic</p><p>Fitbit</p><p>Figure 2: Inference graph for Quantified Self app.</p><p>namics and optimizing for efficient resource usage.Mobile sensing frameworks: Existing work has focusedon applications requiring continuous sensing on mobiledevices. Kobe [23] and Auditeur [40] propose buildinglibraries of inference algorithms to promote code re-useand to enable developers to select inference algorithms.Other work [29, 30, 31, 32, 34] has focused on improv-ing resource utilization by sharing sensing and data pro-cessing across multiple applications on a mobile device.Senergy [32] automates selection of inference algorithmsdriven by an application requirements on a mobile de-vice. These approaches overlook handling environmen-tal dynamics across devices, and do not address optimiz-ing resource use for inferences across multiple devices.Moreover, they require manual composition of certain in-ference parameters (e.g., coverage), thus providing lim-ited decoupling of inference algorithms.Cross-device frameworks: Semantic Streams [49] andTask Cruncher [45] address sharing sensor data anddata processing across devices, but are limited to sim-ple stream processing methods, e.g., aggregates, ratherthan sophisticated inferences. They overlook decouplingof sensing and inferring, as well as handling of dynamics.Macro-programming frameworks: Macro-programming frameworks [22, 26, 35] provide ab-stractions to allow applications to dynamically composedataflows [36, 39]. However these approaches focuson data streaming and aggregations rather than genericinferences, and do not target general purpose computedevices e.g., phones, PCs. In addition, they do not ad-dress handling of environmental dynamics and resourceoptimization across devices at runtime.</p><p>4 Beam Inference FrameworkWe propose Beam as a framework for distributed appli-cations using connected devices. Applications in Beamsubscribe to high-level inferences. Beam dynamicallycomposes the required modules to satisfy application re-quests by using appropriate devices in the given deploy-ment. Central to Beams design are a set of abstractionsthat we describe next.Inference Graphs: Inference graphs are directed acyclicgraphs that connect devices to applications. The nodes</p><p>in this graph correspond to inference modules and edgescorrespond to channels that facilitate the transmission ofinference data units (IDUs) between modules. Figure 2shows an example inference graph for a Quantified Selfapplication that uses eight different devices spread acrossthe users home and workplace, and includes mobile andwearable devices.</p><p>Composing an inference as a directed graph enablessharing of data processing modules across applicationsand across modules that require the same input. In Beam,each compute device associated with a user, such as atablet, phone, PC, or home hub, has a part of the runtime,called the Engine. Engines host inference graphs and in-terface with other engines. Figure 3 shows two engines,one on the users home hub and another on her phone;the inference graph for QS shown earlier is split acrossthese engines, with the QS application itself running ona cloud server. For simplicity, we do not show anotherengine that may run on the users work PC.</p><p>IDU: An Inference data unit (IDU) is a typed inference,and in its general form is a tuple , which denotesany inference with state information s, generated by aninference algorithm at time t and error e. The types of theinference state s, and error e, are specific to the inferenceat hand. For instance, s may be of a numerical type suchas a double (e.g., inferred energy consumption), or anenumerated type such as, high, medium, low, or numer-ical types. Similarly, error e may specify a confidencemeasure (e.g., standard deviation), probability distribu-tion, or error margin (e.g., radius). IDUs abstract awaywhat is inferred from how it is inferred. The latter ishandled by inference modules, which we describe next.</p><p>Inference Modules: Beam encapsulates inference algo-rithms into typed modules. Inference modules consumeIDUs from one or more modules, perform certain com-putation using IDU data and pertinent in-memory state,and output IDUs. Special modules called adapters inter-face with underlying sensors and output sensor data asIDUs. Adapters decouple what is sensed from howit is sensed. Module developers specify the IDU typesa module consumes, the IDU type it generates, and themodules input dependency (e.g., {PIR} OR {cameraAND mic}). Modules have complete autonomy over howand when to output an IDU, and can maintain arbitraryinternal state. For instance, an occupancy inference mod-ule may specify (i) input IDUs from microphone, cam-era, and motion sensor adapters, (ii) allow multiple mi-crophones as input, and (iii) maintain internal state tomodel ambient noise.</p><p>Channels: To ease inference composition, channels linkmodules to each other and to applications. They abstractaway the complexities of connecting modules across dif-ferent devices, including dealing with device disconnec-</p><p>3</p></li><li><p>Inference Engine 1(Home Hub)</p><p>Inference Engine 2(Phone)</p><p>Coordinator(Cloud Server)</p><p> Engine, Inference Graph, and Coverage Managers</p><p> Remote Channel Manger</p><p> Inference Graph Optimizers</p><p> Clock Sync/Skew Manager</p><p>Persistent WebSocket Connection</p><p>Persistent WebSocket Connection</p><p> Subg...</p></li></ul>


View more >