Fundamentals ❯ Programming Pervasive Spaces

Today, with the advent of enabling technologies such as sensor platforms (e.g., our own Atlas integration Platform)and sensor networks, we’re moving much closer to realizing the vision of ubiquitous and pervasive computing. However, as we create pervasive spaces, we must think ahead to consider how we’ll program them—just as we successfully programmed the mainframe and, later on, the Internet. More details on the vision of programming pervasive spaces can be found in the January 2005 article of the IEEE Pervasive Computing magazine (pdf).

In the Mobile and Pervasive Computing Lab we are actively investigating novel programming models for developing pervasive spaces. Our models are driven by multiple goals, most critically: (1) separating and decoupling device and technology instrumentation (deployment) from application development, which allows applications to be thought of, developed, and deployed after a space is fitted with sensors and devices. It also follows that it allows for previously developed applications to be updated and redeployed, which provides for a healthy life cycle of the smart space and its applications and services; (2) enable regular programmers (not specialized system integrators) to engage in pervasive computing using their current skill sets and common software tools; and (3) ensure the safety of the users and the smart space in the face of potential harm due to programming errors or conflicting applications.

Active Projects:

• Service Oriented Device Architecture (SODA) and SODA Programming Model
• Safety-oriented Programming Model

Service Oriented Device Architecture (SODA) and SODA Programming Model

In the Atlas architecture, once a device is integrated into the smart space, developers will be able to connect and control the device as a software service in their programs. Hence, Service-Oriented Device Architecture (SODA) is automatically enabled by the Atlas middleware. SOA (over which SODA is defined) has been around for quite some time, although not tied to devices. It enabled a new programming environment, allowing semi-automated integration and interaction among various system components represented as services. The SODA model focuses on the services provided, rather than the sensor data streams or active contexts of the environment. Services are stackable. Thus, simple services can be composed together and formed into more complex services. Virtually any kind of sensor, actuator, or other more complex device can be integrated as software services into a common data/services bus. Since the Atlas middleware enables service composition and gracefully handles situations where services are updated, created, and aborted, a programmer simply needs to find the proper services and arrange the service method calls to create an application.

From our experience, we find SODA to be a powerful baseline model, but with two critical limitations. First, it tends to overly promise the capabilities of services by overlooking and hiding their inherent limitations. While service interfaces abstract away unneeded information on internal details of the service, it also blinds the programmer from “seeing” critical information, such as the physical limitations of a device, sensor, or actuator. Therefore, the opacity of a service interface creates risks for service misuse or unfounded guarantees, which could lead to what we call “unsafe programming”. Second, it encourages a free and unrestricted style of application composition over available services. While this is a powerful capability to the programmer, it may lead to unpredictable behaviors in the pervasive space when the applications are deployed. Hence, SOA is too powerful to be safe, which calls for new programming models that bring safety into focus.

To demonstrate the effectiveness of SODA, we developed, jointly with IBM, a reference architecture called STEPSTONE to enable the scalable, “friction-free” integration of device-based healthcare solutions into enterprise systems. In a way, STEPSTONE defines a first proposal to a SODA standard, which we hope attracts a broad community effort to further develop the standard and its specifications.

View the STEPSTONE Open Source project page here.

People

Dr. Sumi Helal
Raja Bose
Chao Chen
Scott de Deugd, IBM
Andy Smith, IBM

Publications

• S. Helal, "Programming Pervasive Spaces," the Standards and Emerging Technologies Department, IEEE Pervasive Computing magazine, Sumi Helal, Dept. Editor, Volume 4, Number 1, January-March 2005. (pdf)

• A. Helal, R. Bose, C. Chen, A. Smith, S. de Deugd, and D. Cook, “STEPSTONE: A SODA Case Study in Personal Tele-Health Management,” Journal of Computing Science and Engineering (JCSE), KIISE, 2011

• M. Weitzel, A. Smith, D. Lee, S. de Deugd, and A. Helal “STEPSTONE 2.0: Enabling Connected Health through Social Network Gadgets,” in Proceedings of the 7th International Conference on Smart Homes and Health Telematics (ICOST), July 2009, Tours, France

• C. Chen and A. Helal, “Device Integration in SODA Using the Device Description Language,” in Proceedings of the IEEE/IPSJ Symposium on Applications and the Internet, July 2009, Seattle, Washington, USA. BEST PAPER AWARD.

• C. Chen, R. Bose, and A. Helal, “Atlas: An Open Model for Automatic Integration and Tele-Programming of Smart Objects,” in Proceedings of the 3rd International Workshop on Design and Integration Principles for Smart Objects (DIPSO 2009), in conjunction with Ubicomp 2009, Orlando, Florida

Safety-Oriented Programming Model

Goal

In a world where pervasive computing technology permeates every aspect of our lives, safety is paramount. Unlike traditional computer systems, pervasive systems tie intimately to the user. Errors and conflicts in such space could have detrimental, dangerous, or undesired effects on the space, the devices, and more importantly, the user. There are no support systems or programming models conscious of the issue of safety. Unrestrained programming is the model du jour, which is inadequate. Without the proper safety support from pervasive systems, application programmers are often burdened with safety checking and risk handling, which requires constant awareness and effort in an open and dynamic pervasive space. A safety-oriented programming model is needed to leverage the rich sensing and actuation capabilities of pervasive systems, and to provide support to cope with various safety hazards arising from a multitude of risk factors in pervasive environments.

Our work so far addressed the need to provide safety support to pervasive spaces from two distinct aspects: (1) System-wide safety support, which engages stakeholders, such as domain experts and device/service providers, to participate and contribute to the overall safety of pervasive spaces, and deliver system-wide safety enforcement mechanisms that are independent of applications, and (2) Program-wide safety support, which empowers programmers with language constructs and utilities for specifying, detecting, and handling safety hazards (exceptions) within applications. We believe that both aspects (system-wide and application-wide) of support will have significant impact on the safety of pervasive systems

We now describe each individual safety support project in more detail.

System-Wide Safety: Pervasive Transactions and Context Envelope Theory

System-wide safety support aims to set programmers free from the burdens of safety checking and exception handling by providing a programming model with safety enforcement mechanisms that are independent of applications. We exploit the concept of a transaction to create such a model. Analogous to database transactions that read/write over data entries, pervasive applications perform sensing/actuation operations to access/control the state of the physical space (context). Similar to how a database protects the consistency and integrity of its data, a pervasive system can leverage similar mechanisms to protect the safety of its contexts.

We coined the term pervasive transaction as a general programming model for pervasive spaces. A pervasive transaction is a sequence of (sensing/ actuation) read/write operations over the physical states of a pervasive space represented as context. To ensure the safe execution of pervasive transactions, four properties have been proposed as our safety criteria: atomicity, integrity, isolation, and durability, or AI²D. To preserve AI²D properties, we propose two run-time mechanisms, namely, context locks and safety transactions, to achieve safe pervasive transaction processing. Context locks protect the pervasive space by “locking” the critical context through denying access of risky operations and isolating conflicting transactions. Safety transactions handle safety constraint violations and the pervasive transaction aborts by recovering the space to a safe and stable context and by safely terminating the aborted pervasive transactions.

We also introduce the context envelope concept, a contextual descriptor of safety constraints. We are working on several novel mechanisms that maintain a context envelope during the lifecycle of a pervasive transaction. Our approach focuses on designing, developing, implementing, and evaluating our pervasive transaction model and its associated context lock and safety transaction mechanisms. We are in the process of designing and implementing a pervasive transaction manager that utilizes the aforementioned mechanisms to achieve AI²D safety assurance throughout the lifecycle of a pervasive transaction.

Program-Wide Safety: Situation-Based Exception Definition and Handling

Exception handling technology can be exploited to achieve safety in pervasive systems. However, existing exception handling mechanisms found in most high-level programming languages are inadequate to handle the complexities of the unsafe “situations” that could arise in pervasive spaces. New algorithms that facilitate the detection and remediation of programmer-described abnormal behaviors, using semantically-aware exception handling programs, are needed. With programming language-based exception handling tools, programmers will be able to express exceptions and associated handling procedures based on application semantics, thus facilitating and programming safer pervasive systems.

In this project, we show how existing mechanisms for exception detection and handling are inadequate for cyber-physical spaces. This assertion holds especially for human-centric and life-critical applications. In response, we are currently working on a novel approach for safely detecting and handling complex exceptions in pervasive spaces. Our approach defines and uses situations as descriptors of contextual semantics of exceptions. We are currently designing, developing, implementing, and evaluating these situational descriptors and their associated exception handling mechanisms and algorithms. We will design and implement a declarative programming language construct for specifying situations and their associated exception detection and handling mechanisms.

People

Dr. Sumi Helal
Dr. Eun-Sun Cho
Chao Chen

Publications

• E. Cho and A. Helal, “Expressive Exceptions for Safe Pervasive Spaces,” submitted to the Journal of Information Processing Systems (JIPS), August 2011
• C. Chen and A. Helal, “System-Wide Support for Safety in Pervasive Spaces,” Journal of Ambient Intelligence and Humanized Computing (AIHC), Springer, December 2011
• C. Chen and A. Helal, “A Device-Centric Approach to a Safer Internet of Things,” in Proceedings of the International Workshop on Networking and Object Memories for the Internet of Things (NOMe-IoT), in conjunction with ACM Ubicomp Conference, September 2011, Beijing, China
• E. Cho and A. Helal, “A Situation-Based Exception Detection Mechanism for Safety in Pervasive Systems,” in Proceedings of the IEEE/IPSJ 11th Annual International Symposium on Applications and the Internet (SAINT), July 2011, Munich, Germany.
• C. Chen and A. Helal, “Toward a Programming Model for Safer Pervasive Spaces,” in Proceedings of the 7th International Conference on Ubiquitous Intelligence and Computing, Xi’an, China, October 26-29, 2010.