BraceForce: A Middleware Enabling Novice Programmers to Integrate Sensing in CPS Applications
Xi Zheng, Dewayne E. Perry, Christine Julien ([email protected], [email protected], [email protected])
The Center for Advanced Research in Software Engineering Mobile and Pervasive Computing Lab, Electrical and Computer Engineering The University of Texas at Austin
TR-ARiSE-2013-003
© Copyright 2013 The University of Texas at Austin BraceForce: A Middleware Enabling Novice Programmers to Integrate Sensing in CPS Applications
Xi Zheng, Dewayne E. Perry, Christine Julien The Center for Advanced Research in Software Engineering Mobile and Pervasive Computing Lab The University of Texas at Austin [email protected],[email protected],[email protected]
ABSTRACT forms with little potential for portability to other plat- Even as the use of sensor networks to support CPS forms or integration with other sensors. Debugging CPS applications grows, our ability to seamlessly and effi- applications that inherently integrate with a physical ciently incorporate sensor network capabilities remains environment requires not only the aforementioned in- astoundingly difficult. Today, accessing remote sensing tegration of the application with sensing but also the data and integrating this data into the adaptive behav- use of a testing harness that, at debugging time, ac- ior of a dynamic user-facing CPS application requires in- cesses sensed data about the physical environment for teracting with multiple sensor platform languages, data the purposes of validating the actions of the applica- formats, and communication channels and paradigms. tion. Integrating sensing for application and debugging We present BraceForce, an open and extensible middle- support in a way that is easy, flexible, and portable is ware that allows developers to access the myriad remote essential for supporting CPS application development. sensing capabilities inherent to cyber-physical systems In general, research in this space has been focused on using very minimal code. Further, BraceForce incorpo- demonstrating the feasibility of applications, the devel- rates event- and model-driven data acquisition as first- opment of support services such as routing protocols or class concepts to provide efficient access to sensing while energy-saving algorithms, or on advancement of hard- retaining expressiveness and flexibility for applications. ware platforms and operating systems. Little focus has This paper presents the BraceForce middleware archi- been applied to effective development support for ap- tecture and key abstractions, describes their implemen- plications that integrate the capabilities of networked tations, and provides an empirical study using Brace- sensing platforms in easy to use and extensible ways. In Force to support CPS applications. addition to the variety of data formats, communication technologies, and programming platforms a developer Keywords must tackle, CPS applications also require handling net- work dynamics and energy constraints. sensor drivers, sensor network, mobile computing, smart- This paper introduces BraceForce, a middleware for phones, cyber physical systems CPS application development that simplifies the devel- opment, deployment, and debugging of CPS applica- 1. INTRODUCTION tions. In supporting application deployment, Brace- Developing and deploying CPS applications involves Force allows the developer to connect the application to a large amount of low-level programming that requires sensing assets in the deployment environment. In sup- interacting with different (often proprietary) data for- porting application debugging, BraceForce can be used mats, languages, and operating systems. In practice, to monitor a test environment using capabilities that applications are built for specific sensor network plat- may not be available in the deployment environment. Architecturally, BraceForce defines functional tiers that encapsulate related aspects but coordinate in such a way that the tiers’ deployment to particular physical assets is flexible. Different tiers can be deployed on user-facing Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are devices or on sensing devices with limited capabilities, not made or distributed for profit or commercial advantage and that copies directly addressing and leveraging the specific capabili- bear this notice and the full citation on the first page. To copy otherwise, to ties and intentions of each device. BraceForce provides republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. auto-discovery of new sensing and computing assets, al- Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00. lowing easy integration of new capabilities into existing velopment through an exploratory study of BraceForce applications or automatic and seamless extension of a applied to real CPS applications that rely on networked debugging environment. As BraceForce discovers new sensors. BraceForce provides a clear design contract for components, the tiered architecture organically extends integrating new sensors into existing applications. This to these new components, flexibly deploying the neces- paper makes the concrete contributions in three areas: sary tiers to the new components. 1. Supporting CPS application developers and users Instead of using a proprietary programming language (e.g., nesC [9]), supporting a single hardware platform ◦ BraceForce provides a simple and unified program- (e.g., ODK [5]), or creating a new standard (e.g., Dan- ming interface to reduce programming barriers of delion [19] or DASH [7]), BraceForce presents a simple CPS applications that integrate sensing. Java programming interface for integrating new sensing ◦ BraceForce’s tiered architecture enables dynamic capabilities. To add a new sensor to BraceForce, a de- updates to CPS applications and their physical de- veloper just needs to implement a simple sensor driver ployments without intervention by the users. interface that provides essential commands (e.g., open, 2. Supporting flexible and expressive CPS applications close, query) and configuration. The driver implementa- ◦ BraceForce can be deployed to heterogeneous de- tion can be specific to the particular sensor but basically vices in different configurations to meet constraints translates raw data into meaningful BraceForce sensor of CPS applications and devices. data constructs, guided by the provided BraceForce in- ◦ BraceForce supports both pull- and push-based in- terfaces. BraceForce handles issues such as thread man- teraction with sensing devices. agement, networking, remote procedure call, etc. ◦ BraceForce embraces model-driven data acquisition BraceForce supports both the traditional pull and more to address energy concerns of CPS applications. flexible push based interaction with sensing devices. Out 3. Studying CPS application development of concern of energy-saving, BraceForce’s default form of interaction is event-driven data acquisition, in which ◦ We demonstrate and evaluate how BraceForce makes sensed data is only pushed to an interested applica- both the development process more approachable tion on the occurrence of an event. Applications specify and the resulting CPS application more efficient. ◦ We demonstrate that MDDA within BraceForce thresholds on changes in sensed values that determine can significantly reduce the network overhead, which when new samples are returned. Such an approach has in turn reduces energy consumption. been shown to dramatically reduce energy costs of in- teracting with networked sensors. Existing approaches The next section places this paper’s contributions in that support some integration of sensing capabilities the context of related work. In Section 3, we provide with mobile application development [5] provide only complete details of the BraceForce middleware. Sec- continuous sampling or instantaneous polling, which re- tion 4 presents the empirical design for our evaluation, quire the application to tune the interaction with the while Section 5 describes its results. sensing platform and therefore either expend extrane- ous energy or miss important sensed value changes. 2. RELATED WORK BraceForce embraces model-driven data acquisition BraceForce aims to make sensor programming trans- (MDDA) [14, 21, 22, 24, 27] to reduce energy costs of parent to CPS application developers by explicitly and integrating sensing in CPS applications. MDDA sup- intentionally hiding low-level sensing concerns. Brace- presses sensor readings that are predictable according to Force provides CPS application developers dynamic de- some a priori or learned model. BraceForce supports ployment and automatic discovery of networked sensors, (i) temporal models of data evolution based on previ- distributed data caching and aggregation capabilities, ous sensor readings [24]; (ii) models based on underlying and presents the networked sensors through a combina- physics principles of the sensed system [21]; (iii) mod- tion of event-driven and model-driven accessors, provid- els derived from applying data mining to prior sensed ing both flexibility for developers and efficiency for the data [14]; and (iv) models expressing correlations of data deployment. Existing approaches tackle similar and in in space and time [27]. While the use of model-driven some cases overlapping concerns, but, to our knowledge, data acquisition is itself not novel to BraceForce, what is BraceForce is the first to provide transparent support of new is how BraceForce integrates model-driven data ac- CPS application development and debugging. quisition in a general purpose programming framework Sensor Platforms. Much work on sensor networks for acquiring and interacting with sensed data. has focused on hardware and software platforms to sup- This paper describes BraceForce, from its flexible ar- port increasingly sophisticated capabilities. TinyOS [13] chitecture to a prototype implementation. We directly is an operating system for sensor networks that enables assess BraceForce’s ability to ease CPS application de- developers to use networked sensors to solve distributed sensing, computational, and coordinating tasks. Its fo- stractions have a network focus and are intuitive for sen- cus has largely been on supporting increasingly complex sor and networking experts but do not promote data and and sophisticated applications at the expense of usabil- data integration for application developers. MiLAN [11] ity and flexibility [17]. The Robot Operating System builds on networking and discovery protocols, using a (ROS) [23] provides a component-oriented style of pro- plug-in mechanism to incorporate arbitrary protocols. gramming, in which components communicate via pub- Application developers use QoS graphs to specify their lish/subscribe mechanisms and two-way service calls, sensing requirements, and MiLAN uses this information both using user-defined topics. However, ROS only sup- along with the sensor network state to determine how to ports a communication scale of one machine, and con- configure the network and sensors to meet the provided nection mechanisms are among ROS components run- requirements. This high-level data-centric abstraction is ning on the same machine; CPS systems require coordi- the style we target in our middleware. We couple these nation among distributed components. ROS also comes abstractions with automatic sensor discovery and a dis- with a non-trivial learning curve. tributed architecture that, by its nature, addresses the Arduino has gained wide popularity due to simplic- mixed resource constraints of our target environment. ity, high degrees of usability, and the resultant enabling Dandelion [19] supports developing wireless body sen- of rapid prototyping. While programming for Arduino sor applications on smartphones using a programming is more straightforward, programmers are still required abstraction called a senselet, which abstracts a device to interact with the Arduino at a very low-level of ab- driver and allows applications to integrate data from straction. This does not allow for flexible updating and that device through remote method invocation. This discovery of local sensing devices. The Android Sen- abstraction is data-centric and provides a jumping-off sor Framework [1] provides a programming interface to point for BraceForce’s abstractions, but Dandelion does access hardware and software sensing components on not incorporate higher-level programming constructs for Android. This framework is also limited in its abstract aggregation, model-driven data acquisition, and auto- capabilities; the developer is still entirely responsible for matic sensor discovery and integration. thread control and other essential concerns for accessing Perhaps most similar to our goals, Open Data Kit sensors. Further, the Android Sensor Framework does (ODK) Sensors [5] simplifies deployment of smartphone not enable connecting to external sensors connected to applications that rely on data from a smartphone’s ex- the device via BlueTooth, USB or other connectivity ternal sensors (e.g., connected via USB and BlueTooth). modes. Instead, the developer must use other libraries. The application logic may rely on data from both on Integrating sensing in CPS applications requires high board and external sensors, and the sensor driver devel- level abstractions to provide automatic sensor discov- oper implements specific driver interfaces for configuring ery and flexible and efficient access to the sensor data sensors, packaging the data they generate, and connect- via event- and model-driven data acquisition. Brace- ing that data into the Android framework. Interactions Force unifies access to a variety of sensor platforms and with sensors are confined to pull-based acquisition with provides a flexible and expressive application program- only locally connected sensors. ODK Sensors is tightly ming interface with high-level programming constructs integrated with Android, limiting its applicability. tailored to networked sensor integration. We focus on easing the integration of distributed sen- Sensor Programming Frameworks. Easing pro- sor data into CPS applications without limiting the ex- gramming of sensor networks has received significant pressiveness of sensing capabilities or over-utilizing pre- attention. Mat´e[18], for example, is a tiny virtual ma- cious constrained resources. This demands not only au- chine that allows developers to concisely express sensor tomatic sensor discovery and integration but also ab- programs and cause these programs to be dynamically stractions for acquiring sensor data in ways other than deployed. A virtual machine approach is very flexible, through direct sensor polling. but Mat´ecomes with the cost of increased complex- Model Driven Data Acquisition. Model-driven ity due to the severe and unmitigatable resource con- data acquisition (MDDA) can limit costly communi- straints of the target environment [12]. The mixed (and cation with networked sensors by suppressing polling richer) capabilities of our target CPS environment al- and notifications from the sensors except when the sen- low us to circumvent these resource constraints using sor readings deviate from some pre-defined or learned a distributed architecture. In addition, we can embed model. Gupta et al. studied the problem of collecting data-driven techniques in our programming abstractions spatially correlated data in a wireless sensor network, to make acquiring and integrating sensor data a natural based on the theory of dominating sets [10]. Other work part of the programming task. has focused on achieving data suppression using tempo- SensorWare [4] shares the resources of a single node ral and spatial data correlation either by dividing the among many applications. SensorWare’s primary ab- network into clusters [20], exploiting domain knowledge regarding reasonable ranges of sensed values [26], or a binary array) is converted into a BraceForce sensor combining temporal and spatial correlations [27]. Other data response, which defines an abstract data type uni- approaches use simple models of sensed value trends to fied across all sensor data. Each sensor data response generate readings only when the sensed value deviates maps a data type (or types) to a value (or values) and from the model’s predicted value. Simple linear mod- associates a timestamp with the data. This timestamp els are very effective [24], and the approach can also be ensures that data used by higher layers is fresh within applied to in-network aggregation of raw values [8]. the requirements of the application. We are motivated to use similar techniques in Brace- Force to suppress data without sacrificing the quality of knowledge about the sensed entity. BraceForce al- lows CPS developers to incorporate different models of MDDA both at the level of individual sensors and at CPSApplica:on)Node) the level of an entire distributed application to handle Distributed)Data)) Model)driven) different deployment scenarios and meet specific energy Cache)and)Aggregator) )))))data)acquisi:on) requirements of CPS applications. We avoid approaches Distribu:on)Layer) D2D)Discovery) Distribu:on)Layer) that demand a particular topological structure (e.g., designated clusters of nodes) to avoid unnecessary rigid- Data)Layer) Data)Layer) Model)driven) Model)driven) ity in a dynamic network of supporting sensors and rely )))))data)acquisi:on) )))))data)acquisi:on) on simple models that have shown significant gains. Sensor)Driver)Layer) Sensor)Driver)Layer)
3. BRACEFORCE On#board) On#board) Driver) Sensors) Driver) Sensors) We first describe BraceForce from an abstract archi- tectural perspective; we then detail our prototype im- plementation. External) External) 3.1 BraceForce Abstract Architecture Sensors) Sensors)
BraceForce comprises five abstraction layers: the sen- Figure 1: BraceForce: Uniform Environment sor driver layer, the data layer, the distribution layer, the distributed data cache and aggregator layer, and the Data Layer. Mobile operating systems allow sensors CPS application layer. Fig. 1 shows one example Brace- to be accessed directly using BlueTooth, Near Field Force deployment with these five layers. Communication (NFC), USB, and proprietary interfaces to on-board sensors. This manner of access is device- 3.1.1 BraceForce Layered Architecture. specific and requires a non-trivial amount of low-level Sensor Driver Layer. In the current state of the art, development and testing using interfaces that are not CPS application developers must understand low-level portable across platforms. These programming methods protocols and hardware-specific aspects of sensors to be also usually entail a steep learning curve. BraceForce able to write sensor drivers. Moreover, the raw data encapsulates these communication and sensor frame- from the sensor has no open standard and often loses work interactions in the data layer, thus explicitly sep- the original temporal information associated with the arating user-application code above from sensor- and sensor data retrieval. These issues demonstrate a gap platform-specific code below. The data layer also con- between the low-level sensing capabilities of both on- trols data retrieval for locally connected sensors (both board and external sensors and the application space. on-board and external), where the options include push, At BraceForce’s base, the sensor driver layer bridges in which a sensor pushes every data reading to the data this gap. The sensor driver layer encapsulates functions layer; pull, in which the data layer periodically polls the related to interacting with a sensor, from configuration, connected sensor; and event-driven, in which a sensor through starting, querying, reconfiguring, stopping, and notifies the data layer only upon the occurrence of some cleaning up allocated resources. The sensor driver layer predefined “event. ” At the data layer, BraceForce in- forces driver developers to adhere to a design contract troduces single-device MDDA, whereby simple models enabling these common functionalities and unifying on- of temporal correlation can be used to suppress sensor board and external sensors into a shared data packet readings as long as they follow an expected model [24]. format that can be used throughout the remainder of Distribution Layer. CPS applications require a dis- the BraceForce architecture. A driver developer creates tributed view of active and available sensors, both on the connection between the sensor and the driver layer the local device and available remotely on other de- by defining how raw sensor data (e.g., in the form of vices in the network. Programmers must use message passing mechanisms or RPC-like connectors to make de- gation and sensing capabilities, and the programming vices in the network communicate and coordinate their interface allows the application to subscribe to them. actions. Developers must also handle location trans- Based on the particular application goals, these sensors parency and other intrinsic issues related to distributed can be integrated just as part of a testing harness at programming (e.g., concurrency, failures, and time syn- debugging time or can provide essential functional in- chronization). In the distribution layer, BraceForce pro- formation for the application at deployment time. vides automatic discovery of other BraceForce-enabled devices, and thereby other BraceForce connectable sen- 3.1.2 BraceForce Deployment Scenarios. sors. BraceForce uses a combination of best effort pro- Fig. 1 showed just one possible deployment scenario tocols for the on-the-fly discovery and reliable proto- in which all of the devices are homogeneous (e.g., smart cols for initiating and accepting remote method calls to phones) and have the same capabilities. In BraceForce, transfer sensor data from discovered sensors. The distri- different physical assets can support different pieces of bution layer also extends the data acquisition modalities the architecture, depending on a particular device’s ca- of the data layer by defining data listeners that bridge pabilities and functional requirements. In any deploy- between the data layer below and the aggregation layer ment, the sensor driver layer and the discovery layer above and, more importantly, across distributed devices. must be present on any sensing-capable device, as they One specific function of this bridge is to use guidance are essential to connecting to and getting data from sen- from the cross-device MDDA performed at the aggre- sors. On moderately capable devices, the addition of gation layer (described next) to correctly configure and the data layer adds multiple modalities for driving data query underlying (distributed) sensors. Within the dis- acquisition and the potential for expressive temporal- tribution layer, BraceForce’s automatic detection of dis- based MDDA. Fig. 2 shows an alternative deployment tributed sensors can be deployed alongside the Sensor in which the system consists of heterogeneous devices; Driver Layer, circumventing the data layer, simplifying in this example, the application runs on a dedicated the BraceForce deployment on devices that have signif- high-powered device (e.g., a laptop) that connects to a icant computation and storage constraints. variety of sensing devices of different capabilities, held Distributed Data Cache and Aggregator. CPS appli- together by the distribution layer. cations that require large scale deployments often in- clude sensing devices that have severe computation and storage constraints. In this case, it is highly ideal that data storage and processing are done in backend servers CPS)Applica:on)Node) or other more powerful devices in the network. Pro- gramming these features in a scalable and reliable way Distributed)Data)) Model)driven) Cache)and)Aggregator) )))))data)acquisi:on) is a challenge for CPS application developers. Brace- Force’s aggregation layer is specifically designed to deal Discovery)Ini:ator) with this challenge through a unified view of all of the D2D)Discovery) dynamic sensing capabilities of the networked sensing support infrastructure. As new sensors are discovered Discovery)Target) Discovery)Target) on-the-fly or known sensors disappear, these dynamics Sensor)Driver)Layer) are handled seamlessly by BraceForce. Given a dis- Data)Layer) Model)driven) tributed view of aggregate sensing capabilities, the ag- )))))data)acquisi:on) On.board) gregation layer can perform high-level MDDA, for exam- Driver) Sensors) Sensor)Driver)Layer) ple, by using more sophisticated models based on spa- tial correlations or learned relationships among sensed On.board) data [22]. In our prototype, we demonstrate the poten- Driver) Sensors) tial for this high-level MDDA using a spatial correlation External) Sensors) model that suppresses sensor readings that are similar to neighboring readings. More generally, from the ag- gregation layer, BraceForce can expressively direct data External) acquisition (e.g., by choosing between event-driven data Sensors) acquisition, the push modality, and the pull modality) Figure 2: BraceForce: Mixed Environment for all of the sensors under its purview. This layer also We envision three primary use cases for BraceForce. encapsulates data mining and compression. In the obvious case, BraceForce is an integral part of CPS Application Node. To support the CPS appli- the CPS application. Take a smart home application in cation node, BraceForce maintains a registry of aggre- which a home controller connects to various sensing de- vices integrated with the home to control the ambient description of an operation to be performed; some- environment. In this case, the homeowner may intro- thing that has happened and is being announced. duce and remove components from the home over its Android Interface Definition Language (AIDL): lifetime, and, using BraceForce, the changing capabili- allows definition of the programming interface that ties are seamlessly reflected to the application. the client and service use to communicate with each As a second case, we envision the middleware to be other using interprocess communication (IPC). deployed for large scale ad-hoc sensor networks (e.g., Bundle: a data structure of key-value mappings but to monitor the fire situation in a forest). The Sensor not limited to a single String/Object mapping. Driver Layer and Discovery Layer can be combined into Android does not provide significant high-level ab- a service to be deployed on cheap sensor devices that stractions for programming coordination among distributed have basic sensing and networking capacity without ad- devices. From a model perspective, BraceForce assumes ditional computation and storage resources. These de- such capabilities, e.g., in the form of Java RMI. To sup- vices can be deployed at a mass scale. The Distributed port our BraceForce prototype on Android, we therefore Data Cache and Aggregator can be deployed as service implement our own version of RMI by building on sev- to more powerful Android devices or a cluster of back- eral open source projects. We use JsonBeans [15] to end servers for data processing. The sensor data then serialize and deserialize Java object graphs to and from will be passed to the CPS application node, which runs JSON [6]. JsonBeans is an obvious choice for this task on user-facing Android devices to notify users (e.g., fire because it is very lightweight (45KB) with no external workers and rescuers) of the real time situation in the dependencies. We use ASM [2, 16] to dynamically gen- environment and allow them to make informed actions. erate classes involved in the RMI process in binary form. As a third use case, consider a mobile autonomous robot application wrapped in a test harness that con- 3.2.2 Unified Data and Subscription Interfaces nects to expressive sensing capabilities available in the Programming for Android requires interacting with debugging environment but not expected to be available the Dalvik virtual machine, and it is inevitable that in the deployment environment. At deployment time, our implementation accesses some proprietary Android the robot may be placed in an unknown territory and constructs (e.g., Bundle). To remain as general as pos- expected to perform some tasks. At debugging time, sible, we implement a wrapper that encapsulates these however, the developer may control the environment proprietary components and presents a generic interface and may be able to monitor various aspects of the robot to the BraceForce implementation. Within this wrap- using sensors embedded in the environment (e.g., over- per, BraceForce translates Android data structures to head cameras). The debugging program that surrounds reusable and portable Java data structures. the actual control application can use BraceForce to ac- Android provides sensor data subscription only for in- cess these sensors for debugging; at deployment time, ternal sensors. To subscribe for sensor data from ex- these connections to BraceForce and the debugging en- ternal sensors (e.g., sensors connected via USB), devel- vironment are removed. opers have to create a subscription model themselves 3.2 BraceForce Implementation (e.g., using the observer design pattern) and write a large amount of low-level code to access sensor data. To demonstrate and evaluate BraceForce, we have Retrieving data from other devices is even more diffi- built the entire architecture in the Android operating cult. In BraceForce, we provide a unified subscription system. We choose Android as our initial platform as interface for developers to access internal sensors, ex- it is open source and has extensive support for back- ternal sensors, and networked sensors. Fig. 3 shows ground processes, including several built-in constructs the BraceForce API used to subscribe sensed data from for inter-application communication [25]. BraceForce is an internal accelerometer (line 1), a temperature sen- not particular to Android, and we avoid using low-level sor (Dallas DS18B20) connected via USB (line 2), and constructs and interfaces specific to Android and not all accelerometers on networked devices (line 3). Line 4 replicated on other platforms. shows how to retrieve sensor data; it is the same regard- 3.2.1 Android Programming Idiosyncrasies less of the type of sensor connection. The retrieved data contains a timestamp of the data and where the data is A handful of accidental complexities arise from our from; data values are accessed through meaningful keys choice of Android; below, we describe these challenges instead of array indices provided by Android. and our solutions as they arise. In addition, to under- stand the discussions of the architecture, we briefly re- 3.2.3 Thread Management and Android services view a vocabulary related to Android: Android provides much support for multi-threaded Intent: a passive data structure holding an abstract applications. As with any multithreaded environment, 1 BraceSensorManager. subscribeSensorEvent( BuiltInSensorType .ACCELEROMETER. name() , this , covery mechanisms in the distribution layer, e.g., [3], so this ); that devices can talk to each other even when they are 2 BraceSensorManager. subscribeSensorEvent(”DS18B20”, this , this , SensorAutoDetection.USB ); in different networks (e.g., behind NAT). 3 BraceSensorManager. subscribeSensorEvent( BuiltInSensorType .ACCELEROMETER. name() , this , 3.2.5 Sensor Driver Definition and Discovery this , true ); 4 BraceSensorManager. retrieveSensorData(event); BraceForce’s driver layer separates CPS application Figure 3: Interface for data subscription developers from sensor driver developers by providing a contract for implementing new sensor drivers. Fig. 4 the added flexibility comes with a significant increase shows this contract and the simple SensorDataResponse in complexity. In Android applications that interface structure, which is mapped to a Java Hashtable. The with sensing, developers must implement (and debug) interface shown in Fig. 4 provides a high-level abstrac- threads to listen for and connect to multiple connec- tion that allows access to sensor data in key-value pair tions. These tasks are far from trivial, as they require fashion instead of requiring the application developer to the developer to have a deep understanding of the re- directly interact with myriad forms of raw sensor data. lationships between the operating system and the life 1 public interface D r i v er { cycles of application components. As our user study 2 byte [] getCmdForSensorConfig(String configKey , (described in Section 5) demonstrates, developers have a Hashtable configParams); 3 byte [] getCmdForSensorData() ; difficult time navigating the complexities of the Android 4 byte [] getCmdForStartSensor() ; APIs related to thread management and concurrency. 5 byte [] getCmdForStopSensor() ; 6 SensorDataResponse getSensorData(List < BraceForce exposes thread managers that explicitly SensorDataPacket> rawData ) ; enable thread-safe access to the shared sensor data avail- 7 byte [] sendDataToSensor(Hashtable actuatorData); 8 void shutdown() ; able to the CPS applications. To enable communication 9 } beyond shared memory, we expose the threads and their 10 public interface SensorDataResponse { 11 L i s t